DCCP: פרוטוקול בקרת עומסים לדאטאגרמות

DCCP נקט בגישה הנכונה, אך לשכבה הלא נכונה.

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

DCCP אמור היה להיות הדרך השלישית: מסירה לא אמינה עם בקרת עומסים מובנית. שלח פקטות מבלי להמתין לאישורים, אך הקטן את קצב השליחה כשהרשת עמוסה. מהיר ומנומס. ה-IETF תיקנן אותו ב-2006. ואז כמעט אף אחד לא השתמש בו.

הבעיה שאותה DCCP ביקש לפתור

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

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

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

מה DCCP בפועל עושה

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

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

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

מדוע DCCP נכשל

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

הבעיה השנייה הייתה תמיכת מערכות ההפעלה. ל-Linux הייתה תמיכה ב-DCCP בגרעין, אך לרוב כמודול אופציונלי שלא נטען כברירת מחדל. תמיכת Windows הייתה מינימלית. תמיכת macOS הייתה כמעט ולא קיימת. מפתחי אפליקציות לא יכלו להניח ש-DCCP יהיה זמין במחשבי המשתמשים שלהם.

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

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

מה ניצח במקומו

QUIC, כיום הבסיס של HTTP/3, פתר רבות מאותן בעיות שאיתן DCCP התמודד — והצליח היכן ש-DCCP נכשל. ההבדל המרכזי: QUIC פועל מעל UDP ולא לצידו.

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

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

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

הלקח

DCCP היה תקין מבחינה טכנית. הוא טיפל בבעיה אמיתית עם פתרון מעוצב היטב. ה-IETF תיקנן אותו כראוי. מימושים היו קיימים. כל זה לא היה חשוב.

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

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

שאלות נפוצות על DCCP

האם DCCP עדיין בשימוש כלשהו?

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

כיצד DCCP שונה מ-UDP עם בקרת עומסים ברמת האפליקציה?

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

האם DCCP יכול לחזור לחיים?

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

מדוע ה-IETF לא צפה מראש את בעיית התקני הביניים?

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