QUIC პროტოკოლი მოქმედებაში: როგორ განახორციელა Uber-მა ის შესრულების ოპტიმიზაციისთვის

QUIC პროტოკოლი უაღრესად საინტერესო საყურებელია, რის გამოც ჩვენ გვიყვარს მასზე წერა. მაგრამ თუ წინა პუბლიკაციები QUIC-ის შესახებ უფრო ისტორიული (ადგილობრივი ისტორია, თუ გნებავთ) ბუნება და აპარატურა იყო, დღეს ჩვენ სიამოვნებით გამოვაქვეყნებთ სხვა სახის თარგმანს - ჩვენ ვისაუბრებთ პროტოკოლის რეალურ გამოყენებაზე 2019 წელს. უფრო მეტიც, საუბარია არა ეგრეთ წოდებულ ავტოფარეხში დაფუძნებულ მცირე ინფრასტრუქტურაზე, არამედ Uber-ზე, რომელიც თითქმის მთელ მსოფლიოში მუშაობს. როგორ მივიდნენ კომპანიის ინჟინრებმა QUIC-ის წარმოებაში გამოყენების გადაწყვეტილება, როგორ ჩაატარეს ტესტები და რა ნახეს მისი წარმოებაში გაშვების შემდეგ - ჭრის ქვემოთ.

სურათების დაჭერა შესაძლებელია. ისიამოვნეთ კითხვით!

Uber-ს აქვს გლობალური მასშტაბი, კერძოდ, 600 ქალაქი, რომელთაგან თითოეულში აპლიკაცია მთლიანად ეყრდნობა უკაბელო ინტერნეტს 4500-ზე მეტი ფიჭური ოპერატორისგან. მომხმარებლები მოელიან, რომ აპლიკაცია იქნება არა მხოლოდ სწრაფი, არამედ რეალურ დროში - ამის მისაღწევად Uber აპს სჭირდება დაბალი შეყოვნება და ძალიან საიმედო კავშირი. ვაი, მაგრამ დასტა HTTP / 2 კარგად არ მუშაობს დინამიურ და დაკარგვისადმი მიდრეკილ უკაბელო ქსელებში. ჩვენ მივხვდით, რომ ამ შემთხვევაში დაბალი შესრულება პირდაპირ კავშირშია TCP დანერგვასთან ოპერაციული სისტემის ბირთვებში.

პრობლემის მოსაგვარებლად მივმართეთ QUICარხის მულტიპლექსირების თანამედროვე პროტოკოლი, რომელიც გვაძლევს მეტ კონტროლს სატრანსპორტო პროტოკოლის შესრულებაზე. ამჟამად სამუშაო ჯგუფი IETF სტანდარტიზებს QUIC როგორც HTTP / 3.

ვრცელი ტესტირების შემდეგ, ჩვენ დავასკვენით, რომ ჩვენს აპლიკაციაში QUIC-ის დანერგვა გამოიწვევს TCP-თან შედარებით დაბალ შეყოვნებას. ჩვენ დავინახეთ შემცირება დიაპაზონში 10-30% HTTPS ტრაფიკისთვის მძღოლისა და მგზავრების აპლიკაციებში. QUIC-მა ასევე მოგვცა საბოლოო კონტროლი მომხმარებლის პაკეტებზე.

ამ სტატიაში ჩვენ ვიზიარებთ ჩვენს გამოცდილებას Uber აპლიკაციებისთვის TCP ოპტიმიზაციის შესახებ დატის გამოყენებით, რომელიც მხარს უჭერს QUIC-ს.

უახლესი ტექნოლოგია: TCP

დღეს TCP არის ყველაზე ხშირად გამოყენებული სატრანსპორტო პროტოკოლი ინტერნეტში HTTPS ტრაფიკის მიწოდებისთვის. TCP უზრუნველყოფს ბაიტების საიმედო ნაკადს, რითაც უმკლავდება ქსელის გადატვირთულობას და ბმული ფენის დანაკარგებს. TCP-ის ფართო გამოყენება HTTPS ტრაფიკისთვის განპირობებულია პირველის ყველგანმყოფობით (თითქმის ყველა OS შეიცავს TCP-ს), ხელმისაწვდომობას უმეტეს ინფრასტრუქტურაზე (როგორიცაა დატვირთვის ბალანსერები, HTTPS მარიონეტები და CDN-ები) და ხელმისაწვდომი ფუნქციონალურობა. თითქმის უმეტეს პლატფორმებზე და ქსელებზე.

