wireshark网络分析的艺术笔记【答读者问】

Gryffinbit

发布于：2022年7月13日

Linux为什么卡住了

Question：有时通过SSH 登录 Linux 服务器时，输完用户名就卡住了，要等待10秒钟才提示密码输入。

Answer：Linux 服务器在收到 SSH 访问请求时，会先查询该客户端 IP 所对应的 PTR 记录。假如经过 5 秒钟还没有收到回复，就再发一次查询。如果第二次查询还是等了 5 秒还没复，就彻底放弃查询。如果DNS 查询能成功，就不用白等那10 秒钟了。

PTR记录：域名系统 (DNS) 将域名与 IP 地址相关联。DNS 指针记录（简称 PTR）提供与 IP 地址关联的域名。DNS PTR 记录与“A”记录完全相反，它提供与域名关联的 IP 地址。DNS PTR 记录用于反向 DNS 查找。当用户尝试在其浏览器中访问域名时，会进行 DNS 查找，将域名与 IP 地址相匹配。反向 DNS 查找与此过程相反：它是以 IP 地址开始并查找域名的查询。

Solution：针对这个问题，解决方法是更改ssh配置文件，将UseDNS配置项关闭（UseDNS no）

VMware优化存储阵列和读写性能

Question：某些iSCSI 存储阵列在出现网络拥塞时处理不当，会严重影响VMware 的读写性能

Answer：这和它们的TCP 实现方式有关。延迟确认会在收到数据包时，不直接发出确认包而是等待一段时间，并且将这段时间的确认包作为捎带确认数据一并发送。这样的话，便将原来多个数据包合并到一个数据包发送了，减少了数据包的发送，节省了数据包数量。但如果多个延迟确认拥塞在一起，就会出现较长等待时间，影响性能。

SCSI是小型计算机系统接口(Small Computer System Interface)的简称，SCSI作为输入/输出接口，主要用于硬盘、光盘、磁带机、扫描仪、打印机等设备。iSCSI就是在IP网络上运行SCSI协议的一种网络存储技术

Solution：VMware通过关闭延迟确认，可以优化ISCSI存储阵列和VMware的读写性能。

wireshark中三次握手

wireshark中，在Edit/Preferences/Protocols/TCP 菜单中勾上 Relative Sequence Numbers ，以此来启用序号相对值，便于观察TCP三次握手时需要的Seq值和ACK值。
成功的握手都是一样的，失败的握手却各有不同，因此解决起来还是需要一些技巧的。握手失败一般分两种类型，要么被拒绝，要么是丢包了。作者提到使用下面两个过滤表达式便可以定位出大多数握手失败的数据包：
1. 表达式 1：(tcp.flags.reset == 1) && (tcp.seq == 1)，表示握手请求被对方拒绝了。
  
  表面上看，其只是过滤出 Seq 号为 1，且含有 Reset 标志的包。但在启用Relative Sequence Numbers 的情况下，这往往表示握手请求被对方拒绝了。接下来只需右键选中过滤出的包，再点击Follow TCP Stream 就可以把失败的全过程显示出来。
