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

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 TCP packets 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 Modubs protocol for serial because of there is already a checksum in TCP packets.

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

ADDED: After 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?

The SHA checksum is used to verify integrity, i.e. that the data was not intentionally modified, while the CRC is meant to protect against bit errors.

The CRC can not be used for tamper resistance, because it can be trivially recomputed after modifying the data.

The TCP checksum is even simpler than a CRC, so its presence is more of a formality these days. Most link level protocols have their own checksums or error correcting codes, so bit errors have become unlikely, but they used to be common with RS-232 links.

The SHA checksum alone does not provide protection, because it also needs to be transmitted, but if you can establish a secure channel for the checksum, it is possible to use an insecure channel for the bulk data and then verify it against the SHA checksum, and be reasonably sure that the data has not been tampered with.