Может ли контрольная сумма TCP не обнаружить ошибку? Если да, то как с этим бороться?
=====================================================================================

Если данные TCP повреждены при передаче, пересчитанная контрольная сумма не будет соответствовать переданной контрольной сумме. Отлично, пока все хорошо.

Если контрольная сумма TCP будет повреждена при передаче, пересчитанная контрольная сумма не будет соответствовать теперь поврежденной контрольной сумме. Отлично, пока все хорошо.

Что происходит, когда и полезная нагрузка, и контрольная сумма повреждаются, а пересчитанная контрольная сумма, хотя и отличается от того, что должно быть, просто совпадает с теперь поврежденной контрольной суммой?

Я могу видеть с хорошим алгоритмом контрольной суммы (и дополнительными контрольными суммами на более низких уровнях), это может быть очень, очень маловероятным, но разве TCP не должен быть на 100% надежным? Как это разрешает эти ложные срабатывания?

Некоторые из них более строгие, чем контрольные суммы, например Ethernet использует[CRC](https://en.wikipedia.org/wiki/Cyclic_redundancy_check) вместо контрольной суммы.

это может быть очень, очень маловероятно, но разве TCP не должен быть надежным на 100%? Как это разрешает эти ложные срабатывания?

Я не думаю, что это возможно. Даже если он отправит дубликат через печатного носителя и почтового голубя, космический луч или квантовые эффекты теоретически могут исказить дубликат тоже точно так же. Это просто очень, очень маловероятно.

Вы также можете реализовать произвольно строгую проверку целостности на уровне приложений (выше TCP), например, используя криптографическую подпись.



полезная нагрузка пакета: 1000 байт

контрольная сумма пакета: 2 байта

вероятность пакета с двойной ошибкой, одна из которых в контрольной сумме (предположим, что P очень мало, меньше 1/10 ^ 5):

вероятность точной контрольной суммы:

вероятность ложного срабатывания:

Вероятность низкая (P = 1/10 ^ 6, тогда вероятность ложноположительного A * B = 4/10 ^ 11), но в любом случае с любым алгоритмом crc она не может быть нулевой. Вероятность появления случайного 1000-байтового пакета в виде другого случайного 1000-байтового пакета составляет P ^ 8000, как если бы все байты содержали ошибки.

Если P высокое, например, от 1/10 ^ 3 до 1, приведенные выше вычисления не применяются. В этом случае A = 1 (все пакеты содержат двойные ошибки), а вероятность ложного срабатывания равна A * B = 6/10 ^ 4. Это не очень актуальный случай, потому что более 99% полученных пакетов будут содержать ошибки в crc.



[Эта бумага](https://portal.acm.org/citation.cfm?id=347561&dl=GUIDE&coll=GUIDE&CFID=106734705&CFTOKEN=32083801) упоминает 1 из 16 миллионов до 10 миллиардов пакетов, не обнаруженных системой контроля ошибок. Я позволю вам рассчитать события в день / неделю :)



 что вероятность составляет один на миллиард миллионов каджиллионов, потому что если данные TCP повреждены, что является транспортным уровнем, это также будет означать, что другие уровни (канал данных и сеть) также будут повреждены. Я полагаю, что, по крайней мере, уровень канала данных имеет контрольную сумму на целостность, поэтому вам придется потерять обе контрольные суммы.

Коррупция таким образом, что по крайней мере две отдельные контрольные суммы терпят неудачу, астрономически маловероятна, возможно даже невозможна.



 что большинство людей полностью упускают из виду тот факт, что контрольная сумма TCP на самом деле очень плохая контрольная сумма.

Контрольная сумма TCP представляет собой 16-битную сумму данных с одним дополнением. Эта сумма поймает любую пакетную ошибку 15 бит или меньше, и все 16-битные пакетные ошибки, за исключением тех, которые заменяют один ноль дополнения одного на другой (то есть 16 смежных 1 бит заменяются 16 нулевыми битами или наоборот). На равномерно распределенных данных ожидается обнаружение других типов ошибок со скоростью, пропорциональной 1 в 2 ^ 16. Контрольная сумма также имеет главное ограничение: сумма набора 16-битных значений одинакова, независимо от порядка, в котором эти значения отображаются.

Источник:<ftp://ftp.cis.upenn.edu/pub/mbgreen/papers/ton98.pdf>

Поэтому, если вы случайным образом перевернете какие-либо числовые биты где-нибудь в части данных пакета, есть вероятность от 1 до 65536, что эта ошибка не будет обнаружена, даже если вы вообще не трогаете контрольную сумму, как новые данные, даже если они полностью поврежден, имеет фактически ту же контрольную сумму, что и старая. Если вы просто поменяете местами два 16-битных значения в части данных, независимо от того, какие из них и как часто, вероятность того, что эта ошибка не будет обнаружена даже на 100%, так как порядок, в котором 16-битные значения появляются в части данных Пакет совершенно не имеет отношения к значению вычисленной контрольной суммы.

Здесь я пытаюсь сказать, что вам не нужно слишком беспокоиться о довольно маловероятном случае, когда данные и контрольная сумма будут повреждены, и эта ошибка не будет обнаружена, поскольку поврежденная контрольная сумма совпадает с поврежденными данными, правда в том, что каждый день миллионы TCP-пакетов в Интернете содержат только поврежденные данные, и эта ошибка не обнаруживается, поскольку нетленная контрольная сумма по-прежнему соответствует поврежденным данным.

Если вам нужно передать данные и вы хотите быть уверены, что данные не были повреждены, одной контрольной суммы TCP, безусловно, недостаточно для этой задачи. Я бы даже осмелился сказать, что контрольной суммы CRC недостаточно для этой задачи, поскольку CRC32 может не обнаружить ошибку, когда затронуто более 32 битов подряд (эти ошибки могут «компенсировать» друг друга). Минимальная контрольная сумма, необходимая для обеспечения безупречной передачи данных, - это значение данных MD5. Конечно, все, что лучше (SHA-1, SHA-256, SHA-384, SHA-512, Whirlpool и т. Д.), Будет работать еще лучше, но MD5 достаточно. MD5 может быть недостаточно безопасным для криптографической защиты (поскольку в прошлом он многократно нарушался), но в качестве контрольной суммы данных MD5 все еще абсолютно достаточен.



Да. Контрольная сумма значительно меньше, чем пакет, поэтому множество различных пакетов могут соответствовать данной контрольной сумме.

Если да, то как с этим бороться?

В ПТС совсем нет. Однако большинство повреждений данных будет заметно на более высоком уровне, например ваш XML больше не является правильным; ваш адрес электронной почты больше не английский и т. д.