O cerere HTTP/3 are nevoie de o cale de proxy compatibilă cu UDP
Distingeți transportul QUIC al HTTP/3 de tunelurile TCP HTTP CONNECT obișnuite și de suportul UDP opțional al unui serviciu SOCKS5.
Un client care ajunge cu succes la HTTPS printr-un proxy TCP nu a stabilit o rută pentru HTTP/3. HTTP/3 folosește QUIC, iar QUIC folosește UDP.
Un tunel HTTP CONNECT obișnuit oferă un flux TCP către destinația sa. Nu devine un releu UDP atunci când URL-ul începe cu HTTPS sau când destinația ascultă pe portul 443.
Și SOCKS5 are nevoie de calea UDP
SOCKS5 definește o asociere UDP, dar atât clientul, cât și serverul trebuie să o implementeze, iar punctul final al releului trebuie să fie accesibil. O bibliotecă ce expune doar un dialer TCP SOCKS nu poate oferi transport de datagrame doar pentru că numele tipului ei spune SOCKS5.
În mod similar, o componentă a unui instrument numită proxy poate fi un simulator de pierdere de pachete pentru dezvoltare, nu un client generic de proxy upstream. Examinați interfața reală și transportul acceptat.
Standarde precum CONNECT-UDP definesc o altă modalitate de a transporta UDP printr-un sistem de proxy HTTP. Ele necesită suport la ambele capete și nu trebuie confundate cu CONNECT tradițional.
Dacă clientul HTTP revine la HTTP/2 sau HTTP/1.1 peste TCP, o cerere poate reuși prin proxy-ul obișnuit fără a se fi folosit vreo conexiune HTTP/3. Înregistrați protocolul negociat atunci când această distincție contează.
Prin urmare, întrebarea utilă de compatibilitate este concretă: poate acest client să transporte datagramele sale QUIC prin acest proxy cu acest mecanism acceptat? O pagină de browser funcțională sau o verificare a portului TCP răspunde la o întrebare mai mică.