If TCP is a reliable data transfer method, then how come its checksum is not 100% reliable?

Question

So in the networking book by Kurose, we define UDP as a unreliable method because it might not detect errors and therefore transfer a corrupted packet or transfer the data without the order so its not good for important stuff like emails

then it says TCP is a reliable method because it can gurantee data transfer without corruption, and in order, but based on this topic :

https://stackoverflow.com/questions/3830206/can-a-tcp-checksum-fail-to-detect-an-error-if-yes-how-is-this-dealt-with

Something that should be noted here, and that most people overlook completely, is the fact, that the TCP checksum is actually a very poor checksum.

so the checksum of TCP is no good at all?!

so how can TCP be a reliable method when there is a chance that it transfers a corrupted packet and the end system won't notice it? how is this even possible?

because for example i have not received an email with a corrupted message, is it even possible?

Answer 1

No checksum is 100% reliable. The more reliable the error detection, the more computational power you need. It's a tradeoff between reliability and speed/processing power.

The TCP checksum was limited by available computing power at the time. It gives you 99.9984% assurance that your data has not been corrupted by single bit errors. The developers assumed that if stricter error checking was required, it would happen at the application layer.

Answer 2

So in the networking book by Kurose, we define UDP as a unreliable method because it might not detect errors and therefore transfer a corrupted packet

No, we define UDP as an unreliable protocol because it takes no measures to ensure that the data is actually delivered in the event of problems on the underlying network. It also takes no measures to ensure that the data is delivered in the correct order if the underlying network re-orders packets.

In terms of protection against corruption UDP uses the same checksum that TCP does (technically it's optional but in the vast majority of cases it is used).

so the checksum of TCP is no good at all?!

It depends.

To estimate how likely an application is to experiance corruption we need to answer several questions first.

1. How much data is being transfered.
2. What proportion of packets get corrupted in the first place.
3. Are there lower level checksums? if so how effective are they? (both in terms of the effectiveness of the checksum itself and in terms of whether particular error sources are gaurded by it)
4. What if any similarities are there between any checksums used by lower layers and the checksum used by TCP. Do these similarities increase the probability of a corrupted packet passing both checks over what would nievely be assumed.

The answers to these questions and hence the probability of corruption will vary massively, from extremely unlikely at one extreme to almost a certainty at the other. People moving a few megabytes of data over high quality networks will get a very different answer than people moving terabytes of data over terrible networks.