TCP上的校验和

TCP是否不负责确保流在传输过程中发生丢失等情况时，通过采取任何必要的措施，通过线路完整地发送

它不是做得很好吗

---

为什么更高的应用层协议及其应用程序仍然执行校验和？

虽然TCP确实包含自己的校验和，但它只是一个16位校验和，而且TCP校验和机制肯定可能会导致多位传输错误。这是相当罕见的，但它仍然是可能的，事实上，我已经看到了它的发生（在几十年内一次或两次）

---

健壮的协议需要使用更高级别的哈希函数来确保传输数据的完整性。话虽如此，传输少量数据的应用程序并不多。大容量传输应用程序（如包管理器或自动更新机制）通常会使用加密哈希函数来增加数据完整性的保证。

TCP使用校验和来捕获传输过程中引入的错误，从而确保可靠地传输TCP包，以及根据需要重新传输丢失或损坏的数据包。当数据包被传输时，它被保留在重传队列中，直到对等主机确认接收；如果在某个超时时间段内未收到确认，则重新传输数据包。但主机不会永远重新传输数据包——如果数据包一再失败，TCP最终会放弃并关闭连接

高级协议假设TCP工作可靠（一个公平的假设），并使用它们自己的校验和或任何东西来检查高级数据流是否安全到达。我已经编写了很多有缺陷的Socket应用程序，它们破坏了自己的高级缓冲区，并破坏了应用程序数据流

---

在任何具有健壮应用程序的生产级TCP/IP堆栈中，我认为您可以确信问题在于您的连接正在断开。或者你可能有一个有缺陷的应用程序，但我怀疑你的fetch/wget有缺陷。

@cnicutar目前最让我头疼的是FreeBSD上的fetch（类似于wget的工具），它通过移动互联网连接下载一个60 MB的文件。叫我uninformation，但我不知道有任何应用层协议执行校验和。你能特别提到你正在考虑的应用层协议吗？@Robᵩ 你是对的。我的表述可能并不十分清楚。校验和由使用http、ftp等协议下载大型文件的应用程序或操作系统的包管理器执行。所以它发生在周围，而不是作为这些协议的一个组成部分。虽然我不确定当我们考虑BitTorrent和类似的对等数据传输协议时，是否可以安全地说；这种不诚实导致了我的模棱两可的表述。此时此刻，我身上一直在发生：）我打算放弃，等到下午我的主要互联网连接恢复正常后再继续。如果你反复遇到同样的问题，那么不太可能是TCP传输错误。这种多位传输错误是不可重复的。

FreeBSD

上的

fetch

（尽管是在VirtualBox中）的观点不一样（我也希望如此）。可能是因为我没有足够的知识来正确地“操作”

fetch

，并且它会在出现校验和错误时重新启动下载。