Shulou(Shulou.com)05/31 Report--

What are the QUIC protocols that can accelerate the Internet? I believe many inexperienced people are at a loss about this. Therefore, this paper summarizes the causes and solutions of the problems. Through this article, I hope you can solve this problem.

As we all know, QUIC (Quick UDP Internet Connection) is an Internet transport layer protocol developed by Google. It is based on the UDP transport layer protocol and has the reliability and security of TCP, TLS, HTTP/2 and other protocols. It can effectively reduce the connection and transmission delay and better meet the current challenges of the transport layer and the application layer. Below, we will discuss the characteristics of QUIC protocol in layers from low to top.

The QUIC protocol is a collection of a series of protocols, including:

Transport Protocol (Transport)

Packet loss detection and congestion control (Recovery)

Secure Transport Protocol (TLS)

HTTP3 protocol

HTTP header Compression Protocol (QPACK)

Load balancing Protocol (Load Balance)

Quic-based discussions are based on the quic-34 series version.

The QUIC protocol is similar to the express company, which, after receiving the user data, packages the data, transmits it to the opposite end, unpacks it, and gives the user data to the final target user. QUIC is based on UDP protocol and achieves reliable transmission similar to TCP. On this basis, combined with HTTP3/QPACK, it can better serve the HTTP Request/Response needs of Internet Shanghai. As the name sounds, QUIC (quick), the goal is to have a better experience than TCP-based HTTP interactions.

Characteristics of QUIC/HTTP3:

Orderly transmission: use the concept of stream to ensure that the data is orderly. Different stream or packet does not guarantee orderly arrival.

Message compression, improve the load ratio: for example, QUIC introduced variable-length integer encoding. For example, the introduction of QPACK for head compression

Reliable transmission: supports packet loss detection and retransmission

Secure Transport: TLS 1.3Security Protocol

Layered protocol

QUIC is a reliable transport protocol similar to TCP based on UDP. HTTP3 completes HTTP transactions on the basis of QUIC.

The network is always discussed in layers, so here we discuss the quic protocol from the bottom up.

UDP layer: what is transmitted in the UDP layer is the UDP message. Here we focus on what the UDP message load content is and how to send the UDP message efficiently.

Connection layer: Connection confirms the unique connection through CID, and connection provides reliable and secure transmission to packet.

Stream layer: Stream performs unique stream confirmation through StreamID in the corresponding Connection, and stream manages the transmission of stream frame

HTTP3 layer: HTTP3 is based on QUIC Stream and provides more efficient HTTP transaction transport than HTTP1.1 and HTTP2.0,HTTP3. Header Compression through QPACK Protocol in HTTP3

UDP layer

This section discusses issues related to the UDP part of the QUIC package.

UDP load magnitude

The size of the load is limited by three objects: the QUIC protocol; the acceptance capacity of the path MTU; terminal

1. QUIC cannot run on a single UDP transport network path that does not support 1200 bytes. QUIC stipulates that the size of initial packets must not be less than 1200. If the data itself is less than 1200 (such as initial ack), then you need to use padding to fill at least 1200 bytes.

2. QUIC does not want IP layer fragmentation. This requirement means that the data handed over by udp to ip layer will not be more than 1 MTU. Assuming that mtu is 1500 MTU, the upper limit of udp load is 1472 bytes (1500-20-8), and the upper limit of IPv4 load is 1452 (1500-40-8) in ipv6. QUIC recommends using PMTUD and DPLPMTUD for mtu probing. In actual combat, we recommend that you set the MTU of IPv6 to 1280, which is greater than this value, and packet loss may occur in some networks.

3. The ability of the terminal to accept the max_udp_payload_size (0x03) of transport paraments is the ability of the terminal to accept the size of a single udp packet. The sender should follow this convention.

UDP load content

The content of UDP load is packet in quic protocol. The agreement stipulates that if the limit of the load is not exceeded, then multiple packet can be sent out as a udp message. In the quic implementation, if each udp message contains only one quic packet, it is more likely to be out of order.

Send UDP packets efficiently

Unlike tcp, quic needs to assemble udp data at the application layer, and each udp message is less than 1 mtu. If it is not optimized, for example, each packet is sent directly with sendto/sendmsg, it is bound to cause a large number of system calls and affect throughput.

1. Through sendmmsg interface optimization, sendmmsg can send multiple udp quic packets in user mode to kernel state through a system call. Kernel states are sent as udp packets independently for each udp quic packet.

2. In 1.) solved the problem of the number of system calls. Enabling GSO can improve the delay of a subpacket to the moment before it is sent to the network card driver, which can further increase the throughput and reduce the CPU consumption.

