土法炼钢兴趣小组的算法知识备份

【网络工程】Wireshark 深度分析:流图、专家信息与协议解析

文章导航

分类入口
network
标签入口
#wireshark#packet-analysis#tshark#network-diagnostics

目录

tcpdump 负责精确捕获,Wireshark 负责深度分析——这是网络诊断的黄金搭档。

大多数工程师用 Wireshark 只会”打开 pcap 文件,肉眼扫描”。但 Wireshark 真正的威力在于:Display Filter 的精确过滤、Expert Information 的自动诊断、TCP Stream Graph 的可视化分析、以及 tshark 的批量处理能力。掌握这些能力,一个 pcap 文件能告诉你的信息远超你的想象。

一、Display Filter vs Capture Filter

1.1 两种过滤器的本质区别

Capture Filter (BPF):
  作用时机: 抓包时
  执行位置: 内核态
  语法:     BPF 语法(pcap-filter)
  特点:     高性能,但语法受限
  示例:     tcp port 80 and host 10.0.1.5

Display Filter:
  作用时机: 分析时(包已经捕获后)
  执行位置: 用户态
  语法:     Wireshark 专有语法(功能更强大)
  特点:     可以过滤任何协议字段
  示例:     tcp.port == 80 && ip.addr == 10.0.1.5

关键区别:
  BPF: tcp port 80
  Display Filter: tcp.port == 80

  BPF: host 10.0.1.5
  Display Filter: ip.addr == 10.0.1.5

  Display Filter 可以做到 BPF 做不到的事:
  - 过滤 TCP 重传: tcp.analysis.retransmission
  - 过滤 HTTP 状态码: http.response.code == 500
  - 过滤 TLS 版本: tls.handshake.version == 0x0303
  - 过滤 DNS 响应类型: dns.qry.type == 28 (AAAA)

1.2 Display Filter 高级语法

基础比较:
  ip.addr == 10.0.1.5          精确匹配
  ip.addr != 10.0.1.5          不等于
  tcp.port >= 8000             大于等于
  frame.len > 1000             帧长度大于 1000

字符串匹配:
  http.host == "api.example.com"    精确匹配
  http.host contains "example"      包含
  http.host matches "api\\..*\\.com" 正则表达式

集合匹配:
  tcp.port in {80, 443, 8080}       端口在集合中
  http.response.code in {500..599}  HTTP 5xx 错误

逻辑运算:
  &&  或  and     与
  ||  或  or      或
  !   或  not     非

字段存在性:
  tcp.analysis.retransmission       字段存在即匹配
  !dns                              不是 DNS 包

切片:
  tcp.payload[0:4] == "GET "        TCP 负载前 4 字节
  eth.addr[0:3] == 00:1a:2b        MAC 地址前 3 字节(OUI)

1.3 常用 Display Filter 速查

TCP 诊断:
  tcp.analysis.retransmission        重传
  tcp.analysis.fast_retransmission   快速重传
  tcp.analysis.duplicate_ack         重复 ACK
  tcp.analysis.zero_window           零窗口
  tcp.analysis.window_update         窗口更新
  tcp.analysis.keep_alive            Keep-Alive
  tcp.analysis.reset                 RST 分析
  tcp.analysis.out_of_order          乱序包
  tcp.analysis.lost_segment          丢包(推断)
  tcp.flags.syn == 1 && tcp.flags.ack == 0   纯 SYN
  tcp.flags.reset == 1               RST 包

HTTP:
  http.request                       HTTP 请求
  http.response                      HTTP 响应
  http.response.code >= 400          4xx + 5xx 错误
  http.response.code == 502          502 错误
  http.request.method == "POST"      POST 请求
  http.host == "api.example.com"     指定 Host
  http.content_type contains "json"  JSON 响应
  http.time > 1                      响应时间 > 1 秒

