TCP مقابل UDP أو مستقبل بروتوكولات الشبكة

قبل أن تنشئ كل خدمة ما لا يقل عن 1 ميجابايت / ثانية من حركة المرور على الإنترنت ، يطرح السؤال التالي: "كيف؟ عبر TCP أو عبر UDP؟ " في مجالات التطبيق ، بما في ذلك منصات التسليم ، تم تطوير تفضيلات وتقاليد اتخاذ مثل هذه القرارات بالفعل.

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

يمكنك مقارنة الكثير: ARM مع Intel و iOS و Android و Mortal Kombat مع Injustice. واندفع إلى holivar فضاء ، لذا عد إلى موضوع تقديم كميات هائلة من المحتوى متعدد الأشكال.

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


الحذر ، تحت خفض 99 الرسوم التوضيحية والرسوم البيانية وكلها مهمة.

يتم إجراء المقارنة بواسطة رئيس قسم تطوير منصات الفيديو والشرائط في OK Alexander Tobol ( alatobol ). خدمات الفيديو والأخبار تغذية على الشبكة الاجتماعية حسنا - حصريا حول المحتوى وتسليمها إلى جميع منصات العملاء الحالية في أي ظروف سيئة أو ممتازة في الشبكة ، ومسألة كيفية تقديمها - عبر TCP أو UDP - أمر بالغ الأهمية.

TCP مقابل UDP. نظرية الحد الأدنى

للوصول إلى المقارنة ، نحتاج إلى نظرية أساسية صغيرة.



ماذا نعرف عن شبكات IP؟ يتم تقسيم دفق البيانات الذي ترسله إلى حزم ، ويقدم نوع من الصندوق الأسود هذه الحزم إلى العميل. يجمع العميل الحزم ويتلقى دفق البيانات. عادة ما يكون كل هذا شفافًا ولا توجد حاجة للتفكير في المستويات الدنيا.



يُظهر الرسم التخطيطي مكدس TCP / IP و UDP / IP. في الجزء السفلي ، توجد حزم Ethernet ، وحزم IP ، وهناك أيضًا TCP و UDP على مستوى OS. لا تختلف TCP و UDP في هذه المجموعة عن بعضها البعض. يتم تغليفها في حزم IP ، ويمكن للتطبيقات استخدامها. لمعرفة الاختلافات ، تحتاج إلى البحث داخل حزم TCP و UDP.



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

التحدث تقريبًا ، TCP هو بروتوكول تسليم موثوق به ، و UDP بروتوكول غير موثوق.

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

• لماذا تقارن TCP أو ما هو الخطأ في ذلك ؛
• مع ماذا وعلى ماذا يجب أن تقارن TCP ؛
• ما الذي قامت به Google وما القرار الذي اتخذته ؛
• ما ينتظرنا من بروتوكولات الشبكة.

لن تحتوي هذه المقالة على نظرية: مستويات ونماذج OSI ، النماذج الرياضية المعقدة ، رغم أنه يمكن حساب كل شيء من خلالهم. سنقوم بتحليل إلى أقصى حد كيفية لمس الشبكة ليس من الناحية النظرية ، ولكن بأيدينا.

لماذا قارن TCP أو ما هو الخطأ في ذلك

اخترع برنامج التعاون الفني في عام 1974 ، وبعد 20 سنة ، عندما ذهبت إلى المدرسة ، اشتريت بطاقات الإنترنت ، ومحو الرمز ، واتصلت بمكان ما. علاوة على ذلك ، إذا اتصلت من ليلتين إلى 7 في الصباح ، فإن الإنترنت مجاني ، ولكن كان من الصعب الوصول إليه.

مرت 20 سنة أخرى ، وبدأ المستخدمون على الشبكات اللاسلكية المحمولة ينتشرون على المستخدمين "السلكيين" ، بينما لم يتغير TCP من الناحية النظرية.

فاز عالم الهواتف المحمولة ، وظهرت البروتوكولات اللاسلكية ، ولم يتغير برنامج التعاون الفني.

اليوم ، يستخدم 80٪ من المستخدمين شبكة Wi-Fi أو شبكة 3G-4G اللاسلكية.



في الشبكات اللاسلكية ، هناك:

• فقدان الحزمة - يتم فقد حوالي 0.6٪ من الحزم التي نرسلها على طول الطريق ؛
• إعادة ترتيب - إعادة ترتيب الحزم في الأماكن ، في الحياة الحقيقية هي ظاهرة نادرة إلى حد ما ، لكنه يحدث في 0.2 ٪ من الحالات ؛
• ارتعاش - عند إرسال الحزم بالتساوي ووصولها إلى قوائم الانتظار مع تأخير حوالي 50 مللي ثانية.

يخفي TCP بنجاح كل هذه الميزات لنقل البيانات في الشبكات غير المتجانسة منك ، ولا تحتاج إلى الغطس في الداخل.

أدناه على الخريطة متوسط ​​معدل بيانات TCP في روسيا. إذا قمت بإزالة الجزء الغربي ، فمن الواضح أن السرعة تقاس بالكيلوبت أكثر من بالميغابت.



هذا ، في المتوسط ​​، لمستخدمينا (باستثناء الجزء الغربي من روسيا): الإنتاجية 1.1 ميغابت في الثانية ، وفقدان الحزمة بنسبة 0.6 ٪ ، RTT (وقت ذهابا وإيابا) من 200 مللي ثانية.

كيفية حساب RTT

عندما رأيت متوسط ​​200 مللي ثانية ، اعتقدت أن هناك خطأ في الإحصائيات ، وقررت قياس RTT إلى خوادمنا في MSC بطريقة بديلة باستخدام RIPE Atlas. هذا هو نظام لجمع البيانات حول حالة الإنترنت. يتوفر مسبار RIPE Atlas مجانًا.



خلاصة القول هي أنك تقوم بتوصيله بالإنترنت في منزلك وجمع "الكرمة". تعمل لعدة أيام ، والبعض الآخر يلبي بعض طلباتها عليها. ثم يمكنك تعيين المهام المختلفة نفسك. مثال على هذه المهمة: خذ 30 نقطة بطريق الخطأ على الإنترنت ، واطلب قياس RTT ، أي تنفيذ الأمر ping على موقع Odnoklassniki.



الغريب في الأمر ، من بين النقاط العشوائية هناك العديد من هذه التي لديها بينغ 200 إلى 300 مللي.

بشكل عام ، تعتبر الشبكات اللاسلكية شائعة وغير مستقرة (على الرغم من أن هذه الأخيرة عادة ما يتم تجاهلها ، حيث يُعتقد أن TCP يمكنه معالجة هذا):

