企业官网建设流程全解析

TCP/IP五层网络模型这五个字，几乎每个做技术的人都背过：物理层、数据链路层、网络层、传输层、应用层。背完也就背完了，真正被问到“一个HTTP请求从浏览器发出去，中间到底被改写了多少次、加了几层头、在哪一跳被拆开”的时候，很多人还是会卡住。这篇东西不打算复述教材上的分层图，而是把传输过程这条线完整走一遍：从应用层交出一段字节流开始，到它变成电信号离开网卡，再到对端一层层剥回原始数据，中间每一步谁在动手、动了什么、为什么非得这么动。适合已经知道五层名字、但对其体运转机制还停留在“加个头”层面的读者，也适合那些在排查网络问题时经常不知道该怀疑哪一层的人。看完之后，至少在看到一次抓包、一条路由、一个MTU告警的时候，脑子里能自动对上号。

1. 把五层当成一条流水线：先搞清楚每一层各自签收什么

很多人学分层模型的第一步就走偏了，把五层理解成五个并列的模块，好像数据在每一层之间跳来跳去。实际不是。它更像一条单向流水线，数据从上层往下走的时候被逐层打包，每一层只关心自己那一段该写的信息，写完就交给下一道工序，绝不越界去管别人的事。这个“不越界”才是分层的全部价值所在。

1.1 分层的真正动机：让变化被关在各自的房间里

设想一下如果没有分层会怎样。应用程序要自己处理“对面那台机器的网卡是不是千兆”“中间经过了几台交换机”“丢包了要不要重发”这些事，任何一处硬件升级或链路变更都要改应用代码，这种系统没人维护得动。分层的做法是把这些关注点切开：应用层只管“我要传什么内容”，传输层只管“这段内容有没有完整送到、顺序对不对”，网络层只管“怎么从A找到B”，链路层只管“这一跳的物理邻接怎么把比特送过去”。

这么切的好处是变化被隔离。把机房从铜缆换成光纤，只动物理层和链路层，上面的IP地址和端口号一个都不用变；把IPv4升级成IPv6，主要动网络层，TCP和应用层的逻辑基本不动。反过来说，这也解释了为什么很多“网络问题”排查起来很别扭——问题现象出现在应用层（比如页面转圈），根因却可能埋在链路层（比如双工不匹配导致大量CRC错误）。现象所在的层和根因所在的层，经常不是同一层，这是后面所有排查思路的总纲。

还有一个常被忽略的点：分层是逻辑模型，不是物理隔离。同一台机器上，五层全部由内核协议栈和网卡驱动实现，数据在内存里被一次次的头部拼接和指针偏移处理掉，根本没有“五趟旅程”。你在抓包软件里看到的分层展开，是解析器按照协议号一层层猜出来的结构，不是内核真的分了五次搬运。

1.2 五层的PDU、地址与责任田对照

要理解传输过程，得先记住每层操作的“单位”叫什么、用的“地址”是什么。这两个东西一旦混淆，看抓包就会一头雾水。

这张表里最值得反复看的是地址那一列。端口号只在主机内部有意义，出了网卡就没人认；IP地址在整个互联网范围内有意义，但只在三层及以上有效；MAC地址只在同一个广播域内有效，跨了路由器就换一套。数据在传输过程中，源和目的IP通常是不变的（NAT场景除外），而源和目的MAC每过一跳就换一次。这一点如果没吃透，看到抓包里MAC地址和IP地址对不上就会怀疑人生。

1.3 封装不是抽象概念，它就是一次次加头和拷贝

所谓封装，落到实处就是：上层交下来一段内存，本层在它前面预留一块空间，填上本层的头部字段，然后把这整块内存往下交。TCP在应用数据前面加20字节（不含选项），IP再在TCP段前面加20字节，以太网再在前面加14字节帧头、后面加4字节FCS。一个1460字节的应用数据，最终在链路上是1514字节的帧（不含FCS）或者1518字节（含FCS）。

