Quic resistance

HTTP/3 Standardized , When QUIC Can plug in all over the world ？

Not so fast , Even very difficult .

I have a lot of ideas about transport protocol optimization , Occasionally, several , But this is crazy , It has no general meaning . It is easy to design or optimize a protocol , But deploying a protocol is very difficult .

TCP That's the problem , How to solve them is obvious , Ten people can have ten plans . But get everyone to agree to your new agreement to replace TCP, Need motivation , Whether it's technical , It's still economical . Best outcome , Probability also coexists .

Deploy QUIC The resistance of the ：

• Operator support .
• Software compatibility .
• Protocol universality .

What is mentioned most is that operators are right UDP Not friendly .

In the vast majority of cases , Any unfriendliness is to dislike the high management cost .

Unless QUIC Form a set of standard management interfaces ,QUIC The management cost will not decrease , This management cost is deployment QUIC The resistance of the .

All management , Finally, the management of data objects should be implemented , That is, the allocation of data structures , lookup , modify , The destruction , In the final analysis, it is CPU Cycles and memory , Or time complexity and space complexity , That's money .

First, check the status of the equipment , Such as stateful firewall ,NAT.

TCP Built in closed-loop state machine , Network devices can use state machines to TCP Traffic management . received SYN Just create a stream , received FIN or RST Start destroying a stream , This is a passive management , Just simple parsing TCP The flag of the header can realize the operation of the flow .

and UDP There is no state available , How to manage the data structure depends on initiative . For example, create a flow , If based on five tuple recognition UDP flow , but UDP Ports can be changed at any time , If based on other fields , Is this field standardized ？ When to destroy a stream , Only by timer , How long is the timeout ？

Or create new streams frequently CPU cycle , Either the Dead Zombie stream is stuck and memory is consumed , It's hard to find a balance .

Look at stateless devices , Such as standard router , The speed limit , A firewall , Stateless load balancing device .

Stateless devices also generally classify packets based on tuple hash values , Or match based on exact quintuples ,UDP Variable tuple information makes it difficult for these devices to work efficiently or even correctly .

Whether it is a stateful device or a stateless device , Yes UDP It is difficult to identify and control the flow , Suppose success limits one UDP flow , It changes the source port , Everything has to be done again .

When management costs are high , One size fits all is the best strategy , Yes UDP Traffic , If the threshold is not exceeded , Let go , Once the bandwidth exceeds the threshold , Just drop the packet , That's why UDP It can fly when it is fast , The reason for the mess when it was bad .

To guarantee TCP The flow of QoS, Yes UDP If the traffic is not friendly, it is not difficult to understand .

QUIC It perfectly solves the problem of flow identification .QUIC Use a negotiated Connection ID Identify a flow , And five tuples . No matter how the address port is translated , As long as the packet can reach its destination ,QUIC Can receive correctly .

QUIC Stream identification no longer relies on fixed tuples , The port can even actively change the address to support mobility or concealment , This means that the difficulties related to flow identification and packet classification are left to the forwarding device . The flow identification and packet classification mechanisms based on fixed tuples have failed .

QUIC Generally, the content provider recommends the deployment , The client from QUIC Get a committed experience , Content providers also get traffic , But the operators did not get direct benefits , So what are the incentives for equipment manufacturers and operators to upgrade ？

In addition to operator resistance , Let's look at compatibility resistance .

Home APP Connect to your own server , This is easy to handle. , The server and APP Coordinate the rhythm ,AB Smooth upgrade .

But how should browser manufacturers implement a general browser , Do you want to use HTTP /3 Try it first , No more HTTP /2, No more fallback To HTTP /1, This obviously only supports HTTP /1 The service is unfair , The service performance is not poor , It is the pot of browser compatible operation , Can this unfairness promote the upgrade of the server ？ not necessarily .

Initiate three at the same time HTTP Version request , Whichever comes back first counts , It feels good , But this behavior is not clean , The Internet will be flooded with such garbage traffic , Especially short connection , There will be nearly three times the request traffic ,QUIC Are the benefits of short connections greater than three times the traffic cost ？ not necessarily .

QUIC Emphasize that you implement it in user mode , This is also QUIC One of the selling points of . But I think it's a big resistance . For existing applications , by QUIC What are the motivations for upgrading ？ To put a HTTP/TCP Application migration to QUIC, The difficulty can only be imagined . For newly developed applications , To support its direct use QUIC, Need a lot of Libraries , Middleware directly provides QUIC Interface , How motivated are you to develop these interfaces .

