HTTP/۳ چیست؟ راهنمای QUIC، مزایا، ریسک و فعال‌سازی

HTTP/3 نسل جدید انتقال درخواست‌های HTTP روی QUIC است. هدف آن حفظ معنای آشنای وب—URL، Header، Status Code و Cache—در کنار اتصال کم‌تأخیرتر، Streamهای مستقل و رفتار بهتر در بعضی شبکه‌های پرتلفات یا متغیر است. اما فعال‌کردن HTTP/۳ تضمین نمی‌کند هر سایت سریع‌تر شود و جای بهینه‌سازی Backend، Cache، تصویر یا JavaScript را نمی‌گیرد.

برای تصمیم درست باید تفاوت HTTP/۲ و HTTP/۳، نقش UDP و TLS ۱.۳، محدودیت ۰‑RTT، روش Discovery، Fallback و سنجه‌های واقعی را بشناسید. این راهنما معماری، امنیت، فعال‌سازی و عیب‌یابی HTTP/۳ را از CDN تا Origin توضیح می‌دهد.

HTTP/۳ چیست؟

HTTP/۳ نگاشت HTTP semantics روی پروتکل انتقال QUIC است. RFC 9114 آن را به‌عنوان استاندارد IETF تعریف می‌کند. HTTP/۳ هنوز همان درخواست و پاسخ HTTP را ارائه می‌دهد، اما به‌جای TCP از QUIC برای انتقال استفاده می‌کند.

پشته ساده‌شده:

• HTTP/۱.۱ یا HTTP/۲ معمولاً روی TLS و TCP؛
• HTTP/۳ روی QUIC؛
• QUIC روی UDP/IP؛
• TLS ۱.۳ داخل Handshake و حفاظت QUIC ادغام شده است.

بنابراین جمله «HTTP/۳ به‌جای TLS از UDP استفاده می‌کند» غلط است. UDP حامل Datagramهاست و QUIC قابلیت اطمینان، رمزنگاری، کنترل جریان و کنترل ازدحام را در لایه خود فراهم می‌کند.

مقایسه HTTP/۱.۱، HTTP/۲ و HTTP/۳

«بهتر» بودن به شبکه، پیاده‌سازی، اندازه صفحه، Cache و Backend بستگی دارد. HTTP/۲ همچنان Fallback ضروری و کارآمد است.

چرا HTTP/۲ هنوز Head-of-Line Blocking دارد؟

HTTP/۲ چند درخواست را روی یک اتصال TCP Multiplex می‌کند. اما TCP یک جریان بایت مرتب است. اگر Packet گم شود، لایه TCP باید آن بخش را بازیابی کند و داده بعدی را به‌ترتیب به برنامه تحویل دهد. از دید HTTP/۲، Streamهای مستقل روی همان اتصال ممکن است تا بازیابی Packet متوقف شوند.

QUIC قابلیت اطمینان را در سطح Stream ارائه می‌کند. طبق RFC ۹۱۱۴، یک Stream گرفتار Loss مانع پیشرفت Streamهای دیگر نمی‌شود. این تفاوت در شبکه با Packet Loss یا RTT بالاتر می‌تواند مهم باشد؛ در شبکه پایدار و پاسخ کوچک ممکن است تفاوت محسوس نباشد.

QUIC چیست؟

RFC 9000، QUIC را یک انتقال Multiplexed و امن مبتنی بر UDP تعریف می‌کند. UDP به‌تنهایی تحویل، ترتیب یا کنترل ازدحام را تضمین نمی‌کند؛ QUIC این قابلیت‌ها را خودش پیاده می‌کند.

• Streamهای مستقل دوطرفه و یک‌طرفه؛
• Reliability و تحویل مرتب درون هر Stream؛
• Flow Control در سطح Stream و Connection؛
• Congestion Control و Loss Recovery؛
• Handshake امن مبتنی بر TLS ۱.۳؛
• Connection ID و امکان Migration؛
• Version Negotiation و قابلیت تکامل در User Space.

مزیت User Space این است که پیاده‌سازی QUIC می‌تواند بدون انتظار برای تغییر Kernel TCP سریع‌تر به‌روز شود؛ در مقابل، مصرف CPU، پیچیدگی و کیفیت کتابخانه اهمیت بیشتری پیدا می‌کنند.