მომხმარებელთა უმეტესობა იყენებს ჩვენს აპს მოძრაობაში, და TCP კუდის შეფერხებები არ იყო ახლოს ჩვენი HTTPS ტრაფიკის რეალურ დროში მოთხოვნილებებთან. მარტივად რომ ვთქვათ, მომხმარებლებმა მთელ მსოფლიოში განიცადეს ეს - სურათი 1 გვიჩვენებს შეფერხებებს დიდ ქალაქებში:

სურათი 1: კუდის შეყოვნება განსხვავდება Uber-ის მთავარ ქალაქებში.

მიუხედავად იმისა, რომ ინდოეთის და ბრაზილიის ქსელებში შეყოვნება უფრო მაღალი იყო, ვიდრე აშშ-სა და დიდ ბრიტანეთში, კუდის შეყოვნება მნიშვნელოვნად მაღალია, ვიდრე საშუალო შეყოვნება. და ეს მართალია აშშ-სა და დიდ ბრიტანეთშიც კი.

TCP საჰაერო შესრულება

TCP შეიქმნა ამისთვის სადენიანი ქსელები, ანუ უაღრესად პროგნოზირებადი ბმულების აქცენტით. თუმცა, უკაბელო ქსელებს აქვთ საკუთარი მახასიათებლები და სირთულეები. პირველ რიგში, უკაბელო ქსელები ექვემდებარება დანაკარგებს ჩარევისა და სიგნალის შესუსტების გამო. მაგალითად, Wi-Fi ქსელები მგრძნობიარეა მიკროტალღების, ბლუთუზისა და სხვა რადიოტალღების მიმართ. ფიჭური ქსელები განიცდიან სიგნალის დაკარგვას (დაკარგული გზა) ობიექტების და შენობების მიერ სიგნალის არეკვლის/შთანთქმის გამო, აგრეთვე დან ჩარევა მეზობლებიდან უჯრედის კოშკები. ეს იწვევს უფრო მნიშვნელოვანს (4-10-ჯერ) და უფრო მრავალფეროვნებას ორმხრივი მგზავრობის დრო (RTT) და პაკეტის დაკარგვა სადენიან კავშირთან შედარებით.

გამტარუნარიანობის რყევებთან და დანაკარგებთან საბრძოლველად, ფიჭური ქსელები ჩვეულებრივ იყენებენ დიდ ბუფერებს ტრაფიკის ადიდებისთვის. ამან შეიძლება გამოიწვიოს გადაჭარბებული რიგი, რაც ნიშნავს უფრო მეტ შეფერხებას. ძალიან ხშირად 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 პაკეტებს გამოყენებით tcpdump ერთი კვირის განმავლობაში საბრძოლო ტრაფიკზე, რომელიც მოდის ინდოეთის ზღვარზე სერვერებიდან. შემდეგ ჩვენ გავაანალიზეთ TCP კავშირები გამოყენებით tcptrace. გარდა ამისა, ჩვენ შევქმენით 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 დანერგვის უმეტესობა იყენებს RTO მნიშვნელობას 1 წამის SYN პაკეტებისთვის, რაც ექსპონენტურად იზრდება შემდგომი დანაკარგებისთვის. აპლიკაციის ჩატვირთვის დრო შეიძლება გაიზარდოს იმის გამო, რომ TCP-ს მეტი დრო სჭირდება კავშირების დამყარებისთვის.

მონაცემთა პაკეტების შემთხვევაში, მაღალი RTO მნიშვნელობები მნიშვნელოვნად ამცირებს ქსელის სასარგებლო გამოყენებას უსადენო ქსელებში გარდამავალი დანაკარგების არსებობისას. ჩვენ აღმოვაჩინეთ, რომ საშუალო გადაცემის დრო არის დაახლოებით 1 წამი, კუდის დაგვიანებით თითქმის 30 წამი. ამ მაღალმა შეფერხებებმა TCP დონეზე გამოიწვია HTTPS დროის ამოწურვა და ხელახალი მოთხოვნები, რაც კიდევ უფრო გაზრდის ქსელის შეყოვნებას და არაეფექტურობას.

