HTTP/2 و HTTP/3 (QUIC) چیست و چرا در برخی شبکه‌ها کار نمی‌کند؟

HTTP چیست و چرا نسخه‌هایش مهم است؟

HTTP زبان مشترک مرورگر و وب‌سرور است: مرورگر درخواست می‌دهد («صفحهٔ اصلی را بده»، «این تصویر را بده») و سرور پاسخ می‌دهد. یک صفحهٔ وب امروزی ده‌ها تا صدها فایل دارد: HTML، CSS، جاوااسکریپت، تصاویر، فونت‌ها. نحوهٔ ارسال این درخواست‌ها و پاسخ‌ها، روی سرعت بارگذاری اثر مستقیم دارد.

نسخهٔ قدیمی و هنوز رایج HTTP/1.1 دهه‌ها پیش طراحی شد؛ زمانی که صفحات چند فایل بیشتر نداشتند. HTTP/2 و HTTP/3 برای حل محدودیت‌های آن در وب مدرن ساخته شدند. خبر خوب این است که برای استفاده از آن‌ها نیازی به تغییر در کد سایت نیست؛ فقط وب‌سرور یا CDN باید آن‌ها را پشتیبانی کند.

پشتهٔ سه نسخهٔ HTTP

HTTP/1.1یک درخواست در هر لحظه روی هر اتصال TCP

HTTP/2چندگانه‌سازی روی یک اتصال TCP با TLS

HTTP/3جریان‌های مستقل روی QUIC و UDP با TLS 1.3

محدودیت HTTP/1.1

در HTTP/1.1، روی هر اتصال در هر لحظه فقط یک درخواست پاسخ می‌گیرد و درخواست بعدی باید منتظر بماند. مرورگرها برای جبران، چند اتصال موازی به هر دامنه باز می‌کنند، اما تعدادشان محدود است. نتیجه این‌که در صفحه‌ای با صد فایل، بسیاری از درخواست‌ها در صف می‌مانند. به این پدیده Head-of-Line Blocking (مسدود شدن سر صف) می‌گویند. علاوه بر این، هدرهای هر درخواست (مثل کوکی‌ها و User-Agent) هر بار کامل و بدون فشرده‌سازی ارسال می‌شوند.

HTTP/2: چندگانه‌سازی روی یک اتصال

HTTP/2 این مشکلات را با چند ایده حل می‌کند:

• Multiplexing (چندگانه‌سازی): همهٔ درخواست‌ها و پاسخ‌ها به قطعه‌های کوچک تقسیم و هم‌زمان روی یک اتصال ارسال می‌شوند. دیگر لازم نیست درخواستی منتظر تمام شدن درخواست قبلی بماند.
• فشرده‌سازی هدرها (HPACK): هدرهای تکراری فقط یک بار کامل ارسال می‌شوند.
• اولویت‌بندی: مرورگر می‌تواند بگوید کدام فایل‌ها مهم‌ترند (مثلاً CSS پیش از تصاویر).
• فقط روی HTTPS: مرورگرها HTTP/2 را فقط روی اتصال رمزنگاری‌شده پشتیبانی می‌کنند؛ پس داشتن گواهی SSL پیش‌نیاز است. دربارهٔ SSL در SSL چیست؟ بخوانید.

یک محدودیت باقی ماند: HTTP/2 روی TCP اجرا می‌شود. TCP تضمین می‌کند داده‌ها به ترتیب برسند؛ اگر یک بسته در شبکه گم شود، همهٔ داده‌های بعدی روی آن اتصال، حتی مربوط به فایل‌های دیگر، منتظر ارسال مجدد آن بسته می‌مانند. روی شبکه‌های پرتلفات مثل موبایل، این مسئله محسوس است.

HTTP/2 در برابر HTTP/3

HTTP/2

• روی TCP
• گم‌شدن یک بسته همه را معطل می‌کند
• در همهٔ شبکه‌ها کار می‌کند
• پشتیبانی گسترده

