Стоит ли дополнительных накладных расходов добавить дополнительную контрольную сумму в пакеты UDP?

Question

Я работаю над приложением, которое передает зашифрованные файлы по UDP (да; я знаю, что UDP обычно не используется для передачи файлов, но это крайний случай), и мне было интересно, стоит ли добавлять дополнительные накладные расходы, чтобы добавить дополнительная контрольная сумма к пакету. Я знаю, что «маловероятно», что UDP-пакеты будут повреждены, но стоит ли добавлять дополнительную контрольную сумму?

Answer 1

зашифрованные файлы по UDP

Если вы шифруете, то ваше шифрование должно включать HMAC . Кроме того, если вы шифруете, у вас должен быть протокол обмена ключами сеанса (через UDP? Давайте на мгновение проигнорируем это), и вы должны сгенерировать случайный IV для каждого пакета UDP и включить это IV в пакете. Если вы не примете эти меры предосторожности (отдельно IV для каждого пакета, добавьте HMAC), то ваше шифрование в основном бесполезно. И если у вас есть HMAC, вам не нужна контрольная сумма.

Answer 2

У UDP уже есть контрольная сумма 16 битов, очень маловероятно, что возможна коллизия, теоретически возможная.

Вам определенно нужны частичные контрольные суммы. Если у вас есть файл размером 1 ТБ, на передачу которого уходит один день, а затем происходит сбой хэша, это очень огорчает вас.

Ленивое решение: Хэш каждого мегабайта или около того? Может быть, более или менее, глазное яблоко это.

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

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

Answer 3

Учитывая, что UDP уже делает контрольную сумму (дополнение) и алгоритм шифрования также имеет некоторый тип проверки целостности (вы не сказали, какой тип шифрования вы используете, но большинство установленных схем шифрования имеют проверку целостности)Я думаю, что не было бы необходимости добавлять дополнительную контрольную сумму.Сказав это, я укажу, что вы должны знать, как будут сообщаться о сбоях целостности UDP и шифрования.Я полагаю, что ошибка Chacksum сообщается как SocketException с кодом ошибки, установленным в WSANO_RECOVERY 11003. Очевидно, как это сообщается для вашей схемы шифрования, e зависит от схемы.Затем вам придется решить, что вы собираетесь с этим делать.Перехват на уровне пакета позволяет запросу снова отправить только этот пакет, предполагая, что отправитель отслеживает, что находится в каждом пакете.Это может усложниться в спешке, а ведь многие люди просто используют TCP.

Надеюсь, это поможет.

Answer 4

Я бы сказал, да. Насколько я помню, контрольные суммы уровня IPV4 являются необязательными для потоков UDP. IPV6 делает это обязательным.

Answer 5

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

Answer 6

Это зависит от вас.Если вам нужна очень высокая надежность, вы можете добавить вычисление CRC32.

Контрольная сумма для UDP-пакета вычисляется следующим образом: "все 16-битные слова суммируются с использованием арифметики одного дополнения.мы дополняем его до значения поля контрольной суммы UDP. "

... Похоже, вы будете иметь достаточно высокую, но не надежную надежность с существующей контрольной суммой.

Answer 7

UDP-пакеты уже имеют контрольную сумму для обнаружения повреждений. Я не думаю, что добавление еще одной контрольной суммы ничего не улучшит. Тем не менее, вы можете быть заинтересованы в Hash Trees .

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