1. HTTP到底是个啥：先搞懂协议和通信模型

1.1 协议的本质：双方共同遵守的“行话”

HTTP这个缩写，凡是碰过网站开发的人都不陌生。地址栏里的https://、接口文档里的POST、浏览器F12面板里那一排200和404，背后都是同一个协议在工作。但说实话，能把HTTP完整讲清楚的文章不多。大多数教程要么只讲请求和响应，要么直接甩给你一张状态码表，看完还是不知道为什么线上接口会慢、刷新后缓存为什么不生效、HTTPS握手到底多了几次往返。

我先把概念放下来，用个生活化的例子。

HTTP本质上是一种约定，是客户端和服务器之间关于“怎么问、怎么答”的规矩。你可以把它想象成去餐厅点餐：你拿起菜单（URL），告诉服务员你要什么（HTTP请求），服务员转身把单子交给后厨（服务器处理），然后后厨把菜端上来（HTTP响应）。这个过程大家都很熟悉，但把“点菜”变成机器能懂的流程，就需要双方说同一种行话——这就是HTTP协议。

另一个更贴切的类比是快递。底层的TCP协议就像快递物流，负责把你寄的东西安全、完整地从A地运到B地，不丢件、不串件。而HTTP是写在包裹上的单据格式：收件人是谁、寄的什么东西、什么时间寄出的。没有这个大快递系统，HTTP说白了跑不起来；没有HTTP这层单据规则，TCP也不知道该怎么把数据传输给“看看网页”这个动作。

所以HTTP属于应用层协议，它不关心数据在网络上具体经过哪些路由器、走的是光纤还是Wi-Fi，它只关心两端之间的语义沟通。这种分层设计最大的好处是，你可以在HTTP下面换成任何可靠的传输机制，上层不需要改动。

1.2 三个绕不开的特性：请求-响应、无状态、明文

要理解HTTP，必须先接受它的三个“底层性格”。这三个特性和后期很多技术方案（Cookie、Session、HTTPS、缓存）都密切相关。

第一个特性是请求-响应模型。这是一问一答的通信模式。客户端发起一个请求，服务器必须给一个响应，不存在服务器主动往客户端推数据的逻辑（后来搞的WebSocket、SSE另说）。你打开网页时，那个页面上的每个图片、每个接口、每段脚本，都是浏览器主动发起的独立请求。服务器不会在你什么都没问的情况下，突然把一堆图片塞过来。

第二个特性是无状态。这是新手最容易迷糊的地方。HTTP协议本身根本不记得上一次请求是谁发的，也不记得上次请求干了什么。每次请求对服务器来说都是“初次见面”。这就好比你去同一家便利店买了三次东西，每次结账店员都当你是新顾客。你理解这一点后，再看Session、Cookie、Token这些东西就不会乱了——因为它们的存在，本来就是为了弥补HTTP无状态这个天生的缺陷，给网络应用强行加上“记忆”。

第三个特性是明文。在HTTPS普及之前，HTTP报文是直接以文本形式在网络上传输的。这就意味着任何能在网络路径上监听的人，都能直接看到你的账号密码、聊天内容、银行卡号。现代互联网几乎全面转向HTTPS之后，纯HTTP已经很少见了，但理解“明文时代”的痛点，你才能真正理解HTTPS那一套复杂的加密机制到底在防谁。

1.3 一个完整请求经历了什么

纸上谈兵没意思，我带你从输入一个网址开始，完整走一遍HTTP请求的旅程。整个过程看起来是一瞬间，实际上分成好几个阶段。

第一步是DNS解析。你输入一个域名，比如https://example.com，但网络通信靠的是IP地址，所以浏览器要先去问DNS服务器：“example.com的IP是多少？”这个环节会消耗几十毫秒，很多时候用户感觉卡顿，瓶颈就在这里。

