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

本文（）指出，由于TCP校验和算法相当弱，使用TCP时每1600万到100亿个数据包就会出现一个未检测到的错误

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

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

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

我从来没有因为TCP而害怕网络位错误——直到我看到那篇文章

对于一些极少数的客户机-服务器远程接口，实现应用程序级校验和可能没有那么多工作。但是，在单个数据中心的多台机器上运行的分布式企业软件呢。可以有大量的远程接口

是否每个企业软件供应商，如SAP、Oracle和其他公司都忽略了这类问题？银行呢？证券交易软件呢

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

---

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

我曾为IBs的交易系统工作过，我可以向你保证没有额外的校验和操作——大多数应用程序都使用裸套接字。考虑到目前金融业存在的问题，我认为糟糕的TCP/IP校验和应该是你最不担心的问题。

好吧，那篇论文是2000年的，所以它是很久以前的（老兄，我老了吗），而且记录的痕迹非常有限。因此，对他们的数字要有很大的怀疑。这就是说，看看情况是否仍然如此将是一件有趣的事情。然而，我怀疑情况已经发生了变化，尽管某些类型的错误可能仍然存在，例如硬件故障

---

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

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

尽管多年来我经常看到数据损坏——甚至是通过校验和得到的数据——但最令人难忘的事实是涉及到股票交易系统。坏路由器正在破坏数据，使其通常通过TCP校验和。它在不断地切换相同的部分。当然，没有人会因为TCP校验和失败的数据包而得到警告。应用程序没有额外的数据完整性检查

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

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

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

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

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

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

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

---

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

@altCognito请不要编辑我的答案以改变它们的含义。谢谢。这是一个过早优化的例子（旧答案被删除了，我被吓坏了）文档来自2000年，但TCP协议及其校验和更为古老——来自上个世纪70年代——错误仍然存在。因此，我不希望它会因为变得太“古老”而消失。关于这个问题的一些评论：