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

#c #networking #udp

Вопрос:

Возможно ли, чтобы данные UDP пришли к вам поврежденными? Я знаю, что это может быть потеряно.

Ответ №1:

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

Комментарии:

1. Технически контрольная сумма является необязательной. Из RFC 768: «Все нулевое переданное значение контрольной суммы означает, что передатчик не генерировал контрольную сумму (для отладки или для протоколов более высокого уровня, которым все равно)».

2. Да, НО: а) контрольная сумма, я полагаю, всегда рассчитывается для обычной, специально не настроенной передачи UDP, б) если пакет имеет правильную длину и контрольную сумму, то он правильный, иначе система не доставила бы такой пакет вызывающему абоненту. Верно?

Ответ №2:

Во-первых, «контрольная сумма IP», упомянутая выше, является только контрольной суммой IP-заголовка. Он не защищает полезную нагрузку. См. RFC 791

Во-вторых, UDP разрешает транспортировку без контрольной суммы, что означает, что 16-разрядная контрольная сумма установлена в 0 (т. е. Отсутствует). См. RFC 768. (Все переданное нулевое значение контрольной суммы означает, что передатчик не генерировал контрольную сумму)

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

Комментарии:

1. Если дейтаграмма приходит без контрольной суммы, может ли приложение запросить эту информацию?

2. Спасибо за разъяснение, что контрольная сумма IP-адреса предназначена только для заголовка.

3. @RandomInsano Пожалуйста, обратите внимание, что на плакате было три пункта. В пункте 1 говорится о «контрольной сумме IP», которая на один уровень ниже UDP, в пункте 3 говорится, что у UDP действительно есть контрольная сумма. Таким образом, существует 2 контрольные суммы: IP, защищающий IP-заголовок, и контрольная сумма UDP, защищающая UDP-заголовок и данные. Таким образом, данные защищены.

4. @benc Нет. Контрольная сумма обрабатывается операционной системой, и пользователь получит пакет только в том случае, если пакет пройдет проверку контрольной суммы (или пропустит проверку при нулевой контрольной сумме). Пользователь не знает, использовалась ли контрольная сумма или нет.

5. согласно RFC, контрольная сумма предназначена не только для заголовка: «Контрольная сумма-это 16-разрядное дополнение к сумме дополнений одного псевдо-заголовка информации из заголовка IP, заголовка UDP и данных».

Ответ №3:

Возможно? Абсолютно. Незамеченным? Маловероятно, поскольку UDP использует контрольную сумму, для которой потребовались бы многоразрядные ошибки, чтобы казаться допустимыми. Если будет обнаружена ошибка, система, скорее всего, отбросит пакет — таковы риски использования UDP.

Ответ №4:

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

Ответ №5:

Распространенной формой «коррупции», которая затрагивает ничего не подозревающих программистов, является усечение дейтаграмм. См. «Сетевое программирование Unix» Стивенса для получения дополнительной информации (стр. 539 во 2-м изд.)

Вы можете проверить флаг MSG_TRUNC…

Ответ №6:

Короткий ответ: ДА.

Подробный ответ:

Около 7 лет назад(может быть, 2011?) Мы обнаружили, что датаграммы UDP непреднамеренно изменяются при обмене датаграммой UDP между компьютером в Китае и другим компьютером в Корее. Конечно, контрольная сумма в заголовке пакета UDP также пересчитывается в связи с изменением полезной нагрузки. На двух компьютерах не было вредоносного программного обеспечения.

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

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

Я точно не знаю причину, но примерно предполагаю, что это Китайский Золотой Щит.

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