Loại hình minh hoạ nào?
RTCQuicTransport là một API nền tảng web mới cho phép trao đổi dữ liệu tuỳ ý với các máy ngang hàng từ xa bằng giao thức QUIC. API này dành cho các trường hợp sử dụng ngang hàng, do đó, được dùng với API RTCIceTransport độc lập để thiết lập kết nối ngang hàng thông qua ICE. Dữ liệu được vận chuyển một cách đáng tin cậy và theo thứ tự (xem phần bên dưới để biết thông tin chi tiết về việc phân phối không theo thứ tự và không đáng tin cậy). Vì là một phương thức truyền dữ liệu hai chiều, chung, nên bạn có thể dùng phương thức này để chơi trò chơi, chuyển tệp, truyền nội dung nghe nhìn, nhắn tin, v.v.
Tại sao?
Một API truyền dữ liệu cấp thấp mạnh mẽ có thể cho phép các ứng dụng (chẳng hạn như giao tiếp theo thời gian thực) thực hiện những việc mới trên web. Bạn có thể xây dựng dựa trên API, tạo giải pháp của riêng mình, đẩy giới hạn của những việc có thể làm được với các kết nối ngang hàng, chẳng hạn như mở khoá các nút phân bổ tốc độ bit tuỳ chỉnh. Trong tương lai, việc hỗ trợ thêm nội dung đa phương tiện được mã hoá thậm chí có thể cho phép bạn tạo ứng dụng giao tiếp bằng video của riêng mình bằng các chế độ điều khiển cấp thấp. Nỗ lực của WebRTC về NV là chuyển sang các API cấp thấp hơn và việc thử nghiệm sớm với điều này là rất có giá trị.
Tại sao nên dùng QUIC?
Giao thức QUIC là lựa chọn phù hợp cho hoạt động giao tiếp theo thời gian thực. Giao thức này được xây dựng dựa trên UDP, tích hợp sẵn tính năng mã hoá, kiểm soát tình trạng tắc nghẽn và được đa kênh hoá mà không chặn đầu dòng. RTCQuicTransport
cung cấp các chức năng rất giống với API RTCDataChannel
, nhưng sử dụng QUIC thay vì SCTP làm giao thức truyền tải. Vì RTCQuicTransport
là một API độc lập, nên API này không có chi phí hao tổn của API RTCPeerConnection
, bao gồm cả ngăn xếp nội dung nghe nhìn theo thời gian thực.
Cách thực hiện:
Tổng quan chung về API
API này có 3 thành phần trừu tượng chính là RTCIceTransport
, RTCQuicTransport
và RTCQuicStream
.
RTCIceTransport
ICE là một giao thức để thiết lập kết nối ngang hàng qua Internet và được sử dụng trong WebRTC hiện nay. Đối tượng này cung cấp một API độc lập để thiết lập kết nối ICE. Lớp này được dùng làm phương thức truyền gói cho kết nối QUIC và RTCQuicTransport
sẽ lấy lớp này trong hàm khởi tạo.
RTCQuicTransport
Đại diện cho một kết nối QUIC. Lớp này được dùng để thiết lập kết nối QUIC và tạo luồng QUIC. Trình phân tích tài nguyên cũng hiển thị số liệu thống kê có liên quan cho cấp kết nối QUIC.
RTCQuicStream
Dùng để đọc và ghi dữ liệu đến/từ phía xa. Luồng truyền dữ liệu một cách đáng tin cậy và theo thứ tự. Bạn có thể tạo nhiều luồng từ cùng một RTCQuicTransport
và sau khi dữ liệu được ghi vào một luồng, luồng đó sẽ kích hoạt sự kiện "onquicstream" trên phương thức truyền từ xa. Luồng cung cấp một cách để phân biệt các dữ liệu khác nhau trên cùng một kết nối QUIC. Ví dụ phổ biến có thể là gửi các tệp riêng biệt trên các luồng riêng biệt, các đoạn dữ liệu nhỏ trên các luồng khác nhau hoặc các loại nội dung nghe nhìn khác nhau trên các luồng riêng biệt. RTCQuicStream
có kích thước nhỏ, được đaплекс qua kết nối QUIC và không gây ra tình trạng chặn đầu hàng đối với các RTCQuicStream
khác.
Thiết lập kết nối
Sau đây là ví dụ về cách thiết lập kết nối QUIC ngang hàng.
Giống như RTCPeerConnection
, API RTCQuicTransport
yêu cầu sử dụng một kênh báo hiệu bảo mật để đàm phán các tham số của kết nối, bao gồm cả các tham số bảo mật. RTCIceTransport
đàm phán các tham số ICE (ufrag và mật khẩu), cũng như RTCIceCandidate
.
Quan điểm của ứng dụng:
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);
}
};
Quan điểm của máy chủ:
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);
}
};
Chuyển dữ liệu
Bạn có thể chuyển dữ liệu bằng cách sử dụng các API RTCQuicStream để đọc và ghi:
RTCQuicStreamReadResult readInto(Uint8Array data);
void write(RTCQuicStreamWriteParameters data);
Promise<void> waitForWriteBufferedAmountBelow(unsigned long amount);
Promise<void> waitForReadable(unsigned long amount);
Đang lưu tạm vào bộ đệm
Các lời hứa do các phương thức waitFor*
trả về cho phép lưu dữ liệu vào bộ đệm khi JavaScript đang bận. Áp lực ngược được áp dụng cho phía gửi khi vùng đệm đọc đầy ở phía nhận. Bên gửi có vùng đệm ghi có thể lấp đầy khi áp dụng áp lực ngược, do đó, bên ghi cũng có phương thức waitForWriteBufferedAmountBelow
để cho phép chờ không gian trong vùng đệm để ghi. Bạn có thể tìm thêm thông tin về việc ghi/đọc dữ liệu trong tài liệu khác dành cho nhà phát triển.
Giao hàng không theo đơn đặt hàng/Không đáng tin cậy
Mặc dù RTCQuicStream
chỉ hỗ trợ gửi dữ liệu một cách đáng tin cậy và theo thứ tự, nhưng bạn có thể thực hiện việc phân phối không đáng tin cậy/không theo thứ tự thông qua các phương tiện khác. Đối với việc phân phối không theo thứ tự, bạn có thể gửi các phần dữ liệu nhỏ trên các luồng riêng biệt vì dữ liệu không được sắp xếp giữa các luồng. Đối với việc phân phối không đáng tin cậy, bạn có thể gửi các phần dữ liệu nhỏ với trạng thái hoàn tất được đặt thành true, sau đó gọi reset()
trên luồng sau khi hết thời gian chờ. Thời gian chờ phải phụ thuộc vào số lần truyền lại mong muốn trước khi loại bỏ dữ liệu.
Thời gian?
Bản dùng thử theo nguyên gốc sẽ bắt đầu trong phiên bản Chrome 73 và sẽ có sẵn cho đến phiên bản M75. Sau đó, bản dùng thử theo nguyên gốc sẽ kết thúc. Dựa trên ý kiến phản hồi và mức độ quan tâm, chúng tôi sẽ thực hiện các thay đổi thích hợp và phân phối API, tiếp tục thử nghiệm nguồn gốc mới của API này hoặc ngừng cung cấp API.
Ở đâu?
Trình duyệt Chrome trên tất cả nền tảng ngoại trừ iOS.
Còn gì nữa không?
Phản hồi
Một trong những mục tiêu chính của chương trình thử nghiệm theo nguồn gốc là nhận ý kiến phản hồi từ các nhà phát triển. Chúng tôi quan tâm đến:
- API này cho phép bạn làm gì?
- API này cải thiện như thế nào so với các API truyền dữ liệu khác (
WebSocket
hoặcRTCDataChannel
của WebRTC)? API này có thể cải thiện như thế nào? - Hiệu suất
- Khả năng thích ứng của API
Đăng ký bản dùng thử theo nguyên gốc
- Yêu cầu mã thông báo cho nguồn gốc của bạn.
- Thêm mã thông báo vào các trang của bạn. Có hai cách để cung cấp mã thông báo này trên bất kỳ trang nào trong nguồn gốc của bạn:
- Thêm thẻ
origin-trial
<meta>
vào đầu trang bất kỳ. Ví dụ: nội dung này có thể có dạng như sau:<meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
- Nếu có thể định cấu hình máy chủ, bạn cũng có thể cung cấp mã thông báo trên các trang bằng cách sử dụng tiêu đề HTTP
Origin-Trial
. Tiêu đề phản hồi thu được sẽ có dạng như sau:Origin-Trial: TOKEN_GOES_HERE
- Thêm thẻ
Quy cách web
Thông số kỹ thuật nháp đã đi trước API trong bản dùng thử theo nguyên gốc, bao gồm:
- Luồng một chiều phù hợp hơn với luồng WHATWG
- Tắt tính năng truyền lại
- (Sắp ra mắt) gói dữ liệu
Chúng tôi muốn triển khai toàn bộ thông số kỹ thuật và hơn thế nữa (bao gồm cả tính năng hỗ trợ luồng WHATWG), nhưng trước tiên, chúng tôi muốn nghe ý kiến phản hồi của bạn!
Bảo mật
Tính bảo mật trong quy trình bắt tay QUIC được thực thi thông qua việc sử dụng khoá được chia sẻ trước để thiết lập kết nối QUIC P2P được mã hoá. Khoá này cần được báo hiệu qua một kênh ngoài băng tần an toàn với các đảm bảo về tính bảo mật và tính toàn vẹn. Xin lưu ý rằng khoá sẽ được hiển thị cho JavaScript.
Tấn công chủ động
Không giống như DTLS-SRTP, chỉ yêu cầu tính toàn vẹn để báo hiệu vân tay số của chứng chỉ, việc báo hiệu khoá dùng chung trước cần có tính toàn vẹn và tính bảo mật. Nếu PSK bị xâm phạm (chẳng hạn như do máy chủ trong kênh báo hiệu), thì kẻ tấn công đang hoạt động có thể thực hiện một cuộc tấn công xen giữa đối với quy trình bắt tay QUIC.
Trạng thái hiện tại
Bước | Trạng thái |
---|---|
1. Tạo video giải thích | Hoàn tất |
**2a. Quy cách RTCQuicTransport ** | **Đang tiến hành** |
**2b. Quy cách RTCIceTransport ** | **Đang tiến hành** |
**3. Thu thập ý kiến phản hồi và lặp lại thiết kế** | **Đang tiến hành** |
4. Bản dùng thử theo nguyên gốc | Bắt đầu trong Chrome 73! |
5. Khởi chạy | Chưa bắt đầu |
Liên kết Hữu ích
- Tài liệu khác
- Video giải thích công khai
- Theo dõi lỗi
- Yêu cầu mã thông báo dùng thử nguồn gốc
- Cách sử dụng mã thông báo dùng thử gốc
- Thảo luận về các vấn đề của RTCQuicTransport
- Thảo luận về các vấn đề của RTCIceTransport