ที่บอกว่า
RTCQuicTransport เป็นแพลตฟอร์มเว็บใหม่ที่ช่วยให้แลกเปลี่ยนข้อมูลได้ตามต้องการกับแอปเทียบเท่าจากระยะไกลโดยใช้โปรโตคอล QUIC เครื่องมือดังกล่าวมีไว้สําหรับกรณีการใช้งานแบบเพียร์ทูเพียร์ จึงใช้กับ API RTCIceTransport แบบสแตนด์อโลนเพื่อสร้างการเชื่อมต่อแบบเพียร์ทูเพียร์ผ่าน ICE ได้ ข้อมูลจะได้รับการจัดส่งอย่างเสถียรและเป็นไปตามลำดับ (ดูรายละเอียดเกี่ยวกับการนำส่งที่ไม่เรียงลำดับและไม่น่าเชื่อถือ) ได้ในส่วนด้านล่าง เนื่องจากเป็นการรับส่งข้อมูลแบบ 2 ทิศทางโดยทั่วไป จึงใช้สำหรับการเล่นเกม การโอนไฟล์ การส่งสื่อ การรับส่งข้อความ ฯลฯ ได้
เหตุผล
API การรับส่งข้อมูลระดับต่ำที่มีประสิทธิภาพช่วยให้แอปพลิเคชัน (เช่น การสื่อสารแบบเรียลไทม์) ทำสิ่งใหม่ๆ ในเว็บได้ คุณสามารถต่อยอดจาก API สร้างโซลูชันของตัวเอง ขยายขอบเขตของสิ่งที่ทำได้ด้วยการเชื่อมต่อแบบเพียร์ทูเพียร์ เช่น ปลดล็อกปุ่มการจัดสรรอัตราบิตที่กำหนดเอง ในอนาคต การสนับสนุนเพิ่มเติมสำหรับสื่อที่เข้ารหัสอาจช่วยให้สร้างแอปพลิเคชันการสื่อสารผ่านวิดีโอของคุณเองโดยมีการควบคุมในระดับต่ำได้ ความพยายามของ NV สำหรับ WebRTC คือการเปลี่ยนไปใช้ API ระดับต่ำกว่า และการทดลองกับ API นี้ในช่วงต้นเป็นสิ่งที่มีค่า
ทำไมต้องเป็น QUIC
โปรโตคอล QUIC เป็นที่ต้องการสำหรับการสื่อสารแบบเรียลไทม์ เทคโนโลยีนี้สร้างขึ้นจาก UDP มีการเข้ารหัสในตัว การควบคุมความคับคั่ง และทำการมัลติเพล็กซ์โดยไม่ต้องมีการบล็อกบรรทัดใหม่ RTCQuicTransport
มีความสามารถคล้ายกับ RTCDataChannel
API แต่ใช้ QUIC เป็นโปรโตคอลการขนส่งแทน SCTP เนื่องจาก RTCQuicTransport
เป็น API แบบสแตนด์อโลน จึงไม่มีค่าใช้จ่ายของ RTCPeerConnection
API ซึ่งรวมถึงสแต็กสื่อแบบเรียลไทม์
ต้องทำอย่างไร
ภาพรวม 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 แบบเพียร์ทูเพียร์
RTCQuicTransport
API ต้องใช้ช่องทางการส่งสัญญาณที่ปลอดภัยเพื่อเจรจาพารามิเตอร์ของการเชื่อมต่อ ซึ่งรวมถึงพารามิเตอร์ความปลอดภัยของช่องทางดังกล่าว เช่นเดียวกับ RTCPeerConnection
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 สำหรับส่งข้อมูลอื่นๆ (
WebSocket
หรือRTCDataChannel
ของ WebRTC) อย่างไร จะปรับปรุงได้อย่างไร - การแสดง
- หลักการยศาสตร์ของ API
ลงทะเบียนช่วงทดลองใช้จากต้นทาง
- ขอโทเค็นสำหรับต้นทาง
- เพิ่มโทเค็นลงในหน้าเว็บ คุณจะระบุโทเค็นนี้ในหน้าใดก็ได้ในต้นทางได้ 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
แอ็คชัน Attack
การส่งสัญญาณคีย์ที่แชร์ล่วงหน้าจำเป็นต้องมีความสมบูรณ์และข้อมูลลับ ซึ่งต่างจาก DTLS-SRTP ตรงที่เพียงต้องการความสมบูรณ์ในการส่งสัญญาณลายนิ้วมือของใบรับรอง หาก PSK ถูกบุกรุก (เช่น เซิร์ฟเวอร์ในช่องส่งสัญญาณ) ผู้โจมตีที่ใช้งานอยู่อาจสร้างการโจมตีแบบแทรกกลางการสื่อสาร (Man-In-The-Middle) ต่อแฮนด์เชค QUIC
สถานะปัจจุบัน
ขั้นตอน | สถานะ |
---|---|
1. สร้างคำอธิบาย | เสร็จสมบูรณ์ |
**2a. ข้อกำหนดจำเพาะของ RTCQuicTransport ** | **กำลังดำเนินการ** |
**2b. ข้อกำหนดของ RTCIceTransport ** | **กำลังดำเนินการ** |
**3. รวบรวมความคิดเห็นและทำซ้ำการออกแบบ** | **กำลังดำเนินการ** |
4. ช่วงทดลองใช้จากต้นทาง | เริ่มได้ใน Chrome 73 |
5. เปิดใช้งาน | Not started |
ลิงก์ที่มีประโยชน์
- เอกสารประกอบเพิ่มเติม
- คำอธิบายแบบสาธารณะ
- การติดตามข้อบกพร่อง
- ขอโทเค็นการทดลองใช้ต้นทาง
- วิธีใช้โทเค็นช่วงทดลองใช้จากต้นทาง
- การพูดคุยเกี่ยวกับปัญหาสำหรับ RTCQuicTransport
- การพูดคุยเกี่ยวกับปัญหาสำหรับ RTCIceTransport