Wireshark 用户使用手册 ———— 数据分析

跟踪协议流（Following Protocol Streams）

 以应用层看待协议的方式看待协议是非常有帮助的。 也许您正在 Telnet 流中寻找密码，或者您正在尝试理解数据流。 也许您只需要一个显示过滤器来仅显示 TLS 或 SSL 流中的数据包。 如果是这样，Wireshark 跟踪协议流的能力将对您有用。要过滤到特定流，请在需要过滤的流或者连接的数据包列表中选择指定流的数据包。 Wireshark 将设置适当的显示过滤器并显示一个对话框，其中包含来自流的数据布局，如“Follow TCP Stream”对话框中所示。跟踪协议流应用显示过滤器，该过滤器选择当前流中的所有数据包。 有些人打开“Follow TCP Stream”对话框并立即关闭它，作为隔离特定流的快速方法。 如果不需要此行为，使用“back”按钮关闭对话框将重置显示过滤器。

 流内容的显示顺序与其在网络上出现的顺序相同。 不可打印的字符由点代替。 从客户端到服务器的流量为红色，而从服务器到客户端的流量为蓝色。 这些颜色是可以进行更改。 进行实时捕获时不会更新流内容。 要获取最新内容，您必须重新打开对话框。

Function of Follow TCP Stream Dialog Box
Function	Description
Help	显示帮助文档
Filter out this stream	应用显示过滤器从显示中删除当前流数据
Print	以当前选择的格式打印流数据
Save as…	以当前选择的格式保存流数据
Back	关闭此对话框并恢复先前的显示过滤器
Close	关闭此对话框，使当前显示过滤器有效

 默认情况下，Wireshark 显示客户端和服务器数据。 您可以选择整个对话以在客户端到服务器或服务器到客户端数据之间切换。 您可以选择以下列格式之一查看数据：
  1. ASCII
  2. C Arrays
  3. EBCDIC
  4. HEX Dump
  5. UTF-8
  6. UTF-16
  7. YAML
  8. Raw

数据包字节（Show Packet Bytes ）

 如果选定的数据包字段未显示所有字节（即它们在显示时被截断），或者如果它们显示为字节而不是字符串，或者如果它们需要更多格式，因为它们包含图像或 HTML，则可以使用此对话框。 此对话框还可用于解码来自 base64、zlib 压缩或引用打印的字段字节，并将解码的字节显示为可配置输出。 也可以选择一个字节子集来设置开始字节和结束字节。

 您可以选择以下操作：
  1. Help：显示帮助文档。
  2. Print：以当前选择的格式打印字节。
  3. Copy：以当前选择的格式将字节复制到剪贴板。
  4. Save As：以当前选择的格式保存字节。
  5. Close：关闭此对话框。

 可以选择从以下格式之一解码数据：
  1. NoneL：默认值，不解码任何东西。
  2. Base64： Base64 解码
  3. Compressed：使用 zlib 解压缩缓冲区。
  4. Quoted-Printable：Quoted-Printable 字符串解码
  5. ROT-13：解码 ROT-13 编码的文本

 可以选择以下列格式之一查看数据：
  1. ASCII
  2. C Arrays
  3. EBCDIC
  4. HEX Dump
  5. HTML
  6. Image
  7. ISO 8859-1
  8. Raw
  9. ASCII & Control
  10. UTF-8
  11. UTF-16
  12. YAML

专家信息（Expert Information）

 Wireshark 会跟踪它在捕获文件中找到的任何异常和其他感兴趣的项目，并在“专家信息”对话框中显示它们。 目标是让您更好地了解不常见或显着的网络行为，并让新手和专家用户比手动扫描数据包列表更快地找到网络问题。专家信息是调查的起点，而不是终点。 每个网络都是不同的，由你来验证 Wireshark 的专家信息是否适用于你的特定情况。 专家信息的存在并不一定表明存在问题，专家信息的缺乏并不一定意味着一切正常。 专家信息的数量很大程度上取决于所使用的协议。 虽然 TCP 和 IP 等一些常见协议的解析器会显示详细信息，但其他解析器将显示很少或不显示。 下面描述了单个专家信息条目以及专家用户界面的组件。

Intruduction of Expert Information
Module	Item	Description
Severity	Chat (blue)	有关常规工作流程的信息
	Note (cyan)	值得注意的事件
	Warn (yellow)	应用程序返回了一个不寻常的错误代码，如连接问题
	Error (red)	严重的问题，如格式错误的数据包
