syn / ack序列号混淆

我正在看wireshark中的一些随机stream量，并碰到这个（使用相对seq / ack数字）：

1. myIP -> 74.125.227.96 [SYN] seq=0 2. 74.125.227.96 -> myIP [SYN/ACK] seq=0 ack=1 3. myIP -> 74.125.227.96 [ACK] seq=1 ack=1 4. myIP -> 74.125.227.96 [ACK] seq=1 ack=1 len=14600 5. 74.125.227.96 -> myIP [ACK] seq=1 ack=2921 6. 74.125.227.96 -> myIP [ACK] seq=1 ack=5841 7. myIP -> 74.125.227.96 [ACK] seq=14601 ack=1 len=8760 8. 74.125.227.96 -> myIP [ACK] seq=1 ack=8761 9. myIP -> 74.125.227.96 [ACK] seq=23361 ack=1 len=4380 etc...

我使用http://packetlife.net/blog/2010/jun/7/understanding-tcp-sequence-acknowledgment-numbers作为资源，它似乎像seq =前ack和ack + =以前的seq + len /旗（请如我错了请纠正我）。但是第4-7行发生了什么？数据包是碎片还是什么东西？ seq / ack数字似乎并没有加起来，所以我哪里错了？

TCP序列号

解码TCP跟踪时有几件事要记住…

TCP序列号是定向的（即，如果有人给我发送一个有效载荷，我不会根据我收到的字节增加我的序列号）
TCP序列号指向分组的有效载荷的头部

然而，这些点本身并没有考虑数据包6和7之间的序列号为5841-14600的丢失的ACK。我最好的猜测（我现在可以做的就是这一点）就是你可能丢失了ACK数据包网卡和wireshark之间。你可以知道什么时候发生这种情况，如果你看到这样的消息（从Linux的xterm或ssh会话）…

 19431 packets captured 38863 packets received by filter 572 packets dropped by kernel <---------------- 7 packets dropped by interface <----------------

解决wireshark数据包丢失

减lesswireshark查看的数据包的大小（每个数据包100个字节通常绰绰有余）
禁用DNS查找和实时捕获滚动（磁盘缓冲区捕获效率最高）
在Linux中，您可以通过调整NIC上的缓冲区以及内核和libpcap之间的缓冲区来修复这些丢包。

ethtool -G eth0 rx 768

sysctl -w net.core.netdev_max_backlog=30000
如果你在Windows中，当你调用它的时候，给wireshark更多的缓冲空间（-B CLI选项）会有帮助。

注意：1. YMMV，缓冲区设置是特定于您的系统…与他们一起玩，直到您看不到包丢弃的消息

也许是碎片化。也许另一个会话到服务器。端口公式？ Wireshark可以从接口中select一个tcp会话中的所有数据包（通过在rcm数据包上的菜单中select）