RTCQuicTransport появится в пробной версии Origin рядом с вами (Chrome 73)

Что?

RTCQuicTransport — это новый API веб-платформы, который позволяет обмениваться произвольными данными с удаленными узлами с использованием протокола QUIC. Он предназначен для одноранговых вариантов использования и поэтому используется с автономным API RTCIceTransport для установления однорангового соединения через ICE . Данные передаются надежно и в порядке (подробную информацию о неупорядоченной и ненадежной доставке см. в разделе ниже). Поскольку это универсальный двунаправленный транспорт данных, его можно использовать для игр, передачи файлов, передачи мультимедиа, обмена сообщениями и т. д.

Почему?

Мощный низкоуровневый API-интерфейс передачи данных может позволить приложениям (например, средствам связи в реальном времени) выполнять новые действия в Интернете. Вы можете использовать API, создавая свои собственные решения, расширяя границы того, что можно сделать с одноранговыми соединениями, например, разблокируя пользовательские ручки распределения битрейта. В будущем дальнейшая поддержка закодированных мультимедиа может даже позволить создать собственное приложение для видеосвязи с элементами управления низкого уровня. Усилия WebRTC NV направлены на переход к API более низкого уровня, и раннее экспериментирование с этим имеет ценность.

Почему QUIC?

Протокол QUIC желателен для связи в реальном времени. Он построен на основе UDP, имеет встроенное шифрование, контроль перегрузки и мультиплексируется без блокировки начала линии. RTCQuicTransport предоставляет очень схожие возможности с API RTCDataChannel , но в качестве транспортного протокола использует QUIC, а не SCTP. Поскольку RTCQuicTransport является автономным API, он не требует дополнительных затрат API RTCPeerConnection , который включает в себя стек мультимедиа реального времени.

Как?

Общий обзор API

API имеет три основные абстракции: RTCIceTransport , RTCQuicTransport и RTCQuicStream .

Диаграмма RTCQuicTransport, показывающая архитектуру API

RTCIceTransport

ICE — это протокол для установления одноранговых соединений через Интернет, который сегодня используется в WebRTC. Этот объект предоставляет автономный API для установки соединения ICE. Он используется в качестве транспорта пакетов для соединения QUIC, а RTCQuicTransport принимает его в своем конструкторе.

RTCQuicTransport

Представляет соединение QUIC. Он используется для установления соединения QUIC и создания потоков QUIC. Он также предоставляет соответствующую статистику для уровня соединения QUIC.

RTCQuicStream

Используется для чтения и записи данных на/с удаленной стороны. Потоки передают данные надежно и в порядке. Несколько потоков могут быть созданы из одного и того же RTCQuicTransport , и как только данные записываются в поток, он запускает событие «onquicstream» на удаленном транспорте. Потоки позволяют различать разные данные в одном и том же соединении QUIC. Типичными примерами могут быть отправка отдельных файлов в отдельные потоки, небольшие фрагменты данных в разные потоки или разные типы мультимедиа в отдельные потоки. RTCQuicStream являются облегченными, мультиплексируются по соединению QUIC и не вызывают блокировку начала линии для других RTCQuicStream .

Настройка подключения

Ниже приведен пример настройки однорангового соединения QUIC. Как и RTCPeerConnection , API RTCQuicTransport требует использования безопасного канала сигнализации для согласования параметров соединения, включая его параметры безопасности. RTCIceTransport согласовывает свои параметры ICE (ufrag и пароль), а также RTCIceCandidate s.

Диаграмма RTCQuicTransport, показывающая архитектуру API

Взгляд клиента: 

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);
  }
};

Передача данных

Передачу данных можно осуществить с помощью API-интерфейсов RTCQuicStream для чтения и записи:

RTCQuicStreamReadResult readInto(Uint8Array data);
void write(RTCQuicStreamWriteParameters data);
Promise<void> waitForWriteBufferedAmountBelow(unsigned long amount);
Promise<void> waitForReadable(unsigned long amount);

