Is it redundant to add an extra checksum or CRC in TCP payload to make it possible for the receiver verify whether the data is same with the sent one?

Question

As TCP contains a checksum, and the TCP/IP stack will detect broken packets, is it redundant to add an extra checksum or CRC in a TCP payload (I mean the user data which could be read out by the socket api on the remote end), to make it possible for the receiver verify whether the data is same with the sent one?

Some thought about this question:

1. It's very common seen that there is a SHA256 value to verify the consistency when downloading files from internet.

2. The checksum contained in TCP packets already could detect broken packets in most cases.

3. The Modbus protocol for TCP dropped the CRC, which is used by the Modbus protocol for serial because there is already a checksum in TCP packets.

So, I am really confused now. Could somebody shed some light on this question?

I have googled, it's really not a new question, but the answer is still not clear, there are two opposite voices about this question.

For details, see these:

CRC checking done automatically on Tcp/Ip?

Is it possible for packets sent using TCP to ever arrive with different data?

ADDED:

The two questions aforementioned have been there for more than ten years! But there are still two opposite voices.

Answer 1

TCP has a checksum, which provides only some protection, simply because the checksum is only 16bit. For how much robustness the TCP checksum actually provides, or how much it is lacking, see Can a TCP checksum fail to detect an error? If yes, how is this dealt with?.

If you need more protection, you need to have additional and longer protection, because the more bits are used in protection, the better protection can be provided. If you need protection against active tampering with the traffic (ie not just accidental errors), you also need a cryptographic protection, such as offered by TLS.