TLS:
  tls.handshake                      TLS 握手消息
  tls.handshake.type == 1            ClientHello
  tls.handshake.type == 2            ServerHello
  tls.handshake.type == 11           Certificate
  tls.alert_message                  TLS Alert
  tls.handshake.extensions.server_name == "example.com"  SNI

DNS:
  dns.qry.name == "example.com"      查询域名
  dns.flags.rcode == 3               NXDOMAIN
  dns.flags.rcode == 2               SERVFAIL
  dns.time > 0.5                     DNS 响应 > 500ms
  dns.qry.type == 1                  A 记录查询
  dns.qry.type == 28                 AAAA 记录查询

二、Expert Information

Expert Information 是 Wireshark 最强大的自动诊断功能——它分析整个抓包文件,标记出所有可疑的网络行为。

2.1 四个级别

Expert Information 级别:

  🔴 Error(错误):
    确定性的协议违规或严重问题
    示例: 校验和错误、畸形包、协议解析失败
    必须关注: 有 Error 一定有问题

  🟡 Warning(警告):
    值得关注的异常行为
    示例: TCP 重传、乱序包、窗口满、连接重置
    需要判断: 少量可能正常,大量则有问题

  🔵 Note(提示):
    正常但值得注意的事件
    示例: TCP Keep-Alive、零窗口探测、重复 ACK
    通常正常: 但异常多时可能指示问题

  💬 Chat(信息):
    正常的协议行为记录
    示例: TCP 连接建立/关闭、TLS 握手步骤
    可以忽略: 纯粹的信息记录

2.2 关键 Warning 解读

TCP 重传相关:

  "Retransmission" (Warning):
    包被重传了
    少量: 正常(互联网有 0.1-1% 的丢包率)
    大量: 网络质量问题

  "Fast Retransmission" (Warning):
    收到 3 个重复 ACK 后立即重传(不等 RTO)
    比普通重传好——说明接收方在积极通知丢包

  "Spurious Retransmission" (Warning):
    虚假重传——原始包已经被确认,但又重传了
    原因: RTO 估算不准、ACK 延迟到达

  "Out-Of-Order" (Warning):
    包的序列号不连续
    少量: 多路径路由导致
    大量: 网络路径不稳定

TCP 窗口相关:

  "Zero Window" (Warning):
    接收方通告窗口为 0——"别再发了,我处理不过来"
    原因: 应用层消费太慢、内存不足

  "Window Full" (Warning):
    发送方已经填满了接收方通告的窗口
    正常现象,但频繁出现说明接收方处理能力不足

  "Window Update" (Note):
    接收方更新了窗口大小(通常是零窗口恢复后)

连接相关:

  "Connection Reset" (Warning):
    TCP 连接被 RST 重置
    可能原因: 服务端崩溃、防火墙干预、端口未监听

  "TCP ACKed unseen segment" (Warning):
    确认了一个 Wireshark 没有捕获到的包
    通常是因为抓包不完整(开始抓包时连接已存在)

2.3 使用 Expert Information 的工作流

步骤 1: 打开 Expert Information
  菜单: Analyze → Expert Information
  或: 状态栏左下角的彩色圆点

步骤 2: 按级别排序
  先看 Error(必须处理)
  再看 Warning(重点分析)
  Note 和 Chat 可以暂时忽略

步骤 3: 点击条目跳转到对应包
  双击 Expert Information 条目
  Wireshark 会定位到该包并高亮

步骤 4: 用 Display Filter 聚焦
  发现大量重传?→ 过滤: tcp.analysis.retransmission
  发现零窗口?→ 过滤: tcp.analysis.zero_window
  发现 RST?→ 过滤: tcp.flags.reset == 1

步骤 5: 结合 Follow TCP Stream
  右键 → Follow → TCP Stream
  查看完整的 TCP 会话内容
  对 HTTP 特别有用——可以看到请求和响应的全文

三、TCP Stream Graph

3.1 IO Graph

菜单: Statistics → I/O Graphs

IO Graph 显示时间维度上的包速率、字节速率等

