如何去排查网络故障

# 15.如何去排查网络故障

# 目录介绍

01.工作案例引入
- 1.1 一次"服务挂了"的排查全记录
- 1.2 故障背后的排查知识图谱
02.学会使用Ping工具
- 2.1 Ping工具是什么
- 2.2 Ping工具的用途
- 2.3 Ping工具使用
- 2.4 Ping诊断结果分析
- 2.5 Ping常见案例
- 2.6 Ping基础的原理
03.用ifconfig查询网络
- 3.1 ifconfig 是什么
04.netstat和lsof
- 4.1 netstat和lsof是什么
05.HTTP应用排查工具
- 5.1 应用层排查工具
- 5.2 找有问题服务端IP
- 5.3 辅助排查网页慢问题
- 5.4 解决失效Cookie
- 5.5 查看证书的信息
06.传输层排查工具
- 6.1 路径可达性测试
- 6.2 查看当前连接状况
- 6.3 查看连接传输速率
- 6.4 查看丢包和乱序等
07.网络层排查工具
- 7.1 查看网络路径状况
- 7.2 查看路由信息
08.数据链路层排查
- 8.1 ARP相关排查
- 8.2 查看网卡信息
- 8.3 抓取链路层数据
09.CURL网络请求工具
- 9.1 CURL工具介绍
- 9.2 CURL访问网络
- 9.3 CURL的GET请求
- 9.4 CURL的POST请求
- 9.5 CURL文件上传
- 9.6 CURL文件下载
- 9.7 CURL添加请求头
- 9.8 CURL通信过程
- 9.9 CURL其他的实践
10.综合案例：一个完整故障的逐层排查实战
- 10.1 案例背景与目标
- 10.2 第一层：用户侧验证（能访问吗？）
- 10.3 第二层：应用层排查（HTTP返回什么？）
- 10.4 第三层：传输层排查（端口通不通？）
- 10.5 第四层：网络层排查（路径上卡在哪？）
- 10.6 第五层：链路层排查（网线/交换机/ARP）
- 10.7 排查全景总结
- 10.8 全文知识图谱回顾
11.思考题与作业
- 11.1 基础思考题
- 11.2 进阶思考题
- 11.3 动手作业

# 01.工作案例引入

# 1.1 一次"服务挂了"的排查全记录

场景：小林是一名后端工程师，今天值班。凌晨 2:13，手机告警响了——"用户登录接口 POST /api/login 响应时间超过 5 秒，P99 延迟飙升"。小林揉了揉眼睛，打开笔记本电脑，开始了排查。

第一步排查：确认现象。小林用 curl 直接请求登录接口——返回 504 Gateway Timeout。504 说明上游（应用服务器）没有在 Nginx 的超时时间内返回响应。是应用挂了还是网络断了？

第二步排查：测试连通性。ping api-server-1——丢包率 0%，延迟 3ms。网络通着，服务器没死。但 telnet api-server-1 8080——Connection refused。端口拒绝了！说明 Tomcat 进程可能挂了。

第三步排查：检查进程状态。SSH 到服务器上，ps aux | grep tomcat——进程还在。但 netstat -ant | grep 8080——没有 LISTEN 状态。进程在，但不监听端口？tail -f /var/log/tomcat/catalina.out——看到 OutOfMemoryError: Java heap space。应用因为 OOM 卡在 GC 循环中，虽然没有退出，但已经无法处理请求。

第四步排查：为什么 OOM？。小林重启了 Tomcat，服务恢复。但他还需要找根因——为什么突然 OOM？grep "OutOfMemory" /var/log/tomcat/catalina.out——最近一小时内出现了 3 次。再查 Nginx 日志：awk '{print $7}' access.log | sort | uniq -c | sort -rn | head——发现一个爬虫 IP 在疯狂请求 GET /api/products/export?size=100000（导出 10 万条商品数据），每次请求在 Tomcat 堆里创建了巨大的 ArrayList。

第五步排查：从源头阻断。小林在 Nginx 上添加了 limit_req_zone 限制单 IP 频率，把爬虫 IP 加入了黑名单，并给 /export 类接口添加了 slow-query-threshold 监控。

疑惑链条：

