提到HTTP持续连接和非持续连接很多人的第一反应是背定义HTTP/1.0默认非持续HTTP/1.1默认持续。但真要问起来持续连接到底省了什么、非持续连接慢在哪一步、计算题里的RTT是怎么累加的答得清楚的人其实不多。之前我有一次面试被问到“Keep-Alive头在HTTP/1.1里还有没有保留意义”当场被绕晕。后来把整个连接管理机制从原理到抓包重新过了一遍才发现这两者的差别本质上就是“打完一个电话要不要立刻挂断”的差别。如果你在复习计算机网络准备考试或者正在排查线上接口缓慢的报障只要需要跟HTTP打交道这篇文章都值得看完。它不只会讲定义还会把非持续连接的完整生命周期、持续连接省下的三笔成本、教科书RTT公式的来龙去脉以及真实抓包验证的方法一次性讲透。1. 先分清楚这不是“粘不粘”的问题而是“打完电话挂不挂”的问题很多人第一次接触这两个概念时会下意识往“TCP长连接”“WebSocket”“会话保活”这些方向联想结果越扯越乱。其实持续连接和非持续连接描述的非常简单HTTP请求/响应对是否复用同一条TCP连接。想通这一点后面所有公式和排查思路都顺了。1.1 非持续连接每个资源都是一次完整的“从陌生到分手”非持续连接的含义是每次HTTP请求都建立一条全新的TCP连接服务器返回完响应就关闭连接下一个资源另起炉灶。假设用户访问一个页面页面里除了HTML还有8张图片、3个CSS文件、2个JS文件。在非持续连接模式下浏览器需要请求这些资源那就意味着要建立14条甚至更多独立的TCP连接。每一条连接都要走一遍三次握手、传输数据、四次挥手。打个电话的比方非持续连接就像你每次找客服办一件事都要重新拨号、等待接通、说完就挂办理下一件事时再重新拨号。如果一次要办五六件事光拨号浪费的时间就够喝一壶了。在真实网络环境中非持续连接很少被现代浏览器主动使用但理解它是理解持续连接的钥匙。1.2 持续连接把多条请求放进同一条TCP管道持续连接的含义正好相反TCP连接建立后服务器不主动关闭多个HTTP请求和响应在这条连接上依次传输直到客户端或服务器明确要求断开或者连接空闲超时。继续用打电话的比方这次你拨通客服电话后在同一通电话里把所有业务一次性办完不会每办一件事就挂断重拨。HTTP/1.1默认采用这种模式所以打开一个包含几十个资源的现代网页可能只需要一到几条TCP连接就能完成大部分资源加载。很多人容易把“持续连接”和“状态保持”混在一起。HTTP协议本身是无状态的哪怕连接一直被复用服务器也不会因此记住你是谁、你上次做了什么。连接是否持续属于传输层面的连接管理策略有无状态属于请求/响应语义层面的设计。两者互不干扰也完全不冲突。1.3 几个高频误解先在这里拆掉常见说法正解“持续连接就是TCP长连接”本质确实基于TCP连接复用但HTTP层有自己闲置超时控制和操作系统TCP长连接并不是一回事“Keep-Alive就是持续连接”Keep-Alive只是HTTP头/机制的名字持续连接是一个更上层的连接策略两者有关联但不是同义词“持续连接会让服务器保存我的登录状态”不会无状态性是HTTP协议的设计原则连接复用不会自动带来会话状态“HTTP/1.0完全不能用持续连接”不对HTTP/1.0可以用Connection: keep-alive协商开启建议学习这一块时先把“连接复用”和“状态管理”两条线彻底分开否则后面看RTT计算、看队头阻塞思路很容易乱。2. 非持续连接的完整生命周期一笔笔算清开销只记住“非持续连接慢”是不够的要能说清它到底慢在哪几步。下面把一次完整请求拆开你就能看到非持续连接的成本结构。2.1 一个对象的完整旅程假定浏览器请求http://某站点/a.jpg这张图片采用非持续连接。它的完整时间线是这样的DNS解析如果有缓存可省略否则先花掉一段DNS查询时间。三次握手建立TCP连接客户端发SYN服务器回SYN-ACK客户端回ACK。客户端通过这条连接发送GET /a.jpg请求。服务器处理请求把响应返回给客户端。响应传输结束后连接被关闭HTTP/1.0里服务器响应完基本就主动关。客户端进入TIME_WAIT或直接释放资源四元组暂时被占用。注意第2到第5步就是“建立连接 一次请求响应”的全部流程。非持续连接模式下页面里每个资源都要完整走一遍这个流程。首页HTML走一遍CSS走一遍每张图片各走一遍每段JS各走一遍。资源一多重复开销就被放得很大。2.2 开销不只多一次握手慢启动和TIME_WAIT才是隐藏成本三次握手是大家最容易想到的账但实际代价远不止多花一两个RTT。还有两个经常被忽略的隐性成本。第一个是TCP慢启动。新建的TCP连接拥塞窗口很小Linux默认initcwnd一般是10个MSS大约14KB。也就是说连接刚建立时发送方一次最多只能发14KB左右数据等收到确认后窗口才会翻倍。如果传输的是一个几十KB的图片往往刚开始提速连接就传完了根本没有跑到带宽上限。非持续连接等于让每个小对象都重新经历一次“从低速热身到提速”的过程性能损失非常实在。第二个是TIME_WAIT端口占用。主动关闭连接的一方需要进入TIME_WAIT状态并等待2个MSL通常约1到4分钟。在这段时间里这个连接的四元组不能立即被新连接复用。如果客户端以短连接高频率发起请求本地端口号会被TIME_WAIT连接占满很快就出现Cannot assign requested address之类的报错。这在后面第5章会展开细说。第三个是系统调度开销。每一条TCP连接都对应内核里的socket、TCP控制块以及用户态的事件回调、缓冲区。连接数量一多CPU中断、上下文切换、内存占用都会上涨。一个页面几十个资源非持续连接就要创建、销毁几十个连接对高并发服务端压力很大。2.3 验证非持续连接抓包看看“一地鸡毛”讲理论不如动手验证。用curl强制走HTTP/1.0再去抓包看连接行为sudo tcpdump -i 你的网卡名 -n tcp port 80 -q curl --http1.0 http://127.0.0.1/a.jpg curl --http1.0 http://127.0.0.1/b.jpg观察抓包结果你会看到非常清晰的规律第一个连接的流SYN → SYN-ACK → ACK → GET → 响应 → FIN第二个连接又是一轮独立的SYN → SYN-ACK → ACK → GET → 响应 → FIN每个HTTP资源对应一条独立TCP连接每条连接都有完整的三次握手和断开过程。如果再用wireshark按tcp.stream分组看会发现每个stream里只有一条HTTP事务。这就是非持续连接的直观形态。3. 持续连接到底省了什么三笔账一次算清理解了非持续连接的开销持续连接的价值就很好计算了。它省下的不只是“几次握手”而是三笔相互叠加的成本。3.1 第一笔三次握手的RTT重复支出一次TCP三次握手理想情况下也要花费至少1到2个RTT。在非持续连接里页面有几个资源这笔连接建立成本就要重复几次。而在持续连接模式下只有第一条连接的握手成本是必需品后续所有对象都在这条已经建立的连接上传输。举例假设RTT是100ms页面有10个对象。非持续连接仅在连接建立上就可能花掉10 × 2 × 100 2000ms。持续连接方案里这笔钱只花一次后面9个对象直接复用等于省下了1800ms。3.2 第二笔TCP慢启动的重复热身这一笔是最容易被忽略、但实际影响最大的。持续连接的价值不只是“少握手”更在于拥塞窗口已经提前打开。第一条连接传输HTML、CSS等资源时TCP窗口已经通过慢启动翻了几倍。后续图片、JS在同一条连接上传输时发送窗口已经接近带宽延迟积不再有“从14KB开始爬坡”的过程。打个比方非持续连接像每次跑短跑都从起跑线重新加速持续连接则是你已经跑在高速上后面每个资源只是继续提速。对于几十KB的小对象慢启动阶段可能占整个传输时间的一半以上所以省掉重复热身收益非常明显。3.3 第三笔连接生命周期带来的资源释放非持续连接下每条连接都要经历创建、传输、关闭、TIME_WAIT这四个阶段。持续连接把这些阶段合并成“创建一次、复用N次、超时后再关闭”直接减少了socket的创建销毁次数、TIME_WAIT连接数量、内核协议栈处理压力。代价是空闲连接会占用文件描述符和内存所以服务端必须配置合理的空闲超时否则连接池会被大量僵尸连接占满。持续连接不是“越多越持久越好”而是要控制在一个合理的生命周期里。3.4 HTTP/1.0与HTTP/1.1的开关逻辑以及管线化的真实处境连接策略在协议版本里的表现也不一样协议版本默认连接策略开启/关闭方式HTTP/1.0非持续请求和响应都带Connection: keep-alive才持续否则响应完关闭HTTP/1.1持续请求不带Connection: close就默认持续带Connection: close则响应后关闭HTTP/2、HTTP/3持续 多路复用单条连接并行传输多个流基本不会再逐请求建连HTTP/1.1里其实不需要显式写Connection: keep-alive因为持续连接是默认行为这个头更多是为了兼容HTTP/1.0时代的中间设备。真正表示关闭意图的是Connection: close。这里还需要顺带说清管线化PipeliningHTTP/1.1允许客户端在一条持续连接上连续发出多个请求不必等前一个响应回来再发下一个听起来很美好。但实现上有个硬约束服务器响应必须按请求顺序返回。如果第一个请求处理得很慢后面所有响应都要排队等它这个现象就是队头阻塞。再加上中间代理兼容性问题管线化在实际系统中几乎被主流浏览器放弃等到HTTP/2才用真正的多路复用解决了这个局面。提示面试里经常有人把“管线化”和“多路复用”混为一谈。管线化只是“连续发请求”响应仍然按序排队多路复用才是“多条请求流并行推进互不阻塞”。4. 响应时间计算题把教科书公式掰开揉碎很多人在这一步就卡住了因为没有理解三种模型到底在算什么。先约定一组符号后面所有公式都用这套符号避免记混。RTT一个短分组从客户端到服务器再返回客户端的时间。M页面资源总数基础HTML也算一个对象再加上N个引用的图片、CSS、JS所以M N 1。C建立一条TCP连接需要多少个RTT。这是最关键的变量不同教材取值可能不同后面单独说。4.1 三种模型的时间线对照非持续连接串行第1个对象建立连接C 请求/响应1 C1RTT第2个对象再建立连接C 请求/响应1 C1RTT全部对象M × (C1)RTT持续连接非管线化建第一条连接只花一次C每个对象各自完整走一次“请求-响应”各花1RTT全部对象C MRTT持续连接管线化理想情况建一次连接C所有请求可以连续发出服务器连续返回近似为一个RTT窗口内完成全部对象C 1RTT放一张表更直观连接模式总耗时RTT以C2、M11为例非持续串行M × (C1)11 × 3 33 RTT持续非管线化C M2 11 13 RTT持续管线化C 12 1 3 RTT4.2 用具体数字感受差距假设RTT100ms页面有1个HTML和10个图片即M11取C2非持续串行33 × 100 3300ms超过3秒。持续非管线化13 × 100 1300ms大约1.3秒。持续管线化3 × 100 300ms0.3秒。这个差距就是为什么现代网页几乎不可能用非持续连接加载。页面资源越多RTT越大差距越夸张。注意上面的计算默认“传输时延可忽略”也就是对象足够小、带宽足够大一个对象在约一个RTT内就能传完。如果题目明确给了对象大小与带宽还需要在每项基础上叠加对象大小/瓶颈带宽的传输时延不能只算RTT。4.3 三次握手到底算几个RTT必须先看题目假设这是做题最容易翻车的地方。三次握手的严格过程是客户端发SYN收到SYN-ACK约1个RTT。客户端再回ACK这个ACK到达服务器大约要0.5个RTT。如果ACK同时捎带HTTP请求那HTTP请求也在1.5个RTT时到达服务器。服务器返回响应客户端大约在2个RTT时收到首个数据字节。所以从客户端视角第一条HTTP响应确实可以在接近2RTT内收到。但是教材为了简化通常把“建立连接一次请求响应”拆成两个阶段建立连接按2 RTT算请求/响应再按1 RTT算于是每个对象一共3 RTT。也有教材只把握手按1 RTT算那样每个对象就是2 RTT。两种简化各有道理做题时一定要先看题目有没有给出“TCP连接建立需要X个RTT”的假设。如果题目没有明说优先按国内教材最主流的默认方式非持续连接下每个对象3 RTT持续连接非管线化按2 MRTT。但别把3RTT当成铁律一切以题干口径为准。5. 理论之外的真实网络并发数、超时与队头阻塞教科书里的持续连接模型是“一条连接传完所有对象”但真实浏览器从来不会只开一条连接。现实要比模型复杂得多也正是这些复杂性构成了日常排查问题的主要战场。5.1 浏览器为什么同时开多条连接HTTP/1.1虽然默认持续但非管线化模式下一条TCP连接同一时刻只能有一个请求在途。假如页面有50个资源全挤在一条连接上串行传输总时间就是所有“请求-响应”RTT的累加效率依然低。所以主流浏览器的做法是为同一个站点建立多条持续连接形成一个连接池常用的并发上限大约是6条。这6条连接并行加载不同资源能把一个页面的加载时间大幅压缩。这个数量是个妥协太少了并行度不够太多了会加大服务器压力、更容易触发网络拥塞。HTTP/1.1规范最早甚至建议“每个主机最多2条连接”但因为不切实际后续被主流浏览器各自放宽。理解了这一点你就明白为什么服务器上会看到大量ESTABLISHED状态连接那不是异常而是浏览器连接池的正常表现。5.2 Keep-Alive超时参数到底调多长才合适连接既要复用又不能无限占着不放所以必须有超时回收机制。服务端常见的调优维度有三个空闲超时一条连接空闲多久后被关闭。太短会导致频繁握手太长会积累大量无用连接。最大请求数一条连接最多服务多少次请求后主动关闭避免个别连接被长时间占用。上游连接池反向代理与后端服务之间的连接复用数量。以常见的Nginx为例涉及的核心配置项包括keepalive_timeout、keepalive_requests和上游的keepalive。Apache则对应KeepAlive On、MaxKeepAliveRequests、KeepAliveTimeout。前端场景下超时设置在30秒到75秒是比较常见的范围高并发后端会配合比较大的keepalive_requests比如几千上万让单条连接承载更多请求后再关闭。注意HTTP层的Keep-Alive超时和TCP层的SO_KEEPALIVE不是一回事。SO_KEEPALIVE是每隔一段时间发探测包确认对端是否存活与HTTP连接是否空闲复用没有直接关系。排查连接问题时别把这两个机制混在一起看。5.3 队头阻塞管线化为什么没能解决一切第3章提到管线化要按序响应这里再往深挖一层。即便客户端连续发出了3个请求A、B、C服务器也必须按A→B→C的顺序返回响应。如果A因为数据库查询慢、上游接口慢而卡住B和C就算早就处理完了也得堵在缓冲区里等着。这种应用层的队头阻塞是HTTP/1.1最明显的痛点。管线化理论上能缓解但它把“响应是否被阻塞”押在了服务器的处理顺序上实际部署时又面临中间代理兼容性的问题所以最终没有被普及。HTTP/2使用单条TCP连接上的多流并发让不同请求的响应可以交错传输解决了应用层队头阻塞但TCP丢包时底层的队列仍然可能阻塞所有流于是HTTP/3改用基于UDP的QUIC进一步弱化传输层队头阻塞。这一段演进脉络建议和连接模型一起记考试和面试都爱考。5.4 现实故障短连接风暴与TIME_WAIT端口耗尽线上最经典的连接相关故障就是非持续连接大量出现时的“本地端口枯竭”。先看背景主动关闭连接的一方会进入TIME_WAIT并且要等2MSL才能复用四元组。如果一个客户端以短连接高频访问服务端每个请求都新建连接、请求完断开那么本地就会积压大量TIME_WAIT连接。端口号是有限的默认可能只有几万个一旦全部被TIME_WAIT占用新连接就没法建立业务层出现Cannot assign requested address或“连接建立失败”的报错。这类问题的排查思路一般是执行netstat -tan或ss -tan统计TIME_WAIT数量。如果数量持续处于高位基本可以确认是短连接过多。找出客户端代码里是否每次都创建新连接优先改成连接复用。如果短期内无法改架构可以临时调整内核参数缓解例如sudo sysctl -w net.ipv4.tcp_tw_reuse1 sudo sysctl -w net.ipv4.ip_local_port_range10000 65535这些参数能扩大可用端口范围并允许复用处于TIME_WAIT的连接但治本方案仍然是“减少不必要的连接创建”。这个故障本身就是持续连接价值的现实注脚理论算的是RTT账实际里还要加上端口、内存、系统调度这些资源账。6. 从面试题到抓包常见考法与自测方法最后说点实用的。这块内容既可以直接用来应付考试和面试也可以当作平时自测理解程度的练习。6.1 时间计算题的几种变形套路除了基础三模型题目还喜欢加各种前置条件核心判断点如下变形方向计算要点带DNS时延先加DNS查询时间再按连接模型计算后续耗时允许并行连接非持续连接下可用P条并行连接总耗时近似为ceil(M/P) × (C1)RTT但还需考虑分配批次传输时延不可忽略每个对象要叠加对象大小/带宽多个对象在同一条持续连接上传输时还要合计总字节除以带宽管线化传输时延先算建连C再把所有对象字节总量除以带宽作为传输时间最后按管线化近似为C 1RTT做题时建议先把题干里“RTT”“带宽”“对象大小”“是否忽略DNS”“是否允许并行”这些关键条件圈出来再决定用哪个公式不要上来就套。6.2 判断题与概念题常见的坑题目说法正确与否HTTP是无状态协议所以不能用持续连接错。无状态是语义层设计连接复用是传输层表现两者互不冲突HTTP/1.0完全不能用持续连接错。可以用Connection: keep-alive协商开启HTTP/1.1中Connection: keep-alive表示开启长连接不准确。HTTP/1.1默认就是持续的这个头更多用于兼容HTTP/1.0管线化可以并发处理多个请求不完全对。它能连续发请求但服务器响应仍要按序返回持续连接在任何情况下都优于非持续连接大多数情况是但空闲连接会占资源超时配置不合理时也可能引入新问题6.3 自测实验用curl和抓包验证你的连接模型理解动手验证一遍比背十遍公式都管用。先看HTTP/1.0的非持续行为curl -v --http1.0 http://127.0.0.1/test.jpg观察输出里的Connection: close和末尾的“Closing connection”。它在提示你HTTP/1.0语义下响应完就断开。再看HTTP/1.1的持续行为curl -v --http1.1 http://127.0.0.1/test.jpg curl -v --http1.1 http://127.0.0.1/style.css注意第二段请求的输出如果出现类似“Re-using existing connection”的提示说明连接被复用了这正是持续连接在客户端侧的直观表现。再进一步抓包sudo tcpdump -i 你的网卡名 -n -q tcp port 80 or tcp port 443连续发起多次HTTP/1.1请求后统计同一个TCP stream里是否包含多条HTTP事务同时留意SYN和FIN的数量。如果只有最开始一次SYN、最后才出现FIN中间全是数据交互那就说明连接确实在持续复用。最后说一下我的工作习惯遇到任何和连接相关的线上问题第一反应不是去看代码而是先抓包数一下同一个连接上有几个HTTP请求、几个SYN和FIN。原因很简单连接模型是HTTP性能的基础许多“服务器慢”的报障查到最后都会落在“连接被频繁重建”这个根上。希望这篇能把持续连接和非持续连接的账算清楚让你下次排查时也能少走弯路。