TCP/IP协议栈详解：从三次握手到Wireshark抓包实战

每天有数以亿计的数据包在全球的网络里穿梭，但绝大多数写代码的、做运维的、搞设计的，甚至包括一部分专职做网络的人，都说不清楚这些数据包到底是怎么从一台设备跑到另一台设备的。TCP/IP协议栈就是互联网通信的核心，它负责把数据拆分、封装、寻址、传输、再拼装还原，整个过程环环相扣。这篇文章我想抛开教科书式的讲法，用一组组真实可验证的场景，把这个协议栈的底层逻辑彻底掰开揉碎讲清楚，适合后端开发、网络工程师、运维同学，以及每一位想真正理解“上网到底在干什么”的读者。

从你在浏览器地址栏敲下一个网址、按下回车，到页面完整渲染出来，中间一般只有几百毫秒。但这几百毫秒里，你的设备其实完成了一整套极其复杂的协作：域名翻译成IP、建立连接、分段封装、传输确认、数据校验、连接关闭——这一整套动作，都建立在TCP/IP协议栈的四层结构之上。理解这套结构，不只是在应付面试，更是排查线上故障、优化网络性能的基本功。

1. 协议栈到底在解决一道什么题

1.1 从“互通”到“标准化”：协议栈的核心价值

互联网最牛的地方不在于“网”本身，而在于“互”。不同厂商生产的交换机、路由器，不同操作系统的电脑、手机，完全不同架构的服务器，凭什么能放在一起正常通信？答案只有一个：大家都遵守同一套规则。TCP/IP就是这套规则的名字，准确说，它不是单个协议，而是一个协议家族的统称。

这套规则要解决的核心矛盾其实很朴素——把不可靠的物理网络，包装成看起来还挺可靠的通信服务。物理线路上的电磁干扰、丢包、乱序、延迟，这些都是常态，但上层应用不想管这些破事。TCP/IP协议栈通过分层，把“物理链路上的不稳定”逐层消化掉，最后呈现给应用程序一个相对干净、可靠的通信通道。

为什么叫“栈”？因为数据在发送端要从上层往下层走，每一层都会给数据“套上一层衣服”（封装），在接收端再从下层往上层走，每层脱掉一件衣服（解封装）。一层叠着一层，跟栈的结构一模一样。

1.2 四层模型：每层只解决一个独立问题

TCP/IP协议栈按职责拆成四层，每一层只管自己的事，不用关心别的层怎么实现。怎么理解这件事？我习惯用寄快递来打比方：

这种分层最大的好处是“可替换性”。IP地址不够用了，网络层从IPv4换到IPv6，上层TCP和HTTP完全不用感知，下层网卡驱动也基本不关心；应用层从HTTP/1.1换到HTTP/2，传输层和网络层也无所谓。每一层内部发生变化，都不影响相邻层，这就是分层协议栈的生命力所在。

1.3 数据的封装与解封装：一次标准的“套娃”

一个HTTP请求从应用层出发时，本质上就是一段字符串。这段字符串交给TCP后，TCP会在前面加上20字节的TCP头部，包含源端口、目的端口、序列号、确认号、窗口大小、校验和等信息，这段数据此时叫TCP段。TCP段再往下交给IP层，IP层又加上20字节的IP头部，包含源IP、目的IP、TTL、协议号等字段，变成IP包。IP包交给以太网驱动后，再加上14字节的以太网头部（源MAC、目的MAC、类型）和4字节的校验尾部，变成一串比特流，通过网线或电磁波发出去。

接收端的工作刚好反过来，从网卡收到比特流后，以太网层先摘掉MAC头部和尾部，IP层再拆掉IP头部，TCP层再拆掉TCP头部，最后把原始那段字符串交给应用层。每一层只处理自己关心的头部，就像过安检时层层掏证件，掏完自己那层就把证件装回去，剩下的东西继续往下传。

理解了封装和解封装，后面所有关于抓包、排查网络问题的话题就都顺了。你在Wireshark里看到的一层层协议，其实就是这一层层的头部信息。

2. 传输层：TCP为什么能撑起“可靠”两个字

2.1 三次握手：为什么不多不少，正好三次

TCP面向连接，所谓“连接”，本质上是通信双方各自在内核里维护的一组状态信息，包括序列号、窗口大小、缓冲区状态。建立连接的过程，就是双方完成一次状态同步。三次握手的过程大家都很熟：