"504 和 502 有什么区别？" → 504=上游超时未响应，502=上游返回了无效响应 → 不同的排查方向
"ping 通了为什么 telnet 不通？" → ping 走 ICMP（网络层），telnet 走 TCP（传输层）→ 网络通不意味着端口通 → 不同层的问题要用不同层的工具排查
"进程在为什么不监听端口？" → 进程在 GC 停滞，主线程卡住，还没来得及 bind() 端口 → netstat 看不到 LISTEN
"怎么找到是哪个请求导致的 OOM？" → Nginx 日志按 URL 聚合排序 → 找出请求量/数据传输量最大的接口

小林这一串排查，本质是在问：网络出问题时，从哪一层开始查？每层用什么工具？工具的输入和输出怎么解读？——这正是"如何去排查网络故障"要回答的。

# 1.2 故障背后的排查知识图谱

小林排查路径在 OSI 模型中的映射：

应用层：    curl → 504 Gateway Timeout → 问题在上游         [第5章]
传输层：    telnet → Connection refused → 端口不监听        [第6章]
          netstat → 无LISTEN → 进程异常                    [第4章]
网络层：    ping → 0%丢包 → 网络层正常                      [第2章]
          traceroute → 路径可达                            [第7章]
链路层：    arp → MAC地址正常                               [第8章]

1
2
3
4
5
6
7
8

排查方法论：自顶向下还是自底向上？

自顶向下（小林的做法）：
  应用层 → 传输层 → 网络层 → 链路层
  优点：从用户视角出发，快速定位到问题层次
  适用：用户报告"功能不可用"时

自底向上：
  链路层 → 网络层 → 传输层 → 应用层
  优点：先排除底层问题，避免上层误判
  适用：网络基础设施变更后验证

本章主线：掌握 ping / telnet / netstat / traceroute / tcpdump / curl 这六大工具，
并知道在什么场景下先拿起哪个，什么时候该换下一个。

1
2
3
4
5
6
7
8
9
10
11
12

本章的主线就是沿着 OSI 模型从应用到链路，介绍每一层的排查工具和技巧，最后用一个完整的排查案例把所有工具串联起来。读完之后，你不仅能独立排查网络故障，还能形成"分层排查"的系统思维。

# 02.学会使用Ping工具

# 2.1 Ping工具是什么

Ping工具是一种网络诊断工具，通过发送ICMP（Internet Control Message Protocol）回显请求消息到目标主机，并等待返回ICMP回显应答来测量往返时间（RTT）和丢包率。

# 2.2 Ping工具的用途

测试网络连接、测量延迟、检测丢包。

# 2.3 Ping工具使用

PING ww1.sinaimg.cn (61.184.4.235): 56 data bytes
64 bytes from 61.184.4.235: icmp_seq=0 ttl=64 time=18.723 ms
64 bytes from 61.184.4.235: icmp_seq=1 ttl=64 time=16.442 ms
--- ping statistics ---
9 packets transmitted, 9 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 10.068/12.908/18.723/2.700 ms

1
2
3
4
5
6

# 2.4 Ping诊断结果分析

重点关注：目标IP、RTT（低=好）、丢包率（0%=好）、min/max/avg（波动范围）。

# 2.5 Ping常见案例

连接超时（Request timeout）：目标不可达或防火墙屏蔽ICMP
高延迟和丢包：网络拥塞或链路质量问题

# 2.6 Ping基础的原理

ping 基于 ICMP 协议（不是 TCP 也不是 UDP）。ICMP 在 IP 报文后加入了类型（ping请求=8，应答=0）、代码、校验和、标识符、序列号等字段。

这是小林排查中的关键认知：ping 通了只说明 IP 层可达，不说明 TCP 端口开放。所以 ping 通但 telnet 不通是完全合理的情况。

# 03.用ifconfig查询网络

# 3.1 ifconfig 是什么

ifconfig 用于配置和显示网络接口信息：IP地址、子网掩码、MAC地址、MTU等。

常用命令：ifconfig（显示所有接口）、ifconfig eth0（特定接口）、ifconfig eth0 up/down（启用/禁用）、ifconfig eth0 mtu 1500（设置MTU）。

# 04.netstat和lsof

# 4.1 netstat和lsof是什么

netstat 用于显示网络连接、路由表和网络接口统计信息。

netstat -ant  # 所有TCP连接
netstat -u    # UDP连接
netstat -p    # 显示关联进程

1
2
3

lsof 用于列出当前系统中打开的文件和网络连接。

lsof -i       # 所有网络连接
lsof -i :80   # 使用端口80的连接
lsof -p <PID> # 特定进程的连接

1
2
3

