Mga tunnel ng Java Socket HTTP CONNECT sa OpenJDK 25

Ang isang custom na TCP protocol ay maaaring maglakbay sa isang HTTP proxy kapag pinahihintulutan ng proxy na iyon ang CONNECT patungo sa destinasyon. Hindi kailangang maging HTTP ang protocol ng application: ang HTTP ang nagtatatag ng tunnel, pagkatapos ay ipinagpapalit ng application ang sarili nitong mga byte sa loob nito.

Nag-aalok ang OpenJDK 25 ng landas sa HTTP proxy sa Socket(Proxy). Ginagawa ng implementasyon nito ang pagpapalitan ng CONNECT at nagbabalik ng konektadong socket para gamitin ng application.

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

Gumagamit ang bahaging ito ng mga class mula sa java.net at java.io. Palitan ang dalawang endpoint at gawin ang pagpapalitan ng protocol bago umalis sa bloke ng try. Para sa pinahihintulutang pampublikong target na TCP, pumili ng mga kandidatong HTTP mula sa listahan ng HTTP proxy pagkatapos lamang suriin ang pahintulot sa CONNECT para sa port ng target na iyon. Ang address ng proxy ang lugar kung saan unang kumokonekta ang Java; ang address na ipinapasa sa connect ang tumutukoy sa serbisyong dapat maabot ng proxy.

Ang hindi pa nareresolbang destinasyon ay nagpapanatili ng hostname nito para sa kahilingan ng CONNECT ng implementasyong ito. Ang nareresolbang InetSocketAddress naman ay nagbibigay ng nareresolbang IP address nito sa kahilingang iyon. Mahalaga ang pagkakaibang iyon kapag kailangang i-resolve ng proxy ang pangalan ng serbisyo o magpatupad ng patakarang nakabatay sa hostname.

Ano ang iniiwan sa iyo ng matagumpay na koneksyon

Dinadala ng mga resultang stream ang data ng serbisyong nasa tunnel. Hindi sila naglalantad ng hiwalay na tugon ng HTTP na dapat basahin at itapon ng iyong application. Ang pagdaragdag ng pangalawang pagpapalitan ng CONNECT ay magpapadala ng tekstong HTTP sa serbisyo pagkatapos nang itatag ng JDK ang tunnel.

Nagtakda ang halimbawa ng timeout ng koneksyon at timeout ng pagbasa sa socket; magkahiwalay ang mga kontrol na iyon, hindi isang pangkalahatang takdang oras para sa session ng application.

Pag-aari pa rin ng proxy ang pahintulot sa CONNECT. Ang endpoint na nagpapasa ng mga ordinaryong kahilingan sa web ay maaaring tanggihan ang port ng serbisyo o humingi ng pagpapatunay bago magbukas ng tunnel. Paghiwalayin ang mga kabiguan na iyon mula sa server na tumatanggap ng tunnel ngunit kalaunan ay tinatanggihan ang protocol ng iyong application.

Kung kailangan ng TLS ng protocol na iyon, makipag-ayos ng TLS sa konektadong socket gamit ang inilaan na hostname ng serbisyo at ang karaniwang pagsusuri ng sertipiko. Ang CONNECT lamang ay hindi nag-e-encrypt ng stream. Para sa tunay na HTTP API, ang HTTP client pa rin ang mas maginhawang interface dahil hinahawakan din nito ang mga mensahe ng HTTP.