آیا UDP ذاتاً سریع‌تر از TCP است؟

خیر. UDP Header و مکانیزم ساده‌تری دارد، اما برای انتقال قابل اعتماد وب، QUIC باید ACK، Retransmission، Flow Control و Congestion Control را انجام دهد. سرعت از «حذف قابلیت اطمینان» نمی‌آید؛ از طراحی یکپارچه Handshake، Streamهای مستقل و امکان تکامل انتقال حاصل می‌شود.

در بعضی شبکه‌ها UDP محدود، Rate-limit یا مسدود می‌شود. در این حالت Client باید به نسخه TCP-based مانند HTTP/۲ برگردد. RFC ۹۱۱۴ همین Fallback را توصیه می‌کند.

Handshake در QUIC چگونه است؟

در اولین اتصال، QUIC و TLS ۱.۳ با هم مذاکره می‌شوند. Client معمولاً می‌تواند پس از یک رفت‌وبرگشت داده Application بفرستد و Server نیز زود پاسخ دهد. حذف Handshake جداگانه TCP می‌تواند هزینه راه‌اندازی Connection را کم کند.

1‑RTT

در اتصال تازه، هویت Server و کلیدها در Handshake تأیید می‌شوند. عدد دقیق زمان صرفه‌جویی به RTT، DNS، اتصال قبلی، Session Resumption و رفتار Client بستگی دارد.

0‑RTT

در اتصال ازسرگرفته‌شده، Client می‌تواند Early Data را پیش از تکمیل Handshake بفرستد. RFC ۹۰۰۱ درباره TLS در QUIC هشدار می‌دهد که داده ۰‑RTT ممکن است Replay شود؛ بنابراین برای دستوری که تکرار آن اثر ناخواسته دارد مناسب نیست.

• GET یا درخواست Idempotent فقط پس از ارزیابی Cache و Authorization؛
• خرید، انتقال وجه، تغییر رمز یا ثبت عملیات را با ۰‑RTT نپذیرید؛
• Server باید Early Data را تشخیص و Policy مناسب اعمال کند؛
• فعال‌سازی عمومی ssl_early_data بدون کنترل Application امن نیست.

TLS ۱.۳ در HTTP/۳

HTTP/۳ برای QUIC Version ۱ به TLS ۱.۳ یا جدیدتر متکی است. TLS داخل QUIC برای Authentication، محرمانگی و Integrity استفاده می‌شود. بیشتر Frameهای انتقال نیز رمزگذاری می‌شوند، اما IP و برخی اطلاعات لازم برای Routing کاملاً پنهان نیستند.

HTTP/۳ سایت را خودکار در برابر XSS، SQL Injection، بدافزار یا سرقت Session محافظت نمی‌کند. این‌ها در لایه Application و عملیات امنیتی حل می‌شوند. برای آن‌ها راهنمای جلوگیری از SQL Injection و XSS را ببینید.

Stream و QPACK

هر Request/Response معمولاً یک QUIC Stream دوطرفه مصرف می‌کند. Stream کنترل و QPACK جدا هستند. HTTP/۳ نمی‌تواند HPACK را عیناً استفاده کند، چون HPACK به ترتیب دریافت Headerها در Connection وابسته است. QPACK برای محیطی طراحی شده که Streamها مستقل حرکت می‌کنند.

QPACK نیز می‌تواند Blocking محدود ناشی از وابستگی به Dynamic Table ایجاد کند. تنظیم Capacity و تعداد Blocked Stream باید با Headerهای واقعی تست شود؛ «حذف کامل هر نوع Blocking» تعبیر دقیقی نیست.

Connection Migration چگونه کار می‌کند؟

TCP Connection معمولاً با آدرس و پورت دو سمت شناخته می‌شود. QUIC از Connection ID استفاده می‌کند تا Connection بتواند در شرایطی مانند NAT Rebinding یا تغییر شبکه Client ادامه یابد. RFC ۹۰۰۰ برای مسیر جدید Path Validation تعریف می‌کند.

Migration تضمین نمی‌کند تغییر Wi‑Fi به موبایل همیشه بدون وقفه باشد:

