Java Socket HTTP CONNECT tuneli u OpenJDK 25
Koristite put socketa kroz HTTP proxy u OpenJDK 25 da dosegnete dopuštenu TCP uslugu, držeći proxy krajnju točku i odredište odvojenima.
Prilagođeni TCP protokol može putovati kroz HTTP proxy kada taj proxy dopušta CONNECT prema odredištu. Aplikacijski protokol ne mora postati HTTP: HTTP uspostavlja tunel, a zatim aplikacija razmjenjuje vlastite bajtove unutar njega.
OpenJDK 25 nudi put kroz HTTP proxy u Socket(Proxy). Njegova implementacija obavlja CONNECT razmjenu i vraća povezani socket za korištenje aplikaciji.
Proxy route = new Proxy(
Proxy.Type.HTTP,
new InetSocketAddress("proxy.example", 8080));
try (Socket socket = new Socket(route)) {
socket.setSoTimeout(10000);
socket.connect(
InetSocketAddress.createUnresolved("tcp-service.example", 8443),
5000);
InputStream input = socket.getInputStream();
OutputStream output = socket.getOutputStream();
}Ovaj ulomak koristi klase iz java.net i java.io. Zamijenite dvije krajnje točke i obavite razmjenu protokola prije izlaska iz try bloka. Za dopuštenu javnu TCP metu odaberite HTTP kandidate s popisa HTTP proxyja tek nakon što provjerite dopuštenje za CONNECT na portu te mete. Adresa proxyja mjesto je na koje se Java prvo povezuje; adresa proslijeđena u connect označava uslugu do koje proxy mora doći.
Nerazriješeno odredište zadržava svoje ime hosta za CONNECT zahtjev ove implementacije. Razriješeni InetSocketAddress umjesto toga tom zahtjevu dostavlja svoju razriješenu IP adresu. Ta je razlika važna kada proxy mora razriješiti ime usluge ili primijeniti pravilo utemeljeno na imenu hosta.
Što vam uspješna veza ostavlja
Dobiveni tokovi nose podatke tunelirane usluge. Oni ne izlažu zaseban HTTP odgovor koji bi vaša aplikacija trebala pročitati i odbaciti. Dodavanje druge CONNECT razmjene poslalo bi HTTP tekst usluzi nakon što je JDK već uspostavio tunel.
Primjer postavlja vremensko ograničenje povezivanja i vremensko ograničenje čitanja sa socketa; to su odvojene kontrole, a ne jedan zajednički rok za aplikacijsku sesiju.
Dopuštenje za CONNECT i dalje pripada proxyju. Krajnja točka koja prosljeđuje obične web zahtjeve može odbiti port usluge ili zatražiti autentifikaciju prije otvaranja tunela. Te neuspjehe držite odvojeno od poslužitelja koji prihvaća tunel ali kasnije odbija vaš aplikacijski protokol.
Ako tom protokolu treba TLS, pregovarajte TLS kroz povezani socket s predviđenim imenom hosta usluge i uobičajenim provjerama certifikata. Sam CONNECT ne šifrira tok. Za stvarni HTTP API, HTTP klijent ostaje prikladnije sučelje jer obrađuje i HTTP poruke.