HTTP/3-pyyntö tarvitsee UDP-kykyisen välityspalvelinreitin
Erottele HTTP/3:n QUIC-siirto tavallisista HTTP CONNECT TCP -tunneleista ja SOCKS5-palvelun valinnaisesta UDP-tuesta.
Asiakas, joka saavuttaa HTTPS:n onnistuneesti TCP-välityspalvelimen kautta, ei ole muodostanut reittiä HTTP/3:lle. HTTP/3 käyttää QUICia ja QUIC käyttää UDP:tä.
Tavallinen HTTP CONNECT -tunneli tarjoaa TCP-virran kohteeseensa. Se ei muutu UDP-välittäjäksi, kun URL alkaa HTTPS:llä tai kun kohde kuuntelee porttia 443.
Myös SOCKS5 tarvitsee UDP-reitin
SOCKS5 määrittelee UDP-liitoksen, mutta sekä asiakkaan että palvelimen on toteutettava se, ja välityksen päätepisteen on oltava tavoitettavissa. Kirjasto, joka tarjoaa vain SOCKS TCP -valitsimen, ei voi tarjota datagrammisiirtoa vain siksi, että sen tyyppinimi on SOCKS5.
Samoin työkalun proxy-niminen komponentti voi olla kehitysvaiheen paketinhäviön simulaattori eikä yleinen ylävirran välityspalvelinasiakas. Tutki sen todellinen rajapinta ja tuettu siirto.
Standardit, kuten CONNECT-UDP, määrittelevät toisen tavan kuljettaa UDP:tä HTTP-välityspalvelinjärjestelmän läpi. Ne vaativat tuen molemmissa päissä, eikä niitä pidä sekoittaa perinteiseen CONNECTiin.
Jos HTTP-asiakas palaa HTTP/2:een tai HTTP/1.1:een TCP:n yli, pyyntö voi onnistua tavallisen välityspalvelimen kautta ilman, että HTTP/3-yhteyttä käytettiin. Kirjaa neuvoteltu protokolla, kun tällä erolla on merkitystä.
Hyödyllinen yhteensopivuuskysymys on siis täsmällinen: voiko tämä asiakas kuljettaa QUIC-datagramminsa tämän välityspalvelimen läpi tällä tuetulla mekanismilla? Toimiva selainsivu tai TCP-portin tarkistus vastaa pienempään kysymykseen.