Возможно ли, чтобы данные UDP попали вам в коррумпированные? Я знаю, что это возможно для его потери.
Могут ли данные UDP быть повреждены?
Ответ 1
UDP-пакеты используют 16-битную контрольную сумму. Невозможно, чтобы UDP-пакеты имели коррупцию, но это маловероятно. В любом случае он не более подвержен коррупции, чем TCP.
Ответ 2
Прежде всего, "контрольная сумма IP", упомянутая выше, является только контрольной суммой IP-заголовка. Он не защищает полезную нагрузку. См. RFC 791
Во-вторых, UDP позволяет передавать с контрольной суммой NO, что означает, что 16-разрядная контрольная сумма установлена на 0 (т.е. нет). См. RFC 768. (Все значения контрольной суммы, переданной с нуля, означают, что передатчик не генерировал контрольную сумму)
В-третьих, как отмечали другие, UDP имеет 16-битный checkSUM, который не является лучшим способом обнаружения многобитовой ошибки, но не плохо. Конечно, незаметная ошибка может проникнуть, но очень маловероятна.
Ответ 3
Возможные? Абсолютно. Необнаруженная? Невероятно, поскольку UDP использует контрольную сумму, которая потребует появления многобитовых ошибок. Если обнаружена ошибка, система, скорее всего, потеряет пакет - таковы риски использования UDP.
Ответ 4
UDP-пакеты также могут быть доставлены не в порядке, поэтому, если вы разрабатываете протокол поверх UDP, вы также должны учитывать это.
Ответ 5
Общей формой "коррупции", которая затрагивает ничего не подозревающих программистов, является урезание дейтаграммы. Дополнительную информацию см. В разделе "Сетевое программирование Unix" Стивенса (стр. 539 в 2-й редакции).
Вы можете проверить флаг MSG_TRUNC...
Ответ 6
Краткий ответ: ДА.
Подробный ответ:
Около 7 лет назад (может быть, в 2011 году?) Мы обнаружили, что дейтаграммы UDP непреднамеренно изменяются при обмене дейтаграммой UDP между компьютером в Китае и другим в Корее. Конечно, контрольная сумма в заголовке пакета UDP также пересчитывается в отношении изменения полезной нагрузки. На двух компьютерах не было вредоносного программного обеспечения.
Мы обнаружили, что непреднамеренное изменение происходит только тогда, когда эти условия совпадают:
- Первые несколько байтов дейтаграмм похожи на предыдущие дейтаграммы
- Происходит только тогда, когда UDP-дейтаграммы переходят из одной страны в другую.
Я не причина именно, но я примерно предполагаю, что это Золотой щит Китая.
Поэтому мы добавили алгоритм обработки дейтаграмм в наше программное обеспечение ProudNet, и проблема исчезла. Это не сложно реализовать. Просто закодируйте или запутайте первые несколько байтов вашей дейтаграммы.