4. 网络基础:TCP/IP、DNS、HTTP、TLS 与抓包

CI/CD 与生产故障的共同底座:网络与协议。

本章目标

把网络问题从“玄学”变成“可分层定位”:DNS → TCP → TLS → HTTP → 应用。

你会掌握

三次握手/重传、DNS 递归链路、TLS 握手、HTTP 请求生命周期,以及抓包/命令排障套路。

典型收益

当出现 502/超时/握手失败/证书报错/间歇性断连时,你知道先看哪一层、用什么证据验证。

在 DevOps 世界里,“网络”经常扮演反派:它不坏得彻底,而是坏得若隐若现——有时能通、有时超时;有时 200、有时 502;有时证书正常、有时握手失败
你要做的不是背协议,而是建立一套分层诊断的本能:把问题像剥洋葱一样,一层层剥到根因。

1) 网络排障的“分层地图”(你要先学会站位)

遇到“访问不了服务”,不要先怪应用。先按层归类:

  1. DNS:域名能不能解析到正确 IP?TTL/缓存有没有坑?
  2. 连通性(TCP):三次握手是否完成?是否被防火墙/安全组/路由拦住?
  3. 加密(TLS):握手是否成功?证书链/域名匹配/时间是否正确?
  4. 应用协议(HTTP):状态码/路由/反代/超时/头部是否正确?
  5. 应用本身:进程、依赖、资源、线程池、数据库连接等。
排障黄金句:“我现在要证明的是哪一层出问题?”
只要你能用证据回答这句话,问题就已经成功了一半。

2) TCP:连接是怎么建立的?为什么会超时?

绝大多数线上“超时”,最终都会落在 TCP 的两个问题:握手没完成数据没按预期到达(丢包/拥塞/重传)。

图 1:TCP 三次握手 + 超时/重传的直觉(动态)

你不需要背所有字段,但要知道“握手卡住”意味着什么:路由/防火墙/端口/服务监听任一处都可能出错。

Client curl / browser Network 路由 / 防火墙 / 安全组 Server listen :443/:80 1) SYN 2) SYN-ACK 3) ACK 直觉:握手卡住 → 先证明“端口可达 + 服务在监听”。

TCP 排障的最短命令

3) DNS:域名到 IP 的“暗箱”其实有迹可循

DNS 问题的典型症状:

图 2:DNS 递归解析链路(动态)

把“为什么我解析到这个 IP?”变成可解释的链路:本地缓存 → 递归解析器 → 根/权威 → 结果返回。

Client 浏览器/应用 本地缓存/hosts Recursive Resolver 公司 DNS / 运营商 缓存 + 递归查询 Root 指向 TLD TLD 指向权威 Authoritative 最终记录(A/AAAA/CNAME) TTL 控制缓存 技巧:用 dig/nslookup 看“谁回答的 + TTL + 记录类型”,别只看结果。

DNS 排障的最短命令

4) HTTP:状态码只是表象,关键在“谁在说 502?”

HTTP 排障的一条核心思路:

最关键:当你看到 502/504,先问一句:是 Nginx/网关返回的,还是应用返回的?这是两条完全不同的排障路。

5) TLS:证书不是“文件”,是“信任链 + 时间 + 域名匹配”

TLS 握手失败的常见原因其实很“工程化”:

图 3:TLS + HTTP 请求生命周期(动态)

一条请求里通常包含三段“握手”:DNS(找地址)→ TCP(建连接)→ TLS(建信任)→ HTTP(传业务)。

DNS domain → IP TCP connect() TLS handshake + verify HTTP request → response 排障策略:先证明 DNS/TCP/TLS 哪一步失败,再进入 HTTP 与应用层。

TLS/HTTP 排障的最短命令

6) 抓包:你不是在“抓数据”,你是在“抓证据”

抓包的核心是:你要先知道自己想证明什么。常见目标:

优先在离问题最近的地方抓:客户端、反代、后端服务节点。三点抓包往往能把链路问题定位到“哪一段”。

本章小结:把网络从“恐怖片”变成“侦探片”

← 上一章:systemd 与日志 下一章:Shell 脚本与可维护自动化 →