הכירות עם פרוטוקולי TCP/IP
חוברת הכנה

לפני שמידע מתחיל לעבור מעל פרוטוקול TCP , מוקם קשר בין 2 תחנות הקצה. יוזם הקשר תופס פורט מקבוצת המספרים הגבוהים, ושולח בקשה ליצירת קשר לקצה השני. הקצה השני הוא בדרך כלל שרת שמאזין על אחד מהפורטים הנמוכים ) Well known ports (, כך ששולח הבקשה יודע לאיזו כתובת IP ולאיזה פורט למען את הבקשה.

הקמת הקשר כרוכה בהחלפת 3 הודעות במה שנקרא Triple hand shake . זה נראה כך:

בתום החלפת 3 הודעות אלו אפשר להתחיל לשלוח מידע ב- 2 הכיוונים. כמעט תמיד זה שפתח את הקשר ישלח מידע ראשון.

ראוי להזכיר שבעולם ה- TCP/IP היחידים שמודעים לקשר שנוצר הן 2 תחנות הקצה. כל הצמתים האחרים בתווך מתייחסים להודעות אלו כהודעות IP , כך שבהחלט יכול לקרות מצב שבו הודעות שונות ששייכות לאותו קשר ינותבו דרך נתיבים שונים.

יש 2 דרכים מרכזיות להודיע לצד השני על סיום קשר ה- TCP .

הדרך הראשונה היא המסודרת, ומופעלת כאשר הקשר סיים את תפקידו (למשל דף ה- HTML גמר לרדת). גם כאן מופעלת הדדיות מסוימת, כאשר כל צד מודיע על כך שהוא מסיים את הקשר, והצד השני מאשר את ההודעה. סה"כ נשלחות 3 או 4 הודעות באופן הבא:

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

ישנן הרבה סיבות אפשריות למצב בו צד אחד חושב שהקשר קיים וצד שני כבר לא. למשל, תוכנית (למשל דפדפן) שהתרסקה, או כאשר יש אובדן של חבילות שאי אפשר לגשר עליו, הצד שמבחין בזה מסיים את הקשר. דוגמא נוספת היא של שרת שעבר Restart , אבל יש clients שלא מודעים לכך ושולחים בקשה על גבי קשר שכבר לא קיים.

כפי שכבר הוזכר, פרוטוקול TCP מבטיח את אמינות הקשר בין 2 הקצוות. 2 השדות החשובים ביותר ב- Header של TCP המשמשים למטרה זו הם ה- Sequence Number וה- Acknowledgement Number .

על מנת להבין טוב יותר כיצד פועל TCP נשתמש בדוגמא של אימייל. נניח שאפליקצית אימייל כלשהי שולחת 3 הודעות אימייל ברצף. המיילים הראשון והשלישי של 100 בתים והמייל השני של 10000 בתים. כיצד זה מתורגם ל- TCP ?

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

ה- sequence number מבטא היטב את הגישה הזו בכך שהוא מציין כמה בתים עברו מאז שהקשר הוקם, ללא התייחסות כלל למספר ההודעות. המספר מייצג את המספר הסידורי של הבית הראשון של החבילה. אם נניח לצורך הדוגמא שה- sequence number מתחיל מאפס, אז החבילה הראשונה יוצאת עם sequence number=1 , החבילה השניה עם sequence number=1001 , החבילה החמישית עם sequence number=4000 .

ה- Acknowledgment number מציין מה הבית האחרון שהתקבל מהקצה השני, בתנאי שכל הבתים שלפניו התקבלו גם הם. במילים אחרות, הוא מציין את הבית הבא אותו המקבל מצפה לקבל מהשולח. מבולבלים? הנה כמה דוגמאות:

מחשב A שולח כמה חבילות עם מידע למחשב B . מחשב B מקבל את כולם בזמן ושולח ACK עבור כל אחד. מכיוון שהמידע זורם רק בכיוון אחד, מ- A ל- B ה- sequence בכיוון השני נשאר תמיד 1

בדוגמא זו נתייחס למקרה אחד של אובדן חבילות. במקרה זה, חבילה עם מידע הולכת לאיבוד. המחשב השולח A מחכה זמן מסויים (timeout) ומשלא מגיעה הודעת ack עבור חבילה זו, הוא שולח את החבילה שוב.

זהו שכלול של מנגנון השליחה מחדש שהוצג בסעיף הקודם. בדוגמא הזו, חבילה אשר מהווה חלק מרצף חבילות (דבר הנפוץ מאד ברשת) הולכת לאיבוד. המחשב השולח A מקבל על כך אינדיקציה ממחשב B ע"י זה שמחשב B שולח כמה חבילות עם אותו ערך ב- ack duplicate) ack). אחרי שלושה duplicate acks מחשב A מבין שההודעה הלכה לאיבוד ושולח אותה שוב. מנגנון זה נקרא fast retransmit מכיוון שהמחשב השולח לא מחכה ל- timeout על מנת לשלוח את החבילה שוב, מה שמייעל מאד את מנגנון ה- TCP .

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

כאמור, אחד מתפקידי שכבת ה- TCP הינו לחלק את זרימת המידע לחבילות IP בהתאם לגודל ה- MTU . כל חתיכה כזו של מידע נקראת סגמנט. גודל הסגמנט נקבע בעת הקמת הקשר. במסגרת ה- Triple Hand Shake , מועבר מידע בין שני הצדדים אשר נקרא MSS) Maximum Segment Size). ה- MSS הינו חלק ה- Data של חבילת ה- TCP (מה שמסומן בכחול בציור למטה). ה- MSS שכל צד מעביר נגזר בדרך כלל מה- MTU פחות גודל ה- Headers כפי שהוא מוגדר בתחנת הקצה.

