C++ 为什么TCP套接字在收到错误的ACK时发送RST数据包而不是重新发送数据？

TPC连接的“酷”之处之一是数据不会丢失。当数据未确认时，TCP可能会重新发送数据

我有一个经典的游戏服务器，用C++编写，客户端用Flash AS3.0.P/>编写。 在客户端中，我添加了一个检查工具，该工具每X秒尝试连接YouTube和Twitter，超时时间为5秒。问题是，当客户端的internet连接在几秒钟内中断后（internet checker收到1或2次超时，但在收到OKs后），它开始从服务器接收数据，但服务器停止从客户端接收数据

这是TCPDUMP接收到的流：

1. server > client: Flags [P.], seq 2374:2378, ack 119, win 14600, length 4
2. client > server: Flags [.], ack 2374, win 15524, length 0
3. client > server: Flags [.], ack 2378, win 15520, length 0
 . [Here the client sends data to the server, but the server never receives it...]
4. server > client: Flags [P.], seq 2378:2383, ack 119, win 14600, length 5
5. server > client: Flags [P.], seq 2386:2389, ack 119, win 14600, length 3
6. client > server: Flags [.], ack 2386, win 15512, length 0
7. client > server: Flags [.], ack 2389, win 15509, length 0
8. client > server: Flags [R.], seq 127, ack 2389, win 0, length 0

如您所知，当服务器发送带有错误ACK的数据时，重新发送数据的客户端istead将发送RST数据包（强制服务器关闭连接）。在客户端日志中，我可以看到接收和处理服务器发送的数据（因此，当服务器发送错误的ACK时，连接不会关闭）

当TCP在收到错误的ACK后决定发送RST数据包而不是重新发送数据时

客户端套接字是一个AS3

套接字，定义如下：

var socket:Socket = new Socket();

使用
fcntl（）
将服务器套接字设置为非阻塞。还有以下选项：

setsockopt(socket, IPPROTO_TCP, TCP_NODELAY, (char *)&dummyint, sizeof(int));
setsockopt(socket, SOL_SOCKET, SO_KEEPALIVE, (char *)&dummyint, sizeof(int));

TCP本身并不“不稳定”，它是一种协议。如果有什么不稳定的地方，那就是你的网络连接。TCP有一种在不稳定网络上重试的算法。您的代码也可能有问题，也可能有中间设备超时了您的连接。
请注意，转储中似乎丢失了一个额外的数据包，即服务器字节2383-2385，尽管客户端似乎确实看到了它们，因为它确认了它们

服务器没有用不正确的ACK应答。它用它在流中看到的最后一个字节号#119的ACK进行应答。当服务器在一段时间后无法确认丢失的字节时，由客户端重新传输这些字节。相反，它正在发送RST

没有定时信息，但我必须猜测RST来自于重新传输信息之前客户端上的超时。
是的，我知道TCP只是一个协议。我说的是创建的套接字，因此是连接。我不认为第三方会终止连接，因为当客户端在发送服务器没有接收到的数据后收到错误的ACK时，会接收到RST数据包。这一点没有所谓的“假定”。它确实会重新发送数据。你认为哪一个更可能：一个协议中的漏洞，有超过30年的发展历史，一个在互联网上的全球部署，它在拥有数百万用户的大量平台上表现出稳定，还是你全新的未知代码中的漏洞？如果你想要一个解决方案，我建议你在这里发表评论，而不是猜测。然而，从帖子的本质来看，你似乎并没有问一个真正的问题。我并不是说一个30多年的协议有一个bug。。。我不是那种人：-/我告诉你，TCP有时决定发送RST数据包而不是重新发送数据，我不知道为什么。我需要知道为什么会发生这种情况，这样我才能解决它。我将编辑这篇文章，让它更清晰。这正是你所说的。您使用了“假定”一词，并且您的帖子也包含了“TCP有什么问题？”，至少在您编辑它之前是这样。如果你有一个真正的问题，问它，并包括相关的代码，或者更确切地说是一个足够简短的摘录来演示这个问题。我明白了。对不起，我的英语不够好。当我写它的时候，听起来不像你告诉我的那么糟糕，那是因为我编辑了它。我仍然认为“应该”是因为tcpdump显示不重新发送数据。谢谢您的评论。当您执行这些
setsockopt（）
调用时，“dummyint”中的值是多少？好的，我现在看到了。我跟踪了更多的数据包，服务器字节很奇怪，在这一切发生之前，它发送
字节2261:2324
，并同时接收ACK和第三个ACK
2328
，因此发送/接收数据似乎有更多的问题。我已经检查了时间，是的，RST数据包是在服务器发送最后一个信息后3秒收到的，所以这是可能的。非常感谢。