About HTTP/3.0 - Browser behavior

HTTP has evolved over the years, from the original version HTTP/0.9 to the current standard HTTP/2. However, HTTP/2 still has some limitations and challenges, such as head-of-line blocking, TCP inefficiency, and encryption overhead. To address these issues, a new version of HTTP, called HTTP/3, has been developed.

Benefits of HTTP/3

HTTP/3 offers several benefits over HTTP/2, especially in terms of performance, security, and flexibility. Some of the main advantages are:

  • Reduced latency: HTTP/3 eliminates head-of-line blocking, reduces connection establishment time, and improves congestion control and loss recovery, resulting in lower latency and faster page load times.
  • Improved security: HTTP/3 encrypts all data by default, using the Transport Layer Security (TLS) 1.3 protocol, which provides stronger encryption and authentication than previous versions.
  • Better mobility: HTTP/3 supports connection migration, which allows clients and servers to maintain a connection even when they change their network interface or IP address, such as when switching from Wi-Fi to cellular.
  • More robustness: HTTP/3 is more resilient to packet loss, network fluctuations, and middlebox interference, thanks to the use of UDP, QUIC, and QPACK.
  • More flexibility: HTTP/3 is more extensible and adaptable, thanks to the use of greasing, datagrams, and other mechanisms that allow for future innovation and experimentation.

One of the main challenges of enabling HTTP/3 is how to negotiate the protocol version between clients and servers. This is because HTTP/3 requires the use of QUIC, which runs over UDP, while previous versions of HTTP run over TCP. To address this issue, HTTP/3 uses two different methods of negotiation, depending on whether the HTTP traffic is encrypted (HTTPS) or unencrypted (HTTP).

  • ALPN method: For HTTPS, HTTP/3 uses a mechanism called Application-Layer Protocol Negotiation (ALPN), which allows the client and the server to indicate their supported protocols during the TLS handshake. The client initiates a QUIC connection to the server and sends a list of ALPN identifiers in its ClientHello message, including "h3" for HTTP/3. The server responds with its ServerHello message, which contains the selected ALPN identifier, either "h3" or another protocol. If the server chooses "h3", the client and the server proceed with the HTTP/3 communication over the established QUIC connection. If the server chooses another protocol, such as "h2" for HTTP/2, the client and the server switch to a TCP connection and use the selected protocol. Also, if the server does not respond too, then the client switches to TCP connection to move forward with either HTTP/2 or HTTP/1.1.
  • Alt-Svc method: For HTTP, HTTP/3 uses a mechanism called HTTP Alternative Services (Alt-Svc), which allows the server to advertise its support for alternative protocols and hosts. The server sends an Alt-Svc header in its HTTP response, which contains information such as the protocol identifier, the host name, and the port number for the alternative service. For example, the server may send "Alt-Svc: h3=":443" to indicate that it supports HTTP/3 on the same host and port as the original request. The client can then use this information to initiate a new QUIC connection to the server and use HTTP/3 for subsequent requests. Alternatively, the server may use an HTTP/2 extension frame called ALTSVC to convey the same information as the Alt-Svc header.

That said, many browsers don't yet support the ALPN method. This is because many web servers are not HTTP/3 ready. Using the ALPN method can introduce delays to HTTP transactions due to waiting for timeouts to occur before HTTP/2 or 1.1 connections start. Due to this, the Alt-svc method is used, even for HTTPS. That is, browsers (clients) start with TCP, and when they learn that servers support HTTP/3, future requests use HTTP/3 for those domains. Browsers tend to cache this information and keep those entries in the cache up to the max-age proposed by servers. Some browsers may have their own limits on the time for the cache entries.


If the likelihood of vulnerabilities is proportional to complexity, don’t you worry that http/3 is (for all its proclaimed security features) unsecurable on a practical level? Also, has the web finally decided that its key protocol should be beyond the implementation reach of constrained clients? (Full disclosure: I’ve been for some time lamenting the simplicity-is-bad mentality that seems to plague web protocols in general and TLS1.3 in particular. Perhaps I’m not giving http/3 a fair shake.) A lot of layers squeezed into one and a lot of obsession about latency (rather than, say, fixing the insanity of redirect-based flows) and multiplexing seems to drowned out other concerns.

I like the Mobility aspects of HTTP/3.

要查看或添加评论,请登录

社区洞察

其他会员也浏览了