HTTP/3 მოთხოვნას UDP-ის მქონე პროქსის გზა სჭირდება
განასხვავეთ HTTP/3-ის QUIC ტრანსპორტი ჩვეულებრივი HTTP CONNECT TCP გვირაბებისა და SOCKS5 სერვისის არასავალდებულო UDP მხარდაჭერისგან.
კლიენტი, რომელიც TCP პროქსით წარმატებით აღწევს HTTPS-ს, ჯერ არ შეუქმნია გზა HTTP/3-ისთვის. HTTP/3 იყენებს QUIC-ს, ხოლო QUIC — UDP-ს.
ჩვეულებრივი HTTP CONNECT გვირაბი TCP ნაკადს აწვდის თავის დანიშნულებას. ის არ იქცევა UDP გადამცემად, როცა URL იწყება HTTPS-ით ან დანიშნულება 443 პორტზე უსმენს.
SOCKS5-საც სჭირდება UDP გზა
SOCKS5 განსაზღვრავს UDP ასოციაციას, მაგრამ როგორც კლიენტმა, ისე სერვერმა უნდა დანერგოს ის, და გადაცემის საბოლოო წერტილი უნდა იყოს მისაწვდომი. ბიბლიოთეკა, რომელიც მხოლოდ SOCKS TCP dialer-ს გვთავაზობს, ვერ უზრუნველყოფს დატაგრამულ ტრანსპორტს მხოლოდ იმიტომ, რომ მისი ტიპის სახელი SOCKS5-ია.
ანალოგიურად, ხელსაწყოს proxy-სახელწოდების კომპონენტი შეიძლება იყოს განვითარების პაკეტების დაკარგვის სიმულატორი და არა ზოგადი ზედა პროქსის კლიენტი. შეამოწმეთ მისი რეალური ინტერფეისი და მხარდაჭერილი ტრანსპორტი.
სტანდარტები, როგორიცაა CONNECT-UDP, განსაზღვრავს UDP-ის HTTP პროქსის სისტემით გადატანის სხვა ხერხს. ისინი მოითხოვენ მხარდაჭერას ორივე მხარეს და არ უნდა აგვერიოს ტრადიციულ CONNECT-ში.
თუ HTTP კლიენტი TCP-ზე უკან იხევს HTTP/2-ზე ან HTTP/1.1-ზე, მოთხოვნა შეიძლება წარმატებით შესრულდეს ჩვეულებრივი პროქსით, მაშინ როცა HTTP/3 კავშირი არ გამოყენებულა. ჩაწერეთ შეთანხმებული პროტოკოლი, როცა ეს განსხვავება მნიშვნელოვანია.
ამიტომ სასარგებლო თავსებადობის კითხვა კონკრეტულია: შეუძლია ამ კლიენტს თავისი QUIC დატაგრამების ამ მხარდაჭერილი მექანიზმით ამ პროქსის გავლით გადატანა? მომუშავე ბრაუზერის გვერდი ან TCP პორტის შემოწმება უფრო მცირე კითხვას პასუხობს.