| TCP is fine. There is some questionable things here and I'll just touch on a couple of them. 1) TCP checksums are a bit weak. The author claims that we don't know how many errors are not caught by TCP's CRC and while that's true on some level the probability of bit errors is driven by properties of the physical medium over which the packet is traveling, not the transport layer protocol in use. That's why most, if not all, physical layers that do have a significant chance of bit errors have FEC built-in at the physical layer. As a point of reference, I pulled stats on one of our servers and see about 10k bad packets out of 1.3 billion. If we assume that bit errors caused all 10k, we get an error rate of about %0.00076. Since we need two independent bit errors to trigger a state where the CRC might not catch the error, we can calculate that on this particular server we would expect .076 packets that might be corrupt in a way in which it's even possible for the existing checksum would miss it (and it probably would still be caught). If that is an unacceptable error rate, you should absolutely be using some way to verify message integrity at a higher layer. Still, for most applications, a fast hash that lets a bad packet through every couple of years is a good trade-off. 2) TCP's over-eager in-order delivery The author talks about getting packets 1,3,2 in that order in the context of a file transfer, and in that specific scenario, it might be marginally preferable. Far more likely than out of order packets are lost packets and lost packets may never come if the connection gets closed/reset before its retransmitted. For the vast majority of applications having a partially transferred entity isn't helpful, but not having to deal with the complexity of out of order and partial transfers is. |
This issue, however, is so overblown by the author. It's not that often earlier packages delayed and new packages arrive faster and when that happens often you problem is usually much greater than server waiting for 101-200 before sending 201-300 to application...
To me the most annoying part of TCP are:
- Slow Start - Single channel - Single Mode
Everyone life would be so much better if within a single established connection you could open multiple channels in multiple modes like framed vs stream. Each channel could have its own order with congestion control overseeing entire bunch of channels.
You can build something similar on top TCP today, but it's not the same. Best part of TCP is that it's a standard available everywhere without conflicting implementations.