【问题标题】:Checksums on TCPTCP 上的校验和
【发布时间】:2012-05-16 16:32:09
【问题描述】:

在传输过程中发生丢失等情况时,TCP 是否不负责确保通过线路完整发送流?

它没有做好它的工作吗?

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

【问题讨论】:

  • @cnicutar 在这一刻让我非常痛苦的是在 FreeBSD 上获取(类似 wget 的工具),通过移动互联网连接下载一个 60 MB 的文件。
  • 叫我不知情,但我不知道有任何执行校验和的应用层协议。您能否具体谈谈您正在考虑的应用层协议?
  • @Robᵩ 你是对的。我的表述可能不是很清楚。校验和由使用 http、ftp 等协议下载大文件的应用程序或操作系统的包管理器执行。所以它发生在周围而不是作为此类协议的组成部分。虽然我不确定当我们考虑 bittorrent 和类似的点对点数据传输协议时是否可以安全地说;这种不确定性导致我的表述模棱两可。

标签: tcp network-programming checksum crc


【解决方案1】:

虽然 TCP 确实包含自己的校验和,但它只是一个 16 位校验和,而且 TCP 校验和机制肯定有可能漏掉多位传输错误。这种情况非常罕见,但仍有可能发生,事实上我已经看到它发生了(几十年一到两次)。

健壮的协议需要使用更高级别的哈希函数来确保传输数据的完整性。话虽如此,传输少量数据的应用程序并没有遇到这个麻烦。批量传输应用程序(例如包管理器或自动更新机制)通常会使用加密哈希函数来增加数据完整性的保证。

【讨论】:

  • 在这一刻不断发生在我身上 :) 我即将放弃,等到下午我的主要互联网连接恢复正常后再继续。
  • 如果你反复遇到同样的问题,那么不太可能是 TCP 传输错误。这种多位传输错误是不可重复的。
  • fetch on FreeBSD(尽管在 VirtualBox 中)持不同意见(在我的情况下也是希望)。也许是因为我的知识不足以正确“操作”fetch,它确实会在校验和错误时重新启动下载。
【解决方案2】:

TCP 确保 TCP 数据包可靠传递,使用校验和捕获传输过程中引入的错误,并根据需要重新传输丢失或损坏的数据包。当数据包被传输时,它会保留在重传队列中,直到对等主机确认接收;如果在某个超时期限内没有收到确认,则重新传输数据包。但是主机不会永远重新传输数据包 - 如果数据包反复失败,那么 TCP 最终会放弃并关闭连接。

高级协议假定 TCP 工作可靠(一个公平的假设)并使用它们自己的校验和或其他任何东西来检查高级数据流是否安全到达。我编写了许多有问题的套接字应用程序,它们搞砸了自己的高级缓冲区并破坏了应用程序数据流!

在任何具有强大应用程序的生产级 TCP/IP 堆栈中,我认为您可以确信问题在于您的连接中断。或者您可能有一个有问题的应用程序,但我怀疑您的 fetch/wget 是否有问题。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2012-10-08
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2020-08-11
    • 1970-01-01
    • 2015-01-04
    相关资源
    最近更新 更多