1. 客户端发送SYN报文，初始序列号设为x
2. 服务端收到后回复SYN+ACK报文，自己的初始序列号为y，确认号填x+1
3. 客户端再发ACK报文，确认号填y+1，连接建立

这里最值得琢磨的问题是：为什么非要三次，两次不行吗？这个问题我面试过很多人，能真正答透的不多。关键在于一个词——网络会滞留旧包。客户端之前发起过一条连接请求SYN，因为网络拥塞滞留了一段时间，现在姗姗来迟被服务端收到了。服务端这会如果直接回SYN+ACK并认为连接建立，就会白白给一个已经不需要的连接分配资源。但如果是三次握手，服务端发完SYN+ACK后会等客户端的ACK，这个“幽灵SYN”不会引发ACK响应，服务端自然就放弃了这条假连接。第三次握手本质上是让服务端确认：客户端确实是在响应我刚才那条SYN+ACK，而不是一个迟到的历史报文。

顺便说下随机初始序列号。Linux内核会为每个新连接生成一个随机化的ISN，而不是永远从0开始。这也是为了防止某个连接的旧报文段恰好被新连接当成有效数据接收。如果序列号固定可预测，攻击者就可以伪造合法报文，安全风险很大。

2.2 四次挥手：关闭连接为何比建立还复杂

TCP关闭连接不是一蹴而就的，标准流程是四次挥手：

1. 主动关闭方发送FIN报文，进入FIN_WAIT_1状态
2. 被动方收到FIN后回ACK，进入CLOSE_WAIT状态，主动方进入FIN_WAIT_2
3. 被动方把自己剩余的数据发完，然后发送FIN报文，进入LAST_ACK状态
4. 主动方收到FIN后回ACK，随后进入TIME_WAIT状态，等待2MSL后彻底关闭

四次的原因在于TCP是全双工的，数据可以双向同时流动。每个方向都需要单独关闭，A方向关闭需要一对FIN/ACK，B方向关闭又需要一对FIN/ACK，所以一共四次。这和打电话是一个道理：一方说“我说完了（FIN）”，对方说“知道了（ACK）”，但对方自己可能还有话说，等他讲完了也得说句“我也说完了（FIN）”，这边再回一句“知道了（ACK）”，通话才算真正结束。

TIME_WAIT是这个流程里最容易让人困惑的环节。主动关闭方在发送最后那个ACK后，并不会立刻关闭，而是进入TIME_WAIT并等待2MSL（最长报文段生存时间，通常为30秒到1分钟，2MSL约2到4分钟）。这个等待有两个目的：一是确保自己最后的ACK能到达对方，这个ACK一旦丢了，被动方会重新发送FIN，如果主动方已经关闭就会直接回RST，打乱被动方的状态机；二是让本次连接的报文段在网络中彻底消失，避免复用同一端口的新连接收到历史残留数据。TIME_WAIT是TCP可靠性的最后一道防线，删不得、省不得。

2.3 可靠传输的秘密：确认、重传、窗口与拥塞控制

TCP的可靠性不是靠“祈祷网络不丢包”实现的，而是靠一套完整的确认与重传机制。TCP给每一个字节都编上了序列号，接收方收到数据后，会返回一个确认号，表示“你发的数据我收到了，下一个我期待收到的字节是这个编号”。发送方如果在超时时间内没等到确认，就认为数据丢了，重新发送。这个超时时间（RTO）不是拍脑袋定的，而是根据网络往返时间RTT动态估算出来的，网络波动时会自动调整。

但每个包都等确认再发下一个，效率太低了。所以TCP引入了滑动窗口，允许发送方在未收到确认的情况下，连续发送一批数据。窗口大小由接收方的缓冲区剩余容量决定，接收方在ACK里通过窗口字段告诉发送方“我还有多少空间”。如果接收方处理不过来，窗口会收缩，甚至变成0，相当于对发送方说“你先别发了，我消化一下”。这就是流量控制。

拥塞控制则处理另一个问题：网络中间设备（如路由器）的转发能力是有限的，如果所有主机都不管不顾地猛发数据，网络会瞬间拥堵，丢包率飙升。TCP为此内置了慢启动、拥塞避免、快速重传、快速恢复四件事。慢启动的意思是连接刚开始时发送速率很保守，每收到一个ACK就翻倍增加发送量，直到达到阈值；出现丢包或者网络延迟增加时，发送速率会快速回落。这就像一个车队刚进高速公路时不会一脚油门到底，而是先试探路况，发现通畅再逐步提速。

