Mae cais HTTP/3 angen llwybr dirprwy sy'n gallu UDP
Gwahaniaethwch gludiant QUIC HTTP/3 od tiwneli TCP HTTP CONNECT cyffredin ac od cymorth UDP dewisol gwasanaeth SOCKS5.
Nid yw cleient sy'n cyrraedd HTTPS yn llwyddiannus drwy ddirprwy TCP wedi sefydlu llwybr ar gyfer HTTP/3. Mae HTTP/3 yn defnyddio QUIC, ac mae QUIC yn defnyddio UDP.
Mae tiwnel HTTP CONNECT cyffredin yn darparu ffrwd TCP i'w gyrchfan. Nid yw'n troi'n ail-ddarlledwr UDP pan fo'r URL yn dechrau ag HTTPS neu pan fo'r gyrchfan yn gwrando ar borth 443.
Mae SOCKS5 hefyd angen y llwybr UDP
Mae SOCKS5 yn diffinio cysylltiad UDP, ond rhaid i'r cleient a'r gweinydd ei weithredu, a rhaid i'r pwynt ail-ddarlledu fod yn gyrraeddadwy. Ni all llyfrgell sy'n cynnig deialydd TCP SOCKS yn unig ddarparu cludiant datagramau dim ond oherwydd bod enw ei math yn dweud SOCKS5.
Yn yr un modd, gall cydran offeryn o'r enw proxy fod yn efelychydd colli pecynnau datblygu yn hytrach na chleient dirprwy llifoedd cyffredinol. Archwiliwch ei ryngwyneb gwirioneddol a'r cludiant a gefnogir.
Mae safonau fel CONNECT-UDP yn diffinio ffordd arall o gludo UDP drwy system ddirprwy HTTP. Maent angen cymorth ar y ddau ben ac ni ddylid eu drysu â CONNECT traddodiadol.
Os yw'r cleient HTTP yn disgyn yn ôl i HTTP/2 neu HTTP/1.1 dros TCP, gall cais lwyddo drwy'r dirprwy cyffredin heb i unrhyw gysylltiad HTTP/3 gael ei ddefnyddio. Cofnodwch y protocol a drafodwyd pan fo'r gwahaniaeth hwnnw'n bwysig.
Felly mae'r cwestiwn cydnawsedd defnyddiol yn benodol: a all y cleient hwn gludo ei ddatagramau QUIC drwy'r dirprwy hwn gan ddefnyddio'r mecanwaith a gefnogir hwn? Mae tudalen porwr sy'n gweithio neu wiriad porth TCP yn ateb cwestiwn llai.