مناقشة NTCP

فيما يلي نقاش حول NTCP الذي جرى في مارس 2007. لم يتم تحديثه ليعكس التنفيذ الحالي. للاطلاع على مواصفات NTCP الحالية، راجع صفحة NTCP2 .

مناقشة NTCP مقابل SSU، مارس 2007

أسئلة NTCP

(مُقتبس من نقاش IRC بين zzz و cervantes)

لماذا يُفضل NTCP على SSU، ألا يحتوي NTCP على overhead أعلى وزمن استجابة أكبر؟ إنه يتمتع بموثوقية أفضل.

ألا تعاني مكتبة التدفق عبر NTCP من مشاكل TCP-over-TCP الكلاسيكية؟ ماذا لو كان لدينا نقل UDP بسيط جداً لحركة البيانات المنشأة من streaming-lib؟ أعتقد أن SSU كان مُعداً ليكون ما يُسمى بنقل UDP البسيط جداً - لكنه أثبت عدم موثوقيته.

تحليل “NTCP يُعتبر ضاراً” بواسطة zzz

تم النشر في Syndie الجديد، 2007-03-25. تم نشر هذا لتحفيز النقاش، لا تأخذه بجدية مفرطة.

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

المناقشة

لدينا حالياً وسيلتا نقل، NTCP و SSU. كما هو مُطبق حالياً، NTCP له “عروض” أقل من SSU لذلك يُفضل، باستثناء الحالة التي يوجد فيها اتصال SSU مُنشأ ولكن لا يوجد اتصال NTCP مُنشأ للنظير.

SSU مشابه لـ NTCP في أنه يطبق الإقرارات والمهلات الزمنية وإعادة الإرسال. ومع ذلك فإن SSU هو كود I2P مع قيود صارمة على المهلات الزمنية والإحصائيات المتاحة حول أوقات الرحلة ذهاباً وإياباً وإعادة الإرسال وما إلى ذلك. يعتمد NTCP على Java NIO TCP، وهو صندوق أسود ويُفترض أنه يطبق معايير RFC، بما في ذلك المهلات الزمنية القصوى الطويلة جداً.

غالبية حركة البيانات داخل I2P تنشأ من streaming-lib (HTTP، IRC، Bittorrent) وهو تطبيقنا لبروتوكول TCP. نظراً لأن النقل على المستوى الأدنى عادةً ما يكون NTCP بسبب العطاءات المنخفضة، فإن النظام يخضع لمشكلة TCP-over-TCP المعروفة والمخيفة http://sites.inka.de/~W1011/devel/tcp-tcp.html ، حيث تقوم طبقتا TCP العليا والسفلى بإعادة الإرسال في آن واحد، مما يؤدي إلى الانهيار.

على عكس سيناريو PPP over SSH الموضح في الرابط أعلاه، لدينا عدة قفزات للطبقة السفلى، كل منها مغطاة برابط NTCP. لذا فإن كل زمن استجابة NTCP عمومًا أقل بكثير من زمن استجابة مكتبة البث للطبقة العليا. هذا يقلل من احتمالية الانهيار.

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

الإصدار .28 زاد من أقصى مهلة زمنية لمكتبة البث من 10 ثوانٍ إلى 45 ثانية مما حسن الأمور بشكل كبير. أقصى مهلة زمنية لـ SSU هي 3 ثوانٍ. أقصى مهلة زمنية لـ NTCP من المفترض أن تكون على الأقل 60 ثانية، وهي التوصية وفقاً لـ RFC. لا توجد طريقة لتغيير معاملات NTCP أو مراقبة الأداء. انهيار طبقة NTCP هو [المحرر: نص مفقود]. ربما ستساعد أداة خارجية مثل tcpdump.

ومع ذلك، عند تشغيل الإصدار .28، فإن معدل الرفع المُبلغ عنه في i2psnark لا يبقى عموماً على مستوى عالٍ. فهو غالباً ما ينخفض إلى 3-4 كيلوبايت/ثانية قبل أن يرتفع مرة أخرى. هذا مؤشر على أنه ما زالت هناك انهيارات في الاتصال.

