☰

syn/ack 序列号混乱

tag-icon • tag-icon networking tcp wireshark
syn/ack 序列号混乱

我正在查看 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 数字似乎对我不利，那么我哪里错了？

答案1

TCP 序列编号

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

  1. TCP 序列号是有方向性的（即，如果有人向我发送了一个有效载荷，我不会根据我发送的字节数来增加我的序列号）。已收到）
  2. TCP 序列号指向数据包有效负载的头部

但是，仅凭这些点无法解释数据包 6 和 7 之间序列号 5841-14600 丢失的 ACK。我最好的猜测（也是我目前唯一能做的）是您可能在 NIC 和 wireshark 之间的某个地方丢弃了 ACK 数据包。如果您看到这样的消息（来自 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，缓冲区设置特定于您的系统... 尝试使用它们，直到您看不到数据包丢失的消息

答案2

可能是碎片。可能是与服务器的另一个会话。端口是否等同？Wireshark 可以从接口中选择 TCP 会话中的所有数据包（通过在 rcm 上的数据包菜单中选择）

相关内容