שליטה בעומס ב-TCP — הסבר מלא

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

הסקה בעיוורון

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

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

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

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

מדוע זה חשוב: קריסת עומס

ללא שליטה בעומס, רשתות עלולות להרוס את עצמן. הרצף:

1. התנועה גוברת עד שנתבים מתחילים להפיל מנות
2. שולחים מזהים אבדן ומשדרים מחדש
3. שידורים חוזרים מוסיפים תנועה לרשת העמוסה ממילא
4. מנות נוספות נושרות
5. עוד שידורים חוזרים מציפים את הרשת
6. תפוקה שימושית מתקרבת לאפס בעוד הרשת רוויה בשידורים חוזרים חסרי תועלת

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

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

חלון העומס: מגבלת מהירות עצמית

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

חלון אפקטיבי = min(cwnd, rwnd)

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

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

התחלה איטית: השם מטעה

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

התחלה איטית היא הפתרון של TCP: התחל בזהירות, ואז האץ במהירות. למרות השם, מדובר בצמיחה מעריכית:

• התחל עם חלון קטן (בדרך כלל 1–10 מקטעים)
• לכל אישור שהתקבל, הגדל את cwnd במקטע אחד
• מכיוון ששולחים מקטעי cwnd לכל סבב, החלון מכפיל את עצמו בכל RTT

ההתקדמות: 1 → 2 → 4 → 8 → 16 → 32...

זה נמשך עד שמשהו עוצר אותו:

1. זוהה אבדן מנות — הרשת דחפה חזרה
2. הגיע לסף ההתחלה האיטית (ssthresh) — מגבלה שנזכרת מעומס קודם
3. הגיע לחלון המקבל — שליטת הזרימה נכנסת לתמונה

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

הימנעות מעומס: בדיקה ליניארית

ברגע ש-cwnd מגיע ל-ssthresh, TCP יודע שהוא באזור הסכנה — קרוב למקום שבו קרה עומס בעבר. האסטרטגיה משתנה ממעריכית לליניארית: הגדל רק במקטע אחד לכל RTT, ללא קשר לכמה אישורים מגיעים.

זה יוצר את דפוס המסור האופייני של TCP:

1. החלון גדל בצורה ליניארית, בוחן לאיתור רוחב פס נוסף
2. זוהה עומס (אבדן מנות)
3. החלון נופל בחדות
4. התחלה איטית עד ssthresh
5. צמיחה ליניארית מתחדשת
6. חזור על הרצף

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

קריאת שתיקה: כיצד TCP מזהה עומס

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

אבדן מנות

האות המסורתי. שני סוגים:

שלושה אישורים כפולים: המקבל קיבל מנות 1, 2, 4, 5, 6 ומאשר שוב ושוב מנה 2, מבקש מנה 3. שלושה אישורים זהים מרמזים שמקטע אחד אבד בעוד אחרים עברו — עומס קל. תגובה: קצץ את cwnd בערך לחצי, המשך לשדר.

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

התראת עומס מפורשת (ECN)

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

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

האבולוציה של האלגוריתמים

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

TCP Reno (הקלאסי)

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

TCP Cubic (ברירת המחדל של Linux)

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

BBR (שינוי הפרדיגמה)

BBR של Google נוטש את האבדן כאות ראשי. במקום זאת, הוא מודד באופן פעיל:

• רוחב פס צוואר הבקבוק: באיזו מהירות נתונים יכולים לזרום בפועל?
• RTT מינימלי: מהו האחזור הבסיסי ללא הצטברות תורים?

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

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

ההבחנה שחשובה

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

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

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

שאלות נפוצות על שליטת עומס ב-TCP

מדוע הרשת פשוט לא אומרת ל-TCP מתי היא עמוסה?

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

כיצד שליטת עומס ב-TCP משפיעה על מהירות ההורדה שלי?

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

מה קורה כאשר מספר חיבורי TCP חולקים קישור עמוס?

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

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

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