If the data that are being encapsulated have the possibility of corruption while crossing over the wire, what is stopping the TCP checksum itself from being corrupted, and if it also can be corrupted, why is it considered reliable data transfer?
To strictly answer the questions:
- Can the checksum itself be corrupted? Certainly, the noise sources have no idea whether they are corrupting data bits or checksum bits
- What happens if only the checksum itself is corrupted? The calculated value by the receiver is certain to fail the match.
- If checksum and data are corrupted, t(as given in the first answer) it's very unlikely to match.
While checksums in general have the characteristic that there are many messages which identical checksums (after all, we're going from perhaps 1Kbyte packet to 16 bits), many real life checksums have surprising good and bad properties. For example, IP checksum is guaranteed to detect all 1-bit errors; but fails to detect byte swaps. Real communications lines have certain errors much more common than others: much more common to get "all bits arrive as 0" for a short period for example, and "bytes are swapped" is more or less impossible.
For a deeper understanding
RFC 1071 "Computing the internet checksum" https://tools.ietf.org/html/rfc1071
Stone Greenwald Partridge Hughs (1998) "CRC and checksums on real data" http://ieeexplore.ieee.org/document/731187/ or earlier version available in full text http://ccr.sigcomm.org/archive/1995/conf/partridge.pdf
Wood Eddy McKim Ivancic (2007) "Checksum coverage and delivery of errored content" http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.131.7753&rep=rep1&type=pdf
Hope that's helpful
If the TCP checksum is corrupted, then it will not match the TCP pseudo header and payload. There should only be one checksum that matches the pseudo header and payload, but there are multiple TCP pseudo header and payload combinations that will resolve to the same checksum. It is a one-way function.
There is no completely reliable way to communicate over a network. Even if a second copy of the payload is used as a checksum, it is possible that both copies get corrupted in exactly the same way. The odds of that are very low, but that greatly increases the number of bits sent, impacting the throughput.
What the checksum does is gives you a good chance that your data are not corrupt, and it is very small and quickly, easily calculated.
What TCP reliability really means is that the data are guaranteed to be delivered, and in order, to the application. This is accomplished by handshaking and acknowledgements. Contrast this to UDP, an unreliable protocol, that gives no such guarantee, not even that the data will reach the destination.
what is stopping the TCP checksum itself from being corrupted,
and if it also can be corrupted, why is it considered reliable data transfer?
If either the checksum, the data or both are corrupted then most likely the checksum will not match and the packet will be discarded (and later retransmitted). However there is a possibility that the checksum will match dispite the corruption.
In general most networks rarely corrupt packets and the TCP checksum rejects most of those that do get corrupted, so the overall probability of delivering a corrupted packet so the application is acceptably low on most networks. However if you have a network that frequently corrupts packets and you transfer a large ammount of data then the TCP checksum starts to look sorely inadequate.