חלון TCP אפס דרך פרוקסי: זהו את המקלט
אתרו את בקרת הזרימה של TCP בצד הלקוח או השרת של הפרוקסי לפני שתייחסו הורדה שנתקעה לשינוי קנה מידה של חלון או לגודל חוצץ.
קובץ מעקב מנות מראה TCP ZeroWindow. לפני שינוי הגדרת ליבה, זהו את נקודת הקצה שמכריזה על האפס.
נקודת הקצה הזו מתארת את קיבולת הקליטה שלה באותו חיבור TCP. היא אינה מכריזה כמה רוחב פס יש לפרוקסי כולו. בדיקת חלון אפס מאפשרת לשולח לגלות אם הקיבולת המוכרזת השתנתה; הבדיקות לבדן אינן מוכיחות אובדן מנות או פרוקסי תקול.
browser <-- TCP A --> proxy <-- TCP B --> websiteאלה שיחות TCP נפרדות. נניח שהדפדפן מפסיק לקרוא תגובה גדולה ומכריז אפס על A. הפרוקסי עשוי בסופו של דבר להפסיק לרוקן את B כשהחוצצים שלו מתמלאים. חלון אפס מאוחר יותר על B עשוי להיות תוצאה של הלקוח האיטי ולא הבעיה המקורית.
המצב ההפוך אפשרי בזמן העלאה. אם אפליקציית היעד מפסיקה לצרוך נתונים, החלון שלה על B עשוי להיסגר. הלחץ יכול אז לנוע בחזרה אל הלקוח דרך החוצצים של הפרוקסי.
סדרו את התצפיות
- רשמו את נקודות הקצה של החיבור ואת כיוון העברת הנתונים שנפגעה.
- זהו איזו נקודת קצה הכריזה ראשונה על חלון קליטה הולך וקטן או אפס.
- בדקו אם האפליקציה שלה קראה, עמדה בפעולה אחרת או הוגבלה במשאבים.
- השוו את התזמון בחיבור האחר של הפרוקסי לפני שאתם קובעים את הסיבה המקורית.
תוויות ניתוח החלונות של Wireshark הן פרשנויות מועילות של הלכידה, לא הוראה להגדיל כל חוצץ קליטה. גם שינוי קנה המידה של החלון צריך להתפרש לאור המשא ומתן של החיבור.
ניסיון נקודת קצה אחרת מרשימת פרוקסי ולראות שההעברה מתאוששת הוא ראיה מועילה שהנתיב השתנה. אך הוא לבדו אינו מוכיח שיישום ה-TCP של מערכת הפעלה כלשהי היה פגום. שמרו את ההסבר קשור לתהליך הקולט ולחיבור שבו החלה ההמתנה.