HTTP همان پروتکلی است که در فصل ۱ دیدیم — اما سه نسل آن آنقدر فرق دارند که تصمیمهای معماری را عوض میکنند: چند اتصال باز کنیم؟ چرا push لحظهای با HTTP معمولی نمیشود؟ و چرا موبایل با اینترنت قطعووصل از HTTP/3 سود میبرد؟
هر نسل چه دردی را دوا کرد
| نسخه | نوآوری کلیدی | دردی که ماند |
|---|---|---|
| HTTP/1.1 | keep-alive: استفاده مجدد از یک اتصال TCP برای چند درخواست | یک اتصال = یک درخواست در لحظه؛ مرورگرها برای موازیسازی ۶ اتصال باز میکنند |
| HTTP/2 | فریم باینری + multiplexing: صدها stream همزمان روی یک اتصال TCP؛ فشردهسازی هدر (HPACK) | Head-of-Line Blocking در لایه TCP: گمشدن یک بسته، همه stream ها را معطل میکند |
| HTTP/3 | روی QUIC (بهجای TCP): stream های مستقل روی UDP، handshake ترکیبی 1-RTT، مهاجرت اتصال | پشتیبانی زیرساخت میانی (پروکسیها/فایروالها) هنوز در حال رسیدن |
QUIC چرا مهم است
- در TCP، بسته گمشده همه صف پشت سرش را نگه میدارد (HOL blocking)؛ در QUIC هر stream مستقل است — فقط همان stream صبر میکند.
- Connection Migration: اتصال با یک ID شناخته میشود نه با IP/port — وقتی موبایل از WiFi به اینترنت همراه میرود، اتصال زنده میماند.
- TLS 1.3 در QUIC تعبیه شده: handshake اول 1-RTT (بهجای 2-3 رفتوبرگشت TCP+TLS قدیمی) و اتصالهای بعدی 0-RTT.
- 0-RTT را با دقت بکار ببر: درخواستهای replayable هستند — هرگز برای عملیات غیر-idempotent (پرداخت!) 0-RTT نگذار.
پیامد معماری
- عادتهای دوران HTTP/1.1 مثل domain sharding و sprite و concat کردن فایلها در دنیای HTTP/2+ ضدبهرهوریاند — یک اتصال multiplexed کافی است.
- برای API داخلی سرویسها، HTTP/2 بستر gRPC است (درس ۴۱)؛ برای وب مدرن، CDN ها (Cloudflare و…) HTTP/3 را لبه میدهند و به origin با HTTP/1.1/2 حرف میزنند.
- متریکها را per-پروتکل ببین: سهم کاربران HTTP/3 و تأثیرش بر TTFB را در CDN گزارش بگیر.
به زبان ساده
HTTP/2 چند درخواست را روی یک اتصال قاطی میکند و HTTP/3 با QUIC روی UDP حتی قطعشدن اینترنت موبایل را هم نرم میکند.
مثال واقعی
وقتی از وایفای خانه به آنتن سیمکارت سوار میشوی، دانلود با TCP قطع میشود؛ با QUIC اتصال با همان شناسه ادامه پیدا میکند و ویدیو نمیپرد.