QUIC (اتصالات إنترنت UDP السريعة) هو بروتوكول عبر UDP يدعم جميع ميزات TCP و TLS و HTTP / 2 ويحل معظم مشاكلهم. غالبًا ما يُطلق عليه اسم بروتوكول جديد أو "تجريبي" ، لكنه تجاوز المرحلة التجريبية لفترة طويلة: استمر التطوير لأكثر من 7 سنوات. خلال هذا الوقت ، لم يكن لدى البروتوكول الوقت ليصبح معيارًا ، لكنه لا يزال واسع الانتشار. على سبيل المثال ، يتم استخدام QUIC لتسريع حركة المرور وتقليل زمن الوصول في شبكات الهاتف المحمول من قبل عمالقة مثل Google و Facebook ، وقد أعلنت IETF أن تفرع البروتوكول الخاص بها هو الأساس لمعيار HTTP / 3 (على الرغم من استخدام HTTP / 2 مواقع).
مفهوم
تم تطوير QUIC كبديل لبرنامج TCP القديم ، والذي تم تصميمه في الأصل للشبكات السلكية مع نسبة منخفضة من الخسائر. يسلم TCP الحزم بالترتيب ، لذلك عند فقدان حزمة واحدة ، تتم إضافة قائمة الانتظار بأكملها () ، مما يؤثر سلبًا على جودة الاتصال واستقراره. لتجنب الخسائر الهائلة ، تلجأ الشبكات الخلوية إلى استخدام مخازن كبيرة ، مما يؤدي بدوره إلى التكرار واستجابة البروتوكول السلبية الخاطئة (). بالإضافة إلى ذلك ، يقضي TCP الكثير من الوقت في إنشاء اتصال: يتم إرسال طلبات SYN / ACK و TLS بشكل منفصل ، مما يتطلب ثلاث رحلات ذهابًا وإيابًا بدلاً من واحدة ، كما يفعل QUIC.
نظرًا لأن QUIC يجمع بين استبدال TCP وتنفيذ TLS 1.3 ، فإن جميع الاتصالات دائمًا ما تكون مشفرة ، وفك تشفير حركة المرور هذه ليس أسهل مما لو تم تجاوز HTTPS. بالإضافة إلى ذلك ، يتم تنفيذ QUIC على مستوى التطبيق ، مثل كيف سيستغرق الاستبدال الكامل لمكدس TCP خلود.
على الرغم من دعم تعدد الإرسال في HTTP / 2 ، ظلت مشكلة حظر رأس الخط قائمة بسبب الحاجة إلى تسليم الحزم بالترتيب. يتم تنفيذ QUIC أعلى UDP ، لذلك لا يوجد حظر من حيث المبدأ ، وحتى لا تضيع الحزم إلى الأبد ، فهي مرقمة وقد تحتوي على أجزاء من "جيرانها" ، مما يوفر التكرار. بالإضافة إلى ذلك ، يقسم QUIC قائمة انتظار متجانسة إلى عدة خيوط لأنواع مختلفة من الطلبات ضمن اتصال واحد. وبالتالي ، في حالة فقد حزمة ، يمكن أن تواجه قائمة انتظار واحدة مشاكل (على سبيل المثال ، لنقل ملف معين):
استخدام
في البداية ، تم تطوير QUIC داخل Google وكان مصممًا إلى حد كبير للاستخدام داخل الشركة. في عام 2013 ، تم تقديمه إلى IETF للتوحيد القياسي (والذي لا يزال جاريًا) ، والآن يمكن للجميع المشاركة في تطوير البروتوكول من خلال تقديم ما ينقصه. تنظم مجموعة عمل IETF اجتماعات سنوية حيث تتم الموافقة على معيار جديد ومناقشة الابتكارات. يعتبر تطبيق QUIC هذا هو التطبيق الرئيسي وعلى أساسه يتم اعتماد معيار HTTP / 3.
حتى الآن ، فإن إدراج HTTP / 3 كبروتوكول رئيسي غير وارد ، لأنه لم ينته بعد ولا يتم دعمه تقريبًا:
ولكن يمكن تنفيذ QUIC كوسيلة نقل بين التطبيق والخادم ، وهو ما تم إجراؤه بنجاح في Uber:
تعليق أوبر على تنفيذ QUIC
من أجل تضمين QUIC بنجاح وتحسين أداء التطبيق في حالة الاتصال الضعيف ، فقد استبدلنا المكدس القديم (HTTP / 2 عبر TLS / TCP) ببروتوكول QUIC. استخدمنا مكتبة الشبكة من ، والذي يحتوي على نسخة Google الأصلية من البروتوكول - gQUIC. يتم أيضًا تحسين هذا التنفيذ باستمرار لاتباع أحدث مواصفات IETF.
قمنا أولاً بدمج Cronet في تطبيقات Android لإضافة دعم QUIC. تم تنفيذ الدمج بطريقة تقلل من تكلفة الهجرة. بدلاً من استبدال مكدس الشبكات القديم الذي كان يستخدم المكتبة تمامًا ، قمنا بدمج Cronet ضمن إطار OkHttp API. من خلال الدمج بهذه الطريقة ، تجنبنا إجراء تغييرات على مكالمات الشبكة (التي تستخدم ) على مستوى API.
على غرار نهج Android ، قمنا بتطبيق Cronet في تطبيقات Uber iOS من خلال اعتراض حركة مرور HTTP من الشبكة باستخدام . يتعامل هذا التجريد ، المقدم من iOS Foundation ، مع بيانات عنوان URL الخاصة بالبروتوكول ويضمن أنه يمكننا دمج Cronet في تطبيقات iOS الخاصة بنا دون تكاليف ترحيل كبيرة.
مأخوذ من مقالات اوبر
على الواجهة الخلفية ، اكتشفوا اتصالات QUIC من خلال Google Cloud lb ، والتي منذ منتصف 2018.
ليس من المستغرب أن يعمل Google Cloud بشكل رائع مع البروتوكول الذي طورته Google ، ولكن ما هي البدائل؟
إنجن إكس
منذ وقت ليس ببعيد CloudFlare nginx (الذي لا يعرف HTTP / 3 افتراضيًا) باستخدام أداة Quiche الخاصة به. يتوفر التطبيق كملف .patch واحد ، والذي يأتي مع برنامج تعليمي للتثبيت:
curl -O https://nginx.org/download/nginx-1.16.1.tar.gz
tar xvzf nginx-1.16.1.tar.gz
git clone --recursive https://github.com/cloudflare/quiche
cd nginx-1.16.1
patch -p01 < ../quiche/extras/nginx/nginx-1.16.patchهنا يمكنك توصيل الوحدات الخاصة بك إذا لزم الأمر.
./configure
--prefix=$PWD
--with-http_ssl_module
--with-http_v2_module
--with-http_v3_module
--with-openssl=../quiche/deps/boringssl
--with-quiche=../quiche
makeيبقى فقط لتمكين دعم HTTP / 3
events {
worker_connections 1024;
}
http {
server {
# Enable QUIC and HTTP/3.
listen 443 quic reuseport;
# Enable HTTP/2 (optional).
listen 443 ssl http2;
ssl_certificate cert.crt;
ssl_certificate_key cert.key;
# Enable all TLS versions (TLSv1.3 is required for QUIC).
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
# Request buffering in not currently supported for HTTP/3.
proxy_request_buffering off;
# Add Alt-Svc header to negotiate HTTP/3.
add_header alt-svc 'h3-27=":443"; ma=86400';
}
}
في المتصفحات العادية ، لن يعمل الاتصال عبر HTTP / 3 بعد ، ولكن يمكنك القيام بذلك وتشغيله بالعلم --enable-quic، انتقل إلى الخادم الخاص بك أو ، على سبيل المثال ، موقع quic.rocks وشاهد نوع الاتصال في Developer Tools:
بدلا من HTTP / 3 هو مكتوب http2+quic/99، لكنها في الأساس نفس الشيء.
تقنيات أخرى
- كويك يدعم أيضا (التي تتصل بفيسبوك عبر HTTP / 3 بضجة كبيرة) وتقدمية . لا يعرف Apache بعد كيف ، لكن العمل جار .
- تم تحديث 21 يناير
- فقط في اليوم الآخر ، فتحت مايكروسوفت ، حيث لا تتوفر جميع الوظائف من معيار IETF حتى الآن ، ولكن هذا بالفعل تقدم كبير.
اختتام
الاهتمام بـ QUIC غير مستقر ، لكن العمل جار على توحيدها. تظهر التطبيقات الجديدة للبروتوكول كل شهر تقريبًا ، وكل عام يقتنع المزيد والمزيد من المطورين بأن المستقبل ينتمي إلى QUIC. يُسمح حتى بإدراج البروتوكول في الإصدارات المستقبلية من TCP stack ، مما يعني أنه عاجلاً أم آجلاً سينتقل الإنترنت بالكامل إلى اتصالات أكثر استقرارًا وأسرع.
يمكنك الآن إعداد تفاعل QUIC للبنية التحتية الخاصة بك أو حتى إعطائها للمتصفحات - يخططون جميعًا لإضافة دعم البروتوكول ، وستصبح الإحصاءات المحزنة باستخدام caniuse أكثر متعة.
المصدر: www.habr.com