Ένα αίτημα HTTP/3 χρειάζεται διαδρομή proxy με υποστήριξη UDP

Ένας πελάτης που φτάνει με επιτυχία σε HTTPS μέσω proxy TCP δεν έχει δημιουργήσει διαδρομή για HTTP/3. Το HTTP/3 χρησιμοποιεί QUIC, και το QUIC χρησιμοποιεί UDP.

Ένα συνηθισμένο τούνελ HTTP CONNECT παρέχει ροή TCP προς τον προορισμό του. Δεν μετατρέπεται σε αναμεταδότη UDP όταν η διεύθυνση URL αρχίζει με HTTPS ή όταν ο προορισμός ακούει στη θύρα 443.

Και το SOCKS5 χρειάζεται τη διαδρομή UDP

Το SOCKS5 ορίζει τη συσχέτιση UDP, αλλά πρέπει να την υλοποιήσουν και ο πελάτης και ο διακομιστής, και το τελικό σημείο αναμετάδοσης πρέπει να είναι προσβάσιμο. Μια βιβλιοθήκη που εκθέτει μόνο dialer TCP του SOCKS δεν μπορεί να παρέχει μεταφορά datagram μόνο επειδή το όνομα του τύπου της λέει SOCKS5.

Παρομοίως, ένα στοιχείο ενός εργαλείου με όνομα proxy μπορεί να είναι προσομοιωτής απώλειας πακέτων για ανάπτυξη και όχι γενικός πελάτης proxy ανάντη. Εξετάστε την πραγματική διεπαφή του και τη μεταφορά που υποστηρίζει.

Πρότυπα όπως το CONNECT-UDP ορίζουν έναν άλλο τρόπο μεταφοράς UDP μέσα από σύστημα proxy HTTP. Απαιτούν υποστήριξη και στα δύο άκρα και δεν πρέπει να συγχέονται με το παραδοσιακό CONNECT.

Αν ο πελάτης HTTP υποχωρήσει σε HTTP/2 ή HTTP/1.1 πάνω από TCP, ένα αίτημα μπορεί να πετύχει μέσω του συνηθισμένου proxy χωρίς να έχει χρησιμοποιηθεί σύνδεση HTTP/3. Καταγράψτε το πρωτόκολλο που διαπραγματεύτηκε όταν αυτή η διάκριση έχει σημασία.

Επομένως το χρήσιμο ερώτημα συμβατότητας είναι συγκεκριμένο: μπορεί αυτός ο πελάτης να μεταφέρει τα datagram QUIC του μέσω αυτού του proxy με αυτόν τον υποστηριζόμενο μηχανισμό; Μια σελίδα προγράμματος περιήγησης που λειτουργεί ή ένας έλεγχος θύρας TCP απαντά σε μικρότερο ερώτημα.