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 API nền tảng web mới cho phép trao đổi dữ liệu tuỳ ý với các ứng dụng 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 và do đó được dùng với một API RTCIceTransport độc lập để thiết lập kết nối ngang hàng thông qua ICE. Dữ liệu được truyền một cách đáng tin cậy và đúng thứ tự (xem phần dưới đây để biết thông tin chi tiết về hoạt động phân phối không theo thứ tự và không đáng tin cậy). Vì là phương thức truyền dữ liệu chung và hai chiều, nên bạn có thể dùng phương thức này để chơi trò chơi, truyền tệp, truyền nội dung nghe nhìn, nhắn tin, v.v.

Tại sao?

API truyền tải dữ liệu cấp thấp mạnh mẽ có thể cho phép các ứng dụng (như giao tiếp theo thời gian thực) làm những việc mới trên web. Bạn có thể xây dựng trên API, tạo các giải pháp riêng, mở rộng giới hạn của những việc có thể thực hiện bằng 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 cho nội dung nghe nhìn được mã hoá thậm chí có thể cho phép bạn tạo ứng dụng giao tiếp qua video của riêng mình với các chế độ điều khiển cấp thấp. NV của WebRTC là chuyển sang các API cấp thấp hơn và việc thử nghiệm sớm bằng cách này là rất có giá trị.

Vì sao nên chọn QUIC?

Giao thức QUIC được mong muốn cho việc giao tiếp theo thời gian thực. API 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 nghẽn và được ghép kênh mà không có phương thức chặn đầu dòng. RTCQuicTransport cung cấp các khả năng rất giống như API RTCDataChannel, nhưng sử dụng giao thức truyền tải QUIC thay vì SHST. Vì RTCQuicTransport là một API độc lập nên nó không có mức 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 có 3 thành phần trừu tượng chính là RTCIceTransport, RTCQuicTransport và RTCQuicStream.

Sơ đồ RTCQuicTransport thể hiện cấu trúc của API

RTCIceTransport

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

RTCQuicTransport

Đại diện cho kết nối QUIC. Hàm này dùng để thiết lập kết nối QUIC và tạo luồng QUIC. Tệp này 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 vào/từ phía từ xa. Các luồng truyền phát 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 ghi dữ liệu vào một luồng, dữ liệu sẽ kích hoạt sự kiện "onquicstream" trên truyền tải từ xa. Luồng cung cấp cách thức để phân biệt dữ liệu khác nhau trên cùng một kết nối QUIC. Một số 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 nhẹ, được ghép kênh qua kết nối QUIC và không gây ra hiện tượng chặn dòng tớ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 tín hiệu an toàn để thương lượng các tham số kết nối, bao gồm cả các thông số bảo mật của kênh đó. RTCIceTransport thương lượng các tham số ICE (ufrag và mật khẩu), cũng như RTCIceCandidate.

Sơ đồ RTCQuicTransport thể hiện 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);
  }
};

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 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 vào bộ đệm

Các 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 bận. Áp lực quay lại được áp dụng cho bên gửi khi vùng đệm đọc đầy ở bên 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 đợi khoảng trống trong vùng đệm ghi. Bạn có thể tìm thêm thông tin về cách ghi/đọc dữ liệu trong tài liệu bổ sung dành cho nhà phát triển.

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ự, 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 thức khác. Đối với phương thức phân phối không theo thứ tự, người dùng có thể gửi nhiều 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 theo thứ tự giữa các luồng. Để phân phối không đáng tin cậy, người dùng có thể gửi các phần dữ liệu nhỏ với kết thúc đượ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ụ thuộc vào số lượt truyền lại mong muốn trước khi xoá dữ liệu.

Khoảng thời gian đó là khi nào?

Bản dùng thử theo nguyên gốc sẽ bắt đầu trong phiên bản Chrome 73 và sẽ được cung cấp cho đến phiên bản M75 và bao gồm cả 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ối quan tâm, chúng tôi sẽ thực hiện các thay đổi 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 tất cả các nền tảng trừ iOS.

Còn gì nữa?

Ý kiến 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 ý kiến phản hồi của các nhà phát triển – bạn. Chúng tôi quan tâm đến:

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

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

  1. Yêu cầu mã thông báo cho nguồn gốc của bạn.
  2. 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 mọi trang trong nguồn gốc của bạn:
    • Thêm thẻ origin-trial <meta> vào đầu của một 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ủ của mình, thì 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

Quy cách web

Thông số kỹ thuật của bản nháp đã được chuyển lên trước API trong bản dùng thử theo nguyên gốc, bao gồm:

  • Luồng một chiều và được điều chỉnh cho 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à hơn thế nữa (bao gồm cả hỗ trợ phát trực tiếp whatWG), nhưng muốn nghe ý kiến phản hồi của bạn trước!

Bảo mật

Tính bảo mật trong cơ chế bắt tay QUIC được thực thi thông qua việc sử dụng một khoá dùng chung sẵn có để thiết lập kết nối P2P QUIC đã mã hoá. Khoá này cần được phát tín hiệu qua một kênh bảo mật bên ngoài băng tần với sự đả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ẽ cho phép JavaScript hiển thị.

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á được chia sẻ trước đòi hỏi tính toàn vẹn và 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ó khả năng thực hiện cuộc tấn công xen giữa để chống lại cơ chế bắt tay QUIC.

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

Bước Trạng thái
1. Tạo nội dung 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à cải thiện 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

Các Liên kết Hữu dụng