Summary	-	每个专家信息项的简短说明文本
Group	Assumption	协议字段数据不完整，根据假设值进行剖析
	Checksum	校验和无效
	Comment	包注释
	Debug	调试信息 不应该在 Wireshark 的发布版本中看到这个组
	Decryption
	Deprecated	协议字段已被弃用
	Malformed	格式错误的数据包或解剖器有一个错误 该数据包的解剖中止
	Protocol	违反协议规范（例如无效的字段值或非法长度） 对该数据包的剖析可能还在继续
	Reassemble	重新组装时出现问题，并非所有片段都可用，或者在重组过程中发生异常
	Request Code	应用程序请求 通常分配聊天严重性级别
	Response Code	应用程序响应代码表示潜在问题，例如 未找到 HTTP 404 页面
	Security	安全问题，例如不安全的实现
	Sequence	协议序列号是可疑的，例如它不是连续的或检测到重传
	Undecoded	解剖不完整或由于其他原因无法解码数据
Protocol	-	创建专家信息项的协议解析器

Function of Expert Information Dialog
Item	Description
Limit to display filter	仅显示与当前显示过滤器匹配的数据包中存在的专家信息项
Group by summary	按其摘要而不是上述组对项目进行分组
Search	仅显示与搜索字符串匹配的项目 支持正则表达式
Show…	显示或隐藏每个严重性级别
Help	进入用户指南
Close	关闭对话框

TCP 分析（TCP Analysis）

 默认情况下，Wireshark 的 TCP 解析器会跟踪每个 TCP 会话的状态，并在检测到问题或潜在问题时提供附加信息。 首次打开捕获文件时，会对每个 TCP 数据包进行一次分析。 数据包按照它们出现在数据包列表中的顺序进行处理。 可以通过“分析 TCP 序列号”TCP 解析器首选项启用或禁用此功能。TCP 分析标志被添加到“SEQ/ACK 分析”下的 TCP 协议树中。 每个标志如下所述：
  1. Next expected sequence number
    最后看到的序列号加上段长度。 在没有分析标志和零窗口探针时设置。 这最初为零，并根据同一 TCP 流中的前一个数据包计算得出。这可能与 tcp.nxtseq 协议字段不同。
  2. Next expected acknowledgement number
    段的最后看到的序列号。 在没有分析标志和零窗口探针时设置。
  3. Last-seen acknowledgment number
    始终设置。 这与下一个预期的确认编号不同。
  4. Last-seen acknowledgment number
    始终为每个数据包更新。 这与下一个预期的确认编号不同。

TCP ACKed unseen segment

 当为反向设置预期的下一个确认号并且它小于当前确认号时设置。

TCP Dup ACK [frame]#[acknowledgement number]

 当以下所有条件都为真时设置：
  1. 段大小为零。
  2. 窗口大小非零且未更改。
  3. 下一个预期序列号和最后看到的确认号是非零的（即连接已建立）。
  4. SYN、FIN 和RST 未设置。

TCP Fast Retransmission

 当以下所有条件都为真时设置：
  1. 非keepalive 数据包。
  2. 在正向中，段大小大于零或设置了 SYN 或 FIN。
  3. 下一个预期序列号大于当前序列号。
  4. 有两个以上的反向重复 ACK。
  5. 当前序列号等于下一个预期确认号。
  6. 20 毫秒内看到了最后一次确认。

TCP Keep-Alive

 当段大小为零或一时设置，当前序列号比下一个预期序列号少一个字节，并且设置了SYN、FIN或RST中的任何一个。

TCP Keep-Alive ACK

 当以下所有条件都为真时设置：
  1. 段大小为零。
  2. 窗口大小非零且未更改。
  3. 当前序列号与下一个预期序列号相同。
  4. 当前确认编号与上次看到的确认编号相同。
  5. 最近看到的反向数据包是keepalive。
  6. 数据包不是SYN、FIN 或RST。

TCP Out-Of-Order

 当以下所有条件都为真时设置：
  1. 这不是keepalive 数据包。
  2. 在正向中，段长度大于零或设置了 SYN 或 FIN。
  3. 下一个预期序列号大于当前序列号。
  4. 下一个预期序列号大于或等于下一个序列号。
  5. 最后一段到达乱序RTT 阈值内。

TCP Port numbers reused

 设置 SYN 标志时（不是 SYN+ACK），有一个使用相同地址和端口的现有对话，并且序列号与现有对话的初始序列号不同。

TCP Previous segment not captured

 当前序列号大于下一个预期序列号时设置。

TCP Spurious Retransmission

 根据反向分析数据检查重传。 当以下所有条件都为真时设置：
  1. SYN 或FIN 标志被设置。
  2. 这不是keepalive 数据包。
  3. 段长度大于零。
  4. 此流的数据已被确认。 也就是说，最后看到的确认号已经设置。
  5. 下一个序列号小于或等于最后看到的确认号。