第二步是TCP三次握手。拿到IP之后，浏览器要和这台服务器建立一个TCP连接。三次握手是为了保证双方都有发送和接收能力：客户端先发个“SYN”包，服务器回个“SYN+ACK”，客户端再回个“ACK”。整个过程相当于双方先互相对个口号，确认“我听得到你，你也听得到我”，然后才开始正式传递数据。

第三步才是发送HTTP请求。TCP连接建立后，浏览器把准备好的请求报文交给TCP，TCP负责分包、排序、重传，最终完整到达服务器。服务器处理完业务逻辑后，把HTTP响应按同样路径返回给浏览器。

这里有个关键点你需要记住：每个网络请求，如果复用之前的TCP连接，就能省掉第三次握手的过程。这就是连接复用的价值。HTTP/1.0时代每请求一次就要重新握手，所以网页稍微复杂一点就会卡得让人抓狂。HTTP/1.1把连接复用变成了默认行为，之后的性能问题才得到缓解。

最后是浏览器渲染。响应到了浏览器之后，浏览器解析HTML，发现里面还引用了CSS、JS、图片，于是再发起一堆新的HTTP请求。每个请求又走一遍上面的流程，直到整个页面渲染完成。

2. 报文拆解：请求和响应里到底装了什么

2.1 请求报文的四个组成部分

HTTP报文的结构比很多人想象中简单，就四个部分：请求行、请求头、空行、消息体。我直接给你看一个真实格式的请求报文：

POST /api/login HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 Accept: application/json Content-Type: application/json Content-Length: 36 {"username":"demo","password":"123456"}

第一行是请求行，包含三个信息：请求方法（POST）、请求路径（/api/login）、协议版本（HTTP/1.1）。光这一行就能告诉服务器，我要做什么操作、操作哪个资源、用什么协议版本交流。

第二行到空行之前是请求头。每一行都是“键: 值”的格式，用来携带一些附加信息。比如Host告诉服务器访问的是哪个域名，这在多站点共用一台服务器的场景下至关重要；User-Agent让服务器知道你是浏览器还是爬虫、什么版本的系统；Content-Type声明消息体的格式，服务器要按什么格式解析；Content-Length说明消息体的字节长度，方便服务器知道读多少算完。

注意那个空行，千万别以为它是格式美观而已。HTTP规定头部结束必须以一个空行作为标记，服务器看到空行才知道“头部结束了，接下来的内容都是消息体”。没这个空行，接收方根本没法区分头部和消息体。

消息体就是实际传输的数据。GET请求通常没有消息体，POST/PUT类的请求才会有。这里放的是JSON格式的登录信息。

打开这种报文的感觉，就像打开一封信：信封上写着寄给谁（Host）、用什么笔写的（User-Agent）、里面装的是什么（Content-Type），正文放在空行下面。

2.2 请求方法：GET、POST、PUT、DELETE、PATCH等

HTTP请求方法定义了“你想对资源做什么”。最常见的是GET和POST，但完整的方法表远不止这两个。

这里的安全性指的是不会修改服务器上的数据，不是指加密。GET请求被设计为只读操作，但它实际是否安全，取决于你的后端代码怎么写——如果你在GET接口里偷偷改数据库，那就违反了语义，坑的是后来维护你的同事。

幂等性的意思更专业：同一个请求执行一次和执行一万次，结果都一样。PUT和DELETE天然幂等，因为PUT是“把资源整体设置成这个值”，不管执行几次，最终状态都一样。POST不一样，每执行一次就可能创建一条新数据，所以支付、下单这类操作千万别用GET，也别以为POST重复提交没关系。幂等性在重试机制里尤其重要：客户端请求超时后自动重试，如果接口不幂等，用户可能会收到两条订单。

2.3 响应报文与状态码：从200到503

响应报文的结构跟请求报文对称：状态行、响应头、空行、消息体。状态行长这样：

HTTP/1.1 200 OK

协议版本、状态码、原因短语。状态码是一个三位数字，第一位代表大类。你不需要背下所有状态码，但至少要能一眼判断大类：

实际开发里，有几个状态码很容易用错或者看错。

