עודכן לפני חודש
כשאתה מבצע שיחת וידאו או משחק משחק מקוון, אתה צריך שהנתונים יגיעו מהר — לא בצורה מושלמת. אם שיחת הוידאו שלך הייתה קופאת בכל פעם שמנה אבדה כדי שהפרוטוקול יוכל לבקש שידור חוזר, היית מבין מיד מדוע UDP קיים.
פרוטוקול ה-User Datagram נוקט גישה שונה מהותית מ-TCP: שלח את הנתונים והמשך הלאה. ללא ערבויות, ללא ניסיונות חוזרים, ללא טרחה. חוסר האחריות לכאורה הזה הוא בדיוק מה שהופך את UDP לאחד הפרוטוקולים החשובים ביותר באינטרנט.
הפילוסופיה חסרת-החיבור
ל-UDP אין זיכרון. אין לחיצת יד משולשת, אין יצירת חיבור, אין סיום חיבור. כשיישום רוצה לשלוח נתונים, הוא יוצר datagram ושולח אותו. זהו.
כל datagram עצמאי לחלוטין — הודעה שעומדת בפני עצמה, ללא קשר לאף datagram אחר. יישום השליחה מוסיף לכל אחד כתובת IP יעד ומספר פורט, ותפקידו של UDP מסתיים ברגע שהוא מעביר את המנה לשכבת ה-IP שמתחתיו. מה שקורה אחר כך — אם ה-datagram מגיע, נאבד בדרך, או מגיע שלא לפי הסדר — אינו עניינו של UDP.
זה נשמע חסר אחריות עד שאתה מבין מה זה מבטל: אין מספרי רצף לעקוב אחריהם, אין מנות אישור שצורכות רוחב פס, אין טיימרים שממתינים לתגובות. כל המנגנונים שבהם TCP משתמש כדי לערוב למסירה פשוט לא קיימים. התוצאה היא פרוטוקול שמהיר בדיוק משום שאינו מבטיח דבר.
הכותרת המינימלית
הפילוסופיה של UDP מתבטאת בכותרת שלו: רק 8 בתים המכילים ארבעה שדות. הכותרת של TCP היא לפחות 20 בתים (עד 60 עם אפשרויות). כל בית שנחסך בכותרת הוא בית פנוי לנתונים האמיתיים שלך.
פורט מקור (16 ביט): מזהה את יישום השליחה. אופציונלי לתקשורת חד-כיוונית, אך הכרחי אם אתה רוצה לקבל תגובות.
פורט יעד (16 ביט): מציין לאיזה יישום במכונה המקבלת יש להעביר את ה-datagram — מפענח ה-DNS שלך, יישום הסטרימינג, או לקוח המשחק.
אורך (16 ביט): הגודל הכולל של ה-datagram כולל הכותרת. הגודל התיאורטי המרבי הוא 65,535 בתים, אם כי המגבלות המעשיות קטנות יותר בשל אילוצי רשת.
סכום ביקורת (16 ביט): מזהה אם ביטים הושחתו במהלך השידור. אבל הנה האמת: UDP לא מתקן שגיאות. הוא פשוט זורק datagrams פגומים. סכום הביקורת הוא אופציונלי ב-IPv4, חובה ב-IPv6.
אין מספרי רצף. אין מספרי אישור. אין גדלי חלון. אין דגלי ניהול חיבור. הכותרת המינימלית הזו היא הסיבה שבגללה UDP מצליח למסור נתונים עם כל כך מעט זמן אחזור.
מה ש-UDP משמיט בכוונה
UDP אינו מספק מנגנוני אמינות. אם datagram נאבד — נשמט על-ידי נתב עמוס, הושחת על-ידי כבל פגום, ניותב בצורה שגויה — UDP לא ישים לב ולא יכפת לו. אין שידורים חוזרים, אין זיהוי כפילויות, אין ערבויות מסירה.
UDP אינו מספק ערבויות סדר. שלח שלושה datagrams ברצף, והם עשויים להגיע בכל סדר שהוא — או שחלקם לא יגיעו כלל. כל אחד עובר נתיב עצמאי ברשת.
ל-UDP אין בקרת זרימה. הוא לא יאט אם המקבל עמוס. כשאתה שולח מהר יותר ממה שהמקבל יכול לעבד, המנות העודפות פשוט נשמטות.
ל-UDP אין בקרת עומסים. הוא לא יזהה עומס ברשת ולא יתאים את קצב השליחה שלו. יישומי UDP שתוכננו בצורה גרועה עלולים להציף רשת גם כשהתנאים לקויים.
ההשמטות האלה אינן מגבלות — הן כל הנקודה.
מדוע ההשמטות הן תכונות
ללא הגדרת חיבור, אישורים, או שידורים חוזרים, UDP מוסר נתונים עם זמן אחזור מינימלי. בשיחת וידאו, לקבל את מסגרת השמע האחרונה מהר חשוב יותר מלוודא שמסגרת שמע ממאתיים מילישניות לפני כן תגיע בסופו של דבר. עד שמנה ששודרה מחדש תגיע — היא כבר מיושנת.
הכותרת בת 8 הבתים פירושה שרוחב פס רב יותר הולך לנתונים עצמם. ליישומים השולחים הרבה הודעות קטנות, זה מצטבר לחיסכון משמעותי.
UDP מצטיין בשידור ורב-שידור. ללא מצב חיבור שצריך לשמור עליו, datagram יחיד יכול להגיע למספר נמענים בו-זמנית — חיוני לסטרימינג למספר צופים או לגילוי שירותים.
וחשוב מכל, UDP נותן ליישומים שליטה. מכיוון שהוא מספק כל כך מעט, יישומים יכולים לממש בדיוק את האמינות, הסדר, או בקרת העומסים שהם זקוקים להם. לא יותר, לא פחות.
מודל ה-Datagram
בטרמינולוגיה של UDP, כל מנה היא datagram — הודעה עצמאית ובלתי תלויה. זה מנוגד לגישה המכוונת לזרמים של TCP. כשאתה שולח נתונים דרך UDP, אתה שולח datagrams נפרדים, וגבולות ההודעות נשמרים. שלח שלושה datagrams בני 100 בתים, המקבל יקבל שלוש הודעות בנות 100 בתים — לא זרם אחד בן 300 בתים.
שמירת גבולות ההודעות חשובה. שאילתת DNS היא מטבעה הודעה נפרדת. עדכון מצב משחק הוא תמונת מצב ברגע ספציפי. מנת קול מכילה פרוסת זמן ספציפית של שמע. יישומים אלה חושבים במונחים של הודעות, לא זרמים. מודל ה-datagram של UDP מתאים לאופן שבו הם עובדים בפועל.
היכן UDP מצטיין
DNS משתמש ב-UDP מפני שחיפושי שמות צריכים להיות מהירים, ושאילתה שאבדה יכולה פשוט להישלח שוב. רוב הודעות ה-DNS מתאימות ל-datagram יחיד.
שיחות קול ווידאו מסתמכות על UDP מפני שמסירת שמע מהירה חשובה יותר ממסירה מושלמת. בני אדם בקושי שמים לב אם כמה מילישניות של שמע נעלמות — אבל הם בהחלט שמים לב אם הדיבור מתעכב בהמתנה לשידורים חוזרים.
משחקים מקוונים שולחים מיקומי שחקנים דרך UDP מפני שהמיקום האחרון הוא שחשוב, לא מיקומים מלפני חצי שנייה. משחקים בדרך כלל מממשים אמינות משלהם לאירועים קריטיים (איסוף פריטים, שינויי ניקוד) תוך שימוש ב-UDP הבלתי-אמין לזרם הקבוע של עדכוני מיקום.
פרוטוקולי סטרימינג כמו RTP נבנים על UDP למסירת וידאו ושמע חי. פרוטוקולי ניהול רשת כמו SNMP משתמשים ב-UDP לאיסוף נתוני ניטור. אפילו QUIC — הפרוטוקול המודרני המניע HTTP/3 — נבנה על גבי UDP, ומממש אמינות משלו תוך ניצול זמן האחזור הנמוך שהוא מציע.
שאלות נפוצות על UDP
מדוע מישהו ישתמש בפרוטוקול שאינו ערב למסירה?
מפני שעבור יישומים רבים, מסירה מובטחת גרועה יותר מאי-מסירה כלל. אם אתה בשיחת וידאו ומנה אובדת, עדיף לדלג על אותן 20 מילישניות של שמע מאשר להקפיא את כל השיחה בהמתנה לשידור חוזר. עד שהמנה הישנה מגיעה, היא חסרת תועלת — כבר עברת לרגע הבא בשיחה.
כיצד יישומים מתמודדים עם מנות UDP שאבדו?
תלוי במה שהם עושים. DNS פשוט שולח שוב את השאילתה אם לא מגיעה תשובה. שיחות וידאו משתמשות בהסתרת שגיאות כדי להסתיר מסגרות חסרות. משחקים מבצעים אינטרפולציה של נתוני מיקום חסרים. יישומים מסוימים מממשים שכבת אמינות משלהם מעל UDP להודעות קריטיות, בעוד שהם מקבלים אובדן לכל השאר.
האם UDP מהיר יותר מ-TCP?
ל-UDP יש זמן אחזור נמוך יותר כי הוא מדלג על הגדרת חיבור ואינו ממתין לאישורים. אבל "מהיר יותר" תלוי בהקשר. להעברת קבצים גדולים שבהם כל בית חייב להגיע, תכונות האמינות של TCP עשויות להביא נתונים ביעילות רבה יותר מ-UDP עם ניסיונות חוזרים ברמת היישום. UDP מנצח כשאתה צריך את זמן האחזור הנמוך ביותר האפשרי ויכול לסבול אובדן מסוים.
האם מנות UDP יכולות להגיע שלא לפי הסדר?
כן. כל datagram עובר נתיב עצמאי ברשת. נתבים שונים, תורים שונים, עיכובים שונים. יישומים הזקוקים לסדר מסוים חייבים לעקוב בעצמם אחרי מספרי רצף.
מדוע ל-UDP יש סכום ביקורת אם הוא לא מתקן שגיאות?
סכום הביקורת מזהה השחתה — ביטים שהתהפכו במהלך השידור. תגובתו של UDP להשחתה פשוטה: השלך את ה-datagram לחלוטין. עדיף לא לקבל נתונים כלל מאשר לקבל נתונים פגומים. היישום יכול להחליט אם לבקש ניסיון חוזר או להמשיך הלאה.
האם דף זה היה מועיל?