HTTP UDP-ზე - QUIC პროტოკოლის კარგად გამოყენება

QUIC (Quick UDP Internet Connections) არის პროტოკოლი UDP-ის თავზე, რომელიც მხარს უჭერს TCP, TLS და HTTP/2-ის ყველა მახასიათებელს და წყვეტს მათ პრობლემებს. მას ხშირად უწოდებენ ახალ ან „ექსპერიმენტულ“ პროტოკოლს, მაგრამ ის დიდი ხანია აჭარბებს ექსპერიმენტულ ეტაპს: განვითარება 7 წელზე მეტია მიმდინარეობს. ამ ხნის განმავლობაში პროტოკოლმა ვერ შეძლო სტანდარტად ქცევა, მაგრამ მაინც ფართოდ გავრცელდა. მაგალითად, QUIC გამოიყენება ისეთი გიგანტების მიერ, როგორიცაა Google და Facebook, რათა დააჩქაროს ტრაფიკი და შეამციროს შეფერხებები მობილურ ქსელებში, და 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-ში:

Uber-ის კომენტარი 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 აპლიკაციებში მნიშვნელოვანი მიგრაციის ხარჯების გარეშე.

აღებულია ეს თარგმანი Uber-ის სტატიები

უკანა პლანზე მათ დაიჭირეს QUIC კავშირები Google Cloud lb-ის მეშვეობით, რომელიც მხარს უჭერს პროტოკოლს 2018 წლის შუა რიცხვებიდან.

გასაკვირი არ არის, რომ Google Cloud მშვენივრად მუშაობს 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 საიტზე და შეხედეთ კავშირის ტიპს Developer Tools-ში:

HTTP/3-ის ნაცვლად წერია http2+quic/99, მაგრამ ეს არსებითად იგივეა.

სხვა ტექნოლოგიები

• QUIC ასევე მხარს უჭერს LiteSpeed (რომელიც ფეისბუკს უკავშირდებოდა HTTP/3-ის საშუალებით დიდი აურზაურით) და პროგრესული Caddy. Apache-ს ჯერ არ შეუძლია, მაგრამ სამუშაოები მიმდინარეობს სრული სვლა.
• განახლებულია 21 იანვარს WebRTC სტანდარტის პროექტი
• მხოლოდ მეორე დღეს Microsoft გაიხსნა msquic განხორციელების კოდი, რომელშიც IETF სტანდარტის ყველა ფუნქცია ჯერ არ არის ხელმისაწვდომი, მაგრამ ეს უკვე დიდი გარღვევაა.

დასკვნა

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

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

წყარო: www.habr.com