问题描述
我正在尝试确定一个已知的WFP相关错误是否导致某些HTTP下载因错误发送的ACK而卡住。
另一个线程（"流层上的clone-block-reinject导致ack延迟"）建议 "的TcpAckFrequency等于1英寸;作为解决方法，但这没有帮助。
我们使用FWPS_STREAM_ACTION_DEFER和FwpsStreamContinue0。在暂停/恢复流之后，机器确认尚未接收的段。它永远不会确认服务器的最后一段，并且流卡住了。
外包：
$
[ ACK] Seq = 102 Ack = 1150481 Win = 65700 Len = 0
[ACK] Seq = 102 Ack = 1151941 Win = 65700 Len = 0
[ACK] Seq = 102 Ack = 1205961 Win = 65700 Len = 0
[TCP确认丢失段] 49619> http [ACK] Seq = 102 Ack = 1277501 Win = 65700 Len = 0
[TCP Dup ACK 5861＃1] 49619> http [ACK] Seq = 102 Ack = 1277501 Win = 65700 Len = 0
[TCP Dup ACK 5861＃2] 49619> http [ACK] Seq = 102 Ack = 1277501 Win = 65700 Len = 0
[TCP Dup ACK 5861＃3] 49619> http [ACK] Seq = 102 Ack = 1277501 Win = 65700 Len = 0
传入数据包（len，ack，seq）：
23414 102 1178221    [TCP窗口已满] [重新组装的PDU的TCP段]
8814 102       1201581    [TCP窗口已满] [重新组装的PDU的TCP段]
32174 102 1210341    [重新组装的PDU的TCP段]
29254 102 1242461    [TCP窗口已满] [重新组装的PDU的TCP段]
1514 102       1205961    [TCP重传] [重组PDU的TCP段]
1514 102       1205961    [TCP重传] [重组PDU的TCP段]
（总之，客户端确认1277501，而服务器仅在SEQ 1205961.完全.pcap（ 1MB）位于http://patraulea.com/temp/wfp-lost-ack.pcap)
这通常发生在下载的前10MB内，但仅限于与linux对等体（将大型（50KB）TCP片段分成多个IP片段）。
我的猜测是，ACK数据的计算就像数据一样（被忽略了）由于暂停流）被收到两次。如果这是一个已知问题，是否有任何解决方法？
$
I am trying to determine whether a known WFP-related bug is causing some HTTP downloads to become stuck due to incorrectly sent ACKs.
Another thread ("clone-block-reinject on stream layer causes ack delays") suggests "TcpAckFrequency=1" as a workaround but this didn't help.
We use FWPS_STREAM_ACTION_DEFER and FwpsStreamContinue0. After the stream is paused/resumed, the machine ACKs segments which were not yet received. It never ACKs the server's last segments, and the stream becomes stuck.
Outgoing packets:
[ACK] Seq=102 Ack=1150481 Win=65700 Len=0
[ACK] Seq=102 Ack=1151941 Win=65700 Len=0
[ACK] Seq=102 Ack=1205961 Win=65700 Len=0
[TCP ACKed lost segment] 49619 > http [ACK] Seq=102 Ack=1277501 Win=65700 Len=0
[TCP Dup ACK 5861#1] 49619 > http [ACK] Seq=102 Ack=1277501 Win=65700 Len=0
[TCP Dup ACK 5861#2] 49619 > http [ACK] Seq=102 Ack=1277501 Win=65700 Len=0
[TCP Dup ACK 5861#3] 49619 > http [ACK] Seq=102 Ack=1277501 Win=65700 Len=0
Incoming packets (len, ack, seq):
23414 102 1178221 [TCP Window Full] [TCP segment of a reassembled PDU]
8814 102 1201581 [TCP Window Full] [TCP segment of a reassembled PDU]
32174 102 1210341 [TCP segment of a reassembled PDU]
29254 102 1242461 [TCP Window Full] [TCP segment of a reassembled PDU]
1514 102 1205961 [TCP Retransmission] [TCP segment of a reassembled PDU]
1514 102 1205961 [TCP Retransmission] [TCP segment of a reassembled PDU]
(In summary, the client ACKs 1277501, while the server is only at SEQ 1205961. Full .pcap (1MB) is at http://patraulea.com/temp/wfp-lost-ack.pcap)
This usually happens within the first 10MB of downloading, but only with linux peers (which split large (50KB) TCP segments into multiple IP fragments).
My guess is that the ACK numbers are calculated as if the data (that's ignored due to pausing the stream) was received twice. If this is a known issue, is there any workaround ?
推荐答案
这篇关于在暂停流之后，将针对未接收的段发送ACK的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！