204 No Content表示请求成功了，但响应没有内容体。常用于删除操作后不需要返回数据的场景。304 Not Modified是缓存协商的结果，表示“你本地缓存的那个版本还有效，不用重新下载了”。401和403经常被混淆：401是“你没有身份凭证”，403是“你有身份，但没权限”。301是永久重定向，搜索引擎会更新链接记录；302是临时重定向，只是这次先跳到别处。503是服务器临时过载或维护中，502是网关拿不到上游的合法响应。排查线上问题的时候，光看状态码你已经能排除一半嫌疑。

2.4 如何看真实报文：curl和浏览器开发者工具

纸上报文看着简单，但实际开发中报文是封装在浏览器里的，怎么直观地看到呢？两个工具足够：命令行工具和浏览器自带的开发者工具。

命令行里最常用的是curl，它能看到最原始的交互过程。加上-v参数，它会打印整个会话的细节：

curl -v https://example.com/

运行之后，你会看到以*开头的行是底层连接信息（TCP连接、TLS握手），以>开头的行是发出的请求头，以<开头的行是收到的响应头。这是最接近协议本身的观察方式。我曾经遇到过线上接口莫名其妙多了一次重定向，用curl一看就发现是某个中间层悄悄加了一条跳转规则——这种问题在浏览器里根本发现不了。

浏览器开发者工具更适合日常调试。按F12打开“网络”面板，刷新页面，每一个请求都在列表里。点开任意一个，能看到完整的请求头、响应头、消息体、耗时分布。这比curl直观得多，而且能看到浏览器特有的行为，比如强制缓存时“from disk cache”的标记。我建议两类工具配合使用：浏览器看全貌，curl看细节。

3. 从HTTP到HTTPS：数据在传输中如何不被偷看

3.1 为什么HTTP不够安全：窃听与篡改

理解HTTPS之前，先弄清楚HTTP的“裸奔”到底有多危险。

HTTP报文是明文传输的，而且它跑在网络链路上。你坐在咖啡厅里连了公共Wi-Fi，理论上同一个Wi-Fi里任何懂技术的人都可以抓网络包，直接看到你发的所有HTTP报文内容。如果你的登录接口还是HTTP的，账号密码就相当于写在明信片上，一路经过十多个网络节点，每个节点拆开就能看到。

比窃听更恶心的是篡改。攻击者在中间改掉响应里的内容，往HTML里插入一段恶意脚本，你在浏览器里看到的可能就是完全被篡改过的页面，这比偷密码还难防，因为你根本不知道页面被动手脚了。

HTTPS解决的就是这两件事：加密（让别人看不懂）+ 完整性校验（让别人改不了）。HTTPS并不是一套独立的协议，它就是在HTTP和TCP之间加了一层TLS/SSL加密层。HTTP负责语义，TLS负责安全。

3.2 加密技术的组合：对称加密与非对称加密的配合

既然要加密，就直接用最简单的方式加密啊？问题没有这么简单。

对称加密（比如AES）性能高，但双方必须持有同一把密钥。这把密钥本身要传到对方手里，如果直接传，传输过程中被截获就等于白加密了。

非对称加密（比如RSA）思路很有意思：它有一对钥匙，公钥可以公开，私钥只自己保留。用公钥加密的数据只有私钥能解开，用私钥加密的数据只有公钥能验证。看起来完美解决了密钥传输问题，但非对称加密的计算开销比对称加密大了好几个数量级，如果所有数据都用它加密，服务器会累死。

所以实际方案是混合加密：通信双方先用非对称加密完成密钥交换，安全地确认一把随机生成的“会话密钥”，之后所有业务数据都用这把会话密钥配合对称加密来传输。打个不太准确但好懂的比方：你先用一个上锁的保险箱把一把普通钥匙寄给对方，之后所有贵重物品都用那把普通钥匙开锁存取。保险箱锁很慢，但只寄一次钥匙；普通钥匙很快，日常大量数据全靠它。

3.3 证书与证书链：信任从哪里来

