كويك (شبكات)

قبل الخوض في التفاصيل، كويك هو بروتوكول شبكة ينتمي إلى طبقة النقل متعدد اللأغراض تم تصميمه في البداية من طرف Jim Roskind في Google . تم تطويره و نشره لأول مرة في عام 2012. تم الإعلان عنه في عام 2013 مع توسع التجارب، وتم وصفه في اجتماع IETF .

إضافةً إلى ذلك، يهدف كويك كذلك إلى خفض الوقت الذي تستغرقه عملية الإتصال و النقل، وتقدير عرض النطاق في كل اتجاه لتجنب الازدحام . كما أنه ينقل خوارزميات التحكم في الازدحام إلى مساحة المستعمل في كلتا النقطتين النهائيتين، بدلاً من مساحة النواة. يمكن كذلك توسيع البروتوكول باستخدام تصحيح الأخطاء الأمامي (FEC) لتحسين الأداء بشكل أكبر عندما تكون الأخطاء متوقعة، ويُنظر إلى هذا على أنه الخطوة التالية في تطور البروتوكول. لقد تم تصميمه لتجنب تصلب البروتوكول بحيث يظل قابلاً للتطور، على عكس TCP، الذي عانى من تصلب كبير.

وفي هذا الصدد، على الرغم من أن اسمه كان مقترحًا في البداية باعتباره اختصارًا لـ "اتصالات الإنترنت السريعة عبر UDP"، إلا أن كلمة QUIC في استخدام IETF ليست اختصارًا؛ بل هي ببساطة اسم البروتوكول. يعمل QUIC على تحسين أداء تطبيقات الويب الموجهة للاتصال والتي تستعمل في الوقت الحالي بروتوكول التحكم في الإرسال (TCP). يتم ذلك من خلال إنشاء عدد من الاتصالات المتعددة بين نقطتين نهائيتين باستخدام بروتوكول بيانات المستعمل (UDP)، وهو مصمم لحل محلّ بروتوكول TCP في طبقة النقل للعديد من التطبيقات، وبالتالي يكتسب البروتوكول لقب "TCP/2" في بعض الأحيان.

ومن ناحية أخرى، يعمل كويك جنبًا إلى جنب مع اتصالات HTTP/3 المتعددة، مما يسمح لتدفقات متعددة من البيانات بالوصول إلى نقاط النهاية دون أن يؤثر بعضها على بعض (في حالة فقدان رزم مثلا). في المقابل، يمكن أن يعاني HTTP/2 الذي يستعمل TCP من تأخيرات head-of-line-blocking إذا تم إرسال تدفقات متعددة على اتصال TCP، و فُقدت أو تأخرت أي حزم TCP.

وفي هذا السياق، في سياق دعم حركة مرور HTTP المشفرة ، يلعب QUIC دورًا مشابهًا لـ TCP، ولكن مع زمن انتقال منخفض أثناء إعداد الاتصال و كفاءة أكبر عند استعادة رزم مفقودة أثناء إرسال تدفقات HTTP متعددة عبر اتصال واحد.