שכבת התעבורה מוסברת לעומק - מה קורה בפועל מתחת למילה TCP

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

פורטים - איך כתובת אחת משרתת עשרות שיחות בו זמנית

כתובת IP מזהה מחשב, אבל מחשב בודד מריץ עשרות תהליכים שכל אחד רוצה לתקשר ברשת - דפדפן שפותח כמה חיבורים במקביל, לקוח מייל, שיחת וידאו, כולם על אותה כתובת IP בדיוק. הדרך שבה שכבת התעבורה פותרת את זה היא פורטים - מספר בין 0 ל-65535 שמזהה שיחה ספציפית. השילוב של כתובת IP ופורט, שנקרא Socket, הוא מה שבאמת מזהה חיבור בודד באופן ייחודי. זו הסיבה שאפשר לפתוח כמה טאבים בדפדפן לאותו אתר בדיוק, כל אחד עם חיבור נפרד, בלי שהם מתבלבלים אחד עם השני.

לחיצת היד המשולשת - three-way handshake, שלב אחר שלב

לפני שמעביר ולו בית אחד של מידע ממשי, TCP מבצע תהליך של שלוש הודעות כדי לוודא ששני הצדדים מוכנים ומסונכרנים:

1. SYN. הצד היוזם שולח הודעה עם דגל SYN (Synchronize) ומספר רצף התחלתי אקראי משלו.
2. SYN-ACK. הצד המקבל משיב עם דגל SYN משלו, יחד עם דגל ACK שמאשר את הרצף שקיבל.
3. ACK. הצד היוזם משיב באישור סופי, ומהרגע הזה החיבור פתוח והעברת מידע ממשית יכולה להתחיל.

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

מספרי רצף ואישורים - איך TCP יודע מה כבר הגיע

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

חלון גולש - Sliding Window - למה TCP לא מחכה לאישור על כל בית בנפרד

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

בקרת עומס - Congestion Control - כשTCP נזהר מעצמו

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

סגירת חיבור - לא רק פותחים בזהירות, גם סוגרים בזהירות

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

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

מפתחים שמבינים את מנגנוני TCP האלה מבינים גם למה חיבור עם רשת איטית "נתקע" בפתאומיות (בקרת עומס), למה חיבורים רבים במקביל לאותו שרת יכולים להיות מהירים יותר מחיבור אחד (ניצול כמה sockets), ולמה timeout קורה בדיוק כשהוא קורה.

קורס הרשתות המלא נמצא כאן, חינם ובעברית, כולל תרגול מעשי על ניתוח תעבורת TCP אמיתית ב-Wireshark.

יש לכם שאלה על זרימת TCP בפרויקט שלכם? שאלו בדיסקורד.

הצטרפו לקהילה בדיסקורד

לסיכום

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