Why Large File Downloads Still Need Integrity Verification Despite TCP Reliability

Hello everyone, I'm Fei! A few days ago I answered an interesting question on Zhihu and received many likes, so I’m sharing the insights here.

Even though TCP’s transmission process is reliable, large file downloads should still be verified for integrity. The reasons are as follows:

1) TCP’s reliable transmission guarantees retransmission when packets are lost or checksum errors occur, but CRC checks can only roughly detect errors and cannot ensure 100% data correctness.

2) The transport‑layer protocol only guarantees checks during transmission. If the sending process crashes before some data is sent, or if a resume calculation misses a segment during breakpoint continuation, that data never reaches the transport layer, so overall reliability cannot be assured.

3) During the HTTP era, data could be altered by intermediate operators motivated by profit (known as ISP hijacking). The widespread adoption of HTTPS has largely mitigated this risk.

4) The ACKs received by the TCP receiver’s transport layer only confirm that the kernel correctly received the packets. Whether the user‑space process has actually read the data is uncertain; the process might crash, a rare memory bit‑flip could occur, or a disk write error could happen even after correct reception.

All these errors represent scenarios that TCP’s reliability cannot cover. Therefore, for large file downloads, a final integrity check is essential.

For deeper understanding of network packet handling, you can refer to the following detailed articles:

Illustrated Linux Network Packet Receiving Process

Decomposing Linux Network Packet Sending Process