IRCNF

QUIC داره نحوه کار وب رو تغییر میده — اینجا ببین چرا مرورگرت بدون اینکه بگه پروتکل عوض کرد

اشتراک‌گذاری:
QUIC داره نحوه کار وب رو تغییر میده — اینجا ببین چرا مرورگرت بدون اینکه بگه پروتکل عوض کرد

چند سال پیش، بدون هیچ اعلام یا آپدیت نرم‌افزاری، مرورگرت دیگه از همون پروتکلی استفاده نکرد که از دهه ۱۹۸۰ اینترنت رو راه می‌نداخت. اجازه نگرفت. هیچ خطی تو تغییرات نبود. ولی یه تغییر اساسی تو نحوه حرکت داده‌هات تو شبکه افتاد — و این یکی از بزرگ‌ترین تغییرات زیرساخت وب تو یه نسل اخیره.


پروتکلی که هیچوقت بهش فکر نکردی


بیشتر تاریخ وب، HTTP روی TCP اجرا می‌شد — همون Transmission Control Protocol. TCP از طراحی قابل اعتماده: تضمین می‌کنه هر بسته به ترتیب می‌رسه، اگه گم شد دوباره می‌فرسته، و integrity داده رو از انتها تا انتها حفظ می‌کنه. به همین خاطر وقتی HTTP اوایل دهه ۹۰ طراحی شد، انتخاب واضحی بود.


ولی قابلیت اطمینان هزینه داره. TCP قبل از هر انتقال داده نیاز به دست دادن داره — معمولاً ۱ تا ۳ round trip فقط برای برقراری ارتباط. روی یه فیبر نوری سریع تو دیتاسنتر خلوت، این سربار دیده نمی‌شه. ولی تو شبکه موبایل، جایی که بسته‌ها ممکنه بی‌ترتیب برسن، گم بشن، یا latency خیلی متغیر باشه، تضمین‌های TCP تبدیل به یه منبع اصطکاک می‌شن نه آرامش.


مشکل head-of-line blocking


HTTP/2 که سال ۲۰۱۵ منتشر شد، سعی کرد با multiplexing چندین درخواست روی یه connection TCP واحد، عملکرد وب رو بهتر کنه. به جای باز کردن شش تا connection جداگانه به یه سرور (مثل مرورگرهای HTTP/1.1)، HTTP/2 می‌تونست ده‌ها درخواست همزمان از یه لوله بفرسته. این یه پیشرفت واقعی بود — بارگذاری سریع‌تر صفحه، سربار کمتر سرور، استفاده بهتر از پهنای باند.


ولی HTTP/2 یه نقص پنهان از TCP به ارث برد: head-of-line blocking. وقتی یه بسته TCP تو راه گم می‌شه، کل connection متوقف می‌شه. هر stream — هر تصویر، شیوه‌نامه، و اسکریپتی که همزمان منتقل می‌شه — یخ می‌زنه و صبر می‌کنه تا TCP قطعه گم‌شده رو دوباره بفرسته. تو یه شبکه موبایل ناپایدار که ۲–۳٪ از دست دادن بسته رایجه، این می‌تونه multiplexing HTTP/2 رو بی‌فایده کنه. داری یه connection رو به اشتراک می‌ذاری و یه بسته گم‌شده همه چیز رو متوقف می‌کنه.


این مشکلیه که QUIC واسه حلش طراحی شد.


QUIC واقعاً چیه


QUIC — که حدود ۲۰۱۲ تو گوگل به عنوان یه آزمایش شروع شد — یه رویکرد متفاوت تو لایه انتقال داره. به جای ساختن روی TCP، مستقیماً روی UDP اجرا می‌شه، یعنی User Datagram Protocol. UDP برادر ساده‌تر و بدون اتصال TCP هست: بسته‌ها رو بدون تضمین، بدون دست دادن، بدون ترتیب می‌فرسته. به نظر یه قدم عقبه. ولی QUIC مکانیزم‌های قابلیت اطمینان خودش رو بالای UDP می‌سازه — مکانیزم‌هایی که نسبت به stream آگاه هستن.


