پروتکل UDP هرگز کار نخواهد کرد

بسیاری از شرکت‌ها، اپراتور‌ها و سازمان‌ها ترافیک UDP خارج از پورت ۵۳ (استفاده شده برای DNS) را از آنجایی که امروزه بیشتر در جهت حمله‌ها مورد سو‌ءاستفاده قرار می‌گیرد مسدود و یا محدود می‌کنند. همچنین به طور خاص، برخی از پروتکل‌های UDP موجود و سرور‌های پیاده‌سازی شده‌ی حاضر برای آنها در برابر حملات تقویت شده و بسیط که در آن یک حمله کننده می‌تواند ترافیک سنگینی را سمت یک هدف بی‌گناه مورد هدف‌گیری قرار می‌دهد آسیب پذیر و قابل حمله بوده است.

پروتکل QUIC یک کاهش‌دهنده‌ی‌‌ داخلی در برابر چنین حملات تقویت شده‌ای دارد، بدین ترتیب که بسته‌ اولیه بایست حداقل ۱۲۰۰ بایت باشد و با این محدودیت که یک سرور اجازه ندارد در ازای هر پاسخ بیش از سه برابر از حجم درخواست را ارسال کند بدون آنکه ابتدا در پاسخ از سمت کاربر بسته‌ای دریافت کند.

پروتکل UDP در کرنل کند است

که به نظر درست می‌رسد، حداقل امروزه در ۲۰۱۸. ما نمی‌توانیم به ضرس قاطع بگوییم که این مسأله چگونه توسعه می‌یابد و چقدر از آن نتیجه‌ی سالیان در دیدرسِ توسعه دهندگان نبودنِ کیفیت انتقال در UDP است.

برای اکثر کاربران این کندی هرگز قابل مشاهده نمی‌باشد.

پروتکل QUIC مقدار قابل توجهی CPU مصرف می‌کند

همانند قسمت بالا، دلیل از آن روست که TCP و TLS زمان بیشتری برای بالغ شدن، بهبود یافتن و پشتیبانی سخت افزاری است.

دلایلی وجود دارد که می‌توان انتظار بهبود این مورد را در طول زمان داشت. سوال این است که تا چه اندازه این کارکردِ CPU استفاده‌کنندگان را آزار خواهد داد.

این فقط Google است

نه اینطور نیست. Google مشخصات اولیه را به IETF (کارگروه مهندسی اینترنت) آورد - بعد از آنکه در یک مقیاس بزرگ اینترنتی ثابت کرد راه‌اندازی چنین پروتکلی بر روی بستر UDP در واقع بسیار خوب عمل می‌کند.

از آن موقع، افراد از شرکت‌ها و سازمان‌های متعددی در سازمان تأمین کننده بی‌طرفِ IETF گرد هم آمدند تا یک پروتکل انتقال استاندارد ایجاد کنند. در این کار، کارمندانِ Google بی‌شک حضور داشتند اما در کنارشان تعداد زیادی از کارمندان شرکت‌های دیگر نیز نقش داشتند که تلاششان بر این بود تا جایگاه پروتکل‌های انتقال در اینترنت را به جلو ببرند، از جلمه Mozilla، Fastly، Cloudflare، Akamai، Microsoft، Facebook و Apple.

این پیشرفت بسیار کوچک است

این یک نقد نیست بلکه یک نظر است. شاید همینطور باشد، شاید این یک پیشرفت خیلی کوچک و با توجه به هنگامی که HTTP/2 ارائه شد باشد.

احتمالاً HTTP/3 در شبکه‌هایی که از دست رفتگی بسته زیاد است بهتر عمل می‌کند، همچنین handshake سریع‌تری را پیشنهاد می‌کند و در نتیجه تأخیر را چه در تشخیص و چه در حقیقت بهبود خواهد یافت. اما آیا این امکانات و مزایا برای ترغیب و تهییج مردم کافیست تا پشتیبانی این پروتکل را روی سرور‌ها و سرویس‌های خود اضافه کنند؟ بی‌شک زمان و اندازه‌گیری کیفی در آینده به ما خواهد گفت!