这里有个实操中很关键的细节：每次加头都可能触发内存拷贝，也可能不触发。现代内核协议栈为了性能会做“预留头部空间”（headroom），应用层写数据时就在缓冲区前面留出足够空间，TCP和IP直接往前面填，避免反复拷贝。这也是为什么某些高性能网络框架会自己管理缓冲区，而不是简单调用一次发送接口——它们省掉的是这一串拷贝开销，而不是什么玄学优化。

理解了流水线的方向，接下来的问题就自然了：这条流水线的第一站，应用层到底交给传输层什么东西？

2. 应用层交付给传输层的那一刻：端口、序号与三次握手

应用层看起来最“不像协议”，因为它就是程序本身。浏览器拼出一段HTTP请求文本，或者一个自研服务把结构体序列化成字节数组，这些内容在应用层眼里是有结构的，但在传输层眼里只是一串没有边界的字节流。这个认知差是后面无数问题的源头。

2.1 从HTTP文本到字节流：应用层其实什么都没做

以一次普通的HTTP请求为例，浏览器最终要发出去的东西大致是这样一段文本：请求行、若干头部字段、一个空行、可能的请求体。这段文本在应用层缓冲区里就是连续的字节。应用层调用发送接口时，只告诉内核三件事：往哪个套接字写、写多少字节、数据在哪。至于这些字节会被切成几段、每段多大、什么时候真正发出去，应用层一概不管，也管不了。

这就是为什么“一次发送”不等于“一次接收”。应用层写入了3000字节，TCP可能把它切成两段各1460字节加一段80字节发出去，对端可能一次性收到3000字节，也可能分三次收到。TCP提供的是有序的字节流，不是消息流，它不保留任何消息边界。这条性质几乎每年都会在技术社区被重新讨论一遍，因为它太反直觉了。

顺带说一句UDP。UDP同样不保证顺序和可靠性，但它保留消息边界：发一次收一次，收上来的数据报要么完整要么没有。所以对边界敏感、又不介意自己实现重传的场景（比如某些实时音视频、DNS查询），UDP反而是更自然的选择。选TCP还是UDP，本质上问的是“我要的是字节流还是消息流”，而不是“哪个更快”。

2.2 TCP头部逐字段拆解：哪些字段在传输过程中真的被用到

TCP头部固定部分20字节，加上最多40字节选项。字段不多，但每一个都在传输过程中承担具体职责，没有凑数的。

真正需要重点理解的是序号和确认号这一对。序号不是“第几个包”，而是“这个包里第一个字节在字节流中的偏移量”。假设初始序号是1000，第一段携带1460字节，那它的序号是1000，下一段的序号就是2460，而不是2。对端回的确认号是2460，意思是“2460之前的我都收到了，下一个我要2460开始的”。这个设计让TCP可以处理任意大小的数据流，也让它能天然支持重传和乱序重组——只要按序号拼回去就行。

窗口字段同样关键。它决定了发送方能连续发出多少数据而不等确认。窗口为0意味着接收方缓冲区满了，发送方必须停下等窗口更新。很多“连接卡住但没断”的现场，抓包里就是一路的零窗口探测，这个现象后面还会提到。

2.3 握手发生在数据之前：为什么必须先对齐序号

三次握手的意义在很多资料里被简化为“确认双方都能收发”，这话没错但不够。更准确的说法是：双方必须就初始序号达成一致，否则后续的字节流无法拼接。SYN包里携带的是己方的初始序号，对方用ACK确认这个序号，同时把自己的初始序号带过来，第三次ACK再确认对方的。三次交互结束，双方的发送序号和接收序号窗口都对齐了。

为什么不能两次？因为两次无法确认“己方发出的SYN对方确实收到了”，只能确认“对方发出的东西我收到了”。在不可靠信道上，任何单方向的确认都不足以让双方同时进入确定状态。这个论证在教材里讲得很细，实际排查中它的价值在于：如果你在抓包里只看到SYN没有看到SYN+ACK，问题很可能不在你的应用，而在路径上的某一跳——可能是防火墙拦截、可能是目的端口没监听、也可能是回程路由不通。

