यूडीपी पर HTTP - QUIC प्रोटोकॉल का अच्छा उपयोग करना

QUIC (क्विक यूडीपी इंटरनेट कनेक्शंस) यूडीपी के शीर्ष पर एक प्रोटोकॉल है जो टीसीपी, टीएलएस और HTTP/2 की सभी सुविधाओं का समर्थन करता है और उनकी अधिकांश समस्याओं का समाधान करता है। इसे अक्सर एक नया या "प्रयोगात्मक" प्रोटोकॉल कहा जाता है, लेकिन यह लंबे समय तक प्रयोगात्मक चरण से आगे निकल चुका है: विकास 7 वर्षों से अधिक समय से चल रहा है। इस समय के दौरान, प्रोटोकॉल एक मानक बनने में कामयाब नहीं हुआ, लेकिन फिर भी व्यापक हो गया। उदाहरण के लिए, QUIC का उपयोग ट्रैफ़िक को तेज़ करने और मोबाइल नेटवर्क में देरी को कम करने के लिए Google और Facebook जैसे दिग्गजों द्वारा किया जाता है, और IETF ने प्रोटोकॉल के अपने फोर्क को HTTP/3 मानक के लिए आधार घोषित किया है (भले ही HTTP/2 का उपयोग किया जाता है) केवल 44.8% साइटें)।

संकल्पना

QUIC को पुराने टीसीपी के प्रतिस्थापन के रूप में विकसित किया गया था, जिसे मूल रूप से कम-नुकसान वाले वायर्ड नेटवर्क के लिए डिज़ाइन किया गया था। टीसीपी क्रम में पैकेट वितरित करता है, इसलिए यदि एक पैकेट खो जाता है, तो पूरी कतार बंद हो जाती है (हेड-ऑफ़-लाइन अवरोधन), जो कनेक्शन की गुणवत्ता और स्थिरता को नकारात्मक रूप से प्रभावित करता है। बड़े पैमाने पर नुकसान से बचने के लिए, सेलुलर नेटवर्क बड़े बफ़र्स का उपयोग करते हैं, जिसके परिणामस्वरूप प्रोटोकॉल की अतिरेक और झूठी नकारात्मक प्रतिक्रिया होती है (बफरब्लोट). इसके अलावा, टीसीपी कनेक्शन स्थापित करने में बहुत समय खर्च करता है: SYN/ACK और TLS अनुरोधों को अलग-अलग संसाधित किया जाता है, जिसके लिए एक के बजाय तीन राउंडट्रिप की आवश्यकता होती है, जैसा कि QUIC करता है।

चूंकि QUIC एक टीसीपी प्रतिस्थापन और टीएलएस 1.3 के कार्यान्वयन को जोड़ता है, सभी कनेक्शन हमेशा एन्क्रिप्टेड होते हैं, और ऐसे ट्रैफ़िक को डिक्रिप्ट करना HTTPS पर जाने से आसान नहीं है। इसके अलावा, QUIC को एप्लिकेशन स्तर पर लागू किया गया है, क्योंकि टीसीपी स्टैक का पूर्ण प्रतिस्थापन होगा अनंत काल.

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

उपयोग

प्रारंभ में, QUIC को Google के भीतर विकसित किया गया था और इसे बड़े पैमाने पर कंपनी के भीतर उपयोग के लिए तैयार किया गया था। 2013 में, इसे मानकीकरण के लिए IETF में स्थानांतरित कर दिया गया था (जो अभी भी जारी है), और अब हर कोई यह प्रस्तावित करके प्रोटोकॉल के विकास में भाग ले सकता है कि उनमें क्या कमी है। IETF कार्य समूह वार्षिक बैठकें आयोजित करता है जिसके दौरान एक नए मानक को मंजूरी दी जाती है और नवाचारों पर चर्चा की जाती है। QUIC का यह कार्यान्वयन मुख्य माना जाता है और इसके आधार पर ही HTTP/3 मानक प्रमाणित होता है।

अभी तक, HTTP/3 को मुख्य प्रोटोकॉल के रूप में शामिल करने के बारे में कोई बात नहीं हुई है, क्योंकि यह अभी तक समाप्त नहीं हुआ है और लगभग समर्थित नहीं है:

लेकिन QUIC को एप्लिकेशन और सर्वर के बीच परिवहन के रूप में कार्यान्वित किया जा सकता है, जो उबर में सफलतापूर्वक किया गया था:

QUIC की शुरूआत पर उबर की टिप्पणी

QUIC को सफलतापूर्वक एम्बेड करने और खराब कनेक्टिविटी वातावरण में एप्लिकेशन प्रदर्शन को बेहतर बनाने के लिए, हमने पुराने स्टैक (HTTP/2 ओवर TLS/TCP) को QUIC प्रोटोकॉल से बदल दिया। हमने नेटवर्क लाइब्रेरी का उपयोग किया क्रोनेट से क्रोमियम परियोजनाएँ, जिसमें प्रोटोकॉल का मूल, Google संस्करण शामिल है - gQUIC। नवीनतम IETF विनिर्देश का पालन करने के लिए इस कार्यान्वयन में भी लगातार सुधार किया जा रहा है।

हमने QUIC के लिए समर्थन जोड़ने के लिए सबसे पहले क्रोनेट को अपने एंड्रॉइड ऐप्स में एकीकृत किया। एकीकरण इस तरह से किया गया कि प्रवासन लागत को यथासंभव कम किया जा सके। लाइब्रेरी का उपयोग करने वाले पुराने नेटवर्किंग स्टैक को पूरी तरह से बदलने के बजाय OkHttp, हमने OkHttp एपीआई ढांचे के तहत क्रोनेट को एकीकृत किया है। इस तरह से एकीकरण करके, हमने अपने नेटवर्क कॉल (जिनका उपयोग किया जाता है) में बदलाव से बचा लिया पुराना वापस) एपीआई स्तर पर।