הפעולה של חלוקת ה- data לסגמנטים נקראת סגמנטציה (segmentation) .

מכיוון שלפעמים יש הרבה מאד מידע אשר זורם במהירות, פעולת החלוקה הזו, אשר נקראת סגמנטציה, גוזלת משאבי CPU . עלמנת להקל על ה- CPU , כרטיסי רשת רבים תומכים בפעולה שנקראת TCP Segmentation Offloading , או בקיצור TSO . כאשר TSO מופעל, מערכת ההפעלה בונה חבילות IP המכילות כמה סגמנטים, וגדולות בצורה משמעותית מה- MTU 0 (אפילו פי 40 ויותר). הכרטיס מקבל את החבילות הגדולות ומפרק אותן לחבילות קטנות יותר בהתאם למה שמותר לו להעביר ברשת.

ראוי לציין שהרשת לא מרגישה אם מחשב מבצע TSO או לא. כך או כך החבילות יוצאות בגודל של MSS אחד. זהו אלגוריתם פנימי שמתבצע בין המעבד לכרטיס הרשת.

הנה דוגמא שתמחיש את השיטה:

נניח שאפליקציה צריכה להעביר 3000 בתים. גודל מקסימלי של חבילה הוא 1100 בתים, ואורך ה- Headers הוא 100 בתים. מכאן נובע שה- MSS הוא 1000 בתים, והמידע יעבור ב- 3 חבילות.

אם אין TSO , רמת האפליקציה שולחת 3000 בתים לרמת ה- TCP . ה- TCP מבצע סגמנטציה לפי ה - MSS , מחלק ל- 3 חלקים מוסיף TCP Header ומעביר כל אחד מהחלקים לשכבת ה- IP , שמוסיפה Header משלה וכך הלאה עד שהחבילות יוצאות מתוך השיכבה הפיזית.

אם TSO מופעל, עד לשכבה 2 המידע יגיע כיחידה אחת, ורק כרטיס הרשת יעשה את הפירוק לסגמנטים:

בצורה זו קטן העומס על ה- CPU , ובנוסף לכך מספר קריאות ה- I/O בין המחשב לכרטיס הרשת יורד גם הוא.

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

אם נמשיך את הדוגמא שלמעלה, נניח שאפליקציה רוצה להעביר מליון בתים. ה- TSO יכול להחליט להעביר 10 סגמנטים כל פעם. מכיוון שה- MSS הוא 1000 , ה- TCP ישבור את המידע לקבוצות של 10,000 בתים ויעביר אותם ל- IP . כרטיס הרשת כבר ישבור את כל חבילה של 10,000 בתים למסגרות של 1000 פלוס Headers .

קיימים שני מנגנונים שנועדו לווסת את קצב שליחת המידע על מנת שלא ייווצר מצב של עומס יתר. המנגנונים הם בקרת זרימה (Flow Control) , ובקרת גודש (Congestion Control). למרות שהמטרה היא זהה, מדובר בשני מנגנונים שונים שנובעים מצורך אחר. בקרת זרימה נועדה למנוע מצב בו התחנה המקבלת אינה יכולה לקבל עוד חבילות מידע. לעומת זאת בקרת גודש נועדה להתמודד עם מצב בו לאורך הנתיב בין המחשב שמשדר את הנתונים לזה שמקבל אותם יש צוואר בקבוק שאינו מסוגל להתמודד עם תעבורה מעל לקיבולת מסויימת.

