Zahteva HTTP/3 potrebuje proxy pot s podporo UDP
Razlikujte transport QUIC pri HTTP/3 od običajnih tunelov TCP HTTP CONNECT in od neobvezne podpore UDP pri storitvi SOCKS5.
Odjemalec, ki uspešno doseže HTTPS prek proxyja TCP, ni vzpostavil poti za HTTP/3. HTTP/3 uporablja QUIC, QUIC pa uporablja UDP.
Običajni tunel HTTP CONNECT zagotavlja tok TCP do svojega cilja. Ne spremeni se v posredovalnik UDP, ko se URL začne s HTTPS ali ko cilj posluša na vratih 443.
Tudi SOCKS5 potrebuje pot UDP
SOCKS5 določa povezavo UDP, vendar jo morata izvesti tako odjemalec kot strežnik, končna točka posredovanja pa mora biti dosegljiva. Knjižnica, ki ponuja le klicatelja TCP za SOCKS, ne more zagotoviti prenosa datagramov samo zato, ker se njen tip imenuje SOCKS5.
Podobno je lahko komponenta orodja z imenom proxy razvojni simulator izgube paketov in ne splošni odjemalec nadrejenega proxyja. Preglejte njegov dejanski vmesnik in podprti transport.
Standardi, kot je CONNECT-UDP, določajo drug način prenosa UDP skozi sistem proxy HTTP. Zahtevajo podporo na obeh straneh in jih ne smemo zamenjevati s tradicionalnim CONNECT.
Če odjemalec HTTP preide na HTTP/2 ali HTTP/1.1 prek TCP, lahko zahteva uspe prek običajnega proxyja, ne da bi bila uporabljena povezava HTTP/3. Zabeležite dogovorjeni protokol, kadar je to razlikovanje pomembno.
Zato je koristno vprašanje združljivosti konkretno: ali lahko ta odjemalec prenese svoje datagrame QUIC prek tega proxyja s tem podprtim mehanizmom? Delujoča stran v brskalniku ali preverjanje vrat TCP odgovarja na manjše vprašanje.