لماذا لا ينبغي استخدام تفكير TCP مع UDP
Categories:
- لماذا لا ينبغي استخدام تفكير TCP مع UDP
لماذا لا ينبغي استخدام TCP في تفكير UDP؟
الاختلافات البنيوية
يوجد العديد من المفاهيم في TCP: إنشاء مسار الاتصال، استخدام الموارد، نقل البيانات، نقل موثوق، إعادة إرسال قائم على التأكيد التراكمي، إعادة إرسال بعد انتهاء المهلة، مجموع التحقق، التحكم بالتدفق، التحكم بالازدحام، الحجم الأقصى للقطعة، تأكيد الاختيار، خيار توسيع نافذة TCP، طابع زمن TCP، تسليم البيانات القسري، إنهاء المسار.
كل هذه القدرات، UDP لا يمتلكها أساسًا، فهي لا تمتلك سوى القليل من القدرة على التمييز بين طبقات التطبيق مقارنة بطبقة الربط. مرونة UDP كافية تعني مرونة كبيرة.
إذا كان من الممكن أن يحدث، فسيحدث بالتأكيد
قانون مورفي:
إذا كان هناك أكثر من طريقة واحدة للقيام بشيء ما، وكانت إحدى هذه الطرق ستؤدي إلى كارثة، فمن المؤكد أن شخصًا ما سيختار هذه الطريقة.
عادةً ما يُقال إن UDP مناسب للألعاب/الصوت/الفيديو وغيرها من السيناريوهات، حيث لا تؤثر الحزم الخاطئة قليلة العدد على الأعمال. لماذا UDP مناسب لهذه السيناريوهات؟ استخدام UDP لا يعني بالضرورة أنه الحل الأمثل لهذه السيناريوهات، بل بالتأكيد وجود مشكلات لا يستطيع TCP حلها، مما دفع هذه الخدمات لاختيار بروتوكول UDP البسيط. لا تؤثر الحزم الخاطئة على الأعمال، ولكن تأثير الحزم الخاطئة على TCP و UDP مختلف، UDP لا تهتم بالحزم الخاطئة، بل تهتم بالاتصال الفوري/المستمر. ميزة 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، غالبًا ما نهتم باستهلاك موارد الطرف الخادم، ولكن في الواقع، موارد الشركة المشغلة أيضًا محدودة، وطرف الخادم لا يستجيب للطلب ببساطة، ولكن استقبال الحركة قد استهلك عرض النطاق الترددي، وهذه الموارد عادة ما تكون مملوكة للشركة المشغلة. لذلك، يجب على الشركة المشغلة بالتأكيد التفكير في كيفية حجب هذه الحركة، أي جودة الخدمة لـ UDP. في TCP هناك التحكم بالازدحام، ولكن في UDP، يمكن للشركة المشغلة التحكم في الحركة من خلال فقدان الحزم. في الواقع، تكون الشركة المشغلة أكثر بساطة وخشونة، وتقوم مباشرة بحجب حركة المرور للمنافذ التي تُستخدم لفترة طويلة، أي حجب منافذ UDP. في الاختبار الفعلي لمكالمات WeChat، وجدنا أن كل مكالمة تستخدم عدة منافذ للعميل، وهناك منفذ UDP واحد يتواصل مع 6 منافذ UDP لخادم واحد، ونفترض أن ذلك من أجل مواجهة حجب منافذ UDP للشركة المشغلة.
ملخص
مرونة UDP تظهر في وجود طرق متعددة لتحقيق هدف واحد، وكلها قانونية، طالما يمكن في النهاية إتمام اتصال مستقر، بغض النظر عن كيفية اختلاف تنفيذه عن TCP، فهي “موجودة وبالتالي معقولة”. لذلك، لا يمكننا تطبيق مفاهيم TCP بالكامل على UDP، حتى لو قمنا بخلق تعريف جديد لاتصال UDP من أجل تصميم المنتج، يجب أن نتوقع ونسمح بالخطأ، بالطبع “السماح بالخطأ” هو الوظيفة الأساسية لـ UDP، هذه ميزة لـ UDP، وليست عيبًا، إنها القدرة الأساسية للبروتوكول التي يختارها الخدمة بشكل نشط، وليست عيبًا لا يمكن تجنبه.