על מנת להבין את המנגנונים, נדבר לפני כן על מונח אחר שיעזור להבין אותם, Bytes in Flight .

ההגדרה של Bytes in Flight היא מספר הבתים שהשולח שלח, ושעדיין לא קיבל עליהם תשובה.

לדוגמא, אם ה- ACK האחרון שקיבלתי הוא 1200 ושלחתי seq=2500, data size=120 אז ערך ה- Bytes in Flight הוא 1420=2500+120-1200 . בתים אלו יכולים ל הימצא בכמה מקומות: בתורים של נתבים ומתגים, על קווי שידור ארוכים, כרטיס הרשת מבצע סגמנטציה מחכים לעיבוד בצד המקבל, או שהבתים כבר הגיעו, אבל ה- ACK הוא בדרך ולכן השולח עדיין לא יודע מזה ומבחינתו הבתים לא התקבלו.

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

השדה האחראי על בקרה הזרימה הוא Receive Window או בקיצור RWin. כשצד B שולח ל- A ערך X בשדה זה, המשמעות היא שאסור לשדה A לחרוג מ- X bytes in flight .

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

לדוגמא, נניח שיש Round trip time קבוע של 0.2 שניות, וגודל חלון של 80 Kbytes. יקרה הדבר הבא:

יוצא שבמחזור זמן של 0.2 שניות יכולות לעבור על הקו רק 80 אלף בתים. ולכן קצב התעבורה האפקטיבי על הקו הוא 80,000/0.2 שזה 400Kbytes/sec . ובאופן כללי הנוסחה היא Throughput=WinSize/RTT .

גודל השדה של Receive Window נקבע ל- 2 בתים. עם הזמן, כשקצבי השידור עלו, גודל של 2 בתים, שמגביל את גודל החלון ל- 64K , נהפך לקטן מדי וממש פגע ב- throughput . לכן הוסיפו שדה אופצניונאלי נוסף של Window Scale .

עכשיו חישוב חלון הקבלה יחושב כך: אם שדה ב- Rcv Win הוא X ושדה ה- Win Scale הוא Y, אז גודל חלון הקבלה הוא X*2^Y . הגודל החוקי המקסימלי כיום הוא 1GB .

Window Scale מועבר רק בעת יצירת הקשר, כלומר כאשר דגל SYN מודלק. ספציפית עבור חבילות SYN הפקטור לא מופעל, מה שלא משנה כלל לאור העובדה שלא עוברים נתונים בחבילה זו.

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

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

הנה דוגמא למצב של עומס יתר. הרשת המצויירת בציור למטה מבוססת כולה על 100Mbps Ethernet . ישנם 2 קשרי TCP , האחד בין מחשב A למחשב D (הקו הכחול) והשני בין מחשב B למחשב C (הקו הירוק). מחשב A משדר למחשב D במלוא העוצמה, כלומר בקצב של 100Mbps . כך עושה גם מחשב C למחשב B. כאשר כל אחד מהם משדר בזמן אחר אין בעיה. אולם כאשר הם משדרים ביחד, נוצר עומס יתר על קטע המשותף ביניהם, כלומר על הקו בין R1 ל- R2 . מהר מאד יצטברו חבילות ב- R1 ולא יצליחו לצאת לכיוון R2 . התורים ב- R1 יתמלאו מהר מאד וחבילות יתחילו להיזרק. במצב כזה המחשבים השולחים יבצעו שליחה מחדש של החבילות שנזרקו, מה שיגרום לנצילות של הקו לרדת. בעולם האמיתי בו המרחק בין המקור ליעד הרבה י ותר גדול מדובר בבזבוז משאבים רב יותר בגלל החבילות הרבות שתופסות רוחב פס ובסוף לא מגיעות ליעדן.

