😻 🕡 💜 QUIC في العمل: كيف نفذها Uber لتحسين الأداء ⛹🏾 🐳 💱

بروتوكول QUIC مثير للغاية للمشاهدة ، لذلك نحب أن نكتب عنه. ولكن إذا كانت المنشورات السابقة حول QUIC كانت ذات طبيعة وتاريخ (تاريخ محلي ، إذا كنت تحب) ، فسوف يسعدنا اليوم نشر تفسير مختلف - سنتحدث عن التطبيق الفعلي للبروتوكول في عام 2019. لا يتعلق الأمر ببنية تحتية صغيرة قائمة على مرآب مشروط ، ولكن حول Uber ، والذي يعمل في جميع أنحاء العالم تقريبًا. كيف توصل مهندسو الشركة إلى قرار استخدام QUIC في الإنتاج ، وكيف أجروا الاختبارات ، وما رأوه بعد الدخول في الإنتاج - تحت القص.

الصور قابلة للنقر. هل لديك قراءة لطيفة!

تعد Uber نطاقًا عالميًا ، أي 600 مدينة وجود ، حيث يعتمد التطبيق بالكامل على الإنترنت اللاسلكي من أكثر من 4500 مشغل للهاتف المحمول. يتوقع المستخدمون أن يعمل التطبيق ليس فقط بسرعة ، ولكن في الوقت الفعلي - لضمان ذلك ، يحتاج تطبيق Uber إلى زمن انتقال منخفض واتصال موثوق للغاية. للأسف ، لا يشعر مكدس HTTP / 2 بشكل جيد في الشبكات اللاسلكية الديناميكية والمعرضة للخسارة. لقد أدركنا أنه في هذه الحالة ، يرتبط الأداء المنخفض بشكل مباشر بتطبيقات TCP في نواة أنظمة التشغيل.

لحل المشكلة ، قمنا بتطبيق QUIC ، وهو بروتوكول حديث مع تعدد إرسال القناة ، والذي يمنحنا مزيدًا من التحكم في أداء بروتوكول النقل. تقوم مجموعة عمل IETF حاليًا بتوحيد معايير الجودة مثل HTTP / 3 .

بعد اختبارات تفصيلية ، توصلنا إلى أن تطبيق QUIC في طلبنا سيجعل التأخير "الذيل" أقل مقارنة بـ TCP. لاحظنا انخفاضًا في نطاق 10-30٪ لحركة HTTPS على سبيل المثال لتطبيقات السائق والركاب. لقد أعطتنا QUIC أيضًا سيطرة شاملة على الحزم المخصصة.

في هذه المقالة ، نشارك تجربتنا في تحسين TCP لتطبيقات Uber باستخدام مكدس يدعم QUIC.

الكلمة الأخيرة للتكنولوجيا: TCP

اليوم ، يعد TCP بروتوكول النقل الأكثر استخدامًا لتوفير حركة مرور HTTPS على الإنترنت. يوفر TCP دفقًا موثوقًا من وحدات البايت ، وبالتالي التعامل مع ازدحام الشبكة وفقدان طبقة الارتباط. يفسر الاستخدام الواسع النطاق لحركة مرور TCP ل HTTPS في كل مكان (حيث يحتوي كل نظام تشغيل تقريبًا على TCP) ، والتوفر على معظم البنية التحتية (على سبيل المثال ، على موازنات التحميل ، وكلاء HTTPS و CDNs) والوظائف المتوفرة في معظم الأنظمة الأساسية و الشبكات.

يستخدم معظم المستخدمين تطبيقنا أثناء التنقل ، كما أن التأخير في بروتوكول TCP بعيد عن متطلبات الوقت الحقيقي لحركة HTTPS لدينا. ببساطة ، واجه المستخدمون في جميع أنحاء العالم هذا - يوضح الشكل 1 التأخير في المدن الكبيرة:

الشكل 1. يتفاوت حجم التأخير "الذيل" في المدن الرئيسية التي يعمل فيها أوبر.

على الرغم من أنه كان هناك المزيد من التأخير في الشبكات الهندية والبرازيلية في الولايات المتحدة وبريطانيا العظمى ، إلا أن التأخير في الذيل أكبر بكثير من التأخير المتوسط. وهذا صحيح حتى بالنسبة للولايات المتحدة الأمريكية وبريطانيا العظمى.