TCP Retransmission

 当以下所有条件都为真时设置：
  1. 这不是keepalive 数据包。
  2. 在正向中，段长度大于零或设置了 SYN 或 FIN 标志。
  3. 下一个预期序列号大于当前序列号。

TCP Window Full

 当segment size非零时设置，我们知道反向的窗口大小，我们的segment大小超过了反向的窗口大小。

TCP Window Update

 当以下所有条件都为真时设置：
  1. 段大小为零。
  2. 窗口大小非零且不等于最后看到的窗口大小。
  3. 序列号等于下一个预期序列号。
  4. 确认号等于最后看到的确认号。
  5. SYN、FIN 或RST 均未设置。

TCP ZeroWindow

 当接收窗口大小为零且未设置 SYN、FIN 或 RST 时设置。每个 TCP 报头中的窗口字段通告接收方可以接受的数据量。 如果接收方不能再接受任何数据，它会将窗口值设置为零，这会告诉发送方暂停其传输。 在某些特定情况下，这是正常的——例如，打印机可能会在加载或反转一张纸时使用零窗口来暂停打印作业的传输。 但是，在大多数情况下，这表明接收端存在性能或容量问题。 恢复暂停的连接可能需要很长时间（有时几分钟），即使导致零窗口的基础条件很快清除。

TCP ZeroWindowProbe

 当序列号等于下一个预期序列号时设置，段大小为1，反向上次看到的窗口大小为零。如果来自零窗口探针的单个数据字节被接收器丢弃，则如果该段满足以下所有以下条件，则不应将后续段标记为重传： 段大小大于 1。 下一个预期序列号比当前序列号小 1。

TCP ZeroWindowProbeAck

 当以下所有条件都为真时设置：
  1. 段大小为零。
  2. 窗口大小为零。
  3. 序列号等于下一个预期序列号。
  4. 确认号等于最后看到的确认号。
  5. 最后看到的反向数据包是零窗口探测。

TCP Ambiguous Interpretations

 有些捕获很难自动分析，特别是当时间范围可能涵盖快速重传和乱序数据包时。 TCP 首选项允许在协议级别切换这两种解释的优先级。

TCP Conversation Completeness

 当 TCP 对话同时具有打开和关闭握手时，就被认为是完整的，独立于任何数据传输。 但是，我们可能对识别发送的某些数据的完整对话感兴趣，我们正在使用以下位值在 tcp.completeness 字段上构建过滤器值：
   1 : SYN
   2 : SYN-ACK
   4 : ACK
   8 : DATA
   16 : FIN
   32 : RST

时间戳（Time Stamps）

 时间戳、它的精度以及所有这些都可能令人困惑。 当数据包被捕获时，每个数据包都会在它进入时加上时间戳。这些时间戳将保存到捕获文件中，因此它们也可用于分析。 那么这些时间戳是从哪里来的呢？ 在捕获时，Wireshark 从 libpcap (Npcap) 库中获取时间戳，而后者又从操作系统内核中获取它们。 如果捕获数据是从捕获文件加载的，Wireshark 显然会从该文件中获取数据。

Wireshark Internals

 Wireshark 用来保存数据包时间戳的内部格式由日期（自 1970 年 1 月 1 日以来的天数）和一天中的时间（自午夜以来的纳秒数）组成。 可以调整Wireshark在数据包列表中显示时间戳数据的方式，详见“Time Display Format”。 Wireshark 在读取或写入捕获文件时，根据需要在捕获文件格式和内部格式之间转换时间戳数据。 捕获时，Wireshark 使用支持微秒分辨率的 libpcap (Npcap) 捕获库。

Capture File Formats

 Wireshark 知道的每种捕获文件格式都支持时间戳。 特定捕获文件格式支持的时间戳精度差异很大，从一秒“0”到一纳秒“0.123456789”不等。 大多数文件格式以固定精度存储时间戳，而某些文件格式甚至能够存储时间戳精度本身。 Wireshark使用的常见 libpcap 捕获文件格式仅支持固定的微秒分辨率“0.123456”。 将数据写入不提供存储实际精度能力的捕获文件格式将导致信息丢失。 例如，如果加载一个纳秒分辨率的捕获文件并将捕获数据存储在一个 libpcap 文件中（微秒分辨率），Wireshark 显然必须将精度从纳秒降低到微秒。

