网硕互联帮助中心Wireshark 抓包实战：从 DNS 解析到 HTTPS 加密全解析> 实验环境：Kali Linux 2026 + Wireshark + MariaDB 11 + Pikachu 靶场
目标：理解 DNS 解析过程、HTTPS 加密原理、以及生产环境 HTTP 安全头部配置
一、前言
理解"域名如何变成 IP"、"HTTPS 为什么比 HTTP 安全"是基本功。本文通过 Wireshark 抓包，从数据包层面观察：
二、实验环境
| Kali Linux | 2026.x |
| Wireshark | 内置最新版 |
| 网络接口 | eth0（VMware NAT） |
| 测试工具 | dig、curl |
三、DNS 抓包分析
3.1 启动 Wireshark
sudo wireshark &
选择 eth0 接口（访问外网流量），开始抓包。
3.2 过滤 DNS 流量
过滤栏输入：
udp.port == 53
为什么用 UDP 53？ DNS 查询默认走 UDP 53 端口，数据量小、速度快。只有响应超过 512 字节时才切换 TCP。
3.3 触发 DNS 查询
浏览器访问外网可能走系统 DNS 缓存，抓不到查询过程。使用 dig 强制触发：
dig @8.8.8.8 example.com
3.4 分析 DNS 包
查询包（Standard query）：
- Queries：查询的域名和类型
- Flags：Recursion desired: Do query recursively（递归查询）
响应包（Standard query response）：
Answers 详情：
3.5 DNS 解析链分析
以 www.ctrip.com 为例，真实的解析过程不是"一步到 IP"，而是 CNAME 链式跳转：
www.ctrip.com
→ CNAME → cert1.c1.geo.ctripgslb.net
→ CNAME → std.c1.default.acc.ctripgslb.net
→ CNAME → dinixodcdwbrky.wsglb0.com
→ A 记录 → 61.163.112.24
→ A 记录 → 58.144.228.126
关键发现：
- 经过 3 层 CNAME 才到实际 IP
- 返回了 2 个 IP 地址（负载均衡/高可用）
- 这是典型的 CDN 架构
四、HTTP vs HTTPS 对比抓包
Wireshark 抓包时如果不加过滤，会同时抓到 TCP、UDP、ARP、ICMP 等大量无关流量，根本找不到目标。过滤表达式的作用就是"只显示我关心的协议和端口"。
4.1 HTTP 明文抓包（tcp.port == 80）
为什么用 tcp.port == 80？
- 80 端口是 HTTP 协议的默认端口
- 浏览器访问 http:// 开头的网站时，默认向服务器的 80 端口发起 TCP 连接
- 过滤后 Wireshark 只显示 80 端口的流量，排除其他干扰，方便定位 HTTP 请求和响应
过滤条件：
tcp.port == 80
浏览器访问：
http://httpbin.org/get
结果： Wireshark 中能看到明文 HTTP 请求和响应，包括 URL、Header、Body 内容。
4.2 HTTPS 加密抓包（tcp.port == 443）
为什么用 tcp.port == 443？
- 443 端口是 HTTPS 协议的默认端口
- 浏览器访问 https:// 开头的网站时，默认向服务器的 443 端口发起 TLS 握手
- 过滤后只显示 443 端口的流量，可以清晰观察到 TLS 握手过程（ClientHello、ServerHello、Certificate 等）
- 与 80 端口对比，能直观看到"同样都是 HTTP 应用层数据，为什么一个明文一个密文"
过滤条件：
tcp.port == 443
浏览器访问：
https://www.baidu.com
结果： 只能看到 TLS 握手过程，Application Data 是加密的，无法直接读取内容。
观察到的 TLSv1.2 握手过程：
4.3 核心对比
| 端口 | 80 | 443 |
| 协议 | HTTP | TLS + HTTP |
| 能否看到内容 | ✅ 明文可见 | ❌ 加密不可见 |
| 安全性 | 低，中间人可窃听 | 高，加密传输 |
结论： HTTPS 通过 TLS 握手协商加密密钥，后续所有 HTTP 数据都是密文传输，防止中间人窃听。
五、HTTP 安全头部对比分析
5.1 检查方法
使用 curl -I 查看响应头：
curl -I https://www.baidu.com
curl -I https://www.zhihu.com
curl -I https://github.com
curl -I http://localhost/pikachu/
5.2 实测结果对比
| X-Frame-Options | ❌ 缺失 | ❌ 缺失 | ✅ deny | ❌ 缺失 |
| CSP | ❌ 缺失 | ❌ 缺失 | ✅ 非常完善 | ❌ 缺失 |
| HSTS | ❌ 缺失 | ❌ 缺失 | ✅ max-age=31536000; includeSubdomains; preload | ❌ 缺失 |
| X-Content-Type-Options | ❌ 缺失 | ❌ 缺失 | ✅ nosniff | ❌ 缺失 |
| Referrer-Policy | ❌ 缺失 | ⚠️ no-referrer-when-downgrade | ✅ strict-origin-when-cross-origin | ❌ 缺失 |
| Server 头 | ⚠️ bfe（隐藏版本） | ⚠️ BLB/25.12.0.2 | ✅ github.com（无版本） | ❌ Apache/2.4.68 (Debian)（暴露版本！） |
| Cookie HttpOnly | ❌ 无 | ❌ 无 | ✅ 有 | ❌ 无 |
| Cookie Secure | ⚠️ 部分有 | ❌ 无 | ✅ 有 | ❌ 无 |
5.3 关键发现
GitHub（安全配置标杆）：
- strict-transport-security: max-age=31536000; includeSubdomains; preload
- x-frame-options: deny
- x-content-type-options: nosniff
- content-security-policy 极长，限制极严格
- Cookie 同时设置了 HttpOnly + secure + SameSite=Lax
百度/知乎（国内网站典型配置）：
- 安全头部较少
- 但百度隐藏了 Server 版本（bfe 是百度自研负载均衡），属于基本的信息泄露防护
Pikachu 靶场（故意不设防）：
- Server: Apache/2.4.68 (Debian) → 信息泄露
- 无任何安全头部 → 这是靶场故意设计的漏洞，方便练习攻击
六、HTTP 安全头部检查清单（实用工具）
基于今天的分析，整理一份可复用的检查清单：
| 1 | X-Frame-Options | curl -I | 有 DENY/SAMEORIGIN | 中 | header(“X-Frame-Options: DENY”); |
| 2 | CSP | curl -I | 有 CSP 策略 | 高 | header(“CSP: default-src ‘self’”); |
| 3 | HSTS | curl -I | 有 HSTS 头 | 中 | header(“HSTS: max-age=31536000”); |
| 4 | X-Content-Type-Options | curl -I | 有 nosniff | 中 | header(“X-Content-Type-Options: nosniff”); |
| 5 | Referrer-Policy | curl -I | 有 Referrer-Policy | 低 | header(“Referrer-Policy: strict-origin”); |
| 6 | Server 头隐藏 | curl -I | 不暴露版本 | 低 | Apache: ServerTokens Prod; ServerSignature Off; |
| 7 | Cookie HttpOnly | 浏览器 F12 | Set-Cookie 有 HttpOnly | 高 | setcookie(…, [‘httponly’ => true]); |
| 8 | Cookie Secure | 浏览器 F12 | Set-Cookie 有 Secure | 高 | setcookie(…, [‘secure’ => true]); |
七、思考
八、总结
本文通过 Wireshark 抓包，从数据包层面观察了：
评论前必须登录！
注册