最近一段时间一直在补网络基础把 TCP/IP 四层模型重新完整过了一遍。以前零零散散知道一点像三次握手、IP 地址、端口这些概念都能说上几句但真遇到线上问题比如访问慢、连接超时、抓包看不懂还是会发懵。这次复盘让我把很多碎片知识串起来了所以想整理一篇相对完整的总结既是对自己的梳理也希望能给正在学网络、或者工作几年但基础不牢的朋友一些参考。这篇内容主要围绕 TCP/IP 四层模型展开从设计思路、每一层的职责、一次完整请求的流动过程到用抓包工具验证理论最后再聊几个我踩过的坑。适合刚入门的学生、转后端或运维的开发者以及所有想系统捋一遍网络体系的人。1. 重新理解整体设计思路1.1 为什么 TCP/IP 四层模型才是事实标准大学教材里一般先讲 OSI 七层模型从物理层一路到应用层讲得特别细。但实际工作中大家讨论问题的时候几乎不会说“这层是 OSI 的会话层”而是直接说“这是应用层的事”“这是传输层的机制”“链路层丢包了”。原因很简单TCP/IP 四层模型是互联网真正跑起来的协议栈而 OSI 只是一个理论参考框架。四层模型的划分是链路层、网络层、传输层、应用层。有的教材会把链路层再拆成物理层和链路层变成五层模型本质差不多。我复盘时更倾向于用四层来理解因为物理层的介质网线、光纤、无线信号对上层来说是透明的真正需要我们去抓的是从数据帧开始的部分。这个模型强在哪核心是“分层”思想。每一层只负责自己那一摊事上层不需要关心底层是怎么把比特流传出去的底层也不需要理解上层的数据含义。就像公司里不同部门各司其职研发不直接跟客户沟通销售也不去写代码但整个流程能顺畅运转就是因为职责边界清晰。1.2 封装与对等通信是理解一切的钥匙整个 TCP/IP 模型有两个核心机制一个是封装另一个是对等通信。这两个概念如果不理解后面看抓包、排错、配置防火墙都会很吃力。封装指的是发送端从上往下每经过一层就加上该层的头部信息。应用层产生数据传输层加上端口号和序列号之类的 TCP 头部网络层加上源 IP 和目的 IP链路层加上源 MAC 和目的 MAC最后变成一串比特流传到物理介质上。接收端则反过来从下往上逐层剥掉头部最后把原始数据交给应用进程。对等通信的意思是虽然数据是层层传递的但逻辑上每一层只和对方的同层“对话”。比如浏览器发出的 HTTP 请求应用层只关心对端服务器的应用层是怎么响应的TCP 层只关心对方 TCP 层有没有正确收到数据。不需要跨层通信每一层都认为对面就是自己的“镜像”。我刚开始学的时候总觉得这东西抽象后来用了一个快递的类比才彻底想通。你寄一个包裹里面是你的商品快递单上写收件地址和寄件地址快递公司在外部贴运单号。包裹经过一个个中转站每个中转站只看运单号决定往哪儿送不会拆开你的商品。到了目的地收件人拆开快递盒拿出商品。这里商品是应用层数据快递单是 IP 头部运单号是 MAC 信息中转站是路由器。每一步都是“封装”和“解封装”的过程。2. 逐层拆解每一层到底干了什么2.1 链路层网线、交换机与邻居之间的通信链路层是整个模型的最底层负责在同一个物理网络内把数据从一台设备传输到另一台相邻设备。它的最小传输单元叫“帧”帧里最重要的两个字段就是源 MAC 地址和目的 MAC 地址。MAC 地址是网卡出厂时烧录的物理地址相当于这台设备在网络世界的“身份证号”。但 MAC 地址只在同一链路内有意义出了这个局域网就没人关心它了。交换机就是工作在链路层的设备它通过学习帧里的源 MAC 地址来维护一张 MAC 地址表然后根据目的 MAC 地址把数据帧从正确的端口转发出去。这里有一个关键协议必须提ARP地址解析协议。因为网络层用的是 IP 地址而链路层转发用的是 MAC 地址那么“谁有这个 IP 地址对应的 MAC 地址是什么”这个问题就得由 ARP 来解决。发送端会广播一个 ARP 请求“谁的 IP 是 192.168.1.1请告诉你的 MAC 地址。”目标设备收到后单播回复发送端把这个映射关系缓存下来下次直接用不用再广播。链路层的可靠性并不强帧尾部有个 FCS帧校验序列用来检测数据是否在传输中损坏但发现损坏后通常只是丢弃不会像 TCP 那样主动重传。这正好体现了“分层”的设计链路层追求的是快速转发可靠传输交给上层去处理。2.2 应用层HTTP、DNS 与所有业务的载体应用层是最靠近用户的一层直接为应用程序提供网络服务。浏览器访问网页用的 HTTP/HTTPS、解析域名用的 DNS、发送邮件用的 SMTP、传输文件用的 FTP全都属于应用层协议。应用层的核心特点有两个。第一它直接面向业务协议种类非常多因为不同的业务有不同的交互模式。HTTP 是请求-响应模式DNS 是查询-应答模式FTP 需要建立两条连接控制连接和数据连接甚至很多游戏公司会自己定制基于 UDP 的私有协议都是为了满足特定场景。第二应用层的数据是不关心“怎么传”的。 HTTP 请求内容、JSON 数据、图片流对 TCP 层来说就是一个字节序列TCP 不关心这些字节的含义只负责把它可靠地送到对端。这就是分层带来的好处业务归业务传输归传输。很多人会把“应用层”和“用户态程序”搞混其实不是一回事。应用层协议是程序通过网络通信时使用的“语言规范”而具体的程序浏览器、客户端、前端项目是遵循这些规范的实现者可以同时使用多种应用层协议。比如你在浏览器里输一个网址浏览器至少会用到 DNS 协议先做域名解析再用 HTTP 协议发起请求。2.3 网络层IP 地址、路由与跨网络寻址链路层解决了“局部网络内怎么传”那互联网这么大跨网络怎么传这就是网络层的工作。网络层的核心协议是 IPInternet Protocol它负责为每一台设备分配逻辑地址并根据目的 IP 地址决定数据包往哪个方向转发。IP 地址是一个逻辑地址和 MAC 地址最大的区别在于它是可以被规划和聚合的。IPv4 地址是 32 位分成网络部分和主机部分网络部分相同的主机在同一个网段。子网掩码就是用来划分这两个部分的比如 192.168.1.100/24表示前 24 位是网络部分后 8 位是主机部分。路由器是工作在网络层的设备它通过路由表来决定数据包的下一跳。路由表就像地图告诉你“去某个网段该走哪个接口”。当数据包到达路由器路由器会查询目的 IP 地址如果匹配到路由条目就按照条目指定的下一跳转发如果没有匹配就丢弃并返回一个 ICMP 消息比如“网络不可达”。这里有一个特别容易让人迷惑的点IP 地址是“端到端”的MAC 地址是“逐跳”的。什么意思呢一个数据包从杭州的机器发到北京的服务器目的 IP 始终不变除非做 NAT但每经过一个路由器MAC 地址都会改变。因为每一跳都发生在不同的链路上源和目的 MAC 都是这条链路的两个端点。抓包的时候经常能看到这种变化这也是理解网络层和链路层关系的关键。2.4 传输层端口、TCP 与 UDP传输层是四层模型里最“复杂”的一层也是排查问题最常交战的战场。它的核心任务是提供“端到端”的通信服务也就是从这台机器上的一个进程到那台机器上的一个进程。怎么标识进程靠端口号。IP 地址找到了主机端口号找到了主机上的具体应用。传输层有两个性质完全不同的协议TCP 和 UDP。TCP 是面向连接的、可靠的传输协议。它通过三次握手建立连接通过序列号、确认应答、超时重传、滑动窗口等一系列机制来保证数据不丢失、不重复、按序到达。代价是效率相对低且连接状态复杂。UDP 则是无连接的、不可靠的传输协议。它只管把数据报发出去不保证对端能收到也不保证顺序。但 UDP 头部只有 8 个字节延迟低、开销小非常适合实时音视频、DNS 查询、游戏数据传输这些能容忍少量丢失、但绝不允许重传延迟的场景。我实际操作中发现很多人对 TCP 的理解停留在“可靠”两个字上但面试或排错时一旦追问“TCP 是怎么实现可靠的”就只能答出“重传”和“三次握手”。实际上 TCP 的可靠是个系统性工程序列号每个字节都有一个编号接收方可以通过序列号判断有没有漏收数据再通过 ACK 告诉发送方“我收到哪了”。确认应答ACK接收方每收到数据都要回复确认发送方收到确认才知道数据已到达。超时重传如果发送方在指定时间内没有收到 ACK会认为数据丢失重新发送。流量控制接收方通过窗口字段告诉发送方“我的缓冲区还能收多少”防止发送太快把接收方压垮。拥塞控制发送方自己控制发包速率避免数据太多把网络链路堵死。这一整套机制才是 TCP 真正值钱的地方。UDP 一个都不占所以很多场景下虽然“不可靠”反而因为简单而更好用。3. 一次请求的完整旅程从输网址到看到页面3.1 第一步永远不是发 HTTP 请求很多人学完四层模型还是不知道每一层什么时候生效所以我拿“浏览器输入网址访问网站”这个场景串一遍。注意第一步绝对不是浏览器直接发出 HTTP 请求而是先解析域名。你输入 www.example.com浏览器会先查询这个域名对应的 IP 地址。查询顺序是浏览器缓存 - 操作系统 hosts 文件 - 本地 DNS 解析器 - 递归查询 DNS 服务器。每一级都有缓存就是为了减少重复解析的耗时。DNS 查询本身也是一次完整的网络通信你的机器向 DNS 服务器发出一个 UDP 报文DNS 标准查询其中 UDP 头部目的端口是 53IP 头部目的 IP 是 DNS 服务器地址链路层再根据网关的 MAC 地址把帧发出去。等拿到 www.example.com 的 IP 地址后浏览器才开始真正地向这个 IP 发起 TCP 连接。这里的“开始”也值得注意HTTP/1.1 默认开启了 Keep-Alive如果之前连接还在会直接复用不会每次都重新握手。3.2 三次握手建立连接的“双向确认”TCP 建立连接之前双方都不知道对方是否在线、是否愿意通信所以需要通过三次握手协商初始序列号并确认双方的收发能力都正常。我手头没有绘图工具用文字描述一下完整过程客户端发送一个 SYN 报文序列号假设为 x表示“我想和你建立连接”。服务端收到后如果同意就回复 SYN-ACK序列号为 y确认号为 x1表示“收到你的 SYN我也准备好了”。客户端再回复一个 ACK确认号为 y1表示“收到你的 SYN-ACK连接建立”。为什么要三次而不是两次因为三次握手能防止“已失效的连接请求突然又到达服务端”导致资源浪费。如果只有两次握手服务端收到一个延迟到达的旧 SYN 就会误以为是新连接从而建立一条无效连接并分配资源三次握手可以让服务端确认客户端确实收到自己的响应因为第三次 ACK 必须由客户端发出。抓包验证时这三步的标记非常直观第一次是 SYN第二次是 SYNACK第三次是 ACK。我自己比较喜欢用 Wireshark 看这个顺序比看任何流程图都清晰。3.3 数据发送HTTP 请求的封装和逐层套娃连接建立后浏览器开始构造 HTTP 请求内容比如 GET /index.html HTTP/1.1然后加上 Host、User-Agent 等头部信息。到了这一步应用层的工作就算完成了剩下的交给下面的层。传输层拿到 HTTP 数据后会把整段数据作为 TCP 的负载加上一个 TCP 头部。头部里有源端口浏览器随机分配的端口比如 51234和目的端口服务器 80/443还有序列号、确认号、窗口大小等。然后这段数据被交给网络层。网络层加上一个 IP 头部源 IP 是你本机的 IP目的 IP 是 www.example.com 解析出来的 IP。然后交给链路层。链路层要填充 MAC 头部和帧校验。注意这里的源 MAC 是本机网卡的地址目的 MAC 是什么如果目标服务器不在同一个局域网这个目的 MAC 就是“默认网关”的 MAC 地址。因为本机根本不知道服务器的 MAC也不需要通过 ARP 去查——查了也查不到数据包必须交给网关路由器才能出网。这是很多初学者容易踩坑的地方拿抓包工具看目的 MAC发现不是服务器地址其实是网关地址这是正常的。3.4 网络设备的逐跳转发与接收端解封装数据帧离开本机后最先到达的是接入层交换机。交换机只看 MAC 头根据目的 MAC 地址查询自己的 MAC 地址表发现该 MAC 对应某个端口就直接转发出去。如果查不到就会泛洪给除接收端口以外的所有端口让目标设备回应后再记录。数据一旦到达路由器网关路由器会剥掉链路层的帧头和帧尾取出里面的 IP 数据包然后查询路由表。路径上的每一台路由器都只负责“把数据包往下一跳发”不会修改源和目的 IP除了 NAT 场景但会把源和目的 MAC 重新封装成下一跳链路所需的地址。这个过程叫“逐跳转发”。当数据包到达目标服务器所在的网络后服务器的网卡收到帧逐层解封装链路层剥掉 MAC 头网络层剥掉 IP 头传输层检查 TCP 头部并处理确认号、窗口等信息然后应用层拿到完整的 HTTP 请求交给后端的 Web 服务处理。服务端处理完再按同样的方式把响应封装并通过原路径返回。等浏览器收到完整的 HTTP 响应渲染出页面这才算一次完整的请求闭环。4. 用 Wireshark 把四层模型“看”一遍4.1 为什么要用抓包来辅助学习说实话只看协议文档永远记不牢。我真正对四层模型形成清晰认知是在自己电脑上抓包观察之后。抓包工具能把每一层实际添加的头部和内容完整展示出来相当于把黑盒打开给你看。Windows 用的比较多的是 WiresharkmacOS 上也可以直接安装命令行版本Windows 下也可以用 npcap 驱动。我复盘的时候做法很简单先抓一个访问 www.baidu.com 的包然后对着四层模型逐层找字段。这样学一次比看十遍书都管用。抓包要注意一点如果抓的是 HTTPS 流量应用层内容基本都是加密的看不到明文 HTTP 头部只能看到 TSL 握手的记录。想看完整的应用层内容可以抓 HTTP 站点或者本地起一个简单的 HTTP 服务。4.2 在抓包里定位三次握手和四次挥手打开 Wireshark访问一个 HTTP 网站然后停止抓包在过滤器里输入 tcp.port 80。你真能看到清晰的 SYN、SYN-ACK、ACK 三个报文逐个点开看SYN 报文里TCP 头部有一个 Flags 字段SYN 位被置为 1Sequence Number 显示为一个随机初始值比如 123456789。SYN-ACK 报文的 Flags 里SYN 和 ACK 都为 1Sequence Number 是服务器端的初始值Acknowledgment Number 是客户端初始值加 1。最后的 ACK 报文里只有 ACK 位为 1Acknowledgment Number 是服务器初始值加 1。四次挥手也值得抓一次看看。关闭一个 TCP 连接时主动关闭方发送 FIN被动方回复 ACK然后被动方发送 FIN最终主动方再回复 ACK。这里你可能会看到 FIN 报文和 ACK 报文经常粘在一起因为 TCP 允许合并发送实际抓包时经常只看到三个报文而不是四个。还有一个很有价值的观察点你可以在抓包里看到 TCP 的“延迟 ACK”和“快速重传”等行为。比如你故意在一个丢包率较高的网络环境中下载文件就能看到大量重传标记Wireshark 还专门用不同的颜色标记乱序包和重传包。4.3 用抓包反向验证自己对层的理解我复盘时列了一个“应知应会”的清单每看完一个协议就尝试对号入座帧里的源 MAC 是不是本机 MAC目的 MAC 是不是网关 MACIP 头里的 TTL 字段是多少有没有因为跨路由发生变化TCP 头部里的窗口大小在接收过程中会不会动态变化HTTP 响应的 Content-Length 和数据包的实际传输分段有什么关系这些问题一开始很多答不上来但抓包后一个个对照着看很快就懂了。这种“带着问题抓包”的方式比漫无目的地盯着报文列表要高效得多。5. 学习过程中的高频误区和排错心得5.1 几个特别容易绕进去的常见误区第一个误区是把 IP 和 MAC 混为一谈。IP 地址是可以变化的逻辑地址MAC 地址基本固定是物理属性IP 负责跨网络寻址MAC 负责同一链路内传输。排查问题时如果数据包到了同一交换机下的另一台主机但收不到先查 MAC 表而不是 IP 表。第二个误区是混淆“端口”和“接口”。TCP/UDP 的端口号是软件层面的抽象用于区分同一主机上的不同进程而路由器、交换机上的“接口”是物理或虚拟的网络口。说“端口被占用”是 TCP 端口被进程占用说“接口 down 了”是设备接口出问题了两个完全不是一回事。第三个误区是认为路由器只做路由交换机只做交换。现代设备早就“跨界”了三层交换机可以配置 VLAN 接口并执行路由决策家用路由器本质上就是“路由器交换机无线 AP”的组合体。学习时可以先从纯功能的视角理解但实际排错时一定要看设备具体配置了哪些功能。第四个误区是忽视 NAT 的影响。现在绝大多数家用和办公网络都靠 NAT 把私有 IP 映射成公网 IP这就导致了一个重要影响内网访问外网时源 IP 会发生变化如果你在内网架设一个只能在内网访问的服务外部设备无法建立主动连接。很多初学者在自己电脑上起了服务手机连同一个 Wi-Fi 却访问不了第一反应是代码问题其实往往是 NAT 和防火墙问题。5.2 常见故障排查速查表在学习复盘过程中我把平时工作中遇到最多的几类现象整理成了一个表格方便快速定位问题现象可能原因排查方法浏览器提示“无法访问此网站”DNS 解析失败 / 网络未连接ping 网关、nslookup 域名能 ping 通 IP但访问不了服务端口未监听 / 防火墙拦截telnet IP 端口、netstat -an偶尔超时丢包严重无线信号不稳定 / 中继设备拥塞ping -f 检测丢包、查看信号强度同一个局域网内访问很慢交换机环路 / ARP 攻击查看交换机端口统计、arp -a抓包有数据但应用层收不到防火墙拦截 / 进程绑定错误地址tcpdump 抓包确认、检查监听地址能访问外网但无法访问内网特定服务路由配置缺失 / 安全策略tracert 路径、检查路由表这个表不是万能的但可以帮你形成一个基本思路从链路层开始逐层检查而不是一上来就怀疑应用层代码。5.3 复盘之后我觉得值得保留的几个习惯这套模型学完之后我养成了几个习惯分享给大家参考。第一排查网络问题前先在脑子里过一遍四层模型问自己“这个问题可能出现在哪一层”。如果是网页打不开而且好几台设备都不行大概率在网络层或链路层如果只有一台设备不行要重点看应用层和传输层。第二尽量少用“ping 通了就说明网络没问题”来下结论。 ping 使用的是 ICMP 协议它通过不代表 TCP 端口通、服务正常。还得亲自试一下端口用 telnet、nc 或者 SSH 连接测试。很多线上事故就是因为 ICMP 通了就掉以轻心结果发现业务端口已经卡死。第三抓包是个宝别怕分析。任何时候遇到说不清的网络问题抓一份包再说话。无论是自己本机还是生产环境条件允许的话抓包数据总比猜测可靠得多。6. 复盘后的几点心得6.1 从“背概念”到“推导行为”以前学 TCP/IP 四层模型背得滚瓜烂熟但都是概念。真正让我觉得学会了的是能从模型推导出一些行为。比如 TCP 的三次握手不是死记硬背“SYN、SYN-ACK、ACK”而是能理解为什么需要三次。因为“双方都得确认自己和对方的收发能力都正常”这是信息论里最简单的确认机制少一次都不够。如果再往深一层想如果网络环境里大量出现重复 SYN那可能是有恶意扫描也可能是客户端超时重传排查时思路就不一样了。6.2 建议的学习路径如果你也想把四层模型吃透我的建议顺序是先看懂一个最核心的场景——“浏览器访问网站”的完整流程把每一步和四层模型对应上。然后逐层深入推荐的学习顺序是链路层 ARP、网络层 IP、传输层 TCP最后应用层协议。每一层都配合 Wireshark 抓包验证不要只看书。最后找一份“故障排查题集”或者干脆在自己电脑上故意制造一些问题比如关闭一个服务的端口、模拟 IP 地址冲突然后用四层模型的思路去定位。6.3 最后一个小技巧最后分享一个实操中用得非常多的小技巧排查连通性时先 ping 网关再 ping 公网 IP比如 114.114.114.114再 nslookup 一个域名。如果 ping 网关通、公网 IP 不通问题大概率在路由器或运营商链路如果公网 IP 通但域名不通问题在 DNS。这套顺序本质上就是在沿着四层模型逐层向上排查链路层通、网络层通、应用层解析不通每一步对应一层。这次复盘前前后后花了不少时间但收获很大。网络不像写业务代码问题藏得深现象和原因往往隔了好几层。把四层模型吃透等于给自己配了一张“地图”以后遇到任何网络相关的怪问题至少知道往哪个方向挖。希望这篇复盘也能帮你把零散的知识串成体系。