Является ли избыточным добавление дополнительной контрольной суммы или CRC в TCP-пакеты, чтобы получатель мог проверить, совпадают ли данные с отправленными?

Поскольку TCP содержит контрольную сумму, а стек TCP/IP обнаружит поврежденные пакеты, не будет ли излишним добавлять дополнительный контрольная сумма или CRC в TCP-пакетах, чтобы получатель мог проверить, совпадают ли данные с отправленными?

Некоторые задумались над этим вопросом:

1. Очень часто встречается значение sha256 для проверки согласованности при загрузке файлов из Интернета.

2. Контрольная сумма, содержащаяся в TCP-пакетах, уже могла в большинстве случаев обнаруживать поврежденные пакеты.

3. Протокол Modbus для TCP отбросил CRC, который используется протоколом Modubs для последовательного соединения, поскольку в TCP-пакетах уже есть контрольная сумма.

Итак, я действительно запутался сейчас. Может ли кто-нибудь пролить свет на этот вопрос?

ДОБАВЛЕН: После того как погуглил, вопрос действительно не новый, но ответ до сих пор не ясен, есть два противоположных голоса по этому вопросу.

Для получения подробной информации см. эти:

Проверка CRC выполняется автоматически на Tcp/IP?

Могут ли пакеты, отправленные с использованием TCP, когда-либо приходить с разными данными?

Контрольная сумма SHA используется для проверки целостности, т. е. того, что данные не были намеренно изменены, а CRC предназначена для защиты от битовых ошибок.

CRC нельзя использовать для защиты от несанкционированного доступа, потому что его можно тривиально пересчитать после модификации данных.

Контрольная сумма TCP еще проще, чем CRC, поэтому ее наличие в наши дни является скорее формальностью.Большинство протоколов уровня канала имеют свои собственные контрольные суммы или коды исправления ошибок, поэтому битовые ошибки стали маловероятными, но раньше они были обычным явлением для каналов RS-232.

Сама по себе контрольная сумма SHA не обеспечивает защиты, потому что ее тоже нужно передавать, но если вы можете установить безопасный канал для контрольной суммы, можно использовать небезопасный канал для массива данных, а затем сверять его с контрольной суммой SHA, и быть разумно уверенным, что данные не были подделаны.