2.4 TCP与UDP：一对性格相反的难兄难弟

传输层地位同等重要的还有UDP，但两者的设计哲学几乎是镜像的。TCP追求“可靠、有序、不会丢”，UDP追求“快、开销小、不管不顾”。我做个对比：

很多人觉得UDP一无是处，其实不对。实时视频通话、在线游戏这种场景，延迟比丢包可怕得多——丢几个画面帧没关系，但画面卡顿一两秒完全没法忍。UDP不做重传，报文丢了直接就显示一个模糊帧，体验反而更流畅。DNS查询和DHCP地址分配也大量使用UDP，因为这些请求本身很短，用TCP连接反而要多吃握手开销。有意思的是，HTTP/3底层就没用TCP，而是基于UDP实现了QUIC协议，自己补齐了可靠性和拥塞控制，换来了更低的连接建立延迟和更好的多路复用能力——这说明协议选择永远是trade-off。

3. 网络层：数据包怎么顺着地址找到彼此

3.1 IP地址：逻辑寻址的基石

传输层关心的是“哪个进程发给哪个进程”，网络层关心的则是“哪台机器发给哪台机器”。这里的主角是IP地址。IPv4地址是一个32位的二进制数，通常写成四组十进制数，比如192.168.1.10。IPv6则扩展到128位，地址空间大到可以给地球上每一粒沙子都分配好几个地址。

IP地址看起来平平无奇，但内部结构是有讲究的。它由网络号加主机号组成，网络号标识所在网段，主机号标识网段里的具体设备。子网掩码就是用来切分这两个部分的，比如255.255.255.0表示前24位是网络号，后8位是主机号，一个网段最多有254个可用主机地址。这就像快递地址里的“城市+街道+门牌号”，城市决定了包裹发往哪个中心局，门牌号决定了最后送进哪一户。

有一个有意思的问题：既然每台设备的网卡都有全球唯一的MAC地址，为什么不直接用MAC地址寻址，还要发明IP地址？原因在于MAC地址是扁平结构，彼此之间没有任何聚合关系，路由器拿到一长串MAC地址根本没法做路由汇总。IP地址是层级化的，路由器只需要记住网段级别的路由，就能把大量流量导向正确的方向，这是互联网能扩展到今天这个规模的前提。

3.2 路由：数据包是一跳一跳跳过去的

数据包从源机器到目标机器，通常不是直飞过去的，而是经过一个又一个路由器转发。每个路由器收到数据包后，查自己的路由表，决定“下一跳该交给谁”。路由表里记录的是目标网段、子网掩码、下一跳地址和出接口。这个查表转发的过程，很像你在一个陌生的城市里拿着地图问路：先问到一个主干道，再顺着主干道走到下一个路口，继续问下个人。你手里一直拿着的那个小纸条——目标地址——一直没变过，但每个路口的人指给你的方向都不一样。

有个细节值得单独拎出来：IP头里的TTL（生存时间）字段。每经过一个路由器，TTL减1，减到0就丢弃并给源地址回一个ICMP超时通知。这个设计的用途是防止数据包在环路拓扑里永远转圈圈，浪费网络资源。Traceroute工具正是利用这个机制来探测路径的：它先发一个TTL=1的包，第一个路由器会把它丢掉并回超时消息，记录下这个路由器的IP；再发TTL=2的包，第二个路由器响应；就这么逐个递增，把整条链路的路由器列表摸出来。做网络故障排查时，traceroute是定位“断在哪一节点”的利器。

3.3 ARP：从IP地址到MAC地址的“翻译官”

到这里有个隐患：IP地址解决了跨网络寻址的问题，但数据在同一个局域网内传输时，物理链路只认MAC地址。那么发送方怎么知道同一网段里目标设备的MAC地址？答案是ARP协议。某台设备要向同网段的目标发送数据时，先查自己的ARP缓存表，没有就去广播一个ARP请求：“谁是192.168.1.10？请把你的MAC地址告诉我。”目标设备收到后单播回复自己的MAC地址，发送方把对应关系缓存起来，下次直接使用。

为什么不让IP地址和MAC地址一一对应，直接写死？因为MAC地址是生产时烧录的，设备换了网卡MAC地址就变，用硬件地址做逻辑标识没法灵活组网。IP地址则是可以变化的逻辑标签，跟设备被分配在哪个网络密切相关。这种“逻辑地址管寻路、物理地址管交付”的分工，保证网络拓扑可以随时调整而不用换硬件。

