Контрольная сумма на уровне приложения, поскольку контрольная сумма tcp может быть слишком слабой?

Question

Этот Документ (Когда контрольная сумма CRC и TCP расходятся) предполагает, что, поскольку алгоритм определения контрольной суммы TCP довольно слаб, каждые 16-10 миллиардов пакетов, использующих TCP, будет возникать необнаруженная ошибка.

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

Существуют ли какие-либо шаблоны, доступные для защиты от таких ошибок при выполнении вызова удаленного метода EJB (Java EE 5)?Или Java уже автоматически сериализует контрольную сумму объектов (в дополнение к базовому сетевому протоколу)?

Корпоративное программное обеспечение работает на компьютерах, выполняющих не только ECC памяти, но и проверку ошибок в процессоре в регистрах и т.д. (SPARC и другие).Битовые ошибки в системах хранения данных (жесткие диски, кабели, ...) можно предотвратить с помощью Solaris ZFS.

Я никогда не боялся сетевых битовых ошибок из-за TCP - пока не увидел эту статью.

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

Неужели каждый поставщик корпоративного программного обеспечения, такой как SAP, Oracle и другие, просто игнорирует такого рода проблемы?А как насчет банков?А как насчет программного обеспечения для фондовой биржи?

Последующие действия: Большое вам спасибо за все ваши ответы!Таким образом, кажется, что проверка на необнаруженное повреждение сетевых данных довольно необычна - но они, похоже, существуют.

Не мог бы я решить эту проблему, просто настроив серверы приложений Java EE (или дескрипторы развертывания EJB) на использование RMI поверх TLS с TLS, настроенным на использование MD5 или SHA1, и настроив клиенты Java SE для выполнения того же?Будет ли это способом получить надежную прозрачную контрольную сумму (хотя и излишним), чтобы мне не пришлось реализовывать это на уровне приложения?Или я полностью запутался в сетевом стеке?

Answer 1

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

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

Сообщения представляли собой такие вещи, как заказы на акции и сделки.Последствия повреждения данных столь же серьезны, как это звучит.

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

Нам повезло определить проблему - чей-то SSH-сеанс между двумя задействованными серверами завершился сбоем со странным сообщением об ошибке.Очевидно, что SSH должен обеспечивать целостность данных.

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

На самом деле это правильное решение для всех вовлеченных лиц.Разработчик, который предотвращает проблему, вызванную какой- либо другой частью системы (напримерплохая память, плохой контроллер жесткого диска, плохой маршрутизатор) вряд ли что-нибудь выиграет.Дополнительный код создает риск добавления ошибки или быть обвиненным в ошибке, которая на самом деле не связана.Если проблема действительно возникнет позже, это будет чья-то другая вина.

Для руководства это все равно что тратить время на обеспечение безопасности.Вероятность инцидента невелика, но "напрасные" усилия заметны.Например, обратите внимание, как сквозная проверка целостности данных уже сравнивалась здесь с преждевременной оптимизацией.

Что касается изменений с момента написания этой статьи - все, что изменилось, это то, что у нас стали более высокие скорости передачи данных, более сложные системы и более быстрые процессоры, чтобы сделать криптографический хэш менее дорогостоящим.Больше шансов для коррупции и меньше затрат на ее предотвращение.

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

Answer 2

Я работал над торговыми системами для IBs, и могу заверить вас, что никакого дополнительного подсчета контрольной суммы не происходит - большинство приложений используют открытые сокеты.Учитывая текущие проблемы в финансовом секторе, я думаю, что плохие контрольные суммы TCP / IP должны беспокоить вас меньше всего.

Answer 3

Ну, эта бумага датирована 2000 годом, так что она сделана ОЧЕНЬ давно (блин, неужели я старый) и на довольно ограниченном наборе следов.Так что отнеситесь к их цифрам с огромной долей скептицизма.Тем не менее, было бы интересно посмотреть, так ли это по-прежнему.Однако я подозреваю, что ситуация изменилась, хотя некоторые классы ошибок все еще могут существовать, такие как аппаратные сбои.

Более полезно, чем контрольные суммы, если вы действительно потребность дополнительной гарантией на уровне приложения был бы SHA-N хэш данных, или MD5, и т.д.