TCP Criticized for being built into the operating system , Change TCP It is necessary to change the operating system , However QUIC Can you really customize it at will ？ It may be enough to change the operating system once , If QUIC Modify Library , Modify middleware , library , Is the workload of upgrading middleware really less than that of operating system ？ If you have upgraded libc, Evaluate , upgrade Linux Kernel and upgrade libc, Which is more difficult ？

alike ,QUIC Emphasize your built-in security , However, for applications that do not need security , How difficult and costly is it to split security support ？

Assume the above , Whether operators or software manufacturers , No motivation to deploy QUIC, So someone said , If QUIC Good enough. , They must be forced to support QUIC And deploy QUIC.so ？

Last , Let's look at the universality of the protocol .

thorough QUIC details ,QUIC At high packet loss , It solves the problem of TCP Unsolvable problems , Whether separated from the byte stream Packet Number Or independent ACK Frame, Are subject to TCP The powerless method can judge the packet loss more accurately and retransmit more efficiently , meanwhile , Its built-in multiplexing and improved sliding window allow multiple Stream parallel , Solved the problem of team head blocking ( Although not so thorough ). But what can this do ？ The actual network environment , How many scenarios do the above optimization measures just need ？

Obvious , The above optimization measures are beneficial to Wi-Fi The weak net is the more the better , can Wi-Fi The weak net is also getting stronger . If the bottom layer is improved ,Wi-Fi Gradually not weak ,QUIC Is the advantage still obvious ？

although QUIC In any scenario, it may be better than TCP Well, then , But this difference will strengthen the deployment QUIC Your motivation ？

TCP Although the performance is not good , But general enough ,QUIC It's not universal ,QUIC Just claim to be in TCP Where it is not done well enough, it can do better , But it's just a claim , Not a promise . stay TCP Enough scenes ,QUIC Obviously there is no need , Such as remote login , Signaling transmission ,pingpong agreement .

obviously ,TCP Must be with QUIC Long term coexistence . Interestingly , As long as the goal is not completely replaced TCP, The thing itself is QUIC The biggest obstacle to deployment . Even in order to completely replace TCP, have a look IPv6 Replace IPv4 The process is enough , What a clear goal , But progress has been so slow , Probably this kind of replacement will never be completed .

QUIC It's not a new agreement , I put TCP Referred to as A, that QUIC Namely A+, It's just about TCP Some pain points in some scenes , Solve problems pertinently , That's why ,QUIC It is only suitable for those who have TCP The scene of pain points , For other scenarios , Good but not necessary .

I haven't mentioned it yet QUIC The cost of these gains . More complex protocol headers , More complicated analysis , Higher CPU And memory , If you don't need or can't afford those more or less benefits , Is it worth the effort ？ The price of Tomson's flat floor is reduced 50%,8000 Ten thousand hands , Expensive is expensive , Still can't afford .

QUIC be relative to TCP Performance improvement of , In essence, it is the result of the enhanced expression ability of the protocol header ,RTT The measurement is more accurate , Packet loss judgment is more accurate , Under normal conditions, there is no packet loss , There is no difference . That explains why QUIC Better in weak network environment , When the quality of the network is good, it is not unusual .

QUIC There is no lower limit to improve transmission performance , Just raised the upper limit , The upper limit is not easy to reach .

It's like an exam , Ability determines the maximum score , Your ability determines that you cannot pass the exam 100 branch , But I can't pass the exam either 0 branch , No matter how tossed , Your score always hovers between the score of random guessing and the score of your ability limit .TCP yes 70 branch ,QUIC Namely 80 branch , that TCP My grades are always 50～70 Section , and QUIC The result is 50～80 Section . The weak net sees the upper limit , A good network looks at the lower limit , This is fundamental .

TCP May never be replaced , There may no longer be an agreement to replace TCP, Probably TCP Has been and IP The same , Just as they were meant to be together .

in the light of TCP Block data transmission pain points ,QUIC Maybe just one of the solutions , For live streaming ,QUIC Far from being competent , Other transport protocols may be required , But certainly with TCP/QUIC Completely different .

Recently standardized HTTP /3, People are boiling , Circle of friends , Microblogs are forwarding , Some people even found Ali's XQUIC, Thousand boiling water PR, Dig out Akamai, Japanese operators ,Google … I'm going to pour cold water again .

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