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

Question

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

Answer 1

UDP использует 16-битную необязательную контрольную сумму. Пакеты, которые не прошли проверку контрольной суммы, отбрасываются.

При условии идеальной контрольной суммы, 1 из 65536 поврежденных пакетов не будет замечен. Нижние уровни также могут иметь контрольные суммы (или даже более сильные методы, такие как прямое исправление ошибок 802.11). Предполагая, что нижние уровни передают поврежденный пакет в IP каждые n пакетов (в среднем), и все контрольные суммы совершенно некоррелированы, тогда каждые 65536 * n пакетов ваше приложение будет видеть повреждение.

Пример. Предположим, что нижележащий уровень также использует 16-битную контрольную сумму, поэтому один из каждых 2 ^ 16 * 2 ^ 16 = 2 ^ 32 поврежденных пакетов будет проходить через поврежденные. Если повреждены 1/100 пакетов, то приложение увидит 1 повреждение в среднем на 2 ^ 32 * 100 пакетов.

Если мы назовем это 1 / (65536 * n) числом p, то вы можете рассчитать вероятность отсутствия искажения вообще как (1-p) ^ i, где i - количество отправленных пакетов. В этом примере, чтобы получить вероятность возникновения коррупции до 0,5%, необходимо отправить почти 2,2 миллиарда пакетов.

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

Answer 2

UDP использует 16-битную контрольную сумму, поэтому у вас есть достаточная уверенность в том, что данные не были повреждены канальным уровнем. Однако это не абсолютная гарантия. Всегда полезно проверять любые входящие данные на прикладном уровне, когда это возможно.

Обратите внимание, что контрольная сумма технически необязательна в IPv4. Это должно еще больше снизить уровень «абсолютной достоверности» для пакетов, отправляемых через Интернет.

См. Технический документ UDP

Answer 3

Вам гарантируется только то, что контрольная сумма соответствует заголовку и данным в UDP-пакете. Шансы контрольной суммы, совпадающей с поврежденными данными или заголовком, равны 1 в 2 ^ 16. Это хорошие шансы для одних приложений, плохие для других. Если кто-то в цепочке сбрасывает контрольные суммы, вы попадаете в ловушку и не можете даже догадаться, является ли какая-либо часть пакета «правильной». Для этого вам нужен TCP.

Answer 4

Стоит отметить, что одна и та же 16-битная реализация crc применима как к TCP, так и к UDP для каждого пакета. При характеристике свойств UDP учитывают большинство передач данных, которые сегодня происходят в Интернете, используют TCP. При загрузке файла с веб-сайта для передачи используется тот же CRC.

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

Например, у модемов было исправление ошибок, а у уровня PPP также была своя контрольная сумма.

DSL аналогичен исправлению ошибок в ATM (коды Соломона) и CRC на уровнях PPPoA.

Кабельные модемы Docsis используют технологию, аналогичную технологии DSL, для обнаружения и исправления ошибок.

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

Я видел проблемы с часами в старых цепях Frame Relay 14 лет назад, которые обычно приводили к повреждению на уровне TCP. Слышал также истории о переворотах на неисправных аппаратных средствах, способствующих отмене CRC и повреждению TCP.

Так что да, это возможно для повреждения, и да, вы должны реализовать собственное обнаружение ошибок, если данные очень важны. На практике в Интернете и частных сетях сегодня это редкое явление.

Все аппаратные средства: дисководы, шины, процессоры и даже память ECC имеют собственные вероятности ошибок - для большинства приложений их достаточно мало, поэтому мы принимаем их как должное.

Answer 5

Не совсем. И это зависит от того, что вы подразумеваете под «Правильно».

UDP-пакеты имеют контрольную сумму, которая будет проверяться на сетевом уровне (ниже уровня приложения), поэтому, если вы получаете UDP-пакет на прикладном уровне, вы можете предположить, что контрольная сумма пройдена.

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

См. RFC 768 , чтобы узнать больше о UDP (довольно мало для технической спецификации:).

Answer 6

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

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