Java DatagramSocket og SOCKS5 UDP-videresending
Forstå hvorfor en Java UDP-socket trenger en SOCKS5 UDP-implementasjon selv når TCP-tilkoblinger allerede bruker SOCKS.
Java HTTP-forespørselen din fungerer gjennom SOCKS, men en UDP-funksjon sender fortsatt trafikk direkte eller feiler. Å sette JVM-ens SOCKS-egenskaper gir ikke DatagramSocket en SOCKS5 UDP-implementasjon.
DatagramSocket-API-et sender og mottar datagrammer adressert til nettverksendepunkter. Metoden connect() velger en peer for den sockelen. Den utfører ikke en SOCKS-forhandling med peeren.
En SOCKS5 UDP-rute krever ekstra arbeid
SOCKS5 definerer en UDP-assosiasjon som etableres over en TCP-kontrollforbindelse. Deretter utveksler klienten innkapslede datagrammer med videresendingsadressen som proxyen oppgir. Hver innkapslede melding identifiserer målet sitt. En klientimplementasjon må håndtere denne innrammingen og levetiden til kontrollforbindelsen.
Å peke en vanlig UDP-socket mot proxyens TCP-lytteport hopper over disse trinnene. Å sende applikasjonens rå datagrammer til den adressen er ikke en erstatning for assosiasjonen.
Velg et bibliotek eller en applikasjonsfunksjon som uttrykkelig støtter SOCKS5 UDP-videresending, og bekreft at serveren også støtter det. Et bibliotek som reklamerer med SOCKS-støtte implementerer kanskje bare TCP CONNECT. Protokollspesifikasjonen skiller mellom kommandoene.
UDP-videresendingen trenger også en brukbar vei
En vellykket TCP-tilkobling til proxyen etablerer bare kontrollveien. Brannmurer eller NAT-atferd kan fortsatt forstyrre datagrammer sendt til videresendingen. Samle inn det returnerte videresendingsendepunktet og eventuelle videresendingsfeil før du konkluderer med at applikasjonens mål er frakoblet.
Til slutt legger SOCKS-transportstøtte ikke til leveringsgarantier for UDP. Applikasjonens egne tidsavbrudd, tapshåndtering og begrensninger på meldingsstørrelse gjelder fortsatt etter at ruten er endret.