HTTP/3 eskaera batek UDP gaitasuna duen proxy bidea behar du

TCP proxy baten bidez HTTPS-era ondo iristen den bezeroak ez du HTTP/3rako biderik ezarri. HTTP/3k QUIC erabiltzen du, eta QUICek UDP erabiltzen du.

Ohiko HTTP CONNECT tunelak TCP fluxua ematen dio bere helmugari. Ez da UDP errele bihurtzen URL-a HTTPS-rekin hasten denean edo helmugak 443 portuan entzuten duenean.

SOCKS5ek ere UDP bidea behar du

SOCKS5ek UDP elkartzea definitzen du, baina bai bezeroak eta bai zerbitzariak inplementatu behar dute, eta errele muturra irisgarria izan behar da. SOCKS TCP dialer bat soilik eskaintzen duen liburutegi batek ezin du datagramen garraiorik eman bere tipoaren izenak SOCKS5 esaten duelako bakarrik.

Era berean, proxy izena duen tresna baten osagai bat garapenerako pakete-galeraren simulatzailea izan daiteke, eta ez goi-korronteko proxy bezero orokor bat. Aztertu bere benetako interfazea eta onartzen duen garraioa.

CONNECT-UDP bezalako estandarrenek UDP HTTP proxy sistema baten bidez eramateko beste modu bat definitzen dute. Bi muturretan euskarria behar dute eta ez dira CONNECT tradizionalarekin nahastu behar.

HTTP bezeroak TCP gaineko HTTP/2 edo HTTP/1.1-era atzera egiten badu, eskaerak arrakasta izan dezake ohiko proxyaren bidez, HTTP/3 konexiorik erabili gabe. Erregistratu negoziatutako protokoloa bereizketa hori garrantzitsua denean.

Beraz, bateragarritasun galdera erabilgarria zehatza da: bezero honek bere QUIC datagramak proxy honetatik eraman ditzake mekanismo onartu honekin? Funtzionatzen duen nabigatzaile orri batek edo TCP portu egiaztapen batek galdera txikiagoari erantzuten dio.