还有个小细节值得注意：握手阶段双方会交换MSS（最大段长度）选项，各自告诉对方“我这边能接收的单段最大是多少”。这个值和后面的分片问题直接相关，是下一节的主角。

3. 网络层接手：IP头部、路由查表与分片的真实代价

TCP段交给网络层的时候，网络层只关心一件事：把它送到目的IP。至于里面装的是HTTP还是数据库协议，它一概不看。这种“不关心载荷”的设计是IP层能承载一切的基础，也是它无法提供任何服务质量保证的原因。

3.1 IP头部里三个决定命运的字段

IPv4头部固定20字节，可选字段很少被使用。字段虽多，但真正影响传输过程走向的主要是三个。

第一个是TTL（生存时间）。每经过一台路由器减1，减到0就丢弃并发回ICMP超时报文。它的初衷是防止路由环路导致包永远转下去，实际用途却变成了两件事：一是 traceroute 靠它工作（发送TTL从1开始递增的探测包，看哪一跳返回超时），二是它能间接暴露路径长度。不同系统的默认TTL不一样，常见的是64和128，抓到包后看TTL的初始值能大致判断对面是什么系统，也能估算经过了几个路由（用默认值减去抓到的TTL）。当然这个判断并不可靠，因为路径上可能有设备改写TTL。

第二个是协议号。它告诉接收方“载荷交给谁”，6是TCP，17是UDP，1是ICMP。这是解封装时的关键索引，网络层剥掉自己的头部之后，靠这个字段决定把剩下的内容递给传输层的哪个模块。如果协议号被中间设备改了（极少见但存在），上层就会直接解析失败。

第三个是分片相关的一组字段：标识（Identification）、标志（Flags）、片偏移（Fragment Offset）。同一个原始包被切开后，所有分片共享同一个标识值，接收方靠它把碎片归拢到一起；标志位里的DF表示“不许分片”，MF表示“后面还有分片”；片偏移表示这个分片在原始包中的位置。这组字段是很多诡异问题的来源，下一小节专门说。

3.2 路由查表：最长前缀匹配与默认路由的兜底

IP包要发出去，第一步是查路由表决定从哪块网卡出、下一跳是谁。查表的规则叫最长前缀匹配：在所有匹配目的地址的条目里，选掩码最长（也就是最精确）的那一条。

举个例子，路由表里有这么几条：默认路由 0.0.0.0/0 指向网关A，10.0.0.0/8 指向网关B，10.1.0.0/16 指向网关C。现在要发往 10.1.2.3，三条里前两条都匹配（默认路由匹配一切，10.0.0.0/8也匹配），但 10.1.0.0/16 掩码最长，所以走网关C。这就是为什么默认路由永远排最后——它的掩码长度是0，匹配优先级最低。

实操中容易踩的坑是多网卡机器的路由选择。一台机器同时有内网网卡和公网网卡时，如果默认路由配错，回包可能从错误的网卡出去，对端看到源地址不对就直接丢弃，表现为“请求能到但响应回不来”。这类问题用ip route get <目的地址>一条命令就能验证，它会直接告诉你内核最终选了哪条路由、从哪个源地址发出，比对着路由表一条条算快得多。

路由查完之后，网络层把包交给链路层，同时给出下一跳地址。注意，网络层自己不知道下一跳的MAC地址，这是链路层要解决的事，两者的分工在这里体现得很清楚。

3.3 MTU、DF与分片：一个能让人查一晚上的问题

以太网的标准MTU是1500字节，指的是帧的数据部分最大长度，不含14字节帧头和4字节FCS。IP包要装进这个空间，所以IP包最大1500字节；IP头20字节，TCP头20字节，留给应用数据的空间是1460字节，这就是MSS的常见值。

问题出在路径上的某一段MTU更小的时候。比如经过一条隧道（IP-in-IP、GRE之类），外层要额外加20到60字节的头，内层能通过的包就变小了。如果发送方不知道这件事，发出1500字节的包，到了隧道入口就装不下，要么分片，要么丢弃。

