UDP वर HTTP - QUIC प्रोटोकॉलचा चांगला वापर करणे

QUIC (क्विक UDP इंटरनेट कनेक्शन) हा UDP च्या वरचा एक प्रोटोकॉल आहे जो TCP, TLS आणि HTTP/2 च्या सर्व वैशिष्ट्यांना समर्थन देतो आणि त्यांच्या बहुतेक समस्यांचे निराकरण करतो. याला बऱ्याचदा नवीन किंवा "प्रायोगिक" प्रोटोकॉल म्हटले जाते, परंतु ते प्रायोगिक अवस्थेपेक्षा जास्त काळ टिकले आहे: विकास 7 वर्षांहून अधिक काळ चालू आहे. या काळात, प्रोटोकॉल एक मानक बनू शकला नाही, परंतु तरीही व्यापक झाला. उदाहरणार्थ, ट्रॅफिकला गती देण्यासाठी आणि मोबाइल नेटवर्कमधील विलंब कमी करण्यासाठी Google आणि Facebook सारख्या दिग्गजांकडून QUIC चा वापर केला जातो आणि IETF ने त्याच्या प्रोटोकॉलचा फाटा HTTP/3 मानकाचा आधार घोषित केला (जरी HTTP/2 वापरते. फक्त ७०% साइट्स).

संकल्पना

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

QUIC मध्ये TCP रिप्लेसमेंट आणि TLS 1.3 ची अंमलबजावणी एकत्रित केल्यामुळे, सर्व कनेक्शन नेहमी कूटबद्ध केले जातात आणि अशा ट्रॅफिकचे डिक्रिप्ट करणे HTTPS वर जाण्यापेक्षा सोपे नाही. याव्यतिरिक्त, TCP स्टॅकची संपूर्ण बदली करण्यासाठी अर्ज स्तरावर QUIC लागू केले जाते अनंतकाळ.

HTTP/2 मध्ये मल्टिप्लेक्सिंगसाठी समर्थन असूनही, पॅकेट्स क्रमाने वितरीत करण्याची आवश्यकता असल्यामुळे हेड-ऑफ-लाइन ब्लॉकिंगची समस्या तिथेच राहिली. QUIC ची अंमलबजावणी UDP च्या वर केली जाते, त्यामुळे त्यात तत्त्वतः कोणतेही ब्लॉकिंग नसते आणि पॅकेट्स कायमचे हरवण्यापासून रोखण्यासाठी, त्यांना क्रमांकित केले जाते आणि त्यात “शेजारी” चे भाग असू शकतात, जे रिडंडंसी प्रदान करतात. याव्यतिरिक्त, QUIC एकाच कनेक्शनमध्ये विविध प्रकारच्या विनंत्यांसाठी मोनोलिथिक रांगेला एकाधिक थ्रेडमध्ये विभाजित करते. अशा प्रकारे, पॅकेट हरवल्यास, समस्या फक्त एका रांगेसाठी उद्भवू शकतात (उदाहरणार्थ, विशिष्ट फाइल हस्तांतरित करण्यासाठी):

वापरा

सुरुवातीला, QUIC Google मध्ये विकसित केले गेले होते आणि मोठ्या प्रमाणात कंपनीमध्ये वापरण्यासाठी तयार केले गेले होते. 2013 मध्ये, ते IETF ला मानकीकरणासाठी हस्तांतरित केले गेले (जे अद्याप चालू आहे), आणि आता प्रत्येकजण त्यांच्याकडे काय गहाळ आहे ते प्रस्तावित करून प्रोटोकॉलच्या विकासामध्ये सहभागी होऊ शकतो. IETF वर्किंग ग्रुप वार्षिक बैठका आयोजित करतो ज्या दरम्यान नवीन मानक मंजूर केले जाते आणि नवकल्पनांवर चर्चा केली जाते. QUIC ची ही अंमलबजावणी मुख्य मानली जाते आणि त्याच्या आधारावर HTTP/3 मानक प्रमाणित केले जाते.

आतापर्यंत, मुख्य प्रोटोकॉल म्हणून HTTP/3 समाविष्ट करण्याबद्दल कोणतीही चर्चा नाही, कारण ते अद्याप पूर्ण झालेले नाही आणि जवळजवळ समर्थित नाही:

परंतु क्विक हे ऍप्लिकेशन आणि सर्व्हरमधील वाहतूक म्हणून कार्यान्वित केले जाऊ शकते, जे Uber येथे यशस्वीरित्या केले गेले:

QUIC च्या परिचयावर Uber ची टिप्पणी

