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

פריט הגרפיקה

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

למה?

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

למה QUIC?

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

איך עושים את זה?

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

ל-API יש 3 תקצירים עיקריים: RTCIceTransport, RTCQuicTransport ו-RTCQuicStream.

תרשים RTCQuicTransport שמציג את הארכיטקטורה של API

RTCIceTransport

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

RTCQuicTransport

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

RTCQuicStream

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

הגדרת החיבור

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

תרשים RTCQuicTransport שמציג את הארכיטקטורה של API

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

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);

הסרטון בתהליך אגירת נתונים

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

פרטי המשלוח לא מוזמנים או לא מהימנים

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

מתי?

גרסת המקור לניסיון תתחיל בגרסת Chrome 73, ותהיה זמינה עד גרסה M75, כולל. לאחר מכן, תקופת הניסיון המקורית תסתיים. בהתאם למשוב ולהתעניינות שלנו, נבצע את השינויים המתאימים. לאחר מכן נשלח את ה-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 בגרסת המקור, כולל:

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

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

אבטחה

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

התקפה פעילה

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

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

שלב סטטוס
1. יצירת הסבר הושלם
**2a. מפרט RTCQuicTransport ** **בתהליך**
**2b. מפרט RTCIceTransport ** **בתהליך**
**3. אוספים משוב וחוזרים על העיצוב** **בתהליך**
4. גרסת מקור לניסיון מתחיל ב-Chrome 73!
5. הפעלה לא התחיל

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