Буферизация

Промисы, возвращаемые методами waitFor* , позволяют буферизовать данные, когда JavaScript занят. Обратное давление применяется к стороне отправки, когда буфер чтения заполняется на стороне приема. Сторона отправки имеет буфер записи, который может заполняться при приложении обратного давления, и поэтому сторона записи также имеет метод waitForWriteBufferedAmountBelow , позволяющий ожидать освобождения места в буфере для записи. Более подробную информацию о записи/чтении данных можно найти в дальнейшей документации разработчика.

Незаказированная/ненадежная доставка

Хотя RTCQuicStream поддерживает только надежную и упорядоченную отправку данных, ненадежная/неупорядоченная доставка может быть достигнута другими способами. Для неупорядоченной доставки можно отправлять небольшие порции данных в отдельных потоках, поскольку данные не упорядочены между потоками. Для ненадежной доставки можно отправлять небольшие порции данных с параметром Finish, установленным в true, с последующим вызовом функции reset() в потоке после тайм-аута. Тайм-аут должен зависеть от того, сколько повторных передач требуется перед удалением данных.

Когда?

Пробная версия Origin начнется с версии Chrome 73 и будет доступна до версии M75 включительно. После этого испытание происхождения завершится. На основании отзывов и интереса мы внесем соответствующие изменения и либо выпустим API, либо продолжим пробную версию этого API в новом источнике, либо прекратим поддержку API.

Где?

Браузер Chrome на всех платформах, кроме iOS.

Что еще?

Обратная связь

Одна из основных целей пробной версии Origin — получить отзывы от вас, разработчиков. Нас интересует:

  • Что этот API дает вам?
  • Чем этот API улучшает другие API-интерфейсы передачи данных ( WebSocket или RTCDataChannel WebRTC)? Как это могло улучшиться?
  • Производительность
  • API эргономика

Зарегистрируйтесь для участия в пробной версии Origin

  1. Запросите токен для вашего происхождения.
  2. Добавьте токен на свои страницы. Есть два способа разместить этот токен на любых страницах вашего источника:
    • Добавьте тег <meta> origin-trial в заголовок любой страницы. Например, это может выглядеть примерно так: <meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
    • Если вы можете настроить свой сервер, вы также можете предоставить токен на страницах, используя HTTP-заголовок Origin-Trial . Результирующий заголовок ответа должен выглядеть примерно так: Origin-Trial: TOKEN_GOES_HERE

Веб-спецификация

Проект спецификации опередил API в исходной пробной версии, включая:

  • Однонаправленные потоки, которые более тесно связаны с потоками WHATWG.
  • Отключение повторной передачи
  • (Скоро) датаграммы

Мы заинтересованы в реализации полной спецификации и не только (включая поддержку потоков WHATWG), но сначала хотим услышать ваши отзывы!

Безопасность

Безопасность при подтверждении связи QUIC обеспечивается за счет использования предварительного общего ключа для установки зашифрованного P2P-соединения QUIC. Этот ключ должен передаваться по защищенному внешнему каналу с гарантиями конфиденциальности и целостности. Обратите внимание, что ключ будет доступен JavaScript.

Активная атака

В отличие от DTLS-SRTP, которому для передачи отпечатка сертификата требуется только целостность, для сигнализации предварительного общего ключа требуется целостность и конфиденциальность. Если PSK скомпрометирован (скажем, сервером в сигнальном канале), активный злоумышленник потенциально может организовать атаку «человек посередине» против подтверждения связи QUIC.

Текущий статус

Шаг Статус
1. Создайте объяснитель Полный
**2а. Спецификация RTCQuicTransport ** **В ходе выполнения**
**2б. Спецификация RTCiceTransport ** **В ходе выполнения**
**3. Собирайте отзывы и дорабатывайте дизайн** **В ходе выполнения**
4. Пробная версия происхождения Запускается в Chrome 73!
5. Запуск Не запущено

Полезные ссылки