本文（When the CRC and TCP checksum disagree）表明，由于TCP校验和算法相当薄弱，因此使用TCP每1600万到100亿个数据包会发生一个未检测到的错误。
是否有任何应用程序开发人员通过在应用程序级别添加校验和来保护数据免受此类错误的影响？
在进行EJB远程方法调用（Java EE 5）时，是否有任何可用于防止此类错误的模式？或者Java是否已经自动校验和序列化对象（除了底层网络协议）？
企业软件一直在不只有内存ECC的计算机上运行，而且还在寄存器等CPU内部进行错误检查（SPARC等）。使用Solaris ZFS可以防止存储系统（硬盘驱动器，电缆等）出现位错误。
由于TCP，我从不害怕网络位错误 - 直到我看到那篇文章。
对于一些非常少的客户端服务器远程接口实现应用程序级校验和可能没那么多工作。但是，在单个数据中心的许多机器上运行的分布式企业软件呢？可能存在大量远程接口。
每个企业软件供应商都像SAP，Oracle和其他人一样忽略了这种问题吗？银行怎么样？那么股票交易软件呢？
跟进：非常感谢您的所有答案！因此，检查未检测到的网络数据损坏似乎非常罕见 - 但它们似乎确实存在。
我不能简单地通过将Java EE应用服务器（或EJB部署描述符）配置为使用配置为使用MD5或SHA1的TLS并通过配置Java SE客户端执行相同的TLS来使用RMI over TLS来解决此问题吗？这是一种获得可靠的透明校验和的方法（尽管是过度杀伤），这样我就不必在应用程序级别实现这一点了吗？或者我完全混淆网络堆栈？
答案 0 :(得分：2)
我曾为IBs的交易系统工作，我可以向你保证没有额外的校验和 - 大多数应用都使用裸套接字。鉴于当前金融领域存在的问题，我认为糟糕的TCP / IP校验和应该是您最不担心的问题。
答案 1 :(得分：2)
我确信每个关心数据完整性的应用程序都应该使用安全哈希。然而，大多数人没有。人们完全忽略了这个问题。
虽然我多年来经常看到数据损坏 - 即使是通过校验和得到的数据 - 实际上最令人难忘的是股票交易系统。糟糕的路由器破坏了数据，使其通常超过了TCP校验和。它正在打开和关闭相同的位。当然，没有人会收到事实上未通过TCP校验和的数据包的警报。该应用程序没有额外的数据完整性检查。
消息是股票订单和交易。腐败数据的后果与听起来一样严重。
幸运的是，腐败导致邮件无效，导致交易系统完全崩溃。一些业务损失的后果远不及执行虚假交易的潜在后果那么严重。
我们发现这个问题很幸运 - 有人在两个服务器之间的SSH会话失败并出现奇怪的错误消息。显然，SSH必须确保数据的完整性。
在此事件发生后，该公司没有采取任何措施来降低飞行中或存储期间数据损坏的风险。相同的代码仍在生产中，事实上，其他代码已投入生产，假设其周围的环境永远不会破坏数据。
这实际上是所有相关人员的正确决定。防止由系统的其他部分（例如，坏内存，坏硬盘控制器，坏路由器）引起的问题的开发人员不可能获得任何收益。额外的代码会产生添加错误的风险，或者被指责为实际上没有相关的错误。如果以后出现问题，那将是别人的错。
对于管理层来说，就像花时间在安全上一样。事件发生的几率很低，但“浪费”的努力是显而易见的。例如，请注意如何将端到端数据完整性检查与此处的过早优化进行比较。
自从撰写该论文以来，事情发生了变化 - 所有改变的是我们拥有更高的数据速率，更复杂的系统，以及更快的CPU，使加密哈希成本更低。更多的腐败机会，以及预防腐败的成本更低。
真正的问题是，在您的环境中检测/防止问题或忽略问题是否更好。请记住，通过检测问题，它可能成为您的责任。如果您花时间预防管理层无法识别的问题是一个问题，它可能会让您看起来像是在浪费时间。
答案 2 :(得分：1)
那么，那篇论文是从2000年开始的，所以它是从很久以前开始的（男人，我老了），并且是一组相当有限的痕迹。所以把他们的数字带上一大堆盐。也就是说，看看是否仍然如此，这将是有趣的。但是，我怀疑事情已经发生了变化，尽管某些类型的错误可能仍然存在，例如硬件故障。
如果你真的需要，那么额外的应用程序级保证将是数据的SHA-N哈希，或MD5等，这比校验和更有用。