HTTP/3 چه چیزی را سریع‌تر می‌کند؟ راهنمای عملی مالتی‌پلکسینگ

وب‌سایت شما روی HTTP/2 است، ولی TTFB هنوز بالا است

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

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

مالتی‌پلکسینگ در HTTP/2 چطور کار می‌کند و کجا می‌شکند

HTTP/1.1 برای هر درخواست یک اتصال TCP جدا باز می‌کرد. مرورگرها مجبور بودند ۶ اتصال موازی بسازند و هر اتصال یک فایل را در یک زمان منتقل می‌کرد. HTTP/2 این را با مالتی‌پلکسینگ حل کرد: یک اتصال TCP واحد، چندین stream همزمان. تصویر زیر را در نظر بگیرید: یک لوله‌ی بزرگ که چندین بسته‌ی کوچک را همزمان از آن عبور می‌دهید.

این راه‌حل یک نقطه‌ی شکست دارد. TCP تضمین می‌کند که بسته‌ها به ترتیب برسند. اگر بسته‌ی شماره ۳ گم شود، بسته‌های ۴، ۵ و ۶ که رسیده‌اند، در بافر می‌مانند تا بسته‌ی ۳ دوباره ارسال شود. حالا تصور کنید در همان لوله، stream مربوط به CSS شما و stream مربوط به تصویر hero هر دو پشت بسته‌ی گم‌شده معطل شده‌اند. این همان head-of-line blocking است و دقیقاً همان چیزی است که HTTP/2 را در شبکه‌های ناپایدار کند می‌کند.

نکته‌ی مهم: در شبکه‌های پایدار با پکت‌لاس نزدیک به صفر، این اتفاق به ندرت می‌افتد. در دیتاسنتر یا فیبر شهری با کیفیت، HTTP/2 و HTTP/3 تقریباً هم‌سرعت هستند. مشکل وقتی شروع می‌شود که کاربر از موبایل با وای‌فای ضعیف یا شبکه‌ی همراه با نوسان وارد می‌شود.

این‌جا اشتباه می‌کنند: تست روی شبکه‌ی پایدار

توسعه‌دهنده HTTP/3 را روی سرور فعال می‌کند، با لپ‌تاپ متصل به فیبر اداری تست می‌گیرد و نتیجه را «بدون تغییر» می‌بیند. بعد نتیجه می‌گیرد که HTTP/3 بی‌فایده است و آن را غیرفعال می‌کند. این اشتباه رایج است. تست باید از یک شبکه‌ی همراه با سینگال ضعیف یا با شبیه‌ساز شبکه مثل clumsy یا tc netem انجام شود که پکت‌لاس و تأخیر واقعی را شبیه‌سازی کند. دستور زیر روی لینوکس ۵٪ پکت‌لاس و ۱۰۰ms تأخیر اضافه می‌کند:

sudo tc qdisc add dev eth0 root netem loss 5% delay 100ms

بعد از تست، حذفش کنید:

sudo tc qdisc del dev eth0 root

HTTP/3 چه چیزی را متفاوت انجام می‌دهد

HTTP/3 روی UDP سوار می‌شود، نه TCP. پروتکل زیرین آن QUIC است که توسط Google طراحی شده و حالا RFC 9000 است. QUIC سه کار اساسی انجام می‌دهد که TCP نمی‌تواند:

• حذف head-of-line blocking در سطح اتصال: هر stream در QUIC مستقل است. اگر بسته‌ای در stream شماره ۱ گم شود، streamهای ۲ و ۳ بدون معطلی ادامه می‌یابند.
• کاهش زمان اتصال اولیه: TCP نیاز به یک round-trip برای handshake دارد و TLS هم یک round-trip دیگر. QUIC هر دو را در یک round-trip ترکیب می‌کند. روی اتصال‌های جدید، این یعنی یک RTT صرفه‌جویی؛ روی اتصال‌های تکراری با session resumption، این عدد به صفر می‌رسد.
• تغییر آدرس IP بدون قطع اتصال: گوشی شما از وای‌فای به 4G سوییچ می‌کند، اتصال QUIC با Connection ID ادامه پیدا می‌کند. TCP این کار را نمی‌کند؛ اتصال قطع می‌شود و باید از نو handshake کنید.

نتیجه‌ی این سه مورد یک عدد مشخص است: در شبکه‌ای با ۲٪ پکت‌لاس، بارگذاری صفحه با HTTP/3 معمولاً ۱۵ تا ۳۰ درصد سریع‌تر از HTTP/2 است. در شبکه‌ی پایدار، این عدد به ۲ تا ۵ درصد می‌رسد. این را در گزارش‌های Cloudflare و Fastly می‌بینید و در تست خودتان هم باید ببینید.