• أكثر من 80 ٪ من المستخدمين يستخدمون الإنترنت اللاسلكي.
• تتغير معلمات الشبكات اللاسلكية ديناميكيًا ، على سبيل المثال ، على حقيقة أن المستخدم قد تخطى الزاوية ؛
• تتمتع الشبكات اللاسلكية بمعدلات عالية من فقد الحزمة والارتعاش وإعادة الترتيب ؛
• قناة غير متماثلة ثابتة ، تغيير عنوان IP.

يعتمد استهلاك المحتوى على سرعة الإنترنت

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



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

لصالح حقيقة أن سرعة الإنترنت ككل غير كافية ، فإنه يشير إلى أن جميع منشئي التطبيقات الكبيرة والشبكات الاجتماعية وخدمات الفيديو وما إلى ذلك يقومون بتحسين خدماتهم للعمل في شبكة سيئة. بعد 10 كيلو بايت من البيانات المستلمة ، يمكنك الاطلاع على الحد الأدنى من المعلومات في الشريط ، وبسرعة 500 كيلوبايت يمكنك مشاهدة الفيديو.

كيفية تسريع التحميل

في عملية تطوير النظام الأساسي للفيديو ، أدركنا أن TCP ليس فعالًا للغاية في الشبكات اللاسلكية. كيف توصلت إلى هذا الاستنتاج؟

قررنا تسريع التنزيل وفعلنا الحيلة التالية.



قمنا بتنزيل الفيديو من العميل إلى الخادم في عدة تدفقات ، أي ، يتم تقسيم 40 ميغابايت إلى 4 أجزاء من 10 ميغابايت وتحميلها بالتوازي. لقد بدأنا تشغيله على Android وحققنا أنه يتم تحميله بشكل متوازٍ أسرع من اتصال واحد ( العرض التوضيحي في التقرير). الشيء الأكثر إثارة للاهتمام هو أنه عند طرح التنزيلات المتوازية في الإنتاج ، لاحظنا أن سرعة التنزيل في بعض المناطق زادت 3 مرات!

يمكن لأربعة اتصالات TCP بالفعل تحميل البيانات إلى الخادم أسرع 3 مرات.

لذلك قمنا بزيادة سرعة تنزيل الفيديو وخلصنا إلى أن التنزيل يحتاج إلى موازاة.

TCP في شبكات غير مستقرة

يمكن لمس تأثير لا يصدق مع التوازي. يكفي أخذ عداد السرعة لاستلام / إرسال البيانات (على سبيل المثال ، اختبار السرعة) ومُشكل حركة المرور (على سبيل المثال ، مكيف شبكة الاتصال ، إذا كان لديك جهاز Mac) ، فنحن نقيِّد الشبكة على معلمات 1 ميغابت في الثانية للتحميل والتنزيل والبدء في زيادة فقد الحزمة.



يوضح الجدول RTT والخسائر. يمكن أن نرى أنه في حالة فقدان 0 ٪ ، يتم استخدام الشبكة بنسبة 100 ٪.

بحلول التكرار التالي ، نزيد من فقد الحزمة بنسبة 5٪ ، ونرى أن الشبكة تستخدم بنسبة 74٪ فقط. يبدو على ما يرام - مع فقدان الحزمة بنسبة 5 ٪ ، يتم فقدان 26 ٪ من الشبكة. ولكن إذا قمت أيضًا بزيادة مستوى ping ، فسيظل أقل من نصف القناة .

إذا كانت القناة عالية RTT وفقدان كبير للحزم ، فإن اتصال TCP واحد لا يستخدم الشبكة بالكامل.

هناك خدعة أخرى توضح أنك إذا بدأت في استخدام اتصالات TCP المتوازية (يمكنك فقط تشغيل العديد من اختبارات السرعة في نفس الوقت) ، يمكنك رؤية النمو العكسي للاستفادة من القناة.



مع زيادة عدد اتصالات TCP المتوازية ، يصبح استخدام الشبكة مساويًا تقريبًا للإنتاجية ، مطروحًا منه نسبة الخسائر.

وهكذا ، اتضح:

• فازت شبكات المحمول اللاسلكية وهي غير مستقرة.
• لا يستخدم TCP القناة بالكامل في شبكات غير مستقرة.
• يعتمد استهلاك المحتوى على سرعة الإنترنت: فكلما ارتفعت سرعة الإنترنت ، زاد عدد المستخدمين الذين يشاهدون ، ونحب مستخدمينا حقًا ونريدهم أن يشاهدوا المزيد.

من الواضح أنك تحتاج إلى الانتقال إلى مكان ما والنظر في بدائل TCP.

TCP مقابل لا TCP

كيفية مقارنة الحارة؟ هناك خياران.

الخيار الأول - على مستوى IP هناك TCP و UDP ، يمكننا تحمل بعض البروتوكول الآخر من الأعلى. من الواضح ، إذا قمت ببدء تشغيل بروتوكولك الخاص بالتوازي مع TCP و UDP ، فلن يعرف Firewall و Brandmauer وأجهزة التوجيه وبقية العالم المشترك في تسليم الحزمة. نتيجة لذلك ، سيتعين عليك الانتظار لسنوات عندما يتم تحديث جميع المعدات وتبدأ في العمل مع البروتوكول الجديد.

الخيار الثاني هو جعل بروتوكول تسليم البيانات الخاص بك موثوق به بالإضافة إلى UDP غير الموثوق بها. من الواضح ، يمكنك الانتظار لفترة طويلة حتى تضيف Linux و Android و iOS بروتوكولًا جديدًا إلى kernel ، لذلك تحتاج إلى قطع البروتوكول في مساحة المستخدم.

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



سنقوم بتطويرها ، أثناء دراسة كيفية عمل الشبكة.

TCP مقابل UDP عصامي

حسنا ، وعلى ماذا للمقارنة؟

الشبكات مختلفة:

• مع الازدحام ، عندما يكون هناك الكثير من الحزم ويسقط بعضها بسبب ازدحام القنوات أو المعدات.
• عالية السرعة مع رحلة ذهابًا وإيابًا كبيرة (على سبيل المثال ، عندما يكون الخادم بعيدًا نسبيًا).
• غريب - عندما لا يبدو أن هناك شيئًا يحدث على الشبكة ، لكن الحزم لا تزال تختفي ببساطة لأن نقطة الوصول إلى Wi-Fi تقع خلف الحائط.

يمكنك دائمًا لمس ملفات تعريف الشبكة بنفسك: حدد ملفًا شخصيًا واحدًا أو آخر على هاتفك وتشغيل اختبار السرعة.



بالإضافة إلى ملفات تعريف الشبكة ، تحتاج أيضًا إلى تحديد ملف تعريف استهلاك حركة المرور. هنا هي تلك التي استخدمناها:



نظرًا لأنني مسؤول عن الفيديو والدفق ، فإن الملفات الشخصية مناسبة:

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