أداء TCP على الهواء

تم إنشاء TCP للشبكات السلكية ، مع التركيز على الروابط التي يمكن التنبؤ بها جيدًا. ومع ذلك ، فإن الشبكات اللاسلكية لها خصائصها وصعوباتها. أولاً ، تكون الشبكات اللاسلكية عرضة للفقد بسبب التداخل وتخفيف الإشارة. على سبيل المثال ، تعتبر شبكات Wi-Fi حساسة للميكروويفات وبلوتوث وموجات الراديو الأخرى. تعاني الشبكات الخلوية من فقدان الإشارة (فقدان المسير ) بسبب انعكاس / امتصاص الإشارة بواسطة الأجسام والمباني ، وكذلك التداخل من أبراج الخلايا المجاورة. هذا يؤدي إلى أكثر أهمية (4-10 مرات) ومجموعة متنوعة من التأخير ذهابا وإيابا (RTT) وفقدان الحزمة بالمقارنة مع اتصال سلكي.

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

أخيرًا ، يختلف أداء الشبكة الخلوية تبعًا للناقل والمنطقة والوقت. في الشكل 2 ، قمنا بجمع التأخير المتوسط لحركة HTTPS على الخلايا في مدى 2 كيلومتر. يتم جمع البيانات لاثنين من أكبر مشغلي شبكات الهاتف النقال في دلهي ، الهند. كما ترون ، يختلف الأداء من خلية إلى أخرى. أيضا ، أداء المشغل واحد يختلف عن أداء المشغل الثاني. يتأثر هذا بعوامل مثل أنماط الوصول إلى الشبكة ، مع مراعاة الوقت والمكان ، وتنقل المستخدم ، وكذلك البنية التحتية للشبكة ، مع مراعاة كثافة الأبراج ونسبة أنواع الشبكات (LTE ، 3G ، إلخ).

الشكل 2. التأخير للحصول على مثال عن دائرة نصف قطرها 2 كم. دلهي ، الهند.

أيضا ، يختلف أداء الشبكات الخلوية بمرور الوقت. يوضح الشكل 3 التأخير المتوسط حسب يوم الأسبوع. لاحظنا أيضًا اختلافًا على نطاق أصغر - خلال يوم واحد وساعة واحدة.

الشكل 3. يمكن أن تختلف تأخيرات الذيل بشكل كبير في أيام مختلفة ، ولكن مع نفس المشغل.

كل ما سبق يؤدي إلى حقيقة أن أداء TCP غير فعال في الشبكات اللاسلكية. ومع ذلك ، قبل البحث عن بدائل لبرنامج التعاون الفني ، أردنا تطوير فهم دقيق للنقاط التالية:

هل TCP هو السبب الرئيسي لتأخير الذيل في طلباتنا؟
هل للشبكات الحديثة تأخيرات كبيرة ومتنوعة في الرحلات ذهابًا وإيابًا (RTT)؟
ما هو تأثير فقدان أداء RTT و TCP؟

تحليل أداء TCP

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

في حالة فقدان حزمة أو ACK ، يعيد المرسل إعادة الإرسال بعد انتهاء مهلة (RTO ، مهلة إعادة الإرسال ). يتم احتساب RTO ديناميكيًا استنادًا إلى عدة عوامل ، على سبيل المثال ، تأخير RTT المتوقع بين المرسل والمستقبل.

الشكل 4. يتضمن تبادل حزم TCP / TLS آلية إعادة الإرسال.

لتحديد كيفية عمل TCP في تطبيقاتنا ، راقبنا حزم TCP مع tcpdump لمدة أسبوع على حركة القتال القادمة من خوادم الحدود الهندية. ثم قمنا بتحليل اتصالات TCP باستخدام tcptrace . بالإضافة إلى ذلك ، أنشأنا تطبيق Android يرسل حركة مرور مضاهاة إلى خادم اختبار ، يقلد حركة المرور الحقيقية قدر الإمكان. تم تسليم الهواتف الذكية مع هذا التطبيق إلى العديد من الموظفين الذين قاموا بجمع السجلات لعدة أيام.

