Túnels Java Socket HTTP CONNECT a OpenJDK 25

Utilitzeu la ruta de socket HTTP proxy a OpenJDK 25 per arribar a un servei TCP permès, mantenint separats el punt final del proxy i la destinació.

Un protocol TCP personalitzat pot viatjar a través d'un proxy HTTP quan aquest proxy permet CONNECT cap a la destinació. El protocol d'aplicació no ha de convertir-se en HTTP: HTTP estableix el túnel i després l'aplicació intercanvia els seus propis bytes a dins.

OpenJDK 25 ofereix una ruta de proxy HTTP a Socket(Proxy). La seva implementació fa l'intercanvi CONNECT i retorna un socket connectat perquè l'aplicació l'utilitzi.

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

Aquest fragment utilitza classes de java.net i java.io. Substituïu els dos punts finals i feu l'intercanvi de protocol abans de sortir del bloc try. Per a una destinació TCP pública permesa, trieu candidats HTTP de la llista de proxies HTTP només després de comprovar el permís CONNECT per al port d'aquesta destinació. L'adreça del proxy és on Java es connecta primer; l'adreça passada a connect identifica el servei que el proxy ha d'assolir.

La destinació no resolta conserva el seu nom d'amfitrió per a la sol·licitud CONNECT d'aquesta implementació. Una InetSocketAddress resolta, en canvi, forneix la seva adreça IP resolta a aquesta sol·licitud. Aquesta distinció importa quan el proxy ha de resoldre el nom del servei o aplicar una política basada en el nom d'amfitrió.

Què us deixa una connexió correcta

Els fluxos resultants porten les dades del servei tunelitzat. No exposen una resposta HTTP separada que la vostra aplicació hagi de llegir i descartar. Afegir un segon intercanvi CONNECT enviaria text HTTP al servei després que el JDK ja hagi establert el túnel.

L'exemple proporciona un temps d'espera de connexió i un temps d'espera de lectura del socket; són controls separats, no un únic termini global per a la sessió de l'aplicació.

El permís CONNECT continua pertanyent al proxy. Un punt final que reenvia sol·licituds web ordinàries pot rebutjar el port del servei o exigir autenticació abans d'obrir un túnel. Manteniu aquestes fallades separades d'un servidor que accepta el túnel però després rebutja el vostre protocol d'aplicació.

Si aquest protocol necessita TLS, negocieu TLS a través del socket connectat amb el nom d'amfitrió previst del servei i les comprovacions de certificat habituals. CONNECT sol no xifra el flux. Per a una API HTTP real, un client HTTP continua sent la interfície més convenient perquè també gestiona els missatges HTTP.

Articles relacionats