这里有个经典陷阱：如果IP头里DF位被置1（不分片），设备就会丢弃该包并返回一条ICMP“需要分片但DF已置位”的消息。正常的协议栈收到这条消息会调小MSS重发，问题就自愈了。但如果路径上的防火墙把这类ICMP全屏蔽了（很常见的安全策略），发送方永远收不到通知，就会一直重发大包、一直失败，表现为“小请求正常，大请求卡死”“网页能打开但图片加载不出来”。这个现象在业界有个专门的说法，排查思路是拿ping手动测：

# 逐步试探路径上能通过的最大包，-M do 表示禁止分片，-s 指定数据部分长度 ping -M do -s 1472 192.0.2.10 ping -M do -s 1400 192.0.2.10 ping -M do -s 1200 192.0.2.10

1472 + 20（IP头）+ 8（ICMP头）= 1500，所以1472是标准以太网下的最大可测值。如果1472不通而1400通，说明路径MTU大概在1428到1500之间，把这个值减掉头部开销后配置到TCP的MSS上，问题基本就解决了。

顺带说一个常被搞混的概念：IP分片和TCP分段是两回事。TCP分段发生在传输层，由MSS控制，目的是适配MTU，属于正常行为；IP分片发生在网络层，是包已经太大又不得不发时的补救措施，属于异常行为。分片的代价在于：只要丢一个分片，整个原始包都要重传，而且分片会增加中间设备的处理负担。所以现代实践里，尽可能在传输层就避免分片，IPv6甚至直接取消了路由器分片，只允许源端分片。

4. 数据链路层的最后一百米：ARP、MAC与交换机的转发表

网络层把包和下一跳地址交给链路层之后，链路层面临一个非常具体的问题：下一跳的IP我知道，但要把帧发出去，得知道它的MAC地址。这个转换过程就是地址解析。

4.1 ARP：一次广播换一个MAC地址

ARP的工作方式很朴素：在本地广播域里喊一嗓子“谁是192.0.2.1，请把MAC告诉我”，广播帧的的目的MAC是全F。目标主机听到后单播回一个应答，带上自己的MAC。请求方把结果缓存起来，后续一段时间内直接用。

这个“缓存”是很多问题的温床。缓存有过期时间，也有容量上限；过期后要重新解析，解析期间发往该地址的包会排队或者丢弃；表满了会覆盖旧条目，导致频繁重新解析。更麻烦的是ARP缓存可能被错误信息污染——同一个广播域里如果有设备恶意或错误地宣称自己是某个IP，后续流量就会被引到错误的地方。这也是为什么跨网段的通信必须经过网关，而不是靠ARP直达——广播域被路由器隔开了，ARP请求根本过不去。

实操中一个高频现象是“服务刚迁移完，部分客户端访问异常，过几分钟自己好了”。原因往往就是客户端的ARP缓存里还留着旧机器的MAC，包还往旧地址发。清一下缓存立刻恢复：

# Linux ip neigh flush all # 查看当前邻居表 ip neigh show

4.2 交换机不看IP：转发表、泛洪与广播域

交换机工作在链路层，它维护一张“MAC地址 → 端口”的转发表。收到帧后，查目的MAC：查到了就从对应端口发出去（单播），查不到就向除入端口外的所有端口泛洪，同时学习源MAC和入端口的对应关系。这个过程完全不需要理解IP。

理解这一点对排查很有帮助。同网段内的两台机器通信，包根本不经过网关，也不经过路由，路径就是网卡→交换机→网卡。所以如果两台同网段机器不通，查路由表是没有意义的，应该查ARP、查交换机端口、查VLAN配置。反过来，跨网段不通，才轮到路由和网关登场。

广播域的概念也在这里。一次ARP广播会到达同一个VLAN内的所有主机，主机多了、广播频繁了，就会形成广播风暴，消耗大量带宽和CPU。划分子网、划分VLAN本质上是缩小广播域，把一个大的广播域切成若干小的，让广播只在局部传播。这也是为什么一个网段里塞几千台机器是自找麻烦。