بالطبع ، تحتاج إلى مقارنة البروتوكولات على HTTP الأكثر شعبية.

HTTP 1.1 و HTTP 2.0

بدا مكدس 2000s القياسي مثل HTTP 1.1 أعلى SSL. الحزمة الحديثة هي HTTP 2.0 و TLS 1.3 ، وكلها أعلى TCP.



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



HTTP 1.1 يعمل مثل هذا: تقديم طلب ، الحصول على البيانات ، تقديم طلب ، الحصول على البيانات.



عادة ما يقاتل المتصفح أو أحد تطبيقات الهاتف المحمول ، أي اتصال لاستقبال الصور والبيانات عن طريق واجهة برمجة التطبيقات (API) ، وتنفذ في وقت واحد طلبًا للحصول على صورة ، وواجهة برمجة التطبيقات (API) ، والفيديو ، وما إلى ذلك.



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

باستخدام HTTP 1.1 ، لا يزال بإمكانك الحصول على ما طلبته ، من الصعب إلغاء التنزيل.

مقبس مأخذ الفرصة الوحيد هو إغلاق الاتصال. ثم سنرى لماذا هذا سيء.

الاختلافات في HTTP 2.0

HTTP 2.0 يحل هذه المشاكل:

• ثنائي، ضغط الرأس؛
• تعدد إرسال البيانات ؛
• تحديد الأولويات.
• الغاء التحميل
• دفع الخادم

لننظر في المزيد من النقاط المهمة بالنسبة لنا.



طلب صورة و API. يتم إعطاء الصورة على الفور ، أعدت API بعد حين. أعطيت API - أعطيت الصورة حتى النهاية. كل هذا يحدث بشفافية. يتم تنزيل المحتوى ذي الأولوية العالية مسبقًا.



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

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

وبالتالي ، سنقارن TCP على مختلف:

• ملفات تعريف الشبكة: Wi-Fi ، 3G ، LTE.
• ملفات تعريف الاستهلاك: الدفق (الفيديو) ، وتعدد الإرسال وتحديد الأولويات مع إلغاء التنزيل (HTTP / 2) لاستقبال محتوى الشريط.

نموذج ضياع

دعنا نبدأ المقارنة بشبكة بسيطة لا يوجد فيها سوى معلمتين: زمن الرحلة وعرض النطاق الترددي.

إن RTT عبارة عن اختبار ping أو وقت دوران الحزمة أو استلام الإقرار أو وقت صدى الاستجابة.

لقياس عرض النطاق الترددي - عرض النطاق الترددي للشبكة - نرسل حزمة من الحزم ونحسب عدد الحزم المرسلة في فترة زمنية معينة.



نظرًا لأننا نعمل مع بروتوكولات موثوقة ، بالطبع ، هناك إقرار - نرسل الحزم ونتلقى تأكيد الاستلام.

مشكلة الإنترنت البطيء

في فجر تطوير خدمة الفيديو الخاصة بنا في عام 2013 ، ذهب صديقي إلى كاليفورنيا وقرر مشاهدة سلسلة جديدة من مسلسله المفضل على Odnoklassniki. كان لديه 250 ميغا بايت RTT ، وواي فاي مثالي 400 ميغابت في الثانية في حرم جوجل ، وقال انه يريد أن يرى سلسلة جديدة في FullHD.

هل تعتقد أنه كان قادرا على مشاهدة الفيديو؟ تعتمد الإجابة على تكوين المخزن المؤقت للإرسال / recv على خوادمنا.



نظرًا لأن لدينا بروتوكول مع الإقرار ، يتم تخزين جميع البيانات التي لم تتلق تأكيداً للتسليم في مخزن مؤقت. إذا اقتصر الإرسال المؤقت على 128 كيلو بايت ، فعندئذ تكون 128 كيلو بايت أقل من RTT ، لا يمكننا الإرسال. وهكذا ، من شبكتنا التي تبلغ مساحتها 400 ميجابت / ثانية ، تبقى 4 ميجابت / ثانية. هذا لا يكفي لمشاهدة الفيديو على الإنترنت في FullHD.

بعد ذلك قمت بسحب حجم المخزن المؤقت ونظرت في كيفية تغير سرعة إخراج مقطع فيديو واحد بالفعل تبعًا للتغير في حجم المخزن المؤقت. قم بإجراء حجز فورًا والذي تم ضبطه تلقائيًا في المخزن المؤقت لـ recv ، أي ما أرسله الخادم ، يمكن للعميل أن يقبل دائما.

وصفة TCP واضحة: إذا قمت بنقل بيانات عالية السرعة عبر مسافات طويلة ، فأنت بحاجة إلى زيادة المخزن المؤقت للإرسال.

يبدو أن كل شيء على ما يرام. يمكنك الانتقال إلى خدمة fast.com ، والتي تقيس سرعة الإنترنت لديك إلى خوادم Netflix. من المكتب حصلت بسرعة 210 ميغابت في الثانية. ثم من خلال صافي المشكل قمت بإعداد شروط المهمة وذهبت إلى هذا الموقع مرة أخرى. السحر - حصلت على 4 ميغابت في الثانية بالضبط.



بغض النظر عن كيفية تحريفها ، لم يتمكن Netflix من الحصول على مخزن مؤقت أكبر من 128 كيلو بايت.

حجم العازلة

لمعرفة حجم المخزن المؤقت الأمثل ، تحتاج إلى فهم ماهية الحزم أثناء التنقل.



هناك حالة الشبكة:

• تم إرسال الحزمتين 1 و 2 بالفعل ، وتم استلام تأكيد لهما ؛
• تم إرسال الحزم 3 و 4 و 5 و 6 ، لكن نتيجة التسليم غير معروفة (الحزم السريعة) ؛
• الحزم الأخرى في قائمة الانتظار.

إذا كان عدد الحزم الموجودة في On-the-fly مساوياً لحجم المخزن المؤقت ، فإنه ليس كبيرًا بما يكفي. في هذه الحالة ، الشبكة تتضور جوعًا ، ولا تستخدم بالكامل.

الوضع العكسي ممكن - المخزن المؤقت كبير جدًا. في هذه الحالة ، يتضخم المخزن المؤقت. لماذا هذا سيء؟



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

حل بسيط هو ضبط حجم المخزن المؤقت تلقائيًا. الآن يتوفر على العديد من العملاء ويعمل مثل هذا.



إذا كان بالإمكان إرسال الكثير من الحزم الآن ، فإن المخزن المؤقت يزداد ، ويزداد نقل البيانات ، ويزداد حجم المخزن المؤقت ، ويبدو أن كل شيء رائع.

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

إذا كتبنا بروتوكول UDP الخاص بنا ، فسيكون كل شيء بسيطًا للغاية - لدينا وصول إلى المخزن المؤقت.



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

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

