Analysis of QUIC protocol

    QUIC (Quick UDP Internet Connection) is a UDP-based low-latency Internet transport layer protocol developed by Google. In November 2016, the International Internet Engineering Task Force (IETF) held the first meeting of the QUIC working group, which received extensive attention from the industry. This also means that QUIC begins its standardization process and becomes a new generation transport layer protocol.
QUIC (Quick UDP Internet Connection) is a UDP-based low-latency Internet transport layer protocol developed by Google. We know that the TCP/IP protocol suite is the foundation of the Internet. The transport layer protocols include TCP and UDP protocols. Compared to the TCP protocol, UDP is more lightweight, but also has much less error checking. This means that UDP tends to be more efficient (infrequently talking to the server to see if packets are delivered or in order), but not as reliable as TCP. Usually, applications such as games, streaming media, and VoIP use UDP, while most applications such as web pages, emails, and remote login use TCP. [2]
    QUIC is a good solution to the various needs facing the transport and application layers today, including handling more connections, security, and low latency. QUIC incorporates features of protocols including TCP, TLS, HTTP/2, etc., but is based on UDP transport. One of the main goals of QUIC is to reduce the connection delay. When the client connects to the server for the first time, QUIC only needs a delay of 1RTT (Round-Trip Time) to establish a reliable and secure connection, compared to 1-3 times for TCP+TLS RTT is faster. After that, the client can cache the encrypted authentication information locally, and can achieve a 0-RTT connection establishment delay when establishing a connection with the server again. QUIC also reuses the multiplexing function of the HTTP/2 protocol, but because QUIC is based on UDP, it avoids the Head-of-Line Blocking problem of HTTP/2. Because QUIC is based on UDP and runs in the user domain instead of the system kernel, the QUIC protocol can be quickly updated and deployed, thus solving the difficulty of deploying and updating the TCP protocol.
    Today, the IETF's QUIC Working Group is responsible for the standardization process of the QUIC protocol. The IETF community has shown great interest in the standardization of QUIC. A preliminary version of the QUIC protocol has been used in Google's services and the Chrome browser, and has been deployed by a small number of third-party developers. It should be noted that the standardization work of QUIC is completely open, and everyone in the IETF community can make their own suggestions and finally determine an optimal solution. So the final standardized protocol may be quite different from the version currently in use.

    UDP has high transmission efficiency, but is unreliable. Personally, I feel that this is equivalent to UDP 2.0, which solves the problem of unreliability of UDP.