A new generation of Internet transport protocol QUIC

QUIC (Quick UDP Internet Connections, UDP fast Internet connection) is a UDP-based Google proposed an improved communication protocol, which aims to reduce the latency of network communication, provide a better user interactive experience.

    The main features of QUIC comprising: a SPDY (SPDY Google is developed to enhance the speed of the HTTP protocol is HTTP / 2.0 basis) all advantages; 0-RTT connection; reduce packet loss; forward error correction, to reduce retransmission delay ; adaptive congestion control, reduce reconnect; corresponding to TLS encryption.

1. retransmission and recovery

     Similarly to TCP, QUIC after each packet transmission, an acknowledgment packet will wait for a reply. When the packet loss rate exceeds the threshold error correction protocols are explicitly or implicitly retransmission

    For some important data packets, such as packet when the initial key agreement is very important when establishing a connection, if this type of packet loss can clog the overall data stream. QUIC For this type of packet loss before confirming the occurrence of retransmission attempts, usually wait a short time (eg 20ms) did not receive a confirmation immediately after sending again. Thus there will be a number of packets transmitted simultaneously in the same network, as long as there is a successful connection is complete arrival, which reduces the packet loss rate. Receiver for transmitting multiple key timeout retransmission packet and a normal data packet are repeated using the same packet processing mechanism

     QUIC avoid congestion algorithm based on the heartbeat packet is also added for reducing the packet loss rate

     QUIC using FEC (forward error correction code) to recover the data, FEC XOR simple manner. Every time a group of data transmission, comprising a plurality of data packets, and these packets are XORed sequentially, as a final result of FEC packets sent again. After the receiver receives a data word, the data packet and FEC packet and the error correction which can be verified.

    2. Security

    QUIC bulk each UDP packet are encrypted authentication and protection, and to avoid the processing method (e.g., CBC mode) dependent, so that each may be independently UDP packet encryption or authentication processing according to IV before use.

    QUIC uses two key mechanisms: the initial key and the session key. Initial connection is not encrypted, and negotiate the initial key. After completion of the initial key agreement would immediately re-negotiate the session key, so you can ensure the security key before, then it can be achieved in the process of updating of key communications. When the recipient aware of new key to be updated, it will try to use both old and new key to decrypt the data until the key success will be officially updated, otherwise it will remain the old key is valid.

    3. 0-RTT handshake

    QUIC handshake process will take time data exchange, 0-RTT delay to complete the key negotiation handshake process, compared to more than TLS efficiency increased by 5 times, and has a higher level of security.

    QUIC used during the handshake algorithm negotiation initial Diffie-Hellman key, the initial key-dependent on a set of configuration parameters stored in the server periodically update this parameter. After the initial key negotiation is successful, the server will provide a temporary random number, then the two sides session key is generated based on this number.

    Specific handshake process is as follows:

    (1) the client can determine whether all of the configuration parameters of the local existing servers, if there is a direct jump to (5), otherwise continue

    (2) The client sends to the server inchoate client hello (Chlo) message requesting transmission of server configuration parameters

    (3) Chlo server receives, replies rejection (REJ) message, wherein the configuration parameters include Server section

    (4) the client receives the REJ, extract and store server configuration parameters, jumps back to (1) 

    (5) The client sends to the server full client hello message, began formal handshake message includes the number of public clients choice. At this time, the number of client configuration parameters and their choice disclosed by the server acquired, the initial key can be calculated.

    (6) the server receives a full client hello, if the connection does not agree to return the REJ, with (3); if connected to agree, according to the number calculated in the initial disclosure client key, reply server hello (SHLO) message, SHLO with the initial adhesion encryption key, and wherein the server comprises a nonce chosen disclosed.

    (7) The client receives the server's reply, if the situation is the same REJ (4); if SHLO, the initial attempts decryption key extracted nonce disclosed

    (8) client and server in accordance with the number of temporary initial key and disclosed, each based on SHA-256 algorithm derived session key

    (9) to replace both the communication using the session key, the original key is no longer a case, the QUIC handshake process is completed. After the session key updating process similar to the above procedure, but some of the fields in the packet is slightly different.

