1. 理解HTTP与TCP的关系先有TCP才有HTTP的“靠谱”我最早真正理解TCP和HTTP的关系不是在教科书上而是在一次抓包复盘的时候。当时线上有个服务偶尔超时我把整个请求链路的报文抓下来逐帧看发现TCP层在疯狂重传而HTTP层还在傻傻地等响应。那一刻我意识到我们平时说的“HTTP协议”表面上是浏览器和服务器之间的约定但底下真正扛事、真正保证数据不丢不乱不重复的其实是TCP。很多做Web开发的朋友对HTTP很熟知道状态码、Method、Header但一问到“HTTP为什么能这么放心地把请求扔出去就不管了”反而答不上来。核心答案就是HTTP是TCP协议的获益者。它不需要自己实现分片、重传、排序、流量控制这些脏活累活全部由TCP承包。HTTP只需要定义“我说什么格式”“你回什么格式”至于这段数据能不能完整到达对端HTTP一概不负责。这个分工是整个互联网应用能够快速迭代的基础也是深入理解网络性能问题时绕不开的底层逻辑。这套分工还解释了另一个经典问题为什么HTTP通常跑在TCP上而不是UDP上因为UDP只负责“尽力发送”它不保证顺序、不保证不丢天然不适合像网页、接口这样要求完整、有序、可靠的数据交换。除非应用层自己实现一大堆可靠性机制否则直接用UDP承载HTTP就是在沙滩上盖楼。所以TCP/IP协议族里TCP和HTTP是天生的一对TCP提供可靠字节流HTTP在这条字节流之上定义语义。我见过不少人把TCP/IP协议当成一个单一协议其实它是一整个协议栈。IP负责寻址和路由TCP负责端到端的可靠传输HTTP属于最上层的应用协议。你可以把IP想象成快递公司的运输网络TCP是快递员手里的签收流程而HTTP是包裹里那张写着“我要买这个商品”的订单。没有快递员签收流程订单可能丢失、错乱而订单本身不用关心自己是怎么被送达的它只负责把自己的内容写好。HTTP就是那张订单。2. 三次握手、四次挥手与HTTP请求一条链路上的完整故事2.1 三次握手不是摆设它是HTTP请求的发射前检查HTTP请求发出之前TCP必须先建立连接。这个过程就是大家熟悉的三次握手SYN、SYNACK、ACK。很多人背过这个流程但没想过它和HTTP的关系。三次握手的本质是让通信双方确认两件事第一对方的接收能力正常第二自己的发送能力被对方确认。这样HTTP请求一旦发出就能假设底层已经有了一条可靠管道。如果不做握手直接发HTTP请求对方可能根本不在线或者网络是单向通请求过去了响应回不来应用层就要自己做超时、重试、状态维护。TCP把这些问题在连接建立阶段就解决掉了。三次握手还有一个隐藏好处双方会交换初始序号。TCP是面向字节流的每个字节都有编号HTTP的数据会被拆成一个个TCP段每个段带着序号发送。接收方就是靠这些序号把数据重新拼成完整的HTTP报文。初始序号在握手时同步好后续数据传输才有据可循。这也是为什么HTTP请求在TCP层看起来是“一段连续的数据流”而不是一个独立的数据报。有一个非常经典的面试题“为什么HTTP要基于TCP而不是直接基于IP”答案就在这里。IP只管把数据包送到目的地但如果包在路上丢了、乱了、重复了IP不负责处理。HTTP如果真的直接跑在IP上就得自己实现超时重传、去重、排序那HTTP就不是一个应用协议了而是一个复杂到爆炸的传输协议。HTTP选择了站在TCP的肩膀上把可靠性外包出去。2.2 HTTP请求/响应如何在TCP上“搭便车”一个典型的HTTP请求流程是这样的浏览器解析URL得到IP和端口向服务器发起TCP连接三次握手完成后浏览器把HTTP请求报文当作TCP的载荷发送过去。服务器在TCP层把收到的字节流重组好交给HTTP解析器处理完业务再把HTTP响应报文通过同一个TCP连接发送回来。这里有一个很多人忽略的点HTTP报文在TCP眼里只是“一串字节”TCP并不关心这串字节是GET还是POST也不关心JSON结构是什么。TCP只负责把这串字节可靠地从A传到B。HTTP的边界划分是靠空行和Content-Length来实现的而不是TCP主动帮你划分。所以抓包的时候你会看到一个HTTP请求往往被拆成多个TCP段发送。比如一个8KB的POST请求TCP可能分6个段传出去。接收方收齐之后按序号拼接再交给HTTP层。这就是“字节流”的含义HTTP数据没有独立边界TCP用序号保证边界重组。这个机制在排查“响应慢”时特别重要很多时候不是HTTP处理慢而是TCP分段传输遇上网络拥塞导致整个报文迟迟没能组装完。2.3 TCP的连接管理直接把HTTP从复杂状态机里解放出来HTTP 1.1默认用持久连接也就是一个TCP连接上可以连续发送多个HTTP请求。这个特性就是TCP连接管理能力的直接体现。连接建立一次重复使用省掉了重复握手的开销。HTTP/2进一步在一个TCP连接上多路复用多个请求依然依托TCP的可靠传输能力。反过来看如果HTTP跑在UDP上那连接的概念就没了。HTTP/3选择使用QUIC协议本质上是把TCP的可靠性逻辑搬到了UDP之上、用户态实现。这件事从侧面证明了TCP的可靠性设计太重要了以至于即使要换协议也要把这份可靠性带走。凡是涉及重要数据的协议终究绕不开TCP当初解决的那几个问题丢包、乱序、重复、流量控制。所以说HTTP是TCP协议的获益者这个“获益”不只是技术上的省事更是工程上的解耦。HTTP的设计者可以专注语义TCP的设计者可以专注传输质量。两者各司其职才有了我们用浏览器访问网页时那种“输入网址就能打开”的顺畅体验。3. 从抓包到调优TCP与HTTP协作的实操现场3.1 用抓包理解“TCP为HTTP做了什么”我建议每个做Web开发的人都亲手抓一次包别只看Wireshark的图形界面要去看TCP层的Seq和Ack关系。实际操作很简单。在电脑上跑一个本地Nginx用curl请求一个页面同时用tcpdump抓回环接口sudo tcpdump -i lo0 -nn port 80 -w http_tcp.pcap然后在另一个终端curl -v http://localhost/抓完用Wireshark打开展开TCP报文段你会看到非常清晰的序列号递增。第一次握手Seq0ACK1第二次握手Seq0ACK1第三次握手Seq1ACK1。之后HTTP GET请求发出Seq1Len83然后服务器响应Seq1Ack84。这个84就是80字节HTTP请求的下一字节编号。之所以强调看这个细节是因为很多性能问题的根源都在序号上。如果服务器收到HTTP请求后返回的ACK比窗口小说明接收缓冲区还有空间如果窗口变成0说明接收方处理不过来HTTP请求再简单也会卡住。这些状态在HTTP层完全看不出来只能看TCP。3.2 影响HTTP体验的TCP关键参数很多人调HTTP性能第一反应是加缓存、加CDN、优化代码但有时候瓶颈根本不在HTTP层而在TCP参数上。我总结过几个关键项。第一个是MSS最大分段大小。MSS决定了每个TCP段能承载多少HTTP数据。如果MSS设置过大IP层就要分片一旦分片丢失整个TCP段都要重传HTTP延迟会显著增加。常规以太网MSS是1460字节这是MTU1500减去IP头20字节和TCP头20字节的结果。如果你的网络环境里MTU比较小比如PPPoE拨号是1492那MSS就要相应调整否则会出现“网页能打开但图片加载很慢”的诡异现象。第二个是TCP窗口。接收窗口决定了发送方一次可以发多少数据不用等ACK。HTTP请求如果是小包窗口影响不大但如果是大文件下载窗口太小会导致链路利用不充分。Linux下可以通过sysctl net.ipv4.tcp_window_scaling查看窗口缩放是否开启。现代操作系统默认开启但如果中间设备不支持或者TCP握手时没有协商好窗口上限就只有64KB大流量传输时吞吐直接腰斩。第三个是Nagle算法。Nagle算法会把小包合并成大包再发送目的是减少网络小包数量但对HTTP请求这种“发送一个很小的包然后等响应”的场景Nagle算法可能引入延迟。所以像SSH、WebSocket这类实时性要求高的应用往往要关闭Nagle算法也就是设置TCP_NODELAY。HTTP的短请求一般无所谓但长连接上的交互式请求最好开启TCP_NODELAY默认情况下很多语言框架已经做了这件事。3.3 慢是TCP还是HTTP的锅判断方法排查“HTTP请求慢”时我有一套固定打法。先看TCP握手时间。用curl的-w参数可以输出详细耗时curl -o /dev/null -s -w dns:%{time_namelookup} connect:%{time_connect} ttfb:%{time_starttransfer} total:%{time_total}\n http://example.com其中time_connect是TCP握手完成的时间time_starttransfer是收到响应首字节的时间。如果time_connect很大说明TCP层就有问题比如网络延迟高、握手丢包、半连接队列溢出。如果time_connect很小但是time_starttransfer很大那可能是HTTP请求发送后服务器迟迟没处理完也可能是TCP传输中出现重传。判断重传可以直接看网卡统计netstat -s | grep -i retrans如果重传率超过1%就要特别注意。重传多的时候HTTP响应时间会呈指数级恶化因为TCP超时重传的等待时间是指数退避的。第一次重传等1秒第二次等2秒第三次等4秒用户感知就是页面卡顿好几秒。我曾经排查过一个接口偶发2-3秒延迟的案例。从应用日志看HTTP请求到达服务器的时间正常响应时间也就30毫秒但客户端感知经常超过2秒。后来抓包发现客户端发出的HTTP请求有一个TCP分段丢了服务器收不齐迟迟不触发业务逻辑客户端这边等了1秒才开始重传重传后又因为网络抖动再次丢失。最后定位到是运营商网络中的MTU问题调整MSS后问题消失。这个案例让我深刻意识到HTTP性能的很多瓶颈藏在TCP层不懂TCP就没法真正懂HTTP。4. 绕不开的相关话题TCP、UDP与工业通信中的HTTP/TCP影子4.1 TCP与UDP的区别为什么HTTP选TCP整理过这么多抓包经验我愈发觉得“TCP和UDP的区别”这个话题不能只背对比表格要落到场景里去看。TCP是面向连接的、可靠的、有序的字节流协议适合HTTP、FTP、SMTP这类对完整性要求极高的应用。UDP是无连接的、不可靠的、无序的数据报协议适合DNS查询、视频通话、游戏帧同步这类“丢一点数据没关系但延迟必须低”的场景。直接用UDP承载HTTP不是不行但应用层必须自己解决丢包重传和乱序重组这就是HTTP/3把QUIC作为传输层的原因。QUIC在UDP之上实现了类似TCP的可靠性机制还引入了连接ID和多路复用。这说明一个道理TCP的可靠性设计是经过几十年验证的标杆哪怕换成UDP该有的机制一样也不能少。4.2 顺带聊聊Modbus TCP场景中的TCP细节最近看到网上有人在问“西门子PLC200能不能实现Modbus TCP通讯”这个话题其实和HTTP没关系但底层同样是TCP协议。Modbus TCP是把Modbus报文封装在TCP载荷里端口502。S7-200系列本身没有原生Modbus TCP指令需要通过外部网关或协议转换模块。有人卡在这里以为是PLC的问题其实很多时候是TCP连接建立不成功或者端口被防火墙拦了。排查思路和HTTP超时是一样的先用telnet ip 502或nc -vz ip 502确认端口通不通如果TCP握手都失败那换什么应用协议都没用。这个案例告诉我们无论上层是HTTP还是Modbus只要跑在TCP上TCP连接的建立和维护就是共同底座。学会TCP的排查方法不止能解决Web问题还能迁移到各种工业协议、数据库协议、消息队列协议的排障中。这也是我为什么一直说TCP值得每个开发者深度掌握一次。4.3 面向未来的思考HTTP/3为什么不直接用TCP了讲到这里很多人会问既然TCP这么好为什么HTTP/3要改用QUIC/UDP原因是TCP的连接重建立代价太高。HTTP/2虽然在一个TCP连接上多路复用多个请求但一旦丢包TCP的队头阻塞会让所有请求一起等待。这在弱网环境下体验很差。HTTP/3选择UDP加QUIC把可靠传输放到用户态连接迁移也更灵活从WiFi切到蜂窝网络时不用重新握手。但请注意QUIC内部仍然有ACK机制、重传机制、流量控制它的本质还是“学着TCP的样子做事”。所以HTTP/3并没有否定TCP它只是说明在移动互联网时代TCP的内核实现和连接语义存在一些性能代价应用层希望拥有更大的控制权。但无论怎么变TCP确立的可靠传输模型仍然是所有重要协议设计的底层参照系。HTTP作为TCP的获益者这个判断在HTTP/3时代依然是成立的只是“获益方式”从“使用TCP”变成了“借鉴TCP”。5. 常见问题与排查技巧实录5.1 握手正常但HTTP请求一直无响应现象抓包看到三次握手完成客户端也发出了HTTP请求但服务器迟迟不回复客户端的TCP窗口逐渐变小直到0。排查思路先确认服务器端的HTTP服务是否真的在监听端口。很多人只检查了TCP端口通却忽略了应用进程挂了。端口通只意味着内核协议栈在响应不代表HTTP服务没问题。我用这个命令快速确认ss -tnp | grep :80如果看到LISTEN状态且有对应进程再深入看应用日志。还有一种常见情况是HTTP请求头不完整服务器在等剩余数据。TCP是字节流HTTP报文没收到完整的空行之前服务器会继续等哪怕客户端已经发送了半个请求。这时候要检查客户端是否有设置Content-Length或Transfer-Encoding别让服务器一直处于“读请求”状态。5.2 客户端抓包有响应业务层却说收不到有一次排查发现TCP层数据都到了服务器也回了ACK但HTTP客户端就是报超时。最后定位到是代理服务器的问题代理在TCP层做了转发却因为连接池里的连接已经失效数据被代理丢弃了TCP层面上毫无感知。这种问题的核心在于TCP只保证端到端的传输但实际路径中可能有一层透明代理在两边各建立一条TCP连接。代理断开时客户端和服务端都不知道最直接的现象就是“TCP活着HTTP死了”。排查方法是开启HTTP的Keep-Alive日志看连接复用情况以及配合代理的健康检查机制。5.3 UDP场景下排查误区有人遇到网络丢包不管三七二十一就怪UDP。但很多时候UDP丢包是接收缓冲区太小导致的不是网络真的丢了。Linux下可以通过netstat -su看丢包统计如果RcvbufErrors在增长就是接收队列溢出。这个和TCP的流量控制正好形成对比TCP有滑动窗口接收方忙不过来会主动告诉发送方“慢一点”UDP没有这个机制内核缓冲区满了就直接扔包。所以UDP应用必须自己考虑背压控制否则在高并发下会丢得莫名其妙。5.4 一个我一直保留的排查脚本我在处理TCP/HTTP类问题时习惯用一个简明脚本快速摸底#!/bin/bash # 快速网络链路健康检查 echo 本机网卡丢包统计 netstat -i echo TCP重传统计 netstat -s | grep -i retrans echo 端口监听状态 ss -tlnp | grep -E :(80|443|8000|8080) echo 默认路由 ip route | head -1这套检查在我排查过的大量问题中都派上过用场。最后再分享一个小技巧在Wireshark里过滤HTTP请求时不要只写http可以配合tcp.len 0查看真正携带数据的TCP段这样能看到HTTP报文在TCP层的分段情况。我见过太多人盯着HTTP层看却错过了TCP层最关键的线索把一次经典的TCP重传问题硬生生看成了HTTP业务问题。TCP是HTTP的地基地基不稳上层表现再正常都是假象。 HTTP与TCP的关系：三次握手、可靠传输与抓包调优实战
1. 理解HTTP与TCP的关系先有TCP才有HTTP的“靠谱”我最早真正理解TCP和HTTP的关系不是在教科书上而是在一次抓包复盘的时候。当时线上有个服务偶尔超时我把整个请求链路的报文抓下来逐帧看发现TCP层在疯狂重传而HTTP层还在傻傻地等响应。那一刻我意识到我们平时说的“HTTP协议”表面上是浏览器和服务器之间的约定但底下真正扛事、真正保证数据不丢不乱不重复的其实是TCP。很多做Web开发的朋友对HTTP很熟知道状态码、Method、Header但一问到“HTTP为什么能这么放心地把请求扔出去就不管了”反而答不上来。核心答案就是HTTP是TCP协议的获益者。它不需要自己实现分片、重传、排序、流量控制这些脏活累活全部由TCP承包。HTTP只需要定义“我说什么格式”“你回什么格式”至于这段数据能不能完整到达对端HTTP一概不负责。这个分工是整个互联网应用能够快速迭代的基础也是深入理解网络性能问题时绕不开的底层逻辑。这套分工还解释了另一个经典问题为什么HTTP通常跑在TCP上而不是UDP上因为UDP只负责“尽力发送”它不保证顺序、不保证不丢天然不适合像网页、接口这样要求完整、有序、可靠的数据交换。除非应用层自己实现一大堆可靠性机制否则直接用UDP承载HTTP就是在沙滩上盖楼。所以TCP/IP协议族里TCP和HTTP是天生的一对TCP提供可靠字节流HTTP在这条字节流之上定义语义。我见过不少人把TCP/IP协议当成一个单一协议其实它是一整个协议栈。IP负责寻址和路由TCP负责端到端的可靠传输HTTP属于最上层的应用协议。你可以把IP想象成快递公司的运输网络TCP是快递员手里的签收流程而HTTP是包裹里那张写着“我要买这个商品”的订单。没有快递员签收流程订单可能丢失、错乱而订单本身不用关心自己是怎么被送达的它只负责把自己的内容写好。HTTP就是那张订单。2. 三次握手、四次挥手与HTTP请求一条链路上的完整故事2.1 三次握手不是摆设它是HTTP请求的发射前检查HTTP请求发出之前TCP必须先建立连接。这个过程就是大家熟悉的三次握手SYN、SYNACK、ACK。很多人背过这个流程但没想过它和HTTP的关系。三次握手的本质是让通信双方确认两件事第一对方的接收能力正常第二自己的发送能力被对方确认。这样HTTP请求一旦发出就能假设底层已经有了一条可靠管道。如果不做握手直接发HTTP请求对方可能根本不在线或者网络是单向通请求过去了响应回不来应用层就要自己做超时、重试、状态维护。TCP把这些问题在连接建立阶段就解决掉了。三次握手还有一个隐藏好处双方会交换初始序号。TCP是面向字节流的每个字节都有编号HTTP的数据会被拆成一个个TCP段每个段带着序号发送。接收方就是靠这些序号把数据重新拼成完整的HTTP报文。初始序号在握手时同步好后续数据传输才有据可循。这也是为什么HTTP请求在TCP层看起来是“一段连续的数据流”而不是一个独立的数据报。有一个非常经典的面试题“为什么HTTP要基于TCP而不是直接基于IP”答案就在这里。IP只管把数据包送到目的地但如果包在路上丢了、乱了、重复了IP不负责处理。HTTP如果真的直接跑在IP上就得自己实现超时重传、去重、排序那HTTP就不是一个应用协议了而是一个复杂到爆炸的传输协议。HTTP选择了站在TCP的肩膀上把可靠性外包出去。2.2 HTTP请求/响应如何在TCP上“搭便车”一个典型的HTTP请求流程是这样的浏览器解析URL得到IP和端口向服务器发起TCP连接三次握手完成后浏览器把HTTP请求报文当作TCP的载荷发送过去。服务器在TCP层把收到的字节流重组好交给HTTP解析器处理完业务再把HTTP响应报文通过同一个TCP连接发送回来。这里有一个很多人忽略的点HTTP报文在TCP眼里只是“一串字节”TCP并不关心这串字节是GET还是POST也不关心JSON结构是什么。TCP只负责把这串字节可靠地从A传到B。HTTP的边界划分是靠空行和Content-Length来实现的而不是TCP主动帮你划分。所以抓包的时候你会看到一个HTTP请求往往被拆成多个TCP段发送。比如一个8KB的POST请求TCP可能分6个段传出去。接收方收齐之后按序号拼接再交给HTTP层。这就是“字节流”的含义HTTP数据没有独立边界TCP用序号保证边界重组。这个机制在排查“响应慢”时特别重要很多时候不是HTTP处理慢而是TCP分段传输遇上网络拥塞导致整个报文迟迟没能组装完。2.3 TCP的连接管理直接把HTTP从复杂状态机里解放出来HTTP 1.1默认用持久连接也就是一个TCP连接上可以连续发送多个HTTP请求。这个特性就是TCP连接管理能力的直接体现。连接建立一次重复使用省掉了重复握手的开销。HTTP/2进一步在一个TCP连接上多路复用多个请求依然依托TCP的可靠传输能力。反过来看如果HTTP跑在UDP上那连接的概念就没了。HTTP/3选择使用QUIC协议本质上是把TCP的可靠性逻辑搬到了UDP之上、用户态实现。这件事从侧面证明了TCP的可靠性设计太重要了以至于即使要换协议也要把这份可靠性带走。凡是涉及重要数据的协议终究绕不开TCP当初解决的那几个问题丢包、乱序、重复、流量控制。所以说HTTP是TCP协议的获益者这个“获益”不只是技术上的省事更是工程上的解耦。HTTP的设计者可以专注语义TCP的设计者可以专注传输质量。两者各司其职才有了我们用浏览器访问网页时那种“输入网址就能打开”的顺畅体验。3. 从抓包到调优TCP与HTTP协作的实操现场3.1 用抓包理解“TCP为HTTP做了什么”我建议每个做Web开发的人都亲手抓一次包别只看Wireshark的图形界面要去看TCP层的Seq和Ack关系。实际操作很简单。在电脑上跑一个本地Nginx用curl请求一个页面同时用tcpdump抓回环接口sudo tcpdump -i lo0 -nn port 80 -w http_tcp.pcap然后在另一个终端curl -v http://localhost/抓完用Wireshark打开展开TCP报文段你会看到非常清晰的序列号递增。第一次握手Seq0ACK1第二次握手Seq0ACK1第三次握手Seq1ACK1。之后HTTP GET请求发出Seq1Len83然后服务器响应Seq1Ack84。这个84就是80字节HTTP请求的下一字节编号。之所以强调看这个细节是因为很多性能问题的根源都在序号上。如果服务器收到HTTP请求后返回的ACK比窗口小说明接收缓冲区还有空间如果窗口变成0说明接收方处理不过来HTTP请求再简单也会卡住。这些状态在HTTP层完全看不出来只能看TCP。3.2 影响HTTP体验的TCP关键参数很多人调HTTP性能第一反应是加缓存、加CDN、优化代码但有时候瓶颈根本不在HTTP层而在TCP参数上。我总结过几个关键项。第一个是MSS最大分段大小。MSS决定了每个TCP段能承载多少HTTP数据。如果MSS设置过大IP层就要分片一旦分片丢失整个TCP段都要重传HTTP延迟会显著增加。常规以太网MSS是1460字节这是MTU1500减去IP头20字节和TCP头20字节的结果。如果你的网络环境里MTU比较小比如PPPoE拨号是1492那MSS就要相应调整否则会出现“网页能打开但图片加载很慢”的诡异现象。第二个是TCP窗口。接收窗口决定了发送方一次可以发多少数据不用等ACK。HTTP请求如果是小包窗口影响不大但如果是大文件下载窗口太小会导致链路利用不充分。Linux下可以通过sysctl net.ipv4.tcp_window_scaling查看窗口缩放是否开启。现代操作系统默认开启但如果中间设备不支持或者TCP握手时没有协商好窗口上限就只有64KB大流量传输时吞吐直接腰斩。第三个是Nagle算法。Nagle算法会把小包合并成大包再发送目的是减少网络小包数量但对HTTP请求这种“发送一个很小的包然后等响应”的场景Nagle算法可能引入延迟。所以像SSH、WebSocket这类实时性要求高的应用往往要关闭Nagle算法也就是设置TCP_NODELAY。HTTP的短请求一般无所谓但长连接上的交互式请求最好开启TCP_NODELAY默认情况下很多语言框架已经做了这件事。3.3 慢是TCP还是HTTP的锅判断方法排查“HTTP请求慢”时我有一套固定打法。先看TCP握手时间。用curl的-w参数可以输出详细耗时curl -o /dev/null -s -w dns:%{time_namelookup} connect:%{time_connect} ttfb:%{time_starttransfer} total:%{time_total}\n http://example.com其中time_connect是TCP握手完成的时间time_starttransfer是收到响应首字节的时间。如果time_connect很大说明TCP层就有问题比如网络延迟高、握手丢包、半连接队列溢出。如果time_connect很小但是time_starttransfer很大那可能是HTTP请求发送后服务器迟迟没处理完也可能是TCP传输中出现重传。判断重传可以直接看网卡统计netstat -s | grep -i retrans如果重传率超过1%就要特别注意。重传多的时候HTTP响应时间会呈指数级恶化因为TCP超时重传的等待时间是指数退避的。第一次重传等1秒第二次等2秒第三次等4秒用户感知就是页面卡顿好几秒。我曾经排查过一个接口偶发2-3秒延迟的案例。从应用日志看HTTP请求到达服务器的时间正常响应时间也就30毫秒但客户端感知经常超过2秒。后来抓包发现客户端发出的HTTP请求有一个TCP分段丢了服务器收不齐迟迟不触发业务逻辑客户端这边等了1秒才开始重传重传后又因为网络抖动再次丢失。最后定位到是运营商网络中的MTU问题调整MSS后问题消失。这个案例让我深刻意识到HTTP性能的很多瓶颈藏在TCP层不懂TCP就没法真正懂HTTP。4. 绕不开的相关话题TCP、UDP与工业通信中的HTTP/TCP影子4.1 TCP与UDP的区别为什么HTTP选TCP整理过这么多抓包经验我愈发觉得“TCP和UDP的区别”这个话题不能只背对比表格要落到场景里去看。TCP是面向连接的、可靠的、有序的字节流协议适合HTTP、FTP、SMTP这类对完整性要求极高的应用。UDP是无连接的、不可靠的、无序的数据报协议适合DNS查询、视频通话、游戏帧同步这类“丢一点数据没关系但延迟必须低”的场景。直接用UDP承载HTTP不是不行但应用层必须自己解决丢包重传和乱序重组这就是HTTP/3把QUIC作为传输层的原因。QUIC在UDP之上实现了类似TCP的可靠性机制还引入了连接ID和多路复用。这说明一个道理TCP的可靠性设计是经过几十年验证的标杆哪怕换成UDP该有的机制一样也不能少。4.2 顺带聊聊Modbus TCP场景中的TCP细节最近看到网上有人在问“西门子PLC200能不能实现Modbus TCP通讯”这个话题其实和HTTP没关系但底层同样是TCP协议。Modbus TCP是把Modbus报文封装在TCP载荷里端口502。S7-200系列本身没有原生Modbus TCP指令需要通过外部网关或协议转换模块。有人卡在这里以为是PLC的问题其实很多时候是TCP连接建立不成功或者端口被防火墙拦了。排查思路和HTTP超时是一样的先用telnet ip 502或nc -vz ip 502确认端口通不通如果TCP握手都失败那换什么应用协议都没用。这个案例告诉我们无论上层是HTTP还是Modbus只要跑在TCP上TCP连接的建立和维护就是共同底座。学会TCP的排查方法不止能解决Web问题还能迁移到各种工业协议、数据库协议、消息队列协议的排障中。这也是我为什么一直说TCP值得每个开发者深度掌握一次。4.3 面向未来的思考HTTP/3为什么不直接用TCP了讲到这里很多人会问既然TCP这么好为什么HTTP/3要改用QUIC/UDP原因是TCP的连接重建立代价太高。HTTP/2虽然在一个TCP连接上多路复用多个请求但一旦丢包TCP的队头阻塞会让所有请求一起等待。这在弱网环境下体验很差。HTTP/3选择UDP加QUIC把可靠传输放到用户态连接迁移也更灵活从WiFi切到蜂窝网络时不用重新握手。但请注意QUIC内部仍然有ACK机制、重传机制、流量控制它的本质还是“学着TCP的样子做事”。所以HTTP/3并没有否定TCP它只是说明在移动互联网时代TCP的内核实现和连接语义存在一些性能代价应用层希望拥有更大的控制权。但无论怎么变TCP确立的可靠传输模型仍然是所有重要协议设计的底层参照系。HTTP作为TCP的获益者这个判断在HTTP/3时代依然是成立的只是“获益方式”从“使用TCP”变成了“借鉴TCP”。5. 常见问题与排查技巧实录5.1 握手正常但HTTP请求一直无响应现象抓包看到三次握手完成客户端也发出了HTTP请求但服务器迟迟不回复客户端的TCP窗口逐渐变小直到0。排查思路先确认服务器端的HTTP服务是否真的在监听端口。很多人只检查了TCP端口通却忽略了应用进程挂了。端口通只意味着内核协议栈在响应不代表HTTP服务没问题。我用这个命令快速确认ss -tnp | grep :80如果看到LISTEN状态且有对应进程再深入看应用日志。还有一种常见情况是HTTP请求头不完整服务器在等剩余数据。TCP是字节流HTTP报文没收到完整的空行之前服务器会继续等哪怕客户端已经发送了半个请求。这时候要检查客户端是否有设置Content-Length或Transfer-Encoding别让服务器一直处于“读请求”状态。5.2 客户端抓包有响应业务层却说收不到有一次排查发现TCP层数据都到了服务器也回了ACK但HTTP客户端就是报超时。最后定位到是代理服务器的问题代理在TCP层做了转发却因为连接池里的连接已经失效数据被代理丢弃了TCP层面上毫无感知。这种问题的核心在于TCP只保证端到端的传输但实际路径中可能有一层透明代理在两边各建立一条TCP连接。代理断开时客户端和服务端都不知道最直接的现象就是“TCP活着HTTP死了”。排查方法是开启HTTP的Keep-Alive日志看连接复用情况以及配合代理的健康检查机制。5.3 UDP场景下排查误区有人遇到网络丢包不管三七二十一就怪UDP。但很多时候UDP丢包是接收缓冲区太小导致的不是网络真的丢了。Linux下可以通过netstat -su看丢包统计如果RcvbufErrors在增长就是接收队列溢出。这个和TCP的流量控制正好形成对比TCP有滑动窗口接收方忙不过来会主动告诉发送方“慢一点”UDP没有这个机制内核缓冲区满了就直接扔包。所以UDP应用必须自己考虑背压控制否则在高并发下会丢得莫名其妙。5.4 一个我一直保留的排查脚本我在处理TCP/HTTP类问题时习惯用一个简明脚本快速摸底#!/bin/bash # 快速网络链路健康检查 echo 本机网卡丢包统计 netstat -i echo TCP重传统计 netstat -s | grep -i retrans echo 端口监听状态 ss -tlnp | grep -E :(80|443|8000|8080) echo 默认路由 ip route | head -1这套检查在我排查过的大量问题中都派上过用场。最后再分享一个小技巧在Wireshark里过滤HTTP请求时不要只写http可以配合tcp.len 0查看真正携带数据的TCP段这样能看到HTTP报文在TCP层的分段情况。我见过太多人盯着HTTP层看却错过了TCP层最关键的线索把一次经典的TCP重传问题硬生生看成了HTTP业务问题。TCP是HTTP的地基地基不稳上层表现再正常都是假象。