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

อะไร

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

เหตุผล

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

เหตุผลที่ควรใช้ QUIC

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

วิธีการ

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

API มีการแยกแยะหลัก 3 รายการ ได้แก่ RTCIceTransport, RTCQuicTransport และ RTCQuicStream

RTCIceTransport

ICE เป็นโปรโตคอลสำหรับสร้างการเชื่อมต่อแบบ peer-to-peer ผ่านอินเทอร์เน็ต และใช้ใน WebRTC ในปัจจุบัน ออบเจ็กต์นี้มี API แบบสแตนด์อโลนสำหรับสร้างการเชื่อมต่อ ICE แพ็กเก็ตนี้ใช้เป็นการรับส่งแพ็กเก็ตสําหรับการเชื่อมต่อ QUIC และ RTCQuicTransport จะรับแพ็กเก็ตนี้ในคอนสตรคเตอร์

RTCQuicTransport

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

RTCQuicStream

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

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

ต่อไปนี้เป็นตัวอย่างการตั้งค่าการเชื่อมต่อ QUIC แบบ peer-to-peer เช่นเดียวกับ 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);

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

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

การนำส่งที่ไม่เป็นไปตามลำดับ/ไม่น่าเชื่อถือ

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

เมื่อไร

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

ตำแหน่ง

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

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

ความคิดเห็น

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

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

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

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

ข้อกําหนดของเว็บ

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

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

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

ความปลอดภัย

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

การโจมตีที่ใช้งานอยู่

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

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

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

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