მიუხედავად იმისა, რომ გაზომილი RTT-ის 75-ე პროცენტული იყო დაახლოებით 425 ms, 75-ე პროცენტული TCP-სთვის იყო თითქმის 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 საშუალებას აძლევს ხელახლა გამოიყენოს ავტორიზაციები წინა კავშირებიდან, რაც ამცირებს უსაფრთხოების ხელის ჩამორთმევის რაოდენობას. Მომავალში TLS 1.3 დაუჭერს მხარს 0-RTT-ს, მაგრამ სამმხრივი TCP ხელის ჩამორთმევა მაინც საჭირო იქნება.
• HoL ბლოკირების დაძლევა. HTTP/2 იყენებს ერთ TCP კავშირს თითო კლიენტზე მუშაობის გასაუმჯობესებლად, მაგრამ ამან შეიძლება გამოიწვიოს HoL (head-of-line) დაბლოკვა. QUIC ამარტივებს მულტიპლექსირებას და დამოუკიდებლად აწვდის მოთხოვნებს აპლიკაციას.
• შეშუპების კონტროლი. QUIC განლაგებულია აპლიკაციის ფენაში, რაც აადვილებს ძირითადი სატრანსპორტო ალგორითმის განახლებას, რომელიც აკონტროლებს გაგზავნას ქსელის პარამეტრების მიხედვით (ზარალის რაოდენობა ან RTT). TCP დანერგვის უმეტესობა იყენებს ალგორითმს კუბური, რომელიც არ არის ოპტიმალური შეყოვნებისადმი მგრძნობიარე ტრაფიკისთვის. ახლახან შემუშავებული ალგორითმები, როგორიცაა BB გაფართოება, უფრო ზუსტად მოდელირება ქსელი და ოპტიმიზაცია შეყოვნება. QUIC საშუალებას გაძლევთ გამოიყენოთ BBR და განაახლოთ ეს ალგორითმი, როგორც ის გამოიყენება. გაუმჯობესება.
• დანაკარგების შევსება. QUIC იძახებს ორ TLP-ს (კუდის დაკარგვის ზონდი) RTO-ს ამოქმედებამდე - მაშინაც კი, როცა დანაკარგები ძალიან შესამჩნევია. ეს განსხვავდება TCP განხორციელებისგან. TLP გადასცემს ძირითადად ბოლო პაკეტს (ან ახალს, თუ არსებობს) სწრაფი შევსების გასააქტიურებლად. კუდის შეფერხებების მართვა განსაკუთრებით სასარგებლოა Uber-ის ქსელთან მუშაობისთვის, კერძოდ მოკლე, სპორადული და ლატენტურად მგრძნობიარე მონაცემთა გადაცემისთვის.
• ოპტიმიზებული ACK. ვინაიდან თითოეულ პაკეტს აქვს უნიკალური მიმდევრობის ნომერი, პრობლემა არ არის განსხვავებები პაკეტები, როდესაც ისინი ხელახლა გადაიცემა. ACK პაკეტები ასევე შეიცავს დროს პაკეტის დასამუშავებლად და კლიენტის მხარეს ACK-ის გენერირებისთვის. ეს ფუნქციები უზრუნველყოფს, რომ QUIC უფრო ზუსტად გამოთვლის RTT-ს. ACK QUIC-ში მხარს უჭერს 256-მდე ზოლს NACK, ეხმარება გამგზავნს იყოს უფრო მდგრადი პაკეტების არევის მიმართ და გამოიყენოს ნაკლები ბაიტი ამ პროცესში. შერჩევითი ACK (ტომარა) TCP-ში ამ პრობლემას ყველა შემთხვევაში არ წყვეტს.
• კავშირის მიგრაცია. QUIC კავშირები იდენტიფიცირებულია 64-ბიტიანი ID-ით, ასე რომ, თუ კლიენტი ცვლის IP მისამართებს, ძველი კავშირის ID შეიძლება კვლავ გამოიყენოთ ახალ IP მისამართზე შეფერხების გარეშე. ეს არის ძალიან გავრცელებული პრაქტიკა მობილური აპლიკაციებისთვის, სადაც მომხმარებელი გადართავს Wi-Fi-სა და ფიჭურ კავშირებს შორის.

QUIC-ის ალტერნატივები

QUIC-ის არჩევამდე განვიხილეთ პრობლემის გადაჭრის ალტერნატიული მიდგომები.

