لماذا لا ينبغي تطبيق تفكير TCP على UDP؟
Categories:
- لماذا لا ينبغي تطبيق تفكير TCP على UDP؟
لماذا لا ينبغي تطبيق تفكير TCP على UDP؟
الاختلافات الهيكلية
يحتوي TCP على العديد من المفاهيم: إنشاء مسار، استخدام الموارد، نقل البيانات، النقل الموثوق، إعادة الإرسال القائمة على التأكيد التراكمي، إعادة الإرسال عند انتهاء المهلة، التحقق من المجموع، التحكم في التدفق، التحكم في الازدحام، الحجم الأقصى للقطعة، التأكيد الاختياري، خيار توسيع نافذة TCP، طابع وقت TCP، تسليم البيانات القسري، إنهاء المسار.
لا تمتلك UDP معظم هذه القدرات، فهي لا تمتلك سوى قدرة تمييز محدودة لطبقة التطبيق مقارنة بطبقة الربط. مرونة UDP كافية لأن تكون بسيطة ومرنة.
إذا كان يمكن أن يحدث، فسوف يحدث
قانون مورفي:
إذا كان هناك أكثر من طريقة للقيام بشيء ما، وكانت إحدى هذه الطرق ستؤدي إلى كارثة، فسيختار شخص ما بالتأكيد هذه الطريقة.
عادةً ما يُذكر أن UDP مناسب للألعاب/الصوت/الفيديو وغيرها من السيناريوهات، حيث لا تؤثر الحزم الخاطئة بشكل كبير على العمل. لماذا UDP مناسب لهذه السيناريوهات؟ استخدام UDP في هذه السيناريوهات لا يعني بالضرورة أنه الحل الأمثل، بل بالضرورة وجود مشكلات لا يستطيع TCP حلها، ما جعل هذه الخدمات تختار بروتوكول UDP البسيط. لا تؤثر الحزم الخاطئة على العمل بشكل كبير، وهذا يعني أن UDP لا يهتم بالحزم الخاطئة كما يفعل TCP، بل يهتم أكثر بالزمن الحقيقي/الاستمرارية. ميزة UDP هي أنها لا تهتم بالعوامل التي يهتم بها TCP، وهذه العوامل تؤثر على الزمن الحقيقي.
في تنفيذ الكود، يحتاج UDP فقط إلى إنشاء مقبس واحد، وربطه بمنفذ واحد، ثم يمكن البدء في الإرسال والاستقبال. عادةً عندما يتم استخدام المقبس، يتم استخدام المنفذ أيضًا.
لذلك يمكنني استخدام UDP بهذه الطرق:
- إرسال حزم عشوائية إلى منافذ عشوائية لأي IP لرؤية أي منفذ لديه استجابة.
- يقوم الطرف أ بإرسال حزمة الطلب من منفذ A إلى منفذ B للطرف ب، ثم يستخدم الطرف ب منفذ C لإرسال الحزمة المستجيبة إلى منفذ D للطرف أ.
- يقوم الطرف أ بإرسال حزمة الطلب من منفذ A إلى منفذ B للطرف ب، ثم يوكل الطرف ب إلى الطرف ج لإرسال الحزمة المستجيبة من منفذ C إلى منفذ D للطرف أ.
- يقوم الطرف أ بإرسال حزمة الطلب من منفذ A إلى منفذ B للطرف ب، ولكن يقوم بتعديل IP المصدر في الحزمة المرسلة إلى IP الخاص بالطرف ج، وسيقوم الطرف ب بإرسال الحزمة المستجيبة إلى الطرف ج.
- يتفق الطرفان على استخدام 10 منافذ UDP لكل منهما، ويقومان بالاستقبال والإرسال في نفس الوقت.
هذه الطرق لا يمكن تنفيذها في TCP، ولكن في بروتوكول UDP، طالما يمكن فعل ذلك، فسيفعلها شخص ما. لذا فإن تطبيق بعض تفكير TCP على UDP هو تفكير مثالي، والواقع غالبًا لا يمكن تعداده بالكامل.
حزمة UDP بسيطة جدًا، وتُستخدم بشكل مرن، ولا تملك في الأصل مفهوم الاتصال، ويجب تعريف اتصال UDP بنفسك. بعد تجربة بعض طرق التعريف، لم أتمكن من تحقيق دقة كاملة في تحديد اتجاه الاتصال، وهنا يجب قبول بعض التسامح، ففي الأصل لا يوجد تعريف لاتصال UDP، وعندما يكون تعريف各方 لاتصال UDP غير متسق، فمن المؤكد أن السلوك سيكون مختلفًا عن التوقعات.
منظور العميل لـ UDP
غالبًا ما تنتج الأعمال مثل الصوت/الفيديو فقدانًا في الحزم، ولكن طرق فقدان الحزم المختلفة لها تأثيرات مختلفة على العمل. على سبيل المثال، هل 30% من الحزم المفقودة تحدث بشكل موحد، أم تفقد بالكامل في فترة زمنية معينة، يكون لها تأثيرات واضحة على التجربة. من الواضح أننا نتوقع فقدانًا أكثر انتظامًا. ومع ذلك، لا يوجد في UDP طريقة للتحكم في التدفق لمنع ذلك، لذا فإن طرق فقدان الحزم تختلف. على الرغم من أن اتصال UDP غالبًا ما يوصف بأنه “尽力而为”، إلا أن طرق مختلفة من “尽力” تحقق نتائج مختلفة.
منظور مزود الخدمة لـ UDP
إذا كان الهجوم على TCP، فإن العميل يحتاج إلى بعض التكلفة، وإنشاء اتصال، وصيانته، أي أن المهاجم يحتاج إلى دفع ثمن معين. أما في هجوم UDP، فإن تكلفة المهاجم أقل بكثير، وإذا كان المهاجم يريد استهلاك عرض نطاق الخدمة، فإن UDP طريقة جيدة. على سبيل المثال، إذا اشترى الخدمة 100GB من عرض النطاق الترددي دون قيود السرعة، ولكن قدرة المعالجة فقط 10MB في الثانية، بينما سرعة الاستقبال 1GB في الثانية، فإن 90% من حركة المرور غير فعالة، ولكن هذه الحركة ليست مجانية. يجب على مزود الخدمة تجنب حدوث مثل هذه الحالة.
منظور مزود الخدمة لـ UDP
يتطلب إكمال اتصال واحد العديد من الطرفيات وقنوات الاتصال، وغالبًا ما يُهتم بالطرف الخادم والعميل، ولكن منظور مزود الخدمة مهم أيضًا. في هجمات DDoS، غالبًا ما نهتم باستهلاك موارد الخادم، ولكن في الواقع موارد مزود الخدمة محدودة أيضًا، لا يستجيب الخادم للطلبات ببساطة، ولكن استقبال الحركة قد استهلك بالفعل عرض النطاق الترددي، وهذه الموارد عادة ما تكون تابعة لمزود الخدمة. نحن غالبًا نستخدم مقياس “معدل فقد الحزم” في اختبار الضغط، وهذا المقياس يعبر عن فقد الحزم في سلسلة الاتصال الكاملة، وليس فقط فقد الحزم في الخادم. يفقد مزود الخدمة الحزم أيضًا. من منظور مزود الخدمة، اشترى الخادم عرض نطاق ترددي بسرعة 1MB/s، ولكن العميل يرسل بسرعة 1GB/s، ولا يدفع أي من الطرفين مقابل تكلفة حركة المرور المهدرة، بل يتحمل مزود الخدمة هذه التكلفة. لذلك، من المؤكد أن مزود الخدمة سيحاول حجب هذه الحركة، أي جودة الخدمة لـ UDP. في TCP يوجد التحكم في الازدحام، ولكن في UDP يمكن لمزود الخدمة التحكم في الحركة عن طريق فقد الحزم. في الواقع، يكون مزود الخدمة أبسط وأكثر وحشية، ويحجب الحركة من المنافذ المستخدمة لفترة طويلة، أي حجب منفذ UDP. في الاختبار الفعلي لمكالمات WeChat، وجدنا أن كل مكالمة تستخدم العميل عدة منافذ،有一个 منفذ UDP واحد يتفاعل مع 6 منافذ UDP من نفس الخادم، ونفترض أن السبب هو التعامل مع حجب منفذ UDP من قبل مزود الخدمة.
ملخص
مرونة UDP تعني أنه عند تحقيق هدف ما، هناك طرق متعددة للتنفيذ، وكلها قانونية، طالما يمكن في النهاية تحقيق اتصال مستقر، بغض النظر عن مدى اختلاف تنفيذه عن TCP، فهو “موجود لأنه معقول”. وبالتالي، لا يمكننا تطبيق مفاهيم TCP بالكامل على UDP، حتى لو أنشأنا تعريف اتصال UDP جديد من أجل تصميم المنتج، يجب أن نتوقع ونسمح بالخطأ، ففي النهاية “السماح بالخطأ” هو الوظيفة الأساسية لـ UDP، وليس عيبًا فيها، بل هو القدرة الأساسية للبروتوكول التي يختارها الخدمة بشكل نشط، وليس عيبًا لا مفر منه.