默认配置:
  X 轴: 时间
  Y 轴: 包/秒 或 字节/秒
  间隔: 1 秒

实用配置:

  图 1: 总流量
    Display Filter: (留空)
    Y Axis: Bytes/s

  图 2: 重传率
    Display Filter: tcp.analysis.retransmission
    Y Axis: Packets/s
    颜色: 红色

  图 3: HTTP 错误
    Display Filter: http.response.code >= 400
    Y Axis: Packets/s
    颜色: 橙色

  图 4: DNS 查询
    Display Filter: dns.flags.response == 0
    Y Axis: Packets/s
    颜色: 蓝色

分析技巧:
  - 重传率和流量高峰重合 → 拥塞导致丢包
  - 重传率在流量低谷也高 → 网络质量问题(不是拥塞)
  - HTTP 错误和流量高峰重合 → 服务端过载
  - DNS 查询突增 → 可能是 DNS 缓存失效或 DNS 攻击

3.2 TCP Stream Graph: Stevens

菜单: Statistics → TCP Stream Graphs → Stevens Graph

Stevens 图是最经典的 TCP 分析工具:
  X 轴: 时间
  Y 轴: 序列号
  每个点代表一个数据包

正常的 Stevens 图:
  - 斜线上升: 数据持续发送
  - 斜率 = 吞吐量
  - 平坦段: 等待 ACK 或窗口满

异常模式:

  阶梯状(不平滑):
    发一批 → 等待 → 发一批 → 等待
    原因: 窗口太小或 Nagle 算法

  长时间平坦:
    序列号不增长
    原因: 零窗口、应用层没有新数据

  突然回退:
    序列号跳回之前的值
    原因: 重传

  斜率突变:
    斜率突然变低
    原因: 拥塞窗口缩减(丢包触发)

3.3 TCP Stream Graph: Round Trip Time

菜单: Statistics → TCP Stream Graphs → Round Trip Time Graph

RTT 图:
  X 轴: 序列号
  Y 轴: RTT(毫秒)
  每个点代表一个 ACK 的 RTT 测量

正常 RTT:
  - 稳定在一个范围内(如 2-5ms 局域网,50-100ms 跨城)
  - 偶尔小幅波动

异常模式:

  RTT 突然飙升:
    某个时间点 RTT 从 5ms 跳到 200ms
    原因: 网络拥塞、路由变更、中间设备排队

  RTT 持续增长:
    RTT 逐渐上升
    原因: 缓冲区膨胀(Bufferbloat)、接收方处理变慢

  RTT 双峰分布:
    有两组明显不同的 RTT 值
    原因: 多路径路由、不同网段的服务器

  RTT 周期性波动:
    RTT 有规律地高低交替
    原因: 定时任务导致网络拥塞、TCP 拥塞窗口振荡

3.4 Flow Graph

菜单: Statistics → Flow Graph
选择: TCP Flows

Flow Graph 显示主机之间的消息交互时序:

  10.0.1.5          10.0.1.10
     │                  │
     │──SYN────────────→│  t=0.000
     │                  │
     │←─SYN-ACK─────── │  t=0.005 (RTT/2 ≈ 5ms)
     │                  │
     │──ACK────────────→│  t=0.005
     │                  │
     │──[PSH,ACK]──────→│  t=0.006 (HTTP GET)
     │                  │
     │←─[ACK]───────── │  t=0.011
     │                  │
     │←─[PSH,ACK]───── │  t=0.015 (HTTP Response)
     │                  │
     │──[ACK]──────────→│  t=0.015
     │                  │

  从 Flow Graph 可以直接读出:
  - TCP 三次握手 RTT: 5ms
  - 服务端处理时间: 15ms - 6ms = 9ms(从收到请求到开始响应)
  - 数据传输时间: 查看 ACK 和数据包的时间差

四、tshark 批量分析

4.1 基本用法

# tshark 是 Wireshark 的命令行版本
# 适合在服务器上或脚本中使用

