From quic to TCP

In recent days, ,IETF claim HTTP/3 Formally standardized as RFC 9114,QUIC As a bearer protocol . Write a paragraph , What I said must be interesting things that others don't talk about .

QUIC Packet Header Of Packet Number Fields make QUIC “ Confirm the data packet for each transmission , Instead of confirming the byte stream ”.

QUIC many Frame Reuse one Packet Make bearing HTTP More efficient .

QUIC Support 0-RTT Quickly build a company , But maintain session.

QUIC Implementation in user mode , Support rapid iterative upgrade , But it's also easier to do evil , For example, write a preemptive congestion control algorithm regardless of cost .

QUIC Built in security …

…

I am more concerned QUIC It's finally settled TCP Two problems that have been criticized ：

• Unable to distinguish between original message and retransmission message , Lead to RTT Inaccurate measurement .
• The sliding window is suffocated due to the empty serial number at the receiving end , Team head jam .

QUIC Really mapped IP Packet switching semantics , Byte streams are encapsulated in Packet in , Byte stream and Packet Be dealt with separately , End to end byte stream recognition , The transport only focuses on Packet, Flow control and congestion control can be more sophisticated ：

• flow control ：QUIC Flow control against quotas , Byte stream holes no longer easily suffocate windows .
• Congestion control ：QUIC in the light of Packet Scalar feature sampling without concern for continuous byte streams .

QUIC Pay attention to... At the transmission level Packet Instead of focusing on byte streams , after TCP Then the byte stream and Packet Comprehensive consideration , So much so that TCP In fact, there is no Packet , Only byte streams , End to end and network must not be balanced .

All this benefits from QUIC Complex protocol headers , Complex protocol headers enhance expressiveness , Of course you can do more .

If the QUIC regard as TCP The optimization of the , review TCP, We found that TCP Has been committed to optimizing all these aspects ：

• increase SACK It can judge packet loss more accurately , Higher retransmission efficiency .
• Added congestion control , Until more efficient CUBIC/BBR .
• Add timestamp option to make RTT More accurate measurement .
• RACK Trying to separate the transmission time order from the byte order .
• FastOpen Trying to shorten the build time .
• …

but TCP The limited protocol header finally stops these in the middle . Finally redesigned QUIC With stronger header expression ability TCP The problem of .

So it will QUIC regard as TCP It makes sense to optimize ,QUIC Commitment and TCP Exactly the same , reliable , Keep the order .

Interestingly , And vice versa , If time goes backwards ,TCP It can also be regarded as QUIC The optimization of the .

Suppose at first there was no TCP, and QUIC Already deployed , Stable operation 30 year , Today, someone suddenly put forward TCP ( finger 1984 Year of TCP, No congestion control , no SACK, No timestamp , No more RACK, Only GBN) What will happen .

It will definitely cause a sensation in the industry , The explosive effect must be today QUIC The effect is much greater .

People are sure to shout TCP To optimize the QUIC ：

• People are surprised at TCP It is reliable to use such an intensive and compact protocol header , Order preserving semantics .
• People are surprised at GBN and RTO It can be so simple to ensure reliable transmission .
• People are surprised that fast retransmissions can be received continuously 3 A repetition ACK To inspire .
• People are surprised at TCP The sliding window has completed sequence preservation and flow control at the same time .
• …

All this surprise benefits from , People found that the transmission of Packet Can be with TCP Semantic byte streams are considered together , Direct transfer byte stream .

TCP Removed QUIC Data confidentiality , integrity ,TCP say , This is the responsibility of the application itself ,TLS At most, it is the security addition of the transport layer .

It's wonderful ,TCP Realized QUIC The semantics of the , But so thin , This is the most perfect optimization ！ And so on , And? …

TCP You need to shake hands and wave hands every time you establish a connection , The server does not need to save any session, Free up maintenance costs .

TCP Maintain an independent connection state for each byte stream , The state machine has a perfect closed loop . The independent connection state makes it possible to PHB( Hop by hop behavior ) Functional devices make it easier to recognize and manipulate byte streams .

Refined TCP No more , No less , Very stable ,TCP Placed in the operating system as the common denominator , Applications no longer need to link to transport protocols themselves .

People can't see TCP GBN and RTO Resulting in congestion collapse , People can't see the blocking of the sliding window , All the details were ignored , People resolutely abandon QUIC , hug TCP.

A big congestion crash a few years later ,TCP Added congestion control , And then I put forward SACK To optimize retransmission efficiency , And then … Until people realize QUIC It's solved TCP Almost all of these problems .

This is a tail biting snake .

QUIC yes TCP Performance optimization of ？ If you don't always think about performance ,TCP yes QUIC The optimization of ？ After all QUIC Many bloated operations are TCP Can be done in a fairly simplified way .

If only throughput is considered ,QUIC Than TCP good , Speaking of resource occupancy ,TCP Better . If you say TCP Out of date , They are all aimed at a certain feature , such as TCP It is not suitable for transmitting live streams , Really not suitable for . such as TCP Downloading large files is inefficient , It's really low , But remote login is very suitable .

It's interesting , If you consider it as a whole , No matter from TCP To QUIC, Or from the QUIC To TCP, Or self-developed lossy transmission protocol , How to optimize , Losses are conserved as a whole ：

• QUIC The more complex the protocol header , The lower the load rate , All but the payload are losses .
• TCP Streamlining , Weak expression skills can misjudge , The bandwidth encroachment of invalid retransmission and the time waste of delayed retransmission are both losses .
• FEC Occupy the effective bandwidth before packet loss ,ARQ Retransmission encroaches on the effective bandwidth after packet loss , All losses .
• Lossy transmission loss information itself is loss .

Loss is inherent , It's also interesting , See what price to exchange , Resources can be exchanged , You can change it with time , Or simply accept the loss , But the loss must not be eliminated .

QUIC,TCP, Other transmission protocols , Are responding in different ways ( The input method appears as “ Hard connection ”, It's OK ) loss , The inherent loss is determined by the Shannon limit ：

Shannon limit （ Or Shannon capacity ） It refers to the theoretical maximum transmission rate for error free transmission on the channel , It is the theory of Shannon theorem on the channel with limited bandwidth . let me put it another way , When the signal transmission rate has not reached the Shannon limit , A zero error rate coding method can be found .

So what if we haven't reached the limit yet ？ The unachieved waste itself is another kind of loss .

The manager pays great attention to his hairstyle , The manager has a haircut every few months .

Zhejiang Wenzhou leather shoes wet , It's not fat when it's raining .