3 ms·
Or they just optimistically connect to both TCP/443 and UDP/443, create both a HTTP/1 and HTTP/3 connection in parallel, then see which one responds quicker. T
by EwanToo 3y ago
Or they just optimistically connect to both TCP/443 and UDP/443, create both a HTTP/1 and HTTP/3 connection in parallel, then see which one responds quicker.
This already happens with some major apps.
- Matthias247 3y agoSome might indeed do. According to my knowledge from testing 1 year ago it's mostly Safari that is doing this. Other browsers follow the specification and require Alt-Svc information.
- EwanToo 3y agoI'm not sure the specification says what you describe, it doesn't in my reading. I don't believe Alt-Svc is required, and as you say Safari is behaving this way already. https://www.rfc-editor.org/rfc/rfc9114.html#section-3.1-3 https://www.rfc-editor.org/rfc/rfc9114.html#section-3.1-3 Discovering an HTTP/3 Endpoint A client MAY attempt access to a resource with an "https" URI by resolving the host identifier to an IP address, establishing a QUIC connection to that address on the indicated port (including validation of the server certificate as described above), and sending an HTTP/3 request message targeting the URI to the server over that secured connection. Unless some other mechanism is used to select HTTP/3, the token "h3" is used in the Application-Layer Protocol Negotiation (ALPN; see [RFC7301]) extension during the TLS handshake. Connectivity problems (e.g., blocking UDP) can result in a failure to establish a QUIC connection; clients SHOULD attempt to use TCP-based versions of HTTP in this case.
- Matthias247 3y agoThis seems correct. But as the spec says, some services might run HTTP/3 on a different port than 443 - e.g. for load balancing purposes. Those setups would fail if clients just try to connect to 443.