HTTP/3-beiðni þarf UDP-færa proxy-leið
Greindu QUIC-flutning HTTP/3 frá venjulegum HTTP CONNECT TCP-göngum og frá valfrjálsum UDP-stuðningi SOCKS5-þjónustu.
Biðlari sem nær HTTPS með góðum árangri í gegnum TCP-proxy hefur ekki komið á leið fyrir HTTP/3. HTTP/3 notar QUIC, og QUIC notar UDP.
Venjulegt HTTP CONNECT-göng veitir TCP-straumi til áfangastaðar síns. Það breytist ekki í UDP-endurvarpa þegar slóðin byrjar á HTTPS eða áfangastaðurinn hlustar á gátt 443.
SOCKS5 þarf líka UDP-leiðina
SOCKS5 skilgreinir UDP-tengingu, en bæði biðlarinn og þjónninn verða að útfæra hana, og endapunktur endurvarpans verður að vera aðgengilegur. Safn sem býður aðeins upp á SOCKS TCP-dialer getur ekki veitt dagatalgræmflutning bara af því að tegundarheitið segir SOCKS5.
Á sama hátt getur hluti tóls að nafni proxy verið þróunarlíkan af pakkatapi frekar en almennur uppstreymis-proxybiðlari. Skoðaðu raunverulegt viðmót þess og studdan flutning.
Staðlar eins og CONNECT-UDP skilgreina aðra leið til að bera UDP í gegnum HTTP-proxykerfi. Þeir krefjast stuðnings á báðum endum og ætti ekki að rugla saman við hefðbundið CONNECT.
Ef HTTP-biðlarinn fellur aftur í HTTP/2 eða HTTP/1.1 yfir TCP getur beiðni heppnast í gegnum venjulega proxyið án þess að HTTP/3-tenging hafi verið notuð. Skráðu samið prótókoll þegar sá munur skiptir máli.
Gagnlega samhæfingarspurningin er því nákvæm: getur þessi biðlari borið QUIC-dagatalgræm sín í gegnum þetta proxy með þessu studda fyrirkomulagi? Virk vafrasíða eða TCP-gáttaprófun svarar minni spurningu.