Java Socket HTTP CONNECT tunelak OpenJDK 25-en

Erabili HTTP proxy socket bidea OpenJDK 25-en TCP zerbitzu baimendu batera iristeko, proxy muturra eta helmuga bereizita mantenduz.

TCP protokolo pertsonalizatu batek HTTP proxy batetik zehar bidaiatu dezake proxy horrek helmugarako CONNECT baimentzen duenean. Aplikazioaren protokoloak ez du HTTP bihurtu behar: HTTP-k tunela ezartzen du, eta gero aplikazioak bere byteak trukatzen ditu barruan.

OpenJDK 25ek HTTP proxy bidea eskaintzen du Socket(Proxy)-(e)n. Bere inplementazioak CONNECT trukea egiten du eta konektatutako socket bat itzultzen dio aplikazioari erabil dezan.

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();
}

Fragmentu honek java.net eta java.io liburutegietako klaseak erabiltzen ditu. Ordeztu bi muturrak eta egin protokolo trukea try bloketik irten aurretik. Baimendutako TCP helburu publiko baterako, aukeratu HTTP hautagaiak HTTP proxy zerrendatik helburu horren porturako CONNECT baimena egiaztatu ondoren soilik. Proxy helbidea Java lehenengo konektatzen den tokia da; connect-(r)i pasatzen zaion helbideak proxyak iritsi behar duen zerbitzua identifikatzen du.

Ebatzitako helmugak ez du bere ostalari-izena gordetzen inplementazio honen CONNECT eskaerarako. Ebatzitako InetSocketAddress batek, aldiz, bere IP helbide ebatzia ematen dio eskaera horri. Bereizketa hori garrantzitsua da proxyak zerbitzuaren izena ebatzi behar duenean edo ostalari-izenean oinarritutako politika aplikatu behar duenean.

Konexio arrakastatsu batek zer uzten dizun

Lortutako fluxuek tuneleko zerbitzuaren datuak daramatzate. Ez dute zure aplikazioak irakurri eta baztertu beharko lukeen HTTP erantzun bereizi bat erakusten. Bigarren CONNECT truke bat gehitzeak HTTP testua bidaliko lioke zerbitzuari JDK-k tunela jada ezarri ondoren.

Adibideak konexio-denborarako muga eta socket irakurtzeko denbora-muga ematen ditu; kontrol bereiziak dira, ez aplikazioaren saiorako epe orokor bakarra.

CONNECT baimena proxyaren esku dago oraindik. Web eskaera arruntak birbidaltzen dituen mutur batek zerbitzuaren portua ukatu dezake edo tunela ireki aurretik autentifikazioa eskatu. Mantendu huts egite horiek tunela onartu baina gero zure aplikazio protokoloa ukatzen duen zerbitzaritik bereizita.

Protokolo horrek TLS behar badu, negoziatu TLS konektatutako socketaren bidez zerbitzuaren aurreikusitako ostalari-izenarekin eta ziurtagirien ohiko egiaztapenekin. CONNECT bakarrik ez du fluxua zifratzen. Benetako HTTP API baterako, HTTP bezeroa da interfaze egokiena oraindik, HTTP mezuak ere kudeatzen dituelako.

Erlazionatutako artikuluak