With both high reliability and low latency, Google intends to use the QUIC protocol instead of TCP/UDP

Big

Google is quic to see if it can combine the advantages of both protocols, while achieving low latency and high reliability and applying them to higher-security protocols.

This article is to introduce the QUIC protocol in detail.

Speaking from the TCP protocol

Currently, the data transmission of the Web platform is based on the TCP protocol. The TCP protocol requires three handshakes before creating the connection (Figure 1), and if you need to increase the security of the data interaction, increase the Transport Layer Security Protocol (TLS) and increase the number of handshake times (Figure 2).

Figure 1:tcp three times handshake

Figure 2:tls Initialization handshake

Because of the relatively high cost of establishing a TCP protocol connection, you can reduce the number of handshake times when a connection is established through a TCP quick open (TCP fast open). But the technology is currently less used.

In contrast to TCP, the UDP protocol is a connectionless protocol. After the client issues a UDP packet, it can only "assume" that the packet has been received by the server. The advantage is that in the network transport layer does not need to confirm the packet, but the problem is to ensure the reliability of data transmission, the application layer protocol itself to complete the packet transmission confirmation.

At this time, the Quic agreement on the debut. The QUIC protocol completes the creation of the connection (including TLS) in 1 to 2 packets (depending on whether the connected server is new or known) (Figure 3).

Figure 3:quic Protocol Handshake Signal

The purpose of the Quic agreement

From the comparison, it can be seen that the main purpose of the QUIC protocol is to integrate the reliability of TCP protocol and the speed and efficiency of UDP protocol. Quic's Wikipedia page describes the main purpose of the Agreement:

Optimizing the TCP protocol is a long-term goal for Google, Quic is designed to create a standalone connection that is almost identical to TCP, but has a low latency and better support for similar spdy multiplexing streaming protocols. If the characteristics of the QUIC protocol are proven to be valid, these features may later be migrated to subsequent versions of the TCP and TLS protocols (both of which have a long development cycle).

It is noteworthy that if the attributes of the Quic are proven to be valid, these features may later be migrated to subsequent versions of the TCP protocol.

The implementation of the TCP protocol is highly regulated. TCP protocol stacks are typically implemented by the operating system, such as Linux, the Windows kernel, or other mobile device operating systems. Modifying the TCP protocol is a huge project, because the implementation of each device and system needs to be updated.

On the contrary, the UDP protocol is relatively simple to implement in the operating system, and the new protocol based on UDP protocol is used to verify the theory of the improvement of TCP protocol, and the cost is relatively low.

The QUIC protocol has built-in TLS stacks, implementing its own transport encryption layer without using the existing TLS 1.2. At the same time Quic also contains some HTTP/2 implementations, so Quic's status looks like this:

As can be seen from the diagram, the QUIC layer replaces TCP with the UDP protocol, and the upper level only requires a HTTP/2 API for interacting with remote servers. This is because the QUIC protocol already contains multiplexing and connection management, and HTTP APIs only need to complete the HTTP protocol parsing.

Quic protocol Features

1. Avoid pre-ordered packet blocking

The Spdy and HTTP/2 protocols now support the transfer of multiple data from a page (such as pictures, Java, etc.) through a single data link. This feature speeds up the transmission of page components, but for TCP protocols, this can be a problem with the blocking of the front-ordered packets. This is because the TCP protocol has a strict sequence of processing packets, and when one of the packets encounters a problem, the TCP connection needs to wait for the packet to complete retransmission before proceeding. As a result, other unrelated data can be blocked even if a parallel TCP connection is being performed on multiple data transmissions.

The QUIC protocol directly uses the UDP protocol at the bottom to avoid this problem naturally. Because the UDP protocol does not have a strict order, when a packet encountered problems need to be retransmission, only affect the corresponding resources of the packet, other independent resources (such as other CSS, JS files) will not be affected.

2. Reduce data packets

As already described in the previous QUIC protocol when creating a connection handshake, only 1 to 2 packets are required. This may not feel too much in a networked environment with high-speed Internet connections, as a packet delay is probably between 10~50ms.

Generally speaking, the delay does not feel too much within 50ms. But for wireless networks, things are not the same. Not to mention traditional 2g/3g networks, even 4G networks, the latency between client and server is usually above 100ms. Traditional TCP+TLS protocol transmission mode, in the creation of the connection of 4 packets and QUIC protocol of 1 packets, connection creation will be more time-consuming than 300ms.

3. Forward Error correction

Quic protocol has a very unique feature, called Forward error correction (Forward error correction), each packet in addition to its own content, but also includes some other data packet data, so a small number of packet loss can be through other packets of redundant data directly assembled without retransmission.

This is similar to the network layer of RAID 5.

At present, the default redundancy is 10%, which can rebuild a lost packet with redundant data for each 10 packets sent.

