HTTP/3 užklausai reikia UDP palaikančio proxy kelio
Atskirkite HTTP/3 QUIC perdavimą nuo įprastų HTTP CONNECT TCP tunelių ir nuo pasirenkamos SOCKS5 paslaugos UDP paramos.
Klientas, kuris sėkmingai pasiekia HTTPS per TCP proxy, dar nesukūrė kelio HTTP/3. HTTP/3 naudoja QUIC, o QUIC naudoja UDP.
Įprastas HTTP CONNECT tunelis suteikia TCP srautą iki savo paskirties. Jis netampa UDP retransliatoriumi, kai URL prasideda HTTPS arba paskirties vieta klausosi 443 prievado.
SOCKS5 taip pat reikia UDP kelio
SOCKS5 apibrėžia UDP asociaciją, bet ir klientas, ir serveris turi ją įgyvendinti, o retransliavimo galinis taškas turi būti pasiekiamas. Biblioteka, siūlanti tik SOCKS TCP dialerį, negali suteikti datagramų perdavimo vien todėl, kad jos tipo pavadinimas yra SOCKS5.
Panašiai įrankio komponentas, vadinamas proxy, gali būti kūrimo paketų praradimo simulatorius, o ne bendras aukštesnio lygio proxy klientas. Išnagrinėkite jo tikrąją sąsają ir palaikomą perdavimą.
Standartai, tokie kaip CONNECT-UDP, apibrėžia kitą būdą perduoti UDP per HTTP proxy sistemą. Jiems reikia paramos abiejuose galuose ir jų nereikėtų painioti su tradiciniu CONNECT.
Jei HTTP klientas grįžta prie HTTP/2 arba HTTP/1.1 per TCP, užklausa gali pavykti per įprastą proxy, nors HTTP/3 ryšys nebuvo naudojamas. Užfiksuokite suderėtą protokolą, kai šis skirtumas svarbus.
Todėl naudingas suderinamumo klausimas yra konkretus: ar šis klientas gali perduoti savo QUIC datagramas per šį proxy šiuo palaikomu mechanizmu? Veikiantis naršyklės puslapis arba TCP prievado patikra atsako į mažesnį klausimą.