HTTP/3 حالا زیر بیشتر ترافیک وب شما در حال اجراست — اینجا ببینید چه تغییری کرده

HTTP/3 در ژوئن ۲۰۲۲ به عنوان یک استاندارد RFC (RFC 9114) عرضه شد. تا سال ۲۰۲۶، بیش از ۳۰٪ از کل ترافیک وب از آن استفاده می‌کند — از جمله تقریباً تمام ترافیک Google، Cloudflare و Meta. بیشتر توسعه‌دهندگان نمی‌دانند که دارد اجرا می‌شود چون برای لایه application شفاف است. مرورگر به صورت خودکار آن را مذاکره می‌کند، CDN شما بی‌صدا سرویس می‌دهد و کد شما هرگز تغییر نمی‌کند. اینجا ببینید واقعاً چه اتفاقی برای استک پروتکل زیر پایتان افتاده و چرا مهم است.

مشکلی که HTTP/2 حل نکرد — Head-of-Line Blocking

HTTP/2 نسبت به HTTP/1.1 یک بهبود قابل توجه بود. multiplexing را معرفی کرد: چندین درخواست و پاسخ می‌توانند همزمان یک اتصال TCP را به اشتراک بگذارند و دیگر نیازی به باز کردن اتصالات جداگانه برای هر منبع نیست. مرورگری که ۶ منبع را دریافت می‌کند — stylesheet، script، font، تصاویر — می‌تواند همه را از طریق یک اتصال pipeline کند.

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

یعنی: در یک اتصال HTTP/2 با ۶ stream فعال، یک بسته گمشده هر ۶ stream را همزمان مسدود می‌کند — حتی آنهایی که به داده گمشده نیاز ندارند. به این می‌گویند head-of-line blocking در لایه TCP. با ۱٪ packet loss (معمول در شبکه‌های موبایل)، این یک حالت نادر نیست — یک اتفاق معمول است که کل اتصال را در حالی که TCP در حال retransmit است متوقف می‌کند.

HTTP/2 head-of-line blocking را از لایه application (جایی که HTTP/1.1 از آن رنج می‌برد) به لایه transport منتقل کرد. آن را حذف نکرد — فقط جابه‌جا کرد.

QUIC: UDP با مغز

QUIC (Quick UDP Internet Connections) پروتکل حمل و نقلی است که زیر HTTP/3 کار می‌کند. به جای TCP روی UDP اجرا می‌شود. دلیلش معماری است: QUIC مکانیزم تحویل مطمئن خودش را پیاده‌سازی می‌کند، اما این کار را به صورت per-stream انجام می‌دهد نه per-connection.

وقتی بسته‌ای که داده stream 3 را حمل می‌کند گم می‌شود، QUIC آن را دوباره ارسال می‌کند — اما streamهای ۱، ۲، ۴، ۵ و ۶ به کار خود ادامه می‌دهند. مشکل head-of-line blocking ناپدید می‌شود چون QUIC هرگز ترتیب ترتیبی بین streamها تحمیل نمی‌کند. هر stream مستقل است.

QUIC همچنین TLS 1.3 را مستقیماً در handshake اتصال ادغام می‌کند. با HTTPS سنتی روی HTTP/2، ابتدا یک three-way handshake TCP (1 RTT) و سپس یک handshake TLS 1.2 (۱–۲ RTT دیگر) انجام می‌دهید. یعنی ۲–۳ round trip قبل از اینکه اولین بایت داده حرکت کند. QUIC این را جمع می‌کند: یک اتصال جدید QUIC به ۱ RTT برای برقراری نیاز دارد (ترکیب handshake transport و crypto). برای یک جلسه از سر گرفته شده با سرور آشنا، QUIC از حالت 0-RTT پشتیبانی می‌کند — کلاینت داده application را در اولین بسته ارسال می‌کند، قبل از بازگشت هر تأیید handshake.

نتیجه عملی: در یک اتصال با ۵۰ میلی‌ثانیه RTT (لینک معمولی بین قاره‌ای)، HTTP/3 ۵۰–۱۰۰ میلی‌ثانیه در هر راه‌اندازی اتصال جدید نسبت به HTTP/2 روی TLS 1.2 صرفه‌جویی می‌کند. در یک اتصال موبایل با ۱۵۰ میلی‌ثانیه RTT، این صرفه‌جویی به ۱۵۰–۳۰۰ میلی‌ثانیه می‌رسد — قابل توجه برای time-to-first-byte.

Connection Migration: ویژگی قاتل برای موبایل

اتصالات TCP توسط یک 4-tuple شناسایی می‌شوند: source IP, source port, destination IP, destination port. هر عنصری را تغییر دهید، اتصال قطع می‌شود. به همین دلیل است که وقتی از WiFi به شبکه سلولی در گوشی خود سوئیچ می‌کنید، دانلودهای در حال انجام قطع می‌شوند — IP مبدأ شما وقتی بین شبکه‌ها حرکت می‌کند تغییر می‌کند و اتصال TCP از بین می‌رود.

