做网络工程师这些年我最大的感受是网络协议这东西只看书永远觉得懂了一上设备、一抓包就原形毕露。所以很早就想把手头这些协议笔记整理成一个系列标题就叫“网络协议-持续更新”。这个系列我会按“问题驱动”的写法来不打算照着教科书一章章念而是把一个协议放进真实的通信场景里说清楚它解决什么问题、报文长什么样、排查时怎么用再配上抓包验证。无论你是刚入门的学生、准备面试的求职者还是日常要跟网络打交道的运维开发应该都能从这套笔记里拿到能直接上手的思路。整个系列的核心思路是每个协议都回答三个问题——为什么要有它、它的关键机制是什么、出了问题怎么定位。下面的内容就是系列的第一篇先搭好框架再把几个最容易踩坑、也最常被问到的协议细节摊开来讲。1. 网络协议到底在解决什么问题1.1 为什么学网络协议这么痛苦很多人学协议学不下去不是因为笨而是因为这些东西太抽象。TCP、UDP、IP、ARP全都是看不见摸不着的逻辑概念你没法像拆一台服务器那样把它拆开看。好不容易把状态机背下来了真到抓包的时候面对一大堆十六进制报文还是不知道从哪里看起。我一开始也有这个问题后来才琢磨明白网络协议本质上就是通信双方提前约定好的一套“语法、语义和时序”。语法就是报文怎么组织、字段怎么排列语义就是每个字段代表什么意思时序就是谁先发谁后发、发完要等多久。只要抓住这三件事任何协议都逃不出这个框架。另一个让人痛苦的点是协议太多。打开Wireshark的协议列表几千个协议密密麻麻。真正常用的其实就那一二十个。学习的时候如果每个都想去啃肯定要崩。正确的策略是先掌握“链路层、网络层、传输层、应用层”这四个层面的主干协议其他的遇到再看。1.2 没有协议的世界会怎样我经常用一个寄快递的类比来跟朋友解释网络协议。你从北京寄一个包裹到上海要经历什么先把东西装进箱子这叫封装箱子上写收件人地址、电话这是网络层的IP地址快递公司给包裹贴面单、分拨到对应线路这是路由最后一公里配送员按门牌号找到你这是ARP通过IP找到MAC地址的过程。收件人拿到箱子一层层拆开包装最终看到里面的东西这就是解封装。整个过程里每一层只关心自己需要的信息不关心别的。寄件人不关心快递走的是公路还是航空快递公司不关心箱子里装的是手机还是书。如果哪天没有这些“封装规则”快递员拿着一张只写着“送到上海”的纸条肯定一脸懵。网络协议也一样没有大家共同遵守的格式一台服务器发出去的数据另一台服务器根本不知道该怎么解析。1.3 这个系列打算怎么持续更新叫“网络协议-持续更新”不是随便起的名字。网上的协议资料要么太零散要么太陈旧我想用一套统一的标准来写每个协议开头先讲清楚产生背景解决什么问题然后把报文结构、关键字段画出来结合Wireshark实际抓包来解释再做一次实验验证要么用命令行要么用抓包工具最后总结排查技巧和常见误区。这个框架定下来之后后面所有协议的文章都会按这个模板走。读者不需要从头追随便点开哪一篇都能独立看懂。遇到有联系的地方我会互相加链接指路慢慢形成一个能查的协议手册。2. 先从分层模型把网络协议“框”起来2.1 OSI七层和TCP/IP四层实战中哪个更重要学网络协议一定会遇到两套分层模型教科书爱讲OSI七层模型但实际互联网跑的是TCP/IP四层模型。很多人被这两个模型搞晕其实不用纠结实战中记TCP/IP就够OSI顶多用来做参考。TCP/IP四层可以理解为应用层负责产生和解析业务数据HTTP、DNS、FTP都在这层传输层负责端到端的可靠传输或高效传输主要是TCP和UDP网络层负责寻址和选择路径核心是IP协议网络接口层负责直接在物理链路上传数据包括以太网协议、ARP、VLAN等。OSI七层多出来的会话层、表示层现实中基本被应用层或传输层吞掉了。你抓包的时候看不到一个字段叫“会话层”所以没必要为了凑七层硬给自己增加负担。2.2 各层核心协议速查表我整理了一份自己常用的速查表。每次排查网络问题先判断问题落在哪一层再决定看哪个协议的报文。层级核心协议默认端口一句功能描述应用层HTTP80网页传输的明文协议应用层HTTPS443网页传输的加密协议应用层DNS53把域名解析为IP地址应用层DHCP67/68自动分配IP地址应用层FTP20/21文件传输应用层SSH22远程登录和加密管理应用层SMTP/POP3/IMAP25/110/143邮件收发传输层TCP——面向连接、可靠、字节流传输层UDP——无连接、不可靠、高效网络层IP——逻辑寻址和路由选择网络层ICMP——报错与探测ping就靠它网络层ARP——根据IP找MAC地址链路层以太网——局域网的封帧格式这张表的价值不在于背下来而在于当你说“网页打开慢”的时候心里立刻能过一遍可能是HTTP请求被卡住可能是TCP握手延迟也可能是DNS解析超时。每一层都有对应的排查工具后面我会专门讲。2.3 一次HTTP请求在分层模型里的完整旅程把整个过程串起来看会特别直观。假设你在浏览器输入www.example.com并按回车应用层发起DNS解析请求这个请求通常是UDP报文拿到目标IP后浏览器发起HTTP请求传输层用TCP封装加上源端口和目的端口默认443或80网络层给TCP报文加上IP头里面写着源IP和目标IP发送前系统通过ARP广播询问“这个目标IP对应的MAC地址是谁”链路层把IP报文再封装成以太网帧通过网卡发出去沿途每台路由器的处理其实只到网络层它会看IP头决定下一跳怎么走到达目标服务器后再逐层剥掉以太网头、IP头、TCP头把HTTP请求交给应用程序处理服务器返回响应又走一遍同样的封装和解封装流程。这就是常说的“层层封装、层层解封装”。你如果抓包看一个完整的HTTPS请求会看到至少三种协议DNS查询、TCP三次握手、TLS握手和HTTP数据流。把这些流程看熟了后面分析任何协议都能按图索骥。3. 面试和实战里最常见的协议细节3.1 三次握手为什么不能省成两次说个现象去面试网络岗位十个人里至少有八个能背出“三次握手”但你再追问一句“为什么不能只握两次手”一半人当场卡壳。三次握手的过程是客户端先发SYN服务端回SYNACK客户端再回ACK。关键点在于第二次握手时服务端其实同时干了两件事一是回复客户端的SYN表示“你的请求我收到了”二是自己也发起一个SYN表示“我想跟你建立连接”。所以第三次握手是客户端专门用来确认“我收到服务端的SYN了”。如果只有两次握手会出现一个经典的“历史重复连接”问题。假设客户端第一个SYN在网络里卡了很久客户端等不及又发了一个新的SYN结果旧SYN先被服务端收到。服务端傻乎乎地回了SYNACK占用资源建立连接但客户端根本没有这个请求意图连接就浪费了。有了第三次握手客户端可以在收到SYNACK后判断这个连接是不是自己期望的如果是旧的就发RST把它断掉。TCP是全双工协议数据可以双向独立传输所以断开时也要双向独立确认这就是为什么挥手要四次。每次学到这里我都会建议抓一次真实的关闭过程不要只在纸上画箭头。你会在抓包里看到FIN和ACK交替出现比背书清楚得多。3.2 一道高频CSMA/CD计算题全网最常见的那种CSMA/CD现在虽然不如以前普及但面试和考试依然喜欢出它的计算题。最典型的一道就是热词里那个版本a、b两站相距4km信号在网络上的传播速度为200000km/s求这个以太网的最短帧长。第一步是把物理参数换算成时间。两站相距4km传播速度是200000km/s所以单向传播时延是4 ÷ 200000 0.00002s 20μsCSMA/CD的关键是“边发边听”。发送站在发送过程中如果检测到冲突必须继续发一段时间确保其他站也能检测到。检测一个冲突最坏需要多长时间就是信号从A传到B再让B的冲突信号传回A也就是两个单向时延即2τ。2τ 2 × 20μs 40μs所以最短帧长必须保证发送时间 ≥ 2τ否则发送站可能已经把这个短帧发完了冲突信号还没传回来它就会误以为发送成功。如果网络数据率是10Mbps那么最短帧长为10 × 10⁶ bps × 40 × 10⁻⁶s 400bit400bit换算成字节就是50字节。但实际以太网标准是64字节原因是标准里考虑了中继器等设备带来的额外延迟还留了安全余量。所以考试时如果题目给了4km和10Mbps答案写400bit或50字节同时记得说明实际以太网取64字节是因为有余量这就非常加分。这类题最常见的变形是反过来问给定数据率和最小帧长求两站之间的最大距离。公式就变成L_min R × (2 × d ÷ v)把L_min、R、v代进去算d就行。要注意单位速率经常是Gbps距离经常是km传播速度经常是200000km/s或2×10⁸m/s别搞混算之前先统一成相同单位。3.3 网络协议分析时到底在看什么说到“网络协议分析”很多人以为就是把包抓下来然后肉眼盯着一堆十六进制数字硬看。其实不是。正确姿势是带着问题去抓包抓完先用统计和过滤工具缩小范围。我在排障时一般分三步。第一步用tcpdump或Wireshark抓完整流量保存成pcap文件第二步用Wireshark的“统计-协议分级”看各协议占比哪个协议流量异常大就怀疑哪个第三步针对目标流量设置过滤表达式比如tcp.port 443或http.request然后逐包看关键字段。看TCP时主要看Sequence Number和Acknowledgment Number这两个数字能直接反映数据有没有丢、有没有重传。如果Acknowledgment Number反复出现同一个值说明对端没收到新数据可能正在重传。看HTTP时先找请求行和状态码500对应服务端问题404对应路径问题301重定向则要检查Location是否指向正确。看DNS时重点看响应里返回的IP是不是符合预期如果被解析到一个奇怪地址就要怀疑域名劫持或本机hosts文件。一个能提高效率的小技巧是打开Wireshark后先设置“着色规则”TCP重传的包默认是黑色RST的包是红色。一眼扫过去如果满屏彩色斑块红黑交替这个网络的可靠性大概率有问题。4. 二层网络里的重要演进从STP到SPB4.1 STP的痛点环路必须防但代价不小局域网里为了防止单点故障通常会设计冗余链路。可一旦有物理环路二层广播帧就会无限循环造成广播风暴和MAC地址表抖动。传统的解决办法是STP生成树协议它通过阻塞某些冗余端口把物理环路修剪成逻辑无环的树状结构。STP够用但有两个毛病。第一个是带宽浪费明明有多条物理链路STP只保留一条主路径其余全部阻塞花钱买的带宽闲置第二个是收敛慢拓扑发生变化时STP要经历Listening、Learning等状态往往需要几十秒才能恢复这个时间对现代数据中心来说太长了。后来有了RSTP和MSTP收敛速度加快了但“有链路被阻塞”的本质没变。4.2 SPB的出现和它的思路SPB全称Shortest Path Bridging也就是最短路径桥接标准是IEEE 802.1aq。它的思路跟STP完全不同不再刻意阻塞链路而是让所有链路都参与转发。SPB用IS-IS协议作为控制平面让二层网络里的所有交换机互相交换链路状态信息每一台交换机都能算出到其他节点的最短路径。因为有多条等价路径它天生支持ECMP等价多路径数据流量可以哈希到多条链路上带宽利用率大大提高。拿STP、RSTP和SPB做个对比特性传统STPRSTPSPB控制平面BPDU协商BPDU协商IS-IS链路状态转发路径单路径单路径最短路径等价多路径冗余链路被阻塞被阻塞全部可用收敛时间秒级秒级以内更快扩展性一般一般适合大规模大二层SPB在一些数据中心和园区网场景里已经开始落地。它解决的核心问题就是“既要冗余可靠又要所有带宽都能跑流量”。如果你接触过VXLAN会发现SPB和它的目标有些相似都是想把二层网络做得更灵活只是实现路径不同VXLAN偏向在IP网络上用overlaySPB偏向在二层直接用最短路径桥接。4.3 老牌协议和新协议并存我看到的趋势市面上还有很多存量网络跑的是STP/RSTP尤其在传统企业网里短期内不会被替代。但在数据中心接入层、园区核心层SPB这样的新协议会越来越多。原因是现代业务对带宽和收敛速度的要求越来越高让链路闲着不转发老板也不答应。作为工程师不必一上来就追所有新协议可以先吃透STP理解环路问题为什么存在再去看SPB怎么解决会容易得多。这也是我在系列里坚持“先问题后方案”的原因。接下来这个系列会继续覆盖VXLAN、EVPN、Segment Routing等大二层和数据中心相关协议每一篇都会用同样的思路去拆解。5. 排查网络协议的实用工具与踩坑心得5.1 抓包工具怎么选怎么用我电脑里常年装着两套抓包工具命令行下有tcpdump图形界面用Wireshark。tcpdump的优势是轻量、能在没有图形界面的服务器上直接抓Wireshark的优势是过滤和分析直观。几个常用的tcpdump命令# 抓eth0网卡上的全部流量保存到文件 tcpdump -i eth0 -nn -s0 -w /tmp/capture.pcap # 只抓某个主机的TCP 80端口流量 tcpdump -i eth0 -nn host 192.168.1.10 and tcp port 80 # 抓ARP报文 tcpdump -i eth0 -nn arp抓完文件用Wireshark打开过滤表达式可以这样写ip.addr 192.168.1.1只看这个IPtcp.port 443只看443端口流量http.request只看HTTP请求报文tcp.flags.syn 1只看SYN包dns.qry.name contains example.com只看特定域名的DNS查询一个容易忽略的点Linux下抓包需要root权限抓包网卡建议开混杂模式否则你只能看到发给自己网卡的数据包看不到整个链路上的流量。5.2 一次完整的网络问题排查思路没有固定不变的排查手册但我习惯从下往上排查也就是“物理层、链路层、网络层、传输层、应用层”的顺序。第一步先确认链路层和物理层通不通。用ip link show看网卡状态用ethtool eth0看速率和双工模式。之前遇到过一台服务器网卡协商成千兆半双工速率掉一半排查半天才发现是双工不匹配。第二步确认三层连通性。ping是万能的起点但不代表ping通就万事大吉。ICMP可达只能证明网络层通TCP端口和应用层是否正常要再往下测。第三步用traceroute看路由路径。如果某个中间跳延迟很高问题可能出在路径上。不过很多设备默认不回应探针包看到* * *不一定是故障。第四步验证TCP端口。用nc -vz 192.168.1.10 80测端口通不通。端口不通时再判断是防火墙挡了还是服务没起来。第五步测应用层。用curl -v http://example.com看完整交互过程或者dig example.com检查DNS解析结果。这套流程走下来大部分问题都能定位到具体层次。记住一个原则不要把时间浪费在猜上抓包能解决百分之八十的争论。5.3 我踩过的几个典型坑提前帮你避开第一个坑是MTU问题。有次客户反馈“网页打不开但ping服务器是通的”我抓包发现HTTP大包全部没回来小包没问题。原因就是链路MTU设置不一致ICMP小包能过TCP带大数据段的包被中间设备丢弃。后来直接把MTU调成一致的数值问题立刻消失。不是所有网络故障都是协议错误物理参数也可能变成瓶颈。第二个坑是分析抓包时没注意到TCP窗口缩放。Windows和Linux默认都开启了Window Scaling如果抓包软件不识别这个选项看到的接收窗口会被严重低估从而误判为网络吞吐有问题。抓包分析的时候先看一眼TCP Option里的Window Scale值再算真实窗口。第三个坑是把自己的流量和业务流量混在一起。有次我在服务器上抓包忘过滤本机监控程序的流量结果统计出来的协议占比完全失真。从那以后凡是要分析业务流量我都会先写过滤条件把已知噪音排除掉。踩过这些坑之后我慢慢养成一个习惯每学一个协议都亲手抓一条对应的真实流量对照报文去理解字段。协议这东西停留在纸面上永远隔一层抓过包、排过错才算是真正握在手里。最后分享一个小技巧平时可以在自己电脑上开Wireshark抓几百个包然后用协议分级统计看看占比。你会发现一个设备上网时很多背景流量和你想的完全不一样。这个“清理噪音”的过程本身就是理解网络协议很好的入门训练。这个系列我会持续更新下去下一篇计划重点拆TCP重传与拥塞控制的实际表现咱们到时候接着聊。