עודכן לפני חודש
TCP מניח שהבעיה שלך היא שהנתונים עלולים שלא להגיע. הוא בונה מנגנון מסובך כדי למנוע זאת: אישורים, שידורים חוזרים, ערבויות סדר. הפרוטוקול יזיז שמיים וארץ כדי להבטיח שהחבילה שלך תגיע.
אבל מה אם אתה כבר לא רוצה את החבילה הזאת?
ביישומים בזמן אמת, חבילה שמגיעה באיחור גרועה יותר מחבילה שלא הגיעה כלל. TCP ישמח לשדר אותה שוב בכל זאת, ואז יגרום לך לחכות לה. הפרוטוקול שתוכנן להבטיח מסירה הופך לסיבה שהשיחת הווידאו שלך מגמגמת.
תקשורת בזמן אמת
שיחות קוליות ממחישות את הפרדוקס בצורה ברורה. כשאתה מדבר עם מישהו, חבילה אבודה שמכילה 20 אלפיות שנייה של שמע כמעט ואינה מורגשת — המוח שלך ממלא את החסר. אבל אותה חבילה שמגיעה 200 אלפיות שנייה מאוחר מכיוון ש-TCP התעקש לשדר אותה שוב? עכשיו יש לך עיכובים מציקים ואנשים מדברים אחד על השני.
הערובה של TCP הפכה לנטל.
UDP מאפשר ליישומים ליישם אסטרטגיות שחזור משלהם. קודקים מודרניים לשמע מבצעים אינטרפולציה על דגימות חסרות. קודקים לווידאו מדלגים על פריימים פגומים. התוצאה היא שיחה טבעית שבה התזמון חשוב יותר מהשלמות. Zoom, Discord ו-WebRTC כולם משתמשים ב-UDP לזרמי מדיה, ושומרים את TCP רק להודעות צ'אט ואיתותי בקרה.
כאשר חבילות אובדות, יישומי ועידות וידאו מפחיתים את האיכות במקום להמתין לשידורים חוזרים. האחזור נשאר נמוך. השיחה נשארת אינטראקטיבית.
גיימינג
גיימינג מקוון דורש את האחזור הנמוך ביותר האפשרי. כשאתה לוחץ על קפיצה במשחק יריות מגוף ראשון, הפעולה הזאת צריכה להגיע לשרת ולהשתקף חזרה לכל השחקנים תוך עשרות אלפיות שנייה. עיכובי השידור החוזר של TCP יגרמו למשחקים מהירים להרגיש חסרי תגובה.
מפתחי משחקים המשתמשים ב-UDP מיישמים אמינות סלקטיבית. עדכון מיקום של שחקן שאבד? העדכון הבא 16 אלפיות שנייה לאחר מכן מתקן אותו ממילא. אבל "שחקן ירה נשק"? זה צריך אישור ואולי שידור חוזר — שאותו המשחק מיישם בשכבת היישום שלו, מותאם לסמנטיקה של גיימינג ולא לגישת מידה אחת מתאימה לכולם של TCP.
עדכוני תנועה: לא אמינים ותכופים. שינויי מלאי: אמינים אך לא תכופים. המשחק מחליט מה חשוב. Fortnite, Call of Duty, League of Legends — כולם בנויים על יסודות UDP.
שידור חי
וידאו לפי דרישה יכול להצטבר בחוצץ. שידור חי לא יכול.
כשמשדרים אירוע ספורט חי, הצופים מצפים לראות את הפעולה כשהיא קורית. UDP מאפשר שידור בזמן אחזור נמוך שמעדיף עדכניות על פני שלמות. שירותי גיימינג בענן כמו GeForce NOW, פרוטוקולי שולחן עבודה מרוחק, ושידורי טלוויזיה על גבי IP כולם משתמשים ב-UDP כדי למזער את העיכוב מזכוכית לזכוכית.
יישומים אלו שולחים נתונים מיותרים (תיקון שגיאות קדימה) כדי שהמקבלים יוכלו לשחזר חבילות אבודות מבלי לבקש שידורים חוזרים. אם התיקון נכשל, הם מדלגים על החלק הפגום. תקלה קצרה עדיפה על פני פיגור מאחורי האירוע החי.
DNS ופרוטוקולי שאילתה-תגובה
DNS ממחיש את היעילות של UDP לחילופי מידע פשוטים. כאשר המחשב שלך מחפש את "connected.app", הוא שולח חבילת UDP אחת ומצפה לקבל חבילה אחת בחזרה. כל העסקה מסתיימת במחזור הלוך-ושוב אחד.
TCP היה דורש שלוש חבילות רק לצורך הקמת החיבור, לאחר מכן השאילתה והתגובה, ואז פירוק — הכפלת תקורה עבור שאלה ותשובה פשוטות. DNS מיישם לוגיקת ניסיון חוזר משלו: אין תגובה תוך מספר שניות? שלח את השאילתה שוב, אולי לשרת אחר.
NTP (סנכרון שעון), SNMP (ניטור מכשירים) ו-DHCP (תצורת רשת) עוקבים אחר אותו דפוס. חילופים פשוטים אינם זקוקים למצב החיבור וערבויות הסדר של TCP.
אמינות מותאמת אישית עם QUIC
לעיתים יישומים זקוקים לערובות אמינות שונות ממודל של TCP. שירות סנכרון קבצים עשוי לרצות העברה אמינה אך לא אכפת לו מסדר בין קבצים. TCP היה חוסם את כל ההעברות ומחכה לחבילה אבודה אחת. פרוטוקולים מבוססי-UDP יכולים להמשיך להעביר קבצים אחרים בזמן ההמתנה.
QUIC (שמניע את HTTP/3) בנוי על גבי UDP כדי ליישם אמינות לכל זרם בנפרד ולא לכל חיבור. זה מונע חסימת ראש התור — שבה חבילה אבודה אחת עוצרת את כל מה שמאחוריה — שפוקדת את TCP בעת הורדת מספר משאבים על פני חיבור אחד.
Multicast
UDP תומך בתקשורת מאחד לרבים שבה TCP פשוט אינו יכול. פרוטוקולי גילוי שירותים משתמשים ב-UDP multicast כדי לאפשר למכשירים להכריז על נוכחותם לכל המאזינים ברשת מקומית. חבילה אחת מגיעה למספר נמענים.
מערכות IPTV משתמשות ב-UDP multicast כדי לשלוח זרם וידאו אחד שמספר מקבלים יכולים להצטרף אליו. זה מתרחב בצורה טובה בהרבה מהקמת חיבורי TCP נפרדים לכל צופה.
הבחירה
UDP מצטיין כאשר:
- התזמון חשוב יותר מהשלמות — תקשורת בזמן אמת, גיימינג, שידור חי
- החילוף פשוט — DNS, NTP, DHCP
- אתה זקוק לאמינות מותאמת אישית — QUIC, פרוטוקולי משחק, יישומי מרכז נתונים
- אתה צריך תקשורת מאחד לרבים — multicast, גילוי שירותים
אמינות ניתן ליישם בשכבת היישום בעת הצורך. האחזור ותקורת TCP לא ניתנים להסרה. בחר ב-UDP כאשר היישום שלך מתמודד טוב יותר עם אובדן חבילות מאשר עם עיכוב.
שאלות נפוצות על UDP לעומת TCP
מדוע לא כל היישומים פשוט משתמשים ב-UDP אם הוא מהיר יותר?
UDP אינו מהיר יותר מטבעו — הוא פשוט יותר. הוא מעביר את האחריות ליישום. עבור רוב היישומים (גלישה באינטרנט, הורדת קבצים, דואר אלקטרוני), הערובות של TCP הן בדיוק מה שנדרש, ויישום מחדש של אמינות יהיה בזבזני. UDP מנצח כאשר הערובות של TCP יוצרות בעיות במקום לפתור אותן.
האם חבילות UDP יכולות להגיע שלא לפי הסדר?
כן. UDP אינו מספק ערובות סדר. חבילות עלולות להגיע בסדר שונה מזה שנשלחו, או לא להגיע כלל. יישומים המשתמשים ב-UDP חייבים להתמודד עם כך — או להחליט שלא אכפת להם, וזה לרוב המצב בנתוני זמן אמת שבהם רק המצב האחרון חשוב.
מדוע QUIC משתמש ב-UDP במקום להיות פרוטוקול תחבורה חדש?
פרגמטיות. יצירת פרוטוקול תחבורה חדש תדרוש שינויים במערכות הפעלה, חומות אש וציוד רשת ברחבי העולם — תהליך שלוקח עשרות שנים. בנייה על גבי UDP משמעה ש-QUIC עובד היום, דרך תשתית קיימת, תוך מתן האמינות המותאמת אישית והריבוי שדורש HTTP/3.
האם דף זה היה מועיל?