Java Socket HTTP CONNECT-tunnels in OpenJDK 25

Gebruik het HTTP-proxy-socketpad in OpenJDK 25 om een toegestane TCP-dienst te bereiken, terwijl het proxy-eindpunt en de bestemming gescheiden blijven.

Een aangepast TCP-protocol kan door een HTTP-proxy reizen wanneer die proxy CONNECT naar de bestemming toestaat. Het applicatieprotocol hoeft geen HTTP te worden: HTTP brengt de tunnel tot stand en daarna wisselt de applicatie haar eigen bytes daarbinnen uit.

OpenJDK 25 biedt een HTTP-proxypad in Socket(Proxy). De implementatie ervan voert de CONNECT-uitwisseling uit en geeft een verbonden socket terug voor de applicatie.

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

Dit fragment gebruikt klassen uit java.net en java.io. Vervang de twee eindpunten en voer de protocoluitwisseling uit voordat u het try-blok verlaat. Kies voor een toegestaan openbaar TCP-doel HTTP-kandidaten uit de HTTP-proxylijst pas nadat u de CONNECT-toestemming voor de poort van dat doel hebt gecontroleerd. Het proxyadres is waar Java eerst verbinding maakt; het adres dat aan connect wordt doorgegeven, identificeert de dienst die de proxy moet bereiken.

De niet-opgeloste bestemming behoudt haar hostnaam voor de CONNECT-aanvraag van deze implementatie. Een opgeloste InetSocketAddress levert in plaats daarvan het opgeloste IP-adres aan die aanvraag. Dat onderscheid is belangrijk wanneer de proxy de dienstnaam moet oplossen of beleid op basis van hostnaam moet toepassen.

Wat een geslaagde verbinding u oplevert

De resulterende streams dragen de gegevens van de getunnelde dienst. Ze bieden geen afzonderlijk HTTP-antwoord dat uw applicatie zou moeten lezen en weggooien. Een tweede CONNECT-uitwisseling toevoegen zou HTTP-tekst naar de dienst sturen nadat de JDK de tunnel al heeft opgezet.

Het voorbeeld stelt een verbindingstime-out en een socket-leestime-out in; dat zijn afzonderlijke regelingen, niet één algehele deadline voor de applicatiesessie.

CONNECT-toestemming blijft bij de proxy. Een eindpunt dat gewone webaanvragen doorstuurt, kan de poort van de dienst weigeren of authenticatie eisen voordat een tunnel wordt geopend. Houd die fouten gescheiden van een server die de tunnel accepteert maar later uw applicatieprotocol weigert.

Als dat protocol TLS nodig heeft, onderhandel dan TLS via de verbonden socket met de bedoelde hostnaam van de dienst en de gebruikelijke certificaatcontroles. Alleen CONNECT versleutelt de stream niet. Voor een echte HTTP-API blijft een HTTP-client de handigste interface, omdat die ook HTTP-berichten afhandelt.

Gerelateerde artikelen