# 基本读取
tshark -r capture.pcap

# 使用 Display Filter
tshark -r capture.pcap -Y 'tcp.analysis.retransmission'

# 输出指定字段
tshark -r capture.pcap -Y 'http.response' \
    -T fields -e frame.time -e http.response.code \
    -e http.content_length -e http.time

# 统计信息
tshark -r capture.pcap -z io,stat,1
tshark -r capture.pcap -z conv,tcp
tshark -r capture.pcap -z endpoints,ip

4.2 实用分析命令

# 1. HTTP 响应时间分布
tshark -r capture.pcap -Y 'http.time' \
    -T fields -e http.request.uri -e http.time | \
    sort -t$'\t' -k2 -rn | head -20

# 2. TCP 重传率统计
TOTAL=$(tshark -r capture.pcap -T fields -e frame.number | wc -l)
RETRANS=$(tshark -r capture.pcap -Y 'tcp.analysis.retransmission' \
    -T fields -e frame.number | wc -l)
echo "重传率: $(echo "scale=4; $RETRANS / $TOTAL * 100" | bc)%"

# 3. 连接统计(每对 IP:Port 的包数和字节数)
tshark -r capture.pcap -z conv,tcp -q

# 输出示例:
# IP A:Port A     IP B:Port B     Frames  Bytes  Frames  Bytes
# 10.0.1.5:43210  10.0.1.10:80    156     12840  203     156000

# 4. DNS 查询统计
tshark -r capture.pcap -Y 'dns.flags.response == 0' \
    -T fields -e dns.qry.name | sort | uniq -c | sort -rn | head

# 5. TLS 版本和密码套件
tshark -r capture.pcap -Y 'tls.handshake.type == 2' \
    -T fields -e tls.handshake.version \
    -e tls.handshake.ciphersuite

# 6. 每秒包速率
tshark -r capture.pcap -z io,stat,1 -q

# 7. RTT 统计
tshark -r capture.pcap \
    -Y 'tcp.analysis.ack_rtt' \
    -T fields -e tcp.analysis.ack_rtt | \
    awk '{sum+=$1; n++; if($1>max)max=$1} END {
        printf "avg=%.3fms max=%.3fms n=%d\n", sum/n*1000, max*1000, n
    }'

# 8. 找出所有 RST 的来源
tshark -r capture.pcap -Y 'tcp.flags.reset == 1' \
    -T fields -e ip.src -e ip.dst -e tcp.srcport -e tcp.dstport | \
    sort | uniq -c | sort -rn

4.3 tshark 统计模式

# 协议分层统计
tshark -r capture.pcap -z io,phs -q

# 输出:
# Protocol Hierarchy Statistics
# eth  frames:10000 bytes:5000000
#   ip  frames:9900 bytes:4950000
#     tcp  frames:9500 bytes:4750000
#       http  frames:2000 bytes:1500000
#       tls  frames:5000 bytes:3000000
#     udp  frames:400 bytes:200000
#       dns  frames:350 bytes:100000

# HTTP 请求/响应统计
tshark -r capture.pcap -z http,tree -q

# HTTP 状态码分布
tshark -r capture.pcap -z http,stat,1 -q

# 端点统计(按字节排序)
tshark -r capture.pcap -z endpoints,ip -q

# 会话统计
tshark -r capture.pcap -z conv,tcp -q

# Expert Information 统计
tshark -r capture.pcap -z expert -q
# 直接看所有 Warning 和 Error,无需打开 GUI

五、TLS 解密

5.1 使用 Pre-Master Secret

Wireshark 可以解密 TLS 流量——前提是你有密钥。

方法 1: Pre-Master Secret 日志文件(推荐)

  大多数 TLS 库支持导出 Pre-Master Secret:

  # Chrome / Firefox
  export SSLKEYLOGFILE=/tmp/tls-keys.log
  google-chrome  # 或 firefox

  # curl
  export SSLKEYLOGFILE=/tmp/tls-keys.log
  curl https://example.com

  # Go 程序
  // 在代码中设置 KeyLogWriter
  tlsConfig := &tls.Config{
      KeyLogWriter: keyLogFile,
  }

  # Python requests
  import sslkeylog
  sslkeylog.set_keylog("/tmp/tls-keys.log")

