Java DatagramSocket og SOCKS5 UDP-videresendelse
Forstå hvorfor en Java UDP-socket har brug for en SOCKS5 UDP-implementering, selv når TCP-forbindelser allerede bruger SOCKS.
Din Java HTTP-anmodning virker gennem SOCKS, men en UDP-funktion sender stadig trafik direkte eller fejler. At sætte JVM'ens SOCKS-egenskaber giver ikke DatagramSocket en SOCKS5 UDP-implementering.
DatagramSocket-API'en sender og modtager datagrammer adresseret til netværksendepunkter. Dens connect()-metode vælger en peer til den socket. Den udfører ikke en SOCKS-forhandling med peeren.
En SOCKS5 UDP-rute kræver ekstra arbejde
SOCKS5 definerer en UDP-association, der etableres over en TCP-kontrolforbindelse. Klienten udveksler derefter indkapslede datagrammer med den relay-adresse, som proxyen angiver. Hver indkapslet meddelelse angiver sin destination. En klientimplementering skal håndtere den indramning og kontrolforbindelsens levetid.
At pege en almindelig UDP-socket mod proxyens TCP-lytteport springer disse trin over. At sende din applikations rå datagrammer til den adresse er ikke en erstatning for associationen.
Vælg et bibliotek eller en applikationsfunktion, der udtrykkeligt understøtter SOCKS5 UDP-relay, og bekræft, at serveren også understøtter det. Et bibliotek, der reklamerer med SOCKS-understøttelse, implementerer måske kun TCP CONNECT. Protokolspecifikationen skelner mellem kommandoerne.
UDP-relayet har også brug for en brugbar vej
En vellykket TCP-forbindelse til proxyen etablerer kun kontrolvejen. Firewalls eller NAT-adfærd kan stadig forstyrre datagrammer sendt til relayet. Indsaml det returnerede relay-endepunkt og eventuelle relay-fejl, før du konkluderer, at applikationens destination er offline.
Endelig tilføjer SOCKS-transportstøtte ikke leveringsgarantier til UDP. Din applikations egne timeouts, tabshåndtering og begrænsninger for meddelelsesstørrelse gælder stadig, efter at ruten er ændret.