Quic principle agreement
1,0RTT build even

 

 Declare that if one pair of encrypted communications using QUIC two sides had never communicated with, 0RTT is impossible.

So the first time the C and S built or will even take normal tls handshake process, but after a while child or a period of time, S and C want to communicate, then C and S have just negotiated the key out of the (possible It is in memory or external memory). C will use the key K1 and S just to encrypt data for the first time, during the second RTT, S and C will negotiate a new key K2, as the next communication key.

2, there is no ambiguity retransmitted
Sequence Number TCP packet retransmission sequence number and original packages remain the same, it is precisely because of this feature, introduced ambiguity Tcp retransmission.

 

 After the RTO timeout event occurs, the client initiates a retransmission, then received the Ack data. Since the same Sequence Number, in the end this is in response to the original request Ack or retransmission response to the request it? This indirectly led to ambiguity RTT calculation.

 

 

Quic use Packet Number instead of TCP sequence number, and each Packet Number are strictly increasing, which means that even if Packet N lost, retransmission of the Packet N Packet Number is not N, but a value larger than N, This solves the problem of ambiguity RTT calculation.

3, in order to ensure that the package
QUIC introduces a concept called Stream Offset of.

 

 

假设 Packet N 丢失了,发起重传,重传的 Packet Number 是 N+2,但是它的 Stream 的 Offset 依然是 x,这样就算 Packet N + 2 是后到的,依然可以将 Stream x 和 Stream x+y 按照顺序组织起来。

4,解决ack delay

 

 

TCP 的 RTT 计算:

Quic的RTT计算:


5,队头阻塞
拿http2举例,

 

 

http2 在一个 TCP 连接上同时发送 4 个 请求。其中 请求1 已经正确到达,并被应用层读取。但是 请求2 的第三个 tcp包丢失了,为了保证数据的顺序,需要发送端重传第 3 个包才能通知应用层读取接下去的数据,虽然这个时候 请求3 和 请求4 的全部数据已经到达了接收端,但都被阻塞住了。

 

 

Quic基于UDP,各个请求之间相互独立,比如 请求2 丢了一个 Pakcet,不会影响 请求3 和 请求4,不存在 TCP 队头阻塞。

四,Quic和http3
QUIC 协议最初是由Google发起的项目,后面慢慢成为了 HTTP/2-encrypted-over-UDP 协议。
当 IETF 开始进行协议标准化工作时,协议被分为两层:传输部分和 HTTP 部分。这个想法的初衷是考虑到该传输协议也可用于传输其他数据,而不仅仅用于 HTTP 协议。
社区中大家使用 iQUIC 和 gQUIC 这样的非正式名称来引用这些不同版本的协议,以便将IETF 和 Google提出的QUIC 协议分开。
通过 iQUIC 发送 HTTP 请求的协议被称为HTTP-over-QUIC,即HTTP3。

例子:
https://www.cnblogs.com/jb2011/p/8458549.html

References
next-generation communication protocols: Quic
https://knownsec-fed.com/2018-01-19-xia-yi-dai-tong-xin-xie-yi-quic/
QUIC protocol is how to do 0RTT encrypted transmission
https://blog.csdn.net/dog250/article/details/80935534
QUIC protocol Web server quickly enable
https://my.oschina.net/u/347901/blog/1647385
analysis QUIC protocol principle
https: // zhuanlan. zhihu.com/p/32553477
QUIC Tencent in practice and performance optimization
https://zhuanlan.zhihu.com/p/32560981
how seven cattle cloud QUIC push live stream program to achieve 0 Caton
https://zhuanlan.zhihu.com / p / 33698793
when we discuss http head of line blocking, what are we discussing?
https://liudanking.com/arch/what-is-head-of-line-blocking-http2-quic/
QUIC official document
https://www.chromium.org/quic
QUIC protocol specification

https://www.wolfcstech.com/2017/01/13/QUIC%E5%8D%8F%E8%AE%AE%E8%A7%84%E8%8C%83/

Guess you like

Origin www.cnblogs.com/klb561/p/11871549.html