Java Socket HTTP CONNECT-tunneller i OpenJDK 25

Brug HTTP-proxy-socketstien i OpenJDK 25 til at nå en tilladt TCP-tjeneste, mens proxyens slutpunkt og destinationen holdes adskilt.

En brugerdefineret TCP-protokol kan rejse gennem en HTTP-proxy, når proxyen tillader CONNECT til destinationen. Applikationsprotokollen behøver ikke at blive HTTP: HTTP etablerer tunnelen, og derefter udveksler applikationen sine egne bytes inde i den.

OpenJDK 25 tilbyder en HTTP-proxy-sti i Socket(Proxy). Implementeringen udfører CONNECT-udvekslingen og returnerer en tilsluttet socket, som applikationen kan bruge.

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

Dette uddrag bruger klasser fra java.net og java.io. Erstat de to slutpunkter, og udfør protokoludvekslingen, før du forlader try-blokken. For et tilladt offentligt TCP-mål vælges HTTP-kandidater fra HTTP-proxylisten først, når du har kontrolleret CONNECT-tilladelsen for målets port. Proxyadressen er det sted, Java opretter forbindelse til først; adressen, der sendes til connect, angiver den tjeneste, som proxyen skal nå.

Den uafklarede destination bevarer sit værtsnavn til denne implementerings CONNECT-anmodning. En afklaret InetSocketAddress leverer i stedet sin afklarede IP-adresse til den anmodning. Den forskel betyder noget, når proxyen skal afklare tjenestens navn eller anvende en politik baseret på værtsnavn.

Hvad en vellykket forbindelse efterlader dig med

De resulterende streams bærer den tunnelerede tjenestes data. De udstiller ikke et separat HTTP-svar, som din applikation skal læse og kassere. Tilføjelse af en anden CONNECT-udveksling ville sende HTTP-tekst til tjenesten, efter at JDK allerede har etableret tunnelen.

Eksemplet angiver en forbindelsestimeout og en socket-læsetimeout; det er separate kontroller, ikke én samlet frist for applikationssessionen.

CONNECT-tilladelsen tilhører stadig proxyen. Et slutpunkt, der videresender almindelige webanmodninger, kan afvise tjenestens port eller kræve godkendelse, før en tunnel åbnes. Hold disse fejl adskilt fra en server, der accepterer tunnelen, men senere afviser din applikationsprotokol.

Hvis den protokol kræver TLS, skal du forhandle TLS gennem den tilsluttede socket med tjenestens tilsigtede værtsnavn og normale certifikatkontroller. CONNECT alene krypterer ikke strømmen. For en egentlig HTTP-API er en HTTP-klient fortsat den mere bekvemme grænseflade, fordi den også håndterer HTTP-beskeder.

Relaterede artikler