Wireshark 配置:
  Edit → Preferences → Protocols → TLS
  → (Pre)-Master-Secret log filename: /tmp/tls-keys.log

  配置后 Wireshark 自动解密 TLS 流量
  可以看到 HTTP/2 帧、gRPC 消息等

5.2 使用服务端私钥

方法 2: 服务端 RSA 私钥(仅限 RSA 密钥交换)

  Edit → Preferences → Protocols → TLS → RSA keys list
  → Edit → Add:
    IP Address: 10.0.1.10
    Port: 443
    Protocol: http
    Key File: /path/to/server.key

  限制:
  - 仅适用于 RSA 密钥交换(非 ECDHE)
  - TLS 1.3 不支持(TLS 1.3 强制使用 ECDHE)
  - 不推荐: 需要服务端私钥,安全风险大

  推荐始终使用 Pre-Master Secret 方法。

六、Lua 自定义解析器

Wireshark 支持用 Lua 编写自定义协议解析器(Dissector),用于解析私有协议。

6.1 基本 Dissector

-- 自定义协议解析器: 解析一个简单的游戏协议
-- 保存为 game_protocol.lua
-- 放到 Wireshark 的 plugins 目录
-- 或 Edit → Preferences → Protocols → Lua → 指定脚本路径

-- 协议格式:
--   [1 byte] Message Type
--   [2 bytes] Payload Length
--   [N bytes] Payload (JSON)

local game_proto = Proto("game", "Game Protocol")

-- 定义协议字段
local f_type = ProtoField.uint8("game.type", "Message Type", base.DEC, {
    [1] = "Position Update",
    [2] = "Chat Message",
    [3] = "Action",
    [4] = "Heartbeat",
})
local f_length = ProtoField.uint16("game.length", "Payload Length", base.DEC)
local f_payload = ProtoField.string("game.payload", "Payload")

game_proto.fields = { f_type, f_length, f_payload }

function game_proto.dissector(buffer, pinfo, tree)
    if buffer:len() < 3 then return end

    pinfo.cols.protocol = "GAME"

    local subtree = tree:add(game_proto, buffer(),
        "Game Protocol")

    local msg_type = buffer(0, 1):uint()
    local length = buffer(1, 2):uint()

    subtree:add(f_type, buffer(0, 1))
    subtree:add(f_length, buffer(1, 2))

    if buffer:len() >= 3 + length then
        subtree:add(f_payload, buffer(3, length))
    end

    -- 在 Info 列显示消息类型
    local type_names = {
        [1] = "Position",
        [2] = "Chat",
        [3] = "Action",
        [4] = "Heartbeat",
    }
    pinfo.cols.info = type_names[msg_type] or "Unknown"
end

-- 注册到 TCP 端口 9000
local tcp_table = DissectorTable.get("tcp.port")
tcp_table:add(9000, game_proto)

6.2 加载与使用

加载自定义 Dissector:

方法 1: 全局插件目录
  Linux:   ~/.local/lib/wireshark/plugins/
  macOS:   ~/.config/wireshark/plugins/
  Windows: %APPDATA%\Wireshark\plugins\
  将 .lua 文件放入目录,重启 Wireshark

方法 2: 命令行指定
  tshark -X lua_script:game_protocol.lua -r capture.pcap

方法 3: Wireshark 配置
  Edit → Preferences → Protocols → Lua
  添加脚本路径

验证:
  打开包含端口 9000 流量的 pcap
  协议列应显示 "GAME"
  展开详情应显示 Message Type、Payload Length、Payload

七、实战分析案例

7.1 案例:诊断 HTTP 慢请求

