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

פריט הגרפיקה

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

למה?

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

למה כדאי להשתמש ב-QUIC?

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

איך?

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

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

RTCIceTransport

ICE הוא פרוטוקול ליצירת קשרים מקצה לקצה (P2P) באינטרנט, נמצא בשימוש ב-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 ו-password), וגם ל-RTCIceCandidates.

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

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, או לבטל את השימוש ב-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
• השבתת שידורים חוזרים
• (בקרוב) תרשימי נתונים

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

אבטחה

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

התקפה פעילה

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

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

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

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