HTTP/3 pieprasījumam vajadzīgs UDP atbalstošs starpniekservera ceļš
Atšķiriet HTTP/3 QUIC transportu no parastiem HTTP CONNECT TCP tuneļiem un no SOCKS5 servisa neobligātā UDP atbalsta.
Klientam, kas veiksmīgi sasniedz HTTPS caur TCP starpniekserveri, vēl nav izveidots ceļš HTTP/3. HTTP/3 izmanto QUIC, un QUIC izmanto UDP.
Parasts HTTP CONNECT tunelis nodrošina TCP plūsmu uz tā galamērķi. Tas nekļūst par UDP pārsūtītāju, kad URL sākas ar HTTPS vai galamērķis klausās 443 portā.
SOCKS5 arī vajag UDP ceļu
SOCKS5 definē UDP asociāciju, taču gan klientam, gan serverim tā ir jāievieš, un pārsūtīšanas galapunktam jābūt sasniedzamam. Bibliotēka, kas piedāvā tikai SOCKS TCP dialeri, nevar nodrošināt datagrammu transportu tikai tāpēc, ka tās tipa nosaukums ir SOCKS5.
Tāpat rīka komponents ar nosaukumu proxy var būt izstrādes pakešu zuduma simulators, nevis vispārīgs augšupēja starpniekservera klients. Pārbaudiet tā faktisko saskarni un atbalstīto transportu.
Standarti, piemēram, CONNECT-UDP, definē citu veidu, kā pārvadāt UDP caur HTTP starpniekservera sistēmu. Tie prasa atbalstu abos galos, un tos nevajadzētu jaukt ar tradicionālo CONNECT.
Ja HTTP klients atkāpjas uz HTTP/2 vai HTTP/1.1 TCP ietvaros, pieprasījums var gūt panākumus caur parasto starpniekserveri, lai gan HTTP/3 savienojums netika izmantots. Pierakstiet sarunāto protokolu, kad šī atšķirība ir svarīga.
Tāpēc noderīgais saderības jautājums ir konkrēts: vai šis klients var pārvadāt savas QUIC datagrammas caur šo starpniekserveri ar šo atbalstīto mehānismu? Strādājoša pārlūka lapa vai TCP porta pārbaude atbild uz mazāku jautājumu.