تو QUIC، هر stream مستقلاً قابل اعتماد هست. اگه بسته‌ای که داده‌های تصویر اصلی صفحه رو حمل می‌کنه گم بشه، فقط stream همون تصویر متوقف می‌شه تا retransmission انجام بشه. CSS، JavaScript و تماس‌های API تو ادامه حرکت می‌کنن. head-of-line blocking تو لایه انتقال حذف می‌شه.


همچنین QUIC رمزنگاری TLS 1.3 رو مستقیماً داخل پروتکل می‌سازه. دیگه هیچ دست دادن TLS جداگانه‌ای بالای دست دادن connection وجود نداره — هر دو با هم اتفاق می‌افتن. این هزینه شروع رو از ۲–۳ round trip (TCP + TLS) به فقط ۱ round trip برای connection جدید کاهش می‌ده، و با resume connection با ۰-RTT، کاربرانی که برمی‌گردن می‌تونن اولین درخواستشون رو قبل از اینکه connection کامل برقرار بشه بفرستن. برای وب امروزی که کاربرا انتظار بارگذاری زیر ثانیه دارن، این صرفه‌جویی‌ها مهمه.


Connection migration: ابرقدرت گوشی تو


یکی از مفیدترین ویژگی‌های QUIC connection migration هست. یه connection TCP به آدرس IP و شماره پورت گره خورده. وقتی از وای‌فای دفترت راه می‌افتی سمت راهرو و گوشیت سوییچ می‌کنه به دیتای موبایل، آدرس IP تو عوض می‌شه — و هر connection TCP که داشتی قطع می‌شه. دانلودات از اول شروع می‌شن. تماس ویدیوییت لکنت پیدا می‌کنه. استریمت قطع و وصل می‌شه.


connection های QUIC با یه connection ID شناسایی می‌شن، نه جفت IP/port. وقتی گوشیت بین شبکه‌ها جابه‌جا می‌شه، connection ID ثابت می‌مونه. connection های QUIC بدون وقفه به مسیر شبکه جدید مهاجرت می‌کنن. تو عمل یعنی تماس ویدیویی وقتی بین شبکه‌ها جابه‌جا می‌شی نرم می‌مونه، انتقال فایل از اول شروع نمی‌شه، و جلسات وب قطع نمی‌شن — حتی اگه شبکه زیرپات عوض بشه.


HTTP/3: QUIC تو مرورگر


HTTP/3 در واقع همون معنای HTTP هست که روی QUIC اجرا می‌شه به جای TCP. مدل درخواست-پاسخ، هدرها، متدها — همه مثل قبل. ولی لایه انتقال زیرش اساساً متفاوته. HTTP/3 تو ژوئن ۲۰۲۲ به عنوان استاندارد IETF (RFC 9114) منتشر شد، و اون موقع همه مرورگرهای اصلی قبلاً پشتیبانی رو اضافه کرده بودن: کروم از ۲۰۲۰، فایرفاکس از ۲۰۲۱، سافاری از ۲۰۲۲، و Edge به دنبال کروم.


تو سمت سرور هم پذیرش سریع بود. Cloudflare از ۲۰۲۰ به طور پیش‌فرض HTTP/3 رو تو کل شبکه‌ش فعال کرد. سرورهای گوگل از زمانی که این پروتکل هنوز داخلی "QUIC" نامیده می‌شد، HTTP/3 رو سرو می‌دادن. Meta — که یکی از بزرگ‌ترین زیرساخت‌های وب دنیا رو مدیریت می‌کنه — از پیشرفت‌های قابل توجه QUIC روی موبایل گزارش داد، به خصوص تو بازارهایی که قابلیت اطمینان شبکه ناپایدار هست. Akamai یه‌کی از بزرگ‌ترین ارائه‌دهنده‌های CDN، پشتیبانی HTTP/3 رو به کل شبکه edge خودش آورد.


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


