syn/ack 序列号混淆

Question

我正在查看wireshark中的一些随机流量并遇到了这个（使用相对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=previous ack 和 ack+=previous seq+len/flags（请如果我错了纠正我）。但是第 4-7 行发生了什么？数据包是碎片还是什么？seq/ack 数字对我来说似乎没有加起来那么我哪里出错了？

Answer 1

TCP 序列编号

解码 TCP 跟踪时需要记住几件事......

1. TCP 序列号是定向的（即，如果有人向我发送有效负载，我不会根据收到的字节增加序列号）
2. 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丢包的解决办法

• 减少wireshark查看的数据包大小（每个数据包100字节通常就足够了）
• 禁用 DNS 查找和实时捕获滚动（磁盘缓冲区捕获最有效）

• 在 Linux 中，您可以通过调整 NIC 上以及内核和 libpcap 之间的缓冲区来修复这些问题^{注 1} ...

  ethtool -G eth0 rx 768

  sysctl -w net.core.netdev_max_backlog=30000

• 如果您在Windows中，当您调用它时，它有助于为wireshark提供更多缓冲区空间（-B CLI选项）...

注意 1. YMMV，缓冲区设置特定于您的系统...使用它们，直到您看不到数据包丢失消息