كيف يتم ذلك؟ من المعروف أنه لاستعادة الحزم ، وإدارة التسليم ، وتلقي الإقرارات ، تحتاج إلى بعض التسلسل _ الحزم. Sequence_id يتم كتابتنا فقط للحزم أثناء التنقل ، أي أننا نصدرها فقط عندما نرسل الحزم. يمكن نقل كل شيء آخر في المخزن المؤقت كما نريد حتى تختفي الحزم.

الخلاصة: يجب تكوين المخزن المؤقت TCP بشكل صحيح ، وحساب التوازن حتى لا تتاخم الشبكة وليس تضخيم المخزن المؤقت. بالنسبة لبروتوكول UDP الخاص بك ، كل شيء بسيط - يمكن التحكم في ذلك.

نموذج الشبكة المفقودة

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



يرسل الحزم ، لكل حزمة يتلقى الإقرار. Retransmit timeout (RTO) RTT , .

TCP, 5% , 50%.



retransmit, , . , , Congestion control.

Congestion control

flow control, .

• Flow control — . , , . flow control recv window, . flow control — back pressure , - .
• congestion control . , — .

, : , , , . , congestion control.

TCP window.



flow control congestion control, .

الأمثلة على ذلك:

• TCP window = 1, : acknowledgement, ..
• TCP window = 4, , acknowledgement .

, . initial window TCP = 10.



, , .

?

• , . , .
• : , acknowledgements .
• - , acknowledgements ( ).

.



, , . : , .. , . congestion control, TCP window, , .



congestion control, , — . packet loss — , . , , — , .

, TCP , , congestion control loss-. congestion control loss delay, , .



:

• Cubic — Congestion Control Linux 2.6. : — .
• BBR — Congestion Control, Google 2016 . .

BBR Congestion Control

Cubic BBR feedback.



, — acknowledgement . :

• BBR , , , .
• Cubic .

يوجد أدناه رسم بياني للتأخير مقابل وقت الاتصال ، والذي يوضح ما يحدث في عناصر التحكم في الازدحام المختلفة.



يستشعر BBR أولاً وقت الرحلة ذهابًا وإيابًا ، ويرسل المزيد والمزيد من الحزم ، ثم يدرك أن المخزن المؤقت مسدود ، ويدخل في وضع التشغيل بأقل تأخير.

يعمل المكعب بقوة - يفيض المخزن المؤقت بأكمله ، وعندما يحدث تجاوزات المخزن المؤقت وفقدان الحزمة ، يقلل المكعب من النافذة.

يبدو أنه بمساعدة BBR سيكون من الممكن حل جميع المشاكل ، ولكن هناك غضب في الشبكات - الحزم تتأخر في بعض الأحيان ، ويتم تجميعها في بعض الأحيان في حزم. أنت ترسلهم بتردد معين ، ويأتيون في مجموعات. والأسوأ من ذلك ، عندما تتلقى إشعارات العودة إلى هذه الحزم ، كما أنها "غضب" بطريقة أو بأخرى.

نظرًا لأنني وعدت بإمكانية لمس كل شيء بأيدي ، فإننا بعد ذلك نقوم باختبار الأمر ping ، على سبيل المثال ، موقع HighLoad ++ ، وننظر إلى الأمر ping ونفكر في الاهتزاز بين الحزم.



يمكن أن نرى أن الحزم تأتي بشكل غير متساو ، فإن متوسط ​​الارتعاش حوالي 50 مللي ثانية. بطبيعة الحال ، قد يكون الخطأ BBR.

تعتبر BBR جيدة لأنها تميز بين: فقدان الازدحام الحقيقي ، وفقدان الحزمة بسبب تجاوزات المخزن المؤقت للجهاز ، وفقدان عشوائي بسبب ضعف الشبكة اللاسلكية. لكنه لا يعمل بشكل جيد في حالة غضب عالية. كيف يمكنني مساعدته؟

كيفية جعل السيطرة على الازدحام أفضل

في الواقع ، لا يحتوي TCP على معلومات كافية في الإقرار ، بل يحتوي فقط على الحزم التي شاهدها. هناك أيضًا اعتراف انتقائي ، والذي يوضح الحزم المؤكدة ، والتي لم تصل بعد. لكن هذه المعلومات ليست كافية.



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

لماذا هي فعالة عموما لتضخيم الاعتراف؟ لأن شبكات المحمول غير متماثلة. على سبيل المثال ، عادة مع 3G أو LTE ، يتم تخصيص 70 ٪ من النطاق الترددي لتنزيل البيانات و 30 ٪ للتحميل. تبديل الارسال: تحميل - تحميل ، تحميل - تنزيل ، وأنت لا تؤثر عليه بأي شكل من الأشكال. إذا لم تقم بتفريغ أي شيء ، فهذا ببساطة أمر خامل. لذلك ، إذا كان لديك أي أفكار مثيرة للاهتمام ، وزيادة الاعتراف ، لا تخجل - هذه ليست مشكلة.



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

التي تحكم الازدحام للاختيار

زملاء الدراسة عبارة عن شبكة كبيرة بها عدد كبير من الزيارات: الفيديو ، API ، الصور. وهناك إحصاءات السيطرة على الازدحام التي من الأفضل أن تختار.

BBR فعالة دائمًا للفيديو لأنها تقلل من التأخير. في حالات أخرى ، يستخدم التكعيب عادة - إنه جيد للصور. ولكن هناك خيارات أخرى.



هناك العشرات من خيارات التحكم في الازدحام المختلفة. من أجل اختيار أفضل واحد ، يمكنك جمع إحصاءات عن العميل ومحاولة التحكم في الازدحام واحد أو آخر لأنواع مختلفة من ملفات تعريف التحميل.

على سبيل المثال ، هذا هو تأثير بدء تشغيل BBR على مقطع فيديو.



تمكنا من زيادة خطيرة في عمق المشاهدة. تقول Google إن لديها 10٪ أقل من التخزين المؤقت في المشغل عند استخدام BBR.

عظيم ، ولكن ماذا عن عملائنا؟



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

استنتاجات حول السيطرة على الازدحام:

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

إذا قمت بإجراء بروتوكول UDP ، فلديك حرية أكبر من حيث التحكم في الازدحام.

مضاعفة وترتيب الأولويات

هذا هو الاتجاه الجديد ، الجميع يفعل ذلك الآن. ما هي المشاكل هناك؟ إذا استخدمنا TCP ، فمن المؤكد أن الجميع (أو الجميع تقريبًا) يعرفون حالة حظر خط الرأس.



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

اتضح أن تعدد الإرسال عبر TCP ، إذا كنت تستخدم HTTP 2.0 ، لا يكون فعالًا دائمًا على الشبكات السيئة.

المشكلة التالية هي تورم العازلة.



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

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

