★ FEATURED ARTICLE 引子一次普通的网页访问TCP在背后做了什么打开浏览器输入一个网址按下回车。地址栏上的图标转了两圈页面内容就铺满了屏幕。整个过程可能不到一秒看起来顺理成章。但在这背后浏览器和服务器之间其实进行了一场极其严谨的“货物交接”——你要请求的HTML、CSS、JavaScript文件被拆成了成千上万个小数据包经过一条条网络链路最终一个不少、顺序不乱地送到你的电脑上。而负责这场交接的就是TCP协议。它不关心你的文件内容是什么只关心一件事数据能否完整、有序、无损地抵达目的地。今天的这一篇“浏览器原理”系列我想认真聊聊TCP协议。不聊那些教科书里枯燥的“报文格式”和“状态转移图”而是从浏览器加载页面的真实场景出发把TCP的可靠传输、三次握手、流量控制、拥塞控制这些核心机制逐一拆开来看。你不需要是网络工程师也能搞清楚一个问题为什么浏览器能放心地把页面完整性交给TCP而TCP又是凭什么拍这个胸脯的。这篇文章适合所有写前端、做后端、搞运维或者单纯想弄明白“网页到底怎么加载出来的”的人。看完之后你会发现很多前端性能优化的手段——比如减少请求数、分域名、CDN加速——背后都源自TCP协议的脾气和性格。理解了TCP你就理解了浏览器很多行为的底层逻辑。1. 先把TCP放回浏览器的完整工作流里看1.1 从URL到屏幕链路中的TCP位置给一个页面从无到有的过程画一条线大概是这样浏览器解析URL提取协议、域名、端口。DNS解析域名拿到服务器IP地址。浏览器与服务器建立连接——这一步就是TCP干的活。浏览器发出HTTP请求报文。服务器处理请求返回HTTP响应报文。浏览器接收数据解析、渲染、呈现页面。在这个链条里TCP位于“连接建立”和“数据运输”这两个环节。HTTP协议本身是“无状态、无连接”的它只管规定请求和响应的格式至于数据怎么可靠地跑过去就甩给了TCP。简单打个比方HTTP是快递面单上的收件人信息和货物明细TCP则是那辆货车以及背后的物流调度系统。面单写错了货物肯定送不对但面单写对了货车路上抛锚、货物破损、掉沟里了这锅得物流系统背。TCP就是那个用各种手段确保货物安全到达的物流调度系统。1.2 TCP为什么重要浏览器性能的隐形天花板很多人做前端优化把精力花在了压缩图片、合并CSS、减少DOM节点上却忽略了一个底层事实TCP的传输效率直接影响页面加载速度。一个页面的HTML如果有100KB在网络传输时会被切割成几十个甚至上百个TCP数据段。每个数据段的传输都涉及发送等待、确认返回、滑动窗口调整等机制。如果TCP协商不顺畅哪怕带宽再大页面也加载不快。更现实的问题是HTTP/1.1时代浏览器对同一个域名最多只建立6个左右的TCP连接而HTTP/2虽然把多个请求复用在一条TCP连接上却又引出了“队头阻塞”的问题——一条TCP连接上的一个丢包会让后续所有数据都在排队等待。这些细节都说明了TCP对页面加载体验的影响力绝对不是一个“底层透明协议”就能打发的。1.3 TCP协议的两个关键词可靠、有序TCP全称是Transmission Control Protocol传输控制协议。拆开来看两个词传输是它的职责控制是它的手段。所谓“传输”指的是它工作在传输层在IP层之上、应用层之下负责端到端的数据搬运。所谓“控制”指的是它不满足于“把数据扔出去就行”而是要控制数据是否送达、是否有序、是否无损、是否不会让网络或接收方过载。用一句话概括TCP的核心目标在不可靠的IP网络之上实现一份可靠的数据传输服务。IP协议只管“尽力而为”数据包丢了、乱了、重了它都不管而TCP要在这个“不靠谱”的网络地基上盖出“靠谱”的传输大厦。页面文件能不能完整送达浏览器本质上就是TCP这套可靠传输机制交出的答卷。2. 核心细节解析TCP可靠性的秘密武器2.1 分块与编号把大文件切成可管理的“包裹”假设你请求一个2MB的JavaScript文件。网络层IP层能承载的数据包大小是有限的——以太网链路通常MTU最大传输单元是1500字节其中IP头和TCP头还要占掉一部分所以每个TCP数据段最多能携带约1460字节的“有用负载”。2MB的文件除以1460字节约等于1434个数据段。TCP要做的事情就是把应用层丢给它的一大块数据按MSSMaximum Segment Size最大分段大小切成一个个小块然后给每一块编上序号——这就是“序列号”。序列号的作用非常关键接收方收到数据后不是按照到达顺序拼装的而是按照序列号排列。就算第3个数据包比第2个先到接收方也能根据序号把它放到正确的位置。这直接解决了网络传输中一个常见问题——乱序。2.2 三次握手建立连接时的“通话测试”要保证可靠传输第一步是确保收发双方都处于“在线且愿意通信”的状态。TCP用三次握手来完成这个确认。解释之前先看一个生活场景你给朋友打电话说“喂能听到吗”SYN朋友说“能听到你那边我能听到吗”SYNACK你说“能听到”ACK。三次对话之后双方才确认通路没问题开始正式“聊业务”——传输数据。TCP三次握手具体是这样的客户端发送SYN报文初始序列号为x进入SYN_SENT状态。服务端收到后回SYNACK报文自己的初始序列号为y同时确认号是x1进入SYN_RCVD状态。客户端收到后再发ACK报文确认号是y1。握手完成双方进入ESTABLISHED状态。为什么非得三次而不是两次核心原因是防止“过期连接”干扰通信。假设只有两次握手客户端发的SYN因为网络拥堵延迟了很久客户端等不及重发了一个服务器收到了重发的SYN并建立了连接此时旧的SYN又到了服务器服务器可能会误认为是新的连接请求白白建立一条“幽灵连接”消耗资源。三次握手可以通过第三次ACK的时机制衡这种历史重复连接。这里有个细节值得注意三次握手携带的第一个数据段往往也被称为“TCP Fast Open”的载体——握手阶段的SYN包如果带了TFO cookie可以在建立连接的同时捎带应用层数据省心省时。不过这是进阶话题大多数普通请求不会用到。2.3 确认与重传发出去没有回应就自觉重来三次握手只是打好地基。真正的考验在于数据传输阶段。TCP采用“累计确认”机制接收方每收到一个数据段就回一个ACK确认号表示“这个序号之前的数据我都收到无误”。发送方收到确认号后才确定这部分数据可以“翻篇”。问题来了如果数据包在传输途中丢了或者ACK在回来的路上丢了发送方怎么知道答案是超时重传基于时间和快速重传基于重复ACK。超时重传发送方发出数据后启动一个定时器如果超过RTO重传超时时间还没有收到ACK就认为数据丢了重新发送。快速重传发送方如果连续收到3个相同的ACK比如连续收到“确认4号”说明4号之后的数据有问题不等定时器超时立即重传。这里有一个容易踩坑的认知不少人以为TCP每发一个包就要等一个ACK回来才能再发下一个那是大错特错。那样效率太低——去一次要等一个来回带宽全浪费在等待上。2.4 滑动窗口与流量控制收发双方节奏匹配TCP真正提高效率的关键在于“滑动窗口”。发送方有一个发送窗口窗口大小表示“我可以在没收到ACK的情况下连续发送多少数据”。接收方有个接收缓冲区报文到达后先缓存供应用层读取。接收方会在每次ACK里带上自己当前“还能接收多少数据”的窗口大小窗口通告发送方据此调整自己的发送速度。打个比方物流公司的仓库能存1000件货运输车队一次最多能发500件。仓库说“我目前还能接800件”车队就发800件仓库说“我已经堆满了”车队就停下等。这套机制叫流量控制目的是防止发送方过快把接收方的缓冲区塞爆。如果无视接收方的承受能力数据发得再多接收方也来不及处理必然导致丢包、重传传输质量反而下降。2.5 拥塞控制别把网络“堵死”流量控制是接收方的缓冲区说了算拥塞控制则是“网络路径说了算”。两者看着像其实管的事不一样。流量控制管的是“你发太快我吃不消”拥塞控制管的是“你发太多中间的路由器扛不住了”。路由器也有缓冲区数据量大到路由器处理不过来时缓冲区填满新来的数据包只能被丢弃——这就是拥塞丢包。一旦发生拥塞网络里大量丢包、大量重传延迟急剧上升吞吐量反而掉下来造成“拥塞崩溃”。TCP的拥塞控制策略有两个经典的阶段慢启动Slow Start连接刚建立时发送方并不知道网络能承受多大的流量所以先用一个很小的拥塞窗口cwnd探路每收到一个ACK窗口就翻倍增长。这是指数增长增长速度快但只维持在一个阈值之内。拥塞避免Congestion Avoidance当cwnd增长到慢启动阈值ssthresh之后进入线性增长阶段每个RTT只增加一个MSS缓慢试探网络的极限。一旦发生超时重传大幅降低cwnd和ssthresh然后重新开始。这套机制的本质是TCP不是一股脑地把数据全扔进网络而是在不断试探网络的承载上限找到那个“接近满载但没撑爆”的最优速率。而这恰恰解释了为什么一个页面里的第5个、第6个资源文件的加载速度往往比前几个慢——如果它们共用一条新建立的TCP连接那这条连接要从慢启动重新爬升发送窗口前期的传输效率自然偏低。这也是前端优化里“复用连接”被反复强调的原因之一。3. 从页面加载场景看TCP的流量控制与拥塞控制3.1 页面加载中的“慢启动”体验想象你打开一个相当“豪华”的首页一个HTML里面引用着10个CSS、20个JS、30张图片总共60个请求。如果协议是HTTP/1.1浏览器对同一域名一般开6条TCP连接每条连接从0开始慢启动。慢启动意味着什么每条连接刚开始时发送窗口只有10个左右的MSS不同操作系统内核版本不一样大约不到15KB数据。也就是说第一轮只能发送十几个数据段发完就要等服务端的ACK回来窗口翻倍后才能多发一点。而往返时延RTT在50毫秒~200毫秒之间这意味着连接建立的初期传输速率是很慢的。你可以把慢启动理解为一辆刚起步的汽车需要在地面上一点一点加速虽然加速度越来越快但起步阶段终究没有跑起来之后那么猛。一个大型页面文件如果连接没有复用每次都要经历这个“起步-加速”的过程页面加载时间自然被拉长。这就产生了一个相当常见的优化思路资源打包、合并请求、尽量把一个域名下的资源数量减少本质上是减少连接的启动“预热”次数。3.2 窗口完全打开后的带宽利用经过几轮RTT窗口逐渐变大最终能够撑满整条链路带宽。这个过程大概需要多少次RTT呢假设初始窗口是10个MSS每轮RTT翻倍达到拥塞避免阈值假设为64KB大约需要3~4个RTT从64KB线性增长到几MB级别的窗口则需要更多RTT。对于C端的移动端页面RTT如果是100毫秒很可能你还没来得及把窗口跑大页面资源的传输就已经结束了。典型的现象是大文件下载时比较快小文件好多时间卡在“往返延迟”上。下一次你分析页面加载瀑布图时如果发现一个文件本身的下载时间很短但总延迟长就可以去怀疑是不是TCP连接建立和慢启动拖了后腿。3.3 流量控制的现实影响别让你的服务器内存被“撑爆”流量控制对接收方的保护表现在实际开发中最典型的案例就是服务器端向客户端推送大量数据时如果客户端处理得很慢比如解析一个超大的JSON主线程卡住了应用层读取数据的速度下降接收缓冲区就会逐渐填满。接收方在ACK里通告的“窗口大小”会越来越小。发送方的TCP模块一旦发现窗口趋近于零会停止发送新的数据等待接收方发出“窗口更新”的通知。这个机制存在一个小坑更新通知如果丢了双方可能陷入死等——发送方等着窗口更新接收方以为发送方没数据要发了。TCP提供了一种“持续计时器”来解决这个问题发送方会定期发送探测报文询问“你现在能收了吗”。这个机制在开发中带来的启示是某些异常卡顿不一定是带宽问题而是应用层消费数据的速度拖了后腿。比如某个接口返回的数据特别大客户端解析程序写得烂TCP流量控制就会限制服务端的推送速度表现为“下载慢”。真实情况是瓶颈在客户端自身的处理能力上。3.4 拥塞控制与CDN为什么多地点部署能加速再聊一个服务和拥塞控制相关的经典操作CDN内容分发网络。为什么CDN能加速常规解释是“就近访问距离短RTT小”。但结合拥塞控制还有一个更微妙的点因为网络路径上的拥塞窗口调节是围绕RTT来做的——RTT越小窗口增长越快越容易在单位时间内发送更多数据。假设源站服务器距离你2000公里RTT约80毫秒CDN边缘节点距离你500公里RTT约20毫秒。在相同网速、相同路由条件下CDN的连接能从最初的几十KB在几个RTT内迅速冲刺到几MB级别的窗口而源站因为RTT更长每个往返周期内窗口增长得慢最终吞吐量会有明显差距。这不是玄学这是能从拥塞控制算法推导出来的结论。下次有人跟你说“CDN是因为距离近才快”你可以补充一句“还有一个原因是TCP的拥塞控制窗口增长也依赖RTT。”4. 实操验证亲眼看看TCP协议的行为4.1 用开发者工具观察TCP和HTTP的关系浏览器开发者工具DevTools的Network面板里每个请求都有一列“Timing”点开可以看到详细的连接阶段Queueing等待空闲连接的时间。Stalled发出请求前的停滞时间。DNS LookupDNS解析时间。Initial connectionTCP三次握手的时间。SSL/TLS加密握手时间HTTPS。Request sent发送请求报文的时间。Waiting (TTFB)等待服务端响应头部的时间。你可以看到“Initial connection”这个阶段它反映的就是TCP三次握手耗时。如果页面里大量请求都显示Initial connection比较大说明浏览器在频繁建立新连接没有有效复用连接。再配合“Connection ID”列看看同一个TCP连接上承载了哪些请求你就能直观理解连接复用的真实情况。实操建议选一个图片较多的页面看Network面板里有多少个“Initial connection”大于20ms的请求。如果有很多且不是跨域资源那这个页面的连接利用率就有优化空间。4.2 用命令行观察TCP握手的真实时延在终端执行curl命令可以单独测一下TCP握手和TLS握手的耗时curl -o /dev/null -s -w TCP握手时间: %{time_connect} s\nTLS握手时间: %{time_appconnect} s\n总请求时间: %{time_total} s\n https://example.com几个参数解释time_connect从请求开始到TCP三次握手完成的时间。time_appconnect从请求开始到TLS握手完成的时间。time_total整个请求的总耗时。两者求差就是TLS握手本身花掉的时间time_connect再减去DNS解析耗时才是纯粹的TCP握手成本。拿这个数字估算一下RTT再比对地理距离很有意思。4.3 用抓包工具看SYN、ACK、窗口通告Wireshark这类抓包工具能看到最底层的TCP报文。抓包时需要注意Wireshark默认可能抓到的是SSL/TLS加密后的数据如果是HTTPS但仍然能清楚看到握手和传输行为第三、四次TCP报文分别是SYN、SYNACK、ACK对应三次握手。传输阶段的报文里Length列显示的是TCP段携带的实际负载大小。ACK报文里的“Window”字段就是接收方通告的窗口大小。排序时如果看到乱序的TCP序号“TCP out-of-order”就说明网络路径上发生了乱序。一个常见困惑是为什么Wireshark里很多报文显示“TCP Dup ACK”这往往是因为网络出现轻微乱序或丢包发送方触发了快速重传机制。如果一个页面的加载过程中有大量Dup ACK说明网络链路质量堪忧。4.4 模拟慢启动的实验思路如果你想真实验证慢启动对加载时间的影响可以做一个简单的实验准备一个10MB的文件放在本地局域网服务器上。用浏览器或者curl去下载观察前面的1~2秒下载速度。修改服务器的TCP初始窗口大小Linux下可通过ip route命令调整initcwnd再次下载对比前几秒的速度。在我的实际测试中把初始拥塞窗口从10提升到32后同一个小文件的下载完成时间大约缩减了20%左右。当然这只是一个参考值具体提升效果取决于RTT和文件大小——RTT越大初始窗口提升的收益越明显。这里要提醒一句修改系统级TCP参数需要谨慎生产环境不要乱改实验环境随便折腾。5. 常见问题与排查技巧速查5.1 问题一页面加载出现“连接超时”或“一直转圈”排查思路先确认是TCP层的问题还是应用层的问题。用curl测一下目标地址观察是否能在合理时间内完成TCP连接。如果curl显示“Connection timed out”多半是防火墙拦截了端口或者服务端没有监听该端口。如果TCP能连接但HTTP请求迟迟没有响应那问题可能出在服务端应用进程上。工具命令参考# 检查TCP连接是否正常 curl -v telnet://目标地址:80 # 查看当前服务器的TCP连接状态 ss -ant | grep 目标端口5.2 问题二下载速度上不去但带宽明明是够的排除顺序先用HTTP下载一个本机服务端的大文件排除服务端到达用户的链路带宽限制。看是不是接收窗口被卡住了——在Wireshark里如果发现Window字段很小说明接收方缓冲区不足。看看是不是网络往返时延太大同时拥塞窗口还没跑大。这种情况最典型出现在跨境访问或者远端服务器场景。这里有一个坑要提醒很多云服务器默认开启了TCP BBR算法一种拥塞控制算法行为与传统“慢启动拥塞避免”不太一样。如果你的服务器启用了BBR看到的窗口增长曲线会激进很多。排查问题的时候先确认当前用的是哪个拥塞控制算法sysctl net.ipv4.tcp_congestion_control5.3 问题三同一个页面里的资源出现明显的“先后到达”差异观察瀑布图通常排在前面的资源下载很快排在后面的资源虽然文件更小下载时间反而更长。原因大概率是连接数打满了后续请求在排队等待空闲连接。HTTP/1.1的浏览器对同域名的连接数限制意味着第7个、第13个请求都要排队。解决方法开启HTTP/2它允许多路复用多个请求共用一条TCP连接省去多条连接各自的慢启动过程。如果还在用HTTP/1.1做域名分片把资源分布到不同的子域名上让浏览器允许开更多连接。把很小的资源内联进HTML/CSS减少请求数量。5.4 问题四HTTPS页面偶发卡顿TTFB时间波动大TCP层的“队头阻塞”在HTTP/2中是一个老大难问题。因为HTTP/2的多路复用是基于单条TCP连接的如果一个底层数据段在网络中丢失了TCP为了保证有序性会让后续所有到达的数据段都等在缓冲区里必须等重传的数据先到齐应用层才能拿到数据。于是HTTP/2在弱网环境下的表现可能比HTTP/1.1还差。排查方法是看看服务端错误日志里有没有高RTO重传或者抓包看是否有大量Dup ACK和重传报文。如果网络丢包率高那么HTTP/1.1的多连接反而有更好的容错性——一条连接挂了另一条还能继续工作。5.5 问题五如何优化TCP层面上的页面加载性能根据我自己的项目实施经验最实用的几条建议优先保证连接复用。页面资源尽量走同一域名确保浏览器能复用已建立的TCP连接。如果加载的是第三方脚本库考虑用本地文件替代外部引用减少跨境连接的开销。减小关键请求链路的RTT。使用CDN、选择离用户更近的机房。任何连接层面的优化都绕不开RTT。大文件考虑分段下载或并行连接。TCP的窗口增长特性决定了长时间、大流量传输才能跑满带宽短小请求很难从大窗口获益。服务端开启TCP Fast Open。允许在TCP握手阶段携带数据减少一个RTT的等待。关键接口使用HTTP/2但不盲目跟风。在丢包率高的网络环境下HTTP/2可能反而慢需要实际测数据来决定。6. 还有几个值得留意的细节6.1 TCP缓冲区的实际大小并不总是“越大越好”接收缓冲区越大能容纳的乱序数据越多传输效率越高但缓冲区太大也有副作用比如内存占用高、对丢包感知迟钝。内核socket缓冲区大小可以调整# 查看当前值 sysctl net.ipv4.tcp_rmem sysctl net.ipv4.tcp_wmem这三个数字分别表示最小、默认、最大缓冲字节数。如果服务端要给高带宽高延迟场景提供服务考虑调大tcp_rmem和tcp_wmem的最大值。但注意调大之后如果并发连接数很高内存消耗会快速上涨要在资源和速度之间做权衡。6.2 Nagle算法与延迟确认的纠缠TCP传输层有两个经典“小动作”会影响页面加载速度Nagle算法把小数据包攒起来等前面的数据确认后再一起发减少网络中过小报文的数量。对网络友好但对交互型请求不友好——你会感觉到“敲一下键盘卡一下”的延迟感。延迟确认接收方收到数据后不立刻回ACK而是等一小会儿Linux下典型是40ms攒多个ACK一起回。对减少ACK报文数量有好处但和Nagle算法叠加时会产生经典的“40毫秒延迟”问题。如果你在用TCP做实时性要求高的应用比如WebSocket推送、在线协作编辑建议关掉Nagle对socket设置TCP_NODELAY。浏览器自身的HTTP请求则一般不受这个影响因为HTTP请求本身数据量足够大不会触发Nagle的小包攒积条件。6.3 序列号回绕与时间戳选项TCP的序列号是有限范围的32位约4.3GB传大文件或者长时间连接时可能发生序列号回绕。TCP通过时间戳选项TCP Timestamps来辅助计算RTT和区分重复的数据段。Wireshark里经常看到的“PAWS”Protect Against Wrapped Sequence Number保护机制就是利用时间戳判断一段数据是否真的重复。日常开发中一般不用操心这个但抓包看到相关报错时知道是这么回事就行了。一些实操后的经验心得我自己在实际调优TCP的时候最大的体感是“不要轻易动内核参数”。很多网络教程一上来就让人改somaxconn、调拥塞窗口、关Nagle听起来都能提升性能但大多数页面场景下问题根本不是这些参数能解决的。你先把应用层做好——压缩资源、减少请求数量、开启连接复用、选好CDNTCP的不满意自然少一大半。TCP参数调整是高手的精细化操作新手很容易调完发现性能没变反而让某类异常场景更糟。如果真要对TCP做优化我比较推荐的方式是先掌握当前网络的实际链路质量。用长日志跑个周级数据看连接成功率、TLS握手时间、重传率、RTT分布。有了数据支撑再判断要调整哪个环节。完全没有必要为了“调优”而调优。另外如果你是前端开发者建议花半天时间了解一下Wireshark的基本用法不用钻研很深会抓包、会看关键字段就够了。网络问题排查时这个技能非常救命很多后端、运维同事都会高看你一眼。TCP协议是网络世界里最值得花时间理解的协议之一。它不复杂到让人绝望也不简单到一眼看穿。当你真正理解它之后很多“玄学”加载问题都可以找到明确的技术归因。这篇文章如果能帮你建立起一个从浏览器到TCP的清晰认知框架那我这段踩坑式研究就没白费。
阅读完成 · 觉得有帮助？
