HTTP/3

HTTP/3 वेब के प्रोटोकॉल का नवीनतम संस्करण है, और इसका परिभाषित परिवर्तन इसके नीचे का परिवहन है: यह QUIC और UDP पर चलता है न कि TCP पर। यह उस हेड-ऑफ-लाइन ब्लॉकिंग को हटा देता है जो HTTP/2 को प्रभावित करता था, जहां एक खोया हुआ पैकेट कनेक्शन पर हर स्ट्रीम को रोक देता था; QUIC के साथ, स्ट्रीम स्वतंत्र हैं। यह QUIC के तेज, एन्क्रिप्टेड हैंडशेक और नेटवर्क परिवर्तन को सहन करने की क्षमता को भी विरासत में लेता है, जो मिलकर HTTP/3 को शुरू करने में तेज और अधिक लचीला बनाता है, विशेष रूप से मोबाइल पर।

UDP में परिवर्तन का प्रॉक्सींग पर व्यावहारिक परिणाम है: क्योंकि क्लासिक HTTP प्रॉक्सी और CONNECT विधि केवल TCP ले जाती है, HTTP/3 उनके माध्यम से नहीं गुजर सकता। इसे UDP को रिले करने वाले पथ की आवश्यकता है - एक SOCKS5 प्रॉक्सी जो UDP का समर्थन करता है, या एक डिवाइस-व्यापी VPN जो सब कुछ टनल करता है। यदि एक क्लाइंट TCP-केवल प्रॉक्सी के माध्यम से HTTP/3 का प्रयास करता है, तो यह आमतौर पर TCP पर HTTP/2 पर वापस चला जाएगा। जब आपको विशेष रूप से HTTP/3 की आवश्यकता हो, तो इसे s4m VPN या UDP-सक्षम SOCKS5 एंडपॉइंट के माध्यम से रूट करें न कि HTTP प्रॉक्सी के माध्यम से।

क्योंकि HTTP/3 को एक UDP पथ की आवश्यकता होती है, यह एक क्लासिक HTTP प्रॉक्सी के TCP-केवल CONNECT टनल को पार नहीं कर सकता; एक क्लाइंट आमतौर पर TCP पर HTTP/2 पर वापस लौट जाएगा। जब आपको विशेष रूप से HTTP/3 की आवश्यकता होती है, तो इसे एक UDP-सक्षम SOCKS5 प्रॉक्सी या डिवाइस-व्यापी s4m VPN के माध्यम से रूट करें। अधिकांश कार्यों के लिए बैकफॉल ठीक और अदृश्य है, इसलिए केवल तब UDP-सक्षम पथ का उपयोग करें जब कोई उपकरण वास्तव में QUIC की आवश्यकता हो न कि TCP बैकफॉल को स्वीकार करें।