עודכן לפני חודש
UDP לא מחזיר מנות שאבדו. זו בדיוק הנקודה.
TCP מתייחס לכל מנה שאבדה כאל משבר, ועוצר את השידור עד שהפער מתמלא. בהורדת קובץ — זה הגיוני. בשיחת וידאו — זה קטסטרופלי. פריים של וידאו מלפני 500 מילישניות לא מאחר — הוא מת. הצופה כבר המשיך הלאה. במשחק מרובה משתתפים, לדעת איפה שחקן היה לפני חצי שנייה לא עוזר כשצריך לדעת איפה הוא נמצא עכשיו.
הפילוסופיה של UDP: שלח ושכח. אין מצב חיבור, אין מעקב, אין שחזור. זה מה שהופך את UDP למהיר — אבל זה גם אומר שאובדן מנות הוא הבעיה שלך. הפתרון הנכון תלוי בשאלה אחת: האם הנתון הזה עדיין רלוונטי עד שהשחזור יתרחש?
זיהוי אובדן באמצעות מספרי רצף
לפני שאפשר להתמודד עם אובדן, צריך לדעת שהוא קורה.
הוסף מספר רצף לכל מנה — מונה שעולה בכל שליחה. כשהמקבל רואה שמנה 1,043 מגיעה אחרי מנה 1,041, הוא יודע שמנה 1,042 נעלמה. הפער מגלה בדיוק כמה אבד.
מספרי רצף גם מזהים כפילויות (רשתות מדי פעם משכפלות מנות) ושינוי סדר הגעה (מנה 1,045 שמגיעה לפני 1,044). בסטרימינג נתונים, הם מאפשרים לשחזר את הסדר הנכון גם כשהרשת מבלבלת את הסדר.
יישום: הוסף שדה של 32 סיביות או 64 סיביות לכותרת המנה. השולח מקדם אותו. המקבל עוקב אחרי מה שקיבל. כל פער פירושו אובדן.
שחזור סלקטיבי באמצעות אישורים
חלק מיישומי UDP בונים מערכות אישור משלהם — לווים מ-TCP אבל מתאימים אותן לאילוצי זמן אמת.
המקבל שולח מדי פעם דוחות סטטוס: "קיבלתי מנות 1,040-1,042 ו-1,044-1,048, אבל חסרה לי 1,043." השולח אז מחליט אם כדאי לשלוח מחדש את 1,043. אם היא הכילה הודעת צ'אט — כן. אם היא הכילה פריים אחד בסטרים וידאו של 60 fps — הרגע חלף, עוברים הלאה.
ההבדל מ-TCP: המערכות האלה מבינות מה הנתונים מייצגים. הן מקבלות החלטות מושכלות לגבי האם השחזור שווה את המחיר. הודעת צ'אט שווה לחכות 200ms לשליחה מחדש. מנת קול — לא.
מניעת אובדן עם יתירות
תיקון שגיאות קדימה (FEC) לא מחכה לאובדן. הוא שולח נתונים יתירים מראש, ומאפשר למקבל לשחזר מנות שאבדו בלי לבקש אותן מחדש.
הטכניקה הפשוטה ביותר: בצע XOR על מנות 1-4 ושלח את התוצאה כמנה 5. אם מנה אחת מהקבוצה הזו נעלמת, עשה XOR של הנשארות עם מנת הזוגיות כדי לשחזר אותה. תוכניות מתוחכמות יותר כמו קודי Reed-Solomon יכולות להתאושש ממספר אובדנים בתוך בלוק.
לנתונים קריטיים, יש גישה אפילו פשוטה יותר: שלח פעמיים. יישומי VoIP עשויים לשדר כל מנת שמע פעמיים עם הפרש קטן. אם עותק אחד אבד, השני כנראה יגיע. זה עובד כשהאובדנים הם אקראיים ולא מתואמים. אובדנים רצופים מנתב עמוס? פחות שימושי — שני העותקים נעלמים ביחד.
יישומים רבים בזמן אמת משתמשים ביתירות חלקית: כוללים עותק באיכות נמוכה של נתונים קודמים לצד הנתונים הנוכחיים. מנת VoIP נושאת שמע באיכות גבוהה עבור 20ms הנוכחיים ושמע באיכות נמוכה עבור 20ms הקודמים. אם המנה הקודמת אבדה, הגיבוי ממלא את הפער בצורה מקובלת.
FEC מצטיין בתקשורת חד-כיוונית או קישורים בעלי זמן אחזור גבוה. שידורי לוויין משתמשים בו רבות — בקשת שליחה מחדש דרך קישור לוויין מוסיפה שניות של עיכוב. הפשרה היא רוחב סרט: שולחים נתונים נוספים גם כשהרשת מושלמת.
לזייף עם חיזוי
הנה החלק המפתיע: עבור תנועה רציפה או שמע, לפעמים התגובה הטובה ביותר לאובדן היא פשוט לבדות.
מנות וידאו 100 ו-102 מגיעות, אבל 101 אבדה. מבצעים אינטרפולציה — מייצרים פריים ביניים בין 100 ל-102. לסצנות עם תנועה איטית, זה לרוב בלתי ניתן להבחנה. אתה צופה במשהו שמעולם לא היה קיים, ואינך יכול להגיד.
לקוחות משחק מנבאים כל הזמן. אם השרת שולח מיקומי שחקנים כל 50ms ומנה נעלמת, הלקוח מחשב מיקום משוער לפי המיקום והמהירות האחרונים הידועים. הוא מציג לך איפה השחקן כנראה נמצא. כשהעדכון הבא מגיע, הוא מתקן בצורה חלקה כל סטייה. המשחק מרגיש רספונסיבי גם במהלך הפרעות קצרות. אתה רואה מיקומים שהשרת לא דיווח עליהם, והאשליה מחזיקה.
יישומי שמע מסנתזים קטעים חסרים על-ידי חזרה על שמע קרוב או מיזוג ביניהם. 20ms שמע שאבדו במהלך צליל תנועי? לרוב בלתי ניתן לגילוי. המוח שלך לא שם לב.
חיזוי עובד כי המציאות היא בדרך כלל רציפה. עצמים לא קופצים ממקום למקום. צלילים לא משתנים בפתאומיות. הרגע הבא נוטה להיות דומה לרגע שעבר. נצל את זה, ואובדן הופך לבלתי נראה.
בחירת האסטרטגיה שלך
שלוש שאלות קובעות את הגישה הנכונה:
כמה הנתונים רגישים לזמן? הודעת צ'אט יכולה לחכות לשליחה מחדש. פריים וידאו חי — לא.
מה ההשפעה של אובדן? פריים שנשמט בוידאו של 60fps אינו ניתן לגילוי. אירוע "שחקן הבקיע נקודה" שנשמט שובר את מצב המשחק.
מה עלות כל אסטרטגיה? FEC צורך רוחב סרט באופן קבוע. שליחה מחדש מוסיפה זמן אחזור. חיזוי דורש חישוב ועובד רק עבור נתונים רציפים.
יישומים מהעולם האמיתי משלבים אסטרטגיות:
וידאו בזמן אמת מקבל אובדן — מדלגים על הפריים החסר, ממשיכים. ההפרעה הקצרה עדיפה על השהייה.
העברת קבצים במהירות גבוהה על UDP דורשת מסירה מושלמת אבל שולחת מחדש בצורה אגרסיבית — בקשות מרובות בו-זמניות במקום המתנה לפסקי זמן.
משחקים מרובי משתתפים מזרימים מיקומי שחקנים ללא אישור (העדכון הבא מגיע בקרוב ממילא) אבל מאשרים ושולחים מחדש אירועים קריטיים כמו "נשק נרכש" או "נקודה נרשמה". שינויי מצב לא ניתנים לניחוש.
VoIP משתמש ב-FEC להגנה בסיסית, חיזוי לפערים קטנים, ומוותר בחן על פערים גדולים — רגע של דממה עדיף על שיחה מעוכבת.
הדפוס: השתמש באסטרטגיה הפשוטה ביותר שמשמרת את הנתונים שימושיים. כשעדכניות חשובה יותר משלמות — תן לנתונים הישנים לעבור.
שאלות נפוצות על אובדן מנות UDP
כמה אובדן מנות הוא נורמלי באינטרנט?
נתיבי אינטרנט טיפוסיים רואים 0.1% עד 2% אובדן בתנאים רגילים. רשתות עמוסות, WiFi גרוע, או נתיבים בינלאומיים יכולים לדחוף את זה גבוה יותר. יישומי UDP מעוצבים היטב צריכים לטפל ב-5% אובדן בחן ולהישאר פונקציונליים עד 10-15%.
אפשר לשלב מספר אסטרטגיות?
כן, ורוב יישומי הייצור עושים זאת. יישום סטרימינג וידאו עשוי להשתמש ב-FEC להגנה בסיסית, מספרי רצף לזיהוי, אינטרפולציה לפערים קטנים ושליחה מחדש סלקטיבית עבור keyframes. האסטרטגיות משלימות זו את זו.
כיצד אמדוד אובדן מנות ביישום שלי?
עקוב אחרי מספרי הרצף שאתה שולח ומקבל. חשב את שיעור האובדן כ-(צפוי - התקבל) / צפוי על פני חלון זמן. תעד ברציפות — האובדן משתנה לאורך היום ועל פני נתיבי רשת שונים.
למה לא פשוט להשתמש ב-TCP אם אני צריך אמינות?
האמינות של TCP גורמת לחסימת ראש-תור (head-of-line blocking): אם מנה 50 אבדה, מנות 51-100 ממתינות גם אם הגיעו. עבור יישומים בזמן אמת, זה יוצר קפיצות זמן אחזור בלתי מקובלות. UDP מאפשר לך להחליט אילו נתונים שווה לחכות להם ואילו כדאי לדלג עליהם. אתה מוותר על אמינות אוטומטית תמורת שליטה על מה "אמין" אומר עבור הנתונים הספציפיים שלך.
האם דף זה היה מועיל?