你会不会在某一个瞬间突然好奇按下回车之后网页里的那些文字和图片到底是怎么跑到你屏幕上的答案绕不开一套已经运行了几十年的机制——TCP/IP协议。它被称为网络基础中的基础而理解它最常用的入口就是四层结构。这篇文章没有什么吓人的架子目的是让你看完之后能在脑子里建起一张地图哪一层负责什么数据怎么一层层往下封装、再一层层往上解开以及当网络出问题时该从哪一层开始查。不管你是刚接触网络的学生还是工作几年想补基础的开发者又或者是被各种协议报错折腾过的运维都能在这里找到一条清楚的线索。TCP/IP不是“一个”协议而是一组协议的总称。它从底层到上层分工形成一整套可以协同工作的协议栈。我把这些年跟网络打交道的心得按四层模型的顺序拆开讲。你不需要一次全记住重要的是先摸清每一层的职责边界剩下的字段、状态、命令都是在这个框架上长出来的枝叶。1. 为什么网络要分层用一个寄快递的场景把四层串起来1.1 寄包裹的类比每一层解决一个具体问题我第一次接触网络分层时觉得这东西很抽象。后来发现一个特别管用的类比寄快递。你写了一封信这封信要交给快递员。快递员不看信的内容只看信封上的收件人姓名和电话确保“给到具体的人”——这就类似传输层的端口号解决的是“数据要交给机器上的哪个进程”。信封填好后快递网点根据地址判断应该把包裹发往哪个城市再交给长途运输线路——这就类似网际层的IP地址和路由选择解决的是“数据要去哪台机器”。最后快递小货车在街道上按门牌号一件件投递——这就类似网络接口层的MAC地址和物理链路解决的是“在一条具体的线路上怎么把数据送出去”。而信纸上写的那些文字就是应用层真正关心的内容。这个类比虽然不完全严谨但足以让你记住四层各自的价值应用层管“用户要什么”传输层管“交给哪个进程”网际层管“去哪台主机”网络接口层管“怎么沿链路送出去”。1.2 不分层会怎样一次就能尝到苦头假设没有分层或者所有功能都混在一层里会出现什么情况最直接的影响是每出现一种新的应用就得把数据可靠传输、路由寻找、物理信号调制这些事情全部重写一遍。你写一个聊天软件要把丢包重传、IP寻址、网卡驱动都自己处理一遍换一种物理线路比如从网线换成光纤所有应用又得跟着改。分层最重要价值是让每一层只和相邻层打交道彼此独立演化。你家里宽带从旧线路升级到光纤浏览器和服务器软件不需要跟着换你在应用层从HTTP切换到新的接口协议底层路由器也不需要明白你传输的具体内容。这就是为什么今天任何一个应用都能复用电…不是都能复用同一套网络基础设施。用技术词汇说发送方从上往下走的过程叫“封装”每一层都把上一层的数据当作“载荷”再加上本层的头部信息接收方从下往上走的过程叫“解封装”逐层剥掉头部最终把原始数据交给应用。整个TCP/IP协议族的运转都建立在这个最基本的动作之上。2. 四层结构逐层拆解每一层到底解决什么问题2.1 网络接口层从比特到信号再回到比特四层模型里最下面的一层叫法很多网络接口层、链路层、主机到网络层。它负责把数据转换成能在物理介质上传输的信号也负责在同一段链路内让相邻设备之间能认出对方。这一层包含两个块一部分是物理层的事比如网线上的电压、光纤里的光脉冲、无线信号里的调制方式另一部分是数据链路层的事比如以太网帧的格式、MAC地址的寻址。平时你看到的“Wi-Fi信号满格但访问不了网络”“网线插上没反应”绝大多数问题都出在这一层。这里需要提一下ARP协议。严格说IP数据报要发出之前发送方得知道下一跳设备的MAC地址这个“把IP地址翻译成MAC地址”的活儿通常由ARP完成。经典的教科书会把ARP放在网络接口层附近因为它只工作在同一个链路范围内和负责跨网络寻址的IP层逻辑不一样。面试时有人纠结ARP到底算哪一层我觉得不必死抠关键是理解它解决的场景同一条链路里怎么找到对方的物理地址。2.2 网际层IP地址、路由选择和“尽力而为”四层模型的第三层是网际层也有人叫网络层。它是整个互联网的基石解决的问题是我在这个地方目标在另一个地方数据到底应该怎么走。网际层通过IP地址建立了一套全局统一的逻辑地址体系。你电脑上的网卡、服务器、手机只要接入了网络就会有至少一个IP地址。有了这个地址路由器才能做转发决策。路由器不看你在浏览器里打开了哪个网站它只看数据报里的目标IP然后根据路由表决定下一步把数据送到哪个接口。这就是“路由选择”。这一层还会给数据加上一些控制信息比如TTL存活时间每经过一个路由器TTL就减一减到零还不达目的地就丢弃防止数据包在网络里无限循环。IP头部里还有一个“协议字段”用来告诉接收方这个IP包里面装的是TCP数据还是UDP数据。IP层的特点是“尽力而为”它会尽量把数据送到目的地但不承诺不丢包、不重复、不按序。真正负责可靠传输的是上一层——传输层。2.3 传输层端口、可靠传输和两种哲学网际层把数据送到了“某台主机”但一台服务器上同时跑着几十上百个进程网页服务、邮件服务、数据库服务……到底该把数据交给谁传输层用端口号解决了这个问题。端口号可以理解成“进程在主机里的门牌号”。浏览器发起请求时会随机挑一个临时端口作为源端口目标端口则是事先约定好的比如HTTP默认80、HTTPS默认443、DNS查询默认53。有了IP加端口一个连接就能唯一定位到“某台机器上的某个进程”。传输层有两个代表性协议风格完全不同。TCP提供的是可靠的、面向连接的字节流传输。它会先建立连接数据发送后等待确认没收到确认就重传还会调节发送速度避免太块压垮接收方——注意是“太快”我打错了实际是“太快”。TCP做这一大堆事情换来的代价是复杂度高、头部开销大、有握手延迟。UDP则干脆得多不建立连接不确认不重传就是尽可能快地把数据丢出去。它适合那些“宁可丢一小段也不愿意等重传”的场景比如实时语音、视频通话、游戏同步很多基础的DNS查询也走UDP因为快。我们平时说“TCP/IP协议”其实是把这一整族协议打包在一起叫了并不是只有TCP和IP这两个协议。2.4 应用层用户真正看得见的那一层四层模型的最顶层是应用层HTTP、HTTPS、DNS、FTP、SSH、SMTP这些大家挂在嘴边的协议都在这层。它们定义的是“数据长成什么样、交互流程怎么走”。举个例子浏览器向服务器发起一次访问最典型的HTTP请求报文会包含请求方法、请求路径、协议版本以及一堆头部字段。服务器收到后返回状态码和响应体。这个“一问一答”的形式就是应用层协议规定的。DNS也属于应用层它解决的是“域名到IP的映射”。你在地址栏里输入一个域名系统会先通过DNS把域名解析成IP再去建立连接。需要强调一点应用层不关心数据怎么变成电信号也不关心选路只关心数据内容和交互语义。写网页的人不需要懂路由算法这就是分层带来的自由。3. 一次网页请求的四层历险从敲下回车到页面出现3.1 封装每一层都往上贴一个“快递单”理论说完了我们跟着一次真实的网页请求看看数据怎么在四层之间流转。假设你在浏览器输入了一个网址按下回车。实际场景里第一步往往是DNS解析。浏览器要把域名换成IP这个查询报文本身也要走一次完整的封装DNS是应用层默认通过UDP发送UDP头加上源端口和目标端口IP头加上本机IP和目标服务器IP最后一层交给网卡通过网线或者无线发出去。也就是说一个你看不见的DNS查询背后已经跑了一遍四层。拿到IP之后浏览器开始发HTTP请求。这个过程在发送方是这样的应用层生成HTTP请求报文内容包含请求行、头部和请求体。传输层选择TCP分配一个临时源端口填上目标端口加上序号、确认号把HTTP报文当作载荷装进一个TCP段里。网际层接住TCP段填上源IP和目标IP加上TTL等字段变成IP数据报然后查路由表决定下一跳该发给谁。网络接口层通过ARP拿到下一跳设备的MAC地址把整个IP数据报放进以太网帧里加上源MAC、目标MAC最后变成比特流发出去。每一层都相当于往上贴了一张“快递单”不同的是快递单上写的地址类型不一样。这里有一张简表把不同层的数据形态和关键标识串起来层级数据形态关键标识典型设备/对象应用层HTTP报文、DNS报文URL、域名浏览器、服务器进程传输层TCP段 / UDP数据报端口号防火墙、负载均衡设备网际层IP数据报IP地址路由器网络接口层以太网帧、无线帧MAC地址网卡、交换机3.2 连接建立三次握手到底在握什么TCP要传输数据前先要“握手”也就是三次报文交换客户端发SYN服务器回SYNACK客户端再回ACK。很多人背过这个过程却未必明白它为什么非要三次。三次握手的本质是让双方都确认两件事对方能收到我的消息我也能收到对方的消息。第一次SYN让服务器知道客户端想建立连接第二次SYNACK让客户端知道服务器收到了同时客户端也确认自己能收到服务器的消息第三次ACK让服务器确认客户端确实收到了自己的回应。如果你只握两次手可能出现一种情况网络上有一个迟到的旧连接请求服务器误以为这是新连接于是建立了一个本不该存在的连接白白占用资源。三次握手能降低这种“历史请求干扰”的概率。我实际调试时经常用这个知识点去判断故障如果客户端发SYN之后一直没收到SYNACK问题大多在服务器不监听端口、防火墙拦截或者服务器负载过高如果SYNACK发出去了但第三次ACK没到就要去查两端之间的丢包或连接状态。看到“connect超时”和“connection refused”是两种完全不同的问题根源就在握手的哪一步失败。3.3 跨网络送达IP地址相对不变MAC地址一直在变数据从你的电脑发出去之后第一跳通常是家里的网关路由器。在你和网关之间通信靠的是MAC地址出了网关之后每一台路由器会根据IP头部里的目标IP决定下一步转发到哪。很有意思的一点是数据在整个传输过程中源IP和目标IP基本不变但是经过每一跳帧头里的源MAC和目标MAC都会重新改写。链路层解决的是“这一段路上怎么送”网际层解决的是“整个路网里怎么走”。这个区别在抓包时特别明显你抓到的包目标MAC往往不是你最终服务器的地址而是网关的MAC。如果你不理解这一点看到报文里的地址不匹配很容易误判。服务器收到数据后会做和发送方相反的拆解工作网卡收到帧、剥掉帧头发现IP目标是自己、剥掉IP头再根据TCP头里的端口号把数据交给对应进程。服务器进程读完HTTP请求再按照同样流程把响应发回来。你看到的那个网页就是这四层机制来回运转的结果。4. 遇到网络问题按四层模型一层一层排除4.1 先定界再定位不同症状指向不同层这些年排障我最深的感受是网络问题最怕“乱猜”。与其一次尝试多个方向不如先把问题定到某一层再在这一层里面深挖。四层模型本身就是一张极好的排查地图。我常用“自下而上”的顺序先看网络接口层再看网际层接着看传输层最后看应用层。因为底层不通上层一定不通底层通问题才可能在上层。遇到具体现象时可以做一个初筛现象最先怀疑层检查方向Wi-Fi有信号但完全上不了网网络接口层网卡状态、网关链路、线缆/无线信号能上内网但上不了外网网际层网关路由、IP配置、DNS归属能Ping通IP但不能访问网页应用层DNS/HTTP域名解析、服务端口、Web日志能Ping通IP但目标端口连不上传输层服务监听状态、防火墙、端口是否被占首页正常但大附件上传卡死网际层网络接口层MTU、分片、中间链路限制这个表不是绝对的但它能帮你快速锁定排查范围避免一上来就抓包从头到尾瞎看。4.2 常用工具和四层模型的对应关系排查工具里每一个命令其实都有自己的“所属层”。你要做的不是背命令而是知道每个命令是在验证哪一层的哪个问题。ip addr、ifconfig看网络接口层检查网卡是否up、IP和MAC是否正确。ping基于ICMP主要验证网际层的连通性顺带检查丢包和延迟。traceroute/tracert同样基于ICMP或者UDP看数据包经过哪些路由节点定位是靠近本端还是靠近远端的问题。nslookup/dig验证应用层的DNS解析查域名到底解析成哪个IP。netstat看传输层的端口监听和连接状态。nc/telnet直接测试某个IP端口的连通性快速区分“端口问题”和“应用问题”。curl验证应用层的HTTP交互能看到状态码、响应头和页面内容。抓包工具可以同时看到四层报文的全部细节适合前面几步定位不到根因的时候用。举一个组合排查的例子比如“网页打不开”# u先确认本机接口和IP ip addr # 看网关通不通 ping 网关地址 # 看域名能不能解析 nslookup 你访问的域名 # 看目标IP通不通 ping 目标IP # 看目标端口通不通 nc -vz 目标IP 443 # 如果以上都通再用curl看HTTP层反馈 curl -I https://你访问的域名这套流程走下来问题基本能定位到某一层。多数“打不开”的最终原因要么是DNS解析坏了要么是目标端口没监听要么是中间路由断了很少会有四层同时故障的“太巧合”情况。4.3 一个真实案例大文件传不上去小包却完全正常以前维护一个内部系统时遇到过一个让所有人头疼的问题系统里在线查看小页面、小图片都没问题但只要上传几十MB的文件进度到一半就会卡住最后失败换一台电脑也一样看起来非常随机。我当时的排查链路是这样的先查应用层和服务端日志没有任何报错再看传输层连接能正常建立握手没问题。接着用ping测目标服务器小包完全正常延迟和丢包都很低。到这里多数人会认为网络没问题去看应用代码。但问题有一个关键特征小文件能传大文件必卡。这个特征让我把注意力转向了网际层和网络接口层交界处的MTU问题。我用增大ICMP报文长度、同时设置不允许分片的方式去试探发现报文长度超过某个值之后目标就不回应了持续的更大报文则直接超时。再抓包看才发现问题出在中间某段链路的MTU比常规的1500更小大报文到了那里被丢弃。而按IP分片的正常流程这个设备应该回一个“需要分片”的ICMP消息给发送方但中间有人把这类ICMP消息过滤掉了发送方根本不知道自己的包太大就一直重发表现就是卡死在半路。解决办法也很直接把本机和服务器之间相关接口的MTU从默认值调低让两端实际协商出一个更小的报文上限再重试大文件上传稳定跑通了。这个小案例说明两件事第一“小包正常、大包异常”时要优先怀疑MTU和分片问题而不是怀疑应用代码第二抓包看到的往往只是表面现象能不能把报文和各层机制对起来才是排障的关键。后面我会专门展开一下MTU这个容易被忽略的细节。5. 几个容易栽跟头的细节端口、MTU和常见模型之争5.1 端口号与“四元组”很多人知道端口号但说不清端口号是怎么划分的。端口号的取值范围是0到65535其中0到1023是知名端口由常见的应用协议固定占用1024到49151是登记端口很多服务会用这一段49152到65535是动态端口客户端发起连接时通常从这里随机挑一个作为源端口。这里有个容易搞混的地方一个连接并不是由“目标IP目标端口”唯一确定的而是由四个要素组成——源IP、源端口、目标IP、目标端口它们合起来叫四元组。所以同一台服务器上的同一个端口可以同时为成百上千个客户端连接服务因为每个连接的源IP和源端口不一样。这也是防火墙规则和负载均衡策略经常基于四元组来做判断的原因。5.2 MTU、MSS与IP分片MTU最大传输单元指的是网络接口层一次能发送的最大载荷长度。最常见的以太网MTU是1500字节。如果一个IP数据报超过这个长度发送方就面临两个选择让IP层把数据报拆成多个分片或者让上层从一开始就别把它发送那么大。TCP其实很聪明。双方建立连接时会协商一个MSS最大报文段长度通常设为“MTU减掉IP头20字节再减掉TCP头20字节”也就是1460字节。这样一来正常情况下TCP段就不会超过路径上能够承载的尺寸根本不需要IP分片。IP分片本身开销高而且有风险只要一个分片丢了整个数据报都没法重组成功。所以现代网络更倾向于用“发现路径MTU”的方式让发送方先探明整条路径上最小的MTU再按这个限制发送。探明的方法是设置IP头的DF位禁止分片如果中间某个设备发现报文太长就返回一个ICMP消息告诉发送方“需要分片但你不让分片”。这类机制和四层模型的关系是很多人忽略的传输层要考虑网络接口层的能力。我在前面那个大文件案例里遇到的就是“路径MTU发现”依赖的ICMP消息被过滤导致发送方不知道应该减小报文尺寸。所以你在排查“某个连接小流量正常、大流量中断”时可以重点看一下两端接口MTU、中间链路是否有封装额外开销、以及ICMP消息是否被拦截。5.3 四层、五层、七层模型到底怎么对应你可能还听过开发系统互连参考模型OSI的七层概念应用层、表示层、会话层、传输层、网络层、数据链路层、物理层。TCP/IP的四层模型实际上是把OSI中上三层合并成了应用层把数据链路层和物理层合并成了网络接口层。对应关系大致是OSI七层TCP/IP四层应用层、表示层、会话层应用层传输层传输层网络层网际层数据链路层、物理层网络接口层有些教材为了讲清楚链路层内部结构会把网络接口层再拆成“数据链路层”和“物理层”变成五层模型。这三种表达在不同场景里都有人用不用纠结谁对谁错关键是知道它们描述的边界有什么异同。真正日常工作中更常见的说法是“L4”和“L7”。比如某些负载均衡设备L4模式只看IP和端口转发L7模式能看到HTTP里的URL、请求头再决定转发到哪台服务器。理解四层模型之后这两个词对你来说就不再是黑话了。6. 自己动手用几个小实验把四层模型刻进脑子6.1 实验一抓一次包亲眼看看四层头部纸上谈兵再多不如抓一次包。先在命令行里启动抓包工具监听本机的某个网络接口过滤目标端口为80或443的流量tcpdump -i eth0 tcp port 443 -c 30然后打开一个网站让流量产生。抓到的数据会同时展示底层以太网头部里的MAC地址紧接着IP头部里的源IP和目标IP再往上是TCP头部里的端口号和序号最后才是应用层的内容。看的时候别急着全看懂按层折叠着看。你会发现应用层的数据在报文最里面每一层头部的长度基本固定这和“封装”概念完全对上。如果你能看到请求的TCP握手正好观察三次握手里的SYN、SYNACK、ACK三个报文。6.2 实验二用traceroute看数据包逐跳路径执行traceroute 目标IP不同系统命令名可能不一样有些叫tracert它会显示数据包从本机出发经过了多少个路由节点到达目标。它的原理是IP头部里的TTL每经过一个路由器就减1减到0时路由器会把包丢弃并回一个ICMP超时消息。traceroute从TTL1开始逐步增加TTL让沿途每个路由器都“暴露”自己从而把整条路径摸出来。做这个实验时你会发现有些节点显示星号这通常是设备出于安全策略不回应ICMP消息不代表路由一定断了。判断网络路径是否异常不能只看某一个星号要看整体趋势和最终目标是否可达。6.3 实验三用netstat观察连接状态在终端里执行netstat -anp | grep 443你会看到一堆连接状态包括监听状态LISTEN、已建立连接状态ESTABLISHED、正在等待关闭的状态TIME_WAIT。这些状态对应着TCP连接建立和断开的完整生命周期。其中TIME_WAIT是主动断开方在连接结束后等待一段时间、同时清理残留报文的状态。当你看到大量TIME_WAIT时说明这个端主动建立了大量短连接这是线上系统里非常常见的情况。理解了传输层状态机你再去看各种监控指标就不会被一堆缩写吓到。6.4 我个人的学习顺序建议如果你想系统补网络基础我建议的顺序是先把四层职责背熟再抓包看一次真实请求接着跟着排一次故障。不要为了面试去硬背端口号和状态码而是去记“每一层在问什么、靠什么回答、出错会有什么现象”。比如看到“连接超时”先想传输层握手哪一步没完成看到“小包正常大包卡”先想MTU看到“能Ping通但网页打不开”先想DNS和HTTP。最后再送你一个每天都在用的练习场家里网络变卡时先别急着报修。自己按四层顺序过一遍——网卡亮不亮、网关通不通、外网通不通、域名解析正不正常。很多问题到不了运营商那一步而你每排查一次就相当于把这张四层地图又复习了一遍。 
长河君 · 2026/10/17 7:30:39 · 阅读 1.2k TCP/IP四层模型详解：从数据封装到网络排障的完整指南
你会不会在某一个瞬间突然好奇按下回车之后网页里的那些文字和图片到底是怎么跑到你屏幕上的答案绕不开一套已经运行了几十年的机制——TCP/IP协议。它被称为网络基础中的基础而理解它最常用的入口就是四层结构。这篇文章没有什么吓人的架子目的是让你看完之后能在脑子里建起一张地图哪一层负责什么数据怎么一层层往下封装、再一层层往上解开以及当网络出问题时该从哪一层开始查。不管你是刚接触网络的学生还是工作几年想补基础的开发者又或者是被各种协议报错折腾过的运维都能在这里找到一条清楚的线索。TCP/IP不是“一个”协议而是一组协议的总称。它从底层到上层分工形成一整套可以协同工作的协议栈。我把这些年跟网络打交道的心得按四层模型的顺序拆开讲。你不需要一次全记住重要的是先摸清每一层的职责边界剩下的字段、状态、命令都是在这个框架上长出来的枝叶。1. 为什么网络要分层用一个寄快递的场景把四层串起来1.1 寄包裹的类比每一层解决一个具体问题我第一次接触网络分层时觉得这东西很抽象。后来发现一个特别管用的类比寄快递。你写了一封信这封信要交给快递员。快递员不看信的内容只看信封上的收件人姓名和电话确保“给到具体的人”——这就类似传输层的端口号解决的是“数据要交给机器上的哪个进程”。信封填好后快递网点根据地址判断应该把包裹发往哪个城市再交给长途运输线路——这就类似网际层的IP地址和路由选择解决的是“数据要去哪台机器”。最后快递小货车在街道上按门牌号一件件投递——这就类似网络接口层的MAC地址和物理链路解决的是“在一条具体的线路上怎么把数据送出去”。而信纸上写的那些文字就是应用层真正关心的内容。这个类比虽然不完全严谨但足以让你记住四层各自的价值应用层管“用户要什么”传输层管“交给哪个进程”网际层管“去哪台主机”网络接口层管“怎么沿链路送出去”。1.2 不分层会怎样一次就能尝到苦头假设没有分层或者所有功能都混在一层里会出现什么情况最直接的影响是每出现一种新的应用就得把数据可靠传输、路由寻找、物理信号调制这些事情全部重写一遍。你写一个聊天软件要把丢包重传、IP寻址、网卡驱动都自己处理一遍换一种物理线路比如从网线换成光纤所有应用又得跟着改。分层最重要价值是让每一层只和相邻层打交道彼此独立演化。你家里宽带从旧线路升级到光纤浏览器和服务器软件不需要跟着换你在应用层从HTTP切换到新的接口协议底层路由器也不需要明白你传输的具体内容。这就是为什么今天任何一个应用都能复用电…不是都能复用同一套网络基础设施。用技术词汇说发送方从上往下走的过程叫“封装”每一层都把上一层的数据当作“载荷”再加上本层的头部信息接收方从下往上走的过程叫“解封装”逐层剥掉头部最终把原始数据交给应用。整个TCP/IP协议族的运转都建立在这个最基本的动作之上。2. 四层结构逐层拆解每一层到底解决什么问题2.1 网络接口层从比特到信号再回到比特四层模型里最下面的一层叫法很多网络接口层、链路层、主机到网络层。它负责把数据转换成能在物理介质上传输的信号也负责在同一段链路内让相邻设备之间能认出对方。这一层包含两个块一部分是物理层的事比如网线上的电压、光纤里的光脉冲、无线信号里的调制方式另一部分是数据链路层的事比如以太网帧的格式、MAC地址的寻址。平时你看到的“Wi-Fi信号满格但访问不了网络”“网线插上没反应”绝大多数问题都出在这一层。这里需要提一下ARP协议。严格说IP数据报要发出之前发送方得知道下一跳设备的MAC地址这个“把IP地址翻译成MAC地址”的活儿通常由ARP完成。经典的教科书会把ARP放在网络接口层附近因为它只工作在同一个链路范围内和负责跨网络寻址的IP层逻辑不一样。面试时有人纠结ARP到底算哪一层我觉得不必死抠关键是理解它解决的场景同一条链路里怎么找到对方的物理地址。2.2 网际层IP地址、路由选择和“尽力而为”四层模型的第三层是网际层也有人叫网络层。它是整个互联网的基石解决的问题是我在这个地方目标在另一个地方数据到底应该怎么走。网际层通过IP地址建立了一套全局统一的逻辑地址体系。你电脑上的网卡、服务器、手机只要接入了网络就会有至少一个IP地址。有了这个地址路由器才能做转发决策。路由器不看你在浏览器里打开了哪个网站它只看数据报里的目标IP然后根据路由表决定下一步把数据送到哪个接口。这就是“路由选择”。这一层还会给数据加上一些控制信息比如TTL存活时间每经过一个路由器TTL就减一减到零还不达目的地就丢弃防止数据包在网络里无限循环。IP头部里还有一个“协议字段”用来告诉接收方这个IP包里面装的是TCP数据还是UDP数据。IP层的特点是“尽力而为”它会尽量把数据送到目的地但不承诺不丢包、不重复、不按序。真正负责可靠传输的是上一层——传输层。2.3 传输层端口、可靠传输和两种哲学网际层把数据送到了“某台主机”但一台服务器上同时跑着几十上百个进程网页服务、邮件服务、数据库服务……到底该把数据交给谁传输层用端口号解决了这个问题。端口号可以理解成“进程在主机里的门牌号”。浏览器发起请求时会随机挑一个临时端口作为源端口目标端口则是事先约定好的比如HTTP默认80、HTTPS默认443、DNS查询默认53。有了IP加端口一个连接就能唯一定位到“某台机器上的某个进程”。传输层有两个代表性协议风格完全不同。TCP提供的是可靠的、面向连接的字节流传输。它会先建立连接数据发送后等待确认没收到确认就重传还会调节发送速度避免太块压垮接收方——注意是“太快”我打错了实际是“太快”。TCP做这一大堆事情换来的代价是复杂度高、头部开销大、有握手延迟。UDP则干脆得多不建立连接不确认不重传就是尽可能快地把数据丢出去。它适合那些“宁可丢一小段也不愿意等重传”的场景比如实时语音、视频通话、游戏同步很多基础的DNS查询也走UDP因为快。我们平时说“TCP/IP协议”其实是把这一整族协议打包在一起叫了并不是只有TCP和IP这两个协议。2.4 应用层用户真正看得见的那一层四层模型的最顶层是应用层HTTP、HTTPS、DNS、FTP、SSH、SMTP这些大家挂在嘴边的协议都在这层。它们定义的是“数据长成什么样、交互流程怎么走”。举个例子浏览器向服务器发起一次访问最典型的HTTP请求报文会包含请求方法、请求路径、协议版本以及一堆头部字段。服务器收到后返回状态码和响应体。这个“一问一答”的形式就是应用层协议规定的。DNS也属于应用层它解决的是“域名到IP的映射”。你在地址栏里输入一个域名系统会先通过DNS把域名解析成IP再去建立连接。需要强调一点应用层不关心数据怎么变成电信号也不关心选路只关心数据内容和交互语义。写网页的人不需要懂路由算法这就是分层带来的自由。3. 一次网页请求的四层历险从敲下回车到页面出现3.1 封装每一层都往上贴一个“快递单”理论说完了我们跟着一次真实的网页请求看看数据怎么在四层之间流转。假设你在浏览器输入了一个网址按下回车。实际场景里第一步往往是DNS解析。浏览器要把域名换成IP这个查询报文本身也要走一次完整的封装DNS是应用层默认通过UDP发送UDP头加上源端口和目标端口IP头加上本机IP和目标服务器IP最后一层交给网卡通过网线或者无线发出去。也就是说一个你看不见的DNS查询背后已经跑了一遍四层。拿到IP之后浏览器开始发HTTP请求。这个过程在发送方是这样的应用层生成HTTP请求报文内容包含请求行、头部和请求体。传输层选择TCP分配一个临时源端口填上目标端口加上序号、确认号把HTTP报文当作载荷装进一个TCP段里。网际层接住TCP段填上源IP和目标IP加上TTL等字段变成IP数据报然后查路由表决定下一跳该发给谁。网络接口层通过ARP拿到下一跳设备的MAC地址把整个IP数据报放进以太网帧里加上源MAC、目标MAC最后变成比特流发出去。每一层都相当于往上贴了一张“快递单”不同的是快递单上写的地址类型不一样。这里有一张简表把不同层的数据形态和关键标识串起来层级数据形态关键标识典型设备/对象应用层HTTP报文、DNS报文URL、域名浏览器、服务器进程传输层TCP段 / UDP数据报端口号防火墙、负载均衡设备网际层IP数据报IP地址路由器网络接口层以太网帧、无线帧MAC地址网卡、交换机3.2 连接建立三次握手到底在握什么TCP要传输数据前先要“握手”也就是三次报文交换客户端发SYN服务器回SYNACK客户端再回ACK。很多人背过这个过程却未必明白它为什么非要三次。三次握手的本质是让双方都确认两件事对方能收到我的消息我也能收到对方的消息。第一次SYN让服务器知道客户端想建立连接第二次SYNACK让客户端知道服务器收到了同时客户端也确认自己能收到服务器的消息第三次ACK让服务器确认客户端确实收到了自己的回应。如果你只握两次手可能出现一种情况网络上有一个迟到的旧连接请求服务器误以为这是新连接于是建立了一个本不该存在的连接白白占用资源。三次握手能降低这种“历史请求干扰”的概率。我实际调试时经常用这个知识点去判断故障如果客户端发SYN之后一直没收到SYNACK问题大多在服务器不监听端口、防火墙拦截或者服务器负载过高如果SYNACK发出去了但第三次ACK没到就要去查两端之间的丢包或连接状态。看到“connect超时”和“connection refused”是两种完全不同的问题根源就在握手的哪一步失败。3.3 跨网络送达IP地址相对不变MAC地址一直在变数据从你的电脑发出去之后第一跳通常是家里的网关路由器。在你和网关之间通信靠的是MAC地址出了网关之后每一台路由器会根据IP头部里的目标IP决定下一步转发到哪。很有意思的一点是数据在整个传输过程中源IP和目标IP基本不变但是经过每一跳帧头里的源MAC和目标MAC都会重新改写。链路层解决的是“这一段路上怎么送”网际层解决的是“整个路网里怎么走”。这个区别在抓包时特别明显你抓到的包目标MAC往往不是你最终服务器的地址而是网关的MAC。如果你不理解这一点看到报文里的地址不匹配很容易误判。服务器收到数据后会做和发送方相反的拆解工作网卡收到帧、剥掉帧头发现IP目标是自己、剥掉IP头再根据TCP头里的端口号把数据交给对应进程。服务器进程读完HTTP请求再按照同样流程把响应发回来。你看到的那个网页就是这四层机制来回运转的结果。4. 遇到网络问题按四层模型一层一层排除4.1 先定界再定位不同症状指向不同层这些年排障我最深的感受是网络问题最怕“乱猜”。与其一次尝试多个方向不如先把问题定到某一层再在这一层里面深挖。四层模型本身就是一张极好的排查地图。我常用“自下而上”的顺序先看网络接口层再看网际层接着看传输层最后看应用层。因为底层不通上层一定不通底层通问题才可能在上层。遇到具体现象时可以做一个初筛现象最先怀疑层检查方向Wi-Fi有信号但完全上不了网网络接口层网卡状态、网关链路、线缆/无线信号能上内网但上不了外网网际层网关路由、IP配置、DNS归属能Ping通IP但不能访问网页应用层DNS/HTTP域名解析、服务端口、Web日志能Ping通IP但目标端口连不上传输层服务监听状态、防火墙、端口是否被占首页正常但大附件上传卡死网际层网络接口层MTU、分片、中间链路限制这个表不是绝对的但它能帮你快速锁定排查范围避免一上来就抓包从头到尾瞎看。4.2 常用工具和四层模型的对应关系排查工具里每一个命令其实都有自己的“所属层”。你要做的不是背命令而是知道每个命令是在验证哪一层的哪个问题。ip addr、ifconfig看网络接口层检查网卡是否up、IP和MAC是否正确。ping基于ICMP主要验证网际层的连通性顺带检查丢包和延迟。traceroute/tracert同样基于ICMP或者UDP看数据包经过哪些路由节点定位是靠近本端还是靠近远端的问题。nslookup/dig验证应用层的DNS解析查域名到底解析成哪个IP。netstat看传输层的端口监听和连接状态。nc/telnet直接测试某个IP端口的连通性快速区分“端口问题”和“应用问题”。curl验证应用层的HTTP交互能看到状态码、响应头和页面内容。抓包工具可以同时看到四层报文的全部细节适合前面几步定位不到根因的时候用。举一个组合排查的例子比如“网页打不开”# u先确认本机接口和IP ip addr # 看网关通不通 ping 网关地址 # 看域名能不能解析 nslookup 你访问的域名 # 看目标IP通不通 ping 目标IP # 看目标端口通不通 nc -vz 目标IP 443 # 如果以上都通再用curl看HTTP层反馈 curl -I https://你访问的域名这套流程走下来问题基本能定位到某一层。多数“打不开”的最终原因要么是DNS解析坏了要么是目标端口没监听要么是中间路由断了很少会有四层同时故障的“太巧合”情况。4.3 一个真实案例大文件传不上去小包却完全正常以前维护一个内部系统时遇到过一个让所有人头疼的问题系统里在线查看小页面、小图片都没问题但只要上传几十MB的文件进度到一半就会卡住最后失败换一台电脑也一样看起来非常随机。我当时的排查链路是这样的先查应用层和服务端日志没有任何报错再看传输层连接能正常建立握手没问题。接着用ping测目标服务器小包完全正常延迟和丢包都很低。到这里多数人会认为网络没问题去看应用代码。但问题有一个关键特征小文件能传大文件必卡。这个特征让我把注意力转向了网际层和网络接口层交界处的MTU问题。我用增大ICMP报文长度、同时设置不允许分片的方式去试探发现报文长度超过某个值之后目标就不回应了持续的更大报文则直接超时。再抓包看才发现问题出在中间某段链路的MTU比常规的1500更小大报文到了那里被丢弃。而按IP分片的正常流程这个设备应该回一个“需要分片”的ICMP消息给发送方但中间有人把这类ICMP消息过滤掉了发送方根本不知道自己的包太大就一直重发表现就是卡死在半路。解决办法也很直接把本机和服务器之间相关接口的MTU从默认值调低让两端实际协商出一个更小的报文上限再重试大文件上传稳定跑通了。这个小案例说明两件事第一“小包正常、大包异常”时要优先怀疑MTU和分片问题而不是怀疑应用代码第二抓包看到的往往只是表面现象能不能把报文和各层机制对起来才是排障的关键。后面我会专门展开一下MTU这个容易被忽略的细节。5. 几个容易栽跟头的细节端口、MTU和常见模型之争5.1 端口号与“四元组”很多人知道端口号但说不清端口号是怎么划分的。端口号的取值范围是0到65535其中0到1023是知名端口由常见的应用协议固定占用1024到49151是登记端口很多服务会用这一段49152到65535是动态端口客户端发起连接时通常从这里随机挑一个作为源端口。这里有个容易搞混的地方一个连接并不是由“目标IP目标端口”唯一确定的而是由四个要素组成——源IP、源端口、目标IP、目标端口它们合起来叫四元组。所以同一台服务器上的同一个端口可以同时为成百上千个客户端连接服务因为每个连接的源IP和源端口不一样。这也是防火墙规则和负载均衡策略经常基于四元组来做判断的原因。5.2 MTU、MSS与IP分片MTU最大传输单元指的是网络接口层一次能发送的最大载荷长度。最常见的以太网MTU是1500字节。如果一个IP数据报超过这个长度发送方就面临两个选择让IP层把数据报拆成多个分片或者让上层从一开始就别把它发送那么大。TCP其实很聪明。双方建立连接时会协商一个MSS最大报文段长度通常设为“MTU减掉IP头20字节再减掉TCP头20字节”也就是1460字节。这样一来正常情况下TCP段就不会超过路径上能够承载的尺寸根本不需要IP分片。IP分片本身开销高而且有风险只要一个分片丢了整个数据报都没法重组成功。所以现代网络更倾向于用“发现路径MTU”的方式让发送方先探明整条路径上最小的MTU再按这个限制发送。探明的方法是设置IP头的DF位禁止分片如果中间某个设备发现报文太长就返回一个ICMP消息告诉发送方“需要分片但你不让分片”。这类机制和四层模型的关系是很多人忽略的传输层要考虑网络接口层的能力。我在前面那个大文件案例里遇到的就是“路径MTU发现”依赖的ICMP消息被过滤导致发送方不知道应该减小报文尺寸。所以你在排查“某个连接小流量正常、大流量中断”时可以重点看一下两端接口MTU、中间链路是否有封装额外开销、以及ICMP消息是否被拦截。5.3 四层、五层、七层模型到底怎么对应你可能还听过开发系统互连参考模型OSI的七层概念应用层、表示层、会话层、传输层、网络层、数据链路层、物理层。TCP/IP的四层模型实际上是把OSI中上三层合并成了应用层把数据链路层和物理层合并成了网络接口层。对应关系大致是OSI七层TCP/IP四层应用层、表示层、会话层应用层传输层传输层网络层网际层数据链路层、物理层网络接口层有些教材为了讲清楚链路层内部结构会把网络接口层再拆成“数据链路层”和“物理层”变成五层模型。这三种表达在不同场景里都有人用不用纠结谁对谁错关键是知道它们描述的边界有什么异同。真正日常工作中更常见的说法是“L4”和“L7”。比如某些负载均衡设备L4模式只看IP和端口转发L7模式能看到HTTP里的URL、请求头再决定转发到哪台服务器。理解四层模型之后这两个词对你来说就不再是黑话了。6. 自己动手用几个小实验把四层模型刻进脑子6.1 实验一抓一次包亲眼看看四层头部纸上谈兵再多不如抓一次包。先在命令行里启动抓包工具监听本机的某个网络接口过滤目标端口为80或443的流量tcpdump -i eth0 tcp port 443 -c 30然后打开一个网站让流量产生。抓到的数据会同时展示底层以太网头部里的MAC地址紧接着IP头部里的源IP和目标IP再往上是TCP头部里的端口号和序号最后才是应用层的内容。看的时候别急着全看懂按层折叠着看。你会发现应用层的数据在报文最里面每一层头部的长度基本固定这和“封装”概念完全对上。如果你能看到请求的TCP握手正好观察三次握手里的SYN、SYNACK、ACK三个报文。6.2 实验二用traceroute看数据包逐跳路径执行traceroute 目标IP不同系统命令名可能不一样有些叫tracert它会显示数据包从本机出发经过了多少个路由节点到达目标。它的原理是IP头部里的TTL每经过一个路由器就减1减到0时路由器会把包丢弃并回一个ICMP超时消息。traceroute从TTL1开始逐步增加TTL让沿途每个路由器都“暴露”自己从而把整条路径摸出来。做这个实验时你会发现有些节点显示星号这通常是设备出于安全策略不回应ICMP消息不代表路由一定断了。判断网络路径是否异常不能只看某一个星号要看整体趋势和最终目标是否可达。6.3 实验三用netstat观察连接状态在终端里执行netstat -anp | grep 443你会看到一堆连接状态包括监听状态LISTEN、已建立连接状态ESTABLISHED、正在等待关闭的状态TIME_WAIT。这些状态对应着TCP连接建立和断开的完整生命周期。其中TIME_WAIT是主动断开方在连接结束后等待一段时间、同时清理残留报文的状态。当你看到大量TIME_WAIT时说明这个端主动建立了大量短连接这是线上系统里非常常见的情况。理解了传输层状态机你再去看各种监控指标就不会被一堆缩写吓到。6.4 我个人的学习顺序建议如果你想系统补网络基础我建议的顺序是先把四层职责背熟再抓包看一次真实请求接着跟着排一次故障。不要为了面试去硬背端口号和状态码而是去记“每一层在问什么、靠什么回答、出错会有什么现象”。比如看到“连接超时”先想传输层握手哪一步没完成看到“小包正常大包卡”先想MTU看到“能Ping通但网页打不开”先想DNS和HTTP。最后再送你一个每天都在用的练习场家里网络变卡时先别急着报修。自己按四层顺序过一遍——网卡亮不亮、网关通不通、外网通不通、域名解析正不正常。很多问题到不了运营商那一步而你每排查一次就相当于把这张四层地图又复习了一遍。