回到小林的排查：netstat -ant | grep 8080 没有 LISTEN 状态，说明 Tomcat 没有成功绑定端口。配合 ps aux 发现进程在但端口不存在，指向了 OOM → GC 停滞的方向。

# 05.HTTP应用排查工具

# 5.1 应用层排查工具

Chrome DevTools（F12）是最常用的应用层排查工具。

# 5.2 找有问题服务端IP

Network → 点击请求 → Headers → Remote address 查看当前连接的 IP。这在排查 CDN/多节点问题时非常有用——不同用户可能连到不同的节点。

# 5.3 辅助排查网页慢问题

Network → Timeline 查看各资源耗时，定位耗时最高的 HTTP 资源对象。

# 5.4 解决失效Cookie

Application → Storage → Cookie → 清除对应条目。

# 5.5 查看证书的信息

Security 菜单查看 TLS 信息，包括协议版本、密钥交换算法、证书有效期等。更详细的 TLS 握手细节需要用 tcpdump + Wireshark。

# 06.传输层排查工具

# 6.1 路径可达性测试

telnet www.baidu.com 443    # 测试TCP端口可达性
nc -w 2 -zv www.baidu.com 443  # nc 测试连通性

1
2

回到小林的排查：telnet api-server-1 8080 返回 Connection refused，说明 TCP 握手被拒绝——网络通但端口未监听。

# 6.2 查看当前连接状况

netstat -ant  # 查看所有TCP连接及状态

关注输出中的 ESTABLISHED、TIME_WAIT、CLOSE_WAIT 等状态。

# 6.3 查看连接传输速率

iftop（需安装）可以显示不同连接的实时传输速率，定位带宽占用。

# 6.4 查看丢包和乱序等

tcpdump + Wireshark 是最强大的传输层排查组合：

# 抓取特定端口数据包
sudo tcpdump -i eth0 tcp port 80 -w capture.pcap
# 只抓TCP SYN包（排查连接建立问题）
sudo tcpdump -i eth0 'tcp[tcpflags] & tcp-syn != 0' -w syn.pcap

1
2
3
4

Wireshark 过滤器：

tcp.analysis.retransmission     # TCP重传
tcp.analysis.out_of_order       # 乱序包
tcp.analysis.duplicate_ack      # 重复ACK
tcp.analysis.zero_window        # 零窗口（接收缓冲区满）

1
2
3
4

查看 TCP 统计：netstat -s | grep -i retransmit 查看重传次数。

# 07.网络层排查工具

# 7.1 查看网络路径状况

traceroute 逐跳显示数据包经过的路由器：

traceroute www.baidu.com
# 如果UDP被屏蔽，用 -I 切换为ICMP探测
traceroute www.baidu.com -I

1
2
3

mtr 是 traceroute 的超集，能连续多次探测并显示每跳丢包率：

mtr www.baidu.com -r -c 10  # 发送10个包，报告模式

重点关注每跳的 Loss% 列——哪一跳丢包率高，问题就在哪一跳。

# 7.2 查看路由信息

route -n       # 查看路由表
netstat -r     # netstat查看路由
ip route       # 新命令查看路由

1
2
3

# 08.数据链路层排查

# 8.1 ARP相关排查

arp -a              # 查看ARP缓存表
sudo arp -d <IP>    # 清除指定IP的ARP缓存
cat /proc/net/arp   # Linux上查看ARP表

1
2
3

关注：ARP缓存是否过期、是否有ARP欺骗（同一IP对应多个MAC）。

# 8.2 查看网卡信息

ethtool eth0           # 查看网卡速率、双工模式、链路状态
ethtool -S eth0 | grep -i error  # 查看网卡错误统计
ifconfig en0           # macOS查看网卡状态

1
2
3

如果 rx_errors 或 tx_errors 异常高，可能是网线质量问题或交换机端口故障。

# 8.3 抓取链路层数据

sudo tcpdump -i eth0 -e -c 5        # 显示MAC地址
sudo tcpdump -i eth0 arp -c 10      # 抓ARP包
sudo tcpdump -i eth0 ether host aa:bb:cc:dd:ee:ff  # 特定MAC流量

1
2
3

# 09.CURL网络请求工具

# 9.1 CURL工具介绍

CURL 是命令行 HTTP 客户端，支持多种协议，常用于测试 API、下载文件、调试网络请求。功能强大到可以完全取代 Postman。

# 9.2-9.7 CURL基本用法

