RTCQuicTransport sắp ra mắt bản dùng thử gốc ở gần bạn (Chrome 73)

Gì cơ?

RTCQuicTransport là một nền tảng web mới API cho phép trao đổi dữ liệu tuỳ ý với các ứng dụng ngang hàng từ xa bằng QUIC giao thức. Lớp học này dành cho các trường hợp sử dụng ngang hàng, do đó được dùng với một RTCIceTransport độc lập API để thiết lập kết nối ngang hàng thông qua ICE. Dữ liệu được truyền tải một cách đáng tin cậy và theo thứ tự (xem phần dưới đây để biết thông tin chi tiết về sản phẩm chưa được đặt hàng phân phối không đáng tin cậy). Vì đây là quy tắc chung, truyền dữ liệu hai chiều, có thể dùng để chơi trò chơi, truyền tệp, truyền thông đa phương tiện, nhắn tin, v.v.

Tại sao?

API truyền dữ liệu cấp thấp mạnh mẽ có thể hỗ trợ các ứng dụng (như theo thời gian thực thông tin) để làm những việc mới trên web. Bạn có thể tạo dựa trên API, tạo ra giải pháp của riêng bạn, vượt qua giới hạn những gì có thể làm với các nhà sáng tạo khác đến các kết nối ngang hàng, chẳng hạn như mở khoá nút phân bổ tốc độ bit tuỳ chỉnh. Trong trong tương lai, hỗ trợ thêm cho phương tiện được mã hoá thậm chí có thể cho phép tạo của riêng bạn về ứng dụng giao tiếp qua video với các nút điều khiển cấp thấp. NV của WebRTC là chuyển sang API cấp thấp hơn và thử nghiệm sớm với điều này có giá trị.

Tại sao nên sử dụng QUIC?

Giao thức QUIC được mong muốn cho giao tiếp trong thời gian thực. Nền tảng này được xây dựng ở trên cùng của UDP, được tích hợp sẵn tính năng mã hoá, kiểm soát tắc nghẽn và được ghép kênh mà không cần chặn đầu dòng. RTCQuicTransport có những khả năng tương tự như API RTCDataChannel, nhưng sử dụng QUIC thay vì SCTP làm truyền tải giao thức. Vì RTCQuicTransport là một API độc lập nên không có mức hao tổn của API RTCPeerConnection, bao gồm cả phương tiện truyền thông theo thời gian thực ngăn xếp.

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.

Sơ đồ RTCQuicTransport cho thấy cấu trúc của API

RTCIceTransport

ICE là một giao thức dùng để 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. được dùng làm phương tiện truyền tải gói tin cho kết nối QUIC và RTCQuicTransport đưa hàm này vào hàm khởi tạo.

RTCQuicTransport

Đại diện cho kết nối QUIC. Nó được dùng để thiết lập kết nối QUIC và tạo luồng QUIC. Thẻ này cũng hiển thị số liệu thống kê liên quan cho kết nối QUIC cấp độ.

RTCQuicStream

Dùng để đọc và ghi dữ liệu đến/từ xa. Truyền tải luồng dữ liệu một cách đáng tin cậy và theo thứ tự. Bạn có thể tạo nhiều sự kiện phát trực tiếp từ cùng một sự kiện phát trực tiếp RTCQuicTransport và sau khi dữ liệu được ghi vào một luồng, nó sẽ kích hoạt sự kiện "onquicstream" trên truyền tải từ xa. Luồng là 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. Sau đây là một số ví dụ phổ biến: gửi các tệp riêng biệt trên các luồng riêng biệt, các phần dữ liệu nhỏ trên nhiều 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 ghép kênh qua kết nối QUIC và không khiến dòng tiêu đề bị chặn đố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 kênh báo hiệu an toàn để thương lượng các tham số của kết nối, bao gồm cả các thông số bảo mật. RTCIceTransport thương lượng với ICE tham số (ufrag và mật khẩu), cũng như RTCIceCandidate.

