Java Socket HTTP CONNECT-tunnlar i OpenJDK 25

Använd HTTP-proxy-socketvägen i OpenJDK 25 för att nå en tillåten TCP-tjänst, medan proxyns slutpunkt och målet hålls åtskilda.

Ett eget TCP-protokoll kan färdas genom en HTTP-proxy när proxyn tillåter CONNECT till målet. Applikationsprotokollet behöver inte bli HTTP: HTTP upprättar tunneln och därefter utbyter applikationen sina egna byte inuti den.

OpenJDK 25 erbjuder en HTTP-proxyväg i Socket(Proxy). Implementeringen utför CONNECT-utbytet och returnerar en ansluten socket som applikationen kan använda.

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

Det här utdraget använder klasser från java.net och java.io. Byt ut de två slutpunkterna och utför protokollutbytet innan du lämnar try-blocket. För ett tillåtet offentligt TCP-mål väljer du HTTP-kandidater från HTTP-proxylistan först efter att ha kontrollerat CONNECT-tillståndet för målets port. Proxyadressen är platsen där Java ansluter först; adressen som skickas till connect identifierar tjänsten som proxyn ska nå.

Det oupplösta målet behåller sitt värdnamn för den här implementeringens CONNECT-begäran. En upplöst InetSocketAddress levererar i stället sin upplösta IP-adress till den begäran. Den skillnaden spelar roll när proxyn måste lösa upp tjänstens namn eller tillämpa en värdnamnsbaserad policy.

Vad en lyckad anslutning lämnar dig med

Strömmarna som skapas bär den tunnlade tjänstens data. De exponerar inte ett separat HTTP-svar som din applikation ska läsa och kasta bort. Att lägga till ett andra CONNECT-utbyte skulle skicka HTTP-text till tjänsten efter att JDK redan har upprättat tunneln.

Exemplet anger en anslutningstidsgräns och en sockeläsningstidsgräns; det är separata kontroller, inte en enda övergripande tidsfrist för applikationssessionen.

CONNECT-tillståndet tillhör fortfarande proxyn. En slutpunkt som vidarebefordrar vanliga webbförfrågningar kan avvisa tjänstens port eller kräva autentisering innan en tunnel öppnas. Håll de felen åtskilda från en server som accepterar tunneln men senare avvisar ditt applikationsprotokoll.

Om protokollet behöver TLS förhandlar du TLS genom den anslutna sockeln med tjänstens avsedda värdnamn och vanliga certifikatkontroller. Enbart CONNECT krypterar inte strömmen. För ett riktigt HTTP-API är en HTTP-klient fortfarande det bekvämare gränssnittet eftersom den också hanterar HTTP-meddelanden.

Relaterade artiklar