但密钥交换里有个漏洞：如果攻击者在握手阶段就把自己的公钥替换给客户端，客户端以为自己在跟服务器说话，实际上是在跟中间人说话，后面所有加密都白搭。怎么保证收到的公钥真是服务器的？

答案是数字证书。服务器把自己的公钥和域名等信息交给一个被所有人信任的第三方机构（CA），CA用它的私钥给这些信息签名，生成一张证书。客户端收到证书后，用CA的公钥验证签名，确认证书没有被篡改，然后才相信证书里的公钥是可信的。

证书里还有一层机制叫证书链。根CA证书内置于操作系统或浏览器中，它给中间CA签发证书，中间CA再给具体的网站签发证书。客户端验证的时候，从网站证书一路回溯到根证书。如果链条上的任何一环不被信任，浏览器就会弹安全警告。这就是你在本地测试自签证书时浏览器报“不安全”的原因——不是加密不可靠，而是整个信任链的起点不受客户端认可。

3.4 TLS握手流程与优化要点

HTTPS的加密不是在传输前一次性完成的，建立加密通道需要一次握手。这一步经常被人忽略，但它对性能影响很大。

拿TLS 1.2来说，完整握手大致是：

1. 客户端发ClientHello：告诉服务器我支持的TLS版本、加密套件、一个随机数。
2. 服务器回ServerHello：选定加密套件和协议版本，同时带上自己的证书。
3. 客户端验证证书，生成一个PreMasterSecret，用服务器公钥加密后发给服务器。
4. 双方根据相同的随机数和PreMasterSecret各自计算出会话密钥。
5. 双方互发Finished消息确认，之后开始用会话密钥加密通信。

这个过程在TCP三次握手之后还要额外占用2个RTT，也就是说一个全新的HTTPS请求，正式发送业务数据之前已经花了3个RTT在“建路”上。

幸好现代协议一直在优化这块。TLS 1.3把握手压缩到了1-RTT，会话恢复场景下甚至可以做到0-RTT。所以在实际工程里，除了升级TLS版本，还会做几件事：启用会话恢复（Session Ticket）、开启OCSP Stapling、尽量复用TLS连接。这些术语可能听起来陌生，但它们直接决定了用户感知到的首屏延迟。你拿一个没有优化过的HTTPS服务器和一个优化过的相比，同样的网络环境下差别会非常明显。

4. HTTP版本演进：从1.0到3.0都改了些什么

4.1 HTTP/1.0与1.1：连接复用成为分水岭

HTTP协议发展到现在经历了多个版本，最核心的演进逻辑就两个字：更快。早年HTTP/1.0时代，每次请求都要新建一个TCP连接，请求完立即断开。一个包含10张图片的网页，光建立连接就得来回10次TCP握手，用户体验可想而知。

HTTP/1.1最大贡献是默认持久连接。同一个TCP连接上可以连续发送多个请求和响应，请求完连接不马上断，下个请求还能复用。同时它还引入了Host头，让一台服务器上可以托管多个域名；引入了分块传输编码，让动态生成的响应不需要预先知道长度就能流式输出；还支持断点续传相关的Range头。

不过HTTP/1.1有个著名的痛点叫队头阻塞：一个TCP连接上同一时间只能处理一个请求，如果前一个请求响应很慢，后面的请求只能排队等着。为了缓解这个问题，浏览器一般会对同一域名开6个左右的并行TCP连接。这个方案不算优雅，但确实能缓解症状。

4.2 HTTP/2：多路复用与二进制分帧

HTTP/2在2015年发布，它做了一件本质性改变：把HTTP报文从文本格式改成了二进制分帧格式。文本格式的好处是调试友好，但机器解析效率低、格式边界含糊。二进制格式虽然人看不懂，但机器处理起来非常高效。

更重要的是，HTTP/2在同一个TCP连接上实现了多路复用。多个请求可以交错传输，不用再一个个排队。以前一个慢请求堵住后面所有请求的问题，在应用层面基本消失了。同时，HTTP/2还做了一套头部压缩机制，因为浏览器请求文本资源时，Cookie、User-Agent这些头部动辄几KB，大部分内容还都是重复的。头部压缩后，这部分开销大幅下降。

