Linux 服务器网络延迟高的排查方法
问题背景
生产环境中，服务器网络延迟突然升高是常见故障。表现为：API 接口响应慢、数据库连接超时、服务间调用耗时增加、用户反馈页面加载缓慢。延迟问题可能出在应用层、系统层、网络层或物理层，排查时需要自底向上，逐层定位。
本文适用于以下角色：
- 负责服务器运维的系统管理员
- 排查生产故障的运维工程师
- 需要分析网络性能的 DevOps 工程师
- 负责应用性能优化的后端工程师
网络延迟问题具有以下特点：
- 症状明显但根因隐蔽
- 可能涉及多层网络设备
- 需要结合多种工具综合判断
- 可能同时存在多个影响因素
- 需要长期监控才能发现规律
适用场景
本文排查方法适用于以下场景：
- 云服务器或物理服务器网络延迟突然升高
- 服务间调用耗时异常
- 数据库连接延迟增加
- CDN 回源延迟高
- VPN 或专线延迟波动
- 容器网络延迟问题
- 跨机房、跨地域访问延迟高
- 特定时间段延迟升高
- 部分用户反馈访问慢
不适用于以下场景：
- 应用代码逻辑慢（需要代码性能分析）
- 数据库查询慢（需要慢查询分析）
- 磁盘 I/O 慢（需要存储性能分析）
- CPU 或内存瓶颈（需要系统性能分析）
核心知识点
网络延迟的层次
网络延迟可以分为以下几层：
应用层延迟
- DNS 解析延迟
- HTTP 建连延迟
- TLS 握手延迟
- 应用处理延迟
传输层延迟
- TCP 建连延迟（三次握手）
- TCP 重传延迟
- 连接队列延迟
- 拥塞控制延迟
网络层延迟
- 路由查找延迟
- 跨网段转发延迟
- 防火墙规则延迟
- NAT 转换延迟
链路层延迟
关键指标
RTT (Round-Trip Time)
- 往返时延
- 包含发送时延、传播时延、处理时延、排队时延
- 通过 ping 或 mtr 测量
丢包率
- 包丢失比例
- 丢包会导致重传，增加延迟
- 通过 ping 或 mtr 测量
带宽利用率
- 当前使用带宽占总带宽的比例
- 高利用率可能导致排队延迟
- 通过 iftop、nload 或监控系统观察
连接数
- 当前活跃连接数
- 过多连接可能导致队列延迟
- 通过 ss 或 netstat 统计
CPU 软中断
- 网络数据包处理占用的 CPU
- 软中断过高说明网络包处理压力大
- 通过 top、mpstat 观察
常见原因
物理层问题
- 网线老化或接触不良
- 光纤衰减
- 交换机端口故障
- 网卡硬件故障
链路层问题
- 网卡驱动问题
- 网卡队列满
- 交换机配置错误
- VLAN 配置问题
网络层问题
传输层问题
- TCP 重传
- 连接队列满
- 拥塞窗口过小
- TIME_WAIT 过多
应用层问题
- DNS 解析慢
- HTTP Keep-Alive 未启用
- TLS 握手慢
- 应用处理慢
外部因素
- 运营商网络故障
- DDoS 攻击
- 带宽被占满
- 同机房其他服务器异常
整体排查思路
网络延迟排查需要遵循以下原则：
- 先确认现象和影响范围
- 收集基线数据和历史数据
- 从客户端到服务器逐段测试
- 结合多种工具交叉验证
- 排除法逐步缩小范围
- 记录所有测试结果和操作
- 修复后验证并持续观察
排查路径：
用户反馈延迟高 ↓确认影响范围（单用户/多用户，单服务/多服务） ↓确认延迟类型（DNS/建连/传输/应用） ↓测试网络连通性（ping、traceroute、mtr） ↓检查服务器负载（CPU、内存、网络、磁盘） ↓检查网络统计（丢包、重传、错误） ↓检查系统参数（内核参数、网卡配置） ↓检查应用日志（慢请求、超时、错误） ↓检查中间设备（防火墙、负载均衡、NAT） ↓定位根因并修复 ↓验证修复效果 ↓持续监控
实战步骤
第一步：确认现象和影响范围
目的：确定问题的严重程度和影响范围，判断是否需要立即处理。
1.1 确认用户反馈
收集以下信息：
- 哪些用户反馈慢？（全部/部分）
- 哪些功能慢？（登录/查询/上传/下载）
- 什么时候开始慢的？（时间点）
- 慢的程度？（卡顿/超时/完全无法访问）
- 是否有规律？（特定时间/特定操作/特定用户）
1.2 确认服务影响
登录到一台客户端机器或自己的开发机，测试访问：
# 测试 HTTP 接口响应时间time curl -I http://your-server.com# 测试 HTTPS 接口响应时间time curl -I https://your-server.com# 测试 API 接口响应时间time curl -s -o /dev/null -w "time_total: %{time_total}\n" http://your-server.com/api/test# 测试数据库连接time mysql -h your-db-host -u user -p -e "SELECT 1"# 测试 Redis 连接time redis-cli -h your-redis-host PING
预期输出：
正常情况下，HTTP 接口响应时间应在 100ms 以内，数据库连接应在 10ms 以内。
异常表现：
判断逻辑：
- 如果所有接口都慢，可能是服务器整体问题
- 如果只有部分接口慢，可能是应用问题
- 如果只有外网用户慢，可能是网络链路问题
- 如果只有内网用户慢，可能是内网设备问题
1.3 确认影响范围
检查监控系统，确认：
- 是否所有服务器都慢？
- 是否所有服务都慢？
- 是否所有地域的用户都慢？
- 延迟是突然升高还是逐渐升高？
- 是否有告警触发？
如果监控系统中能看到明显的延迟升高，记录时间点，方便后续关联其他变更。
第二步：测试网络连通性
目的：确认网络是否正常，是否存在丢包、延迟高、路由异常等问题。
2.1 使用 ping 测试基本连通性
# 测试到目标服务器的连通性ping -c 100 your-server-ip# 测试到网关的连通性ping -c 100 gateway-ip# 测试到 DNS 服务器的连通性ping -c 100 8.8.8.8# 测试到同机房其他服务器的连通性ping -c 100 other-server-ip
预期输出：
100 packets transmitted, 100 received, 0% packet loss, time 99msrtt min/avg/max/mdev = 0.123/0.456/1.234/0.123 ms
异常表现：
100 packets transmitted, 95 received, 5% packet loss, time 99msrtt min/avg/max/mdev = 0.123/12.456/100.234/15.123 ms
判断逻辑：
- 丢包率大于 1%，说明网络存在丢包
- 平均延迟大于 10ms（同机房）或大于 50ms（跨机房），说明延迟高
- 延迟波动大（mdev 大），说明网络不稳定
- 完全 ping 不通，说明网络中断或防火墙阻止 ICMP
下一步动作：
- 如果丢包率高，使用 mtr 定位丢包位置
- 如果延迟高但不丢包，检查路由和中间设备
- 如果 ping 不通，检查防火墙和路由
2.2 使用 mtr 追踪路由和丢包
mtr 是 traceroute 和 ping 的结合体，能够持续追踪每一跳的延迟和丢包率。
# 安装 mtryum install -y mtr # CentOS/RHELapt install -y mtr # Ubuntu/Debian# 持续追踪路由mtr -r -c 100 your-server-ip# 持续追踪路由（显示 IP 和主机名）mtr -r -c 100 -n your-server-ip# 持续追踪路由（TCP 模式，适用于 ICMP 被禁用的场景）mtr -r -c 100 -T -P 80 your-server-ip# 持续追踪路由（UDP 模式）mtr -r -c 100 -u your-server-ip
预期输出：
HOST: client-machine Loss% Snt Last Avg Best Wrst StDev 1.|-- gateway 0.0% 100 0.5 0.5 0.3 1.2 0.1 2.|-- isp-router-1 0.0% 100 2.3 2.5 2.1 5.6 0.4 3.|-- isp-router-2 0.0% 100 5.6 5.8 5.2 10.3 0.6 4.|-- your-server 0.0% 100 8.9 9.1 8.5 15.2 0.8
异常表现：
HOST: client-machine Loss% Snt Last Avg Best Wrst StDev 1.|-- gateway 0.0% 100 0.5 0.5 0.3 1.2 0.1 2.|-- isp-router-1 5.0% 100 12.3 15.5 10.1 55.6 8.4 3.|-- isp-router-2 10.0% 100 25.6 28.8 20.2 100.3 12.6 4.|-- your-server 10.0% 100 38.9 41.1 35.5 150.2 18.8
判断逻辑：
- 如果某一跳丢包率突然升高，说明该跳存在问题
- 如果某一跳延迟突然升高，说明该跳存在拥塞
- 如果最后一跳丢包率高但中间跳正常，可能是目标服务器问题
- 如果所有跳延迟都高，可能是带宽不足或全链路拥塞
下一步动作：
- 如果丢包或延迟出现在运营商网段，联系运营商
- 如果丢包或延迟出现在自己的网段，检查对应设备
- 如果只有目标服务器延迟高，登录服务器检查系统负载
2.3 使用 traceroute 分析路由路径
traceroute 用于查看数据包到达目标的路径。
# TCP SYN 模式追踪路由traceroute -T -p 80 your-server-ip# ICMP 模式追踪路由traceroute -I your-server-ip# UDP 模式追踪路由（默认）traceroute your-server-ip# 指定最大跳数traceroute -m 30 your-server-ip
预期输出：
traceroute to your-server-ip (x.x.x.x), 30 hops max, 60 byte packets 1 gateway (192.168.1.1) 0.523 ms 0.512 ms 0.498 ms 2 isp-router-1 (x.x.x.x) 2.345 ms 2.312 ms 2.298 ms 3 isp-router-2 (x.x.x.x) 5.678 ms 5.612 ms 5.598 ms 4 your-server (x.x.x.x) 8.901 ms 8.812 ms 8.798 ms
异常表现：
traceroute to your-server-ip (x.x.x.x), 30 hops max, 60 byte packets 1 gateway (192.168.1.1) 0.523 ms 0.512 ms 0.498 ms 2 * * * 3 isp-router-2 (x.x.x.x) 25.678 ms 25.612 ms 25.598 ms 4 * * * 5 your-server (x.x.x.x) 108.901 ms 108.812 ms 108.798 ms
判断逻辑：
* * * 表示该跳没有响应，可能是防火墙阻止了 ICMP/UDP，也可能是设备故障- 延迟在某一跳突然增加，说明该跳或之后的链路存在问题
- 路由路径异常绕路，可能是路由配置错误
下一步动作：
- 如果路径正常但延迟高，继续检查服务器
- 如果路径异常，检查路由配置
- 如果中间跳无响应，联系网络管理员
2.4 测试 TCP 建连延迟
网络层通了不代表传输层没问题，需要测试 TCP 建连延迟。
# 使用 hping3 测试 TCP SYNhping3 -S -p 80 -c 10 your-server-ip# 使用 nc 测试 TCP 建连time nc -zv your-server-ip 80# 使用 telnet 测试 TCP 建连time telnet your-server-ip 80# 使用 curl 测试 HTTP 建连时间curl -w "time_namelookup: %{time_namelookup}\ntime_connect: %{time_connect}\ntime_appconnect: %{time_appconnect}\ntime_starttransfer: %{time_starttransfer}\ntime_total: %{time_total}\n" -o /dev/null -s http://your-server-ip
预期输出（curl）：
time_namelookup: 0.001time_connect: 0.005time_appconnect: 0.000time_starttransfer: 0.015time_total: 0.020
异常表现：
time_namelookup: 0.001time_connect: 1.205time_appconnect: 0.000time_starttransfer: 1.215time_total: 1.220
判断逻辑：
time_connect 是 TCP 建连时间，应在 10ms 以内（同机房）- 如果
time_connect 超过 100ms，说明 TCP 建连慢 - 如果
time_appconnect （TLS 握手时间）很大，说明 TLS 握手慢 - 如果
time_starttransfer 很大，说明服务器处理慢
下一步动作：
- 如果 TCP 建连慢，检查服务器连接队列和防火墙
- 如果 TLS 握手慢，检查 SSL 配置和证书
- 如果服务器处理慢，检查应用日志和性能
第三步：检查服务器负载
目的：排除服务器自身性能瓶颈导致的网络延迟。
3.1 检查 CPU 负载
# 查看整体 CPU 使用率top# 查看每个 CPU 核心的使用率mpstat -P ALL 1# 查看 CPU 软中断占比mpstat -I SUM 1# 查看进程 CPU 使用率ps aux --sort=-%cpu | head -20
预期输出（mpstat）：
%usr %sys %iowait %irq %soft %idle 10.2 5.1 0.5 0.1 2.3 81.8
异常表现：
%usr %sys %iowait %irq %soft %idle 15.2 20.1 0.5 0.1 45.3 18.8
判断逻辑：
%soft 是软中断占比，正常应小于 10%- 如果
%soft 大于 30%，说明网络包处理压力大，可能是流量过大或网卡驱动问题 - 如果
%sys 很高，说明系统调用频繁，可能是连接数过多 - 如果
%iowait 很高，说明磁盘 I/O 慢，但不应影响网络延迟
下一步动作：
- 如果
%soft 高，检查网络流量和网卡队列 - 如果 CPU 整体使用率高，检查进程占用情况
- 如果 CPU 正常，继续检查内存和网络
3.2 检查内存使用
# 查看内存使用情况free -h# 查看内存详细信息cat /proc/meminfo# 查看进程内存使用ps aux --sort=-%mem | head -20# 查看 OOM 记录dmesg | grep -i "out of memory"# 查看 swap 使用swapon -s
预期输出（free）：
total used free shared buff/cache availableMem: 15Gi 3.2Gi 8.5Gi 100Mi 3.3Gi 11GiSwap: 2.0Gi 0B 2.0Gi
异常表现：
total used free shared buff/cache availableMem: 15Gi 14Gi 100Mi 100Mi 900Mi 500MiSwap: 2.0Gi 1.5Gi 500Mi
判断逻辑：
- 如果
available 内存小于总内存的 10%，说明内存不足 - 如果 swap 使用率高，说明内存不足导致频繁换页
- 如果有 OOM 记录，说明系统曾因内存不足杀死进程
下一步动作：
- 如果内存不足，检查哪些进程占用内存多
- 如果内存正常，继续检查网络
3.3 检查磁盘 I/O
虽然磁盘 I/O 不直接影响网络延迟，但如果应用需要读写磁盘，磁盘慢会导致应用响应慢。
# 查看磁盘 I/O 统计iostat -x 1# 查看进程 I/Oiotop# 查看磁盘使用率df -h# 查看 inode 使用率df -i
预期输出（iostat）：
Device r/s w/s rkB/s wkB/s %utilsda 10.2 5.3 512.3 256.8 5.2
异常表现：
Device r/s w/s rkB/s wkB/s %utilsda 500.2 300.3 25600 15300 95.8
判断逻辑：
%util 是磁盘利用率，长期大于 80% 说明磁盘繁忙- 如果
r/s 和 w/s 很高，说明 IOPS 压力大 - 如果
rkB/s 和 wkB/s 很高，说明带宽压力大
下一步动作：
- 如果磁盘 I/O 高，检查哪些进程在读写磁盘
- 如果磁盘正常，继续检查网络
第四步：检查网络流量和连接
目的：确认网络流量是否正常，是否存在连接数过多、流量过大等问题。
4.1 检查网络流量
# 实时查看网络流量iftop -i eth0# 实时查看网络流量（按协议分类）iftop -i eth0 -P# 实时查看网络流量（数字显示）nload -u M eth0# 查看网络流量统计sar -n DEV 1# 查看网卡统计ifconfig eth0# 查看网卡统计（更详细）ip -s link show eth0# 查看网卡队列统计ethtool -S eth0
预期输出（sar -n DEV）：
IFACE rxpck/s txpck/s rxkB/s txkB/seth0 1000.2 1200.5 500.3 800.6
异常表现：
IFACE rxpck/s txpck/s rxkB/s txkB/seth0 50000.2 60000.5 25000.3 40000.6
判断逻辑：
- 如果流量接近网卡带宽上限（1Gbps = 125MB/s），说明带宽不足
- 如果包速率很高但带宽不高，说明小包多，可能是攻击
- 如果丢包率高（通过
ifconfig 看 RX errors 和 TX errors），说明网卡或驱动问题
下一步动作：
- 如果流量过大，使用
iftop 或 nethogs 定位哪些连接占用流量 - 如果丢包率高，检查网卡队列和驱动
- 如果流量正常，检查连接数
4.2 检查连接数
# 查看当前连接数ss -s# 查看各状态连接数ss -ant | awk '{print $1}' | sort | uniq -c# 查看 ESTABLISHED 连接数ss -ant | grep ESTABLISHED | wc -l# 查看 TIME_WAIT 连接数ss -ant | grep TIME_WAIT | wc -l# 查看各 IP 连接数ss -ant | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20# 查看各端口连接数ss -ant | awk '{print $4}' | cut -d: -f2 | sort | uniq -c | sort -rn | head -20
预期输出（ss -s）：
Total: 500TCP: 300 (estab 250, closed 20, orphaned 0, timewait 20)
异常表现：
Total: 50000TCP: 45000 (estab 40000, closed 5000, orphaned 100, timewait 5000)
判断逻辑：
- 如果 ESTABLISHED 连接数超过 10000，可能导致连接队列延迟
- 如果 TIME_WAIT 连接数超过 10000，可能导致端口不足
- 如果 orphaned 连接数很多，说明有连接泄漏
- 如果某个 IP 连接数特别多，可能是攻击或客户端连接池配置不当
下一步动作：
- 如果连接数过多，检查应用是否正常关闭连接
- 如果 TIME_WAIT 过多，调整内核参数或启用端口复用
- 如果连接数正常，检查网卡队列
4.3 检查网卡队列
网卡队列满会导致丢包和延迟。
# 查看网卡队列配置ethtool -g eth0# 查看网卡队列统计ethtool -S eth0 | grep -i queue# 查看网卡队列丢包ethtool -S eth0 | grep -i drop# 查看网卡队列错误ethtool -S eth0 | grep -i error# 查看网卡多队列配置ethtool -l eth0# 查看网卡中断绑定cat /proc/interrupts | grep eth0
预期输出（ethtool -S）：
rx_queue_0_drops: 0rx_queue_1_drops: 0tx_queue_0_drops: 0tx_queue_1_drops: 0
异常表现：
rx_queue_0_drops: 50000rx_queue_1_drops: 60000tx_queue_0_drops: 1000tx_queue_1_drops: 1200
判断逻辑：
- 如果
rx_queue_X_drops 很大，说明接收队列满，丢包 - 如果
tx_queue_X_drops 很大，说明发送队列满，丢包 - 如果网卡只有单队列但流量大，可能是队列不足
下一步动作：
- 如果队列丢包，增大队列长度或启用多队列
- 如果队列正常，检查内核参数
第五步：检查网络统计和错误
目的：通过内核网络统计，发现丢包、重传、错误等异常。
5.1 检查网络统计
# 查看网络统计netstat -s# 查看 TCP 统计netstat -st# 查看 UDP 统计netstat -su# 查看 ICMP 统计netstat -si# 查看 IP 统计cat /proc/net/snmp# 查看 TCP 详细统计cat /proc/net/netstat
预期输出（netstat -st 关键部分）：
Tcp: 500000 active connections openings 300000 passive connection openings 100 failed connection attempts 50 connection resets received 200 connections established 50000000 segments received 60000000 segments sent out 1000 segments retransmitted 0 bad segments received 500 resets sent
异常表现：
Tcp: 500000 active connections openings 300000 passive connection openings 50000 failed connection attempts 10000 connection resets received 200 connections established 50000000 segments received 60000000 segments sent out 5000000 segments retransmitted 10000 bad segments received 50000 resets sent
判断逻辑：
segments retransmitted 是重传包数，重传率应小于 1%failed connection attempts 是建连失败数，过多说明服务端连接队列满或防火墙阻止connection resets received 是收到的 RST 包，过多说明连接被异常关闭bad segments received 是校验和错误的包，过多说明网络质量差
下一步动作：
- 如果重传率高，检查丢包原因
- 如果建连失败多，检查服务端连接队列
- 如果 RST 多，检查应用是否正常关闭连接
5.2 检查 TCP 重传
TCP 重传是延迟升高的常见原因。
# 持续监控 TCP 重传watch -n 1 "netstat -st | grep retransmitted"# 持续监控 TCP 重传率whiletrue; do netstat -st | grep "segments retransmitted" | awk '{print $1}'sleep 1done# 使用 ss 查看重传连接ss -ti | grep retrans# 使用 tcpdump 抓取重传包tcpdump -i eth0 -nn "tcp[tcpflags] & (tcp-syn|tcp-ack) != 0" -w retrans.pcap
预期输出（ss -ti）：
ESTAB 0 0 192.168.1.100:22 192.168.1.200:50000 cubic wscale:7,7 rto:200 rtt:0.5/0.1 ato:40 mss:1448 pmtu:1500 rcvmss:1448 advmss:1448 cwnd:10 bytes_sent:1000 bytes_retrans:0 bytes_acked:1000 segs_out:10 segs_in:10 data_segs_out:5 data_segs_in:5
异常表现：
ESTAB 0 0 192.168.1.100:22 192.168.1.200:50000 cubic wscale:7,7 rto:2000 rtt:500/100 ato:40 mss:1448 pmtu:1500 rcvmss:1448 advmss:1448 cwnd:2 bytes_sent:1000000 bytes_retrans:50000 bytes_acked:950000 segs_out:1000 segs_in:950 data_segs_out:500 data_segs_in:450
判断逻辑：
rto 是重传超时时间，正常应在 200ms 左右rtt 是往返时延，正常应在 1ms 左右（同机房）cwnd 是拥塞窗口，窗口小说明网络拥塞bytes_retrans 是重传字节数，过多说明丢包严重
下一步动作：
- 如果重传多，使用 tcpdump 抓包分析
- 如果拥塞窗口小，检查是否有丢包或 RTT 高
5.3 检查连接队列
连接队列满会导致建连失败和延迟。
# 查看连接队列溢出统计netstat -st | grep -i listen# 查看 SYN 队列溢出netstat -st | grep "SYNs to LISTEN sockets dropped"# 查看 Accept 队列溢出netstat -st | grep "times the listen queue of a socket overflowed"# 查看各端口的队列情况ss -lnt# 查看各端口的队列溢出ss -lnt | awk '{print $2, $3, $4}'
预期输出（netstat -st 关键部分）：
100 SYNs to LISTEN sockets dropped50 times the listen queue of a socket overflowed
异常表现：
50000 SYNs to LISTEN sockets dropped30000 times the listen queue of a socket overflowed
判断逻辑：
SYNs to LISTEN sockets dropped 是 SYN 队列满导致的丢弃times the listen queue of a socket overflowed 是 Accept 队列满导致的丢弃- 如果这两个值持续增长，说明队列不足
下一步动作：
- 如果队列溢出，调整
net.core.somaxconn 和 net.ipv4.tcp_max_syn_backlog - 如果队列正常，检查应用是否及时 accept 连接
第六步：检查内核参数
目的：确认内核网络参数配置是否合理。
6.1 检查关键内核参数
# 查看所有网络相关参数sysctl -a | grep -E "net.ipv4|net.core"# 查看 TCP 相关参数sysctl -a | grep net.ipv4.tcp# 查看关键参数sysctl net.ipv4.tcp_tw_reusesysctl net.ipv4.tcp_tw_recyclesysctl net.ipv4.tcp_timestampssysctl net.ipv4.tcp_syncookiessysctl net.ipv4.tcp_max_syn_backlogsysctl net.core.somaxconnsysctl net.core.netdev_max_backlogsysctl net.ipv4.tcp_max_tw_bucketssysctl net.ipv4.ip_local_port_rangesysctl net.ipv4.tcp_fin_timeoutsysctl net.ipv4.tcp_keepalive_timesysctl net.ipv4.tcp_keepalive_intvlsysctl net.ipv4.tcp_keepalive_probessysctl net.ipv4.tcp_retries1sysctl net.ipv4.tcp_retries2sysctl net.ipv4.tcp_syn_retriessysctl net.ipv4.tcp_synack_retries
预期输出：
net.ipv4.tcp_tw_reuse = 1net.ipv4.tcp_timestamps = 1net.ipv4.tcp_syncookies = 1net.ipv4.tcp_max_syn_backlog = 8192net.core.somaxconn = 1024net.core.netdev_max_backlog = 5000net.ipv4.tcp_max_tw_buckets = 5000net.ipv4.ip_local_port_range = 32768 60999net.ipv4.tcp_fin_timeout = 30
异常表现：
net.ipv4.tcp_tw_reuse = 0net.ipv4.tcp_timestamps = 0net.ipv4.tcp_syncookies = 0net.ipv4.tcp_max_syn_backlog = 128net.core.somaxconn = 128net.core.netdev_max_backlog = 1000net.ipv4.tcp_max_tw_buckets = 1000net.ipv4.ip_local_port_range = 32768 60999net.ipv4.tcp_fin_timeout = 60
判断逻辑：
tcp_tw_reuse 应为 1，允许复用 TIME_WAIT 连接tcp_syncookies 应为 1，防止 SYN Flood 攻击tcp_max_syn_backlog 应大于 8192，高并发场景应调大somaxconn 应大于 1024，高并发场景应调大netdev_max_backlog 应大于 5000，高流量场景应调大tcp_fin_timeout 应小于 60，加快连接回收
下一步动作：
- 如果参数不合理，调整参数并观察效果
- 如果参数合理，检查应用层
6.2 调整内核参数
调整内核参数前，必须备份当前配置。
# 备份当前参数sysctl -a > /root/sysctl_backup_$(date +%Y%m%d_%H%M%S).txt# 临时调整参数（重启后失效）sysctl -w net.ipv4.tcp_tw_reuse=1sysctl -w net.ipv4.tcp_max_syn_backlog=16384sysctl -w net.core.somaxconn=2048sysctl -w net.core.netdev_max_backlog=10000sysctl -w net.ipv4.tcp_max_tw_buckets=10000sysctl -w net.ipv4.tcp_fin_timeout=30# 永久调整参数cat >> /etc/sysctl.conf << 'EOF'net.ipv4.tcp_tw_reuse = 1net.ipv4.tcp_timestamps = 1net.ipv4.tcp_syncookies = 1net.ipv4.tcp_max_syn_backlog = 16384net.core.somaxconn = 2048net.core.netdev_max_backlog = 10000net.ipv4.tcp_max_tw_buckets = 10000net.ipv4.tcp_fin_timeout = 30net.ipv4.ip_local_port_range = 10000 65535EOF# 使配置生效sysctl -p# 验证配置sysctl net.ipv4.tcp_tw_reusesysctl net.ipv4.tcp_max_syn_backlog
风险提醒：
- 修改内核参数可能影响所有连接
- 部分参数在旧内核版本中不存在
tcp_tw_recycle 在 Linux 4.12+ 中已移除，不要使用- 生产环境修改前应在测试环境验证
回滚方案：
# 从备份恢复sysctl -p /root/sysctl_backup_20260815_100000.txt# 或者手动恢复单个参数sysctl -w net.ipv4.tcp_tw_reuse=0
第七步：检查防火墙和安全组
目的：排除防火墙规则导致的延迟。
7.1 检查 iptables 规则
# 查看 iptables 规则数量iptables -L -n | wc -l# 查看 nat 表规则iptables -t nat -L -n -v# 查看 filter 表规则iptables -t filter -L -n -v# 查看 mangle 表规则iptables -t mangle -L -n -v# 查看连接跟踪表cat /proc/net/nf_conntrack | wc -l# 查看连接跟踪表大小sysctl net.netfilter.nf_conntrack_max# 查看连接跟踪统计cat /proc/sys/net/netfilter/nf_conntrack_count
预期输出：
iptables 规则数：50连接跟踪表使用：1000 / 65536
异常表现：
iptables 规则数：5000连接跟踪表使用：65500 / 65536
判断逻辑：
- 如果 iptables 规则超过 1000 条，每个包的匹配延迟增加
- 如果连接跟踪表接近满，新连接会被丢弃
- 如果连接跟踪表持续增长，可能是连接泄漏
下一步动作：
- 如果规则过多，简化规则或使用 ipset
- 如果连接跟踪表满，增大
nf_conntrack_max - 如果连接跟踪表正常，检查应用层
7.2 检查云服务器安全组
如果是云服务器，检查安全组规则。
# AWS 查看安全组aws ec2 describe-security-groups --group-ids sg-xxxxxx# 阿里云查看安全组aliyun ecs DescribeSecurityGroupAttribute --SecurityGroupId sg-xxxxxx# 腾讯云查看安全组tccli vpc DescribeSecurityGroupPolicies --SecurityGroupId sg-xxxxxx
检查要点：
- 是否有不必要的 DENY 规则
- 是否有过于宽松的 ALLOW 规则
- 是否有规则冲突
- 是否有限流规则
第八步：检查应用层
目的：排除应用层导致的延迟。
8.1 检查应用日志
# 查看应用访问日志tail -f /var/log/nginx/access.log# 统计慢请求awk '{if($NF > 1) print $0}' /var/log/nginx/access.log | tail -100# 统计各接口响应时间awk '{print $7, $NF}' /var/log/nginx/access.log | awk '{sum[$1]+=$2; count[$1]++} END {for(i in sum) print i, sum[i]/count[i]}' | sort -k2 -rn | head -20# 查看应用错误日志tail -f /var/log/nginx/error.log# 查看应用错误日志（超时）grep -i timeout /var/log/nginx/error.log | tail -100
预期输出：
接口平均响应时间均在 0.1 秒以内无大量超时错误
异常表现：
部分接口平均响应时间超过 1 秒存在大量 upstream timed out 错误
判断逻辑：
- 如果只有部分接口慢，是应用问题
- 如果所有接口慢，可能是数据库或网络问题
- 如果有 upstream timed out，是后端服务慢
下一步动作：
- 如果应用慢，检查应用性能
- 如果后端慢，检查后端服务
- 如果应用正常，检查数据库
8.2 检查数据库连接
# 查看 MySQL 连接数mysql -e "SHOW PROCESSLIST" | wc -l# 查看 MySQL 慢查询mysql -e "SHOW VARIABLES LIKE 'slow_query_log%'"mysql -e "SHOW VARIABLES LIKE 'long_query_time'"# 查看 MySQL 慢查询日志tail -f /var/log/mysql/slow.log# 查看 Redis 连接数redis-cli INFO clients# 查看 Redis 慢查询redis-cli SLOWLOG GET 10
预期输出：
MySQL 连接数：50 / 200MySQL 慢查询：0Redis 连接数：100Redis 慢查询：0
异常表现：
MySQL 连接数：200 / 200MySQL 慢查询：500Redis 连接数：10000Redis 慢查询：100
判断逻辑：
- 如果数据库连接数达到上限，新连接会等待
- 如果慢查询多，是 SQL 性能问题
- 如果 Redis 连接数过多，可能是连接泄漏
下一步动作：
- 如果数据库连接满，增大连接数或优化连接池
- 如果慢查询多，优化 SQL
- 如果连接数正常，检查 DNS
8.3 检查 DNS 解析
DNS 解析慢是常见问题。
# 测试 DNS 解析时间time nslookup your-domain.com# 测试 DNS 解析时间（指定 DNS 服务器）time nslookup your-domain.com 8.8.8.8# 测试 DNS 解析时间（dig）time dig your-domain.com# 测试 DNS 解析时间（host）time host your-domain.com# 查看 DNS 配置cat /etc/resolv.conf# 测试本地 hostscat /etc/hosts | grep your-domain.com
预期输出：
异常表现：
判断逻辑：
- 如果 DNS 解析慢，换用其他 DNS 服务器
- 如果解析失败，检查 DNS 配置
- 如果解析正常但应用慢，可能是应用未复用连接
下一步动作：
- 如果 DNS 慢，修改
/etc/resolv.conf - 如果 DNS 正常，检查应用是否缓存 DNS
第九步：使用 tcpdump 抓包分析
目的：通过抓包分析，定位具体问题。
9.1 抓取指定端口的包
# 抓取 80 端口的包tcpdump -i eth0 -nn port 80 -w http.pcap# 抓取 443 端口的包tcpdump -i eth0 -nn port 443 -w https.pcap# 抓取 3306 端口的包tcpdump -i eth0 -nn port 3306 -w mysql.pcap# 抓取指定 IP 的包tcpdump -i eth0 -nn host 192.168.1.100 -w host.pcap# 抓取 SYN 包tcpdump -i eth0 -nn "tcp[tcpflags] & tcp-syn != 0" -w syn.pcap# 抓取 RST 包tcpdump -i eth0 -nn "tcp[tcpflags] & tcp-rst != 0" -w rst.pcap# 抓取重传包tcpdump -i eth0 -nn "tcp[tcpflags] & tcp-syn != 0 and tcp[tcpflags] & tcp-ack != 0" -w retrans.pcap
风险提醒：
- tcpdump 会占用 CPU 和磁盘 I/O
- 抓包文件可能很大，注意磁盘空间
- 生产环境抓包应限制时间和大小
限制抓包大小：
# 限制抓包文件大小为 100MBtcpdump -i eth0 -nn port 80 -C 100 -w http.pcap# 限制抓包时间为 60 秒timeout 60 tcpdump -i eth0 -nn port 80 -w http.pcap# 限制抓包数量为 1000 个包tcpdump -i eth0 -nn port 80 -c 1000 -w http.pcap
9.2 分析抓包文件
抓包后，使用 Wireshark 或 tcpdump 分析。
# 查看抓包文件信息tcpdump -r http.pcap | wc -l# 查看抓包文件中的连接tcpdump -r http.pcap -nn | awk '{print $3, $5}' | sort | uniq -c | sort -rn | head -20# 查看抓包文件中的重传包tcpdump -r http.pcap -nn "tcp[tcpflags] & tcp-syn != 0 and tcp[tcpflags] & tcp-ack != 0"# 使用 tshark 分析tshark -r http.pcap -q -z io,stat,1# 使用 tshark 分析重传tshark -r http.pcap -Y "tcp.analysis.retransmission"# 使用 tshark 分析慢响应tshark -r http.pcap -Y "http.time > 1"
分析要点：
- 是否有大量重传？
- 是否有大量 RST？
- 建连时间是否正常？
- 数据传输时间是否正常？
- 是否有乱序？
第十步：定位具体原因并修复
根据前面的排查结果，定位具体原因。
10.1 物理层问题
症状：
修复方案：
# 更换网线# 更换网卡# 更换交换机端口# 检查网卡是否识别lspci | grep -i ethernet# 检查网卡驱动ethtool -i eth0# 重新加载网卡驱动modprobe -r <driver_name>modprobe <driver_name># 重启网卡ifdown eth0ifup eth0
10.2 网卡队列问题
症状：
修复方案：
# 增大网卡队列ethtool -G eth0 rx 4096 tx 4096# 启用网卡多队列ethtool -L eth0 combined 4# 绑定网卡中断到不同 CPU# 需要根据实际情况编写脚本，此处为示例思路for i in $(grep eth0 /proc/interrupts | awk '{print $1}' | tr -d ':'); doecho 1 > /proc/irq/$i/smp_affinitydone
10.3 内核参数问题
症状：
修复方案：
已在第六步描述，此处不再重复。
10.4 防火墙问题
症状：
修复方案：
# 增大连接跟踪表sysctl -w net.netfilter.nf_conntrack_max=262144# 减少连接跟踪超时时间sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=600# 简化 iptables 规则# 使用 ipset 替代大量 IP 规则ipset create blocked_ips hash:ipipset add blocked_ips 1.2.3.4iptables -A INPUT -m set --match-set blocked_ips src -j DROP
10.5 应用层问题
症状：
修复方案：
# 优化应用配置# 启用 HTTP Keep-Alive# 增大连接池# 优化数据库# 添加索引# 优化慢查询# 优化 DNS# 修改 /etc/resolv.confecho"nameserver 8.8.8.8" > /etc/resolv.confecho"nameserver 114.114.114.114" >> /etc/resolv.conf# 或使用本地 DNS 缓存yum install -y dnsmasqsystemctl start dnsmasqsystemctl enable dnsmasqecho"nameserver 127.0.0.1" > /etc/resolv.conf
10.6 带宽不足
症状：
修复方案：
# 限流# 使用 tc 限制带宽tc qdisc add dev eth0 root tbf rate 100mbit burst 10kb latency 50ms# 或升级带宽# 联系运营商或云服务商
第十一步：验证修复效果
修复后，必须验证效果。
11.1 重新测试网络延迟
# 测试 ping 延迟ping -c 100 your-server-ip# 测试 mtrmtr -r -c 100 your-server-ip# 测试 TCP 建连curl -w "time_connect: %{time_connect}\ntime_total: %{time_total}\n" -o /dev/null -s http://your-server-ip# 测试应用接口ab -n 1000 -c 10 http://your-server-ip/api/test
预期结果：
- ping 延迟恢复正常
- mtr 无丢包
- TCP 建连时间正常
- 应用接口响应时间正常
11.2 检查监控指标
登录监控系统，确认：
- 网络延迟指标是否恢复
- 丢包率是否为 0
- 重传率是否降低
- 连接数是否正常
- CPU 软中断是否正常
11.3 观察一段时间
不要立即认为问题已解决，需要持续观察：
- 观察至少 1 小时
- 观察业务高峰期
- 观察是否有新的告警
- 收集用户反馈
第十二步：记录和总结
问题解决后，必须记录和总结。
12.1 记录故障信息
记录内容包括：
- 故障时间
- 故障现象
- 影响范围
- 排查过程
- 根本原因
- 修复方案
- 验证结果
- 遗留问题
12.2 更新文档
将排查方法和修复方案更新到运维文档，方便后续参考。
12.3 优化监控告警
根据本次故障，优化监控告警：
- 增加网络延迟告警
- 增加丢包率告警
- 增加重传率告警
- 增加连接队列告警
- 增加网卡队列告警
常用命令
网络测试命令
# ping 测试ping -c 100 <ip># mtr 测试mtr -r -c 100 <ip># traceroute 测试traceroute <ip># nc 测试端口nc -zv <ip> <port># telnet 测试端口telnet <ip> <port># curl 测试 HTTPcurl -I <url>curl -w "@curl-format.txt" -o /dev/null -s <url># hping3 测试 TCPhping3 -S -p 80 -c 10 <ip>
网络统计命令
# 查看网络统计netstat -snetstat -stnetstat -su# 查看连接ss -antss -s# 查看网卡统计ifconfigip -s link# 查看网卡队列ethtool -S eth0ethtool -g eth0# 查看网络流量iftop -i eth0nload -u M eth0sar -n DEV 1
系统性能命令
# 查看 CPUtopmpstat -P ALL 1mpstat -I SUM 1# 查看内存free -hcat /proc/meminfo# 查看磁盘 I/Oiostat -x 1iotop# 查看进程ps aux --sort=-%cpups aux --sort=-%mem
内核参数命令
# 查看内核参数sysctl -a | grep netsysctl net.ipv4.tcp_tw_reuse# 临时修改内核参数sysctl -w net.ipv4.tcp_tw_reuse=1# 永久修改内核参数echo"net.ipv4.tcp_tw_reuse = 1" >> /etc/sysctl.confsysctl -p
抓包命令
# tcpdump 抓包tcpdump -i eth0 -nn port 80 -w http.pcaptcpdump -i eth0 -nn host 192.168.1.100 -w host.pcap# tcpdump 分析tcpdump -r http.pcaptcpdump -r http.pcap -nn# tshark 分析tshark -r http.pcap -q -z io,stat,1tshark -r http.pcap -Y "tcp.analysis.retransmission"
配置示例
优化后的内核参数
# /etc/sysctl.conf# 网络核心参数net.core.somaxconn = 2048net.core.netdev_max_backlog = 10000net.core.rmem_max = 16777216net.core.wmem_max = 16777216# TCP 参数net.ipv4.tcp_tw_reuse = 1net.ipv4.tcp_timestamps = 1net.ipv4.tcp_syncookies = 1net.ipv4.tcp_max_syn_backlog = 16384net.ipv4.tcp_max_tw_buckets = 10000net.ipv4.tcp_fin_timeout = 30net.ipv4.tcp_keepalive_time = 600net.ipv4.tcp_keepalive_intvl = 30net.ipv4.tcp_keepalive_probes = 3net.ipv4.tcp_rmem = 4096 87380 16777216net.ipv4.tcp_wmem = 4096 65536 16777216net.ipv4.tcp_slow_start_after_idle = 0net.ipv4.tcp_mtu_probing = 1# 端口范围net.ipv4.ip_local_port_range = 10000 65535# 连接跟踪net.netfilter.nf_conntrack_max = 262144net.netfilter.nf_conntrack_tcp_timeout_established = 600
Nginx 配置优化
# nginx.confworker_processes auto;worker_rlimit_nofile65535;events {useepoll;worker_connections10240;multi_accepton;}http {# 连接优化keepalive_timeout65;keepalive_requests100;# 上游连接池upstream backend {server192.168.1.100:8080;keepalive32; }server {listen80;location / {proxy_pass http://backend;proxy_http_version1.1;proxy_set_header Connection ""; } }# 日志格式（包含响应时间）log_format main '$remote_addr - $remote_user [$time_local] "$request" ''$status$body_bytes_sent "$http_referer" ''"$http_user_agent" $request_time';}
监控脚本示例
#!/bin/bash# 网络延迟监控脚本LOG_FILE="/var/log/network_monitor.log"TARGET_IP="your-server-ip"THRESHOLD_RTT=10THRESHOLD_LOSS=1whiletrue; do TIMESTAMP=$(date +"%Y-%m-%d %H:%M:%S")# 执行 ping 测试 RESULT=$(ping -c 10 -W 1 $TARGET_IP 2>&1)# 提取 RTT 和丢包率 RTT=$(echo"$RESULT" | grep "rtt min/avg/max" | awk -F'/''{print $5}') LOSS=$(echo"$RESULT" | grep "packet loss" | awk '{print $6}' | tr -d '%')# 判断是否异常if (( $(echo "$RTT > $THRESHOLD_RTT" | bc -l) )); thenecho"$TIMESTAMP [WARN] RTT: ${RTT}ms > ${THRESHOLD_RTT}ms" >> $LOG_FILEfiif (( $(echo "$LOSS > $THRESHOLD_LOSS" | bc -l) )); thenecho"$TIMESTAMP [WARN] Loss: ${LOSS}% > ${THRESHOLD_LOSS}%" >> $LOG_FILEfisleep 60done
日志和指标观察方法
关键日志位置
# 系统日志/var/log/messages/var/log/syslog# 内核日志dmesg/var/log/kern.log# 网络日志journalctl -u networkjournalctl -u NetworkManager# 应用日志/var/log/nginx/access.log/var/log/nginx/error.log
关键指标
网络指标：
连接指标：
- ESTABLISHED 连接数
- TIME_WAIT 连接数
- 连接队列长度
- 建连失败数
系统指标：
- CPU 软中断占比
- 网卡队列丢包
- 内存使用率
- 磁盘 I/O
应用指标：
Prometheus 监控查询示例
# 网络延迟node_network_receive_bytes_totalrate(node_network_receive_bytes_total[5m])# 网卡错误rate(node_network_receive_errs_total[5m])rate(node_network_transmit_errs_total[5m])# TCP 连接数node_netstat_Tcp_CurrEstab# TCP 重传率rate(node_netstat_Tcp_RetransSegs[5m]) / rate(node_netstat_Tcp_OutSegs[5m])# 软中断rate(node_cpu_seconds_total{mode="softirq"}[5m])
排查路径总结
完整的排查路径：
- 确认现象和影响范围
- 测试网络连通性（ping、mtr、traceroute）
- 检查服务器负载（CPU、内存、磁盘、网络）
- 检查网络流量和连接（iftop、ss、netstat）
- 检查网络统计和错误（netstat -s、ethtool）
- 检查内核参数（sysctl）
- 检查防火墙和安全组（iptables、云控制台）
- 检查应用层（应用日志、数据库、DNS）
- 使用 tcpdump 抓包分析
- 定位具体原因并修复
- 验证修复效果
- 记录和总结
风险提醒
高风险操作
以下操作可能影响生产环境，执行前必须确认：
修改内核参数
# 风险：可能影响所有连接，导致连接中断# 操作前：备份当前配置sysctl -a > /root/sysctl_backup.txt# 操作：先在测试环境验证sysctl -w net.ipv4.tcp_tw_reuse=1# 回滚：从备份恢复sysctl -p /root/sysctl_backup.txt
重启网卡
# 风险：网络中断，所有连接断开# 操作前：确认是否有其他网卡，是否可以通过带外管理恢复# 操作前：通知用户和相关团队# 操作ifdown eth0 && ifup eth0# 回滚：如果无法恢复，需要物理接入或带外管理
修改 iptables 规则
# 风险：可能阻止正常流量，导致服务不可用# 操作前：备份当前规则iptables-save > /root/iptables_backup.txt# 操作：先在测试环境验证iptables -A INPUT -s 1.2.3.4 -j DROP# 回滚：从备份恢复iptables-restore < /root/iptables_backup.txt
抓包
# 风险：占用 CPU、磁盘 I/O、磁盘空间# 操作前：检查磁盘空间df -h# 操作：限制抓包大小和时间tcpdump -i eth0 -nn port 80 -C 100 -w http.pcap# 清理：及时删除抓包文件rm -f /root/*.pcap
常见误区
误区 1：ping 通就代表网络正常
ping 只能测试 ICMP 协议，不能代表 TCP 连接正常。部分防火墙会限制 ICMP，导致 ping 不通但 TCP 正常。
误区 2：延迟高一定是网络问题
延迟高可能是应用处理慢、数据库查询慢、磁盘 I/O 慢等，不一定是网络问题。
误区 3：调大所有内核参数就能解决问题
内核参数需要根据实际情况调整，盲目调大可能导致内存不足或其他问题。
误区 4：重启服务器能解决所有问题
重启服务器可能临时缓解问题，但不能解决根本原因，问题可能再次出现。
误区 5：只看监控指标不分析日志
监控指标只能反映表象，日志才能揭示根本原因。
验证方式
网络层验证
# 验证 ping 延迟ping -c 100 your-server-ip# 验证 mtr 丢包mtr -r -c 100 your-server-ip# 验证 TCP 建连curl -w "time_connect: %{time_connect}\n" -o /dev/null -s http://your-server-ip
传输层验证
# 验证重传率netstat -st | grep "segments retransmitted"# 验证连接数ss -s# 验证连接队列netstat -st | grep -i listen
应用层验证
# 验证应用响应时间ab -n 1000 -c 10 http://your-server-ip/api/test# 验证数据库查询时间mysql -e "SELECT BENCHMARK(1000000, MD5('test'))"# 验证 DNS 解析时间time nslookup your-domain.com
系统层验证
# 验证 CPU 软中断mpstat -I SUM 1# 验证网卡队列丢包ethtool -S eth0 | grep -i drop# 验证内核参数sysctl net.ipv4.tcp_tw_reuse
回滚方案
内核参数回滚
# 备份sysctl -a > /root/sysctl_backup_$(date +%Y%m%d_%H%M%S).txt# 回滚sysctl -p /root/sysctl_backup_20260815_100000.txt# 或手动回滚单个参数sysctl -w net.ipv4.tcp_tw_reuse=0
防火墙规则回滚
# 备份iptables-save > /root/iptables_backup_$(date +%Y%m%d_%H%M%S).txt# 回滚iptables-restore < /root/iptables_backup_20260815_100000.txt
应用配置回滚
# 备份cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.backup_$(date +%Y%m%d_%H%M%S)# 回滚cp /etc/nginx/nginx.conf.backup_20260815_100000 /etc/nginx/nginx.confnginx -tsystemctl reload nginx
网卡配置回滚
# 备份cp /etc/sysconfig/network-scripts/ifcfg-eth0 /root/ifcfg-eth0.backup_$(date +%Y%m%d_%H%M%S)# 回滚cp /root/ifcfg-eth0.backup_20260815_100000 /etc/sysconfig/network-scripts/ifcfg-eth0systemctl restart network
生产环境注意事项
操作前检查
- 确认影响范围
- 通知相关团队
- 备份当前配置
- 准备回滚方案
- 选择业务低峰期
操作中注意
- 一次只改一个参数
- 改完立即验证
- 记录所有操作
- 持续观察监控
- 随时准备回滚
操作后验证
- 验证网络延迟
- 验证应用功能
- 验证监控指标
- 收集用户反馈
- 观察至少 1 小时
变更管理
- 提交变更单
- 变更前评审
- 变更中监控
- 变更后复盘
- 更新文档
应急预案
- 准备回滚命令
- 准备应急联系人
- 准备备用方案
- 准备应急公告
- 准备故障报告模板
总结
网络延迟排查是一个系统工程，需要从物理层到应用层，从客户端到服务器，从网络到系统，全面排查。
排查时要遵循以下原则：
- 先确认现象和影响范围
- 从简单到复杂，从外到内
- 结合多种工具交叉验证
- 记录所有测试结果和操作
- 修复后验证并持续观察
常见原因包括：
- 物理层：网线、网卡、交换机故障
- 链路层：网卡队列满、驱动问题
- 网络层：路由、防火墙、NAT 问题
- 传输层：TCP 重传、连接队列满
- 应用层：DNS 解析慢、应用处理慢
修复后必须验证效果，并持续观察一段时间，确保问题真正解决。
最后，将排查方法和修复方案文档化，方便后续参考，并优化监控告警，提前发现问题。
网络延迟问题排查是运维工程师的基本功，需要不断实践和积累经验。
10个月宝宝每天需要喝多少奶粉？
