Un protocol TCP personalizat poate călători printr-un proxy HTTP atunci când acel proxy permite CONNECT către destinație. Protocolul aplicației nu trebuie să devină HTTP: HTTP stabilește tunelul, apoi aplicația își schimbă propriii octeți în interiorul lui.

OpenJDK 25 oferă o cale prin proxy HTTP în Socket(Proxy). Implementarea sa efectuează schimbul CONNECT și returnează un socket conectat pe care aplicația să îl folosească.

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

Acest fragment folosește clase din java.net și java.io. Înlocuiți cele două puncte finale și efectuați schimbul de protocol înainte de a ieși din blocul try. Pentru o țintă TCP publică permisă, alegeți candidați HTTP din lista de proxy-uri HTTP numai după ce ați verificat permisiunea CONNECT pentru portul acelei ținte. Adresa proxy-ului este locul unde Java se conectează mai întâi; adresa transmisă către connect identifică serviciul la care proxy-ul trebuie să ajungă.

Destinația nerezolvată își păstrează numele de gazdă pentru cererea CONNECT a acestei implementări. O InetSocketAddress rezolvată furnizează în schimb acelei cereri adresa IP rezolvată. Această distincție contează atunci când proxy-ul trebuie să rezolve numele serviciului sau să aplice o politică bazată pe numele de gazdă.

Ce vă lasă o conexiune reușită

Fluxurile rezultate transportă datele serviciului tunelat. Ele nu expun un răspuns HTTP separat pe care aplicația dumneavoastră ar trebui să îl citească și să îl arunce. Adăugarea unui al doilea schimb CONNECT ar trimite text HTTP serviciului după ce JDK-ul a stabilit deja tunelul.

Exemplul stabilește un timp limită de conectare și un timp limită de citire a socketului; acestea sunt controale separate, nu un singur termen global pentru sesiunea aplicației.

Permisiunea CONNECT aparține în continuare proxy-ului. Un punct final care redirecționează cereri web obișnuite poate refuza portul serviciului sau poate cere autentificare înainte de a deschide un tunel. Păstrați aceste eșecuri separate de un server care acceptă tunelul dar apoi respinge protocolul aplicației dumneavoastră.

Dacă acel protocol necesită TLS, negociați TLS prin socketul conectat cu numele de gazdă intenționat al serviciului și verificările obișnuite ale certificatului. CONNECT singur nu criptează fluxul. Pentru un API HTTP real, un client HTTP rămâne interfața mai convenabilă pentru că gestionează și mesajele HTTP.

Articole similare