QUIC ప్రోటోకాల్ చూడటానికి చాలా ఆసక్తికరంగా ఉంటుంది, అందుకే దాని గురించి రాయడం మాకు చాలా ఇష్టం. అయితే QUIC గురించి మునుపటి ప్రచురణలు చారిత్రక (స్థానిక చరిత్ర, మీకు నచ్చితే) స్వభావం మరియు హార్డ్‌వేర్‌గా ఉంటే, ఈ రోజు మేము వేరొక రకమైన అనువాదాన్ని ప్రచురించడానికి సంతోషిస్తున్నాము - మేము 2019లో ప్రోటోకాల్ యొక్క నిజమైన అప్లికేషన్ గురించి మాట్లాడుతాము. అంతేకాకుండా, మేము గ్యారేజ్ అని పిలవబడే చిన్న మౌలిక సదుపాయాల గురించి మాట్లాడటం లేదు, కానీ దాదాపు ప్రపంచవ్యాప్తంగా పనిచేసే Uber గురించి. ఉత్పత్తిలో QUICని ఉపయోగించాలనే నిర్ణయానికి కంపెనీ ఇంజనీర్లు ఎలా వచ్చారు, వారు పరీక్షలను ఎలా నిర్వహించారు మరియు ఉత్పత్తిలో విడుదల చేసిన తర్వాత వారు ఏమి చూశారు - కట్ క్రింద.
చిత్రాలు క్లిక్ చేయదగినవి. చదివి ఆనందించండి!
Uber గ్లోబల్ స్కేల్‌ను కలిగి ఉంది, అవి 600 నగరాల ఉనికిని కలిగి ఉన్నాయి, వీటిలో ప్రతి ఒక్కటి 4500 కంటే ఎక్కువ సెల్యులార్ ఆపరేటర్ల నుండి పూర్తిగా వైర్లెస్ ఇంటర్నెట్‌పై ఆధారపడి ఉంటుంది. యాప్ వేగంగా మాత్రమే కాకుండా నిజ సమయంలో ఉంటుందని వినియోగదారులు భావిస్తున్నారు - దీన్ని సాధించడానికి, Uber యాప్‌కి తక్కువ జాప్యం మరియు చాలా విశ్వసనీయమైన కనెక్షన్ అవసరం. అయ్యో, కానీ స్టాక్ డైనమిక్ మరియు నష్టానికి గురయ్యే వైర్లెస్ నెట్‌వర్క్‌లలో బాగా పని చేయదు. ఈ సందర్భంలో, తక్కువ పనితీరు నేరుగా ఆపరేటింగ్ సిస్టమ్ కెర్నల్స్‌లోని TCP అమలులకు సంబంధించినదని మేము గ్రహించాము.
సమస్యను పరిష్కరించడానికి, మేము దరఖాస్తు చేసాము , రవాణా ప్రోటోకాల్ పనితీరుపై మాకు మరింత నియంత్రణను అందించే ఆధునిక ఛానెల్ మల్టీప్లెక్సింగ్ ప్రోటోకాల్. ప్రస్తుతం కార్యవర్గం QUICని ప్రామాణికం చేస్తుంది .
విస్తృతమైన పరీక్ష తర్వాత, మా అప్లికేషన్‌లో QUICని అమలు చేయడం వలన TCPతో పోలిస్తే తక్కువ టెయిల్ లేటెన్సీలు వస్తాయని మేము నిర్ధారించాము. డ్రైవర్ మరియు ప్యాసింజర్ అప్లికేషన్‌లలో HTTPS ట్రాఫిక్ కోసం 10-30% పరిధిలో తగ్గింపులను మేము గమనించాము. QUIC వినియోగదారు ప్యాకేజీలపై మాకు ఎండ్-టు-ఎండ్ నియంత్రణను కూడా ఇచ్చింది.
ఈ కథనంలో, మేము QUICకి మద్దతిచ్చే స్టాక్‌ని ఉపయోగించి Uber అప్లికేషన్‌ల కోసం TCPని ఆప్టిమైజ్ చేయడంలో మా అనుభవాన్ని పంచుకుంటాము.
తాజా సాంకేతికత: TCP
నేడు, TCP అనేది ఇంటర్నెట్‌లో HTTPS ట్రాఫిక్‌ని అందించడానికి ఎక్కువగా ఉపయోగించే రవాణా ప్రోటోకాల్. TCP బైట్‌ల యొక్క విశ్వసనీయ ప్రవాహాన్ని అందిస్తుంది, తద్వారా నెట్వర్క్ రద్దీ మరియు లింక్ లేయర్ నష్టాలను ఎదుర్కొంటుంది. HTTPS ట్రాఫిక్ కోసం TCPని విస్తృతంగా ఉపయోగించడం అనేది పూర్వం యొక్క సర్వవ్యాప్తి (దాదాపు ప్రతి OS TCPని కలిగి ఉంటుంది), చాలా మౌలిక సదుపాయాలపై లభ్యత (లోడ్ బ్యాలెన్సర్‌లు, HTTPS ప్రాక్సీలు మరియు CDNలు వంటివి) మరియు అందుబాటులో ఉన్న వెలుపలి కార్యాచరణ కారణంగా ఉంది. దాదాపు చాలా ప్లాట్‌ఫారమ్‌లు మరియు నెట్‌వర్క్‌లలో.
చాలా మంది వినియోగదారులు ప్రయాణంలో మా యాప్‌ని ఉపయోగిస్తున్నారు మరియు TCP టెయిల్ లేటెన్సీలు మా నిజ-సమయ HTTPS ట్రాఫిక్ డిమాండ్‌లకు సమీపంలో లేవు. సరళంగా చెప్పాలంటే, ప్రపంచవ్యాప్తంగా ఉన్న వినియోగదారులు దీనిని అనుభవించారు - మూర్తి 1 ప్రధాన నగరాల్లో ఆలస్యం చూపుతుంది:
మూర్తి 1: Uber యొక్క ప్రధాన నగరాల్లో టెయిల్ లేటెన్సీ మారుతూ ఉంటుంది.
భారతీయ మరియు బ్రెజిలియన్ నెట్‌వర్క్‌లలో జాప్యం US మరియు UK కంటే ఎక్కువగా ఉన్నప్పటికీ, టెయిల్ లేటెన్సీ సగటు జాప్యం కంటే గణనీయంగా ఎక్కువగా ఉంది. మరియు ఇది US మరియు UK లకు కూడా వర్తిస్తుంది.
గాలి పనితీరుపై TCP
TCP దీని కోసం సృష్టించబడింది వైర్డు నెట్‌వర్క్‌లు, అంటే, అత్యంత ఊహాజనిత లింక్‌లకు ప్రాధాన్యతనిస్తుంది. అయితే, వైర్లెస్ నెట్‌వర్క్‌లకు వాటి స్వంత లక్షణాలు మరియు ఇబ్బందులు ఉన్నాయి. మొదట, వైర్లెస్ నెట్‌వర్క్‌లు జోక్యం మరియు సిగ్నల్ అటెన్యుయేషన్ కారణంగా నష్టాలకు గురవుతాయి. ఉదాహరణకు, Wi-Fi నెట్‌వర్క్‌లు మైక్రోవేవ్‌లు, బ్లూటూత్ మరియు ఇతర రేడియో తరంగాలకు సున్నితంగా ఉంటాయి. సెల్యులార్ నెట్‌వర్క్‌లు సిగ్నల్ నష్టంతో బాధపడుతున్నాయి () వస్తువులు మరియు భవనాల ద్వారా సిగ్నల్ యొక్క ప్రతిబింబం / శోషణ కారణంగా, అలాగే నుండి పొరుగు నుండి . ఇది మరింత ముఖ్యమైన (4-10 సార్లు) మరియు మరింత వైవిధ్యానికి దారితీస్తుంది మరియు వైర్డు కనెక్షన్‌తో పోలిస్తే ప్యాకెట్ నష్టం.
బ్యాండ్‌విడ్త్ హెచ్చుతగ్గులు మరియు నష్టాలను ఎదుర్కోవడానికి, సెల్యులార్ నెట్‌వర్క్‌లు సాధారణంగా ట్రాఫిక్ పేలుళ్ల కోసం పెద్ద బఫర్‌లను ఉపయోగిస్తాయి. ఇది అధిక క్యూలకు దారి తీస్తుంది, అంటే ఎక్కువ ఆలస్యం అవుతుంది. చాలా తరచుగా TCP ఈ క్యూయింగ్‌ను పొడిగించిన గడువు కారణంగా వృధాగా పరిగణిస్తుంది, కాబట్టి TCP రిలే మరియు తద్వారా బఫర్‌ను నింపుతుంది. ఈ సమస్య అంటారు (), మరియు ఇది చాలా ఆధునిక ఇంటర్నెట్.
చివరగా, సెల్యులార్ నెట్వర్క్ పనితీరు క్యారియర్, ప్రాంతం మరియు సమయాన్ని బట్టి మారుతుంది. మూర్తి 2లో, మేము 2-కిలోమీటర్ల పరిధిలోని సెల్‌లలో HTTPS ట్రాఫిక్ మధ్యస్థ జాప్యాలను సేకరించాము. భారతదేశంలోని ఢిల్లీలో రెండు ప్రధాన సెల్యులార్ ఆపరేటర్ల కోసం డేటా సేకరించబడింది. మీరు గమనిస్తే, పనితీరు సెల్ నుండి సెల్ వరకు మారుతుంది. అలాగే, ఒక ఆపరేటర్ యొక్క ఉత్పాదకత రెండవ ఉత్పాదకతకు భిన్నంగా ఉంటుంది. నెట్వర్క్ ఎంట్రీ నమూనాలు సమయం మరియు స్థానం, వినియోగదారు చలనశీలత, అలాగే టవర్ సాంద్రత మరియు నెట్వర్క్ రకాల (LTE, 3G, మొదలైనవి) నిష్పత్తిని పరిగణనలోకి తీసుకుని నెట్వర్క్ మౌలిక సదుపాయాలు వంటి అంశాల ద్వారా ఇది ప్రభావితమవుతుంది.
మూర్తి 2. ఉదాహరణగా 2 కిమీ వ్యాసార్థాన్ని ఉపయోగించడం ఆలస్యం. ఢిల్లీ, భారతదేశం.
అలాగే, సెల్యులార్ నెట్‌వర్క్‌ల పనితీరు కాలానుగుణంగా మారుతుంది. మూర్తి 3 వారంలోని రోజు మధ్యస్థ జాప్యాన్ని చూపుతుంది. మేము ఒకే రోజు మరియు గంటలోపు చిన్న స్థాయిలో తేడాలను కూడా గమనించాము.
మూర్తి 3. తోక ఆలస్యం రోజుల మధ్య గణనీయంగా మారవచ్చు, కానీ అదే ఆపరేటర్ కోసం.
పైన పేర్కొన్నవన్నీ వైర్లెస్ నెట్‌వర్క్‌లలో TCP పనితీరు అసమర్థంగా ఉండటానికి కారణమవుతాయి. అయినప్పటికీ, TCPకి ప్రత్యామ్నాయాల కోసం వెతకడానికి ముందు, మేము ఈ క్రింది అంశాలపై ఖచ్చితమైన అవగాహనను అభివృద్ధి చేయాలనుకుంటున్నాము:
- మా అప్లికేషన్‌లలో టెయిల్ లేటెన్సీల వెనుక TCP ప్రధాన దోషి కాదా?
- ఆధునిక నెట్‌వర్క్‌లు ముఖ్యమైన మరియు విభిన్న రౌండ్-ట్రిప్ జాప్యాలను (RTT) కలిగి ఉన్నాయా?
- TCP పనితీరుపై RTT మరియు నష్టం యొక్క ప్రభావం ఏమిటి?
TCP పనితీరు విశ్లేషణ
మేము TCP పనితీరును ఎలా విశ్లేషించామో అర్థం చేసుకోవడానికి, TCP పంపినవారి నుండి రిసీవర్‌కి డేటాను ఎలా బదిలీ చేస్తుందో శీఘ్రంగా పరిశీలిద్దాం. ముందుగా, పంపినవారు TCP కనెక్షన్‌ని ఏర్పాటు చేసి, మూడు-మార్గాన్ని ప్రదర్శిస్తారు : పంపినవారు SYN ప్యాకెట్‌ను పంపుతారు, రిసీవర్ నుండి SYN-ACK ప్యాకెట్ కోసం వేచి ఉండి, ఆపై ACK ప్యాకెట్‌ను పంపుతారు. TCP కనెక్షన్‌ని స్థాపించడానికి అదనపు రెండవ మరియు మూడవ పాస్ ఖర్చు చేయబడుతుంది. గ్రహీత విశ్వసనీయ డెలివరీని నిర్ధారించడానికి ప్రతి ప్యాకెట్ (ACK) యొక్క రసీదును అంగీకరిస్తాడు.
ప్యాకెట్ లేదా ACK పోయినట్లయితే, పంపినవారు గడువు ముగిసిన తర్వాత తిరిగి ప్రసారం చేస్తారు (RTO, ) పంపినవారు మరియు గ్రహీత మధ్య ఊహించిన RTT ఆలస్యం వంటి వివిధ అంశాల ఆధారంగా RTO డైనమిక్‌గా లెక్కించబడుతుంది.
మూర్తి 4. TCP/TLS ద్వారా ప్యాకెట్ మార్పిడి పునఃప్రసార విధానం కలిగి ఉంటుంది.
మా అప్లికేషన్‌లలో TCP ఎలా పని చేస్తుందో తెలుసుకోవడానికి, మేము TCP ప్యాకెట్లను ఉపయోగించి పర్యవేక్షించాము భారత ఎడ్జ్ సర్వర్‌ల నుండి వచ్చే పోరాట ట్రాఫిక్‌పై ఒక వారం పాటు. మేము ఉపయోగించి TCP కనెక్షన్‌లను విశ్లేషించాము . అదనంగా, మేము ఎమ్యులేటెడ్ ట్రాఫిక్‌ను టెస్ట్ సర్వర్‌కు పంపే Android అప్లికేషన్‌ను సృష్టించాము, వీలైనంత వరకు నిజమైన ట్రాఫిక్‌ని అనుకరిస్తాము. ఈ అప్లికేషన్‌తో కూడిన స్మార్ట్‌ఫోన్‌లు అనేక రోజుల పాటు లాగ్‌లను సేకరించిన అనేక మంది ఉద్యోగులకు పంపిణీ చేయబడ్డాయి.
రెండు ప్రయోగాల ఫలితాలు ఒకదానికొకటి స్థిరంగా ఉన్నాయి. మేము అధిక RTT జాప్యాలను చూశాము; తోక విలువలు మధ్యస్థ విలువ కంటే దాదాపు 6 రెట్లు ఎక్కువ; ఆలస్యం యొక్క అంకగణిత సగటు 1 సెకను కంటే ఎక్కువ. చాలా కనెక్షన్‌లు నష్టపోయాయి, దీని వలన TCP మొత్తం ప్యాకెట్లలో 3,5%ని తిరిగి ప్రసారం చేస్తుంది. విమానాశ్రయాలు మరియు రైలు స్టేషన్లు వంటి రద్దీ ప్రాంతాలలో, మేము 7% నష్టాలను చూశాము. ఈ ఫలితాలు సెల్యులార్ నెట్‌వర్క్‌లలో ఉపయోగించే సాంప్రదాయిక జ్ఞానంపై సందేహాన్ని కలిగిస్తాయి రవాణా స్థాయిలో నష్టాలను గణనీయంగా తగ్గిస్తుంది. "సిమ్యులేటర్" అప్లికేషన్ నుండి పరీక్ష ఫలితాలు క్రింద ఉన్నాయి:
నెట్వర్క్ కొలమానాలు
అర్థం
RTT, మిల్లీసెకన్లు [50%,75%, 95%,99%]
[350, 425, 725, 2300]
RTT డైవర్జెన్స్, సెకన్లు
సగటున ~1,2 సె
అస్థిర కనెక్షన్లలో ప్యాకెట్ నష్టం
సగటు ~3.5% (ఓవర్‌లోడెడ్ ఏరియాల్లో 7%)
ఈ కనెక్షన్లలో దాదాపు సగం కనీసం ఒక ప్యాకెట్ నష్టాన్ని కలిగి ఉన్నాయి, వాటిలో చాలా వరకు SYN మరియు SYN-ACK ప్యాకెట్లు ఉన్నాయి. చాలా TCP అమలులు SYN ప్యాకెట్ల కోసం 1 సెకను RTO విలువను ఉపయోగిస్తాయి, ఇది తదుపరి నష్టాల కోసం విపరీతంగా పెరుగుతుంది. కనెక్షన్‌లను ఏర్పాటు చేయడానికి TCP ఎక్కువ సమయం తీసుకుంటున్నందున అప్లికేషన్ లోడింగ్ సమయాలు పెరగవచ్చు.
డేటా ప్యాకెట్ల విషయంలో, అధిక RTO విలువలు వైర్లెస్ నెట్‌వర్క్‌లలో తాత్కాలిక నష్టాల సమక్షంలో నెట్వర్క్ యొక్క ఉపయోగకరమైన వినియోగాన్ని బాగా తగ్గిస్తాయి. దాదాపు 1 సెకన్ల టెయిల్ ఆలస్యంతో సగటు పునఃప్రసార సమయం సుమారు 30 సెకను అని మేము కనుగొన్నాము. TCP స్థాయిలో ఈ అధిక లేటెన్సీలు HTTPS గడువు ముగియడం మరియు మళ్లీ అభ్యర్థనలకు కారణమయ్యాయి, నెట్వర్క్ జాప్యం మరియు అసమర్థతను మరింత పెంచుతాయి.
కొలిచిన RTT యొక్క 75వ శాతం దాదాపు 425 ms ఉండగా, TCPకి 75వ శాతం దాదాపు 3 సెకన్లు. ఈ నష్టం TCP డేటాను విజయవంతంగా ప్రసారం చేయడానికి 7-10 పాస్‌లను తీసుకుందని ఇది సూచిస్తుంది. ఇది అసమర్థమైన RTO గణన యొక్క పరిణామం కావచ్చు, TCP నష్టానికి త్వరగా స్పందించలేకపోవడం విండోలో మరియు రద్దీ నియంత్రణ అల్గోరిథం యొక్క అసమర్థత, ఇది నెట్వర్క్ రద్దీ కారణంగా వైర్లెస్ నష్టాలు మరియు నష్టాల మధ్య తేడాను గుర్తించదు. TCP నష్ట పరీక్షల ఫలితాలు క్రింద ఉన్నాయి:
TCP ప్యాకెట్ నష్టం గణాంకాలు
విలువ
కనీసం 1 ప్యాకెట్ నష్టంతో కనెక్షన్ల శాతం
45%
కనెక్షన్ సెటప్ సమయంలో నష్టాలతో కనెక్షన్ల శాతం
30%
డేటా మార్పిడి సమయంలో నష్టాలతో కనెక్షన్ల శాతం
76%
పునఃప్రసారం, సెకన్లలో ఆలస్యం పంపిణీ [50%, 75%, 95%,99%] [1, 2.8, 15, 28]
ఒక ప్యాకెట్ లేదా TCP సెగ్మెంట్ కోసం రీట్రాన్స్మిషన్ల సంఖ్య పంపిణీ
[1,3,6,7]
QUIC యొక్క అప్లికేషన్
వాస్తవానికి Google చే అభివృద్ధి చేయబడింది, QUIC అనేది UDP పైన పనిచేసే బహుళ-థ్రెడ్ ఆధునిక రవాణా ప్రోటోకాల్. ప్రస్తుతం QUIC ఉంది (QUIC యొక్క రెండు వెర్షన్లు, ఆసక్తికరంగా ఉన్నాయని మేము ఇప్పటికే వ్రాసాము - సుమారు అనువాదకుడు). మూర్తి 5లో చూపినట్లుగా, QUIC HTTP/3 క్రింద ఉంచబడింది (వాస్తవానికి, QUIC పైన ఉన్న HTTP/2 అనేది HTTP/3, ఇది ఇప్పుడు ఇంటెన్సివ్‌గా ప్రామాణికం చేయబడుతోంది). ఇది ప్యాకెట్లను రూపొందించడానికి UDPని ఉపయోగించడం ద్వారా HTTPS మరియు TCP లేయర్‌లను పాక్షికంగా భర్తీ చేస్తుంది. TLS పూర్తిగా QUICలో నిర్మించబడినందున QUIC సురక్షిత డేటా బదిలీకి మాత్రమే మద్దతు ఇస్తుంది.
మూర్తి 5: QUIC HTTP/3 కింద రన్ అవుతుంది, TLS స్థానంలో ఉంది, ఇది గతంలో HTTP/2 కింద నడిచింది.
TCP యాంప్లిఫికేషన్ కోసం QUICని ఉపయోగించమని మమ్మల్ని ఒప్పించిన కారణాలు క్రింద ఉన్నాయి:
- 0-RTT కనెక్షన్ ఏర్పాటు. QUIC భద్రతా హ్యాండ్‌షేక్‌ల సంఖ్యను తగ్గించడం ద్వారా మునుపటి కనెక్షన్ల నుండి అధికారాల పునర్వినియోగాన్ని అనుమతిస్తుంది. భవిష్యత్తులో 0-RTTకి మద్దతు ఇస్తుంది, అయితే మూడు-మార్గం TCP హ్యాండ్‌షేక్ ఇప్పటికీ అవసరం.
- HoL నిరోధించడాన్ని అధిగమించడం. పనితీరును మెరుగుపరచడానికి HTTP/2 ప్రతి క్లయింట్‌కు ఒక TCP కనెక్షన్‌ని ఉపయోగిస్తుంది, అయితే ఇది HoL (హెడ్-ఆఫ్-లైన్) నిరోధానికి దారి తీస్తుంది. QUIC మల్టీప్లెక్సింగ్‌ను సులభతరం చేస్తుంది మరియు అప్లికేషన్‌కు స్వతంత్రంగా అభ్యర్థనలను అందిస్తుంది.
- రద్దీ నియంత్రణ. QUIC అప్లికేషన్ లేయర్‌లో నివసిస్తుంది, నెట్వర్క్ పారామీటర్‌ల (నష్టాల సంఖ్య లేదా RTT) ఆధారంగా పంపడాన్ని నియంత్రించే ప్రధాన రవాణా అల్గారిథమ్‌ను నవీకరించడాన్ని సులభతరం చేస్తుంది. చాలా TCP అమలులు అల్గారిథమ్‌ను ఉపయోగిస్తాయి , ఇది జాప్యం-సెన్సిటివ్ ట్రాఫిక్‌కు సరైనది కాదు. వంటి అల్గారిథమ్‌లను ఇటీవల అభివృద్ధి చేశారు , నెట్‌వర్క్‌ను మరింత ఖచ్చితంగా మోడల్ చేయండి మరియు జాప్యాన్ని ఆప్టిమైజ్ చేయండి. QUIC BBRని ఉపయోగించడానికి మరియు ఈ అల్గారిథమ్‌ని ఉపయోగించిన విధంగా అప్‌డేట్ చేయడానికి మిమ్మల్ని అనుమతిస్తుంది. .
- నష్టాల భర్తీ. QUIC రెండు TLPలకు కాల్ చేస్తుంది () RTO ట్రిగ్గర్ చేయబడే ముందు - నష్టాలు చాలా గుర్తించదగినవి అయినప్పటికీ. ఇది TCP అమలులకు భిన్నంగా ఉంటుంది. TLP శీఘ్ర భర్తీని ప్రేరేపించడానికి ప్రధానంగా చివరి ప్యాకెట్‌ను (లేదా కొత్తది, ఒకటి ఉంటే) తిరిగి ప్రసారం చేస్తుంది. Uber తన నెట్‌వర్క్‌ని నిర్వహించే విధానానికి, అంటే చిన్న, అప్పుడప్పుడు మరియు జాప్యం-సెన్సిటివ్ డేటా బదిలీల కోసం టెయిల్ ఆలస్యాలను నిర్వహించడం ప్రత్యేకంగా ఉపయోగపడుతుంది.
- ఆప్టిమైజ్ చేసిన ACK. ప్రతి ప్యాకెట్‌కు ప్రత్యేకమైన సీక్వెన్స్ నంబర్ ఉన్నందున, సమస్య లేదు ప్యాకెట్లు తిరిగి ప్రసారం చేయబడినప్పుడు. ACK ప్యాకెట్లు ప్యాకెట్‌ను ప్రాసెస్ చేయడానికి మరియు క్లయింట్ వైపు ACKని రూపొందించడానికి సమయాన్ని కలిగి ఉంటాయి. ఈ లక్షణాలు QUIC RTTని మరింత ఖచ్చితంగా గణించేలా చేస్తుంది. QUICలోని ACK గరిష్టంగా 256 బ్యాండ్‌లకు మద్దతు ఇస్తుంది , పంపేవారికి ప్యాకెట్ షఫుల్ చేయడానికి మరియు ప్రాసెస్‌లో తక్కువ బైట్‌లను ఉపయోగించడానికి మరింత స్థితిస్థాపకంగా ఉండటానికి సహాయపడుతుంది. సెలెక్టివ్ ACK () TCPలో అన్ని సందర్భాల్లోనూ ఈ సమస్యను పరిష్కరించదు.
- కనెక్షన్ వలస. QUIC కనెక్షన్‌లు 64-బిట్ ID ద్వారా గుర్తించబడతాయి, కాబట్టి క్లయింట్ IP చిరునామాలను మార్చినట్లయితే, పాత కనెక్షన్ IDని కొత్త IP చిరునామాలో అంతరాయం లేకుండా ఉపయోగించడం కొనసాగించవచ్చు. వినియోగదారు Wi-Fi మరియు సెల్యులార్ కనెక్షన్ల మధ్య మారే మొబైల్ అప్లికేషన్‌లకు ఇది చాలా సాధారణ పద్ధతి.
QUICకి ప్రత్యామ్నాయాలు
మేము QUICని ఎంచుకోవడానికి ముందు సమస్యను పరిష్కరించడానికి ప్రత్యామ్నాయ విధానాలను పరిగణించాము.
వినియోగదారులకు దగ్గరగా ఉన్న TCP కనెక్షన్‌లను ముగించడానికి TPC PoPలను (పాయింట్‌స్ ఆఫ్ ప్రెజెన్స్) అమలు చేయడానికి మేము ప్రయత్నించిన మొదటి విషయం. ముఖ్యంగా, PoP లు సెల్యులార్ నెట్‌వర్క్‌కు దగ్గరగా ఉన్న మొబైల్ పరికరంతో TCP కనెక్షన్‌ను రద్దు చేస్తాయి మరియు ట్రాఫిక్‌ను అసలు మౌలిక సదుపాయాలకు ప్రాక్సీ చేస్తాయి. TCPని దగ్గరగా ముగించడం ద్వారా, మేము RTTని తగ్గించగలము మరియు TCP డైనమిక్ వైర్లెస్ వాతావరణానికి మరింత ప్రతిస్పందిస్తుందని నిర్ధారించుకోవచ్చు. అయినప్పటికీ, మా ప్రయోగాలు చాలావరకు RTT మరియు నష్టం సెల్యులార్ నెట్‌వర్క్‌ల నుండి వస్తాయని మరియు PoPల ఉపయోగం గణనీయమైన పనితీరు మెరుగుదలను అందించదని చూపించాయి.
మేము TCP పారామితులను ట్యూనింగ్ చేయడం కూడా చూశాము. మా భిన్నమైన ఎడ్జ్ సర్వర్‌లలో TCP స్టాక్‌ను సెటప్ చేయడం కష్టంగా ఉంది, ఎందుకంటే TCP విభిన్న OS సంస్కరణల్లో భిన్నమైన అమలులను కలిగి ఉంది. దీన్ని అమలు చేయడం మరియు విభిన్న నెట్వర్క్ కాన్ఫిగరేషన్‌లను పరీక్షించడం కష్టం. అనుమతులు లేని కారణంగా మొబైల్ పరికరాల్లో నేరుగా TCPని కాన్ఫిగర్ చేయడం సాధ్యం కాలేదు. మరీ ముఖ్యంగా, 0-RTT కనెక్షన్‌లు మరియు మెరుగైన RTT ప్రిడిక్షన్ వంటి లక్షణాలు ప్రోటోకాల్ ఆర్కిటెక్చర్‌కు కీలకం, అందువల్ల TCPని మాత్రమే ట్యూన్ చేయడం ద్వారా గణనీయమైన ప్రయోజనాలను సాధించడం అసాధ్యం.
చివరగా, మేము వీడియో స్ట్రీమింగ్‌ను పరిష్కరించే అనేక UDP-ఆధారిత ప్రోటోకాల్‌లను విశ్లేషించాము-ఈ ప్రోటోకాల్‌లు మా విషయంలో సహాయపడతాయో లేదో చూడాలనుకుంటున్నాము. దురదృష్టవశాత్తూ, వారు చాలా భద్రతా సెట్టింగ్‌లలో చాలా తక్కువగా ఉన్నారు మరియు మెటాడేటా మరియు నియంత్రణ సమాచారం కోసం అదనపు TCP కనెక్షన్ కూడా అవసరం.
భద్రత మరియు పనితీరు రెండింటినీ పరిగణనలోకి తీసుకుంటూనే, ఇంటర్నెట్ ట్రాఫిక్ సమస్యకు సహాయపడే ఏకైక ప్రోటోకాల్ QUIC అని మా పరిశోధనలో తేలింది.
ప్లాట్‌ఫారమ్‌లో QUIC యొక్క ఏకీకరణ
QUICని విజయవంతంగా పొందుపరచడానికి మరియు పేలవమైన కనెక్టివిటీ పరిసరాలలో అప్లికేషన్ పనితీరును మెరుగుపరచడానికి, మేము QUIC ప్రోటోకాల్‌తో పాత స్టాక్‌ను (TLS/TCP ద్వారా HTTP/2) భర్తీ చేసాము. మేము నెట్వర్క్ లైబ్రరీని ఉపయోగించాము నుండి , ఇది ప్రోటోకాల్ యొక్క అసలు, Google సంస్కరణను కలిగి ఉంది - gQUIC. తాజా IETF స్పెసిఫికేషన్‌ను అనుసరించడానికి ఈ అమలు కూడా నిరంతరం మెరుగుపరచబడుతోంది.
QUICకి మద్దతును జోడించడానికి మేము మొదట క్రోనెట్‌ని మా Android యాప్‌లలోకి చేర్చాము. వలస ఖర్చులను వీలైనంత వరకు తగ్గించే విధంగా ఏకీకరణ జరిగింది. లైబ్రరీని ఉపయోగించిన పాత నెట్‌వర్కింగ్ స్టాక్‌ను పూర్తిగా భర్తీ చేయడానికి బదులుగా , మేము OkHttp API ఫ్రేమ్‌వర్క్ క్రింద క్రోనెట్‌ను ఏకీకృతం చేసాము. ఈ విధంగా ఇంటిగ్రేషన్ చేయడం ద్వారా, మేము మా నెట్వర్క్ కాల్‌లకు మార్పులను నివారించాము (వీటిని ఉపయోగిస్తున్నారు ) API స్థాయిలో.
Android పరికరాలకు సంబంధించిన విధానం వలె, మేము iOSలో Uber యాప్‌లలోకి Cronetని అమలు చేసాము, నెట్వర్క్ నుండి HTTP ట్రాఫిక్‌ను అడ్డగించాము ఉపయోగించి . iOS ఫౌండేషన్ అందించిన ఈ సంగ్రహణ, ప్రోటోకాల్-నిర్దిష్ట URL డేటాను నిర్వహిస్తుంది మరియు గణనీయమైన మైగ్రేషన్ ఖర్చులు లేకుండానే మేము మా iOS అప్లికేషన్‌లలో Cronetని ఇంటిగ్రేట్ చేయగలమని నిర్ధారిస్తుంది.
Google క్లౌడ్ బ్యాలెన్సర్‌లలో QUICని పూర్తి చేస్తోంది
బ్యాకెండ్ వైపు, Google క్లౌడ్ లోడ్ బ్యాలెన్సింగ్ ఇన్‌ఫ్రాస్ట్రక్చర్ ద్వారా QUIC కంప్లీషన్ అందించబడుతుంది, ఇది QUICకి మద్దతు ఇవ్వడానికి ప్రతిస్పందనలలో శీర్షికలు. సాధారణంగా, బాలన్సర్ ప్రతి HTTP అభ్యర్థనకు alt-svc హెడర్‌ను జోడిస్తుంది మరియు ఇది ఇప్పటికే డొమైన్‌కు QUIC మద్దతుని ధృవీకరిస్తుంది. Cronet క్లయింట్ ఈ హెడర్‌తో HTTP ప్రతిస్పందనను స్వీకరించినప్పుడు, అది ఆ డొమైన్‌కి తదుపరి HTTP అభ్యర్థనల కోసం QUICని ఉపయోగిస్తుంది. బ్యాలెన్సర్ QUICని పూర్తి చేసిన తర్వాత, మా ఇన్‌ఫ్రాస్ట్రక్చర్ ఈ చర్యను HTTP2/TCP ద్వారా మా డేటా సెంటర్‌లకు స్పష్టంగా పంపుతుంది.
పనితీరు: ఫలితాలు
మెరుగైన ప్రోటోకాల్ కోసం మా శోధనకు అవుట్‌పుట్ పనితీరు ప్రధాన కారణం. ప్రారంభించడానికి, మేము ఒక స్టాండ్‌ని సృష్టించాము వివిధ నెట్వర్క్ ప్రొఫైల్‌ల క్రింద QUIC ఎలా ప్రవర్తిస్తుందో తెలుసుకోవడానికి. వాస్తవ-ప్రపంచ నెట్‌వర్క్‌లలో QUIC పనితీరును పరీక్షించడానికి, ప్యాసింజర్ యాప్‌లోని HTTP కాల్‌ల మాదిరిగానే ఎమ్యులేటెడ్ నెట్వర్క్ ట్రాఫిక్‌ను ఉపయోగించి న్యూఢిల్లీలో డ్రైవింగ్ చేస్తున్నప్పుడు మేము ప్రయోగాలు చేసాము.
ప్రయోగం 1
ప్రయోగం కోసం పరికరాలు:
- మేము వరుసగా TCP మరియు QUIC ద్వారా HTTPS ట్రాఫిక్‌ను అనుమతిస్తామని నిర్ధారించుకోవడానికి OkHttp మరియు Cronet స్టాక్‌లతో Android పరికరాలను పరీక్షించండి;
- ప్రతిస్పందనలలో ఒకే రకమైన HTTPS హెడర్‌లను పంపే మరియు వాటి నుండి అభ్యర్థనలను స్వీకరించడానికి క్లయింట్ పరికరాలను లోడ్ చేసే జావా-ఆధారిత ఎమ్యులేషన్ సర్వర్;
- TCP మరియు QUIC కనెక్షన్‌లను ముగించడానికి భౌతికంగా భారతదేశానికి దగ్గరగా ఉన్న క్లౌడ్ ప్రాక్సీలు. TCP ముగింపు కోసం మేము రివర్స్ ప్రాక్సీని ఉపయోగించాము , QUIC కోసం ఓపెన్ సోర్స్ రివర్స్ ప్రాక్సీని కనుగొనడం కష్టం. మేము Chromium నుండి ప్రాథమిక QUIC స్టాక్‌ని ఉపయోగించి QUIC కోసం రివర్స్ ప్రాక్సీని తయారు చేసాము మరియు అది ఓపెన్ సోర్స్‌గా క్రోమియంలోకి.
మూర్తి 6. TCP vs QUIC రోడ్ టెస్ట్ సూట్‌లో OkHttp మరియు Cronetతో కూడిన Android పరికరాలు, కనెక్షన్‌లను ముగించడానికి క్లౌడ్ ప్రాక్సీలు మరియు ఎమ్యులేషన్ సర్వర్ ఉన్నాయి.
ప్రయోగం 2
Google QUICని అందుబాటులో ఉంచినప్పుడు , మేము అదే ఇన్వెంటరీని ఉపయోగించాము, కానీ ఒక మార్పుతో: NGINXకి బదులుగా, మేము పరికరాల నుండి TCP మరియు QUIC కనెక్షన్‌లను నిలిపివేయడానికి అలాగే HTTPS ట్రాఫిక్‌ను ఎమ్యులేషన్ సర్వర్‌కి మార్చడానికి Google లోడ్ బ్యాలెన్సర్‌లను తీసుకున్నాము. బ్యాలెన్సర్‌లు ప్రపంచవ్యాప్తంగా పంపిణీ చేయబడ్డాయి, అయితే పరికరానికి దగ్గరగా ఉన్న PoP సర్వర్‌ను ఉపయోగించండి (జియోలొకేషన్‌కు ధన్యవాదాలు).
మూర్తి 7. రెండవ ప్రయోగంలో, మేము TCP మరియు QUIC యొక్క పూర్తి జాప్యాన్ని పోల్చాలనుకుంటున్నాము: Google క్లౌడ్‌ని ఉపయోగించడం మరియు మా క్లౌడ్ ప్రాక్సీని ఉపయోగించడం.
తత్ఫలితంగా, అనేక వెల్లడి మాకు ఎదురుచూస్తోంది:
- PoP ద్వారా ముగింపు TCP పనితీరును మెరుగుపరిచింది. బ్యాలెన్సర్‌లు TCP కనెక్షన్‌లను వినియోగదారులకు దగ్గరగా ముగించడం మరియు అత్యంత ఆప్టిమైజ్ చేయబడినందున, ఇది తక్కువ RTTలకు దారితీస్తుంది, ఇది TCP పనితీరును మెరుగుపరుస్తుంది. మరియు QUIC తక్కువగా ప్రభావితం అయినప్పటికీ, ఇది ఇప్పటికీ తోక జాప్యాన్ని (10-30 శాతం) తగ్గించే విషయంలో TCPని అధిగమించింది.
- తోకలు ప్రభావితమవుతాయి . మా QUIC ప్రాక్సీ Google యొక్క లోడ్ బ్యాలెన్సర్‌ల కంటే పరికరాల నుండి (సుమారు 50 ms ఎక్కువ జాప్యం) ఉన్నప్పటికీ, ఇది అదే విధమైన పనితీరును అందించింది - TCP కోసం 15వ పర్సంటైల్‌లో 20% తగ్గింపుతో పాటు జాప్యంలో 99% తగ్గింపు. నెట్‌వర్క్‌లో చివరి మైలు పరివర్తన ఒక అడ్డంకి అని ఇది సూచిస్తుంది.
మూర్తి 8: రెండు ప్రయోగాల ఫలితాలు QUIC గణనీయంగా TCPని అధిగమిస్తుందని చూపుతున్నాయి.
ట్రాఫిక్‌తో పోరాడండి
ప్రయోగం ద్వారా ప్రేరణ పొంది, మేము మా Android మరియు iOS అప్లికేషన్‌లలో QUIC మద్దతును అమలు చేసాము. Uber పనిచేసే నగరాల్లో QUIC ప్రభావాన్ని గుర్తించడానికి మేము A/B పరీక్షను నిర్వహించాము. సాధారణంగా, మేము రెండు ప్రాంతాలు, టెలికాం ఆపరేటర్లు మరియు నెట్వర్క్ రకం అంతటా టెయిల్ ఆలస్యంలో గణనీయమైన తగ్గింపును చూశాము.
దిగువ గ్రాఫ్‌లు స్థూల-ప్రాంతం మరియు వివిధ నెట్వర్క్ రకాలు - LTE, 95G, 99G ద్వారా టెయిల్‌లలో (3 మరియు 2 పర్సంటైల్‌లు) శాతం మెరుగుదలలను చూపుతాయి.
మూర్తి 9. యుద్ధ పరీక్షలలో, QUIC జాప్యం పరంగా TCPని అధిగమించింది.
ముందుకు మాత్రమే
బహుశా ఇది ప్రారంభం మాత్రమే కావచ్చు - ఉత్పత్తిలోకి QUIC విడుదల స్థిరమైన మరియు అస్థిరమైన నెట్‌వర్క్‌లలో అప్లికేషన్ పనితీరును మెరుగుపరచడానికి అద్భుతమైన అవకాశాలను అందించింది, అవి:
కవరేజ్ పెరిగింది
రియల్ ట్రాఫిక్‌పై ప్రోటోకాల్ పనితీరును విశ్లేషించిన తర్వాత, దాదాపు 80% సెషన్‌లు QUICని విజయవంతంగా ఉపయోగించినట్లు మేము చూశాము всех అభ్యర్థనలు, అయితే 15% సెషన్‌లు QUIC మరియు TCP కలయికను ఉపయోగించాయి. క్రోనెట్ లైబ్రరీ TCPకి తిరిగి సమయం ముగియడం వల్ల ఈ కలయిక జరిగిందని మేము ఊహిస్తాము, ఎందుకంటే ఇది నిజమైన UDP వైఫల్యాలు మరియు పేలవమైన నెట్వర్క్ పరిస్థితుల మధ్య తేడాను గుర్తించలేదు. QUIC యొక్క తదుపరి అమలు కోసం మేము పని చేస్తున్నందున మేము ప్రస్తుతం ఈ సమస్యకు పరిష్కారాన్ని చూస్తున్నాము.
QUIC ఆప్టిమైజేషన్
మొబైల్ యాప్‌ల నుండి వచ్చే ట్రాఫిక్ జాప్యం సెన్సిటివ్, కానీ బ్యాండ్‌విడ్త్ సెన్సిటివ్ కాదు. అలాగే, మా అప్లికేషన్‌లు ప్రధానంగా సెల్యులార్ నెట్‌వర్క్‌లలో ఉపయోగించబడతాయి. ప్రయోగాల ఆధారంగా, వినియోగదారులకు దగ్గరగా TCP మరియు QUICని ముగించడానికి ప్రాక్సీని ఉపయోగిస్తున్నప్పటికీ టెయిల్ లేటెన్సీలు ఇప్పటికీ ఎక్కువగానే ఉన్నాయి. మేము రద్దీ నిర్వహణను మెరుగుపరచడానికి మరియు QUIC లాస్ రికవరీ అల్గారిథమ్‌ల సామర్థ్యాన్ని మెరుగుపరచడానికి మార్గాలను చురుకుగా వెతుకుతున్నాము.
ఇవి మరియు అనేక ఇతర మెరుగుదలలతో, మేము నెట్వర్క్ మరియు ప్రాంతంతో సంబంధం లేకుండా వినియోగదారు అనుభవాన్ని మెరుగుపరచాలని ప్లాన్ చేస్తున్నాము, తద్వారా ప్రపంచవ్యాప్తంగా సౌకర్యవంతమైన మరియు అతుకులు లేని ప్యాకెట్ రవాణాను మరింత అందుబాటులోకి తీసుకువస్తాము.
మూలం: www.habr.com