1. Libreria
  2. TCP ו-UDP
  3. צלילה לעומק TCP

Aggiornato 1 mese fa

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

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

הרעיון המרכזי: חלון מוצהר

כל מקטע TCP שהמקבל שולח בחזרה כולל שדה חלון של 16 סיביות. מספר זה — הנקרא חלון קבלה (rwnd) — אומר לשולח בדיוק כמה בייטים של מקום בחיץ פנויים. השולח יכול לשדר עד כמות זו של בייטים מעבר למה שכבר אושר, ולא יותר.

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

כיצד החלון מחליק

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

נניח שלמקבל יש חיץ של 64 KB והוא מכריז על rwnd=65536. השולח משדר 32 KB. אפליקציית המקבל מעבדת 16 KB ושולחת אישור עם rwnd=49152 (64 KB פחות 16 KB שעדיין ממתינים בחיץ). השולח יכול כעת לשדר עוד 16 KB.

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

בעיית 64 KB והרחבת חלון

שדה החלון של 16 סיביות יוצר מגבלה קשה: מקסימום 65,535 בייטים. בשנת 1981 זה היה נדיב. ברשתות מודרניות — זה משתק.

קחו בחשבון חיבור עם 100 אלפיות שנייה של זמן הלוך-חזור. עם חלון של 64 KB, לעולם לא תוכלו לשלוח יותר מ-64 KB לכל מסלול הלוך-חזור — כ-5 Mbps בלבד, ללא קשר למהירות החיבור בפועל. רוחב הסרט יושב בחוסר מעש, כי הפרוטוקול לא מאפשר לכם למלא את הצינור.

הרחבת חלון (RFC 1323) פותרת זאת על ידי הסכמה על מכפיל בזמן לחיצת היד. שני הצדדים מחליפים מקדם קנה מידה (0–14), וכל ערכי החלון הבאים מוזזים שמאלה בכמות זו. מקדם של 7 אומר שהכרזות החלון מוכפלות ב-128. בבת אחת מגבלת 65,535 הבייטים הופכת ל-8 MB — מספיק כדי לרווות אפילו קישורים מהירים.

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

חלונות אפס ובעיית מבוי הסתום

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

זוהי בקרת הזרימה שעובדת בדיוק כפי שתוכננה. אך היא יוצרת בעיה עדינה.

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

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

הגשש הוא TCP שאומר "שלום? עדיין שם?" עם בייט בודד, רק כדי לשבור את השתיקה.

בקרת זרימה לעומת בקרת עומס

שתיהן נשמעות דומות, אך פותרות בעיות שונות.

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

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

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

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

שאלות נפוצות על בקרת זרימה ב-TCP

מה קורה אם הרחבת חלון אינה נתמכת?

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

האם השולח יכול להתעלם מחלון הקבלה?

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

כיצד אני יודע אם בקרת זרימה מגבילה את החיבור שלי?

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

Questa pagina è stata utile?

😔
🤨
😃
בקרת זרימה ב-TCP: חלון ההזזה • Libreria • Connected