• 这是《计算机网络 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。本附录按生产排障场景组织常用命令和检查项。命令以 Linux 为主线，不同发行版、云平台和内核版本的输出可能有差异；涉及厂商能力时，以当前环境文档为准。1. 基础信息收集网络故障先收集事实，再建立假设。不要在未确认拓扑前直接改参数。uname -acat /etc/os-releaseip -br addrip -d linkip routeip -6 routeip neighss -lntupss -sss -antpethtool eth0ethtool -S eth0ethtool -i eth0常用组合：ip -br addr show eth0ip route get 10.20.30.40ss -lntp | grep ':443'ss -tan state established '( sport = :9000 or dport = :9000 )'解读要点： 输出 含义 常见下一步 ip route get 命中默认路由 走网关 检查网关和安全组 ip neigh 为 FAILED 邻居解析失败 检查 VLAN、ARP、防火墙 ss 只有 LISTEN，无连接 服务未收到请求 检查上游和负载均衡 ethtool -S 错包增长 链路质量问题 检查双工、速率、线缆和交换机 2. 连通性与路径诊断ping -c 4 10.20.30.40ping -c 4 2001:db8::1ping -c 4 -M do -s 1472 10.20.30.40traceroute -n 10.20.30.40traceroute -6 -n 2001:db8::1mtr -rwzc 100 10.20.30.40tracepath -n 10.20.30.40nc -vz 10.20.30.40 3306nc -vl 0.0.0.0 9000ping 不通不代表服务不可用，可能是 ICMP 被策略禁止。端口探测和应用层探测要分开：nc -vz db.internal 5432curl -v telnet://db.internal:5432curl -v http://app.internal:8080/healthz路径质量优先看 mtr：mtr -rwzc 100 -i 0.2 example.com判断要点： 现象 常见原因 下一步 只在某一跳丢包 单节点或链路异常 对比多源拨测 从某一跳后全部丢包 路径中断或策略限速 检查运营商或云网络 延迟阶梯异常 绕行、跨境、拥塞 结合路由和地域 丢包且 TCP 重传高 真实影响流量 看重传统计和抓包 3. TCP 状态速查统计状态：ss -ant | awk 'NR>1 {count[$1]++} END {for (s in count) print s, count[s]}'ss -ant state time-wait | wc -lss -ant state close-wait | wc -lss -antp state close-waitss -antp state established常用状态： 状态 方向 常见含义 LISTEN 服务端 等待连接 SYN-SENT 客户端 已发出 SYN，未收到 SYN-ACK SYN-RECV 服务端 收到 SYN，等待 ACK ESTABLISHED 双向 连接建立 FIN-WAIT-1 主动关闭 已发 FIN CLOSE-WAIT 被动关闭 收到 FIN，应用未关闭 TIME-WAIT 主动关闭 等待旧报文消散 LAST-ACK 被动关闭 等待最后一个 ACK 3.1 TIME_WAIT特征：主动关闭方大量 TIME_WAIT端口多为本机临时端口连接数随短连接创建速率波动判断顺序：先确认业务影响 -> 检查临时端口是否耗尽 -> 应用侧使用连接池和长连接 -> 客户端启用合理的连接复用 -> 扩容或调整业务模型 -> 最后评估内核参数不建议盲目开启 tcp_tw_reuse。Linux 参数语义在不同内核版本有差异，必须先阅读当前内核文档并测试。3.2 CLOSE_WAIT特征：被动关闭方堆积对端已 FIN，本端连接保持 CLOSE_WAIT进程 FD 往往同步增长常见原因： 应用没有关闭 socket； 连接池归还逻辑缺失； 异常分支漏掉清理； 异步回调丢失； HTTP 客户端未消费完响应或未释放对象。排查：ss -antp state close-waitlsof -nP -iTCP -sTCP:CLOSE-WAITls -l /proc/<pid>/fd | wc -l处理点在应用代码。重启只用于止血，根因必须回到资源关闭路径。4. DNS 排查dig www.example.comdig +trace www.example.comdig @8.8.8.8 www.example.com Adig www.example.com AAAAdig www.example.com CNAMEdig -x 203.0.113.10dig +short www.example.comdig +noall +answer www.example.comresolvectl statusresolvectl query www.example.comcat /etc/resolv.confcat /etc/hostssudo tcpdump -i any -nn port 53常见问题： 现象 可能原因 检查 NXDOMAIN 域名不存在或拼写错误 确认域名和权威记录 SERVFAIL DNSSEC、上游异常、递归失败 换 resolver、看 DNSSEC 解析结果旧 缓存未过期 查看 TTL，必要时清缓存 只在某些节点错 本地 resolver 或 hosts 差异 对比 /etc/hosts IPv6 解析正常但连接失败 IPv6 路由不通 ip -6 route 和端口探测 偶发失败 resolver 限流或超时 统计失败率并抓包 应用侧要设置解析超时和重试，不要假设 DNS 永远可用。5. HTTP 与 curlcurl -v http://example.com/curl -v https://example.com/curl -I https://example.com/curl -o /dev/null -s https://example.com/curl --resolve api.example.com:443:192.0.2.10 \ -v https://api.example.com/healthzcurl -x http://proxy.internal:3128 \ -v https://example.com/curl --connect-timeout 2 --max-time 5 \ -v https://example.com/阶段耗时：curl -o /dev/null -s -w '\n\dns=%{time_namelookup}\n\connect=%{time_connect}\n\tls=%{time_appconnect}\n\ttfb=%{time_starttransfer}\n\total=%{time_total}\n\http_code=%{response_code}\n' \ https://example.com/ 指标 覆盖阶段 主要排查 time_namelookup DNS resolver、缓存 time_connect TCP 路由、LB、SYN 丢包 time_appconnect TLS 证书、协商、算法 time_starttransfer 服务端首包 应用排队和后端耗时 time_total 全请求 响应体和传输 常用状态码： 状态码 含义 网络排查方向 301 / 302 / 307 / 308 重定向 跳转次数、协议和路径 400 请求语法错误 客户端参数和编码 401 / 403 认证或授权失败 凭证、WAF、访问控制 404 资源不存在 路由和 upstream 路径 408 请求超时 客户端发送慢 429 限流 限流策略和重试退避 499 客户端主动断开 客户端超时、用户取消 500 / 502 / 503 / 504 服务端或网关错误 upstream、容量、超时 6. TLS 证书排查openssl s_client -connect example.com:443 -servername example.comopenssl s_client -connect example.com:443 -servername example.com \ -showcertsopenssl s_client -connect example.com:443 -servername example.com \ 2>/dev/null | openssl x509 -noout -dates -subject -issueropenssl x509 -in server.crt -noout -dates -subject -issuer \ -ext subjectAltNameopenssl x509 -in server.crt -pubkey -noout | openssl sha256openssl pkey -in server.key -pubout | openssl sha256openssl verify -CAfile ca.crt server.crtopenssl s_client -connect example.com:443 -servername example.com \ -tls1_2openssl s_client -connect example.com:443 -servername example.com \ -tls1_3常见错误： 现象 常见原因 处理 certificate has expired 证书过期 轮换并更新监控 hostname mismatch SAN 不匹配 补齐域名或改 SNI unable to get local issuer certificate 缺中间证书或信任库问题 补全链 私钥不匹配 混用文件 重新绑定 旧客户端失败 协议或算法不兼容 评估兼容策略 只有 SNI 场景失败 未配置默认证书 配置默认或正确 SNI 7. TCP 参数与重传sysctl net.ipv4.ip_local_port_rangesysctl net.core.somaxconnsysctl net.ipv4.tcp_max_syn_backlogsysctl net.ipv4.tcp_syncookiessysctl net.ipv4.tcp_fin_timeoutsysctl net.ipv4.tcp_keepalive_timesysctl net.ipv4.tcp_congestion_controlsysctl net.core.default_qdiscss -tiss -ti dst 10.20.30.40netstat -s | grep -Ei 'retrans|listen|overflow|reset'nstat -az | grep -Ei 'retrans|listen|drop'关键观察： 指标 问题信号 Retrans 持续增长 丢包或 RTT 抖动 LISTEN 队列高 accept 积压 LISTEN overflow 增长 backlog 或应用 accept 慢 SYN 重试多 握手阶段丢包 RST 突增 主动拒绝、进程退出、安全策略 cwnd 长期偏低 拥塞窗口受限 调优必须先定位瓶颈。常见误判是把应用排队、GC 停顿、后端慢或容量不足当成网络问题。8. MTU 与分片ip link show eth0ip link set dev eth0 mtu 1500ping -c 4 -M do -s 1472 10.20.30.40tracepath -n 10.20.30.40ip route get 10.20.30.40常用判断：以太网 MTU 1500IPv4 header 20ICMP header 8不分片最大 ICMP payload = 1500 - 20 - 8 = 1472隧道、VPN、云 overlay 和容器网络可能降低有效 MTU。小包能通、大包卡住时，优先怀疑 MTU 或 PMTUD。排查： 对比两端 MTU； 找路径最小 MTU； 检查 ICMP “fragmentation needed” 是否被丢弃； 检查 overlay 封装开销； 抓包看分片或卡住的字节位置。9. NAT、conntrack 与防火墙sudo iptables -t nat -L -n -vsudo nft list rulesetsudo conntrack -Lsudo conntrack -L -p tcp --state ESTABLISHEDsudo conntrack -Csudo conntrack -Ssysctl net.netfilter.nf_conntrack_maxsysctl net.netfilter.nf_conntrack_countdmesg | grep -i conntrack常见问题： 现象 可能原因 长连接空闲后断开 NAT 或 LB 空闲超时 并发高时新建失败 conntrack 表满 返回包不到应用 会话状态或反向规则 偶发无法访问 SNAT 端口耗尽 安全策略调整后断开 双向路径未同时放通 治理建议： 长连接开启应用层心跳； 监控 conntrack 使用率； 评估 NAT 网关并发和端口； 规则变更前记录会话影响； 云安全组、主机防火墙、CNI 策略分层排查。10. 负载均衡与代理以 Nginx 为例：nginx -tnginx -Tcurl -v http://127.0.0.1/healthztail -f /var/log/nginx/access.logtail -f /var/log/nginx/error.logcurl -v --resolve api.example.com:8080:10.20.30.40 \ http://api.example.com/healthz重点日志字段：request_time Nginx 处理请求总耗时upstream_time upstream 响应耗时upstream_status 后端状态码upstream_addr 实际后端request_length 请求大小bytes_sent 响应大小排障路径：客户端 -> DNS -> CDN / WAF -> LB -> Ingress / Nginx -> upstream -> 数据库或下游每一跳都要能回答： 请求是否到达； 转发到哪个实例； 超时是多少； 错误码是谁产生； 连接是否复用； 是否触发健康检查摘除； 发布或配置是否刚变更。11. CDN 与缓存curl -I https://www.example.com/static/a.jscurl -H 'Cache-Control: no-cache' \ -I https://www.example.com/static/a.jsdig +short www.example.comcurl -w '%{remote_ip}\n' -o /dev/null -s https://www.example.com重点响应头： Header 含义 Cache-Control 缓存策略 Age 对象在边缘已缓存时间 X-Cache 常见命中状态头，具体语义以厂商为准 ETag / Last-Modified 协商缓存 Vary 按请求维度区分缓存 CDN-Cache-Control 部分厂商的边缘缓存策略 排查顺序： 确认用户解析到的边缘节点； 检查回源源站； 检查缓存键是否忽略或包含了错误参数； 检查 Vary 是否导致命中率低； 检查源站是否返回不可缓存状态； 检查证书和 HTTP 协议； 必要时刷新缓存并验证。12. Kubernetes 与 CNI 排障基础检查：kubectl get nodes -o widekubectl get pods -o widekubectl describe pod <pod>kubectl logs <pod> -c <container>kubectl exec -it <pod> -- shkubectl get svc,endpointskubectl get endpointslicekubectl get ingresskubectl get networkpolicykubectl run net-tool --rm -it \ --image=nicolaka/netshoot -- sh容器内探测：ip addrip routecat /etc/resolv.confnc -vz <service-name> <port>curl -v http://<service-name>:<port>/healthz分层判断： 测试 通过含义 Pod IP 直连通 Pod 网络基本可用 Service 名称解析通 DNS 可用 Service ClusterIP 通 服务转发规则可用 NodePort 通 节点转发和外部防火墙可用 Ingress 域名通 入口控制器和证书可用 常见原因： Endpoint 为空：selector、标签、探针或 readiness 不匹配； DNS 失败：CoreDNS、search 域、ndots、Service 命名空间； NetworkPolicy 拒绝：方向、端口、命名空间选择器； CNI 未就绪：节点组件、网段、路由或封装异常； SNAT 或 masquerade 行为不符合预期； conntrack 表满或会话超时； 入口控制器配置或证书错误。13. 抓包过滤器sudo tcpdump -Dsudo tcpdump -i eth0 -nnsudo tcpdump -i any -nnsudo tcpdump -i eth0 -nn host 10.20.30.40sudo tcpdump -i eth0 -nn port 443sudo tcpdump -i eth0 -nn src 10.20.30.40sudo tcpdump -i eth0 -nn dst 10.20.30.40sudo tcpdump -i eth0 -nn \ 'host 10.20.30.40 and (port 80 or port 443)'sudo tcpdump -i eth0 -nn 'tcp[tcpflags] & tcp-syn != 0'sudo tcpdump -i eth0 -nn \ 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn|tcp-ack'sudo tcpdump -i eth0 -nn 'tcp[tcpflags] & tcp-rst != 0'sudo tcpdump -i any -nn port 53sudo tcpdump -i any -nn icmp or icmp6sudo tcpdump -i any -nn arpsudo tcpdump -i any -nn 'net 10.20.0.0/16'sudo tcpdump -i eth0 -nn -s 0 \ 'host 10.20.30.40 and port 443' \ -w /tmp/network.pcap建议控制范围：先选一个接口 -> 加 host / port / net -> 加包数量限制 -c -> 加快照长度限制 -> 输出到 pcap -> 传回分析抓包会包含敏感信息。生产操作要有审批、脱敏、保存期限和最小捕获范围。14. 监控指标基线基础指标： 类型 指标 可用性 成功率、错误率、拨测可用率 延迟 DNS、TCP、TLS、TTFB、P50 / P95 / P99 容量 带宽、PPS、并发连接、新建连接 TCP 重传、RST、队列溢出、窗口 资源 conntrack、网卡丢包、软中断 安全 拒绝数、证书剩余天数、异常流量 入口 upstream 状态、健康检查、5xx 告警要能回答： 哪个域名或服务受影响； 哪个地域和入口节点； 从什么时候开始； 影响多少请求； 是否伴随发布或配置变更； 下一步看哪个面板。15. 网络事故报告模板# 网络事故报告## 1. 摘要- 事故时间：- 恢复时间：- 影响范围：- 影响指标：- 当前状态：## 2. 时间线- 统一使用 UTC 或本地时间：- 每个时间点写事实与证据：- 止血动作：- 根因确认：## 3. 影响评估- 请求量：- 失败率：- 延迟变化：- 用户或商户影响：- 资损评估：## 4. 证据链- DNS：- 路径：- 连接：- 证书：- HTTP：- 抓包：- 配置变更：## 5. 根因- 直接原因：- 促成条件：- 为什么监控没有提前发现：- 为什么防护没有阻止：## 6. 处置评估- 做对的事：- 延误点：- 误判点：- 可自动化点：## 7. 后续行动| 行动 | 负责人 | 截止时间 | 优先级 | 验证方式 ||---|---|---|---|---|## 8. 经验沉淀- 新监控：- 新巡检：- 新预案：- 架构改进：16. 上线前检查清单域名与入口：[ ] DNS TTL 与切换方案已确认[ ] 证书 SAN、证书链和有效期正确[ ] HTTPS 策略已测试[ ] 回源地址和备用入口明确[ ] CDN 缓存键与刷新方案明确超时与重试：[ ] 连接超时、读超时、总超时分层设置[ ] 重试只用于幂等请求[ ] 重试有退避和抖动[ ] 熔断和降级策略明确[ ] 上游最大并发受限负载与容量：[ ] 带宽、PPS、连接数有预算[ ] 健康检查策略正确[ ] 摘流与恢复机制验证[ ] 优雅停机验证[ ] 限流阈值和排队行为明确云原生网络：[ ] NetworkPolicy 意图测试通过[ ] DNS policy 和 search 域确认[ ] CNI 网段与集群规模匹配[ ] conntrack 容量监控[ ] 长连接心跳和空闲超时匹配观测与预案：[ ] 分阶段延迟指标采集[ ] 重传、RST、队列溢出监控[ ] 证书过期告警[ ] 多地域拨测[ ] 抓包和变更审批流程[ ] 回滚与演练记录17. 十分钟排障路径1. 确认影响面：哪个服务、哪个地域、多少用户2. 确认变更：发布、证书、路由、安全组、DNS3. 本机进程：进程在、端口监听、健康检查通过4. 连接路径：DNS -> TCP -> TLS -> HTTP 分层探测5. 跳过入口：直连后端，判断问题在入口还是服务6. 查状态：SYN 积压、CLOSE_WAIT、RST、重传7. 查路径：mtr、MTU、conntrack、防火墙8. 看证据：访问日志、错误日志、抓包、监控9. 止血：回滚、切流、扩容、限流、重启10. 复盘：沉淀监控、预案和自动化检查18. 版本差异提醒 主题 常见差异 ip / ss 老系统可能仍以 ifconfig / netstat 为主 TCP 参数 内核版本、发行版和默认值可能不同 DNS 管理 systemd-resolved、NetworkManager、静态配置并存 防火墙 iptables、nftables、firewalld、云安全组语义不同 CNI overlay、路由、NetworkPolicy 实现差异较大 HTTP 网关和客户端对 HTTP/2、HTTP/3 支持不同 TLS 协议、算法、证书链和 SNI 行为受实现影响 云网络 NAT 网关、LB、弹性网卡能力以厂商文档为准 遇到环境相关行为，优先使用当前环境文档和实验结果，不套用过期结论。
• 这是《计算机网络 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。掌握计算机网络不是背完协议字段，而是能在真实系统中回答：流量从哪里来，路径上有哪里会失败，容量如何评估，延迟如何优化，故障如何止血，安全边界如何设计，并能把证据链讲清楚。35.1 五个成长阶段Level 1 使用者 会 ping、curl、访问服务 | vLevel 2 排障者 能分层定位 DNS、TCP、TLS、HTTP 问题 | vLevel 3 原理掌握者 理解 TCP、UDP、TLS、HTTP、DNS 内部机制 | vLevel 4 架构治理者 能设计 LB、CDN、VPC、安全、容量和监控 | vLevel 5 专家 能读 RFC 和内核实现，优化协议栈和大规模架构每个阶段的核心问题不同。初级问“为什么连不上”，中级问“为什么慢”，高级问“如何设计成不轻易断、断了能恢复、恢复可验证”。35.2 能力矩阵 能力 初级 中级 高级 分层 知道模型 能定位层次 能设计协议边界 TCP 知道握手 会看状态和重传 能治理吞吐与长尾 HTTP 会发请求 懂缓存和幂等 能优化全链路 TLS 会用 HTTPS 能排查证书 能治理 mTLS 和轮换 云网络 会用安全组 能排查 VPC 能设计多地域架构 安全 知道防火墙 能配置策略 能落地零信任 观测 会看日志 会抓包和监控 能建立证据链平台 35.3 必做实验实验一：完整请求拆解dig www.example.comcurl -v https://www.example.comcurl -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' \ -o /dev/null -s https://www.example.com产出：一张请求阶段耗时表。实验二：TCP 状态观察ss -antss -itcpdump -i any 'tcp[tcpflags] & tcp-syn != 0' -nn产出：三次握手、四次挥手、重传和 RST 的抓包分析。实验三：弱网模拟sudo tc qdisc add dev eth0 root netem delay 100ms 20ms loss 1%sudo tc qdisc del dev eth0 root观察 HTTP 耗时、TCP 窗口、重试和熔断。实验四：搭建入口架构Nginx -> 多后端 -> 健康检查 -> draining -> 限流验证发布、摘除、超时和回滚。35.4 项目训练项目一：企业 API 入口功能： HTTPS 和 HTTP/2； 多后端负载均衡； 健康检查； 访问日志； 限流； 灰度路由； 优雅发布。验收：发布期间错误率不上升，真实 IP 可信，P99 有监控。项目二：跨地域网络诊断平台功能： 多地域拨测； DNS 解析； TCP / TLS / HTTP 分阶段耗时； mtr 路径； 证书监控； 告警。产出：可用性视图和故障定位视图。项目三：长连接推送系统功能： WebSocket 服务； 心跳； 断线重连； 连接路由表； Kafka 或 Redis 广播； 慢消费者治理； 集群 draining。验收：单机 10 万连接、广播延迟和内存稳定可测量。35.5 RFC 与文档阅读推荐阅读： 文档 主题 RFC 791 / 2460 / 8200 IPv4 / IPv6 RFC 792 / 4443 ICMP / ICMPv6 RFC 793 / 9293 TCP RFC 768 UDP RFC 1034 / 1035 DNS RFC 7230-7235 或 9110 系列 HTTP 语义 RFC 7540 / 9113 HTTP/2 RFC 9114 HTTP/3 RFC 9000 QUIC RFC 8446 TLS 1.3 阅读方法： 带问题读； 先看 overview 和术语； 手画报文和状态机； 用抓包验证； 记录版本差异； 不假设所有实现完全符合规范。35.6 90 天进阶计划第 1 到 14 天：基础1. 分层模型2. IP / 路由 / ARP / ICMP3. UDP / TCP 基础4. DNS 基础5. curl / ping / mtr / ss产出：命令手册和请求拆解实验。第 15 到 30 天：传输层1. 握手挥手2. 状态机3. 滑动窗口4. 拥塞控制5. 重传和调优产出：TCP 抓包分析报告。第 31 到 50 天：应用层1. HTTP 语义2. HTTPS / TLS3. HTTP/2 / HTTP/34. WebSocket5. 代理与网关产出：入口网关配置和证书轮换流程。第 51 到 70 天：生产架构1. LB / CDN / NAT / VPC2. 网络安全3. 云原生网络4. 容量和延迟优化产出：架构评审模板。第 71 到 90 天：进阶1. 内核网络栈2. IO 模型3. 服务网格4. 压测和混沌5. RFC 阅读产出：压测报告和故障演练记录。35.7 长期习惯 每次问题画出路径； 每个结论给证据； 每个优化给前后指标； 每个变更加回滚； 每个故障沉淀监控； 每季度演练入口切换； 持续跟踪协议演进； 把常用排障命令产品化。35.8 职业方向后端工程师重点：连接池、超时、幂等、HTTP 语义、RPC、长连接。SRE / 运维工程师重点：DNS、LB、证书、VPC、监控、抓包、容量和故障演练。平台工程师重点：网关、服务网格、CNI、网络策略、自动化诊断。性能工程师重点：内核网络栈、epoll、io_uring、零拷贝、拥塞控制和压测。安全工程师重点：TLS、mTLS、零信任、WAF、DDoS、审计和策略治理。本章小结从 0 到大师的路径是：会使用、会排障、懂协议、能治理架构、能读 RFC 和内核实现。持续成长来自实验、项目、压测、故障复盘和文档阅读。最终目标是形成自己的网络方法论：分层定位、证据优先、路径可视化、容量有预算、故障可演练、安全有边界。思考题 评估你当前处于哪个阶段，列出三个短板。 用抓包解释一次 TCP 连接的完整生命周期。 设计一个多地域网络拨测平台。 为团队制定网络故障复盘模板。 写下未来 90 天的实验计划和可验证产出。
• 这是《计算机网络 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。计算机网络面试最怕“名词都听过，追问三层就断”。本章按答题框架整理高频问题：先给出核心答案，再补常见追问和易错点。34.1 答题框架回答网络问题时使用四步：1. 定位层次：物理、链路、网络、传输、应用2. 讲机制：协议怎么工作3. 讲取舍：解决了什么，付出了什么4. 讲实践：如何验证和排障例如被问 TCP 和 UDP 区别，不要只列表格，可以补充：UDP 适合实时场景但可靠性转移到应用层，QUIC 就是基于 UDP 实现可靠流和拥塞控制的例子。34.2 分层与地址问题 1：OSI 七层和 TCP/IP 模型有什么区别？OSI 是理论分层：物理、链路、网络、传输、会话、表示、应用。TCP/IP 更接近工程实现，常简化为应用、传输、网络、链路、物理。加分点： TLS 在严格分层中常归为表示层安全能力，工程上放在应用层讨论； QUIC 基于 UDP，却在用户态实现传输层能力； 分层的价值是职责边界和排障定位，而不是僵化教条。问题 2：MAC 地址和 IP 地址的区别？ 地址 层 作用 MAC 链路层 同一局域网内标识接口 IP 网络层 跨网络全局寻址和路由 跨网段通信时，目的 IP 通常保持不变，下一跳 MAC 逐跳变化。问题 3：ARP 工作流程是什么？查缓存 -> 未命中广播 ARP Request -> 目标主机回复 ARP Reply -> 写入缓存并封装帧追问：跨网段访问时 ARP 请求谁？通常请求网关，而不是最终目标服务器。34.3 TCP 与 UDP问题 4：为什么 TCP 三次握手？三次握手用于： 同步双方初始序列号； 确认双方收发能力； 防止历史 SYN 造成错误连接； 协商 MSS、窗口缩放、SACK 等选项。两次无法确认服务端发送和客户端接收能力，也无法可靠完成序列号同步。问题 5：为什么四次挥手？TCP 全双工，两个方向分别关闭。被动方收到 FIN 后可能还要发送数据，因此 ACK 和 FIN 可以分开。问题 6：TIME_WAIT 过多怎么办？TIME_WAIT 出现在主动关闭方，用于等待旧报文消失和保证最后 ACK。优先处理： 连接复用； HTTP Keep-Alive； 数据库和 RPC 连接池； 降低重试频率。易错点：不要盲目使用端口重用，更不要复活 tcp_tw_recycle。问题 7：CLOSE_WAIT 过多说明什么？CLOSE_WAIT 出现在被动关闭方，表示对端已关闭但本方应用没有调用 close。通常是连接泄漏，应排查响应体关闭、异常 finally、连接池生命周期和线程阻塞。问题 8：TCP 如何保证可靠？机制： 序列号和确认号； 超时重传； 快速重传； SACK； 滑动窗口； 校验和； 连接状态管理； 拥塞控制。追问：TCP 可靠是否等于业务可靠？不等于。请求可能处理失败，重试可能重复，应用仍需要超时、幂等和业务确认。问题 9：流量控制和拥塞控制区别？rwnd：保护接收方cwnd：保护网络send window = min(rwnd, cwnd)慢启动指数增长，拥塞避免线性增长，丢包后窗口下降。CUBIC 和 BBR 的差异要能说出：CUBIC 以丢包为核心信号，BBR 估算瓶颈带宽和最小 RTT。问题 10：UDP 为什么不可靠，为什么 QUIC 还用它？UDP 无连接、不确认、不排序、不流控，但延迟低、实现简单、易于用户态演进。QUIC 在 UDP 之上实现可靠流、流级别独立交付、TLS 1.3、连接迁移和可插拔拥塞控制。34.4 HTTP 与 HTTPS问题 11：GET 和 POST 的区别？GET 语义是读取资源，安全且幂等；POST 语义是创建或执行动作，不保证幂等。GET 可以被缓存和预取，POST 通常需要幂等键才能安全重试。易错点：URL 长度限制来自浏览器和服务器实现，不是 HTTP 协议本身定义的固定值。问题 12：401 和 403 的区别？401 是未认证或认证无效；403 是身份已知但没有权限。问题 13：什么是 HTTPS？HTTPS 是 HTTP over TLS，提供身份认证、机密性和完整性。核心流程：证书链校验 -> 密钥交换 -> 协商对称密钥 -> 加密应用数据TLS 1.3 通常 1 RTT，支持 0-RTT，但 0-RTT 有重放风险。问题 14：SNI 和 ALPN 分别是什么？SNI 在 ClientHello 中告诉服务器要访问的域名，用于单 IP 多证书选择。ALPN 协商应用协议，例如 h2、http/1.1、h3。问题 15：HTTP/2 解决了什么问题？二进制分帧、流多路复用、HPACK 头部压缩和连接级/流级流量控制。它解决了 HTTP 层请求排队和头部重复问题，但仍有 TCP 层队头阻塞。问题 16：HTTP/3 为什么基于 QUIC？QUIC 基于 UDP，实现： 流独立交付，减少传输层队头阻塞； 集成 TLS 1.3； 连接迁移； 0-RTT； 用户态快速迭代。部署需要 UDP 443、客户端、CDN、LB 和防火墙支持。34.5 DNS 与 CDN问题 17：DNS 解析流程是什么？本地缓存 -> Stub Resolver -> Recursive DNS -> Root -> TLD -> Authoritative常见追问：TTL 如何影响切换？TTL 越短切换越快，但递归查询压力越大。生产切换前应先降 TTL。问题 18：CDN 为什么能加速？ 就近接入； 边缘缓存； TLS 终止和连接复用； 内部骨干网回源； 吸收攻击流量。追问：动态接口能否缓存？不能直接缓存，但可以通过就近接入、链路优化和连接复用做动态加速，需实测。34.6 架构与生产问题 19：四层和七层负载均衡区别？L4 基于 IP 和端口转发，性能高但语义少；L7 基于 HTTP 路径、Header、Cookie、域名路由，可做灰度、重写、限流和鉴权。问题 20：X-Forwarded-For 如何安全使用？只有可信代理链设置的值可信。入口代理必须覆盖外部传入值，后端按可信代理跳数解析真实 IP。问题 21：偶发请求超时如何排查？先拆分：DNS / TCP / TLS / TTFB / transfer再看： mtr 丢包和延迟； ss -i RTT 和重传； LB upstream 耗时； 后端线程池和日志； 安全策略和容量； 是否重试风暴。问题 22：大包卡住小包正常说明什么？优先怀疑 MTU / MSS / PMTUD 问题，尤其在 VPN、overlay、容器和专线场景。ping -M do -s 1472 <target>tracepath <target>问题 23：NAT 端口耗尽怎么办？原因是大量短连接访问同一个目标且五元组不可复用。处理是连接池、长连接、降低重试、拆分 NAT 网关或 EIP、多目标域名和限流。问题 24：epoll 为什么适合大量连接？epoll 通过事件通知避免 select/poll 的全量线性扫描，且大量空闲连接不会带来每轮扫描成本。常见模型是主从 Reactor。追问：非阻塞 read 返回 EAGAIN 怎么办？注册读事件并返回，不能忙轮询。34.7 场景题场景 1：某地区用户访问慢排查： 用户运营商和地区； DNS 调度结果； CDN 节点和命中率； mtr 路径； TLS 和 TTFB； 后端地域部署； 其他地区对比。处理： 切换 CDN； 调整调度； 回源链路； 开启就近接入； 客户端重试备用域名。场景 2：服务发布期间 502检查： readiness； preStop； 优雅关闭； LB 摘除延迟； 长连接 draining； 连接池刷新； 健康检查路径。场景 3：WebSocket 半小时断开常见原因是 LB、NAT 或防火墙空闲超时。应让应用心跳间隔小于最短空闲超时，并设置服务端读空闲、客户端重连和退避。34.8 高频易错点 TCP 可靠代表请求成功：不准确； TIME_WAIT 是异常：不一定，短连接场景常见； ping 不通代表服务不可用：可能禁 ICMP； HTTPS 绝对安全：仍需证书治理、授权和 WAF； CDN 缓存所有请求：私有数据不能公共缓存； HTTP/2 完全消除队头阻塞：只消除 HTTP 层，TCP 层仍存在； 内网默认可信：零信任下不成立； 连接数越大越好：会带来内存、调度和容量风险； DNS 权重调度精确：受缓存和 Local DNS 位置影响； 平均延迟代表体验：长尾更关键。本章小结网络面试应先定位层次，再讲机制、取舍和生产验证。TCP 重点掌握握手挥手、状态机、可靠传输、流量和拥塞控制；HTTP 重点掌握语义、幂等、缓存、TLS、HTTP/2 和 HTTP/3；生产题要能拆延迟、看路径、抓证据并给出止血与长期方案。思考题 为什么三次握手不能是两次？ TIME_WAIT 和 CLOSE_WAIT 分别如何治理？ HTTP/2 和 HTTP/3 的队头阻塞差异是什么？ 如何安全获取客户端真实 IP？ 把一次线上网络故障整理成面试案例。
• 这是《计算机网络 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。网络架构评审是在方案进入生产前，系统性检查流量路径、容量、故障域、安全边界、可观测性和演进成本。评审的目标不是否定新方案，而是让风险提前暴露，并让每个取舍有记录。33.1 评审输入方案必须提供： 业务场景和流量模型； 峰值 QPS、带宽和连接数； 用户地域分布； SLO 和错误预算； 网络拓扑图； IP 和端口规划； DNS 和证书方案； 安全边界； 监控指标； 失败场景； 回滚方案； 成本估算。没有流量模型的架构评审容易变成画框图游戏。33.2 流量路径评审南北向路径：User -> DNS / HTTPDNS -> CDN / WAF -> Cloud LB -> Ingress / Gateway -> Service -> Dependency东西向路径：App -> Order -> MySQL -> Redis -> Kafka -> External API检查： 每一跳协议； 超时和重试； 连接复用； 加密方式； 真实 IP 传递； 请求 ID 传递； 熔断降级； 单点； 容量； 故障传播。33.3 故障域设计 层级 故障域 机架 电力、交换机 可用区 网络分区、机房故障 地域 大面积灾难 云账号 权限、配额、管控 DNS 解析服务 证书 CA、轮换流程 专线 单链路 依赖 第三方 API 要求： 至少两个入口； 后端多可用区； 数据层主备或多数派； 客户端重试和本地降级； 跨地域方案明确 RPO / RTO； 切换流程可演练； 避免所有副本同时进入维护。33.4 容量评审估算：入口带宽 = 峰值 QPS × 平均请求响应大小 × 重试系数并发连接 = 峰值 QPS × 平均处理时间TLS 握手 = 新建连接速率NAT 连接 = 外呼并发和新建速率DNS QPS = 客户端数量和缓存策略预留： 峰值系数； 故障接管； 重试放大； 发布窗口； 攻击余量； 一年增长； 监控和日志流量。容量不满足时的方案： CDN 和缓存； 压缩和分页； 连接复用； 水平扩容； 分区域接入； 限流降级； 升级带宽。33.5 安全评审检查： 数据库和中间件是否暴露公网； 安全组是否最小授权； 管理入口是否经过堡垒机； 是否强制 HTTPS； 证书如何轮换； 内部高敏链路是否 TLS / mTLS； 服务身份和授权； WAF 和 Anti-DDoS； 日志是否泄露敏感数据； 网络变更是否有审计。网络可达不等于应该可达。每个端口都应有 owner 和业务理由。33.6 可观测性评审每个组件必须能回答：我是谁？流量从哪里来？去向哪里？成功率多少？延迟多少？当前容量水位？失败原因是什么？如何回滚？数据源： DNS 解析日志； CDN / WAF 日志； LB 访问日志； Gateway 访问日志； 应用 trace； VPC Flow Log； conntrack 指标； TCP 状态和重传； 证书监控； 带宽和包量。告警要覆盖： 可用性； P99 延迟； 错误率； DNS 失败率； 证书有效期； 后端健康； 带宽水位； 连接耗尽； 安全事件； 切换事件。33.7 变更与回滚网络变更要求： 变更单； 影响面； 前置检查； 分步执行； 验证命令； 停止条件； 回滚脚本； 负责人； 通知对象； 变更后观察期。高风险变更： DNS 切换； 证书更换； 防火墙规则； 路由表； LB 配置； CNI 升级； 专线切换； 安全组批量调整。33.8 评审清单[ ] 有完整流量路径图[ ] 南北向和东西向协议明确[ ] 峰值 QPS、带宽、连接数已估算[ ] DNS TTL 和切换方案明确[ ] CDN 缓存和刷新策略明确[ ] LB 健康检查和 draining 明确[ ] 超时、重试、幂等、熔断闭环[ ] 无单点[ ] 多可用区部署[ ] 安全组最小授权[ ] TLS / mTLS 策略明确[ ] 证书自动轮换[ ] 客户端真实 IP 可信[ ] 全链路 trace ID 贯通[ ] VPC Flow Log / 访问日志留存[ ] 带宽和连接告警就绪[ ] 故障切换演练计划[ ] 回滚方案和负责人明确33.9 评审结论结论应包含： 结论 含义 通过 满足要求，可进入实施 有条件通过 补齐指定项后可实施 不通过 存在重大容量、安全或可用性风险 需要降级方案 先小范围灰度 每项风险应记录：风险描述：影响：概率：缓解措施：验证方式：负责人：截止时间：本章小结架构评审应从流量模型和完整路径出发，检查容量、故障域、安全、可观测性、变更和回滚。高质量评审输出的是风险清单、取舍记录和可执行改进项，而不是简单批准或否决。网络方案的最终标准是：故障时可控，增长时可扩，攻击时有边界，排障时有证据。思考题 架构评审为什么必须先看流量模型？ 如何识别网络路径上的单点？ 容量估算为什么要包含重试放大和故障接管？ 网络变更的停止条件应如何设计？ 为一个新公网 API 服务写完整网络架构评审单。
• 这是《计算机网络 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。网络测试的目的是验证容量、延迟、稳定性和故障行为，而不是得到一份好看的最大 QPS。完整测试应覆盖带宽、RTT、丢包、建连、TLS、HTTP 语义、长连接、重试和故障切换。32.1 测试目标先定义问题：1. 系统目标 QPS 是多少？2. P99 / P999 延迟预算是多少？3. 峰值持续多久？4. 允许错误率是多少？5. 单连接还是多连接？6. 请求体和响应体多大？7. 用户分布在哪里？8. 故障时如何降级？测试类型： 类型 目标 基准测试 建立当前性能基线 容量测试 找到安全容量水位 压力测试 观察过载行为 浸泡测试 发现泄漏和衰减 尖峰测试 验证突发和弹性 混沌测试 验证故障切换 32.2 指标必须采集： QPS； 并发数； 错误率； P50 / P95 / P99 / P999； 连接建立耗时； TLS 耗时； 首包耗时； 响应大小； 带宽； 重传； CPU / 内存 / fd； 服务端队列； 下游耗时； LB 状态。不要只看平均延迟。平均 100ms 可能意味着 95% 请求 5ms，5% 请求 2s。32.3 带宽与延迟测试iperf3：iperf3 -siperf3 -c <server> -t 30iperf3 -c <server> -u -b 500M -t 30iperf3 -c <server> -P 8 -t 30路径质量：ping -c 100 <target>mtr -rw -c 200 <target>注意： 单 TCP 连接受 RTT 和窗口影响； -P 8 多流测试更接近总容量； UDP 测试需控制速率并观察丢包； 测试流量可能触发安全策略； 云实例带宽常有规格限制。32.4 HTTP 压测wrk：wrk -t8 -c500 -d60s --latency \ -s post.lua https://api.example.com/api/orderspost.lua：wrk.method = "POST"wrk.body = '{"userId":10001,"skuId":20001}'wrk.headers["Content-Type"] = "application/json"hey：hey -z 60s -c 500 -m POST \ -H "Content-Type: application/json" \ -d '{"userId":10001}' \ https://api.example.com/api/ordersk6：import http from 'k6/http';import { check, sleep } from 'k6';export const options = { stages: [ { duration: '1m', target: 100 }, { duration: '3m', target: 500 }, { duration: '1m', target: 0 } ], thresholds: { http_req_duration: ['p(99)<300'], http_req_failed: ['rate<0.01'] }};export default function () { const res = http.get('https://api.example.com/api/orders'); check(res, { 'status is 200': r => r.status === 200 }); sleep(0.1);}32.5 测试脚本要点 使用生产相似路径长度； 请求参数有分布，避免全部命中一个缓存； 响应体大小接近真实； 认证 token 处理过期； 写接口必须可清理； 压测客户端单独部署； 逐步加压； 每轮之间恢复基线； 记录版本和配置； 不在未授权环境压测。压测客户端瓶颈： CPU 不足； 临时端口耗尽； fd 不足； DNS 慢； TLS 握手过重； 日志写入阻塞； 连接数不足。32.6 延迟统计陷阱协调遗漏固定速率压测工具会测量“发起的请求”，但系统卡顿时，普通客户端可能等待后才发起新请求，从而低估真实排队延迟。应使用固定速率工具并记录目标发送时间。时钟跨机器测量必须确认时间同步，否则耗时可能出现负数或异常漂移。冷热差异冷缓存、JIT、连接池预热、TLS session、CPU 频率调度都会影响首轮结果。长尾来源P999 可能来自： GC； 重传； 慢磁盘； 锁等待； 重试； 某个坏节点； 特定用户数据； 定时任务。32.7 故障注入tc netem：tc qdisc add dev eth0 root netem delay 100ms 20ms loss 1%tc qdisc change dev eth0 root netem delay 200mstc qdisc del dev eth0 root验证： 客户端超时； 重试预算； 幂等性； 熔断； 降级； 告警； 恢复。其他注入： 断开后端； 证书替换为过期； DNS 返回错误； 丢包； 带宽限速； 节点重启； 可用区故障。32.8 报告模板测试目标：环境：版本：拓扑：数据规模：测试工具：加压模型：持续时间：QPS：错误率：P50 / P95 / P99 / P999：平均响应大小：带宽：CPU：内存：连接数：重传：瓶颈判断：异常现象：安全容量：建议：风险：复测计划：安全容量通常不是最大 QPS，而是满足 SLO 并保留故障接管余量的水位。32.9 测试流程1. 明确 SLO2. 准备环境和数据3. 建立监控基线4. 小流量验证正确性5. 逐步加压6. 观察拐点和错误7. 重复测试8. 浸泡测试9. 故障注入10. 输出容量结论11. 设置告警和扩容规则本章小结网络测试要覆盖带宽、RTT、丢包、TCP、TLS、HTTP、长连接和故障切换，指标必须看分位数、错误率和资源水位。iperf3 适合链路容量，wrk/hey/k6 适合 HTTP 压测，tc netem 和混沌工具验证弱网与故障行为。压测结论要给出安全容量，而不是短暂峰值。思考题 为什么最大 QPS 不等于安全容量？ 单连接和多连接吞吐测试有什么区别？ 平均延迟为什么会掩盖长尾问题？ 什么是协调遗漏？ 设计一次跨可用区入口故障切换演练。
• 这是《计算机网络 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。网络容量决定最多能承载多少流量，延迟决定用户体感和分布式系统正确性。优化目标不是让单个 curl 达到极限速度，而是让 P99、P999、错误率和成本同时满足 SLO。31.1 延迟分解一次 HTTPS 请求：DNS+ TCP connect+ TLS handshake+ request upload+ server processing+ response transfer+ client render= total latency测量：curl -o /dev/null -s -w \ 'dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n' \ https://www.example.com不要只看平均耗时，还要看： P50； P95； P99； P999； max； 错误率； 时间序列； 分地域分布。31.2 带宽与吞吐理论传输时间：transfer time = response size / bandwidth实际还受： TCP 慢启动； RTT； 丢包； 拥塞窗口； 单连接或多连接； 服务端处理； 队列； 中间设备限速。优化： 压缩； 减少响应字段； 分页； CDN； 增量加载； 合并请求； 并行下载； 断点续传； 就近部署。31.3 RTT 与请求轮次跨地域 RTT 示例：同城 1ms跨城 30ms跨洲 150ms一次跨洲 HTTPS 首次请求可能至少：DNS + TCP 1RTT + TLS 1RTT + 请求响应 1RTT优化： 长连接； TLS 会话恢复； HTTP/2 多路复用； HTTP/3； CDN； 就近接入； 批量接口； 预取； 合并依赖。31.4 缓存缓存层级：浏览器 -> Service Worker -> CDN -> 网关 -> 应用本地缓存 -> Redis -> MySQL设计： 静态资源内容哈希； HTML 协商缓存； 接口按变化频率分级； 私有数据禁止公共缓存； 缓存 key 明确； 失效策略可验证； 缓存命中率监控； 防雪崩和击穿。31.5 压缩 算法 特点 gzip 兼容性好 br 压缩率更高，浏览器支持广 zstd 高压缩率，适合服务间或新生态 适合压缩： JSON； HTML； CSS / JS； 日志批量传输。不适合： 已压缩图片和视频； 小响应体； 高 CPU 紧张场景未评估时； 流式响应需确认压缩缓冲影响。31.6 连接复用短连接成本：TCP 握手 -> TLS 握手 -> 慢启动 -> 请求 -> 关闭复用方式： HTTP Keep-Alive； HTTP/2； gRPC 长连接； 数据库连接池； Redis 连接池； 内部 RPC 连接池。注意： 空闲时间小于中间设备超时； 借出前健康检查； 最大连接数； 泄漏检测； 优雅关闭； DNS 地址刷新； 负载再平衡。31.7 并发与批量减少延迟：串行：A 100ms -> B 100ms -> C 100ms，总 300ms并发：A / B / C 同时执行，总约 100ms但并发会带来： 下游压力； 线程切换； 连接池竞争； 锁竞争； 带宽放大； 失败扇出。批量适合： 数据库批量查询； 缓存 MGET； 消息批量发送； 日志聚合； 外部 API 合并。批量需要限制： 批大小； 请求体大小； 失败重试粒度； 超时时间； 内存占用。31.8 服务端处理优化网络优化不能掩盖服务端问题： 线程池队列； 数据库慢查询； 下游重试风暴； GC 停顿； 锁竞争； CPU 热点； 缓存穿透； 大对象序列化； 日志阻塞； 连接池耗尽。要建立服务分层耗时：gateway latencyservice latencydb latencyexternal latency31.9 容量模型入口容量：所需带宽 = 峰值 QPS × 平均响应体 + 平均请求体 + 协议开销所需并发 = 峰值 QPS × 平均处理时间连接容量 = 应用实例数 × 每实例连接上限预留： 峰值系数； 故障接管容量； 重试放大； 广播和推送； 备份与同步流量； 安全攻击余量； 发布期间的容量。31.10 优化决策优先顺序：1. 明确 SLO 和当前瓶颈2. 消除明显错误和重试风暴3. 减少请求轮次4. 缓存和压缩5. 连接复用6. 就近部署7. 协议升级8. 架构拆分不要为了几毫秒引入复杂系统。每次优化都应有： 优化前指标； 变更范围； 优化后指标； 成本变化； 风险和回滚； 长期监控。本章小结延迟优化要拆分 DNS、TCP、TLS、服务处理和传输耗时，并关注分位数和地域差异。常见手段是减少请求轮次、缓存、压缩、批量、并发、连接复用、CDN 和就近部署。容量规划必须考虑峰值、重试放大、故障接管、发布窗口和攻击余量。思考题 一次 HTTPS 请求的延迟包含哪些部分？ 为什么跨地域系统要减少请求轮次？ 连接复用需要注意哪些超时问题？ 如何评估响应压缩的收益？ 写一个 API P99 从 800ms 到 200ms 的优化方案。
• 这是《计算机网络 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。Kubernetes 把网络抽象为 Pod、Service、Endpoint、Ingress、NetworkPolicy 和 DNS，但底层由 CNI、内核路由、iptables/eBPF、overlay 或 underlay 实现。云原生网络故障往往横跨 Pod、Node、CNI、kube-proxy、CoreDNS、安全组和云路由。30.1 Pod 网络要求：每个 Pod 有独立 IP同 Node Pod 可直接通信跨 Node Pod 可直接通信NetworkPolicy 可控制访问常见路径：Pod eth0 -> veth pair -> Node bridge / router -> CNI 插件 -> underlay 或 overlay查看：kubectl get pod -o widekubectl exec -it <pod> -- ip addrkubectl exec -it <pod> -- ip route30.2 CNI 模式 模式 代表 特点 Overlay Flannel VXLAN、Calico IP-in-IP 配置简单，有封装开销 路由 Calico BGP 性能好，依赖路由能力 云网络 Terway、Cilium ENI、VPC CNI 使用 VPC IP，受配额影响 eBPF Cilium 内核可编程，策略能力强 选择要评估： Pod 密度； IP 地址规划； 网络性能； NetworkPolicy 能力； 云平台配额； 运维复杂度； 混合云连通。30.3 Service 与 kube-proxyService 提供稳定虚拟 IP：apiVersion: v1kind: Servicemetadata: name: orderspec: selector: app: order ports: - port: 80 targetPort: 8080转发模式： 模式 特点 iptables 常见，规则多时更新慢 IPVS 适合大量 Service eBPF 内核可编程，路径更短 查看：kubectl get svc,endpointslice -o widekubectl get endpointsliceiptables-save | grep <service>ipvsadm -LnEndpoint 为空的常见原因： selector 不匹配； Pod 不 Ready； 端口名不一致； targetPort 错； readiness 失败； EndpointSlice controller 异常。30.4 CoreDNSService DNS：order.prod.svc.cluster.local排查：kubectl run dns-test --rm -it --image=busybox -- shnslookup order.prod.svc.cluster.localcat /etc/resolv.conf查看 CoreDNS：kubectl -n kube-system get pods -l k8s-app=kube-dnskubectl -n kube-system logs deploy/coredns常见问题： Pod /etc/resolv.conf 错； ndots 导致额外查询； CoreDNS 副本不足； 上游 DNS 异常； Headless Service 解析 Pod IP； 服务名命名空间错误； DNS 节点缓存或 NetworkPolicy 拦截。30.5 Ingress 与 GatewayIngress 提供七层入口：apiVersion: networking.k8s.io/v1kind: Ingressmetadata: name: apispec: rules: - host: api.example.com http: paths: - path: / pathType: Prefix backend: service: name: api port: number: 80入口设计：Cloud LB -> Ingress Controller / Gateway -> Service -> Pod关注： 证书和 SNI； Websocket 超时； 客户端真实 IP； 重试和幂等； 连接数； 请求体大小； 灰度路由； 健康检查； 控制器多副本； 配置验证。30.6 NetworkPolicy默认无策略时 Pod 可自由通信。生产应默认拒绝，再放行明确路径：apiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata: name: default-denyspec: podSelector: {} policyTypes: [Ingress, Egress]排障：kubectl get networkpolicy -Akubectl exec -it <pod> -- nc -vz <service> <port>注意： CNI 必须支持策略； 入站和出站分开判断； DNS 出口不能忘记； namespaceSelector 和 podSelector 组合容易写错； 策略顺序由选择器决定； 策略变更需要版本化。30.7 Pod 网络排障从 Pod 访问 Service 失败：kubectl get pod -o widekubectl get svc,endpointslicekubectl exec -it <pod> -- ip routekubectl exec -it <pod> -- nc -vz <pod-ip> <port>kubectl exec -it <pod> -- nc -vz <svc-name> <port>路径：1. 目标 Pod Ready2. EndpointSlice 存在3. Pod IP 可达4. targetPort 正确5. Service 转发规则存在6. DNS 正确7. NetworkPolicy 放行8. 应用监听 0.0.0.09. 云安全组放行30.8 常见故障Pod 之间不通查 CNI、节点路由、MTU、NetworkPolicy、安全组。Service 偶发超时查 conntrack、Endpoint 变化、kube-proxy 模式、Pod 重启、应用慢。DNS 慢查 CoreDNS 负载、ndots、缓存、上游 DNS、监控。外部访问失败查 LB、Ingress 证书、Host、后端 Ready、安全组、控制器配置。大包失败小包成功优先查 overlay MTU、CNI 配置、PMTUD。发布期间 502查 readiness、preStop、优雅关闭、Endpoint 摘除和 LB 缓存。30.9 容量规划指标： Pod 数； Service 数； Endpoint 数； 每秒新建连接； 南北向带宽； 东西向带宽； NetworkPolicy 数量； CoreDNS QPS； Ingress QPS； conntrack 用量。容量风险： IP 地址耗尽； 云网卡配额； iptables 规则过多； CoreDNS CPU 不足； Ingress 带宽不足； 节点 conntrack 满； overlay CPU 过高。本章小结云原生网络由 Pod 网络、CNI、Service、EndpointSlice、kube-proxy、CoreDNS、Ingress 和 NetworkPolicy 组成。排障应从目标 Pod、Endpoint、Service 转发、DNS、策略和云安全组逐层推进。容量上要关注 Pod IP、Service 数量、conntrack、CoreDNS QPS、Ingress 带宽和 CNI 性能。思考题 Kubernetes 对 Pod 网络有哪些基本要求？ Service 和 EndpointSlice 的关系是什么？ Overlay 网络为什么需要特别关注 MTU？ Endpoint 为空如何排查？ 设计一个多团队共享 Kubernetes 集群的网络策略。
• 这是《计算机网络 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。服务网格把服务间通信的认证、加密、路由、重试、熔断、限流和观测从业务代码下沉到基础设施。常见形态是应用旁挂 Sidecar 代理，流量先经过出站代理，再进入对端入站代理，业务进程通常不直接感知这些策略。29.1 为什么需要服务网格微服务的通信治理需求： 服务发现； 负载均衡； TLS / mTLS； 重试； 超时； 熔断； 限流； 灰度路由； 链路追踪； 流量镜像。SDK 模式的问题： 多语言重复实现； 升级依赖业务发版； 策略分散； 故障排查边界不清； 框架和业务耦合。网格把通用能力放在代理和控制面。29.2 Sidecar 流量劫持以 Istio + Envoy 为例：App A -> iptables / eBPF 劫持 -> Envoy A outbound -> mTLS -> Envoy B inbound -> App B控制面：Istiod -> 服务发现 -> 证书签发 -> 配置分发数据面：Envoy -> 实际转发 -> 执行路由和策略29.3 mTLS工作流程： 控制面为工作负载签发证书； 客户端 Sidecar 发起连接； 双方校验证书； 证书中身份对应 Service Account； 授权策略基于身份判断； 证书自动轮换。价值： 防冒充； 加密链路； 服务身份； 细粒度授权； 审计调用双方。注意：mTLS 只解决链路和身份，不代替业务授权。29.4 流量治理常见规则： 能力 示例 超时 请求 500ms 失败 重试 5xx 重试 2 次 熔断 错误率 50% 摘除 限流 每秒 1000 QPS 故障注入 1% 延迟 5s 灰度 10% 流量到 v2 镜像 复制流量到测试版本 区域感知 优先同 AZ 原则： 默认不盲目重试； 重试预算必须有总超时； 连接池和 outlier bounds 要设置； 策略变更可灰度； 观测配置生效版本； 避免多层代理重复重试。29.5 Sidecar 生命周期启动： Pod 创建； Sidecar 注入； Envoy 初始化； 监听端口就绪； 劫持规则生效； 配置同步； 应用开始收发流量。关闭： Pod 进入 Terminating； Endpoint 摘除； 拒绝新请求； 等待存量请求； Sidecar 最后退出； 应用进程退出。如果应用先退出而 Sidecar 仍在收请求，会出现 503；如果 Sidecar 先退出而应用仍外呼，外呼会失败。新版 Kubernetes Sidecar 生命周期和网格配置可以缓解，但要按集群版本验证。29.6 性能影响成本： 每跳增加两个代理； mTLS 握手和加解密 CPU； 连接劫持开销； 内存占用； 配置分发规模； 可观测数据量。优化： 控制平面分域； 减少不必要规则； 合理设置日志采样； 连接复用； 只在需要链路启用 mTLS； 使用轻量代理； 评估 Ambient Mesh / eBPF 形态； 为代理设置资源上限。29.7 排障命令：istioctl proxy-statusistioctl proxy-config listener <pod>.<namespace>istioctl proxy-config cluster <pod>.<namespace>istioctl proxy-config route <pod>.<namespace>istioctl proxy-config log <pod>.<namespace> --level debug抓包：kubectl exec -it <pod> -c istio-proxy -- \ tcpdump -i any -nn port 8080 -w /tmp/debug.pcapEnvoy 状态：kubectl exec -it <pod> -c istio-proxy -- \ curl localhost:15000/clusters常见问题： 现象 排查 503 UC 上游连接失败、健康状态 mTLS 握手失败 证书、策略、身份 路由不生效 版本标签、规则优先级 偶发超时 重试叠加、后端慢 发布失败 Sidecar 生命周期 配置不一致 proxy-status、pilot 版本 29.8 是否使用服务网格适合： 多语言服务多； 统一 mTLS 和授权需求强； 流量治理复杂； 服务数量大； 需要灰度和流量镜像； 平台团队具备运维能力。不适合： 服务数量少； 团队无法承担复杂度； 延迟和资源极度敏感； SDK 已统一且稳定； 缺少观测和排障能力； 只是为了“看起来更云原生”。本章小结服务网格通过数据面代理和控制面配置，把服务发现、mTLS、路由、重试、熔断和观测从业务代码下沉到基础设施。Sidecar 模式带来统一治理能力，也增加延迟、资源、生命周期和排障复杂度。是否引入应基于服务规模、多语言需求、安全合规和平台能力，而不是流行程度。思考题 服务网格和 SDK 治理的边界是什么？ Sidecar 模式如何劫持应用流量？ mTLS 中的服务身份来自哪里？ Sidecar 启动和退出顺序会导致什么问题？ 写一份服务网格灰度接入和回滚方案。
• 这是《计算机网络 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。Socket 是应用访问网络的编程接口，IO 模型决定了应用如何等待和搬运数据。阻塞 IO 简单但并发成本高，IO 多路复用适合大量连接，异步 IO 进一步减少等待和复制开销。28.1 Socket APITCP 客户端：import socketclient = socket.socket(socket.AF_INET, socket.SOCK_STREAM)client.settimeout(3)client.connect(("10.20.1.10", 9000))client.sendall(b"hello\n")print(client.recv(4096))client.close()UDP：import socketsock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)sock.settimeout(2)sock.sendto(b"hello", ("10.20.1.10", 9000))print(sock.recvfrom(4096))常用选项： 选项 作用 SO_REUSEADDR 重启时快速绑定地址 SO_KEEPALIVE TCP 保活 TCP_NODELAY 关闭 Nagle SO_SNDBUF / SO_RCVBUF 缓冲区 SO_LINGER close 行为 O_NONBLOCK 非阻塞 28.2 阻塞 IOread() -> 没有数据就等待 -> 有数据复制到用户态并返回适合： 连接数少； 逻辑简单； 内部低并发任务； 每连接一个线程成本可接受。问题： 连接数增加，线程增多； 上下文切换增加； 慢连接占用线程； 阻塞点难治理； 故障时线程池耗尽。28.3 非阻塞 IOread() -> 没有数据返回 EAGAIN -> 应用稍后再试或注册事件非阻塞解决“等待”问题，但仍需事件通知机制知道什么时候读。28.4 IO 多路复用 模型 特点 select 跨平台，fd 数量和效率受限 poll 无 select 数量限制，仍线性扫描 epoll Linux 事件通知，适合大量空闲连接 kqueue BSD/macOS 事件通知 适合： 大量连接； 大部分连接不完全活跃； 单机网关、推送、代理； 长连接服务。注意： 惊群问题； 事件循环阻塞； 边缘触发漏读； 写事件需要动态注册； 仍需业务线程池隔离。28.5 信号驱动与异步 IO信号驱动 IO：内核准备好人通知应用应用自己调用 read 复制数据异步 IO：应用提交请求内核完成等待和复制通过回调或完成队列通知Linux 的 io_uring 提供高效异步 IO，适合高 PPS、文件与网络混合 IO 的场景，但编程复杂度更高。28.6 Java NIO 与 NettyJava NIO：Selector selector = Selector.open();SocketChannel channel = SocketChannel.open();channel.configureBlocking(false);channel.register(selector, SelectionKey.OP_CONNECT | SelectionKey.OP_READ | SelectionKey.OP_WRITE);Netty 在 NIO 之上封装了： EventLoopGroup； ChannelPipeline； ByteBuf； 编解码器； 空闲检测； 背压； 内存池； 优雅关闭。业务代码不应把耗时操作放在 EventLoop 中，否则会阻塞该 EventLoop 上所有 Channel。28.7 缓冲与消息边界读取到 ByteBuf：readableBytesreaderIndexwriterIndexcapacity自定义协议：| Length | Payload |解码时必须处理： 半包； 粘包； 帧超长； 非法长度； 拆包攻击； 解压后大小。28.8 IO 与业务隔离EventLoop: accept / read / write / codecBusiness Pool: 数据库、RPC、计算External Pool: 第三方调用好处： 慢业务不影响 IO； 线程池可独立观测； 不同依赖可独立隔离； 故障不扩散； 容量更可预测。每个池必须有： 最大线程； 有界队列； 拒绝策略； 执行耗时； 队列长度； 活跃数； 失败数。28.9 模型选择 场景 推荐模型 管理工具、低并发 阻塞 IO + 线程池 Web 服务 框架异步或线程池 网关 / 代理 epoll + Reactor 长连接推送 epoll + 业务池 高性能存储 io_uring / SPDK 等专用方案 简单内网调用 同步 RPC 先满足正确性和可观测性，再引入复杂模型。本章小结Socket 提供网络编程接口，阻塞 IO 简单但并发扩展性差，非阻塞 IO 需要事件机制，epoll 和 Reactor 支撑大量连接，io_uring 提供异步 IO 能力。生产代码要处理消息边界、读写事件、慢业务隔离、有界队列和背压。模型选择应基于连接数、请求耗时和团队维护能力。思考题 阻塞 IO 的主要扩展瓶颈是什么？ select、poll 和 epoll 的差异是什么？ 非阻塞 read 返回 EAGAIN 后应用应该做什么？ 为什么耗时业务不能放在 EventLoop？ 设计一个自定义 TCP 协议的解码器状态机。
• 这是《计算机网络 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。应用发送一个字节到网卡收到数据，中间会经历系统调用、协议栈、路由、Netfilter、qdisc、DMA、硬中断、软中断和协议解析。理解内核网络栈，才能解释 softirq 高、丢包、队列延迟、conntrack 满和 CPU 分布不均。27.1 接收路径网卡收到帧 -> DMA 到 RX Ring Buffer -> 硬中断 -> NAPI 轮询 -> 软中断 NET_RX -> IP 层 -> Netfilter / Conntrack -> TCP / UDP -> Socket Receive Queue -> 应用 read()关键点： Ring Buffer 大小有限； 硬中断只做通知，处理在软中断； NAPI 在高负载下从中断切换到轮询； 应用读取慢会造成 socket 队列堆积； conntrack 会增加每包成本； softnet 丢包说明 CPU 来不及处理。查看：cat /proc/interruptscat /proc/net/softnet_statethtool -S eth027.2 发送路径应用 write() -> Socket Send Buffer -> TCP 分段 -> IP 路由 -> Netfilter -> QDisc -> NIC TX Ring -> 网卡发送如果发送缓冲满，write 可能阻塞或返回 EAGAIN，取决于文件描述符模式。查看：ss -itc -s qdisc show dev eth0ethtool -S eth027.3 NAPINAPI 是中断和轮询的混合机制：低流量：中断驱动，延迟低高流量：关闭或减少中断，批量轮询，减少 CPU 开销收益： 减少每个包一次中断的开销； 批量处理描述符； 提升高包量吞吐；调优通常不是直接修改 NAPI，而是关注： RSS 队列； 中断亲和； Ring Buffer； softnet 分布； 协议处理 CPU。27.4 RSS 与中断亲和RSS 将流量哈希到多个网卡队列：NIC RX Queue 0 -> CPU 0NIC RX Queue 1 -> CPU 1NIC RX Queue 2 -> CPU 2NIC RX Queue 3 -> CPU 3查看队列：ethtool -l eth0查看中断：grep eth0 /proc/interruptscat /proc/irq/<irq>/smp_affinity_list问题： 只有单队列，单核 softirq 高； 中断集中在少数 CPU； 队列数超过业务需要； NUMA 跨节点访问； 云实例规格限流。可配合 RPS / RFS 将包调度到其他 CPU：cat /sys/class/net/eth0/queues/rx-0/rps_cpus27.5 QDiscQDisc 是内核流量调度队列。查看：tc qdisc showtc -s qdisc show dev eth0常见： QDisc 特点 fq_codel 控制队列延迟 fq 公平队列，配合 BBR pfifo_fast 先进先出 tbf 限速 htb 层级带宽控制 生产可用 tc 做备份限速或测试，但大规模策略应由云网络、CNI 或专用网关管理。27.6 Netfilter 与 conntrackNetfilter 钩子：PREROUTINGINPUTFORWARDOUTPUTPOSTROUTINGconntrack 记录连接状态：src=10.0.1.10 dst=1.2.3.4 sport=50000 dport=443 state=ESTABLISHED查看：cat /proc/sys/net/netfilter/nf_conntrack_countcat /proc/sys/net/netfilter/nf_conntrack_maxconntrack -S高并发容器宿主机要监控： conntrack count； insert failed； drop； table full； 新建连接速率； 空闲超时。27.7 常用观测工具系统层：mpstat -P ALL 1vmstat 1watch -d cat /proc/net/softnet_stat网络层：ss -sss -antpss -instat -aznetstat -s追踪工具： 工具 用途 tcpdump 包级事实 bpftrace 内核函数追踪 perf CPU 热点和软中断 ethtool 网卡统计和队列 biolatency / biosnoop 存储侧排查 27.8 调优原则先定位：丢包发生在哪里？CPU 忙在哪里？队列堆积在哪里？延迟来自哪里？再行动： softnet 丢包：增加队列、调整 RSS、优化应用； Ring Buffer 溢出：适度增大，同时关注延迟； conntrack 满：扩容或减少连接； 中断集中：设置亲和； 应用读取慢：优化 IO 模型； 带宽打满：限流或扩容； 队列延迟：更换 qdisc； 云实例限流：升级规格。本章小结Linux 网络栈接收路径经过网卡 DMA、硬中断、NAPI、软中断、协议栈、Netfilter 和 socket 队列；发送路径经过 socket 缓冲、协议栈、QDisc 和网卡队列。softnet、Ring Buffer、RSS、中断亲和、conntrack 和 qdisc 是内核层排障重点。调优必须基于丢包位置和 CPU 热点，而不是盲目改参数。思考题 硬中断和软中断在网络收包中分别负责什么？ NAPI 为什么能降低高流量下的 CPU 开销？ conntrack 表满会造成什么？ fq_codel 对缓冲膨胀有什么帮助？ 写一份高 PPS 宿主机的内核网络观测清单。
• 这是《计算机网络 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。网络故障排查的原则与数据库和系统排查相同：先确认影响面，再保存现场，沿路径分层定位，优先止血，事后复盘。本章把 DNS、TCP、TLS、HTTP、LB、云网络、MTU、丢包和带宽问题整理成可执行手册。26.1 通用流程1. 确认影响范围：用户、地域、运营商、接口、实例2. 确认时间线：开始时间、变更、峰值、恢复时间3. 分层定位：DNS、TCP、TLS、HTTP、应用4. 保存现场：curl、mtr、ss、tcpdump、日志5. 止血：切流、限流、扩容、回滚、降级6. 恢复验证：成功率、P99、连接、错误码7. 根因分析8. 固化监控和预案先问影响面： 现象 优先怀疑 只有某个用户不通 客户端本地网络 某地区不通 运营商、DNS、CDN 某服务不通 LB、安全组、进程 某实例不通 实例路由、网卡、监听 全站不通 入口 DNS、LB、专线 偶发超时 丢包、重传、队列、容量 26.2 快速命令集基础连通：ping <target>mtr -rw -c 100 <target>traceroute -T -p 443 <target>curl -v --connect-timeout 3 https://<target>本地网络：ip -brief addrip routeip ruleip neighss -ntp接口与丢包：ip -s linkethtool -S eth0cat /proc/net/softnet_statDNS：dig <domain>dig @8.8.8.8 <domain>dig +trace <domain>证书：openssl s_client -connect <host>:443 -servername <host>耗时拆解：curl -o /dev/null -s -w \ 'dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n' \ https://<target>26.3 场景一：域名解析失败现象：could not resolve hostNXDOMAINSERVFAIL排查：cat /etc/resolv.confdig @127.0.0.53 <domain>dig @8.8.8.8 <domain>dig @<authoritative-dns> <domain>判断： 本机 resolver 异常； 公共 DNS 正常，运营商异常； 权威异常； 域名过期； NS 委托错误； AAAA 返回但 IPv6 不可用。止血： 切换 resolver； 临时 hosts； 切换备用域名； 多 CDN 或多入口切流； 恢复权威记录。26.4 场景二：TCP 连接失败现象：Connection refusedConnection timed outNo route to host排查：ss -lntpnc -vz <host> <port>traceroute -T -p <port> <host>tcpdump -i any host <host> and port <port> -nn区分： 报错 常见含义 Connection refused 可达但端口未监听或被拒绝 Connection timed out 包被丢弃、路由错误、防火墙丢包 No route to host 本机或中间路由不可达 Network unreachable 无默认路由或错误接口 检查： 服务监听 0.0.0.0 还是 127.0.0.1； 安全组； NACL； 系统防火墙； 路由表； 后端健康状态； 监听队列； conntrack 表。26.5 场景三：TLS 握手失败现象：certificate verify failedSSL handshake failedprotocol version排查：openssl s_client -connect <host>:443 -servername <host>curl -v https://<host>常见原因： 证书过期； 缺中间证书； SAN 不匹配； SNI 未配置； TLS 版本不兼容； Cipher Suite 不匹配； 客户端信任库过旧； LB 证书配置错误。止血： 更新证书链； 回滚证书变更； 切换备用入口； 客户端紧急更新信任库； 临时兼容旧协议需安全评审。26.6 场景四：请求超时或 P99 毛刺先拆耗时：DNSTCP connectTLSfirst bytecontent transfer可能原因： DNS 慢； 高 RTT； 丢包重传； 带宽打满； LB 队列； 后端线程池满； 数据库慢； GC 停顿； 重试风暴； 单机故障。排查：curl -w ...mtr -rw -c 100 <target>ss -inetstat -s | grep -i retrans结合应用指标判断： 如果 DNS 阶段高，查 resolver； 如果 connect 高，查网络和队列； 如果 TLS 高，查握手和证书； 如果 TTFB 高，查服务处理； 如果 transfer 高，查响应体和带宽。26.7 场景五：丢包定位：mtr -rw -c 200 <target>ping -c 100 <target>ip -s linkethtool -S eth0常见原因： 链路质量； 带宽拥塞； 队列丢弃； 云性能限流； 安全策略丢包； conntrack 满； 网卡缓冲不足； 单路径 ECMP 异常。处理： 切换链路或入口； 限流大流量任务； 扩容带宽； 调整队列和缓冲； 修复 conntrack； 联系云厂商； 客户端重试和降级。26.8 场景六：MTU 黑洞现象： ping 小包通； TCP 握手成功； 大请求或大响应卡住； TLS 握手停在证书阶段； VPN、overlay、专线环境明显。排查：ping -M do -s 1472 <target>tracepath <target>tcpdump -i any 'icmp[icmptype] == 3 and icmp[icmpcode] == 4' -nn处理： 放行 PMTUD ICMP； 统一 MTU； 配置 MSS Clamp； 调整 overlay 封装开销； 评估 TCP MTU probing。26.9 场景七：负载均衡异常现象： 502 / 503 / 504； 部分后端不可用； 流量倾斜； 发布期间错误率上升。排查：LB 访问日志后端访问日志健康检查状态后端监听安全组upstream connect timeupstream response time处理： 摘除故障后端； 修复健康接口； 回滚发布； 扩容； 调整超时； 关闭放大重试； 恢复 draining。26.10 场景八：NAT 或 conntrack 异常现象： 外呼偶发失败； 新建连接失败； 宿主机高并发容器受影响； 日志 conntrack full； NAT 网关连接数高。排查：cat /proc/sys/net/netfilter/nf_conntrack_countcat /proc/sys/net/netfilter/nf_conntrack_maxconntrack -L | grep <ip>处理： 长连接复用； 降低重试频率； 增大 conntrack； 缩短超时； 拆分 NAT 网关； 分布实例； 优化安全组规则。26.11 场景九：带宽打满现象： 丢包重传； 延迟升高； 小请求受大文件影响； 备份窗口集中。排查：iftopnethogstc -s qdisc show dev eth0云监控看： 入口带宽； 出口带宽； NAT 网关带宽； 包量； LB 带宽； CDN 回源。处理： 限速备份； 错峰任务； 扩容带宽； CDN 静态化； 压缩响应； 隔离流量； 切流备用链路。26.12 事故报告模板标题：时间：影响：发现方式：时间线：现象证据：排查路径：根因：触发条件：止血动作：恢复验证：为什么没有提前发现：改进项：负责人：截止时间：改进项必须具体，例如“外呼客户端统一启用连接池并将最大空闲时间设置为 LB 超时的 80%”，而不是“加强网络意识”。本章小结网络故障排查要先确认影响面和时间线，再按 DNS、路由、TCP、TLS、HTTP、LB、云网络和应用逐层定位。常用证据包括 ip、ss、mtr、dig、curl、openssl、tcpdump、LB 日志和 VPC Flow Log。常见故障包括解析失败、连接失败、证书错误、丢包、MTU 黑洞、NAT 端口耗尽、conntrack 满、带宽打满和发布 draining 不当。思考题 为什么偶发超时要先拆分 curl 各阶段耗时？ Connection refused 和 timed out 有什么区别？ 如何证明问题发生在客户端、网络还是服务端？ MTU 黑洞的典型证据是什么？ 为一次线上外呼偶发失败写排查流程和监控指标。
• 这是《计算机网络 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。当日志、监控和链路追踪都无法解释“包到底有没有到、协议说了什么”时，抓包是最接近事实的证据。抓包能回答连接是否发起、握手卡在哪一步、谁发送了 RST、是否存在重传、窗口是否为零、DNS 返回了什么、TLS 证书是否匹配。25.1 抓包准备先明确四件事：1. 在哪一端抓：客户端、服务端、LB、中间节点2. 抓哪个接口：eth0、any、VPN、容器 veth3. 过滤什么：IP、端口、协议、方向4. 输出到哪里：文件、滚动文件、实时管道基础命令：tcpdump -Dip linktcpdump -i eth0 -nn host 10.20.1.10tcpdump -i any -nn port 443建议始终使用 -nn，避免 IP 和端口反向解析拖慢抓包。25.2 常用 BPF 过滤# IPtcpdump -i eth0 -nn host 10.20.1.10tcpdump -i eth0 -nn src 10.20.1.10tcpdump -i eth0 -nn dst 10.20.1.10tcpdump -i eth0 -nn net 10.20.0.0/16# 端口tcpdump -i eth0 -nn port 8080tcpdump -i eth0 -nn src port 443tcpdump -i eth0 -nn dst port 53# 协议tcpdump -i eth0 -nn icmptcpdump -i eth0 -nn udp port 53tcpdump -i eth0 -nn arp# TCP 标志tcpdump -i eth0 -nn 'tcp[tcpflags] & tcp-syn != 0'tcpdump -i eth0 -nn 'tcp[tcpflags] & tcp-rst != 0'tcpdump -i eth0 -nn 'tcp[tcpflags] & tcp-fin != 0'组合：tcpdump -i eth0 -nn host 10.20.1.10 and port 443tcpdump -i eth0 -nn host 10.20.1.10 and not port 2225.3 输出文件tcpdump -i eth0 -nn port 443 -w /tmp/debug.pcaptcpdump -r /tmp/debug.pcap -nn限制包大小和数量：tcpdump -i eth0 -nn port 443 -s 128 -c 10000 -w debug.pcap滚动抓包：mkdir -p /var/log/tcpdumptcpdump -i eth0 -nn port 443 \ -C 100 -W 10 -w /var/log/tcpdump/debug.pcap含义： -s 128：每个包最多抓 128 字节； -c 10000：最多抓 10000 个包； -C 100：单文件约 100MB； -W 10：最多保留 10 个滚动文件。25.4 tcpdump 输出解读TCP 握手：10.0.1.10.50000 > 10.20.1.10.443: Flags [S]10.20.1.10.443 > 10.0.1.10.50000: Flags [S.]10.0.1.10.50000 > 10.20.1.10.443: Flags [.]含义： 标志 含义 S SYN S. SYN + ACK . ACK P PSH F FIN R RST 如果只看到 S 和 S.，没有最后一个 ACK，客户端侧可能异常；如果只有 S 没有响应，则包未到达或被丢弃。25.5 Wireshark 分析常用功能： Statistics -> Summary； Statistics -> Conversations； Statistics -> IO Graph； Follow TCP Stream； Follow TLS Stream； Expert Information； Display Filter； Protocol Hierarchy。常用显示过滤：ip.addr == 10.20.1.10tcp.port == 443tcp.flags.reset == 1tcp.analysis.retransmissiontcp.analysis.zero_windowtcp.analysis.duplicate_ackdns.qry.name == "www.example.com"tls.handshake.type == 1http.response.code >= 500推荐排障顺序：1. Summary 看时间范围、包数、丢包2. Conversations 找异常地址和流量3. IO Graph 看时间和速率4. Expert Information 看重传、零窗口、异常5. Follow Stream 看完整交互25.6 重传分析过滤：tcp.analysis.retransmissiontcp.analysis.fast_retransmissiontcp.analysis.duplicate_ack判断： 少量重传：偶发丢包，不一定影响业务； 集中重传：链路质量、拥塞、队列丢包； 一侧发送但无 ACK：回程路径或接收方异常； 握手阶段重传：建连被丢弃； TLS 后重传：网络质量或中间设备干扰； 同一连接大量重传：单路径问题。进一步看：mtr -rw -c 100 <target>ss -i dst <target>ethtool -S eth025.7 RST 分析过滤：tcp.flags.reset == 1常见来源： 端口未监听； 服务崩溃； 应用主动 reset； 防火墙拒绝； LB 摘除后端； 连接队列溢出； 空闲超时； keepalive 失败。抓包特征：客户端发 SYN服务端直接回 RST通常优先查端口监听和安全策略。连接正常建立一段时间后服务端回 RST优先查服务异常、超时策略和连接关闭逻辑。25.8 DNS 抓包tcpdump -i eth0 -nn udp port 53 -w dns.pcapWireshark 过滤：dns.qry.name contains "example"dns.flags.response == 1dns.flags.rcode != 0关注： 查询是否发出； resolver 是否响应； 返回 A 还是 AAAA； TTL 是多少； 是否 CNAME 链； rcode 是否 NXDOMAIN / SERVFAIL； 响应耗时。25.9 TLS 抓包TLS 内容加密，但仍能看到： ClientHello； SNI； ALPN； TLS 版本和 Cipher Suites； 证书链长度； Alert 消息； 握手耗时。过滤：tls.handshake.type == 1tls.record.content_type == 21常见 Alert： Alert 含义 certificate_expired 证书过期 bad_certificate 证书无效 unknown_ca CA 不受信任 handshake_failure 算法或 SNI 不匹配 protocol_version 版本不兼容 如需解密应用数据，客户端可导出 TLS Key Log，但必须在授权和隐私允许时操作。25.10 抓包注意事项 生产抓包先评估流量和磁盘； 只抓必要过滤条件； 使用滚动文件； 包文件可能包含敏感数据； 传输前脱敏或加密； 高流量机器优先在边缘或目标连接抓； 双端抓包更容易判断丢包方向； -i any 在不同系统上链路层表现不同； 容器网络要进入正确 namespace 或抓 veth； 记录抓包时间、机器、接口和过滤条件。本章小结tcpdump 用 BPF 精确采集包，Wireshark 用统计、专家信息、显示过滤和 Follow Stream 还原交互过程。抓包能定位握手卡点、RST 来源、重传、零窗口、DNS 响应、TLS Alert 和延迟层次。生产抓包必须控制范围、大小、留存和隐私。思考题 为什么抓包时推荐 -nn？ SYN 只发不回说明什么？ 如何用 Wireshark 找重传和零窗口？ TLS 加密后还能看到哪些信息？ 写一份生产授权抓包操作流程。
• 这是《计算机网络 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。高性能网络服务的关键不是把参数调到最大，而是让 IO、线程、内存、协议和背压协同工作。单机从 C10K 到 C100K、C1M，需要理解 Socket、IO 多路复用、Reactor 模型、零拷贝、连接池、池化和队列治理。24.1 Socket 编程基础TCP 服务端流程：socket -> bind -> listen -> accept -> read / write -> closePython 示例：import socketserver = socket.socket(socket.AF_INET, socket.SOCK_STREAM)server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)server.bind(("0.0.0.0", 9000))server.listen(1024)while True: conn, addr = server.accept() with conn: data = conn.recv(4096) conn.sendall(b"ack\n")该示例一次只能处理一个连接。并发模型需要多进程、多线程或 IO 多路复用。24.2 阻塞与非阻塞 模式 读写行为 适合 阻塞 没数据时等待 简单、低并发 非阻塞 没数据立即返回 EAGAIN 事件驱动 非阻塞必须搭配事件循环：while True: events = wait(readable_or_writable_fds) handle(events)否则会忙轮询浪费 CPU。24.3 IO 多路复用 机制 特点 select fd 数量有限，线性扫描 poll 无 1024 限制，仍线性扫描 epoll Linux，事件通知，适合大量连接 kqueue BSD / macOS IOCP / IO_URING 不同平台的异步 IO 机制 epoll 示例：int epfd = epoll_create1(0);struct epoll_event event;event.events = EPOLLIN | EPOLLET;event.data.fd = listen_fd;epoll_ctl(epfd, EPOLL_CTL_ADD, listen_fd, &event);while (1) { struct epoll_event events[1024]; int n = epoll_wait(epfd, events, 1024, -1); for (int i = 0; i < n; i++) { handle_event(events[i]); }}边缘触发必须读到 EAGAIN，水平触发可以在每次可读时读一次。24.4 Reactor 模型单 Reactor：Event Loop -> accept -> read -> decode -> business -> encode -> write主从 Reactor：Main Reactor：accept -> 分发连接Sub Reactor 1：IO 事件Sub Reactor 2：IO 事件Worker Pool：耗时业务设计原则： IO 线程不做慢业务； 耗时任务投递业务线程池； 避免锁竞争热点； 每连接状态独立； 写出必须处理 EAGAIN； 有界队列和背压； 优雅关闭。24.5 Netty 示例EventLoopGroup boss = new NioEventLoopGroup(1);EventLoopGroup workers = new NioEventLoopGroup();try { ServerBootstrap bootstrap = new ServerBootstrap(); bootstrap.group(boss, workers) .channel(NioServerSocketChannel.class) .option(ChannelOption.SO_BACKLOG, 1024) .childOption(ChannelOption.TCP_NODELAY, true) .childHandler(new ChannelInitializer<SocketChannel>() { @Override protected void initChannel(SocketChannel ch) { ch.pipeline().addLast(new LineBasedFrameDecoder(4096)); ch.pipeline().addLast(new StringDecoder()); ch.pipeline().addLast(new EchoServerHandler()); } }); ChannelFuture future = bootstrap.bind(9000).sync(); future.channel().closeFuture().sync();} finally { boss.shutdownGracefully(); workers.shutdownGracefully();}EchoServerHandler：public class EchoServerHandler extends SimpleChannelInboundHandler<String> { @Override protected void channelRead0( ChannelHandlerContext ctx, String message) { ctx.writeAndFlush("ack:" + message + "\n"); }}24.6 内存与零拷贝传统文件发送：磁盘 -> 内核页缓存 -> 用户缓冲 -> Socket 缓冲 -> 网卡零拷贝：sendfile磁盘 -> 内核页缓存 -> 网卡Java 示例：FileChannel fileChannel = FileChannel.open(path);fileChannel.transferTo(0, fileChannel.size(), socketChannel);收益： 减少内核与用户态复制； 降低 CPU； 减少内存分配； 提升大文件吞吐。24.7 序列化与协议 协议 特点 JSON 可读，体积较大 Protobuf 二进制，跨语言，高效 FlatBuffers 支持零拷贝访问 自定义 TCP 协议 灵活，需要处理粘包 长度前缀协议：| Magic | Version | Type | Length | Payload |必须限制： 最大帧长度； 最大头部长度； 字段长度； 嵌套深度； 解压后大小。24.8 背压与过载保护请求链路：网络事件 -> IO 线程 -> 有界任务队列 -> 业务线程池 -> 下游连接池过载策略： 策略 语义 Reject 快速失败 Drop 丢弃可丢消息 Latest 只保留最新值 Shed 按用户或优先级丢弃 Degrade 降级非核心逻辑 Throttle 限流 没有背压时，入口速度超过处理速度会导致内存上涨、GC 停顿、超时和雪崩。24.9 单机容量评估指标： QPS； 并发连接； 每秒新建连接； 请求体大小； 响应体大小； P99 处理耗时； CPU； 内存； 网卡带宽； 后端依赖延迟。简化计算：并发 = QPS × 平均处理时间线程数 ≈ CPU 核数 × (1 + 等待时间 / 计算时间)示例：QPS 10000平均处理 20ms并发请求数 ≈ 10000 × 0.02 = 200如果实际连接远高于该值，可能存在长连接、慢消费者或空闲连接。24.10 调优清单[ ] 监听 backlog 足够[ ] accept 和 IO 不做耗时业务[ ] 使用有界队列[ ] 每连接发送缓冲有限制[ ] 慢消费者被断开或降级[ ] 解析器限制消息大小[ ] TCP_NODELAY 按低延迟场景开启[ ] 连接池上限和借出超时明确[ ] 优雅启动与关闭[ ] 监控 fd、线程、队列、GC、重传本章小结高性能网络编程通过非阻塞 IO、epoll、Reactor、线程池、零拷贝和高效序列化提升单机能力。核心工程约束是背压：每一段队列、线程池、连接池和发送缓冲都必须有上限。容量评估要同时看 QPS、并发、请求大小、CPU、内存、带宽和下游延迟。思考题 阻塞 IO 为什么难以支撑大量并发连接？ 主从 Reactor 如何分离 accept 和 IO？ 边缘触发为什么必须读到 EAGAIN？ sendfile 减少了哪些复制？ 设计一个网关的线程池、队列和连接池容量方案。
• 这是《计算机网络 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。网络安全的目标不是安装一个防火墙，而是控制访问面、保护传输链路、识别异常流量、减少爆炸半径并让所有动作可审计。云原生环境下，安全边界从机房网络延伸到 VPC、子网、安全组、容器策略、服务间认证和 API 授权。23.1 安全边界模型传统边界模型：Internet -> Firewall -> DMZ -> Internal Network现代零信任思路：任何访问默认不信任 -> 身份认证 -> 设备与环境评估 -> 最小授权 -> 持续校验 -> 审计网络分区示例：Public Subnet：LB / 堡垒机App Subnet：无状态服务Data Subnet：MySQL / Redis / KafkaMgmt Subnet：运维与监控原则： 数据层不暴露公网； 按职责划分子网； 安全组最小放行； 入口统一治理； 内部服务也认证； 权限和链路可审计。23.2 防火墙与安全组Linux 防火墙工具：iptables -L -nnft list rulesetfirewall-cmd --list-allufw status verbose状态策略： 默认拒绝入站； 明确放行业务端口； 管理端口只允许堡垒网段； 出站也按需限制； 记录拒绝日志； 定期审计规则； 变更走自动化。云安全组：入站：TCP 443 from 0.0.0.0/0入站：TCP 22 from 10.10.0.0/16出站：按业务目标限制安全组应该是角色模板，而不是每台机器随机复制。23.3 加密与传输安全 场景 建议 公网 HTTP 强制 HTTPS 内部敏感通信 TLS 或 mTLS 数据库 TLS 按安全等级启用 消息队列 TLS 和认证 VPN 使用现代协议和强认证 证书 自动轮换和监控 内部网络不等于可信网络。跨机房、跨云、容器平台和服务间通信都应评估加密需求。23.4 认证与授权网络层： VPN 认证； 堡垒机； IP 白名单； mTLS。应用层： OAuth2 / OIDC； JWT； API Key； 签名； RBAC / ABAC； 服务身份。建议： 身份代替 IP 作为主要信任依据； token 短有效期； 刷新令牌安全存储； 服务账户独立； 最小授权； 权限审计； 高危操作二次确认。23.5 常见攻击与防护SYN Flood利用大量半连接耗尽队列。防护： SYN Cookie； 增大队列； 限速； 上游清洗； 监控 SYN_RECV。sysctl net.ipv4.tcp_syncookiesDDoS类型： 类型 特征 流量型 带宽被打满 协议型 TCP / UDP / ICMP 异常 应用层 HTTP 慢速或高频请求 防护： CDN / Anti-DDoS； 限流； 黑白名单； 验证码或挑战； 弹性扩容； 降级非核心功能； 与云厂商联动。ARP 欺骗同二层网络中伪造 ARP Reply。通过 VLAN、端口安全、DAI 和 TLS 降低风险。DNS 劫持与污染防护： DNSSEC； DoH / DoT； 多 resolver； 关键域名监控； 解析结果校验。中间人攻击防护： 强制 HTTPS； mTLS； HSTS； 不忽略证书错误； 关键客户端谨慎评估证书固定。23.6 Web 安全与网络层配合WAF 可以处理： SQL 注入特征； XSS 特征； 路径穿越； 扫描器； 恶意 UA； 高频访问； 大包异常。WAF 不能替代应用安全： 参数化查询； 输出编码； CSRF token； 权限校验； 文件上传治理； 依赖升级； 安全开发流程。Nginx 基础防护：limit_req_zone $binary_remote_addr zone=api:10m rate=100r/s;location /api/ { limit_req zone=api burst=200 nodelay; proxy_pass http://app;}23.7 容器与 Kubernetes 网络安全要点： NetworkPolicy 默认拒绝； 命名空间隔离； Pod 只访问必要服务； 服务间 mTLS； Ingress TLS； 出口流量治理； NodePort 不随意暴露； 镜像仓库私有化； API Server 安全组限制； 审计网络策略变更。NetworkPolicy 思路：apiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata: name: allow-api-to-orderspec: podSelector: matchLabels: app: order policyTypes: [Ingress] ingress: - from: - podSelector: matchLabels: app: api ports: - protocol: TCP port: 808023.8 VPN 与堡垒机VPN： 使用强认证； 按用户授权子网； 会话超时； 双因素认证； 审计访问； 拆分隧道策略明确； 及时回收账号。堡垒机： 统一入口； 身份认证； 授权目标； 命令审计； 录屏或会话日志； 高危命令拦截； 密钥不落个人机器。23.9 网络安全监控必须采集： 数据 用途 VPC Flow Log 内外流量审计 防火墙日志 拒绝和放行 WAF 日志 攻击和误拦 DNS 日志 异常域名 LB 日志 状态码和来源 TLS 监控 证书和协议版本 连接指标 SYN、新建、并发 带宽指标 DDoS 和异常外发 告警： 单 IP 高频请求； 异常 User-Agent； 源站直接访问； 新增防火墙规则； 安全组大规模变更； 证书临近过期； 出口流量突增； 内网横向扫描； 管理端口公网暴露； 未知服务监听。23.10 安全审计清单[ ] 数据库 / Redis / Kafka 不暴露公网[ ] 管理端口仅堡垒网段可访问[ ] 安全组按角色最小授权[ ] HTTPS 强制并开启 HSTS[ ] 证书自动轮换[ ] 内部高敏链路启用 TLS / mTLS[ ] VPN 和堡垒机双因素认证[ ] WAF 和限流策略有效[ ] NetworkPolicy 默认拒绝[ ] VPC Flow Log / WAF / DNS 日志留存[ ] 高危网络变更有审批和回滚本章小结网络安全要从边界控制走向零信任：网络分区和安全组缩小访问面，TLS 和 mTLS 保护传输，身份认证和最小授权控制访问，WAF、Anti-DDoS 和限流抵御攻击，VPC Flow Log、LB 日志和 DNS 日志支撑审计。云原生环境还必须治理 NetworkPolicy、服务间身份和出口流量。思考题 为什么内部网络不应默认可信？ 安全组和应用层授权分别解决什么问题？ SYN Flood 的原理和防护是什么？ WAF 为什么不能替代参数化查询？ 设计一套生产 VPC 的网络分区和安全组策略。
• 这是《计算机网络 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。CDN 把静态资源、动态请求和计算能力放到离用户更近的边缘节点，目标是降低延迟、减少回源、提升可用性和吸收攻击流量。CDN 的效果取决于缓存命中率、内容可缓存性、刷新策略、回源控制和监控。22.1 CDN 架构用户 -> Local DNS /智能调度 -> 边缘节点 Edge -> 中间层 Mid -> 源站 Origin边缘节点： 就近缓存内容； 终止 TLS； 压缩和优化； 回源； 防护攻击； 记录访问日志。22.2 调度方式 方式 说明 DNS 调度 根据 Local DNS 位置返回边缘 IP HTTP DNS 客户端直接请求调度服务，减少运营商劫持 Anycast 同一 IP 广播到多个地域，按路由就近接入 302 调度 先返回调度中心，再跳转边缘 Local DNS 位置可能不等于用户真实位置，因此调度结果不总是最优。22.3 缓存命中请求到达边缘：命中缓存 -> 直接返回未命中 -> 中间层或源站指标： 指标 含义 命中率 命中请求占比 回源率 需要请求源站的比例 回源带宽 源站压力 边缘响应时间 用户侧首包 源站响应时间 回源耗时 状态码分布 4xx / 5xx / 304 命中率低的原因： URL 参数变化； Cache-Control 不允许缓存； Cookie 影响缓存 key； 资源版本变化； 边缘节点容量不足； 用户分布太散； 频繁刷新； 动态接口被误判为静态。22.4 缓存策略静态资源：Cache-Control: public, max-age=31536000, immutable文件名使用内容哈希：app.a1b2c3.jsstyle.d4e5f6.cssHTML：Cache-Control: no-cache接口：Cache-Control: private, no-storeCDN 可能支持忽略或包含 query string，但必须与业务语义一致。带用户 ID、时间戳或随机数的资源不能被公共缓存错误复用。22.5 刷新与预热刷新：让边缘缓存失效。URL 刷新：指定资源立即失效目录刷新：批量失效预热：发布前主动拉取到边缘发布流程：1. 上传新静态资源，文件名带新 hash2. 验证新资源可访问3. 发布新 HTML 引用新资源4. 按需预热热门资源5. 观察命中率和错误率6. 保留旧资源一段时间不要依赖“发布后刷新全部目录”作为常规流程，容易造成回源风暴。22.6 回源控制配置： 回源 Host； 回源协议； 回源超时； 回源重试； 回源跟随 301 / 302； 回源认证； 回源Range； 源站 IP 或负载均衡。常见问题： 回源 Host 错误，源站返回 404； 源站证书不匹配； 回源超时小于源站处理时间； 重试放大源站压力； 回源带错 Cookie； 源站限速； 源站只允许部分 CDN 网段； 源站响应 no-store 但期望 CDN 缓存。22.7 动态加速动态接口不能被缓存，但 CDN 仍可通过优化链路改善： 就近接入； CDN 内部骨干网回源； 连接复用； TCP/TLS 优化； HTTP/2 或 HTTP/3； 智能路由； 请求压缩。注意： 动态请求收益需实测； 敏感数据要评估代理点； POST 和请求体大小有限制； WebSocket 支持视 CDN 而定； 响应流式传输需要验证。22.8 安全与防护CDN 可以隐藏源站 IP、吸收流量攻击、配合 WAF 过滤请求。措施： 源站只允许 CDN 回源网段； 配置回源鉴权； URL 防盗链； 时间戳签名； 频率限制； Bot 治理； WAF 规则； DDoS 清洗； 敏感路径禁缓存； 访问日志脱敏。仅靠隐藏源站 IP 不等于安全，仍需源站防火墙和证书治理。22.9 多 CDN 策略原因： 不同地区性能差异； 单供应商故障； 成本谈判； 特定能力差异； 合规要求。调度：全局流量调度 |-- CDN A：主要地区 |-- CDN B：备份 +-- 源站直连：降级要求： 统一域名和证书管理； 配置一致性验证； 双方缓存和刷新能力； 监控对比； 自动切流阈值； 定期演练。22.10 排障用户访问慢：1. 确认用户地区和运营商2. 解析 CDN 域名3. curl 测边缘响应4. 查看命中状态5. 对比源站响应6. 检查回源耗时7. 查看资源大小和压缩访问 404：1. 确认源站资源存在2. 检查回源 Host 和路径3. 检查重写规则4. 检查缓存 key5. 检查源站路由新旧内容混杂： HTML 缓存策略错误； hash 引用未更新； 部分节点刷新未完成； 用户本地缓存； 浏览器或中间代理缓存。本章小结CDN 通过边缘缓存、就近接入和回源控制降低用户延迟和源站压力。静态资源应使用内容哈希和长缓存，动态接口要谨慎设置 no-store，发布时优先新文件名而不是频繁刷新。CDN 治理重点是命中率、回源带宽、刷新预热、回源 Host、安全防护和多 CDN 切流演练。思考题 CDN 为什么能降低用户访问延迟？ 哪些响应不适合公共边缘缓存？ 如何安全发布静态资源并避免回源风暴？ 回源 Host 错误会导致什么问题？ 设计一个多 CDN 故障切换方案。
• 这是《计算机网络 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。云网络把物理数据中心抽象成 VPC、子网、路由表、安全组、EIP、NAT 网关、对等连接和专线。理解 NAT、conntrack 和路由策略，才能定位“实例能出公网但不能入公网”“内网互通异常”“NAT 端口耗尽”“跨可用区流量绕路”等问题。21.1 私网地址与公网访问私网地址：10.0.0.0/8172.16.0.0/12192.168.0.0/16私网实例访问公网通常经过 NAT：Private EC2 / ECS -> Route Table -> NAT Gateway -> Internet方向差异： 能力 私网实例 有 EIP / 公网 IP 实例 主动访问公网 可经 NAT 可直接转换 公网主动访问 默认不可 可监听服务 暴露服务 通过 LB / VPN / 专线 可直接暴露但需安全策略 数据库和内部服务通常不应直接绑定公网地址。21.2 SNAT 与 DNATSNAT：修改源地址。10.0.1.10:50000 -> InternetNAT 转换为公网 IP:40001响应回来再还原DNAT：修改目标地址。Client -> 公网 VIP:443LB DNAT -> 10.0.1.10:8080NAT 依赖连接状态表。状态老化、表满、后端响应路径不一致，都会造成异常。21.3 NAT 端口耗尽一个公网 IP 的端口最多约 65535，但可通过多个公网 IP 扩展。对单一目标地址和端口，五元组必须唯一。高风险场景： 大量实例共享一个 NAT 网关； 短连接高频访问同一个第三方 API； DNS 或 HTTPS 未复用连接； 重试风暴； 数据库连接创建过多； 压测并发设计不合理。现象： 偶发连接失败； cannot assign requested address； NAT 网关连接数和丢包指标高； 错误与流量高峰相关； 换目标地址或降低并发后缓解。处理： 长连接和连接池； 降低重试频率； 拆分多个 NAT 网关或 EIP； 第三方多域名目标分散； 代理层复用连接； 限流； 监控新建连接速率。21.4 VPC 与路由表典型 VPC：VPC 10.0.0.0/16 Public Subnet 10.0.0.0/24 App Subnet 10.0.16.0/24 Data Subnet 10.0.32.0/24路由表示例： 目的 下一跳 10.0.0.0/16 local 0.0.0.0/0 NAT Gateway / IGW 10.20.0.0/16 Peering / VPN 常见问题： 路由表未关联正确子网； 对等连接两端路由缺少； 网段重叠导致无法建立连接； 默认路由误指向错误网关； 安全组和 NACL 同时拦截； 云路由与系统内路由冲突； 策略路由未覆盖源地址。21.5 安全组与 NACL 项目 安全组 NACL 层级 实例 / 网卡 子网 状态 有状态 无状态 规则 默认拒绝入站，允许出站常见 按编号顺序匹配 适用 服务端口精细治理 子网边界粗粒度控制 排障顺序： 安全组入站； 安全组出站； NACL 入站和出站； 系统防火墙； 应用监听地址； 路由表； 对端安全组。注意：安全组放行入站后，回包通常自动允许；无状态 NACL 还要放行临时端口回包。21.6 云上跨网络互通常见方式： 方式 场景 VPC Peering 同云两个 VPC 内网互通 Transit Gateway / 云连接网 多 VPC 大规模组网 VPN 稳定性要求一般的混合云 专线 低延迟和高可靠性 PrivateLink / Private Endpoint 访问云服务不经公网 Cloud Backbone 跨地域高速互联 设计要点： 网段不能重叠； 路由最小授权； 带宽和并发连接； 跨可用区和跨地域延迟； 故障切换和备份链路； 安全审计； 云平台配额。21.7 Overlay 网络容器和云主机常用 overlay：Pod Packet -> VETH -> Bridge -> VXLAN / IPIP / Geneve 封装 -> Underlay Network影响： MTU 降低； CPU 封装开销； 性能依赖实现； conntrack 表压力； 排障层级增加； 网络策略与安全组叠加。排查 overlay 要同时看 Pod、Node、Veth、Bridge、隧道、underlay 路由和云安全组。21.8 云网络排障ip addrip routeip ruleping <gateway>ping <target>traceroute <target>ss -ntpconntrack -L | grep <ip>云控制台检查： 实例网卡和 IP； 路由表关联； 安全组； NACL； NAT 网关； LB 后端子网； 对等连接路由； 流量镜像或 VPC Flow Log。21.9 实践建议 生产、测试、开发 VPC 隔离； 数据层不放公网； 按应用分层子网； 预留 IP 空间； 安全组按角色命名和复用； 监控 NAT 连接、丢包、带宽； 关键外呼使用连接池； 跨地域调用评估延迟； 架构图与实际路由定期核对； 变更可回滚。本章小结NAT 修改源或目标地址，让私网实例访问公网或让公网流量进入内部服务。云网络由 VPC、子网、路由表、安全组、NACL、NAT 网关和对等连接组成，排障要沿“系统路由 -> 云路由 -> 安全策略 -> NAT 状态 -> 目标服务”推进。短连接外呼要治理连接复用和 NAT 端口耗尽。思考题 SNAT 和 DNAT 分别发生在什么方向？ 为什么 NAT 端口耗尽常表现为偶发失败？ 安全组和 NACL 的状态性有什么区别？ overlay 网络为什么更容易出现 MTU 问题？ 设计一个生产、测试隔离的多 VPC 网络方案。
• 这是《计算机网络 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。负载均衡把流量分发到多个后端实例，是横向扩展、灰度发布和高可用的基础。它不只是“轮询选一台机器”，还涉及健康检查、会话保持、连接 draining、四层与七层能力、过载保护和故障切换。20.1 为什么需要负载均衡单机瓶颈：流量增长 -> CPU / 内存 / 连接数不足 -> 无法无限纵向扩容 -> 多实例水平扩展 -> 需要统一入口分发负载均衡提供： 流量分发； 健康检查； 故障摘除； 平滑发布； TLS 终止； 限流防护； 观测入口； 多可用区容灾。20.2 四层与七层 类型 工作层 能力 典型实现 L4 传输层 按 IP 和端口转发，性能高 LVS、云 NLB、IPVS L7 应用层 按 HTTP 路径、Header、Cookie 路由 Nginx、HAProxy、Envoy、云 ALB 选择： TCP/UDP 私有协议、超高性能转发：L4； HTTP 路由、TLS、重写、限流、灰度：L7； 大型系统常组合使用：L4 承接入口，L7 做业务路由。20.3 常见算法 算法 特点 轮询 依次分发，简单 加权轮询 按机器规格分配 最少连接 优先给当前连接少的节点 加权最少连接 兼顾规格和负载 源 IP Hash 同源尽量稳定 一致性 Hash 节点变化时减少映射变化 随机 实现简单，异常时可能不均 响应时间 依赖探测质量 长连接场景不能只看请求速率。如果每次连接持续数小时，轮询建连数均衡不代表当前在线连接或消息量均衡。20.4 健康检查健康检查类型： TCP 端口检查； HTTP GET； 自定义健康接口； gRPC Health Check； 执行外部脚本； 管理面进程检查。Nginx 主动检查：upstream app { server 10.0.1.10:8080; server 10.0.1.11:8080; health_check interval=5s fails=3 passes=2;}健康接口设计：/health/live：进程存活/health/ready：可以承接流量readiness 应检查： 应用已启动； 依赖可用性是否满足承接条件； 配置加载完成； 预热完成； 当前过载状态。注意：不要让非关键依赖导致整个服务被摘除。如果报表缓存不可用但核心下单可用，应分级降级。20.5 会话保持方式： Source IP Hash； Cookie 插入； 应用 Session ID 粘滞； 服务端外部会话存储； 客户端令牌。建议优先无状态设计。需要粘滞的场景要考虑： 节点故障后的会话迁移； 灰度发布期间兼容； 长连接迁移成本； 数据局部性； 负载倾斜。20.6 连接与请求 draining发布时不能直接把实例从集群删除并杀死进程。正确流程：1. 标记实例为 draining2. 从新流量分配中移除3. 保留既有连接处理4. 主动通知客户端重连或等待连接结束5. 观察连接数下降6. 达到超时后优雅关闭7. 停止进程并发布注意： 长连接需要更长的 drain 时间； 服务端可发送 GoAway 或关闭帧； 客户端要有重连机制； 任务实例要处理任务租约； 数据库连接要等待事务结束； 强杀会造成请求失败和数据不一致。20.7 高可用架构入口层：DNS / Anycast -> L4 LB 多可用区 -> L7 Gateway 多副本 -> Service Pods 多副本关键设计： LB 自身多节点； 配置热更新； 后端多可用区； 健康检查不同步误判； 防止 LB 单点； 管理面故障不影响数据面； 后端容量和 LB 容量同时规划； 入口带宽可扩展。20.8 HAProxy 示例frontend api_frontend bind *:443 ssl crt /etc/haproxy/tls/api.pem default_backend api_backendbackend api_backend balance leastconn option httpchk GET /health/ready http-check expect status 200 server app1 10.0.1.10:8080 check inter 5s fall 3 rise 2 server app2 10.0.1.11:8080 check inter 5s fall 3 rise 2常用观测： 当前连接数； 每秒新建连接； 每秒请求； 后端延迟； 5xx 比例； 健康状态； 队列长度； 重试次数。20.9 常见故障后端全部不健康现象：503。检查健康接口、后端进程、安全组、探针路径、Host 头和协议。流量倾斜检查算法、连接时长、Hash key、单机容量、健康检查和长连接分布。偶发 502排查后端主动 RST、连接队列溢出、网关重试、后端重启和空闲超时。偶发 504查看后端处理耗时、网关读超时、慢依赖和 GC 停顿。客户端本地缓存旧后端服务发现、DNS、连接池未刷新都可能导致。本章小结负载均衡通过算法、健康检查和流量摘除实现多实例水平扩展。L4 性能高，L7 语义强，二者常组合使用。生产重点是 readiness 分级、优雅 draining、长连接治理、LB 自身高可用和容量监控。502、503、504 需要结合 LB、后端和客户端三方证据定位。思考题 L4 和 L7 负载均衡分别适合什么场景？ 轮询在长连接场景有什么问题？ liveness 和 readiness 有什么区别？ 设计长连接服务的 draining 流程。 为一个多可用区 API 服务设计 LB 和健康检查方案。
• 这是《计算机网络 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。代理是现代网络架构的常见组件。它可以是正向代理，代表客户端访问外部；也可以是反向代理，代表服务端接收请求。网关则进一步承载协议转换、路由、认证、限流、观测和流量治理。理解代理的地址透传、协议转换、超时传递和故障语义，是定位线上问题的基础。19.1 正向代理与反向代理 类型 方向 代表谁 典型场景 正向代理 客户端 -> 外部 客户端 出口管控、缓存、审计 反向代理 客户端 -> 内部服务 服务端 LB、TLS 终止、路由、防护 正向代理：Client -> Forward Proxy -> Internet -> Server反向代理：Client -> Reverse Proxy / Gateway -> Backend对后端来说，反向代理是直接客户端；对用户来说，反向代理就是服务入口。19.2 代理的透明性常见头部： Header 含义 X-Forwarded-For 客户端和代理链 IP X-Real-IP 常用于直接客户端 IP X-Forwarded-Proto 客户端原始协议 X-Forwarded-Host 原始 Host X-Request-ID 链路请求 ID Nginx：proxy_set_header Host $host;proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;proxy_set_header X-Forwarded-Proto $scheme;安全原则： 只信任可信入口设置的头； 入口代理覆盖外部传入的转发头； 后端根据可信代理跳数取真实 IP； 记录完整链路或规范化客户端 IP； 审计日志与访问日志统一语义。19.3 正向代理模式HTTP 代理curl -x http://proxy.example.com:8080 https://www.example.comHTTP 代理可以看到明文 HTTP 内容；访问 HTTPS 时通常使用 CONNECT 建隧道。HTTPS CONNECTClient -> Proxy: CONNECT www.example.com:443Proxy -> Client: HTTP/1.1 200 Connection EstablishedClient <-> Server: TLS代理知道目标域名和流量大小，若不做中间人解密，无法看到 TLS 内容。SOCKS 代理SOCKS5 支持 TCP 和 UDP 代理：curl --socks5 host:port https://www.example.com19.4 反向代理能力反向代理常承担： TLS 终止； HTTP 路由； 负载均衡； 健康检查； 缓存； 压缩； 限流； 重写； 访问日志； 故障隔离。示例：upstream app { server 10.0.1.10:8080 max_fails=3 fail_timeout=10s; server 10.0.1.11:8080 max_fails=3 fail_timeout=10s;}server { listen 443 ssl; server_name api.example.com; location / { proxy_pass http://app; proxy_connect_timeout 2s; proxy_read_timeout 10s; proxy_next_upstream error timeout http_502 http_503; }}19.5 API 网关API 网关是带业务治理能力的反向代理。常见能力： 能力 示例 认证 JWT、OAuth2、mTLS 授权 路由级、租户级、API 级 限流 单 IP、用户、API、租户 熔断 下游错误率过高时快速失败 路由 路径、Header、权重、地域 协议转换 REST 到内部 RPC 观测 日志、指标、trace 安全 WAF、Bot 治理 边界： 网关不应包含复杂业务规则； 数据校验仍需服务端完成； 网关高可用影响全站可用性； 重试必须与幂等配合； 网关不能掩盖服务容量问题。19.6 超时与重试链路示例：Client -> LB -> Gateway -> Service -> DB超时设置原则：外层超时必须覆盖内层可接受的处理时间，同时设置总上限重试预算要小于外层超时推荐： 数据库 50ms 到数秒，视查询而定； 内部服务 100ms 到 2s； 网关到服务 2s 到 10s； 用户请求按业务 SLA 设置； 连接超时小于读超时； 空闲超时大于心跳间隔； 所有组件超时来源可配置。重试要考虑： 方法是否幂等； 业务是否有幂等键； 5xx 是否可重试； 429 和 Retry-After； 重试次数和总预算； 随机退避； 熔断状态。19.7 代理与缓存HTTP 缓存：proxy_cache_path /var/cache/nginx keys_zone=api_cache:10m;适合缓存： 公共静态资源； 低频变化配置； 可容忍短暂延迟的商品数据； 聚合报表。不适合缓存： 用户订单列表； 支付结果； 权限数据； 个性化敏感数据。私有响应不能进入共享缓存：Cache-Control: private, no-store19.8 故障语义常见错误： 状态 可能原因 502 后端连接失败、握手失败、后端崩溃 503 后端不可用、健康检查失败、限流 504 后端处理超时 499 客户端主动断开，Nginx 语义 400 请求头过大、协议错误 431 请求头字段过大 排障要看两侧：代理日志：upstream、状态、耗时、重试后端日志：请求是否到达、处理耗时、错误如果代理有 499 而后端无日志，可能是后端未及时收到或客户端极早断开；如果后端慢，应继续查服务与依赖。19.9 网关高可用要求： 多实例部署； 入口 DNS 或 LB 多活； 无状态或状态外置； 配置热更新； 健康检查分级； 后端摘除自动化； 过载保护； 管理面与数据面隔离； 配置版本化； 变更可回滚。容量规划要同时考虑： QPS； 并发连接； TLS 握手； 请求体大小； 日志写入； 后端延迟； 突发重试； 带宽。本章小结正向代理代表客户端访问外部，反向代理和 API 网关代表服务端承接流量。代理通过 X-Forwarded-* 传递链路信息，但必须防止外部伪造。网关治理认证、路由、限流、熔断、观测和协议转换，超时与重试必须跨层级设计。502、503、504、499 需要结合代理与后端两侧日志定位。思考题 正向代理和反向代理分别代表谁？ 为什么不能信任外部传入的 X-Forwarded-For？ HTTPS 经过 HTTP 代理时 CONNECT 做了什么？ API 网关应该承载哪些能力，不应承载哪些业务？ 设计一条 Client -> Gateway -> Service -> DB 链路的超时与重试预算。
• 这是《计算机网络 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。HTTP 是请求响应模型，服务端主动推送并不自然。WebSocket 通过一次 HTTP Upgrade 建立全双工长连接，适合聊天、协同编辑、实时行情、游戏和推送。长连接的价值是降低建连成本，挑战是连接治理、心跳、断线重连、广播扇出和故障切换。18.1 从 HTTP 到 WebSocket握手请求：GET /ws HTTP/1.1Host: ws.example.comUpgrade: websocketConnection: UpgradeSec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==Sec-WebSocket-Version: 13Origin: https://www.example.com握手响应：HTTP/1.1 101 Switching ProtocolsUpgrade: websocketConnection: UpgradeSec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=握手完成后，连接不再使用 HTTP 请求响应语义，改用 WebSocket 帧。18.2 帧格式WebSocket 消息由帧组成： Opcode 含义 0x1 文本帧 0x2 二进制帧 0x8 连接关闭 0x9 Ping 0xA Pong 0x0 continuation 特性： 支持文本和二进制； 支持消息分片； 支持控制帧； 客户端到服务端的帧必须掩码； 有消息边界； 默认使用 TCP 字节流承载。18.3 使用 wscatnpm install -g wscatwscat -c ws://127.0.0.1:8080/wswscat -c wss://ws.example.com/ws发送消息后可观察服务端日志和帧解析。调试时注意 URL 协议是 ws 或 wss，不是 http。18.4 心跳与假死长连接可能被以下设备悄悄断开： 负载均衡空闲超时； NAT 超时； 防火墙会话超时； 代理连接池回收； 服务端主动关闭。策略：客户端每 25 秒发送 Ping服务端收到后回 Pong服务端读空闲 60 秒触发关闭客户端连续 2 次未收到 Pong 则重连心跳间隔必须小于链路中最短空闲超时。18.5 断线重连客户端重连要求： 指数退避加随机抖动； 最大重连间隔； 会话恢复令牌； 消息序号或版本号； 补拉离线消息； 去重； 网络切换后快速重试； 服务端可下发重试建议。错误示例：断线后每 100ms 重连 -> 服务端尚未恢复 -> 连接风暴 -> 雪崩正确示例：1s、2s、4s、8s，最大 60s，加 0-500ms 随机抖动18.6 连接治理服务端要治理： 项目 建议 单机连接数 设置上限和监控 单 IP 连接数 限流，防滥用 用户连接数 同一用户多端策略 消息大小 限制帧和消息上限 发送队列 控制慢消费者 空闲时间 心跳和读超时 广播扇出 分组和分片 优雅关闭 先停止接收，再排空 慢消费者问题：客户端接收慢 -> 服务端为它积压消息 -> 内存上涨 -> 影响其他连接处理： 每连接发送队列上限； 超限断开； 关键消息和可丢消息分级； 广播降级为最新值； 使用有界队列； 监控队列长度。18.7 Spring Boot 示例依赖：<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-websocket</artifactId></dependency>配置：@Configuration@EnableWebSocketpublic class WebSocketConfig implements WebSocketConfigurer { @Override public void registerWebSocketHandlers( WebSocketHandlerRegistry registry) { registry.addHandler(new EchoHandler(), "/ws") .setAllowedOrigins("https://www.example.com"); }}处理器：public class EchoHandler extends TextWebSocketHandler { @Override protected void handleTextMessage( WebSocketSession session, TextMessage message) throws Exception { session.sendMessage( new TextMessage("ack:" + message.getPayload())); }}生产实现还需心跳、异常处理、连接统计和限流。18.8 集群与广播多节点长连接服务需要跨节点推送：用户 A 连接 Node 1用户 B 连接 Node 2系统事件发布到 Kafka / Redis / MQ -> 所有节点收到 -> 各节点推给本机连接要点： 连接路由表； 用户到节点映射； 消息可靠性和顺序； 重复消息去重； 节点故障切换； 广播风暴控制； 离线消息存储； 监控端到端延迟。18.9 代理与负载均衡反向代理必须支持 Upgrade：location /ws { proxy_pass http://websocket-backend; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_read_timeout 300s; proxy_send_timeout 300s;}注意： proxy_read_timeout 应大于心跳间隔； LB 空闲超时要同步调整； TLS 使用 wss://； 保持客户端真实 IP； 健康检查不能只看端口； 会话粘滞视业务状态而定。18.10 安全 强制 wss://； 校验 Origin； 握手时完成认证； 短期 token 或 Ticket； 限制消息大小； 防止注入和 XSS； 每次业务消息授权； 不信任客户端上报的设备信息； 监控异常连接和消息频率。本章小结WebSocket 通过 HTTP Upgrade 建立全双工长连接，使用帧协议承载文本和二进制消息。长连接治理重点是心跳、断线重连、连接上限、慢消费者和集群广播。反向代理和 LB 必须支持 Upgrade 并保证超时大于心跳间隔，安全上应使用 wss、校验 Origin 并在握手和业务消息两层授权。思考题 WebSocket 握手为什么返回 101？ 心跳间隔和 LB 空闲超时应满足什么关系？ 如何避免断线重连风暴？ 慢消费者为什么可能拖垮服务？ 设计一个百万连接推送系统的架构。
• 这是《计算机网络 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。HTTP/3 将 HTTP 的传输基础从 TCP 切换到 QUIC。QUIC 基于 UDP，在用户态实现可靠传输、流多路复用、内置 TLS 1.3、连接迁移和更快的握手恢复。它解决 TCP 时代难以演进的问题，也带来 UDP 防火墙、负载均衡和内核生态的新挑战。17.1 TCP 的演进瓶颈TCP 部署在操作系统内核和大量中间设备中，修改成本高： 拥塞算法迭代依赖内核版本； TCP 队头阻塞难以在 HTTP 层解决； 连接四元组变化即连接身份变化； TLS 与 TCP 分层，握手难以进一步合并； 中间设备可能干扰扩展选项。QUIC 选择 UDP 作为底层承载，把传输层能力放到用户态应用和库中，便于迭代。17.2 QUIC 基本特性 特性 价值 集成 TLS 1.3 传输与加密握手协同 流独立性 一个流丢包不阻塞其他流 连接 ID 地址变化后仍可识别连接 0-RTT 恢复连接降低延迟 用户态实现 迭代快，可随应用发布 拥塞控制可插拔 便于部署现代算法 17.3 队头阻塞的改善HTTP/2 多路复用后，多个流共享一条 TCP 字节流：Stream 1 / Stream 2 / Stream 3 \ | / TCP byte stream | 丢包阻塞所有流QUIC 为不同流维护独立交付状态：Stream 1 丢包 -> Stream 2 已完整到达的数据可以交付它消除传输层流之间的队头阻塞，但单个流内部仍是有序字节流，应用处理慢也会造成该流阻塞。17.4 连接迁移TCP 连接通常由四元组标识：Source IP + Source Port + Destination IP + Destination Port网络从 Wi-Fi 切到 5G 后，源地址变化，旧 TCP 连接无法继续。QUIC 使用 Connection ID：地址变化 -> Connection ID 不变 -> 连接可以迁移 -> 应用会话不必须重建迁移仍需路径验证、安全策略和负载均衡支持。Connection ID 也可能被用于用户跟踪，需要编码和轮换治理。17.5 握手与 0-RTTQUIC 集成 TLS 1.3：Client -> Initial + CRYPTOServer -> Initial + Handshake + CRYPTOClient -> Finished与 TCP + TLS 相比，可减少一次 RTT。恢复连接时可使用 0-RTT 提前发送应用数据。0-RTT 风险： 可能重放； 不能直接用于非幂等写操作； 早期数据加密强度有限； 服务端需要防重放策略。常见做法是 0-RTT 只用于幂等 GET 或携带一次性令牌的握手。17.6 QUIC 流与控制QUIC 有连接级和流级控制： 类型 说明 双向流 两侧都可发送 单向流 只有一个方向发送 MAX_DATA 连接级窗口 MAX_STREAM_DATA 流级窗口 CRYPTO 加密握手数据 ACK 确认 CONNECTION_CLOSE 关闭 帧格式和细节由 QUIC 标准定义，应用开发通常通过库和运行时使用，不需要手工解析。17.7 拥塞控制QUIC 的 ACK 机制携带更丰富的传输时延信息，便于估算 RTT 和丢包。常见实现支持： CUBIC； BBR； 自定义实验算法。由于 QUIC 在用户态运行，应用可以更快获得新算法，但 CPU 成本和库实现质量必须评估。17.8 部署要求启用 HTTP/3 需要： 服务端支持 QUIC/HTTP/3； UDP 443 可达； 证书与 TLS 1.3 配置正确； Alt-Svc 告知客户端； 客户端支持； LB 或 Ingress 支持； 防火墙放行 UDP； 监控 QUIC 流量。Alt-Svc 示例：Alt-Svc: h3=":443"; ma=86400Nginx 新版本可能支持 HTTP/3，但指令和稳定性取决于版本，应查阅当前版本文档。17.9 排障查看协议：curl -I --http3 https://www.example.com抓包：tcpdump -i eth0 udp port 443 -w quic.pcapWireshark 可解析 QUIC，但密钥导出配置会影响解密效果。服务端应记录： QUIC 版本； 握手成功率和失败原因； 0-RTT 比例； 连接迁移次数； RTT 和丢包； 流数量； UDP 缓冲丢弃； CPU 使用率。常见问题： 现象 原因 HTTP/3 无法建立 UDP 被防火墙拦截 回退 HTTP/2 客户端或 Alt-Svc 不支持 握手失败 证书、版本、SNI 配置 吞吐低 UDP 缓冲、丢包、算法 CPU 高 用户态协议栈成本 LB 异常 不支持连接 ID 路由 17.10 适用判断适合： 弱网和移动网络用户； 高 RTT 跨地域访问； 大量并发小请求； 需要连接迁移； CDN 和边缘接入。需评估： 服务端 CPU； 运维观测能力； 中间网络对 UDP 的策略； 客户端兼容； 是否已有 HTTP/2 长连接优化； LB 和代理支持程度。本章小结HTTP/3 基于 QUIC，在 UDP 上实现可靠传输、流独立交付、TLS 1.3、连接迁移和快速恢复。它改善 TCP 队头阻塞、握手延迟和网络切换体验，但部署依赖 UDP 443、客户端支持和基础设施能力。是否启用应基于用户网络形态、CPU 成本和可观测性验证。思考题 QUIC 为什么能减少 HTTP/2 的 TCP 队头阻塞？ Connection ID 如何支持连接迁移？ 0-RTT 有什么安全风险？ HTTP/3 部署需要哪些网络条件？ 设计一次 HTTP/3 灰度验证方案。
• 这是《计算机网络 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。HTTP/2 解决 HTTP/1.1 的连接效率问题：请求队头阻塞、头部重复、文本解析成本和难以并行。它通过二进制分帧、流多路复用、HPACK 头部压缩和单个 TCP 连接复用，显著提升高延迟链路和多请求页面的加载性能。16.1 HTTP/1.1 的问题HTTP/1.1 常见优化：1. 浏览器对同一域名开启多个并发连接2. 静态资源分到多个域名3. Sprite、内联资源4. 减少请求次数原因： 同一连接上响应必须按请求顺序返回； 前一个慢响应会阻塞后续响应； 头部大量重复； 文本解析成本高； 多连接带来更多握手和拥塞竞争。16.2 二进制分帧HTTP/2 将消息拆成帧：| Length | Type | Flags | Stream Identifier | Frame Payload |常见帧： 帧 作用 HEADERS 请求或响应头 DATA 请求或响应体 SETTINGS 连接参数 WINDOW_UPDATE 流量控制 PRIORITY 优先级，后续演进中作用弱化 RST_STREAM 取消流 PING 连接保活与 RTT 测量 GOAWAY 优雅关闭连接 一个请求或响应是一个流，流由多个帧组成。16.3 多路复用TCP Connection |-- Stream 1：GET /api/user |-- Stream 3：GET /api/orders |-- Stream 5：POST /api/payment +-- Stream 7：GET /static/app.js多个流共享一条连接，帧可以交错传输。高 RTT 网络中，不必为每个资源重新建连，也不必等待浏览器连接池分配。多路复用不能突破 TCP 单字节流限制：HTTP/2 消除应用层请求队头阻塞但 TCP 任何一个包丢失会阻塞所有流的字节交付这是 HTTP/3 和 QUIC 的重要动机。16.4 HPACKHPACK 压缩头部： 静态表保存常见头部； 动态表保存连接内重复头部； 使用 Huffman 编码减少体积； 头部字段通过索引引用。注意： 动态表依赖连接状态； 头部大小需限制，防止内存攻击； 敏感头部可标记 never indexed； 压缩对高重复请求收益明显。16.5 流优先级与依赖HTTP/2 早期通过流依赖和权重表达优先级，实践中浏览器策略差异较大，后续标准演进引入了更简单的优先级信号。工程目标： 关键 HTML 和 CSS 先传输； 首屏图片优先； 大文件不阻塞关键请求； 服务端可根据资源类型和业务重要性调度。优先级只是建议，网络、服务器实现和调度策略都会影响最终顺序。16.6 流量控制HTTP/2 有连接级和流级窗口：WINDOW_UPDATE作用： 避免高速流淹没接收方； 控制单个流占用缓冲； 支持流级别的背压。问题： 窗口过小限制吞吐； 应用读取慢会阻塞流； 代理转发慢会放大延迟； 高吞吐服务需评估缓冲策略。16.7 服务端推送服务端推送允许服务器主动发送预测资源，但实践中存在以下问题： 客户端缓存判断困难； 推送资源可能不需要； 占用关键带宽； 浏览器支持逐步弱化； 现代实现更倾向预加载提示。不建议把服务端推送作为核心性能方案。16.8 部署与调试启用条件：HTTPS + ALPN h2Nginx 新版本示例：server { listen 443 ssl; http2 on; server_name www.example.com;}不同版本配置语法可能不同，旧版本可能使用 listen 443 ssl http2;。查看协议：curl -I --http2 https://www.example.comcurl -v --http2 https://www.example.comnghttp -v https://www.example.com浏览器开发者工具的 Protocol 列也可以查看是否为 h2。16.9 常见问题单连接竞争大量下载共享一条 TCP 连接，可能影响关键小请求。可用限速、资源优化和 HTTP/3 缓解。中间设备兼容代理、LB、WAF 必须正确转发 HTTP/2，或明确终止后转为 HTTP/1.1。头部过大检查 HPACK、日志中间件和头部大小限制。流重置客户端取消页面请求会发送 RST_STREAM，需区分正常取消和异常崩溃。连接突然关闭观察 GOAWAY、空闲超时、TLS 错误和 LB 策略。本章小结HTTP/2 使用二进制分帧和流实现多路复用，用 HPACK 减少重复头部，用连接级和流级窗口实现流量控制。它降低了高延迟链路上的建连和排队成本，但仍受 TCP 队头阻塞影响。部署需 HTTPS 和 ALPN，排查时应关注流状态、流量控制、代理兼容和连接超时。思考题 HTTP/2 如何解决 HTTP/1.1 的请求队头阻塞？ 为什么 HTTP/2 仍有 TCP 队头阻塞？ HPACK 的动态表有什么作用？ HTTP/2 流量控制和 TCP 滑动窗口有什么区别？ 如何验证线上站点已经启用 HTTP/2？
• 这是《计算机网络 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。HTTPS 在 HTTP 语义之下加入 TLS，提供身份认证、机密性和完整性保护。生产中 HTTPS 的问题往往集中在证书链、域名匹配、协议版本、SNI、ALPN、证书轮换和会话恢复。本章把这些机制串成可部署、可排障的知识链。15.1 TLS 解决什么问题没有加密的 HTTP 面临： 窃听：路径设备可以看到内容； 篡改：响应或请求可被修改； 冒充：攻击者伪装服务端； 泄露：URL、Header、Cookie 明文传输。TLS 提供： 能力 机制 认证 证书和信任链 机密性 协商对称密钥加密 完整性 AEAD 或 MAC 前向安全 临时密钥交换 应用协议协商 ALPN 15.2 证书体系证书链：Root CA -> Intermediate CA -> Server Certificate服务端通常发送服务器证书和中间证书。根证书预置在操作系统或浏览器信任库中，不由服务端发送。证书包含： Subject / Issuer； 有效期； SAN 域名； 公钥； 签名算法； 密钥用途； 扩展约束。校验通过的条件： 证书链可追溯到受信任 CA； 当前时间在有效期内； 域名匹配 SAN； 用途正确； 未被吊销或按策略完成吊销检查； 签名算法和安全策略满足要求。15.3 TLS 1.2 握手简化流程：Client -> ClientHello：支持的套件、随机数、SNI、扩展Server -> ServerHello：选择套件、随机数 -> Certificate -> ServerKeyExchange -> ServerHelloDoneClient -> ClientKeyExchange -> ChangeCipherSpec -> FinishedServer -> ChangeCipherSpec -> FinishedTLS 1.2 建连通常需要 2 RTT，再叠加 TCP 握手 1 RTT。15.4 TLS 1.3 握手简化流程：Client -> ClientHello：key_share、SNI、ALPNServer -> ServerHello -> EncryptedExtensions -> Certificate -> CertificateVerify -> FinishedClient -> Finished特点： 通常 1 RTT 建连； 握手后大部分消息加密； 删除弱算法； 默认前向安全； 支持 0-RTT 恢复。0-RTT 降低延迟，但重放风险需要应用层防护，不适合非幂等请求直接使用。15.5 SNI 与 ALPNSNI一个 IP 上承载多个 HTTPS 域名时，客户端在 ClientHello 中发送目标域名，服务器据此选择证书：SNI: www.example.comTLS 1.3 中 ClientHello 仍明文，传统 SNI 域名可能被观察。Encrypted Client Hello 是后续增强，部署依赖客户端和服务端支持。ALPNALPN 协商应用协议：Client：h2, http/1.1Server：h2没有 ALPN 时，通常退回 HTTP/1.1。15.6 会话恢复方式： 机制 特点 Session ID 服务端保存会话状态 Session Ticket 服务端加密状态交给客户端保存 TLS 1.3 PSK 支持恢复和 0-RTT 会话恢复减少握手 RTT，但密钥轮换和票据管理要安全治理。15.7 mTLS双向 TLS 要求客户端也提供证书：Server 校验客户端证书Client 校验服务端证书流程： CA 签发客户端证书； 服务端配置信任 CA 和校验模式； 客户端发送证书和私钥证明； 服务端读取证书身份； 应用映射证书到权限。Nginx 示例：server { listen 443 ssl; server_name api.example.com; ssl_certificate /etc/nginx/tls/server.crt; ssl_certificate_key /etc/nginx/tls/server.key; ssl_client_certificate /etc/nginx/tls/client-ca.crt; ssl_verify_client on;}注意：证书只证明身份，不代表授权，仍需授权系统。15.8 证书轮换流程：1. 监控证书到期时间2. 签发新证书3. 在测试环境验证证书链4. 更新 LB / Ingress / 服务5. 滚动重启或热加载6. 验证客户端兼容7. 保留旧证书回滚窗口8. 记录指纹和有效期要求： 到期前至少提前数天告警； 自动化签发和部署； 中间证书必须完整； 私钥权限最小化； 支持热加载； 多域名和泛域名统一治理； 轮换后全链路探测。15.9 排查命令查看证书：openssl s_client -connect www.example.com:443 -servername www.example.comopenssl x509 -in server.crt -noout -textopenssl x509 -in server.crt -noout -dates -subject -issuer测试协议：openssl s_client -connect www.example.com:443 -tls1_2openssl s_client -connect www.example.com:443 -tls1_3curl -v --http2 https://www.example.com常见错误： 报错 原因 certificate has expired 证书过期 unable to get local issuer certificate 缺中间证书或信任库缺失 hostname mismatch SAN 不匹配 certificate signed by unknown authority 自签或私有 CA 未信任 protocol version 协议不兼容 handshake failure 套件、SNI、策略不匹配 15.10 HTTPS 性能优化： 使用 TLS 1.3； 启用会话恢复； 配置 OCSP Stapling； 保留 HTTP/2 长连接； 使用硬件加速或优化的密码库； 减少证书链长度； 就近接入； 会话票据密钥安全轮换。Nginx 示例：ssl_protocols TLSv1.2 TLSv1.3;ssl_ciphers HIGH:!aNULL:!MD5;ssl_prefer_server_ciphers on;ssl_session_cache shared:SSL:10m;ssl_session_timeout 10m;安全与性能需要平衡。禁用 TLS 1.2 前要确认客户端支持。本章小结HTTPS 通过证书链认证服务端身份，通过密钥协商建立加密通道，TLS 1.3 将握手降为 1 RTT 并增强前向安全。SNI 支持单 IP 多域名，ALPN 协商 HTTP/2 和 HTTP/3，mTLS 可用于服务间认证。证书链不完整、过期、SAN 不匹配、SNI 错误和协议不兼容是 HTTPS 主要故障来源。思考题 TLS 1.2 和 TLS 1.3 握手有什么差异？ 为什么服务端必须发送中间证书？ SNI 和 ALPN 分别解决什么问题？ 0-RTT 的重放风险如何缓解？ 写一份生产证书轮换和回滚流程。
• 这是《计算机网络 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。HTTP 是现代应用最常用的应用层协议。理解 HTTP 不只是会发 GET 和 POST，还要理解方法语义、状态码、头部、缓存、幂等、认证、跨域、压缩和消息边界。这些语义直接影响接口正确性、重试安全和 CDN 效果。14.1 HTTP 请求与响应请求：POST /api/orders HTTP/1.1Host: api.example.comContent-Type: application/jsonContent-Length: 45Authorization: Bearer <token>{"userId":10001,"skuId":20001,"quantity":1}响应：HTTP/1.1 201 CreatedContent-Type: application/jsonContent-Length: 58Location: /api/orders/100000001{"orderId":100000001,"status":"CREATED"}HTTP/1.1 明文文本协议，但 HTTP/2 和 HTTP/3 使用二进制分帧，语义仍保持请求响应模型。14.2 方法语义 方法 语义 幂等 安全 GET 读取资源 是 是 HEAD 读取元数据 是 是 OPTIONS 查询能力 是 是 POST 创建或执行动作 否 否 PUT 替换资源 是 否 PATCH 部分更新 不保证 否 DELETE 删除资源 是 否 “安全”表示不改变服务端资源状态，“幂等”表示同一请求执行多次结果一致。POST 不幂等的典型例子：POST /orders 第一次创建订单 1001POST /orders 重试后创建订单 1002要安全重试 POST，需要业务幂等键：Idempotency-Key: 7c9e6679-7425-40de-944b-e07fc1f90ae714.3 状态码 类别 含义 常见状态码 1xx 中间状态 101 Switching Protocols 2xx 成功 200、201、204、206 3xx 重定向和缓存 301、302、304、307、308 4xx 客户端错误 400、401、403、404、409、429 5xx 服务端错误 500、502、503、504 易混状态码： 401 Unauthorized：未认证； 403 Forbidden：已认证但无权限； 409 Conflict：资源状态冲突； 429 Too Many Requests：限流； 502 Bad Gateway：网关收到无效响应； 503 Service Unavailable：服务暂不可用； 504 Gateway Timeout：网关等待上游超时。14.4 常用头部 Header 作用 Host 请求目标主机 Content-Type 请求体类型 Content-Length 请求体长度 Transfer-Encoding 传输编码 Accept 客户端可接受类型 Cache-Control 缓存策略 ETag / If-None-Match 协商缓存 Last-Modified / If-Modified-Since 时间协商 Cookie / Set-Cookie 会话 Authorization 认证凭据 Origin / Referer 来源 X-Forwarded-For 代理链路客户端地址 X-Forwarded-Proto 原始协议 Retry-After 重试建议 代理传递客户端信息时，应确保入口可信并覆盖外部传入的转发头。14.5 缓存语义强缓存：Cache-Control: public, max-age=3600协商缓存：ETag: "v1"If-None-Match: "v1"命中协商缓存返回：HTTP/1.1 304 Not Modified常见指令： 指令 含义 public 允许共享缓存 private 只允许浏览器等私有缓存 no-cache 可缓存，但使用前需验证 no-store 不保存响应 max-age 最大缓存时间 s-maxage 共享缓存时间 must-revalidate 过期后必须验证 静态资源适合内容哈希加长缓存；动态接口需谨慎，避免用户数据被共享缓存。14.6 连接与长连接HTTP/1.1 默认长连接：Connection: keep-alive请求分界： Content-Length； Transfer-Encoding: chunked； HTTP/2 帧； WebSocket 升级后自定义协议。短连接的问题： 每次请求增加 TCP 握手； HTTPS 增加 TLS 握手； TIME_WAIT 增多； 高延迟链路首包变慢。14.7 Cookie、CORS 与 SameSiteCookie 响应：Set-Cookie: sid=abc; Path=/; HttpOnly; Secure; SameSite=Lax属性： 属性 作用 HttpOnly 禁止 JS 读取 Secure 仅 HTTPS 发送 SameSite 跨站发送限制 Domain / Path 作用范围 Max-Age / Expires 过期时间 CORS 简单示例：Origin: https://www.example.comAccess-Control-Allow-Origin: https://www.example.comAccess-Control-Allow-Credentials: true跨域是浏览器安全策略，服务端 curl 不受同源策略限制。带凭据时不能使用 * 作为允许来源。14.8 压缩与范围请求压缩：Accept-Encoding: gzip, brContent-Encoding: gzip范围请求：Range: bytes=1000-1999响应：HTTP/1.1 206 Partial ContentContent-Range: bytes 1000-1999/10000适用： 大文件下载； 断点续传； 视频拖动； CDN 分片。注意：动态压缩会消耗 CPU；加密内容无法在代理层基于明文优化；小响应压缩可能得不偿失。14.9 HTTP 客户端实践curl -v https://www.example.comcurl -o /dev/null -s -w \ 'dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n' \ https://www.example.com客户端必须设置： 连接超时； 读取总超时； 最大响应体； 重试策略； 幂等约束； 连接池上限； 空闲连接回收； 熔断和限流。常见错误： 不设超时； 对 POST 无条件重试； 连接池无限增长； 忽略 429 和 Retry-After； 把 5xx 全部当可重试； 不关闭响应体。本章小结HTTP 语义由方法、状态码、头部和消息体组成。GET/PUT/DELETE 具有明确幂等语义，POST 需要业务幂等键才能安全重试。Cache-Control、ETag 和 304 决定缓存效率，Cookie、SameSite 和 CORS 影响浏览器安全，压缩与范围请求影响传输效率。生产客户端必须治理超时、重试、连接池和响应体释放。思考题 幂等和安全方法分别表示什么？ 301、302、307、308 的关键差异是什么？ no-cache 和 no-store 有什么区别？ 为什么带凭据的 CORS 不能返回 *？ 为一个订单接口设计状态码、幂等键和重试策略。
• 这是《计算机网络 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。DNS 把人类可读的域名转换为 IP 地址，是每一次外部访问的第一跳。它看似简单，实际是一个分层、缓存、可委托的全球分布式系统。DNS 解析失败、TTL 过长、地域调度错误或解析超时，都会直接影响可用性。13.1 域名结构www.example.com. | | | | | +-- TLD | +--------- Second Level +--------------- Subdomain末尾的 . 表示 DNS 根，日常输入时通常省略。解析层级：Stub Resolver -> Recursive Resolver -> Root -> TLD -> Authoritative DNS13.2 递归与迭代客户端通常只向本地递归 DNS 发起请求：浏览器 / 操作系统 -> Local Recursive DNS -> 逐级查询 -> 返回最终 IP递归 DNS 负责代替客户端完成迭代查询，并缓存结果。客户端看到的是一次递归查询。13.3 常见记录 类型 说明 示例 A 域名到 IPv4 1.2.3.4 AAAA 域名到 IPv6 2001:db8::1 CNAME 别名指向另一域名 cdn.example.net NS 委托子域解析 ns1.example.com MX 邮件服务器 10 mail.example.com TXT 文本记录 SPF、验证 CAA 允许签发证书的 CA 0 issue "letsencrypt.org" SRV 服务地址和端口 _sip._tcp PTR IP 反向解析 常用于邮件和日志 13.4 dig 与 nslookupdig www.example.comdig www.example.com Adig www.example.com AAAAdig www.example.com CNAMEdig @8.8.8.8 www.example.comdig www.example.com +shortdig www.example.com +tracedig -x 1.2.3.4重点字段：QUESTION SECTION：查询内容ANSWER SECTION：结果和 TTLAUTHORITY SECTION：授权 NSQuery time：查询耗时SERVER：使用的 DNS 服务器简单查看：nslookup www.example.comhost www.example.comresolvectl query www.example.com13.5 缓存与 TTLTTL 是记录可缓存时间：TTL 300：缓存 300 秒缓存层级：浏览器 -> 操作系统 -> 家用路由器 -> 运营商 / 公共递归 DNS -> 权威 DNS切换 IP 前： 提前降低 TTL； 等待旧 TTL 过期； 切换记录； 多地验证解析； 保留旧服务可用； 观察流量迁移； 再恢复 TTL。不要在 TTL 600 秒的情况下期待 DNS 切换立即生效。13.6 负载均衡与地域调度DNS 可以返回多个 A/AAAA 记录：www.example.com A 1.1.1.1www.example.com A 2.2.2.2调度方式： 方式 特点 轮询 简单，无法感知健康 权重 可控比例，受缓存影响 GeoDNS 按解析者位置调度 健康检查 自动摘除故障地址 Low TTL 快速切换，递归压力大 局限： 客户端可能只用第一个地址； Local DNS 位置不等于用户位置； 缓存让权重不精确； 无法感知真实应用负载； 网络路径质量动态变化。大型系统通常 DNS 只做入口和高层级调度，再由 LB 或服务发现做细粒度流量治理。13.7 DNS 解析失败排查dig @127.0.0.53 www.example.comdig @8.8.8.8 www.example.comdig @<authoritative-dns> www.example.comcat /etc/resolv.confresolvectl status定位顺序： 本机网络是否可用； /etc/hosts 是否覆盖； 系统 resolver 是否异常； 公共 DNS 是否能解析； 权威 DNS 是否返回正确记录； 域名是否过期； NS 委托是否正确； TTL 缓存是否导致旧结果； AAAA 是否可用但 IPv6 路由异常。13.8 应用中的 DNS潜在问题： 启动时解析一次，之后 IP 变化不生效； 客户端未设置解析超时； 连接池没有感知地址变化； IPv4/IPv6 选择策略导致失败； DNS 服务不可用导致雪崩； 内部服务发现依赖单一 DNS。实践： 设置解析和连接超时； 使用多个 DNS Server； 关键结果本地短缓存； 重试使用幂等策略； 定期刷新服务地址； 监控解析成功率和耗时； 内部服务发现准备降级方案。Java 示例：InetAddress[] addresses = InetAddress.getAllByName("www.example.com");for (InetAddress address : addresses) { System.out.println(address.getHostAddress());}注意 JVM 的 DNS 缓存策略，容器和服务重启也会影响解析刷新。13.9 DNS 安全风险： DNS 劫持； 缓存投毒； DDoS； 子域接管； 泄露内部域名； 邮件伪造。防护： 方案 作用 DNSSEC 签名验证，防篡改 DNS over TLS / HTTPS 加密本地到递归的查询 CAA 限制证书签发机构 SPF / DKIM / DMARC 邮件域保护 子域治理 清理悬挂 CNAME 权限控制 防止记录被误改 DoH/DoT 加密查询链路，但不改变递归 DNS 可以看到目标域名这一事实。本章小结DNS 通过分层委托和递归查询完成域名到 IP 的转换，A、AAAA、CNAME、NS 和 TXT 等记录承载不同语义。TTL 决定缓存和切换速度，DNS 调度适合粗粒度入口选择，不能替代负载均衡和服务发现。排查 DNS 应从本机 resolver 到公共 DNS 再到权威 DNS 逐层验证，同时关注 IPv6、缓存和应用刷新策略。思考题 递归查询和迭代查询分别由谁执行？ 切换公网服务 IP 前，DNS TTL 应如何操作？ 为什么 DNS 权重调度不精确？ dig +trace 能帮助定位什么问题？ 设计一套内部服务的 DNS 超时、缓存和降级策略。
• 这是《计算机网络 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。TCP 调优不是复制一份“高性能参数”。不同业务形态对应不同瓶颈：短连接服务要关注 TIME_WAIT 和队列，长肥管道要关注窗口和 BDP，高并发服务要关注 fd、内存和 IO 模型，容器和云环境还要关注 MTU、安全组和连接追踪表。12.1 常用观测命令ss -sss -antss -iss -lntnetstat -snstat -azip -s linktc qdisc show重点指标： 指标 含义 retrans 重传 rtt / rttvar 往返时延和抖动 cwnd 拥塞窗口 unacked 未确认数据 recv-q / send-q 队列 listen drops 监听队列丢弃 rx_dropped 网卡或内核丢包 conntrack full 连接追踪表满 12.2 文件描述符与端口查看 fd 上限：ulimit -ncat /proc/sys/fs/file-maxcat /proc/sys/fs/file-nr查看进程 fd：ls /proc/<pid>/fd | wc -l客户端临时端口：sysctl net.ipv4.ip_local_port_rangesysctl net.ipv4.tcp_tw_reuse端口耗尽原因： 频繁新建连接； 目标地址和端口单一； TIME_WAIT 未释放； 压测并发设计不合理； 连接池未生效。优先使用长连接和多个目标 VIP，而不是盲目扩大端口范围。12.3 缓冲区调优自动调节：sysctl net.ipv4.tcp_rmemsysctl net.ipv4.tcp_wmemsysctl net.core.rmem_maxsysctl net.core.wmem_max典型格式：min default max判断是否需要调整： 吞吐远低于带宽； RTT 高； cwnd 或窗口受限； 丢包低； 大文件或流式传输场景。不要在低 RTT 内网小请求服务上机械放大缓冲区，可能增加内存占用和排队。12.4 队列与 backlog应用监听 backlog：listen(fd, backlog)内核参数：sysctl net.core.somaxconnsysctl net.ipv4.tcp_max_syn_backlog有效 accept 队列上限通常受 min(somaxconn, application backlog) 影响。调优流程： 观察 ss -lnt； 查看 listen overflow/drop； 判断应用 accept 是否慢； 增大 backlog； 优化 IO 和线程模型； 增加前置限流。12.5 TIME_WAIT 治理查看：ss -ant state time-wait | wc -l优先： 启用连接池； HTTP Keep-Alive； gRPC 长连接； 数据库连接复用； 降低无效重试频率。Linux 客户端可在特定场景使用：sysctl net.ipv4.tcp_tw_reuse不要盲目设置 tcp_tw_recycle，该参数在 NAT 环境有严重问题，较新内核中已移除。12.6 连接追踪与防火墙有状态防火墙和 NAT 会维护 conntrack 表：sysctl net.netfilter.nf_conntrack_maxcat /proc/sys/net/netfilter/nf_conntrack_count表满现象： 新建连接失败； 日志 nf_conntrack: table full; 丢包； 重启或清理后恢复； 高并发容器宿主机明显。处理： 增大表容量； 缩短超时； 减少无意义短连接； 拆分流量到多宿主机； 使用无状态规则； 控制异常扫描。12.7 MTU 与 MSS 问题典型症状： 握手成功； 小包正常； 大包卡住； TLS 证书阶段失败； VPN、容器和 overlay 环境明显。排查：ip linkping -M do -s 1472 <target>tracepath <target>tcpdump -i eth0 'icmp[icmptype] == icmp-unreach' -nn处理： 统一路径 MTU； 调整 overlay 封装开销； 使用 MSS Clamp； 放行 PMTUD ICMP； 开启 TCP MTU probing 需评估。12.8 长连接服务疑难问题空闲断开原因： LB 空闲超时； 防火墙会话超时； NAT 超时； 应用未处理半开连接； 服务端主动回收。处理： 应用心跳间隔小于最低超时； 读空闲写事件触发； 客户端断线重连； 服务端推送心跳； 核对 LB 参数。连接假活现象： ESTABLISHED 存在； 对端已宕机； 发送后才发现失败。处理： TCP keepalive； 应用层心跳； 业务级健康检查； 请求超时和快速失败； 连接池驱逐。12.9 调优模板高并发短连接服务：增大 somaxconn 和应用 backlog控制重试风暴启用 SYN Cookie监控 listen drops评估 TIME_WAIT前置限流高吞吐长连接服务：启用连接池和 Keep-Alive评估 BDP 和缓冲区选择拥塞算法监控 cwnd / retrans / RTT隔离批量流量容器宿主机：检查 fd 和 conntrack统一 MTU限制每 Pod 连接监控 softnet评估 IRQ 和队列本章小结TCP 调优必须从观测开始，区分监听队列、fd、端口、缓冲区、拥塞窗口、conntrack、MTU 和应用连接管理问题。短连接重点治理 TIME_WAIT 和重试，长连接重点治理心跳、窗口和吞吐。任何参数修改都应有监控、回滚和压测验证。思考题 ss -lnt 的 Recv-Q 和 Send-Q 在 LISTEN 状态表示什么？ 临时端口耗尽时应优先做哪些改造？ conntrack 表满会有什么表现？ 为什么 tcp_tw_recycle 不适合 NAT 环境？ 写一份高并发网关的 TCP 参数和监控清单。
• 这是《计算机网络 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。TCP 连接有明确的生命周期状态。状态分布是生产排障的重要证据：SYN_RECV 异常可能意味着攻击或队列问题，CLOSE_WAIT 堆积指向应用泄漏，FIN_WAIT 长期挂起可能说明对端或中间链路异常。11.1 状态总览 LISTEN |收到 SYN，发送 | 客户端发送 SYNSYN+ACK vSYN_RECV SYN_SENT | |收到 ACK | 收到 SYN+ACK，发送 ACK v v ESTABLISHED |主动 FIN / 被动 FIN | | v vFIN_WAIT_1 CLOSE_WAIT | |收到 ACK 应用 close v vFIN_WAIT_2 LAST_ACK | |收到 FIN，发送 ACK | 收到 ACK v vTIME_WAIT CLOSED |2MSL vCLOSED11.2 建连阶段状态 状态 位置 含义 LISTEN 服务端 等待连接 SYN_SENT 客户端 已发送 SYN SYN_RECV 服务端 已收到 SYN 并回复 SYN+ACK 异常： 客户端长期 SYN_SENT：网络不可达、丢包、防火墙丢包； 服务端大量 SYN_RECV：SYN Flood、队列满、应用未及时处理； 客户端收到 RST：端口未监听或策略拒绝； 握手完成后立即断开：LB 健康检查或应用异常。查看：ss -ant state syn-recvss -ant state syn-sent11.3 传输阶段状态ESTABLISHED 表示连接可用，但不代表业务健康。观察：ss -ntp state establishedss -i关注： 连接数量； 进程归属； 收发队列； RTT 和重传； 空闲时间； 对端地址分布。11.4 关闭阶段状态 状态 出现位置 含义 FIN_WAIT_1 主动关闭方 已发 FIN，未收到 ACK FIN_WAIT_2 主动关闭方 收到 ACK，等待对端 FIN CLOSE_WAIT 被动关闭方 收到 FIN，等待应用 close LAST_ACK 被动关闭方 已发 FIN，等待最后 ACK TIME_WAIT 主动关闭方 等待旧报文消失 CLOSING 双方同时关闭 少见 FIN_WAIT_1长期堆积可能表示 FIN 或 ACK 丢失，以及对端或中间链路异常。FIN_WAIT_2主动方已关闭一个方向，等待对端 FIN。若对端应用长期不关闭，连接可能停留。Linux 可通过 FIN_WAIT_2 超时控制孤儿连接回收。LAST_ACK被动方发送 FIN 后等待 ACK，如果 ACK 丢失可能停留并重传 FIN。11.5 状态监控命令统计状态：ss -ant | awk 'NR>1 {count[$1]++} END {for (s in count) print s, count[s]}'查看特定进程：ss -ntp | grep <pid>查看监听队列：ss -lnt内核统计：nstat -az | grep -E 'TcpExtListen|TcpRetrans|TcpEstabResets'netstat -s11.6 状态与故障定位 状态 常见原因 处理 SYN_SENT 多 出口网络、目标不可达 路由、防火墙、服务监听 SYN_RECV 多 突发建连或攻击 backlog、SYN Cookie、限流 CLOSE_WAIT 多 应用未 close 修复连接泄漏 TIME_WAIT 多 短连接 连接复用、长连接 FIN_WAIT 多 对端或链路异常 抓包和对端排查 ESTABLISHED 过多 连接池失控 上限、隔离、审计 11.7 同时打开与同时关闭同时打开双方同时向对方发送 SYN，可能进入：SYN_SENT -> SYN_RECV -> ESTABLISHED同时打开较罕见，通常出现在对等连接和测试环境中。同时关闭双方同时发送 FIN：ESTABLISHED -> FIN_WAIT_1 -> CLOSING -> TIME_WAIT11.8 状态机排障案例案例 1：服务偶发连接失败现象：客户端 SYN 超时服务端 CPU 正常SYN_RECV 突增listen overflow 增长处理： 增大 backlog； 检查应用 accept 循环； 优化线程池； 前置限流； 排查重试风暴。案例 2：重启后 fd 耗尽现象：ss -ant state close-wait | wc -l结果很高，进程重启后恢复，运行数小时再次耗尽。根因通常是异常分支没有关闭 socket 或 HTTP 响应体。修复资源释放，而不是单纯增大 fd 上限。本章小结TCP 状态机描述连接从监听、握手、传输到关闭的生命周期。建连阶段重点看 SYN_SENT、SYN_RECV 和监听队列；传输阶段看 ESTABLISHED 与重传；关闭阶段用 TIME_WAIT 和 CLOSE_WAIT 区分短连接与连接泄漏。状态分布结合进程、fd、队列和抓包，可以快速定位网络或应用责任。思考题 画出客户端和服务端完整的 TCP 状态迁移图。 CLOSE_WAIT 出现在哪一方？为什么？ 哪些证据能判断服务端监听队列溢出？ FIN_WAIT_2 长期存在说明什么？ 设计一套 TCP 状态监控告警规则。
• 这是《计算机网络 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。流量控制保护接收方，拥塞控制保护网络。TCP 拥塞控制通过拥塞窗口、慢启动、拥塞避免、快速恢复和多种算法，在丢包或时延信号中探测可用容量。理解拥塞控制，才能解释为什么跨地域长肥网络吞吐低、为什么少量丢包影响巨大、为什么 BBR 在弱网下表现不同。10.1 拥塞窗口与接收窗口实际发送窗口：send window = min(cwnd, rwnd) 窗口 保护对象 rwnd 接收方处理和缓冲能力 cwnd 网络承载能力 拥塞控制演进： 阶段 算法 核心信号 传统 Tahoe / Reno 丢包 改进 NewReno、SACK 丢包恢复 时延 Vegas RTT 增长 现代内核常用 CUBIC 丢包，三次函数窗口增长 基于带宽时延 BBR 带宽与 RTT 查看当前算法：sysctl net.ipv4.tcp_congestion_control查看可用算法：sysctl net.ipv4.tcp_available_congestion_control10.2 慢启动初始窗口较小，每个 RTT 内近似指数增长：RTT 1: cwnd = 10RTT 2: cwnd = 20RTT 3: cwnd = 40达到慢启动阈值后进入拥塞避免：cwnd < ssthresh：慢启动cwnd >= ssthresh：拥塞避免慢启动并不慢，它的起点低但增长快。短连接可能刚完成慢启动就关闭，无法充分利用带宽。10.3 拥塞避免与丢包响应拥塞避免阶段线性增长：每个 RTT cwnd 增加约 1 MSS发生超时：ssthresh = cwnd / 2cwnd = 初始窗口重新慢启动快速重传触发：ssthresh = cwnd / 2cwnd 降半并进入快速恢复传统丢包算法在高 RTT、高带宽和少量随机丢包网络中吞吐受限。10.4 CUBICCUBIC 使用三次函数调整窗口，相比 Reno 对高带宽长延迟网络更友好。特点： 窗口增长与 RTT 关联较弱； 大窗口网络收敛更快； 仍以丢包为主要拥塞信号； 是许多 Linux 版本的默认算法之一； 深缓冲网络可能出现缓冲膨胀。10.5 BBRBBR 估算瓶颈带宽和最小 RTT，目标是让发送速率接近 BDP，而不是持续填满缓冲区。核心指标：delivery rate：交付速率min RTT：路径最小往返时延特点： 优势 注意 弱网和高丢包下吞吐更稳 需要内核版本支持 减少缓冲膨胀 与 CUBIC 竞争时公平性需评估 适合跨地域长肥网络 参数调优复杂 降低排队延迟 不能替代容量规划 10.6 缓冲膨胀路径中缓冲区过大时：cwnd 持续增长 -> 队列变长 -> RTT 上升 -> 交互延迟变大现象： 吞吐不低； RTT 显著上升； 语音和游戏卡顿； 大文件传输影响小请求。缓解： 使用 BBR 或时延敏感算法； 队列管理，如 FQ-CoDel； 限速大流量； 业务流量隔离； 升级链路或分流。Linux 队列规则：tc qdisc show10.7 拥塞控制与业务吞吐常见吞吐异常： 现象 可能原因 单连接吞吐低 RTT 高、窗口小、丢包 多连接吞吐高 单流受拥塞控制限制 偶发长尾 重传、队列、路由切换 高峰下降 带宽拥塞 上传下载差异 路径不对称 新内核变化 CC 算法或队列规则变化 排查：ss -i dst 10.20.1.10cat /proc/net/netstatnetstat -s | grep -i retrans重点指标： RTT； retrans； cwnd； unacked； 丢包率； 实际吞吐。10.8 多流公平性同一瓶颈上的多条 TCP 流会竞争带宽。传统算法通过窗口减半和探测逼近公平，但不同算法、不同 RTT 和非 TCP 流竞争时结果不同。生产建议： 大文件传输与在线交易流量隔离； 备份任务限速； 使用 QoS 标识关键流量； 避免批量任务与用户请求共享同一出口； 监控队列和重传； 跨地域传输优先就近和分片并行。本章小结拥塞控制通过 cwnd 探测网络容量，慢启动指数增长，拥塞避免线性增长，丢包后减半或重新慢启动。CUBIC 改善高带宽长延迟网络表现，BBR 基于带宽和 RTT 降低对丢包和缓冲的依赖。吞吐问题应同时看 RTT、丢包、窗口、队列和并发流数量。思考题 rwnd 和 cwnd 分别保护什么？ 慢启动为什么是指数增长却叫慢启动？ 超时重传和快速重传后的窗口变化有什么不同？ 为什么 BBR 在弱网下可能优于 CUBIC？ 写一份跨地域文件传输吞吐低的排查清单。
• 这是《计算机网络 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。TCP 的可靠性建立在序列号、确认应答、超时重传、快速重传、滑动窗口和流量控制之上。它保证字节流有序、不丢、不重复，但不保证时延，也不保证应用语义成功。9.1 序列号与确认号Seq：本报文段数据第一个字节在字节流中的编号ACK：期望下一个收到的字节编号示例：Sender -> Seq=1000, 100 bytesReceiver -> ACK=1100确认号表示 1100 之前的字节已收到。累积确认：收到 100-199、200-299、300-399ACK=400 表示 400 前全部收到如果只收到 100-199 和 300-399，累积 ACK 只能到 200；SACK 可以补充说明 300-399 也已收到。9.2 超时重传TCP 根据 RTT 动态计算 RTO：SRTT：平滑 RTTRTTVAR：RTT 方差RTO：重传超时简化关系：RTO 略大于 SRTT + 若干倍 RTTVAR超时后： 重传最早未确认数据； 通常指数退避 RTO； 拥塞窗口收缩； 吞吐下降。高 RTT 链路中，一次丢包的恢复成本远高于低 RTT 链路，因此跨地域系统要减少请求轮次。9.3 快速重传接收方每收到一个失序段，重复发送当前期望 ACK：Sender -> Seq=100Sender -> Seq=200Sender -> Seq=300Sender -> Seq=400Receiver -> ACK=200Receiver -> ACK=200Receiver -> ACK=200Receiver -> ACK=200发送方收到 3 个重复 ACK 后，不必等超时，立即重传丢失段。9.4 SACKSACK 允许接收方告知已收到的不连续区间：ACK = 200SACK = 300-400SACK = 500-600发送方可以更准确判断只重传缺失部分。Linux 通常默认启用：sysctl net.ipv4.tcp_sack9.5 滑动窗口发送窗口由接收窗口和拥塞窗口共同限制：effective window = min(rwnd, cwnd)发送方窗口移动：已发送已确认 | 已发送未确认 | 可发送未发送 | 不可发送 <-------- 发送窗口 -------->接收方通过窗口通告控制对端发送量： 应用读取慢，接收缓冲堆积； 接收窗口缩小； 窗口为 0 时发送方暂停； 接收方窗口打开后发送窗口更新； 持续零窗口会触发探测和超时。查看：ss -i重点关注：cwndrwndrttretransunacked9.6 窗口缩放TCP 头部窗口字段最大 65535 字节。Window Scale 选项允许扩大窗口：实际窗口 = 头部窗口值 << shift高带宽长延迟网络需要大窗口：BDP = bandwidth × RTT示例：带宽 100 MbpsRTT 50 msBDP = 100,000,000 / 8 × 0.05 = 625,000 字节若窗口小于 BDP，即使带宽充足，吞吐也上不去。9.7 Nagle 与 Delayed ACKNagle 减少小包：只有所有数据都被确认，或积攒到 MSS，才发送新的小段Delayed ACK 延迟发送 ACK，希望合并响应。两者组合可能带来延迟：发送方等待 ACK 或攒包接收方延迟 ACK-> 小请求延迟上升低延迟交互系统通常关闭 Nagle：TCP_NODELAY查看：sysctl net.ipv4.tcp_low_latency注意：关闭 Nagle 会增加小包数量，应结合业务形态评估。9.8 零窗口与粘包零窗口现象： 发送暂停； 接收窗口为 0； 接收应用处理慢； 连接长期空闲但未断开。排查 ss -i 和应用读取逻辑。TCP 粘包与半包TCP 是字节流，没有消息边界：write("A1")write("B2")对端可能一次读到 "A1B2"应用协议需要定义边界： 固定长度； 分隔符； 长度前缀； HTTP 头部长度加 body； RPC 协议帧。示例长度前缀：| 4 字节长度 | payload |9.9 可靠性误区 TCP 可靠不等于请求一定成功； 重传可能带来长尾延迟； 连接存活不等于服务健康； 有序性可能造成队头阻塞； 发送成功只代表进入内核发送队列； 应用仍需要幂等、超时和业务确认； 大量重传可能表现为应用超时。本章小结TCP 通过序列号和确认号标识字节流，通过超时重传、快速重传和 SACK 恢复丢失，通过滑动窗口和接收窗口控制发送节奏。窗口小于带宽时延积会限制吞吐，Nagle 与 Delayed ACK可能影响小请求延迟，字节流特性要求应用自行划分消息边界。思考题 累积确认和 SACK 有什么区别？ 为什么三次重复 ACK 可以触发快速重传？ 计算 1Gbps、30ms RTT 链路的 BDP。 TCP 为什么会出现粘包和半包？ 为什么 TCP 可靠传输仍需要应用层重试和幂等？
• 这是《计算机网络 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。TCP 提供面向连接、可靠、有序的字节流服务。连接管理的核心包括三次握手、序列号同步、选项协商、数据传输、四次挥手、半关闭和异常复位。生产中大量“连接超时”“连接重置”“TIME_WAIT 过多”问题都与这一层有关。8.1 三次握手Client Server | --- SYN, Seq=x ------------> | | <-- SYN+ACK, Seq=y, ACK=x+1 | | --- ACK, ACK=y+1 ----------> |为什么需要三次？ 双方同步初始序列号； 双方确认发送和接收能力； 防止历史重复连接请求造成错误状态； 协商窗口、MSS、窗口缩放、SACK 等选项。握手耗时至少 1 RTT。跨城或跨洲请求中，连接建立本身就是明显延迟来源，因此长连接和会话复用很重要。8.2 初始序列号TCP 用序列号标识字节流位置：SYN 消耗一个序列号数据字节逐字节递增FIN 消耗一个序列号初始序列号不能从固定值开始，否则旧连接的重复包可能被误认为新连接数据。现代系统会使用随机初始序列号。8.3 TCP 选项 选项 作用 MSS 最大段大小 Window Scale 扩大窗口 SACK Permitted 选择性确认 Timestamps RTT 测量和序号回绕 ALPN TLS 应用协议协商，位于 TLS 扩展而非 TCP 选项 查看握手：tcpdump -i eth0 'tcp[tcpflags] & (tcp-syn|tcp-ack) != 0' -nn8.4 半连接与全连接队列Linux 中服务端有两个关键队列：SYN Queue：收到 SYN，未完成握手Accept Queue：握手完成，等待应用 accept()观察：ss -lntnetstat -s | grep -E 'SYN|listen|overflow|drop'ss -lnt 示例：State Recv-Q Send-Q Local Address:PortLISTEN 0 1024 0.0.0.0:8080在 LISTEN 状态，Send-Q 表示 accept 队列上限，Recv-Q 表示当前完成握手但尚未被应用取走的连接数。溢出表现： 客户端连接超时或重置； 服务端 CPU 不高但建连失败； 监听队列溢出计数增长； SYN 重传； 应用 accept 速度不足。处理： 增大监听 backlog； 优化应用 accept 和 IO 模型； 调整线程池； 前置负载均衡； 限制异常连接速率； 检查 SYN Flood 防护。8.5 四次挥手主动关闭方 被动关闭方 | --- FIN, Seq=u -------------> | | <-- ACK, ACK=u+1 ------------ | | <-- FIN, Seq=v, ACK=u+1 ----- | | --- ACK, ACK=v+1 -----------> |为什么是四次？TCP 全双工，两个方向分别关闭。被动方收到 FIN 后可能还有数据要发，因此 ACK 和 FIN 可以分开发送，也可以合并。8.6 TCP 状态LISTENSYN_RECVESTABLISHEDFIN_WAIT_1FIN_WAIT_2TIME_WAITCLOSE_WAITLAST_ACKCLOSINGCLOSED查看：ss -antss -ant state time-waitss -ant state close-waitTIME_WAIT出现在主动关闭方，通常持续 2MSL。作用： 让旧连接重复包在网络中消失； 保证最后一个 ACK 可被对方收到； 避免新旧连接序列号冲突。大量 TIME_WAIT 的常见原因： 客户端频繁新建短连接； 每次请求都关闭连接； 连接池配置过小； 服务端主动关闭导致客户端侧堆积； 压测工具并发模式造成。优先方案是连接复用和长连接，而不是盲目开启端口重用。CLOSE_WAIT出现在被动关闭方，表示对方已关闭，本方应用还没调用 close。大量 CLOSE_WAIT 常见原因： 应用连接泄漏； 未正确关闭响应体或 socket； 异常路径缺少 finally close； 线程阻塞； 连接池生命周期错误。排查方向在应用代码，而不是网络设备。8.7 RST 与异常关闭触发 RST 的常见场景： 访问未监听端口； 队列溢出或策略拒绝； 应用崩溃； 强制关闭 socket； 防火墙或 LB 断开； 请求已超时后被服务端丢弃； keepalive 探测失败。表现：Connection reset by peerECONNRESET排查：ss -lntptcpdump -i eth0 tcp port 8080 and 'tcp[tcpflags] & tcp-rst != 0' -nn8.8 Keepalive 与应用心跳TCP keepalive 用于检测死连接：sysctl net.ipv4.tcp_keepalive_timesysctl net.ipv4.tcp_keepalive_intvlsysctl net.ipv4.tcp_keepalive_probes局限： 默认探测周期较长； 只能发现连接死活，不能证明服务可用； 中间设备可能提前断开空闲连接； 应用层仍需业务心跳和超时。生产长连接应使用应用层心跳：客户端定期 PING服务端超时未收到则断开连续失败后客户端重连心跳间隔小于中间设备空闲超时8.9 连接管理实践客户端： 使用连接池； 设置连接建立超时； 控制最大连接数； 重试必须幂等； 借出前检测连接健康； 空闲时间小于 LB 超时； 关闭响应体和流。服务端： 合理设置 backlog； accept 后尽快读取； 限制单 IP 连接； 设置读写空闲超时； 优雅关闭； 监控连接状态分布； 对异常 RST 抓包。本章小结TCP 通过三次握手同步序列号并协商选项，通过四次挥手关闭两个方向。Linux 的 SYN 队列和 accept 队列决定突发建连能力；TIME_WAIT 多与短连接有关，CLOSE_WAIT 多与应用连接泄漏有关。RST、keepalive、心跳和连接池是连接治理的关键点。思考题 三次握手为什么不能简化为两次？ SYN Queue 和 Accept Queue 分别在什么阶段？ TIME_WAIT 和 CLOSE_WAIT 分别出现在哪一方？ 大量 CLOSE_WAIT 应优先排查网络还是应用？ 设计一套后端服务长连接心跳和重连策略。
• 这是《计算机网络 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。UDP 是无连接、不可靠、面向数据报的传输协议。它没有连接建立、重传、排序、流量控制和拥塞控制，因此代价小、延迟低，但也把可靠性问题交给了应用层。DNS、NTP、视频通话、游戏和 QUIC 都运行在 UDP 上。7.1 UDP 头部UDP 头部只有 8 字节：| Source Port | Destination Port || Length | Checksum |与 TCP 相比： 维度 TCP UDP 连接 有 无 可靠 重传确认 尽力而为 顺序 字节流有序 数据报可能乱序 流控 滑动窗口 无 拥塞控制 有 无 头部 至少 20 字节 8 字节 边界 字节流 保留数据报边界 UDP 保留消息边界。发送两次数据报，接收方通常按两次读取；TCP 则是连续字节流，需要应用协议划分消息。7.2 UDP 适用场景适合： 实时音视频，宁可丢帧也不愿等待重传； 游戏同步，低延迟优先； DNS 查询，一问一答； 广播或多播； 内网服务发现； 作为 QUIC 的底层承载； 高频遥测，允许少量丢失。不适合： 转账、下单等强一致业务； 大文件可靠传输； 需要严格顺序且不可丢的日志； 未经治理的公网大规模服务； 没有应用层确认与限流的请求响应。7.3 使用 UDP 的代价UDP 简化了协议，但复杂度不会消失，而是转移到应用层： 问题 应用层方案 丢包 序号、ACK、重传或 FEC 乱序 序号重组 重复 去重 流控 接收窗口或速率限制 拥塞控制 自定义 CC 或基于带宽探测 身份安全 DTLS 或自定义加密 连接管理 会话 ID、心跳、超时 QUIC 正是这种思路：基于 UDP，在用户态实现可靠流、多路复用、加密和现代拥塞控制。7.4 Linux UDP 缓冲区UDP 没有发送缓冲的重传语义，但内核仍需要队列。查看：sysctl net.core.rmem_maxsysctl net.core.wmem_maxsysctl net.core.rmem_defaultsysctl net.core.wmem_default查看统计：ss -lunnetstat -su关注： RcvbufErrors：接收缓冲不足； SndbufErrors：发送缓冲不足； InErrors：校验和等错误； InDatagrams / OutDatagrams； receive errors 增长。如果 UDP 接收方处理慢，包会被直接丢弃，不会像 TCP 一样通过窗口通知发送方减速。7.5 UDP 编程示例服务端：import socketserver = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)server.bind(("0.0.0.0", 9000))while True: data, addr = server.recvfrom(4096) server.sendto(b"ack:" + data, addr)客户端：import socketclient = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)client.settimeout(2)for i in range(3): client.sendto(f"ping-{i}".encode(), ("127.0.0.1", 9000)) try: data, _ = client.recvfrom(4096) print(data.decode()) except socket.timeout: print("timeout")如果没有超时，一次丢包就可能让客户端永久等待。7.6 NAT 与 UDPUDP 无连接，NAT 映射通常依赖超时维护：内网主机发送 UDP -> NAT 创建五元组映射 -> 空闲超时后删除 -> 对端再发送无法进入应用层常见方案： 心跳保活； STUN 获取公网映射； TURN 中继； ICE 收集候选地址； 连接迁移时使用会话标识。QUIC 使用 Connection ID 帮助在地址变化后恢复连接，但路径和 NAT 仍需正确处理。7.7 UDP 排障# 查看监听ss -lunp# 测试连通性nc -u -v 10.20.1.10 9000# 抓包tcpdump -i eth0 udp port 9000 -nn# 统计netstat -su排障要点： 双端是否都使用 UDP； 是否单向可达； 安全组是否放行； 接收队列是否溢出； 应用是否阻塞； 数据报是否超过路径 MTU； NAT 映射是否超时； 是否存在丢包和乱序。本章小结UDP 提供低开销、无连接的数据报传输，保留消息边界，但不提供可靠、有序、流控和拥塞控制。实时音视频、DNS、游戏和 QUIC 适合 UDP，而关键业务必须由应用层补足可靠性。UDP 排障要关注接收缓冲丢弃、单向可达、NAT 超时和路径 MTU。思考题 TCP 和 UDP 对消息边界的处理有什么不同？ 为什么实时视频可以接受少量丢包？ UDP 接收方处理慢会发生什么？ QUIC 为什么基于 UDP 而不是直接修改 TCP？ 设计一个可靠的 UDP 协议需要哪些字段和机制？
• 这是《计算机网络 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。ICMP 常被当作 ping 的附属协议，但它同时承担错误报告、路径探测、PMTUD 和 IPv6 邻居发现等功能。错误地全面封禁 ICMP 会带来两类问题：排障困难，以及大包传输的 PMTUD 失效。6.1 ICMP 的定位ICMP 巐藏在 IP 协议号 1 中，用于传递控制和错误消息。它不是应用数据的承载协议。常见类型： 类型 名称 场景 0 / 8 Echo Reply / Request ping 3 Destination Unreachable 网络、主机、端口不可达 5 Redirect 建议更优路径 11 Time Exceeded TTL 超时，traceroute 12 Parameter Problem 包头错误 3 / Code 4 Fragmentation Needed PMTUD 6.2 ping基础用法：ping 10.20.1.10ping -c 100 10.20.1.10ping -i 0.2 10.20.1.10ping -6 2001:db8::1指定不分片并测试载荷：ping -M do -s 1472 10.20.1.10计算：ICMP Header 8 字节IP Header 20 字节1472 + 8 + 20 = 1500如果 1472 不通而 1400 通，路径 MTU 可能小于 1500。6.3 丢包解读ping 结果需要区分三种情况： 全部不通：路由、地址、ACL 或目标不可达； 部分丢包：链路质量、队列拥塞、限速或负载不均； 请求正常但应用失败：传输层或应用层问题。注意： 目标可能禁 ping 但服务可用； 中间设备可能限速 ICMP； ping 通不代表端口开放； ping 的 RTT 低不代表高负载时服务不排队； ICMP 走的路径可能与业务流量不同。6.4 Destination Unreachable常见代码： Code 含义 0 Network Unreachable 1 Host Unreachable 2 Protocol Unreachable 3 Port Unreachable 4 Fragmentation Needed 5 Source Route Failed 例如 UDP 访问未监听端口，通常触发 Port Unreachable。路由器找不到路径时返回 Network/Host Unreachable。6.5 traceroute用法：traceroute 10.20.1.10traceroute -I 10.20.1.10traceroute -T -p 443 10.20.1.10traceroute -U -p 53 10.20.1.10mtr -rw -c 100 10.20.1.10协议差异： 方式 特点 UDP 默认，可能被策略影响 ICMP 常用，可能被限速 TCP 更接近业务端口路径 mtr 更适合观察持续趋势：mtr -rw -c 200 -T -P 443 10.20.1.106.6 PMTUD路径 MTU 发现依赖 ICMP Fragmentation Needed。错误做法：防火墙禁用所有 ICMP -> 路由器无法返回分片要求 -> 发送方持续重传大包 -> TCP 大流量卡住处理： 放行 ICMP Type 3 Code 4； 正确设置隧道和 overlay MTU； TCP 启用 MSS Clamp； 云主机、容器、负载均衡和安全设备统一评估； 用 ping -M do 或 tracepath 验证。Linux 相关：sysctl net.ipv4.ip_no_pmtu_discsysctl net.ipv4.tcp_mtu_probing6.7 ICMP 与安全风险： ICMP 泛洪； 主机探测； 重定向攻击； 大包放大； 隐藏侧信道。安全策略： 允许必要的错误报告； 限制 Echo 速率； 不盲目放行所有 ICMP； 关闭不必要的 ICMP Redirect 接受； 云安全组分层治理； 保留运维专用探测通道。Linux 示例：sysctl net.ipv4.conf.all.accept_redirectssysctl net.ipv4.conf.all.send_redirects6.8 排障案例案例 1：服务访问超时ping <target>mtr -rw -c 100 <target>traceroute -T -p 443 <target>curl -v --connect-timeout 3 https://target结论判断： ping 不通且 traceroute 断在网关：本机路由或网关问题； ping 通但 TCP 不通：安全组、防火墙或服务未监听； 某跳后延迟暴涨：路径或出口异常； 丢包与业务高峰相关：拥塞或带宽打满； 只有 IPv6 异常：AAAA、NDP 或防火墙策略。案例 2：小包正常，大包失败ping -M do -s 1472 <target>ping -M do -s 1400 <target>tracepath <target>优先检查 VPN、隧道、云 overlay 和容器网络的 MTU。本章小结ICMP 承担错误报告、连通性测试、路径探测和 PMTUD 等关键功能。ping 是基础工具，但必须结合端口探测、应用请求和 traceroute 判断问题层级。全面封禁 ICMP 可能造成大包传输异常和排障困难，应精确放行错误报告类消息。思考题 ping 通但 HTTP 超时，可能有哪些原因？ ICMP Type 3 Code 4 在 PMTUD 中有什么作用？ traceroute 中间跳超时是否一定表示故障？ 为什么推荐用 TCP traceroute 验证业务端口路径？ 设计一份兼顾安全和可观测性的 ICMP 策略。
• 这是《计算机网络 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。IP 负责跨网络寻址，但帧必须使用链路层地址交付。IPv4 通过 ARP 将 IP 映射为 MAC，IPv6 通过 NDP 完成类似工作。ARP 问题通常表现为“偶尔能通”“切换后旧地址残留”“IP 冲突”或“同网段部分主机不可达”。5.1 ARP 解决什么问题同一二层网络内，主机需要知道下一跳 MAC：源 IP：192.168.1.10源 MAC：AA:AA:AA:AA:AA:AA下一跳 IP：192.168.1.1下一跳 MAC：BB:BB:BB:BB:BB:BB跨网段访问时，ARP 请求的对象通常是网关，而不是最终目标服务器。5.2 ARP 工作流程1. 主机查缓存2. 未命中则广播 ARP Request3. 目标主机单播回复 ARP Reply4. 请求方写入缓存5. 后续帧使用该 MAC查看 IPv4 ARP：ip neigh showarp -n状态可能包括： 状态 含义 REACHABLE 最近确认可达 STALE 缓存过期，待确认 DELAY / PROBE 延迟或主动探测 FAILED 解析失败 INCOMPLETE 请求进行中 手工清理：ip neigh del 192.168.1.1 dev eth0生产中不要把清 ARP 当作根因修复，只能作为验证手段。5.3 抓包观察 ARPtcpdump -i eth0 arp典型输出字段：ARP, Request who-has 192.168.1.1 tell 192.168.1.10ARP, Reply 192.168.1.1 is-at bb:bb:bb:bb:bb:bb判断： 只有 Request 没有 Reply：目标不在同网段、链路异常、防火墙拦截或地址不存在； Reply 的 MAC 不符合预期：IP 冲突、切换残留或中间代理； 大量 ARP Request：广播域过大或存在扫描； ARP 缓存频繁变化：高可用切换或异常。5.4 ARP 缓存与故障切换服务漂移后，调用方 ARP 可能仍是旧机器。典型时间线：1. VIP 从节点 A 漂移到节点 B2. 节点 B 发送免费 ARP3. 部分交换机或主机立即更新4. 部分旧缓存仍指向 A5. 请求在缓存刷新前失败缓解： 发送多次免费 ARP； 调整交换机 MAC 表老化策略； 使用负载均衡健康检查； 客户端增加重试； 保持连接池可重建； 演练切换并观察恢复时间。5.5 IP 冲突现象： 连接时通时断； 抓包看到同一 IP 多个 MAC 回复； 系统日志出现地址冲突； 高可用切换后冲突； 容器网络误用同网段。排查：ip neigh show 192.168.1.100tcpdump -i eth0 arp host 192.168.1.100处理： 下线冲突地址； 检查 DHCP 静态绑定； 检查容器地址池； 检查漂移脚本； 建立 IP 地址管理系统。5.6 ARP 安全风险ARP 没有认证，同二层攻击者可以发送虚假 Reply。风险： 攻击 效果 ARP 欺骗 劫持流量 ARP 泛洪 消耗资源 MAC 泛洪 溢出交换机表 中间人攻击 窃听或篡改 防护： 划小 VLAN； 交换机绑定 IP-MAC-Port； DHCP Snooping； Dynamic ARP Inspection； 端口安全； 敏感系统使用 TLS； 内部链路也启用证书校验。TLS 不能阻止 ARP 欺骗，但可以降低被窃听和篡改的风险。5.7 IPv6 Neighbor DiscoveryIPv6 使用 ICMPv6 的 NDP： 报文 作用 Neighbor Solicitation 请求邻居链路地址 Neighbor Advertisement 回复邻居信息 Router Solicitation 请求路由器 Router Advertisement 发布路由和前缀 查看：ip -6 neightcpdump -i eth0 icmp6NDP 常见问题： 防火墙拦截 ICMPv6； RA 配置错误； 前缀或网关缺失； 地址选择策略导致走 IPv6 失败； 双栈环境 A/AAAA 优先级问题。5.8 排障流程同网段无法通信：ip addrip routeip neighping <target>tcpdump -i eth0 arp or icmp判断： IP 和掩码是否正确； 是否误把跨网段目标当同网段； ARP 是否有回复； MAC 是否符合预期； 交换机是否学到端口； VLAN 是否一致； 是否存在 IP 冲突； 防火墙是否拦截。本章小结ARP 将 IPv4 地址映射为 MAC 地址，NDP 在 IPv6 中承担邻居和路由发现职责。ARP 缓存、免费 ARP、IP 冲突和二层攻击都会造成难以复现的连接问题。排查同网段通信要看地址、掩码、邻居状态、ARP 报文、交换机 MAC 表和 VLAN。生产环境应通过 VLAN、端口安全、DHCP Snooping 和 TLS 降低二层风险。思考题 跨网段访问时 ARP 解析的是谁？ ARP 的 STALE 和 FAILED 状态说明什么？ VIP 漂移后为什么部分请求仍到旧节点？ ARP 欺骗如何防护？ 写一份同网段两台机器不通的排查命令清单。
• 这是《计算机网络 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。IP 层负责把包从源主机送到目标主机。它提供全局寻址和路由能力，但不保证可靠、有序和带宽。理解 IP 地址、子网、路由选择、TTL、分片和 IPv6，是定位“连不上”“绕路”“丢包”和“跨可用区延迟”的基础。4.1 IPv4 地址与子网IPv4 地址是 32 位：192.168.1.10子网掩码可以用点分十进制或前缀长度表示：192.168.1.10/24255.255.255.0/24 表示前 24 位是网络前缀，后 8 位是主机部分。特殊地址： 地址 含义 0.0.0.0/0 默认路由或任意地址 127.0.0.1 IPv4 回环 10.0.0.0/8 私网地址 172.16.0.0/12 私网地址 192.168.0.0/16 私网地址 169.254.0.0/16 链路本地地址 255.255.255.255 受限广播 查看地址：ip addr showip -brief addr4.2 公网、私网与地址规划公网地址可全球路由，私网地址只在内部网络使用，通常经过 NAT 访问公网。规划示例：10.0.0.0/16 生产 VPC10.0.0.0/20 公共子网10.0.16.0/20 应用子网10.0.32.0/20 数据子网10.0.48.0/20 运维子网原则： 预留扩展空间； 按环境和用途分层； 避免不同 VPC 或数据中心重复网段； 数据库子网不放公网网关； 负载均衡、应用、数据库分层管理； 记录每个网段的用途。4.3 路由表路由器根据最长前缀匹配选择路由。示例：Destination Next Hop Interface0.0.0.0/0 10.0.0.1 eth010.0.0.0/16 10.0.0.1 eth010.20.0.0/16 10.20.0.1 eth1172.17.0.0/16 docker0 docker0查看：ip routeip route get 10.20.1.10route -n路由选择过程： 取目的 IP； 查找所有匹配路由； 选择前缀最长的路由； 确定下一跳和出接口； 通过 ARP 或邻居发现得到下一跳 MAC； 封装并发送帧。4.4 默认网关与策略路由默认路由：ip route add default via 192.168.1.1 dev eth0策略路由可以根据源地址、入口接口或标记选择不同表：ip rule showip route show table 100常见场景： 多网卡分别访问不同运营商； 容器或虚拟机流量走独立表； VPN 与默认路由冲突； 云环境多路由表关联不同子网； 服务流量与存储流量分走不同路径。4.5 TTL 与 tracerouteIP 包每经过一台路由器，TTL 减 1。TTL 为 0 时路由器丢弃并返回 ICMP Time Exceeded。traceroute 利用该机制探测路径：traceroute 10.20.1.10traceroute -I 10.20.1.10traceroute -T -p 443 10.20.1.10mtr 10.20.1.10解读： 某跳 * * * 不一定代表故障，可能限速 ICMP； 后续跳全部超时更值得关注； 延迟逐跳上升且持续，可能路径异常； 中间跳丢包但终点不丢，可能只是控制平面限速； 最好用 mtr 观察趋势。4.6 IP 分片与 PMTUD如果 IP 包大于出接口 MTU，且不可分片标志存在，则返回 ICMP Fragmentation Needed；否则进行分片。TCP 通常在握手阶段协商 MSS，避免 IP 分片：MTU 1500IP Header 20TCP Header 20MSS 1460隧道叠加会降低有效 MTU：物理 MTU 1500VXLAN + Overlay IP + UDP + VXLAN Header有效载荷减少典型现象： ping 小包通； TCP 握手成功； 大请求或响应卡住； SSL 握手在证书阶段失败； MSS 或 PMTUD 问题。测试：ping -M do -s 1472 10.20.1.10tracepath 10.20.1.10云环境和容器网络中应统一检查宿主机、虚拟网络、隧道和安全设备的 MTU。4.7 IPv6IPv6 地址为 128 位：2001:db8:1:2::1/64特点： 地址空间大； SLAAC 支持无状态自动配置； NDP 替代 ARP； 地址结构常为 /64 子网； 内置 IPsec 支持但不是自动启用； NAT 不是必需设计。常用命令：ip -6 addrip -6 routeping -6 2001:db8::1traceroute -6 2001:db8::1应用兼容要点： socket API 使用 AF_INET6 或双栈； URL 中 IPv6 需要方括号； DNS 需要同时考虑 A 和 AAAA； 防火墙必须显式治理 IPv6； 监控和审计不能只统计 IPv4。4.8 路由协议概览 协议 类型 常见场景 静态路由 手工配置 小规模、简单出口 OSPF IGP 链路状态 企业和数据中心内 BGP 路径向量 互联网、云互联、大型数据中心 ECMP 等价多路径 Spine-Leaf、VXLAN 生产应用通常不直接配置这些协议，但需要理解云 VPC 路由表、专线、对等连接和负载均衡路径可能受它们影响。4.9 排障流程连不上目标时：ip addrip routeping <gateway>ping <target>traceroute <target>ip route get <target>ss -ntp判断顺序： 本机地址是否正确； 链路是否 up； 网关是否可达； 路由是否指向预期接口； 目标是否在线； 中间路径哪里断开； 安全组或防火墙是否拦截； 服务是否监听端口。本章小结IP 层提供寻址和路由，子网决定本地与跨网段通信方式，路由表通过最长前缀匹配选择路径。TTL 支持 traceroute，MTU 和 MSS 影响大包传输，IPv6 引入更大地址空间和 NDP。排查连接问题应先看本机地址与路由，再测试网关、路径、端口和安全策略。思考题 为什么路由匹配使用最长前缀而不是最先匹配？ TTL 如何支持 traceroute？ TCP 握手成功但大文件传输卡住，可能与什么有关？ IPv6 环境下 ARP 由什么协议替代？ 为一个三可用区 VPC 设计 IP 和路由规划。
• 这是《计算机网络 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。应用层问题很容易被归咎为“网络抖动”，但真正的底层原因可能是网卡丢包、交换机端口错误、VLAN 配置不一致、广播风暴或链路带宽打满。本章介绍物理网络、以太网、交换机、VLAN、Bond 和无线局域网的基本原理，并给出 Linux 上的观测方法。3.1 以太网帧以太网是局域网最常见的数据链路层技术。简化帧结构：| Destination MAC | Source MAC | Type | Payload | FCS || 6 bytes | 6 bytes | 2 | 46-1500 | 4 |常见 Type： 类型 含义 IPv4 0x0800 IPv6 0x86DD ARP 0x0806 VLAN 0x8100 传统以太网 MTU 为 1500 字节。云环境、容器 overlay 和隧道会叠加额外头，常见路径 MTU 问题都发生在这一层。查看接口与 MTU：ip linkip -details link show eth0ethtool eth03.2 MAC 地址与交换机MAC 地址是网卡在链路上的标识，通常写作：00:16:3e:12:34:56交换机维护 MAC 地址表：MAC Address VLAN PortAA:AA... 10 Gi1/0/1BB:BB... 10 Gi1/0/2工作流程： 收到帧； 学习源 MAC 与端口的映射； 查目的 MAC； 找到则转发到对应端口； 找不到则在同一 VLAN 内泛洪； 目的 MAC 为广播或组播时按规则泛洪。交换机隔离冲突域，但不隔离广播域。路由器或 VLAN 才能隔离广播域。3.3 VLANVLAN 将一个物理局域网划分为多个逻辑广播域。物理交换机 |-- VLAN 10：Web |-- VLAN 20：App +-- VLAN 30：DBVLAN Tag 会增加 4 字节开销：原始 MTU 1500VLAN Tag 后帧长增加 4 字节常见问题： 两端 VLAN ID 不一致； 交换机端口 access/trunk 模式配置错误； 云平台安全组与 VLAN 混淆； 允许通过的 VLAN 列表缺失； 数据库和应用不在同 VLAN，忘记配置路由或防火墙。3.4 链路聚合与 BondLinux Bond 可以将多块网卡绑定为一个逻辑接口，用于冗余或带宽扩展。常见模式： 模式 说明 active-backup 主备，常用且简单 802.3ad LACP，需要交换机配合 balance-rr 轮询，兼容性要求高 balance-xor 基于哈希分流 balance-tlb / alb 发送或收发负载均衡 查看：ip linkcat /proc/net/bonding/bond0注意：单个 TCP 连接的哈希结果通常落在一条物理链路上，Bond 不必然让单连接带宽翻倍。3.5 全双工、速率与网卡队列现代以太网通常全双工，收发可同时进行。查看：ethtool eth0重点字段：SpeedDuplexLink detected网卡和操作系统之间通过队列与软中断交互：网卡 DMA -> RX Queue -> 硬中断 -> NAPI / 软中断 -> 协议栈 -> 应用收包查看统计：ip -s link show eth0ethtool -S eth0cat /proc/interruptscat /proc/net/softnet_stat关注： rx_dropped：接收丢包； tx_dropped：发送丢包； rx_crc_errors：链路质量或网卡问题； collisions：冲突或双工异常； overruns：缓冲不足； softnet 丢包：CPU 处理不及时。3.6 局域网性能问题3.6.1 带宽打满现象： 大文件传输后其他请求变慢； 备份窗口内服务延迟升高； 交换机端口利用率高； 重传增加； 应用超时集中在同机房间链路。处理： 限速备份任务； 错峰传输； 拆分流量到不同链路； 升级带宽； 使用压缩或增量传输； 检查是否异常流量或攻击。3.6.2 广播域过大现象： ARP 请求多； 小包转发速率高； 局域网内所有机器受影响； 抓包看到大量广播。处理： 划分 VLAN； 减少同网段机器数量； 检查环路； 启用生成树相关保护； 排查异常广播源。3.6.3 链路质量差现象： CRC 错误增长； 丢包与重传相关； 更换链路后恢复； 交换机端口错误计数增长。处理： 更换线缆或光模块； 更换交换机端口； 检查网卡； 核对速率与双工； 清洁或更换光纤。3.7 无线局域网Wi-Fi 使用无线介质，天然存在冲突、干扰和信号衰减。影响质量的因素： 信号强度； 信道干扰； 用户密度； AP 负载； 漫游策略； 频段：2.4GHz / 5GHz / 6GHz； 终端网卡能力。现象：信号弱 -> 低速率重传多 -> 占用空气时间 -> 影响其他终端生产服务通常不建议依赖办公 Wi-Fi。办公网络访问生产系统时，要能区分 Wi-Fi 抖动和服务端问题。3.8 数据中心网络拓扑传统三层结构：Core -> Aggregation -> Access -> Server数据中心常用 Spine-Leaf：Spine 1 Spine 2 | \ / |Leaf 1 Leaf 2 | |Server A Server B特点： Leaf 接入服务器； Spine 提供跨 Leaf 转发； 任意两 Leaf 通常一跳或少量跳； 易于水平扩展； 常配合 BGP、VXLAN 和 ECMP。本章小结物理网络与局域网解决信号、帧、MAC、交换、VLAN 和链路可靠性问题。以太网帧承载 IP 包，交换机按 MAC 转发，VLAN 隔离广播域，Bond 提供冗余或带宽扩展。常见底层问题包括 MTU 不一致、链路丢包、带宽打满、广播域过大和网卡队列丢包。ip、ethtool、交换机端口计数和抓包是定位这些问题的基本工具。思考题 交换机如何学习和转发 MAC 地址？ VLAN、冲突域和广播域分别隔离什么？ 为什么 Bond 不一定提升单个 TCP 连接的吞吐？ rx_dropped 和 rx_crc_errors 增长分别说明什么？ 写一份服务器接入生产网络前的链路检查清单。
• 这是《计算机网络 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。分层模型是计算机网络的地图。它把一个复杂问题拆成职责清晰的层次：物理层负责信号，链路层负责同一局域网内的帧传输，网络层负责跨网络寻址，传输层负责进程到进程的通信，应用层负责业务语义。本章重点不是背 OSI 七层名字，而是理解每层解决什么问题、数据如何穿过协议栈、排障时应该在哪一层找证据。2.1 OSI 与 TCP/IP 模型 OSI 层 TCP/IP 常见层 核心问题 典型协议 应用层 应用层 业务语义、请求响应 HTTP、DNS、SMTP、RPC 表示层 应用层 编码、压缩、加密 JSON、Protobuf、TLS 会话层 应用层 会话与状态 Cookie、Token、WebSocket 传输层 传输层 端口、可靠或低延迟传输 TCP、UDP、QUIC 网络层 网络层 寻址与路由 IPv4、IPv6、ICMP 数据链路层 链路层 相邻设备帧传输 Ethernet、ARP、VLAN 物理层 物理层 信号与介质 光纤、双绞线、无线 工程中常用五层视角：Application 业务协议、编码、安全语义Transport 端口、连接、可靠性和流控Network IP 寻址、路由、分片Link MAC、帧、VLAN、ARPPhysical 信号、接口、线路分层不是物理隔离。现代系统里，TLS 在协议上位于传输层之上，但常被归入应用层安全协议；QUIC 基于 UDP，却在用户态实现了可靠传输、流多路复用和加密。2.2 封装与解封装发送方逐层加头，接收方逐层去头：应用数据 + TCP Header = TCP Segment + IP Header = IP Packet + Ethernet Header / Trailer = Frame接收过程相反：Frame -> IP Packet -> TCP Segment -> Application Data各层地址： 层 地址 应用层 URL、域名、用户 ID 传输层 端口号 网络层 IP 地址 链路层 MAC 地址 物理层 接口、端口、信号 一个常见误区是认为 MAC 和 IP 谁替代谁。MAC 标识同一链路上的接口，IP 支持跨网络路由；跨网段通信中，目的 IP 通常不变，而下一跳 MAC 会逐跳变化。2.3 每层的故障特征 层 典型现象 排查工具 物理层 接口 down、丢包、速率异常 ethtool、交换机端口 链路层 ARP 失败、VLAN 错、MAC 冲突 arp、ip neigh、tcpdump 网络层 无路由、TTL 超时、丢包 ping、traceroute、mtr 传输层 端口不通、握手失败、重传高 ss、nmap、tcpdump 应用层 404、证书错误、超时、语义错误 curl、日志、trace 示例：ip linkip addrip routeip neighss -ntpcurl -v https://www.example.com排障时先确认范围：单个服务、单台机器、一个子网，还是全网。再从底层往上验证，能显著减少无效猜测。2.4 协议演进与分层弹性传统 HTTP/1.1 over TCP over IP 的结构清晰，但性能瓶颈也明显：HTTP/1.1：队头阻塞TCP：单一字节流，丢包影响所有请求TLS：握手带来额外 RTT现代方案： 方案 变化 HTTP/2 二进制分帧、多路复用，仍基于 TCP TLS 1.3 握手更短、前向安全更强 HTTP/3 基于 QUIC，集成可靠传输、流复用和 TLS 1.3 QUIC 运行在 UDP 上，在用户态实现传输能力 这说明分层模型是分析工具，而不是僵化架构。工程中仍会按职责分层，但实现边界可以根据性能、安全和演进需求调整。2.5 用分层模型做架构设计设计一个后端服务时，每层都有决策：应用层：接口语义、幂等、错误码、压缩、认证传输层：TCP/UDP、连接池、超时、心跳网络层：VPC、子网、路由、可用区链路层：VLAN、网卡、bond物理层：机房、带宽、拓扑示例：跨机房调用 RTT 高，应用层应减少请求次数；网卡丢包，应用层重试只能止血，根因仍要修网络；证书配置错误，换 HTTP 短连接无法解决问题。本章小结分层模型把网络拆成物理、链路、网络、传输和应用职责，数据通过封装和解封装穿过协议栈。MAC 用于链路内通信，IP 用于跨网络路由，端口用于进程通信，应用协议承载业务语义。现代 QUIC 和 HTTP/3 说明分层边界可以演进，但分析问题时应继续按职责分层定位。思考题 OSI 七层和 TCP/IP 五层分别适合什么场景？ 发送一个 HTTP POST 时，数据经历了哪些封装过程？ 为什么跨网段通信中目的 IP 常不变而下一跳 MAC 变化？ “端口不通”和“无路由”分别对应哪一层？ 用分层模型写一份服务访问失败的排查清单。
• 这是《计算机网络 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。计算机网络的目标说起来很简单：让两台机器可靠地交换数据。但为了这个目标，系统需要解决寻址、路由、握手、可靠性、拥塞控制、安全、命名、负载均衡、移动性、延迟和海量并发等问题。本章先建立网络全景图，后续章节再逐层拆解 DNS、TCP、TLS、HTTP、负载均衡和生产排障。1.1 从一次请求开始当你在浏览器访问：https://www.example.com/order/10001系统大致经历：flowchart TB A[输入 URL] --> B[DNS 解析] B --> C[TCP 三次握手] C --> D[TLS 握手] D --> E[发送 HTTP 请求] E --> F[负载均衡] F --> G[应用服务] G --> H[数据库/缓存/中间件] H --> G G --> F F --> E E --> I[渲染响应]每一步都可能出现问题： 步骤 常见故障 DNS 解析失败、缓存过期、地域调度错误 TCP 握手超时、连接数耗尽、网络丢包 TLS 证书过期、协议不兼容、SNI 配置错误 HTTP 语义错误、超时、重试风暴 负载均衡 后端不健康、会话粘滞、流量倾斜 应用 线程池满、下游依赖慢、内存溢出 数据层 慢查询、锁等待、连接池耗尽 网络排障不是只看 ping，而是沿着请求路径定位失败层。1.2 分层思想网络采用分层设计，每层只解决自己的问题，并向上层提供服务。常见模型： OSI 七层 TCP/IP 常见分层 作用 应用层 应用层 HTTP、DNS、TLS、RPC 表示层 应用层 编码、加密、压缩 会话层 应用层 会话管理 传输层 传输层 TCP、UDP、端口 网络层 网络层 IP、路由、ICMP 数据链路层 链路层 以太网、ARP、交换机 物理层 链路层 光纤、网线、无线信号 工程视角可以简化成：ApplicationTransportNetworkLinkPhysical分层的好处： 模块化； 便于排障； 协议可以独立演进； 不同网络技术可以互通； 问题可以逐层定位。1.3 数据是如何封装的应用发送一段数据时，网络协议栈会逐层加头。Data -> TCP Segment = TCP Header + Data -> IP Packet = IP Header + TCP Segment -> Frame = Ethernet Header + IP Packet + FCS接收方反向解封装：Frame -> IP Packet -> TCP Segment -> Application Data几个关键概念： 概念 说明 MTU 链路层单帧最大载荷，常见 1500 字节 MSS TCP 单段最大数据量，常见 1460 字节 分片 IP 层拆包 分段 TCP 按 MSS 拆数据 PMTUD 路径 MTU 发现 Nagle 小包合并算法 Delayed ACK 延迟确认 如果链路上 MTU 配置错误，可能出现 TCP 握手成功但大包传输失败的现象。1.4 寻址与路由每台联网设备需要地址。IP 地址IPv4：192.168.1.10/24IPv6：2408:8207:1234:abcd::1/64/24、/64 表示网络前缀长度。地址由网络部分和主机部分组成。路由路由器根据路由表决定下一跳：Destination / Mask Next Hop0.0.0.0/0 Gateway10.0.0.0/8 Core Router192.168.1.0/24 Local Interface查看本机路由：ip route查看路径：traceroute www.example.com1.5 域名解析人使用域名，网络使用 IP，DNS 负责转换。www.example.com -> Local DNS -> Root DNS -> TLD DNS -> Authoritative DNS -> IP Address常见记录： 类型 说明 A IPv4 AAAA IPv6 CNAME 别名 MX 邮件 TXT 文本验证、SPF NS 授权 DNS SRV 服务发现 排查：nslookup www.example.comdig www.example.com +traceDNS 缓存会带来解析延迟，也会在切换流量时造成旧地址继续被访问。1.6 传输层：TCP 与 UDP 维度 TCP UDP 连接 面向连接 无连接 可靠性 可靠 尽力而为 顺序 有序 无序 流控 滑动窗口 无 拥塞控制 有 应用自定义 传输单位 Segment Datagram 适用 HTTP、数据库、RPC 视频、游戏、DNS、QUIC TCP 提供可靠字节流，但可靠性不等于业务成功： 请求可能到达但对端处理失败； 连接可能建立但服务超时； 超时重传可能造成延迟毛刺； 半打开连接需要心跳检测； 应用层仍需要幂等和重试策略。1.7 应用协议HTTPHTTP 是无状态请求响应协议。GET /api/orders/10001 HTTP/1.1Host: api.example.comAccept: application/jsonHTTPSHTTPS = HTTP + TLS。TLS 提供： 身份认证； 加密； 完整性保护； 会话恢复； 现代传输安全特性。RPC微服务内部常用 RPC：Client Stub -> Network -> Server Stub -> Business Method相比 HTTP，RPC 通常更关注： 高性能序列化； 服务发现； 负载均衡； 超时重试； 熔断限流； 链路追踪。1.8 延迟与带宽 指标 含义 Bandwidth 单位时间可传输数据量 Latency 一个包从 A 到 B 的时间 RTT 往返时间 Jitter 延迟抖动 Packet Loss 丢包率 Throughput 实际吞吐 一个近似关系：throughput <= bandwidthtransfer time = transfer_size / throughputresponse time = network RTT + queueing + processing跨城网络 RTT 通常明显高于同城。设计系统时要考虑： 减少请求次数； 批量读取； 缓存热点； 就近部署； 控制响应体大小； 使用长连接； 异步化非关键链路。1.9 生产网络观测常用命令：ping www.example.comtraceroute www.example.commtr www.example.comcurl -v https://www.example.comss -sss -ntpnetstat -i抓包：tcpdump -i any host www.example.com and port 443 -w debug.pcap分析：wireshark debug.pcap生产排障要看： 客户端本地网络； DNS 解析； TCP 连接； TLS 握手； 负载均衡； 服务端日志； 链路追踪； 依赖服务状态。本章小结计算机网络由分层协议组成，数据经过逐层封装、路由和传输，再由接收方解封装。DNS 负责命名，IP 负责寻址，TCP/UDP 提供传输语义，HTTP/TLS 支撑现代应用。生产排障的关键是把请求拆成路径，逐层确认延迟、失败和安全边界。思考题 一次 HTTPS 请求包含哪些关键阶段？ 分层模型对故障排查有什么帮助？ MTU、MSS、IP 分片和 TCP 分段有什么区别？ TCP 可靠是否代表业务请求可靠？ 如何定位“请求偶发超时”这类网络问题？