企业官网建设流程全解析

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 /all（Windows）或ifconfig（macOS/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或nc（netcat）测试目标端口：

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模型的七层，是一个从物理介质到用户界面的完整闭环。它的设计初衷是提供一个通用的、与具体技术无关的参考框架，因此每一层都有非常明确的边界和职责：

实操心得：初学者最容易混淆的是网络层（IP）和数据链路层（MAC）。简单记：IP地址是你的“全国身份证号”，告诉全世界你是谁；MAC地址是你的“小区门牌号”，只在你家楼下那个小范围（局域网）里有效。路由器工作在网络层，因为它要根据IP判断数据该发往哪个城市；交换机工作在数据链路层，因为它只认MAC，负责把数据精准投递到你家楼下的那台电脑。

3.2 TCP/IP四层：工业界的极简主义胜利

TCP/IP模型诞生于阿帕网（ARPANET）的实战需求，它删繁就简，把OSI中偏理论、在实践中常被合并的层做了整合：

关键差异点：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）：

1. 新建空白图，设置画布为A4竖版
2. 从左侧工具栏拖入7个“矩形”形状，垂直排列，间距均匀（按住Ctrl键拖动可微调）
3. 选中第一个矩形（物理层），填充色设为#333333（深灰），字体白色，输入“1. 物理层\n• 封装：Bit\n• 设备：集线器、中继器”
4. 重复步骤3，为其余六层设置不同颜色（推荐色系：物理层深灰、数据链路层浅灰、网络层蓝色、传输层绿色、会话层黄色、表示层橙色、应用层红色）
5. 拖入一个大矩形，放在右侧，填充色#FFCC99（暖橙），标注“TCP/IP 四层模型”，内部用4个更小的矩形垂直堆叠
6. 用“虚线箭头”工具，从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个雷区：

1. 错误：把“协议”和“设备”混在同一层级

   • 正确做法：协议是软件逻辑，设备是硬件载体。它们属于同一层，但角色不同。导图中应并列书写，如“协议：HTTP, DNS | 设备：Web服务器, DNS服务器”。

2. 错误：用“发送”“接收”描述层间关系

   • 正确做法：层与层之间是“服务”与“被服务”的关系。上层请求下层提供服务，下层向上层提供服务。例如：“应用层请求传输层建立TCP连接”，而不是“应用层发送数据给传输层”。

3. 错误：忽略“封装”与“解封装”的动态过程

   • 正确做法：在导图底部，用一个横向箭头流程图补充：“发送端：应用数据 → 加表示层头 → 加会话层头 → 加传输层头 → 加网络层头 → 加数据链路层头 → 发送比特流”。这比单纯画七层静态框，更能体现模型的活力。

4. 错误：给OSI和TCP/IP画同样粗细的边框

   • 正确做法：用加粗边框突出TCP/IP模型，用细边框表示OSI模型。这直观传递一个信息：TCP/IP是现实标准，OSI是教学参考。避免给人“两者同等重要”的误导。

5. 错误：不标注数据流向

   • 正确做法：在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 问题2：ARP协议到底属于哪一层？为什么Wireshark里它出现在“网络层”下面？

ARP（地址解析协议）是个“跨界者”，它的行为完美诠释了“模型是指导，不是枷锁”。严格来说，ARP工作在网络层，但服务于数据链路层。

• 为什么需要ARP？因为IP地址（网络层）是逻辑地址，而数据要在局域网里真正跑起来，必须知道对方的MAC地址（数据链路层）。IP包要封装成以太网帧，就必须填上目标MAC。
• ARP怎么工作？它发送一个“广播帧”（Frame），问：“谁的IP是192.168.1.100？请把你的MAC告诉我！” 这个广播帧，是用以太网（L2）的广播MACFF:FF:FF:FF:FF:FF发出去的，但它携带的却是IP（L3）的查询信息。

所以，在Wireshark里，ARP包被归类在“网络层协议”下，是因为它的目的是为网络层服务；但它在数据链路层完成广播，是因为它必须依赖L2的广播能力。这再次印证：分层是逻辑划分，现实中的协议常常横跨多层，解决具体问题才是王道。

5.3 问题3：HTTPS是在应用层，还是在表示层？TLS加密算哪一层？

这是OSI与TCP/IP模型差异最生动的体现。在OSI框架下，TLS（Transport 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 问题5：DNS查询，到底是用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”四步：

  1. Discover（发现）：手机广播一个DHCP Discover包（L2广播帧，目的MACFF:FF:FF:FF:FF:FF）
  2. Offer（提供）：DHCP服务器（通常是路由器）回复一个DHCP Offer包（单播，但因还没IP，实际也是广播）
  3. Request（请求）：手机再广播一个DHCP Request，确认要这个IP
  4. Acknowledge（确认）：服务器发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与基础过滤

1. 访问官网https://www.wireshark.org/download/，下载并安装最新版Wireshark（Windows/macOS/Linux均有）。
2. 安装时，务必勾选“Install Npcap”（Windows）或“Chmod BPF device”（macOS），这是抓包的底层驱动。
3. 启动Wireshark，你会看到一个网络接口列表（如Wi-Fi、Ethernet）。选择你正在上网的那个接口（通常名字里有“Wi-Fi”或“无线”字样）。
4. 点击左上角的蓝色鲨鱼图标（Start），开始捕获数据包。

提示：此时屏幕上会疯狂滚动各种包，信息量巨大。我们先用一个过滤器，聚焦到最核心的HTTP流量：在顶部的过滤栏里，输入http，然后按回车。现在，屏幕上只显示HTTP协议相关的包。

6.2 抓取一个HTTP GET请求：从浏览器到服务器的旅程

1. 打开你的浏览器，访问一个简单的网站，比如http://httpbin.org/get（这是一个专门用于测试HTTP的公益网站）。
2. 立刻切回Wireshark，你会看到至少3-5个新出现的包。找到第一个标记为HTTP且 Info 列显示GET /get HTTP/1.1的包。这就是你的请求。
3. 右键点击这个包，选择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)（标志位，SYN=1）

这就是传输层（L4）为保障可靠连接，所付出的第一步努力。没有这三次