TCP آنقدر شکسته بود که قابل تعمیر نبود؛ بنابراین اینترنت یک پروتکل جدید روی UDP ساخت

TCP از سال ۱۹۷۴ لایه انتقال اینترنت بوده است. هر صفحه وبی که بار می‌کنید، هر درخواست API که اپلیکیشن شما انجام می‌دهد، هر ایمیلی که می‌فرستید — برای پنجاه سال، تقریباً همه اینها از طریق TCP منتقل شده است. این پروتکل قابل اعتماد، آزموده‌شده در میدان نبرد و بر روی تمام دستگاه‌های متصل به شبکه در جهان مستقر است. اما همچنین به‌طور فزاینده‌ای به یک تنگنا برای نحوه عملکرد واقعی وب مدرن تبدیل شده است و تعمیر آن از نظر سیاسی غیرممکن بود. بنابراین صنعت چیزی جدید روی UDP ساخت.

آن چیز جدید QUIC است که در سال ۲۰۲۱ توسط IETF به عنوان RFC 9000 استاندارد شد. HTTP/3، آخرین نسخه از پروتکلی که وب را تغذیه می‌کند، روی QUIC اجرا می‌شود. Cloudflare HTTP/3 را به بیش از ۴۰٪ از ترافیک خود ارائه کرده است. گوگل از سال ۲۰۱۳ QUIC را در سرویس‌های خود مستقر کرده است. پروتکلی که قرار بود یک آزمایش باشد، اکنون بخش قابل توجهی از اینترنت را حمل می‌کند.

چه مشکلی با TCP وجود داشت

طراحی بنیادی TCP برای دنیایی از اتصالات سیمی ثابت و قابل اعتماد ساخته شده بود. این پروتکل فرض می‌کند که اگر یک بسته گم شود، شبکه ازدحام دارد و باید سرعت را کاهش دهد. این در سال ۱۹۷۴ منطقی بود. در سال ۲۰۲۶، با کاربران موبایل که دائماً بین Wi-Fi و سلولی جابجا می‌شوند، بسته‌ها به دلایلی که هیچ ربطی به ازدحام ندارند — تداخل سیگنال، جابجایی بین دکل‌ها، شکاف‌های کوتاه پوشش — از دست می‌روند. TCP نمی‌تواند بین «شبکه ازدحام دارد» و «کاربر تازه وارد آسانسور شده است» تفاوت قائل شود و در هر دو مورد سرعت را کاهش می‌دهد.

مشکل ساختاری بزرگ‌تر، هد-آف-لاین بلاکینگ (blocking head-of-line) است. یک اتصال TCP واحد یک جریان داده مرتب است. اگر بسته ۷ گم شود، بسته‌های ۸ تا ۱۰۰ همگی منتظر می‌مانند حتی اگر به درستی رسیده باشند. HTTP/2 یک نسخه از این مشکل را با مالتی‌پلکس کردن چندین درخواست روی یک اتصال TCP واحد حل کرد — اما این در واقع هد-آف-لاین بلاکینگ را در لایه TCP بدتر کرد، نه بهتر. یک بسته گم‌شده واحد اکنون می‌تواند تمام جریان‌های مالتی‌پلکس شده روی اتصال را همزمان متوقف کند.

همچنین سربار برقراری اتصال وجود داشت. TCP قبل از اینکه داده جریان یابد به یک دست‌داد سه‌مرحله‌ای نیاز دارد. TLS ۱-۲ رفت و برگشت دیگر برای مذاکره رمزنگاری اضافه می‌کند. بارگذاری یک منبع از یک سرور جدید نیاز به ۲-۳ رفت و برگشت کامل قبل از رسیدن اولین بایت محتوا دارد. برای کاربری در توکیو که به سروری در ویرجینیا متصل می‌شود، هر رفت و برگشت تقریباً ۱۷۰ میلی‌ثانیه طول می‌کشد. آن را در تعداد سرورهای متمایزی که یک صفحه وب مدرن با آنها صحبت می‌کند ضرب کنید و سربار تاخیر قابل توجه می‌شود.

چرا آن را روی UDP ساختند

سوال منطقی این است: چرا TCP را تعمیر نکردند؟ پاسخ این است که TCP در هسته هر سیستم‌عامل، هر مسیریاب، هر فایروال، هر متعادل‌کننده بار و هر میان‌افزار (middlebox) در اینترنت پیاده‌سازی شده است. تغییر رفتار TCP نیازمند به‌روزرسانی میلیاردها دستگاه است. برخی از آن دستگاه‌ها دهه‌ها قدمت دارند و هرگز به‌روزرسانی نخواهند شد. میان‌افزارهای شبکه — دستگاه‌هایی که ترافیک را بازرسی، مسیریابی و فیلتر می‌کنند — رفتار TCP را فرض می‌کنند و زمانی که TCP تغییر می‌کند، به روش‌های غیرقابل پیش‌بینی خراب می‌شوند. IETF در طول سال‌ها چندین افزونه TCP را امتحان کرد و متوجه شد که آنها به سادگی توسط میان‌افزارها در میدان مسدود یا حذف شدند.

UDP، در مقابل، اساساً یک بوم خالی است. این یک پروتکل شلیک و فراموش است بدون وضعیت اتصال ذاتی، ترتیب‌دهی یا قابلیت اطمینان. میان‌افزارها با UDP آنطور که با TCP رفتار می‌کنند دستکاری نمی‌کنند زیرا چیزی برای دستکاری وجود ندارد. ساختن QUIC روی UDP به معنای آن است که QUIC می‌تواند مدیریت اتصال، قابلیت اطمینان، ترتیب‌دهی و کنترل ازدحام خود را در فضای کاربر پیاده‌سازی کند — جایی که می‌توان بدون تغییرات هسته به‌روزرسانی شود — در حالی که همچنان از زیرساخت موجود اینترنت بدون تغییر عبور کند.

