เตรียมทดลองใช้ RTCQuicTransport จากต้นทางใกล้บ้านคุณ (Chrome 73)

ที่บอกว่า

RTCQuicTransport เป็นแพลตฟอร์มเว็บใหม่ API ที่อนุญาตให้แลกเปลี่ยนข้อมูลที่กำหนดเองกับกลุ่มแอปเทียบเท่าระยะไกลโดยใช้ QUIC เหมาะสำหรับการใช้งานแบบเพียร์ทูเพียร์ ดังนั้นจึงใช้ร่วมกับ RTCIceTransport แบบสแตนด์อโลน API สำหรับสร้างการเชื่อมต่อแบบเพียร์ทูเพียร์ ICE ข้อมูลจะได้รับการส่งผ่านอย่างเสถียรและเรียงตามลำดับ (ดูหัวข้อด้านล่าง เพื่อดูรายละเอียดเกี่ยวกับ ที่ไม่น่าเชื่อถือ) เนื่องจากเป็นข้อเสนอทั่วไป ในการรับส่งข้อมูลแบบ 2 ทิศทาง สำหรับการเล่นเกม โอนไฟล์ การขนส่งสื่อ การรับส่งข้อความ ฯลฯ

เหตุผล

API การส่งข้อมูลระดับต่ำที่มีประสิทธิภาพช่วยให้เปิดใช้งานแอปพลิเคชันต่างๆ ได้ (เช่น เรียลไทม์ เพื่อทำงานใหม่ๆ บนเว็บได้ คุณสามารถสร้างต่อยอดจาก API สร้างโซลูชันของตัวเอง ทลายขีดจำกัดของสิ่งที่ทำได้ร่วมกับเพื่อน เพื่อเชื่อมต่อกับเพียร์ เช่น การปลดล็อกปุ่มการจัดสรรอัตราบิตที่กำหนดเอง ใน การสนับสนุนเพิ่มเติมสำหรับสื่อที่เข้ารหัสอาจช่วยสร้าง แอปพลิเคชันการสื่อสารผ่านวิดีโอพร้อมด้วยการควบคุมระดับต่ำ ความพยายาม NV ของ WebRTC คือการเปลี่ยนไปใช้ API ระดับต่ำลงมา และทำการทดสอบตั้งแต่เนิ่นๆ มีคุณค่า

ทำไมจึงต้องใช้ QUIC

ควรใช้โปรโตคอล QUIC สำหรับการสื่อสารแบบเรียลไทม์ เราสร้างไว้ที่ด้านบน UDP ที่มีการเข้ารหัสในตัว การควบคุมความคับคั่ง และมีการมัลติเพล็กซ์ ของการบล็อก RTCQuicTransport มีความสามารถที่คล้ายกันมาก RTCDataChannel API แต่ใช้ QUIC แทน SCTP เป็นการส่ง เนื่องจาก RTCQuicTransport เป็น API แบบสแตนด์อโลน จึงไม่มี โอเวอร์เฮดของ API RTCPeerConnection ซึ่งรวมถึงสื่อแบบเรียลไทม์ สแต็ก

วิธีการ

ภาพรวม API ทั่วไป

API มีแอบสแตรกต์หลัก 3 แบบ ได้แก่ RTCIceTransport และ RTCQuicTransport และ RTCQuicStream

RTCIceTransport

ICE เป็นโปรโตคอลสำหรับสร้างการเชื่อมต่อระหว่างเครื่องผ่านอินเทอร์เน็ตและ ใช้ใน WebRTC วันนี้ ออบเจ็กต์นี้มี API แบบสแตนด์อโลนเพื่อสร้าง การเชื่อมต่อ ICE ซึ่งใช้เป็นการขนส่งแพ็กเก็ตสำหรับการเชื่อมต่อ QUIC และ RTCQuicTransport จะนำไปสร้างในเครื่องมือสร้าง

RTCQuicTransport

แสดงการเชื่อมต่อ QUIC โดยใช้เพื่อสร้างการเชื่อมต่อ QUIC และ สร้างสตรีม QUIC นอกจากนี้ยังแสดงสถิติที่เกี่ยวข้องสำหรับการเชื่อมต่อ QUIC ด้วย

RTCQuicStream

ใช้สำหรับอ่านและเขียนข้อมูลไปยัง/จากที่อยู่ระยะไกล การส่งสตรีม ข้อมูลได้อย่างมีเสถียรภาพและเรียงตามลำดับ คุณสามารถสร้างสตรีมหลายรายการจากสตรีมเดียวกันได้ RTCQuicTransport และเมื่อมีการเขียนข้อมูลลงในสตรีม สคริปต์ก็จะเริ่มทำงาน เหตุการณ์ “onquicstream” ในรถส่งของระยะไกล สตรีมช่วยให้คุณ แยกความแตกต่างของข้อมูลต่างๆ บนการเชื่อมต่อ QUIC เดียวกัน ตัวอย่างทั่วไปอาจ ส่งไฟล์แยกผ่านสตรีมแยก ข้อมูลส่วนเล็กๆ สตรีมที่ต่างกัน หรือสื่อประเภทต่างๆ ในสตรีมที่ต่างกัน RTCQuicStream ดังกล่าวมีขนาดเล็ก ทำงานแบบมัลติเพล็กซ์ผ่านการเชื่อมต่อ QUIC และ ไม่ทำให้มีการบล็อกส่วนหัวกับ RTCQuicStream อื่นๆ

การตั้งค่าการเชื่อมต่อ

ตัวอย่างต่อไปนี้เป็นตัวอย่างการตั้งค่าการเชื่อมต่อ QUIC แบบเพียร์ทูเพียร์ เช่นเดียวกับ RTCPeerConnection RTCQuicTransport API กำหนดให้ใช้ ช่องทางการส่งสัญญาณที่ปลอดภัยเพื่อเจรจาหาพารามิเตอร์ของการเชื่อมต่อ รวมถึงพารามิเตอร์ความปลอดภัย 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);
  }
};

