HTTP روی UDP - استفاده مناسب از پروتکل QUIC

QUIC (Quick UDP Internet Connections) پروتکلی در بالای UDP است که از تمامی ویژگی های TCP، TLS و HTTP/2 پشتیبانی می کند و اکثر مشکلات آنها را حل می کند. این پروتکل اغلب یک پروتکل جدید یا "تجربی" نامیده می شود، اما مدت هاست که از مرحله آزمایشی گذشته است: توسعه بیش از 7 سال است که ادامه دارد. در طول این مدت، پروتکل نتوانست به یک استاندارد تبدیل شود، اما همچنان گسترده شد. به عنوان مثال، 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 در داخل گوگل توسعه یافت و تا حد زیادی برای استفاده در شرکت طراحی شد. در سال 2013 برای استانداردسازی به IETF منتقل شد (که هنوز ادامه دارد) و اکنون همه می توانند با پیشنهاد آنچه که از دست داده اند در توسعه پروتکل شرکت کنند. کارگروه IETF جلسات سالانه ای را سازماندهی می کند که طی آن یک استاندارد جدید تصویب شده و نوآوری ها مورد بحث قرار می گیرد. این پیاده سازی QUIC اصلی ترین مورد در نظر گرفته می شود و بر اساس آن استاندارد HTTP/3 تایید می شود.

تاکنون صحبتی در مورد گنجاندن HTTP/3 به عنوان پروتکل اصلی نشده است، زیرا هنوز تکمیل نشده و تقریباً پشتیبانی نمی شود:

اما QUIC می تواند به عنوان یک انتقال بین برنامه و سرور پیاده سازی شود که با موفقیت در Uber انجام شد:

نظر اوبر در مورد معرفی QUIC

به منظور جاسازی موفقیت آمیز QUIC و بهبود عملکرد برنامه در اتصال ضعیف، ما پشته قدیمی (HTTP/2 روی TLS/TCP) را با پروتکل QUIC جایگزین کرده ایم. ما از کتابخانه شبکه استفاده کردیم کرونت از پروژه های کرومیوم، که حاوی نسخه اصلی پروتکل Google - gQUIC است. این پیاده سازی همچنین به طور مداوم در حال بهبود است تا از آخرین مشخصات IETF پیروی کند.

ما ابتدا Cronet را در برنامه های اندروید خود ادغام کردیم تا پشتیبانی QUIC را اضافه کنیم. ادغام به گونه ای انجام شد که هزینه مهاجرت را به حداقل برساند. به جای جایگزینی کامل پشته شبکه قدیمی که از کتابخانه استفاده می کرد OkHttp، ما Cronet را تحت چارچوب OkHttp API یکپارچه کرده ایم. با ادغام به این روش، از تغییر در تماس‌های شبکه خود (که استفاده می‌کنند بازپرداخت) در سطح API.

مشابه رویکرد اندروید، ما با رهگیری ترافیک HTTP از شبکه، Cronet را در برنامه‌های Uber iOS پیاده‌سازی کرده‌ایم. APIاستفاده كردن پروتکل NSURL. این انتزاع که توسط بنیاد iOS ارائه شده است، داده‌های URL خاص پروتکل را مدیریت می‌کند و تضمین می‌کند که می‌توانیم Cronet را در برنامه‌های iOS خود بدون هزینه‌های مهاجرت قابل توجهی ادغام کنیم.

گرفته شده از این ترجمه مقالات اوبر

در باطن آنها اتصالات QUIC را از طریق Google Cloud lb، که از پروتکل پشتیبانی می کند از اواسط سال 2018

جای تعجب نیست که Google Cloud با پروتکل توسعه‌یافته گوگل عالی کار می‌کند، اما گزینه‌های جایگزین چیست؟

Nginx

چندی پیش 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 Canary و آن را با پرچم اجرا کنید --enable-quic، به سرور خود یا مثلاً سایت quic.rocks بروید و در Developer Tools به نوع اتصال نگاه کنید:

به جای HTTP/3 نوشته شده است http2+quic/99، اما اساساً همان چیز است.

سایر فناوری ها

• QUIC نیز پشتیبانی می کند LiteSpeed (که از طریق HTTP/3 با هیاهوی بسیار به فیس بوک متصل می شود) و پیشرو توپ تنیس. آپاچی هنوز نمی تواند این کار را انجام دهد، اما کار در حال انجام است نوسان کامل.
• 21 ژانویه به روز شد پیش نویس استاندارد برای WebRTC
• درست یک روز دیگر مایکروسافت افتتاح شد کد پیاده سازی msquic، که در آن همه عملکردهای استاندارد IETF هنوز در دسترس نیستند، اما این در حال حاضر یک پیشرفت بزرگ است.

نتیجه

علاقه به QUIC ناپایدار است، اما در حال رشد است و کار برای استانداردسازی آن در حال انجام است. پیاده سازی های جدید پروتکل تقریبا هر ماه ظاهر می شوند و هر سال توسعه دهندگان بیشتری متقاعد می شوند که QUIC آینده است. حتی می‌توان پروتکل را در نسخه‌های بعدی پشته TCP گنجاند، به این معنی که دیر یا زود کل اینترنت به اتصالات پایدارتر و سریع‌تر خواهد رفت.

در حال حاضر می توانید تعامل QUIC را برای زیرساخت خود پیکربندی کنید یا حتی آن را به مرورگرها بدهید - همه آنها در حال برنامه ریزی برای اضافه کردن پشتیبانی از پروتکل هستند و آمار غم انگیز با caniuse شادتر می شود.

منبع: www.habr.com