چه زمانی تفاوت HTTP/3 محسوس است

همه‌ی سایت‌ها از HTTP/3 سود نمی‌برند. سه شرط باید برقرار باشد:

1. کاربران شما از شبکه‌های همراه استفاده می‌کنند. اگر آنالیتیکس شما نشان می‌دهد که بیش از ۴۰٪ ترافیک موبایل است، HTTP/3 برای شما مهم است.
2. صفحه‌ی شما بیش از ۵۰ درخواست جدا دارد. هرچه streamهای همزمان بیشتر باشد، احتمال برخورد با head-of-line blocking بیشتر است.
3. فایل‌های شما از چند دامنه یا CDN جدا سرو می‌شوند. هر دامنه‌ی جدا یعنی یک اتصال TCP جدا و یک فرصت جدا برای blocking.

اگر سایت شما یک صفحه‌ی ساده با ۱۰ درخواست است و کاربرانش از فیبر شهری وارد می‌شوند، HTTP/3 تفاوت محسوسی ایجاد نمی‌کند. این را صادقانه بگوییم. هزینه‌ی فعال‌سازی کم است، ولی انتظار معجزه نداشته باشید.

مقایسه‌ی مستقیم: HTTP/2 در برابر HTTP/3

یک نکته‌ی فنی دیگر: QUIC از TLS 1.3 به‌صورت داخلی استفاده می‌کند و اجازه‌ی نسخه‌ی قدیمی‌تر را نمی‌دهد. اگر سرور شما TLS 1.2 دارد، HTTP/3 کار نمی‌کند. اول TLS 1.3 را فعال کنید.

فعال‌سازی HTTP/3 روی NGINX

از نسخه‌ی 1.25.0 به بعد، NGINX پشتیبانی رسمی از HTTP/3 دارد. اگر توزیع شما نسخه‌ی قدیمی دارد، باید از مخزن رسمی NGINX استفاده کنید. مراحل به این شکل است:

# در بلاک server خود، این خطوط را اضافه کنید
listen 443 quic reuseport;
listen 443 ssl;
http2 on;
ssl_protocols TLSv1.3;
add_header Alt-Svc 'h3=":443"; ma=86400' always;

خط Alt-Svc به مرورگر می‌گوید که HTTP/3 در دسترس است. بدون این هدر، مرورگر حتی اگر سرور از QUIC پشتیبانی کند، سراغش نمی‌رود. بعد از اعمال تنظیمات، با دستور زیر تست کنید:

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

خروجی باید شامل alt-svc: h3=":443" باشد. اگر خطای --http3 is experimental دیدید، نسخه‌ی curl را ارتقا دهید. نسخه‌ی 8.0 به بالا پشتیبانی کامل دارد.

یک نکته‌ی مهم درباره‌ی UDP: برخی فایروال‌ها و دیتاسنترها پورت 443/UDP را بسته دارند. قبل از فعال‌سازی، از باز بودن آن مطمئن شوید:

nc -u -vz your-server-ip 443

اگر پورت بسته باشد، مرورگر به‌صورت خودکار به HTTP/2 برمی‌گردد، ولی کاربران شما یک RTT اضافی را تجربه می‌کنند چون مرورگر اول تلاش QUIC را می‌کند و بعد از timeout به TCP برمی‌گردد. این سناریو از نداشتن HTTP/3 بدتر است.

چه زمانی HTTP/3 را فعال نکنیم

یک مورد هست که فعال‌سازی HTTP/3 را توصیه نمی‌کنم: اگر زیرساخت شما از یک لودبالانسر قدیمی استفاده می‌کند که QUIC را پاس نمی‌دهد. در این حالت، ترافیک UDP به لودبالانسر می‌رسد و هیچ پاسخی نمی‌گیرد. مرورگر بعد از چند ثانیه به TCP برمی‌گردد و کاربر شما تأخیر بیشتری از حالت عادی تجربه می‌کند.

راه‌حل میانی: هدر Alt-Svc را با مقدار ma=86400 تنظیم کنید و بعد از ۲۴ ساعت، اگر خطایی در لاگ‌ها ندیدید، آن را دائمی کنید. این یک مهاجرت تدریجی امن است.

