The Drawbacks of TCP: Upgrade Difficulty, Connection Latency, Head‑of‑Line Blocking, and Migration Overhead

Hello everyone, I’m Xiao Lin.

I have written many articles about TCP, and after doing so I began to wonder whether TCP’s mechanisms—sequence numbers, acknowledgments, retransmission timeouts, flow control, and congestion control—truly make it a perfect, flaw‑free protocol.

In this post I will discuss four major drawbacks of TCP:

Upgrading TCP is difficult

TCP connection establishment incurs latency

TCP suffers from head‑of‑line blocking

Network migration requires a new TCP connection

Below is a detailed analysis of each point.

Upgrading TCP Is Difficult

TCP was created in 1973 and many new features are still being added, but the protocol is implemented inside the operating‑system kernel, so applications cannot modify it directly. To upgrade TCP you must upgrade the kernel, which involves updating low‑level libraries and retesting all services for compatibility, making kernel upgrades slow and conservative.

Many TCP enhancements, such as TCP Fast Open, require both client and server support. Even though TCP Fast Open was proposed in 2013, widespread adoption is delayed because many desktop operating systems are still on older versions that do not implement the feature.

TCP Connection Latency

Applications built on TCP (e.g., HTTP/1.0, HTTP/1.1, HTTP/2, HTTPS) must complete a three‑way handshake before any data can be transferred. When HTTPS is used, a TLS handshake follows, adding further delay.

The combined TCP three‑way handshake and TLS handshake latency is illustrated below:

TCP Fast Open reduces the latency of the second connection establishment by allowing the server to embed an encrypted Cookie in the SYN‑ACK. On the next connection the client includes this Cookie in the SYN, enabling the server to skip the full three‑way handshake and reduce the round‑trip time from two RTTs to one.

However, TCP Fast Open requires both ends of the connection to support the feature, and many older operating systems do not, limiting its practical adoption.

Because TCP operates in the kernel while TLS runs in user space, the two handshakes cannot be merged, and TCP sequence numbers remain unencrypted, exposing the protocol to certain security risks such as forged RST packets that can terminate connections.

Head‑of‑Line Blocking in TCP

TCP is a byte‑stream protocol that must deliver data in order. If a packet with a lower sequence number is lost, higher‑numbered packets cannot be delivered to the application until the missing packet is retransmitted, causing head‑of‑line blocking.

This behavior is necessary to preserve ordering, but it also means that a single lost packet can stall all streams multiplexed over the same TCP connection, such as HTTP/2 requests.

Network Migration Requires New TCP Connections

TCP connections are identified by a four‑tuple (source IP, source port, destination IP, destination port). When a mobile device switches from 4G to Wi‑Fi, its IP address changes, forcing the existing TCP connection to be torn down and a new one to be established.

The new connection incurs the TCP three‑way handshake, TLS handshake, and TCP slow‑start, which users perceive as a brief network stall, making connection migration costly.

Conclusion

During a recent interview, a candidate was asked how to implement reliable transmission over UDP. While one could re‑implement TCP’s reliability mechanisms at the application layer, it is worth asking why we would reinvent the wheel when TCP already provides reliability.

Many of TCP’s pain points—upgrade difficulty, handshake latency, head‑of‑line blocking, and migration overhead—are addressed by the QUIC protocol, which runs over UDP and powers HTTP/3.

In a future article I will explore how QUIC achieves reliable transmission and overcomes these TCP shortcomings.