Az az ügyfél, amely TCP-proxyn keresztül sikeresen eléri a HTTPS-t, még nem hozott létre útvonalat a HTTP/3-hoz. A HTTP/3 QUIC-et használ, a QUIC pedig UDP-t.

A szokásos HTTP CONNECT-alagút TCP-folyamot ad a céljához. Nem válik UDP-továbbítóvá attól, hogy az URL HTTPS-sel kezdődik, vagy hogy a cél a 443-as porton figyel.

A SOCKS5-nek is kell az UDP-útvonal

A SOCKS5 UDP-társítást definiál, de az ügyfélnek és a kiszolgálónak is meg kell valósítania, és a továbbítási végpontnak elérhetőnek kell lennie. Egy csak SOCKS TCP-tárcsázót kínáló könyvtár nem tud datagramátvitelt biztosítani csak azért, mert a típusának neve SOCKS5.

Hasonlóképpen egy proxy nevű eszközösszetevő lehet fejlesztési csomagvesztés-szimulátor is, nem általános felső proxyügyfél. Vizsgálja meg a tényleges felületét és a támogatott átvitelt.

A CONNECT-UDP-hez hasonló szabványok más módot határoznak meg az UDP HTTP-proxyrendszeren való átvitelére. Mindkét végén támogatást igényelnek, és nem szabad összetéveszteni őket a hagyományos CONNECT-tel.

Ha a HTTP-ügyfél TCP felett HTTP/2-re vagy HTTP/1.1-re esik vissza, a kérés sikerülhet a szokásos proxyn keresztül anélkül, hogy HTTP/3-kapcsolatot használtak volna. Jegyezze fel az egyeztetett protokollt, amikor ez a különbség számít.

A hasznos kompatibilitási kérdés tehát konkrét: képes-e ez az ügyfél a QUIC-datagramjait ezen a proxyn keresztül, ezzel a támogatott mechanizmussal átvinni? Egy működő böngészőoldal vagy egy TCP-portellenőrzés kisebb kérdésre válaszol.

Kapcsolódó cikkek