SSU أيضاً أكثر كفاءة. NTCP له накладные расходы أعلى وربما أوقات رحلة ذهاب وإياب أطول. عند استخدام NTCP فإن نسبة (مخرجات tunnel) / (مخرجات بيانات i2psnark) تكون على الأقل 3.5 : 1. عند تشغيل تجربة حيث تم تعديل الكود لتفضيل SSU (خيار التكوين i2np.udp.alwaysPreferred ليس له تأثير في الكود الحالي)، انخفضت النسبة إلى حوالي 3 : 1، مما يدل على كفاءة أفضل.

كما تظهر إحصائيات مكتبة التدفق، تحسنت الأمور بشكل كبير - حجم النافذة مدى الحياة ارتفع من 6.3 إلى 7.5، RTT انخفض من 11.5 ثانية إلى 10 ثوانٍ، عمليات الإرسال لكل إقرار انخفضت من 1.11 إلى 1.07.

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

التأثير على سرعات i2psnark الصادرة لم يكن واضحاً بسبب التغيرات الطبيعية. أيضاً للتجربة، تم تعطيل NTCP الواردة. التأثير على السرعات الواردة على i2psnark لم يكن واضحاً.

المقترحات

1. 1A) هذا سهل - يجب أن نعكس أولويات العطاءات بحيث يكون SSU مفضلاً لجميع حركة المرور، إذا كان بإمكاننا فعل هذا دون التسبب في جميع أنواع المشاكل الأخرى. هذا سيصلح خيار التكوين i2np.udp.alwaysPreferred بحيث يعمل (إما كـ true أو false).

2. 1B) بديل لـ 1A)، ليس سهلاً جداً - إذا كان بإمكاننا وضع علامة على حركة المرور دون التأثير سلباً على أهداف إخفاء الهوية لدينا، فيجب علينا تحديد حركة المرور المُولدة من streaming-lib وجعل SSU ينتج عرضاً منخفضاً لتلك حركة المرور. يجب أن تذهب هذه العلامة مع الرسالة عبر كل hop حتى تحترم routers التوجيه أيضاً تفضيل SSU.

3. 2) تقييد SSU أكثر (تقليل الإرسالات المعاد إرسالها القصوى من الـ 10 الحالية) من المحتمل أن يكون حكيماً لتقليل احتمالية الانهيار.

4. 3) نحتاج إلى مزيد من الدراسة حول الفوائد مقابل الضرر من بروتوكول شبه موثوق تحت مكتبة الـ streaming. هل إعادة الإرسال عبر قفزة واحدة مفيد وانتصار كبير أم أنه أسوأ من عدم الفائدة؟ يمكننا إنشاء SUU جديد (UDP آمن غير موثوق) لكن ربما لا يستحق العناء. يمكننا ربما إضافة نوع رسالة لا-تتطلب-إقرار في SSU إذا كنا لا نريد أي إعادة إرسال على الإطلاق لحركة مرور streaming-lib. هل إعادة الإرسال المحدودة بإحكام مرغوبة؟

5. 4) كود إرسال الأولوية في .28 مخصص فقط لـ NTCP. حتى الآن لم تُظهر اختباراتي فائدة كبيرة لأولوية SSU حيث أن الرسائل لا تنتظر في الطابور لفترة كافية لتحقق الأولويات أي فائدة. لكن هناك حاجة لمزيد من الاختبارات.

6. 5) مهلة انتظار مكتبة التدفق الجديدة البالغة 45 ثانية ربما لا تزال منخفضة جداً. معيار TCP RFC ينص على 60 ثانية. ربما لا يجب أن تكون أقصر من مهلة انتظار NTCP الأساسية القصوى (والتي تُفترض أن تكون 60 ثانية).

رد من jrandom

نُشر على Syndie الجديد، 2007-03-27

بشكل عام، أنا منفتح على التجريب مع هذا، لكن تذكر لماذا يوجد NTCP في المقام الأول - فشل SSU في انهيار الازدحام. NTCP “يعمل فحسب”، وبينما يمكن التعامل مع معدلات إعادة الإرسال 2-10% في الشبكات العادية أحادية القفزة، فإن هذا يعطينا معدل إعادة إرسال 40% مع أنفاق القفزتين. إذا أدخلت بعض معدلات إعادة الإرسال المقاسة لـ SSU التي رأيناها قبل تنفيذ NTCP (10-30+%)، فإن ذلك يعطينا معدل إعادة إرسال 83%. ربما كانت تلك المعدلات بسبب المهلة الزمنية المنخفضة البالغة 10 ثوانٍ، ولكن زيادتها كثيراً ستضرنا (تذكر، اضرب في 5 وستحصل على نصف الرحلة).

