اچتیتیپی/۳ اکنون یک سوم وب را حمل میکند — و کوئیک تازه شروع به کار کرده است

بر اساس دادههای HTTP Archive و بررسی سالانه Cloudflare، حدود ۳۰٪ از کل ترافیک وب اکنون از طریق HTTP/3 منتقل میشود. گوگل بیش از ۹۰٪ از درخواستهای خود — جستجو، یوتیوب، جیمیل — را از طریق QUIC ارائه میدهد. متا نیز بخش عمدهای از ترافیک CDN خود را به همین روش مسیریابی میکند. Fastly، Cloudflare و AWS CloudFront همگی HTTP/3 را به صورت پیشفرض فعال کردهاند. این دیگر یک پروتکل آزمایشی نیست. این پروتکل، حملونقل پیشفرض برای بزرگترین سایتها وب است و سهم ترافیکی آن هر سال حدود ۳ تا ۵ واحد درصد رشد میکند.

مشکلی که HTTP/2 حلنکرده باقی گذاشت

HTTP/2 در سال ۲۰۱۵ آمد و یک مشکل واقعی را حل کرد: مسدود شدن سر خط در لایه کاربرد HTTP/1.1، جایی که یک پاسخ کند باعث توقف همه چیز در پشت خود در همان اتصال میشد. HTTP/2 مالتیپلکسینگ — چند جریان منطقی روی یک اتصال TCP — و فشردهسازی هدر از طریق HPACK را معرفی کرد. زمان بارگذاری صفحه به طور قابل اندازهگیری بهبود یافت، بهویژه در پیوندهای با تأخیر بالا.

اما HTTP/2 همچنان TCP را به عنوان لایه انتقال خود حفظ کرد و TCP مشکل مسدود شدن سر خط خود را دارد که مالتیپلکسینگ نمیتواند آن را برطرف کند. TCP تحویل مرتب را تضمین میکند: اگر یک قطعه از دست برود، تمام قطعات بعدی — حتی آنهایی که به جریانهای کاملاً مستقل HTTP/2 تعلق دارند — باید منتظر بازفرستادن قطعه گمشده بمانند تا TCP آنها را به برنامه تحویل دهد. در یک اتصال با ۱٪ از دست رفتن بسته، این میتواند چندین جریان مستقل منابع را همزمان متوقف کند. در یک شبکه موبایل با ۲–۳٪ از دست رفتن بسته (معمول برای LTE در لبه پوشش)، تأثیر تأخیر به شدت تشدید میشود.

دست دادن TLS دومین مشکل بود. HTTP/2 روی TLS 1.2 به ۲ دور رفت و برگشت (RTT) قبل از جریان یافتن داده کاربردی نیاز داشت — یکی برای SYN/SYN-ACK/ACK TCP، دیگری برای مذاکره TLS. در یک اتصال موبایل با RTT 80 میلیثانیه، این یعنی ۱۶۰ میلیثانیه سربار راهاندازی قبل از اولین بایت محتوا. TLS 1.3 این را به ۱-RTT کاهش داد، اما دست دادن سه طرفه خود TCP همچنان غیرقابل اجتناب بود. انتقال اتصال — آنچه وقتی از وایفای به سلولار میروید اتفاق میافتد — به این معنی بود که اتصالات TCP قطع شده و باید از ابتدا دوباره شروع میشدند.

QUIC واقعاً چیست

QUIC یک پروتکل انتقال است که روی UDP اجرا میشود. این پروتکل توسط گوگل در سال ۲۰۱۲ طراحی شد، در حدود سال ۲۰۱۳ به صورت داخلی مستقر شد و توسط IETF در می ۲۰۲۱ به عنوان RFC 9000 استاندارد شد. HTTP/3 (RFC 9114) صرفاً سمنتیک HTTP است که به جای TCP روی QUIC لایهبندی شده است.

تصمیمات کلیدی معماری در QUIC:

