ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

OSI七层模型与TCP/IP四层模型:数据封装、解封装及网络排障实战

OSI七层模型与TCP/IP四层模型:数据封装、解封装及网络排障实战 我最早真正理解OSI七层模型不是从教材上背会的而是面试被问了一句你ping不通一台机器到底卡在哪一层当时脑子里七层图背得滚瓜烂熟真到了排障现场反而发怵。后来才慢慢明白OSI模型这个理论框架的价值不在于把七层名字倒背如流而在于它把一段网络通信拆成了可以观察、可以定位、可以逐层验证的流程——数据从诞生到变成比特每一层加了什么头这就是数据封装收包的另一端怎么把这些头一层层剥掉这就是解封装。而你在实际工作中天天接触的TCP/IP模型正是这套分层思路在互联网语境下的落地版本。这篇文章我会把OSI模型的来龙去脉、七层到底各管什么事、数据封装和解封装的完整链路、以及OSI与TCP/IP之间的对应关系一次讲透。适合三类人看刚入门网络想建立体系的新人面试前想突击概念的技术候选人以及天天和网络打交道但发现模型背了又忘的运维和开发。我不会只罗列概念而是尽量用实际排障和抓包的经验把这些抽象层落地。1. 为什么网络工程师讨厌背七层OSI模型诞生的真实背景1.1 从接口不互通到分层协作的演进逻辑在互联网还没起来的年代网络设备厂商各有各的通信协议你买了一家厂商的设备基本就只能跟它自己家的设备对话跨厂商对接往往要专门写转换程序。IBM有自己的SNADEC有DNA各说各话。1977年左右国际标准化组织ISO开始推动制定一个开放的网络体系结构标准目标就是让不同厂商、不同操作系统的计算机可以互相通信只要大家都遵守同一套分层规范。1978年OSI参考模型正式成形OSI全称是Open Systems Interconnection也就是开放系统互连。为什么叫开放就是因为这套标准不绑定任何一家厂商或一项私有技术所有人都可以使用和实现。OSI把整个通信过程拆成七层每一层只干一类活层与层之间通过服务接口联系。核心思想就是分而治之——一个大公司的销售部不必关心财务怎么记账财务部也不必管销售怎么谈判部门之间只要交接单清晰整个流程就能顺畅运转。放到网络里应用层不需要关心数据怎么被路由器转发链路层也不需要理解HTTP报文语义各层只把自己这部分做到位然后交给下一层。1.2 分层的三个基本原则对等通信、依赖服务、接口清晰第一个原则是对等通信。两台机器通信时每一层都只跟对端机器的同层对话。发送方的传输层跟接收方的传输层约定端口、序列号、确认号发送方的网络层跟接收方的网络层协商IP寻址和路由。从用户的视角看数据好像从应用层直接传到了对方的应用层但实际物理链路只发生在最底层。这种逻辑通路、物理直连的模型是理解所有网络协议的基础。第二个原则是下层为上层提供服务方向自下而上。物理层负责传输原始比特数据链路层帮你在相邻节点间传帧网络层负责跨网络寻址传输层补上端到端的可靠性或实时性应用层则直接面向用户。每一层只依赖下一层不需要关心上一层业务具体怎么处理也不需要知道下一层到底用光纤还是双绞线。第三个原则是接口清晰。每一层都有标准的服务访问点SAP下一层通过SAP把数据交付给上一层。网络世界的SAP最典型例子就是端口号——TCP/UDP端口就是传输层向应用层交付数据的窗口IP头里的Protocol字段相当于网络层向传输层交付数据的窗口以太网头里的Type字段又是链路层向网络层交付数据的窗口。排查问题时你只要弄清楚数据卡在哪个窗口前面基本就能定位到具体层。这套分层思想在当时是很超前的因为它把一个极度复杂的通信系统变成了可替换、可测试、可演进的模块化结构。哪怕到今天你写一个网络应用也只需要关心应用层协议底下的传输、路由、链路全部被模型隔离掉了。2. 从物理电平到应用数据七层里每一层的活儿和对应协议2.1 应用层、表示层、会话层为什么现代网络总是把它们合并看待从顶往下第一层应用层离用户最近HTTP、HTTPS、SMTP、DNS这些天天在用的协议都在这一层。应用层不关心数据怎么传只负责定义业务语义——比如浏览器发一个GET请求服务器回一个响应报文。第二层表示层负责数据格式转化、加密和压缩JPEG图片编码、ASCII与UTF-8之间的转换都属于它的职责范围。第三层会话层负责建立、管理和终止通信会话像HTTP的keep-alive长连接、数据库连接的会话恢复等都可以追溯到这一层的职责。但在真实的TCP/IP模型里这三层被合并成了一个大应用层。原因很现实表示层和会话层在工程中几乎没有独立的协议实现很多职责被下层协议或应用自身接管了。最典型的例子是TLS它同时承担了密钥协商会话层职责和加密传输表示层职责却没人会说它是表示层协议。所以我给初学者的建议是理解应用层就是用户数据产生和消费的地方就够了不值得在表示层和会话层的边界问题上反复纠结。2.2 传输层端口与可靠性的输送调度中心第四层传输层是整个模型的核心枢纽它有两个主力协议TCP和UDP。TCP提供可靠、有序、面向连接的传输用三次握手建立连接用序列号和确认号保证数据不乱序、不丢失还有拥塞控制和流量控制去适配网络状态。UDP则无连接、不保证可靠但延迟低、开销小适合实时语音、视频、DNS查询这类丢一包就算了重传更糟的场景。传输层引入的关键概念是端口用16位端口号区分同一台主机上的不同应用进程。源端口基本是随机的临时端口目的端口则对应明确的服务比如80是HTTP、443是HTTPS、53是DNS。端口的本质就是SAP它让发到主机的数据能够准确敲门找到对应的应用进程。很多排查场景里你确认了IP通但端口不通问题就落到了传输层到应用层这一段。2.3 网络层、数据链路层、物理层IP地址与MAC地址各自管一段第四层网络层负责把数据包从源地址送到目的地址允许跨越多个网络。IP协议在这里承担编址和选路路由器是这一层的主要设备。第五层数据链路层负责在相邻节点之间的链路上传输帧有自己的一套寻址机制——MAC地址交换机依靠MAC地址表转发帧。第六层物理层负责把比特变成电信号、光信号或无线信号真正在双绞线、光纤或者空气里传播。从网络层往下有个常见误区很多人以为MAC地址是设备出厂自带的全球唯一身份证其实MAC地址只在同一个二层域内有意义路由器转发时会把二层帧的头和尾全部重写。跨网络传输时IP地址不变NAT场景除外MAC地址却是每一跳都在变。把这一点想通了很多关于为什么需要ARP为什么IP和MAC两套地址缺一不可的疑惑就自然解开了。3. 数据封装一封信从应用层走到物理层的完整流水线3.1 各层PDU名称与封装动作从数据到帧的名称演变数据封装是OSI模型里最核心也最容易被忽略的概念。所谓封装就是数据从高层往低层流动时每一层都在前面加上本层的头部有时还会加尾部让接收方的同层能够按规则解析。封装之后数据在不同层有不同叫法应用层原始数据叫Data传输层加完TCP/UDP头后叫Segment段网络层加完IP头后叫Packet包数据链路层加完帧头帧尾后叫Frame帧物理层变成Bit比特流。OSI层封装后名称关键头部信息典型协议应用层Data用户原始数据HTTP、DNS、SMTP传输层Segment源/目的端口、序列号、校验和TCP、UDP网络层Packet源/目的IP、TTL、协议号IP、ICMP数据链路层Frame源/目的MAC、类型、FCSEthernet、PPP物理层Bit电/光信号编码10BASE-T、1000BASE-SX这些头部信息是各层沟通的关键。传输层的头告诉接收端该把数据交给哪个进程网络层的头告诉路由器该往哪个方向转发数据链路层的头让下一跳知道这个帧想找哪个邻居。整个过程就像快递包裹的逐层包装先把产品说明书装进带有客户信息的文件袋传输层头再装进贴了面单的快递箱网络层头最后在箱外贴上一张仓库流转标签链路层头才能进入运输通道。3.2 以HTTP请求为例完整走一遍五层封装假设你在浏览器访问https://www.example.com整个封装链路大致分成五步。第一步浏览器经过DNS解析拿到目标服务器IP。DNS解析本身也是一次UDP的数据封装过程先不说它。拿到IP后浏览器构造HTTP请求报文包含请求行、Host头、User-Agent等字段这就是应用层的Data。第二步TCP把HTTP报文视为字节流加上TCP头。头里包含源端口浏览器随机分配的临时端口比如54321、目的端口443、序列号和确认号。此时数据单元叫Segment。第三步IP层在TCP段前加IP头填写源IP、目的IP、TTL、协议字段6表示上层是TCP等生成Packet。TTL初始值是64或128每经过一台路由器减一减到0就被丢弃防止数据包在网络里死循环。第四步数据链路层把IP包封装成以太网帧帧头包含目的MAC和源MAC帧尾加FCS帧校验序列Type字段标识上层协议为0x0800IPv4此时数据单元叫Frame。注意如果目的IP不在同一子网目的MAC字段填的是默认网关的MAC地址而不是目标服务器的MAC。二层寻址永远只负责下一跳这个点新手最容易转不过来。第五步物理层把帧变成比特流经网线、交换机传输。交换机收到帧后看源MAC和目的MAC决定转发端口路由器则把帧头和帧尾整个剥掉只看IP头做路由决策再封装成新的帧发往下一跳。数据包跨网络每走一跳链路层地址就重写一次但网络层的IP地址保持不变。3.3 接收方向的解封装逐层剥头的过程数据到达目标主机后的流程是封装的逆过程叫解封装。网卡收到比特流后先还原成帧检查FCS是否合法失败就直接丢弃然后看帧头目的MAC是否是自己是则剥掉帧头帧尾把IP包交给网络层IP层检查目的IP、TTL必要时做分片重组再根据Protocol字段识别上层协议剥掉IP头交给传输层TCP层检查目的端口把Segment按序列号排序交给对应应用进程最后应用层拿到完整的HTTP请求正文。有一个常被忽视的关键点以太网帧有长度上限MTU默认1500字节。如果IP包大于这个值IP层就要分片接收端再做重组。分片会显著拖慢性能所以TCP必须协商MSS把TCP段大小限制在不会被IP分片的范围内。这个我后面专门展开因为它是实际运维里踩坑重灾区。3.4 延伸案例codesys等工业控制场景里的数据封装热词里出现codesys数据封装很多人会好奇跟OSI模型有什么关系。Codesys是工业自动化领域常用的PLC编程环境它讲的数据封装更多面向EtherCAT、PROFINET这类现场总线协议。这些协议本质上仍然沿用OSI分层思想应用层的PLC程序把工艺数据封装成模块化对象再映射到以太网链路层和物理层做周期报文交换。与HTTP的区别在于工控场景更追求实时性和确定性所以报文往往直接塞进以太网帧、跳过完整的TCP/IP握手过程。理解OSI之后你会发现不管协议多专有数据从产生到发出、逐层加头再逐层剥头的基本逻辑不会变只是层的数量和名称被重新定义了。4. OSI与TCP/IP的账本对不上四层模型为什么更能打4.1 先有鸡还是先有蛋官方标准和事实标准的时间差OSI模型直到1984年才由ISO正式发布而TCP/IP早在上世纪70年代就随着ARPANET投入实际运行了。等OSI七层模型成型时TCP/IP已经积累了大量的实际部署、路由协议和应用程序。网络世界有个残酷的规律事实标准往往比官方标准更有生命力。TCP/IP没有强制做统一的分层规范它只是把已经跑得很好的协议归纳进一个四层框架反而比OSI的七层理论更贴合工程中的协议栈概念。所以你会看到很多教程采用五层混合模型底层保留OSI对数据链路层和物理层的细分上层沿用TCP/IP的合并方式。我在带团队讲网络基础时经常说OSI七层是理论标准TCP/IP四层是事实标准五层混合模型是教学和解脱。不用纠结哪个更正确关键是明确你正在处理的问题落在哪一层。4.2 一张表看清OSI、TCP/IP与实际设备协议的对应关系OSI七层TCP/IP四层代表协议典型设备应用层/表示层/会话层应用层HTTP、HTTPS、DNS、SMTP、FTP服务器、部分防火墙传输层传输层TCP、UDP负载均衡、防火墙网络层网际层IP、ICMP路由器、三层交换机数据链路层网络接口层Ethernet、Wi-Fi、PPP交换机、无线AP物理层网络接口层光纤、双绞线、射频网卡、集线器、中继器表中有一个经常引起争论的细节ARP到底属于哪一层从数据承载上看ARP直接用Ethernet承载抓包里没有IP头更像链路层机制但它干的又是解析网络层地址IP到MAC的活。教科书有的归网络层有的归链路层面试被问到时稳妥的回答是ARP位于网络层与数据链路层之间的边界。类似这种边界模糊的情况反而说明模型是人为划分的不要拿理论去硬套现实。TCP/IP把数据链路层和物理层合并成网络接口层从标准化角度看是个偷懒但工程上并没有带来太多困扰。因为对IP层来说不管是以太网、Wi-Fi还是PPP它只需要一个把包交给下一跳的抽象接口就够了具体链路机制被完全屏蔽在IP层之下。这也是分层设计在现实中最成功的体现。4.3 为什么实际工作中只说三层问题和七层问题排障时最常听到的说法是这是三层问题这是七层问题。三层指的是网络层包括路由、IP地址冲突、不可达七层指应用层包括业务报错、协议交互异常、认证失败。这种口语化表达的流行正好证明了OSI模型的实用性——它不需要你把每一层列全只需快速定位谁的职责范围。初级运维常见的错误是网页打不开就怀疑DNS、怀疑服务器配置但如果你先ping一下网关发现都不通那一层层往上排查根本没意义问题大概率还在二三层。反过来有一种半通的场景也挺能说明问题同一网段内ping得通跨网段ping不通基本就是网络层路由或防火墙策略问题ping通了但端口不通范围就缩到传输层到应用层这一段。能不能准确说出半通到底是哪个层没通是区分理论派和实战派的好标准。5. 把OSI用起来抓包、排障与MTU/MSS里的模型影子5.1 排障中的层层排除法到底怎么用我自己的排障习惯遵循一套清晰的逐层验证顺序。用户报网页打不开我会先看物理链路和链路层用ethtool、ip link确认网卡link是否up、交换机端口是否正常然后ping网关、ping目标IP必要时traceroute看路径上哪一跳断了这是网络层接着用telnet或nc测端口通不通确认TCP握手是否完成这是传输层最后curl -v看HTTP响应和DNS解析这是应用层。分层排障的核心思路是每次只验证一层很快就能把问题范围缩小到一个很小的区间。这套方法看似懂网络的人都会但真正执行到位的不多。很多人一上来就抓包抓了半天也不知道在看什么层次的信息。之前帮同事排查一个服务间歇性超时的问题应用日志里全是超时重试后端代码查不出任何bug。最后在客户端抓包发现IP头的TTL只剩1数据包再经过一个路由器就会被丢弃某些路径能通、某些路径超时。如果心里没有分层这个概念根本想不到去看TTL这种网络层字段。5.2 抓包是理解封装最快的方式协议树本身就是七层的倒影验证数据封装最直观的手段是抓包。tcpdump常用参数-i eth0 -nn -w /tmp/https.cap抓包然后用Wireshark打开就能看到完整的协议树。Wireshark的协议树层次基本就是OSI模型的反向映射最外层是Frame物理层帧信息往下是Ethernet II数据链路层再往下是Internet Protocol Version 4网络层再往上是Transmission Control Protocol传输层最顶层是Hypertext Transfer Protocol应用层。抓包时你会看到一段字符串同时包含TCP层的Seq号、IP层的TTL、Ethernet层的MAC地址这就是封装过程的物证。我第一次把抓包协议树和OSI分层对应起来的时候才真正意识到那些封装不只是图上的概念而是实实在在写进每个字节的东西。学网络基础的时候我强烈建议每个人亲手抓一次自己浏览网页的包对照协议树找到每一层加了什么头比反复背图高效得多。5.3 MTU与MSS一个让运维反复踩坑的二层与四层联动问题最后展开说一个我在运维中反复撞上的问题——MTU和MSS。MTU最大传输单元是数据链路层概念以太网默认1500字节MSS最大报文段长度是传输层概念默认是MTU减去IP头20字节和TCP头20字节即1460字节。TCP建立连接时会在SYN报文里协商MSS让双方选择不会触发IP分片的大小。如果路径上存在PPPoE、VXLAN这种额外开销的封装实际可用MTU会低于1500不调整就会出现小包能通大包不通的诡异现象。验证MTU最常用的命令是ping -M do -s 14721472加28字节的IP和ICMP头正好等于1500。如果返回frag needed错误就说明路径某个节点限制了MTU。这类问题如果你不清楚MTU在OSI模型的哪一层很容易在传输层和应用层之间打转。理解了它是二层帧大小的约束你自然会去检查隧道、宽带拨号、网卡配置这些链路层相关点。我个人一直坚持一个看法与其死背七层名称和顺序不如把模型当成一张网络问题地图。数据封装告诉你每层加什么头解封装告诉你接收端怎么剥头TCP/IP模型告诉你现实中的协议栈长什么样。当你能够把抓包内容对应到协议树的具体分层时模型才真正变成你手里的工具。最后分享一个自己的记忆方法。记七层我用的谐音是应表会传网链物倒过来就是物链网传会表应。排障时脑子里出现一个报文在逐层加头、逐层剥头的画面很多抽象问题就具体了。遇到问题先问一句这个现象发生在哪一层然后用对应层的工具去验证比翻书快得多。这套思路用在网络基础学习、日常排障、甚至面试复盘里都比单纯背层号要实用。
返回列表