• Server می‌تواند Active Migration را غیرفعال کند؛
• Handshake باید تأیید شده باشد؛
• مسیر جدید باید Validate شود؛
• NAT، Firewall و Load Balancer باید QUIC را درست عبور دهند؛
• Application و Client باید قابلیت را پشتیبانی کنند؛
• تغییر RTT و MTU می‌تواند عملکرد را عوض کند.

HTTP/۳ چگونه کشف می‌شود؟

داشتن UDP ۴۴۳ باز کافی نیست. Client باید بداند Endpoint از HTTP/۳ پشتیبانی می‌کند.

Alt-Svc

Origin می‌تواند در پاسخ HTTP/۲ یا HTTP/۱.۱ هدر زیر را اعلام کند:

Alt-Svc: h3=":443"; ma=86400

Client می‌تواند سپس QUIC را روی UDP ۴۴۳ امتحان کند. اگر شکست خورد، نسخه TCP را ادامه می‌دهد. ma مدت اعتبار Advertisement است؛ در Rollback طولانی می‌تواند Client را به Endpoint غیرفعال هدایت کند، پس ابتدا مقدار کوتاه‌تر مناسب است.

DNS HTTPS Record

Service Binding/HTTPS DNS Record نیز می‌تواند اطلاعات Endpoint و ALPN را پیش از اولین پاسخ ارائه دهد. پشتیبانی Resolver، CDN و Client را بررسی کنید؛ Alt-Svc همچنان رایج و کاربردی است.

ALPN

در TLS Handshake، توکن h3 برای مذاکره HTTP/۳ استفاده می‌شود. نسخه‌های Draft قدیمی مانند h3-29 را با استاندارد نهایی اشتباه نگیرید.

چه زمانی HTTP/۳ احتمالاً مفیدتر است؟

• کاربران موبایل با جابه‌جایی شبکه؛
• Packet Loss یا RTT بالاتر؛
• تعداد درخواست موازی زیاد؛
• Connectionهای تازه و Originهای متعدد؛
• Audience جغرافیایی دور از Server؛
• سرویسی که CDN با Edge نزدیک دارد.

اگر TTFB به دلیل Query کند سه ثانیه است، کاهش Handshake مسئله اصلی را حل نمی‌کند. اگر صفحه با JavaScript سنگین Main Thread را قفل می‌کند، HTTP/۳ INP را مستقیماً درمان نمی‌کند.

HTTP/۳ چه زمانی تفاوت کمی دارد؟

• Connection قبلاً Warm و شبکه پایدار است؛
• صفحه کوچک و Cache شده است؛
• Backend یا Origin Bottleneck اصلی است؛
• کاربر نزدیک Edge و RTT بسیار کم دارد؛
• UDP در مسیر محدود می‌شود و Fallback رخ می‌دهد؛
• Client یا Proxy سازمانی HTTP/۳ را استفاده نمی‌کند؛
• هزینه CPU Server یا Edge از سود Latency بیشتر است.

HTTP/۳ و Core Web Vitals

HTTP/۳ خودش Core Web Vital نیست. ممکن است با کاهش زمان Connection یا اثر Loss بر Requestهای موازی، TTFB و گاهی LCP را بهبود دهد. اما LCP به Server Response، Resource Discovery، اولویت، حجم تصویر، CSS و Rendering نیز وابسته است.

INP بیشتر به JavaScript، Event Handler و Main Thread مربوط است و CLS به Layout. برای اصلاح منابع Frontend، راهنمای بهینه‌سازی CSS و JavaScript و برای تصویر، راهنمای فرمت و Fallback تصویر را ببینید.

آیا HTTP/۳ مستقیماً رتبه سئو را بالا می‌برد؟

مدرک معتبری برای «HTTP/۳ به‌عنوان فاکتور مستقیم رتبه‌بندی» وجود ندارد. اثر احتمالی غیرمستقیم است: اگر برای کاربران واقعی سرعت یا پایداری بهتر شود، تجربه و برخی متریک‌ها می‌توانند بهتر شوند. تغییر Protocol بدون بهبود Field Data را مزیت سئوی قطعی معرفی نکنید.

قبل و بعد را با Real User Monitoring، Search Console و Lab Test مقایسه کنید. میانگین کل ممکن است تفاوت شبکه و کشور را پنهان کند.

فعال‌سازی HTTP/۳ روی CDN

