پنجره صفر TCP از طریق پروکسی: گیرنده را شناسایی کنید

یک ردیابی بسته TCP ZeroWindow را نشان می‌دهد. پیش از تغییر یک تنظیم هسته، نقطه پایانی‌ای را که صفر را اعلام می‌کند شناسایی کنید.

آن نقطه پایانی ظرفیت دریافت خود را روی همان اتصال TCP توصیف می‌کند. اعلام نمی‌کند که کل پروکسی چه پهنای باندی دارد. کاوش پنجره صفر به فرستنده امکان می‌دهد بفهمد آیا آن ظرفیت اعلام‌شده تغییر کرده است؛ کاوش به‌تنهایی نه افت بسته را ثابت می‌کند و نه پروکسی خراب را.

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

این‌ها گفت‌وگوهای جداگانه TCP هستند. فرض کنید مرورگر خواندن یک پاسخ بزرگ را متوقف کند و روی A صفر اعلام کند. پروکسی می‌تواند در نهایت با پر شدن بافرهای خود، تخلیه B را متوقف کند. پنجره صفر بعدی روی B می‌تواند پیامد کلاینت کند باشد، نه مشکل اصلی.

وضعیت معکوس هنگام بارگذاری ممکن است. اگر برنامه مقصد مصرف داده را متوقف کند، پنجره‌اش روی B می‌تواند بسته شود. فشار سپس می‌تواند از طریق بافرهای پروکسی به سمت کلاینت بازگردد.

مشاهدات را مرتب کنید

1. نقطه‌های پایانی اتصال و جهت انتقال داده آسیب‌دیده را ثبت کنید.
2. مشخص کنید کدام نقطه پایانی نخست پنجره دریافت کوچک‌شونده یا صفر را اعلام کرد.
3. بررسی کنید که برنامه‌اش در حال خواندن بود، روی عملیات دیگری متوقف شده بود یا با منابع محدود بود.
4. زمان‌بندی را روی اتصال دیگر پروکسی مقایسه کنید، پیش از آنکه علت اصلی را تعیین کنید.

برچسب‌های تحلیل پنجره در Wireshark تفسیرهای مفیدی از ضبط هستند، نه دستوری برای بزرگ‌کردن هر بافر دریافت. مقیاس‌بندی پنجره را نیز باید با توجه به مذاکره اتصال تفسیر کرد.

آزمودن نقطه پایانی دیگری از یک فهرست پروکسی و دیدن بازیابی انتقال، شواهد مفیدی است که مسیر تغییر کرده است. اما به‌خودی‌خود ثابت نمی‌کند که پیاده‌سازی TCP یک سیستم‌عامل معیوب بوده است. توضیح را به فرایند دریافت و اتصالی که انتظار در آن آغاز شد گره بزنید.