إذا قمنا بتعدد الإرسال الخاص بنا ، فيمكننا وضع بيانات متنوعة هناك.



هذا ليس صعبًا ، فما عليك سوى إضافة حزم تحتوي على أرقام إلى المخزن المؤقت. أثناء التنقل - لا تلمس ما تم إرساله بالفعل ، ولكن ما لم يتم إرساله بعد يمكن إعادة ترتيبه. يبدو مثل هذا.



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

تأسيس اتصال

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



للتعامل مع هذا ، دعونا نرى كيف يتم تأسيس الاتصال.



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

من المألوف الآن قياس أرقام زمن الوصول للذاكرة ، للأقراص ، ولشيء آخر. يمكنك قياسها لشبكة 3G أو 4G ومعرفة المدة التي تستغرقها في أسوأ الحالات لإنشاء اتصال TCP مع TLS.



ويمكن أن يكون ثواني! حتى على 4G تصل إلى 700 مللي هو أيضا مهم. لكن TCP لا يمكن أن يعيش بهذه السهولة طوال هذا الوقت.

يعتمد الاتصال على خوارزمية مصافحة TCP ثلاثية الاتجاه الأساسية. قم بإجراء syn ، syn + ack ، ثم صحح الطلب لاحقًا (على اليسار في الرسم التخطيطي).



يوجد TCP Fast Open (يمين). إذا سبق لك استخدام هذا الخادم يدويًا ، فهناك ملف تعريف ارتباط ، يمكنك إرسال طلبك على الفور للحصول على صفر RTT. لاستخدام هذا ، تحتاج إلى إنشاء مأخذ توصيل ، وجعل sendto () البيانات الأولى ، قل أنك تريد FASTOPEN.



يمكن لـ Nginx القيام بكل هذا - ما عليك سوى تشغيله ، وسيعمل كل شيء (أو تشغيله في النواة).

TLS

دعونا نتحقق من أن TLS سيئة.

لقد قمت بتعيين net shaper مرة أخرى لمدة 200 مللي ثانية ، وتتعرضت لضغوط من خلال google.com ورأيت أن RTT = 220 هو المشكل RTT + RTT الخاص بي. ثم تقدمت بطلب عبر HTTP و HTTPS. لقد اكتشفت أنه من خلال HTTP ، يمكن الحصول على استجابة خلال RTT ، أي أن TFO يعمل لصالح Google من جهاز الكمبيوتر الخاص بي. ل HTTPS ، استغرق هذا وقتا أطول.



هذا حمل TLS شائع يتطلب المراسلة من أجل تأسيس اتصال آمن.



للقيام بذلك ، فكروا بالنسبة لنا ، وأضاف TLS 1.3. من السهل أيضًا تضمينه في nginx.



كل شيء يبدو للعمل. ولكن دعونا نرى ما هو على عملاء المحمول لدينا التي تستفيد من كل هذا.

ما الأمر مع العملاء

TCP Fast Open هو شيء رائع. حسب الاحصائيات



هناك العديد من المقالات التي تفيد بأن إنشاء اتصال مضمون لتمرير 10 ٪ بشكل أسرع. لكن على نظام Android 8.1.0 (شاهدت أجهزة مختلفة) لا أحد لديه TFO. على Android 9 ، رأيت TFO على المحاكي ، ولكن ليس على أجهزة حقيقية. IOS هو أفضل قليلا. هنا يمكنك أن ترى ذلك:

sysctl -a | grep fast net.ipv4.tcp_fastopen = 0 

لماذا حدث هذا؟ تم اقتراح TCP Fast Open في عام 2014 ، والآن أصبح بالفعل معيارًا ، وهو مدعوم على نظام Linux وكل شيء رائع. ولكن هناك مشكلة بدأت مصافحة TFO في الانهيار في بعض الشبكات. وذلك لأن بعض مقدمي الخدمات (أو بعض الأجهزة) معتادون على فحص TCP ، والقيام بتحسيناتهم ، ولا يتوقعون أن يكون هناك مصافحة TFO. لذلك ، استغرق تنفيذه الكثير من الوقت ، وحتى الآن ، لا يقوم عملاء الأجهزة المحمولة بتضمينه افتراضيًا ، على الأقل Android.

مع TLS 1.3 ، الذي يعدنا إعداد اتصال RTT صفر أفضل. لم أجد أي أجهزة تعمل بنظام Android وستعمل عليها. لذلك ، صنع Facebook مكتبة Fizz . قبل شهرين ، أصبح متاحًا في المصادر المفتوحة ، ويمكنك سحبه معك واستخدام TLS 1.3. اتضح أنه حتى الأمن يجب أن يتم جره ، لا يظهر شيء في صميم هذا الأمر.



يوضح الرسم البياني استخدام إصدارات مختلفة من Android من قبل عملاء الأجهزة المحمولة لدينا. V 9.x قليلاً جداً - حيث يمكن أن يظهر TFO ، ولم يتم العثور على TLS1.3 في أي مكان آخر.

استنتاجات حول إنشاء اتصال:

• TFO غير متوفر لـ 95٪ من الأجهزة.
• يلزم إحضار TLS1.3 مع نفسه.
• إذا كنت بحاجة إلى تكرار هذا في UDP ، فقم بنقل كل هذا إلى UDP وكرر.

اتضح أن 97 ٪ من الاتصالات التي تم إنشاؤها تستخدم المفتاح الحالي ، أي يتم إنشاء 97 ٪ لصفر RTT ، و 3 ٪ فقط جديدة. يتم تخزين المفتاح على الجهاز لبعض الوقت.

لا يمكن لـ TCP التباهي به. في 5٪ من الحالات كحد أقصى ، إذا قمت بكل شيء بشكل صحيح ، فستتمكن من الحصول على RTT الحقيقي الذي يتحدث عنه الجميع الآن.

تغيير عنوان IP

في كثير من الأحيان ، عندما تغادر المنزل ، ينتقل هاتفك من Wi-Fi إلى 4G.

يعمل TCP كما يلي: لقد تغير عنوان IP - فشل الاتصال.

إذا كتبت بروتوكول UDP الخاص بك ، فهذا أمر بسيط للغاية ، من خلال تطبيق معرف اتصال (CUID) في كل حزمة ، يمكنك التعرف عليه ، حتى لو كان مصدره عنوان IP مختلف.



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

في TCP ، يعد ترحيل IP شيءًا مستحيلًا.

إذا قمت بإجراء UDP الخاص بك ، وجئت إلى نفس الخادم ، فستحتاج إلى القيام ببعض السحر ، وإدراج معرّف الأمان (CID) في كل حزمة ، وستتمكن من استخدام الاتصال الثابت عند تغيير عنوان IP.

إعادة استخدام الاتصال

يقول الجميع أنك بحاجة إلى إعادة استخدام الاتصالات لأن الاتصالات شيء مكلف للغاية.