有一个很多教程忽略的细节：HTTP/2虽然解决了应用层的队头阻塞，但TCP层的队头阻塞依然存在。因为TCP本身就是按顺序传输的，如果一个数据包丢了，后续数据必须等它重传。这个问题的根治方案不在TCP层，而在换掉TCP。

4.3 HTTP/3与QUIC：绕开TCP的新思路

既然TCP层有队头阻塞，HTTP/3干脆换了一条路：跑在基于UDP的QUIC协议上。QUIC自己实现了可靠传输、拥塞控制、加密连接，并且原生支持多路复用和连接迁移。

这里有个知识盲点：很多人以为UDP=不可靠=不能传重要数据，其实UDP只是个传输载体，可靠性完全可以由上层协议自己实现。QUIC就是可靠UDP的典型代表。它最大优势有三个：一是每个请求的数据流独立，某个流丢包不影响其他流；二是握手耗时短，把TLS 1.3直接集成进来，新建连接时通常1-RTT就能开始传数据，连接恢复时0-RTT；三是连接迁移，IP地址变了连接不中断——你在Wi-Fi切到4G的时候，视频通话不断流，靠的就是这个能力。

当然HTTP/3还没有全面取代HTTP/2的规模。它要求中间设备（路由器、防火墙、网关）能放行UDP流量，一些老旧的网络设备对UDP并不友好。但大趋势已经很明显，新协议一旦铺开，很多性能优化手段会再次面临洗牌。

4.4 版本选择建议与运维注意

版本这么多，实际项目里怎么选？我的经验是分情况看。

静态资源占比高、首屏速度敏感的场景，优先支持HTTP/2，部署成本相对低，只需要Web服务器配置一下、证书配齐，客户端自动协商升级。如果长连接场景多、弱网环境多，或者希望降低连接建立延迟，可以考虑HTTP/3，但前提是你对全网UDP路径有基本判断。

有一个常见坑：Web服务器前端如果还有一层老旧的负载均衡设备或反代软件，它可能不支持HTTP/2甚至HTTP/1.1的某些特性。结果你后端配置了HTTP/2，但这一层不兼容，导致连接协商失败又回退到HTTP/1.1，性能提升全白搭。我见过不止一次这种“配了但没生效”的事故。升级协议版本时，一定要从最边缘的入口设备排查到源站，确认整条链路都支持，才能落到实处。

5. 缓存机制：让HTTP再快一步的关键

5.1 强缓存与Cache-Control

HTTP缓存是性能优化里见效最快、成本最低的手段之一，但它也是最容易被搞混的机制。我先把规则拆开讲。

浏览器拿到一个响应后，如果响应头里有缓存相关的指令，它会先判断“这东西能不能直接用本地副本”。这个判断叫强缓存。最常用的是Cache-Control头：

Cache-Control: max-age=31536000

max-age是相对时间，单位秒，含义是“从响应生成时刻算起，这个副本在31536000秒内可以直接复用”。在这一年内，浏览器再请求同一个URL，根本不发出请求，直接拿本地缓存，性能自然极快。你在开发者工具里看到的“from disk cache”就是这个过程。

注意几个容易踩的坑。Cache-Control: no-cache不是“不缓存”，而是“可以缓存，但每次使用前必须去服务器验证一下”。真正不让缓存的是no-store。max-age和Expires同时出现时，Cache-Control优先级更高，因为Expires是绝对时间，客户端时钟不准会导致判断失误，max-age没有这个问题。

5.2 协商缓存：Last-Modified与ETag

有时候资源确实更新了，但你没法预先知道什么时候改，强缓存就不太适用。这时候可以用协商缓存。

协商缓存的流程是：浏览器带上一个条件请求头去问服务器，“我本地这个版本还能用吗？”服务器判断后，如果没变，就返回304 Not Modified，不带任何消息体；如果变了，就返回200和新的内容。虽然每次都会发请求，但304的响应体非常小，比重新下载整个资源省太多了。

