Un protocolo TCP personalizado pode viaxar a través dun proxy HTTP cando ese proxy permite CONNECT cara ao destino. O protocolo da aplicación non ten que converterse en HTTP: HTTP establece o túnel e despois a aplicación intercambia os seus propios bytes dentro del.

OpenJDK 25 ofrece unha ruta de proxy HTTP en Socket(Proxy). A súa implementación realiza o intercambio CONNECT e devolve un socket conectado para que o use a aplicación.

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

Este fragmento usa clases de java.net e java.io. Substitúa os dous puntos finais e realice o intercambio de protocolo antes de saír do bloque try. Para un destino TCP público permitido, elixa candidatos HTTP da lista de proxies HTTP só despois de comprobar o permiso CONNECT para o porto dese destino. O enderezo do proxy é onde Java se conecta primeiro; o enderezo pasado a connect identifica o servizo que o proxy debe alcanzar.

O destino non resolto conserva o seu nome de host para a solicitude CONNECT desta implementación. Un InetSocketAddress resolto, en cambio, fornece o seu enderezo IP resolto a esa solicitude. Esa distinción importa cando o proxy debe resolver o nome do servizo ou aplicar unha política baseada no nome de host.

Que lle deixa unha conexión correcta

Os fluxos resultantes transportan os datos do servizo tunelizado. Non expoñen unha resposta HTTP separada que a súa aplicación deba ler e descartar. Engadir un segundo intercambio CONNECT enviaría texto HTTP ao servizo despois de que o JDK xa establecese o túnel.

O exemplo fornece un tempo de espera de conexión e un tempo de espera de lectura do socket; son controis separados, non un único prazo global para a sesión da aplicación.

O permiso CONNECT segue pertencendo ao proxy. Un punto final que reenvía solicitudes web ordinarias pode rexeitar o porto do servizo ou esixir autenticación antes de abrir un túnel. Manteña esas fallas separadas dun servidor que acepta o túnel pero despois rexeita o protocolo da súa aplicación.

Se ese protocolo necesita TLS, negocie TLS a través do socket conectado co nome de host previsto do servizo e as comprobacións habituais de certificados. CONNECT por si só non cifra o fluxo. Para unha API HTTP real, un cliente HTTP segue a ser a interface máis cómoda porque tamén xestiona as mensaxes HTTP.

Artigos relacionados