curl http://www.baidu.com              # GET请求
curl -d 'key=value' -X POST URL       # POST表单
curl -H "Content-Type: application/json" -X POST -d '{"a":1}' URL  # JSON POST
curl -F "file=@photo.jpg" URL          # 文件上传
curl -o filename URL                   # 下载文件
curl -H 'Authorization: bearer xxx' URL # 自定义头

1
2
3
4
5
6

# 9.8 CURL通信过程

curl -v 显示完整通信过程——DNS解析→TCP连接→TLS握手→HTTP请求→响应，是排查应用层问题的首选。

curl -v https://www.wanandroid.com/banner/json
# 输出：DNS解析 → TCP握手 → TLS协商 → HTTP请求行/头 → 响应状态行/头 → 响应体

1
2

# 9.9 CURL其他的实践

curl --connect-timeout 5 --max-time 30 URL   # 超时控制
curl -L URL                                    # 跟随重定向
curl -x http://proxy:8080 URL                  # 使用代理
curl -k https://self-signed.example.com        # 忽略SSL证书
curl -A "User-Agent" -e "Referer" URL          # 模拟浏览器
# 查看各阶段耗时（DNS/TCP/TLS/TTFB/总耗时）
curl -o /dev/null -s -w "DNS:%{time_namelookup}s TCP:%{time_connect}s TLS:%{time_appconnect}s TTFB:%{time_starttransfer}s Total:%{time_total}s\n" URL

1
2
3
4
5
6
7

# 10.综合案例：一个完整故障的逐层排查实战

本章用一个贯穿全文的实战案例——模拟一个从用户投诉到根因定位的完整排查过程。我们会从应用层开始，沿着 OSI 模型逐层下沉，每层使用对应的工具，直到找到根因。读完这一节，你应该能形成"遇到任何网络问题都能按层次、用工具、找线索"的排查能力。

# 10.1 案例背景与目标

场景设定：运维接到用户投诉——"网站打不开了"。作为值班工程师，你需要独立完成排查。系统的部署架构如下：

用户浏览器 → CDN → Nginx(反向代理) → Tomcat集群 → MySQL

没有已知线索，需要从零开始一步步排查。

# 10.2 第一层：用户侧验证——能访问吗？

目标：确认问题是"完全打不开"还是"慢"还是"部分功能不可用"。

# 1. 用 curl 模拟用户请求，看返回什么
curl -I https://www.company.com
# HTTP/1.1 200 OK → 主站正常
# 或 HTTP/1.1 502 Bad Gateway → 后端有问题
# 或 curl: (7) Failed to connect → 网络不通
# 或 curl: (28) Connection timed out → 超时

1
2
3
4
5
6

情况A：返回 502/504 → 问题在上游（Nginx 连不上 Tomcat），进入第二层

情况B：返回超时 → 网络不通或服务器没响应，跳过传输层查网络层

情况C：返回 200 但用户说打不开 → 可能是 CDN 缓存了旧内容、DNS 解析到了错误 IP

# 2. 查看请求耗时明细
curl -o /dev/null -s -w \
  "DNS:%{time_namelookup}s TCP:%{time_connect}s TLS:%{time_appconnect}s TTFB:%{time_starttransfer}s Total:%{time_total}s\n" \
  https://www.company.com
# 如果 DNS > 1s → DNS问题
# 如果 TCP > 100ms → 网络延迟高
# 如果 TTFB > 5s → 服务端处理慢

1
2
3
4
5
6
7

# 10.3 第二层：应用层排查——HTTP返回什么？

目标：确定 HTTP 层面的具体错误。

# 直接绕过CDN，请求Nginx
curl -v -H "Host: www.company.com" http://10.0.0.1/
# → HTTP/1.1 502 Bad Gateway
# 说明 Nginx 活着，但连不上 Tomcat

# 查看 Nginx 错误日志
tail -100 /var/log/nginx/error.log
# → upstream timed out (110: Connection timed out) while connecting to upstream
# Nginx连接Tomcat超时

# 查看 Nginx upstream 状态
curl http://127.0.0.1/nginx_status  # 如果配置了stub_status

1
2
3
4
5
6
7
8
9
10
11
12

确定问题：Nginx 正常，连接不到 Tomcat。

# 10.4 第三层：传输层排查——端口通不通？

目标：确定 TCP 层面的连通性。