说一下排查ARP问题时的常见现象：网络突然批量超时，ping某些IP通通失败，结果一看ARP缓存表里全是错误或者冲突记录。比如两台设备被配置了相同IP，ARP缓存表里就会反复收到冲突响应，流量一会儿去这台一会儿去那台，表现就是时好时坏。遇到这类诡异问题，在Windows上用arp -d清缓存，在Linux上用ip neigh flush all，通常能快速让异常恢复。

3.4 ICMP：网络层的“体检医生”

IP协议只负责尽力转发，本身不提供错误报告机制。数据包在传输路上被路由器丢弃了、TTL到期了、目标端口不可达了，这些信息谁来通知源端？ICMP就是干这个的。Ping命令最核心的就是ICMP回显请求和回显应答：源端发一个Type 8的报文出去，目标返回Type 0的应答，往返时间一目了然。ping不通但业务正常的情况也很常见，很多网络设备默认禁用了ICMP响应，所以最好不要把“ping不通”等同于“网络不通”。真正要验证某条TCP服务通不通，用telnet ip port或者nc -vz ip port去测试连接更靠谱。

4. 应用层：你的数据在这里“开口说话”

4.1 HTTP与HTTPS：浏览器和服务器之间的通用语言

应用层是距离使用者最近的一层，也是大多数人写代码时打交道的层次。HTTP协议定义了客户端怎么发起请求、服务器怎么返回响应。一个HTTP请求报文由请求行、请求头、空行和请求体四部分组成，请求行里包含方法（GET、POST、PUT、DELETE等）、路径和协议版本。请求头里则塞满了Host、User-Agent、Accept、Cookie这些元信息。响应报文的结构类似，状态行里的状态码含义每个人都应该熟：2xx表示成功，3xx表示重定向，4xx是客户端问题，5xx是服务端问题。

HTTPS则是在HTTP之下加了一层TLS/SSL加密。客户端和服务端在正式传输数据前先做一次TLS握手，协商出对称加密密钥，之后所有HTTP内容都在加密隧道里传输。为什么要加密？因为在网络上传输的数据会经过很多中间设备，明文HTTP等于把账号密码、个人信息直接摊在所有人面前。TLS握手还要校验服务器证书，防止你连到的是一个伪装的假服务器。可以说，没有HTTPS，现代互联网的电子商务、网银、社交一切皆不可用。

4.2 DNS：把域名翻译成IP的“电话簿”

机器之间通信要用IP地址，但人记不住一串数字。DNS的作用就是把人类友好的域名翻译成机器友好的IP。整个系统是一个全球分布式数据库，根域名服务器负责把请求引导到顶级域服务器，顶级域服务器再引导到权威服务器，最后这台权威服务器上有域名和IP的确切对应关系。

这个过程里有两个容易混淆的概念：递归查询和迭代查询。你的机器向本地DNS服务器发起的查询是递归查询——意思是“你帮我查到底，把最终结果给我”；而DNS服务器之间互相询问是迭代查询——意思是“我告诉你下一站去哪查，你自己接着跑”。为了提升效率，各级DNS服务器都会缓存记录，浏览器自己也有缓存，所以解析域名时很少真的走到根服务器。实际排查网站打不开问题时，第一件事往往就是确认这个域名当前到底解析到了哪个IP：用nslookup或dig命令，看看返回结果是否是你预期的地址。

4.3 DHCP：进入网络就能上网的隐形功臣

设备接入一个Wi-Fi或者插上网线后，网络能自动通，背后靠的是DHCP。新设备接入网络时会发送一个广播的DHCP Discover报文，网络里的DHCP服务器收到后，从地址池中挑一个空闲IP分配给它，回复DHCP Offer，设备再回DHCP Request确认要这个地址，服务器最终发DHCP Ack确认。整个过程只有四步，这就是为什么你打开手机连上Wi-Fi，基本不用手动配IP就能上网。

DHCP分配的IP是有租期的，默认可能是几小时到几天。租期过半时设备会自动发起续租，如果服务器没有响应，设备还会在租期快结束时再次请求。运维排查网络故障时，遇到过一半设备无法上网、另一半正常的情况，检查DHCP地址池就会发现池子已经满了，大量无效租约占着地址不放。这类问题一般通过调整租期策略、合理规划地址池范围来解决。

