UDP ద్వారా HTTP - QUIC ప్రోటోకాల్‌ను బాగా ఉపయోగించడం

QUIC (త్వరిత UDP ఇంటర్నెట్ కనెక్షన్లు) అనేది UDP పైన ఉన్న ప్రోటోకాల్, ఇది TCP, TLS మరియు HTTP/2 యొక్క అన్ని లక్షణాలకు మద్దతు ఇస్తుంది మరియు వాటి సమస్యలను చాలా వరకు పరిష్కరిస్తుంది. ఇది తరచుగా కొత్త లేదా "ప్రయోగాత్మక" ప్రోటోకాల్ అని పిలువబడుతుంది, కానీ ఇది చాలా కాలం పాటు ప్రయోగాత్మక దశను మించిపోయింది: అభివృద్ధి 7 సంవత్సరాలకు పైగా కొనసాగుతోంది. ఈ సమయంలో, ప్రోటోకాల్ ప్రమాణంగా మారలేదు, కానీ ఇప్పటికీ విస్తృతంగా మారింది. ఉదాహరణకు, ట్రాఫిక్‌ను వేగవంతం చేయడానికి మరియు మొబైల్ నెట్‌వర్క్‌లలో ఆలస్యాన్ని తగ్గించడానికి Google మరియు Facebook వంటి దిగ్గజాలు QUICని ఉపయోగిస్తాయి మరియు IETF తన ప్రోటోకాల్ యొక్క ఫోర్క్‌ను HTTP/3 ప్రమాణానికి (HTTP/2 ఉపయోగిస్తున్నప్పటికీ) ఆధారంగా ప్రకటించింది. 44.8% మాత్రమే సైట్లు).

భావన

QUIC లెగసీ TCPకి ప్రత్యామ్నాయంగా అభివృద్ధి చేయబడింది, ఇది వాస్తవానికి తక్కువ-నష్టం కలిగిన వైర్డు నెట్‌వర్క్‌ల కోసం రూపొందించబడింది. TCP ప్యాకెట్లను క్రమంలో పంపిణీ చేస్తుంది, కాబట్టి ఒక ప్యాకెట్ పోయినట్లయితే, మొత్తం క్యూ నిలిపివేయబడుతుంది (హెడ్-ఆఫ్-లైన్ నిరోధించడం), ఇది కనెక్షన్ యొక్క నాణ్యత మరియు స్థిరత్వాన్ని ప్రతికూలంగా ప్రభావితం చేస్తుంది. భారీ నష్టాలను నివారించడానికి, సెల్యులార్ నెట్‌వర్క్‌లు పెద్ద బఫర్‌లను ఉపయోగించడాన్ని ఆశ్రయిస్తాయి, ఇది ప్రోటోకాల్ యొక్క రిడెండెన్సీ మరియు తప్పుడు ప్రతికూల ప్రతిస్పందనకు దారితీస్తుంది (బఫర్‌బ్లోట్) అదనంగా, TCP ఒక కనెక్షన్‌ని స్థాపించడానికి చాలా సమయాన్ని వెచ్చిస్తుంది: SYN/ACK మరియు TLS అభ్యర్థనలు విడివిడిగా ప్రాసెస్ చేయబడతాయి, QUIC చేసినట్లుగా ఒకదానికి బదులుగా మూడు రౌండ్‌ట్రిప్‌లు అవసరం.

QUIC TCP రీప్లేస్‌మెంట్ మరియు TLS 1.3 అమలును మిళితం చేస్తుంది కాబట్టి, అన్ని కనెక్షన్‌లు ఎల్లప్పుడూ గుప్తీకరించబడతాయి మరియు అటువంటి ట్రాఫిక్‌ని డీక్రిప్ట్ చేయడం HTTPS ద్వారా వెళ్లడం కంటే సులభం కాదు. అదనంగా, QUIC అప్లికేషన్ స్థాయిలో అమలు చేయబడుతుంది, ఎందుకంటే TCP స్టాక్ యొక్క పూర్తి రీప్లేస్‌మెంట్ పడుతుంది శాశ్వతత్వం.

HTTP/2లో మల్టీప్లెక్సింగ్‌కు మద్దతు ఉన్నప్పటికీ, ప్యాకెట్‌లను క్రమంలో డెలివరీ చేయాల్సిన అవసరం ఉన్నందున హెడ్-ఆఫ్-లైన్ బ్లాకింగ్ సమస్య అలాగే ఉంది. QUIC UDP పైన అమలు చేయబడుతుంది, కాబట్టి దీనికి సూత్రప్రాయంగా ఎటువంటి నిరోధం లేదు మరియు ప్యాకెట్‌లు శాశ్వతంగా కోల్పోకుండా నిరోధించడానికి, అవి సంఖ్యతో ఉంటాయి మరియు రిడెండెన్సీని అందించే “పొరుగువారి” భాగాలను కలిగి ఉంటాయి. అదనంగా, QUIC ఒకే కనెక్షన్‌లోని వివిధ రకాల అభ్యర్థనల కోసం ఏకశిలా క్యూను బహుళ థ్రెడ్‌లుగా విభజిస్తుంది. అందువలన, ఒక ప్యాకెట్ పోయినట్లయితే, ఒక క్యూలో మాత్రమే సమస్యలు తలెత్తవచ్చు (ఉదాహరణకు, నిర్దిష్ట ఫైల్‌ను బదిలీ చేయడం కోసం):

ఉపయోగం