برای بیشتر سایت‌ها، فعال‌سازی در CDN کم‌ریسک‌ترین مسیر است. Browser تا Edge از HTTP/۳ استفاده می‌کند و CDN می‌تواند با HTTP/۲ یا HTTP/۱.۱ به Origin متصل شود. لازم نیست Origin هم‌زمان QUIC داشته باشد.

چک‌لیست CDN

• HTTP/۳/QUIC برای Zone فعال است.
• گواهی و Hostname پوشش درست دارند.
• UDP ۴۴۳ در Edge ارائه می‌شود.
• Alt-Svc یا Discovery صحیح است.
• HTTP/۲ و TCP ۴۴۳ به‌عنوان Fallback باقی مانده‌اند.
• Cache Key و Compression تغییر ناخواسته نکرده‌اند.
• Protocol در Log یا Analytics قابل مشاهده است.
• Origin Timeout و Retry مستقل پایش می‌شوند.

فهرست کشور، Plan و رفتار هر CDN تغییر می‌کند؛ مستندات همان Provider و حساب خود را مبنا قرار دهید.

فعال‌سازی روی NGINX Origin

NGINX از شاخه Mainline ۱.۲۵.۰ ماژول HTTP/۳ را ارائه کرده است، اما Build، کتابخانه TLS و وضعیت نسخه اهمیت دارند. مستندات رسمی QUIC در NGINX نسخه کتابخانه پیشنهادی، Build و عیب‌یابی را به‌روز نگه می‌دارد.

نمونه مفهومی—نه Config آماده Production:

server {
    listen 443 ssl;
    listen 443 quic reuseport;

    ssl_protocols TLSv1.3;
    ssl_certificate     /path/fullchain.pem;
    ssl_certificate_key /path/privkey.pem;

    add_header Alt-Svc 'h3=":443"; ma=86400' always;
}

قبل از استفاده، Syntax نسخه نصب‌شده را با nginx -V و مستندات همان Release بررسی کنید. HTTP/۲ را روی Listener TCP حفظ، Config را Validate و Reload را مانیتور کنید.

Apache، LiteSpeed، Caddy و Application Server

پشتیبانی و روش فعال‌سازی میان Serverها و نسخه‌ها متفاوت است. گاهی Reverse Proxy یا Load Balancer HTTP/۳ را Terminate می‌کند و Application هیچ تغییری نمی‌بیند. از Patch غیررسمی یا Tutorial قدیمی برای Production بدون بررسی Maintenance و CVE استفاده نکنید.

تصمیم بگیرید QUIC در کدام لایه Terminate شود:

• CDN Edge؛
• Cloud Load Balancer؛
• Reverse Proxy؛
• Application Server.

یک Owner و منبع Log برای همان لایه تعیین کنید.

Firewall و Load Balancer

HTTPS سنتی روی TCP ۴۴۳ است؛ HTTP/۳ به UDP ۴۴۳ نیاز دارد. Checklist شبکه:

• Inbound و Outbound UDP ۴۴۳ مجاز باشد.
• Security Group و ACL مسیر کامل را پوشش دهند.
• NAT Timeout برای QUIC مناسب باشد.
• Load Balancer QUIC و Connection ID را پشتیبانی کند.
• Health Check فقط TCP نباشد.
• MTU و Fragmentation در Tunnel بررسی شوند.
• Rate Limit یا DDoS Policy UDP را بی‌دلیل Drop نکند.
• Fallback TCP ۴۴۳ سالم بماند.

بازکردن UDP ۴۴۳ روی Origin عمومی بدون نیاز، سطح عملیات را زیاد می‌کند. اگر CDN Termination کافی است، Origin را فقط برای IPهای مجاز Provider محدود کنید.

امنیت و DDoS در QUIC

QUIC رمزنگاری اجباری دارد، اما UDP و Handshake همچنان نیازمند محافظت‌اند:

• Address Validation و Retry برای کاهش Amplification؛
• Rate Limit بر مبنای IP/Connection با توجه به NAT؛
• سقف Connection و Stream؛
• Timeout و Token Rotation؛
• Patch منظم کتابخانه QUIC/TLS؛
• Logging خطای Handshake و Version؛
• DDoS Scrubbing سازگار با QUIC؛
• ۰‑RTT Policy در Application؛
• Fallback بدون Downgrade ناامن.