ولكن هناك مطبات في إعادة استخدام المركبات.



على الأرجح ، يتذكر الكثير من الناس (إن لم يكن ، ثم انظر هنا ) أن ليس لكل شخص عناوين عامة ، ولكن هناك NAT ، الذي عادة ما يخزن التعيين لبعض الوقت على جهاز التوجيه المنزلي. بالنسبة إلى TCP ، من الواضح حجم التخزين ، ولكن بالنسبة لـ UDP ، فإنه غير واضح. تعمل NAT على مهلة ، إذا قمت بقياس هذه المهلة بعناية ، فسنحصل في حوالي 15-30 ثانية على فشل أكثر من 50٪ من الاتصالات.

لا بأس - سنقوم بتقديم حزمة كرة الطاولة لمدة 15 ثانية. بالنسبة للحالات التي لا يزال الاتصال فيها معطلاً ، فهناك IP Migration ، وهو ما يسمح لك بتغيير المنفذ الموجود على جهاز التوجيه.

سرعة الحزمة

هذا شيء مهم للغاية إذا كنت تفعل بروتوكول UDP الخاص بك.



إذا كان الأمر بسيطًا جدًا ، فكلما طالت فترة طويلة في إرسال الحزم إلى الشبكة ، زاد احتمال فقد الحزمة. إذا قمت بتصفية الحزم ، فستكون خسارة الحزم أقل.

هناك العديد من النظريات المختلفة حول كيفية عمل هذا ، لكني أحب هذه النظرية.



هناك 3 اتصالات يتم إنشاؤها في وقت واحد. لديك ما يسمى النافذة الأولية - 10 حزم تم إنشاؤها في نفس الوقت. بالطبع ، قد لا يكون النطاق الترددي كافياً في هذه المرحلة. ولكن إذا قمت بتوزيعها بعناية ، وفصلها ، فسيكون كل شيء على ما يرام ، كما في الشكل الصحيح.

وبالتالي ، إذا قمت بتعيين معدل موحد لإرسال الحزم ، قم بتقليص حجمها ، يصبح احتمال تجاوز سعة المخزن المؤقت لمرة واحدة أقل. لم يثبت هذا ، ولكن من الناحية النظرية اتضح مثل هذا.



عندما تحتاج إلى قطع الحزم (فعل السرعة):

• عند إنشاء نافذة.
• عند تكبير النافذة ، على سبيل المثال ، يوصى بإضافة أكبر عدد ممكن من الحزم لإرسالها إلى RTT / 2. هذا لن يقلل من وقت التسليم ، ولكن يقلل من فقدان الحزمة.
• في حالة فقد الازدحام ، لتقليل النافذة ، تحتاج إلى تشويه الحزم أكثر. 4/5 RTT هو شخصية مختارة تجريبيا.

MTU

عند كتابة بروتوكول UDP ، تأكد من تذكر MTU. MTU هو حجم البيانات التي يمكنك إعادة توجيهها.



نرسل حزمًا من الخادم إلى العميل ، على سبيل المثال ، بحجم 1500. إذا كان هناك جهاز توجيه على المسار الذي لا يدعم حجم وحدة الإرسال الكبرى هذا ، فسيتم تجزئته. تتمثل مشكلة التجزئة الوحيدة في أنه في حالة فقد حزمة واحدة ، سيتم فقد كليهما ، ويجب إعادة إرسال كل هذا. لذلك ، يحتوي TCP على خوارزمية لتحديد MTU - PMTU.



ينظر كل جهاز توجيه إلى وحدة الإرسال الكبرى في واجهته ، ويرسلها إلى عميل واحد ، والآخر يرسلها إلى عميله ، ويعرف الجميع عدد وحدات الإرسال الكبرى لديهم على العميل. ثم يحظر تجزئة العلم ويتم إرسال حزم من حجم MTU. إذا كان شخص ما داخل الشبكة يدرك في هذه اللحظة أن لديه أقل من وحدة الإرسال الكبرى ، فسيقول عبر "ICMP": "عذرًا ، فقد تم فقد الحزمة بسبب الحاجة إلى التجزئة" ، وأشار إلى حجم وحدة الإرسال الكبرى. سوف نقوم بتغيير هذا الحجم ومواصلة الشحن. في أسوأ الحالات ، لدينا حمولة صغيرة هي RTT / 2. هذا في TCP.



إذا كنت لا ترغب في استخدام بروتوكول UDP في بروتوكول UDP ، فيمكنك القيام بما يلي: السماح بالتجزئة عند إرسال البيانات العادية. وهذا يعني إرسال حزم مجزأة - دعهم يعملون. وبالتوازي مع بدء عملية تحظر التجزئة ، سيختار البحث الثنائي وحدة الإرسال الكبرى المثلى ، والتي سنذهب إليها بعد ذلك. هذا ليس فعالًا تمامًا ، لأنه في البداية يبدو أن وحدة الإرسال الكبرى ستعمل على الاحماء.

خيار أصعب هو النظر في توزيع MTU بين عملاء الأجهزة المحمولة.



من جميع العملاء ، أرسلنا حزمًا من مختلف الأحجام مع حظر التفتت. أي إذا لم تصل الحزمة ، فسوف تنخفض ، وينبغي أن يصل أصغر وحدة MTU إلى 100٪. ولكن هناك خسارة صغيرة في الحزمة ، لذلك هناك شريحتان على الرسم البياني:

1. 1350 بايت - بدلاً من 98٪ ، نحصل على تسليم 95٪ على الفور.
2. 1500 بايت - وحدة الإرسال الكبرى ، وبعد ذلك لن يحصل 80٪ من العملاء على هذه الحزم.

في الواقع ، يمكننا أن نقول هذا: نحن نهمل 1-2٪ من عملائنا ، ودعهم يعيشون على حزم مجزأة. ولكن سنبدأ على الفور من ما نحتاج إليه - وهذا من عام 1350.

تصحيح الخطأ (SACK ، NACK ، FEC)

إذا كنت تقوم بعمل بروتوكول ، فأنت بحاجة إلى تصحيح الأخطاء. إذا كانت الحزمة مفقودة (وهذا أمر طبيعي بالنسبة للشبكات اللاسلكية) ، فيجب استعادتها.

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

الخوارزمية التالية هي إعادة الإرسال السريع . هذه كلها خوارزميات TCP ، ولكن يمكن نقلها بسهولة إلى UDP.



عندما تختفي الحزمة ، نستمر في الإرسال - هناك انتقال للحزم الأخرى. في هذا الوقت ، يقول الخادم إنه تلقى الحزمة التالية ، ولكن لم يكن هناك أي حزمة سابقة. للقيام بذلك ، يقدم اعترافًا صعبًا ، وهو يساوي رقم الحزمة + 1 ، ويقوم بتعيين علامة ack المكررة. إنه يرسل هذه البيانات المزدوجة ، وعلى المستوى الثالث عادة ما نفهم أن الحزمة قد اختفت وأرسلتها مرة أخرى.