การโอนข้อมูล

คุณทำการโอนข้อมูลได้โดยใช้ RTCQuicStream API สำหรับการอ่านและ การเขียน:

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

กำลังบัฟเฟอร์

คำมั่นสัญญาที่แสดงผลโดยเมธอด waitFor* จะทำให้มีการบัฟเฟอร์ข้อมูลเมื่อ JavaScript ไม่ว่าง แรงกดดันย้อนกลับจะมีผลกับด้านส่งเมื่อ บัฟเฟอร์การอ่านจะเต็มในด้านรับ ด้านส่งมีการเขียน สามารถเติมพื้นเมื่อมีการใช้แรงดันด้านหลัง ด้วยเหตุนี้ ด้านการเขียนมีเมธอด waitForWriteBufferedAmountBelow และเพื่อ รอให้ที่ว่างในบัฟเฟอร์เขียน ข้อมูลเพิ่มเติมเกี่ยวกับ ดูการเขียน/การอ่านข้อมูลได้ในนักพัฒนาซอฟต์แวร์เพิ่มเติม เอกสารประกอบ

การนำส่งที่ไม่ได้สั่งซื้อ/ไม่น่าเชื่อถือ

แม้ว่า RTCQuicStream จะรองรับเฉพาะการส่งข้อมูลอย่างเสถียรและเรียงตามลำดับเท่านั้น การนำส่งที่ไม่น่าเชื่อถือ/ไม่เรียงลำดับนั้นเกิดขึ้นได้ด้วยวิธีอื่นๆ สำหรับ การนำส่งที่ไม่ได้เรียงลำดับ คนหนึ่งสามารถส่งข้อมูลส่วนเล็กๆ ในสตรีมแยกกัน เนื่องจากไม่ได้เรียงลำดับข้อมูลระหว่างสตรีม สำหรับการนำส่ง ที่ไม่น่าเชื่อถือ สามารถส่งข้อมูลส่วนเล็กๆ โดยตั้งค่าขั้นสุดท้ายเป็น "จริง" ตามด้วยการเรียกใช้ reset() ในสตรีมหลังจากหมดเวลา การหมดเวลาควรขึ้นอยู่กับ ต้องการส่งข้อมูลซ้ำกี่ครั้งก่อนที่จะทิ้งข้อมูล

เมื่อไร

ช่วงทดลองใช้จากต้นทางจะเริ่มต้นใน Chrome เวอร์ชัน 73 และจะพร้อมใช้งาน และรวมถึงเวอร์ชัน M75 หลังจากช่วงทดลองใช้จากต้นทางจะ สิ้นสุด เราจะทำการเปลี่ยนแปลงที่เหมาะสมตามความคิดเห็นและความสนใจ แล้วจัดส่ง API ดำเนินการต่อด้วยช่วงทดลองใช้จากต้นทางใหม่ของ API นี้ หรือ เลิกใช้ API