• مالتیپلکسینگ مبتنی بر UDP با جریانهای مستقل: QUIC مالتیپلکسینگ جریان را در لایه انتقال پیادهسازی میکند، نه لایه کاربرد. هر جریان کنترل جریان و بازیابی از دست رفتن خود را دارد. یک بسته گمشده فقط بر جریانی که به آن تعلق دارد تأثیر میگذارد — جریانهای دیگر بدون وقفه به تحویل داده ادامه میدهند. این مسدود شدن سر خط TCP در سطح انتقال را از بین میبرد.
• TLS 1.3 یکپارچه: QUIC TLS را روی لایه انتقال لایهبندی نمیکند؛ TLS 1.3 بخش جداییناپذیری از پروتکل است. دست دادن و مذاکره رمزگذاری همزمان با برقراری اتصال انجام میشود. یک اتصال جدید QUIC به ۱-RTT قبل از جاری شدن داده کاربردی نیاز دارد — یک دور رفت و برگشت کمتر از TLS 1.2 روی TCP.
• ازسرگیری اتصال ۰-RTT: وقتی یک کلاینت دوباره به سروری که قبلاً با آن ارتباط داشته وصل میشود، QUIC میتواند با اولین بسته با استفاده از حالت ۰-RTT داده کاربردی ارسال کند. کلاینت از دادههای بلیط نشست از اتصال قبلی برای رمزگذاری فوری درخواست استفاده میکند. در یک اتصال مجدد موبایل معمولی — جابهجایی بین وایفای و سلولار — این بدان معناست که اولین درخواست HTTP میتواند قبل از تکمیل دست دادن ارسال شود و تأخیر درک شده برای بازدیدهای مکرر را تقریباً به صفر برساند.
• انتقال اتصال: QUIC اتصالات را با یک شناسه اتصال ۶۴ بیتی شناسایی میکند، نه یک ۴تایی از آدرسهای IP و پورتها. وقتی دستگاه شما آدرس IP خود را تغییر میدهد — از وایفای به ۵G یا جابهجایی بین دکلهای سلولار — اتصال QUIC بدون وقفه ادامه مییابد. بدون بازنشانی TCP، بدون دست دادن جدید، بدون جریان افتاده. سرور بستهها را از آدرس IP جدید با همان شناسه اتصال دریافت کرده و به طور یکپارچه ادامه میدهد.

شواهد عملکرد: اعداد چه میگویند

بهبود عملکرد از QUIC در دو شرایط بیشتر نمایان است: از دست رفتن بسته بالا و انتقالهای مکرر شبکه. گوگل نتایج تست A/B داخلی را منتشر کرد که نشان داد QUIC تأخیر جستجو را ۸٪ در میانه و تا ۲۸٪ در صدک ۹۹ام (تأخیر دم) در مقایسه با HTTPS روی TCP کاهش داده است. دادههای QUIC یوتیوب کاهش ۱۵٪ در رویدادهای بافر کردن مجدد را نشان داد.

معیارهای Cloudflare در سال ۲۰۲۳ برای HTTP/3 در مقابل HTTP/2 روی یک شبکه شبیهسازیشده با ۱٪ از دست رفتن بسته، بهبود زمان بارگذاری صفحه میانه را ۱۲–۱۸٪ برای صفحات پرمصرف نشان داد. در ۳٪ از دست رفتن بسته — واقعگرایانه برای شبکههای موبایل شلوغ — بهبود به ۲۵–۳۵٪ افزایش یافت. در یک اتصال تمیز با تأخیر کم و ۰٪ از دست رفتن بسته، تفاوت عملکرد بین HTTP/2 و HTTP/3 کوچک است (زیر ۵٪)، زیرا مسدود شدن سر خط TCP فقط زمانی ظاهر میشود که قطعات از دست بروند.

مزیت ازسرگیری ۰-RTT جداسازی سختتر اما قابل اندازهگیری است. متا گزارش داد که فعالسازی ۰-RTT برای بازدیدکنندگان بازگشتی در CDN خود، زمان تا اولین بایت (TTFB) را ۳۰–۶۰ میلیثانیه در اتصالات موبایل کاهش داده است که مستقیماً به نمرات سریعتر Largest Contentful Paint (LCP) ترجمه میشود — Core Web Vital که بیشترین همبستگی را با تجربه کاربری و رتبهبندی جستجوی گوگل دارد.