2. 表达式 2：(tcp.flags.syn == 1) && (tcp.analysis.retransmission)，可过滤出重传的握手请求。
  
  一个握手请求之所以要重传，往往是因为对方没收到，或者对方回复的确认包丢失了。过滤之后，再右键点击过滤出的包，再用Follow TCP Stream 就可以把失败过程显示出来。
  三次握手建立连接：
  1. 客户端发送SYN，请求建立连接【SYN=1，ACK=0】
  2. 服务器端收到SYN，发送ACK确认，同时自己发送一个SYN【SYN=1，ACK=1】
  3. 客户端收到ACK+SYN，回复ACK确认，连接建立完成【SYN=0，ACK=1】
  四次握手断开连接：
  1. 客户端发送FIN，请求释放连接【FIN】
  2. 服务器端收到FIN，发送ACK确认【ACK】
  3. 服务器端发送FIN，告知释放连接【FIN】
  4. 客户端收到FIN，发送ACK【ACK】
  TCP标志位
  
  SYN：同步标志位，用于2台主机要建立连接时，第一次发出的数据包，在TCP三次握手中，前两次握手会带有SYN标志位，如上图的TCP三次握手。
  
  ACK：确认位，用于说明前对方发过来的数据包成功收到，上图中可以看到，第二次握手时，Receiver发送的包里面带有ACK和SYN，ACK是告诉Sender，刚刚你发过来的SYN包，我已经收到了。
  
  FIN：发送方发送FIN标志位，目的是告诉接收者，这是最后一个包了。
  
  URG：urgent flag用于通知receiver进程这个包要优先处理，把其他包先放一边。
  
  PSH：push flag功能也urgent一样，优先处理，只是带有这个标志位的包程序直接处理，不进入接收缓存中。
  
  RST：reset flag是从receiver发送到sender的包中才有，表明需要重连。需要复位。
  
  ECE：ECN响应标志被用来在TCP3次握手时表明一个TCP端是具备ECN功能的，并且表明接收到的TCP包的IP头部的ECN被设置为11。
  
  CWR：拥塞窗口减少标志被发送主机设置，用来表明它接收到了设置ECE标志的TCP包。拥塞窗口是被TCP维护的一个内部变量，用来管理发送窗口大小。
  
  NS：（experimental）还在试验中。
  
  tcp.flags.reset == 1 需要重连，复位
基于三次握手的SYN flood

原理：从大量主机发送SYN请求给服务器，假装要建立TCP连接。这些SYN请求可能含有假的源地址，所以服务器响应后永远收不到ACK，就会留下half-open状态的TCP连接。由于每个TCP连接都会消耗一定的系统资源，如果攻击足够猛烈，此类连接建立越多，服务器的资源就会被耗光，真正的用户访问也会被拒绝

Solution：如果干扰包太多，点击Analyze/Expert Info/Chats菜单，可以看到SYN 的总数量统计。

被误解的TCP

Question：发出去的TCP包，都应该有对应的ACK确认吗

Answer：TCP 数据接收方可以不必对每一个数据包都做ack确认，数据接收方也可以累积一些包才对发送方 Ack一次。对于ACK的频率，不同的操作系统有不同的频率。因为Ack 是有累积效应的，它隐含了“在此之前的其他包也已收到”的意思。

Question：TCP因为需要进行ack确认，是否效率更低呢

Answer：不会，因为如果TCP发送窗口足够大的话，也可以不受往返时间的约束，源源不断的传送数据。但如果传输小块数据的话，比如能在一个往返时间内就完成的小事，就会因为需要3次握手、4次握手而加大开销，比如DNS查询

最经典的网络问题

Question: Nagle算法和延迟确认在一起使用时产生的性能问题，从而导致下载速度变慢。

Answer:

通过wireshark分析一段下载文件的数据包，从中分析出Nagle算法和延迟确认在一起使用时产生的性能问题，从而导致下载速度变慢。

在某些情况下，应用层传递给TCP 层的数据量很小，比如在SSH 客户端以一般速度打字时，几乎是逐个字节传递到TCP 层的。传输这么少的数据量却要耗费20 字节IP 头+20 字节TCP 头，是非常浪费的，这种情况称为发送方的愚笨窗口综合症，也叫“小包问题”。针对这种小包问题，出现了一种Nagel算法，即将多个数据缓存起来，凑够MSS或等到确认到达之后再发送。

Nagle 和延迟确认本身都没有问题，但一起用就会影响性能。解决方法要么是关闭Nagle算法，要么是关闭延迟确认。

分析过程：

Statistics/Capture file properties菜单，可以看到网络传输的平均速度等。
Analyze/Expert Infos 菜单，可以看到网络传输时出现的错误信息
选定一个包，然后点击Statistics/TCP StreamGraph /TCP Sequence Graph（Stevens）菜单，可以看到数据传输的速度图。

为什么丢了单子

Question: 这章谈论的问题是一个NFS服务器的问题，有些用户属于数十个用户组，有些文件明明允许某个用户组访问的，但是属于该组的用户却访问不了。

Answer:

