应用层这一篇我拖了很久才动笔。前面五篇从物理层一路爬到传输层讲的都是管道怎么铺、数据怎么搬到了这一层管道已经通了问题变成了跑在上面的到底是什么。计算机网络应用层是整个体系结构里离用户最近、也最容易被甩锅的一层——用户说网站打不开运维看传输层没问题开发看代码没问题最后翻出来是 DNS 缓存脏了或者一个 302 循环。它没有 TCP 三次握手那种教科书式的仪式感协议数量却最多、语义最杂、历史包袱最重谁能把这一层摸透谁在排障的时候就能少绕很多弯路。这篇东西面向的是已经懂点 TCP/IP、想真正把应用层协议吃透并且能上手抓包定位问题的读者从体系结构讲到 DNS、HTTP、邮件与文件传输再落到实操排障和内容分发全程按为什么这么设计的思路拆不背概念。1. 应用层到底在解决什么问题1.1 从一次网页打不开的误判说起我见过太多次这样的场景某个业务方跑过来说站点挂了第一反应是网络不通ping 一下通telnet 端口也通然后就开始互相甩锅。实际上传输层只负责把字节可靠地从一端搬到另一端它根本不知道这一坨字节是一个 HTTP 请求还是一个邮件正文。真正决定这坨字节该怎么解释的是应用层协议。应用层不提供任何数据传输能力它只定义数据的格式、交互的时序和每条消息的语义。这个定位很关键。它意味着应用层的所有问题最终都表现为三种形态第一名字解析不出来DNS 层第二连接建立不了传输层但由应用层触发第三连上了但语义对不上协议层比如返回 400、返回一个错误页、返回一个空的 JSON。排障时把这三类分开效率能提升一大截。我自己习惯的顺序是先确认域名解析结果对不对再看 TCP 连接能不能建起来最后才去分析应用层报文内容。这个顺序的好处是前面的环节没过后面所有的分析都是浪费。还有一个常见误解很多人把浏览器报错等同于应用层协议出错。实际上浏览器给的错误信息往往是分层的比如连接被拒绝是传输层的事证书校验失败是应用层安全子层的事而页面白屏可能是前端渲染的事。分清归属是这一层最值钱的基本功。1.2 应用层与传输层的分工边界应用层往下就是传输层两层的接口就是端口号加套接字。这个边界看起来简单实际设计上充满了取舍。核心问题是应用层该用 TCP 还是 UDP。这个选择不是随便定的它直接决定了应用层协议要不要自己实现可靠性、有序性和流量控制。用一个生活类比TCP 像是一个负责任的快递公司保证包裹按顺序送到、丢了会重发、送太快了会主动降速UDP 像是往邮筒里塞明信片塞进去就不管了可能丢、可能乱序但快、开销小。所以凡是不能容忍丢包和乱序的比如网页、邮件、文件传输基本都压在 TCP 上而能容忍偶尔丢几个包、但对延迟极度敏感的比如实时音视频、在线游戏的状态同步、DNS 的单次查询就用 UDP 更合适。这里有个容易忽略的点用 UDP 不等于不要可靠性而是把可靠性的实现权交给了应用层自己。实时音视频就是典型它不用 TCP 的重传机制因为重传带来的延迟比丢一帧更难受它选择在应用层做前向纠错和丢包隐藏。理解这个设计哲学你就能明白为什么有些协议明明可以跑在 TCP 上却偏要自己造轮子——不是造轮子好玩是通用机制的成本在这个场景下不可接受。另外还要注意端口号的分配逻辑。0 到 1023 是知名端口需要特权才能绑定1024 到 49151 是注册端口49152 以上是动态端口。服务端监听知名端口客户端用动态端口发起连接一条连接由四元组唯一确定。这个设计让同一台机器可以同时跑几十个服务而不冲突也让 NAT 设备的端口映射有了依据。1.3 网络应用体系结构的三种形态在写具体协议之前得先把体系结构讲清楚因为它决定了后面所有协议的行为模式。主流就三种客户端-服务器C/S、对等网络P2P、以及两者混合。C/S 结构是最常见的形态特点是有一个永远在线、固定地址的服务端客户端主动发起请求。优势是管理集中、易于做权限控制和数据一致性劣势是服务端容量决定了整体上限扩展要靠加机器和负载均衡。绝大多数 Web 业务、邮件系统、数据库服务都是这个模式。P2P 结构里每个节点既是客户端又是服务端没有永远在线的中心。它的优势是天然可扩展——用户越多可提供的资源越多成本不随用户量线性增长劣势是节点行为不可控、内容管理困难、NAT 穿透复杂。文件共享、某些分布式存储和内容分发会用到。混合结构是现实中最多的用中心服务器做节点发现和索引实际数据传输走 P2P。这样既拿到了中心化的可管理性又拿到了分布式的带宽优势。提示判断一个应用属于哪种结构看它谁先发起、谁持有权威数据就够了。不要被有没有中心服务器这个表象迷惑很多号称 P2P 的系统仍然有中心化的信令服务。这三种结构的选择直接影响了协议设计的复杂度。C/S 可以假设服务端有能力维护大量状态所以 HTTP 早期甚至设计成无状态的P2P 必须假设任意节点随时掉线所以协议里充满了心跳、超时和重新发现机制。看协议的时候带着这个视角很多看起来多余的设计就讲得通了。2. DNS一切应用层交互的起点2.1 域名空间的分级授权设计DNS 的本质是一个分布式的、分层授权的名字到地址的映射系统。分布式和分层授权这两个词是关键——它不是一个巨大的中心数据库而是把整个命名空间切成树每一层只负责自己那一小段的管理权。最顶层是根往下是顶级域比如通用的 com、net、org以及国家地区域再往下是二级域依次类推。每一级都把下一级的授权委托出去自己只保留指向下一级的指针记录。这个设计的好处是任何一个域的管理者都可以独立增删记录不需要惊动上层坏处是解析一次名字可能要跨越多个服务器延迟不可控所以才必须靠缓存来兜底。这里必须讲清楚一个容易混淆的概念区域zone和域domain不是一回事。域是命名空间里的一个子树区域是实际由某台服务器负责管理的那一段数据。一个域可以拆成多个区域分别管理比如把子域委托给不同的团队。这个区别在做多环境拆分、跨团队协作的时候特别重要因为决定这条记录该去哪儿改的依据是区域划分不是名字前缀。2.2 递归查询与迭代查询的完整流程解析过程分两种查询方式很多人背了流程但没搞懂为什么要这么分。递归查询是客户端对本地域名服务器发起的语义是你帮我搞定给我最终答案。客户端不想自己跑一圈它只想要结果。迭代查询是本地域名服务器对上级服务器发起的语义是你知道就告诉我不知道就告诉我该去问谁。上级服务器不承担帮你跑完全程的义务。为什么这么设计因为如果根服务器对每个查询都做递归全球的解析请求会瞬间把它压垮。迭代查询把工作量分散给了每一级的权威服务器和本地缓存服务器根服务器只负责指路。这是一种典型的把昂贵操作下推到边缘的思路和后来 CDN 的调度逻辑一脉相承。完整走一遍浏览器先查自己的缓存再查操作系统缓存和 hosts 文件都没有就问本地域名服务器。本地服务器如果也没有缓存就从根开始迭代——根返回顶级域服务器地址顶级域返回权威服务器地址权威服务器返回最终的 A 或 AAAA 记录。本地服务器拿到结果后按 TTL 缓存再返回给客户端。# 观察完整的迭代过程trace 会从根开始逐级打印 dig trace example.com # 只查指定类型并直接问指定服务器 dig 8.8.8.8 example.com MX short # 查看 TTL 和权威段判断缓存是否命中 dig example.com Atrace这个参数我强烈建议每个做后端的人都跑一次它会让你亲眼看到根、顶级域、权威服务器各自返回了什么比看十遍流程图都管用。而且要留意输出里的status字段NOERROR、NXDOMAIN、SERVFAIL三种状态对应完全不同的排查方向后者往往不是名字不存在而是权威服务器本身出问题了。2.3 资源记录类型速查与选型记录类型不多但每一种的语义和坑都不一样我整理了一张表。记录类型作用常见坑A域名到 IPv4 地址多值轮询没有健康检查挂了不会自动摘除AAAA域名到 IPv6 地址客户端有 IPv6 优先策略配错了会拖慢首包CNAME域名别名指向另一个域名与 MX、NS 等记录冲突链路过长增加解析次数MX邮件交换记录带优先级优先级数字越小越优先漏配会导致收不到信NS指定该区域的权威服务器修改后需要上级重新委派生效慢TXT任意文本常用于域名所有权校验单条长度有限超长要拆成多条SRV指定服务的主机和端口服务发现场景常用客户端支持度要确认SOA区域的起始授权与默认参数里面的序列号决定从服务器是否同步选型上有几条经验。第一CNAME 不要用在根域上很多解析服务商在根域配 CNAME 会和 NS、SOA 记录打架实际表现是解析时好时坏。第二A 记录多值轮询是最朴素的负载分担但它没有任何健康判断一台机器挂了流量还会往上打生产环境要么配健康检查要么老老实实上负载均衡。第三CNAME 链要尽量短每多一跳就多一次解析延迟链路上任何一环的权威服务器慢了用户的首屏就慢了。TTL 的设置是个权衡题。设短了故障切换快但解析请求量大、缓存命中率低用户每次都要重新走一遍流程设长了缓存命中高、延迟低但改记录之后要等很久才全网生效。我的做法是日常记录设中等 TTL做迁移前提前把 TTL 调短等旧值过期后再改指向改完稳定一段时间再调回来。这个提前降 TTL的动作是很多人漏掉的一步直接改记录然后抱怨怎么一半用户还在访问老机器多半就是这里没做。2.4 缓存、TTL 与典型解析故障DNS 的问题有八成出在缓存上。缓存分布在浏览器、操作系统、本地域名服务器、甚至某些中间设备里每一层的过期时间判断逻辑还不完全一样。所以你会遇到我明明改了记录为什么还是解析到旧地址这种经典问题。排查顺序建议这样先在客户端dig一次看返回的 TTL 还剩多少如果 TTL 是接近满值的大数字说明命中的是缓存再去确认是哪一层缓存。可以用dig norecurse直接问权威服务器绕开所有缓存看真实配置。如果权威返回的是新值而本地不是那就是缓存没到期只能等或者联系缓存持有方清理。另一个高频问题是解析慢而非解析错。表现是首次访问特别慢之后正常。原因通常是解析链路太长——CNAME 链多、权威服务器响应慢、或者客户端在 IPv6 和 IPv4 之间反复尝试。这时候可以抓包看解析耗时分布重点看每一级查询的往返时间找出那个拖后腿的环节。注意修改 NS 记录是最慢的操作因为要等上级域重新委派而且全球各地的缓存过期时间不一致。做这类变更一定要留出足够的时间窗口不要安排在业务高峰期前的半小时。还有一个容易被忽略的点本地域名服务器通常会对同一个域名做并发请求合并。如果一个热门域名缓存刚过期瞬间涌入几百个请求本地服务器只会向上游发一次查询其余请求排队等待。这个机制在正常情况下是好事但如果上游响应很慢就会造成雪崩式的排队延迟表现为整站首屏同时变慢。3. HTTP应用层里最重的那块活3.1 报文结构逐字节拆解HTTP 是文本协议这个选择在当年是为了易调试代价是传输效率不如二进制协议。报文分请求和响应两种结构都是起始行 头部 空行 正文。请求的起始行是方法 路径 版本比如GET /index.html HTTP/1.1。响应起始行是版本 状态码 原因短语。头部是若干名称: 值的行每行以回车换行结束。空行是头和正文的分隔符这个空行不能省省了对方就不知道头部到哪结束。正文长度由Content-Length或者Transfer-Encoding: chunked决定。GET /api/v1/items?page2 HTTP/1.1 Host: example.com User-Agent: demo-client/1.0 Accept: application/json Accept-Encoding: gzip, br Connection: keep-alive上面这个请求没有正文所以空行之后直接结束。要注意Host头在 HTTP/1.1 里是强制的因为同一台服务器可能承载多个站点没有 Host 就无法确定该交给哪个虚拟主机处理。这也是为什么直接用 IP 访问某些站点会返回默认页或者 400。分块传输值得单独说。当响应正文长度在发送前无法确定时比如边查数据库边输出服务器会用 chunked 编码每个块前面带十六进制长度最后用一个长度为 0 的块表示结束。这个机制解决的是不知道总长度就不能设 Content-Length的问题但它和 HTTP/1.0 的客户端不兼容做兼容性要求高的场景要留意。3.2 请求方法与状态码的语义边界方法的核心区别在于是否幂等、是否安全。安全指的是不改变服务端状态幂等指的是重复执行效果相同。GET 是安全且幂等的HEAD 同理但只返回头PUT 和 DELETE 是幂等但不安全POST 既不安全也不幂等。这个分类不是学术洁癖它直接影响重试策略——网络抖动时幂等的方法可以放心重试POST 重试就可能产生重复订单。状态码分五类我列几个实际排障中最常打交道的。状态码含义排查切入点200成功内容不对就往业务逻辑查不是协议问题301 / 308永久重定向检查是否被缓存301 在浏览器里缓存极久302 / 307临时重定向307 保留原方法和正文302 历史上行为不统一304协商缓存命中说明缓存机制生效正文为空是正常的400请求语法错误看请求头和正文格式常见于缺 Host 或 JSON 格式错401 / 403未认证 / 无权限401 看凭证403 看权限配置别混为一谈404资源不存在可能真是路径错也可能是路由没匹配上502网关从上游收到无效响应上游进程挂了或返回了非法内容504网关等待上游超时上游处理太慢看慢查询和线程池502 和 504 是最值得展开的两个。502 是反向代理连上了上游但上游返回的东西不符合 HTTP 规范或者连接被上游直接断开。常见原因包括上游进程崩溃、上游返回了非 HTTP 内容、连接复用配置不一致。504 是代理等上游响应超时说明上游还活着但太慢。两者的处置方向完全不同502 查进程和端口504 查性能和超时阈值。还有一个坑301 被浏览器长期缓存几乎无法通过服务端控制清除。做过一次错误的重定向配置用户浏览器会一直跳错地址只能让用户清缓存。所以做永久重定向一定要慎之又慎能用 302 就别用 301除非你百分百确定。3.3 连接复用、管道化与队头阻塞HTTP/1.0 默认每次请求新建一条 TCP 连接用完就关。这在早期网页只有几个资源的时候无所谓但现代页面动辄几十上百个请求每次都要三次握手加慢启动开销大到不可接受。所以 HTTP/1.1 默认开启持久连接用Connection: keep-alive表达一条连接上可以串行发多个请求。但串行就意味着队头阻塞——前一个请求的响应没回来后面的只能等着。理论上 HTTP/1.1 有管道化pipelining可以连续发多个请求不等响应但实际部署中问题太多响应必须按序返回、中间设备兼容性差、无法处理乱序所以主流浏览器全部默认关闭。实际的应对办法是开多条连接。浏览器对同一域名通常维持 6 个左右的并发连接这也是为什么早期前端优化里有一堆域名分片的技巧——把静态资源分散到多个子域绕过单域名连接数限制。这个技巧在 HTTP/2 普及后基本废弃了因为 HTTP/2 用二进制分帧在单条连接上做了多路复用多个请求可以并行交错传输不再需要开多连接。理解这段历史很有必要因为它解释了现在很多看起来莫名其妙的工程实践。比如为什么静态资源要单独放一个域名、为什么要做资源合并、为什么早期提倡雪碧图。这些方案的共同目标是减少请求数和绕过连接数限制而 HTTP/2 之后这些优化反而可能变成负优化比如过度合并会导致缓存粒度变粗改一个图标整个包都失效。3.4 缓存与协商机制的实际配置HTTP 缓存分强缓存和协商缓存两层。强缓存命中时浏览器直接用本地副本连请求都不发协商缓存则要发一次请求带上校验字段服务端说没变就返回 304浏览器用本地副本。强缓存靠Cache-Control控制关键指令是max-age相对秒数、no-cache可以缓存但每次要校验、no-store完全不缓存、public/private是否允许中间代理缓存。协商缓存靠两组字段ETag配If-None-MatchLast-Modified配If-Modified-Since。配置上有几条实操原则。第一带用户身份的内容一律 private 或者 no-store否则被 CDN 缓存了就是数据泄露事故这个坑每年都有人踩。第二静态资源用内容哈希命名配超长的 max-age因为文件名变了 URL 就变了压根不需要靠过期来控制更新。第三HTML 入口文件千万别设长缓存否则用户永远拿不到新的资源引用。HTTP/1.1 200 OK Cache-Control: public, max-age31536000, immutable ETag: a1b2c3d4 Content-Type: application/javascriptimmutable这个指令值得提一句它告诉浏览器在 max-age 有效期内连刷新都不要去校验直接跳过协商请求。配合哈希文件名使用能把静态资源的请求量压到极低。提示no-cache不是不缓存是每次使用前必须校验别把它和no-store搞混。想彻底不落盘用no-store。4. 邮件、文件传输与其他经典协议4.1 邮件系统的三段式架构与协议分工邮件这套体系比大多数人想的要复杂因为它分了发送、投递、收取三个阶段每个阶段用不同协议很多人把 SMTP 和 POP3 混着记实际用途完全不同。SMTP 负责推把邮件从客户端推到提交服务器以及从提交服务器推到目标域的接收服务器。它假设对方随时在线如果对方不在就排队重试。POP3 和 IMAP 负责拉让用户从自己的邮箱里把邮件取下来。POP3 的语义是下载后可以删除客户端是权威数据源IMAP 的语义是服务器是权威数据源支持多端同步、文件夹、服务端搜索。现在多设备场景下基本都是 IMAPPOP3 只剩下少数老旧场景。邮件内容本身的格式也有很多门道。一封邮件是头部 空行 正文正文用 MIME 扩展支持多部分可以同时包含纯文本和 HTML 两个版本也可以带附件。Content-Type里的multipart/alternative表示多版本二选一客户端优先渲染靠后的那个multipart/mixed表示这些部分都要展示。这个区别决定了客户端是显示纯文本还是 HTML配错了会出现邮件正文显示成一堆源码的现象。投递失败的原因八成集中在三处MX 记录配置错误、发信源 IP 信誉不足被拒、SPF/DKIM/DMARC 校验不通过。前两个好理解第三个是很多人第一次配邮件服务时踩的坑。SPF 是在 DNS 里用 TXT 记录声明哪些主机有权代表这个域发信DKIM 是给邮件签名让接收方验证未被篡改DMARC 是对齐策略。这三者不配邮件要么进垃圾箱要么直接被拒收。4.2 FTP 的主动与被动模式FTP 是个很有意思的协议因为它用两条连接分别传命令和数据这在当年是为了让数据可以不走控制连接、支持边传边操作但放到 NAT 和防火墙普及之后就变得很难受。主动模式下客户端告诉服务端我监听在某个端口你来连我服务端从自己的 20 端口发起数据连接回连客户端。问题是客户端在 NAT 后面的话服务端根本连不进去所以现在基本不可用。被动模式反过来服务端打开一个随机端口把端口号通过控制连接告诉客户端由客户端发起第二条连接。这才是现在能用的方式。即便如此被动模式在严格防火墙下仍可能失败因为随机端口范围往往没被放开。配置时要把服务端的被动端口范围固定下来再在防火墙上按范围放行这个动作在实际部署里经常被漏掉表现是能登录、能列目录但一传文件就卡住。顺带说一句现在做文件传输基本不用 FTP 了SFTP 走 SSH 通道天然加密只用一条连接或者直接走 HTTPS 上传。FTP 明文传输账号密码这一点在任何认真考虑过安全的场景里都是硬伤。4.3 DHCP被忽视但时刻在用的协议DHCP 虽然名字里没有应用层三个字但它确实是应用层协议跑在 UDP 的 67 和 68 端口上。它的作用是在设备接入网络时自动分配地址、掩码、网关和 DNS 服务器。流程是四步业界叫 DORADiscover客户端广播喊有没有 DHCP 服务器、Offer服务器回复我可以给你这个地址、Request客户端广播我要这个、Ack服务器确认。第一步用广播是因为客户端还没有地址不知道服务器在哪。第二步之后仍然用广播是为了让所有服务器都知道这个地址已经被占用了。这里有个细节值得说租约。地址不是永久分配的是有租期的。客户端在租期过半时会主动续租续租失败到租期结束时才放弃地址重新走 DORA。这个机制保证了地址能被回收复用也让设备换网络之后能快速拿到新地址。常见的 DHCP 故障有三类地址池耗尽表现为部分设备拿不到地址用了自动私有地址、网关或 DNS 配置下发错误表现为能上网但解析不了域名、以及网络里存在多个 DHCP 服务器造成冲突。第三个问题最隐蔽因为设备会接受先到的那个 Offer表现为某些设备上网正常某些不正常排查时要用抓包看 Offer 到底来自哪个地址。4.4 WebSocket 与长连接的握手细节传统 HTTP 是请求-响应模式服务端没法主动推消息。早期用轮询和长轮询来模拟前者浪费请求后者占用连接。WebSocket 解决的就是这个问题在一条 TCP 连接上做全双工通信。它的建立过程很巧妙——借用了 HTTP 的握手。客户端先发一个普通的 HTTP 请求带上Upgrade: websocket、Connection: Upgrade、Sec-WebSocket-Key等头部。服务端如果支持返回 101 状态码表示协议切换之后这条连接就不再走 HTTP 语义而是走 WebSocket 的帧格式了。GET /chat HTTP/1.1 Host: example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ Sec-WebSocket-Version: 13这么设计的好处是能穿过绝大多数只认 HTTP 的中间设备和代理不需要额外开放端口。但实际部署中仍然有坑负载均衡如果配了短的空闲超时连接会被悄悄掐断某些代理不认识 Upgrade 头会把连接降级。所以生产环境里必须配心跳——客户端定期发 ping 帧服务端回 pong既能保活也能及时发现连接已死。心跳间隔怎么定我的经验是比链路上最短的空闲超时小一半左右。如果负载均衡的空闲超时是 60 秒心跳就设 20 到 30 秒。设太长会被设备先踢设太短则增加无谓流量。5. 应用层排障实操全流程5.1 工具链准备与分层验证顺序排障最忌讳一上来就抓包。抓包信息量大没有假设地看等于大海捞针。我习惯的顺序是先验名字再验连接最后验语义。第一步验证名字解析。用dig或nslookup看返回的地址对不对TTL 是否合理有没有 CNAME 链。这一步能解决掉相当比例的打不开问题。第二步验证连接用curl -v或者telnet看 TCP 能不能建起来如果卡在连接阶段问题在传输层或者中间网络设备。第三步才看应用层报文用curl -v看完整的请求响应头或者抓包看原始字节。# 只看解析结果快速判断 dig short example.com # 看完整交互包括握手、请求头、响应头 curl -v -o /dev/null -s https://example.com/ # 只测到建立连接为止不传数据 curl -v --head https://example.com/ # 抓 80 端口的 HTTP 报文-A 打印 ASCII tcpdump -i any -A -s 0 tcp port 80 -w http.pcapcurl -v的输出里以*开头的是连接层信息以开头的是发出的请求头以开头的是收到的响应头。这个约定能让你一眼分清问题出在哪一层非常好用。5.2 DNS 侧故障的定位手法DNS 故障的表现通常是偶发慢或者部分用户访问异常。偶发慢多半是解析链路长或者权威服务器响应慢部分用户异常多半是缓存不一致。定位方法先在出问题的客户端上dig目标域名看返回的服务器和 TTL。如果 TTL 明显偏大说明命中了某层缓存。再用dig norecurse 权威服务器地址直接问权威对比结果。如果权威返回新值而客户端拿旧值问题就在缓存。还有一种情况是解析结果在不同地区不一样这通常是权威服务器做了基于来源的智能解析。验证方法是找不同出口的机器分别dig对比结果。如果确实做了地域调度那么某地访问慢就不是故障是调度策略的问题要去看调度规则是否合理。注意NXDOMAIN是这个域名真的不存在SERVFAIL是服务器无法完成查询NOERROR但返回空答案是存在但没有该类型的记录。三个状态对应三种完全不同的排查路径别看到解析失败就往域名被删了上想。5.3 HTTP 侧故障的定位手法HTTP 故障分两类连不上和连上了但结果不对。连不上先看curl -v卡在哪一步。如果卡在Trying x.x.x.x:443...是 TCP 没建起来查防火墙、查服务是否监听、查安全策略。如果卡在 TLS 握手阶段是证书或加密套件协商问题。如果已经发出请求但迟迟没响应那是服务端处理慢对应 504 或者客户端超时。连上了但结果不对重点看状态码和响应头。401 和 403 要区分清楚前者是没提供凭证或者凭证无效后者是提供了但没权限。502 要去看上游服务是否存活、是否返回了非 HTTP 内容。304 看起来没返回内容其实是正常的缓存命中不要误判成故障。还有一个隐蔽的问题响应头里有Transfer-Encoding: chunked但正文被中间设备截断表现为客户端一直等不到结束块超时后才报错。这种情况在中间有代理、且代理对长连接处理不当时会出现抓包能看到最后一个块的长度不是 0。排查时用curl --raw看原始字节能直接看到分块结构。# 查看完整的原始响应包括分块边界 curl --raw -s https://example.com/ | head -50 # 只请求头快速看状态码和缓存策略 curl -sI https://example.com/5.4 常见问题速查表现象可能原因验证方式处置首次访问慢之后正常解析链路长 / 首次握手开销dig trace看耗时分布缩短 CNAME 链启用长连接部分用户访问到旧资源静态文件长缓存未更新看响应头 Cache-Control文件名加哈希或降 max-age偶发 502上游进程重启或连接复用不一致查上游日志和进程存活调整 keepalive 配置加健康检查偶发 504上游处理超时看慢查询和线程池优化耗时操作调整超时阈值传文件卡住FTP 被动端口未放行抓包看数据连接是否建立固定被动端口范围并放行WebSocket 几分钟断一次中间设备空闲超时看断连时间是否有规律加心跳间隔小于空闲超时一半邮件进垃圾箱SPF/DKIM/DMARC 未配或配错检查 DNS 里的 TXT 记录补齐三条记录并对齐域同域名不同地区解析不同智能解析调度多出口分别 dig 对比核对调度规则属正常行为这张表我自己是常驻在排查笔记里的遇到现象先对一遍能省掉大量试错。6. 内容分发与应用层加速6.1 CDN 的调度逻辑与回源链路CDN 本质上是一个应用层的分布式缓存系统它解决的核心问题是物理距离带来的延迟和源站带宽成本。它的调度逻辑值得拆开看因为很多人只把它当黑盒用出了问题不知道怎么定位。接入方式通常是把业务域名的 CNAME 指向 CDN 服务商给的域名用户解析时就会拿到离他最近的边缘节点地址。这个最近由全局负载均衡决定依据可能是地理位置、运营商、节点负载、或者探测到的实际链路质量。回源是缓存没命中时的动作。边缘节点发现本地没有就向上一级节点或者直接向源站请求拿到之后按策略缓存。这里有个关键配置叫回源 HOST——它决定了回源时请求头里的 Host 是什么。配错了会导致源站收到不认识的域名返回 404 或者默认站点。这个坑极其常见尤其是接入多个站点的时候。缓存策略的配置原则和前面讲的 HTTP 缓存一致但多了一条CDN 只应该缓存明确可共享的内容。带Set-Cookie的响应、带用户标识的接口、私有数据一律不缓存。技术上可以在 CDN 侧配置忽略某些参数或者强制不缓存但最稳妥的做法是源站直接把Cache-Control: private写清楚让 CDN 默认遵守。还有一个经常被忽略的点是缓存刷新。改了源站的静态文件CDN 上还是旧的就算文件名没变也要主动刷新。刷新的生效时间取决于节点数量和分发机制通常几分钟到十几分钟。所以上线流程里必须预留这个时间或者干脆用文件名哈希的方式规避。6.2 应用层网关与反向代理的角色反向代理挡在服务前面承担了 TLS 终止、路由分发、限流、压缩、静态文件直出等职责。它在应用层的价值在于把通用能力从业务代码里抽出来让业务只关心逻辑。最常见的配置是路径路由和头部改写。路径路由按 URL 前缀把请求分给不同的上游服务头部改写则是补上或者覆盖某些头比如把真实客户端地址放到X-Forwarded-For里让后端能拿到。这个头要注意它是可被伪造的只有经过可信代理层追加的那部分才可信取的时候要从右往左取。超时配置是反向代理里最容易出问题的地方。一般有三段超时连接上游超时、读取上游响应头超时、以及空闲超时。三段都配成一样是不对的连接超时应该短几秒响应头超时可以稍长而对待长任务接口要单独设更长的读超时否则就会出现接口明明在跑但网关先返回 504的情况。提示反向代理和上游同时配了 keepalive 的情况要特别注意两边参数要匹配。代理侧的空闲连接超时如果比上游长会复用一条上游已经关掉的连接表现就是偶发的 502。这类问题用抓包看连接复用行为最快。压缩也值得说一下。文本类内容开 gzip 或者 brotli压缩率能有七八成对首屏影响明显但图片视频这类已经压缩过的格式再压就是浪费 CPU。而且压缩是在代理层做的还是源站做的效果和开销不一样通常放在代理层更划算因为可以统一控制并且释放源站 CPU。7. 几个我在实际项目中踩过的坑7.1 关于改了没生效的三个典型第一个坑是改 DNS 记录后立刻验证结果还是旧值就以为没改成功。实际是本地缓存或者本地域名服务器缓存没过期。正确姿势是先确认权威返回的是新值再接受全网生效需要等 TTL这个事实。第二个坑是改了重定向规则但用户还跳到旧地址。原因是之前配过 301浏览器把它缓存了服务端怎么改都没用。这个的教训是不确定的场景一律用 302301 只在你百分百确定永久不变的时候用。第三个坑是改了静态资源但页面样式没变。原因是 HTML 没设短缓存浏览器拿了旧的 HTML里面引用的还是旧的文件名。所以入口 HTML 必须是短缓存或者不缓存这个是硬性要求。7.2 关于偶发问题的定位思路所有偶发问题的排查核心都是找到什么条件下必现。我的做法是记录每次失败的时间戳、客户端出口地址、请求的完整头部、以及对应的服务端日志然后找规律。是特定地区特定运营商特定时间点特定请求头特征WebSocket 断连这个例子很典型。一开始以为是代码问题加了日志发现断连时间间隔非常规律基本在 60 秒左右一看就是中间设备有空闲超时。改成 25 秒心跳之后就再没出现过。如果当时一上来就翻代码估计要查很久。502 偶发也一样规律可能是每隔一段时间出现一批那就往连接池和上游重启上想如果是高峰期必现那就往资源耗尽上想。规律比单次现象重要得多。7.3 关于协议版本升级的实际收益从 HTTP/1.1 升到 HTTP/2收益主要在请求数多的场景比如首屏要加载几十个资源的页面。多路复用消除了连接级别的队头阻塞也省掉了开多连接的开销。但如果你的页面资源本来就少、或者瓶颈在服务端处理速度那升上去的感知会很弱。实际做的时候有几点要注意HTTP/2 在浏览器端强制要求 TLS所以得先把证书搞好多路复用之后之前的域名分片技巧要撤掉否则反而把连接拆散了还有就是服务端的并发处理能力要跟上因为单连接上并行请求的并发度上来了后端线程池和数据库连接池可能需要调大。提示升级之前先测别凭感觉。用同一个页面在两种协议下各跑一遍看首屏时间和请求瀑布图差异一目了然。8. 写在最后的一点个人体会应用层是唯一一层协议行为和业务语义直接耦合的层。传输层出问题表现是连不上或者慢应用层出问题表现是功能不对。这个特性决定了它没法靠通用工具一把梭必须懂业务才能定位。我自己这几年最大的转变是把排障顺序从先看代码改成了先看链路。绝大多数所谓的应用层疑难杂症追到根上都是名字解析、缓存、超时、连接复用这几件事真正需要改代码的比例并不高。手里有几个顺手的工具——dig、curl -v、抓包——再加上一张现象对照表能省下的时间比想象中多得多。这一层讲完整个六层的骨架算是搭完了。后面如果还要往下写我更想聊的是这些协议在真实流量下的组合行为比如一次页面加载背后到底触发了多少次解析、多少条连接、多少层缓存那种把静态知识串成动态链路的感觉比单纯记协议有用得多。