المسائل المتعلقة بالتصميم-إرسال قطع صغيرة من البيانات عبر TCP مع Winsock

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

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

الخلفية

عندما يتلقى مكدس Microsoft TCP حزمة بيانات، جهاز ضبط وقت تأخير 200 ms يذهب. عندما يتم إرسال ACK أخيرا، إعادة تعيين جهاز ضبط الوقت تأخير وسيبدأ تأخير 200 ms آخر عند تلقي حزمة البيانات التالية.لزيادة الكفاءة في تطبيقات الإنترانت والإنترنت، يستخدم مكدس Microsoft TCP المعايير التالية لتحديد متى يتم إرسال ACK واحد على حزم البيانات المتلقاة:
  • إذا تم تلقي حزمة البيانات الثاني قبل انتهاء صلاحية جهاز ضبط الوقت تأخير, يتم إرسال ACK.
  • إذا كانت هناك بيانات لإرسالها في نفس الاتجاه مثل ACK قبل تلقي حزمة البيانات الثاني وانتهاء صلاحية جهاز ضبط الوقت تأخير، ACK piggybacked مع مقطع البيانات وإرسالها فورا.
  • عند انتهاء صلاحية جهاز ضبط الوقت تأخير، يتم إرسال ACK.
لتجنب حزم البيانات الصغيرة كونجيست الشبكة يتيح مكدس Microsoft TCP خوارزمية Nagle بشكل افتراضي، يتحول المخزن مؤقت لبيانات صغيرة من تأخير إرسال حتى إرسال ACK لحزمة البيانات السابقة تلقيه من المضيف البعيد وإرسال مكالمات متعددة. فيما يلي استثناءان من خوارزمية ناغل:
  • وقد تضامنت المكدس المخزن مؤقت لبيانات أكبر من وحدة الإرسال الكبرى (MTU)، يتم إرسال حزمة كاملة الحجم فورا دون انتظار ACK من مضيف بعيد. على شبكة اتصال Ethernet وحدة الإرسال الكبرى لبروتوكول TCP/IP 1460 بايت.
  • يتم تطبيق خيار مأخذ التوصيل TCP_NODELAY تعطيل خوارزمية ناغل حيث يتم تسليم حزم البيانات الصغيرة إلى المضيف البعيد دون تأخير.
لتحسين الأداء في طبقة التطبيق، إرسال Winsock مخازن البيانات نسخاً من تطبيق الاستدعاءات إلى المخزن مؤقت kernel Winsock. ثم يستخدم المكدس الأساليب البحثية الخاصة بها (مثل خوارزمية ناغل) لتحديد متى يتم فعلياً وضع الحزمة على السلك. يمكنك تغيير حجم المخزن المؤقت kernel Winsock المخصص لمآخذ التوصيل باستخدام الخيار SO_SNDBUF (من 8 كيلو بايت بشكل افتراضي). إذا لزم الأمر، Winsock يمكن المخزن المؤقت إلى حد كبير أكبر من حجم المخزن المؤقت SO_SNDBUF. في معظم الحالات، إكمال الإرسال في التطبيق فقط تشير إلى المخزن المؤقت للبيانات في تطبيق إرسال استدعاء يتم نسخة إلى المخزن المؤقت kernel Winsock ولا يشير إلى أن البيانات ضرب متوسط الشبكة. الاستثناء الوحيد عندما تقوم بتعطيل التخزين المؤقت Winsock بتعيين SO_SNDBUF إلى 0.

يستخدم Winsock القواعد التالية للإشارة إلى إتمام إرسال إلى التطبيق (اعتماداً على كيفية استدعاء الإرسال إشعار الإكمال يمكن الدالة الرجوع من استدعاء حظر، مما يشير إلى حدث أو استدعاء دالة إعلام، وهكذا):
  • في حالة استمرار داخل الحصة النسبية SO_SNDBUF مأخذ التوصيل، نسخ البيانات من إرسال التطبيق Winsock واﻹشارة إلى إتمام إرسال إلى التطبيق.
  • إذا مأخذ التوصيل تتجاوز الحصة النسبية SO_SNDBUF وهناك واحد فقط إرسال المخزن مسبقاً في المخزن المؤقت kernel مكدس، بنسخ البيانات من إرسال التطبيق Winsock والإشارة إلى إتمام إرسال إلى التطبيق.
  • إذا مأخذ التوصيل تتجاوز الحصة النسبية SO_SNDBUF وهناك أكثر من قاعدة البيانات التي تم تخزينها مؤقتاً إرسال في المخزن المؤقت kernel مكدس، Winsock بنسخ البيانات من تطبيق الإرسال. Winsock لا يشير إلى إتمام إرسال إلى التطبيق حتى يتم إكمال المكدس إرسال كافية لوضع مأخذ التوصيل مرة أخرى داخل الحصة النسبية SO_SNDBUF أو شرط إرسال المعلقة واحد فقط.

