一、核心功能与界面解析
1. 基础架构与工作原理
抓包原理：通过 WinPCAP/libpcap 直接访问网卡，支持端口镜像、ARP 欺骗等方式获取局域网流量。
界面模块：
数据包列表：显示捕获的数据包摘要，支持颜色编码（如 SYN 包为红色）。
详细信息：分层展示协议字段（如 TCP 序列号、HTTP 头部），支持右键追踪流。
字节区：显示原始十六进制数据，可定位特定字段（如 Cookie 值）。
2. 协议解码深度
OSI 七层解析：从物理层（Frame）到应用层（HTTP/TLS）逐层拆解，支持 2000 + 协议。
动态解码：自动识别协议类型（如 WebSocket 升级请求），支持自定义协议插件。
二、过滤系统：精准定位关键数据
1. 抓包过滤器（BPF 语法）
语法规则：协议 方向 类型 值，如host 192.168.1.1 and port 80。
实战场景：
仅捕获 SSH 流量：port 22
排除广播包：not broadcast
混合协议过滤：(tcp port 80 or udp port 53) and net 192.168.1.0/24。
在上面我们通过指定要抓包的网卡以及加上过滤条件即可实现捕获过滤
2.显示过滤器（灵活表达式）
（1）核心语法规则（4 个部分）
在进行捕获过程中使用的过滤器为显示过滤器，语法格式如下
字段：Wireshark 定义的数据包字段，格式为 "协议.字段名"，需记常用字段：
IP 层：ip.addr（IP 地址，含源和目的）、ip.src（源 IP）、ip.dst（目的 IP）
TCP 层：tcp.port（TCP 端口）、tcp.srcport（源端口）、tcp.dstport（目的端口）
UDP 层：udp.port（UDP 端口）
ICMP 层：icmp.type（ICMP 类型，如 8 = 请求、0 = 响应）
应用层：http（HTTP 流量）、dns（DNS 流量）
比较运算符：连接字段和值，常用：
==：等于（如ip.addr == 192.168.1.1）
!=：不等于
>=/<=：大于等于 / 小于等于（用于端口 / 数值）
逻辑运算符：组合多个条件，需大写：
and：同时满足（如ip.src == 10.0.0.2 and tcp.dstport == 80）
or：满足一个即可（如tcp.port == 80 or tcp.port == 443）
not：排除条件（如not ip.addr == 192.168.0.0/24）
特殊格式：
网段：ip.addr == 192.168.1.0/24（注意用==，而非捕获过滤的空格）
端口范围：tcp.port >= 1024 and tcp.port <= 65535
（2）构造逻辑：按 "目标→找字段→组合条件"
明确筛选目标：比如 "在已抓包中，筛选出所有 HTTP 流量（80 端口）且源 IP 是 192.168.2.5 的数据包"。
找字段拆解：
HTTP 流量：tcp.dstport == 80（或直接用http）
源 IP：ip.src == 192.168.2.5
组合语法：http and ip.src == 192.168.2.5（或tcp.dstport == 80 and ip.src == 192.168.2.5）
（3）关键区别：捕获过滤 vs 显示过滤
|-------|------------------------|---------------------------|
| 维度 | 捕获过滤（BPF） | 显示过滤（专有语法） |
| 作用时机 | 抓包前 | 抓包后 |
| 语法核心 | 协议 + 方向 + 主机 / 端口（无.） | 协议。字段名 + 运算符 + 值（有.） |
| 逻辑运算符 | 小写（and/or/not） | 大写（AND/OR/NOT） |
| 网段格式 | src net 192.168.1.0/24 | ip.addr == 192.168.1.0/24 |
字段语法：协议.字段 == 值，如http.request.method == "POST"。
高级技巧：
逻辑组合：(tcp.port == 80 || tcp.port == 443) && ip.src == 192.168.1.100
内容搜索：tcp contains "password"（需谨慎使用，可能泄露敏感信息）。
正则匹配：http.host matches ".*\\.com$"（匹配所有.com 域名）。
协议专属过滤：
TCP：tcp.flags.syn == 1（SYN 包）、tcp.analysis.retransmission（重传包）。
HTTP：http.response.code >= 400（错误响应）、http.time > 1.0（慢速响应）。
DNS：dns.flags.rcode != 0（解析错误）、dns.qry.name contains "example.com"。
3. 过滤性能优化
优先级原则：抓包过滤器优先于显示过滤器，复杂条件应前置到抓包阶段。
字段索引：使用http.request.uri而非http contains "uri"，利用 Wireshark 内置索引提升效率。
三、协议分析实战
1. TCP 连接全流程解析
三次握手：
tcp.flags.syn == 1（客户端发起 SYN）
tcp.flags.syn == 1 && tcp.flags.ack == 1（服务器响应 SYN-ACK）
tcp.flags.ack == 1（客户端确认 ACK）。
异常诊断：
连接重置：tcp.flags.reset == 1（排查防火墙或服务崩溃）。
窗口为零：tcp.analysis.zero_window（流量控制导致传输暂停）。
在分析->专家信息可以看到抓到的流量分析，在握手失败这里会有红色报告错误
2. HTTP 流量深度分析
请求 - 响应追踪：右键数据包选择Follow TCP Stream，可查看完整对话（含 POST 数据、Cookie）。
性能诊断：
http.time > 2.0（响应时间超 2 秒）
http.content_length > 1000000（大文件传输优化）。
在统计->捕获文件属性我们可以看到上面的的统计信息。
安全检测：
SQL 注入尝试：http.request.uri contains "union"
XSS 攻击特征：http.request.uri contains "<script>"。
3. DNS 解析故障排查
查询与响应：
dns.flags.response == 0（DNS 查询）
dns.flags.response == 1（DNS 响应）。
性能问题：dns.time > 0.1（解析时间超 100ms）。
四、高级功能与工具
1. 追踪流（Follow Stream）
功能价值：将分散的数据包按会话重组，适用于分析完整业务流程（如登录认证）。
操作方法：右键 TCP/UDP 数据包→Follow TCP Stream，支持导出为文本或图片。
2. 统计分析工具
统计-->协议分级：查看各层协议占比，快速定位异常流量（如 ARP 攻击）。
统计-->会话：按 IP / 端口统计流量，识别高频通信对（如数据库主从同步）。
统计-->I/O 图表（I/O Graphs）：可视化流量趋势，叠加过滤条件（如tcp.analysis.retransmission）监控重传率。
wireshark即是一个流量抓包工具。也是一个流量分析工具，有图形化，适合在windows上运行，也有linux版本的，但是在linux使用最多的还是tcpdump，通过使用tcpdump进行抓包，然后保存至wireshark进行分析。
五、在排障，分析等方面如何正确进行流量分析
1 、分析前的准备与角色分工
tcpdump：适合在服务器/设备上高效抓包，可做初步过滤和统计。
tcpdump -i eth0 -w capture.pcap host 10.0.0.1 and port 80
抓回来的 pcap 文件直接丢给 Wireshark。
Wireshark：负责深度分析、可视化、协议解码。
打开文件后第一步往往是确认时间格式、设置合适的过滤条件。
关键提醒：抓包位置决定你看到的"视角"。抓在客户端、服务器还是中间交换机，看到的重传、RTT 都会不同。
2 、通用分析思路
1. 先看全局统计
Statistics → Summary：看包速率、平均包大小、持续时间，先有个整体感觉。
Statistics → Protocol Hierarchy：流量由哪些协议组成？HTTP/TLS/DNS 占比多少？有没有意料之外的协议？
Statistics → Endpoints / Conversations：哪些 IP/端口在大量通信？哪个会话流量最大？点进去直接可以过滤。
这一步能帮你快速定位"谁和谁在说话，说了多少"，锁定待分析的"嫌疑流"。
2. 聚焦问题流
利用 Wireshark 的显示过滤器，精准提取你要的会话：
ip.addr == 10.0.0.5 and tcp.port == 443
http.request or http.response
dns然后右键 Follow → TCP/UDP Stream，看整个会话的请求-响应序列，快速判断业务是否正确。
3. 看"专家信息"
点击左下角圆点或 Analyze → Expert Information。
重点关注 Errors（红色）、Warnings（黄色）、Notes（青色）。
常见预警：重传、重复 ACK、零窗口、上一段未捕获到、RST、乱序、校验和错误等。它们直接告诉你哪里可能出了问题。
4. 深入时间线与序列
Statistics → Flow Graph 或 TCP Stream Graphs → Time-Sequence (Stevens)，能看到握手、数据交互、延迟、重传的时序图。
查看两次包之间的时间差（设置时间显示为"Seconds Since Previously Displayed Packet"），找出长延时点。
5. 逐包解析字段
在 Packet Details 中展开关键协议的每个字段，比如 TCP 的 flags、seq、ack、window size、TCP options（MSS、SACK、Window Scale），TLS 的 handshake 信息，HTTP 头部等。
3 、重点看这几个方面
1. TCP 连接问题
三次握手
是否收到 SYN-ACK？如果只有 SYN 重传，说明服务器端口可能不通或被防火墙拦截。
收到 RST：说明端口未开放或服务拒绝了连接。
握手时间：计算 SYN 到 SYN-ACK 的间隔，如果 >100ms 可能链路延迟高或服务器负载高。
四次挥手 / RST 中断
正常 FIN 交换 vs 突然 RST：RST 可能由应用崩溃、防火墙阻断、超时关闭导致。
查看是谁先发的 RST，结合应用日志判断原因。
2. 重传与丢包
重传现象：
快速重传（收到 3 个 dup ACK 后重传）通常表明少量乱序或丢包。
超时重传（RTO）则表明更严重的丢包或网络断连。
在 Expert Info 中统计重传次数，如果集中在某个会话，就过滤该会话逐包看：
是否某段 seq 被反复重传？
丢包点前后是否伴随零窗口、拥塞窗口掉底？
配合 IO Graph 看吞吐量骤降点，可能对应重传事件。
3. 延迟分析
网络延迟：看 SYN → SYN-ACK 时间，可估算 RTT 基线。
应用延迟：
客户端发出请求到收到第一个响应数据包的时间（HTTP 的 Time to First Byte）。
通过 http.time 字段可直接过滤。
TLS 握手延迟：
Client Hello → Server Hello 的时间。
Certificate、Server Key Exchange 是否带来大包分片和重传。
TCP 零窗口：接收端窗口变为 0，发送端停止发送，直到收到窗口更新。出现大量零窗口表示应用层取数据太慢（接收端性能瓶颈）。
4. TCP 吞吐量与窗口
计算实际吞吐 ≈ 窗口大小 / RTT。
查看三次握手协商的 Window Scale 因子，以及实时窗口值是否增长到理想大小。
如果窗口始终很小，即使链路带宽很大也跑不满，可能是接收端缓冲区设置太小或应用处理慢。
通过 TCP Stream Graphs → Window Scaling 窗口变化图，直观看到窗口被消耗和恢复的过程。
5. 应用层协议行为
状态码：http.response.code >= 400 过滤错误，重点关注 502/504（后端故障）和大量的 404/500。
慢请求：查看 http.time 值大的包，结合请求 URI 找到后端慢接口。
HTTP 长连接与管道：连接复用是否正常，是否有频繁的 SYN 新建连接（大量短连接）。
HTTPS（TLS）：
检查 TLS 版本（是否还在用 1.0/1.1）、加密套件、证书链是否完整。
若需查看加密载荷，可配置 SSLKEYLOGFILE 并导入 Wireshark 解密。
重点看 Server Hello 后的证书传递是否有错误导致握手失败。
6. DNS 解析问题
过滤 dns，看有无 Server failure (SERVFAIL) 或 NXDOMAIN。
查询响应时延：dns.time > 0.5 可能导致业务超时。
是否出现超短 TTL 的域名（可能用于 C2 通信或快速切换）。
分析是否存在 DNS 隧道：大包 TXT/MX 记录、异常长域名、高频率心跳查询。
4、一个典型的排查心法
例如"用户反馈访问卡"
先过滤该用户 IP，看三次握手是否很快（判断基础网络延迟）。
找到 HTTP 请求，看 Time to First Byte 是否过大。
如果是 HTTPS，检查 TLS 握手是否多了一次额外 round-trip。
追踪整个 TCP 流，统计重传次数，看是否有拥塞导致速度骤降。
观察服务器返回的窗口大小，是否出现零窗口。
最后再去看应用层负载本身（请求参数、返回内容大小、状态码）。
总结一句话：先宏观看谁在说话，再微观看说话的过程是否顺畅，最后看说了什么内容。 始终让过滤器和统计图帮你跳出现象看本质，而不是一上来就一头扎进几千个包里面逐包看。
六、实例分析
一、针对这个包，套用"五步法"的具体操作
1. 先看全局统计
统计→ 捕获文件属性：
如果这是完整抓包，你会看：
包数量、平均包大小（这个包60字节，偏小）。
持续时间、包速率。
在这个包中：只看它自己的长度60字节，可以推测这是一个TCP纯ACK（头部40字节IP+TCP，再加20字节以太网帧头？实际以太网帧头14字节，加上4字节FCS通常不捕获，所以60字节是合理的）。
统计 → 协议分级：
这个包只有 Ethernet / IPv4 / TCP，没有应用层数据。
看这个包：展开后你可以看到TCP占比100%（就一个包），Len=0说明没有应用数据。
统计 → 端点：
对这个包，端点对是 (183.36.42.106, 443) ↔ (192.168.198.67, 69527)。
记录这两个IP和端口，作为后续过滤的依据。
在这个包上，你实际要看的参数：包长度60、协议栈(Eth+IP+TCP)、端点对、TCP Len=0。
2. 聚焦问题流 -- 过滤出这个会话
在Wireshark过滤栏输入：
ip.addr == 183.36.42.106 and tcp.port == 443
或更精确：
tcp.stream eq X (X是这个流号，你可以从第278包的TCP部分右键 → Conversation Filter → TCP 得到)
然后 Follow → TCP Stream。
在这个操作中你要看什么？
整个会话的请求-响应序列：这个包之前是否有客户端→服务器的数据（Seq/Ack关系）？
这个ACK包在流中的位置：比如它是第几个包？
如果Follow后看到乱序或重传，会在窗口中高亮。
实际要看的参数：流号、该包前后的Seq/Ack对应关系、是否有重传标记。
3. 看"专家信息"
点 Analyze → Expert Information，或点左下角圆点。
针对第278号包，假设只抓了这个包，专家信息里可能没有条目。但如果是完整抓包：
Errors：这个包本身无错误（校验和正确，Wireshark未报Malformed）。
Warnings：可能提示"TCP Window Full"或"Zero Window"吗？
这个包 Win=42 非常小，如果之前窗口较大突降到42，专家信息里会有 "Window update" 或 "Zero window" 相关提醒。
你可以手动检查：在包细节里 TCP → Window: 42。
再往前找同一个流的前一个包，对比窗口值是否骤降。
实际要看的参数：Expert Info中的Warning/Note条目，以及窗口字段的具体数值变化。
4. 时间线与序列图
统计→ 流量图：
选择这个TCP流，你会看到时间轴上的包方向。
针对第278包：看它前面是否有 SYN, SYN-ACK，以及它是否是对之前某个数据包的ACK。
如果这个包之前有一个客户端发来的长度为M的包，那么Ack=5628 表明那个包的Seq+Len = 5628。
统计 → TCP流行图->时间序列：
这个包在图上是一个点（Seq=2636, 时间=40.138079）。
你要看：
前一个点（客户端的发送）的Seq是多少，判断是否丢包。
这个ACK是否对应了数据段的确认。
时间差：
设置 Time Display Format 为 "Seconds Since Previous Displayed Packet"。
看这个包与前一个包的时间差。如果差值很大（比如>200ms），可能提示网络延迟或应用处理慢。
实际要看的参数：时间差、序列号在时间序列图上的位置、是否触发快速重传的Dup ACK。
5. 逐包解析字段 -- 这个包的细节
包展开每一层，查看：
|-------------|------------------|---------------------|------------------|
| 层级 | 字段 | 本包的值 | 意义 |
| Ethernet II | Src MAC, Dst MAC | Huawei → EliteGroup | 直连或同交换机 |
| IPv4 | TTL | 55 | 经过了55跳，说明公网过来的 |
| IPv4 | Total Length | 40 | IP头+TCP头，无载荷 |
| TCP | Src port | 443 | HTTPS服务 |
| TCP | Dst port | 69527 | 客户端临时端口 |
| TCP | Seq | 2636 (相对) | 服务器发送序列号（无数据） |
| TCP | Ack | 5628 | 确认收到了客户端的5627及之前 |
| TCP | Flags | 0x010 (ACK) | 仅确认，无SYN/FIN/RST |
| TCP | Window | 42 | 接收窗口极小，需关注 |
| TCP | Len | 0 | 无数据 |
| TCP | Options | (无) | 本包没有选项，说明不是握手包 |
实际要看的参数：所有这些字段的数值，尤其是 Ack, Win, Len。
6. 总结：在包上你必须看的几个关键数据点
|-----------|----------------------------------------------|
| 你要回答的问题 | 查看这个包的哪些字段/参数 |
| 这个包在干什么？ | TCP flags=ACK, Len=0 → 纯确认 |
| 谁和谁通信？ | IP: 183.36.42.106:443 → 192.168.198.67:69527 |
| 确认了哪个数据？ | Ack=5628 → 客户端之前发到了5627 |
| 客户端窗口状态？ | Win=42 → 非常小，可能接收缓冲区紧张 |
| 是否有重传/丢包？ | 对比前后ACK号是否重复，Expert Info是否有Dup ACK |
| 网络延迟如何？ | 本包时间戳减去上一个发送包的记录时间 |
| 会话是否正常？ | 查看TCP Stream中是否有RST、零窗口、重传等异常 |
七、具体操作
第一步：拿到抓包后，先看宏观统计
在Wireshark里打开完整抓包文件后，依次操作：
菜单栏 → 统计 → 捕获文件属性
看什么：
持续时间（多久）
平均包速率（包/秒）
平均数据速率（bit/s 或 Byte/s）
平均包大小（字节）
你抓包里的参考：从0.14秒到150秒，约150秒；包数量较少，平均速率很低。
菜单栏 → 统计 → 协议分层统计
看什么：
哪个协议占的包数百分比和字节数百分比最大
有没有异常协议（比如大量ARP、ICMP）
你的片段里：主要是TCP和TLSv1.2，说明是加密Web流量。
菜单栏 → 统计 → 端点
看什么：
哪个IP发送/接收的包最多、字节最多（按"字节"列排序）
是内网IP还是公网IP
你的片段里：183.36.42.106 和 192.168.198.67 是主角。
菜单栏 → 统计 → 会话
看什么：
哪一对（IP+端口）通信量最大
双向流量是否对称（A→B 和 B→A 的包数/字节数）
你的片段里：192.168.198.67:60527 ↔ 183.36.42.106:443 就是这个会话。
这一步的目的：找出"谁在跟谁说话，用什么协议，流量多大"。不用深入细节，只要知道重点分析对象。
第二步：聚焦目标会话，使用显示过滤器
在过滤栏输入精确的过滤器，例如：
ip.addr == 192.168.198.67 && tcp.port == 60527 && ip.addr == 183.36.42.106 && tcp.port == 443更简单的方法：在任意一个相关包上右键 → 会话过滤 → 选中"TCP"。
这一步后，Wireshark只显示这个TCP连接的所有包。
第三步：查看"专家信息"快速定位异常
菜单栏 → 分析 → 专家信息（或点击左下角的彩色圆点）
红色错误（Errors）：一般是有问题的包（如校验和错误、解析失败）。你的片段里没有。
黄色警告（Warnings）：常见的有
- TCP重传
- 重复ACK
- 零窗口（窗口为0）
- 窗口已满（窗口很小，接近0）
- 保活包（Keep-Alive）
你片段里有 TCP Keep-Alive，属于黄色警告级别的笔记（Note）或警告（Warning）。
青色注释（Notes）：比如 TCP ACKed unseen segment 等。
这一步的目的：不用自己翻几百个包，Wireshark帮你把可疑事件汇总出来。重点关注那些重复出现的事件。
第四步：逐个字段分析------以TCP窗口为例
双击任何一个包，在下方包详情面板展开 传输控制协议。你要看的关键字段有：
|-----------|--------------------|-------------------------------------|
| 字段名（中文显示） | 你要看什么数值 | 这个数值正常/异常怎么判断 |
| 源端口、目的端口 | 例如 443、60527 | 确定服务类型（443=HTTPS） |
| 序列号 | 例如 Seq=2636 | 正常通信中，数据包的序列号每次增加载荷长度；纯ACK包序列号不变 |
| 确认号 | 例如 Ack=5628 | 确认对方已收到哪个序号之前的数据 |
| 标志位 | SYN, ACK, FIN, RST | SYN=建立连接；RST=异常重置；FIN=正常关闭 |
| 窗口大小 | 例如 Win=42 | 正常值一般几千到几万；如果长期低于100甚至为0，说明接收端处理不过来 |
| 长度 | Len=0 / Len=1440 | Len=0表示没有数据（纯ACK或保活）；Len>0表示携带应用数据 |
| TCP选项 | 例如 MSS、窗口缩放因子 | 只在SYN包中出现，用来协商最大段大小和窗口倍数 |
可以这样练习：
找出 窗口大小 这一列（如果没有，右键列标题 → 列首选项 → 添加 tcp.window_size）。
然后观察：服务器→客户端的包，Win 长期是 42、45、49。
客户端→服务器的包，Win 是 1029、1026、1025。
对比：1029 比 42 大很多，说明是服务器端的接收窗口特别小，而不是客户端。
找出 长度 列，看哪些包 Len>0，它们就是真正的数据传输包。
例如第14包 Len=89，第276包 Len=1440。
这一步的目的：学会看每个字段的值，并和"正常范围"对比。正常范围可以通过看别的会话或查资料获得。
第五步：分析时间关系（延迟、间隔）
在Wireshark中，时间显示格式可以切换：
菜单栏 → 视图 → 时间显示格式 → 建议选 自上次显示包以来的秒数 或 自捕获开始以来的秒数。
然后看两个相关包之间的 时间差：
找出一个请求包和对应的响应包。
例如：第276包（客户端发数据，时间40.133754秒），第278包（服务器确认，时间40.138079秒）。
时间差 = 40.138079 - 40.133754 = 0.004325秒 ≈ 4.3毫秒。
这个值很小，说明网络延迟正常。
找出发送数据和下一个数据发送之间的间隔。
例如：第276包（客户端发）和第285包（客户端又发），时间差很大（因为中间很多服务器ACK）。
如果间隔很大，可能是窗口限制导致发送端等待。
这一步的目的：判断慢是因为网络延迟，还是因为应用处理慢，还是因为TCP窗口卡住。
第六步：使用图形工具看趋势
菜单栏 → 统计 → TCP流图 → 选择 时间序列（史蒂文斯） 或 窗口缩放。
时间序列图：横轴时间，纵轴序列号。
正常情况：斜率平稳向上。
如果出现水平线段（序列号不增长），说明没有数据发送。
如果出现向下的折线，那是重传。
窗口缩放图：可以看到窗口大小随时间的变化。
在你抓包里，服务器窗口长期在42附近画出一条水平低线，一眼就能看出问题。
这一步的目的：把枯燥的数字变成曲线图，异常模式一目了然。
第七步：应用层分析（对于TLS/HTTP）
由于你的流量是TLS加密，在没有解密密钥的情况下，只能看到 Application Data，看不到具体内容。但你可以：
统计TLS记录的大小：通过 tls.record.length 字段。
查看TLS握手包：过滤 tls.handshake.type。
如果你有浏览器或程序的环境变量 SSLKEYLOGFILE，可以在Wireshark中导入解密，然后看到明文HTTP请求。
这一步的目的：判断应用层协议是否正常交互。比如HTTP请求后有没有对应的HTTP响应，状态码是否200等。
八、解密TLS数据包
我们知道在进行正常抓包的情况下，通过TLS加密的数据包我们是无法看到的，这个需要我们去进行配置才能够看到其数据包的正常内容。在wireshark4.x以上的版本通过配置SSLKEYLOGFILE来进行解密，这种方法的核心是让浏览器在建立 TLS 连接时，将用于加密的"会话密钥"自动保存到一个文件中，之后Wireshark读取这个文件来解密流量。它的最大优势在于，即使网站使用了支持"前向安全"的高级加密算法（如 ECDHE），这个方法也同样有效，步骤都是很简单的，首先，进去如下页面
第一个是放置会话密钥的文件，随便创建一个.log文件，放在哪都是可以到，只要可以让浏览器成功读取即可
第二个是选择浏览器，很简单，只要右击你的浏览器图标，选择打开文件所在的文件位置，然后再选择其中的exe文件，右击选择复制文件地址即可
这两个设置完成，然后点击launch,会跳到你选择的浏览器的页面，接下来再进入到winreshark，开始捕获流量
再跳到的浏览器页面选择你要解密的流量，就是再开始捕获流量之前将所有的浏览器页面进行关闭，这里才能真正读取到会话密钥，捕获完成后点击右上角的暂停键
然后点击save进行保存
然后编辑-->首选项
然后protocols,下滑找到TLS
然后就是log filename选择你上面所存放会话密钥的文件即可
点击确认，我们看看结果
可以看到已经成功解密，可以看到里面的包格式之类的。
九、总结：你作为初学者，拿到一个抓包文件应该按顺序做什么？
宏观统计（菜单→统计）：找到主要会话和协议。
过滤出目标流（过滤器 + Follow Stream）。
看专家信息（底部圆点）：快速发现重传、零窗口等警告。
逐包看关键字段：序列号、确认号、窗口大小、长度、标志位。
对比时间差：切换时间显示格式，计算间隔。
用图形工具：时间序列图、窗口缩放图。
如果需要，解密应用层（TLS/HTTP）。