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 .

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 предварительного общего ключа. В настоящее время мы не планируем оставлять этот API после первоначальной пробной версии. Он будет заменен сигнализацией отпечатков пальцев удаленного сертификата для проверки самозаверяющих сертификатов, используемых при рукопожатии, как только эта поддержка будет добавлена ​​в QUIC в Chromium.

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

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. Запуск	Не начался

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

• Дополнительная документация
• Публичный объяснитель
• Ошибка отслеживания
• Запросить пробный токен источника
• Как использовать пробный токен происхождения
• Обсуждение вопросов для RTCQuicTransport
• Обсуждение вопросов для RTCiceTransport