QUIC به جای آن از connection ID استفاده می‌کند. هر اتصال QUIC یک شناسه تصادفی تولید شده دارد که مستقل از مسیر شبکه زیرین است. وقتی گوشی شما از WiFi (192.168.1.5) به 5G (100.73.42.18) تغییر مسیر می‌دهد، connection ID QUIC معتبر باقی می‌ماند. سرور همان connection ID را در IP جدید تشخیص می‌دهد و اتصال بدون وقفه زنده می‌ماند.

این ویژگی — connection migration — یک بهینه‌سازی جزئی نیست. برای کاربران موبایل که در حین حرکت ویدیو استریم می‌کنند، مسیریابی می‌کنند یا از اپلیکیشن‌ها استفاده می‌کنند، تفاوت بین تداوم یکپارچه و یک اتصال قطع شده است که نیاز به اتصال مجدد کامل و handshake دوباره دارد. HTTP/2 روی TCP نمی‌تواند این کار را بدون منطق از سرگیری جلسه در سطح application انجام دهد؛ QUIC به طور خودکار در لایه transport آن را مدیریت می‌کند.

Benchmarkها چه نشان می‌دهند

داده‌های عملکرد از استقرارهای بزرگ مقیاس سازگار است:

• مطالعات داخلی Google کاهش ۳٪ در تأخیر جستجو برای کاربران در HTTP/3 نسبت به HTTP/2 نشان داد. این عدد کوچک به نظر می‌رسد تا زمانی که مقیاس Google را در نظر بگیرید: ۳٪ در میلیاردها جستجو عظیم است.
• Cloudflare بهبود ۱۲٪ در time-to-first-byte (TTFB) برای ترافیک جهانی سرویس شده روی HTTP/3 نسبت به HTTP/2 گزارش می‌دهد، که در سراسر شبکه آنها اندازه‌گیری شده است.
• Meta (Facebook) کاهش ۸٪ در نرخ خطای درخواست پس از راه‌اندازی HTTP/3 مستند کرده است که عمدتاً به کاهش شکست اتصال در شبکه‌های موبایل نسبت داده می‌شود.

این سودها با شرایط شبکه مقیاس می‌شوند. در یک اتصال سیمی پایدار با packet loss نزدیک به صفر، تفاوت‌ها ناچیز است. مزایای پروتکل در شرایط نامطلوب ترکیب می‌شوند:

• در محیط‌های 4G با ۲٪ packet loss، HTTP/3 تا ۴۰٪ بارگذاری سریع‌تر صفحه نسبت به HTTP/2 ارائه می‌دهد.
• در اتصالات ماهواره‌ای (تأخیر بالا، packet loss متوسط)، از سرگیری 0-RTT و تحویل مستقل stream بهبودهای قابل اندازه‌گیری نسبت به پروتکل‌های مبتنی بر TCP فراهم می‌کند.
• اتصال‌پذیری در مناطق روستایی و جهان در حال توسعه — که با تأخیر متغیر و نرخ تلفات بالاتر مشخص می‌شود — به طور نامتناسبی از طراحی QUIC بهره می‌برد.

الگو واضح است: HTTP/3 در جایی که شبکه بدترین است بیشترین ارزش را دارد. با توجه به اینکه بیشتر رشد جهانی وب از کاربران موبایل در مناطق با تأخیر بالا می‌آید، این دقیقاً tradeoff درستی است.

چطور چک کنید که الان روی HTTP/3 هستید

در Chrome، DevTools را باز کنید (F12)، به تب Network بروید، روی header ستون‌ها کلیک راست کنید و ستون "Protocol" را فعال کنید. صفحه را ریلود کنید. هر درخواستی که h3 در آن ستون نشان دهد، روی HTTP/3 سرویس می‌شود. درخواست‌ها به دامنه‌های Google، سایت‌های proxy شده توسط Cloudflare و بیشتر endpointهای CDN بزرگ معمولاً h3 را نشان می‌دهند.

از خط فرمان، curl با یک flag از HTTP/3 پشتیبانی می‌کند:

curl -sI --http3 https://example.com

اگر هدرهای پاسخ شامل alt-svc: h3=":443" باشند، سرور پشتیبانی HTTP/3 را اعلام می‌کند. مرورگرها از این هدر Alt-Svc برای کشف اینکه HTTP/3 در دسترس است استفاده می‌کنند — در اولین بازدید از طریق HTTP/2 وصل می‌شوند، اعلام Alt-Svc را می‌بینند و در اتصالات بعدی به HTTP/3 سوئیچ می‌کنند.

همچنین می‌توانید از مجموعه nghttp2 یا افزونه‌های مرورگر مانند HTTP/2 and SPDY Indicator برای ممیزی اینکه کدام نسخه پروتکل برای هر اتصالی فعال است استفاده کنید.