در برابر

HTTP/3

• روی QUIC و UDP
• جریان‌های مستقل
• اتصال سریع‌تر و مهاجرت اتصال
• ممکن است در برخی شبکه‌ها مسدود باشد

HTTP/3 و QUIC

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

• جریان‌های مستقل: گم‌شدن یک بسته فقط همان فایل را معطل می‌کند، نه همه را.
• برقراری سریع‌تر اتصال: دست‌دهی رمزنگاری و انتقال در هم ادغام شده‌اند و برای سایتی که قبلاً بازدید شده، اتصال می‌تواند با رفت‌وبرگشت کمتری شروع شود.
• مهاجرت اتصال: اگر گوشی از وای‌فای به اینترنت همراه برود و آی‌پی عوض شود، اتصال QUIC می‌تواند ادامه پیدا کند.
• رمزنگاری اجباری با TLS 1.3.

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

HTTP/3 از UDP روی پورت 443 استفاده می‌کند. بسیاری از شبکه‌ها، فایروال‌های سازمانی و برخی اپراتورها ترافیک UDP را محدود، کند یا کاملاً مسدود می‌کنند؛ چون تاریخچهٔ وب بر TCP بنا شده است و UDP بیشتر برای کاربردهای دیگر استفاده می‌شد. در شبکه‌های ایران هم رفتار UDP روی پورت 443 بسته به اپراتور و زمان، ممکن است متفاوت باشد.

نکتهٔ مهم این است که این موضوع دسترسی به سایت را قطع نمی‌کند. مرورگر ابتدا با HTTP/2 روی TCP وصل می‌شود؛ سرور در هدر Alt-Svc اعلام می‌کند که HTTP/3 هم پشتیبانی می‌کند و مرورگر در درخواست‌های بعدی آن را امتحان می‌کند. اگر UDP مسدود باشد، مرورگر بی‌صدا روی HTTP/2 می‌ماند. بنابراین فعال‌سازی HTTP/3 در بدترین حالت بی‌اثر است.

فعال‌سازی HTTP/2 در Nginx

در نسخه‌های جدید Nginx، کافی است دستور زیر را در بلوک server که روی 443 گوش می‌دهد اضافه کنید:

server {
    listen 443 ssl;
    http2 on;
    server_name example.com;
    # ssl_certificate ...
}

در نسخه‌های قدیمی‌تر، به‌جای آن از listen 443 ssl http2; استفاده می‌شد. پس از تغییر، nginx -t && systemctl reload nginx را اجرا کنید. ساختار فایل‌های Nginx در مبانی پیکربندی Nginx آمده است.

فعال‌سازی HTTP/3 در Nginx

Nginx از نسخهٔ ۱.۲۵ به بعد از HTTP/3 پشتیبانی می‌کند، به شرطی که با ماژول مربوطه ساخته شده باشد. نمونهٔ تنظیم:

server {
    listen 443 ssl;
    listen 443 quic reuseport;
    http2 on;
    http3 on;
    add_header Alt-Svc 'h3=":443"; ma=86400';
    ssl_protocols TLSv1.2 TLSv1.3;
}

فراموش نکنید پورت 443 را برای UDP هم در فایروال باز کنید (ufw allow 443/udp). اگر سایت پشت CDN است، کار ساده‌تر است: بیشتر CDNها HTTP/2 و HTTP/3 را در لبهٔ شبکه فعال می‌کنند و ارتباط CDN با سرور شما همچنان می‌تواند HTTP/1.1 یا HTTP/2 باشد.

ارتقای خودکار به HTTP/3

بررسی پروتکل فعال

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

curl -sI --http2 https://example.com | head -1
curl -sI https://example.com | grep -i alt-svc

آیا ارتقا به HTTP/2 و HTTP/3 ارزش دارد؟