ما الذي تريد القيام به أنيق آخر ، وما هو غير موجود في TCP وما يقترحونه القيام به في UDP هو تصحيح الخطأ الأمامي .



يبدو أننا إذا علمنا أن الحزم قد تُفقد ، فيمكننا أخذ مجموعة من الحزم وإضافة حزمة XOR إليها وحل المشكلة دون إعادة إرسال إضافية فورًا على العميل عند استلام البيانات. ولكن هناك مشكلة إذا اختفت عدة حزم. يبدو أنه يمكن حلها من خلال حماية التكافؤ ، ريد سولومون ، إلخ.

لقد جربنا بهذه الطريقة ، فقد تبين أن الحزم تختفي في الواقع في حزم.



اتضح أن متوسط ​​الفجوة في الرزمة هو 6. هذه فجوة في الرزمة غير مريحة للغاية - تحتاج إلى الكثير من رموز تصحيح الأخطاء. في الوقت نفسه ، هناك نوع من الذروة عند 11 - لا أعرف السبب ، ولكن الحزم تختفي في بعض الأحيان في حزم من 11. بسبب هذه الفجوة الحزمة ، هذا لا يعمل.

جوجل كما حاول هذا ، الجميع يحلم FEC ، ولكن حتى الآن لم يعمل أحد.

هناك خيار آخر عندما FEC يمكن أن تساعد.



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

لفهم ما إذا كانت هذه البيانات قد وصلت أم لا ، بعد فترة تبدأ في إجراء TLP (اختبار فقدان الذيل) ، اسأل عما إذا كانت النهاية قد تم استلامها. والحقيقة هي أن نقل البيانات قد انتهى ، وأنك لا ترسل أي شيء ، فلن يعمل Fast Retransmit. لإصلاح ذلك ، قم بإجراء TLP.

يمكنك إضافة FEC إلى TLPs. يمكنك إلقاء نظرة على جميع الحزم التي لم تصل ، واعتماد التكافؤ عليها وإرسال TLPs مع بعض حزم التماثل.

هذا كل شيء رائع ، ويبدو أن العمل. ولكن هناك مثل هذه المشكلة.



جمعنا الإحصاءات ، واتضح أن 98 ٪ من الأخطاء يتم إصلاحها من خلال Fast Retransmit. يتم إصلاح الباقي عن طريق إعادة إرسال المهلة ، وأقل من 1 ٪ من خلال TLP. إذا قمت بإصلاح شيء آخر FEC ، فسيكون أقل من 0.5 ٪.

لا يدعم TCP FEC. في UDP ، ليس من الصعب القيام بذلك ، ولكن في الحالة العامة ، خوارزميات الاسترداد TCP القياسية كافية.

أداء

سيكون من الممكن عدم الإضرار بالأداء عن طريق مقارنة TCP مع UDP.

بروتوكول TCP عبارة عن بروتوكول قديم جدًا ولديه الكثير من التحسينات المختلفة ، على سبيل المثال ، LSO (إلغاء تحميل مقطع كبير) ونسخ zerocopy. الآن من أجل UDP كل شيء غير متوفر. لذلك ، فإن أداء UDP هو 20٪ فقط نسبة إلى TCP من نفس الخوادم. ولكن هناك بالفعل حلول جاهزة ( UDP GSO ، zerocopy ) تسمح لنظام Linux بدعم ذلك.

المشكلة الرئيسية التي تدعم تحسين zerocopy و LSO هي فقدان السرعة.

الوقت للسوق أو ما قتل TCP

في الآونة الأخيرة ، عندما أصبحت الشبكات اللاسلكية المحمولة شائعة ، ظهرت العديد من معايير TCP المختلفة: TLP و TFO والتحكم Congestion الجديد و RACK و BBR والمزيد.

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

بالإضافة إلى ذلك ، يتم تحديث عملاء الأجهزة المحمولة لفترة طويلة ، ولا يمكننا تقديم هذه التحديثات. إذا نظرت إلى آخر التحديثات المتوفرة على العميل ، وما هو موجود على الخادم ، يمكنك القول أنه لا يوجد شيء تقريبًا على العميل.



لذلك ، فإن قرار كتابة بروتوكول في مساحة المستخدم ، على الأقل طالما تراكمت كل هذه الميزات ، لا يبدو سيئًا للغاية.



مع TCP ، تم تشغيل الميزات لسنوات. بالنسبة لبروتوكول UDP ، يمكنك ترقية الإصدار حرفيًا في تحديث واحد من العميل والخادم. ولكن ستحتاج إلى إضافة تفاوض الإصدار.

TCP مقابل UDP عصامي. القتال النهائي

• إرسال / recv المخزن المؤقت: يمكن إجراء المخزن المؤقت القابل للتغيير للبروتوكول الخاص بك ، وسوف تكون هناك مشاكل مع سخام المخزن المؤقت مع TCP.
• السيطرة على الازدحام يمكنك استخدام القائمة. في UDP هم أي.
• من الصعب إضافة عنصر التحكم Congestion الجديد إلى TCP ، لأنك تحتاج إلى تعديل الإقرار ، لا يمكنك القيام بذلك على العميل.
• الضرب مشكلة حرجة. يحدث حظر رئيس الخط عندما تفقد حزمة ، لا يمكنك المضاعفة على TCP. لذلك ، HTTP2.0 عبر TCP يجب أن لا تعطي زيادة خطيرة.
• الحالات التي يمكنك فيها الحصول على إعداد اتصال لـ 0-RTT في TCP تكون نادرة للغاية ، حيث تصل إلى 5٪ ، وترتيب 97٪ لـ UDP عصامي.

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

إذا قمت بجمع كل ما هو أكثر أهمية ، فإن UDP ، على الأرجح ، لديه إيجابيات أكثر من سلبيات.



اختر UDP!

اختبار UDP عصامي على المستخدمين

لقد وضعنا معا اختبار البدلاء.



هناك عميل على TCP و UDP. نحن تطبيع حركة المرور من خلال صافي المشكل ، وإرسالها إلى الإنترنت وإلى الخادم. خدمة REST API واحدة ، والثانية مع UDP. ويذهب UDP إلى نفس واجهة برمجة تطبيقات REST داخل مركز البيانات نفسه للتحقق من البيانات. قمنا بجمع ملفات تعريف مختلفة لعملائنا المتنقلين وبدأنا الاختبار .



عند قياس المتوسط ​​عبر البوابة ، رأينا أننا تمكنا من تقليل وقت الاتصال بـ API بنسبة 10٪ ، والصور بنسبة 7٪. زاد نشاط المستخدم بنسبة 1٪ فقط ، لكننا لا نستسلم ، نعتقد أنه سيكون أفضل.



