HTTP माथि UDP - QUIC प्रोटोकलको राम्रो प्रयोग गर्दै

QUIC (Quick UDP इन्टरनेट जडानहरू) UDP को शीर्षमा रहेको एउटा प्रोटोकल हो जसले TCP, TLS र HTTP/2 का सबै सुविधाहरूलाई समर्थन गर्दछ र तिनीहरूका अधिकांश समस्याहरू समाधान गर्दछ। यसलाई प्रायः नयाँ वा "प्रयोगात्मक" प्रोटोकल भनिन्छ, तर यसले लामो समयदेखि प्रयोगात्मक चरणमा बाँचेको छ: विकास 7 वर्ष भन्दा बढीको लागि जारी छ। यस समयमा, प्रोटोकल मानक बन्न सकेन, तर अझै व्यापक भयो। उदाहरण को लागी, ट्राफिक को गति र मोबाइल नेटवर्क मा ढिलाइ कम गर्न को लागी गुगल र फेसबुक जस्ता दिग्गजहरु द्वारा QUIC को प्रयोग गरिन्छ, र IETF ले आफ्नो प्रोटोकल को फोर्क को HTTP/3 मानक को आधार घोषणा गर्यो (यद्यपि HTTP/2 प्रयोग गर्दछ। ७०% मात्र साइटहरू)।

अवधारणा

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

QUIC ले TCP प्रतिस्थापन र TLS 1.3 को कार्यान्वयनलाई संयोजन गरेको हुनाले, सबै जडानहरू सधैं इन्क्रिप्टेड हुन्छन्, र त्यस्ता ट्राफिकहरूलाई डिक्रिप्ट गर्न HTTPS मा जानु भन्दा सजिलो छैन। थप रूपमा, TCP स्ट्याकको पूर्ण प्रतिस्थापनको रूपमा QUIC अनुप्रयोग स्तरमा लागू हुन्छ सधैंभरि.

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

प्रयोग गर्नुहोस्

प्रारम्भमा, QUIC गुगल भित्र विकसित गरिएको थियो र धेरै हदसम्म कम्पनी भित्र प्रयोगको लागि अनुकूल थियो। 2013 मा, यसलाई मानकीकरणको लागि IETF मा हस्तान्तरण गरिएको थियो (जुन अझै चलिरहेको छ), र अब सबैले के छुटेको प्रस्ताव गरेर प्रोटोकलको विकासमा भाग लिन सक्छन्। IETF कार्य समूहले वार्षिक बैठकहरू आयोजना गर्दछ जसमा नयाँ मानक अनुमोदन गरिन्छ र नवाचारहरू छलफल गरिन्छ। QUIC को यो कार्यान्वयन मुख्य मानिन्छ र यो यसको आधारमा HTTP/3 मानक प्रमाणित छ।

अहिलेसम्म, मुख्य प्रोटोकलको रूपमा HTTP/3 समावेश गर्ने बारे कुनै कुरा छैन, किनभने यो अझै समाप्त भएको छैन र लगभग समर्थित छैन:

तर QUIC लाई अनुप्रयोग र सर्भर बीचको यातायातको रूपमा लागू गर्न सकिन्छ, जुन Uber मा सफलतापूर्वक गरिएको थियो:

QUIC को परिचयमा Uber को टिप्पणी

QUIC लाई सफलतापूर्वक इम्बेड गर्न र खराब जडान वातावरणमा अनुप्रयोग प्रदर्शन सुधार गर्न, हामीले पुरानो स्ट्याक (HTTP/2 over TLS/TCP) लाई QUIC प्रोटोकलसँग बदल्यौं। हामीले नेटवर्क लाइब्रेरी प्रयोग गर्यौं क्रोनेट बाट क्रोमियम परियोजनाहरू, जसमा प्रोटोकलको मूल, गुगल संस्करण - gQUIC समावेश छ। नवीनतम IETF विनिर्देशहरू पालना गर्न यो कार्यान्वयन पनि निरन्तर सुधार भइरहेको छ।

हामीले QUIC को लागि समर्थन थप्नको लागि पहिले हाम्रो Android एपहरूमा Cronet एकीकृत गर्यौं। एकीकरण सम्भव भएसम्म बसाइँसर लागत घटाउने तरिकामा गरिएको थियो। पुरानो नेटवर्किङ स्ट्याक पूर्ण रूपमा प्रतिस्थापन गर्नुको सट्टा जुन पुस्तकालय प्रयोग गर्यो OkHttp, हामीले OkHttp API फ्रेमवर्क अन्तर्गत Cronet लाई एकीकृत गरेका छौं। यसरी एकीकरण गरेर, हामीले हाम्रो नेटवर्क कलहरूमा परिवर्तनहरू बेवास्ता गर्यौं (जुन द्वारा प्रयोग गरिन्छ रेट्रोफिट) API स्तरमा।

एन्ड्रोइड उपकरणहरूको लागि दृष्टिकोण जस्तै, हामीले आईओएसमा उबर एपहरूमा क्रोनेट लागू गर्यौं, नेटवर्कबाट HTTP ट्राफिकलाई रोक्दै। एपीआईप्रयोग गर्दै NSURL प्रोटोकल। iOS फाउन्डेसनद्वारा प्रदान गरिएको यो अमूर्तताले प्रोटोकल-विशिष्ट URL डेटा ह्यान्डल गर्छ र हामीले महत्त्वपूर्ण माइग्रेसन लागतहरू बिना नै हाम्रा iOS अनुप्रयोगहरूमा Cronet एकीकृत गर्न सक्छौं भन्ने सुनिश्चित गर्छ।

बाट लिइएको यो अनुवाद Uber लेखहरू

ब्याकएन्डमा उनीहरूले गुगल क्लाउड एलबी मार्फत QUIC जडानहरू समाते, जुन प्रोटोकल समर्थन गर्दछ मध्य 2018 देखि।

यो कुनै आश्चर्यको कुरा होइन कि गुगल क्लाउडले गुगल-विकसित प्रोटोकलसँग राम्रो काम गर्दछ, तर विकल्पहरू के हुन्?

निजिनक्स

धेरै समय अघि 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 स्ट्याकको भविष्यका संस्करणहरूमा समावेश गर्न पनि सम्भव छ, जसको मतलब छिट्टै वा पछि सम्पूर्ण इन्टरनेट थप स्थिर र छिटो जडानहरूमा सारिनेछ।

पहिले नै अब तपाइँ तपाइँको पूर्वाधारको लागि QUIC अन्तरक्रिया कन्फिगर गर्न सक्नुहुन्छ वा ब्राउजरहरूलाई पनि दिन सक्नुहुन्छ - तिनीहरू सबै प्रोटोकलको लागि समर्थन थप्ने योजनामा ​​छन्, र क्यानियुजको साथ दुखद तथ्याङ्कहरू थप प्रफुल्लित हुनेछन्।

स्रोत: www.habr.com