دراسة حالة 1

نظرة عامة:

يلزم عميل Winsock TCP إرسال سجلات 10000 خادم Winsock TCP لتخزينها في قاعدة بيانات. يختلف حجم السجلات من 20 بايت إلى 100 بايت. لتبسيط منطق التطبيق، التصميم كما يلي:
  • يقوم العميل بإرسال الحظر فقط. يقوم الخادم بحظر تلقي فقط.
  • تعيين مأخذ توصيل العميل SO_SNDBUF إلى 0 بحيث يخرج كل سجل في مقطع واحد من بيانات.
  • تلقي مكالمات الخادم في تكرار حلقي. نشرت في تلقي المخزن المؤقت من 200 بايت حتى يمكن تلقي كل سجل في استدعاء تلقي واحد.

الأداء:

أثناء الاختبار، يجد المطور فقط على العميل إرسال خمسة سجلات في الثانية إلى الخادم. إجمالي 10000 السجلات، أقصى في 976 كيلو بايت من البيانات (10000 * 100/1024)، يأخذ أكثر من نصف ساعة لإرسالها إلى الملقم.

تحليل:

سبب عدم تعيين العميل الخيار TCP_NODELAY، يفرض خوارزمية ناغل مكدس TCP لانتظار ACK قبل إرسال حزمة أخرى على السلك. ومع ذلك، قام العميل تعطيل التخزين المؤقت Winsock بتعيين الخيار SO_SNDBUF إلى 0. لذلك، إرسال 10000 المكالمات من الضروري إرسال و ACK'ed كل على حدة. هو كل ACK ms 200 المؤجل لأن يحدث ما يلي على مكدس TCP على الملقم:
  • عندما يحصل الخادم حزمة، الانتقال المؤقت الخاص به تأخير 200 ms.
  • لا يحتاج الملقم لإرسال أي شيء إلى الوراء، حيث لا يمكن piggybacked ACK.
  • لن ترسل العميل حزمة أخرى إلا المسلم الحزمة السابقة.
  • انتهت صلاحية عداد الوقت التأخير على الملقم ويتم إرسال ACK.

كيفية تحسين:

هناك مشكلتان مع هذا التصميم. أولاً، هناك مسألة التأخير المؤقت. العميل يجب أن يكون قادراً على إرسال الحزم اثنين إلى الخادم داخل السيدة 200 لأن العميل يستخدم خوارزمية Nagle بشكل افتراضي، يجب أن يستخدم Winsock التخزين المؤقت الافتراضي ولم يتم تعيين SO_SNDBUF إلى 0. بمجرد قد تضامنت مكدس TCP مخزن مؤقت أكبر من وحدة الإرسال الكبرى (MTU)، يتم إرسال حزمة كاملة الحجم فورا دون انتظار ACK من مضيف بعيد.

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

دراسة حالة 2

نظرة عامة:

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

الأداء:

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

تحليل:

يسمح هذا التصميم فقط طلب أسعار الأسهم المعلقة واحد في مرة الواحدة. رمز السهم الأول يتم إرسالها إلى الخادم من خلال قناة الأمر (اتصال) ويتم مباشرة إرسال استجابة من الخادم إلى العميل عبر قناة البيانات (اتصال). ثم يقوم العميل بإرسال طلب رمز السهم الثاني مباشرة والإرسال إرجاع مباشرة كما يتم نسخ المخزن المؤقت للطلب في استدعاء الإرسال إلى المخزن المؤقت kernel Winsock. مع ذلك، مكدس TCP العميل لا إرسال الطلب من المخزن المؤقت kernel الخاص به مباشرة لإرسال الأول عبر قناة الأمر لم يوافق بعد. بعد تأخير 200 ms جهاز ضبط الوقت في انتهاء صلاحية القناة الأمر server، ACK طلب الرمز الأول يأتي مرة أخرى إلى العميل. ثم طلب عرض الأسعار الثاني يتم بنجاح إرسال إلى الملقم بعد التأخير للسيدة 200 عرض الأسعار لرمز السهم الثاني عودة مباشرة من خلال قناة البيانات لأن في هذا الوقت، صلاحية جهاز ضبط الوقت تأخير في قناة بيانات العميل. ACK الأسعار السابقة الاستجابة المتلقاة من قبل الملقم. (تذكر أن العميل تعذر إرسال طلب عرض أسعار أسهم ثانية 200 مللي ثانية، مما يتيح الوقت للتأخير المؤقت على العميل أن تنتهي وإرسال ACK إلى الخادم). وكنتيجة لذلك، العميل الحصول على استجابة الاقتباس الثاني ويمكن إصدار طلب عرض أسعار آخر، الذي يخضع لنفس الدورة.

