Tunnel Java Socket HTTP CONNECT in OpenJDK 25

Usa il percorso socket del proxy HTTP in OpenJDK 25 per raggiungere un servizio TCP consentito, mantenendo separati l'endpoint del proxy e la destinazione.

Un protocollo TCP personalizzato può viaggiare attraverso un proxy HTTP quando quel proxy consente CONNECT verso la destinazione. Il protocollo applicativo non deve diventare HTTP: HTTP stabilisce il tunnel, poi l'applicazione scambia i propri byte al suo interno.

OpenJDK 25 fornisce un percorso tramite proxy HTTP in Socket(Proxy). La sua implementazione esegue lo scambio CONNECT e restituisce un socket connesso che l'applicazione può usare.

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

Questo frammento usa classi di java.net e java.io. Sostituisci i due endpoint ed esegui lo scambio del protocollo prima di uscire dal blocco try. Per una destinazione TCP pubblica consentita, scegli i candidati HTTP dall'elenco dei proxy HTTP solo dopo aver verificato l'autorizzazione CONNECT per la porta di quella destinazione. L'indirizzo del proxy è il punto in cui Java si connette per primo; l'indirizzo passato a connect identifica il servizio che il proxy deve raggiungere.

La destinazione non risolta conserva il proprio nome host per la richiesta CONNECT di questa implementazione. Un InetSocketAddress risolto, invece, fornisce a quella richiesta il proprio indirizzo IP risolto. Questa distinzione conta quando il proxy deve risolvere il nome del servizio o applicare una policy basata sul nome host.

Cosa lascia una connessione riuscita

I flussi risultanti trasportano i dati del servizio incapsulato nel tunnel. Non espongono una risposta HTTP separata che l'applicazione dovrebbe leggere e scartare. Aggiungere un secondo scambio CONNECT invierebbe testo HTTP al servizio dopo che il JDK ha già stabilito il tunnel.

L'esempio imposta un timeout di connessione e un timeout di lettura del socket; sono controlli separati, non un'unica scadenza complessiva per la sessione applicativa.

L'autorizzazione CONNECT appartiene ancora al proxy. Un endpoint che inoltra normali richieste web può rifiutare la porta del servizio o richiedere l'autenticazione prima di aprire un tunnel. Mantieni questi errori distinti da un server che accetta il tunnel ma poi rifiuta il protocollo della tua applicazione.

Se quel protocollo richiede TLS, negozia TLS attraverso il socket connesso con il nome host previsto del servizio e i normali controlli dei certificati. CONNECT da solo non cifra il flusso. Per una vera API HTTP, un client HTTP resta l'interfaccia più comoda perché gestisce anche i messaggi HTTP.

Articoli correlati