Ombi la HTTP/3 linahitaji njia ya proksi inayoweza UDP
Tofautisha usafirishaji wa QUIC wa HTTP/3 na vichuguu vya kawaida vya TCP vya HTTP CONNECT na usaidizi wa hiari wa UDP wa huduma ya SOCKS5.
Mteja anayefikia HTTPS kwa mafanikio kupitia proksi ya TCP hajaunda njia ya HTTP/3. HTTP/3 hutumia QUIC, na QUIC hutumia UDP.
Kichuguu cha kawaida cha HTTP CONNECT hutoa mtiririko wa TCP kuelekea lengo lake. Hakibadiliki kuwa kipitishaji cha UDP wakati URL inaanza na HTTPS au lengo linasikiliza kwenye bandari 443.
SOCKS5 pia inahitaji njia ya UDP
SOCKS5 hufafanua muunganisho wa UDP, lakini mteja na seva zote mbili lazima ziutekeleze, na kiini cha mwisho cha upitishaji lazima kifikiwe. Maktaba inayotoa tu dialer ya TCP ya SOCKS haiwezi kutoa usafirishaji wa datagrami kwa sababu tu jina la aina yake linasema SOCKS5.
Vivyo hivyo, sehemu ya chombo inayoitwa proxy inaweza kuwa kiiga cha upotevu wa pakiti kwa ajili ya maendeleo badala ya mteja wa jumla wa proksi ya juu. Chunguza kiolesura chake halisi na usafirishaji unaotumika.
Viwango kama CONNECT-UDP hufafanua njia nyingine ya kubeba UDP kupitia mfumo wa proksi wa HTTP. Vinahitaji usaidizi pande zote mbili na havipaswi kuchanganywa na CONNECT ya jadi.
Ikiwa mteja wa HTTP anarudi kwenye HTTP/2 au HTTP/1.1 juu ya TCP, ombi linaweza kufanikiwa kupitia proksi ya kawaida bila muunganisho wowote wa HTTP/3 kutumika. Rekodi itifaki iliyojadiliwa wakati tofauti hiyo ni muhimu.
Kwa hivyo swali muhimu la uoanifu ni mahususi: je, mteja huyu anaweza kubeba datagrami zake za QUIC kupitia proksi hii kwa utaratibu huu unaotumika? Ukurasa wa kivinjari unaofanya kazi au ukaguzi wa bandari ya TCP hujibu swali dogo zaidi.