HTTP/3 و QUIC: آنچه پایه جدید وب واقعاً تغییر می‌دهد

HTTP/3 در حال حاضر پیش‌فرض وب برای یک سوم کل ترافیک است

HTTP/3 اکنون بیش از ۳۰٪ از ترافیک وب جهانی را مدیریت می‌کند و بیشتر کاربران نمی‌دانند که در حال استفاده از آن هستند. تغییر از HTTP/2 به HTTP/3 ظاهری نیست - این تغییر لایه انتقال را به طور کامل جایگزین می‌کند و TCP را با QUIC، پروتکلی که از ابتدا روی UDP ساخته شده است، عوض می‌کند. نتیجه، راه‌اندازی سریع‌تر اتصال، مقاومت در برابر از دست رفتن بسته، و توانایی زنده ماندن در تغییرات شبکه بدون نیاز به اتصال مجدد است. درک اینکه چه چیزی تغییر کرده و چرا اهمیت دارد، نیاز به بازگشت به مشکل اساسی TCP دارد.

انسداد سرخط (HOL blocking) در TCP: مشکل صف صندوق

یک سوپرمارکت با یک خط پرداخت را تصور کنید. حتی اگر ۱۰ مشتری پشت سر شما فقط یک کالا داشته باشند، همه منتظر می‌مانند تا صندوقدار سبد پر شما را پردازش کند. TCP به همین صورت کار می‌کند: داده‌ها را به ترتیب دقیق تحویل می‌دهد. اگر یک بسته گم شود، هر بسته بعدی - حتی برای منابع کاملاً متفاوت - در صف منتظر می‌ماند تا بسته گمشده دوباره ارسال و تأیید شود. این انسداد سرخط (HOL) در لایه TCP است.

HTTP/2 مالتی‌پلکسینگ را معرفی کرد و چندین جریان داده را روی یک اتصال TCP واحد ارسال می‌کند. این مشکل انسداد سرخط را در لایه برنامه حل کرد - چندین درخواست دیگر در داخل HTTP منتظر یکدیگر نمی‌ماندند. اما این رفع ناقص بود. یک بسته TCP افتاده همچنان همه جریان‌ها را به طور همزمان در لایه انتقال متوقف می‌کند، زیرا TCP اتصال را به عنوان یک جریان بایت مرتب می‌بیند و از مرزهای HTTP/2 بالای آن آگاه نیست. نرخ ۱٪ از دست رفتن بسته در یک اتصال HTTP/2 می‌تواند تأخیرهایی بدتر از HTTP/1.1 ایجاد کند.

QUIC انسداد سرخط را در لایه انتقال حذف می‌کند

QUIC توسط Google طراحی و در سال ۲۰۲۱ در RFC 9000 استاندارد شد. این پروتکل روی UDP به جای TCP اجرا می‌شود، به این معنی که کنترل کامل قابلیت اطمینان، ترتیب، و کنترل ازدحام را در فضای کاربر به جای واگذاری به هسته سیستم‌عامل به دست می‌گیرد. تصمیم معماری کلیدی: هر جریان HTTP/3 به طور مستقل در داخل QUIC توالی‌بندی می‌شود. یک بسته گمشده متعلق به جریان ۳، جریان ۷ را مسدود نمی‌کند. سایر جریان‌ها بدون وقفه به جریان خود ادامه می‌دهند در حالی که ارسال مجدد در پس‌زمینه انجام می‌شود.

این فقط یک بهبود حاشیه‌ای نیست. در اتصالات با تلفات بالا - شبکه‌های موبایل، لینک‌های دوربرد، WiFi شلوغ - تفاوت قابل اندازه‌گیری و ثابت است. QUIC همچنین TLS 1.3 را به صورت بومی بسته‌بندی می‌کند؛ هیچ دست‌دهی TLS جداگانه‌ای وجود ندارد. امنیت در پروتکل تعبیه شده است، نه لایه‌بندی شده روی آن.

راه‌اندازی اتصال 0-RTT در مقابل دست‌دهی سه مرحله‌ای TCP

یک اتصال TCP قبل از جریان یافتن داده‌ها نیاز به یک دست‌دهی سه مرحله‌ای دارد: SYN، SYN-ACK، ACK. اضافه کردن یک دست‌دهی TLS روی آن به معنای ۲ تا ۳ رفت و برگشت قبل از رسیدن اولین بایت محتوا است. در یک اتصال با RTT 100 میلی‌ثانیه، این ۲۰۰ تا ۳۰۰ میلی‌ثانیه زمان مرده قبل از ارسال اولین درخواست HTTP از مرورگر است.

دست‌دهی 1-RTT QUIC راه‌اندازی انتقال و رمزنگاری را در یک رفت و برگشت واحد ترکیب می‌کند. مهم‌تر اینکه، برای بازدیدکنندگان بازگشتی، QUIC از ازسرگیری 0-RTT پشتیبانی می‌کند - مشتری می‌تواند داده‌ها را در اولین بسته با استفاده از کلیدهای جلسه از یک اتصال قبلی ارسال کند. این کار راه‌اندازی اتصال را برای بازدیدهای مکرر به صفر رفت و برگشت اضافی کاهش می‌دهد، که یک برد قابل توجه برای تماس‌های API با فرکانس بالا و پیمایش‌های مکرر است.

مهاجرت اتصال: زنده ماندن در تغییر شبکه

TCP یک اتصال را با یک 4-تایی شناسایی می‌کند: IP مبدأ، پورت مبدأ، IP مقصد، پورت مقصد. وقتی از WiFi دفتر به پارکینگ می‌روید و تلفن شما به LTE سوئیچ می‌کند، آدرس IP شما تغییر می‌کند. TCP این را به عنوان یک نقطه پایانی کاملاً جدید می‌بیند - اتصال موجود قطع می‌شود و همه چیز باید از ابتدا شروع شود. هر درخواست باز شکست می‌خورد.