كيفية تحسين:

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

توصيات:

أثناء هذه دراستي حالة مصطنعة، المساعدة لتوضيح بعض أسوأ السيناريوهات. عندما تقوم بتصميم تطبيق يتضمن مقطع البيانات الصغيرة الواسعة لإرسال وريكفس، يجب مراعاة الإرشادات التالية:
  • إذا لم مرة بيانات المقاطع الحرجة، التطبيق يجب أن الاندماج لهم في كتلة بيانات أكبر لتمريرها إلى استدعاء إرسال. لأنه من المرجح إرسال المخزن المؤقت ليتم نسخها إلى المخزن المؤقت kernel Winsock، يجب إلا يكون المخزن المؤقت كبير جداً. أقل قليلاً من 8 كيلو عادة ما تكون فعالة. كما يحصل Winsock kernel كتلة أكبر من وحدة الإرسال الكبرى، سيرسل عدة حزم كامل الحجم وحزمة الأخير بما تبقى. لن الوصول إلى جانب إرسال، ما عدا الحزمة الأخيرة، بتأخير 200 ms جهاز ضبط الوقت. الحزمة الأخيرة، إذا حدث أن حزمة الفردية، لا تزال عرضه خوارزمية تأخير الإقرار بالإعلام. إذا كان مكدس نهاية إرسال مقطع آخر أكبر من وحدة الإرسال الكبرى، أنها لا تزال تتجاوز خوارزمية Nagle.
  • إذا كان ذلك ممكناً، تجنب اتصالات مأخذ التوصيل مع تدفق البيانات أحادي الاتجاه. تكون الاتصالات عبر مأخذ توصيل أحادي الاتجاه تتأثر ناغل تسهيل وتأخير إقرار خوارزميات. إذا كان الاتصال تتبع طلب واستجابة تدفق, يجب استخدام مأخذ توصيل واحد لفعل كل من إرسال وريكفس حتى يمكن piggybacked ACK على الاستجابة.
  • إذا كان لديك كافة أجزاء صغيرة من البيانات لإرسالها فورا، تعيين خيار TCP_NODELAY على طرف الإرسال.
  • إلا إذا كنت تريد ضمان إرسال حزمة على السلك عند الإشارة إلى اكتمال عملية إرسال ب Winsock، يجب عدم تعيين في SO_SNDBUF إلى صفر. في الواقع، قبل المخزن المؤقت الافتراضي 8 كيلو بايت تم إحباطه قرر العمل بشكل جيد لمعظم الحالات والتي لا يجب تغييرها ما لم تتمكن من اختبار أن إعدادات المخزن المؤقت Winsock جديدة يعطيك أداء أفضل من الافتراضي. أيضا، إعداد SO_SNDBUF إلى صفر بالكاد مفيدة لتطبيقات المجمع نقل البيانات. حتى ذلك الحين، لأقصى قدر من الكفاءة التي يجب استخدامها بالاقتران مع مزدوج التخزين المؤقت (أكثر من إرسال المعلقة في أي وقت من الأوقات) وتتداخل الإدخال/الإخراج.
  • إذا لم يكن التسليم البيانات ضمان، استخدام UDP.
مراجع
لمزيد من المعلومات حول "تأجيل إقرار" والخوارزمية ناغل، الرجاء راجع ما يلي:

برادن، ور. [1989] RFC 1122، متطلبات هندسة إنترنت المضيفين-طبقات الاتصالات، إنترنت في فرقة العمل المعنية.

تحذير: تمت ترجمة هذه المقالة تلقائيًا

خصائص

رقم الموضوع: 214397 - آخر مراجعة: 03/14/2015 05:03:00 - المراجعة: 4.0

  • kbdswnet2003swept kbapi kbinfo kbip kbnetwork kbwinsock kbmt KB214397 KbMtar
تعليقات