كانت نتائج كلتا التجربتين متسقة مع بعضها البعض. رأينا تأخير RTT عالية. كانت قيم الذيل أعلى بنحو 6 مرات من القيمة المتوسطة ؛ القيمة الحسابية للتأخيرات - أكثر من ثانية واحدة. فقد العديد من الاتصالات ، مما تسبب في إعادة إرسال TCP بنسبة 3.5٪ من جميع الحزم. في المناطق المزدحمة ، مثل المطارات ومحطات القطار ، لاحظنا خسارة بنسبة 7 ٪. تلقي هذه النتائج بالشكوك على الحكمة التقليدية المتمثلة في أن مخططات إعادة الإرسال المتقدمة المستخدمة في الشبكات الخلوية تقلل إلى حد كبير من فقد النقل. فيما يلي نتائج الاختبار من تطبيق "simulator":

مقاييس الشبكة	معنى
RTT ، مللي ثانية [50٪ ، 75٪ ، 95٪ ، 99٪]	[350 ، 425 ، 725 ، 2300]
تباين RTT ، ثانية	~ 1.2 ثانية المتوسط
فقدان الحزمة في اتصالات غير مستقرة	في المتوسط ~ 3.5 ٪ (7 ٪ في المناطق ذات الازدحام)

ما يقرب من نصف هذه الوصلات بها خسارة واحدة على الأقل للحزم ، معظمها كانت رزم SYN و SYN-ACK. تستخدم معظم تطبيقات TCP قيمة RTO لمدة ثانية واحدة لحزم SYN ، مما يزيد بشكل كبير عن الخسائر اللاحقة. قد يزيد وقت تحميل التطبيق بسبب حقيقة أن TCP سيتطلب المزيد من الوقت لإقامة اتصالات.

في حالة رزم البيانات ، تقلل RTOs العالية الاستخدام المفيد للشبكة إلى حد كبير في ظل وجود خسائر مؤقتة في الشبكات اللاسلكية. وجدنا أن متوسط وقت إعادة الإرسال حوالي ثانية واحدة مع تأخير الذيل ما يقرب من 30 ثانية. تسببت مثل هذه التأخيرات العالية على مستوى TCP في مهل HTTPS وإعادة المحاولات ، مما زاد من الكمون وعدم كفاءة الشبكة.

في حين أن النسبة المئوية 75 من RTT المقاسة كانت حوالي 425 مللي ثانية ، كان المئين 75 ل TCP ما يقرب من 3 ثوان. هذا يشير إلى أن الخسارة أجبرت TCP على المرور من 7 إلى 10 تمريرات من أجل نقل البيانات بنجاح. قد يكون هذا بسبب حساب RTO غير الفعال ، وعدم قدرة TCP على الاستجابة بسرعة لفقدان الحزم الأخيرة في النافذة ، وعدم كفاءة خوارزمية التحكم في الازدحام ، والتي لا تميز بين الخسائر اللاسلكية والخسائر الناتجة عن ازدحام الشبكة. فيما يلي نتائج اختبار خسارة TCP:

إحصائيات خسارة رزم TCP	قيمة
النسبة المئوية للاتصالات مع فقدان حزمة واحدة على الأقل	45٪
نسبة الاتصالات مع الخسارة أثناء إنشاء الاتصال	30٪
نسبة الاتصالات بالخسارة أثناء تبادل البيانات	76٪
توزيع تأخير إعادة الإرسال ، بالثواني [50٪ ، 75٪ ، 95٪ ، 99٪]	[1 ، 2.8 ، 15 ، 28]
توزيع عمليات إعادة الإرسال لحزمة واحدة أو مقطع TCP	[1،3،6،7]

تطبيق سريع