یک نکته: ۰-RTT دارای آسیبپذیری پخش مجدد است. یک مهاجم که داده ۰-RTT را ضبط میکند میتواند آن را پخش مجدد کرده و درخواستهای تکراری ارسال کند. به همین دلیل است که ۰-RTT برای درخواستهای بیتأثیر (GET, HEAD) ایمن است اما باید برای عملیات تغییردهنده وضعیت (POST, پرداختها) غیرفعال یا با دقت مدیریت شود. پیادهسازیهای مدرن سرور این کار را به طور خودکار انجام میدهند، اما ارزش دانستن این محدودیت را دارد.

چه کسانی امروز HTTP/3 را اجرا میکنند

چشمانداز پذیرش تا اواسط ۲۰۲۶ قابل توجه است:

• Cloudflare: HTTP/3 از سال ۲۰۲۰ به صورت پیشفرض برای همه مشتریان فعال است. Cloudflare همچنین یکی از پرکاربردترین پیادهسازیهای QUIC (quiche) را اداره میکند که متنباز است و توسط فایرفاکس و پروژههای دیگر استفاده میشود.
• Google: QUIC را به صورت داخلی برای جستجو، یوتیوب، جیمیل، گوگل درایو و Maps اجرا میکند. مرورگر کروم از سال ۲۰۱۵ از QUIC پشتیبانی میکند. پیادهسازی QUIC گوگل (quic-go و cronet C++) پیادهسازی مرجع برای بخش بزرگی از اکوسیستم است.
• Meta: HTTP/3 را برای ترافیک CDN فیسبوک، اینستاگرام و واتساپ اجرا میکند. متا پیادهسازی QUIC خود را (mvfst) نگهداری میکند که در سال ۲۰۱۹ متنباز شد و در مقیاس میلیاردها کاربر در تولید استفاده میشود.
• Fastly, Akamai, AWS CloudFront: همه HTTP/3 را به عنوان گزینه CDN ارائه میدهند، فستلی از سال ۲۰۲۲ آن را به صورت پیشفرض فعال کرده است.

در سمت نرمافزار سرور: nginx پشتیبانی QUIC/HTTP/3 را در نسخه v1.25.0 (ژوئن ۲۰۲۳) به عنوان یک ویژگی پایدار اضافه کرد. Caddy از نسخه v2.4 HTTP/3 را به صورت پیشفرض فعال کرده است. LiteSpeed و نسخه متنباز آن OpenLiteSpeed از سال ۲۰۲۰ پشتیبانی HTTP/3 را دارند. Apache httpd HTTP/3 را از طریق ماژول mod_quic ارائه میدهد که تا Apache 2.4.55 همچنان آزمایشی است. سرور H2O پشتیبانی QUIC را دارد. Node.js یک API QUIC آزمایشی دارد. زمان اجرای Deno به صورت بومی از HTTP/3 پشتیبانی میکند.

توسعهدهندگان وب چه باید بکنند

برای اکثر توسعهدهندگانی که از CDN یا بالانسر بار ابری استفاده میکنند، HTTP/3 از قبل فعال است — آن را تأیید کنید، فعالش نکنید. اگر زیرساخت سرور خود را مدیریت میکنید، مسیر عملی در اینجا آمده است:

HTTP/3 فعال است را تأیید کنید:

• از curl --http3 https://yourdomain.com -I استفاده کنید و HTTP/3 را در خط پاسخ بررسی کنید. نیاز به curl ساخته شده با پشتیبانی QUIC دارد (curl --version | grep HTTP3).
• در Chrome DevTools: پنل Network را باز کنید، روی سرستونها کلیک راست کنید، "Protocol" را فعال کنید. اتصالات HTTP/3 به صورت h3 نمایش داده میشوند. HTTP/2 به صورت h2.
• Firefox DevTools همین را در ستون Protocol پنل Network نشان میدهد.
• بررسی کننده quic.cloud Cloudflare و ابزار http3check.net تأیید خارجی سریع ارائه میدهند.