4.3 出口处的地址改写：网关与NAT做了什么

当目的IP不在本网段时，包会被送到网关。这里有一个非常容易被忽视的细节：帧的目的MAC是网关的MAC，但IP包里的目的IP仍然是最终目标的IP。也就是说，链路层的地址被换掉了，网络层的地址没动。交换机看到的是“发给网关的帧”，路由器拆开后看到的是“发给某个远端IP的包”，两者各司其职。

如果出口处还做了地址转换（NAT），情况会再复杂一层。NAT设备会把内网源IP和源端口替换成自己的公网IP和某个端口，并记录一条映射关系，等回包到达时再按映射表改回去。这一改动的后果是：外网看到的所有流量来源都是同一个地址，内网主机的真实地址被隐藏了；同时，外网无法主动向内网发起连接，因为映射表里没有对应条目，包到了不知道往哪送。

这也解释了为什么端口号在NAT环境下变得格外重要——它不只是区分进程的标识，还承担了复用同一个公网地址的功能。映射表的容量和老化时间，直接决定了一台NAT设备能同时支撑多少连接。连接数一多，新连接建不起来，现象是“偶发握手失败”，很容易被误判成对端服务的问题。

5. 到达对端之后的解封装：剥离、重组与ACK的回程

前面所有内容都是“发”的过程。真正让传输闭环的是接收端的处理：一层层剥掉头部，把数据还原，然后回一个确认。这个过程不是发送过程的简单镜像，中间有很多只有接收方才会遇到的判断。

5.1 反向流水线：从帧到字节流的逐层剥离

网卡收到电信号，还原成比特，攒成帧。硬件先做FCS校验，不通过就直接丢弃，上层根本不知道有这回事——这也是链路层错误很难被应用感知的原因，你只会看到重传，看不到错误。校验通过后，检查目的MAC是不是自己（或者是广播/组播地址），不是就丢弃。

接着剥掉帧头，看类型字段：如果是IP，交给网络层；如果是ARP，交给ARP模块。网络层剥掉IP头，检查目的IP是不是自己，检查校验和，检查TTL，然后看协议号决定交给TCP还是UDP。传输层剥掉TCP头，按四元组找到对应的套接字，把数据放进接收缓冲区，按序号排序，然后唤醒等待的应用进程。

这一串动作里，四元组定位套接字是关键一步。源IP、源端口、目的IP、目的端口四个值共同确定一个连接。同一台服务器上，不同客户端连同一个端口，靠源IP和源端口区分；同一个客户端连同一个服务器的不同端口，靠目的端口区分。这也解释了为什么端口耗尽会发生在“客户端”侧——每个对外连接都要占用一个本地端口，端口数量有限。

5.2 乱序、重传与滑动窗口：可靠性到底靠什么撑住

TCP的可靠性不是靠“保证不丢”，而是靠“丢了能补”。具体机制是三件事配合：序号用于识别缺口，确认号用于告知进度，超时与重复确认用于触发重传。

接收方收到乱序的段时，不会丢弃，而是放进乱序队列，同时重复发送当前期望的确认号（也就是缺口的位置）。发送方连续收到三个相同的确认号，就认为该段丢了，立刻重传，这叫快速重传。如果确认号一直不推进又没有足够的重复确认，就等超时定时器到期再重传，这叫超时重传。两套机制并存，前者快，后者兜底。

滑动窗口负责效率。发送方不必每发一个段就停下来等确认，而是可以连续发出窗口大小范围内的数据，收到确认后窗口向前滑动。窗口大小由接收方通告，受限于接收缓冲区剩余空间。窗口太小会让带宽利用率上不去，窗口太大又会让缓冲区压力变大，所以现代协议栈会做窗口缩放（Window Scaling），在握手时协商一个缩放因子，把16位的窗口字段扩展成更大的值。

这里有个排查经验：如果抓包里看到大量“零窗口”通告，说明接收方应用读取太慢，缓冲区满了，问题在应用侧不在网络侧；如果看到大量重传但窗口正常，才需要怀疑链路质量。这两个现象长得很像，但根因完全在两个方向。