تم تصميم QUIC في الأصل من قبل Google ، وهو بروتوكول نقل حديث ومتعدد الخيوط يعمل على UDP. في الوقت الحالي ، QUIC في طور التوحيد (لقد كتبنا بالفعل أنه ، كما كان ، نسختين من QUIC ، يمكن للفضول متابعة الرابط - تقريبا. المترجم). كما هو موضح في الشكل 5 ، يتم استضافة QUIC ضمن HTTP / 3 (في الواقع ، HTTP / 2 أعلى QUIC - هذا هو HTTP / 3 ، والذي أصبح الآن موحدًا بدرجة كبيرة). يستبدل جزئياً طبقات HTTPS و TCP ، باستخدام UDP لتشكيل الحزم. تدعم QUIC فقط النقل الآمن للبيانات ، لأن TLS مدمجة بالكامل في QUIC.

الشكل 5: تعمل QUIC ضمن HTTP / 3 ، لتحل محل TLS ، والتي تستخدم للعمل ضمن HTTP / 2.

نورد أدناه الأسباب التي أقنعتنا باستخدام QUIC لتعزيز TCP:

إعداد اتصال 0-RTT. QUIC يسمح بإعادة استخدام التراخيص من الاتصالات السابقة ، مما يقلل من عدد المصافحات الأمنية. في المستقبل ، سوف يدعم TLS1.3 0-RTT ، ولكن لا يزال هناك حاجة إلى مصافحة TCP ثلاثية الاتجاه.
التغلب على حجب هول. يستخدم HTTP / 2 اتصال TCP واحد لكل عميل لتحسين الأداء ، ولكن هذا يمكن أن يؤدي إلى كتلة HoL (رأس السطر). QUIC يبسط الإرسال المتعدد ويقدم الطلبات إلى التطبيق بشكل مستقل عن بعضها البعض.
إدارة الازدحام. QUIC في مستوى التطبيق ، مما يسهل عملية تحديث خوارزمية النقل الرئيسية ، التي تتحكم في الإرسال ، بناءً على معلمات الشبكة (مقدار الخسارة أو RTT). تستخدم معظم تطبيقات TCP خوارزمية CUBIC ، وهي ليست الأمثل لتأخير حركة المرور الحساسة. تقوم الخوارزميات المطورة حديثًا مثل BBR بتصميم الشبكة بدقة أكبر وتحسين زمن الوصول. يسمح لك QUIC باستخدام BBR وتحديث هذه الخوارزمية أثناء تحسينها .
تعويض عن الخسائر. تقوم QUIC باستدعاء TLPs ( مسبار فقد الذيل ) قبل إطلاق RTO - حتى عندما تكون الخسائر ملحوظة للغاية. هذا يختلف عن تطبيقات TCP. يعيد TLP إرسال الحزمة الأخيرة (أو الجديدة ، إن وجدت) بشكل أساسي لتشغيل التجديد السريع. تعد معالجة تأخير الذيل مفيدة بشكل خاص لكيفية عمل Uber مع الشبكة ، وتحديداً في عمليات نقل البيانات القصيرة ، العرضية والحساسة للتأخير.
ACK الأمثل. نظرًا لأن كل حزمة لها رقم تسلسلي فريد ، فلا توجد مشكلة في التمييز بين الحزم عند ترحيلها. تحتوي حزم ACK أيضًا على وقت لمعالجة الحزمة وإنشاء ACKs من جانب العميل. تضمن هذه الميزات أن تقوم QUIC بحساب RTT بشكل أكثر دقة. يدعم QUIC ACK ما يصل إلى 256 نطاقًا من NACK ، مما يساعد المرسل على أن يكون أكثر مرونة في تبديل الحزم واستخدام وحدات بايت أقل في هذه العملية. ACK الانتقائي ( SACK ) في TCP لا يحل هذه المشكلة في جميع الحالات.
الهجرة الصدد. يتم تعريف الاتصالات السريعة بمعرف 64 بت ، لذلك إذا قام العميل بتغيير عناوين IP ، فيمكنك الاستمرار في استخدام معرف الاتصال القديم على عنوان IP الجديد ، دون مقاطعة. هذه ممارسة شائعة جدًا لتطبيقات الأجهزة المحمولة عندما ينتقل المستخدم بين شبكة Wi-Fi والاتصالات الخلوية.

بدائل ل QUIC

نظرنا في طرق بديلة لحل المشكلة قبل اختيار QUIC.

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

