نافذة TCP الصفرية عبر وكيل: تحديد المتلقي

يُظهر تتبع الحزم TCP ZeroWindow. قبل تغيير إعداد في النواة، حدد الطرف الذي يعلن الصفر.

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

browser  <-- TCP A -->  proxy  <-- TCP B -->  website

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

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

رتّب المشاهدات

1. سجّل طرفي الاتصال واتجاه نقل البيانات المتأثر.
2. حدد الطرف الذي أعلن أولًا نافذة استقبال متقلصة أو صفرية.
3. تحقق مما إذا كان تطبيقه يقرأ، أو توقف عند عملية أخرى، أو كان مقيدًا بالموارد.
4. قارن التوقيت على الاتصال الآخر للوكيل قبل إسناد السبب الأصلي.

تسميات تحليل النوافذ في Wireshark تفسيرات مفيدة للالتقاط، وليست تعليمًا بزيادة كل مخزن استقبال. كما يجب تفسير تحجيم النافذة في ضوء تفاوض الاتصال.

إن تجربة طرف آخر من قائمة الوكلاء ورؤية النقل ينتعش دليل مفيد على أن المسار تغير. لكنه لا يثبت بذاته أن تنفيذ TCP في نظام تشغيل ما كان معيبًا. أبقِ التفسير مرتبطًا بعملية الاستقبال والاتصال الذي بدأ فيه الانتظار.