ప్రారంభంలో, QUIC Googleలో అభివృద్ధి చేయబడింది మరియు కంపెనీలో ఉపయోగం కోసం ఎక్కువగా రూపొందించబడింది. 2013లో, ఇది ప్రామాణీకరణ కోసం IETFకి బదిలీ చేయబడింది (ఇది ఇప్పటికీ కొనసాగుతోంది), మరియు ఇప్పుడు ప్రతి ఒక్కరూ తాము తప్పిపోయిన వాటిని ప్రతిపాదించడం ద్వారా ప్రోటోకాల్ అభివృద్ధిలో పాల్గొనవచ్చు. IETF వర్కింగ్ గ్రూప్ వార్షిక సమావేశాలను నిర్వహిస్తుంది, ఈ సమయంలో కొత్త ప్రమాణం ఆమోదించబడింది మరియు ఆవిష్కరణలు చర్చించబడతాయి. QUIC యొక్క ఈ అమలు ప్రధానమైనదిగా పరిగణించబడుతుంది మరియు దాని ఆధారంగా HTTP/3 ప్రమాణం ధృవీకరించబడింది.

ఇప్పటివరకు, HTTP/3ని ప్రధాన ప్రోటోకాల్‌గా చేర్చడం గురించి ఎటువంటి చర్చ లేదు, ఎందుకంటే ఇది ఇంకా పూర్తి కాలేదు మరియు దాదాపు మద్దతు లేదు:

కానీ QUIC అప్లికేషన్ మరియు సర్వర్ మధ్య రవాణాగా అమలు చేయబడుతుంది, ఇది Uberలో విజయవంతంగా జరిగింది:

QUIC పరిచయంపై Uber యొక్క వ్యాఖ్య

QUICని విజయవంతంగా పొందుపరచడానికి మరియు పేలవమైన కనెక్టివిటీ పరిసరాలలో అప్లికేషన్ పనితీరును మెరుగుపరచడానికి, మేము QUIC ప్రోటోకాల్‌తో పాత స్టాక్‌ను (TLS/TCP ద్వారా HTTP/2) భర్తీ చేసాము. మేము నెట్‌వర్క్ లైబ్రరీని ఉపయోగించాము క్రోనెట్ నుండి Chromium ప్రాజెక్ట్‌లు, ఇది ప్రోటోకాల్ యొక్క అసలు, Google సంస్కరణను కలిగి ఉంది - gQUIC. తాజా IETF స్పెసిఫికేషన్‌ను అనుసరించడానికి ఈ అమలు కూడా నిరంతరం మెరుగుపరచబడుతోంది.

QUICకి మద్దతును జోడించడానికి మేము మొదట క్రోనెట్‌ని మా Android యాప్‌లలోకి చేర్చాము. వలస ఖర్చులను వీలైనంత వరకు తగ్గించే విధంగా ఏకీకరణ జరిగింది. లైబ్రరీని ఉపయోగించిన పాత నెట్‌వర్కింగ్ స్టాక్‌ను పూర్తిగా భర్తీ చేయడానికి బదులుగా OkHttp, మేము OkHttp API ఫ్రేమ్‌వర్క్ క్రింద క్రోనెట్‌ను ఏకీకృతం చేసాము. ఈ విధంగా ఇంటిగ్రేషన్ చేయడం ద్వారా, మేము మా నెట్‌వర్క్ కాల్‌లకు మార్పులను నివారించాము (వీటిని ఉపయోగిస్తున్నారు రెట్రోఫిట్) API స్థాయిలో.

Android పరికరాలకు సంబంధించిన విధానం వలె, మేము iOSలో Uber యాప్‌లలోకి Cronetని అమలు చేసాము, నెట్‌వర్క్ నుండి HTTP ట్రాఫిక్‌ను అడ్డగించాము APIఉపయోగించి NSURLప్రోటోకాల్. iOS ఫౌండేషన్ అందించిన ఈ సంగ్రహణ, ప్రోటోకాల్-నిర్దిష్ట URL డేటాను నిర్వహిస్తుంది మరియు గణనీయమైన మైగ్రేషన్ ఖర్చులు లేకుండానే మేము మా iOS అప్లికేషన్‌లలో Cronetని ఇంటిగ్రేట్ చేయగలమని నిర్ధారిస్తుంది.

నుండి తీసుకోబడింది ఈ అనువాదం ఉబెర్ కథనాలు

బ్యాకెండ్‌లో వారు Google Cloud lb ద్వారా QUIC కనెక్షన్‌లను పొందారు, ఇది ప్రోటోకాల్‌కు మద్దతు ఇస్తుంది 2018 మధ్య నుండి.

Google అభివృద్ధి చేసిన ప్రోటోకాల్‌తో Google క్లౌడ్ అద్భుతంగా పని చేయడంలో ఆశ్చర్యం లేదు, అయితే ప్రత్యామ్నాయాలు ఏమిటి?

వికీపీడియా

చాలా కాలం క్రితం CloudFlare నేను దాటడానికి ప్రయత్నించాను nginx (ఇది డిఫాల్ట్‌గా HTTP/3కి మద్దతు ఇవ్వదు) దాని Quiche సాధనంతో. అమలు సింగిల్ .patch ఫైల్‌గా అందుబాటులో ఉంది, ఇది ఇన్‌స్టాలేషన్ ట్యుటోరియల్‌తో వస్తుంది:

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 ద్వారా కనెక్ట్ చేయడం ఇంకా సాధ్యం కాదు, కానీ మీరు ఉపయోగించవచ్చు Chrome కెనరీ మరియు దానిని జెండాతో అమలు చేయండి --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