Wireshark – תופעות Zero Window ואיך לבדוק "מי אשם" באיטיות במערכת

מבוא

שאלה שתמיד אנחנו שואלים את עצמנו (אחרי התלונות ש"הרשת עובדת לאט"..) היא האם הבעייה היא ברשת או במערכות הקצה – מחשבים, שרתים, Smartphones  וכד'.

על תופעות של איטיות במערכות הקצה כבר דיברתי במאמר על תופעת ה-  TCP Zero-Window. כאן אכנס ליותר פרטים על התופעה, ואיך לבדוק האם האיטיות היא בגלל אפליקציה איטית או מחשב איטי.

מאמר זה הינו סקירה קצרה מתוך פרק Advanced statistics בקורס Wireshark.

חזרה קצרה על TCP ומנגנון ה- Sliding Window

מנגנון ה- Sliding Window עובד באופן הבא (עבור כל TCP Connection בנפרד!)  כאשר שתי תחנות מדברות ביניהן ב- TCP, נפתח קישור (TCP Connection)  ביניהן. בקישור שנפתח, כל צד מודיע לצד השני מה גודל החלון בזיכרון (Memory buffer) שהוא מקצה לטובת התהליך, כאשר תהליך יכול להיות העברת קובץ, DB Client שמדבר עם DB Server, גלישה מול שרת Web  ב- HTTP או כל יישום אחר העובד מעל TCP.

גודל החלון בזיכרון קובע את קצב העברת הנתונים,  לפי הנוסחה המקורבת:

RTT – Round Trip Time: הזמן בין משלוח מנת TCP וקבלת אישור עליה, שקשור באופן ישיר ל-Delay  על הקו

Throughput: רוחב הפס האפקטיבי של האפליקציה, לא כולל תקורות הפרוטוקול

Window Size: גודל המקום בזיכרון שהצד המקבל מקצה לתהליך (ל- TCP Connection)

באופן רגיל, הצד השולח (Sender) מעביר לצד המקבל (Receiver) מנות של מידע (Packets), בכל מנה כמות מסוימת של Bytes, למשל PC עם Browser שגולש באינטרנט ומחובר לשרת Web מסוים. בצד המקבל ה- Buffer מתמלא על ידי המידע הנשלח, למשל התוכן של אותו עמוד אינטרנט. מדי פעם האפליקציה, במקרה הזה ה- Browser על התחנה של הצד המקבל, קוראת את המידע מתוך ה- Buffer של ה- TCP, מרוקנת את ה- Buffer מהמידע שנקרא, ונשלח Acknowledge לצד השולח, במקרה הזה שרת ה- Web.

נאמר שהתחנה שלנו איטית, והשרת מעביר אלינו מידע בקצב גבוה מדי, החלון שהקצינו לתהליך אצלנו בזיכרון יתחיל להתמלא, ואז אחד משני דברים יקרו: או שנודיע לצד השני להקטין את קצב שליחת המידע לקצב (Throughput) מסוים, או שנגיד לו להפסיק לשלוח מידע עד שנפנה מקום בזיכרון. את קצב העברת המידע אלינו TCP מקטין (או מגדיל) על ידי הודעה שגודל המקום בזיכרון אצלנו, ה- Window Size, קטן או התאפס. תוכנת ה- Wireshark תזהה את זה על ידי הודעות Expert מסוג Zero-window ו- Window-full במקרה של חלון שמתאפס או Window-change במקרה של חלון שקטן או גדל.

איך בודקים ועל מה להסתכל

קודם כל, אם אנחנו רואים ב- Analyze – Expert Information  תופעות של Zero Window ו/או Window Full (שכמעט תמיד הם יהיו ביחד) – Zero Window מציין ששדה ה- Window Size ב- Packet שווה ל- 0.

בדוגמא אנחנו רואים ששדה ה- TCP Window Size ב- Packets  שנשלחים מ- 10.0.52.164 אל 61.8.0.17 שווה ל-0. כל מה שנשאר לנו לוודא זה האם התופעה קוראת באפליקציה אחת או בכל האפליקציות העובדות על המחשב, ולפי זה נדע אם זאת בעיית מחשב או בעיית אפליקציה.  כמובן שיכול להיות גם שהאפליקציה משתמשת במנגנון זה כדי לעצור קבלת מידע.

אם נוסיף עמודה של Bytes in flight (קליק ימני על SEQ/ACK analysis à [bytes in flight] בפירוט ה- Packet של ה- TCP), נראה כי ה- Bytes in flight שהם כמות ה- Bytes  שעליהם לא התקבל Ack נשאר נמוך, כלומר כאן אפשר להגיד כמעט בוודאות כי מסיבה כלשהי המחשב המקבל או האפליקציה שאנחנו בודקים נעצרו והבעייה היא בעיית חומרה/תוכנה/אפליקציה.

נוכל גם לראות את זה ב- Statistics – TCP Stream graphs – Window scaling, בתמונה הבאה:

כאשר הצד השולח מעביר כמות גדולה של מידע, והצד המקבל לא מצליח לעבד אותו, אנחנו נראה חלון שהולך ומצטמצם, כמו בדוגמא הבאה.

כאן אנחנו רואים איך החלון הפנוי הולך ומצטמצם עד שמגיע לאפס, בזמן 26.905 שניות מתחילת ה- Capture. במקרה שבו רואים תופעה כזאת, חשוב לבדוק כמה פעמים היא קוראת, האם כל פעם באותו מקום – למשל בגישה לקובץ מסוים, בגישה לדו"ח מסוים ב- Database, בגישה לעמוד אינטרנט מסוים וכד', האם הבעיה קוראת באפליקציה מסוימת או בכל האפליקציות וכד'.

צריך לבדוק גם כמובן נתונים נוספים כמו TCP Retransmissions שיכולים להיגרם גם ממחשבים איטיים, לבדוק מה מקבלים ב- Transum, האם יש זמני תגובה איטיים וממה הם נובעים ועוד.

ודוגמא אחרונה – Client בכתובת 10.0.0.7 מתחבר ב- HTTP לאתר בכתובת 62.219.24.171, ושולח/מקבל ממנו מייל (בדיקה קצרה תגלה לכם שהאתר הוא www.jumbomail.co.il)

התמונה שנקבל ב- TCP Stream graphs – TCPtrace היא:

כאשר אנחנו רואים איך החלון בצד המקבל הולך ומצטמצם עד שיורד לגודל אפס (גודל החלון הוא ההפרש בין הקו העבה התחתון לקו הדק שמעליו). ואם נסתכל על הגרף  שבתמונה הבאה – TCP Stream Graphs – Window Scaling, נראה שקצת אחרי זמן 16.8 שניות מתחילת ה- Capture מתחיל הירידה בגודל החלון הפנוי, כאשר הצד השולח ממשיך לשלוח Packets  עד קצת אחרי 16.88 שניות שם מופיע Zero Window, כלומר הצד המקבל מבקש להפסיק לקבל מידע, במקרה שכאן לקצת יותר משניה. כמו שזה נראה גם כאן בעיה אפליקטיבית, אבל יש לבדוק מאיפה באפליקציה זה מגיע.

סיכום:

במאמר זה נכנסתי קצת יותר לעומק על איך לאתר בעיות חומרה/תוכנה/אפליקציה בתחנות/שרתי קצה.

מקווה שעזרתי ואשמח לענות לכל שאלה או בעיה.

יורם