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,ip4.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 -rn4.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 的价值不在于”看到了什么包”,而在于理解包之间的关系。
Display Filter 是分析的第一步。学会用
tcp.analysis.*系列过滤器——它们是 Wireshark 帮你预分析好的 TCP 诊断结论,比肉眼扫描快一百倍。Expert Information 先于手动分析。打开 pcap 文件后第一件事应该是看 Expert Information,它会告诉你这个抓包中有多少重传、多少 RST、多少零窗口——给你一个全局概览。
TCP Stream Graph 揭示性能瓶颈。Stevens 图看吞吐量趋势,RTT 图看延迟分布,Flow Graph 看交互时序——三张图覆盖了大多数 TCP 性能问题的可视化诊断。
tshark 是自动化分析的利器。线上环境不能开 GUI,但 tshark 可以做 Wireshark 能做的几乎一切——统计、过滤、字段提取、Expert Information。把 tshark 命令写进排查脚本,让诊断自动化。
TLS 解密用 Pre-Master Secret。不要用服务端私钥——设置
SSLKEYLOGFILE环境变量,让 TLS 库自动记录密钥,Wireshark 自动解密。
参考文献
- Wireshark User’s Guide (wireshark.org/docs/wsug_html_chunked)
- Wireshark Display Filter Reference (wireshark.org/docs/dfref)
- Sanders, C. (2017). Practical Packet Analysis, 3rd Edition, No Starch Press
- Wireshark Lua API Reference (wireshark.org/docs/wsdg_html_chunked/wsluarm.html)
- TCP Analysis Flags (wiki.wireshark.org/TCP_Analyze_Sequence_Numbers)
同主题继续阅读
把当前热点继续串成多页阅读,而不是停在单篇消费。
【网络工程】ICMP 与网络诊断:ping 和 traceroute 的工程本质
ping 超时不代表'网络不通',traceroute 的星号不代表'那一跳有问题'。这篇文章拆解 ICMP 协议的工程本质——每种类型和代码的含义、ping 和 traceroute 的三种实现方式、ICMP 限速与防火墙行为对诊断的干扰,以及如何用 ICMP 构建系统化的网络诊断方法论。
【网络工程】TCP 问题诊断实战:重传、RST 与窗口异常
TCP 问题排查是后端工程师的日常。本文系统梳理重传、RST、窗口异常三大类 TCP 问题的诊断方法,通过 ss、netstat、tcpdump、Wireshark 等工具链配合 Prometheus 指标采集,建立完整的 TCP 故障诊断体系。
【网络工程】TLS 1.2 握手完整解剖:从 ClientHello 到 Application Data
TLS 1.2 握手是 HTTPS 的基础机制。本文逐包分析完整握手的每一步——ClientHello 的密码套件协商、ServerHello 的参数选择、证书验证、密钥交换(RSA vs ECDHE)的安全差异,以及 ChangeCipherSpec 到 Application Data 的完整流程。结合 Wireshark 抓包和 OpenSSL 命令实操。
【网络工程】网络延迟分析方法论:从现象到瓶颈定位
系统讲解网络延迟的分解方法论:从 DNS 到 TCP 到 TLS 到 TTFB 到传输的全链路延迟拆解,Wireshark RTT 测量、mtr/hping3 路径分析、内核协议栈延迟追踪,建立从'用户说慢'到精确定位瓶颈的工程方法。