TCP的确认不能保证数据已经传递

在RFC 793中，有一部分关于TCP段的确认：

当TCP传输包含数据的段时，它将副本放在重传队列上并启动计时器。收到该数据的确认后，该段将从队列中删除。如果在计时器用尽之前未收到确认，则重新发送该段。

TCP的确认不能保证已将数据传递给最终用户，而只能保证接收方的TCP承担了责任。

现在，这很有趣。在我们的NOC中，我们经常对网络与外部客户端网络之间的连接问题进行故障排除，并且每当我们在防火墙上嗅探流量并看到双向发送和接收的SYN和ACK位时，我们都假定已建立连接并且问题不存在。做网络。

但是现在，这个RFC让我开始思考-如果建立了TCP连接，但用户仍然遇到连接问题，我还要检查什么（不设置Wireshark）？

RFC的这一部分是关于将责任转移到操作系统或过程的下一阶段。从根本上讲，它与层的分离有关。

TCP的确认不能保证已将数据传递给最终用户，而只能保证接收方的TCP承担了责任。

我一直这样想：

• 操作系统可能在发送ACK和到达客户端进程的数据之间崩溃（此处的“客户端”是指操作系统的客户端，而不是“网络客户端”）
• 客户端进程可能是错误的或崩溃的，或者比预期的慢得多，无法处理其传入的数据，或者实际上仅在非显而易见的情况下才读取它
• 如果客户端正在将数据向前发送，也许是发送到磁盘文件，则该文件可能尚未被写入或刷新
• 如果客户端正在通过TCP继续发送数据，则远端TCP可能尚未发送数据，未收到ACK，或者远端进程已成功使用了数据

只是说这是第3层确认（“我听到了您的字节”），而不是更高层的确认。考虑例如TCP ACK，250 OK下一跳邮件网关接受消息之后的SMTP ，消息接收消息（例如，按照RFC 3798），消息打开的跟踪像素，来自PA的感谢信之间的区别，并回答“是的，我会做。”

另一个具体示例是打印机：

• 在知道数据的末尾之前，它必须提早确认数据（可能是Postscript文件，其开头的库大于TCP传输窗口）
• 它可能包含状态查询（“您有纸吗？”，显然可以执行该查询）
• 它可能包含打印命令（“请打印此命令”，如果缺纸，则可能会失败）

我建议如果用户正在查看和发送ACK，但仍然遇到连接问题，那么拥塞，操作系统或应用程序问题的发生率要比与网络完全相关的问题高出几个数量级。

为了诊断，我建议寻找重传，而不是专门的ACK。

从RFC的角度来看，“最终用户”是应用程序。不能保证应用程序可以获取数据，而不能保证TCP进程已接收到数据。

从您的NOC角度来看，网络正在运行，数据已到达终端主机。想必，这就是您所关心的。

你可以这样看。

您是M.Smith，并且想发送一封信给M.Toto（人员是应用程序层）。

若要发送该信件，请转到您的本地邮局A，后者将把信件发送给M.Toto本地邮局B（邮局是TCP层）。

在您之间，邮局A和邮局B之间的一切工作都可能顺利进行，B会向邮局A发送ACK。但是，不能保证这封信会到达M.Toto。邮局B和M.Toto之间可能发生任何事情。

基本上就是RFC所说的。