RTCQuicTransport מגיע לגרסת מקור לניסיון בסביבה שלך (Chrome 73)

פריט הגרפיקה

RTCQuicTransport הוא ממשק API חדש לפלטפורמת אינטרנט שמאפשר להחליף נתונים שרירותיים עם עמיתים מרוחקים באמצעות פרוטוקול QUIC. הוא מיועד לתרחישי שימוש של שיתוף פעולה בין משתמשים, ולכן משמש עם API עצמאי של RTCIceTransport כדי ליצור חיבור בין משתמשים דרך ICE. הנתונים מועברים בצורה מהימנה ובסדר (בקטע שבהמשך מוסבר על העברה לא מסודרת ולא מהימנה). מכיוון שזוהי מערכת גנרית להעברת נתונים דו-כיוונית, אפשר להשתמש בה למשחקים, להעברת קבצים, להעברת מדיה, לשליחת הודעות וכו'.

למה?

ממשק API חזק להעברת נתונים ברמה נמוכה יכול לאפשר לאפליקציות (כמו תקשורת בזמן אמת) לבצע פעולות חדשות באינטרנט. אתם יכולים להשתמש ב-API כדי ליצור פתרונות משלכם, ולחקור את הגבולות של מה שאפשר לעשות באמצעות חיבורי peer-to-peer. לדוגמה, תוכלו לפתוח את הנעילה של פקדים מותאמים אישית להקצאת קצב העברת נתונים. בעתיד, תמיכה נוספת במדיה מקודדת עשויה לאפשר לכם ליצור אפליקציה משלכם לתקשורת וידאו עם אמצעי בקרה ברמה נמוכה. המאמץ של WebRTC בנושא NV הוא לעבור ל-API ברמה נמוכה יותר, וחשוב להתנסות בכך מוקדם.

למה QUIC?

פרוטוקול QUIC מומלץ לתקשורת בזמן אמת. הוא מבוסס על UDP, כולל הצפנה מובנית, בקרת עומסים ומופעל במולטיפלקס ללא חסימה של ראש התור. ל-RTCQuicTransport יש יכולות דומות מאוד לאלה של ה-API ‏RTCDataChannel, אבל הוא משתמש ב-QUIC במקום ב-SCTP כפרוטוקול התעבורה שלו. מאחר ש-RTCQuicTransport הוא ממשק API עצמאי, הוא לא כולל את התקורה של ממשק ה-API RTCPeerConnection, שכולל את סטאק המדיה בזמן אמת.

איך?

סקירה כללית על ממשקי API

ל-API יש 3 רמות הפשטה עיקריות: RTCIceTransport,‏ RTCQuicTransport ו-RTCQuicStream.

RTCIceTransport

ICE הוא פרוטוקול ליצירת חיבורים מקצה לקצה באינטרנט, והוא נמצא בשימוש ב-WebRTC כיום. האובייקט הזה מספק ממשק API עצמאי ליצירת חיבור ICE. הוא משמש להעברת חבילות בחיבורי QUIC, וה-RTCQuicTransport מקבל אותו ב-constructor שלו.

RTCQuicTransport

מייצג חיבור QUIC. הוא משמש ליצירת חיבור QUIC וליצירת סטרימינג של QUIC. הוא גם חושף נתונים סטטיסטיים רלוונטיים ברמת החיבור של QUIC.

RTCQuicStream

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

הגדרת החיבור

בדוגמה הבאה מוסבר איך מגדירים חיבור QUIC מקצה לקצה. בדומה ל-RTCPeerConnection, גם ב-API של RTCQuicTransport נדרש שימוש בערוץ איתות מאובטח כדי לנהל משא ומתן על הפרמטרים של החיבור, כולל פרמטרים של אבטחה. ה-RTCIceTransport מנהל משא ומתן על הפרמטרים של ICE (ufrag וסיסמה), וגם על RTCIceCandidate.

מנקודת המבט של הלקוח:

const iceTransport = new RTCIceTransport();
const quicTransport = new RTCQuicTransport(iceTransport);
// Signal parameters, key and candidates.
signalingChannel.send({
  iceParams: iceTransport.getLocalParameters(),
  quicKey: quicTransport.getKey(),
});
iceTransport.onicecandidate = e => {
  if (e.candidate) {
    signalingChannel.send({candidate: e.candidate});
  }
};

// When remote parameters are signaled, start connection.
signalingChannel.onMessage = async ({iceParams, candidate}) => {
  if (iceParams) {
    iceTransport.start(iceParams);
    quicTransport.connect();
  } else if (candidate) {
    iceTransport.addRemoteCandidate(candidate);
  }
};

מנקודת המבט של השרת:

const iceTransport = new RTCIceTransport();
const quicTransport = new RTCQuicTransport(iceTransport);
// Signal parameters, key and candidates.
signalingChannel.send({
  iceParams: iceTransport.getLocalParameters(),
});
iceTransport.onicecandidate = e => {
  if (e.candidate) {
    signalingChannel.send({candidate: e.candidate});
  }
};