现象: 某些 HTTP 请求响应时间 > 5 秒

步骤 1: 用 tshark 找出慢请求
  tshark -r capture.pcap -Y 'http.time > 5' \
      -T fields -e http.request.uri -e http.time \
      -e ip.src -e ip.dst

步骤 2: 在 Wireshark 中打开 pcap
  Display Filter: http.time > 5

步骤 3: 选择一个慢请求,Follow TCP Stream
  右键 → Follow → TCP Stream

步骤 4: 查看 Flow Graph
  Statistics → Flow Graph → 选择该 TCP 流
  观察:
  - 请求发送到第一个响应字节的时间差 = TTFB
  - TTFB 大 → 服务端处理慢
  - 第一个响应字节到最后一个字节的时间差 = 传输时间
  - 传输时间大 → 网络慢或响应体太大

步骤 5: 检查 Expert Information
  是否有重传?→ 网络丢包导致延迟
  是否有零窗口?→ 接收方处理不过来
  是否有 RST?→ 连接异常中断

诊断结论:
  TTFB 大 + 无网络异常 → 后端应用层问题
  TTFB 正常 + 大量重传 → 网络质量问题
  零窗口频繁出现 → 客户端或服务端处理能力不足

7.2 案例:TCP 重传与丢包分析

步骤 1: 量化重传
  tshark -r capture.pcap -z expert -q | grep -i retrans

步骤 2: 重传的时间分布
  Statistics → I/O Graphs
  添加过滤: tcp.analysis.retransmission
  观察重传是否集中在某个时间段

步骤 3: 重传的方向
  哪个方向重传多?
  src→dst 重传多: 发送端到接收端链路有问题
  dst→src 重传多: 反向链路有问题

步骤 4: 重传类型分析
  快速重传(收到 3 个 dup ACK): 丢包但网络仍在工作
  RTO 重传(超时重传): 更严重的丢包或网络中断
  虚假重传: RTO 估算不准

步骤 5: 与 RTT 关联
  TCP Stream Graphs → Round Trip Time
  重传时 RTT 是否飙升?
  RTT 飙升 + 重传 → 网络拥塞
  RTT 稳定 + 重传 → 随机丢包(链路质量差)

7.3 案例:TLS 握手失败

步骤 1: 过滤 TLS 握手
  Display Filter: tls.handshake

步骤 2: 检查 ClientHello
  展开 TLS → Handshake Protocol → Client Hello
  查看:
  - 支持的 TLS 版本
  - 支持的密码套件列表
  - SNI (Server Name Indication)

步骤 3: 检查 ServerHello 或 Alert
  正常: ServerHello 选择了密码套件和 TLS 版本
  异常: TLS Alert 消息

  Alert 类型解读:
  handshake_failure (40): 密码套件不匹配
  protocol_version (70): TLS 版本不支持
  certificate_unknown (46): 证书问题
  bad_certificate (42): 证书格式错误
  certificate_expired (45): 证书过期
  unknown_ca (48): 未知 CA

步骤 4: 密码套件协商失败
  比较客户端支持的套件和服务端配置的套件
  如果没有交集 → handshake_failure
  解法: 服务端添加客户端支持的密码套件

步骤 5: 证书链验证
  展开 Certificate 消息
  检查:
  - 证书域名是否匹配 SNI
  - 证书是否过期
  - 证书链是否完整(中间证书是否包含)

八、Wireshark 配置优化

8.1 性能配置

处理大文件的配置:

  Edit → Preferences → Protocols → TCP:
  ✅ Relative sequence numbers(相对序列号,更易读)
  ✅ Calculate conversation timestamps
  ✅ Analyze TCP sequence numbers(启用 TCP 分析标记)

  Edit → Preferences → Protocols → HTTP:
  ✅ Reassemble HTTP bodies(重组 HTTP 响应体)

  Edit → Preferences → Capture:
  缓冲区大小: 适当增大(默认 2MB → 8MB)

  大文件优化:
  - 用 editcap 分割大 pcap:
    editcap -c 100000 large.pcap split.pcap
  - 用 tshark 预过滤:
    tshark -r large.pcap -Y 'tcp.port == 80' -w filtered.pcap
  - 禁用不需要的协议解析:
    Analyze → Enabled Protocols → 取消不需要的协议

