Why TCP will not be replaced

The reasons for "complaining" about TCP are almost all these sentences:

• TCP’s congestion control algorithm actively reduces throughput when packets are lost;
• TCP's three-way handshake adds latency and overhead to data transmission;
• TCP's cumulative acknowledgment mechanism results in the transmission of data segments;

In the end, it comes down to this: in a weak network environment, TCP efficiency will drop significantly, so Google's QUIC is the tool to liberate productivity - after all, they have already adopted HTTP 3.

[[312955]]

What is a weak network?

Weak network generally refers to wireless network, LTE (4G) and Wifi belong to this type of network. The network is evolving towards mobility and unboundedness. Limited by the development of access technology, wireless access faces the dual challenges of coverage and higher bandwidth. This situation can be understood as an "unstable physical link". It is not like Ethernet wired access - it is either connected or not connected, but there will be a "bandwidth" that is too small to transmit a packet header (commonly known as "poor signal") or a direct "physical disconnection". This is not caused by congestion, QoS or the server side not being able to handle it in time during network transmission, but due to the technical bottleneck of the wireless network access technology itself.

Betting on the future

Technology will only develop in a positive direction. The current technical "end point" of Wireless Network is 5G. Yes, don't think that 5G will only replace mobile phone access. The problem of Wi-Fi signal strength can only be solved by "cellular technology", and the most advanced cellular technology is 5G. In short, 5G will bring:

• Provide better wireless access physical links through higher frequency bands, better modulation and demodulation, and more powerful antennas;
• By reducing latency at edge nodes;
• Provide more efficient and flexible networking methods through NFV and cloud-network integration;

If you bet on the future, then there may not be a "weak network" in the future. So when I saw that the "foresighted IETF" passed QUIC to become the HTTP3 draft, I was confused. HTTP2 is not yet popular, and the big guys are already busy formulating HTTP3 - and with their knowledge, they should be able to see that 5G will definitely mature earlier than HTTP2, so why are they so eager to formulate HTTP3? Later I figured it out - there is no rule that "KPI projects" can only be used by our country. If we are allowed to "open source KPI", we must allow others to "standardize KPI". Google has always wanted to make a difference on the Internet, so it must "make a difference".

Solve the present

Answer a question: As an application, what kind of protocol do you need?

• If you don't want packet loss to occur, you must have an ACK mechanism;
• If you want the data to be in order, you must allocate a "buffer" to reassemble the data packets within a certain period of time;

Following this line of thought, the result must be - sliding window, congestion algorithm, ACK mechanism, so when you need a reliable protocol, the conclusion must be TCP protocol, and when you try to create a "new" reliable protocol, you are almost reinventing TCP. In the end, the focus of everyone's debate can only be - the timing of ACK, how to set the sliding window size, how to optimize RTO and other issues.

As for the three-way handshake, it is not the point of the problem at all. The concept of "session" is needed from the design point of view, and the handshake process of establishing a session does not bring very obvious network overhead.

The real problem that the "weak network" we are talking about now is that if the network is almost unable to communicate, the application must know in time and take feedback actions (stop network requests, prompt that the network cannot be connected)

Take WeChat as an example. In a weak network, TCP's RTO (retransmission timeout) is calculated dynamically. If a network problem occurs, the application cannot quickly perceive it. Social applications are very sensitive to "feedback", so "weak network optimization" is required. The most thorough way to solve this problem is to modify the protocol stack. However, an application should not mess around with the kernel. Therefore, a set of "engineering" methods are used to solve this problem, such as Fast Recovery, HARQ, connection pool, merged connection and other extreme methods.

If a protocol wants to replace TCP, it must be re-implementing TCP

The network of the future will have better access experience, larger bandwidth, lower latency, more flexible networking methods, and more efficient communication. So if the problem domain that a technology is trying to solve is a very "narrow" field, then it really shouldn't become a "trend" or even a standard. A viable technology should provide mechanisms rather than strategies. Solving "current problems" is a strategy, just some methods forced out to make a living.