מכיוון ש- TCP הוא פרוטוקול קצה אל קצה, R1 אינו יכול לדווח כי הוא מתקרב למצב של עומס יתר. לכן רק תחנות הקצה יכולות לזהות מצב זה ולהגיב אליו. זה יקרה כאשר הקשר יגיע למצב של אובדן חבילות. כפי שהוסבר בסעיף על אמינות הקשר, הזיהוי נעשה כאשר תחנת הקצה מקבלת Timeout או שלושה duplicate acks . במצב אובדן חב ילות תתבצע שליחה מחדש של החבילה האבודה וגם הערכה מחדש של קצב השידור.

גם בקרת גודש קיים מתייחס ל- Bytes in Flight , הפעם עם חלון גודש (CWND). חלון הגודש קובע כמה בתים המחשב יכול לשלוח מבלי שקיבל עליהם ACK. בניגוד לחלון קבלה, זהו פרמטר פנימי שהשולח קובע עם עצמו, ולכן ה וא אינו חלק מהפרוטוקול. חלון הגודש מתחיל מגודל מסויים, וכל עוד אין אבדן חבילות גודל הוא עולה בהתמדה. כאשר המחשב מזהה אובדן חבילות, הוא מוריד בצורה דרסטית את גודל חלון הגודש, ומעלה אותו שוב קצת יותר בזהירות עד אובדן החבילות הבא וחוזר חלילה. בצורה זו הוא מווסת את עצמו. במקרה שערך CWND יורד מתחת לערך Bytes in Flight הנוכחי, שידור החבילות מפסיק עד אשר CWND יעלה שוב מעל לערך זה.

כפי שלמדתם בקורס מבוא לרשתות, פרוטוקול TCP מתבסס על אלגוריתם Go Back N , כלומר מותר לשולח לשדר כמות מסוימת של מידע מבלי שקיבל עליה חיווי.

גרסאות מתקדמות יותר של הפרוטוקול, ובכלל זה הגרסא שממומשת במחשבי ה- Linux במעבדה הוסיפו אלמנטים של selective repeat . מנגנון זה נקרא Selective Ack או בקיצור SACK .

מהו מנגנון ה- SACK ?

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

על מנת לייעל יותר את קשר ה- TCP פותח מנגנון ה- SACK . נניח את התרחיש הבא:

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

בהתאם לפרוטוקול TCP , ערך ה- ACK שהמקבל מעביר לשולח הוא 1000 , מכיוון שזהו הבית הראשון אותו הוא לא קיבל.

כאשר SACK לא ממומש, מבחינת השולח ישנם 6000 בתים שהוא שלח ועדיין לא קיבל עליהם חיווי. מכיוון שזהו גודל החלון, יש הפסקה בשליחה.

כאשר SACK ממומש, המקבל מעביר לשולח את התמונה כפי שהיא. כלומר הוא מדווח לו שהבתים 1200-2000 , 2200-4000 ו- 4200-5000 הגיעו גם כן. זה נותן כמה יתרונות יחסית לשיטה הקודמת:

1. מבחינת השולח יש רק 2600 בתים שהוא לא קיבל עליהם חיווי (600 שהלכו לאיבוד ועוד 2000 אפורים בדרך). לכן אפשר להמשיך לשדר.
2. נעשה שידור מחדש רק לבתים שהלכו לאיבוד, כלומר לבתים 1000-1200 , 2000-2200 ו- 4000-4200

• Source Port : הפורט שהמחשב השולח משתמש בו לקשר זה
• Destination Port : הפורט שהמחשב המקבל משתמש בו לקשר זה
• Sequence Number : כפי שהוסבר למעלה
• Acknowledgement Number : כפי שהוסבר למעלה
• HLEN : אורך ה- TCP Header
• דגלים: ראו בסעיף הבא.
• Window : גודל חלון הקבלה כפי שהוסבר בסעיף על בקרת זרימה
• Checksum : בדיקת נכונות של המידע, כולל ה- TCP Header וה- dat
• Urgent Pointer : לא נרחיב עליו את הדיבור כי הוא לא ממש בשימוש
• Options : לעיתים יש הרחבה של הפרוטוקול לאופציות נוספות. הרחבה על כך בהמשך

שדה הדגלים מורכב מ- 6 דגלים. הנה אלו אשר תיתקלו בהם במהלך הניסוי:

• SYN : בקשה לפתיחת קשר
• FIN : בקשה לסיום קשר
• RST : הודעה על הפסקת הקשר. השולח ישלח הודעת RST כלל כאשר מבחינתו הקשר כבר לא קיים (או שלא היה קיים מעולם)
• ACK : מעיד על כך שההודעה מכילה ערך בשדה ה- ACK
• PUSH : ההודעה צריכה להגיע לאפליקציה כמה שיותר מהר, בלי לחכות ל- data נוסףץ הרבה פעמים נראה את הדגל הזה בהודעות קצרות, כי בהם היה מצופה שמנגנון ה- TCP ימתין לעוד data לפני שהוא מעביר את ההודעה הלאה

פרוטוקול TCP , כפי שכבר הוזכר, עבר כמה שכלולים והרחבות עם השנים, במסגרתם היה צורך בשדות נוספים ב- header . הבעיה בלהוסיף שדות היא שלא ניתן לדעת איזה host משתמש באיזו גירסה, ולכן ה- header הבסיסי לא יכול להשתנות, על מנת שכל host יוכל לתקשר עם כל host אחר. לכן התוספות לפרוטוקול מגיעות בשיטת Type Length Value או בקיצור TLV .

השיטה עובדת כך:

• השדה הראשון שהוא היחיד המנדטורי, מגדיר את סוג התוספת, שנקרא Kind . גודל השדה הוא בית אחד, ולכן יכולים להיות 256 ערכים. ארגון IANA אחראי על התקינה שקובעת את המספור הזה. כיום יש עשרות בודדות של סוגי תוספות, ואנחנו בניסוי ניתקל בכמה מהם.
• השדה השני הוא Length שמגדיר את אורך התוספת כולל שדות ה- Kind וה- Length
• השדה השלישי הוא הערך של התוספת.

דוגמאות:

אמינות שידור

1. כיצד מחשב ששולח רצף חבילות TCP מזהה במהירות שאחת החבילות הלכה לאיבוד ?
2. נניח שמחשב א' צריך לשלוח למחשב ב' 10000 בתים . גודל ה- payload המירבי הוא 1000 בתים והרשת עובדת כהלכה (אין אבדן מידע, איבוד בדר של החבילות וכו'). מה יהיה ב- sequence number של חבילת ה- IP השישית שתישלח? מה יהיה ה- ack השישי ?
3. בציור שבעמוד הבא, ציינו את מספר ה- ack עבור חבילות 1-8 מ- B ל- A,
4. אם נתבסס על אותו ציור, נניח שגודל חלון הגודש ( CWND ) הוא 1500 בתים. כמה חבילות נוספות יכול A לשדר, שלא צוירו בציור, לפני שהוא נעצר בגלל מגבלת גודל חלון (יש להתעלם מתזמונים, כלומר להניח שלא מפסיקים את השידור בגלל ה- Fast Retransmit) ?

סגמנטציה

5. הסבר מדוע לא ניתקל ב- IP Fragmentation בקשר TCP מעל Ethernet
6. מחשב 1 שולח למחשב 2 שלוש הודעות על גבי ערוץ TCP . התוכן של כל הודעה הינו הבתים 0x02 , 0x01 , 0x00 עד 0x09 . המחשבים קבעו ביניהם בזמן הקמת הקשר, שגודל ה- MSS הוא 16 . כמה הודעות TCP יישלחו, ומה יהיה התוכן של כל הודעה?

בקרת גודש

7. נתונה רשת שבה RTT=100ms ו - RWin=10,000Bytes . שאר הפרמטרים (מהירות הקו, קצב קליטת המידע אצל המקבל וכו') הם ללא הגבלה. מהו הקצב האפקטיבי של הקו אחרי שהמערכת מגיעה למצב יציב?
8. שני מחשבים, מחשב א' וב' מחוברים זה אל זה בחיבור איטי יחסית. את החיבור בין המחשבים נתאר כתור. מחשב א' שולח פקטות למחשב ב', כאשר נתון:
   1. קצב השחרור מהתור הוא 512Kbps (ביטים)
   2. למחשב ב' לוקח 100msec לעבד פקטה ולהחזיר תשובה.
   3. ה- RTT של כל פקטה, כפי שרואה מחשב א', בממוצע הוא 500msec
   מה הוא גודל התור ב- KB (קילו בתים)?
9. שני מחשבים, מחשב א' וב' מחוברים זה אל זה בחיבור איטי יחסית, עם זמן שהיה גבוה. מחשב א' שולח פקטות למחשב ב', ומנצל את הקו ניצולת מלאה. נתון:
   1. מהירות הקו היא 512Kbps (ביטים)
   2. Round Trip Time = 500ms
   כמה Bytes in Flight רואה מחשב א'?