Контрольная сумма на уровне приложения, поскольку контрольная сумма tcp может быть слишком слабой? - PullRequest
4 голосов
/ 13 мая 2009

В этом документе ( Когда контрольная сумма 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 для того же? Будет ли это способ получить надежную прозрачную контрольную сумму (хотя и с избыточным), чтобы мне не пришлось реализовывать это на уровне приложения? Или я полностью запутался в сетевом стеке?

Ответы [ 3 ]

2 голосов
/ 20 мая 2009

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

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

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

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

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

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

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

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

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

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

2 голосов
/ 13 мая 2009

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

1 голос
/ 16 мая 2009

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

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

...