على عكس TCP، ليس لدينا ملاحظات من tunnel لمعرفة ما إذا كانت الرسالة قد وصلت - لا توجد إقرارات على مستوى tunnel. لدينا إقرارات من طرف إلى طرف، ولكن فقط على عدد قليل من الرسائل (كلما قمنا بتوزيع علامات جلسة جديدة) - من أصل 1,553,591 رسالة عميل أرسلها router الخاص بي، حاولنا فقط إرسال ACK لـ 145,207 منها. الباقي قد يكون فشل بصمت أو نجح بشكل مثالي.

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

مهلة NTCP القصوى تُفترض أن تكون 60 ثانية على الأقل، وهو ما يوصي به RFC. لا توجد طريقة لتغيير معاملات NTCP أو مراقبة الأداء.

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

يتميز NTCP بعبء أعلى وربما أوقات استجابة أطول. عند استخدام NTCP تكون نسبة (مخرجات tunnel) / (مخرجات بيانات i2psnark) على الأقل 3.5 : 1. عند تشغيل تجربة حيث تم تعديل الكود لتفضيل SSU (خيار التكوين i2np.udp.alwaysPreferred لا يؤثر في الكود الحالي)، انخفضت النسبة إلى حوالي 3 : 1، مما يشير إلى كفاءة أفضل.

هذه بيانات مثيرة للاهتمام جداً، لكن أكثر كمسألة ازدحام router من كفاءة عرض النطاق الترددي - ستحتاج لمقارنة 3.5*$n*$NTCPRetransmissionPct ./. 3.0*$n*$SSURetransmissionPct. تشير نقطة البيانات هذه إلى وجود شيء في router يؤدي إلى تكدس محلي مفرط للرسائل التي يتم نقلها بالفعل.

حجم نافذة العمر الافتراضي ارتفع من 6.3 إلى 7.5، RTT انخفض من 11.5 ثانية إلى 10 ثواني، الإرسالات لكل > ACK انخفضت من 1.11 إلى 1.07.

تذكر أن عدد الإرسالات لكل ACK هو مجرد عينة وليس عداد كامل (حيث أننا لا نحاول إرسال ACK لكل إرسالية). كما أنها ليست عينة عشوائية، بل تأخذ عينات أكثر كثافة من فترات عدم النشاط أو بداية اندفاع من النشاط - الأحمال المستمرة لن تتطلب العديد من رسائل ACK.

أحجام النوافذ في هذا النطاق لا تزال منخفضة بشكل مؤسف للحصول على الفائدة الحقيقية من AIMD، ولا تزال منخفضة جداً لنقل جزء BT واحد بحجم 32KB (رفع الحد الأدنى إلى 10 أو 12 سيغطي ذلك).

مع ذلك، إحصائية wsize تبدو واعدة - على مدى كم من الوقت تم الحفاظ عليها؟

في الواقع، لأغراض الاختبار، قد ترغب في النظر إلى StreamSinkClient/StreamSinkServer أو حتى TestSwarm في apps/ministreaming/java/src/net/i2p/client/streaming/ - StreamSinkClient هو تطبيق سطر أوامر يرسل ملفاً محدداً إلى وجهة محددة و StreamSinkServer ينشئ وجهة ويكتب أي بيانات مرسلة إليه (عارضاً الحجم ووقت النقل). TestSwarm يجمع بين الاثنين - يغمر بيانات عشوائية إلى أي شخص يتصل به. هذا يجب أن يمنحك الأدوات لقياس قدرة الإنتاجية المستدامة عبر مكتبة streaming، بدلاً من آلية الخنق/الإرسال في BitTorrent.

