Contact emails

yhir...@chromium.org, vasi...@chromium.org

Explainer

https://github.com/w3c/webtransport/blob/main/explainer.md

Specification

https://w3c.github.io/webtransport

https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/

https://datatracker.ietf.org/doc/html/draft-ietf-quic-datagram/

Design docs

https://web.dev/webtransport/

https://docs.google.com/document/d/1UgviRBnZkMUq4OKcsAJvIQFX6UCXeCbOtX_wMgwD_es/edit

Summary

WebTransport is an interface representing a set of reliable/unreliable
streams to a server. The interface potentially supports multiple protocols,
but based on discussions on the IETF webtrans working group, we are
developing WebTransport over HTTP/3 which uses HTTP3 as the underlying
protocol.

This time, we want to ship the core part. The following features are
excluded:

   -

   Connection sharing
   -

   Stream Prioritization
   -

   Statistics
   -

   WebTransport over HTTP/2


Blink component

Blink>Network>WebTransport

TAG review

https://github.com/w3ctag/design-reviews/issues/669

TAG review status

Pending

Risks

Interoperability and Compatibility

This is a new API and doesn’t change any existing behaviors.

Gecko: Worth Prototyping
<https://github.com/mozilla/standards-positions/issues/167>. They are
actively involved in the specification effort.

WebKit: No signal
<https://lists.webkit.org/pipermail/webkit-dev/2021-September/031980.html>.

Web developers: Positive

Twitch

https://twitch.tv



Twitch is using WebTransport to serve live video to our users with lower
latency and higher quality. We plan on rolling out our new playback
experience once it's fully available given our positive results.



WebTransport offers all of the benefits of QUIC, but in a browser
environment and without the constraints of HTTP semantics. Most notably we
can push data over multiple streams, eliminating head-of-line blocking and
enabling new functionality during congestion. This is not possible with
existing browser standards such as WebSockets and WebRTC data channels.

Google Stadia

https://stadia.google.com/

“Google Stadia is using the WebTransport API in conjunction with the
WebCodecs API for several use cases, both internally and with partners. The
underlying WebTransport protocol, QUIC, has far greater throughput and
resiliency characteristics than other mechanisms available, which enables
use cases like webcams, and transmission of results of browser-based
processing to applications and games in the cloud. The capability to
transmit datagrams to cloud endpoints enables many new use cases for Stadia
including communication with custom hardware endpoints. In the future we
hope to explore using this API for other use cases.”

Ergonomics

The API is built around ReadableStream/WritableStream interfaces, which
means that its core I/O principles would be familiar to the developers who
had already used Streams via Fetch and other APIs.

The API does not use cookies, HTTP authentication or socket pooling.  This
would help us avoid unexpected interactions with the other elements of the
network stack.

Activation

Since UDP is often blocked on the network, the developers have to assume
that the API often would not work even in the situations when it is
implemented in the browser.

Security

See <https://wicg.github.io/web-transport/#privacy-security> for more info.



We allow web developers to use an alternative certification verification
method than the usual HTTPS way. We allow a web developer to connect to a
WebTransport over HTTP/3 server when its certificate’s fingerprint matches
with the developer provided fingerprint. This is discussed at
https://github.com/w3c/webtransport/issues/349 and we will update the spec
shortly.

Debuggability

Printing an error message with the reason when the opening handshake fails.

We show outgoing WebTransport sessions in the “Network” section of
DevTools, the same place where WebSocket connections are shown.  Unlike
WebSockets, we do not intend to show the actual contents of the
WebTransport sessions, thus avoiding the performance decrease that would
cause.

Just like with regular HTTP/3-based QUIC traffic, detailed information
about the connection can be obtained via chrome://net-export interface.

Is this feature fully tested by web-platform-tests?

Yes

We are writing WPTs (/webtransport
<https://wpt.fyi/results/webtransport?label=experimental&label=master&aligned>).
We expect the task to be completed by the branch point. The WebTransport
over HTTP/3 server for testing
<https://github.com/web-platform-tests/wpt/tree/master/tools/webtransport>
is running locally, but we need more time to run it on wpt.live or Chromium
CI.

Requires code in //chrome?

False

Tracking bug

https://crbug.com/10111392

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4854144902889472

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6HZaCbG_q8wVv0ukaGRwir-%2BVr0yQTGy3nXH0Qwa1fe%3Dg%40mail.gmail.com.

Reply via email to