Një kërkesë HTTP/3 kërkon një rrugë proxy me mbështetje UDP
Dalloni transportin QUIC të HTTP/3 nga tunelet e zakonshme TCP të HTTP CONNECT dhe nga mbështetja opsionale UDP e një shërbimi SOCKS5.
Një klient që arrin me sukses HTTPS përmes një proxy TCP nuk ka krijuar një rrugë për HTTP/3. HTTP/3 përdor QUIC, dhe QUIC përdor UDP.
Një tunel i zakonshëm HTTP CONNECT ofron një rrjedhë TCP drejt destinacionit të tij. Ai nuk kthehet në një përcjellës UDP kur URL-ja fillon me HTTPS ose kur destinacioni dëgjon në portin 443.
Edhe SOCKS5 ka nevojë për rrugën UDP
SOCKS5 përcakton një asociacion UDP, por si klienti ashtu edhe serveri duhet ta zbatojnë atë, dhe pika fundore e përcjelljes duhet të jetë e arritshme. Një bibliotekë që ofron vetëm një dialer TCP SOCKS nuk mund të sigurojë transport datagramesh vetëm sepse emri i tipit të saj thotë SOCKS5.
Po ashtu, një komponent i një mjeti i quajtur proxy mund të jetë një simulator i humbjes së paketave për zhvillim dhe jo një klient i përgjithshëm i proxy-t të sipërm. Shqyrtoni ndërfaqen e tij aktuale dhe transportin e mbështetur.
Standardet si CONNECT-UDP përcaktojnë një mënyrë tjetër për të transportuar UDP përmes një sistemi proxy HTTP. Ato kërkojnë mbështetje në të dy skajet dhe nuk duhet të ngatërrohen me CONNECT tradicional.
Nëse klienti HTTP zbret në HTTP/2 ose HTTP/1.1 mbi TCP, një kërkesë mund të ketë sukses përmes proxy-t të zakonshëm pa u përdorur asnjë lidhje HTTP/3. Regjistroni protokollin e negociuar kur ky dallim ka rëndësi.
Prandaj pyetja e dobishme e përputhshmërisë është specifike: a mund ky klient t'i transportojë datagramet e tij QUIC përmes këtij proxy me këtë mekanizëm të mbështetur? Një faqe shfletuesi që funksionon ose një kontroll porti TCP përgjigjet një pyetje më të vogël.