نظرنا أيضًا في ضبط معلمات TCP. كان تكوين مكدس TCP على خوادم الحافة غير المتجانسة أمرًا صعبًا لأن TCP يحتوي على تطبيقات مختلفة عبر إصدارات نظام تشغيل مختلفة. كان من الصعب تنفيذ هذا واختبار تكوينات الشبكة المختلفة. لم يكن تكوين TCP مباشرة على الأجهزة المحمولة ممكنًا بسبب الافتقار إلى السلطة. والأهم من ذلك ، أن الرقائق مثل الاتصالات مع 0-RTT والتنبؤ المحسّن من RTT ضرورية لبنية البروتوكول ، وبالتالي لا يمكن تحقيق فوائد كبيرة فقط من خلال تكوين TCP.

أخيرًا ، قمنا بتقييم العديد من البروتوكولات التي تستند إلى UDP والتي تعمل على استكشاف أخطاء دفق الفيديو - أردنا معرفة ما إذا كانت هذه البروتوكولات ستساعد في حالتنا. للأسف ، كانت تفتقر إلى العديد من إعدادات الأمان ، كما أنها تحتاج إلى اتصال TCP إضافي للبيانات التعريفية ومعلومات التحكم.

أظهر بحثنا أن QUIC هو البروتوكول الوحيد الذي يمكن أن يساعد في حل مشكلة حركة مرور الإنترنت ، مع مراعاة كل من الأمان والأداء.

الاندماج السريع في المنصة

لدمج QUIC بنجاح وتحسين أداء التطبيق في ظروف الاتصال السيئة ، استبدلنا المكدس القديم (HTTP / 2 عبر TLS / TCP) ببروتوكول QUIC. استخدمنا مكتبة شبكة Cronet من Chromium Projects ، التي تحتوي على الإصدار الأصلي من Google للبروتوكول - gQUIC. كما يتم تحسين هذا التطبيق باستمرار لمتابعة أحدث مواصفات IETF.

أولاً ، قمنا بدمج Cronet في تطبيقات Android لدينا لإضافة دعم QUIC. تم الدمج من أجل تقليل تكاليف الترحيل. بدلاً من استبدال مكدس الشبكة القديم بالكامل الذي استخدم مكتبة OkHttp ، قمنا بدمج Cronet UNDER the OkHttp API framework. من خلال الاندماج بهذه الطريقة ، تجنبنا التغييرات في مكالمات شبكتنا (التي يستخدمها Retrofit ) على مستوى واجهة برمجة التطبيقات.

على غرار نهج أجهزة Android ، قمنا بتطبيق Cronet في تطبيقات Uber لنظام iOS ، حيث اعترضنا حركة مرور HTTP من واجهات برمجة تطبيقات الشبكة باستخدام NSURLProtocol . يقوم هذا التجريد ، الذي توفره iOS Foundation ، بمعالجة بيانات عناوين URL الخاصة بالبروتوكول ويضمن أنه يمكننا دمج Cronet في تطبيقات iOS الخاصة بنا دون تكاليف ترحيل كبيرة.

اكتمل التنفيذ على Google Cloud Balancers

على الجانب الخلفي ، يتم توفير إنهاء QUIC بواسطة البنية التحتية لموازنة تحميل السحاب من Google ، والتي تستخدم رؤوس alt-svc في الردود لدعم QUIC. بشكل عام ، يضيف الموازن رأس alt-svc إلى كل طلب HTTP ويقوم بالتحقق من صحة دعم QUIC للمجال. عندما يتلقى عميل Cronet استجابة HTTP باستخدام هذا العنوان ، فإنه يستخدم QUIC لطلبات HTTP اللاحقة إلى هذا المجال. بمجرد اكتمال الموازن QUIC ، ترسل بنيتنا التحتية هذا الإجراء بشكل صريح عبر HTTP2 / TCP إلى مراكز البيانات الخاصة بنا.

الأداء: النتائج

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

التجربة 1

جرد التجربة:

أجهزة اختبار Android مع مكدسات OkHttp و Cronet للتأكد من أننا نرسل حركة مرور HTTPS عبر TCP و QUIC ، على التوالي ؛
Java, HTTPS- , ;
, , TCP QUIC-. TCP NGINX , QUIC. QUIC , QUIC Chromium .