პირველი, რაც ჩვენ შევეცადეთ, იყო TPC PoP-ების (Presence Points) განლაგება, რათა შეწყვიტოთ TCP კავშირები მომხმარებლებთან უფრო ახლოს. არსებითად, PoP-ები წყვეტენ TCP კავშირს მობილურ მოწყობილობასთან უფრო ახლოს ფიჭურ ქსელთან და აბრუნებენ ტრაფიკს თავდაპირველ ინფრასტრუქტურაში. TCP უფრო ახლოს შეწყვეტით, ჩვენ შეგვიძლია პოტენციურად შევამციროთ RTT და დავრწმუნდეთ, რომ TCP უფრო რეაგირებს დინამიურ უკაბელო გარემოზე. თუმცა, ჩვენმა ექსპერიმენტებმა აჩვენა, რომ RTT და დანაკარგების უმეტესი ნაწილი ფიჭური ქსელებიდან მოდის და PoP-ების გამოყენება არ უზრუნველყოფს შესრულების მნიშვნელოვან გაუმჯობესებას.

ჩვენ ასევე გადავხედეთ TCP პარამეტრების დარეგულირებას. ჩვენს ჰეტეროგენულ ზღვარზე სერვერებზე TCP სტეკის დაყენება რთული იყო, რადგან TCP-ს აქვს განსხვავებული დანერგვა OS-ის სხვადასხვა ვერსიებში. რთული იყო ამის განხორციელება და სხვადასხვა ქსელის კონფიგურაციის ტესტირება. პირდაპირ მობილურ მოწყობილობებზე TCP-ის კონფიგურაცია შეუძლებელი იყო ნებართვების არარსებობის გამო. რაც მთავარია, ისეთი ფუნქციები, როგორიცაა 0-RTT კავშირები და გაუმჯობესებული RTT პროგნოზი, გადამწყვეტია პროტოკოლის არქიტექტურისთვის და, შესაბამისად, შეუძლებელია მნიშვნელოვანი სარგებლის მიღწევა მხოლოდ TCP-ის დარეგულირებით.

და ბოლოს, ჩვენ შევაფასეთ UDP-ზე დაფუძნებული რამდენიმე პროტოკოლი, რომლებიც აგვარებენ ვიდეო ნაკადის პრობლემებს - გვინდოდა გვენახა, დაგეხმარებოდა თუ არა ეს პროტოკოლები ჩვენს შემთხვევაში. სამწუხაროდ, მათ ძლიერ აკლდათ მრავალი უსაფრთხოების პარამეტრი და ასევე მოითხოვდნენ დამატებით TCP კავშირს მეტამონაცემებისა და საკონტროლო ინფორმაციისთვის.

ჩვენმა კვლევამ აჩვენა, რომ QUIC არის ალბათ ერთადერთი პროტოკოლი, რომელსაც შეუძლია დაეხმაროს ინტერნეტ ტრაფიკის პრობლემას, უსაფრთხოებისა და შესრულების გათვალისწინებით.

QUIC-ის ინტეგრაცია პლატფორმაში

QUIC-ის წარმატებით ჩასართავად და აპლიკაციის მუშაობის გასაუმჯობესებლად ცუდი კავშირის გარემოში, ჩვენ შევცვალეთ ძველი სტეკი (HTTP/2 TLS/TCP-ზე) QUIC პროტოკოლით. ჩვენ გამოვიყენეთ ქსელის ბიბლიოთეკა კრონეტი საქართველოს Chromium პროექტები, რომელიც შეიცავს პროტოკოლის ორიგინალურ, Google ვერსიას - gQUIC. ეს იმპლემენტაცია ასევე მუდმივად იხვეწება, რათა დაიცვას უახლესი IETF სპეციფიკაცია.

ჩვენ პირველად გავაერთიანეთ Cronet ჩვენს Android აპებში QUIC-ის მხარდაჭერის დასამატებლად. ინტეგრაცია განხორციელდა ისე, რომ მაქსიმალურად შემცირებულიყო მიგრაციის ხარჯები. იმის ნაცვლად, რომ მთლიანად შეცვალოს ძველი ქსელის სტეკი, რომელიც იყენებდა ბიბლიოთეკას OkHttp, ჩვენ გვაქვს Cronet ინტეგრირებული OkHttp API ჩარჩოს ქვეშ. ამ გზით ინტეგრაციის განხორციელებით, ჩვენ თავიდან ავიცილეთ ცვლილებები ჩვენს ქსელურ ზარებში (რომლებსაც იყენებენ გადაკეთება) API დონეზე.

