4

この論文 ( CRC と TCP チェックサムが一致しない場合) は、TCP チェックサム アルゴリズムがかなり弱いため、TCP を使用する 1600 万から 100 億パケットごとに検出されないエラーが発生することを示唆しています。

アプリケーション レベルでチェックサムを追加することによって、この種のエラーからデータを保護するアプリケーション開発者はいますか?

EJB リモート メソッド呼び出し (Java EE 5) の実行中に、このようなエラーから保護するために使用できるパターンはありますか? または、Java はすでにシリアル化されたオブジェクトを自動的にチェックサムしますか (さらに、基礎となるネットワーク プロトコルに加えて)?

エンタープライズ ソフトウェアは、メモリ ECC だけでなく、レジスタなど (SPARC など) で CPU 内のエラー チェックを実行するコンピューター上で実行されています。ストレージ システム (ハード ドライブ、ケーブルなど) でのビット エラーは、Solaris ZFS を使用することで防ぐことができます。

その記事を見るまでは、TCP によるネットワーク ビット エラーを恐れたことはありませんでした。

一部の非常に少数のクライアント サーバー リモート インターフェースに対してアプリケーション レベルのチェックサムを実装するのは、それほど大変な作業ではないかもしれません。しかし、単一のデータセンター内の多数のマシンで実行される分散エンタープライズ ソフトウェアはどうでしょうか。非常に膨大な数のリモート インターフェイスが存在する可能性があります。

SAP、Oracle などのすべてのエンタープライズ ソフトウェア ベンダーは、この種の問題を無視しているのでしょうか? 銀行はどうですか？証券取引所のソフトウェアはどうですか？

フォローアップ:たくさんの回答ありがとうございました! そのため、検出されないネットワーク データの破損をチェックすることはほとんどないように思われますが、それらは存在するようです。

MD5 または SHA1 を使用するように構成された TLS で RMI over TLS を使用するように Java EE アプリケーション サーバー (または EJB デプロイメント記述子) を構成し、同じことを行うように Java SE クライアントを構成するだけで、この問題を解決できませんでしたか? これは、アプリケーションレベルでこれを実装する必要がないように、信頼できる透過的なチェックサムを取得する方法でしょうか (やり過ぎではありますが)? それとも、ネットワークスタックに関して完全に混乱していますか?

4

3 に答える 3

2

データの整合性を気にするすべてのアプリケーションは、安全なハッシュを使用する必要があると確信しています。ただし、ほとんどはそうではありません。人々は単に問題を無視します。

私は何年にもわたって頻繁にデータの破損を目にしてきましたが (チェックサムによるものであっても)、実際に最も記憶に残っているのは株式取引システムに関するものでした。不良ルーターがデータを破損していたため、通常は TCP チェックサムを通過していました。同じビットをオフとオンに切り替えていました。そしてもちろん、実際に TCP チェックサムに失敗したパケットについて警告を受けることはありません。アプリケーションには、データの整合性に関する追加のチェックはありませんでした。

メッセージは、株式注文や取引のようなものでした。データの破損の結果は、聞こえるほど深刻です。

幸いなことに、破損によりメッセージが無効になり、取引システムが完全にクラッシュしました。一部のビジネスを失った場合の結果は、偽の取引を実行した場合の潜在的な結果ほど深刻ではありませんでした。

この問題は幸運にも特定されました。関係する 2 つのサーバー間の SSH セッションが奇妙なエラー メッセージで失敗しました。明らかに、SSH はデータの整合性を確保する必要があります。

この事件の後、同社は飛行中または保管中のデータ破損のリスクを軽減するために何もしませんでした. 同じコードが本番環境に残っており、実際、周囲の環境がデータを破損しないことを前提とした追加のコードが本番環境に移行しています。

これは実際、関係者全員にとって正しい決定です。システムの他の部分 (不良メモリ、不良ハード ドライブ コントローラ、不良ルーターなど) によって引き起こされた問題を防止する開発者は、何も得られない可能性があります。余分なコードにより、バグが追加されたり、実際には関係のないバグのせいにされたりするリスクが生じます。後で問題が発生した場合、それは他の誰かのせいになります。

管理者にとっては、セキュリティに時間を費やすようなものです。インシデントの可能性は低いですが、「無駄な」努力が目に見えます。たとえば、エンド ツー エンドのデータ整合性チェックが、既にここで説明した時期尚早の最適化と比較されていることに注目してください。

その論文が書かれてからの変化について言えば、変化したのは、データレートが向上し、システムがより複雑になり、暗号化ハッシュのコストを削減するために CPU が高速になったことだけです。破損の可能性が高くなり、それを防止するためのコストが削減されます。

本当の問題は、問題を検出/防止するか、無視することが環境内で優れているかどうかです。問題を検出すると、それがあなたの責任になる可能性があることを忘れないでください。また、経営陣が認識していない問題を防ぐために時間を費やすと、時間を無駄にしているように見える可能性があります。

于 2009-05-20T18:52:29.313 に答える
2

私は IB のトレーディング システムに取り組んできましたが、余分なチェックサムが行われていないことを保証できます。ほとんどのアプリはネイキッド ソケットを使用しています。金融セクターにおける現在の問題を考えると、TCP/IP チェックサムの不良は心配する必要がないと思います。

于 2009-05-13T13:29:44.990 に答える
1

ええと、その紙は2000年のものなので、かなり前のことです（男、私は年をとっています）、そしてかなり限られた痕跡のセットにあります。だから彼らの姿を巨大な塩の粒で取ってください。そうは言っても、これがまだ当てはまるかどうかを確認するのは興味深いでしょう。ただし、ハードウェアの障害など、いくつかのクラスのエラーがまだ存在している可能性はありますが、状況は変わったと思います。

追加のアプリケーションレベルの保証が 本当に必要な場合は、チェックサムよりも便利なのは、データのSHA-Nハッシュ、またはMD5などです。

于 2009-05-15T20:15:33.773 に答える