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

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

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

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

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

Ответы на вопрос(6)

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

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

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

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

 Mr Question McQuestion30 сент. 2010 г., 14:15
В этом есть смысл. Для длинного соединения по множеству различных типов каналов передачи данных (ethernet, ppp, atm), я думаю, вы окажетесь во власти худшего компонента (который может вообще не иметь проверки целостности).
 Mr Question McQuestion30 сент. 2010 г., 14:01
В то время как Ethernet имеет хорошую проверку целостности, как насчет других форм сети?
 curiousguy08 дек. 2011 г., 21:02
"Ethernet использует CRC вместо контрольной суммы."как CRC не является" контрольной суммой "?
 ChrisW30 мар. 2017 г., 15:52
@curiousguy Для меня слово "контрольная сумма«подразумевает (потому что термин включает в себя) простое XOR, бит четности в байтах битов или байты четности в пакетах байтов - тогда как CRC является более сложным алгоритмом.
 ChrisW30 сент. 2010 г., 14:06
Я ожидаю, что вы захотите создать систему проверки целостности, соответствующую частоте ошибок вашего канала передачи данных. НапримерPPP также использует CRC.
 samy30 сент. 2010 г., 14:18
Хороший вопрос, ииспользование вашего Data Link тоже имеет значение. Если это важно, перейдите на другой уровень защиты; Вы только задержите неизбежное, все же. Если это просто передача одноразовых данных, зачем беспокоиться, так как люди не заметят или не обновят свой запрос ...

полезная нагрузка пакета: 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.

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

 Mecki27 мар. 2013 г., 01:31
На самом деле ваш номер включает проверки на более низких уровнях в сочетании с TCP (например, Ethernet CRC). Одна контрольная сумма TCP с вероятностью 1 из 65536 ошибок не будет обнаружена. Это очень высоко. Принимая во внимание, что каждый день существует триллион пакетов, частота ошибок TCP сама по себе все равно будет вызывать миллионы поврежденных пакетов в день, которые не обнаруживаются, поскольку поврежденные данные по-прежнему имеют ту же контрольную сумму, что и исходная.
 samy30 сент. 2010 г., 14:22
@ChrisW Спасибо за ссылку :) Вы более консервативны, чем я, в отношении размера пакета, хотя, даже принимая максимальный размер пакета, ошибки случаются ежедневно
 samy30 сент. 2010 г., 14:16
Я думаю, что единственный показатель того, насколько вероятно, что один человек испытает это, связан с пакетами; Вы подвержены этой проблеме так же, как и другие, которые используют такое же количество пакетов. OTOH, чтобы быть заметным, вы должны испытать сбой в критическом пакете; если ваш html или js искажен, вы хмуритесь и просто перезагружаете страницу, вы не извлекаете посмертные инструменты :) Кстати, где вы нашли свою статистику? Я посмотрел вокруг, но не смог найти данные о количестве пакетов ...
 ChrisW30 сент. 2010 г., 14:03
Мировой трафик составляет от 10 до 15 пакетов в день, поэтому вероятность того, что он случится с некоторыми пакетами других людей (хотя и не с вашими), довольно высока.
 ChrisW30 сент. 2010 г., 14:22
Я просто указывал, что если частота ошибок составляет один на 10 миллиардов, то, вероятно, с вами этого не случится (потому что вы не отправляете столько пакетов), но, вероятно, это случится с кем-то другим (потому что они делают это коллективно , отправьте больше, чем много пакетов). Первая статистика, которую я нашел, былаМир 7500-12000 ПБ (PetaByte = 10 ^ 15 байт), который я разделил на мою оценку 500 байтов на пакет.

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

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

 curiousguy08 дек. 2011 г., 21:03
ОЗУ также может вносить ошибки. Не все проблемы возникают в проводе (или эфире).
 nos30 сент. 2010 г., 14:13
Увидетьacademic.research.microsoft.com/Paper/22436.aspx Более низкий уровень CRC может быть не таким надежным, как вы думаете.
 Mr Question McQuestion30 сент. 2010 г., 14:00
Не все слои каналов данных имеют проверку целостности, хотя?
 samy30 сент. 2010 г., 14:02
Нет, они не В статье, на которую я ссылался выше, упоминается использование проверок на уровне приложений в некоторых случаях.

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

 fumoboy00715 июн. 2015 г., 23:06
Почему контрольная сумма MD5 достаточна?
 Mecki16 июн. 2015 г., 15:32
@ fumoboy007 Потому что вы не имеете дело с криптографией. Вероятность того, что поврежденные данные имеют ту же контрольную сумму MD5, что и правильные данные, составляет один к 340 282 366 920 938 463 463 374 607 431 768 211 456 (39 цифр!), Во Вселенной, вероятно, меньше атомов, чем это. Вы можете легко сгенерировать два набора данных с одинаковой контрольной суммой MD5 (вот почему выне должен использовать MD5 для криптографии больше), но эти два набора данных будут выглядеть совершенно по-разному (даже близко не похоже!). Данные, измененные из-за ошибки передачи, будут выглядеть очень похоже на правильные данные.
 natersoz31 окт. 2017 г., 19:47
Цитируемая статья очень хорошо читается. Что действительно интересно в этой статье, так это их анализ источника ошибок пакетов и того, как с ними справляются в реальном мире. Тем не менее, они исключают источник ложноположительного вывода CRC. Эта статья выводит CRC ложноположительных вероятностей:ris.utwente.nl/ws/portalfiles/portal/5382287, См. Уравнение (2) и см. Также рисунок 2, который относится к CCITT CRC-16, но аналогичные результаты можно рассчитать для CRC-32. Итог: ложные CRC-позитивы гораздо более вероятны, чем 1/2 ^ N.

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

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

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

 rajb24519 апр. 2015 г., 22:44
в дополнение к тому, что я информативен, я очень сильно смеялся над тем, что «твоя электронная почта больше не английская»
 Pierre Maoui26 янв. 2016 г., 14:26
Может ли бит данных в данных привести к электронной почте, чтобы перевернуть ее язык?
 Bryan26 янв. 2016 г., 17:46
Переключение одного бита приведет к сбою контрольной суммы; Чтобы увидеть проблему, о которой идет речь в первоначальном вопросе, требуется больше переворотов. Но я имел в виду, что слова будут полностью искажены, а не изменены с английского на французский, скажем. Вероятность того, что это произойдет и все еще проходит контрольную сумму, очень и очень мала :-)

Ваш ответ на вопрос