FE.BASE-HTTP3 knowledge notes

Although HTTP/3 does have some promising new concepts, unfortunately, their impact on most web pages and users may be relatively limited (but may be critical for a small number). HTTP/3 is also very challenging to set up and use (correctly), so be careful when configuring new protocols.

Part 1: HTTP/3 history and core concepts

Misunderstandings of http2\expectations that cannot be implemented

• sever push does not work in practice
• data flow and priority are often not
• In some cases (reduced) resource package size or even fragment is still a good practice
• Other mechanisms to adjust protocol behavior, such as preload , usually include hide , making them difficult to use correctly. (Concept supplement preload and prefetch )

(Comparison between HTTP/2 and HTTP/3 protocol stacks)
Protocol layering is for reuse, in which TCP protocol ensures complete transmission. The QUIC ( https://www.rfc-editor.org/rfc/rfc9000.html) protocol was TCP did not really consider the maximum efficiency.

• TCP requires a "handshake", and each round-trip time (RTT) may take more than 100 milliseconds, causing significant delays
• TCP treats all the data it transmits as a single "file" or byte stream, and there will be header of line (HoL) blocking (If a file TCP packet is lost, then all other files will also be delayed until these data packets are restored.)

basic concepts

It is very difficult to optimize directly in HTTP/2, so we reimagined and implemented a more advanced version of TCP and called it QUIC. Because we want to make QUIC easier to deploy, we run it via UDP.

We are excited about the main features of HTTP/3 (faster connection settings, less HoL blocking, connection migration, etc.), which actually come from QUIC.

QUIC uses UDP, so HTTP/3 is designed mainly because it makes them easier to deploy, because UDP is known and implemented by almost all devices on the Internet.

On top of UDP, QUIC basically re-implements the functions of TCP. QUIC is absolutely reliable. It uses to retransmit acknowledgments of received packets and to ensure that the lost packet still arrives. QUIC also establishes a connection and has a highly complex handshake .

QUIC also uses the so-called flow control and congestion control mechanism to prevent the sender or receiver from overloading, but this also makes TCP slower than the original UDP.

(TLS, TCP and QUIC handshake duration)

Given this apparent evolution to always-on TLS (especially network traffic), it is not surprising that the designers of QUIC decided to take this trend to a new level. They did not simply define a plaintext mode for HTTP/3, but chose to deeply root encryption in QUIC itself, which broke the typical clear separation between protocols in the protocol stack.

(Unlike TCP + TLS, QUIC also encrypts its transport layer metadata in the packet header and payload.)

Pros and cons

Advantages

• QUIC is more secure for its users.

  There is no way to run plaintext QUIC, so attackers and eavesdroppers have fewer options for monitoring. (Recent research shows how dangerous the plaintext option of .)

• QUIC's connection establishment is faster.

  For TLS-over-TCP, both protocols need their own separate handshake, while QUIC combines the transmission and encryption handshake into one, saving round trips (see the figure above).

• QUIC can evolve more easily.

  Because it is completely encrypted, the middleware in the network can no longer observe and explain its internal working principles like using TCP. Therefore, they will not be (unexpectedly) interrupted in newer versions of QUIC due to update failures. If we want to add new features to QUIC in the future, we "only need" to update the terminal equipment, not all middleware.

Disadvantages

• Many networks hesitate to allow QUIC.

  Companies may want to block it on their firewalls because it becomes more difficult to detect unwanted traffic. ISPs and intermediate networks may prevent it because metrics such as average delay and packet loss percentage are no longer easily available, making it more difficult to detect and diagnose problems. All this means that QUIC may never be universally available.

• QUIC has higher encryption overhead.

  QUIC uses TLS to encrypt each individual data packet, while TLS-over-TCP can encrypt multiple data packets at the same time. For high throughput scenarios, this may make QUIC slower.

• QUIC makes the network more centralized.
  The complaint I often encounter is, "Google is pushing QUIC because it gives them full access to data without sharing any data with others." I mostly disagree with this. First, compared to TLS-over-TCP, QUIC does not hide more (or less!) user-level information (for example, which URLs you are visiting) from external observers (QUIC keeps the status quo).

characteristic

solves HoL blocking

Solving the HoL congestion at the transport layer is one of the main goals of QUIC. Unlike TCP, QUIC is very aware that it is multiplexing multiple independent byte streams.

(QUIC allows HTTP/3 to bypass the head-of-line blocking problem.)

QUIC supports connection migration

There is no mechanism under the TCP protocol to allow the client to let the server know that it has changed the IP, so every network change means that the existing TCP connection can no longer be used. Restarting the TCP connection will have serious effects (waiting for a new handshake, restarting the download, re-establishing the context).

To solve this problem, QUIC introduced a new concept called connection identifier (CID). Each connection is assigned another number at the top of the 4-tuple to uniquely identify it between the two endpoints. To prevent tracking, QUIC changes the CID every time a new network is used.

(QUIC uses multiple negotiated connection identifiers (CIDs) to prevent user tracking)

In TCP, the connection is defined by four parameters (client IP address + client port + server IP address + server port). When the endpoint changes the network, these parameters will change. Therefore, it is sometimes necessary to restart these connections, which leads to downtime. QUIC adds another parameter to the mix called connection ID . Both the QUIC client and server know which connection ID maps to which connection, so it is more robust to network changes.

QUIC is flexible and expandable

1. The fact that QUIC is almost completely encrypted means that if we want to deploy a newer version of QUIC, we only need to update the endpoints (client and server), not all middleware.
2. QUIC does not use a single fixed packet header to send all protocol metadata. In contrast, QUIC has a shorter packet header and uses various "frames" (similar to tiny private packets) within the packet payload to convey additional information. For example, there is an ACK frame (used to confirm), a NEW_CONNECTION_ID frame (used to help establish connection migration), and a STREAM frame (used to carry data), as shown in the following figure.
3. QUIC uses custom TLS extensions to carry so-called transmission parameters. These allow the client and server to choose the configuration for the QUIC connection. This means they can negotiate which features are enabled (for example, whether connection migration is allowed, which extensions are supported, etc.) and communicate reasonable default values for certain mechanisms (for example, the maximum supported packet size, flow control limits).
4. Most implementations are currently done in "user mode" (unlike TCP, which is usually done in "kernel mode").

Although QUIC is now standardized, it should indeed be regarded as QUIC 1, with a clear intention to create version 2 and faster.

Part 2: HTTP/3 performance characteristics

QUIC and HTTP/3 do have huge web performance potential, but mainly used for users on slow networks. If your regular visitors are using fast wired or cellular networks, they may not benefit much from the new agreement.

Congestion control

One aspect of performance is about how efficiently the transport protocol uses the entire (physical) bandwidth of the network (that is, roughly how many packets can be sent or received per second). This in turn will affect the download speed of page resources. Some people claim that QUIC is better than TCP to some extent, but this is not the case.

The connection does not know how much bandwidth it can use in advance safely or fairly, and the bandwidth will change as users join, leave, and use the network. To solve this problem, TCP will continuously try to discover the available bandwidth by using a mechanism called congestion control.

(Simplified example of TCP congestion control, starting with a sending rate of 10 packets)

Although TCP congestion control make it sound, but it also implies the need for some time to achieve optimal transmission rate , depending on RTT and the actual available bandwidth. For web page loading, this slow start method also affects indicators such as FCP (First Content Draw), because only a small amount of data (tens to hundreds of KB) can be transferred in the first few round trips.

It is not that QUIC does not use congestion control, but actually uses bandwidth management techniques very similar to TCP. It also starts with a lower sending rate and grows over time, using confirmation as a key mechanism for measuring network capacity. Congestion control algorithms are still developing vigorously today. For example, we may need adjust something to take full advantage of 5G .

QUIC's delayed confirmation frequency extension proposal

Although by default QUIC sends an acknowledgement every 2 packets it receives, this extension allows the endpoint to acknowledge, for example, every 10 packets. This has been proven to bring great speed advantages to satellites and very high-bandwidth networks, because the overhead of transmitting confirmation packets is reduced. Adding such extensions to TCP takes a long time to be adopted, and for QUIC, it is much easier to deploy.

Congestion control algorithms are not specific to TCP or QUIC ; they can be used by any protocol, in fact, most production-level QUIC implementations have custom implementations Cubic and BBR

0-RTT connection settings

Because TCP is designed to be used without relying on TLS, it does not support sending non-TCP content during the handshake. requires at least two round-trip handshake waiting time overhead for before we can send the first HTTP request, which is inefficient.

QUIC has considered TLS from the beginning, so it combines transmission and encryption handshake in a single mechanism. This means that the QUIC handshake only needs one round trip in total, which is one less round trip than TCP + TLS 1.3.

(TCP + TLS and QUIC connection settings)

Although in the worst case (TCP + TLS 1.2, (a)) QUIC is two or even three round trips faster than TCP, but modern TCP + TLS 1.3 also "only" performs two round trips (rarely shown (b))

Session resumption and 0-RTT are often misinterpreted as QUIC specific functions. In fact, these are actually TLS functions. They have appeared in TLS 1.2 in some form and are now fully mature TLS 1.3

QUIC's faster connection setting using 0-RTT is actually more of a micro-optimization, rather than a revolutionary new feature. Compared with the most advanced TCP + TLS 1.3 settings, it can save up to one round trip. The actual amount of data that can be sent in the first round trip is also limited by many security considerations. Therefore, if your users use a network with very high latency (for example, a satellite network with an RTT of more than 200 milliseconds), or you usually don't send large amounts of data, this feature will shine. In other cases, you can only get tens of milliseconds at most, or even less if you are already using CDN.

UDP and TLS performance
QUIC uses UDP and heavy encryption to make it a bit slower than TCP (but the situation is improving) because TCP and UDP are usually implemented directly in the OS" fast kernel. In contrast, TLS and QUIC are mostly implemented by slower users In space.

(Implementation differences between TCP and QUIC)
For TCP, these overheads are much lower than UDP, mainly because historically, TCP has been used much more than UDP. But over the past five years, most operating systems add optimization options for the UDP .

Second, QUIC has a lot of overhead because it encrypts each packet individually. In practice, optimized encryption library and a clever method that allows bulk encryption of QUIC packet headers. Recently, Google QUIC stack optimized version of the current than TCP + TLS slow about% 20 .

Part 3: Practical HTTP/3 deployment options

Changes to pages and resources

If you are already using HTTP/2, you may not need to make any changes to pages or resources when migrating to HTTP/3!

Server and network

These implementations mainly deal with HTTP/3 and QUIC things; they are not really mature web servers themselves.

Python	aioquic
Go	quic-go
Rust	(quiche)[https://github.com/cloudflare/quiche] (Cloudflare), Quinn, Neqo (Mozilla)
C and C++	mvfst (Facebook), MsQuic, (Microsoft), (Google), ngtcp2, LSQUIC (Litespeed), picoquic, quicly (Fastly)

A partial list of complete web servers out of the box and their current HTTP/3 support are as follows:

• Apache

  Support is currently unclear. Nothing was announced. It may also require OpenSSL. (But please note that there is a Apache Traffic Server implementation.)

• NGINX

  This is a custom implementation. This is relatively new and still highly experimental. It is expected that will be merged into the mainline at the end of 2021. This is relatively new and still highly experimental. Please note that there is also a patch to run Cloudflare's quic library on NGINX, which may be more stable at the moment.

• Node.js

  This uses the ngtcp2 library internally. Its is blocked by OpenSSL progress , although they plan to switch to QUIC-TLS fork to get some work faster .

• IIS

  It is not yet clear about IIS support, and nothing has been announced. However, it may use the MsQuic library internally.

• Hypercorn

  This integrated aioquic, with experimental support.

• Caddy

  This uses quic-go, which is fully supported.

• H2O

  This is used very quickly and is fully supported.

• Litespeed

  This uses LSQUIC, which is fully supported.

Client

Most popular browsers already (experimental) HTTP/3 support!

Reference

[HTTP/3 From A To Z: Core Concepts (Part 1)
](https://www.smashingmagazine.com/2021/08/http3-core-concepts-part1/)

HTTP/3: Performance Improvements (Part 2)

[HTTP/3: Practical Deployment Options (Part 3)
](https://www.smashingmagazine.com/2021/09/http3-practical-deployment-options-part3/)