Sơ đồ RTCQuicTransport cho thấy cấu trúc của API

Quan điểm của khách hà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);
  }
};

Góc nhìn 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

Việc chuyển dữ liệu có thể đạt được bằng cách sử dụng các API RTCQuicStream để đọc và viết:

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

Lời hứa mà 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 bộ đệm đọc bị đầy ở bên nhận. Bên gửi có ghi bộ đệm có thể lấp đầy khi áp lực ngược được áp dụng và do đó phía ghi cũng có phương thức waitForWriteBufferedAmountBelow để cho phép chờ có chỗ trong bộ đệm để ghi. Xem thêm thông tin về hoạt động ghi/đọc dữ liệu trong tài liệu.

Giao hàng không theo thứ tự/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ự, việc phân phối không đáng tin cậy/không theo thứ tự có thể đạt được thông qua các phương tiện khác. Cho phân phối không theo thứ tự, người dùng 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 dịch vụ giao hàng không đáng tin cậy, hãy có thể gửi các phần dữ liệu nhỏ với kết thúc được thiết lập là 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ượt truyền lại mong muốn trước khi xoá 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 lên đến và bao gồm cả phiên bản M75. Sau ngày này, 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ối quan tâm của người dùng, chúng tôi sẽ thay đổi cho phù hợp và gửi API, tiếp tục với bản dùng thử theo nguyê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 mọi nền tảng, trừ iOS.

Còn gì nữa?

Phản hồi

Một trong những mục tiêu chính của bản dùng thử theo nguyên gốc là nhận phản hồi của bạn, các nhà phát triển. Chúng tôi quan tâm đến:

  • API này mang đến lợi ích gì cho bạn?
  • API này cải thiện như thế nào so với các API truyền dữ liệu khác (RTCDataChannel của WebRTC hoặc WebSocket)? Bạn cần cải thiện những điểm nào?
  • Hiệu suất
  • Công thái học API

Đăng ký bản dùng thử theo nguyên gốc

  1. Yêu cầu một mã thông báo cho máy chủ gốc của bạn.
  2. Thêm mã thông báo vào các trang của bạn. Bạn có 2 cách để cung cấp mã thông báo này bất kỳ trang nào trong máy chủ gốc của bạn:
    • Thêm một thẻ origin-trial <meta> vào phần đầu của một trang bất kỳ. Ví dụ: đoạn mã 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 tiêu đề HTTP Origin-Trial. Tiêu đề phản hồi thu được sẽ sẽ có dạng như sau: Origin-Trial: TOKEN_GOES_HERE

Thông số kỹ thuật của trang web

Thông số kỹ thuật dự thảo đã vượt 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
  • Gói dữ liệu (Sắp ra mắt)

Chúng tôi quan tâm đến việc triển khai quy cách đầy đủ và các mục khác (bao gồm hỗ trợ luồng whatWG), nhưng chúng tôi muốn nghe ý kiến phản hồi của bạn trước!

Bảo mật

Bảo mật trong cơ chế bắt tay QUIC được thực thi thông qua việc sử dụng khoá dùng chung để thiết lập kết nối P2P QUIC đã mã hoá. Khoá này cần được báo hiệu qua một kênh an toàn ngoài phạm vi 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á này sẽ hiển thị với 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 chứng chỉ vân tay số, báo hiệu khoá được chia sẻ trước đòi hỏi tính toàn vẹn và tính bí mật. Nếu PSK bị xâm phạm (thông báo của máy chủ trong tín hiệu) một kẻ tấn công đang hoạt động có thể thực hiện cuộc tấn công xen giữa so với cơ chế bắt tay QUIC.

Trạng thái hiện tại

Bước Trạng thái
1. Tạo thông báo giải thích Hoàn tất
**2a. Thông số kỹ thuật RTCQuicTransport ** **Đang tiến hành**
**2b. Thông số kỹ thuật 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 Not started

Liên kết Hữu ích