QUIC بخشی از Headerهای انتقال را Encrypt می‌کند و دید ابزارهای سنتی شبکه را کم می‌کند. مشاهده‌پذیری باید به Endpoint Log و Telemetry منتقل شود.

Connection ID و حریم خصوصی

Connection ID برای Routing و Migration مفید است، اما استفاده ثابت می‌تواند Linkability بسازد. RFCها تغییر Connection ID را برای مسیر جدید در نظر می‌گیرند. Load Balancer نباید اطلاعات داخلی حساس را بدون حفاظت در CID Encode کند.

Retention Log، دسترسی و ارتباط CID با User Session را مستند کنید. شناسه انتقال را برای تحلیل بازاریابی فردی بازاستفاده نکنید.

تست HTTP/۳

curl

نسخه curl باید با HTTP/۳ Build شده باشد. ابتدا قابلیت را بررسی کنید و سپس:

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

دستور اول ممکن است Fallback کند؛ دستور دوم شکست HTTP/۳ را آشکارتر می‌کند. خروجی Version و Timing را ذخیره کنید.

Browser DevTools

در Network، ستون Protocol را فعال کنید و به دنبال h3 باشید. اولین Load ممکن است از HTTP/۲ برای دریافت Alt-Svc استفاده کند؛ Reload یا Connection جدید را نیز بررسی کنید. Extension یا VPN می‌تواند رفتار را تغییر دهد.

Header و Packet Capture

وجود Alt-Svc را با Header Check تأیید کنید. Packet Capture باید UDP ۴۴۳ را نشان دهد، اما Payload رمزگذاری‌شده است. Key Log و ابزار QUIC-aware فقط در محیط کنترل‌شده استفاده شوند.

چطور عملکرد را درست مقایسه کنیم؟

A/B Test در سطح User همیشه ساده نیست، چون Client Protocol را انتخاب می‌کند. می‌توانید Hostname یا Edge Configuration کنترل‌شده، قبل/بعد با Segment و Synthetic Test تکرارشونده استفاده کنید. تغییر CDN، Cache و HTTP/۳ را هم‌زمان انجام ندهید.

نقشه انتشار کم‌ریسک

مرحله ۱: Baseline

• HTTP/۲، TTFB، LCP، Error و CPU را ثبت کنید.
• کشورها، Browserها و شبکه‌های اصلی را مشخص کنید.
• UDP و Load Balancer را Read-only بررسی کنید.

مرحله ۲: Edge Pilot

• HTTP/۳ را روی CDN یا Hostname آزمایشی فعال کنید.
• HTTP/۲ Fallback را نگه دارید.
• Alt-Svc با Max-age کوتاه اعلام کنید.
• Protocol و خطا را در Log جدا کنید.

مرحله ۳: Canary

• Traffic یا دامنه محدود را گسترش دهید.
• ISP/ASN و کشور را مقایسه کنید.
• CPU، Handshake و Fallback را پایش کنید.
• Runbook Rollback را اجراپذیر نگه دارید.

مرحله ۴: Production

• پس از ثبات، Advertisement را بلندتر کنید.
• Alert و Dashboard دائمی بسازید.
• Version و کتابخانه را در Patch Cycle قرار دهید.
• فصلانه نتیجه عملکرد را بازبینی کنید.

برای آمادگی ظرفیت و Incident در ترافیک بالا، چک‌لیست جلوگیری از قطع سایت در کمپین را ببینید.

HTTP/۳ و IPv6

HTTP/۳ روی IPv4 و IPv6 کار می‌کند و وابسته به IPv6 نیست. اما Dual-stack، DNS، Route و Firewall هر دو خانواده باید تست شوند. ممکن است QUIC روی IPv4 سالم و روی IPv6 مسیر متفاوتی داشته باشد یا برعکس.

برای رکورد AAAA، Dual-stack و عیب‌یابی مسیر، راهنمای IPv6، هاست و DNS را مطالعه کنید.

اشتباه‌های رایج HTTP/۳

