מבוא:
רציתי לדבר קצת על יישומים ב- Wireshark שבד"כ לא מכירים, או לפחות לא מכירים את החשיבות שלהם ומה אפשר לעשות איתם.
לפתוח את ה- TCP Stream Graphs עוברים לתפריט Statistics, ותחת התפריט, בצד התחתון של Statistics, רואים 5 אפשרויות:
- (Time Sequence (Stevens
- (Time Sequence (tcptrace
- Throughput
- Round Trip Time
- Window Scaling
קצת רקע טכני:
ולפני שניכנס לפרטים, כמה מילים על אופן העבודה של TCP. TCP מבוסס על העברה של Packets, וקבלת אישור שה- Packetsהגיעו (Acknowledgements). מנגנון זה עובד באופן הבא, כפי שרואים בתמונה הבאה:
מה שאנחנו רואים החל מ- Packet 4
(1-2-3 זה הקמת ה- Connection) זה:
- ב- Packet 4, מועבר ה- Byte הראשון (Sequence=1)
- ב- Packet 5, מועבר ה- Byte ה- 1453 (Sequence=1453)
- ב- Packet 6, עובר Ack שאומר לצד השולח: תשלח לי (בבקשה..) את ה- Byte ה- 1453 ועוד גודל המנה האחרונה 1452, כלומר Byte (Sequence) מספר 2905
- ב- Packet 7, מועבר ה- Byte ה- 2905 (Sequence=2905)
- ב- Packet 8, מועבר ה- Byte ה- 4357 (Sequence=4357)
וכן הלאה.
בציור זה נראה ככה:
(במבחני הסמכה של סיסקו יש תמיד שאלה "מה מסמל המספר הנשלח ב- TCP Acknowledge". אל תשכחו לענות שהוא מסמל את ה- Byte הבא שאנחנו מצפים לקבל, ולא את מספר ה- Packet…)
חשוב להדגיש כי מה שאנחנו רואים כאן זה מקרה פשוט, ללא (SACK (Selective ACKs, וכאשר הכול עובד באופן תקין (מקרים מיוחדים כולל תקלות "מאתגרות" במאמרים הבאים…).
מה נראה ב- (TCP Stream Graphs (Stevens
קודם כל, נסמן עם העכבר את ה- Stream שאותו אנחנו רוצים לראות, בכיוון שאנחנו רוצים (ב- TCP חשוב הכיוון, למשל כאן כאשר בכיוון אחד עובד המידע ובכיוון השני חוזרים ה- ACKs). נסמן Packet בכיוון של הגעת המידע ונקבל את מה שאנחנו רואים בתמונה הבאה. נתחיל עם Stevens.
מה אנחנו רואים? בד"כ התקדמות יפה של העברת המידע, אבל יש מספר מקומות שהקו "מתיישר". בואו ניקח מקום אחד כזה, בצד ימין למעלה (מסומן בתמונה) ונתמקד בו באמצעות ה- Zoom בצד שמאל למעטה של החלון.
נקבל את החלון הבא:
בגרף הזה, כל נקודה מסמלת Packet (ואם נדייק – TCP Segments). נקודה שלא במקומה – Packet שקרה לו משהו. ואם נתמקד עוד קצת ("מה קורה כאן" בתמונה) נקבל:
ואם נסמן את Drags (צד שמאל למעטה) ו"נקליק" על הנקודה יביא אותנו ל- Packet מספר 45666 בקובץ, שהוא Fast Retransmission (זה למעשה Retransmission שמגי בתגובה ל- Duplicate Ack אבל לזה ניכנס במאמר אחר).
מה ראינו, שב- TCP Stream Graphs à Stevens אנחנו רואים את קצב התקדמות המידע על ה- TCP Connection, ואם הסדר משובש, משהו כאן קרה.
עכשיו בואו נראה את הגרף המעניין באמת, הוותיק יותר, זה שמגיע מ- Linux, ונקרא TCP Stream Graphs à tcptrace
עוד קצת רקע תיאורטי
מנגנון חשוב נוסף שנדבר עליו וקיים ב-TCP נקרא Sliding Windows. מה הוא אומר? הרעיון פשוט. כל צד ב- Connection מגדיר "חלון" בזיכרון לטובת ה- Connection שאומר מה גודל ה- Buffer שהוא מקצה ל- Connection. ככל שה- Buffer גדול יותר, קצב קבלת המידע שהצד המקבל מוכן לקבל הוא גדול יותר. באמצעות מנגנון זה הצד המקבל את המידע יכול לשלוט על קצב שידור המידע אליו, כאשר ככל שגודל החלון יגדל קצב המידע המשודר יגדל ולהיפך. גודל חלון 0 אוצר לשולח להפסיק לשלוח מידע.
ומנגנון מוסף שנדבר עליו נקרא Duplicate Acknowledge, שנקרא גם DupAck או Negative Ack. כאן הרעיון פשוט – במידה ולא קיבלתי את ה- Packet ש אני מצפה לו, אני אשלח Ack'ים נוספים שמבקשים את ה- Packet (זוכרים – Ack מבקש לשלוח לי את ה- Sequence הבא). כאשר השולח ישלח לי את ה- Packet שלו אני מצפה יקראו לזה Fast Retransmission.
מה נראה ב- (TCP Stream Graphs (tcptrace
מה שנראה כאן הרבה יותר מעניין. נתמקד באותו הקובץ, נתמקד ב"יישורת" בצד ימין למעלה וצילום מסך הבא נראה מה נקבל.
מה שאנחנו רואים זה שני קווים עיקריים:
- בקו התחתון אנחנו רואים את התקדמות העברת ה- Bytes, כלומר התקדמות ה- Sequences
- בקו העליון אנחנו רואים עד איזה Byte המחשב המקבל מוכן לקבל Bytes מהשולח.
ההפרש בין שי הקווים נותן את גודל החלון הפנוי. כמובן שהצטמצמות החלון אומרת ירידה ב- Throughput או בקצב המידע שה- Receiver יכול לקבל וקווים צמודים אומרים קצב אפס. תקלות אביא במאמרים הבאים. בואו נמשיך להתמקד וניכנס ב- Zoom לקטע הקצר שמשמאל ל- 60 שניות, ראה בצילום מסך להלן.
כאן אנחנו רואים מצב תקין – שני Packets נשלחים, ואז ה- ACK מגיע (הקו הדק עוקב אחרי המקטעים של המנות). במצבים לא תקינים נראה עיכובים, חזרות (Retransmissions) ועוד מספר תופעות שנראה בתקלות שאביא.
מה נראה ב- (TCP Stream Graphs (Throughput
כאן נראה את ה- Throughput (הקו המשתנה, צבע חום), את גודל ה- TCP Segment המקסימלי ואת גודל ה- TCP Segment הממוצע.
אם נבחר גם להראות את ה- Goodput, שהוא ה- Throughput האפקטיבי שעבר (כמות ה- Bytes/Sequences של מידע אמיתי שעברו מתוך כל ה- Bytes באותו הכיוון) נראה כמעט תמיד שקרוב מאוד ל- Throughput הרגיל. אם לא, יצביע על בעיה.
מה נראה ב- (TCP Stream Graphs (Window Scaling
גרף זה מציג בצורה פשוטה עד כמה ה- Receiver יכול ועומד בקבלת מידע מה- Sender. איך רואים את זה:
- בקו התחתון (העשוי מנקודות המייצגות Packets) אנחנו רואים מספר ה- Bytes שנשלחו ושהתקבלו על ידי ה- Receiver
- בקו הדק העליון אנחנו רואים את גודל החלון של ה- Receicer. גודל חלון יציב אומר שה- Receuiver יכול לקבל את כל המידע שנשלח אליו, ולא צריך להתאים את גודל החלון. ככה זה אמור להיות.
שינויים בקו העליון, למשל צורת "שן מסור" מצביעים על כך שה- Receiver לא עומד בקצב ההעברה, וסביר להניח שיש בו בעיית חומרה ו/או תוכנה ש"חונקים" אותו.
בדוגמא הנ"ל אנחנו רואים מצב תקין. כמובן שגודל החלון הוא רק אחד הפרמטרים שמשפיעים על מהירות ההעברה, וישנם נוספים כמו RTT, Packet losses וכד'.
מה נראה ב- (TCP Stream Graphs (Round Trip Time
ואחרון, גרף בשם Round Trip Time נותן לנו את ה- RTT, זהו הזמן שבים משלוח Sequences לבין קבלת ה- ACKs עליהם. יש לזכור שעיכוב ב- ACK יכול להיות בגלל Delay ברשת אבל גם בגלל אפליקציה או שרת שלא מגיבים מספיק מהר.
כאן אנחנו רואים את השינוי ב- RTT לאורך הזמן. במקרה הזה אנחנו רואים שינויים שבין מילי-שניות בודדות ועד לכ- 200 מילי-שניות במקסימום. במקרה הזה, למרות שהשינויים נראים קיצוניים, הם עדיין בגדר הנורה ל- TCP, וכמובן גם כאן יש לא מעט פרמטרים נוספים שיש להתחשב בהם ונראה אותם בהמשך.
לסיכום
ה- TCP Stream Graphs הוא אחד הכלים החשובים ב- Wireshark. בהמשך נראה תקלות בהם השתמשתי בהם ועזרו מאוד באיתור ופתרון התקלות.
מקווה שעזרתי ואשמח לענות לכל שאלה או בעייה.
להעשרה והרשמה לקורסים בנושא Wireshrak, עכשיו גם ב-Online: