تحليل TCP Nagle وتأخر ACK PCAP: زمن وصول الحزم الصغيرة، والأكشاك 40 مللي ثانية، وتطبيقات الطلب/الاستجابة البطيئة
كيفية تحليل خوارزمية TCP Nagle وتفاعلات ACK المتأخرة في عمليات التقاط الحزم، وزمن وصول الحزم الصغيرة، وأكشاك الطلب/الاستجابة، وتأخيرات البروتوكول التفاعلي، وأدلة TCP_NODELAY.
تبدو بعض تطبيقات TCP بطيئة حتى مع عدم فقدان الحزمة وانخفاض وحدة المعالجة المركزية وعرض النطاق الترددي السليم. يمكن أن يكون السبب هو التفاعل بين خوارزمية Nagle وسلوك ACK المتأخر. يبحث المستخدمون عن "TCP Nagleتأخر ACK pcap"، و"تأخير TCP 40 مللي ثانية"، و"زمن وصول الحزمة الصغيرة"، و"التقاط حزمة TCP_NODELAY"، و"استجابة طلب بطيئة TCP"، و"لماذا ينتظر TCP قبل إرسال حزم صغيرة" عندما يتوقف البروتوكول التفاعلي عند عمليات الكتابة الصغيرة.
تعد جراحة PCAP مفيدة لأن هذه المشكلة تعتمد بالكامل على التوقيت. تحتاج إلى الحفاظ على الطوابع الزمنية للحزمة وأحجام الحمولة وتوقيت ACK واتجاهها وحدود رسائل التطبيق.
ماذا يفعل نيجل
تعمل خوارزمية Nagle على تقليل حمل الحزم الصغيرة عن طريق إعاقة عمليات الكتابة الصغيرة عندما تكون هناك بالفعل بيانات غير معترف بها أثناء الطيران. بالنسبة للنقل بالجملة، يمكن أن يكون هذا فعالاً. بالنسبة لبروتوكولات الطلب/الاستجابة التفاعلية التي ترسل العديد من الرسائل الصغيرة، يمكنها تقديم زمن وصول مرئي.
النمط النموذجي:
- يرسل التطبيق شريحة صغيرة.
- كتابة صغيرة أخرى جاهزة.
- ينتظر المرسل ACK قبل إرسال المزيد.
- يقوم المتلقي بتأخير ACK على أمل الحصول عليه.
- كلا الجانبين ينتظر لفترة وجيزة.
يمكن أن يبدو هذا التأخير وكأنه توقف مؤقت غامض للتطبيق.
ما يفعله تأخير ACK
يتيح ACK المؤجل للمتلقي الانتظار قبل الاعتراف بالبيانات، غالبًا لتقليل حركة مرور ACK أو ACKs على بيانات الاستجابة. يعد هذا سلوكًا صالحًا عادةً لبروتوكول TCP.
تظهر المشكلة عندما:
- ينتظر المرسل بسبب Nagle.
- ينتظر المتلقي بسبب تأخير ACK.
- ينتظر التطبيق الجزء الصغير الثاني.
- لا يرسل أي طرف بيانات كافية لكسر الانتظار على الفور.
يُظهر التقاط الحزمة فجوة متكررة، غالبًا ما تكون حول تأخير ثابت صغير.
الأعراض الشائعة
غالبًا ما يصف الباحثون:
- "لا يعاني بروتوكول TCP من فقدان الحزمة ولكن التطبيق بطيء."
- "كل طلب له تأخير قدره 40 مللي ثانية."
- "الكتابة الصغيرة بطيئة."
- "تعطيل زمن الاستجابة الثابت لـ TCP_NODELAY."
- "بروتوكول قاعدة البيانات بطيء عبر VPN."
- "واجهة المستخدم البعيدة بطيئة مع وجود العديد من الحزم الصغيرة."
- "تحتوي مكالمات RPC على فجوات غريبة."
- "يحدث زمن الاستجابة فقط على نظام التشغيل Linux لنظام التشغيل Windows."
قد يكون السبب الجذري هو خيارات مأخذ التوصيل أو أنماط كتابة التطبيق أو سياسة ACK الخاصة بجهاز الاستقبال.
أدلة الحزمة
بحث:
- حمولات TCP صغيرة.
- جانب واحد يرسل أقل من MSS.
- تأخرت رسالة التطبيق الثانية.
- يصل ACK بعد فجوة ثابتة تشبه المؤقت.
- لا يحدث إعادة الإرسال.
- النافذة ليست ممتلئة.
- RTT أقل من المماطلة الملحوظة.
- الإنتاجية ليست عنق الزجاجة الرئيسي.
وهذا ما يميز Nagle/تأخر ACK عن الخسارة والازدحام وتأخير DNS وتفاوض TLS ووقت معالجة الخادم.
بروتوكولات الطلب/الاستجابة
البروتوكولات التفاعلية حساسة بشكل خاص:
- استعلامات قاعدة البيانات.
- تأطير RPC.
- بروتوكولات تشبه Telnet.
- بروتوكولات التحكم الصناعية المخصصة.
- قنوات التحكم بسطح المكتب البعيد.
- بوابات التداول المالي.
- مكتبات عملاء Chatty HTTP.
- بروتوكولات الأوامر الموجهة نحو الخط.
إذا أرسل أحد التطبيقات الرؤوس وحقول الطول وأجزاء النص كعمليات كتابة صغيرة منفصلة، فقد يكشف تتبع الحزمة عن زمن الوصول الذي يمكن تجنبه.
TCP_NODELAY وتجميع التطبيقات
يمكن أن يؤدي تعطيل Nagle باستخدام TCP_NODELAY إلى تقليل زمن الوصول لبعض التطبيقات التفاعلية. لكنه ليس دائما الحل الأفضل.
تشمل الخيارات ما يلي:
- تمكين
TCP_NODELAYللرسائل الصغيرة الحساسة لزمن الاستجابة. - دفعة صغيرة يكتب في تطبيق واحد الكتابة.
- مسح إطارات البروتوكول الكاملة فقط.
- تجنب أنماط الكتابة والكتابة والقراءة ذات الأجزاء الصغيرة.
- قم بضبط سلوك ACK المؤجل إذا كان النظام الأساسي يسمح بذلك.
- حافظ على تمكين Nagle لعمليات النقل المجمعة.
يجب أن يوجه PCAP القرار.
التشخيصات الكاذبة
غالبًا ما يتم تشخيص هذه المشكلة بشكل خاطئ على النحو التالي:
- فقدان الحزمة.
- وحدة المعالجة المركزية للخادم بطيئة.
- TLS النفقات العامة.
- الكمون واي فاي.
- ازدحام VPN.
- تأخير DNS.
- مشكلة MTU.
قد تكون هذه حقيقية في حالات أخرى، ولكن إذا أظهر التتبع فجوات متسقة في الحزم الصغيرة دون عمليات إعادة الإرسال، فإن تفاعل إرسال TCP/ACK يستحق الاهتمام.
التقاط المتطلبات
للحصول على تحليل مفيد، احتفظ بما يلي:
- مصافحة TCP.
- أول طلب بطيء
- أحجام الحمولة.
- الطوابع الزمنية للحزمة بدقة عالية.
- حزم ACK فقط.
- اتجاه كل شريحة.
- الطوابع الزمنية لسجل التطبيق إذا كانت متوفرة.
- معرفة خيار المقبس إذا كان متاحًا.
لا تقم بقص الفجوات الصغيرة الخاملة. هم الأدلة.
قائمة التحقق من التصحيح
استخدم سير العمل هذا:
- تحديد فجوات الكمون المتكررة.
- قياس مدة الفجوة.
- تحقق مما إذا كانت الحمولات صغيرة.
- تحقق مما إذا كان لدى المرسل بيانات لم يتم الإقرار بها.
- تحقق من توقيت ACK.
- تأكيد عدم إعادة الإرسال يفسر الفجوة.
- قارن مع RTT.
- اختبار كتابة التطبيق التجميعي.
- اختبر
TCP_NODELAYإذا كان ذلك مناسبًا. - الحفاظ على قبل / بعد PCAPS.
التشخيص النهائي
مشاكل TCP Nagle وACK المتأخرة هي مشاكل التوقيت والكتابة الصغيرة، وليست مشاكل عرض النطاق الترددي. الدليل المهم هو المقاطع الصغيرة، وتأخير ACK، وسلوك انتظار المرسل، وفجوات زمن الاستجابة الثابتة المتكررة.
تساعد جراحة PCAP في الحفاظ على توقيت الحزمة المطلوب ومقارنته لإثبات ما إذا كان تطبيق الطلب/الاستجابة البطيء قد تم حظره بواسطة سلوك الحزمة الصغيرة لـ TCP.