CH-J Server Managerمدیریت سرور از طریق SSH
منو
همهٔ راهنماها و مقاله‌ها ←

چگونه مطمئن شویم HTTP/3 و QUIC واقعاً کار می‌کنند

چرا سرآیند Alt-Svc اثبات نیست، چه چیزهایی را باید در NGINX و فایروال بررسی کرد و چگونه یک انتقال واقعی QUIC را تأیید کنیم.

اعلام پشتیبانی به معنای کارکردن نیست

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

curl -sI https://server.example/ | grep -i alt-svc

تأیید یک انتقال واقعی

تنها یک درخواست تکمیل‌شده از طریق QUIC می‌تواند پشتیبانی را تأیید کند: HTTP/3. از نسخه‌ای از curl استفاده کنید که با پشتیبانی HTTP/3 ساخته شده باشد؛ بسیاری از بسته‌های سیستم این پشتیبانی را ندارند و در نتیجه گزینه رد می‌شود، که چیزی دربارهٔ سرور نمی‌گوید. در مرورگر، ابزارهای توسعه‌دهنده را باز کنید و ستون Protocol را بخوانید که برای چنین درخواستی h3 را نشان می‌دهد. ممکن است مرورگر در اولین بازدید از HTTP/2 استفاده کند، پس صفحه را دوباره بارگیری کنید.

curl -V | grep -i http3
curl -sS --http3-only -o /dev/null -w '%{http_version}\n' https://server.example/

بررسی پیکربندی NGINX

NGINX در کنار شنوندهٔ TCP به شنوندهٔ QUIC نیاز دارد و هم نسخه و هم ساخت آن باید از این قابلیت پشتیبانی کنند. TLS 1.3 ضروری است، چون QUIC مستقیماً از آن استفاده می‌کند. پیش از بارگذاری مجدد، پیکربندی را بررسی کنید. مقدار ma در Alt-Svc مدت‌زمانی بر حسب ثانیه است که کلاینت‌ها این وعده را به خاطر می‌سپارند؛ پس هنگام آزمایش از مدت کوتاهی استفاده کنید.

listen 443 ssl;
listen 443 quic reuseport;
http2 on;
add_header Alt-Svc 'h3=":443"; ma=300' always;

nginx -V 2>&1 | grep -o with-http_v3_module
sudo nginx -t

بازکردن UDP 443 در سراسر مسیر

رایج‌ترین علت شکست، فایروالی است که TCP 443 را مجاز می‌کند اما UDP 443 را نه. سرور و هر فیلتر بیرونی را بررسی کنید. می‌توانید روی سرور تأیید کنید که سوکت در حال گوش‌دادن است. بعضی شبکه‌های سازمانی و عمومی QUIC را عمداً مسدود می‌کنند؛ بنابراین شکست آزمایش از یک شبکه ثابت نمی‌کند ایراد از سرور است: آزمایش را از شبکه‌ای دیگر تکرار کنید.

sudo ss -lunp | grep ':443'
sudo ufw allow 443/udp
sudo tcpdump -ni any udp port 443

آیا پروتکل جدید سریع‌تر است؟

HTTP/3 بیشترین کمک را در اتصال‌های دارای اتلاف بسته یا هنگام جابه‌جایی بین شبکه‌ها می‌کند، چون گم‌شدن یک بسته جریان‌های دیگر را معطل نمی‌کند. در یک اتصال کابلی خوب ممکن است تفاوت کم باشد و مصرف CPU سرور بیشتر شود. به‌جای فرض‌کردن بهبود، وضعیت خودتان را اندازه بگیرید و HTTP/2 را برای کلاینت‌هایی که نمی‌توانند از UDP استفاده کنند در دسترس نگه دارید.

آزمایش HTTP/3 در CH-J Server Manager

Server Diagnostics یک کلاینت HTTP همراه خود دارد، پس آزمایش به curl سیستم وابسته نیست. تنها پس از تکمیل انتقال QUIC، HTTP/3 را تأییدشده گزارش می‌کند و Alt-Svc را صرفاً اعلان پشتیبانی می‌داند. هنگام پایان مهلت UDP اعلام می‌کند که پشتیبانی سرور همچنان تأیید نشده است، چون علت ممکن است شبکهٔ بین شما و سرور باشد؛ همچنین بازگشت به پروتکلی دیگر را موفقیت به حساب نمی‌آورد.

مستندات مفصل

RFC 9114: HTTP/3 ←

NGINX: QUIC and HTTP/3 ←

باز کردن قفل بیومتریک و امنیت ←