4

这篇论文（当 CRC 和 TCP 校验和不一致时）表明，由于 TCP 校验和算法相当弱，使用 TCP 时每 1600 万到 100 亿个数据包就会发生未检测到的错误。

是否有任何应用程序开发人员通过在应用程序级别添加校验和来保护数据免受此类错误的影响？

在执行 EJB 远程方法调用 (Java EE 5) 时，是否有任何模式可用于防止此类错误？或者 Java 是否已经自动校验和序列化对象（除了底层网络协议）？

企业软件已经在计算机上运行，​​不仅执行内存 ECC，而且还在 CPU 内的寄存器等（SPARC 和其他）处进行错误检查。使用 Solaris ZFS 可以防止存储系统（硬盘驱动器、电缆等）的位错误。

因为 TCP，我从不害怕网络误码——直到我看到那篇文章。

为一些非常少的客户端服务器远程接口实现应用程序级校验和可能不是很多工作。但是，在单个数据中心的多台机器上运行的分布式企业软件呢？可能有大量的远程接口。

SAP、甲骨文等企业软件供应商是否都忽略了这类问题？银行呢？股票交易软件呢？

跟进：非常感谢您的所有回答！因此，检查未检测到的网络数据损坏似乎非常罕见 - 但它们似乎确实存在。

难道我不能简单地通过将 Java EE 应用程序服务器（或 EJB 部署描述符）配置为使用 RMI over TLS 并将 TLS 配置为使用 MD5 或 SHA1 并通过配置 Java SE 客户端来解决这个问题吗？这是否是一种获得可靠透明校验和的方法（尽管通过矫枉过正），这样我就不必在应用程序级别实现它？还是我完全混淆了网络堆栈？

4

3 回答 3

2

我曾为 IB 开发过交易系统，我可以向您保证不会进行额外的校验和 - 大多数应用程序都使用裸套接字。鉴于当前金融领域的问题，我认为糟糕的 TCP/IP 校验和应该是您最不担心的问题。

于 2009-05-13T13:29:44.990 回答
2

我相信每个关心数据完整性的应用程序都应该使用安全哈希。然而，大多数人没有。人们只是忽略了这个问题。

尽管多年来我经常看到数据损坏——即使是通过校验和得到的数据——实际上最令人难忘的是股票交易系统。一个坏的路由器正在破坏数据，因此它通常可以通过 TCP 校验和。它正在打开和打开相同的位。当然，对于实际上未能通过 TCP 校验和的数据包，没有人会收到警报。该应用程序没有额外的数据完整性检查。

这些消息是股票订单和交易之类的东西。破坏数据的后果与听起来一样严重。

幸运的是，损坏导致消息无效，导致交易系统完全崩溃。一些业务损失的后果远没有执行虚假交易的潜在后果那么严重。

我们很幸运地发现了这个问题——有人在所涉及的两台服务器之间的 SSH 会话失败并出现了一条奇怪的错误消息。显然 SSH 必须保证数据的完整性。

在此事件之后，该公司没有采取任何措施来降低在飞行或存储过程中数据损坏的风险。相同的代码仍在生产中，事实上，其他代码已经投入生产，假设它周围的环境永远不会破坏数据。

这实际上是所有相关人员的正确决定。防止由系统的其他部分（例如内存故障、硬盘控制器故障、路由器故障）引起的问题的开发人员不太可能获得任何收益。额外的代码会产生添加错误或被指责为实际上不相关的错误的风险。如果以后确实出现问题，那将是别人的错。

对于管理来说，这就像花时间在安全上。发生事故的几率很低，但“浪费”的努力是可见的。例如，请注意如何将端到端数据完整性检查与此处的过早优化进行比较。

自从那篇论文发表以来，事情发生了变化——所有变化都是我们拥有更高的数据速率、更复杂的系统以及更快的 CPU，从而降低了加密哈希的成本。腐败的机会更多，预防腐败的成本更低。

真正的问题是在您的环境中检测/预防问题或忽略它们是否更好。请记住，通过检测问题，它可能成为您的责任。如果你花时间防止管理层没有意识到的问题是问题，它会让你看起来像是在浪费时间。

于 2009-05-20T18:52:29.313 回答
1

嗯，那篇论文是 2000 年的，所以它是很久以前的（伙计，我老了），而且痕迹非常有限。因此，对他们的数字持保留态度。也就是说，看看情况是否仍然如此会很有趣。但是，我怀疑事情已经发生了变化，尽管某些类别的错误可能仍然存在，例如硬件故障。

如果您确实需要额外的应用程序级保证， 则比校验和更有用的是数据的 SHA-N 哈希或 MD5 等。

于 2009-05-15T20:15:33.773 回答