QUIC արձանագրությունը չափազանց հետաքրքիր է դիտելու համար, այդ իսկ պատճառով մենք սիրում ենք գրել դրա մասին: Բայց եթե QUIC-ի մասին նախորդ հրապարակումներն ավելի շատ պատմական (տեղական պատմություն, եթե կուզեք) բնույթ ու սարքավորում էին, ապա այսօր մենք ուրախ ենք տպագրել այլ տեսակի թարգմանություն՝ արձանագրության իրական կիրառման մասին կխոսենք 2019 թվականին: Ընդ որում, խոսքը ոչ թե, այսպես կոչված, ավտոտնակում հիմնված փոքր ենթակառուցվածքների մասին է, այլ Uber-ի, որը գործում է գրեթե ամբողջ աշխարհում։ Ինչպես ընկերության ինժեներները որոշեցին օգտագործել QUIC-ը արտադրության մեջ, ինչպես նրանք կատարեցին թեստերը և ինչ տեսան այն արտադրության մեջ գլորելուց հետո՝ կտրվածքից ցածր:
Նկարները սեղմելի են: Վայելե՛ք կարդալը:
Uber-ն ունի գլոբալ մասշտաբ, մասնավորապես՝ ներկայության 600 քաղաք, որոնցից յուրաքանչյուրում հավելվածն ամբողջությամբ հիմնված է ավելի քան 4500 բջջային օպերատորների անլար ինտերնետի վրա: Օգտատերերն ակնկալում են, որ հավելվածը կլինի ոչ միայն արագ, այլ իրական ժամանակում. դրան հասնելու համար Uber հավելվածին անհրաժեշտ է ցածր ուշացում և շատ հուսալի կապ: Ավաղ, բայց բուրգը լավ չի աշխատում դինամիկ և կորուստների հակված անլար ցանցերում: Մենք հասկացանք, որ այս դեպքում ցածր կատարողականությունը ուղղակիորեն կապված է օպերացիոն համակարգի միջուկներում TCP-ի ներդրման հետ:
Խնդիրը լուծելու համար դիմել ենք , ժամանակակից ալիքների մուլտիպլեքսավորման արձանագրություն, որը մեզ ավելի շատ վերահսկողություն է տալիս տրանսպորտային արձանագրության կատարման վրա: Ներկայումս աշխատանքային խումբը ստանդարտացնում է QUIC-ը որպես .
Լայնածավալ փորձարկումներից հետո մենք եզրակացրինք, որ QUIC-ի ներդրումը մեր հավելվածում կհանգեցնի պոչի ավելի ցածր հետաձգման՝ համեմատած TCP-ի հետ: Մենք նկատեցինք 10-30% կրճատում HTTPS տրաֆիկի համար վարորդի և ուղևորի հավելվածներում: QUIC-ը նաև մեզ տվել է վերջնական վերահսկողություն օգտվողների փաթեթների նկատմամբ:
Այս հոդվածում մենք կիսում ենք Uber հավելվածների համար TCP-ի օպտիմալացման մեր փորձը՝ օգտագործելով QUIC-ն աջակցող կույտ:
Վերջին տեխնոլոգիան՝ TCP
Այսօր TCP-ն ամենաշատ օգտագործվող տրանսպորտային արձանագրությունն է՝ ինտերնետում HTTPS տրաֆիկի առաքման համար: TCP-ն ապահովում է բայթերի հուսալի հոսք՝ դրանով իսկ հաղթահարելով ցանցի գերբեռնվածությունը և կապի շերտի կորուստները: TCP-ի լայնածավալ օգտագործումը HTTPS տրաֆիկի համար պայմանավորված է առաջինի համատարածությամբ (գրեթե յուրաքանչյուր ՕՀ պարունակում է TCP), ենթակառուցվածքների մեծ մասում առկայությամբ (օրինակ՝ բեռնվածության հավասարակշռող սարքեր, HTTPS վստահված սարքեր և CDN-ներ) և հասանելի գործառույթներից դուրս: գրեթե շատ հարթակներում և ցանցերում:
Օգտատերերի մեծամասնությունն օգտագործում է մեր հավելվածը շարժման ընթացքում, և TCP-ի հետևի ուշացումները ոչ մի կերպ մոտ չեն մեր իրական ժամանակի HTTPS տրաֆիկի պահանջներին: Պարզ ասած, ամբողջ աշխարհի օգտատերերը դա զգացել են. Նկար 1-ը ցույց է տալիս ուշացումները խոշոր քաղաքներում.
Նկար 1. Պոչերի հետաձգումը տարբերվում է Uber-ի հիմնական քաղաքներում:
Թեև հնդկական և բրազիլական ցանցերում ուշացումն ավելի բարձր էր, քան ԱՄՆ-ում և Մեծ Բրիտանիայում, պոչի հետաձգումը զգալիորեն ավելի բարձր է, քան միջին ուշացումը: Եվ դա ճիշտ է նույնիսկ ԱՄՆ-ի և Մեծ Բրիտանիայի համար:
TCP օդային կատարողականություն
TCP-ն ստեղծվել է լարային ցանցեր, այսինքն՝ շեշտը դնելով խիստ կանխատեսելի հղումների վրա։ Այնուամենայնիվ, անլար ցանցերն ունեն իրենց առանձնահատկություններն ու դժվարությունները: Նախ, անլար ցանցերը ենթակա են կորուստների՝ կապված միջամտության և ազդանշանի թուլացման հետ: Օրինակ, Wi-Fi ցանցերը զգայուն են միկրոալիքային վառարանների, bluetooth-ի և այլ ռադիոալիքների նկատմամբ: Բջջային ցանցերը տուժում են ազդանշանի կորստից () օբյեկտների և շինությունների, ինչպես նաև ազդանշանի արտացոլման/կլանման պատճառով հարևանից . Սա հանգեցնում է ավելի նշանակալի (4-10 անգամ) և ավելի բազմազան և փաթեթի կորուստ՝ համեմատած լարային կապի հետ:
Թողունակության տատանումների և կորուստների դեմ պայքարելու համար բջջային ցանցերը սովորաբար օգտագործում են մեծ բուֆերներ երթևեկության պայթյունների համար: Սա կարող է հանգեցնել ավելորդ հերթերի, ինչը նշանակում է ավելի երկար ուշացումներ: Շատ հաճախ TCP-ն վերաբերվում է այս հերթին որպես վատնում երկարաձգված ժամանակի դադարի պատճառով, ուստի TCP-ն հակված է փոխանցել և դրանով իսկ լրացնել բուֆերը: Այս խնդիրը հայտնի է որպես (), և սա շատ է ժամանակակից ինտերնետ.
Ի վերջո, բջջային ցանցի աշխատանքը տատանվում է ըստ օպերատորի, տարածաշրջանի և ժամանակի: Նկար 2-ում մենք հավաքել ենք HTTPS տրաֆիկի միջին ուշացումները բջիջների միջով 2 կիլոմետր տիրույթում: Տվյալներ հավաքագրվել են երկու խոշոր բջջային օպերատորների համար Դելիում, Հնդկաստան: Ինչպես տեսնում եք, կատարումը տատանվում է բջիջից բջիջ: Նաև մեկ օպերատորի արտադրողականությունը տարբերվում է երկրորդի արտադրողականությունից: Դրա վրա ազդում են այնպիսի գործոններ, ինչպիսիք են ցանցի մուտքի ձևերը՝ հաշվի առնելով ժամանակը և գտնվելու վայրը, օգտագործողների շարժունակությունը, ինչպես նաև ցանցային ենթակառուցվածքը՝ հաշվի առնելով աշտարակի խտությունը և ցանցի տեսակների հարաբերակցությունը (LTE, 3G և այլն):
Նկար 2. Հետաձգումներ՝ օգտագործելով 2 կմ շառավիղը որպես օրինակ: Դելի, Հնդկաստան.
Բացի այդ, բջջային ցանցերի արդյունավետությունը տատանվում է ժամանակի ընթացքում: Գծապատկեր 3-ը ցույց է տալիս միջին ուշացումն ըստ շաբաթվա օրերի: Մենք նաև նկատեցինք տարբերություններ ավելի փոքր մասշտաբով՝ մեկ օրվա և մեկ ժամվա ընթացքում:
Նկար 3. Պոչերի հետաձգումները կարող են զգալիորեն տարբերվել օրերի միջև, բայց նույն օպերատորի համար:
Վերոհիշյալ բոլորը հանգեցնում են նրան, որ TCP-ի կատարումն անարդյունավետ է անլար ցանցերում: Այնուամենայնիվ, նախքան TCP-ի այլընտրանքներ փնտրելը, մենք ցանկանում էինք ճշգրիտ պատկերացում կազմել հետևյալ կետերի վերաբերյալ.
- Արդյո՞ք TCP-ն հիմնական մեղավորն է մեր հավելվածների ուշացման հետևում:
- Արդյո՞ք ժամանակակից ցանցերն ունեն զգալի և բազմազան հետաձգումներ (RTT):
- Ո՞րն է RTT-ի և կորստի ազդեցությունը TCP-ի կատարողականի վրա:
TCP-ի կատարողականի վերլուծություն
Հասկանալու համար, թե ինչպես ենք մենք վերլուծել TCP-ի կատարումը, եկեք արագ նայենք, թե ինչպես է TCP-ն փոխանցում տվյալներն ուղարկողից ստացողին: Նախ, ուղարկողը հաստատում է TCP կապ՝ կատարելով եռակողմ Ուղարկողը ուղարկում է SYN փաթեթ, սպասում է ստացողի կողմից SYN-ACK փաթեթին, այնուհետև ուղարկում է ACK փաթեթ: Լրացուցիչ երկրորդ և երրորդ անցաթուղթը ծախսվում է TCP կապի հաստատման համար: Ստացողը հաստատում է յուրաքանչյուր փաթեթի ստացումը (ACK)՝ հուսալի առաքում ապահովելու համար:
Եթե փաթեթը կամ ACK-ը կորչում է, ուղարկողը վերահասցեավորում է դադարից հետո (RTO, ) RTO-ն հաշվարկվում է դինամիկ կերպով՝ հիմնվելով տարբեր գործոնների վրա, ինչպիսիք են ուղարկողի և ստացողի միջև սպասվող RTT ուշացումը:
Նկար 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-ի տակ (փաստորեն, HTTP/2-ը QUIC-ի վերևում HTTP/3-ն է, որն այժմ ինտենսիվ ստանդարտացվում է): Այն մասամբ փոխարինում է HTTPS և TCP շերտերը՝ օգտագործելով UDP փաթեթներ ձևավորելու համար: QUIC-ն աջակցում է միայն տվյալների անվտանգ փոխանցմանը, քանի որ TLS-ն ամբողջությամբ ներկառուցված է QUIC-ում:
Նկար 5. QUIC-ն աշխատում է HTTP/3-ի ներքո՝ փոխարինելով TLS-ին, որը նախկինում աշխատում էր HTTP/2-ի ներքո:
Ստորև բերված են այն պատճառները, որոնք մեզ համոզեցին օգտագործել QUIC-ը TCP ուժեղացման համար.
- 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-ը: ACK-ը QUIC-ում աջակցում է մինչև 256 տիրույթ , օգնելով ուղարկողին ավելի դիմացկուն լինել փաթեթների խառնման նկատմամբ և օգտագործել ավելի քիչ բայթ գործընթացում: Ընտրովի ACK () TCP-ում ոչ բոլոր դեպքերում է լուծում այս խնդիրը:
- կապի միգրացիա. QUIC կապերը նույնացվում են 64-բիթանոց ID-ով, այնպես որ, եթե հաճախորդը փոխում է IP հասցեները, ապա հին կապի ID-ն կարող է շարունակել օգտագործվել նոր IP հասցեում առանց ընդհատումների: Սա շատ տարածված պրակտիկա է բջջային հավելվածների համար, որտեղ օգտատերը անցնում է Wi-Fi-ի և բջջային կապերի միջև:
QUIC-ի այլընտրանքներ
Նախքան QUIC-ն ընտրելը դիտարկել ենք խնդրի լուծման այլընտրանքային մոտեցումներ:
Առաջին բանը, որ մենք փորձեցինք, TPC PoPs (Ներկայության կետեր) տեղակայելն էր՝ օգտվողներին ավելի մոտ TCP կապերը դադարեցնելու համար: Ըստ էության, PoP-ները դադարեցնում են TCP կապը բջջային ցանցին ավելի մոտ գտնվող բջջային սարքի հետ և փոխադրում են տրաֆիկը դեպի սկզբնական ենթակառուցվածք: TCP-ն ավելի մոտեցնելով, մենք կարող ենք պոտենցիալ նվազեցնել RTT-ը և ապահովել, որ TCP-ն ավելի շատ արձագանքում է դինամիկ անլար միջավայրին: Այնուամենայնիվ, մեր փորձերը ցույց են տվել, որ RTT-ի և կորստի մեծ մասը գալիս է բջջային ցանցերից, և PoP-ների օգտագործումը չի ապահովում կատարողականի զգալի բարելավում:
Մենք նաև նայեցինք TCP պարամետրերի թյունինգին: Մեր տարասեռ եզրային սերվերների վրա TCP ստեկի ստեղծումը դժվար էր, քանի որ TCP-ն ունի տարբեր իրականացումներ ՕՀ-ի տարբեր տարբերակներում: Դժվար էր դա իրականացնել և փորձարկել ցանցի տարբեր կոնֆիգուրացիաներ: TCP-ի կարգավորումն անմիջապես շարժական սարքերի վրա հնարավոր չէր թույլտվությունների բացակայության պատճառով: Ավելի կարևոր է, որ այնպիսի առանձնահատկություններ, ինչպիսիք են 0-RTT կապերը և բարելավված RTT կանխատեսումը, կարևոր են արձանագրության ճարտարապետության համար, և, հետևաբար, անհնար է էական առավելությունների հասնել միայն TCP-ի թյունինգով:
Վերջապես, մենք գնահատեցինք UDP-ի վրա հիմնված մի քանի արձանագրություններ, որոնք լուծում են տեսահոսքի անսարքությունները. մենք ուզում էինք տեսնել, թե արդյոք այս արձանագրությունները կօգնե՞ն մեր դեպքում: Ցավոք սրտի, դրանք խիստ բացակայում էին անվտանգության բազմաթիվ կարգավորումներում, ինչպես նաև պահանջում էին լրացուցիչ TCP կապ մետատվյալների և վերահսկման տեղեկատվության համար:
Մեր հետազոտությունը ցույց է տվել, որ QUIC-ը, թերևս, միակ արձանագրությունն է, որը կարող է օգնել ինտերնետ տրաֆիկի խնդրին, միաժամանակ հաշվի առնելով և՛ անվտանգությունը, և՛ արդյունավետությունը:
QUIC-ի ինտեգրումը հարթակում
QUIC-ը հաջողությամբ զետեղելու և հավելվածի աշխատանքը վատ կապակցված միջավայրում բարելավելու համար մենք փոխարինեցինք հին փաթեթը (HTTP/2՝ TLS/TCP-ով) QUIC արձանագրությամբ: Մենք օգտագործեցինք ցանցային գրադարանը - ից , որը պարունակում է արձանագրության բնօրինակ, Google տարբերակը՝ gQUIC: Այս իրականացումը նույնպես մշտապես բարելավվում է՝ հետևելու IETF-ի վերջին ճշգրտմանը:
Մենք նախ ինտեգրեցինք Cronet-ը մեր Android հավելվածներում՝ QUIC-ին աջակցություն ավելացնելու համար: Ինտեգրումն իրականացվել է այնպես, որ հնարավորինս կրճատվեն միգրացիոն ծախսերը։ Գրադարանն օգտագործող հին ցանցային կույտը ամբողջությամբ փոխարինելու փոխարեն , մենք ինտեգրել ենք Cronet-ը OkHttp API շրջանակի ներքո: Այս կերպ ինտեգրումը կատարելով՝ մենք խուսափեցինք մեր ցանցային զանգերի փոփոխություններից (որոնք օգտագործվում են ) API մակարդակում:
Android սարքերի մոտեցման նման՝ մենք Cronet-ը ներդրեցինք Uber հավելվածներում iOS-ում՝ ընդհատելով HTTP տրաֆիկը ցանցից։ օգտագործելով . Այս աբստրակցիան, որը տրամադրվել է iOS հիմնադրամի կողմից, մշակում է արձանագրության հատուկ URL-ի տվյալները և երաշխավորում է, որ մենք կարող ենք ինտեգրել Cronet-ը մեր iOS հավելվածներում՝ առանց զգալի միգրացիոն ծախսերի:
QUIC-ի լրացում Google Cloud Balancers-ում
Հետին մասում QUIC-ի ավարտը տրամադրվում է Google Cloud Load-ի հավասարակշռման ենթակառուցվածքի կողմից, որն օգտագործում է վերնագրեր՝ QUIC-ին աջակցելու պատասխաններում: Ընդհանուր առմամբ, հավասարակշռողն ավելացնում է alt-svc վերնագիր յուրաքանչյուր HTTP հարցումին, և դա արդեն վավերացնում է QUIC աջակցությունը տիրույթի համար: Երբ Cronet-ի հաճախորդը ստանում է HTTP պատասխան այս վերնագրով, այն օգտագործում է QUIC՝ այդ տիրույթին հաջորդող HTTP հարցումների համար: Երբ հավասարակշռողն ավարտում է QUIC-ը, մեր ենթակառուցվածքը բացահայտորեն ուղարկում է այս գործողությունը HTTP2/TCP-ի միջոցով մեր տվյալների կենտրոններին:
Կատարում: Արդյունքներ
Արդյունքների կատարումը ավելի լավ արձանագրության մեր որոնման հիմնական պատճառն է: Սկզբից մենք ստենդ ենք ստեղծել պարզելու, թե ինչպես է իրեն պահելու QUIC-ը տարբեր ցանցային պրոֆիլների ներքո: QUIC-ի կատարողականությունը իրական աշխարհի ցանցերում փորձարկելու համար մենք փորձեր կատարեցինք Նյու Դելիում շրջելիս՝ օգտագործելով նմանակված ցանցային տրաֆիկը, որը շատ նման է ուղևորների հավելվածի HTTP զանգերին:
Փորձ 1
Սարքավորումներ փորձի համար.
- փորձարկել Android սարքերը OkHttp և Cronet կույտերով՝ համոզվելու համար, որ մենք թույլ ենք տալիս HTTPS տրաֆիկը համապատասխանաբար TCP և QUIC-ով;
- Java-ի վրա հիմնված էմուլյացիոն սերվեր, որը պատասխանների մեջ ուղարկում է նույն տեսակի HTTPS վերնագրեր և բեռնում է հաճախորդի սարքերը՝ նրանցից հարցումներ ստանալու համար.
- ամպային վստահված անձինք, որոնք ֆիզիկապես տեղակայված են Հնդկաստանի մոտ՝ TCP և QUIC կապերը դադարեցնելու համար: Մինչ TCP-ի դադարեցման համար մենք օգտագործում էինք հակադարձ պրոքսի , դժվար էր QUIC-ի համար բաց կոդով հակադարձ պրոքսի գտնել: Մենք ինքներս կառուցեցինք հակադարձ պրոքսի QUIC-ի համար՝ օգտագործելով Chromium-ի հիմնական QUIC փաթեթը և այն վերածվում է քրոմի՝ որպես բաց կոդով:
Նկար 6. TCP vs QUIC ճանապարհային փորձարկման փաթեթը բաղկացած էր Android սարքերից OkHttp-ով և Cronet-ով, կապերն ավարտելու համար ամպային վստահված սարքերից և էմուլացիոն սերվերից:
Փորձ 2
Երբ Google-ը հասանելի դարձրեց QUIC-ը , մենք օգտագործեցինք նույն գույքագրումը, բայց մեկ փոփոխությամբ. NGINX-ի փոխարեն մենք վերցրեցինք Google-ի բեռների հավասարակշռող սարքերը՝ դադարեցնելու TCP և QUIC կապերը սարքերից, ինչպես նաև ուղղորդելու HTTPS տրաֆիկը դեպի էմուլացիոն սերվեր: Հավասարակշռիչները բաշխված են ամբողջ աշխարհում, բայց օգտագործում են սարքին ամենամոտ գտնվող PoP սերվերը (շնորհիվ աշխարհագրական դիրքի):
Նկար 7. Երկրորդ փորձի ժամանակ մենք ցանկանում էինք համեմատել TCP-ի և QUIC-ի ավարտի հետաձգումը. օգտագործելով Google Cloud-ը և օգտագործելով մեր ամպային վստահված անձը:
Արդյունքում մեզ մի քանի բացահայտումներ էին սպասում.
- PoP-ի միջոցով դադարեցումը բարելավեց TCP-ի կատարումը: Քանի որ հավասարակշռողները դադարեցնում են TCP կապերը օգտվողներին ավելի մոտ և շատ օպտիմիզացված են, դա հանգեցնում է ցածր RTT-ների, ինչը բարելավում է TCP-ի կատարումը: Եվ թեև QUIC-ն ավելի քիչ է տուժել, այն դեռևս գերազանցել է TCP-ն՝ պոչի հետաձգման կրճատման առումով (10-30 տոկոսով):
- պոչերը ախտահարվում են . Չնայած մեր QUIC պրոքսին ավելի հեռու էր սարքերից (մոտ 50 ms-ով ավելի բարձր ուշացում), քան Google-ի բեռնվածության հավասարակշռողները, այն ապահովում էր նմանատիպ արդյունավետություն՝ 15% հետաձգման կրճատում TCP-ի 20% նվազման դիմաց 99-րդ ցենտիլում: Սա ենթադրում է, որ վերջին մղոնի անցումը ցանցի խցան է:
Նկար 8. Երկու փորձերի արդյունքները ցույց են տալիս, որ QUIC-ը զգալիորեն գերազանցում է TCP-ին:
Մարտական երթևեկություն
Ոգեշնչված փորձերից՝ մենք ներդրել ենք QUIC աջակցություն մեր Android և iOS հավելվածներում: Մենք A/B թեստավորում ենք անցկացրել՝ QUIC-ի ազդեցությունը որոշելու այն քաղաքներում, որտեղ գործում է Uber-ը: Ընդհանուր առմամբ, մենք տեսանք պոչի հետաձգումների զգալի կրճատում երկու մարզերում, հեռահաղորդակցության օպերատորների և ցանցի տեսակի մեջ:
Ստորև բերված գրաֆիկները ցույց են տալիս պոչերի տոկոսային բարելավումները (95 և 99 տոկոս) ըստ մակրոշրջանի և ցանցի տարբեր տեսակների՝ LTE, 3G, 2G:
Նկար 9. Մարտական թեստերում QUIC-ը գերազանցում էր TCP-ին լատենտության առումով:
Միայն առաջ
Թերևս սա միայն սկիզբն է. QUIC-ի թողարկումը արտադրության մեջ զարմանալի հնարավորություններ է ընձեռել բարելավելու հավելվածների կատարումը ինչպես կայուն, այնպես էլ անկայուն ցանցերում, մասնավորապես.
Ծածկույթի ավելացում
Վերլուծելով արձանագրության կատարումը իրական տրաֆիկի վրա՝ մենք տեսանք, որ նիստերի մոտավորապես 80%-ը հաջողությամբ օգտագործել է QUIC-ը: Ամբողջ հարցումներ, մինչդեռ նիստերի 15%-ն օգտագործում էր QUIC-ի և TCP-ի համադրություն: Մենք ենթադրում ենք, որ համակցությունը պայմանավորված է Cronet գրադարանի ժամանակի դադարով դեպի TCP, քանի որ այն չի կարող տարբերակել իրական UDP խափանումներն ու ցանցի վատ պայմանները: Մենք ներկայումս փնտրում ենք այս խնդրի լուծումը, քանի որ աշխատում ենք QUIC-ի հետագա իրականացման ուղղությամբ:
QUIC օպտիմիզացում
Բջջային հավելվածներից երթևեկությունը զգայուն է հապաղման նկատմամբ, բայց ոչ թողունակության նկատմամբ: Բացի այդ, մեր հավելվածները հիմնականում օգտագործվում են բջջային ցանցերում: Ելնելով փորձերից՝ պոչերի հետաձգումները դեռևս բարձր են, թեև օգտագործողների մոտ TCP-ն և QUIC-ը դադարեցնելու համար օգտագործվող պրոքսի է: Մենք ակտիվորեն ուղիներ ենք փնտրում գերբեռնվածության կառավարումը բարելավելու և QUIC կորուստների վերականգնման ալգորիթմների արդյունավետությունը բարելավելու համար:
Այս և մի քանի այլ բարելավումներով մենք նախատեսում ենք բարելավել օգտատերերի փորձը՝ անկախ ցանցից և տարածաշրջանից՝ հարմարավետ և անխափան փաթեթների փոխադրումն ավելի հասանելի դարձնելով ամբողջ աշխարհում:
Source: www.habr.com