Last-Modified记录的是资源最后修改时间，浏览器带上If-Modified-Since去问。它的缺点是精确到秒，而且有时候内容没变但文件时间变了，导致缓存失效。ETag是资源的唯一标识，通常是根据内容算出来的指纹，更准确。两个同时存在时，ETag优先。

我建议API接口设计时尽量带上ETag。比如一个详情页接口，如果数据没变化，客户端拿ETag来协商，返回304省流量；数据一变，ETag自动变，客户端拿到新数据。理解这套机制后，你再看到线上“304”刷屏就不会慌，那是缓存正在勤勤恳恳工作。

5.3 启发式缓存与缓存策略设计

有一种情况很多人不知道：如果响应既没有Cache-Control，也没有Expires，但带有Last-Modified，浏览器会进行启发式缓存——它基于上次修改时间与当前时间差的某个比例来估算缓存有效期。这个比例不是HTTP协议强制规定的，不同浏览器可能完全不同。所以生产环境千万不要依赖启发式缓存，它只是个兜底策略，不是可预期的机制。

真正稳妥的缓存策略，我习惯按资源类型分开设计：

• 带指纹的静态资源（比如app.a1b2c3.js）：文件内容变了，文件名就变，URL跟着变，所以可以放心大胆给Cache-Control: max-age=31536000, immutable。
• HTML文档：它是指纹资源的入口，如果缓存太久，新版本文件发布后浏览器仍然拿着旧的HTML去引用旧文件，页面就乱了。所以HTML一般用no-cache，确保每次访问都“问一下服务器”。
• 动态接口：按数据实时性要求来。实时行情类接口可以直接no-store；详情类接口可设置短max-age或者走ETag协商。

很多人缓存配置出问题，都是因为没理解“指纹资源”和“入口文档”之间的关系。牢记一条：文件名可变的内容，往死里缓存；文件名不变的内容，谨慎缓存。

6. 实战排查：从一个页面加载看HTTP全链路

6.1 用瀑布流找瓶颈

理论讲了一堆，最终都要落到“怎么用HTTP知识解决实际问题”。我习惯从一次页面加载的瀑布流开始看起。

浏览器开发者工具的“网络”面板，每个请求都有一个耗时条，拆开看一般包括：排队等待（Queueing/Stalled）、DNS解析（DNS Lookup）、TCP连接（Initial Connection）、TLS握手（SSL）、等待响应头（TTFB）、下载内容（Content Download）。

看懂这几个阶段，你就能定位大多数性能问题。TTFB过长，通常意味着服务器处理太慢或者网络链路有问题；DNS耗时异常，可能是DNS服务器配置不合理；SSL耗时过长，多半和证书链太长或TLS版本太旧有关；大量请求都卡在排队阶段，可能是浏览器对同一域名的连接数限制，这个时候就该考虑域名拆分或者上HTTP/2。

有一次我排查一个“接口偶尔慢”的问题，看瀑布流发现DNS解析时不时飙到几百毫秒，换了更近的DNS服务器后立刻缓解。这类问题不看瀑布流，纯靠猜，怎么猜都猜不到。

6.2 常见的性能优化操作

基于对HTTP的理解，常用的优化手段可以反复使用。第一个是压缩。文本类资源开启gzip或Brotli压缩后，体积通常能减少70%以上。响应头里带Content-Encoding: br或gzip，浏览器自动解压，用户无感。第二个是连接复用。HTTP/1.1默认支持Keep-Alive，但服务器端配置不当有可能会主动断开空闲连接，导致频繁重新握手。确认一下Web服务器和网关的超时配置，别让连接动不动就断开。第三个是减少重定向。每次302跳转都意味着多一次完整的HTTP往返，在一个资源真正加载出来之前，用户已经被重定向链拖延了好几百毫秒。第四个是CDN缓存。把静态资源分发到离用户近的节点，避免所有请求都回源站。

