وضعیت

کارگروه QUIC از اواخر ۲۰۱۶ سخت مشغول تبیین و به کارگیری پروتکل‌ها بوده‌اند و اکنون قرار بر این است که این امر تا تاریخ جولای ۲۰۱۹ به پایان رسیده باشد.

از نوامبر ۲۰۱۸، هنوز آزمایش هم‌کنش‌پذیری بزرگتری در خصوص HTTP/3 انجام نگرفته است - تنها با دو پیاده سازی موجود که هیچ کدام توسط یک مرورگر یا یک نرم افزارِ باز سمتِ کارساز صورت نگرفته اند.

در حال حاضر حدود ۱۵ پیاده سازی QUIC در صفحات ویکی کارگروه QUIC فهرست شده است، اما توانایی هم‌کنش‌پذیری با آخرین نسخه‌ی پیش‌نویسِ تجدید شده راه طولانی‌ای پیش‌رو دارد.

پیاده سازی QUIC به این سادگی نیست و خود پروتکل دائم تغییر کرده است.

کارگزار‌ها

پشتیبانی NGINX از QUIC و HTTP/3 در دست توسعه است و بنا است که در حین چرخه‌ی توسعه NGINX 1.17 توزیع گردد.

هیچ اعلامیه رسمی از طرف Apache در ارتباط با پشتیبانی از QUIC وجود ندارد.

کارخواه‌ها

هیچ یک از عرضه کنندگانِ مرورگرهای بزرگ نسخه‌ای که بتواند از نسخه‌ی QUIC کارگروه مهندسی اینترنت پشتیبانی کند را ارائه نکرده‌اند.

گوگل کروم سال‌هاست که همراه با نسخه‌ی توسعه داده شده‌ی خودش از QUIC عرضه شده است، اما در تعامل با نسخه‌ی کارگروه مهندسی اینترنت مشکل دار و پیاده سازیِ HTTP متفاوتی هم نسبت به HTTP/3 دارد.

شرکت Mozilla در حال توسعه‌ی Neqo است - یک پیاده سازیِ QUIC و HTTP/3 نوشته شده با زبانِ Rust. بناست که Neqo داخل Necko (که یک کتابخانه‌ی شبکه‌ی مورد استفاده در بسیاری از برنامه‌های سمت کارخواهِ مبتنی بر Mozilla است - از جمله Firefox) کار گذاشته شود.

نرم‌افزار curl اولین پشتیبانی از نسخه‌ی آزمایشی HTTP/3 (پیش‌نویسِ ۲۲) را در نشرِ 7.66.0 در تاریخ ۱۱ سپتامبرِ سال ۲۰۱۹ عرضه کرد. برای انجام کار، curl یا از کتابخانه‌ی Quiche توسط Cloudflare یا خانواده‌ی کتابخانه‌های ngtcp2 استفاده می‌کند.

موانع پیاده‌سازی

برای پروتکل QUIC تصمیم گرفته شده تا از TLS 1.3 به عنوان زیربنای رمزگذاری و لایه‌ی امنیت استفاده شود تا از ساخت و تولید یک چیز جدید اجتناب شود و در عوض بر روی یک پروتکل موجود و قابل اعتماد تأکید شود. گرچه، در همین هنگام، کارگروه تصمیم گرفت تا کاربرد TLS (پروتکل امنیتی لایه‌ی انتقال) در QUIC را بهینه سازد، بدین شکل که فقط باید از "پیغام‌های TLS" و نه "رکورد‌های TLS" برای پروتکل استفاده شود.

این تغییر شاید به ظاهر بی‌ضرر باشد، اما در واقع یک مانع قابل توجهی برای بسیاری از پیاده‌سازانِ پشته‌ی QUIC ایجاد کرده است. کتابخانه‌های TLS موجود که از TLS 1.3 پشتیبانی می‌کنند از رابط برنامه‌نویسی کاربردیِ کافی برای دسترسی به این کارکرد و همچنین ایجاد امکان دسترسی به آن برای QUIC برخوردار نیستند. تعدادی از پیاده‌سازانِ QUIC از سازمان‌های بزرگتری می‌آیند که به موازات در حال کار بر روی پشته‌ی امنیت لایه‌ی انتقالِ (TLS) خود هستند، اما به هر حال این برای همه صادق نیست.

بطور مثال OpenSSL متن‌باز بزرگ، هیچ API (رابط برنامه‌نویسی کاربردی) برای این منظور ندارد. به نظر می‌رسد که رسیدگی به این موضوع در درخواستِ انجامِ PR 8797 اتفاق می‌افتد که مقصود معرفی یک رابط برنامه‌نویسی کاربردی بسیار شبیه به برای BoringSSL است.

این موضوع در نهایت موجب موانعِ راه‌ اندازی می‌شود زیرا که پشته‌های QUIC نیاز خواهند داشت که یا خود را بر روی کتابخانه‌های امنیت لایه‌ی انتقالِ دیگر بنا کنند، یا از یک نسخه‌ی جدا و تصحیح شده‌ی OpenSSL استفاده کنند و یا نیازمند بروزرسانی‌ای در نسخه‌ای از OpenSSL درآینده باشند.

بارِ هسته و پردازنده‌ی مرکزی

شرکت‌های Google و Facebook گفته‌‌اند که آنها برای راه اندازی QUIC در مقیاس گسترده تقریباً به دوبرابر میزان CPU ای که برای همان‌مقدار ترافیک به هنگام ارائه‌ی HTTP/2 بر روی TLS استفاده می‌شود نیاز دارند.

برخی توضیحات در این مورد شامل موادر ذیل می‌شود:

• بخش‌های UDP در لینوکس از آنجا که بطور معمول برای انتقال‌های اینچنین پر‌سرعت استفاده نشده‌ است اساساً به هیچ وجه به اندازه‌ی پشته‌ی TCP بهینه نشده است.

• تخلیه‌ی بارِ TCP و TLS به سخت افزار موجود است، اما برای UDP بسیار نادرتر و برای QUIC اساساً ناموجود است.

باور بر این است که کارایی و نیازمندی‌های CPU به مرور زمان بهبود خواهند یافت.