4.4 一次网页请求的完整旅程

把前面所有层次串起来，可以看一次完整访问经历了什么。以在浏览器输入一个网址为例：

• 浏览器解析URL，提取出域名
• 调用系统DNS解析接口，将域名换成IP地址
• 客户端随机选一个本地端口，向目标服务器的443端口发起TCP连接（三次握手）
• 连接建立后，走TLS握手协商加密参数
• 浏览器构造HTTP GET请求报文，通过加密隧道发送
• 服务器解析请求，返回HTTP响应，浏览器检查状态码和响应头
• 浏览器逐步解析HTML、CSS和JavaScript，期间会发起多个并行请求加载子资源
• 图片、脚本等资源全部加载完毕，页面渲染完成
• 空闲连接或通过四次挥手关闭

这一段旅程执行下来，每一层协议都在默默干活。最常见的故障也往往藏在某一层的某个细节里：DNS解析失败、TCP连接超时、TLS证书过期、HTTP响应太慢……排查问题时的基本功，就是能判断问题到底卡在了哪一层。

5. 实战视角：抓包分析与问题排查实录

5.1 用Wireshark亲手抓住三次握手

理论讲得再多，都不如自己抓一次包来得直观。Wireshark是最常用的图形化抓包工具，把网卡设成混杂模式，过滤器和过滤器表达式是所有网络排查的基本功。要看三次握手，过滤表达式可以这样写：

text复制tcp.flags.syn == 1

这条表达式会筛出所有TCP连接建立的SYN报文。如果你只关心某个IP的通信，再加一个条件：

text复制ip.addr == 172.16.1.10 && tcp.flags.syn == 1

抓包记录里通常能看到三个包按顺序出现：第一个是源端口随机的大端口号发往目的端口443，SYN标志位为1；第二个是服务器回的SYN+ACK；第三个是客户端发回的纯ACK。第一次看到这三兄弟时，大多数人会瞬间理解为什么叫“握手”。进一步还可以看TCP头的详细字段，里面序列号在数值上看着像随机数，那是内核随机生成的初始序列号；窗口大小字段可以看到双方协商的接收窗口；选项字段里则有MSS信息，代表双方都能接受的最大分段大小。

我自己排查“连接建立慢”问题时，常用的套路是在Wireshark里加一列“TCP Delta Time”，看三次握手每个包之间的间隔。如果SYN发出后隔了1秒才收到SYN+ACK，大概率是服务器端SYN队列满了或者被防火墙拦了一拍；如果SYN+ACK发出后迟迟收不到客户端ACK，则要怀疑客户端侧或者中间链路丢包了。这比在服务器上看日志定位问题快得多，因为抓包反映的是链路和内核的真实行为。

5.2 常见网络问题排查速查表

实际故障中问题常集中发生在几个点。我把自己踩过的坑整理成了一张排查速查表，每次遇到网络问题先按表格方向排查，能省下很多时间：

5.3 一个值得分享的MTU踩坑经历

有次线上环境出现非常邪门的问题：部分页面请求经常超时，但ping服务器却一直通。排查到后面，发现是MTU设置导致的IP分片丢失。MTU是网络接口能承载的最大报文长度，以太网通常为1500字节。当TCP报文加上IP头部超过这个值，IP层就会把数据包拆成多个分片传输。问题是很多网络设备对分片包的处理策略是直接丢弃，或者丢弃其中一部分分片。接收端等不到全部分片，整个包就只能超时丢弃，而ping用的是小包，不受MTU限制，所以ping是好的，但大数据包死活不通。

这个案例给我的教训是无条件的：网络排查永远不要预先假设“某层没问题”，尤其是不要因为“ping通了”就排除网络层以下的问题。用ping -s 1472这种命令测大包，用traceroute看每一跳的路径，用抓包确认分片情况，一步一步来，比乱猜高效得多。

我个人在实际操作中的体会是：TCP/IP协议栈的学习路径，一定是从理论到抓包、再从抓包回到理论的循环。只看书不抓包，很多状态机制永远记不住说得清；只抓包不看书，遇到诡异现象时又搞不清底层机制。最好是在一台自己可控的机器上，用Wireshark或者tcpdump把日常业务流量、登录过程、下载过程都抓一遍，对照协议文档逐字段看一遍。把这套流程走完，绝大多数网络问题在你眼里都不再是玄学，而是清清楚楚的层次逻辑。