作者通过wireshark分析出现问题的流量包，通过搜索关键字找到出现问题的数据包，发现其只将16个Group ID传给了服务器，而不是20 个，这些ID 对应着Linux的用户组，这是RFC的限制，也是问题所在。

作者分析的步骤是：

报错是Permission denied，用了Ctrl+F 搜索字符串“denied”
找到了服务器响应的375 号包，定位到了出问题的时间点。不过真正有价值的却是它的上一个包，即来自客户端的374 号包。从中可见RPC（Remote Procedure Call）层只把16 个Group ID 传给服务器，而不是20 个。
这些ID 对应着Linux客户端的/etc/group文件。本地访问之所以没有出问题，是因为不需要调用RPC 层发送用户组。
查了RPC 协议所对应的RFC 5531，找到关于“gids<16>”的定义，发现最多传 16 个用户组是RFC 限制的。

Solution: 解决办法是将客户端的/etc/passwd和/etc/group文件复制到服务器中，需要用到用户组的时候就自己在服务器上查询，完全忽略客户端通过RPC 层传过来的信息。

RPC层：RPC（remote procedure call protocal）远程过程调用协议。通过RPC协议向远程服务器请求服务。属于传输层和应用层。

受损的帧

Question：正常情况下，出错的帧不会出现在wireshark里，但为什么会出现呢？

Answer：是wireshark的误报，有时它会出现FCS错误的帧。但实际传输中，是不会有帧检验序列错误的数据包的。因为每个帧在发送前都会被发送方校验一次，然后生成4个字节的FCS存在帧尾。接收方拿到帧之后，又会用相同的算法在做一次校验并生成FCS。假如这次生成的FCS和帧尾携带的不一致，就说明该帧已被损坏，应该被丢弃了。

Wireshark的提示

Packet size limited during capture

当你看到这个提示，说明被标记的那个包没有抓全
TCP Previous segment not captured

在 TCP 传输过程中，同一台主机发出的数据段应该是连续的，如果Wireshark发现后一个包的Seq 号大于前一个包的Seq+Len，就知道中间缺失了一段数据。假如缺失的那段数据在整个网络包中都找不到（即排除了乱序），就会提示该报错。
TCP ACKed unseen segment

当Wireshark 发现被Ack 的那个包没被抓到，就会提示该报错。
TCP Out-of-Order

当Wireshark 发现后一个包的Seq 号小于前一个包的Seq+Len 时，就会认为是乱序了，就会提示该报错。
TCP Dup ACK

当乱序或者丢包发生时，接收方会收到一些Seq 号比期望值大的包。它每收到一个这种包就会Ack 一次期望的Seq 值，以此方式来提醒发送方，于是就产生了一些重复的Ack。Wireshark 会在这种重复的Ack 上标记TCP Dup ACK
TCP Fast Retransmission

当发送方收到3 个或以上[TCP Dup ACK]，就意识到之前发的包可能丢了，于是快速重传它
TCP Retransmission

如果一个包真的丢了，又没有后续包可以在接收方触发[Dup Ack]，就不会快速重传。这种情况下发送方只好等到超时了再重传，此类重传包就会被Wireshark标上[TCP Retransmission]。
TCP zerowindow

当Wireshark 在一个包中发现接收窗口为0时，就会给它打上“TCP zerowindow”的标志，表示缓存区已满，不能再接收数据了。
TCP window Full

当Wireshark 在一个包中打上[TCP window Full]标志时，就表示这个包的发送方已经把对方所声明的接收窗口耗尽了。
TCP segment of a reassembled PDU

当你收到这个提示，肯定已经在Edit􀃆Preferences/Protocols/TCP 菜单里启用了Allow sub dissector to reassemble TCP streams。它表示Wireshark 可以把属于同一个应用层PDU（比如SMB 的Read Response 和Write Request 之类）的TCP包虚拟地集中起来。
Continuation to #

你看到这个提示，说明已经在Edit/Preferences/Protocols/TCP 菜单里关闭了Allow sub dissector to reassemble TCP streams。
Time-to-live exceeded (Fragment reassembly time exceeded

表示这个包的发送方之前收到了一些分片，但是由于某些原因迟迟无法组装起来