Java Socket HTTP CONNECT tuneli u OpenJDK 25

Koristite putanju HTTP proxy socketa u OpenJDK 25 da dosegnete dopuštenu TCP uslugu, a proxy krajnju tačku i odredište držite odvojenim.

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 pruža putanju kroz HTTP proxy u Socket(Proxy). Njegova implementacija izvodi 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 fragment koristi klase iz java.net i java.io. Zamijenite dvije krajnje tačke i obavite razmjenu protokola prije izlaska iz try bloka. Za dopuštenu javnu TCP metu birajte HTTP kandidate sa liste HTTP proxyja tek nakon provjere dopuštenja za CONNECT na portu te mete. Adresa proxyja je mjesto na koje se Java prvo povezuje; adresa proslijeđena u connect označava uslugu koju proxy treba dosegnuti.

Neriješeno odredište zadržava ime hosta za CONNECT zahtjev ove implementacije. Riješeni InetSocketAddress umjesto toga tom zahtjevu dostavlja svoju riješenu IP adresu. Ta razlika je bitna kada proxy mora riješiti ime usluge ili primijeniti pravilo zasnovano na imenu hosta.

Šta vam ostavlja uspješna veza

Dobijeni 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 socketa; to su odvojene kontrole, a ne jedan zajednički rok za aplikacijsku sesiju.

Dopuštenje za CONNECT i dalje pripada proxyju. Krajnja tačka koja prosljeđuje obične web zahtjeve može odbiti port usluge ili zahtijevati autentifikaciju prije otvaranja tunela. Te neuspjehe držite odvojeno od servera koji prihvata 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 prikladniji interfejs jer obrađuje i HTTP poruke.

Povezani članci