'n HTTP/3-versoek het 'n UDP-geskikte proxy-roete nodig
Onderskei HTTP/3 se QUIC-vervoer van gewone HTTP CONNECT-TCP-tonnels en van die opsionele UDP-ondersteuning van 'n SOCKS5-diens.
'n Kliënt wat suksesvol HTTPS deur 'n TCP-proxy bereik, het nog nie 'n roete vir HTTP/3 geskep nie. HTTP/3 gebruik QUIC, en QUIC gebruik UDP.
'n Gewone HTTP CONNECT-tonnel gee 'n TCP-stroom na sy bestemming. Dit word nie 'n UDP-aflaier wanneer die URL met HTTPS begin of die bestemming op poort 443 luister nie.
SOCKS5 het ook die UDP-roete nodig
SOCKS5 definieer UDP-assosiasie, maar beide die kliënt en die bediener moet dit implementeer, en die aflaai-eindpunt moet bereikbaar wees. 'n Biblioteek wat net 'n SOCKS TCP-dialer bied, kan nie 'n datagramvervoer lewer bloot omdat sy tipe naam SOCKS5 sê nie.
Net so kan 'n gereedskap se komponent met die naam proxy 'n ontwikkelings-pakkieverlies-simuleerder wees eerder as 'n algemene opstroom-proxykliënt. Ondersoek sy werklike koppelvlak en ondersteunde vervoer.
Standdaarde soos CONNECT-UDP definieer 'n ander manier om UDP deur 'n HTTP-proxistelsel te dra. Hulle vereis ondersteuning aan beide kante en moet nie met tradisionele CONNECT verwar word nie.
As die HTTP-kliënt terugval na HTTP/2 of HTTP/1.1 oor TCP, kan 'n versoek deur die gewone proxy slaag terwyl geen HTTP/3-verbinding gebruik is nie. Teken die onderhandelde protokol aan wanneer daardie onderskeid saak maak.
Die nuttige verenigbaarheidsvraag is dus spesifiek: kan hierdie kliënt sy QUIC-datagramme deur hierdie proxy dra met hierdie ondersteunde meganisme? 'n Werkende blaaierblad of 'n TCP-poorttoets beantwoord 'n kleiner vraag.