SCTP: פרוטוקול העברת נתונים בשליטת זרם

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

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

SCTP (פרוטוקול העברת נתונים בשליטת זרם) נבנה כדי לתקן זאת. וזה מה שהוא עושה. בצורה אלגנטית.

התובנה המרכזית: זרמים בתוך חיבור

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

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

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

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

ריבוי כתובות: מעבר אוטומטי ללא דרמה

נקודות קצה של SCTP יכולות לקבל כתובות IP מרובות. לא כחיבורים נפרדים — כחלק מאותה אסוציאציה.

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

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

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

גבולות ההודעות נשמרים

TCP הוא זרם בתים. אתה שולח 500 בתים, אחר כך 300 בתים. המקבל עשוי לקבל 200, אחר כך 400, אחר כך 200. אתה חייב לממש מסגור משלך — קידומות אורך, מפרידים, משהו — כדי להבין היכן הודעות מתחילות ומסתיימות.

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

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

היכן SCTP באמת חי

SCTP תוכנן עבור איתות טלפוניה, וזה עדיין ביתו העיקרי. כשמוקמות שיחות טלפון דרך רשתות IP, תעבורת האיתות (ההודעות שאומרות "צלצל בטלפון הזה" ו"הם ענו") עוברת לעיתים קרובות דרך SCTP. ריבוי הזרמים מטפל באלפי זרמי שיחות עצמאיים. ריבוי הכתובות מספק אמינות ברמת ספק תקשורת.

WebRTC הוא החיים השניים של SCTP. כשדפדפנים מקימים ערוצי נתונים — החלק של נתונים שרירותיים ב-WebRTC, לא האודיו/וידאו — הם משתמשים ב-SCTP. הוא עטוף ב-DTLS מעל UDP כדי לחצות NATs, אבל סמנטיקת ערוץ הנתונים האמיתית מגיעה מ-SCTP. כל ערוץ נתונים של WebRTC הוא זרם SCTP. סדר עצמאי. גבולות הודעות. התכונות מתאימות בצורה מושלמת.

למה מעולם לא השתמשת בו

SCTP עדיף טכנית על TCP עבור מקרי שימוש רבים. אז למה הוא לא בכל מקום?

האינטרנט התאבן.

חומות אש לא מבינות SCTP. הן רואות פרוטוקול IP 132 ומפילות אותו. התקני NAT לא יודעים כיצד לעקוב אחר אסוציאציות SCTP. רכיבי הביניים שיושבים בינך לבין כל השאר נבנו עבור TCP ו-UDP, והם מתייחסים לכל דבר אחר כחשוד.

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

בינתיים, TCP קיבל ריבוב HTTP/2, שפותר חסימת ראש התור בשכבת היישום (ברובה). QUIC הגיע ופתר את זה כראוי — על ידי מעבר ל-UDP ויישום מחדש של תעבורה מהימנה. הבעיות ש-SCTP פתר נפתרו בדרכים אחרות.

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

הבנת SCTP חושפת משהו חשוב: הפרוטוקול הטוב ביותר לא תמיד מנצח. לעיתים הבסיס המותקן מנצח. לעיתים רכיבי הביניים מנצחים. לעיתים "מספיק טוב" בתוספת פריסה אוניברסלית עוקף "טוב יותר" בתוספת "המנות שלך יופלו".

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

במה SCTP שונה מ-TCP?

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

האם ניתן להשתמש ב-SCTP באינטרנט הציבורי?

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

מהי חסימת ראש התור?

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

למה WebRTC משתמש ב-SCTP?

ערוצי נתוני WebRTC זקוקים לגבולות הודעות (לא זרמי בתים), ערוצים עצמאיים מרובים, ואפשרויות אמינות גמישות. SCTP מספק את כל זאת באופן מובנה. הוא עטוף ב-DTLS מעל UDP כדי לחצות NATs, אבל סמנטיקת הערוצים האמיתית מגיעה מ-SCTP.