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

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

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

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

که به نظر درست می‌رسد، حداقل در وهلهٔ نخست. ما نمی‌توانیم به ضرس قاطع بگوییم که این مسئله چگونه توسعه می‌یابد و چقدر از آن نتیجهٔ سالیان سهو و از نظر افتادگی کیفیت انتقال در UDP توسط توسعه‌دهندگان است.

برای اکثر کاربران اما، این کندی هرگز محسوس نیست.

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

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

دلایلی وجود دارد که انتظار می‌رود این موضوع با گذشت زمان بهبود یابد، و در حال حاضر نیز شاهد برخی پیشرفت‌ها در این فضا هستیم. سؤال این است که این استفادهٔ مازاد CPU تا چه اندازه به راه‌اندازان آسیب وارد می‌کند.

این فقط Google است

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

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

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

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

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