Java DatagramSocket și retransmiterea UDP prin SOCKS5
Înțelegeți de ce un socket UDP Java are nevoie de o implementare SOCKS5 UDP chiar și atunci când conexiunile TCP folosesc deja SOCKS.
Cererea dvs. HTTP Java funcționează prin SOCKS, dar o caracteristică UDP trimite în continuare trafic direct sau eșuează. Setarea proprietăților SOCKS ale JVM nu îi oferă lui DatagramSocket o implementare SOCKS5 UDP.
API-ul DatagramSocket trimite și primește datagrame adresate punctelor finale de rețea. Metoda sa connect() alege un partener pentru acel socket. Nu efectuează o negociere SOCKS cu partenerul.
O rută UDP prin SOCKS5 necesită muncă suplimentară
SOCKS5 definește o asociere UDP stabilită printr-o conexiune de control TCP. Apoi clientul schimbă datagrame încapsulate cu adresa de retransmitere furnizată de proxy. Fiecare mesaj încapsulat își identifică destinația. O implementare de client trebuie să gestioneze această încadrare și durata de viață a conexiunii de control.
Direcționarea unui socket UDP obișnuit către portul de ascultare TCP al proxy-ului omite acești pași. Trimiterea datagramelor brute ale aplicației dvs. la acea adresă nu înlocuiește asocierea.
Alegeți o bibliotecă sau o funcție a aplicației care acceptă explicit retransmiterea UDP prin SOCKS5 și confirmați că serverul o acceptă și el. O bibliotecă ce promovează suport SOCKS poate implementa doar TCP CONNECT. Specificația protocolului distinge aceste comenzi.
Retransmiterea UDP are nevoie și de o cale utilizabilă
O conexiune TCP reușită la proxy stabilește doar calea de control. Firewall-urile sau comportamentul NAT pot încă perturba datagramele trimise către retransmitere. Colectați punctul final de retransmitere returnat și orice eroare de retransmitere înainte de a concluziona că destinația aplicației este offline.
În final, suportul de transport SOCKS nu adaugă garanții de livrare pentru UDP. Timeout-urile proprii ale aplicației, gestionarea pierderilor și limitele de dimensiune ale mesajelor se aplică în continuare după schimbarea rutei.