एंड्रॉइड डिवाइसों के लिए दृष्टिकोण के समान, हमने नेटवर्क से HTTP ट्रैफ़िक को रोकते हुए, iOS पर Uber ऐप्स में क्रोनेट लागू किया APIका उपयोग करते हुए NSURLप्रोटोकॉल. आईओएस फाउंडेशन द्वारा प्रदान किया गया यह अमूर्त प्रोटोकॉल-विशिष्ट यूआरएल डेटा को संभालता है और यह सुनिश्चित करता है कि हम महत्वपूर्ण माइग्रेशन लागत के बिना क्रोनेट को अपने आईओएस अनुप्रयोगों में एकीकृत कर सकते हैं।

से लिया यह अनुवाद उबेर लेख

बैकएंड पर उन्होंने Google क्लाउड lb के माध्यम से QUIC कनेक्शन पकड़े, जो प्रोटोकॉल का समर्थन करता है 2018 के मध्य से।

इसमें कोई आश्चर्य की बात नहीं है कि Google क्लाउड Google-विकसित प्रोटोकॉल के साथ बढ़िया काम करता है, लेकिन विकल्प क्या हैं?

nginx

अभी कुछ समय पहले CloudFlare मैंने पार करने की कोशिश की nginx (जो डिफ़ॉल्ट रूप से HTTP/3 का समर्थन नहीं करता है) अपने क्विच टूल के साथ। कार्यान्वयन एकल .पैच फ़ाइल के रूप में उपलब्ध है, जो एक इंस्टॉलेशन ट्यूटोरियल के साथ आता है:

curl -O https://nginx.org/download/nginx-1.16.1.tar.gz
tar xvzf nginx-1.16.1.tar.gz
git clone --recursive https://github.com/cloudflare/quiche
cd nginx-1.16.1
patch -p01 < ../quiche/extras/nginx/nginx-1.16.patch

यदि आवश्यक हो तो आप यहां अपने मॉड्यूल कनेक्ट कर सकते हैं

./configure                          	
   	--prefix=$PWD                       	
   	--with-http_ssl_module              	
   	--with-http_v2_module               	
   	--with-http_v3_module               	
   	--with-openssl=../quiche/deps/boringssl 
   	--with-quiche=../quiche
 make

जो कुछ बचा है वह HTTP/3 समर्थन सक्षम करना है

events {
    worker_connections  1024;
}

http {
    server {
        # Enable QUIC and HTTP/3.
        listen 443 quic reuseport;

        # Enable HTTP/2 (optional).
        listen 443 ssl http2;

        ssl_certificate      cert.crt;
        ssl_certificate_key  cert.key;

        # Enable all TLS versions (TLSv1.3 is required for QUIC).
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;

        # Request buffering in not currently supported for HTTP/3.
        proxy_request_buffering off;

        # Add Alt-Svc header to negotiate HTTP/3.
        add_header alt-svc 'h3-27=":443"; ma=86400';
    }
}

नियमित ब्राउज़रों में HTTP/3 के माध्यम से कनेक्ट करना अभी तक संभव नहीं है, लेकिन आप इसका उपयोग कर सकते हैं क्रोम कैनरी और इसे झंडे के साथ चलायें --enable-quic, अपने सर्वर पर जाएं या, उदाहरण के लिए, quic.rocks साइट पर जाएं और डेवलपर टूल्स में कनेक्शन प्रकार देखें:

HTTP/3 की जगह लिखा है http2+quic/99, लेकिन यह मूलतः एक ही चीज़ है।

अन्य प्रौद्योगिकियाँ

• QUIC भी सपोर्ट करता है LiteSpeed (जो बड़ी धूमधाम से HTTP/3 के माध्यम से फेसबुक से जुड़ा) और प्रगतिशील चायदान. अपाचे अभी तक ऐसा नहीं कर सकता, लेकिन काम चल रहा है पूरे जोरों पर.
• 21 जनवरी अपडेट किया गया WebRTC के लिए मसौदा मानक
• अभी कुछ दिन पहले ही माइक्रोसॉफ्ट खुला msquic कार्यान्वयन कोड, जिसमें IETF मानक के सभी फ़ंक्शन अभी तक उपलब्ध नहीं हैं, लेकिन यह पहले से ही एक बड़ी सफलता है।

निष्कर्ष

QUIC में रुचि अस्थिर है, लेकिन बढ़ रही है, और इसे मानकीकृत करने के लिए काम चल रहा है। प्रोटोकॉल के नए कार्यान्वयन लगभग हर महीने सामने आते हैं, और हर साल अधिक से अधिक डेवलपर्स आश्वस्त होते हैं कि QUIC ही भविष्य है। टीसीपी स्टैक के भविष्य के संस्करणों में प्रोटोकॉल को शामिल करना भी संभव है, जिसका अर्थ है कि देर-सबेर पूरा इंटरनेट अधिक स्थिर और तेज़ कनेक्शन में चला जाएगा।

पहले से ही अब आप अपने बुनियादी ढांचे के लिए QUIC इंटरेक्शन को कॉन्फ़िगर कर सकते हैं या इसे ब्राउज़रों को भी दे सकते हैं - वे सभी प्रोटोकॉल के लिए समर्थन जोड़ने की योजना बना रहे हैं, और कैनियस के साथ दुखद आंकड़े अधिक हर्षित हो जाएंगे।

स्रोत: www.habr.com