فعالسازی HTTP/3 روی nginx (1.25+): listen 443 quic reuseport; را در کنار دستور listen 443 ssl; موجود اضافه کنید، سپس add_header Alt-Svc 'h3=":443"; ma=86400'; را برای اعلام QUIC به مرورگرها اضافه کنید. هدر Alt-Svc روشی است که کلاینتها متوجه میشوند HTTP/3 در دسترس است — اولین اتصال از HTTP/2 استفاده خواهد کرد و اتصالات بعدی به HTTP/3 ارتقا مییابند.

فعالسازی HTTP/3 روی Caddy: چیزی برای پیکربندی وجود ندارد — Caddy وقتی TLS فعال باشد، HTTP/3 را به صورت پیشفرض فعال میکند. از طریق ستون Protocol در DevTools تأیید کنید.

پیکربندی فایروال یک مانع رایج است: QUIC روی پورت UDP 443 اجرا میشود. بسیاری از فایروالهای شرکتی ترافیک UDP را مسدود یا محدود میکنند. اگر HTTP/3 نتواند مذاکره کند، مرورگرها به طور خودکار به HTTP/2 بازمیگردند — کاربران نهایی هیچ خطایی نمیبینند، اما از QUIC هم بهرهمند نمیشوند. اگر در حال رفع اشکال عدم استفاده HTTP/3 در یک شبکه خاص هستید، بررسی کنید که UDP/443 باز است.

هنوز کنترل ازدحام QUIC را به صورت دستی تنظیم نکنید. پیادهسازیهای QUIC به طور پیشفرض از کنترل ازدحام BBR (پهنای باند گلوگاه و RTT) استفاده میکنند که در اکثر شبکههای مدرن از CUBIC (پیشفرض TCP) بهتر عمل میکند. مگر اینکه مشکلات عملکرد اندازهگیریشده خاصی داشته باشید، پیشفرضها درست هستند.

0-RTT: اکثر پیادهسازیهای سرور 0-RTT را برای درخواستهای GET به طور خودکار فعال میکنند. اگر برنامه شما عملیات تغییردهنده وضعیت را در بارگذاری صفحه صادر میکند (غیر معمول اما ممکن است)، آن نوع درخواستها را ممیزی کنید. راهنمایی استاندارد این است که داده 0-RTT را به عنوان قابل پخش مجدد در نظر بگیرید و بر این اساس طراحی کنید — از توکنهای بیتأثیر استفاده کنید یا وضعیت لایه کاربرد را بررسی کنید.

راه پیش رو

HTTP/3 و QUIC هنوز در حال تکامل هستند. QUIC نسخه ۲ (RFC 9369، منتشر شده در ۲۰۲۳) بهبودهایی در انتقال اتصال و یک مکانیسم جدید مذاکره نسخه اضافه میکند. WebTransport — یک API مرورگر که جریانها و دیتاگرامهای QUIC را مستقیماً در معرض جاوااسکریپت قرار میدهد — در کروم و فایرفاکس در حال عرضه است و ارتباط دوطرفه با تأخیر کم را بدون سربار WebSocket ممکن میسازد. MASQUE (Multiplexed Application Substrate over QUIC Encryption)، یک پروتکل گروه کاری IETF، تونلزنی مشابه VPN را روی QUIC میسازد و در iCloud Private Relay مستقر شده است.

برای توسعهدهنده وب که TCP و HTTP را میشناسد، QUIC همان مشکل است که به درستی حل شده است: تحویل قابل اعتماد و مرتب در جایی که لازم است (به ازای هر جریان)، بدون محدودیت نظمدهی سراسری که TCP را در لینکهای پراتلاف بیمار میکند. پروتکل پایدار است، ابزارها وجود دارند و شواهد عملکرد واضح است. اگر ترافیک شما از طریق یک CDN مدرن اجرا میشود، کاربران شما در حال حاضر بهرهمند هستند. اگر اینطور نیست، مسیر ارتقا یک خط پیکربندی nginx است.