5.3 回程链路：一个ACK也要走完五层

确认包不是“免费”的。它同样要经过传输层封装（携带确认号和窗口）、网络层寻址（源和目的IP对调）、链路层找下一跳MAC，然后从网卡发出去。也就是说，每一次确认都在消耗双向的链路资源。

这个认知解释了几个现象。一是为什么高延迟链路上吞吐上不去——往返时间长了，确认回来得慢，窗口滑动得慢，即使带宽充足也跑不满。二是为什么双向都拥塞时情况会急剧恶化——数据方向拥塞导致确认延迟，确认延迟又导致发送方误判丢包而重传，重传进一步加剧拥塞。三是为什么某些单向大流量的场景要做确认合并或延迟确认——减少确认包的数量，把链路资源留给数据。

理解了完整的去程和回程，才算真正理解了“传输过程”这个说法。剩下的问题就是：怎么证明你说的这些真的发生了？答案是抓包。

6. 用抓包把分层变成看得见的证据

理论讲再多，不如看一次真实的包。抓包的价值在于，它把抽象的“封装”变成了可以逐层展开的结构，把“重传”变成了时间轴上的重复片段。但抓包也有讲究，抓错位置等于白抓。

6.1 抓包点选在哪里，决定了你能看到哪一层

抓包的位置不同，能看到的东西完全不同，这是很多人抓了半天看不出问题的原因。

在本机网卡上抓，看到的是已经封装完的帧，包含完整的以太网头、IP头、TCP头。但如果你抓的是回环接口（loopback），很多系统上不会走完整的链路层封装，帧头可能是伪造的或者干脆没有，看到的MTU也和物理网卡不一样。

在交换机镜像端口上抓，能看到整个广播域或者某个端口的全部流量，包括不是你本机的流量。这是排查“到底是对方没发还是我没收到”的最佳位置——如果镜像口上看到了包，本机没收到，问题在链路或本机；如果镜像口上压根没有，问题在发送方。

在路由器之间抓，看到的是经过NAT之后的地址，和两端的真实地址都不一样，很容易看晕。这种情况下最好同时在对端抓，两边对比着看。

一个实用建议：排查问题时尽量在两端同时抓包。单侧抓包最大的问题是无法区分“没发出去”和“没收到”，而双侧抓包一对比，丢包的区间立刻就被圈定了。

6.2 几条常用过滤器与真实输出的读法

抓包的原始输出信息量太大，必须靠过滤器缩小范围。下面几条是日常用得最多的：

# 抓指定主机和端口的流量，-nn 表示不做域名和端口名解析，-s 0 抓完整包 tcpdump -i eth0 -nn -s 0 'host 192.0.2.10 and tcp port 8080' -w cap.pcap # 只抓SYN包，用来看建连是否成功 tcpdump -i eth0 -nn 'tcp[tcpflags] & tcp-syn != 0' # 抓ICMP，用来看是否有不可达或超时 tcpdump -i eth0 -nn icmp # 实时看HTTP请求行（未加密的情况下） tcpdump -i eth0 -nn -A 'tcp port 80 and tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420'

最后那条看着吓人，其实逻辑很简单：先算出TCP头的实际长度（数据偏移字段乘以4），再从载荷起始位置取4个字节，和“GET ”的十六进制比较。这类表达式不需要背，用抓包工具的图形界面点几下就能生成。

抓到包之后怎么读，重点看三处：握手是否完成（SYN、SYN+ACK、ACK三个包是否齐全）、序号是否连续（有没有明显的空洞和重复）、时间间隔（相邻包之间的时间差是否异常）。这三处能覆盖大部分常见问题。

6.3 从抓包识别MTU问题、重传与RST

几个典型现象和它们的含义，值得记一下。

现象一：小包正常，大包发出去没有任何回应。大概率是MTU问题。特征是请求包发出去了，但对端没有任何ACK，也没有RST，就是沉默。这时候看请求包的大小，如果刚好在1400到1500之间，基本可以确认。处理方法前面提过，测出路径MTU后调整。

