In HTTP/3-fersyk hat in UDP-geskikte proxyrûte nedich
Unterskied it QUIC-ferfier fan HTTP/3 fan gewoane HTTP CONNECT-TCP-tunnels en fan de opsjonele UDP-stipe fan in SOCKS5-tsjinst.
In klant dy't mei súkses HTTPS berikt fia in TCP-proxy hat noch gjin rûte foar HTTP/3 oanlein. HTTP/3 brûkt QUIC, en QUIC brûkt UDP.
In gewoane HTTP CONNECT-tunnel jout in TCP-stream nei syn bestimming. Hy wurdt gjin UDP-relay as de URL mei HTTPS begjint of as de bestimming op poarte 443 harket.
SOCKS5 hat ek de UDP-rûte nedich
SOCKS5 definiearret UDP-assosjaasje, mar sawol de klant as de tsjinner moatte it ymplementearje, en it relay-einpunt moat berikber wêze. In bibleteek dy't allinnich in SOCKS TCP-dialer biedt, kin gjin datagramferfier leverje allinnich om't de namme fan har type SOCKS5 seit.
Lykwols kin in komponint fan in helpmiddel mei de namme proxy in ûntwikkelings-pakketferlies-simulator wêze ynstee fan in algemiene upstream-proxyklant. Undersykje syn wirkliche ynterface en stipe ferfier.
Standerts lykas CONNECT-UDP definiearje in oare manier om UDP troch in HTTP-proxysysteem te ferfieren. Se freegje stipe oan beide kanten en moatte net mei tradisjonele CONNECT betize wurde.
As de HTTP-klant weromfalt nei HTTP/2 of HTTP/1.1 oer TCP, kin in fersyk troch de gewoane proxy slagje wylst gjin HTTP/3-ferbining brûkt waard. Notearje it ûnderhannele protokol as dat ûnderskied fan belang is.
Dêrom is de nuttige kompatibiliteitsfrage konkreet: kin dizze klant syn QUIC-datagrammen troch dizze proxy drage mei dit stipe meganisme? In wurkjende browserside of in TCP-poartkontrôle beantwurdet in lytsere fraach.