Accuracy

 Wireshark 本身不会创建任何时间戳，而只是从“其他地方”获取它们并显示它们。 因此准确性将取决于您使用的捕获系统（操作系统、性能等）。USB 连接的网络适配器通常提供非常糟糕的时间戳准确性。 传入的数据包必须经过“漫长而曲折的道路”才能通过 USB 电缆传输，直到它们真正到达内核。 由于传入的数据包在被内核处理时被打上了时间戳，这种时间戳机制变得非常不准确。 当您需要精确的时间戳精度时，不要使用 USB 连接的 NIC。

时区（Time Zones）

 如果在地球上旅行，时区可能会令人不适。 如果从世界各地的某个时区获取捕获文件甚至会更加混乱。 首先，你可能根本不需要考虑时区的原因有两个：
  1. 只对数据包时间戳之间的时间差感兴趣，不需要了解捕获数据包的确切日期和时间。
  2. 不会从与自己的时区不同的时区获取捕获文件，因此根本不存在时区问题。

 时区的基准时间是 UTC（Coordinated Universal Time）或祖鲁时间（军事和航空）。 不应使用旧术语 GMT（Greenwich Mean Time），因为它略有错误（与 UTC 相差最多 0.9 秒）。 UTC 基准时间等于 0（基于英格兰格林威治），所有时区与 UTC 的偏移量在 -12 到 +14 小时之间。还有一个是Daylight Saving Time (DST)。 为此，许多国家/地区将 DST 小时添加到现有的 UTC 偏移量。 因此，可能需要再花一个小时（或在极少数情况下甚至是两个小时！）的时区计算差异。具体的情况请使用者自身量定。

数据包重组（Packet Reassembly）

 网络协议通常需要传输大量数据，这些数据本身是完整的，例如 传输文件时。 底层协议可能无法处理该块大小（网络数据包大小的限制），或者像 TCP 一样基于流，它根本不知道数据块。 在这种情况下，网络协议必须自己处理块边界，并且将数据分布在多个数据包上。 它显然还需要一种机制来确定接收方的块边界。 Wireshark 将这种机制称为重组，尽管特定的协议规范可能为此使用不同的术语（desegmentation, defragmentation等）。

 对于 Wireshark 知道的一些网络协议，实施了一种机制来查找、解码和显示这些数据块。 Wireshark 将尝试找到该块的相应数据包，并将组合数据显示为“Packet Bytes”窗格中的附加页面。

名称解析（Name Resolution）

  Name Resolution 尝试将一些数字地址值转换为人类可读的格式。 根据要完成的解析，有两种可能的方法进行这些转换：调用系统/网络服务（如 gethostname() 函数）和/或从 Wireshark 特定配置文件解析。可以为以下部分中列出的协议层单独启用名称解析功能。

Name Resolution Drawbacks

  1. 名称解析经常会失败。 要解析的名称可能只是被询问的名称服务器未知，或者服务器不可用并且该名称也未在 Wireshark 的配置文件中找到。
  2. 解析名称可能不可用。 Wireshark 从各种来源获取名称解析信息，包括 DNS 服务器、捕获文件本身以及系统和配置文件目录中的主机文件。如果稍后或在不同的机器上打开捕获文件，则解析的名称可能不可用。
  3. DNS 可能会向你的捕获文件添加额外的数据包。 如果来自 Wireshark 的 DNS 查询和响应的额外流量影响你尝试排除故障或任何后续分析的问题，可能会遇到观察者效应。
  4. 已解析的 DNS 名称由 Wireshark 缓存。 这是可接受的性能所必需的。但是，如果在 Wireshark 运行时名称解析信息发生变化，Wireshark 将不会注意到名称解析信息在缓存后发生变化。 如果这
Wireshark 运行时信息会发生变化，例如 新的 DHCP 租约生效，Wireshark 不会注意到。

Ethernet Name Resolution (MAC Layer)

 1. ARP： Wireshark 会要求操作系统将以太网地址转换为相应的 IP 地址（例如 00:09:5b:01:02:03 → 192.168.0.1）。
 2. 以太网代码（ethers 文件）： 如果 ARP 名称解析失败，Wireshark 会尝试将以太网地址转换为用户使用 ethers 文件分配的已知设备名称（例如 00:09:5b:01:02: 03 → 家庭路由器）。
 3. 以太网制造商代码（manuf 文件）： 如果 ARP 或 ethers 都没有返回结果，Wireshark 会尝试将以太网地址的前 3 个字节转换为 IEEE 指定的缩写制造商名称（例如 00:09:5b： 01:02:03 → Netgear_01:02:03）。

