يعد بروتوكول QUIC مثيرًا للاهتمام للغاية، ولهذا السبب نحب الكتابة عنه. ولكن إذا كانت المنشورات السابقة حول QUIC ذات طبيعة وأجهزة تاريخية (التاريخ المحلي، إذا أردت)، فنحن اليوم سعداء بنشر ترجمة من نوع مختلف - سنتحدث عن التطبيق الحقيقي للبروتوكول في عام 2019. علاوة على ذلك، نحن لا نتحدث عن البنية التحتية الصغيرة القائمة في ما يسمى بالمرآب، ولكن عن أوبر، التي تعمل في جميع أنحاء العالم تقريبًا. كيف توصل مهندسو الشركة إلى قرار استخدام QUIC في الإنتاج، وكيف أجروا الاختبارات وما رأوه بعد طرحه في الإنتاج - أسفل القطع.
الصور قابلة للنقر. استمتع بالقراءة!
تتمتع أوبر بنطاق عالمي، حيث تتواجد في 600 مدينة، يعتمد التطبيق في كل منها بشكل كامل على الإنترنت اللاسلكي من أكثر من 4500 مشغل خلوي. يتوقع المستخدمون ألا يكون التطبيق سريعًا فحسب، بل في الوقت الفعلي - ولتحقيق ذلك، يحتاج تطبيق Uber إلى زمن استجابة منخفض واتصال موثوق للغاية. للأسف، ولكن المكدس لا يعمل بشكل جيد في الشبكات اللاسلكية الديناميكية والمعرضة للخسارة. لقد أدركنا أنه في هذه الحالة، يرتبط الأداء المنخفض بشكل مباشر بتطبيقات TCP في نواة نظام التشغيل.
لحل المشكلة قدمنا طلبنا ، وهو بروتوكول حديث لتعدد إرسال القنوات يمنحنا المزيد من التحكم في أداء بروتوكول النقل. حاليا فريق العمل توحيد QUIC كما .
بعد اختبارات مكثفة، توصلنا إلى أن تنفيذ QUIC في تطبيقنا سيؤدي إلى تقليل زمن الوصول مقارنة بـ TCP. لاحظنا انخفاضًا بنسبة 10-30% في حركة مرور HTTPS في تطبيقات السائق والركاب. لقد منحتنا QUIC أيضًا تحكمًا شاملاً في حزم المستخدم.
في هذه المقالة، نشارك خبرتنا في تحسين TCP لتطبيقات Uber باستخدام حزمة تدعم QUIC.
أحدث التقنيات: TCP
اليوم، يعد TCP بروتوكول النقل الأكثر استخدامًا لتوصيل حركة مرور HTTPS على الإنترنت. يوفر TCP دفقًا موثوقًا من البايتات، وبالتالي يتعامل مع ازدحام الشبكة وفقدان طبقة الارتباط. يرجع الاستخدام الواسع النطاق لـ TCP لحركة مرور HTTPS إلى انتشار TCP في كل مكان (يحتوي كل نظام تشغيل تقريبًا على TCP)، وتوافره في معظم البنية التحتية (مثل موازنات التحميل، ووكلاء HTTPS وشبكات CDN)، والوظائف الجاهزة المتوفرة على معظم المنصات والشبكات تقريبًا.
يستخدم معظم المستخدمين تطبيقنا أثناء التنقل، ولم تكن فترات استجابة TCP قريبة من متطلبات حركة مرور HTTPS في الوقت الفعلي. ببساطة، لقد شهد المستخدمون في جميع أنحاء العالم هذا الأمر - يوضح الشكل 1 حالات التأخير في المدن الكبرى:
الشكل 1: يختلف زمن الاستجابة في مدن أوبر الرئيسية.
على الرغم من أن زمن الاستجابة في الشبكات الهندية والبرازيلية كان أعلى منه في الولايات المتحدة والمملكة المتحدة، إلا أن زمن الوصول الخلفي أعلى بكثير من متوسط زمن الاستجابة. وهذا صحيح حتى بالنسبة للولايات المتحدة والمملكة المتحدة.
TCP على أداء الهواء
تم إنشاء TCP لـ سلكي الشبكات، أي مع التركيز على الروابط التي يمكن التنبؤ بها بدرجة كبيرة. لكن، لاسلكي الشبكات لها خصائصها وصعوباتها الخاصة. أولاً، تكون الشبكات اللاسلكية عرضة للخسائر بسبب التداخل وتوهين الإشارة. على سبيل المثال، تكون شبكات Wi-Fi حساسة لموجات الميكروويف والبلوتوث وموجات الراديو الأخرى. تعاني الشبكات الخلوية من فقدان الإشارة () بسبب انعكاس/امتصاص الإشارة من قبل الأشياء والمباني، وكذلك من من المجاورة . وهذا يؤدي إلى المزيد من الأهمية (4-10 مرات) وأكثر تنوعًا وفقدان الحزمة مقارنة بالاتصال السلكي.
لمكافحة تقلبات وخسائر عرض النطاق الترددي، تستخدم الشبكات الخلوية عادةً مخازن مؤقتة كبيرة لتدفقات حركة المرور. وهذا يمكن أن يؤدي إلى طوابير طويلة، مما يعني تأخيرات أطول. في كثير من الأحيان، يتعامل TCP مع هذا الانتظار على أنه إهدار بسبب انتهاء المهلة الممتدة، لذلك يميل TCP إلى الترحيل وبالتالي ملء المخزن المؤقت. تُعرف هذه المشكلة باسم ()، وهذا جدا الإنترنت الحديث.
وأخيرًا، يختلف أداء الشبكة الخلوية حسب شركة الاتصالات والمنطقة والوقت. في الشكل 2، قمنا بجمع متوسط التأخيرات لحركة مرور HTTPS عبر الخلايا ضمن نطاق 2 كيلومتر. تم جمع البيانات لاثنين من شركات الاتصالات الخلوية الكبرى في دلهي، الهند. كما ترون، يختلف الأداء من خلية إلى أخرى. كما أن إنتاجية أحد المشغلين تختلف عن إنتاجية المشغل الثاني. ويتأثر ذلك بعوامل مثل أنماط دخول الشبكة مع مراعاة الوقت والموقع، وتنقل المستخدم، بالإضافة إلى البنية التحتية للشبكة مع مراعاة كثافة الأبراج ونسبة أنواع الشبكات (LTE، 3G، وما إلى ذلك).
الشكل 2. التأخير باستخدام دائرة نصف قطرها 2 كم كمثال. نيودلهي، الهند.
كما أن أداء الشبكات الخلوية يختلف بمرور الوقت. ويبين الشكل 3 متوسط زمن الوصول حسب يوم الأسبوع. ولاحظنا أيضًا اختلافات على نطاق أصغر، خلال يوم وساعة واحدة.
الشكل 3. يمكن أن تختلف التأخيرات الخلفية بشكل كبير بين الأيام، ولكن لنفس المشغل.
يؤدي كل ما سبق إلى عدم فعالية أداء TCP في الشبكات اللاسلكية. ومع ذلك، قبل البحث عن بدائل لـ TCP، أردنا تطوير فهم دقيق للنقاط التالية:
- هل TCP هو السبب الرئيسي وراء زمن الاستجابة في تطبيقاتنا؟
- هل تعاني الشبكات الحديثة من تأخيرات كبيرة ومتنوعة في رحلات الذهاب والإياب (RTT)؟
- ما هو تأثير RTT والخسارة على أداء TCP؟
تحليل أداء برنامج التعاون الفني
لفهم كيفية تحليلنا لأداء TCP، دعونا نلقي نظرة سريعة على كيفية نقل TCP للبيانات من المرسل إلى جهاز الاستقبال. أولاً، يقوم المرسل بإنشاء اتصال TCP، من خلال إجراء اتصال ثلاثي : يرسل المرسل حزمة SYN، وينتظر حزمة SYN-ACK من جهاز الاستقبال، ثم يرسل حزمة ACK. يتم إنفاق تمريرة ثانية وثالثة إضافية في إنشاء اتصال TCP. يقر المستلم باستلام كل حزمة (ACK) لضمان التسليم الموثوق.
في حالة فقدان حزمة أو ACK، يقوم المرسل بإعادة الإرسال بعد انتهاء المهلة (RTO، ). يتم حساب RTO ديناميكيًا استنادًا إلى عوامل مختلفة، مثل تأخير RTT المتوقع بين المرسل والمستلم.
الشكل 4. يتضمن تبادل الحزم عبر TCP/TLS آلية إعادة الإرسال.
لتحديد كيفية أداء TCP في تطبيقاتنا، قمنا بمراقبة حزم TCP باستخدام لمدة أسبوع على حركة المرور القتالية القادمة من خوادم الحافة الهندية. قمنا بعد ذلك بتحليل اتصالات TCP باستخدام . بالإضافة إلى ذلك، قمنا بإنشاء تطبيق Android الذي يرسل حركة مرور تمت محاكاتها إلى خادم اختبار، ويحاكي حركة المرور الحقيقية قدر الإمكان. تم توزيع الهواتف الذكية المزودة بهذا التطبيق على العديد من الموظفين، الذين قاموا بجمع السجلات على مدار عدة أيام.
وكانت نتائج كلتا التجربتين متسقة مع بعضها البعض. لقد رأينا فترات استجابة RTT عالية؛ وكانت قيم الذيل أعلى بحوالي 6 مرات من القيمة المتوسطة؛ المتوسط الحسابي للتأخير أكثر من ثانية واحدة. كانت العديد من الاتصالات مفقودة، مما أدى إلى قيام TCP بإعادة إرسال 1% من كافة الحزم. وفي المناطق المزدحمة مثل المطارات ومحطات القطارات، شهدنا خسائر بنسبة 3,5%. تلقي هذه النتائج بظلال من الشك على الحكمة التقليدية المستخدمة في الشبكات الخلوية تقليل الخسائر بشكل كبير على مستوى النقل. وفيما يلي نتائج الاختبار من تطبيق "المحاكاة":
مقاييس الشبكة
معنى
RTT، ميلي ثانية [50%، 75%، 95%، 99%]
[350 ، 425 ، 725 ، 2300]
تباعد RTT، ثانية
في المتوسط ~ 1,2 ثانية
فقدان الحزمة على الاتصالات غير المستقرة
المتوسط ~3.5% (7% في المناطق المثقلة بالحمولة)
ما يقرب من نصف هذه الاتصالات تعرضت لخسارة حزمة واحدة على الأقل، معظمها حزم SYN وSYN-ACK. تستخدم معظم تطبيقات TCP قيمة RTO تبلغ ثانية واحدة لحزم SYN، والتي تزيد بشكل كبير في حالة الخسائر اللاحقة. قد تزيد أوقات تحميل التطبيق نظرًا لأن بروتوكول TCP يستغرق وقتًا أطول لإنشاء الاتصالات.
في حالة حزم البيانات، فإن قيم RTO العالية تقلل بشكل كبير من الاستخدام المفيد للشبكة في حالة وجود خسائر عابرة في الشبكات اللاسلكية. لقد وجدنا أن متوسط وقت إعادة الإرسال يبلغ حوالي ثانية واحدة مع تأخير يصل إلى 1 ثانية تقريبًا. تسببت فترات الاستجابة العالية هذه على مستوى TCP في انتهاء مهلات HTTPS وإعادة الطلبات، مما أدى إلى زيادة زمن الوصول للشبكة وعدم كفاءتها.
في حين أن النسبة المئوية الخامسة والسبعين لـ RTT المقاسة كانت حوالي 75 مللي ثانية، فإن النسبة المئوية الخامسة والسبعين لـ TCP كانت حوالي 425 ثوانٍ. يشير هذا إلى أن الخسارة تسببت في أن يأخذ TCP من 75 إلى 3 تمريرات لنقل البيانات بنجاح. قد يكون هذا نتيجة لحساب 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 بإعادة استخدام التراخيص من الاتصالات السابقة، مما يقلل من عدد المصافحات الأمنية. في المستقبل سيدعم 0-RTT، ولكن ستظل هناك حاجة إلى مصافحة TCP ثلاثية الاتجاهات.
- التغلب على حظر HoL. يستخدم HTTP/2 اتصال TCP واحدًا لكل عميل لتحسين الأداء، ولكن هذا قد يؤدي إلى حظر HoL (رأس الخط). يعمل QUIC على تبسيط تعدد الإرسال وتسليم الطلبات إلى التطبيق بشكل مستقل.
- التحكم في الازدحام. يوجد QUIC في طبقة التطبيق، مما يسهل تحديث خوارزمية النقل الرئيسية التي تتحكم في الإرسال بناءً على معلمات الشبكة (عدد الخسائر أو RTT). تستخدم معظم تطبيقات TCP الخوارزمية ، وهو ليس الأمثل لحركة المرور الحساسة لوقت الاستجابة. الخوارزميات التي تم تطويرها مؤخرًا مثل ، وتصميم الشبكة بشكل أكثر دقة وتحسين زمن الوصول. يتيح لك QUIC استخدام BBR وتحديث هذه الخوارزمية عند استخدامها. .
- تجديد الخسائر. يستدعي QUIC اثنين من TLPs () قبل تشغيل RTO - حتى عندما تكون الخسائر ملحوظة للغاية. وهذا يختلف عن تطبيقات TCP. يقوم TLP بإعادة إرسال الحزمة الأخيرة بشكل أساسي (أو الحزمة الجديدة، إذا كانت هناك واحدة) لبدء عملية التجديد السريع. يعد التعامل مع التأخيرات الخلفية مفيدًا بشكل خاص للطريقة التي تدير بها أوبر شبكتها، وتحديدًا لعمليات نقل البيانات القصيرة والمتفرقة والحساسة لزمن الوصول.
- ACK الأمثل. وبما أن كل حزمة لها رقم تسلسلي فريد، فلا توجد مشكلة الحزم عند إعادة إرسالها. تحتوي حزم ACK أيضًا على وقت لمعالجة الحزمة وإنشاء ACK من جانب العميل. تضمن هذه الميزات قيام QUIC بحساب RTT بشكل أكثر دقة. يدعم ACK في QUIC ما يصل إلى 256 نطاقًا ، مما يساعد المرسل على أن يكون أكثر مرونة في خلط الحزم واستخدام وحدات بايت أقل في العملية. إقرار انتقائي () في TCP لا يحل هذه المشكلة في جميع الحالات.
- ترحيل الاتصال. يتم تعريف اتصالات QUIC بواسطة معرف 64 بت، لذلك إذا قام العميل بتغيير عناوين IP، فيمكن الاستمرار في استخدام معرف الاتصال القديم على عنوان IP الجديد دون انقطاع. هذه ممارسة شائعة جدًا لتطبيقات الهاتف المحمول حيث يقوم المستخدم بالتبديل بين شبكة Wi-Fi والاتصالات الخلوية.
بدائل لـ QUIC
لقد نظرنا في طرق بديلة لحل المشكلة قبل اختيار QUIC.
أول شيء حاولناه هو نشر TPC PoPs (نقاط التواجد) لإنهاء اتصالات TCP بالقرب من المستخدمين. بشكل أساسي، تقوم نقاط الاتصال (PoPs) بإنهاء اتصال TCP بجهاز محمول أقرب إلى الشبكة الخلوية وإعادة حركة المرور إلى البنية التحتية الأصلية. من خلال إنهاء TCP بشكل أقرب، يمكننا تقليل RTT والتأكد من أن TCP أكثر استجابة لبيئة لاسلكية ديناميكية. ومع ذلك، فقد أظهرت تجاربنا أن معظم RTT والخسارة تأتي من الشبكات الخلوية وأن استخدام PoPs لا يوفر تحسنًا كبيرًا في الأداء.
لقد نظرنا أيضًا في ضبط معلمات TCP. كان إعداد مكدس TCP على خوادمنا الطرفية غير المتجانسة أمرًا صعبًا لأن TCP لديه تطبيقات متباينة عبر إصدارات نظام التشغيل المختلفة. كان من الصعب تنفيذ ذلك واختبار تكوينات الشبكة المختلفة. لم يكن تكوين TCP مباشرة على الأجهزة المحمولة ممكنًا بسبب نقص الأذونات. والأهم من ذلك، أن ميزات مثل اتصالات 0-RTT وتحسين التنبؤ بـ RTT تعتبر ضرورية لبنية البروتوكول، وبالتالي من المستحيل تحقيق فوائد كبيرة عن طريق ضبط TCP وحده.
أخيرًا، قمنا بتقييم العديد من البروتوكولات المستندة إلى UDP والتي تعمل على استكشاف أخطاء بث الفيديو وإصلاحها - أردنا معرفة ما إذا كانت هذه البروتوكولات ستساعد في حالتنا. ولسوء الحظ، كانت تفتقر بشدة إلى العديد من إعدادات الأمان، وكانت تتطلب أيضًا اتصال TCP إضافيًا للبيانات التعريفية ومعلومات التحكم.
لقد أظهر بحثنا أن QUIC ربما يكون البروتوكول الوحيد الذي يمكنه المساعدة في حل مشكلة حركة المرور على الإنترنت، مع الأخذ في الاعتبار الأمان والأداء.
دمج 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 Balancers
على الجانب الخلفي، يتم توفير إكمال QUIC من خلال البنية التحتية لموازنة Google Cloud Load، والتي تستخدم رؤوس في الردود لدعم 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 استخدمنا وكيلًا عكسيًا ، كان من الصعب العثور على وكيل عكسي مفتوح المصدر لـ QUIC. لقد قمنا ببناء وكيل عكسي لـ QUIC بأنفسنا باستخدام مكدس QUIC الأساسي من Chromium و تحويله إلى الكروم كمصدر مفتوح.
الشكل 6. تتألف مجموعة اختبار الطريق TCP vs QUIC من أجهزة Android المزودة بـ OkHttp وCronet، والوكلاء السحابيين لإنهاء الاتصالات، وخادم المحاكاة.
التجربة 2
عندما قامت Google بتوفير QUIC مع ، استخدمنا نفس المخزون، ولكن مع تعديل واحد: بدلاً من NGINX، استخدمنا موازنات التحميل من Google لإنهاء اتصالات TCP وQUIC من الأجهزة، بالإضافة إلى توجيه حركة مرور HTTPS إلى خادم المحاكاة. يتم توزيع الموازنات في جميع أنحاء العالم، ولكن استخدم خادم PoP الأقرب إلى الجهاز (بفضل تحديد الموقع الجغرافي).
الشكل 7. في التجربة الثانية، أردنا مقارنة زمن استجابة TCP وQUIC: باستخدام Google Cloud واستخدام وكيل السحابة الخاص بنا.
ونتيجة لذلك، كان ينتظرنا العديد من الوحي:
- أدى الإنهاء عبر PoP إلى تحسين أداء TCP. نظرًا لأن الموازنات تنهي اتصالات TCP بالقرب من المستخدمين ويتم تحسينها بشكل كبير، فإن هذا يؤدي إلى انخفاض RTTs، مما يؤدي إلى تحسين أداء TCP. وعلى الرغم من أن QUIC كان أقل تأثرًا، إلا أنه لا يزال يتفوق على TCP من حيث تقليل زمن الوصول (بنسبة 10-30 بالمائة).
- تتأثر ذيول . على الرغم من أن وكيل QUIC الخاص بنا كان بعيدًا عن الأجهزة (زمن استجابة أعلى بنحو 50 مللي ثانية) من موازنات التحميل من Google، إلا أنه قدم أداءً مشابهًا - انخفاض بنسبة 15% في زمن الاستجابة مقابل انخفاض بنسبة 20% في النسبة المئوية الـ 99 لـ TCP. يشير هذا إلى أن انتقال الميل الأخير يمثل عنق الزجاجة في الشبكة.
الشكل 8: تظهر نتائج تجربتين أن QUIC يتفوق بشكل كبير على TCP.
مكافحة حركة المرور
مستوحاة من التجربة، قمنا بتنفيذ دعم QUIC في تطبيقات Android وiOS. لقد أجرينا اختبار A/B لتحديد تأثير QUIC في المدن التي تعمل فيها Uber. بشكل عام، شهدنا انخفاضًا كبيرًا في حالات التأخير في كلا المنطقتين، ومشغلي الاتصالات ونوع الشبكة.
توضح الرسوم البيانية أدناه النسبة المئوية للتحسينات في الأطراف (95 و99 بالمائة) حسب المنطقة الكلية وأنواع الشبكات المختلفة - LTE، 3G، 2G.
الشكل 9. في اختبارات المعركة، تفوقت QUIC على TCP من حيث الكمون.
فقط إلى الأمام
ربما تكون هذه مجرد البداية - فقد أتاح إطلاق QUIC في الإنتاج فرصًا مذهلة لتحسين أداء التطبيق في كل من الشبكات المستقرة وغير المستقرة، وهي:
زيادة التغطية
بعد تحليل أداء البروتوكول على حركة المرور الحقيقية، رأينا أن ما يقرب من 80٪ من الجلسات استخدمت بنجاح QUIC جميع الطلبات، بينما استخدمت 15% من الجلسات مزيجًا من QUIC وTCP. نحن نفترض أن هذا الدمج يرجع إلى انتهاء مهلة مكتبة Cronet مرة أخرى إلى TCP، حيث لا يمكنها التمييز بين حالات فشل UDP الحقيقية وظروف الشبكة السيئة. نحن نبحث حاليًا عن حل لهذه المشكلة بينما نعمل على التنفيذ اللاحق لـ QUIC.
تحسين كويك
تعد حركة المرور من تطبيقات الهاتف المحمول حساسة لوقت الاستجابة، ولكنها ليست حساسة لعرض النطاق الترددي. كما يتم استخدام تطبيقاتنا بشكل أساسي على الشبكات الخلوية. استنادًا إلى التجارب، لا تزال أزمنة الاستجابة مرتفعة على الرغم من استخدام وكيل لإنهاء TCP وQUIC بالقرب من المستخدمين. نحن نبحث بنشاط عن طرق لتحسين إدارة الازدحام وتحسين كفاءة خوارزميات استرداد الخسارة QUIC.
ومن خلال هذه التحسينات والعديد من التحسينات الأخرى، نخطط لتحسين تجربة المستخدم بغض النظر عن الشبكة والمنطقة، مما يجعل نقل الحزم المريح والسلس أكثر سهولة في جميع أنحاء العالم.
المصدر: www.habr.com