我有一台Windows 7笔记本电脑，我正在使用Mozilla Firefox网络浏览器观看YouTube视频 . 除了YouTube之外，互联网上没有其他任何内容可供查看 . 没有其他浏览器/浏览器选项卡打开 . 笔记本电脑通过以太网连接连接到互联网 .
这是我所看到的：在一定数量的数据包（实际上是一个大数据包）之后，我注意到TCP的段中存在一种模式 - ACK传输 . 通过单个TCP ACK确认大约10个TCP段 . 这种模式不断重复 . 所有TCP段都具有相同的源IP地址，因此我假设它们来自同一台服务器 .
我最初的猜测是，这可能是由于TCP延迟的ACK机制造成的 . 但是，根据RFC 1122，对于全尺寸传入段的流，应该为每个第二段发送ACK响应 . 另外，我检查了构成初始SYN-ACK握手的数据包 . 商定的MSS是1460字节 . 所以这意味着应该有5个ACK而不是一个 . （注意：RFC 1122已经由RFC 1349,4379,5884,6093,6298,6633,6864和8029更新 . 但是，我找不到任何这些RFC改变这种特定的延迟ACK机制（即'确认每隔一段'） ）） .
我知道RFC说应该而不是必须 . 我可以在我自己的跟踪中看到，主要是在开始和很长一段时间内，TCP会确认每个其他段 . 但是，在一段时间之后，ACK的数量减少了 . 我假设这与特定操作系统的特定TCP实现有关？ ...不同的TCP版本将一起确认不同数量的数据包 . 但是，我想知道是否有任何文档/资源可以用来了解有多少数据包在不同的TCP实现或至少是常用的实现中一起被确认 .
我还进行了另一项实验，并为以下来源拍摄了几条痕迹：YouTube，亚马逊Prime视频，潘多拉 . 我看到了类似的趋势 . 即使使用Ubuntu而不是Windows，也会发生这种情况 .
我附上了我在Wireshark中看到的内容的快照 . 我还在飞行列中添加了一个字节 . 在时间t的飞行变量中的字节（在wireshark中）表示尚未被确认到该点的字节数 . 因此，如果飞行中的字节从1460 B - > 14600 B上升然后下降到0并且在ACK之后再次从1430 B开始，则这意味着这10个段由该特定ACK确认 .
