Una petició HTTP/3 necessita un camí de proxy amb UDP
Distingiu el transport QUIC de HTTP/3 dels túnels TCP ordinaris d'HTTP CONNECT i del suport UDP opcional d'un servei SOCKS5.
Un client que arriba amb èxit a HTTPS a través d'un proxy TCP no ha establert cap ruta per a HTTP/3. HTTP/3 fa servir QUIC, i QUIC fa servir UDP.
Un túnel HTTP CONNECT ordinari proporciona un flux TCP fins a la seva destinació. No es converteix en un repetidor UDP quan l'URL comença amb HTTPS o quan la destinació escolta al port 443.
SOCKS5 també necessita el camí UDP
SOCKS5 defineix l'associació UDP, però tant el client com el servidor l'han d'implementar, i el punt de repetidor ha de ser accessible. Una biblioteca que només exposa un dialer TCP de SOCKS no pot oferir un transport de datagrames només perquè el nom del seu tipus digui SOCKS5.
De la mateixa manera, un component d'una eina anomenat proxy pot ser un simulador de pèrdua de paquets de desenvolupament i no un client general de proxy ascendent. Examineu la seva interfície real i el transport que admet.
Estàndards com CONNECT-UDP defineixen una altra manera de transportar UDP a través d'un sistema de proxy HTTP. Requereixen suport als dos extrems i no s'han de confondre amb el CONNECT tradicional.
Si el client HTTP retrocedeix a HTTP/2 o HTTP/1.1 sobre TCP, una petició pot tenir èxit a través del proxy ordinari sense que s'hagi utilitzat cap connexió HTTP/3. Anoteu el protocol negociat quan aquesta distinció sigui important.
Per tant, la pregunta útil de compatibilitat és concreta: pot aquest client transportar els seus datagrames QUIC a través d'aquest proxy amb aquest mecanisme admès? Una pàgina de navegador que funciona o una comprovació de port TCP responen a una pregunta més petita.