设备 1 Windows XP。192.168.101.173，我可以访问应用程序代码，但它很大。
设备 2 嵌入式设备。192.168.101.205。我无权访问代码，甚至无法访问该设备的日志。
设备 1 和设备 2 已连接，显然设备 2 不支持 SACK。因此，我想在第一台设备上禁用 SACK，看看我遇到的问题是否得到解决。
以下是 Wireshark 上发生的情况的一些记录。请注意，该图像仅用于说明目的，而不是发送我所面临问题的数据。
可以看出，第一设备发送重启连接命令，之后发送SACK。第二台设备永远不会从此恢复。
更新：两个设备之间的通信不是大流量，而是在第二个设备上不断进行 ping 操作，并且每次都会有很大的数据流，但数据量在 Kbytes 范围内，除此之外，通信只是前面提到的 ping 操作看到这么多的 SACK 真的很烦人。我不知道在 Windows 端禁用 SACK 是否可以解决任何问题，但我想看看禁用它们后系统的行为。
更新：请在此链接上查找 Wireshark 捕获的正在发生的情况。对文件的简单评论： 11:35 我休息了一下。11:53 我重新开始捕捉。到这里一切都很正常。在包 963 处，设备 2 上的应用程序发生了一些问题。显然，它冻结了。您可以看到设备 2 不会重放，它仅发送 ACK（与它执行 ACK 然后应答的方式不同）。
在包 969 处，设备 1 重置连接。
从那里你可以不断地看到SACK_PERM。所以我想在Windows XP机器上禁用SACKs，看看是否有任何改进。
请在回答之前再次阅读问题。
Windows 中的 SACK 支持是通过注册表控制的：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\ParametersSackOptsSACK 并不是唯一使用 TCP 选项的功能；
TCP1323Opts控制时间戳和窗口缩放，我认为没有任何方法可以禁用“最大段大小”选项。参考： https: //www.fs-net.de/assets/download/docu/netdcu/en/NetDCU_TCPIP_ParametersConfigurableByUser.pdf
不太可能。
首先，“SACK_PERM”并不是 SACK 的实际用法——“SACK_PERM”是 SACK能力协商，是一个 TCP 握手选项，表示如果对方同意则愿意使用 SACK。不支持 SACK 的设备只会应答握手，而不包含其自己的“SACK_PERM”选项，并且连接将在不使用 SACK 的情况下自动继续。
但是，您的设备在其答案中确实包含“SACK_PERM”，表明它确实支持 SACK – 不仅如此，它还在其发送的数据包中生成实际的 SACK（例如在捕获的数据包 954 中）。因此，这反驳了您最初对设备 2 不支持 SACK 的猜测，这意味着在客户端禁用 SACK 不太可能起到任何有用的作用。
（您所描述的“恒定 SACK_PERM”并不是 SACK 使用的样子；它更像是当设备 1 不断尝试建立新连接时的“恒定 TCP 握手尝试”，尽管 Wireshark 在其 GUI 中强调了这一点，SACK Offer不是这些数据包的主要内容。）
即使设备的内存空间非常紧张，无法实现 SACK，它仍然能够接受带有附加选项的 TCP SYN，并忽略那些它不理解的选项，因为几乎所有操作系统都在过去35 多年来，我们一直在每次握手中添加这些内容 - 任何制造商生产的设备都需要在每个客户端中在系统范围内禁用 SACK，这是不现实的。
此外，不仅SACK使用TCP选项；也是TCP窗口大小缩放；TCP MSS协商；TCP 时间戳...您的设备显然支持所有这些，从其 SYN_ACK 回复（包括所有这些选项）来看。
其次，在你的描述中：
……不是同一个连接。这些数据包针对不同的 TCP 端口号发送。
tcp.stream eq 4据我在捕获中所见，与数据包 963 ( ) 的连接根本没有冻结 - 设备实际上在下一个数据包中进行应答，并且它会一直继续工作，直到捕获结束。与数据包 969 ( ) 的连接
tcp.stream eq 5是在数据包 879 中建立的非常短暂的连接，并且它确实冻结，但不是由于使用了 SACK；此时只有一个段需要确认，而设备只是不确认它。“SACK_PERM”数据包（全部
tcp.stream eq 6）是重置后建立新连接的一次尝试（与客户端尝试重新传输 SYN 一样，该尝试会被忽略）；但是，其中的 SACK_PERM 选项与工作TCP 连接的 SYN 数据包中的完全相同，因此它不太可能是连接尝试被忽略的原因。