current position:Home>[technical update] http / 3 quic Foundation

[technical update] http / 3 quic Foundation

2022-04-29 04:25:30baoleilei6

Over to this article, you can read HTTP/2 elementary analysis

although HTTP/2 Standard in 2015 year 5 With the moon RFC 7540 Officially published , And most browsers are in 2015 At the end of the year .

however , To be really widely used is to 2018 About years ago , But also in 2018 year ,11 month IETF Given official approval , recognition HTTP-over-QUIC Become HTTP/3.

HTTP/2 The reason " deprecated ", Because the transport protocol he uses is still TCP, therefore HTTP/3 The first problem to solve is to bypass TCP

Develop a new protocol , It will also be affected by the rigidity of intermediate devices , It can't be used on a large scale . therefore , Researchers have come up with a solution based on UDP How to achieve .

What we're talking about now HTTP/3, In fact, that is HTTP over QUIC, That is, based on QUIC Protocol implemented HTTP.

QUIC The agreement has the following characteristics

  • be based on UDP Transport layer protocol : It USES UDP Port number to identify a specific server on a given machine .

  • reliability : although UDP It's an unreliable transport protocol , however QUIC stay UDP We've made some changes on the basis of , Makes him provide and TCP Similar reliability . It provides packet retransmission 、 Congestion control 、 Adjust the transmission rhythm and so on TCP The characteristics that exist in .

  • The disorder is realized 、 Concurrent byte streams :QUIC A single stream of data can guarantee orderly delivery , But multiple streams may be out of order , This means that the transmission of a single data stream is sequential , However, the order in which the receiver receives data in multiple streams may be different from the sending order of the sender !

  • Quick handshake :QUIC Provide 0-RTT and 1-RTT The connection is established

  • Use TLS 1.3 Transport layer security protocol : And earlier TLS Version comparison ,TLS 1.3 There are many advantages , But the main reason for using it is that the handshake takes less round trips , This can reduce the delay of the protocol .

QUIC agreement brief introduction

QUIC Is based on UDP Realized , And is HTTP/3 The protocols that depend on , that , according to TCP/IP In terms of stratification , It belongs to the transport layer , That is, and TCP、UDP Belong to the same floor .

because QUIC It's not just the transport layer protocol , And you have TLS Security related capabilities of , therefore , It can be understood from the figure below QUIC stay HTTP/3 Position in the implementation of .


QUIC agreement Establishing a connection

TCP This reliable transport protocol requires three handshakes , It's also because of three handshakes , So it takes extra consumption 1.5 RTT, And if you add TLS Words , It needs to be consumed 3-4 individual RTT Connect .

QUIC A new connection establishment mechanism is proposed , Based on this connection mechanism , Realize the function of quick handshake , once QUIC Connection establishment can be realized by using 0-RTT perhaps 1-RTT To establish a connection .

picture ...

QUIC Use during the handshake Diffie-Hellman The algorithm ensures the security of data interaction and combines its encryption and handshake process to reduce the number of round trips in the connection establishment process .

Diffie–Hellman ( hereinafter referred to as DH) Key exchange is a special way to exchange keys . It is one of the earliest key exchange methods put into practice in the field of cryptography . DH Can make both sides in total lack of each other ( private ) Under the premise of information, a shared key is achieved through an insecure channel . This key is used for symmetric encryption of subsequent information exchange .

QUIC The whole process of connection establishment is roughly as follows :QUIC Use during the handshake Diffie-Hellman The algorithm negotiates the initial key , The initial key depends on a set of configuration parameters stored by the server , This parameter is updated periodically . After the initial key agreement is successful , The server will provide a temporary random number , According to this number, both parties generate the session key again . The client and server will use the new key to encrypt and decrypt the data .

The above process is mainly divided into two steps : Initial handshake (Initial handshake)、 Final ( And repetition ) handshake (Final (and repeat) handshake), Introduce the two processes respectively

Initial handshake

When the connection starts to be established , The client will send a greeting message to the server ,(inchoate client hello (CHLO)), Because it was the first time , therefore , The server will return a rejection message (REJ), Indicates that the handshake is not established or the key has expired .



however , This rejection message will contain more information ( Configuration parameters ), There are mainly :

  • Server Config: A server configuration , Including server side Diffie-Hellman The long-term public key of the algorithm (long term Diffie-Hellman public value)
  • Certificate Chain: The chain of trust used to authenticate the server
  • Signature of the Server Config: take Server Config Using the leaf certificate of trust chain public key Encrypted signature
  • Source-Address Token: An authenticated block of encryption , Contains publicly visible IP Address and server timestamp .

The client received a message at the time of rejection (REJ) after , The client will parse the data , Signature verification and other operations , After that, the necessary configuration will be cached .

meanwhile , On receiving REJ after , The client will randomly generate a pair of its own short-term keys for this connection (ephemeral Diffie-Hellman private value) and Short term public key (ephemeral Diffie-Hellman public value).

after , The client will package the short-term public key it has just generated Complete CHLO In the message package of , Send it to the server . The purpose of this request is to transmit your short-term key to the server , Easy to do forward secrecy



After sending Complete CHLO After the message is sent to the server , In order to reduce the RTT, The client doesn't wait for the server to respond , It's a data transfer right away .

