QUIC (Quick UDP Internet Connections) (pronunciation: Quick) is a next-generation network transport protocol developed by Google. QUIC was designed to take advantage of engineers’ decades of experience to improve network latency.
It may surprise you, but the development of HTTP was in the hands of the G-men. Http-over-spdy was renamed HTTP/2, and http-over-quic was renamed HTTP/3.
QUIC based on UDP protocol to achieve similar TCP+TLS+HTTP2 function combination. So you can think of QUIC and existing protocols as the following structure:
www.nanog.org/sites/defau…
So why QUIC?
Why QUIC?
Is there anything hard about HTTP/2 that cannot be fixed? The Achilles heel of HTTP/2 is TCP.
TCP protocol was designed and finalized in the 1970s, when the network had a high packet loss rate, poor network speed, and link stability and reliability were the most important things to be solved at that time. Compared to the current state of the Internet today, there is no doubt that we have made tremendous progress in terms of reliability and speed.
After decades of accumulated experience, the network engineers on how to optimize the network access and reduce the delay also had the new cognition, then update the TCP protocol, but the TCP update is very difficult, because the realization of the network protocol stack is dependent on system kernel updates, and terminal equipment, middleware system update is very slow, A new iteration could take 5-15 years to spread, too slow for the current Internet.
So TCP’s vulnerability is summed up: TCP update optimization needs to rely on the system kernel update.
This is a contradiction between an increasingly high-speed application layer and a slowly evolving network transport layer, so JIM (QUIC protocol designer) decided to abandon TCP at the transport layer and embrace UDP. Relative TCP, UDP is an unstable optimistic protocol, he doesn’t need handshake to establish a connection, as to what prevent IP attack, how to guarantee the data consistency, these are all above UDP work, it just fit our requirements, a lot of work from the transport layer to application layer (layer 4 in terms of network model ~), as a result, In the future, the UPGRADE of QUIC protocol does not depend on the underlying operating system at all, and only terminals and servers need to be upgraded to the specified version.
This is what QUIC is all about, as well as the ultimate features and advantages over HTTP/2.
What are the advantages over HTTP/2?
HTTP/2 is an excellent protocol, and its biggest feature is multiplexing, so what does QUIC bring to the table and its advantages over HTTP/2?
It has huge advantages mainly in the following aspects:
- Delay in establishing connections
- Improved congestion control
- Multiplexing – no queue head blocking version
- Automatic error correction
- Connect the migration
Next we will briefly explain why there are these advantages 😜
Delay in establishing connections
First of all, we should clarify the concept of round-trip time (RTT), which, as its name implies, is the time required by a server and a terminal to interact. RTT is generally used to measure network latency.
With traditional TCP, we need three handshakes, or 1.5 RTT, to start transferring data.
For HTTP/2, although TLS is not enabled on the protocol, but the current implementation of everyone is bound to TLS and HTTP, that is, we not only need to establish a connection, but also determine the encryption version, encryption key and other information, TCP+TLS requires 3 RTT.
For QUIC at this stage, it has designed its own encryption protocol and process to achieve 0 RTT effect in the best case.
Dev. To/grigorkh/wh…
The effect of 0 RTT is that the QUIC client caches the tokens and certificates issued by the server. When data needs to be sent again, the client can use the old tokens and certificates directly, which achieves 0 RTT. In the case of no cache, the server side simply rejects the request and returns the newly produced token and certificate. So when the token expires or there is no cache, QUIC still needs a handshake to start transferring data.
Of course, there is a cost to playing this way, and defending against replay attacks needs to be addressed at the application layer.
It should be noted that after being accepted as HTTP/3, QUIC will adopt TLS 1.3 in the future, abandoning the existing encryption algorithm ~
TLS 1.3 is a big jump from 1.2 and 1.1, and there is no official version yet. TLS 1.3 requires only 2 RTT to establish a connection.
Improved congestion control
The current congestion control of QUIC mainly realizes TCP slow start, congestion avoidance, fast retransmission, fast recovery. On the basis of these congestion control algorithms, some improvements are made.
For example, monotonically increasing Packet Number. TCP uses byte Sequence numbers and AKS to ensure the orderly arrival of messages. However, Sequence numbers are ambiguous during retransmission. You don’t know if the next AKS will be the response to the previous request or the retransmitted response. Monotone increasing Packet Number can avoid this problem and ensure the accuracy of sampling RTT.
For specific improvements, please refer to the STGW article
QUIC congestion control algorithm is mainly a re-implementation of TCP algorithm, after all, TCP algorithm after decades of production validation.
Multiplexing – no queue head blocking version
SPDY and HTTP/2 are already multiplexed. Multiplexing refers to the fact that we do not need to re-establish TCP connections for each resource, multiple resource transfers can share one connection.
www.nanog.org/sites/defau…
As a result, on HTTP/2 enabled sites, we no longer need to merge resources (:) compression can be done), after all, sending multiple resources at once is faster than making multiple connections to download one resource at a time.
The big problem with HTTP/2 multiplexing, however, is that headers block. The reason is still due to the Sequence Number mechanism of TCP. To ensure the orderly arrival of resources, if a resource is lost at the head of the transmission queue, TCP will notify the application layer to process subsequent resources only after the resource is successfully retransmitted.
www.nanog.org/sites/defau…
Since QUIC avoided TCP, he designed the concepts of Connection and stream. A connection can multiplex multiple streams, and each stream is independent. The packet loss of a single stream will not affect the processing of other resources.
www.nanog.org/sites/defau…
Automatic error correction
The error here means that a packet is missing. When a packet is lost, QUIC can repair the resource through other received packets.
This means that, in fact, each packet carries redundant information, through which QUIC can reorganize corresponding resources without retransmitting.
Currently, about one packet can be repaired for every 10 packets.
Connect the migration
TCP determines a connection based on four elements (client IP address, port number, server IP address, and port number). When one of these four elements changes, the connection needs to be re-established. On the mobile side, we often switch to 4G/wifi, and each time we switch, we have to re-establish the connection.
In QUIC, connections are maintained by it. So QUIC differentiates connections by generating a client that generates a Connection ID (64-bit). As long as the generated UUID remains the same, the Connection does not need to be re-established, even if the client’s network changes.
medium.com/@nirosh/und…
Present situation of QUIC
Http-over-quic will be absorbed and renamed HTTP/3. The future of Web transport does not rely on TCP, nor does it require kernel support, and HTTP can become more and more like other products every month or even every week.
Currently, if you want to experience QUIC you can use candy server. Candy has QUIC support since version 0.9.
Github has found a C++ version of the implementation, using Nodejs C++ module, we can quickly implement a node-quic look. 😎
The resources
chromium quic blog
medium
Rogan_Quic_Next_Generation
Zhihu column
Mattias