תוכנת Wireshark הינה תוכנה המיועדת לאיתור תקלות ברשתות תקשורת, אבל התקשורת לא חיה לבד. גם כאשר יש לנו בעיות איטיות הנוסעות משרתים או תחנות איטיות, אפליקציה איטית או אפילו מרכיב מסוים באפליקציה איטי, נוכל כמעט תמיד לזהות את הבעיה באמצעות התוכנה, ולפעמים אפילו נוכל לדעת במדויק מהיכן היא נובעת.
מאמר זה מתבסס על קורס Wireshark – פרטים נוספים בעמוד הקורס.
אחת הדרכים לזהות תופעות אלו של איטיות בנקודות הקצה (שרת, תחנה או אחד היישומים העובדים בינהם) היא איתור בעיות איטיות הנובעות ממנגנון ה- Sliding Windows של TCP.
איך עובד מנגנון זה? פשוט מאוד. כאשר שתי תחנות מדברות בינהן ב- TCP, נפתח קישור (TCP Connection) בינהן. בקישור שנפתח, כל צד מודיע לצד השני מה גודל החלון בזיכרון (Memory buffer) שהוא מקצה לטובת התהליך, כאשר תהליך יכול להיות העברת קובץ, DB Client שמדבר עם DB Server, גלישה מול שרת Web ב- HTTP או כל יישום אחר העובד מעל TCP.
גודל החלון בזיכרון קובע את קצב העברת הנתונים, לפי הנוסחה המקורבת:
RTT – Round Trip Time: הזמן בין משלוח מנת TCP וקבלת אישור עליה, שקשור באופן ישיר ל- Delay על הקו
Throughput: רוחב הפס האפקטיבי של האפליקציה, לא כולל תקורות
Window Size: גודל המקום בזיכרון שהצד המקבל מקצה לתהליך (ל- TCP Connection)
ועכשיו, נאמר שהתחנה שלנו איטית, והשרת מעביר אלינו מידע בקצב גבוה מדי, החלון שהקצינו לתהליך אצלנו בזיכרון יתחיל להתמלא, ואז אחד משני דברים יקרו: או שנודיע לצד השני להקטין את קצב שליחת המידע לקצב (Throughput) מסוים, או שנגיד לו להפסיק לשלוח מידע עד שנפנה מקום בזיכרון. את קצב העברת המידע אלינו TCP מקטין (או מגדיל) על ידי הודעה שגודל המקום בזיכרון אצלנו, ה- Window Size, קטן או התאפס. תוכנת ה- Wireshark תזהה את זה על ידי הודעות Expert מסוג Zero-window ו- Window-full במקרה של חלון שמתאפס או Window-change במקרה של חלון שקטן או גדל.
בואו נראה כמה דוגמאות. קודם כל, בכל פעם שאני בודק רשת באמצעות Wireshark, אחד הדברים הראשונים לעשות זה לפתוח את חלון ה- Expert Information (מתוך תפריט Analyse), ולראות אם ישנן תופעות חריגות. במקרה שלנו, אנחנו רואים כמות גדולה מאוד של TCP Window Full (ראה תמונה להלן):
ועכשיו, אם נקליק על אחת השורות (כל שורה מציינת מנה), נעבור לקובץ ונראה את התופעה במדוייק:
מה אנחנו רואים? בצד התחתון של המסך אנחנו רואים הודעה ש- TCP Window שהוגדר על ידי המקבל (Receiver) – 10.10.40.19, הינו מלא לגמרי. איך התוכנה יודעת את זה? פשוט. היא רואה בתוך ה- Header של ה- TCP את גודל החלון שהמקבל (ה- Receiver) שלח לשולח (ה- Sender), ואז סופרת את מספר ה- Bytes שנשלחו אליו ועדייו לא התקבל אישור (Ack) עבורם.
ועכשיו, נגדיר Display filer – tcp.analysis.window_full (כפי שרואים בתמונה הבאה):
נעבור למסך Conversations (מתוך תפריט Statistics), ונגדיר Limit to display filter, נראה כי כל התופעות מסוג זה הינן בין 10.10.49.19 לבין 10.10.20.9, והבעייה כמובן שהיעד אליו שולחים את המידע, באפליקציה המסוימת אליו הוא נשלח, איטי (בתמונה הבאה – בתמונה העליונה המסך ללא הפילטר, ובתחתונה עם הפילטר):
ועכשיו, נראה איך נראה שרת "חנוק", וכאן רואים את הבעיה הרבה יותר יפה (או לא יפה, תלוי מי מסתכל …):
כאן אנחנו רואים תנועה תקינה בין 91.208.139.200 ל- 192.168.13.128, שבמנה מספר 2487 משהו "מתקלקל" ואנחנו רואים הודאה של TCP Window Full. קודם ראינו שהודאה כזאת אומרת שהחלון של המקבל, במקרה הזה 192.168.13.128, מלא.
מיד לאחר שתי פענוחים של TCP Window Full אנחנו רואים הודאה ש- 192.168.13.128 שולח, כלומר הוא שולח את הערך 0 בתוך שדה ה- Window Size ב- Header של ה- TCP, ולמעשה אומר לצד השני – "תפסיק לשלוח אלי מידע, אין לי מקום בזיכרון".
וזוב, כדי לדעת מי "חנוק", ניגש למסך Conversations, נגדיר פילטר על TCP Zero-Window, ונראה מי חנוק, ואיזה אפליקציה חנוקה (לפי ה- TCP Port Number כמובן).
במקרה הזה, של Zero-window שמשתחרר אחרי זמן קצר, צריך לבדוק מה גרם לשרת או לתחנה "לקפוא" לפרק זמן זה – יכול להיות איזה תוכנה שרצה (למשל סריקה של אנטי וירוס), עומס פתאומי מהרשת או כל דבר אחר שנוכל לזהות לפי ה- TCP Port number.
בתמונה הבאה רואים איך העומס משתחרר – הודעת TCP window update, והכל חוזר להיות כרגיל:
ניכנס לעומק לנושא זה בקורס Wireshark מתקדם.
ולסיכום:
- לא כל איטיות היא בגלל הרשת (הרוב אפילו לא כאלה)
- שימו לב לתופעות של TCP Windows – כמעט תמיד אלו אינדיקציות לשרת או תחנת קצה איטיים, או אפליקציה איטית או בעייתית מסיבה כלשהי
- לזהות האם זה שרת/תחנה מסוימים או אפליקציה מסוימת – כנסו לחלון Conversations והפעילו עם הפילטר המתאים
מקווה שעזרתי ואשמח לענות לכל שאלה או בעיה.
יורם