sockets - RST上的TCP重传-Windows和Linux上的套接字行为不同？

Question

摘要:

我猜这里的问题与Windows和Linux如何处理TCP连接或套接字有关，但我不知道它是什么。我正在启动与其他人开发的自定义硬件的TCP连接，并且试图了解其行为。为此，我创建了一个.Net core 2.2应用程序。在Windows系统上运行，我可以成功启动连接，但是在Linux(最新Raspbian)上，我不能启动连接。

看来可能是因为Linux系统没有尝试在RST之后重试/重新发送SYN，而Windows系统却尝试了-这种行为似乎是这种特殊硬件如何工作的关键。

背景:

我们有一个黑匣子硬件，可以使用制造商提供的Windows应用程序通过网络进行控制和查询。数据是未加密的，不需要身份验证即可连接到该数据，并且该应用程序还存在其他一些问题。最终，我们希望能够将数据从它中继到另一个系统，因此我们决定创建自己的应用程序。

我花了很长时间尝试了解数据包格式，并创建了一个针对.net core 2.2的库，该库可用于成功与此工具包进行通信。这样做时，我发现设备似乎需要通过UDP发送一种“连接请求”命令。紧接着，我能够在端口16000上启动TCP连接，尽管第一次TCP尝试始终会导致返回RST，ACK-因此需要进行第二次尝试。

我开发的软件在Windows(x86)和Linux(Raspberry Pi/ARM)系统上都可以正常工作，并且我可以发送和接收数据。但是，在Raspbian系统上运行时，启动TCP连接时似乎会出现问题。我可能会发誓我们在以前的版本中可以正常工作，但是以前的提交似乎都不起作用-因此它很可能是对系统/内核进行了更改的更新。

问题:

启动与该设备的TCP连接时，它将(立即)重置连接。即使使用制造商提供的软件，它也可以执行此操作，然后该软件本身立即立即再次尝试连接并成功。因此，这种二次重置行为本身并不是我可以控制的“问题”。

我想了解的是，为什么Windows系统立即通过重新传输来重新尝试连接...


..但是Linux系统只是在一次尝试之后就放弃了(这是数据包捕获的结束。)


为了证明它不是特定于应用程序的问题，我尝试在Windows系统和Raspbian系统上使用ncat/netcat，并在单独的笔记本电脑上使用Kali系统来证明它不是ARM/Raspberry问题。由于尚未发送UDP“请求”，因此连接将永远不会成功，但这仅说明了操作系统之间的不同行为。

Linux版本看起来与上面的版本几乎相同，因此它们发送一个重置后的数据包-而Windows尝试显示多次重传。



那么，有人对这种行为差异有任何答案吗？我猜这不是特定于.net核心的问题，但是有什么方法可以设置套接字选项以尝试重新传输？还是可以使用systemctl命令或其他在操作系统级别设置它？我确实尝试过看看.net中是否有任何SocketOptionName，它们似乎可以控制尝试/重试，就像this answer令我感到奇怪的那样，但到目前为止还算不上成功。

如果有人对如何更好地跨平台调整此行为有任何建议，或者可以解释造成这种差异的原因，我将不胜感激!

Answer 1

很高兴找到!根据this的说明，如果Windows TCP在发送SYN后从远程主机接收到RST/ACK，它将重试连接:

... Upon receiving the ACK/RST client from the target host, the client determines that there is indeed no service listening there. In the Microsoft Winsock implementation of TCP, a pending connection will keep attempting to issue SYN packets until a maximum retry value is reached (set in the registry, this value defaults to 3 extra times)...

根据同一文章，在HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpMaxConnectRetransmissions中设置了用于限制这些重试的值。至少在Win10 Pro中，默认情况下似乎不存在。

尽管这对于Windows机器来说很方便，但应用程序仍应确定自己的标准来处理失败的IMO连接尝试(即尝试次数，超时等)。

无论如何，正如我所说，令人惊讶的事实!我想生活和学习...

克里斯蒂安。