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

Question

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

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

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

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

Answer 1

Здесь следует отметить, что большинство людей полностью упускают из виду, это тот факт, что контрольная сумма 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 по-прежнему абсолютно достаточен.

Answer 2

Нет, это не может быть на 100% надежно: в этой статье упоминается от 1 до 16 миллиардов пакетов, не обнаруженных системой контроля ошибок. Я позволю вам рассчитать вхождения в день / неделю:)

Answer 3

Может ли контрольная сумма TCP выдавать ложное срабатывание?

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

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

Answer 4

и дополнительные контрольные суммы на нижних уровнях

Некоторые из них более строгие, чем контрольные суммы, например Ethernet использует CRC вместо контрольной суммы.

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

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

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

Answer 5

Предположим,

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

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

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

A = 8P*(1000*8P) = 6*10^4 * P^2

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

B = 1/2^16 = 6/10^4

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

A * B = 40 * P^2 

Вероятность низкая (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.

Answer 6

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

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