tcp - 应用程序级校验和，因为 tcp 校验和可能太弱了？

Question

这篇论文 ( When the CRC and TCP checksum disagree ) 表明，由于 TCP 校验和算法相当弱，使用 TCP 每 1600 万到 100 亿个数据包就会出现一个未检测到的错误。

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

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

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

在看到那篇文章之前，我从不害怕 TCP 的网络位错误。

为极少数客户端服务器远程接口(interface)实现应用程序级校验和可能不需要太多工作。但是在单个数据中心的多台机器上运行的分布式企业软件呢？可以有非常多的远程接口(interface)。

像 SAP、Oracle 和其他企业软件供应商是否都忽略了这种问题？银行呢？股票交易软件怎么样？

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

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

Answer 1

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

虽然多年来我经常看到数据损坏 - 甚至是通过校验和获得的数据 - 但最令人难忘的实际上涉及股票交易系统。坏路由器正在破坏数据，因此它通常会通过 TCP 校验和。它正在关闭和打开相同的位。当然，没有人会收到实际上未通过 TCP 校验和的数据包的警报。该应用程序没有对数据完整性进行额外检查。

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

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

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

此事件发生后，该公司未采取任何措施来降低数据在传输过程中或存储过程中损坏的风险。相同的代码仍在生产中，事实上，额外的代码已经进入生产，假设它周围的环境永远不会破坏数据。

这实际上是所有相关人员的正确决定。阻止由系统其他部分引起的问题(例如内存故障、硬盘驱动器 Controller 故障、路由器故障)的开发人员不太可能获得任何 yield 。额外的代码会产生添加错误的风险，或者因实际上不相关的错误而受到指责。如果以后确实出现问题，那将是其他人的错。

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

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

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