אחד המנגנונים החשובים ב- TCP הוא ה- Retransmission, שהינו מנגנון של TCP לשדר שוב מנות, TCP segments בשפה של TCP, כאשר לא קיבלנו עליהם Acknowledge בזמן. הזמן שבו אנחנו מצפים לקבל את ה- Acknowledge נקרא RTO – Retransmission Timer Timeout, והוא מחושב (בקירוב) לפי הזמן הממוצע של הגעת ה- Segments ואישורם ב- 4 מנות האחרונות. ניתן לראות זמן זה בפרמטר tcp.analysis.ack_rtt תחת SEQ/ACK Analysis בסוף ה- TCP Segment.
מאמר זה מתבסס על חומר הנלמד בקורס Wireshark.
קיימים 3 סוגים של Retransmissions שה- Wireshark נותן עליהם אינדיקציה:
1. Retransmission – עבור מצב רגיל, שבו TCP Segment לא מקבל Acknowledge בזמן המוגדר (RTO), ואז הוא משודר שוב. דוגמא פשוטה לכך במנה מספר 5968 שהיא Retransmission, ואם נסתכל למעטה בתמונה נראה שה- Retransmission מתבסס על הזמן שעבר ממנה מספר 5957.
2. Fast Retransmissions – במצב שבו יש מספר רב של Acknowledges (מינימום 1*ACK + 2*DuplicateACK) ואז זאת המנה שנדרשת. בדוגמא אנחנו רואים שמחשב 10.0.52.164 שולח מספר רב של Duplicate Acks שבהם הוא מבקש ממחשב 61.8.0.17: שלח לי בבקשה את TCP Segment עם Sequence Number 1731890. ב- Fast Retransmission הוא מקבל את מה שביקש.
3. Spurious Retransmission (נוסך בגרסאות האחרונות של Wireshark) או מה שנקרא Fake Retransmission, כאשר ה- Retransmission אינו אמיתי. בדרך כלל זה יקרה כאשר שלחו אלינו TCP segments, אנחנו שלחנו חזרה Acknowledge שהלך לאיבוד, ואז הצד השני שולח לנו שוב את מה שכבר שלח ואנחנו מזהים את זה כ-Retransmission. דוגמא למצב זה בתמונה הבאה. כאן אנחנו רואים כי מנה 13 היא Retransmission של מנה 8, ומנה 15 היא Retransmission של מנה 11, וזאת למרות שהמנות המקוריות (8 ו- 11) הגיעו. מצב זה יכול להיות למשל כאשר אנחנו קיבלנו את המנה המקורית, שלחנו עליה Ack שלא הגיע, ולכן הצד השני שולח לנו את המנה שוב.
מה יכולה להיות הסיבה לכל מה שראינו? על זה אדבר באחד המאמרים הקרובים.
בקורס Wireshark מתקדם ניכנס לעומק לנושאים אלו.
