מספרי רצף ואישורים ב-TCP

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

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

כל בייט מקבל מספר

TCP לא חושב במנות. הוא חושב בבייטים.

כשאתה משדר נתונים, TCP מתייחס אליהם כאל זרם רציף. לכל בייט בזרם הזה יש מספר רצף. אם אתה שולח קטע המכיל 500 בייטים החל ממספר רצף 1000, שלחת בייטים 1000 עד 1499. הקטע הבא מתחיל ב-1500.

המעקב ברמת הבייט הוא מה שהופך את TCP לאמין. המקבל יודע בדיוק אילו בייטים יש לו ואילו חסרים. אם מגיעים בייטים 1000-1499 ו-2000-2499 אך לא 1500-1999, המקבל יודע בדיוק מה חסר ויכול לחכות לו.

מוסכמת האישור

כאן מתגלה האלגנטיות של TCP. מספר האישור לא אומר "קיבלתי." הוא אומר "אני מוכן למה שבא אחר כך."

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

האישורים הם גם מצטברים. קיבלת שלושה קטעים ברצף מהיר? שלח אישור אחד עבור כולם. האישור עבור בייט 3000 מאשר מכללא שבייטים 1000-2999 הגיעו כולם. אם אישור אובד, האישור הבא מכסה את אותו השטח.

כיצד נוצרת האמינות

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

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

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

מדוע חיבורים מתחילים עם מספרים אקראיים

חיבורי TCP לא מתחילים לספור מאפס. במהלך לחיצת היד התלת-שלבית, כל צד בוחר מספר רצף התחלתי אקראי (ISN).

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

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

החלטת עיצוב משנות ה-70 שעדיין מריצה את האינטרנט

מספרי הרצף הם מספרים שלמים של 32 סיביות: 0 עד 4,294,967,295. כשתוכנן TCP, שידור 4.3 GB נראה כאילו ייקח נצח. מרחב הרצף לעולם לא יתגלגל חזרה.

היום, חיבור של 10 Gbps מגלגל את המונה הזה תוך פחות מארבע שניות.

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

כך זה עובד בפועל

הורדת קובץ בגודל 2000 בייטים, כשה-ISN של השרת הוא 50000:

1. השרת שולח בייטים 50000-50999 (מספר רצף 50000)
2. הלקוח מאשר 51000 ("קיבלתי, מוכן ל-51000")
3. השרת שולח בייטים 51000-51999 (מספר רצף 51000)
4. הלקוח מאשר 52000 ("קיבלתי הכל")

אם הקטע השני אובד:

1. השרת שולח בייטים 50000-50999
2. הלקוח מאשר 51000
3. השרת שולח בייטים 51000-51999 (אובד בדרך)
4. הלקוח ממשיך לאשר 51000
5. השרת מגיע לפסק זמן, משדר מחדש בייטים 51000-51999
6. הלקוח מאשר 52000

הלקוח מעולם לא ראה את המנה האבודה. הוא פשוט המשיך לומר "אני צריך 51000" עד ש-51000 הגיע.

האילוץ האלגנטי

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

אין משא ומתן מורכב. אין קודי שגיאה מתוחכמים. רק: "הנה בייטים 1000-1499" ו"מוכן ל-1500." כל השאר נובע מכך.

שאלות נפוצות על מספרי רצף TCP

מדוע TCP מספר בייטים במקום מנות?

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

מה קורה כשמספרי הרצף מתגלגלים חזרה?

אחרי 4.3 GB של נתונים, מספרי הרצף מתגלגלים מ-4,294,967,295 חזרה ל-0. TCP מטפל בכך בצורה שקופה באמצעות חשבון מודולרי. TCP מודרני משתמש גם בחותמות זמן כדי להבחין בין מנות ישנות לחדשות עם אותו מספר רצף — קריטי ברשתות מהירות שבהן הגלגול מתרחש תוך שניות.

האם תוקף יכול לנחש מספרי רצף?

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

מדוע לאשר את הבייט הבא הצפוי במקום האחרון שהתקבל?

זה מבטל עמימות. אם אתה מאשר "1499", האם זה אומר שקיבלת בייט 1499, או הכל עד 1499, או הכל עד ולא כולל 1499? אישור "1500" הוא חד-משמעי: שלח לי בייט 1500 בהמשך.