• UDP را سریع و غیرقابل اعتماد معرفی می‌کنند: QUIC Reliability و Congestion Control دارد.
• HTTP/۳ را بدون TLS می‌دانند: TLS ۱.۳ در QUIC ادغام شده است.
• ۰‑RTT را برای همه درخواست‌ها فعال می‌کنند: Replay نادیده گرفته می‌شود.
• Connection Migration را تضمینی می‌دانند: Path Validation و Policy Server حذف می‌شوند.
• UDP ۴۴۳ را باز نمی‌کنند: Client دائماً Fallback می‌کند.
• TCP Fallback را می‌بندند: کاربران شبکه محدود قطع می‌شوند.
• Alt-Svc را فراموش می‌کنند: Client Endpoint را کشف نمی‌کند.
• بهبود سئو را قطعی می‌دانند: Field Data اندازه‌گیری نمی‌شود.
• هم‌زمان CDN و Cache را عوض می‌کنند: علت نتیجه قابل تشخیص نیست.
• فقط Browser خودشان را تست می‌کنند: تفاوت شبکه و مسیر دیده نمی‌شود.

چک‌لیست پیش از فعال‌سازی

• گواهی معتبر و TLS ۱.۳ آماده است.
• HTTP/۲ روی TCP ۴۴۳ باقی می‌ماند.
• UDP ۴۴۳ در تمام مسیر مجاز است.
• CDN/Server نسخه پشتیبانی‌شده دارد.
• Alt-Svc یا Discovery درست تنظیم شده است.
• ۰‑RTT غیرفعال یا Application-aware است.
• Load Balancer و DDoS Protection با QUIC سازگارند.
• Log شامل Protocol و خطای Handshake است.
• Baseline عملکرد و هزینه داریم.
• Canary، Alert و Rollback تعریف شده‌اند.

سؤالات متداول HTTP/۳ و QUIC

آیا HTTP/۳ همیشه از HTTP/۲ سریع‌تر است؟

خیر. مزیت به RTT، Packet Loss، Connection جدید، Client، CDN و Bottleneck سایت بستگی دارد. در شبکه پایدار یا Backend کند، تفاوت ممکن است کم باشد.

آیا برای HTTP/۳ باید HTTP/۲ را خاموش کنیم؟

خیر. HTTP/۲ و HTTP/۱.۱ Fallback ضروری‌اند، چون UDP ممکن است در برخی مسیرها مسدود یا محدود باشد و همه Clientها HTTP/۳ را استفاده نکنند.

آیا HTTP/۳ امنیت سایت را کامل می‌کند؟

خیر. QUIC رمزنگاری و Integrity انتقال را فراهم می‌کند، اما آسیب‌پذیری Application مانند XSS، SQL Injection، Authorization یا بدافزار را رفع نمی‌کند.

چطور بفهمیم سایت واقعاً h3 استفاده می‌کند؟

در Browser DevTools ستون Protocol را ببینید یا از curl ساخته‌شده با HTTP/۳ استفاده کنید. وجود هدر Alt-Svc به‌تنهایی ثابت نمی‌کند Connection موفق شده است.

آیا HTTP/۳ به IPv6 نیاز دارد؟

خیر. QUIC روی IPv4 و IPv6 کار می‌کند. در سایت Dual-stack باید هر دو مسیر، DNS و Firewall را جداگانه تست کنید.

جمع‌بندی: HTTP/۳ را اندازه‌گیری کنید، نه فرض

HTTP/۳ با QUIC، Streamهای مستقل، Handshake یکپارچه TLS ۱.۳ و امکان Migration را به وب می‌آورد. این معماری می‌تواند در شبکه‌های موبایل یا پرتلفات مزیت داشته باشد، اما عملکرد بهتر خودکار نیست. CDN Pilot، Fallback سالم، کنترل ۰‑RTT، مشاهده‌پذیری و مقایسه Field Data مسیر درست است.

اگر برای انتخاب CDN، بررسی Firewall، فعال‌سازی NGINX، طراحی Canary یا تحلیل RUM به کمک نیاز دارید، از طریق درخواست مشاوره مایندیو معماری فعلی، Server و الگوی ترافیک را ارسال کنید.

مطالب مرتبط

• IPv6، هاست و DNS
• آمادگی سایت برای ترافیک بالا
• بهینه‌سازی CSS و JavaScript
• بهینه‌سازی فرمت تصویر وب
• جلوگیری از SQL Injection و XSS
• طراحی پایپ‌لاین CI/CD امن