QUIC واقعاً چه چیزی را تغییر می‌دهد

اولین بهبود قابل توجه زمان برقراری اتصال است. QUIC دست‌داد انتقال و دست‌داد رمزنگاری TLS 1.3 را در یک رفت و برگشت واحد ترکیب می‌کند. برای یک اتصال اولیه به یک سرور، QUIC قبل از جریان یافتن داده به یک رفت و برگشت نیاز دارد، در مقابل دو یا سه برای TCP+TLS. برای کاربر بازگشتی که قبلاً به سرور متصل شده است، QUIC از ازسرگیری 0-RTT پشتیبانی می‌کند — کلاینت می‌تواند داده برنامه را در اولین بسته، با صفر رفت و برگشت، ارسال کند. بهبود عملکرد در شبکه‌های موبایل که تاخیر بالاست بیشتر مشهود است.

مهاجرت اتصال (Connection migration) مشکل جابجایی موبایل را مستقیماً حل می‌کند. یک اتصال QUIC با یک شناسه اتصال (connection ID) انتخاب‌شده توسط نقطه پایانی شناسایی می‌شود، نه توسط 4-تایی (آدرس IP مبدأ، پورت مبدأ، آدرس IP مقصد، پورت مقصد) که یک اتصال TCP را شناسایی می‌کند. هنگامی که یک تلفن از Wi-Fi به سلولی حرکت می‌کند و آدرس IP جدیدی دریافت می‌کند، اتصالات TCP آن همگی قطع می‌شوند و نیاز به برقراری مجدد دارند. اتصالات QUIC از تغییر IP جان سالم به در می‌برند — کلاینت آدرس جدید خود را اعلام می‌کند و اتصال بدون وقفه ادامه می‌یابد.

جریان‌های مالتی‌پلکس شده بدون هد-آف-لاین بلاکینگ، تعمیر ساختاری است که HTTP/2 به آن نیاز داشت اما نتوانست روی TCP به آن دست یابد. QUIC جریان‌های مستقل متعددی را در یک اتصال پیاده‌سازی می‌کند؛ یک بسته گم‌شده برای جریان A، جریان‌های B، C و D را مسدود نمی‌کند. هر جریان ضمانت ترتیب‌دهی خود را دارد، بنابراین از دست دادن در یک جریان فقط آن جریان را متوقف می‌کند.

واقعیت استقرار

پذیرش سریع‌تر از اکثر انتقال‌های پروتکل در تاریخ اینترنت بوده است، که همچنان «بر حسب سال سنجیده می‌شود». گوگل QUIC را در سال ۲۰۱۵ در کروم مستقر کرد، ابتدا فقط برای سرویس‌های خود گوگل. IETF QUIC و HTTP/3 را در سال ۲۰۲۱ استاندارد کرد. تا سال ۲۰۲۳، داده‌های W3Techs نشان می‌داد که HTTP/3 تقریباً روی ۳۰٪ وب‌سایت‌ها پشتیبانی می‌شود. Cloudflare گزارش می‌دهد که QUIC تقریباً ۳۵-۴۰٪ از ترافیک آن را حمل می‌کند و این نسبت سال به سال به طور پیوسته رشد کرده است.

پذیرش سمت سرور در میان CDNهای بزرگ (Cloudflare، Fastly، Akamai) و ارائه‌دهندگان ابری (AWS CloudFront، Google Cloud) قوی است. اکثر فریم‌ورک‌های وب مدرن و متعادل‌کننده‌های بار از HTTP/3 پشتیبانی می‌کنند. سمت کلاینت پوشش داده شده است: کروم، فایرفاکس، سافاری و اج همه به طور پیش‌فرض از HTTP/3 پشتیبانی می‌کنند، همچنین مرورگرهای موبایل.

هر اتصال QUIC بهتر از TCP عمل نمی‌کند. در اتصالات پهن‌باند ثابت با کیفیت بالا، تفاوت حداقل است. پیاده‌سازی فضای کاربری QUIC به این معنی است که از بهینه‌سازی‌های CPU که TCP در طول دهه‌ها در هسته انباشته کرده است بهره نمی‌برد — سربار پردازش هر بسته بیشتر است، که در اتصالات با توان بالا مهم است. برای انتقال فایل حجیم روی لینک‌های سریع و قابل اعتماد، TCP همچنان رقابتی است.

دستاوردها در سه سناریو بیشتر مشهود است: شبکه‌های موبایل با تاخیر بالا، اتصالاتی که از تغییر آدرس IP جان سالم به در می‌برند، و بارگذاری صفحاتی که شامل بسیاری از درخواست‌های کوچک به سرورهای متعدد است. وب در سال ۲۰۲۶ به شدت به هر سه سناریو وزن می‌دهد، به همین دلیل است که مهاجرت شتاب پایداری داشته است که نسخه‌های قبلی HTTP به آن دست نیافتند.

QUIC هر مشکل حمل و نقل اینترنت را حل نمی‌کند — کنترل ازدحام، بافر بلوت (bufferbloat) و ظرفیت مایل آخر محدودیت‌های واقعی باقی می‌مانند. اما مشکلاتی را که بدون جایگزینی زیرساخت فیزیکی شبکه قابل تعمیر بودند حل می‌کند. این یک پیشرفت معنادار است که از طریق یکی از سریع‌ترین استقرارهای پروتکل در تاریخ IETF ارائه شده است.