Intent to Implement: QuicTransport
Victor Vasiliev
Contact emails
yhi...@chromium.org, vas...@chromium.org
Explainer
https://github.com/WICG/web-transport/blob/master/explainer.md
Design doc/Spec
Spec: https://wicg.github.io/web-transport/
Design doc: https://docs.google.com/document/d/1UgviRBnZkMUq4OKcsAJvIQFX6UCXeCbOtX_wMgwD_es/edit
TAG review: https://github.com/w3ctag/design-reviews/issues/389
Summary
QuicTransport is an API that allows Web applications to connect directly to remote servers using QUIC. It is a part of the WebTransport framework; Http3Transport and FallbackTransport are not covered by this Intent.
Motivation
Currently, Web application developers have two APIs for bidirectional communications with a remote server: WebSockets and RTCDataChannel. WebSockets are TCP-based, thus having all of the drawbacks of TCP that make it a poor fit for latency sensitive applications (head of line blocking, lack of support for unreliable data transport). RTCDataChannel is based on SCTP, which does not have these drawbacks; however, it is designed to be used in a peer-to-peer context, which caused its use in client-server settings to be fairly low. QuicTransport provides a client-server API that supports bidirectional transfer of both unreliable and reliable data, using UDP-like datagrams and cancellable streams.
Risks
Interoperability and Compatibility
The main compatibility risk would be the lack of support in other browsers. We’ve been in contact with other browser vendors and incorporated some of the feedback we’ve received so far into our design. We are thus optimistic, though of course the outcome is hard to predict before the origin trial.
Edge: Positive signals (co-editing the spec)
Firefox: No signals (positive reception during dispatch, but no official position yet)
Safari: No signals
Web / Framework developers: some opinions can be seen at WICG discourse.
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. WebTransport solves this problem by providing FallbackTransport, a WebSocket-based polyfill that is interchangeable with QuicTransport on the API level; developers can manually switch transports as they see fit.
Debuggability
The current plan is to show outgoing QuicTransport connections 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 QuicTransport sessions, thus avoiding the performance decrease that would cause.
Just like with regular HTTP/3-based QUIC traffic, the detailed information about the connection can be obtained via chrome://net-export interface.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Link to entry on the feature dashboard
https://www.chromestatus.com/feature/4854144902889472
Requesting approval to ship?
No.
Emily Stark
Victor Vasiliev
A couple questions from reviewing https://wicg.github.io/web-transport/#privacy-security:- The spec says "In WebTransport, certificate verification errors are fatal; no interstitial allowing bypassing certificate validation is available." This sounds potentially tricky to implement in Chrome because if a user has previously bypassed a certificate error for a host, the decision is currently cached based on the host alone (not the port). If this is the desired behavior, please make sure you test for it specifically, including the scenario where the user has previously clicked through a certificate error on the same host.
- "All transports must allow the server to filter connections based on the origin of the resource originating the transport session." => Should that be the "origin of the document/worker" rather than "origin of the resource"? "Origin of the resource" is a little confusing because if a.com includes a script from b.com that initiates the transport session, I assume the origin exposed to the server will be a.com, not b.com (which is what I'd call the "origin of the resource").
- In https://tools.ietf.org/html/draft-vvv-webtransport-quic-00#section-7, it seems like there are some words missing in this sentence: "In order to avoid the use of QuicTransport, the user agents MUST NOT allow the clients..."- It would be helpful if https://tools.ietf.org/html/draft-vvv-webtransport-quic-00#section-7 addressed the "consent freshness" property mentioned in https://wicg.github.io/web-transport/#protocol-security explicitly.
Please make sure this feature goes through internal security/privacy review before it ships to beta. Thanks!
Kinuko Yasuda
--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAZdMafW4uoh%3DZ9h-V-NjpSFj0JgPZ_i%2BcfdTms3-hB2MnPRrQ%40mail.gmail.com.