فيما يتعلق بالأحمال ، لدينا الآن حوالي 10 ملايين مستخدم على UDP المصنَّعة ذاتياً ، وحركة مرور تصل إلى 80 جيجابت / ثانية ، و 6 ملايين حزمة في الثانية ، و 20 خادمًا تخدم كل هذا.

قائمة مراجعة UDP

إذا كنت ستكتب البروتوكول الخاص بك ، فأنت بحاجة إلى قائمة مرجعية:

• سرعة.
• اكتشاف MTU.
• إصلاح الأخطاء المطلوبة .
• التحكم في التدفق والسيطرة على الازدحام.
• اختياريًا ، يمكنك دعم ترحيل IP ، TLP سهل.

تذكر أن القنوات غير متماثلة ، وأثناء تلقي البيانات من الخادم ، قد يكون تحميلك خاملاً ، حاول استخدامه.

QUIC

سيكون من غير أمين أن نقول إن جوجل لم يفعل ذلك.



هناك بروتوكول QUIC نفذته Google بموجب HTTP 2.0 ، والذي يدعم نفس الشيء كثيرًا.

لماذا QUIC ليست سريعة جدا

عندما خرجت QUIC ، كان هناك الكثير من الكراهية حول حقيقة أن Google تقول إن كل شيء يعمل بشكل أسرع ، و "لقد قمت بقياسه في المنزل على جهاز كمبيوتر - إنه يعمل بشكل أبطأ".



تحتوي هذه المقالة على مجموعة من الصور والقياسات.

حسنًا ، اتضح أننا قمنا بكل هذا دون جدوى ، هل قاس الناس بالنسبة لنا؟ هناك قياسات المنزل الحقيقي ، حتى مع أمثلة التعليمات البرمجية.



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

ولكن هناك إيجابية ، كما يقولون ، QUIC ليست أفضل ولا أسوأ. وبالتالي ، في الشبكات المثالية ، QUIC يعمل بشكل جيد.

المستقبل

قامت Google مؤخرًا بتسمية HTTP 2.0 أعلى QUIC HTTP 3 ، لا يجب الخلط بينها ، لأن HTTP 2.0 قد يكون أعلى TCP و أعلى QUIC. الآن هو HTTP 3.



كان هناك أيضًا Google QUIC - هذا هو QUIC ، والذي يتم تنفيذه في Chrome ، و iQUIC - وهو QUIC قياسي. لم يتم تطبيق QUIC القياسي في أي مكان ، ولم تصادق خوادم iQUIC القياسية على Google QUIC. الآن يعدون بحل هذه المشكلة ، وسوف تكون متاحة قريباً.

سريع في كل مكان

إذا كنت لا تزال لا تعتقد أن TCP قد مات ، فسأخبرك أنه عند استخدامك Chrome و Android و iOS قريبًا والانتقال إلى google و youtube وما إلى ذلك ، فإنك تستخدم QUIC و UDP ( prooflink ).

QUIC الآن هو:

• 1.9 ٪ من جميع المواقع ؛
• 12 ٪ من جميع حركة المرور ؛
• 30 ٪ من حركة الفيديو على شبكات المحمول.

كيفية التحقق من أنك تستخدم QUIC إذا كنت لا تصدق؟ افتح في Chrome Wireshark. كنت أبحث عن iQUIC ، لم أجدها في أي مكان ، لكن GQUIC يحدث.



يمكنك أيضًا الدخول إلى الإنترنت في متصفحك ومعرفة ما هو GQUIC الموجود هناك.

بعض المزيد من المستقبل

Multipath ينتظر منا قريبا.



عندما يكون لديك عميل متنقل مزود بخدمة Wi-Fi و 3G ، يمكنك استخدام كلتا القناتين. يتم الآن تطوير Multipath TCP وسيتم توفيره قريبًا في نواة Linux. من الواضح ، لن تصل إلى العملاء قريبًا ، وأعتقد أنه يمكن القيام به على UDP بشكل أسرع بكثير.



نظرًا لأننا نجري الكثير من الترجمات لكل منها 3 تيرابايت ، فإننا نستخدم غالبًا تقنيات مثل توزيع CDN و p2p ، عندما يحتاج المحتوى نفسه إلى تسليمه إلى العديد من المستخدمين حول العالم.

في IPv6 ، هناك بث متعدد مع UDP ، مما سيسمح بتوصيل الحزم إلى العديد من المستخدمين المشتركين في آن واحد. لذلك ، أعتقد أنه لن تكون هناك حاجة إلى تقنيات CDN و p2p في المستقبل القريب إذا قدمنا ​​كل المحتوى باستخدام البث المتعدد إلى IPv6.

النتائج

أتمنى أن تفهم:

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

تقرأ كل شيء وحسبت ماذا بعد؟

• قم بتهيئة البروتوكول (TCP ، UDP - لا يهم) للموقف (ملف تعريف الشبكة + ملف تعريف التحميل).
• استخدم وصفات TCP التي أخبرتك بها: TFO ، إرسال / إعادة تخزين مؤقت ، TLS1.3 ، CC ...
• اصنع بروتوكولات UDP إذا كانت لديك الموارد.
• إذا كنت قد فعلت UDP الخاص بك ، تحقق من قائمة الاختيار UDP أنك فعلت كل ما تحتاجه. نسيان أي هراء مثل سرعة ، فإنه لن ينجح.

إذا لم يكن لديك الموارد ، فقم بإعداد البنية الأساسية لـ QUIC. عاجلاً أم آجلاً سوف يأتي إليك.

نحن نحدد المستقبل. نقرر ما البروتوكولات لاستخدام. إذا كنت ترغب في استخدام QUIC - استخدامه ، إذا كنت تريد UDP الخاص بك أو البقاء على TCP - قرر المستقبل بنفسك.

روابط مفيدة

• مليون مكالمة فيديو يوميًا أو "اتصل بأمي!" .
• نكتب بروتوكولنا على رأس UDP .
• بودكاست عن تحسين الشبكة .
• زيادة سرعة نقل البيانات في الشبكات السيئة .

حتى 7 سبتمبر ، لا يزال بإمكانك إرسال طلب إلى Moscow HighLoad ++ ومشاركة كيفية تحضير خدماتك للأحمال الكبيرة. ولكن يتم بالفعل ملء البرنامج تدريجيًا ، من تقارير Odnoklassniki التي تم تلقيها على الهيكل الجديد لمخطط الأصدقاء ، حول تحسين خدمة الهدايا للأحمال الكبيرة وما يجب القيام به إذا قمت بتحسين كل شيء والبيانات لا تصل إلى المستخدم بسرعة كافية.