1A) هذا سهل - > يجب أن نعكس أولويات العروض بحيث يُفضل SSU لجميع حركة البيانات، إذا > كان بإمكاننا فعل ذلك دون التسبب في جميع أنواع المشاكل الأخرى. هذا سيصلح > خيار التكوين i2np.udp.alwaysPreferred بحيث يعمل (إما كـ true > أو false).

احترام i2np.udp.alwaysPreferred فكرة جيدة في أي حال - لا تتردد في إجراء هذا التغيير. لكن دعنا نجمع المزيد من البيانات قبل تبديل التفضيلات، حيث أن NTCP تمت إضافته للتعامل مع انهيار الازدحام الذي أحدثه SSU.

1B) بديل للخيار 1A)، ليس سهلاً جداً - > إذا كان بإمكاننا وسم حركة البيانات دون التأثير سلباً على أهداف إخفاء الهوية الخاصة بنا، يجب > أن نحدد حركة البيانات المُولدة بواسطة streaming-lib > ونجعل SSU ينتج عرضاً منخفضاً لتلك الحركة. يجب أن تذهب هذه العلامة مع > الرسالة عبر كل hop > حتى تحترم router الإعادة التوجيه أيضاً تفضيل SSU.

في الممارسة العملية، هناك ثلاثة أنواع من حركة البيانات - بناء/اختبار tunnel، استعلام/استجابة netDb، وحركة بيانات streaming lib. تم تصميم الشبكة لجعل التمييز بين هذه الأنواع الثلاثة صعباً للغاية.

2) تقييد SSU أكثر (تقليل الإرسالات المعاد إرسالها القصوى من أكثر من 10 حاليًا) من المحتمل أن يكون حكيمًا لتقليل فرصة الانهيار.

عند 10 عمليات إعادة إرسال، نكون في مأزق كبير بالفعل، أتفق معك. واحدة، ربما اثنتان من عمليات إعادة الإرسال أمر معقول، من طبقة النقل، ولكن إذا كان الطرف الآخر مزدحمًا جدًا بحيث لا يستطيع إرسال ACK في الوقت المناسب (حتى مع قدرة SACK/NACK المنفذة)، فلا يوجد الكثير مما يمكننا فعله.

في رأيي، لحل المشكلة الأساسية حقاً نحتاج إلى معالجة سبب ازدحام الـ router بحيث لا يستطيع إرسال ACK في الوقت المناسب (والذي، حسب ما وجدت، يعود إلى تنافس وحدة المعالجة المركزية). ربما يمكننا ترتيب بعض الأمور في معالجة الـ router لجعل إرسال tunnel موجود مسبقاً له أولوية أعلى في وحدة المعالجة المركزية من فك تشفير طلب tunnel جديد؟ لكن علينا أن نكون حذرين لتجنب المجاعة.

3) نحتاج إلى مزيد من الدراسة حول فوائد مقابل أضرار بروتوكول شبه موثوق > تحت مكتبة التدفق. هل إعادة الإرسال عبر قفزة واحدة مفيدة > ومكسب كبير أم أنها أسوأ من عدم الفائدة؟ > يمكننا عمل SUU جديد (UDP آمن وغير موثوق) ولكن ربما لا يستحق ذلك. يمكننا > ربما إضافة نوع رسالة لا تتطلب ACK في SSU إذا كنا لا نريد أي > إعادة إرسال على الإطلاق لحركة مرور مكتبة التدفق. هل إعادة الإرسال > المحدودة بإحكام مرغوبة؟

يستحق البحث - ماذا لو قمنا بتعطيل إعادة الإرسال في SSU؟ ربما يؤدي ذلك إلى معدلات إعادة إرسال أعلى بكثير في مكتبة البث، لكن ربما لا.

4) كود إرسال الأولوية في .28 مخصص فقط لـ NTCP. حتى الآن لم تُظهر اختباراتي استخداماً كبيراً لأولوية SSU حيث أن الرسائل لا تنتظر في الطابور لفترة كافية لتحقق الأولويات أي فائدة. لكن هناك حاجة لمزيد من الاختبارات.

هناك UDPTransport.PRIORITY_LIMITS و UDPTransport.PRIORITY_WEIGHT (التي تحترمها TimedWeightedPriorityMessageQueue)، ولكن حالياً الأوزان متساوية تقريباً، لذا لا يوجد تأثير. يمكن تعديل ذلك بالطبع (ولكن كما تذكر، إذا لم يكن هناك طابور انتظار، فلا يهم الأمر).