بله؛ هزینهٔ آن تقریباً صفر است و برای صفحاتی با فایل‌های زیاد، به‌ویژه روی شبکه‌های موبایل، بهبود قابل لمسی ایجاد می‌کند. اما جادو نمی‌کند: اگر سرور کند است یا تصاویر سنگین‌اند، پروتکل جدید مشکل را حل نمی‌کند. فشرده‌سازی (Gzip و Brotli)، کش و CDN را هم فراموش نکنید.

چند ترفند قدیمی که دیگر لازم نیست

در دوران HTTP/1.1، توسعه‌دهندگان برای دور زدن محدودیت تعداد اتصال، ترفندهایی به کار می‌بردند: ترکیب همهٔ فایل‌های CSS و JS در یک فایل بزرگ، چسباندن آیکون‌ها در یک تصویر بزرگ (Sprite) و پخش فایل‌ها روی چند زیردامنه (Domain Sharding). با HTTP/2، این ترفندها بیشتر ضرر دارند تا فایده. به‌ویژه Domain Sharding باعث می‌شود مرورگر به‌جای یک اتصال کارآمد، چند اتصال جداگانه با دست‌دهی‌های اضافه باز کند. اگر سایت قدیمی دارید، پس از فعال‌سازی HTTP/2 این ترفندها را بازبینی کنید.

HTTP/3 و CDN: چه کسی باید آن را فعال کند؟

اگر سایت شما پشت CDN است، کاربر در واقع با لبهٔ CDN گفت‌وگو می‌کند، نه مستقیم با سرور شما. بنابراین پروتکلی که مرورگر می‌بیند، همان پروتکلی است که CDN پشتیبانی می‌کند. در این حالت، فعال‌سازی HTTP/3 روی سرور مبدأ تأثیر چندانی بر تجربهٔ کاربر ندارد و مهم‌تر این است که اتصال بین CDN و مبدأ پایدار و امن باشد. در عمل بسیاری از مدیران سایت ترجیح می‌دهند مبدأ را روی HTTP/1.1 یا HTTP/2 با TLS نگه دارند و پروتکل‌های جدید را به لبهٔ CDN بسپارند؛ چون لبه‌ها برای مدیریت تعداد زیادی اتصال هم‌زمان طراحی شده‌اند و تنظیمات UDP و فایروال را خودشان مدیریت می‌کنند.

اگر سایت شما مستقیماً به کاربران سرویس می‌دهد، HTTP/2 را حتماً فعال کنید؛ هزینه‌ای ندارد و تقریباً همهٔ مرورگرها از آن پشتیبانی می‌کنند. HTTP/3 را وقتی اضافه کنید که نسخهٔ Nginx شما آن را به‌طور پایدار پشتیبانی می‌کند، پورت UDP 443 در فایروال باز است و بتوانید رفتار سایت را پس از تغییر پایش کنید. یک قاعدهٔ ساده: همیشه HTTP/2 را به‌عنوان پشتیبان فعال نگه دارید تا اگر مسیر UDP در شبکهٔ کاربری مسدود یا ناپایدار بود، مرورگر بی‌دردسر به نسخهٔ قبلی برگردد.

اثر واقعی را چطور بسنجیم؟

پیش از و پس از تغییر، چند صفحهٔ مهم سایت را با ابزار توسعه‌دهندهٔ مرورگر بررسی کنید. در تب Network ستون Protocol را فعال کنید تا ببینید هر درخواست با h2 یا h3 بارگذاری شده است. سپس زمان بارگذاری کامل و زمان نمایش اولین محتوا را در چند نوبت و از چند شبکهٔ مختلف (اینترنت خانگی و اینترنت همراه) مقایسه کنید. بیشترین بهبود معمولاً در شبکه‌های همراه و پرنوسان دیده می‌شود، جایی که از دست رفتن بسته‌ها رایج‌تر است. اگر تفاوتی نمی‌بینید، احتمالاً گلوگاه جای دیگری است: تصاویر بزرگ، اسکریپت‌های سنگین یا پاسخ کند سرور. در این صورت سراغ بهینه‌سازی محتوا و کش بروید.

سؤالات متداول