# 1. ping 测试（网络层）
ping 10.0.0.101  # Tomcat-1 的IP
# 64 bytes from 10.0.0.101: icmp_seq=0 ttl=64 time=0.5ms
# ✅ 网络层可达

# 2. telnet 测试端口（传输层）
telnet 10.0.0.101 8080
# Trying 10.0.0.101...
# telnet: connect to address 10.0.0.101: Connection refused
# ❌ TCP端口不监听！

# 3. SSH登录服务器，检查进程
ssh 10.0.0.101
ps aux | grep tomcat
# tomcat  12345  0.1  85.2 5123456 4096000 ?  Sl   02:00  0:30 java ...
# 进程在！内存占用85%

# 4. 检查端口监听
netstat -ant | grep 8080
# 空！没有LISTEN状态
# 进程在但不监听端口 → 进程异常（可能卡在GC或其他阻塞操作）

# 5. 查看应用日志
tail -200 /var/log/tomcat/catalina.out
# java.lang.OutOfMemoryError: Java heap space
# Dumping heap to java_pid12345.hprof ...
# ❌ OOM！应用在Full GC循环中，无法响应任何请求

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

确定根因：Tomcat OOM，应用卡在 GC，无法监听端口。Nginx 连接超时 → 返回 502。

# 10.5 第四层：网络层排查——如果ping不通怎么办？

如果第三步 ping 不通，排查方向转到网络层：

# 1. traceroute看路径
traceroute 10.0.0.101 -n
# 1  10.0.0.1  0.5ms  ← 到了网关
# 2  * * *           ← 之后全是星号
# 说明：出了网关就断了 → 路由问题或交换机/防火墙问题

# 2. 检查路由表
ip route | grep 10.0.0
# 如果没有到10.0.0.0/24的路由 → 路由缺失

# 3. 检查防火墙
sudo iptables -L -n | grep 10.0.0.101
# 如果有DROP规则 → 防火墙阻断了

# 4. 用mtr持续探测
mtr 10.0.0.101 -r -c 20
# 可以精确定位丢包发生在哪一跳

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

# 10.6 第五层：链路层排查——如果traceroute看不到问题

如果以上都正常，但问题仍然存在，排查方向转到链路层：

# 1. 检查网卡状态
ethtool eth0 | grep -E "Speed|Duplex|Link"
# Speed: 1000Mb/s  ✅
# Duplex: Full      ✅
# Link detected: yes ✅

# 2. 检查网卡错误计数
ethtool -S eth0 | grep -i error
# rx_errors: 12547  ← 接收错误很多！
# → 可能是网线质量问题或交换机端口故障

# 3. 检查ARP
arp -a | grep 10.0.0.101
# 如果IP对应的MAC是(incomplete) → ARP解析失败
# 可能是同一网段有IP冲突

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# 10.7 排查全景总结

小林完成排查后整理的问题分析：

问题现象：    网站打不开，返回502
直接原因：    Tomcat OOM，进程卡在GC无法响应
根本原因：    爬虫疯狂请求导出接口，每次创建大对象导致堆溢出
触发条件：    凌晨爬虫集中扫描 + 导出接口没有做限制
解决方案：    Nginx限流 + 爬虫IP黑名单 + 导出接口异步化 + JVM参数优化

排查路径回顾（自顶向下）：
  L7 应用层： curl → 502 → 问题在上游
  L4 传输层： telnet → Connection refused → 端口不监听
             netstat → 无LISTEN → 进程异常
             SSH → 日志 → OOM
  L3 网络层： ping → 正常（本次排查中网络层没问题）
  L2 链路层： 无需排查

排查工具箱：
  应用层   → curl, Chrome DevTools
  传输层   → telnet, nc, netstat, tcpdump, Wireshark
  网络层   → ping, traceroute, mtr, ip route
  链路层   → arp, ethtool, tcpdump -e

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

"遇到网络问题第一件事做什么？"

不是敲命令，而是先做一件事：缩小范围。

1. 是自己打不开还是所有人都打不开？
   → curl/cron监控 → 所有人打不开 = 服务端问题

2. 是哪个服务/接口出问题？
   → 日志+curl逐个接口测试 → 定位到具体接口

3. 是整个服务都慢，还是特定操作慢？
   → 接口粒度 → 定位到具体操作

4. 是什么时候开始出的问题？
   → 日志时间+版本发布时间 → 关联到变更

范围缩小后，再按OSI模型自顶向下逐层使用工具排查。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

