Подтвердить что ты не робот

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

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

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

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

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

4b9b3361

Ответ 1

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

Контрольная сумма TCP - это 16-разрядная сумма данных. Эта сумма будет ловить любую пакетную ошибку 15 бит или меньше, и весь 16-разрядный пакет ошибки, за исключением тех, которые заменяют один ноль дополнения 1 с другой (то есть 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 по-прежнему абсолютно достаточна.

Ответ 2

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

Ответ 3

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

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

Если да, с чем это связано?

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

Ответ 4

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

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

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

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

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

Ответ 5

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

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

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

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

Ответ 6

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

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