שכבת התעבורה — הסבר מפורט

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

זוהי שכבה 4 במודל OSI. היא פותרת בעיה שנראית בלתי אפשרית: כיצד שני יישומים על מכונות שונות, המופרדים במרחקים לא ידועים וברשתות בלתי צפויות, יכולים לנהל שיחה רציפה ומסודרת?

הבעיה שפותרת שכבת התעבורה

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

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

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

הרשת אומרת "אנסה". שכבת התעבורה מחליטה אם לומר "אני מבטיח" או "בהצלחה".

מספרי פורט: כיצד יישומים חולקים חיבור

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

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

מספרי פורט הם מספרים שלמים בגודל 16 סיביות — 0 עד 65535. הטווחים חשובים:

• 0–1023: פורטים ידועים. HTTP פועל על פורט 80, HTTPS על פורט 443, SSH על פורט 22. אלה שמורים לשירותים סטנדרטיים.
• 1024–49151: פורטים רשומים. יישומים יכולים לבקש אלה מ-IANA.
• 49152–65535: פורטים ארעיים. כשהדפדפן שלך מתחבר לשרת אינטרנט, הוא בוחר פורט אקראי מהטווח הזה ומשתמש בו ככתובת מקור.

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

TCP: ההבטחה למסירה אמינה

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

שמירת ההתחייבות הזו דורשת מנגנון מורכב:

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

למה שלושה שלבים? כי שני הצדדים צריכים לאשר שהצד השני יכול גם לשלוח וגם לקבל. ה-SYN הראשון מוכיח שאתה יכול לשלוח. ה-SYN-ACK מוכיח שהשרת יכול לשלוח וקיבל את הודעתך. ה-ACK האחרון מוכיח שקיבלת את הודעתם. שני שלבים היו משאירים כיוון אחד ללא אישור.

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

אשר קבלה. המקלט מודיע לשולח מה הוא קיבל. אם אישורים אינם חוזרים, השולח מניח שהנתונים אבדו ומשדר אותם מחדש.

שלוט בקצב. TCP משתמש בשני מנגנונים כדי למנוע הצפה של המקלט או הרשת:

• בקרת זרימה: המקלט מפרסם חלון — כמה מקום במאגר יש לו פנוי. השולח לא יחרוג מכך. המקלט אומר בעצם: "כל כך הרבה אני יכול לעכל, לא יותר."

• בקרת עומס: השולח עוקב אחר סימני עומס ברשת (מנות אבודות, עיכובים הולכים וגדלים) ומאט כשהרשת נאנחת תחת העומס. זה מונע מ-TCP להחמיר מצב שממילא רע.

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

UDP: מהירות על פני בטיחות

UDP שולח את הנתונים שלך וממשיך הלאה.

ללא הקמת חיבור. ללא אישורים. ללא שידור חוזר. ללא ערבויות סדר. ללא בקרת עומס. UDP עוטף את הנתונים שלך בכותרת מינימלית (פורט מקור, פורט יעד, אורך, סכום ביקורת) ומוסר אותה לשכבת הרשת.

זה נשמע פזיז, עד שמבינים מה יישומים מסוימים באמת זקוקים לו.

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

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

DNS משתמש ב-UDP מפני שהשאילתות קטנות ומהירות. התקורה של הקמת חיבור TCP הייתה גדולה מהעבודה עצמה. אם שאילתת DNS אובדת — פשוט שולחים שוב.

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

פילוח: פיצול נתונים לחלקים

לרשתות יש מגבלות גודל. Ethernet בדרך כלל מגביל מנות ל-1500 בייט. אבל יישומים עובדים עם נתונים גדולים בהרבה — תמונות, קבצים, זרמי וידאו.

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

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

חלון ההזזה

בקרת הזרימה של TCP אלגנטית. המקלט שומר מאגר לנתונים נכנסים ומודיע לשולח: "החלון שלי הוא X בייטים." לשולח יכולים להיות עד X בייטים "בדרך" — שנשלחו אך טרם אושרו.

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

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

שתי מכונות מתאמות את הקצב שלהן ללא בורר חיצוני. המקלט מציין מה הוא מסוגל לעמוד בו. השולח מכבד את הגבול. השיחה זורמת מהר ככל שהצד האיטי מסוגל.

מדוע השכבה הזו קיימת

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

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

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

הרשת מספקת מסירה במאמץ מיטבי. שכבת התעבורה בונה על אותה תשתית את כל הערבויות שהיישומים זקוקים להן.

שאלות נפוצות על שכבת התעבורה

מדוע יישומים מסוימים משתמשים ב-TCP ואחרים ב-UDP?

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

מה קורה אם שני הצדדים של חיבור TCP רוצים לשלוח נתונים בו-זמנית?

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

האם אני יכול לראות אילו פורטים פעילים במחשב שלי?

כן. במערכות דמויות-Unix, netstat -an או ss -tuln מציגים חיבורים פעילים ופורטים מאזינים. ב-Windows, netstat -an עובד באופן דומה. תוכל לראות אילו פורטים מקומיים מאזינים לחיבורים ולאילו כתובות מרוחקות המחשב שלך מחובר.