Forward correction sacrifices the upper limit on the amount of data that each packet can send, but reduces the data retransmission caused by packet loss because data retransmission consumes more time (including the time consuming to confirm packet loss, request retransmission, wait for new packets, etc.).

4. Session Restart and concurrent downloads

Another great benefit of the underlying protocol switching to the UDP protocol is that the connection is no longer dependent on the source IP.

For TCP protocols, it takes 4 parameters to identify a TCP connection, from the source IP, source port, destination IP, and destination port. If any of these parameters change, the TCP connection needs to be recreated.

This has little impact on traditional networks because the source and destination IP are relatively fixed. But in the wireless network, the situation is very different. When the device is moving, the TCP connection may need to be recreated because of a network switch, such as switching from a WiFi network to a 4G network environment.

The QUIC protocol uses the UDP protocol and no longer requires these four-tuple parameters. At the same time, the QUIC protocol implements its own session marking method, called the connection uuid. The connection UUID does not change when the device network environment is switched, so there is no need to shake hands again.

In addition to reducing unnecessary connection reconnection, this feature can also make full use of different network interfaces of the equipment to download the resources in parallel. Because although these network interfaces have different IP, they can download data from the server in parallel as long as they can share the connection uuid.

Quic Protocol Practice

Chrome has already experimentally supported the QUIC protocol since 2014. You can enter the chrome://net-internals/#quic查看是否已经支持QUIC协议 in the Chrome browser. If it is not yet supported, it can be opened in the chrome://flags/#enable-quic.

After you start the Chrome browser's support for the QUIC protocol, you can #quic中查看到当前浏览器的QUIC一些连接 in chrome://net-internals/. Of course, only Google services currently support the QUIC protocol (such as YouTube, Google.com).

About Firewalls

Typically, the system administrator focuses on the TCP rules of the firewall and ignores the UDP rules. If you want to use the QUIC protocol behind a firewall, open 443/UDP Access is also required for Quic, in addition to the 80/TCP and 443/tcp that are required for traditional Web services.

Service side uses Quic protocol

Currently, the Web services that support the QUIC protocol have only 0.9 versions of the Caddy. Other common Web services, such as Nginx, Apache, and so on, have not been supported. Curl expressed interest in the support of the Quic agreement.

Quic Performance Advantages

In the 2015 blog post, Google shared some of the results of the QUIC protocol implementation.

These advantages are more pronounced in video services such as YouTube. Users report that the QUIC protocol can reduce the buffer time by 30% when watching video.

-end-Big

Google is quic to see if it can combine the advantages of both protocols, while achieving low latency and high reliability and applying them to higher-security protocols.

This article is to introduce the QUIC protocol in detail.

Speaking from the TCP protocol

Currently, the data transmission of the Web platform is based on the TCP protocol. The TCP protocol requires three handshakes before creating the connection (Figure 1), and if you need to increase the security of the data interaction, increase the Transport Layer Security Protocol (TLS) and increase the number of handshake times (Figure 2).

Figure 1:tcp three times handshake

Figure 2:tls Initialization handshake

Because of the relatively high cost of establishing a TCP protocol connection, you can reduce the number of handshake times when a connection is established through a TCP quick open (TCP fast open). But the technology is currently less used.

In contrast to TCP, the UDP protocol is a connectionless protocol. After the client issues a UDP packet, it can only "assume" that the packet has been received by the server. The advantage is that in the network transport layer does not need to confirm the packet, but the problem is to ensure the reliability of data transmission, the application layer protocol itself to complete the packet transmission confirmation.

At this time, the Quic agreement on the debut. The QUIC protocol completes the creation of the connection (including TLS) in 1 to 2 packets (depending on whether the connected server is new or known) (Figure 3).

Figure 3:quic Protocol Handshake Signal

The purpose of the Quic agreement

From the comparison, it can be seen that the main purpose of the QUIC protocol is to integrate the reliability of TCP protocol and the speed and efficiency of UDP protocol. Quic's Wikipedia page describes the main purpose of the Agreement:

Optimizing the TCP protocol is a long-term goal for Google, Quic is designed to create a standalone connection that is almost identical to TCP, but has a low latency and better support for similar spdy multiplexing streaming protocols. If the characteristics of the QUIC protocol are proven to be valid, these features may later be migrated to subsequent versions of the TCP and TLS protocols (both of which have a long development cycle).

It is noteworthy that if the attributes of the Quic are proven to be valid, these features may later be migrated to subsequent versions of the TCP protocol.

The implementation of the TCP protocol is highly regulated. TCP protocol stacks are typically implemented by the operating system, such as Linux, the Windows kernel, or other mobile device operating systems. Modifying the TCP protocol is a huge project, because the implementation of each device and system needs to be updated.

On the contrary, the UDP protocol is relatively simple to implement in the operating system, and the new protocol based on UDP protocol is used to verify the theory of the improvement of TCP protocol, and the cost is relatively low.