3. On the basis of 2.), the mainstream network card now supports the hardware GSO offload scheme, which can further increase throughput and reduce cpu consumption.

The sending method described above can in fact be understood as udp burst sending mode, which brings a problem, congestion control requires pacing ability!

Connection layer

During our discussion, we know that a udp message is actually a packet defined by one or more quic protocols. So at the level of Connection, it is actually managed by packet. When a packet arrives, the terminal needs to parse the target ConnectionID (DCID) field and hand over the packet to the corresponding quic connection. A packet is composed of two parts: header and payload.

Connection id

Unlike tcp's 4-tuple, which only confirms a connection, QUIC defines a ConnectionID that has nothing to do with network routing to confirm a unique connection. This has the advantage of staying connected when the quad changes (such as nat rebinding or terminal network switching wifi- > 4G). Of course, although the connection state is still maintained, congestion control needs to be adjusted in time due to changes in the path.

Packet header

The quic header of IETF is divided into two types, long header and short header. Long header can be divided into four types: initial, 0rtt, handshake and retry. The definition of the type can be referred directly to the rfc documentation, which will not be repeated here.

Quic stipulates that packet number is always self-increasing, and even if the content of a packet is retransmitted frame data, its packet number must also be self-increasing, which brings an advantage over TCP, which can collect the RTT attributes of the path more accurately.

Packet number encoding and decoding: packet number is a range of values of 0,262-1. In order to save space, quic introduces the concept of unacked when calculating packet number. By truncating (keeping only valid bits), only 1-4 bytes are used, that is, the correct packet number can be encode/decode. The process of enc/dec is explained in detail in the appendix in the rfc document.

The packet header is the protected object in the secure transmission, which also means that it is impossible to use wireshake to analyze the timing of packet without ssl information. Intermediate network devices are also unable to obtain packet number for out-of-order reorganization as TCP does.

Packet load

After decrypting the packet and removing the packet header, the load of the packet will be full of frame (at least 1).

If the load of packet does not include three types of frames: ACK, PADDING and and CONNECTION_CLOSE, then the packet is defined as ack-eliciting, which means that the peer must generate the corresponding ack notification to the sender of this packet to ensure that the data is not lost.

There are as many as 30 types of frames in the load of packet. Each type has its own application scenarios, such as ACK Frame for reliable transmission (Recovery), Crypto for secure transmission (TLS handshake), Stream Frame for business data transfer, MAX_DATA/DATA_BLOCKED for flow control, and PING Frame for mtu detection. For more information, please see rfc documentation.

Secure transmission

The secure transport of QUIC depends on TLS1.3, while boringssl is a dependent library for many quic implementations. The protocol protects the head and load of Packet (including packet number). The ability of TLS1.3 0RTT, while providing data protection, can send Response Header to the client as soon as the server receives the first request message. The time of the first package in HTTP service is greatly reduced. In order to support 0RTT, the client needs to save PSK information, as well as some transport parament information.

Secure transmission often involves performance issues. In the current mainstream servers, AESG has the best performance because cpu provides hardware acceleration. CHACHA20 requires more CPU resources. In short video service, plaintext transmission is usually used directly because of the requirement of the first frame.

Transport Paramenter (TP) negotiation is completed in the handshake phase of secure transmission. In addition to the TP specified in the protocol, users can also expand private TP content, which brings great convenience. For example, the client can use tp to inform the server for plaintext transmission.

Reliable transmission

QUIC protocol needs to be able to transmit reliably like TCP, so QUIC has a separate rfc that describes the topic of packet loss detection and congestion control.

Packet loss detection: the protocol uses two ways to determine whether packet loss occurs: one is based on ack detection, which deduces whether the packet sent before the packet is lost according to the packet that has arrived through time threshold and packet threshold. Second, in the case of losing the reference package, we can only infer whether the packet is lost or not by PTO. Generally speaking, a large number of triggers should be the way ACK is detected. If PTO is triggered in large quantities, it will affect the efficiency of sending packets.

Congestion control: QUIC specially optimizes some defects in the TCP protocol. For example, always increasing packet number, rich ack range,host delay computing and so on. At the same time, the congestion control of tcp needs to be implemented in kernel state, while QUIC is implemented in user mode, which greatly reduces the threshold for the study of efficient and reliable transmission protocols. In Recovery protocol, the implementation of newReno is described. In GOOGLE chrome, cubic, bbr and bbrv2 are implemented, while the mvfst project is richer, including ccp and copa protocols.

Stream layer

