Watching B station can be faster!

[[384367]]

This article is reprinted from the WeChat public account "Xiao Lin Coding", the author is Xiao Lin Coding. Please contact Xiao Lin Coding public account to reprint this article.

Now when you use Google Chrome to watch videos on Bilibili, the default protocol is HTTP/2, which has much better performance than HTTP/1.1, but in fact, you can watch videos on Bilibili even faster!

Because some video servers of Bilibili support watching videos using the QUIC protocol, QUIC is implemented based on the UDP transmission protocol, and the latest HTTP/3 uses the QUIC protocol. It actually has better performance than HTTP/2 and provides a better video watching experience, especially in weak network environments.

How good is the QUIC protocol?

The Chromium (the engine behind Google's Chrome browser) team said it found the performance benefits of QUIC to be particularly high, reducing Google Search latency by more than 2%, reducing YouTube rebuffering time by more than 9%, and increasing client throughput on PCs by more than 3% and on mobile devices by more than 7%.

How to watch B station videos using QUIC?

I haven’t studied how to use the QUIC protocol to watch Bilibili videos on mobile phones, but it is easy to do with Google Chrome.

Google Chrome supports the QUIC protocol, which is an experimental feature. The QUIC protocol is actually still in draft and has not been officially released, so it is not enabled by default and needs to be turned on manually.

The first step is to open the Chrome browser, enter chrome://flags/#enable-quic in the address, and set the flag to Enabled.

Step 2: After restarting the browser, open Station B, click on a video, and then check whether the QUIC protocol is used for video playback. The check method is as follows:

• Press F12 to enter the browser debugging information interface;
• Select Network->Protocol. If Protocol shows h3, it means that HTTP/3 (which means QUIC protocol) is currently used to transmit video content.

For example, in the picture below, I am watching the B-station video of Mr. He interviewing Cook, using the HTTP3 protocol:

Note: If your access speed is affected and becomes slower after turning it on, then you must remember to turn off this function, because the transmission protocol used by the QUIC protocol is UDP, and some operators' networks will drop UDP packets when they are busy.

Transitions

Well, that’s all about B Station. You might think I’m going to talk about B Station this time, but actually I’m going to talk about HTTP/3!

It's not easy. In order to let everyone learn HTTP/3, Xiaolin took great pains to set up the cover of B Station to attract everyone to click in. So, don't think it's a clickbait title.

In fact, HTTP/3 has not been officially launched yet, but since 2017, HTTP/3 has been updated to 34 drafts, the basic features have been determined, and the packet format may change in the future.

Therefore, this introduction to HTTP/3 will not involve the packet format, but only talk about its features.

HTTP/2’s flaws

HTTP/2 has greatly improved the performance of HTTP/1.1 through new features such as header compression, binary encoding, multiplexing, and server push. However, the only drawback is that the HTTP/2 protocol is implemented based on TCP, so there are three defects.

• Head-of-line blocking;
• TCP and TLS handshake delays;
• Network migration requires reconnection;

Head of Line Blocking

Multiple HTTP/2 requests run in one TCP connection. When TCP packets are lost, the entire TCP connection has to wait for retransmission, which will block all requests in the TCP connection.

Because TCP is a byte stream protocol, the TCP layer must ensure that the received byte data is complete and in order. If a TCP segment with a lower sequence number is lost during network transmission, even if a TCP segment with a higher sequence number has been received, the application layer cannot read this data from the kernel. From the HTTP perspective, the request is blocked.

For example, as shown below:

In the figure, the sender sends many packets, each of which has its own sequence number, which you can think of as the TCP sequence number. Packet 3 is lost in the network. Even if packets 4-6 are received by the receiver, the TCP data in the kernel is not continuous, so the receiver's application layer cannot read it from the kernel. Only after packet 3 is retransmitted can the receiver's application layer read the data from the kernel. This is the head-of-line blocking problem of HTTP/2, which occurs at the TCP level.

TCP and TLS handshake delay

When initiating an HTTP request, it is necessary to go through the TCP three-way handshake and the TLS four-way handshake (TLS 1.2) process, so a total of 3 RTT delays are required to send the request data.

In addition, because TCP has the feature of "congestion control", the newly established TCP connection will have a "slow start" process, which will have a "slow down" effect on the TCP connection.

Network migration requires reconnection

A TCP connection is determined by a four-tuple (source IP address, source port, destination IP address, destination port). This means that if the IP address or port changes, TCP and TLS will need to re-handshake, which is not conducive to scenarios where mobile devices switch networks, such as switching from a 4G network environment to a WIFI network.

These problems are inherent in the TCP protocol and cannot be avoided no matter how HTTP/2 at the application layer is designed.

To solve this problem, the transport layer protocol must be replaced with UDP. HTTP/3 made this bold decision!

Features of the QUIC protocol

We are well aware that UDP is a simple, unreliable transmission protocol, and that UDP packets are out of order and have no dependencies.

Moreover, UDP does not require a connection, nor does it require a handshake or waving process, so it is naturally faster than TCP.

Of course, HTTP/3 does not simply replace the transport protocol with UDP, but also implements the QUIC protocol at the "application layer" based on the UDP protocol. It has network characteristics similar to TCP's connection management, congestion window, and flow control, which is equivalent to turning the unreliable transmission UDP protocol into a "reliable" one, so there is no need to worry about data packet loss.

The QUIC protocol has many advantages, here are a few examples, such as:

• No head-of-line blocking;
• Faster connection establishment;
• Connection migration;

No head-of-line blocking

The QUIC protocol also has concepts similar to HTTP/2 Stream and multiplexing, and can transmit multiple Streams concurrently on the same connection. A Stream can be considered as an HTTP request.

Since the transport protocol used by QUIC is UDP, UDP does not care about the order of data packets, and does not care if data packets are lost. However, the QUIC protocol guarantees the reliability of data packets, and each data packet has a unique sequence number.

If a packet is lost in a stream in a QUIC connection, only that stream is blocked, and other streams are not affected. This is different from HTTP/2, where if a packet is lost in a stream, other streams are also affected.

Therefore, there is no dependency between the multiple streams on the QUIC connection. They are all independent. If packet loss occurs in a stream, it will only affect that stream, and other streams will not be affected, eliminating the head-of-line blocking problem of HTTP/2.

Faster connection establishment

For HTTP/1 and HTTP/2 protocols, TCP and TLS are layered, belonging to the transport layer implemented by the kernel and the presentation layer implemented by the openssl library respectively. Therefore, they are difficult to merge together and need to be handshaked in batches, first TCP handshake and then TLS handshake.

Although HTTP/3 requires a QUIC protocol handshake before transmitting data, this handshake process only requires 1 RTT. The purpose of the handshake is to confirm the "connection ID" of both parties. Connection migration is implemented based on the connection ID.

However, the QUIC protocol of HTTP/3 is not layered with TLS. Instead, QUIC includes TLS inside. It carries "records" in TLS in its own frames. In addition, QUIC uses TLS1.3, so only one RTT is required to "simultaneously" complete the connection establishment and key negotiation. Even during the second connection, the application data packet can be sent together with the QUIC handshake information (connection information + TLS information), achieving a 0-RTT effect.

As shown in the right part of the figure below, when the HTTP/3 session is resumed, the payload data is sent together with the first data packet, which can achieve 0-RTT:

Connection Migration

As we mentioned earlier, the HTTP protocol based on the TCP transport protocol determines a TCP connection through a four-tuple (source IP, source port, destination IP, destination port).

So when the network of a mobile device switches from 4G to WIFI, it means that the IP address has changed, so the connection must be disconnected and then re-established. The process of establishing a connection includes the delays of the TCP three-way handshake and the TLS four-way handshake, as well as the deceleration process of TCP slow start. The user feels that the network suddenly freezes, so the cost of connection migration is very high.

The QUIC protocol does not use a four-tuple method to "bind" the connection, but instead uses a connection ID to mark the two endpoints of the communication. The client and server can each choose a set of IDs to mark themselves.

Therefore, even if the mobile device's network changes, causing the IP address to change, as long as the context information (such as connection ID, TLS key, etc.) is still retained, the original connection can be reused "seamlessly", eliminating the cost of reconnection without any sense of lag, thus achieving the function of connection migration.

HTTP/3 Protocol

After understanding the characteristics of the QUIC protocol, let's take a look at the changes made by the HTTP/3 protocol at the HTTP layer.

HTTP/3 uses the same binary frame structure as HTTP/2. The difference is that HTTP/2's binary frame needs to define a Stream, but HTTP/3 itself does not need to define a Stream and directly uses the Stream in QUIC, so the frame structure of HTTP/3 becomes simpler.

As can be seen from the figure above, the HTTP/3 frame header has only two fields: type and length.

According to the different frame types, they are generally divided into two categories: data frames and control frames. HEADERS frames (HTTP headers) and DATA frames (HTTP body) belong to data frames.

HTTP/3 has also upgraded the header compression algorithm to QPACK. Similar to the HPACK encoding method in HTTP/2, QPACK in HTTP/3 also uses static tables, dynamic tables and Huffman encoding.

Regarding the changes in the static table, the static table of HPACK in HTTP/2 has only 61 items, while the static table of QPACK in HTTP/3 is expanded to 91 items.

The Huffman coding of HTTP/2 and HTTP/3 is not much different, but the dynamic table encoding and decoding methods are different.

The so-called dynamic table, after the first request-response, both parties will update their respective dynamic tables with the Header items that are not included in the static table, and then only use one number to represent it in subsequent transmissions. The other party can then look up the corresponding data from the dynamic table based on this one number, so there is no need to transmit long data each time, which greatly improves the encoding efficiency.

It can be seen that the dynamic table is time-series. If the first request is lost, the other party will not be able to decode the HPACK header for subsequent requests because the other party has not yet established the dynamic table. Therefore, the decoding of subsequent requests will block the retransmission of the data packet lost in the first request.

HTTP/3's QPACK solves this problem, but how does it solve it?

QUIC has two special unidirectional streams. The so-called unidirectional stream can only send messages at one end, and bidirectional means that both ends can send messages. Bidirectional streams are used to transmit HTTP messages. The usage of these two unidirectional streams is:

• One is called QPACK Encoder Stream, which is used to pass a dictionary (key-value) to the other party. For example, when facing an HTTP request header that does not belong to a static table, the client can send a dictionary through this stream;
• One is called QPACK Decoder Stream, which is used to respond to the other party and tell it that the dictionary just sent has been updated to its local dynamic table, so that this dictionary can be used for encoding later.

These two special unidirectional streams are used to synchronize the dynamic tables of both parties. The encoder uses the dynamic table to encode the HTTP header only after receiving the update confirmation notification from the decoder.

Summarize

Although HTTP/2 has the ability to transmit multiple streams concurrently, its transport layer is the TCP protocol, which results in the following defects:

• Head-of-line blocking: Multiple HTTP/2 requests run in one TCP connection. If a TCP segment with a lower sequence number is lost during network transmission, even if a TCP segment with a higher sequence number has been received, the application layer cannot read this data from the kernel. From the HTTP perspective, multiple requests are blocked.
• TCP and TLS handshake delay, TCL three-way handshake and TLS four-way handshake, a total of 3-RTT delay;
• Connection migration requires reconnection. When a mobile device switches from a 4G network environment to a WIFI network, since TCP confirms a TCP connection based on a quaternary, changes in the network environment will cause changes in the IP address or port. TCP can only disconnect and then re-establish the connection, resulting in a high cost for switching network environments.

HTTP/3 replaces the transport layer from TCP to UDP, and develops the QUIC protocol on the UDP protocol to ensure reliable data transmission.

Features of the QUIC protocol:

• There is no head-of-line blocking. Multiple streams on a QUIC connection have no dependencies on each other and are independent. There are no underlying protocol restrictions. If a stream is lost, only that stream will be affected, and other streams will not be affected.
• The connection establishment speed is fast. Because QUIC contains TLS1.3, it only takes 1 RTT to "simultaneously" complete the connection establishment and TLS key negotiation. Even when connecting for the second time, the application data packet can be sent together with the QUIC handshake information (connection information + TLS information), achieving a 0-RTT effect.
• Connection migration: The QUIC protocol does not use a four-tuple method to "bind" the connection, but uses a connection ID to mark the two endpoints of the communication. The client and server can each choose a set of IDs to mark themselves. Therefore, even if the mobile device's network changes, resulting in a change in the IP address, as long as the context information (such as the connection ID, TLS key, etc.) is still retained, the original connection can be "seamlessly" reused, eliminating the cost of reconnection;

In addition, HTTP/3's QPACK uses two special unidirectional streams to synchronize the dynamic tables of both parties, solving the head-of-line blocking problem of HPACK in HTTP/2.

However, since QUIC uses the UDP transport protocol, UDP is a "second-class citizen". Most routers will drop UDP packets when the network is busy and give "space" to TCP packets, so the promotion of QUIC should not be that easy.

Looking forward to the day when HTTP/3 is officially launched!

Reference Links

https://medium.com/faun/http-2-spdy-and-http-3-quic-bae7d9a3d484

https://developers.google.com/web/fundamentals/performance/http2?hl=zh-cn

https://blog.cloudflare.com/http3-the-past-present-and-future/

https://tools.ietf.org/html/draft-ietf-quic-http-34

https://tools.ietf.org/html/draft-ietf-quic-transport-34#section-17

https://ably.com/topic/http3?amp%3Butm_campaign=evergreen&%3Butm_source=reddit&utm_medium=referral

https://www.nginx.org.cn/article/detail/422

https://www.bilibili.com/read/cv793000/

https://www.chinaz.com/2020/1009/1192436.shtml

Original link: https://mp.weixin.qq.com/s/bHuhvkVOwplkvPwEHxF4mg