5) المهلة القصوى الجديدة البالغة 45 ثانية لمكتبة streaming ما زالت منخفضة على الأرجح. معيار TCP RFC يقول 60 ثانية. ربما لا يجب أن تكون أقصر من المهلة القصوى الأساسية لـ NTCP (المفترض أن تكون 60 ثانية).

تلك الـ 45 ثانية هي أقصى مهلة زمنية لإعادة الإرسال في مكتبة التدفق، وليس مهلة التدفق الزمنية. TCP في الممارسة العملية له مهل زمنية لإعادة الإرسال أقل بمراتب من حيث الحجم، رغم أنه نعم، يمكن أن تصل إلى 60 ثانية على الروابط التي تعمل عبر أسلاك مكشوفة أو إرسال عبر الأقمار الصناعية ;) إذا زدنا مهلة إعادة الإرسال الزمنية لمكتبة التدفق إلى مثلاً 75 ثانية، يمكننا الذهاب لاحتساء الجعة قبل أن تحمّل صفحة الويب (خاصة بافتراض نقل أقل من 98% موثوقية). هذا أحد الأسباب التي تجعلنا نفضل NTCP.

الرد من zzz

نُشر في Syndie الجديد، 2007-03-31

عند 10 إعادات إرسال، نحن في مأزق بالفعل، أوافق. إعادة إرسال واحدة، ربما اثنتان > معقولة، من طبقة النقل، لكن إذا كان الطرف الآخر مزدحماً جداً للرد بـ ACK في الوقت المحدد > (حتى مع قدرة SACK/NACK المُنفذة)، > فلا يوجد الكثير مما يمكننا فعله. > > في وجهة نظري، لمعالجة المشكلة الأساسية حقاً نحتاج لمعالجة سبب > ازدحام الـ router بحيث لا يستطيع الرد بـ ACK في الوقت المحدد (والذي، مما وجدته، يرجع إلى > تنافس المعالج). ربما يمكننا إعادة ترتيب بعض الأشياء في معالجة الـ router لجعل > إرسال tunnel موجود مسبقاً له أولوية معالج أعلى من > فك تشفير طلب tunnel جديد؟ رغم أنه يجب أن نكون حذرين لتجنب > التجويع.

إحدى تقنياتي الرئيسية لجمع الإحصائيات هي تشغيل net.i2p.client.streaming.ConnectionPacketHandler=DEBUG ومراقبة أوقات RTT وأحجام النوافذ أثناء مرورها. للتعميم المفرط للحظة، من الشائع رؤية 3 أنواع من الاتصالات: RTT بحوالي 4 ثواني، RTT بحوالي 10 ثوانٍ، وRTT بحوالي 30 ثانية. الهدف هو محاولة تقليل اتصالات RTT البالغة 30 ثانية. إذا كان تنافس المعالج هو السبب فربما بعض التنظيم سيحقق ذلك.

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

يستحق النظر فيه - ماذا لو قمنا بتعطيل إعادة الإرسال في SSU فقط؟ من المحتمل أن يؤدي ذلك إلى معدلات إعادة إرسال أعلى بكثير في مكتبة التدفق، ولكن ربما لا.

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

(ولكن كما تذكر، إذا لم يكن هناك طابور انتظار، فهذا لا يهم).

قمت بتنفيذ الإرسال ذي الأولوية لـ UDP ولكنه عمل حوالي 100,000 مرة أقل من الكود في جانب NTCP. ربما تكون هذه دليلاً للمزيد من التحقيق أو تلميحاً - لا أفهم لماذا سيتراكم بهذا الشكل أكثر في NTCP، ولكن ربما يكون ذلك تلميحاً حول سبب أداء NTCP الأسوأ.

سؤال أجاب عليه jrandom

نُشر في Syndie الجديد، 2007-03-31

