TCP has another unfixable flaw - it cannot be properly secured. Writing a security layer on top of TCP can at most detect, not avoid, attacks.

It is very easy for a malicious actor anywhere in the network to inject data into a connection. By contrast, it is much harder for a malicious actor to break the legitimate traffic flow ... except for the fact that TCP RST grants any rando the power to upgrade "inject" to "break". This is quite common in the wild for any traffic that does not look like HTTP, even when both endpoints are perfectly healthy.

Blocking TCP RST packets using your firewall will significantly improve reliability, but this still does not project you from more advanced attackers which cause a desynchronization due to forged sequence numbers with nonempty payload.

As a result, it is mandatory for every application to support a full-blown "resume on a separate connection" operation, which is complicated and hairy and also immediately runs into the additional flaw that TCP is very slow to start.

---

While not an outright flaw, I also think it has become clear by now that it is highly suboptimal for "address" and "port" to be separate notions.

> While not an outright flaw, I also think it has become clear by now that it is highly suboptimal for "address" and "port" to be separate notions.

If we fixed that issue, what would be different? The operating system still needs to assign different addresses to different sockets. So now... we have 48-bit addresses, and instead of reserving one "address" and giving each socket a 16-bit port, we reserve a /32 block of 65536 addresses and give each socket its own address with a unique 16-bit suffix?