📚 课程目录第2章网络基础回顾

网络基础回顾：TCP/IP协议栈、OSI模型、数据包结构

做网络抓包这几年，最深的体会是：层没搞透，抓到的包就是一堆乱码。我刚入行时拆过一例诡异丢包，折腾三天才发现是MTU分段没对齐。嗯，从那以后每次看包前都会先默背一遍分层模型。

这一节我会把TCP/IP协议栈、OSI参考模型、还有实际抓包看到的数据包结构串起来讲。不搞空洞的理论，只聊你我在Wireshark里真会撞上的东西。

OSI模型：七层，教科书上的理想乡

OSI模型是国际标准化组织（ISO）在1984年提出的概念框架，一共7层。说实话，现实项目里很少直接拿它当协议实现，但它的分层思想——每层只管自己的事，上下层通过接口通信——是所有网络排错的思维锚点。

我个人习惯把OSI七层记成一个口诀：“物链网传会表应”，对应物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。下面这张表列了一下每层的核心职责和常见协议：

层号	名称	核心职责	常见协议/设备
7	应用层	用户交互接口	HTTP、FTP、SMTP、DNS
6	表示层	数据格式转换、加解密	SSL/TLS、JPEG、ASCII
5	会话层	建立/管理/终止会话	NetBIOS、RPC
4	传输层	端到端可靠传输	TCP、UDP
3	网络层	路由寻址、分组转发	IP、ICMP、ARP（跨层常用）
2	数据链路层	帧封装、介质访问控制	Ethernet、Wi-Fi（MAC子层）
1	物理层	比特流传输、电气特性	网线、光缆、集线器

小经验： 实际排错时，我基本只关心L2～L4。L5～L7在TCP/IP里被合并到应用层，你看到的HTTP、DNS、TLS握手都属于这一层。

TCP/IP协议栈：五层，抓包时面对的活模型

TCP/IP模型是事实标准。它比OSI更精简，我把常用的五层模型画出来：

物理层：比特流。你插的网线、Wi-Fi信号都归它。抓包时这一层是透明的。
数据链路层：以太网帧头。看到MAC地址就对了。Wireshark里叫“Ethernet II”。
网络层：IP包。源IP、目标IP、TTL、协议类型。抓包跳不过的一层。
传输层：TCP/UDP段。端口号、序列号、确认号。异常重传都看这里。
应用层：Payload。HTTP请求、DNS查询、TLS证书。你最终要分析的业务数据。

你想想看，OSI的会话层和表示层在TCP/IP里去哪了？它们被塞进了应用层。比如TLS握手，它既做会话管理又做加密，实际工作在传输层之上，我们通常把它归为应用层协议。

两种模型的关系（配一张图）

为了帮大家把这两个模型对应起来，我专门画了一张对照图。左边是TCP/IP五层，右边是OSI七层，箭头标出了映射关系。记住这个对应，以后看任何网络资料都不会分层混乱。

重点抓住： 抓包时我们看到的“帧 → IP → TCP/UDP → 应用数据”这个堆叠，就是数据链路层→网络层→传输层→应用层的顺序。每一层给上层加头信息（封装），下层拆掉自己的头再往上送。

数据包结构：抓包时实际看到的样子

好，理论对应完了，我们直接看一个真实的TCP数据包在Wireshark里的样子。我用伪代码把各层头部的关键字段列出来，方便你对照着看：

// 以太网帧头部（14字节）
[
  DestMAC (6B)  |  SrcMAC (6B)  |  EtherType (2B)  // 0x0800 = IP
]

// IP头部（20字节，无选项）  
[
  Version (4b) | IHL (4b) | DSCP (6b) | ECN (2b)
  Total Length (16b)
  Identification (16b) | Flags (3b) | Fragment Offset (13b)
  TTL (8b) | Protocol (8b)  // 6=TCP, 17=UDP
  Header Checksum (16b)
  SrcIP (32b) | DestIP (32b)
]

// TCP头部（20字节，无选项）
[
  SrcPort (16b) | DestPort (16b)
  Sequence Number (32b)
  Acknowledgment Number (32b)
  Data Offset (4b) | Reserved (6b) | Flags (6b) // SYN,ACK,FIN,RST...
  Window Size (16b)
  Checksum (16b) | Urgent Pointer (16b)
]

// 应用数据（Payload）
[
  HTTP请求/响应 / DNS报文 / TLS握手...
]

我的查看习惯： Wireshark点开任意TCP包，下面解码区会直接给三个折叠块：

Ethernet II：看MAC，确认是否跨子网。
Internet Protocol Version 4：看IP、TTL、协议类型。
Transmission Control Protocol：看端口、SEQ、ACK、标志位。

你只要记住每一层头部偏移的字节数，就能用十六进制裸数据推导出问题，这在没有Wireshark的极端场景下极有用。

实际抓包怎么看？学两招排错技巧

我记得有一次线上接口报超时，同事盯着应用日志看了俩小时没结果。我让他直接拿tcpdump在服务器上抓20秒，然后导到Wireshark里看TCP握手。结果发现客户端发了SYN后服务器回了SYN+ACK，但客户端没回最后的ACK——典型的半连接队列满了。这就是TCP三次握手在传输层的证据，你光看应用层日志根本看不到。

给你几个排错时的快速定位点：

丢包：看TCP重传（Wireshark里标记为[TCP Retransmission]）。如果大量重传，查网络层路由或MTU。
时延高：看TCP握手时间（SYN→SYN+ACK间隔）和应用响应时间（请求发出到第一个数据包）。
连接被重置：看RST标志。谁发的RST？如果服务器发，可能是应用层主动关闭或防火墙注入。
数据乱序：看SEQ号是否跳变，或者Wireshark提示[TCP Out-of-Order]。

避坑指南：我踩过的三个分层陷阱

说几个我当年栽过的跟头，你听了能省至少一周的排查时间。

陷阱一：ARP是网络层？不对。

我曾经在面试时把ARP归为网络层，结果被打脸。ARP报文是封在以太网帧里的，靠广播MAC地址寻址，工作在数据链路层。虽然它和IP有千丝万缕的联系，但它的帧头不经过IP层。

陷阱二：TCP校验和出错≠应用层问题。

有一次我们线上延迟告警，看应用日志一切正常。我抓包一看，TCP校验和全是红色（Bad checksum）。一开始以为是网卡硬件坏了，后来查出来是虚拟机网卡开启了Task Offload，网卡自己算校验和但tcpdump截到的数据是分片前的，导致校验和字段看起来不对。把Offload关掉，世界清静了。

陷阱三：MTU怎么测都不对？查ICMP。

公司之前搬家后，某个子网总出现大包丢包，ping大包却能通。我猜是中间设备Do-not-Fragment标记位不一致。用ping -M do -s 1472测MTU，一路追查到核心交换机才发现有个ACL把ICMP不可达消息给过滤了。那之后我学乖了：测试MTU不要只用ping，还要在防火墙侧抓ICMP目的不可达（Type 3, Code 4）的包。

好了，网络基础回顾就到这。你带着这些分层视角再看抓包，就像戴了透视眼镜——每一层头的含义都会在你脑海里变成可操作的信息。后面几节我们会用真实的异常包案例一层层解剖，到时候你会发现，今天打的地基，就是明天排查的倚仗。