IP Name Resolution (Network Layer)

 DNS 名称解析（系统/库服务）： Wireshark 将使用名称解析器将 IP 地址转换为与其关联的主机名（例如 216.239.37.99 → www.1.google.com）。
 大多数应用程序使用同步 DNS 名称解析。Web 浏览器必须先解析 URL 的主机名部分，然后才能连接到服务器。捕获文件分析是不同的。一个给定的文件可能有数百、数千或数百万个 IP 地址，因此出于可用性和性能原因，Wireshark 使用异步解析。这两种机制都将 IP 地址转换为人类可读的（域名）名称，并且通常使用不同的来源，例如系统主机文件 (/etc/hosts) 和任何配置的 DNS 服务器。由于 Wireshark 不等待 DNS 响应，因此当你第一次查看给定数据包时，给定地址的主机名可能会丢失，但在你以后查看时会出现。可以在首选项对话框的名称解析部分调整名称解析行为。可以通过将主机文件添加到您的个人配置目录来控制分辨率本身。还可以编辑系统主机文件，但通常不建议这样做。

TCP/UDP Port Name Resolution (Transport Layer)

 TCP/UDP 端口转换（系统服务）： Wireshark 会要求操作系统将 TCP 或 UDP 端口转换为其众所周知的名称（例如 80 → http）。

VLAN ID Resolution

 要获取 VLAN 标记 ID 的描述性名称，可以使用 vlans 文件。

SS7 Point Code Resolution

 要获取 SS7 点代码的节点名称，可以使用 ss7pcs 文件。

校验和（Checksums）

 一些网络协议使用校验和来确保数据完整性。 应用此处所述的校验和也称为冗余检查。校验和用于确保数据传输或存储的数据部分的完整性。校验和基本上是这种数据部分的计算摘要。网络数据传输通常会产生错误，例如切换、丢失或重复位。这会导致接收到的数据可能与传输的数据不一致。由于这些传输错误，网络协议经常使用校验和来检测此类错误。发送器将计算数据的校验和并将数据与校验和一起发送。接收器将使用与发送器相同的算法计算接收数据的校验和。如果接收和计算的校验和不匹配，则发生传输错误。一些校验和算法能够通过计算预期错误的位置并修复它来恢复错误。如果出现无法恢复的错误，则接收方丢弃该数据包。根据网络协议，这种数据丢失会被简单地忽略，或者发送方需要以某种方式检测到这种丢失并重新传输所需的数据包。使用校验和可以大大减少未检测到的传输错误的数量。但是，通常的校验和算法不能保证 100% 的错误检测，因此可能会有极少量的传输错误未被检测到。 有几种不同类型的校验和算法；经常使用的校验和算法的例子是 CRC32。为特定网络协议实际选择的校验和算法将取决于网络介质的预期错误率、错误检测的重要性、执行计算的处理器负载、所需的性能以及许多其他因素。

Wireshark Checksum Validation

 Wireshark 将验证许多协议的校验和，例如 IP、TCP、UDP 等。它将执行与普通接收器相同的计算，并在数据包详细信息中显示校验和字段，并带有注释。 可以在 Wireshark 协议首选项中为各种协议关闭校验和验证。 如果启用校验和验证并且检测到无效的校验和，则不会处理数据包重组等功能。 这是可以避免的，因为不正确的连接数据可能会混淆内部数据库。

Checksum Offloading

 校验和计算可能由网络驱动程序、协议驱动程序甚至硬件完成。如果接收到的校验和错误，Wireshark 甚至不会看到数据包，因为以太网硬件内部会丢弃数据包。 更高级别的校验和传统上由协议实现计算，然后将完成的数据包移交给硬件。 最近的网络硬件可以执行高级功能，例如 IP 校验和计算，也称为校验和卸载。 网络驱动程序不会自己计算校验和，而是简单地将一个空的（零或垃圾填充）校验和字段交给硬件。校验和卸载通常会导致混淆，因为要传输的网络数据包在实际计算校验和之前已移交给 Wireshark。 Wireshark 获取这些空校验和并将它们显示为无效，即使数据包稍后离开网络硬件时将包含有效的校验和。Checksum Offloading 可能会令人困惑，并且在屏幕上显示大量无效消息可能非常烦人。 如上所述，无效的校验和可能导致未重组的数据包，使数据包数据的分析变得更加困难。 可以做两件事来避免Checksum Offloading 问题：
  1. 如果此选项可用，关闭网络驱动程序中的校验和卸载。
  2. 在 Wireshark 首选项中关闭特定协议的校验和验证。 由于现代硬件和操作系统中卸载的盛行，Wireshark 的最新版本默认禁用校验和验证。