پذیرش الان کجاست


تا سال ۲۰۲۴، HTTP/3 یه آزمایش حاشیه‌ای نیست. طبق داده‌های رادار Cloudflare، حدود ۳۰٪ ترافیک جهانی وب الان از HTTP/3 استفاده می‌کنه. این عدد روی موبایل و تو مناطقی با شرایط شبکه چالش‌برانگیز بالاتر هست — دقیقاً همون موارد استفاده‌ای که مزایای QUIC بیشتر به چشم میاد.


اما چالش زیرساخت واقعیه. QUIC روی UDP اجرا می‌شه، و دهه‌ها تجهیزات شبکه — فایروال‌ها، load balancerها، جعبه‌های deep packet inspection — بهینه TCP بودن. خیلی از شبکه‌های سازمانی و فایروال‌های شرکتی UDP روی پورت ۴۴۳ رو مسدود یا محدود می‌کنن، جایی که QUIC زندگی می‌کنه. این یعنی مرورگرها و سرورها به منطق fallback نیاز دارن: اگه QUIC نتونه رد بشه، به HTTP/2 روی TCP برمی‌گردن. انتقال طوری طراحی شده که نامرئی باشه.


برای توسعه‌دهنده‌ها و اپراتورها، پشتیبانی HTTP/3 معمولاً رایگان هست اگه پشت یه CDN بزرگ باشین. اگه زیرساخت خودتون رو اجرا می‌کنین، شاخه QUIC nginx، Caddy و LiteSpeed همه HTTP/3 رو پشتیبانی می‌کنن. سربار پیکربندی کمه به شرطی که گواهی TLS معتبر داشته باشین — که تو عصر QUIC غیرقابل مذاکره هست، چون رمزنگاری تو خود پروتکل تعبیه شده.


تغییر زیرساخت پنهان


چیزی که انتقال QUIC رو قابل توجه می‌کنه اینه که عمدتاً بدون اینکه کاربران نهایی متوجه بشن اتفاق افتاد. هیچ‌کس مرورگرش رو حذف نصب نکرد. هیچ‌کس روی "ارتقا به HTTP/3" کلیک نکرد. تغییر تو لایه مذاکره پروتکل اتفاق افتاد، نامرئی تو Chrome مرورگر اما اساسی تو سطح شبکه.


اینطوری زیرساخت وب معمولاً تکامل پیدا می‌کنه: نه از طریق انقلاب‌های ناگهانی، بلکه از طریق مذاکره‌های سازگار با عقب که به تدریج خط پایه رو جابه‌جا می‌کنه. HTTP/2 سال‌ها با استانداردسازی ۲۰۱۵ طول کشید تا به پذیرش اکثریت برسه. HTTP/3 مسیر سریع‌تری داره، که توسط مقیاس پیاده‌سازی‌ها رانده می‌شه — وقتی Cloudflare و گوگل سوییچ می‌کنن، بخش بزرگی از ترافیک وب با اونا جابه‌جا می‌شه.


برای کاربران شبکه‌های موبایل — که امروز یعنی بیشتر کاربران اینترنت دنیا — بهبودها قابل توجه هستن: بارگذاری سریع‌تر صفحه، connectionهای مقاوم‌تر، جابه‌جایی‌های یکپارچه بین شبکه‌ها. اینترنت یکشبه عوض نشد. ولی زیر کاپوت، لوله‌هایی که داده‌هات ازشون عبور می‌کنن خیلی بهتر شدن. QUIC دلیلشه.

اشتراک‌گذاری:
QUIC داره نحوه کار وب رو تغییر میده — اینجا ببین چرا مرورگرت بدون اینکه بگه پروتکل عوض کرد | IRCNF - Intelligent Reliable Custom Next-gen Frameworks