ตำแหน่ง

เบราว์เซอร์ Chrome ในทุกแพลตฟอร์มยกเว้น iOS

มีอะไรอีกไหม

ความคิดเห็น

เป้าหมายหลักอย่างหนึ่งของ ช่วงทดลองใช้จากต้นทางคือการรับความคิดเห็นจากคุณ นักพัฒนาซอฟต์แวร์ สิ่งที่เราสนใจมีดังนี้

• API นี้ช่วยอะไรคุณได้บ้าง
• API นี้ปรับปรุงอย่างไรกับ API การนำส่งข้อมูลอื่นๆ (RTCDataChannel ของ WebSocket หรือ WebRTC) หรือไม่ จะปรับปรุงให้ดีขึ้นได้อย่างไร
• ประสิทธิภาพ
• การยศาสตร์ของ API

ลงทะเบียนช่วงทดลองใช้จากต้นทาง

1. ขอโทเค็นสำหรับต้นทาง
2. การเพิ่มโทเค็นไปยังหน้าเว็บของคุณ คุณสามารถระบุโทเค็นนี้ได้ 2 วิธี หน้าใดก็ได้ในต้นทางของคุณ
   • เพิ่มแท็ก origin-trial <meta> ในส่วนหัวของหน้าใดก็ได้ ตัวอย่างเช่น ซึ่งอาจมีลักษณะดังนี้ <meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
   • หากคุณกำหนดค่าเซิร์ฟเวอร์ได้ คุณยังระบุโทเค็นในหน้าต่างๆ ได้ด้วย โดยใช้ส่วนหัว HTTP ของ Origin-Trial ส่วนหัวการตอบกลับที่ได้ควร จะมีลักษณะดังนี้ Origin-Trial: TOKEN_GOES_HERE

ข้อกำหนดเกี่ยวกับเว็บ

ข้อกำหนดฉบับร่างได้ย้ายไปก่อน API ในช่วงทดลองใช้จากต้นทาง ซึ่งรวมถึง

• สตรีมแบบทิศทางเดียวที่มีแนวเดียวกับสตรีม WHATWG มากกว่า
• การปิดการรับส่งข้อมูลอีกครั้ง
• Datagrams (เร็วๆ นี้)

เราสนใจที่จะปฏิบัติตามข้อกำหนดทั้งหมดและอื่นๆ (รวมถึง รองรับสตรีม WHATWG) แต่อยากฟังความคิดเห็นจากคุณก่อน

ความปลอดภัย

ระบบจะบังคับใช้ความปลอดภัยในแฮนด์เชค QUIC ผ่านการใช้คีย์ที่แชร์ล่วงหน้าเพื่อ สร้างการเชื่อมต่อ P2P QUIC ที่เข้ารหัส คีย์นี้ต้องได้รับสัญญาณผ่าน เป็นช่องที่มีความปลอดภัยน้อยกว่า และรับประกันความซื่อสัตย์และการรักษาข้อมูลที่เป็นความลับ โปรดทราบว่าคีย์จะแสดงใน JavaScript

การโจมตีแบบแอ็กทีฟ

ต่างจาก DTLS-SRTP ซึ่งแค่ต้องการความสมบูรณ์ในการส่งสัญญาณใบรับรอง ลายนิ้วมือ การส่งสัญญาณคีย์ที่แชร์ล่วงหน้าต้องมีความสมบูรณ์และ การรักษาข้อมูลที่เป็นความลับ หาก PSK ถูกบุกรุก (เช่น เซิร์ฟเวอร์ในการส่งสัญญาณ) ) ผู้โจมตีที่ใช้งานอยู่อาจเพิ่มการโจมตีแบบแทรกกลางการสื่อสารได้ เทียบกับแฮนด์เชค QUIC

สถานะปัจจุบัน

ลิงก์ที่มีประโยชน์

• เอกสารประกอบเพิ่มเติม
• คำอธิบายแบบสาธารณะ
• ข้อบกพร่องในการติดตาม
• ขอโทเค็นการทดลองใช้ต้นทาง
• วิธีใช้โทเค็นช่วงทดลองใช้จากต้นทาง
• การสนทนาเกี่ยวกับปัญหาของ RTCQuicTransport
• การสนทนาเกี่ยวกับปัญหาของ RTCIceTransport