QUIC از یک Connection ID استفاده می‌کند - یک شناسه تصادفی که در زمان دست‌دهی مذاکره می‌شود - برای شناسایی اتصال مستقل از آدرس IP و پورت. وقتی شبکه تغییر می‌کند، مشتری بسته‌هایی با همان Connection ID از آدرس جدید خود ارسال می‌کند. سرور ID را تشخیص می‌دهد، اتصال به طور شفاف مهاجرت می‌کند و جریان‌های در حال انجام بدون وقفه ادامه می‌یابند. برای کاربران موبایل - که اکنون اکثریت ترافیک وب را تشکیل می‌دهند - این یک بهبود قابلیت اطمینان ملموس است، نه نظری.

اعداد پذیرش: چه کسانی در حال اجرای HTTP/3 هستند

Cloudflare HTTP/3 را در سراسر شبکه خود در سال ۲۰۲۰ فعال کرد و گزارش می‌دهد که اکثریت قابل توجهی از ترافیک آن اکنون از آن استفاده می‌کند. Google از زمان شروع آزمایش QUIC در سال ۲۰۱۳، HTTP/3 را از سرویس‌های اصلی خود - Search، YouTube، Gmail - ارائه می‌دهد. Meta HTTP/3 را در زیرساخت Facebook، Instagram و WhatsApp ارائه می‌دهد.

پشتیبانی مرورگر جامع است: Chrome از Chrome 87 (2020)، Firefox از نسخه 88 (2021)، Safari از iOS 15 و macOS Monterey (2021)، و Edge از نسخه 87 از QUIC/HTTP/3 پشتیبانی می‌کند. از سال ۲۰۲۴، بیش از ۹۶٪ از نصب‌های مرورگر در حال استفاده فعال از HTTP/3 پشتیبانی می‌کنند.

داده‌های عملکرد: اعداد واقعاً چه نشان می‌دهند

داده‌های داخلی Google از استقرار QUIC در Search نشان داد که میانگین تأخیر جستجو ۸٪ و در صدک ۹۹ام ۱۳٪ کاهش یافته است. داده‌های YouTube نشان داد که نرخ بافرینگ مجدد در QUIC نسبت به TCP ۱۵٪ کاهش یافته است. این اعداد از ترافیک تولیدی در مقیاس میلیاردها درخواست به دست آمده‌اند، نه شرایط آزمایشگاهی.

تحقیقات Akamai در مورد پذیرش HTTP/3 در CDN خود نشان داد که بهبود میانگین TTFB برای کاربران در اتصالات با تأخیر بالا بین ۱۲ تا ۲۰٪ است. بهبودها به طور مداوم در صدک‌های بالاتر و شرایط شبکه بدتر بیشتر است.

پیاده‌سازی سرور: تیم‌های عملیاتی برای استقرار چه نیاز دارند

HTTP/3 نیاز به باز بودن پورت UDP 443 و یک گواهی TLS دارد. پیاده‌سازی‌های اصلی سرور:

• nginx: پشتیبانی از QUIC در nginx 1.25.0 mainline در سال ۲۰۲۳ ارائه شد.
• Caddy: HTTP/3 از Caddy 2 به طور پیش‌فرض فعال است. هیچ پیکربندی اضافی لازم نیست.
• H2O: پشتیبانی کامل از HTTP/3 از سال ۲۰۲۰ از طریق کتابخانه داخلی quicly.
• LiteSpeed/OpenLiteSpeed: پشتیبانی کامل از HTTP/3، رایج برای پشته‌های میزبانی WordPress.

جایی که HTTP/3 کمکی نمی‌کند

فایروال‌های سازمانی اغلب ترافیک UDP را در پورت ۴۴۳ مسدود یا محدود می‌کنند. در این موارد، مرورگرها به طور خودکار به HTTP/2 روی TCP بازمی‌گردند. تخمین‌ها نشان می‌دهد که ۳ تا ۷٪ از اتصالات به دلیل مسدود شدن UDP نمی‌توانند از HTTP/3 استفاده کنند.

برای اتصالات کوتاه‌مدت در محیط‌های LAN با تأخیر کم، مزایای QUIC ناچیز است. انتقال‌های حجیم با توان بالا در اتصالات قابل اعتماد نیز سود کمی می‌بینند.

تأیید HTTP/3 در سایت شما

هدر پاسخ Alt-Svc را بررسی کنید. یک سرور به درستی پیکربندی شده برمی‌گرداند: alt-svc: h3=":443"; ma=86400

• Chrome DevTools: برگه Network، ستون Protocol را فعال کنید. اتصالات HTTP/3 h3 را نشان می‌دهند.
• curl: curl -I --http3 https://yourdomain.com (نیاز به curl ساخته شده با پشتیبانی QUIC دارد).
• ابزارهای آنلاین: http3check.net هر URL عمومی را برای پشتیبانی HTTP/3 آزمایش می‌کند.

اکنون چه باید کرد

• اگر nginx اجرا می‌کنید، به 1.25.0+ mainline ارتقا دهید و listener QUIC را در کنار listener TCP موجود خود اضافه کنید.
• اگر از Caddy استفاده می‌کنید، HTTP/3 از قبل فعال است - با DevTools تأیید کنید.
• اگر پشت Cloudflare هستید، HTTP/3 را در پنل تنظیمات Speed فعال کنید.
• UDP 443 را در فایروال خود باز کنید اگر در حال حاضر مسدود است.
• سهم پروتکل h3 را در تحلیل خود نظارت کنید. اگر پس از فعال‌سازی زیر ۵٪ باقی ماند، احتمالاً UDP مسدود شده است.