Stream is an abstract concept that represents an orderly stream of bytes, and these bytes are actually made up of Stream Frame. Multiple streams can be transmitted at the same time on a quic connection.

Stream header

In Quic protocol, stream is divided into one-way flow or two-way flow, and it is also divided into client-side initiation or server-side initiation. The different types of definitions of stream are fully utilized in HTTP3.

Stream load

The load of the Stream is a series of Stream Frame, and a single flow is confirmed by the Stream ID of the Stream Frame header.

In TCP, if a segment transmission is lost, the subsequent segment arrives out of order and will not be used by the application layer until the lost segment is retransmitted successfully, so the multiplexing ability of HTTP2 implemented by TCP is restricted. In the QUIC protocol, the concept of order is only maintained in a single stream, and order is not required between stream and packet. If a packet is lost, it will only affect the stream contained in the packet. Other stream can still extract the data they need from the subsequent out-of-order packet and submit it to the application layer.

HTTP3 layer

Stream classification

After the introduction of HTTP3, the unidirectional flow type of stream is extended to: control flow, Push flow and other retention types. Among them, the setting of HTTP3 is transmitted in the control flow, while the HTTP data transmission is in the two-way flow initiated by the client, so the reader will find that the stream id of HTTP data transmission is modulo 4 equal to 0.

After the introduction of QPACK, one-way flow is further extended to two types, encoder flow, decoder flow, and the update of dynamic tables in QPACK depends on these two streams.

QPACK

The function of QPACK is head compression. Similar to HPACK,QPACK, static tables are defined, while dynamic tables are used for header indexes. Static tables are predefined for common headers and protocols. The dynamic table is gradually established during the HTTP process of the QUIC Connection service. The Encoder/Decoder flow established by QPACK is the QUIC Connection lifecycle that accompanies HTTP transactions.

Dynamic tables are not a must for HTTP3 to run, so complex dynamic table functions are not implemented in some QUIC open source projects.

In the dynamic table service of QPACK, data stream, encoding stream and decoding stream participate together, the encoding stream and decoding stream are responsible for maintaining the dynamic table changes, and the data stream parses the index number of the header and queries it in the dynamic table to get the final header definition.

Other

Flow Control flow control

QUIC protocol introduces the concept of flow control, which is used to express the acceptability of the receiver. Flow control is divided into two levels, Connection level, and Stream level. The data offset sent by the sender cannot exceed the limit of flow control. If the limit is reached, then the sender should pass the

DATA_BLOCKED/STREAM_DATA_BLOCKED to notify the receiver. For the sake of transmission performance, the receiver should try its best to keep the limit large enough, for example, when it reaches half of the max_data, it will update the max_data and transmit it to the sender. If the receiver does not want to accept data too quickly, the sender can also be constrained by flow control.

QUIC version

QUIC was designed and developed by google at the beginning. In the chromium project, we can see that the version number of google quic (GQUIC) is defined as Q039, Q043, Q046, Q050 and so on.

With the launch of the IETF version of QUIC, there are also many versions of ietf quic (IQUIC), such as 29Magne30 and 34 (the latest version). Different versions may not be interoperable, for example, different versions have different salt variables for secure transmission. Therefore, IQUIC introduces the function of version negotiation, which is used for different clients and servers to negotiate versions that can communicate with each other.

In practice, there is also a requirement that a service can serve different versions of GQUIC and different versions of IQUIC at the same time. This requires that after the service receives the packet, it needs to judge the packet, analyze whether it belongs to iquic or gquic, and then carry on the logical diversion.

Application and Future Prospect of QUIC

Currently, Aliyun CDN provides GQUIC version service online, and applicable products include static content distribution (small image files, large file downloads, video and audio on demand) and dynamic content distribution (site-wide acceleration). Users only need to enable "QUIC Protocol switch" on the domain name in CDN and site-wide acceleration console, and clients that support QUIC protocol can communicate with Aliyun CDN node through QUIC protocol.

QUIC application scenario

Small picture files: significantly reduce the total time spent downloading files and improve efficiency

VOD: improve the second opening rate of the first screen, reduce the stutter rate, and improve the user viewing experience.

Dynamic request: suitable for dynamic request, improve access speed, such as web login, transaction and other interactive experience

Weak network environment: it can still provide available services in the case of serious packet loss and network delay, and optimize transmission indicators such as stutter rate, request failure rate, second open rate, and improve connection success rate.

Large concurrent connections: strong connection reliability, supporting a higher access rate in the case of more page resources and more concurrent connections

Encrypted connection: secure and reliable transmission performance

After reading the above, have you mastered the methods of QUIC protocol that can accelerate the Internet? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.