UDP مقابل TCP، ما مدى سرعته؟[مغلق]

Question

لتبادل رسائل البروتوكول العام، والذي يمكن أن يتحمل بعض فقدان الحزم.ما مدى كفاءة UDP مقارنة بـ TCP؟

Answer 1

يعد UDP أسرع من TCP، والسبب البسيط هو أن حزمة الإقرار غير الموجودة (ACK) الخاصة به تسمح بتدفق مستمر للحزم، بدلاً من TCP الذي يتعرف على مجموعة من الحزم، ويتم حسابها باستخدام حجم نافذة TCP ووقت الرحلة ذهابًا وإيابًا (RTT) ).

لمزيد من المعلومات أوصي بالبساطة، ولكنها مفهومة للغاية شرح Skullbox (TCP مقابل.UDP)

Answer 2

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

وعلى نطاق أوسع، فإن سلوك TCP هذا هو ما يمنع الإنترنت من الانغلاق على "انهيار الازدحام".

الأشياء التي تميل إلى دفع التطبيقات نحو UDP:

• دلالات التسليم الجماعي:من الممكن إجراء توصيل موثوق لمجموعة من الأشخاص بكفاءة أكبر بكثير من الإقرار من نقطة إلى نقطة في بروتوكول TCP.

• التسليم خارج الطلب:في الكثير من التطبيقات، طالما أنك تحصل على جميع البيانات، فلا يهمك الترتيب الذي تصل إليه؛يمكنك تقليل زمن الوصول على مستوى التطبيق من خلال قبول حظر خارج الترتيب.

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

ولكن حتى لو كنت تهتم بالأداء، فربما لا ترغب في استخدام UDP:

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

• أنت الآن غير صديق للشبكة، مما قد يسبب مشاكل في البيئات المشتركة.

• والأهم من ذلك، أن جدران الحماية سوف تمنعك.

من المحتمل أن تتمكن من التغلب على بعض مشكلات أداء TCP وزمن الوصول عن طريق "ربط" اتصالات TCP المتعددة معًا؛يقوم بروتوكول iSCSI بذلك للالتفاف على التحكم في الازدحام على شبكات المنطقة المحلية، ولكن يمكنك أيضًا القيام بذلك لإنشاء قناة رسائل "عاجلة" ذات زمن وصول منخفض (سلوك TCP "العاجل" معطل تمامًا).

Answer 3

في بعض التطبيقات، يكون TCP أسرع (إنتاجية أفضل) من UDP.

هذا هو الحال عند القيام بالكثير من عمليات الكتابة الصغيرة بالنسبة لحجم وحدة الإرسال الكبرى.على سبيل المثال، قرأت تجربة تم فيها إرسال دفق من 300 حزمة بايت عبر Ethernet (1500 بايت MTU) و كان TCP أسرع بنسبة 50% من UDP.

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

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

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

Answer 4

مع تحمل الخسارة

هل تقصد "مع تحمل الخسارة"؟

في الأساس، UDP ليس "متسامحًا مع الخسارة".يمكنك إرسال 100 حزمة إلى شخص ما، وقد يحصل على 95 حزمة فقط، وقد يكون بعضها بترتيب خاطئ.

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

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

ولحسن الحظ، قام بعض الأشخاص الأذكياء جدًا بذلك، وأطلقوا عليه اسم TCP.

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

Answer 5

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

Answer 6

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

Answer 7

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

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

Answer 8

عند الحديث عن "ما هو الأسرع" - هناك جانبان مختلفان تمامًا على الأقل:الإنتاجية والكمون.

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

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

بعد أي فقدان للحزمة، سينتظر TCP إعادة الإرسال لمدة 200 مللي ثانية على الأقل (ثانية واحدة لكل فقرة 2.4 من RFC6298، لكن التطبيقات العملية الحديثة تميل إلى تقليلها إلى 200 مللي ثانية).علاوة على ذلك، باستخدام TCP، حتى تلك الحزم التي وصلت إلى المضيف الوجهة - لن يتم تسليمها إلى تطبيقك حتى يتم استلام الحزمة المفقودة (أي يتم تأخير الاتصال بالكامل بمقدار 200 مللي ثانية تقريبًا) - راجع للشغل، هذا التأثير، المعروف باسم Head-of - حظر الخط، هو أمر متأصل في جميع التدفقات المطلوبة الموثوقة، سواءً كان TCP أو UDP الموثوق + المطلوب.لجعل الأمور أسوأ - إذا فقدت الحزمة المعاد إرسالها أيضًا، فسنتحدث عن تأخير قدره ~ 600 مللي ثانية (بسبب ما يسمى بالتراجع الأسي، إعادة الإرسال الأولى هي 200 مللي ثانية، والثانية هي 200 * 2 = 400 مللي ثانية).إذا كانت قناتنا تعاني من فقدان الحزمة بنسبة 1% (وهو أمر ليس سيئًا وفقًا لمعايير اليوم)، ولدينا لعبة تحتوي على 20 تحديثًا في الثانية - فستحدث مثل هذه التأخيرات البالغة 600 مللي ثانية في المتوسط ​​كل 8 دقائق.وبما أن 600 مللي ثانية أكثر من كافية لقتلك في لعبة سريعة الوتيرة - حسنًا، فهي سيئة جدًا للعب.هذه التأثيرات هي بالضبط السبب الذي يجعل مطوري الألعاب يفضلون UDP على TCP.