# 10.8 全文知识图谱回顾

                    小林的排查之旅
                    │
    ┌───────┬───────┼───────┬───────┐
    │       │       │       │       │
  curl    telnet  netstat  ping    traceroute
  应用层   传输层   传输层   网络层   网络层
    │       │       │       │       │
    ▼       ▼       ▼       ▼       ▼
   502   Refused  OOM    通但端口  路径追踪
 [9章]  [6章]   [4章]   [2章]   [7章]
    │       │       │       │       │
    └───────┴───────┼───────┴───────┘
                    │
        ┌───────────┴───────────┐
        │                       │
  tcpdump抓包 [6.4]       链路层排查 [8章]
  重传/乱序/0窗口           ARP/网卡/MAC
        │                       │
        └───────────┬───────────┘
                    │
   应用→传输→网络→链路  完整故障排查实战
     [第10章]           curl→telnet→netstat→日志
                    │
                    ▼
      缩小范围 + 分层排查 + 工具组合
         网络故障排查的方法论 [10.7节]

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

最终的方法论沉淀——排查网络故障时，都应该问自己三个问题：

范围缩小了吗？（是全局还是局部？哪个接口？什么时间开始的？→ 不盲目排查）
层次清楚了吗？（应用层→传输层→网络层→链路层，各用各的工具 → 不混用工具）
根因找到了吗？（不只是"重启好了"，而是找到为什么出问题 → 不复现）

把这三个问题问到位，你就从"会敲命令"进化到了"能独立排查网络问题的工程师"。

# 11.思考题与作业

# 11.1 基础思考题

Ping vs Telnet：ping 10.0.0.1 能通但 telnet 10.0.0.1 80 不通，可能的原因有哪些？（至少列举3种）
502 vs 504：Nginx 返回 502 和 504 分别代表什么？排查方向有什么不同？
traceroute 星号之谜：traceroute 输出中从某跳开始全是 * * *，说明什么？加 -I 参数又正常了，说明什么？
工具分层：将以下工具填入正确的 OSI 层次：ping、telnet、curl、tcpdump、arp、traceroute、ethtool。

# 11.2 进阶思考题

CLOSE_WAIT 堆积排查：netstat -ant | grep CLOSE_WAIT | wc -l 返回 500+。这是什么问题？如何找到是哪个服务没有正确关闭连接？和之前哪篇文章的知识点关联？
TIME_WAIT 的排查思路：netstat -ant | grep TIME_WAIT | wc -l 返回 30000+。这是正常的还是不正常的？如何判断是否需要优化？优化手段有哪些？
TCP重传的定量分析：netstat -s 显示 1000 万次重传。如何判断这个数值是否正常？如何用 tcpdump 抓包并精确定位是哪个连接在重传？重传的主要原因有哪些？
跨层排查的陷阱：为什么网络工程师经常说"ping通了不代表网络就没问题"？请举出一个 ping 通但应用层出问题的具体例子（不是防火墙屏蔽端口），并给出排查方法。

# 11.3 动手作业

作业一（必做）：模拟并排查一个网络故障。

在你的机器上启动一个简单的 HTTP 服务（python -m http.server 8080）。
分别执行：ping localhost、telnet localhost 8080、curl localhost:8080、netstat -ant | grep 8080。
记录每个命令的输出和含义。
然后 kill 掉 HTTP 服务，再次执行以上命令，对比输出差异。

作业二（选做）：用 tcpdump 抓包分析一次 HTTPS 请求。

sudo tcpdump -i lo0 -w https_debug.pcap port 443 &
curl -v https://www.baidu.com > /dev/null
sudo pkill tcpdump

1
2
3

用 Wireshark 打开 https_debug.pcap，找到 TCP 三次握手、TLS 握手（ClientHello→ServerHello→...）、HTTP 请求/响应（加密后不可读）。
在 Wireshark 的 Statistics → Flow Graph 中查看完整的通信时序图。
计算：TCP握手耗时、TLS握手耗时、总RTT次数。

作业三（架构思考）：建立你的排查清单。

为你负责的线上服务建立一份"故障排查 SOP"，按照"现象→工具→命令→预期输出→异常判断"的格式编写。
至少覆盖三类常见故障：① 完全无法访问 ② 访问慢 ③ 间歇性超时。
标注每步命令对应本章的哪个章节。

上次更新: 2026/06/09, 15:47:57

← HTTP代理和缓存设计 WebSocket实时通信→