很多人学TCP/IP第一件事就是背那几张分层图第二件事是背三次握手四次挥手。背完觉得自己懂了真到了线上排查问题对着tcpdump抓出来的包还是一脸茫然——为什么有这么多重传为什么连接堆积一堆TIME_WAIT为什么握手老是超时这篇文章我想换一种讲法不从概念出发而是从真实数据流动的角度把TCP/IP这套协议栈彻底拆开揉碎。不管你是刚入门的学生、转行做网络的开发还是被线上故障折磨的运维读完这篇你应该能建立起一套完整的网络排查思维。1. 数据到底怎么“流”起来封装与分层的真实逻辑1.1 一次浏览器请求数据在每一层干了什么先构建一个最熟悉的场景你在浏览器输入一个网址按下回车。表面上看网页内容很快就回来了但在网线、Wi-Fi、光纤里真正跑的并不是你看到的文字和图片而是一串又一串的0和1。这串0和1是按层次一层层“加工”出来的。数据从浏览器出发先被HTTP协议包装成请求报文这份报文被交给TCP协议TCP给它加上源端口、目的端口和序号信息然后切成合适大小的数据段这些数据段再交给IP协议IP又给它加上源IP、目的IP变成数据报最后落到网卡上以太网协议再套一个帧头和帧尾变成能在物理介质上传输的数据帧。这个过程有个专业名词叫封装。每一层只管自己该管的事做完就交给下一层不越界。接收端则反过来一层层拆掉头部这叫解封装。我拿一个真实抓包里的帧结构给你示意这就是一个最普通的TCP数据包在以太网上的最终形态[以太网帧头 14字节] - 目的MAC(6) 源MAC(6) 类型(2) [IP头 20字节] - 版本/首部长度(1) TOS(1) 总长度(2) 标识(2) 标志/片偏移(2) TTL(1) 协议号(1) 首部校验和(2) 源IP(4) 目的IP(4) [TCP头 20字节] - 源端口(2) 目的端口(2) 序号(4) 确认号(4) 头部长度/标志位(2) 窗口大小(2) 校验和(2) 紧急指针(2) [HTTP数据] - GET /index.html HTTP/1.1... [以太网帧尾 4字节] - FCS帧校验序列不要被这一长串吓到实际上每一层加的头都只包含这一层自己需要的信息。IP层不关心TCP端口TCP层不关心MAC地址各干各的。这也是后面排查问题的核心思路先确定问题出在哪一层才谈得上怎么解决。1.2 四层模型的职责边界以及容易被忽略的层间接口我们常说的TCP/IP协议族对应的是四层模型应用层、传输层、网络层、网络接口层。它和教科书里的OSI七层模型经常被拿来对照但实际工作中没人按七层来抓包排障基本都按四层来思考。应用层HTTP、FTP、DNS、SMTP这些具体业务的协议生成人类能理解的业务数据。传输层TCP和UDP的地盘。它给数据加上端口号实现“进程到进程”的通信并负责可靠性、流量控制。网络层IP协议的地盘。它负责寻址和路由让数据能从一台主机跑到另一台主机哪怕跨越大半个地球。网络接口层以太网、Wi-Fi这些物理链路协议负责在同一段链路内传递帧通过MAC地址寻址。这四层之间怎么认出“这是给我上一层的数据”靠的是层间接口标识。以太网头里的类型字段0x0800表示里面封装的是IPv4报文IP头里的协议号字段6表示上层是TCP17表示上层是UDPTCP/UDP头里的端口号则指明了数据要交给上层的哪个进程。1.3 分层的最大好处故障可以隔离我在实操中最深的感受是分层设计最大的价值不是让理论更好背而是让排障有了清晰路径。举个例子你发现网站打不开。如果ping不同IP问题大概率出在网络层或链路层如果能ping通但浏览器报错那问题在传输层或应用层。你要是脑子里没有层次感很容易在应用层瞎折腾半天最后发现是路由器MTU配置的问题。所以每次做网络排查我脑子里先过一遍链路层通不通、IP层通不通、TCP层能不能握手、应用层有没有响应。这个顺序固定下来排查效率会高很多。2. IP协议真正在网络上“跑腿”的地址系统2.1 IP头里那20个字节每个字段都是为路由服务的IP协议是TCP/IP体系的“地基”它的核心使命是寻址和路由。IPv4头虽然固定就20字节但每个字段都有明确用途。字段长度作用版本4bitIPv4还是IPv64表示IPv4首部长度4bitIP头长度单位是4字节常用值5表示20字节总长度16bit整个IP数据报的长度最大65535字节标识/标志/片偏移16bit3bit13bit分片与重组的关键信息TTL8bit最大跳数每经过一个路由器减1减到0丢弃协议号8bit上层协议类型TCP为6UDP为17源IP/目的IP32bit32bit通信双方的逻辑地址表格里最容易被低估的是TTL和协议号。TTL是防环的“自杀机制”——假如网络里出现路由环路没有TTL的话数据包会永远在路由器之间空转直到网络被垃圾数据灌满。每过一个路由器TTL减1减到0就丢包并回复ICMP超时这也是traceroute命令的工作原理。2.2 同网段靠ARP跨网段靠网关一条数据帧的转发决策很多人对“路由”的理解停留在概念上我拿一个典型家庭网络举例。你的电脑IP是192.168.1.100/24网关是192.168.1.1你想访问192.168.1.200这台打印机。因为目的IP和源IP在同一个网段内电脑会直接广播ARP请求询问192.168.1.200的MAC地址然后直接把帧发给打印机这中间根本不需要经过网关。但如果你要访问的是220.181.38.148这种公网IP电脑发现目的IP和自己的网段对不上就会把数据帧发给默认网关——也就是路由器的LAN口MAC地址。路由器收到这个帧后剥掉链路层头看IP目的地址查自己的路由表决定从哪个出口转发出去重新封装成新的以太网帧发给下一跳。这里有个技术细节值得注意数据跨网段传输时IP头里的源IP和目的IP始终不变但以太网帧头里的源MAC和目的MAC在每一跳都在变。这也解释了为什么抓包的时候如果在路由器外口抓看到的源MAC是路由器出口的MAC而不是你电脑的MAC。2.3 分片与MTU大包带来的“连锁噩梦”以太网标准MTU是1500字节。如果一个IP数据报超过1500字节它就得被分片——在IP层拆成多个小报文分别传输到达目的地后再重组。分片本身不复杂复杂的是一旦其中一片丢失整个原始数据报都无法重组接收方就会丢弃所有分片。这意味着丢失一个片等于丢了整包数据传输层还得触发重传。在高丢包率的链路上分片会成倍放大损失。所以TCP协议在建立连接时会协商一个MSS最大报文段长度让每个TCP段加上IP头后不超过MTU从源头上避免IP分片。这也是为什么你看到的多数TCP数据包大小都在1448字节左右——1500减20字节IP头再减20字节TCP头就是1460加在一起正好卡在MTU以内。实际数值取决于链路MTU和头开销。3. TCP的经典面试题背后连接管理的完整画面3.1 三次握手双向的“序号同步仪式”TCP三次握手是所有人最早接触的概念但它的本质不是“你好——你好——你好”的打招呼而是通信双方各自确认对方的收发能力并同步初始序号。我在纸上画过无数次这个序列客户端 服务器 |--------- SYN, seq1000 -----------| | | |------ SYNACK, seq8000, ack1001 -| | | |--------- ACK, ack8001 -----------| | | | 连接建立完成 |第一次握手客户端发送SYN并带上自己的初始序号1000第二次握手服务器回应SYNACK同时把确认号设为1001意思就是“你发的1000我收到了下次请从1001继续发”第三次握手客户端再回应ACK确认号8001意思是“你的8000我收到了”。为什么要三次而不是两次关键在服务器必须确认自己的ISN被客户端收到了。如果只有两次握手服务器不知道客户端到底有没有收到自己的初始序号——万一客户端发完SYN就失联了服务器还得白白维护一个半吊子连接这给SYN洪水攻击留了可乘之机。3.2 四次挥手与TIME_WAIT主动关闭方为什么要等2MSL挥手比握手更复杂因为TCP连接是双向的每一方向都必须单独关闭主动关闭方 被动关闭方 |--------- FIN, seq2000 -----------| | | |---------- ACK, ack2001 ----------| | | | 被动方还在发数据 | | | |--------- FIN, seq3500 -----------| | | |---------- ACK, ack3501 ----------| | | | 主动方进入TIME_WAIT |主动关闭方在发出最后一次ACK后不会立刻关闭而是进入TIME_WAIT状态等待2MSL最大报文段生存期通常是2分钟。原因有两个第一确保最后一次ACK能让对面收到如果丢了对面会重发FIN这边还能再回一个ACK第二让本连接发出的所有旧报文在网络中自然消亡防止它们混入后续连接。3.3 用netstat和ss看清真实世界里的连接状态机学完状态迁移一定要在真机上观察一遍状态机。我经常在服务器上执行ss -ant然后就能看到一堆连接状态。其中TIME_WAIT和CLOSE_WAIT是最值得盯的两个状态。TIME_WAIT多通常说明这台机器主动发起了大量短连接属于正常现象但积压过多会导致端口资源耗尽CLOSE_WAIT多则说明被动关闭方应用代码没及时调用close()属于典型的应用层泄漏。我在排查后端服务时看到大量CLOSE_WAIT的第一反应不是调内核参数而是去找代码里谁把socket忘关了。4. 可靠性不是靠“情怀”序号、确认、重传、窗口如何协同4.1 序号和确认号字节流里的“页码系统”TCP是面向字节流的可靠传输协议。可靠性的支柱就是报文段里的序号和确认号。假设你要发送一段5000字节的数据TCP会把它切分成多个段比如第1段带序号1001-1200第2段带序号1201-1400。接收方每收到一个段会回复确认号确认号的值代表“我已收到该序号之前的全部字节请从这个序号继续发”。这里有个经典坑很多人以为确认号是“收到第几个包”其实是“下一个期望收到的字节序号”。比如收到1-200字节回ack201意思是“请从201开始发”。这个细节抓包时非常明显理解之后读tcpdump输出会流畅得多。TCP还采用累积确认机制——接收方只确认连续收到的数据。如果中间有个洞即使后面的数据都到了确认号也只会停在洞的前面这引导发送方优先补漏。4.2 滑动窗口允许“抢跑”但有限度可靠性不等于傻等——如果发一个数据必须等确认才能再发下一个网络利用率会惨不忍睹。TCP用滑动窗口做流量控制。接收方在TCP头里带上“窗口大小”字段告诉发送方“你还能再发多少字节我心里有数。”发送方在窗口范围内收到确认就往前滑动窗口也随接收方处理能力动态调整。这就是流量控制核心是让发送速度匹配接收方的处理速度。初学的时候容易把流量控制和拥塞控制搞混。一句话区分流量控制是接收方根据自己能力约束发送方拥塞控制是发送方根据网络状况主动收敛。4.3 超时重传与快速重传丢包的两种自救数据丢失时TCP有两种自救手段。一是超时重传发送方给每个段设定一个定时器超时没收到确认就重传。超时时间基于RTT采样动态计算不能太长也不能太短。二是快速重传如果接收方收到乱序数据序号有缺口会立刻重复确认期望的序号。发送方连续收到3个相同的重复ACK就知道某个段丢了不等超时立刻重传。快速重传的价值在于减少了白白等待的时间。4.4 拥塞控制慢启动、拥塞避免和快恢复如果说滑动窗口管的是“接收方装不装得下”拥塞控制管的就是“网络扛不扛得住”。TCP发送方维护一个拥塞窗口cwnd实际能发送的数据量是min(拥塞窗口, 接收窗口)。连接刚建立时cwnd很小一般只有几个MSS然后每收到一轮确认就翻倍这叫慢启动。听着名字带“慢”可实际是倍数增长速度一点不慢。增长到慢启动阈值ssthresh后切换到拥塞避免cwnd按线性增长。一旦发生丢包TCP会收窄窗口把ssthresh降到丢包时cwnd的一半再重新慢启动或快速恢复。这套机制导致TCP的带宽探测像“爬坡——遇坑——收窄——再爬坡”的过程。理解这一点你就能明白为什么高延迟跨洋链路很难跑满带宽因为慢启动阶段来回确认一轮时间太长cwnd增长跟不上。实际工程中通常需要调大初始窗口或者用BBR这类新型拥塞控制算法才能改善。5. 从DNS到HTTP一次真实请求的完整链路拆解5.1 DNS应用层里最容易忽视的“UDP典型用例”在建立TCP连接之前浏览器还得先知道目标IP。DNS查询默认走UDP端口53。一个DNS请求包的封装链路是这样的应用层构造查询“www.example.com的A记录是什么”UDP加上源端口随机高位端口和目的端口53IP加上源IP和DNS服务器IP以太网封装后发出。因为单个DNS查询报文很小不需要可靠传输——如果丢了客户端直接超时重发就行这是UDP在这个场景下的经典选择。UDP和TCP的差异你在抓包里一眼就能看出来UDP头只有8字节没有序号、没有确认号、没有窗口丢不丢全靠上层自己负责。视频通话、实时游戏、DNS查询这类“能容忍少量丢包但不能容忍重传延迟”的场景UDP是更合适的载体。5.2 在一个抓包里读懂TCP/IP的全部协作我用tcpdump在Linux上抓过一次访问某个HTTP网站的过程核心几行大概是IP 192.168.1.100.54321 93.184.216.34.80: Flags [S], seq 1000 IP 93.184.216.34.80 192.168.1.100.54321: Flags [S.], seq 8000, ack 1001 IP 192.168.1.100.54321 93.184.216.34.80: Flags [.], ack 8001 IP 192.168.1.100.54321 93.184.216.34.80: Flags [P.], seq 1001:1201, ack 8001第一行客户端发SYN第二行服务器回SYNACK第三行握手完成。第四行客户端发送HTTP请求数据seq范围1001-1201一共发了200字节同时确认了服务器的8000。这里的[P.]表示带数据推送[.]表示纯ACK。等到服务器回包时IP 93.184.216.34.80 192.168.1.100.54321: Flags [P.], seq 8001:10001, ack 1201你看服务器的seq从8001开始发数据ack1201意味着“你的1001-1200我全收到了请从1201继续”。这一来一回序号、确认号、端口、IP全部协同起来了。5.3 三句话建立排查框架分层定位把前面所有内容落成一套可执行的排查方法我总结成三句话第一句ping不通先看链路和IP层。用ip addr确认本地配置用ping -c 3 网关IP切分内外网用traceroute看卡在哪一跳。第二句ping得通但TCP连不上重点看端口和状态。用ss -ant看目标端口是否有监听用telnet 目标IP 目标端口测连通性再看防火墙规则有没有放行。第三句TCP建立了但业务无响应问题大概率在应用层。这时候抓包看HTTP请求有没有到达服务端、响应有没有生成而不是再折腾传输层。6. 这些年踩过的TCP/IP坑一线实战排障记录6.1 TIME_WAIT堆积到端口耗尽有段时间我维护的一个高并发短连接服务频繁报错Cannot assign requested address一看就是本地端口被占满。用ss -s检查发现TIME_WAIT连接数以万计。原因是短连接场景下主动关闭方每次连接结束都要经历2MSL的TIME_WAIT端口在此期间被占用。最稳妥的解法不是调低TIME_WAIT而是改用长连接让连接复用起来。如果实在没办法改代码再考虑开启net.ipv4.tcp_tw_reuse让内核复用处于TIME_WAIT的连接同时配合开启TCP时间戳。这里要特别注意tcp_tw_recycle这个参数在NAT环境下容易导致丢包新的内核版本里已经移除了别再按老教程去开了。6.2 Nagle算法让你“变慢”的40毫秒我遇到过一个小包接口单次请求本身只有几十字节但每次都要白白等上40毫秒。原因是发送方开启了Nagle算法——当TCP连接里还有未确认的小包时后续小包会被攒住等之前的包确认了才一起发出去。这种“攒包”机制在实时交互场景里很致命。解法也简单程序里把TCP_NODELAY置1关闭Nagle算法让每个小包立即发出int flag 1; setsockopt(sockfd, IPPROTO_TCP, TCP_NODELAY, flag, sizeof(flag));代价是网络里可能多一些小包但在交互式应用里完全值得。这个优化在很多网络库源码里都能看到比如gRPC、Netty的某些配置项。6.3 MTU黑洞大包不通小包通还有一种疑难杂症小文件访问正常大文件下载卡死或超时。这多半是MTU黑洞。原理是这样的数据包经过某条MTU更小的链路时路由器本该通过ICMP消息通知源主机“这个包太大了请分片或减小”。但如果这个ICMP消息被中间网络过滤掉源主机就永远不知道要减小包尺寸只能反复重发大包全部石沉大海。排查时用ping -s 1472 目标IP测试不同包大小的连通性如果大包ping不通、小包能通基本就是MTU问题。治本的办法是调整链路MTU或者让路由器给通过它的TCP流量设置MSS钳制把TCP段大小限制在链路能承受的范围内。6.4 SYN队列溢出握手总是超时还有一个高频问题服务端在连接高峰时出现大量握手超时客户端开始疯狂重传SYN。这通常意味着SYN队列半连接队列溢出。服务端收到SYN后会先把这个半连接放进SYN队列等三次握手完成再移入accept队列等待应用调用accept()。队列是有上限的一旦占满新的SYN就会被直接丢弃。应用层处理不动、队列过短都会导致这个问题。我当时的处理顺序是先用ss -lnt看服务端有没有大量SYN_RECV堆积再确认应用是否来得及accept最后调整内核参数net.ipv4.tcp_max_syn_backlog和应用的backlog配置同时确保应用本身没有阻塞在耗时操作上。调参只是兜底很多所谓“SYN洪水”其实是应用层处理能力不足。把状态机、序号、窗口这几个东西吃透之后你会发现TCP/IP不再是需要死记硬背的抽象规则而是一套可以预测行为的系统。网络故障大多是某个机制被低估或者某个参数被忽略把这些机制的内在逻辑理解到位排障就没那么玄学了。 
长河君 · 2026/10/8 2:47:47 · 阅读 1.2k TCP/IP协议栈拆解：从数据流动到网络故障排查实战
很多人学TCP/IP第一件事就是背那几张分层图第二件事是背三次握手四次挥手。背完觉得自己懂了真到了线上排查问题对着tcpdump抓出来的包还是一脸茫然——为什么有这么多重传为什么连接堆积一堆TIME_WAIT为什么握手老是超时这篇文章我想换一种讲法不从概念出发而是从真实数据流动的角度把TCP/IP这套协议栈彻底拆开揉碎。不管你是刚入门的学生、转行做网络的开发还是被线上故障折磨的运维读完这篇你应该能建立起一套完整的网络排查思维。1. 数据到底怎么“流”起来封装与分层的真实逻辑1.1 一次浏览器请求数据在每一层干了什么先构建一个最熟悉的场景你在浏览器输入一个网址按下回车。表面上看网页内容很快就回来了但在网线、Wi-Fi、光纤里真正跑的并不是你看到的文字和图片而是一串又一串的0和1。这串0和1是按层次一层层“加工”出来的。数据从浏览器出发先被HTTP协议包装成请求报文这份报文被交给TCP协议TCP给它加上源端口、目的端口和序号信息然后切成合适大小的数据段这些数据段再交给IP协议IP又给它加上源IP、目的IP变成数据报最后落到网卡上以太网协议再套一个帧头和帧尾变成能在物理介质上传输的数据帧。这个过程有个专业名词叫封装。每一层只管自己该管的事做完就交给下一层不越界。接收端则反过来一层层拆掉头部这叫解封装。我拿一个真实抓包里的帧结构给你示意这就是一个最普通的TCP数据包在以太网上的最终形态[以太网帧头 14字节] - 目的MAC(6) 源MAC(6) 类型(2) [IP头 20字节] - 版本/首部长度(1) TOS(1) 总长度(2) 标识(2) 标志/片偏移(2) TTL(1) 协议号(1) 首部校验和(2) 源IP(4) 目的IP(4) [TCP头 20字节] - 源端口(2) 目的端口(2) 序号(4) 确认号(4) 头部长度/标志位(2) 窗口大小(2) 校验和(2) 紧急指针(2) [HTTP数据] - GET /index.html HTTP/1.1... [以太网帧尾 4字节] - FCS帧校验序列不要被这一长串吓到实际上每一层加的头都只包含这一层自己需要的信息。IP层不关心TCP端口TCP层不关心MAC地址各干各的。这也是后面排查问题的核心思路先确定问题出在哪一层才谈得上怎么解决。1.2 四层模型的职责边界以及容易被忽略的层间接口我们常说的TCP/IP协议族对应的是四层模型应用层、传输层、网络层、网络接口层。它和教科书里的OSI七层模型经常被拿来对照但实际工作中没人按七层来抓包排障基本都按四层来思考。应用层HTTP、FTP、DNS、SMTP这些具体业务的协议生成人类能理解的业务数据。传输层TCP和UDP的地盘。它给数据加上端口号实现“进程到进程”的通信并负责可靠性、流量控制。网络层IP协议的地盘。它负责寻址和路由让数据能从一台主机跑到另一台主机哪怕跨越大半个地球。网络接口层以太网、Wi-Fi这些物理链路协议负责在同一段链路内传递帧通过MAC地址寻址。这四层之间怎么认出“这是给我上一层的数据”靠的是层间接口标识。以太网头里的类型字段0x0800表示里面封装的是IPv4报文IP头里的协议号字段6表示上层是TCP17表示上层是UDPTCP/UDP头里的端口号则指明了数据要交给上层的哪个进程。1.3 分层的最大好处故障可以隔离我在实操中最深的感受是分层设计最大的价值不是让理论更好背而是让排障有了清晰路径。举个例子你发现网站打不开。如果ping不同IP问题大概率出在网络层或链路层如果能ping通但浏览器报错那问题在传输层或应用层。你要是脑子里没有层次感很容易在应用层瞎折腾半天最后发现是路由器MTU配置的问题。所以每次做网络排查我脑子里先过一遍链路层通不通、IP层通不通、TCP层能不能握手、应用层有没有响应。这个顺序固定下来排查效率会高很多。2. IP协议真正在网络上“跑腿”的地址系统2.1 IP头里那20个字节每个字段都是为路由服务的IP协议是TCP/IP体系的“地基”它的核心使命是寻址和路由。IPv4头虽然固定就20字节但每个字段都有明确用途。字段长度作用版本4bitIPv4还是IPv64表示IPv4首部长度4bitIP头长度单位是4字节常用值5表示20字节总长度16bit整个IP数据报的长度最大65535字节标识/标志/片偏移16bit3bit13bit分片与重组的关键信息TTL8bit最大跳数每经过一个路由器减1减到0丢弃协议号8bit上层协议类型TCP为6UDP为17源IP/目的IP32bit32bit通信双方的逻辑地址表格里最容易被低估的是TTL和协议号。TTL是防环的“自杀机制”——假如网络里出现路由环路没有TTL的话数据包会永远在路由器之间空转直到网络被垃圾数据灌满。每过一个路由器TTL减1减到0就丢包并回复ICMP超时这也是traceroute命令的工作原理。2.2 同网段靠ARP跨网段靠网关一条数据帧的转发决策很多人对“路由”的理解停留在概念上我拿一个典型家庭网络举例。你的电脑IP是192.168.1.100/24网关是192.168.1.1你想访问192.168.1.200这台打印机。因为目的IP和源IP在同一个网段内电脑会直接广播ARP请求询问192.168.1.200的MAC地址然后直接把帧发给打印机这中间根本不需要经过网关。但如果你要访问的是220.181.38.148这种公网IP电脑发现目的IP和自己的网段对不上就会把数据帧发给默认网关——也就是路由器的LAN口MAC地址。路由器收到这个帧后剥掉链路层头看IP目的地址查自己的路由表决定从哪个出口转发出去重新封装成新的以太网帧发给下一跳。这里有个技术细节值得注意数据跨网段传输时IP头里的源IP和目的IP始终不变但以太网帧头里的源MAC和目的MAC在每一跳都在变。这也解释了为什么抓包的时候如果在路由器外口抓看到的源MAC是路由器出口的MAC而不是你电脑的MAC。2.3 分片与MTU大包带来的“连锁噩梦”以太网标准MTU是1500字节。如果一个IP数据报超过1500字节它就得被分片——在IP层拆成多个小报文分别传输到达目的地后再重组。分片本身不复杂复杂的是一旦其中一片丢失整个原始数据报都无法重组接收方就会丢弃所有分片。这意味着丢失一个片等于丢了整包数据传输层还得触发重传。在高丢包率的链路上分片会成倍放大损失。所以TCP协议在建立连接时会协商一个MSS最大报文段长度让每个TCP段加上IP头后不超过MTU从源头上避免IP分片。这也是为什么你看到的多数TCP数据包大小都在1448字节左右——1500减20字节IP头再减20字节TCP头就是1460加在一起正好卡在MTU以内。实际数值取决于链路MTU和头开销。3. TCP的经典面试题背后连接管理的完整画面3.1 三次握手双向的“序号同步仪式”TCP三次握手是所有人最早接触的概念但它的本质不是“你好——你好——你好”的打招呼而是通信双方各自确认对方的收发能力并同步初始序号。我在纸上画过无数次这个序列客户端 服务器 |--------- SYN, seq1000 -----------| | | |------ SYNACK, seq8000, ack1001 -| | | |--------- ACK, ack8001 -----------| | | | 连接建立完成 |第一次握手客户端发送SYN并带上自己的初始序号1000第二次握手服务器回应SYNACK同时把确认号设为1001意思就是“你发的1000我收到了下次请从1001继续发”第三次握手客户端再回应ACK确认号8001意思是“你的8000我收到了”。为什么要三次而不是两次关键在服务器必须确认自己的ISN被客户端收到了。如果只有两次握手服务器不知道客户端到底有没有收到自己的初始序号——万一客户端发完SYN就失联了服务器还得白白维护一个半吊子连接这给SYN洪水攻击留了可乘之机。3.2 四次挥手与TIME_WAIT主动关闭方为什么要等2MSL挥手比握手更复杂因为TCP连接是双向的每一方向都必须单独关闭主动关闭方 被动关闭方 |--------- FIN, seq2000 -----------| | | |---------- ACK, ack2001 ----------| | | | 被动方还在发数据 | | | |--------- FIN, seq3500 -----------| | | |---------- ACK, ack3501 ----------| | | | 主动方进入TIME_WAIT |主动关闭方在发出最后一次ACK后不会立刻关闭而是进入TIME_WAIT状态等待2MSL最大报文段生存期通常是2分钟。原因有两个第一确保最后一次ACK能让对面收到如果丢了对面会重发FIN这边还能再回一个ACK第二让本连接发出的所有旧报文在网络中自然消亡防止它们混入后续连接。3.3 用netstat和ss看清真实世界里的连接状态机学完状态迁移一定要在真机上观察一遍状态机。我经常在服务器上执行ss -ant然后就能看到一堆连接状态。其中TIME_WAIT和CLOSE_WAIT是最值得盯的两个状态。TIME_WAIT多通常说明这台机器主动发起了大量短连接属于正常现象但积压过多会导致端口资源耗尽CLOSE_WAIT多则说明被动关闭方应用代码没及时调用close()属于典型的应用层泄漏。我在排查后端服务时看到大量CLOSE_WAIT的第一反应不是调内核参数而是去找代码里谁把socket忘关了。4. 可靠性不是靠“情怀”序号、确认、重传、窗口如何协同4.1 序号和确认号字节流里的“页码系统”TCP是面向字节流的可靠传输协议。可靠性的支柱就是报文段里的序号和确认号。假设你要发送一段5000字节的数据TCP会把它切分成多个段比如第1段带序号1001-1200第2段带序号1201-1400。接收方每收到一个段会回复确认号确认号的值代表“我已收到该序号之前的全部字节请从这个序号继续发”。这里有个经典坑很多人以为确认号是“收到第几个包”其实是“下一个期望收到的字节序号”。比如收到1-200字节回ack201意思是“请从201开始发”。这个细节抓包时非常明显理解之后读tcpdump输出会流畅得多。TCP还采用累积确认机制——接收方只确认连续收到的数据。如果中间有个洞即使后面的数据都到了确认号也只会停在洞的前面这引导发送方优先补漏。4.2 滑动窗口允许“抢跑”但有限度可靠性不等于傻等——如果发一个数据必须等确认才能再发下一个网络利用率会惨不忍睹。TCP用滑动窗口做流量控制。接收方在TCP头里带上“窗口大小”字段告诉发送方“你还能再发多少字节我心里有数。”发送方在窗口范围内收到确认就往前滑动窗口也随接收方处理能力动态调整。这就是流量控制核心是让发送速度匹配接收方的处理速度。初学的时候容易把流量控制和拥塞控制搞混。一句话区分流量控制是接收方根据自己能力约束发送方拥塞控制是发送方根据网络状况主动收敛。4.3 超时重传与快速重传丢包的两种自救数据丢失时TCP有两种自救手段。一是超时重传发送方给每个段设定一个定时器超时没收到确认就重传。超时时间基于RTT采样动态计算不能太长也不能太短。二是快速重传如果接收方收到乱序数据序号有缺口会立刻重复确认期望的序号。发送方连续收到3个相同的重复ACK就知道某个段丢了不等超时立刻重传。快速重传的价值在于减少了白白等待的时间。4.4 拥塞控制慢启动、拥塞避免和快恢复如果说滑动窗口管的是“接收方装不装得下”拥塞控制管的就是“网络扛不扛得住”。TCP发送方维护一个拥塞窗口cwnd实际能发送的数据量是min(拥塞窗口, 接收窗口)。连接刚建立时cwnd很小一般只有几个MSS然后每收到一轮确认就翻倍这叫慢启动。听着名字带“慢”可实际是倍数增长速度一点不慢。增长到慢启动阈值ssthresh后切换到拥塞避免cwnd按线性增长。一旦发生丢包TCP会收窄窗口把ssthresh降到丢包时cwnd的一半再重新慢启动或快速恢复。这套机制导致TCP的带宽探测像“爬坡——遇坑——收窄——再爬坡”的过程。理解这一点你就能明白为什么高延迟跨洋链路很难跑满带宽因为慢启动阶段来回确认一轮时间太长cwnd增长跟不上。实际工程中通常需要调大初始窗口或者用BBR这类新型拥塞控制算法才能改善。5. 从DNS到HTTP一次真实请求的完整链路拆解5.1 DNS应用层里最容易忽视的“UDP典型用例”在建立TCP连接之前浏览器还得先知道目标IP。DNS查询默认走UDP端口53。一个DNS请求包的封装链路是这样的应用层构造查询“www.example.com的A记录是什么”UDP加上源端口随机高位端口和目的端口53IP加上源IP和DNS服务器IP以太网封装后发出。因为单个DNS查询报文很小不需要可靠传输——如果丢了客户端直接超时重发就行这是UDP在这个场景下的经典选择。UDP和TCP的差异你在抓包里一眼就能看出来UDP头只有8字节没有序号、没有确认号、没有窗口丢不丢全靠上层自己负责。视频通话、实时游戏、DNS查询这类“能容忍少量丢包但不能容忍重传延迟”的场景UDP是更合适的载体。5.2 在一个抓包里读懂TCP/IP的全部协作我用tcpdump在Linux上抓过一次访问某个HTTP网站的过程核心几行大概是IP 192.168.1.100.54321 93.184.216.34.80: Flags [S], seq 1000 IP 93.184.216.34.80 192.168.1.100.54321: Flags [S.], seq 8000, ack 1001 IP 192.168.1.100.54321 93.184.216.34.80: Flags [.], ack 8001 IP 192.168.1.100.54321 93.184.216.34.80: Flags [P.], seq 1001:1201, ack 8001第一行客户端发SYN第二行服务器回SYNACK第三行握手完成。第四行客户端发送HTTP请求数据seq范围1001-1201一共发了200字节同时确认了服务器的8000。这里的[P.]表示带数据推送[.]表示纯ACK。等到服务器回包时IP 93.184.216.34.80 192.168.1.100.54321: Flags [P.], seq 8001:10001, ack 1201你看服务器的seq从8001开始发数据ack1201意味着“你的1001-1200我全收到了请从1201继续”。这一来一回序号、确认号、端口、IP全部协同起来了。5.3 三句话建立排查框架分层定位把前面所有内容落成一套可执行的排查方法我总结成三句话第一句ping不通先看链路和IP层。用ip addr确认本地配置用ping -c 3 网关IP切分内外网用traceroute看卡在哪一跳。第二句ping得通但TCP连不上重点看端口和状态。用ss -ant看目标端口是否有监听用telnet 目标IP 目标端口测连通性再看防火墙规则有没有放行。第三句TCP建立了但业务无响应问题大概率在应用层。这时候抓包看HTTP请求有没有到达服务端、响应有没有生成而不是再折腾传输层。6. 这些年踩过的TCP/IP坑一线实战排障记录6.1 TIME_WAIT堆积到端口耗尽有段时间我维护的一个高并发短连接服务频繁报错Cannot assign requested address一看就是本地端口被占满。用ss -s检查发现TIME_WAIT连接数以万计。原因是短连接场景下主动关闭方每次连接结束都要经历2MSL的TIME_WAIT端口在此期间被占用。最稳妥的解法不是调低TIME_WAIT而是改用长连接让连接复用起来。如果实在没办法改代码再考虑开启net.ipv4.tcp_tw_reuse让内核复用处于TIME_WAIT的连接同时配合开启TCP时间戳。这里要特别注意tcp_tw_recycle这个参数在NAT环境下容易导致丢包新的内核版本里已经移除了别再按老教程去开了。6.2 Nagle算法让你“变慢”的40毫秒我遇到过一个小包接口单次请求本身只有几十字节但每次都要白白等上40毫秒。原因是发送方开启了Nagle算法——当TCP连接里还有未确认的小包时后续小包会被攒住等之前的包确认了才一起发出去。这种“攒包”机制在实时交互场景里很致命。解法也简单程序里把TCP_NODELAY置1关闭Nagle算法让每个小包立即发出int flag 1; setsockopt(sockfd, IPPROTO_TCP, TCP_NODELAY, flag, sizeof(flag));代价是网络里可能多一些小包但在交互式应用里完全值得。这个优化在很多网络库源码里都能看到比如gRPC、Netty的某些配置项。6.3 MTU黑洞大包不通小包通还有一种疑难杂症小文件访问正常大文件下载卡死或超时。这多半是MTU黑洞。原理是这样的数据包经过某条MTU更小的链路时路由器本该通过ICMP消息通知源主机“这个包太大了请分片或减小”。但如果这个ICMP消息被中间网络过滤掉源主机就永远不知道要减小包尺寸只能反复重发大包全部石沉大海。排查时用ping -s 1472 目标IP测试不同包大小的连通性如果大包ping不通、小包能通基本就是MTU问题。治本的办法是调整链路MTU或者让路由器给通过它的TCP流量设置MSS钳制把TCP段大小限制在链路能承受的范围内。6.4 SYN队列溢出握手总是超时还有一个高频问题服务端在连接高峰时出现大量握手超时客户端开始疯狂重传SYN。这通常意味着SYN队列半连接队列溢出。服务端收到SYN后会先把这个半连接放进SYN队列等三次握手完成再移入accept队列等待应用调用accept()。队列是有上限的一旦占满新的SYN就会被直接丢弃。应用层处理不动、队列过短都会导致这个问题。我当时的处理顺序是先用ss -lnt看服务端有没有大量SYN_RECV堆积再确认应用是否来得及accept最后调整内核参数net.ipv4.tcp_max_syn_backlog和应用的backlog配置同时确保应用本身没有阻塞在耗时操作上。调参只是兜底很多所谓“SYN洪水”其实是应用层处理能力不足。把状态机、序号、窗口这几个东西吃透之后你会发现TCP/IP不再是需要死记硬背的抽象规则而是一套可以预测行为的系统。网络故障大多是某个机制被低估或者某个参数被忽略把这些机制的内在逻辑理解到位排障就没那么玄学了。