عند طلب الطعام من هاتفك، حتى الوقت المستغرق في التنقل داخل التطبيق يُعد وقتًا ضائعًا.
تُعد Delivery Hero غير معروفة تقريبًا في الولايات المتحدة، التي تهيمن عليها Uber Eats و DoorDash. لكنها شركة ذات انتشار عالمي خارج الولايات المتحدة، مع قاعدة مستخدمين تقدر بـ 60 مليونًا في جميع أنحاء أوروبا وأمريكا اللاتينية وإفريقيا والشرق الأوسط وآسيا. تستحوذ أوبر حاليًا على Delivery Hero مقابل 14.8 مليار دولار، مع خطط لتوحيد الشركة مع Uber Eats.
وبهذا الشراء، ستوسع أوبر عدد الأسواق التي تقدم فيها خدمات طلب الركوب والتوصيل، وإن لم يكن بالضرورة تحت اسم Uber Eats. تدير Delivery Hero مركزيًا تطبيقات منفصلة لمناطق مختلفة، وقد قامت ببناء أو الاستحواذ على جميعها. يمكن للآسيويين طلب أطباق البوك والسلع المتنوعة عبر Foodpanda. ويمكن للأتراك طلب الكباب عبر Yemeksepeti. وفي جميع أنحاء إسبانيا وإيطاليا وبولندا ورومانيا وأوكرانيا والكثير من إفريقيا، يُستخدم تطبيق Glovo لطلب التوصيلات الليلية. وفي أمريكا اللاتينية، يتصل المستخدمون بـ PedidosYa للحصول على ما يحتاجونه من الصيدليات والمطاعم والأسواق القريبة.
تتميز كل هذه المناطق باتصال شبكي متفاوت على نطاق واسع، وهي مشكلة أرادت Delivery Hero تقليلها.
كانت شبكة الميل الأخير هي العائق الأكبر في معظم الأحيان. فالتطبيقات في باكستان، على سبيل المثال، يمكن أن تستغرق ما يقرب من ثانية (عند P90) لإجراء مصافحة آمنة مع الخادم. نظر فريق الهندسة إلى HTTP/3 كوسيلة لخفض، بل وحتى إلغاء، هذا التأخير.
كيف يجعل QUIC بروتوكول HTTP أسرع؟
قدمت فرقة عمل هندسة الإنترنت (IETF) رسميًا الإصدار الثالث من بروتوكول نقل النص التشعبي للإنترنت في عام 2022. HTTP هو بروتوكول طبقة التطبيق الذي يربط المتصفحات والموارد الأخرى المتصلة بالخوادم عبر الإنترنت.
بُنيت الإصدارات السابقة من HTTP على بروتوكول التحكم في الإرسال (TCP)، الذي يوفر تسليمًا مضمونًا وتحكمًا في التدفق. وبالاشتراك مع بروتوكول الإنترنت (IP)، بنى TCP/IP الإنترنت الحديث.
استبدل HTTP/3 بروتوكول TCP بـ Quick UDP Internet Connection (QUIC)، الذي طورته جوجل، لمعالجة بعض البطء الملحوظ في TCP كبروتوكول نقل.
UDP هو اختصار لـ User Datagram Protocol، وعلى عكس TCP، فإنه لا يضمن تسليم الحزم أو التحكم في التدفق.
لكن HTTP/3 القائم على UDP يقلل، وفي بعض الأحيان يلغي، الرحلات ذهابًا وإيابًا اللازمة لتأمين الاتصالات. يمكن للتطبيق تخزين تذكرة جلسة، وفي اتصال لاحق، استخدام قدرة 0-RTT لـ QUIC لبدء إرسال بيانات التطبيق المؤهلة بينما لا تزال المصافحة جارية، بدلاً من انتظار انتهائها.
قال إلفيس تشيديرا: "في الأساس، يمكنك التخلص من تلك الثانية الواحدة" من التأخير التي ابتليت بها الشبكات الأبطأ. وأضاف: "لا تريد أن تدفع تكلفة رحلتين ذهابًا وإيابًا فقط لتبادل البيانات، إذا كان بإمكانك القيام بذلك بشكل أسرع."
وعلى عكس HTTP/2، لا يتوقف HTTP/3 عند فقدان الحزم أو تأخيرها. لا يوجد حجب لمقدمة الصف لأن الحزم تُرسل في تدفقات متعددة، وليس فقط السلسلة الواحدة التي يقدمها HTTP/2.
ما هي التحديات التي واجهت عملية التهيئة؟
وجد تشيديرا أن إعداد HTTP/3 كان سهلاً بشكل مفاجئ. استخدمت Delivery Hero شبكة توصيل المحتوى (CDN) الخاصة بـ Cloudflare لخدمة قاعدة مستخدميها العالمية، لذا تضمن الانتقال إلى HTTP/3 إعادة تهيئة بسيطة.
أثبتت إضافة دعم HTTP/3 إلى العملاء، ومعظمهم من الأجهزة المحمولة، أنها مباشرة تقريبًا. تدعم آبل HTTP/3 منذ iOS 15، ومعظم المتصفحات الأصلية تدعم HTTP/3 بشكل افتراضي.
أثبت أندرويد أنه أكثر تعقيدًا بعض الشيء. استخدم المهندسون مكتبة Cronet من جوجل لمكدس الشبكات، وتم ربطها في البداية بتطبيقات أندرويد الخاصة بهم باستخدام غلاف Cronet Transport for OkHttp لتقليل إعادة كتابة الكود الحالي، الذي كُتب في الأصل لعميل HTTP OkHttp.
بشكل افتراضي، ساعدت Cronet في دعم طرح HTTP/3، مما قلل من فشل طلبات مستوى الشبكة. لكنها جاءت أيضًا مع مشكلة كبيرة: استغرقت المحرك حوالي 800 مللي ثانية للتهيئة عند P90، مما أثر على بعض فوائد سرعة 0-RTT لـ HTTP/3. لذلك، قام الفريق بتشعيب الكود إلى جسر خاص بهم باستخدام مكتبة تسمى OKCronet. كما قاموا ببعض الأعمال الهندسية الإضافية، والتي تضمنت تداخل تهيئة Cronet مع مهام خلفية أخرى.
بشكل عام، خفضوا زمن التأخير عند P95 من 1.2 ثانية إلى 120 مللي ثانية، محققين تحسنًا بمقدار 10 أضعاف في زمن تأخير القراءة.
بشكل عام، نقل فريق الهندسة 95 بالمائة من المستخدمين إلى HTTP/3. الأجهزة التي لم تتمكن من استخدام البروتوكول (بسبب حظر الشبكات لحركة مرور UDP بشكل كبير) عادت تلقائيًا إلى HTTP/2. تم خفض زمن تأخير المصافحة بين التطبيقات والخادم بنسبة 51 بالمائة. وتم خفض زمن استجابة باكستان إلى النصف.
ومع ذلك، بقيت عقبة واحدة. فقد واجهت الشاشات الثانوية في بعض التطبيقات (الصفحات/الشاشات التي ليست الصفحة الرئيسية) مشكلات في زمن التأخير. حدثت هذه المشكلات فقط في أسواق معينة معروفة بأنها عرضة لفقدان الحزم، مثل باكستان.
عزا مهندسو Delivery Hero المشكلة إلى اختيار Cloudflare لخوارزمية التحكم في الازدحام لـ HTTP/3، وهي Cubic، والتي لم تتعامل تاريخيًا مع فقدان الحزم بشكل جيد. اختبر فريق الهندسة بعض حركة المرور الخاصة بهم باستخدام خوادم جوجل المتوافقة مع HTTP/3، والتي تستخدم بروتوكول ازدحام آخر، وهو Bottleneck Bandwidth and Round-trip propagation time (BBR)، ولم تواجه مشكلة في فقدان الحزم.
قال تشيديرا: "تعمل Delivery Hero حاليًا مع Cloudflare لحل مشكلة خوارزمية الازدحام المحددة هذه."
أحيانًا، لن يصل ذلك اللحم بعجين الطازج واللذيذ إلى باب منزلك بالسرعة الممكنة، على الرغم من كل الجهود المبذولة.
ماذا يعني هذا للمستخدم العربي؟
تعمل Delivery Hero في مناطق تشمل إفريقيا والشرق الأوسط، وقد واجهت مشكلات في الاتصال الشبكي في أسواق مثل باكستان، حيث تمكنت من خفض زمن الاستجابة إلى النصف بفضل HTTP/3.
اقرأ الشرح الكامل: دليل: قياس البينج وزمن الاستجابة في الألعاب
