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

ניב שינה

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

מנגנון שידור חוזר

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

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

תרחיש 1: כאשר חבילת הנתונים אובדת או שגויה.

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

תרחיש 2: כאשר החבילה מתקבלת אך האישור אובד.

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

תרחיש 3: כאשר פסק הזמן המוקדם מתרחש.

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

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

כמה זמן השולח צריך לחכות?

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

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

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

כיצד נוכל להשיג את ה-RTT?

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

בואו נראה איך אנחנו יכולים למדוד את ה-RTT.

נשתמש ב- אלגוריתם מקורי כדי למדוד את ה-RTT.

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

שלב 2: לא ניקח רק דגימה אחת. נמשיך לקחת דגימות שונות ולחשב את הממוצע המשוקלל של הדגימות הללו, וזה הופך ל- EstRTT (Estimated RTT).

כאשר, α+β = 1

גלילה בעכבר לא עובדת

α נמצא בין 0.8 ל-0.9

β נמצא בין 0.1 ל-0.2

שלב 3: הזמן הקצוב נקבע על סמך EstRTT.

פסק זמן = 2 * EstRTT.

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

פגם בגישה זו

יש פגם באלגוריתם המקורי. הבה נבחן שני תרחישים.

תרחיש 1.

אלפבית עם מספרים

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

תרחיש 2.

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

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

מסקנה של האלגוריתם לעיל.

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

כדי להתגבר על הבעיות לעיל, ניתן פתרון פשוט על ידי אלגוריתם Karn/Partridge. אלגוריתם זה נתן פתרון פשוט שאוסף את הדגימות שנשלחו בבת אחת ואינו מתחשב בדגימות בזמן השידור החוזר לחישוב ה-RTT המשוער.

אלגוריתם קארן/פרטרידג'

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

הַגבָּלָה

זה לא לוקח בחשבון את השונות ב-RTT.

אם השונות קטנה, ה- EstimatedRTT יוצא מדויק. אם השונות גדולה, ה- EstimatedRTT אינו מדויק.

כדי להתגבר על המגבלה לעיל, פותח האלגוריתם של Jacobson/Karels שמציג את גורם השונות ב-RTT.

אלגוריתם יעקבסון/קרלס

אלגוריתם זה פותח כדי להתגבר על המגבלה של קארן/פרטרידג' אַלגוֹרִיתְם. הוא מחשב את ההבדל בין ה-SampleRTT ל-EstimatedRTT, ומגביר את ה-RTT בהתבסס על ההבדל.

חסום פרסומות ב-YouTube אנדרואיד

חישובים עבור RTT ממוצע

• ראשית, אנו מחשבים את גורם ההפרש.

Diff = SampleRTT - EstimatedRTT

• כעת, אנו מחשבים את EstimatedRTT, אשר יחושב באותו אופן כפי שעשינו לעיל.

EstRTT = EstRTT + (δ*Diff)

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

Dev = Dev + δ ( |הבדל| - Dev)

כאן, Dev הוא גורם סטייה, ו-δ הוא גורם בין 0 ל-1. ה Dev הוא אומדן של השונות מ- EstRTT .

• נשקול את השונות בזמן חישוב ערך הזמן הקצוב.

איפה, µ =1 ו-ɸ =4

שידור חוזר מהיר

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

בת כמה קיילי ג'נר

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

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

הפתרון הטוב יותר מתחת לחלון הזזה:

נניח ש-n חבילה אבדה, אבל עדיין, החבילות n+1, n+2 וכן הלאה התקבלו. המקלט מקבל ברציפות את החבילות ושולח את מנות ה-ACK באומר שהמקלט עדיין ממתין לחבילה ה-n'. המקלט שולח אישורים חוזרים או כפולים. במקרה שלעיל, ACK של חבילה 1 נשלחת שלוש פעמים מכיוון שחבילה 2 אבדה. חבילת ACK כפולה זו היא אינדיקציה לכך שהחבילה ה-n חסרה, אך החבילות המאוחרות יותר מתקבלות.

ניתן לפתור את המצב לעיל בדרכים הבאות:

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

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