现象二：同样的序号反复出现，间隔逐渐拉长。这是超时重传的典型形态，间隔按指数退避增长。如果同时看到重复ACK，说明是快速重传。区分两者有助于判断是偶发丢包还是持续性链路问题。

现象三：连接被RST。RST表示强制关闭，可能来自对端应用崩溃、端口未监听、也可能是中间设备（比如负载均衡）主动断连。看RST的源地址就能大致判断是谁发的。如果是中间设备发的，往往伴随连接空闲超时，表现为“长时间不活动的连接下一次请求必失败”。

现象四：窗口一直是0。接收方缓冲区满了，应用没及时读。这时候看应用日志，八成是在做耗时操作阻塞了读取线程。

7. 分层图之外的实战经验：几个经常被误判的现象

理论走到这里已经闭环了，但实际工作中遇到的很多问题，症状和根因错位得厉害。下面这几个是反复出现的误判。

7.1 “粘包”从来不是TCP的问题

“TCP粘包”这个说法流传极广，但它本身是个错误命名。TCP是字节流协议，它本来就不保留消息边界，把两次写入的数据合在一起发，或者把一次写入拆成多次发，都是完全合法的行为。所谓粘包，本质是应用层没有定义消息边界。

解决办法全在应用层：要么用长度前缀（先发4字节表示消息体长度，再发消息体），要么用分隔符（比如换行、特殊字符），要么用固定长度。这三种方案各有适用场景：长度前缀最通用，二进制协议首选；分隔符简单直观，文本协议常用，但要求消息内容里不能出现分隔符，否则要转义；固定长度实现最简单，但浪费空间且不灵活。

选长度前缀时有个细节要注意：长度字段本身的字节序。大端小端在网络编程里必须约定清楚，否则一端按大端解析、另一端按小端发，长度会变成一个天文数字，然后就是一顿乱读。业界的惯例是网络字节序（大端），跨语言跨平台时按这个来最省事。

7.2 能ping通但业务不通，该往哪层怀疑

这是最经典的误判场景。ping用的是ICMP，走的是网络层，只要IP可达、ICMP没被拦，就能通。业务不通可能是传输层端口没监听、可能是应用层返回了错误、也可能是中间设备只放行了ICMP没放行TCP。

按层往下捋的思路是这样的：先确认传输层——用telnet或nc直接连端口，看能不能建立连接。连不上说明端口不通，可能是服务没起、可能是防火墙拦了、也可能是监听地址不对（监听在回环地址上，外部连不进来）。这一步能排掉一大半问题。

连得上但业务报错，问题就上到应用层了。这时候看服务日志、看返回的状态码、看请求内容是否符合预期。如果日志里什么都没有，说明请求根本没到达应用，那要回头查是不是被中间设备转发到了别的实例。

还有一类更隐蔽的情况：连接能建立，但数据传输到一半卡住。这种往往是MTU问题或者中间设备的会话超时。区分方法是看卡住发生在什么时机——如果是固定传输多少字节后卡住，怀疑MTU；如果是空闲一段时间后卡住，怀疑会话老化。

7.3 一份按层排查的清单

把上面的经验整理成一张表，遇到问题时从上往下过一遍，能省掉大量瞎猜的时间。

这张表不是万能的，但它提供了一个方向：先定位层次，再定位设备，最后定位配置。跳过层次直接猜配置，是最容易绕远路的做法。

写到这里，我自己在实际处理问题时感受最深的一点是：五层模型真正的用处不是用来背的，而是用来缩小怀疑范围的。每次遇到“网络不通”，脑子里过的第一个问题不该是“是不是防火墙”，而应该是“这个现象属于哪一层的问题，上一层有没有可能是根因”。把这条线走顺了，抓包、看路由、查ARP这些动作自然会串起来，而不是每次都在一堆命令里乱试。至于那些看起来玄学的“重启一下就好了”，多数时候也能用这套框架解释清楚——无非是某个缓存过期了、某个表项被刷新了、某条连接被重建了而已。