برای استقرار HTTP/3 چه نیاز دارید

الزامات سمت سرور به استک شما بستگی دارد:

• nginx: نسخه ۱.۲۵+ که با --with-http_quic_module کامپایل شده است. نیاز به fork OpenSSL سازگار با QUIC (quictls) یا BoringSSL دارد. با listen 443 quic reuseport; در بلوک سرور خود به همراه listener استاندارد TLS فعال کنید.
• Caddy: HTTP/3 به صورت built-in و به طور پیش‌فرض فعال است. نیازی به پیکربندی نیست — خارج از جعبه کار می‌کند.
• Cloudflare, Fastly, AWS CloudFront: در داشبورد فعال کنید. بدون نیاز به تغییرات زیرساختی در مبدأ شما.
• HAProxy: پشتیبانی از 2.6+ برای frontendهای QUIC/HTTP/3 موجود است.

رایج‌ترین مانع استقرار فایروال است. QUIC روی UDP پورت ۴۴۳ اجرا می‌شود. بسیاری از فایروال‌های شرکتی و برخی ISPها ترافیک UDP روی پورت ۴۴۳ را مسدود یا محدود می‌کنند، زیرا از نظر تاریخی فقط TCP دیده‌اند. وقتی UDP 443 مسدود می‌شود، مرورگرها به طور خودکار به HTTP/2 روی TCP fallback می‌کنند — مکانیزم fallback داخلی QUIC این را به خوبی مدیریت می‌کند. اما به این معنی است که بخشی از کاربران شما هرگز از مزایای HTTP/3 بهره نمی‌برند.

قوانین فایروال خود را چک کنید: sudo nmap -sU -p 443 your-domain.com باید open برای UDP برگرداند اگر QUIC قابل دسترسی است.

جایی که HTTP/3 هنوز کم می‌آورد

HTTP/3 بدون tradeoff نیست:

• مشکلات NAT traversal: UDP بدون حالت است و دستگاه‌های NAT که وضعیت اتصال را بر اساس معنای TCP ردیابی می‌کنند ممکن است جریان‌های QUIC را به اشتباه مدیریت کنند. برخی روترهای مصرفی جداول ردیابی اتصال بهینه شده برای TCP دارند که با جلسات طولانی مدت UDP QUIC خوب کار نمی‌کند.
• محدودیت ISP: برخی ISPها ترافیک UDP را بی‌تمایز محدود می‌کنند. این می‌تواند عملکرد QUIC را به روش‌هایی تحت تأثیر قرار دهد که روی TCP تأثیر نمی‌گذارد. این مشکل بیشتر در شبکه‌های موبایل و در برخی مناطق جغرافیایی رایج است.
• سربار حافظه سرور: حفظ وضعیت اتصال QUIC — شامل زمینه رمزنگاری، جدول‌های stream و نگاشت‌های connection ID — حافظه بیشتری در هر اتصال نسبت به TCP مصرف می‌کند. در تعداد اتصال بسیار بالا، این می‌تواند در سرورهای مبدأ نگران‌کننده باشد.
• حملات replay 0-RTT: حالت از سرگیری 0-RTT، اگرچه سریع است، در برابر حملات replay بر روی درخواست‌های غیر idempotent آسیب‌پذیر است. مهاجمی که یک بسته 0-RTT را ضبط کند می‌تواند آن را دوباره پخش کند تا همان درخواست را دوباره راه‌اندازی کند. سرورها باید یا 0-RTT را برای درخواست‌های غیر GET رد کنند یا مکانیزم‌های ضد replay پیاده‌سازی کنند. اکثر پیاده‌سازی‌ها به طور پیش‌فرض این را به درستی مدیریت می‌کنند، اما برای استقرارهای سفارشی QUIC یک ملاحظه است.
• قابلیت مشاهده: QUIC هدرهای بیشتری نسبت به TCP رمزگذاری می‌کند که دیباگ در سطح بسته و نظارت شبکه را پیچیده‌تر می‌کند. ابزارهایی مانند Wireshark از رمزگشایی QUIC با کلیدهای جلسه پشتیبانی می‌کنند، اما دید عملیاتی نیاز به راه‌اندازی بیشتری نسبت به پروتکل‌های مبتنی بر TCP دارد.

HTTP/3 در حال حاضر برای شما کار می‌کند — سؤال این است که آیا زیرساخت شما اجازه می‌دهد به خوبی که باید کار کند. قوانین فایروال UDP 443 خود را چک کنید، تأیید کنید که CDN شما HTTP/3 را فعال کرده است و به هدرهای Alt-Svc سرور خود نگاه کنید. پروتکل وجود دارد؛ سودها واقعی هستند؛ اصطکاک استقرار نسبت به دو سال پیش کمتر است. بیشتر وب بدون اعلام رسمی تغییر را انجام داده است.