معدلات إعادة الإرسال المقاسة لـ SSU التي رأيناها قبل تطبيق NTCP > (10-30+%) > > هل يمكن للـ router نفسه قياس هذا؟ إذا كان الأمر كذلك، هل يمكن اختيار وسيلة نقل بناءً > على الأداء المقاس؟ (أي إذا كان اتصال SSU مع peer يسقط عدداً > غير معقول من الرسائل، فضّل NTCP عند الإرسال لذلك الـ peer)

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

الرد من foofighter

نُشر على Syndie الجديد، 2007-03-26

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

حسب علمي، لم تكن هناك نظرية عميقة كثيرة وراء تفضيل TCP مقابل UDP، باستثناء الاعتبارات التالية:

• شبكة TCP فقط تعتمد بشكل كبير على العقد القابلة للوصول (تلك التي يمكنها توجيه الاتصالات الواردة عبر NAT الخاص بها)
• حتى لو كانت العقد القابلة للوصول نادرة، فإن كونها عالية السعة يخفف إلى حد ما من مشاكل الندرة الطوبولوجية
• UDP يسمح بـ “NAT hole punching” مما يتيح للأشخاص أن يكونوا “نوعاً ما شبه قابلين للوصول” (بمساعدة المُقدِمين) الذين لا يمكنهم سوى الاتصال الخارجي
• تنفيذ نقل TCP “القديم” تطلب الكثير من الخيوط، مما كان قاتلاً للأداء، بينما نقل TCP “الجديد” يعمل بشكل جيد مع خيوط قليلة
• router من المجموعة A تتعطل عند التشبع بـ UDP. router من المجموعة B تتعطل عند التشبع بـ TCP.
• “يبدو” (كما في، هناك بعض المؤشرات ولكن لا توجد بيانات علمية أو إحصائيات جودة) أن A منتشر على نطاق أوسع من B
• بعض الشبكات تحمل حزم UDP غير DNS بجودة سيئة بصراحة، بينما لا تزال تهتم إلى حد ما بحمل تدفقات TCP.

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

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

رد من zzz (إلى foofighter)

نُشر في Syndie الجديد، 2007-03-27

حسب علمي، لم تكن هناك نظرية عميقة وراء تفضيل TCP مقابل UDP، باستثناء الاعتبارات التالية:

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

ما أقوله هو أنه يجب عليك أن تأخذ مكتبة التدفق (streaming lib) في الاعتبار.

لذا إما تغيير التفضيلات للجميع أو التعامل مع حركة مرور مكتبة البث بشكل مختلف.

هذا ما تتحدث عنه مقترحي 1B) - وجود تفضيل مختلف لحركة بيانات streaming-lib عن حركة البيانات غير الخاصة بـ streaming-lib (على سبيل المثال رسائل بناء الأنفاق).

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

متفق. الإصدار الجديد .28 ربما جعل الأمور أفضل بالنسبة لفقدان الحزم عبر UDP، أو ربما لا.

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

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

لدينا أربعة مقابض ضبط - قيم العطاءات الأربعة (SSU و NTCP، للمتصل مسبقاً وغير المتصل مسبقاً). يمكننا جعل SSU مُفضل على NTCP فقط إذا كان كلاهما متصلاً، على سبيل المثال، ولكن محاولة NTCP أولاً إذا لم يكن أي من النقلين متصلاً.

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

نتائج النقاش

… والتغييرات الأخرى ذات الصلة في نفس الإطار الزمني (2007):

• تم تنفيذ ضبط كبير لمعاملات مكتبة streaming، مما زاد بشكل كبير من الأداء الصادر، في الإصدار 0.6.1.28
• تم تنفيذ الإرسال ذو الأولوية لـ NTCP في الإصدار 0.6.1.28
• تم تنفيذ الإرسال ذو الأولوية لـ SSU بواسطة zzz لكن لم يتم إدراجه أبداً
• تم تنفيذ التحكم المتقدم في عروض النقل i2np.udp.preferred في الإصدار 0.6.1.29.
• تم تنفيذ pushback لـ NTCP في الإصدار 0.6.1.30، وتم تعطيله في الإصدار 0.6.1.31 بسبب مخاوف الخصوصية، وأعيد تفعيله مع تحسينات لمعالجة تلك المخاوف في الإصدار 0.6.1.32.
• لم يتم تنفيذ أي من اقتراحات zzz من 1-5.