QUIC यशस्वीरित्या एम्बेड करण्यासाठी आणि खराब कनेक्टिव्हिटी वातावरणात अनुप्रयोग कार्यप्रदर्शन सुधारण्यासाठी, आम्ही जुना स्टॅक (HTTP/2 ओव्हर TLS/TCP) QUIC प्रोटोकॉलने बदलला. आम्ही नेटवर्क लायब्ररी वापरली क्रोनेट पासून Chromium प्रकल्प, ज्यामध्ये प्रोटोकॉलची मूळ, Google आवृत्ती आहे - gQUIC. नवीनतम IETF तपशीलांचे पालन करण्यासाठी ही अंमलबजावणी देखील सतत सुधारली जात आहे.

QUIC साठी समर्थन जोडण्यासाठी आम्ही प्रथम आमच्या Android अॅप्समध्ये Cronet समाकलित केले. स्थलांतर खर्च शक्य तितक्या कमी करण्यासाठी एकत्रीकरण केले गेले. लायब्ररी वापरलेल्या जुन्या नेटवर्किंग स्टॅकला पूर्णपणे बदलण्याऐवजी OkHttp, आम्ही OkHttp API फ्रेमवर्क अंतर्गत Cronet समाकलित केले आहे. अशा प्रकारे एकत्रीकरण करून, आम्ही आमच्या नेटवर्क कॉलमधील बदल टाळले (जे वापरतात रिट्रोफिट) API स्तरावर.

अँड्रॉइड उपकरणांसाठीच्या दृष्टिकोनाप्रमाणेच, आम्ही iOS वरील Uber अॅप्समध्ये Cronet लागू केले, नेटवर्कवरून HTTP ट्रॅफिक रोखून APIवापरत आहे NSURLप्रोटोकॉल. iOS फाउंडेशनद्वारे प्रदान केलेले हे अ‍ॅब्स्ट्रॅक्शन, प्रोटोकॉल-विशिष्ट URL डेटा हाताळते आणि हे सुनिश्चित करते की आम्ही महत्त्वपूर्ण स्थलांतर खर्चाशिवाय आमच्या iOS अनुप्रयोगांमध्ये Cronet समाकलित करू शकतो.

पासून घेतले हे भाषांतर उबर लेख

बॅकएंडवर त्यांनी Google Cloud lb द्वारे QUIC कनेक्शन पकडले, जे प्रोटोकॉलचे समर्थन करते 2018 च्या मध्यापासून.

Google क्लाउड Google-विकसित प्रोटोकॉलसह उत्कृष्ट कार्य करते हे आश्चर्यकारक नाही, परंतु पर्याय काय आहेत?

Nginx

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

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 देखील समर्थन लाइटस्पीड (जे मोठ्या धूमधडाक्यात HTTP/3 द्वारे Facebook शी जोडलेले आहे) आणि प्रगतीशील चहा ठेवण्याची लहान पेटी. Apache अद्याप करू शकत नाही, परंतु काम चालू आहे पूर्ण स्विंग.
• जानेवारी 21 अद्यतनित WebRTC साठी मसुदा मानक
• दुसऱ्या दिवशी मायक्रोसॉफ्ट उघडले msquic अंमलबजावणी कोड, ज्यामध्ये IETF मानकातील सर्व कार्ये अद्याप उपलब्ध नाहीत, परंतु हे आधीच एक मोठे यश आहे.

निष्कर्ष

QUIC मधील स्वारस्य अस्थिर आहे, परंतु वाढत आहे आणि त्याचे प्रमाणीकरण करण्यासाठी काम सुरू आहे. प्रोटोकॉलची नवीन अंमलबजावणी जवळजवळ प्रत्येक महिन्यात दिसून येते आणि दरवर्षी अधिकाधिक विकसकांना खात्री आहे की QUIC हे भविष्य आहे. TCP स्टॅकच्या भविष्यातील आवृत्त्यांमध्ये प्रोटोकॉल समाविष्ट करणे देखील शक्य आहे, याचा अर्थ असा की लवकरच किंवा नंतर संपूर्ण इंटरनेट अधिक स्थिर आणि जलद कनेक्शनवर जाईल.

आधीच आता तुम्ही तुमच्या पायाभूत सुविधांसाठी क्विक संवाद कॉन्फिगर करू शकता किंवा ब्राउझरला देखील देऊ शकता - ते सर्व प्रोटोकॉलसाठी समर्थन जोडण्याची योजना आखत आहेत आणि कॅनियुजसह दुःखी आकडेवारी अधिक आनंदी होईल.

स्त्रोत: www.habr.com