همچنین اگر از سرویس‌های میزبانی اشتراکی استفاده می‌کنید که کنترل NGINX ندارید، HTTP/3 معمولاً در دسترس نیست. در این حالت، ارتقا به یک سرور مجازی ایران با دسترسی کامل به تنظیمات وب‌سرور، اولین قدم عملی است. بدون دسترسی به کانفیگ سرور، بحث HTTP/3 صرفاً تئوری می‌ماند.

تأثیر HTTP/3 روی سئو و Core Web Vitals

گوگل رسماً اعلام کرده که HTTP/3 یک سیگنال رتبه‌بندی نیست. اما این به معنای بی‌تأثیر بودن آن نیست. LCP (Largest Contentful Paint) که یک متریک اصلی Core Web Vitals است، مستقیماً به سرعت تحویل بزرگ‌ترین عنصر صفحه وابسته است. اگر آن عنصر از یک stream جدا سرو می‌شود و stream دیگری بسته گم کرده باشد، LCP شما بالا می‌رود. HTTP/3 این وابستگی را قطع می‌کند.

در عمل، سایت‌هایی که روی HTTP/3 مهاجرت کرده‌اند، بهبود ۵ تا ۱۵ درصدی در LCP گزارش می‌دهند. این عدد به‌اندازه‌ای است که در رتبه‌بندی موبایل تأثیر غیرمستقیم بگذارد، چون گوگل از تعامل کاربر به‌عنوان سیگنال استفاده می‌کند و کاربرِ سریع‌تر، تعامل بهتری دارد.

ابزارهای اندازه‌گیری و مانیتورینگ

بعد از فعال‌سازی، باید تفاوت را اندازه بگیرید. سه ابزار کاربردی:

• HTTP/3 Check از KeyCDN: یک صفحه‌ی ساده که نشانی سایت شما را می‌گیرد و می‌گوید HTTP/3 فعال است یا نه.
• WebPageTest: در تنظیمات آزمایش، گزینه‌ی HTTP/3 را انتخاب کنید و نتیجه را با حالت عادی مقایسه کنید.
• Chrome DevTools: در تب Network، ستون Protocol را فعال کنید. مقدار h3 یعنی درخواست از QUIC رفته است.

برای مانیتورینگ مستمر، متریک quic_connections را در NGINX استاب‌استاتوس فعال کنید. اگر این عدد صفر ماند، یعنی مرورگرها به HTTP/3 وصل نمی‌شوند و مشکل از هدر Alt-Svc یا فایروال است.

پرسش‌های پرتکرار

آیا HTTP/3 روی همه‌ی مرورگرها کار می‌کند؟

خیر. Safari از نسخه‌ی 16.4 به بعد از HTTP/3 پشتیبانی می‌کند. مرورگرهای قدیمی‌تر به‌صورت خودکار به HTTP/2 برمی‌گردند، پس نگران کاربران با مرورگر قدیمی نباشید. نکته‌ی مهم این است که هدر Alt-Svc را حتماً اضافه کنید تا مرورگرهای مدرن متوجه وجود HTTP/3 شوند.

آیا HTTP/3 امنیت کمتری نسبت به HTTP/2 دارد؟

نه. QUIC از TLS 1.3 به‌صورت اجباری استفاده می‌کند و اجازه‌ی TLS 1.2 یا پایین‌تر را نمی‌دهد. در عمل، HTTP/3 امن‌تر از HTTP/2 است چون ضعیف‌ترین نسخه‌ی TLS را حذف کرده است. تنها نگرانی امنیتی، ترافیک UDP است که برخی فایروال‌ها آن را به‌درستی بازرسی نمی‌کنند.

چطور بفهمم سایت من الان روی HTTP/3 است؟

ساده‌ترین راه: کنسول Chrome را باز کنید (F12)، به تب Network بروید، روی هدر جدول راست‌کلیک کنید و گزینه‌ی Protocol را فعال کنید. اگر مقدار h3 می‌بینید، یعنی سایت شما روی HTTP/3 سرو می‌شود. اگر h2 می‌بینید، هنوز روی HTTP/2 هستید.

آیا HTTP/3 پهنای باند بیشتری مصرف می‌کند؟

بله، حدود ۵ تا ۱۰ درصد بیشتر. QUIC هدرهای بزرگ‌تری نسبت به TCP دارد و برای هر stream جداگانه بسته‌های acknowledgment می‌فرستد. اگر پهنای باند شما محدود است و هزینه‌ی ترافیک برایتان مهم است، این عدد را در محاسباتتان در نظر بگیرید. در پلن‌های نامحدود، این تفاوت ناچیز است.