8.2 自定义列配置

Wireshark 默认列可能不够用。推荐添加:

  右键列标题 → Column Preferences

  推荐列配置:
  ┌────────────┬─────────────────────┬──────────────────┐
  │ 列标题     │ 类型                │ 字段名           │
  ├────────────┼─────────────────────┼──────────────────┤
  │ Time       │ Time (format)       │ frame.time       │
  │ Delta      │ Custom              │ frame.time_delta │
  │ Source     │ Source              │ ip.src           │
  │ Src Port   │ Custom              │ tcp.srcport      │
  │ Dest       │ Destination         │ ip.dst           │
  │ Dst Port   │ Custom              │ tcp.dstport      │
  │ Protocol   │ Protocol            │ -                │
  │ Length     │ Packet Length       │ frame.len        │
  │ Info       │ Information         │ -                │
  │ RTT        │ Custom              │ tcp.analysis.ack_rtt │
  │ HTTP Time  │ Custom              │ http.time        │
  │ Stream     │ Custom              │ tcp.stream       │
  └────────────┴─────────────────────┴──────────────────┘

  Delta 列特别有用——立即看出包之间的时间间隔
  Stream 列用于识别属于同一 TCP 连接的包

九、总结

Wireshark 的价值不在于”看到了什么包”,而在于理解包之间的关系

  1. Display Filter 是分析的第一步。学会用 tcp.analysis.* 系列过滤器——它们是 Wireshark 帮你预分析好的 TCP 诊断结论,比肉眼扫描快一百倍。

  2. Expert Information 先于手动分析。打开 pcap 文件后第一件事应该是看 Expert Information,它会告诉你这个抓包中有多少重传、多少 RST、多少零窗口——给你一个全局概览。

  3. TCP Stream Graph 揭示性能瓶颈。Stevens 图看吞吐量趋势,RTT 图看延迟分布,Flow Graph 看交互时序——三张图覆盖了大多数 TCP 性能问题的可视化诊断。

  4. tshark 是自动化分析的利器。线上环境不能开 GUI,但 tshark 可以做 Wireshark 能做的几乎一切——统计、过滤、字段提取、Expert Information。把 tshark 命令写进排查脚本,让诊断自动化。

  5. TLS 解密用 Pre-Master Secret。不要用服务端私钥——设置 SSLKEYLOGFILE 环境变量,让 TLS 库自动记录密钥,Wireshark 自动解密。


参考文献


上一篇:tcpdump 实战精通:BPF 过滤与捕获策略

下一篇:网络延迟分析方法论:从现象到瓶颈定位

同主题继续阅读

把当前热点继续串成多页阅读,而不是停在单篇消费。

2026-04-14 · network

【网络工程】ICMP 与网络诊断:ping 和 traceroute 的工程本质

ping 超时不代表'网络不通',traceroute 的星号不代表'那一跳有问题'。这篇文章拆解 ICMP 协议的工程本质——每种类型和代码的含义、ping 和 traceroute 的三种实现方式、ICMP 限速与防火墙行为对诊断的干扰,以及如何用 ICMP 构建系统化的网络诊断方法论。

2025-08-02 · network

【网络工程】TLS 1.2 握手完整解剖:从 ClientHello 到 Application Data

TLS 1.2 握手是 HTTPS 的基础机制。本文逐包分析完整握手的每一步——ClientHello 的密码套件协商、ServerHello 的参数选择、证书验证、密钥交换(RSA vs ECDHE)的安全差异,以及 ChangeCipherSpec 到 Application Data 的完整流程。结合 Wireshark 抓包和 OpenSSL 命令实操。


By .