HTTP/3 հարցումը պահանջում է UDP-ին ընդունակ փրոքսի ուղի
Տարանջատեք HTTP/3-ի QUIC տրանսպորտը սովորական HTTP CONNECT TCP թունելներից և SOCKS5 ծառայության ընտրովի UDP աջակցությունից։
Այն հաճախորդը, որը հաջողությամբ հասնում է HTTPS-ին TCP փրոքսի միջոցով, դեռ ուղի չի ստեղծել HTTP/3-ի համար։ HTTP/3-ը օգտագործում է QUIC, իսկ QUIC-ը՝ UDP։
Սովորական HTTP CONNECT թունելը TCP հոսք է տալիս իր նպատակակետին։ Այն չի վերածվում UDP վերահաղորդիչի, երբ URL-ը սկսվում է HTTPS-ով կամ նպատակակետը լսում է 443 պորտին։
SOCKS5-ին նույնպես պետք է UDP ուղին
SOCKS5-ը սահմանում է UDP միավորում, սակայն և՛ հաճախորդը, և՛ սերվերը պետք է այն իրականացնեն, և վերահաղորդման վերջնակետը պետք է հասանելի լինի։ Միայն SOCKS TCP dialer տրամադրող գրադարանը չի կարող տվյալագրամային տրանսպորտ ապահովել միայն այն պատճառով, որ իր տիպի անվանումը SOCKS5 է։
Նույն կերպ, գործիքի proxy անվանումով բաղադրիչը կարող է լինել մշակման փաթեթների կորստի սիմուլյատոր, այլ ոչ թե ընդհանուր վերին փրոքսի հաճախորդ։ Ուսումնասիրեք դրա իրական ինտերֆեյսը և աջակցվող տրանսպորտը։
CONNECT-UDP-ի նման ստանդարտները սահմանում են UDP-ն HTTP փրոքսի համակարգով փոխանցելու այլ եղանակ։ Դրանք պահանջում են աջակցություն երկու ծայրերում և չպետք է շփոթել ավանդական CONNECT-ի հետ։
Եթե HTTP հաճախորդը TCP-ի վրա վերադառնում է HTTP/2 կամ HTTP/1.1, հարցումը կարող է հաջողվել սովորական փրոքսի միջոցով, մինչդեռ HTTP/3 կապ չի օգտագործվել։ Գրանցեք համաձայնեցված արձանագրությունը, երբ այդ տարբերությունը կարևոր է։
Ուստի օգտակար համատեղելիության հարցը կոնկրետ է՝ կարո՞ղ է այս հաճախորդն իր QUIC տվյալագրամները փոխանցել այս փրոքսի միջով այս աջակցվող մեխանիզմով։ Աշխատող զննարկիչի էջը կամ TCP պորտի ստուգումը պատասխանում է ավելի փոքր հարցի։