ومع ذلك، عند استخدام UDP لتقليل زمن الاستجابة - من المهم أن تدرك أن مجرد "استخدام UDP" لا يكفي للحصول على تحسين كبير في زمن الاستجابة، فالأمر كله يتعلق بكيفية استخدام UDP.على وجه الخصوص، في حين أن مكتبات RUDP عادةً ما تتجنب "التراجع الأسي" وتستخدم أوقات إعادة إرسال أقصر - إذا تم استخدامها كتدفق "مرتب وموثوق"، فلا يزال يتعين عليها أن تعاني من حظر رأس الخط (لذلك في حالة وجود تدفق مزدوج فقدان الحزمة، بدلاً من 600 مللي ثانية، سنحصل على حوالي 1.5*2*RTT - أو لمدة 80 مللي ثانية RTT جيدة جدًا، إنه تأخير ~ 250 مللي ثانية، وهو تحسن، ولكن لا يزال من الممكن القيام بعمل أفضل).من ناحية أخرى، إذا تم استخدام التقنيات التي تمت مناقشتها في http://gafferongames.com/networked-physics/snapshot-compression/ و/أو http://ithare.com/udp-from-mog-perspective/#low-latency-compression ، من الممكن إزالة حظر رأس الخط تمامًا (لذلك بالنسبة لخسارة الحزمة المزدوجة للعبة ذات 20 تحديثًا في الثانية، سيكون التأخير 100 مللي ثانية بغض النظر عن RTT).

وكملاحظة جانبية - إذا كان لديك حق الوصول فقط إلى TCP ولكن لا يوجد UDP (كما هو الحال في المتصفح، أو إذا كان العميل الخاص بك وراء واحد من 6-9٪ من جدران الحماية القبيحة التي تحظر UDP) - هناك يبدو لتكون وسيلة لتنفيذ UDP-over-TCP دون تكبد الكثير من فترات الاستجابة، راجع هنا: http://ithare.com/almost-zero-additional-latency-udp-over-tcp/ (تأكد من قراءة التعليقات أيضًا (!)).

Answer 9

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

Answer 10

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

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

Answer 11

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

Answer 12

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

Answer 13

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

SCTP

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

• من أجل تسليم الرسائل
• إعادة الإرسال التلقائي للرسائل المفقودة، مع المعلمات المحددة من قبل المستخدم

إذا كان أيًا من هذا مطلوبًا لتطبيقك الخاص.

إحدى المشكلات في هذا هي أن إنشاء الاتصال عملية معقدة (وبالتالي عملية بطيئة)

أشياء أخرى مماثلة

• https://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol

شيء تجريبي آخر مماثل

• https://en.wikipedia.org/wiki/QUIC

يحاول هذا أيضًا تحسين المصافحة الثلاثية لـ TCP وتغيير التحكم في الازدحام للتعامل بشكل أفضل مع الخطوط السريعة.

Answer 14

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

Answer 15

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

ثلاثة أشياء أريد إضافتها إلى المناقشة:

1. باستطاعتك العثور هنا مقالة جيدة جدًا حول TCP مقابل TCP.UDP في سياق تطوير اللعبة.
2. بالإضافة إلى ذلك، com.iperf (com.jperf تعزيز IPERF مع واجهة المستخدم الرسومية) هي أداة لطيفة للغاية للإجابة على سؤالك بنفسك عن طريق القياس.
3. لقد قمت بتطبيق معيار في بايثون (انظر هذا السؤال SO).في متوسط ​​10^6 تكرارات، يكون الفرق في إرسال 8 بايت حوالي 1-2 ميكروثانية لـ UDP.