一张图看懂OSI与TCP/IP网络分层模型

1. 为什么一张图就能讲清网络分层——从“寄快递”开始理解OSI与TCP/IP你有没有想过当你在浏览器里输入一个网址几秒钟后页面就完整加载出来背后到底发生了什么不是魔法而是一套精密协作的“通信协议体系”在默默工作。这套体系最核心的骨架就是OSI七层模型和TCP/IP四层模型。很多人一看到“七层”“四层”就头皮发麻觉得是教科书里用来考试的抽象概念。但其实它本质上就是一套“网络世界的物流分工手册”——把复杂的端到端通信拆解成七个或四个各司其职、层层交接的环节。我带过不少刚接触网络的学员发现最大的障碍不是技术本身而是缺乏一个具象的锚点。所以这次我不打算从“物理层定义”“会话层功能”这种术语堆砌开始。我们先来模拟一个最日常的场景给外地的朋友寄一封手写信。你写好信应用层你想表达的内容把信装进信封写上收件人地址和邮编表示层数据格式化、编码比如把中文转成UTF-8在信封上贴好邮票盖上本地邮局的戳会话层建立、管理、终止“通信会话”就像你拨通电话后说“喂是我”查邮政编码表确定这封信该走哪条干线传输层核心是端到端的可靠/不可靠传输对应TCP/UDP就像你选择“挂号信”还是“平信”把信交给本地邮局分拣中心网络层负责逻辑寻址和路由IP协议干的就是这个活相当于给信分配一个全国唯一的“门牌号”邮局用卡车把一摞信运到下一个中转站数据链路层负责同一物理网络内的节点间传输处理MAC地址、帧校验就像卡车司机只管把货送到隔壁城市的分拣点卡车在高速公路上跑靠的是油、发动机和轮胎物理层纯粹的比特流传输电缆、光缆、无线信号就是“力气”本身而TCP/IP模型则是这套物流体系在真实世界中的“精简高效版”。它把OSI里偏理论的会话层、表示层直接合并进应用层把数据链路层和物理层打包成“网络接口层”。这不是偷懒而是工程实践的胜利——就像快递公司不会为每封信单独设立“信封设计部”和“邮戳审核组”而是让客服和分拣员一起搞定前端包装。OSI是理想化的参考框架TCP/IP是落地生根的工业标准。你在Wireshark里抓到的每一个包背后跑的都是TCP/IP而你在教材里学到的“分层思想”绝大多数来自OSI的清晰划分。这张思维导图就是把这套“物流分工手册”画成一张一眼能看懂的路线图。它不追求穷尽所有协议细节而是帮你建立第一性认知数据不是凭空飞过去的它像一件货物在每一层都被加上新的“外包装”又在对端被一层层拆开。你看懂了这个“加壳-拆壳”的过程再去看HTTP、DNS、ARP这些具体协议就不再是孤立的名词而是有位置、有职责、有上下游关系的“物流环节负责人”。这才是真正的一分钟入门——不是记住七层名字而是理解分层背后的工程哲学。2. 模型不是摆设OSI与TCP/IP如何决定你的网络问题排查路径很多初学者有个误区以为OSI和TCP/IP只是考试要背的“知识点”跟实际排障八竿子打不着。直到某天他发现公司网站打不开第一反应是重启路由器——结果折腾半小时问题出在自己电脑的防火墙把HTTP端口给拦了。这就是典型的“没有分层思维”导致的低效排查。模型的价值不在于它多完美而在于它给你提供了一条清晰、可逆、有优先级的故障定位路径。就像医生看病不会上来就做全身CT而是先问症状、测体温、听心肺再逐级深入。我们来拆解一个真实高频场景笔记本连不上公司Wi-Fi显示“已连接无Internet访问”。如果你脑子里有OSI/TCP/IP模型排查就变成了一条有迹可循的流水线2.1 从底层物理层/网络接口层开始先确认“力气”够不够这是最容易被忽略却最该最先检查的环节。别急着怀疑DNS或网关先问自己笔记本的Wi-Fi开关打开了吗物理层硬件是否启用任务栏右下角的网络图标显示的是“已连接”还是“无连接”数据链路层是否成功关联到AP的BSSID你拿到的IP地址是169.254.x.x这样的“自动私有地址”还是192.168.x.x这样的正常内网地址网络层DHCP是否成功分配IP提示ipconfig /allWindows或ifconfigmacOS/Linux是你的第一把手术刀。如果连IP地址都没有说明问题卡在了网络层以下这时候去查DNS配置就是缘木求鱼。2.2 向上一层网络层验证“门牌号”是否有效假设你拿到了正确的IP下一步就是测试“逻辑寻址”是否通。打开命令行执行ping 192.168.1.1这里的192.168.1.1是你家路由器的默认网关地址。如果ping不通说明你的设备和本地网络的“指挥中心”失联了。可能原因包括路由器死机或网线松动物理层你的IP和网关不在同一网段配置错误路由器的DHCP服务崩溃导致网关IP失效注意ping用的是ICMP协议它工作在网络层不经过传输层的端口。所以ping通只能证明网络层可达不代表你能访问网页那需要传输层的TCP 80端口开放。2.3 再向上传输层确认“运输通道”是否畅通如果网关ping通了但网页还是打不开问题大概率出在传输层。这时要用telnet或ncnetcat测试目标端口telnet www.baidu.com 80 # 或 nc -zv www.baidu.com 80如果返回Connected to...说明TCP三次握手成功80端口是开着的如果显示Connection refused或超时说明要么目标服务器没开Web服务要么你本地的防火墙/安全软件把出站连接给拦了。2.4 最顶层应用层检查“货物内容”是否合规最后一步才是真正的应用层问题。比如你ping得通telnet也连得上80端口但浏览器依然白屏。这时候就要怀疑浏览器缓存或DNS解析错误nslookup www.baidu.com看是否返回正确IP网站本身维护中HTTP状态码503你的代理设置被意外开启浏览器设置里的“使用代理服务器”这个自底向上的排查法就是OSI模型给你的最强武器。它强迫你把一个模糊的“上不了网”问题分解成7个或4个明确的、可独立验证的子问题。每一次ping或telnet失败都精准地告诉你问题出在哪一层接下来该查什么。这比盲目重启、重装驱动、重置网络效率高出十倍。我在某高校网络中心实习时导师教我的第一课就是“别当救火队员要当侦探。模型就是你的破案指南。”3. 思维导图核心结构拆解七层与四层的映射、差异与实战取舍一张好的思维导图绝不是把七层名字罗列出来就完事。它必须清晰展现各层之间的数据流向、封装关系、典型协议、以及最关键的——OSI与TCP/IP的对应逻辑。下面这张导图的核心骨架就是围绕这四个维度构建的。我们逐层拆解告诉你为什么这样画而不是那样画。3.1 OSI七层从“比特”到“应用”的完整闭环OSI模型的七层是一个从物理介质到用户界面的完整闭环。它的设计初衷是提供一个通用的、与具体技术无关的参考框架因此每一层都有非常明确的边界和职责层级名称核心职责典型设备/协议封装单元关键特征7应用层为用户提供网络服务接口HTTP, FTP, SMTP, DNSData用户直接交互如浏览器、邮件客户端6表示层数据格式转换、加密、压缩JPEG, MPEG, SSL/TLS部分Data解决“不同系统怎么读懂同一份数据”的问题如把EBCDIC码转ASCII5会话层建立、管理、终止会话NetBIOS, RPC, SIPData处理“对话管理”如断点续传、会话同步4传输层端到端可靠/不可靠传输TCP, UDP, SCTPSegment (TCP) / Datagram (UDP)核心分水岭TCP保证顺序和重传UDP只管发不保证到达3网络层逻辑寻址、路由选择IP, ICMP, ARP, OSPFPacket给全球每个设备分配唯一IP决定数据包“走哪条路”2数据链路层同一网络内节点间可靠传输Ethernet, Wi-Fi (802.11), PPP, MAC地址Frame处理物理地址MAC解决“怎么把包准确送到隔壁机器”1物理层比特流的物理传输电缆、光纤、集线器、中继器Bit纯硬件层“0”和“1”怎么用电压、光信号表示实操心得初学者最容易混淆的是网络层IP和数据链路层MAC。简单记IP地址是你的“全国身份证号”告诉全世界你是谁MAC地址是你的“小区门牌号”只在你家楼下那个小范围局域网里有效。路由器工作在网络层因为它要根据IP判断数据该发往哪个城市交换机工作在数据链路层因为它只认MAC负责把数据精准投递到你家楼下的那台电脑。3.2 TCP/IP四层工业界的极简主义胜利TCP/IP模型诞生于阿帕网ARPANET的实战需求它删繁就简把OSI中偏理论、在实践中常被合并的层做了整合TCP/IP层对应OSI层整合逻辑为什么这样整合应用层应用层 表示层 会话层把所有“用户看得见”的功能打包工程实践发现加密、压缩、会话管理往往由同一个应用如浏览器或库如OpenSSL统一处理没必要硬拆三层传输层传输层完全保留TCP/UDP是端到端通信的基石不可替代网络层网络层完全保留IP协议是互联网的DNA地位无可撼动网络接口层数据链路层 物理层把所有“怎么把数据送上物理线路”的细节打包无论是以太网、Wi-Fi还是PPP对上层IP来说只要能收发“帧”就行底层怎么实现IP不关心关键差异点OSI的“表示层”和“会话层”在TCP/IP里消失了它们的功能被下沉到了应用层协议内部。例如HTTPS HTTP应用层 TLS原本属于表示层现在是应用层的一个子协议。这种“务实主义”让TCP/IP模型异常坚韧——从1970年代的粗缆以太网到今天的5G和Wi-Fi 6只要IP协议栈还在上层应用几乎不用改。3.3 映射不是一一对应一张图看清本质关系导图中最容易被误解的部分就是试图给OSI每一层找一个TCP/IP的“一对一”对应。这是个陷阱。真实的关系是一对多、多对一的映射。导图用虚线箭头和颜色区块清晰标出了这一点OSI应用层→TCP/IP应用层直接对应OSI表示层 会话层→TCP/IP应用层功能被吸收OSI传输层→TCP/IP传输层直接对应OSI网络层→TCP/IP网络层直接对应OSI数据链路层 物理层→TCP/IP网络接口层功能被合并提示当你在Wireshark里看到一个数据包它的结构是Ethernet Header (L2)IP Header (L3)TCP Header (L4)HTTP Data (L7)。这里没有单独的“表示层头”或“会话层头”因为它们已经作为HTTP协议的一部分被封装在了HTTP Data里。这就是模型指导实践的铁证。4. 从零手绘一张高信息密度思维导图工具、结构与避坑指南一张能真正帮人理解的思维导图不是靠堆砌文字而是靠精准的层级、克制的关键词、以及体现逻辑关系的视觉符号。我试过不下十种工具从XMind到MindNode再到纯手绘最终沉淀出一套“三步高效法”。下面我就带你一步步用最基础的工具甚至一张白纸一支笔画出一张信息密度远超普通导图的专业级网络模型图。4.1 工具选型为什么推荐Draw.io而非XMind市面上主流思维导图工具大多为“树状结构”优化强调分支发散。但OSI/TCP/IP的本质是纵向分层横向映射它更像一个“七层蛋糕”或“四层金字塔”而不是一棵枝繁叶茂的树。XMind这类工具强行用“中心辐射”模式画分层会导致层与层之间距离过大无法体现“紧耦合”的封装关系映射关系如OSI L2/L1 → TCP/IP 网络接口层需要用大量弯曲连线图面混乱无法方便地添加表格、代码块等复合信息而Draw.io现为diagrams.net是一个开源的流程图/架构图工具它用“容器连接线”的方式天然适合画分层模型你可以用7个矩形框垂直堆叠完美模拟“七层”物理结构用不同颜色填充每个框一眼区分层级如物理层用深灰应用层用亮蓝用虚线箭头从OSI的L2/L1框指向TCP/IP的“网络接口层”框关系一目了然在每个框内用小号字体嵌入表格列出协议、封装单元、设备信息密度拉满实操步骤Draw.io新建空白图设置画布为A4竖版从左侧工具栏拖入7个“矩形”形状垂直排列间距均匀按住Ctrl键拖动可微调选中第一个矩形物理层填充色设为#333333深灰字体白色输入“1. 物理层\n• 封装Bit\n• 设备集线器、中继器”重复步骤3为其余六层设置不同颜色推荐色系物理层深灰、数据链路层浅灰、网络层蓝色、传输层绿色、会话层黄色、表示层橙色、应用层红色拖入一个大矩形放在右侧填充色#FFCC99暖橙标注“TCP/IP 四层模型”内部用4个更小的矩形垂直堆叠用“虚线箭头”工具从OSI的L2/L1框画线指向TCP/IP的“网络接口层”框从OSI的L5/L6/L7框画线指向TCP/IP的“应用层”框4.2 结构设计三层信息叠加拒绝文字堆砌一张优秀的导图信息应该分层呈现而不是一股脑塞进去。我采用“三层洋葱结构”第一层核心骨架7个彩色矩形框只写层号和名称如“7. 应用层”。这是视觉锚点让人一眼抓住主干。第二层关键属性在每个框内用•符号列出3个最核心的属性封装单元Bit, Frame, Packet...典型协议HTTP, IP, TCP...典型设备路由器、交换机...第三层深度注释在框的右下角用小号灰色字体10pt添加一句“灵魂注释”解释该层存在的根本原因。例如物理层旁注“没有它一切协议都是空中楼阁——比特流是所有数字通信的起点。”传输层旁注“TCP的三次握手是互联网‘可靠’二字的物理基石UDP的无连接则是实时音视频的生命线。”注意事项绝对不要在一个框里写超过5行文字。如果某个层协议太多如应用层有HTTP/FTP/DNS/SMTP就只写最典型的2个后面加“等”。导图的使命是建立认知框架不是当协议字典。4.3 避坑指南新手常犯的5个致命错误画导图不是艺术创作而是知识建模。我见过太多学员花了两小时画出一张“美得像海报”的图结果核心逻辑全是错的。以下是血泪教训总结的5个雷区错误把“协议”和“设备”混在同一层级正确做法协议是软件逻辑设备是硬件载体。它们属于同一层但角色不同。导图中应并列书写如“协议HTTP, DNS | 设备Web服务器, DNS服务器”。错误用“发送”“接收”描述层间关系正确做法层与层之间是“服务”与“被服务”的关系。上层请求下层提供服务下层向上层提供服务。例如“应用层请求传输层建立TCP连接”而不是“应用层发送数据给传输层”。错误忽略“封装”与“解封装”的动态过程正确做法在导图底部用一个横向箭头流程图补充“发送端应用数据 → 加表示层头 → 加会话层头 → 加传输层头 → 加网络层头 → 加数据链路层头 → 发送比特流”。这比单纯画七层静态框更能体现模型的活力。错误给OSI和TCP/IP画同样粗细的边框正确做法用加粗边框突出TCP/IP模型用细边框表示OSI模型。这直观传递一个信息TCP/IP是现实标准OSI是教学参考。避免给人“两者同等重要”的误导。错误不标注数据流向正确做法在OSI和TCP/IP两个模型之间画一条双向的、带箭头的粗线标注“数据封装发送”和“数据解封装接收”。这是整个模型的灵魂动作缺失它导图就只剩下一堆名词。5. 常见问题与排查技巧实录那些年我们踩过的分层认知坑在带新人、做培训的过程中我发现关于OSI和TCP/IP的疑问高度集中在几个“似是而非”的点上。这些问题看似简单但如果概念不清会在后续学习中埋下巨大隐患。下面我把最常被问到的6个问题结合真实排障案例掰开揉碎讲清楚。每一个答案都来自我亲手调试过的上百个网络故障现场。5.1 问题1为什么说“TCP是可靠的UDP是不可靠的”它们不都是在IP上面跑吗这是一个经典误区。很多人以为“可靠/不可靠”是指数据能不能发出去其实完全相反——它们都能发出去区别在于“发出去之后要不要管它死活”。TCP的“可靠”体现在它有一整套“售后服务”机制序列号Sequence Number给每个字节编号确保对方收到的数据是按顺序拼起来的。确认应答ACK接收方收到后必须回一个“我收到了序号X之前的所有数据”的报文。超时重传Retransmission发送方等不到ACK就认为丢了立刻重发。流量控制Window Size通过滑动窗口防止发送方把接收方的缓冲区撑爆。UDP的“不可靠”是主动选择的“轻装上阵”它只有一个简单的头部8字节里面只有源端口、目的端口、长度、校验和。发送方把数据扔给IP层就不管了。丢包乱序重复UDP一概不处理全交给上层应用自己想办法。实战案例某在线教育平台的直播课卡顿严重。抓包发现老师端用的是UDP推流学生端大量丢包。运维第一反应是“UDP不可靠赶紧换TCP”。但这是个灾难性决策——TCP的重传机制会让延迟飙升到数秒直播就彻底废了。正确解法是在UDP之上用前向纠错FEC或重传请求NACK这类应用层协议来弥补既保持低延迟又提升抗丢包能力。模型教会你的不是哪个协议“更好”而是哪个协议“更适合当前场景”。5.2 问题2ARP协议到底属于哪一层为什么Wireshark里它出现在“网络层”下面ARP地址解析协议是个“跨界者”它的行为完美诠释了“模型是指导不是枷锁”。严格来说ARP工作在网络层但服务于数据链路层。为什么需要ARP因为IP地址网络层是逻辑地址而数据要在局域网里真正跑起来必须知道对方的MAC地址数据链路层。IP包要封装成以太网帧就必须填上目标MAC。ARP怎么工作它发送一个“广播帧”Frame问“谁的IP是192.168.1.100请把你的MAC告诉我” 这个广播帧是用以太网L2的广播MACFF:FF:FF:FF:FF:FF发出去的但它携带的却是IPL3的查询信息。所以在Wireshark里ARP包被归类在“网络层协议”下是因为它的目的是为网络层服务但它在数据链路层完成广播是因为它必须依赖L2的广播能力。这再次印证分层是逻辑划分现实中的协议常常横跨多层解决具体问题才是王道。5.3 问题3HTTPS是在应用层还是在表示层TLS加密算哪一层这是OSI与TCP/IP模型差异最生动的体现。在OSI框架下TLSTransport Layer Security协议明确属于表示层因为它负责数据的加密、解密、压缩、格式转换——这正是表示层的本职工作。但在TCP/IP模型里TLS被当作应用层的一个子协议。你打开Chrome开发者工具看到的https://其底层是HTTP over TLS而TLS本身又运行在TCP之上。所以完整的协议栈是HTTP (App)→TLS (App sub-layer)→TCP (Transport)→IP (Network)。关键洞察TLS的“层归属”取决于你用哪个模型说话。考试时按OSI答“表示层”写代码、配Nginx、抓包分析时按TCP/IP思维把它看作应用层的安全增强模块。模型是工具不是教条。5.4 问题4为什么路由器工作在网络层而交换机工作在数据链路层这是网络设备选型的底层逻辑。记住一个黄金法则设备根据它所“看”的地址类型来决定工作在哪一层。路由器Router它收到一个数据包第一件事是拆开IP头部看里面的“目的IP地址”。然后查自己的路由表Routing Table决定把这个包转发到哪个下一跳IP。它完全不关心这个包的MAC地址是什么。所以它工作在网络层L3。交换机Switch它收到一个以太网帧第一件事是拆开帧头部看里面的“目的MAC地址”。然后查自己的MAC地址表CAM Table决定把这个帧从哪个物理端口转发出去。它对IP地址一无所知。所以它工作在数据链路层L2。验证实验在一台电脑上ping另一台同网段的电脑。用Wireshark抓包你会看到第一次ping时先发一个ARP请求广播获取对方MAC后续ping直接发ICMP包目的MAC就是对方的MAC源MAC是你的MAC。 这个过程中数据全程在交换机L2内部流转路由器L3根本没参与。这就是“同网段通信不经过路由器”的原理。5.5 问题5DNS查询到底是用UDP还是TCP为什么DNS是少数几个“双栈协议”它既可以用UDP也可以用TCP选择权在DNS客户端如你的操作系统。默认用UDP端口53因为绝大多数DNS查询如A记录查询响应数据很小512字节UDP的无连接特性让它更快、开销更低。强制用TCP端口53当响应数据太大如DNSSEC签名、AXFR区域传输或者UDP查询失败后重试时客户端会自动降级到TCP。排查技巧如果你的DNS解析特别慢先用dig tcp example.com强制走TCP看是否变快。如果TCP快而UDP慢问题很可能出在中间某个防火墙或ISP设备错误地截断或丢弃了大于512字节的UDP DNS响应包。这是个非常隐蔽但高频的生产环境问题。5.6 问题6手机连Wi-Fi时“获取IP地址中…”卡住是哪一层的问题这个现象太常见了背后是典型的DHCP协议故障它横跨网络层和应用层。DHCP动态主机配置协议的工作流程是经典的“DORA”四步Discover发现手机广播一个DHCP Discover包L2广播帧目的MACFF:FF:FF:FF:FF:FFOffer提供DHCP服务器通常是路由器回复一个DHCP Offer包单播但因还没IP实际也是广播Request请求手机再广播一个DHCP Request确认要这个IPAcknowledge确认服务器发DHCP Ack正式分配IP卡在“获取IP地址中…”意味着第一步Discover发出去了但没收到Offer。原因必然是物理层/数据链路层Wi-Fi信号太弱广播帧根本没送达路由器网络层路由器的DHCP服务没开或者地址池如192.168.1.100-192.168.1.200已耗尽设备问题手机的Wi-Fi芯片固件Bug无法正确处理DHCP广播。快速诊断用另一台设备如笔记本连同一个Wi-Fi看能否正常获取IP。如果可以问题在手机如果都不行问题在路由器或线路。6. 从模型到实战用Wireshark抓包亲眼见证“七层封装”的全过程再完美的思维导图也只是静态的蓝图。真正的顿悟发生在你第一次在Wireshark里亲眼看到一个HTTP请求是如何被一层层“穿上马甲”又在服务器端被一层层“剥开”的那一刻。下面我将带你完成一次完整的抓包实战用最真实的网络数据验证模型的每一个细节。你不需要是专家只需要一台能上网的电脑和15分钟专注时间。6.1 准备工作安装Wireshark与基础过滤访问官网https://www.wireshark.org/download/下载并安装最新版WiresharkWindows/macOS/Linux均有。安装时务必勾选“Install Npcap”Windows或“Chmod BPF device”macOS这是抓包的底层驱动。启动Wireshark你会看到一个网络接口列表如Wi-Fi、Ethernet。选择你正在上网的那个接口通常名字里有“Wi-Fi”或“无线”字样。点击左上角的蓝色鲨鱼图标Start开始捕获数据包。提示此时屏幕上会疯狂滚动各种包信息量巨大。我们先用一个过滤器聚焦到最核心的HTTP流量在顶部的过滤栏里输入http然后按回车。现在屏幕上只显示HTTP协议相关的包。6.2 抓取一个HTTP GET请求从浏览器到服务器的旅程打开你的浏览器访问一个简单的网站比如http://httpbin.org/get这是一个专门用于测试HTTP的公益网站。立刻切回Wireshark你会看到至少3-5个新出现的包。找到第一个标记为HTTP且 Info 列显示GET /get HTTP/1.1的包。这就是你的请求。右键点击这个包选择Follow→TCP Stream。这会弹出一个新窗口展示完整的TCP会话内容左边是客户端你的电脑发的右边是服务器httpbin回的。现在我们来“解剖”这个TCP Stream窗口里的第一行数据GET /get HTTP/1.1\r\n Host: httpbin.org\r\n User-Agent: Mozilla/5.0 ...\r\n Accept: text/html...\r\n \r\n这整段就是应用层L7的原始数据。它就是你浏览器构造的HTTP请求报文未经任何修改。6.3 逐层“剥洋葱”在原始包中定位每一层头部回到Wireshark主窗口重新选中那个GET /get包。在下方的“Packet Details”面板里你会看到一个树状结构。展开它你会看到Frame最顶层这是Wireshark捕获的整个数据帧包含捕获时间、帧长等元信息。它对应物理层L1的“比特流”在抓包工具里的表现形式。Ethernet II展开它看到Source: aa:bb:cc:dd:ee:ff和Destination: 11:22:33:44:55:66。这就是数据链路层L2的以太网帧头包含了源和目的MAC地址。Internet Protocol Version 4展开它看到Source: 192.168.1.100和Destination: 34.123.45.67。这就是网络层L3的IP头部包含了源和目的IP地址。Transmission Control Protocol展开它看到Source Port: 54321和Destination Port: 80。这就是传输层L4的TCP头部包含了端口号和序列号等。Hypertext Transfer Protocol展开它你终于看到了刚才在TCP Stream里看到的GET /get HTTP/1.1。这就是应用层L7的数据。关键发现你在这个包里看不到OSI的“表示层”和“会话层”头部。因为它们的功能如HTTP的字符编码、Cookie会话管理已经作为HTTP协议的一部分直接写在了Hypertext Transfer Protocol这个节点的数据里。这再次印证了TCP/IP模型的务实性——它把所有“用户相关”的逻辑都打包进了应用层。6.4 观察“三次握手”传输层的可靠性基石HTTP是基于TCP的所以在发送GET请求之前你的电脑和服务器之间必须先完成TCP的“三次握手”。在Wireshark的包列表里找到三个连续的包Info列分别是SYN你的电脑发给服务器请求建立连接SYN, ACK服务器回复同意建立连接ACK你的电脑确认连接建立选中第一个SYN包在“Packet Details”里展开Transmission Control Protocol你会看到Source Port: 54321你的随机端口Destination Port: 80服务器的HTTP端口Sequence number: 0初始序列号Flags: 0x002 (SYN)标志位SYN1这就是传输层L4为保障可靠连接所付出的第一步努力。没有这三次