In order to ensure the security of data , The client will calculate its own short-term key and the long-term public key returned by the server , Get an initial key (initial keys).

With this initial key , The client can use this key , Encrypt the information you want to transmit , And then they can be safely transmitted to the server .



Received Complete CHLO Requested server , After parsing the request , At the same time, it has the client's short-term public key and its own long-term key . So, by computing , As like as two peas, the server can get the same initial key as the client (initial keys).

Next, he receives the data encrypted by the client using the initial key , You can use this initial key to decrypt , And you can encrypt your response through the initial key and return it to the client .

therefore , From the start of the connection to the data transfer , It only consumes the initial connection established by the connection 1 RTT

Final ( And repetition ) handshake

The initial key can be used for subsequent data transmission (initial keys) Is it encrypted ?

It's not exactly , Because the initial key is generated based on the server's long-term public key , And before the public key fails , Almost every connection uses the same public key , therefore , There is a certain danger in this .

therefore , In order to achieve forward secrecy (Forward Secrecy) The security of , The client and the server need to use each other's short-term public key and their own short-term key for operation .

In cryptography , Forward secrecy ( English :Forward Secrecy,FS) It is the security property of communication protocol in cryptography , It means that the long-term use of the master key disclosure will not cause the past session key disclosure .

So now the question is , The client's short-term key has been sent to the server , The server only gives its own long-term key to the client , I didn't give myself a short-term key .

therefore , The server is receiving Complete CHLO after , Will give the server a server hello(SHLO) news , This message uses the initial key (initial keys) To encrypt .


This CHLO In the message packet , It will contain a short-term public key that the server regenerates .

In this way, both the client and the server have each other's short-term public key (ephemeral Diffie-Hellman public value).

such , Both the client and the server can operate based on their own short-term key and the other party's short-term public key , Generate a forward secret key for this connection only (Forward-Secure Key), Subsequent requests are sent , It's OK to encrypt and decrypt based on this key .

such , The two sides have completed the final key exchange 、 Connect the handshake and establish QUIC Connect .

The next time you re create the connection , The client will take the long-term public key of the server that it has previously cached from the cache , And recreate a short-term key , Regenerate a new key , Then use this initial key to encrypt the data you want to transfer , Send one to the server Complete CHLO The request can be . So that's it 0 RTT Data transmission of .



therefore , If it's a long-term public key with cache , Then the data transfer will go directly , The preparation time is 0 RTT

above , By using Diffie-Hellman The algorithm negotiates the key , And merge the encryption and handshake processes , Greatly reduce the connection process RTT , Make based on QUIC Less connections can be made 1 RTT even to the extent that 0 RTT.

Google There is a picture on the official website about QUIC Flow chart of connection establishment , Can help understand this process



in addition , Through the above process of handshake establishment , We can also know ,QUIC In the whole process, through the way of encryption and decryption, the security is well guaranteed .


be based on TCP The protocol of HTTP One of the biggest problems is the team head blocking problem , that , In this regard ,QUIC How to solve this problem ?

TCP During transmission, the data will be divided into packets arranged in order , These packets are transmitted over the network to the receiver , The receiver then combines these packets into the original data in order , This completes the data transmission .



But if one of the packets doesn't arrive in order , The receiver will remain connected and wait for the packet to return , This will block subsequent requests . That's what happened TCP Team head jam .



Be similar to HTTP/2,QUIC There can be multiple independent logical data streams on the same physical connection , These streams are transmitted in parallel over the same connection , And there is no timing requirement between multiple data streams , It doesn't affect each other .

Data flow (Streams) stay QUIC Provides a lightweight 、 Abstraction of ordered byte streams

QUIC A single stream of data can guarantee orderly delivery , But multiple streams may be out of order . This means that the transmission of a single data stream is sequential , However, the order in which the receiver receives data in multiple streams may be different from the sending order of the sender !

In other words, there is no dependency between multiple data streams on the same connection ( It is not required to arrive in order ), Even if a packet does not reach , This data stream only affects itself , It doesn't affect other data streams .



Connection migration

about TCP Identification of connections , Need to pass through both the server and the client ip And port four parameters . In the context of network switching , For example, cell phones switch networks , So the ip It's going to change . This leads to the previous TCP The connection will fail , You need to rebuild .

This scenario is for today's popularity of mobile devices , More frequently .

therefore , At this point ,QUIC optimized .

QUIC Protocol uses specific UUID Mark each time you connect , When the network environment changes , as long as UUID unchanged , You don't have to shake hands , Continue to transmit data .

HTTP/2 and HTTP/3 The differences and similarities

characteristic HTTP/2HTTP/3
Transport layer protocol TCP be based on UDP Of QUIC
Default encryption no yes
Independent data streams no yes
Team head jam There is TCP Team head jam nothing
Header compression HPACKQPACK
Handshake delay TCP+TLS Of 1-3 RTT0-1 RTT
Connection migration nothing Yes
Server push Yes Yes
Multiplexing Yes Yes
flow control Yes Yes
Data retransmission Yes Yes
Congestion control Yes Yes

author :zcwfeng
link :
source : Simple books
The copyright belongs to the author . Commercial reprint please contact the author for authorization , Non-commercial reprint please indicate the source .

copyright notice
author[baoleilei6],Please bring the original link to reprint, thank you.

Random recommended