这些优化听着都不难，但每一项都需要你真正理解HTTP的往返成本才能落实到位。

6.3 Cookie、Session与跨域：身份与门槛

HTTP无状态，但业务需要有状态，身份认证就靠Cookie和Session这类机制补上。

服务器第一次识别用户时，生成一个会话ID，通过Set-Cookie响应头种到浏览器里。浏览器后续请求自动带上Cookie请求头，服务器看到会话ID就知道“这是之前登录过的那个用户”。Session数据存在服务器端，Cookie里只存会话ID。

Cookie有几个属性必须重视。HttpOnly让脚本读不到Cookie，能有效防XSS窃取；Secure只在HTTPS连接下才发送；SameSite可以限制跨站请求携带Cookie，是防CSRF的重要防线。我见过不少开发者在本地测试时为了省事把Cookie设置得非常宽松，一上线就被安全扫描抓个正着。

跨域则是另一个高频困惑点。浏览器的同源策略要求协议、域名、端口完全一致才能互相读取资源。你前端页面在example.com，接口在api.example.com，这就算跨域，浏览器会拦截非简单请求。跨域问题的解决思路很多，服务端设置Access-Control-Allow-Origin、开发环境用代理转发、或者干脆让接口和页面同域，关键是要理解浏览器为什么要设这个限制——它是在保护用户，防止恶意网站偷偷调用你的接口、读取你的数据。

6.4 Range断点续传：中断下载如何继续

还有一个很实用但很多文章不讲的知识点：Range请求。

下载一个文件，如果下到一半断了，是重新下载还是从中断的地方继续？HTTP从1.1开始就支持。客户端在请求头里带上：

Range: bytes=0-1023

服务器收到后，如果支持Range请求，就返回206 Partial Content，并在Content-Range里说明返回的是哪一段内容。下载工具就是靠这个机制实现断点续传的。视频播放器的拖动进度条、分片下载、大文件上传时的分片校验，原理都是它。

这里有个细节：服务器的响应如果是200而不是206，说明它不支持或者没启用Range，那你就必须整份下载。排查断点续传失效问题时，先看响应状态码，这是最直接的线索。

7. 高频问题速查与我的排障心得

7.1 高频问题速查表

这些年被问得最多的HTTP问题，我整理成一张表，直接对照着查就行。

这张表不能覆盖所有情况，但80%的线上HTTP问题都能在这些方向里找到答案。

7.2 排障的通用思路

遇到HTTP问题，我的排查顺序基本固定：先看状态码，确定大类；再看耗时分布，定位阶段；然后看缓存相关头，排除缓存干扰；最后抓原始报文确认细节。

比如一个接口偶发报错，状态码一会儿200一会儿500，我会先搜日志看500的具体堆栈；如果500集中在某个时间段，可能对应服务部署或流量高峰；如果请求头里有异常，可能需要看是不是网关加塞了某个特殊头。整个过程中，curl和抓包工具能帮你把“浏览器层屏蔽掉的细节”重新暴露出来。

有一个特别实用的命令，curl -w可以输出耗时统计：

curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" https://example.com/

输出示例：

dns:0.021 connect:0.045 tls:0.082 ttfb:0.132 total:0.148

我把这串命令存成了一个脚本，每次怀疑网络问题时，先对目标接口跑一遍，几秒钟就能分辨问题是DNS、TCP、TLS还是服务端响应慢。这个方法帮我省掉了大量盲猜的时间。

最后说一个我自己的习惯：不要等到出问题才打开开发者工具或者抓包。平时正常浏览网页、调用接口的时候，顺手把网络面板打开扫两眼，看看哪些请求走了缓存、哪些304、哪一项耗时异常。看得多了，你会对HTTP产生一种天然的直觉，线上出问题的时候往往一眼就能锁定嫌疑。这种手感是看任何教程都学不来的，但它恰恰是HTTP这个看起来“很简单”的协议，真正拉开工程师水平差距的地方。