Android მოწყობილობების მიდგომის მსგავსად, ჩვენ დავაყენეთ Cronet Uber-ის აპებში iOS-ზე, რაც ხელს უშლის HTTP ტრაფიკს ქსელიდან. APIგამოყენება NSURL პროტოკოლი. ეს აბსტრაქცია, რომელიც მოწოდებულია iOS ფონდის მიერ, ამუშავებს პროტოკოლის სპეციფიკურ URL მონაცემებს და უზრუნველყოფს Cronet-ის ინტეგრირებას ჩვენს iOS აპლიკაციებში მნიშვნელოვანი მიგრაციის ხარჯების გარეშე.

QUIC-ის დასრულება Google Cloud Balancers-ზე

უკანა მხარეს, QUIC დასრულებას უზრუნველყოფს Google Cloud Load დაბალანსების ინფრასტრუქტურა, რომელიც იყენებს alt-svc სათაურები პასუხებში QUIC-ის მხარდასაჭერად. ზოგადად, ბალანსერი ამატებს alt-svc სათაურს თითოეულ HTTP მოთხოვნას და ეს უკვე ადასტურებს QUIC მხარდაჭერას დომენისთვის. როდესაც Cronet კლიენტი იღებს HTTP პასუხს ამ სათაურით, ის იყენებს QUIC-ს შემდგომი HTTP მოთხოვნებისთვის ამ დომენზე. მას შემდეგ, რაც ბალანსერი დაასრულებს QUIC-ს, ჩვენი ინფრასტრუქტურა ცალსახად აგზავნის ამ მოქმედებას HTTP2/TCP-ით ჩვენს მონაცემთა ცენტრებში.

შესრულება: შედეგები

გამომავალი შესრულება არის უკეთესი პროტოკოლის ძიების მთავარი მიზეზი. დასაწყისისთვის, ჩვენ შევქმენით სტენდი ქსელის ემულაციაიმის გასარკვევად, თუ როგორ მოიქცევა QUIC სხვადასხვა ქსელის პროფილებში. QUIC-ის მუშაობის რეალურ ქსელებზე შესამოწმებლად, ჩვენ ჩავატარეთ ექსპერიმენტები ნიუ დელიში მოგზაურობისას ემულირებული ქსელის ტრაფიკის გამოყენებით, რომელიც ძალიან ჰგავს HTTP ზარებს სამგზავრო აპლიკაციაში.

ექსპერიმენტი 1

აღჭურვილობა ექსპერიმენტისთვის:

• შეამოწმეთ Android მოწყობილობები OkHttp და Cronet სტეკებით, რათა დარწმუნდეთ, რომ ჩვენ დავუშვებთ HTTPS ტრაფიკს TCP-ზე და QUIC-ზე შესაბამისად;
• ჯავაზე დაფუძნებული ემულაციის სერვერი, რომელიც აგზავნის იგივე ტიპის HTTPS სათაურებს პასუხებში და ატვირთავს კლიენტის მოწყობილობებს მათგან მოთხოვნების მისაღებად;
• ღრუბლოვანი მარიონეტები, რომლებიც ფიზიკურად მდებარეობს ინდოეთთან ახლოს TCP და QUIC კავშირების შესაწყვეტად. ხოლო TCP შეწყვეტისთვის ჩვენ ვიყენებდით საპირისპირო პროქსის NGINX, რთული იყო QUIC-ისთვის ღია კოდის საპირისპირო პროქსის პოვნა. ჩვენ თვითონ შევქმენით საპირისპირო პროქსი QUIC-ისთვის Chromium-ის ძირითადი QUIC სტეკის გამოყენებით გამოქვეყნდა ის ქრომის სახით, როგორც ღია წყარო.

სურათი 6. TCP vs QUIC გზის სატესტო კომპლექტი შედგებოდა Android მოწყობილობებისგან OkHttp და Cronet-ით, ღრუბლოვანი პროქსი კავშირების შეწყვეტისთვის და ემულაციის სერვერისგან.

ექსპერიმენტი 2

როდესაც Google-მა QUIC ხელმისაწვდომი გახადა Google Cloud Load Balancing, ჩვენ გამოვიყენეთ იგივე ინვენტარი, მაგრამ ერთი მოდიფიკაციით: 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 დანაკარგების აღდგენის ალგორითმების ეფექტურობის გასაუმჯობესებლად.

ამ და რამდენიმე სხვა გაუმჯობესებით, ჩვენ ვგეგმავთ მომხმარებლის გამოცდილების გაუმჯობესებას ქსელისა და რეგიონის მიუხედავად, რაც ხელსაყრელი და უწყვეტი პაკეტის ტრანსპორტირებას უფრო ხელმისაწვდომი გახდის მთელ მსოფლიოში.

წყარო: www.habr.com