// When remote parameters are signaled, start connection.
signalingChannel.onMessage = async ({iceParams, quicKey, candidate}) => {
  if (iceParams && quicKey) {
    iceTransport.start(iceParams);
    quicTransport.listen(quicKey);
  } else if (candidate) {
    iceTransport.addRemoteCandidate(candidate);
  }
};

העברת נתונים

אפשר להעביר נתונים באמצעות ממשקי ה-API של RTCQuicStream לקריאה ולכתיבה:

RTCQuicStreamReadResult readInto(Uint8Array data);
void write(RTCQuicStreamWriteParameters data);
Promise<void> waitForWriteBufferedAmountBelow(unsigned long amount);
Promise<void> waitForReadable(unsigned long amount);

מאחסן במאגר

ה-promises שמוחזרים על ידי השיטות waitFor* מאפשרים להעביר נתונים למאגר כש-JavaScript עסוק. לחץ חזרה מוחל על צד השליחה כשמאגר הקריאה מתמלא בצד הקבלה. בצד השליחה יש מאגר לכתיבה שיכול להתמלא כשיש לחץ חוזר, ולכן בצד הכתיבה יש גם שיטה waitForWriteBufferedAmountBelow שמאפשרת לחכות למקום במאגר כדי לכתוב. מידע נוסף על כתיבת נתונים או קריאת נתונים זמין במסמכי התיעוד למפתחים.

משלוח לא מדויק/לא אמין

RTCQuicStream תומך רק בשליחת נתונים באופן מהימן ומסודר, אבל אפשר להשיג העברה לא מהימנה או לא מסודרת באמצעים אחרים. כדי לשלוח נתונים ללא סדר, אפשר לשלוח קטעי נתונים קטנים במקורות נתונים נפרדים, כי הנתונים לא מסודרים בין המקורות. כדי לשלוח נתונים באופן לא מהימן, אפשר לשלוח קטעי נתונים קטנים עם הערך finish מוגדר כ-true, ולאחר מכן לבצע קריאה ל-reset() על הסטרימינג לאחר זמן קצוב לתפוגה. זמן הקצאת הזמן צריך להיות תלוי במספר ההעברות החוזרות הרצויות לפני שמבטלים את הנתונים.

מתי?

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

איפה?

דפדפן Chrome בכל הפלטפורמות, מלבד iOS.

מה עוד?

משוב

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

• מה אפשר לעשות באמצעות ממשק ה-API הזה?
• מהם יתרונות ה-API הזה על פני ממשקי API אחרים להעברת נתונים (WebSocket או RTCDataChannel של WebRTC)? איך אפשר לשפר אותו?
• ביצועים
• ארגונומיה של API

הרשמה לגרסת המקור לניסיון

1. מבקשים אסימון למקור.
2. מוסיפים את האסימון לדפים. יש שתי דרכים לספק את האסימון בכל דפים במקור:
   • מוסיפים תג origin-trial <meta> לחלק ה'כותרת' של כל דף. לדוגמה, זה יכול להיראות כך: <meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
   • אם אפשר להגדיר את השרת, אפשר גם לספק את האסימון בדפים באמצעות כותרת HTTP מסוג Origin-Trial. כותרת התגובה שמתקבלת אמורה להיראות בערך כך: Origin-Trial: TOKEN_GOES_HERE

מפרט אינטרנט

טיוטת המפרט התקדמה לפני ה-API בגרסת המקור לניסיון, כולל:

• שידורים חד-כיווניים שתואמים יותר לשידורים של WHATWG
• השבתת העברות חוזרות
• (בקרוב) נתונים

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

אבטחה

האבטחה במחווה הראשונית להתחברות (handshake) ב-QUIC נאכפת באמצעות שימוש במפתח ששותף מראש כדי ליצור חיבור QUIC מוצפן מסוג P2P. צריך לשלוח את המפתח הזה באמצעות ערוץ מאובטח מחוץ לפס, עם ערבויות לסודיות ולתקינות. שימו לב שהמפתח יהיה חשוף ל-JavaScript.

Active Attack

בניגוד ל-DTLS-SRTP, שבו נדרש רק תקינות לשליחת אות של טביעת האצבע של האישור, לשליחת אות של מפתח משותף מראש נדרשת תקינות וסודיות. אם ה-PSK נפרץ (למשל על ידי השרת בערוץ האותות), תוקף פעיל עלול לבצע התקפת אדם בתווך על לחיצת היד של QUIC.

הסטטוס הנוכחי

קישורים מועילים

• מסמכי עזרה נוספים
• הסבר ציבורי
• באג במעקב
• שליחת בקשה לאסימון לתקופת ניסיון במקור
• איך משתמשים באסימון לניסיון מקור
• דיון בבעיות בנושא RTCQuicTransport
• דיון בבעיות בנושא RTCIceTransport