R6bandito Hexo https://r6blog.online/img/logo.svg https://r6blog.online/ All rights reserved 2026, R6bandito R6bandito 的笔记 2026-10-08T07:15:10.251Z R6bandito 前言

前面已经梳理了同处于网络层的ARP地址解析协议和ICMP控制报文协议。这些协议都是为了辅助网络层最核心的IP协议而诞生的。网络层的IP协议可以说是整个TCP/IP协议栈的“半壁江山”，是构建起互联网环境的重要一环。

什么是IP协议

IP协议又叫作网际协议，核心定位是负责将网络数据包从源主机端尽可能的运送到目标主机端。IP协议有一个很特殊的地方：位于网络层上接TCP/UDP等高层协议，下接Ethernet等底层通信链路，这就体现了IP协议一个很重要的作用——屏蔽底层不同链路的实现差异，为协议上层及应用层提供统一的标准接口。

需要知道，网络底层链路不只有Ethernet以太网一种，老式的PPP拨号上网、Wi-Fi、移动网络(4G/5G)等等这些都是不同的底层链路协议，而不同协议之间根据适用场景不同往往差距是比较大的。如果没有IP协议，那么上层需要为每一个网络链路定制一套自身的逻辑，类似于这种：

HTTP on Wi-Fi.

HTTP on Ethernet.

HTTP on 4G/5G.

….

这显然不规范，而且没有统一标准各自实现起来十分复杂。

而IP协议正好解决了这个问题：IP协议通过IP地址统一了整个自网络层之上的行为，上层在发送数据包时并不需要关心自己底层处于什么网络链路，只需要将包交给协议栈就行；协议栈规定了统一的数据帧格式，不管底层处于什么链路，怎么去路由，反正帧格式是定死了的，拆掉外壳，里面永远是同一个IP数据报。

IP协议特点

IP协议是无连接不可靠的，发送端随时可以发送数据，接收端也随时可能接收到数据。不管是数据的发送还是接收，每一个数据包都必须带有独立的IP头以及IP地址信息。IP协议不保证数据能够正确送达对端，出错之后尽可能返回ICMP控制报文由上层来决定下一步；就算送达了也不保证顺序。

这里要强调一点：一定要正确区分IP地址和MAC地址的行为。IP地址用于在网络环境中逻辑定位通信双方，是跨网段寻址的依据，而MAC地址是底层网络链路中路由数据包的依据。下面以一个例子来讲讲IP与MAC的工作流程：

两个路由器都连接到多个网段，因此网卡接口也有多个（一个接口一个MAC地址）。

  • 主机H1在发送网络数据包之前发现对方H2并不处于同一网段，因此将数据包发往路由器R1。此时整个数据包源IP为IP1，目的IP为IP2。其源MAC为HA1，目标MAC为HA3。
  • 数据包到达路由器R1，被R1通过接口HA4发送给路由器R2。此时源、目的IP不变，源MAC变为HA4，目的MAC变为HA5。
  • 数据包到达路由器R2，R2发现目标设备在HA6接口管理的网段内，通过HA6接口将该包发到目标设备。此时源、目的IP依然不变，源MAC为HA6，目标MAC为HA2。

发现了吗？在本次跨网段的通信示例中，源IP和目标IP地址是不会发生变化的，原因在于IP地址作为“路标”，要指引数据路由方向；而MAC地址则是根据路由方向在两个直连设备之间实现通信，而每个设备接口都是有差异的，因此MAC地址在本次通信中是时刻变化的，用于在物理上真真实实将数据路由到指定下一跳位置。

另外，这里还得附注一下：

IP地址并不是全球唯一的，这里要注意，IP协议划分出了3类私有网段地址，这些地址在全球这么多网段中是肯定有重复的。

但是私有地址是局域网段内部使用的，无法直接连接公网。如果需要连接公网那么得走公网IP+NAT映射。更多详见IP地址体系、NAT地址转换

IP协议帧格式

认识一个协议，首先肯定得从协议报文格式入手。IP协议标准头部最少有20字节大小（大部分情况下都是20字节），这20字节携带了必要的通信讯息，如果还有剩余的字节，则为选项字段带一些额外通信参数。

字段长度含义
版本号4 位IPv4 = 4，IPv6 = 6
首部长度4 位以 4 字节为单位，最小 5（20 字节），最大 15（60 字节）
服务类型（TOS）8 位优先级 + 延迟/吞吐/可靠性标志（现多用于 DSCP）(看看就行，一般用不上)
总长度16 位首部 + 数据，最大 65535
标识16 位分片时用于重组，同一数据报的分片共享此 ID
标志3 位DF（不分片）、MF（还有分片）、保留位
分片偏移13 位本分片在原始数据报中的位置，以 8 字节为单位，同样用于重组
生存时间（TTL）8 位每经一跳减 1，为 0 时丢弃并回 ICMP 超时
协议8 位上层协议：1=ICMP，6=TCP，17=UDP
首部校验和16 位只校验首部，不校验数据
源 IP32 位发送方 IP
目标 IP32 位接收方 IP
选项最多40字节记录路由、时间戳、源路由等（很少用）

至于后面的数据部分，负责承载ICMP/UDP/TCP报文头部及其数据、以及应用层的数据。

IP分片与重组

上文我们提到了，IP统一了自网络层之上的内容。但是底层的数据链路层，其实现是各异的。一次跨网段的网络通信底层可能会经过多个不同的物理链路，而每个物理链路都维护有自己的MTU(最大传输单元)表示在该链路层中最大的传输帧长度。例如以太网MTU的典型值就是1500。

这就会导致出现一个问题：假如我们本地网段为以太网，MTU为1500。为了最大化提升效率，我们按照这个数字发包，结果网络包在中间某一跳时，进入了另一类型链路层，通道MTU < 1500了，这时候怎么办？

IP的分片与重组功能就是专门设计出来解决这个问题的——可以将数据包拆开分段传输过去，再由对端正确重组得到完整数据；上述情况中，这个时候中间路由器在传输时就可能会触发IP分片。

为什么说是可能？因为IP分片与重组是可选功能。必须满足以下条件才会触发分片和重组机制：

  • 接收方/发送方均开启IP分片重组功能，否则要不就一个发不出，要不就是收到不会重组。
  • 数据包IP头标志位必须设置可分片。若不允许分片则直接被丢弃。
  • 传输时IP数据报总长(IP头+数据) > 当前传输链路MTU。

上述示意图便是在中间路由器R1分片触发的场景，若允许分片，则进行切片与对端重组；若不允许则回复ICMP报文（类型3Code4）。

当然，要注意的是并不只有中间路由器会触发分片的情况，在源主机有时也会触发分片：比如Ethernet MTU=1500，我们从应用层向IP协议栈递交了一个大于1500字节的数据报，这个时候若我们开启了分片功能，那么在IP层就会主动将其分片发出。

这里讲讲分片重组的一些细节操作：

分片和重组都涉及到IP头部的几个关键字段：标识、标志、分片偏移、以及总长度。

我们以在Ethernet环境下一次性发送4000字节数据(此处演示源主机处分片)，并且对端重组并正确接收4000字节数据为例：

  • 在发送数据包前，协议栈会检查总长度是否大于出口网络接口的MTU，如果总长度<MTU则直接发送；若总长度>MTU，则进行下一步。

  • 检查协议栈是否允许分片，若不允许分片则直接拒绝该次请求，并返回对应的错误给上层；若允许分片，则计算需要分为多少片。

  • 本示例要发送4000字节数据，每个分片最大承载的数据量为：1500 - 20(标准IP头部，无选项字节) = 1480字节。简单运算下可以得到总共需要分为三片：
    分片1：IP头20字节 + 1480字节数据；分片偏移0、MF = 1（后面还有分片）

    分片2：IP头20字节 + 1480字节数据；分片偏移185（注意，8字节为单位）、MF = 1（还有分片）
    分片3：IP头20字节 + 1040字节数据；分片偏移370、MF = 0（后面没有分片了）

  • 分片完毕，几个分片包的标识被打上相同ID表示都属于同一个大包，然后逐个以计算出的值填充每个分片的IP头后，依次发出。

这就是发送方IP分片的流程。这里有一个地方要注意：因为分片偏移以8字节为单位，所以除开最后一包数据以外，其它中间的包数据必须能够整除8字节。这通常由协议栈内部进行管理，我们无需干涉。例如将MTU设置为1499，1499 - 20 = 1479 是无法整除8的。这个时候协议栈内部会退到1472，然后剩下的数据丢给下一包。

接收方收到分片数据后：

  • 根据标识 + 源 IP + 目标 IP + 协议号将同一个大包的分片归为一类，并从中找出首片。
  • 而后根据分片偏移将所有分片进行排序。
  • 当所有分片收齐后(收到MF = 0的包)，脱掉每个分片的IP头，然后按排序进行拼接。
  • 拼好后将完整数据报递交给上层。

我们在Linux中使用ICMP报文来实际看看该示例的情况：

1
2
3
4
5
6
#终端1
sudo ip link set eth0 mtu 1499  #设置MTU为1499.
ping -M dont -c 1 -s 4000 172.18.224.1  #Ping一次网关，数据大小为4000字节，允许分片

#终端2
sudo tshark -i eth0 icmp

运行后各终端情况如下：

1
2
3
4
5
6
7
8
9
10
11
#终端1
PING 172.18.224.1 (172.18.224.1) 4000(4028) bytes of data.
4008 bytes from 172.18.224.1: icmp_seq=1 ttl=128 time=0.359 ms

#终端2
172.18.228.235 → 172.18.224.1 IPv4 1506 Fragmented IP protocol (proto=ICMP 1, off=0, ID=4237)
172.18.228.235 → 172.18.224.1 IPv4 1506 Fragmented IP protocol (proto=ICMP 1, off=1472, ID=4237)
172.18.228.235 → 172.18.224.1 ICMP 1098 Echo (ping) request  id=0x6940, seq=1/256, ttl=64
172.18.224.1 → 172.18.228.235 IPv4 1514 Fragmented IP protocol (proto=ICMP 1, off=0, ID=126b)
172.18.224.1 → 172.18.228.235 IPv4 1514 Fragmented IP protocol (proto=ICMP 1, off=1480, ID=126b)
172.18.224.1 → 172.18.228.235 ICMP 1082 Echo (ping) reply    id=0x6940, seq=1/256, ttl=128 (request in 3)

可以看到，MTU=1499的情况下，我们4008字节（ICMP头部还要占8字节）数据被分为了三片，前两片数据负载均为1472(1479不可用，协议栈自动退回1472)。第三片总大小为1098，减去MAC14字节再减去20字节IP头部，最后IP数据负载为1064字节。1064 + 1472 * 2 = 4008字节，验算通过。

但是在实际网络环境中，其实都会尽量去避免使用分片功能。因为一段分片数据中，只要丢一个分片，那么所有分片都必须重传。而且将一段数据拆成多段发送，本身就加大了路由出错的风险，同时也增加设备负担。所以这也是为什么会有PMTUD技术，就是为了保证在正确路由到对端的整个环境中，我该发多大的包以至于不会在中间路径触发分片。

其它

关于选项字段

IP头部最多60字节，扣除掉20字节的固定标准头部，剩下40字节作为选项插入。选项字节部分是可变的，最大40字节，且必须满足4字节对齐（不满足将使用填充字节进行补齐）。

这40字节内部维护了一个类似于K-V(键值对应)的机制：也就是说IP选项的格式如下面所示

1
2
3
4
┌────────┬────────┬──────────────────┐
│Type   │Length   │    Value       |
│1 字节  │1 字节   │ Length-2 字节  |
└────────┴────────┴──────────────────┘
  • Type：选项类型，比如源路由、记录路由路径等。
  • Length：选项总长度。
  • Value：选项的数据部分。

其中，Type的8位又被划分如下：

1
2
3
4
5
6
  0   1   2   3   4   5   6   7
┌───┬───┬───────────────────────┐
│ C │ C │      Number        │
└───┴───┴───────────────────────┘
  ↑   ↑
 复制标志  选项类别
  • 复制标志（Copied）占一位，表征是否将该选项字段复制到所有IP分片（若有分片的情况下）。0表示不复制，只有首片具有该选项；1表示复制，每个分片都有。
  • 类别占两位，0=控制；1=保留；2=调试和测量；3=保留。
  • 后面的Number编号就是具体的选项类别了(没用，了解一下)。

你比如：
严格源路由：Type = 137，类别是0（控制）

路径记录：Type = 7，类别是0（控制）

这里有两个特殊的单字节类型选项要注意：NOP、EOL。这两个作为选项但是没有常规控制头的Length和Value部分。NOP用于填补占位（前面说过选项要对齐到4字节，若未对齐就用NOP进行填补对齐）、EOL用于表征选项字段结束。

这里以一个路径记录的选项例子来看看实际的布局是什么样的：

路径记录其实就是traceroute，每一个中间路由器都将自己的IP写进Pointer指向的位置，最多记录9跳内容。但是当今互联网发展很多时候通信跳数大于9跳，所以这个功能基本不会使用。

IP选项需要额外解析，降低数据流通速度；而且存在一定的安全风险；同时功能也比较鸡肋。因此在当前的互联网环境中基本上不会被使用，很多协议栈默认设置是关闭IP选项字段功能的。这里只简单讲讲，不深入讨论。

关于TTL

TTL是网络数据包在网络环境中的存活时间。因为占1个字节，所以最大值为255。其典型值为64或255。需要注意的是这里的时间指的并不是我们常识中的分秒这一类时间，而是数据包在路由路径上经过的跳数。

数据包每经过一个中间路由器，TTL都会减少1，当TTL减到0时该包被丢弃。我们在Traceroute中依靠的原理就是TTL超时对端发回ICMP。

之所以要引入TTL，是为了防止失效数据包在网络环境中不断循环被转发。有了TTL，包最多经过255跳就会被丢弃，不会永久占用网络资源。

END

IP协议是网络层的核心，把数据包从源送到目标。不保证可靠、不保证顺序，这些交给上层。IP头的20字节里，每一个字段都有明确分工：版本、长度、分片、TTL、协议、校验和、源/目标 IP。分片是IP应对MTU差异的手段，但代价高，现代网络尽量用PMTUD技术来避免分片。IP选项是补充机制，几乎废弃。

]]> https://r6blog.online/2026/10/06/%E5%B5%8C%E5%85%A5%E5%BC%8F2026100601/ 2026-10-06T07:01:51.000Z 前言

前面已经梳理了同处于网络层的 日语学到现在也接触了不少词语的变形，在运用时虽然能够正确变形但是仍不熟练。因此在此处整理一份到目前阶段为止的高频变形规则，便于随时查阅与巩固。这里先给个包姐梳理的思维导图，后续参考该图进行整理：

动词分类

日语动词分为三类：一类动词（五段动词）、二类动词（一段动词）、三类动词（か・さ变动词）。

简单讲下区分：

  • 一类动词（五段动词）：词尾在五十音表う段上。例：読む、行く、話す、買う

  • 二类动词（一段动词）：词尾る，る前面是い / え段假名。例：食べる、見る、寝る。
    （这其中又分为上一段动词与下一段动词。不过目前来看只要知道这个就行，实际运用时不会去区分这一点）

  • 三类动词（か・さ变动词）：其中か变动词就一个——来(く)る。する / 名词 + する（勉強する、残業する）

这里有几个十分高频的特殊词语并不遵循上述规则，要特殊记：

入る（はいる）、走る（はしる）、切る（きる）、知る（しる）、減る（へる）。这几个词共同点都是符合二类动词规则，但是实际全是一类动词，后续变形时均要按照一类的规则来。尤其是知る（しる）出现频次很高。

当前阶段(N5-N4)所有变形整理

  1. 辞书形/基本形
  2. ます形
  3. ない形
  4. た形
  5. て形
  6. ている形
  7. たい形
  8. 命令形
  9. 意志形
  10. 可能形

接下来从辞书形开始挨个进行整理。

动词基本形/辞书形

这就是日语动词变形之前的原貌，日语动词的变形是十分丰富的，但是最后剥开各个变形规则后底层还是它。新标日为了简单快速过渡到日语学习，开篇介绍的是动词ます形，在后续学习中再深入到基本形。但是学到目前阶段我认为必须优先记忆辞书形式，因此此处放到第一个整理。

日语语言表达分为简/敬体，辞书形是简体的现在肯定时态。这个要记忆纯靠背单次积累词汇量。

你比如：食べる、行く、読む、勉強する。

这里抄一些平时经常遇见的动词的辞书形(也算是记记单词)：

泊まる　結ぶ　撮る　取る　食べる

止まる　生まれる　回る　防ぐ　足りる

动词ます形

动词ます形是敬体的现在肯定形式，上述的动词辞书形是简体的现在肯定形式。其变形规则根据动词分类有如下：

  • 一类动词（五段）：词尾从う段变到前面的い段，后接ます。例如：行く→行きます、買う→買います。
  • 二类动词（一段）：词尾直接去る加ます。例如：食べる→食べます、見る→見ます。
  • 三类动词：来(く)る->来(き)ます（特殊变形，独一份）、～する变します，例如：勉強する→勉強します。

私は毎朝パンを食べる <—> 私は毎朝パンを食べます。和辞书形对比下来二者含义和时态都是完全相同的，区别只是在于说话的对象是谁。同辈和亲密的对象之间往往是简体形；而对长辈以及不熟的人往往用敬体形。

动词ない形

有肯定形式，那自然有否定形式。动词ない形表示的就是简体现在时态的否定形式，与辞书形互为反义。其变形规则为：

  • 一类动词（五段）：词尾变为对应あ段（也就是五十音表开头第一列），加ない。例如：話す→話さない、読む→読まない。
    这里要强调一点：词尾为あ行上面的假名(あいうえお)的变形，词尾不是变为あ，而是变为わ！例如：買う→買わない、会う→会わない。
  • 二类动词（一段）：词尾去掉る加ない。例如：食べる→食べない、見る→見ない。
  • 三类动词：来る (くる)→来ない (こない)；する→しない。

明日のパーティーは私が行かないの。（明天的派对我就不去了哦）

敬体现在时态的否定形式为ません。例如：

私は毎日コーヒーを飲みません。（我每天不喝咖啡）

动词て形

て形一般用作固定搭配、句子前后连接表动作顺序、轻微原因、同时状态以及中顿。其变形规则为：

  • 一类动词（五段）：
    如果词尾为：く・ぐ则发生い音变，即去掉く・ぐ变为いて/いで。例如：泳ぐ→泳いで。

    如果词尾为：つ・る・う则发生促音变，去掉词尾加促音って。例如：待つ→待って、取る→取って。

    如果词尾为：ぬ・ぶ・む则发生拨音变，去掉词尾加んで。例如：飲む→飲んで、遊ぶ→遊んで、死ぬ→死んで。

    如果词尾为：す则发生し音变（有点类似三类），去掉词尾加して。例如：話す→話して 。

  • 二类动词（一段）：去掉词尾る加て。例如：食べる→食べて、見る→見て。

  • 三类动词：来る→来て (きて)。～する→～して（和词尾为す的一类动词情况一样）。例如：勉強する→勉強して。

表动作顺序：家に帰って、晩御飯を食べます。（回家然后吃饭）

表中顿：天気がよくてな、私の気持ちがいいよ。（天气很好啊，我心情很不错）（简体句）

固定搭配：君の名はここに書いてください。（请在这里写下你的名字）(～てください句型)

Ps：行く这个词要单独记忆，因为行く不是变成行いて！而是行って。还有上述分类时提到的入る（はいる）这几个特殊一类动词需要特别注意。

动词た形

动词た形表示的是动词的简体过去时态的肯定形式，指示过去做过的动作。其变形规则和て形一样，区别只是在于将て变为た，で变为だ。

去年の夏休み、毎日2時間日本語を勉強した。（去年暑假，每天学习2小时日语）

昨日、友達と駅前の本屋へ行って、たくさん雑誌を買った。（昨天和朋友去车站前的书店里买了不少杂志）

对应的敬体过去时态的肯定形式为ました。例如：

昨日、友達とデパートへ行きました。（昨天和朋友去了百货商店（敬体））

对应的简体过去时态的否定形式为なかった（ない+かった)。例如：

昨日はパーティーに行かなかった。（昨天我没去派对）

对应的敬体过去时态的否定形式为ませんでした。例如:
昨日はパーティーに行きませんでした。（昨天我没去派对（敬体形））

这里要注意：结合ない形来看，梳理一下——动词时态分为现在、将来时态和过去时态两种，每一个时态都有各自对应的肯定形式和否定形式。而每个形式在语境上又分为敬体和简体。所以总的变换是有8种，这几个变换一定要分清楚。

ている形式

ている形式本身并不表示时态或肯定否定。而是由て形派生出来表示动作的持续进行、某种日常习惯、职业身份、以及状态的持续。但是要注意：虽然自身并不携带时态以及肯否定，但是也具有时态等变形。这些变形是全部发生在いる身上的。

变形规则：

动词て形 + いる。いる是二类动词，所有变形参考二类动词规则即可。例如以持续进行为例：

ている（简体现在肯定）：目前正在做的事

ていた（简体过去肯定）：过去某个时间节点下正在做的事

ていない（简体现在否定）：现在没在做某事

ていなかった（简体过去否定）：过去那个时间节点没在做某事

其各自的敬体形式分别是：

ています　ていました　ていません　ていませんでした

  • 表示动作的持续进行：
    今、李さんは日本語の漫画を読んでいる。（小李现在正在看日语漫画）

    彼はご飯を食べていた。（他当时正在吃饭）

  • 表示处于某种状态（也就是瞬间动词完成之后，动作的结果保留了下来）：

    雨が止んでいるのに、彼は傘をさしている。（明明雨已经停了，他却还撑着伞）(撑伞这个动作维持)

    窓が開いている。（窗户正开着）（不是正在开窗这个动作！而是窗户打开这个状态。这里面两个的区别涉及自他动词，此处不做讲解）

    長い間東京に住んでいる。（我住在东京很久了） 这里要注意区分：長い間東京に住んでいた。(我之前在东京住了很久（意思现在已经不住了）)

  • 表示一种日常习惯：
    毎週土曜日に私はAKB48のライブを見ている。（每周六我都会看AKB48的Live）（日常客观的一个长期习惯行为，不等于目前正在做）

  • 表示职业（目前正在从事的）：
    佐藤さん今は北京で日本語の教師をしている。（佐藤目前在北京做日语老师）

这里有一点要注意：表示存在关系的动词いる、ある不能套用ている的形式，也就是说不存在这种形式。

我之前写过这样一个句子：ママ、弟が今家にいていないの。（妈妈，现在弟弟不在家）

这个句子是个错句，原因在于いる存在动词没有再套用一个ている的说法。正确的写法应该是：

ママ、弟が今家にいないの。

动词 + たい形式

たい和ている类似，本身不带时态和肯否定。表示一种愿望，在中文语境中可以译为“我想要…..”。这里要强调一下这个“我”字，也就是说：这个形态下，主语只能是说话人自己（我），不能用于形容别人想要。

变形规则：

这个变形很简单，动词ます形去掉ます＋たい。至于辞书形怎么变到ます形，上述已经讲了。

例如：日本へとても行きたいな。（真想去日本啊）

含义是很简单的，但是这里重点在于活用形式。既然有现在想要做某事，那么肯定也有过去想要做某事，不想要做某事。たい形的活用规则与一类形容词规则是一样的。

  • [简体现在否定] コーヒーを飲みたくない。（不想喝咖啡）
  • [简体过去否定] 昨日は何も食べたくなかった。（昨天啥也不想吃）
  • [敬体现在否定] コーヒーを飲みたくないです。
  • [敬体过去否定] 昨日は何も食べたくなかったです。

其它的变形不展示更多了，参考一类形容词即可。

]]> https://r6blog.online/2026/10/05/%E6%97%A5%E8%AF%AD2026100501/ 2026-10-05T08:33:25.000Z 日语学到现在也接触了不少词语的变形，在运用时虽然能够正确变形但是仍不熟练。因此在此处整理一份到目前阶段为止的高频变形规则，便于随时查阅与巩固。这里先给个包姐梳理的思维导图，后续参考该图进行整理：

形容词/名词小句修饰名词

小句即类似于英语中的从句概念，例如：“我想要一台操作简单的电脑”。本句中核心主干为“我想要电脑(コンピューターが欲しいです)”，具体是什么样的电脑呢？是“操作简单的电脑(操作が簡単なの)”。这便是一个典型的形容词小句修饰主干句名词的典型示例。

接续规则：

  • 一类形容词小句，形容词用基本形直接接续。
  • 二类形容词小句，形容词用 “二类形 + な” 的形式。
  • 名词小句，用 “名词 + の”　的形式。

示例如下：

  • [形1小句] 空気がいい國へ旅行に行きたいです。（想要去空气好的国家旅行）
  • [形2小句] 料理が上手な人が好きです。（我喜欢对做饭很拿手的人）
  • [名词小句] 皮が手作りの餃子を食べたいです。（想要吃皮是纯手工制作的饺子）

动词小句修饰名词

接续规则：

  • 动词小句直接用动词简体形接续，表示某个习惯或将来状态。
  • 如果是形容已经发生的动作，那么应该使用动词た形（过去时态）。

示例如下：

  • これは李さんにあげる本です。（这是我要给小李的书(将来时，现在在我手上还没给)）
  • あれは私が李さんにあげた本です。（那本是我给小李的书(过去时，已经给了，所属权不再归我)）
  • 昨日会社を休んだ人は森さんです。（昨天请假没来公司的人是森先生）
  • 明日来ない人は私が知らない。（我不知道明天谁不来(这里是简体否定形来ない修饰人)）
  • 公園で歌っている人。(公园里正在唱歌的人(ている 正在持续的状态))

の　形式名词

形式名词の作用就是：将动词/形容词句子进行名词化，使其整体能够作为一个名词进行使用。动词・イ形容词简体 + の → 变成名词性质，可以当主语、宾语。

一般情况下，の名词化的小句做主语时，主语助词用は引导。例如：
自転車に二人で乗るのは危ないです。（骑自行车带入很危险）

本句中，自転車に二人で乗る是一个动词小句，被の名词化之后以名词身份做主语。は是主语助词提示主题，表示“骑自行车带人”这件事，所以句子核心其实就是： A は B です的一个简单句型。

但是要注意：当被名词化的小句是“好きです”、“上手です”、“下手です”、“嫌いです”等这些表示情感和好恶的形容词作用的对象时，主语助词要用が。例如：

李さん、絵をかくのが好きですね。（小李，你很喜欢画画啊）

例句：

  • 日本語で手紙を書くのは難しいですね。（用日语写信真难啊）
  • 佐藤さんは写真を撮るのが本当に上手です。（佐藤很会拍照片）
  • テレビを消すのを忘れました。（忘关电视了）

附注：

こと和の一样，都可以将小句名词化。こと本意就是“这件事”的意思，可以用于名词化小句代指小句描述的这件事。接续规则和の一样，因此大部分情况下二者可以互相替换。

例如：日本語を勉強するのは難しいです　＝　日本語を勉強することは難しいです

但是以下情况不能互换：

  1. 固定搭配，比如 た＋ことがある（曾经做过，经历过），只能用固定的搭配，比如此处的こと；再比如 ことができる（能力，能够做），也是只能用こと。
  2. 感官动词之前必须用の，比如 見る、聞こえる等等。
    例如：李さんは森さんが車から降りるのを見ました。（小李看见森从车上下来了）
  3. 语言和思想行为方面的动词前只能用こと不能用の，比如 伝える、話す。
    例如：李さんは森さんが休むことを伝えました。（小李转告了森请假的事）

由于比较杂，这里引用一个梦子老师的口诀来记忆：除了语言和思想行为方面的动词，其它情况一律用の就不会错。

でしょう　表推测

表猜测，可能性在80%左右，读降调👇。你也可以将它理解为表确认（自己内心已经有一个看法，用于确认自己的看法对不对）。

でしょう在日常口语中的频率是比较高的，而且常常与たぶん（或许，也许）配合使用，加强语气。

接续规则：

  • 一类形容词/动词 均用简体 + でしょう。
  • 二类形容词词干/名词 + でしょう。（名词/二类形 去掉だ）
    例如:静かだ（二类形简体）-> 静かでしょう（去掉だ）
    ここは静かでしょう。（这里应该很安静吧）

先来看表推测情况的例句：

  • 明日の朝は大雨になるでしょう。（明早会下大雨吧）
  • いま桜の季節ですから、東京はたぶん賑やかでしょう。（现在是樱花的季节，东京大概很热闹吧）
  • その赤い服を着ない人はたぶん森さんだろう。（那个没穿红衣服的人也许是森吧）

Ps：でしょう的简体形是だろう。

再来看表确认情况的例句：

  • 李さん、明日パーティーに行くでしょう。（小李，明天的派对你会去吧）
  • 也可以带有一定的质问语气：おかあさん、私の日記、見たでしょう。（老妈，你看了我的日记了吧）

要注意：表确认情况时读上升调👆。

这里要提一嘴：でしょう没有过去式，如果要表示对过去的推测应该是 动词た形+でしょう，而不是でしたでしょう！

例如：昨日雨が降ったでしょう。（昨天应该下过雨了吧）

かもしれません

也表示推测，但是这个可能性只有50%，也就是说可能会发生某事，但是没有でしょう那么确定。所有的接续规则和でしょう是一样的，所以把它和でしょう一块记忆就可以了。可以搭配もしかしたら（也许，说不定）一起使用。

例句：

  • 森さんは今日会社を休むかもしれません。（森啊今天可能不来上班了）
  • もしかしたら、いま李さんは忙しいかもしれません。（也许现在小李正在忙吧）
  • 明日の天気はもしかしたら大雨かもしれない。（明天天气也许会下大雨吧（かもしれない是简体形式））

注意：一对相反形（肯定和否定）后面并列使用かもしれません可以表示“也许….也许….”句型。例如：

明日は雨が降るかもしれませんが、降らないかもしれませんよ。（明天也许下雨，也许不会下雨）

ながら　同时进行的动作

ながら和中文语境中的”一边….一边….”是一样的。都是强调同时进行的两个动作，其中ながら后面接的是主要动作。要注意的是：ながら只能用于同一主体，也就是说不能写成“小李一边….，小森一边….”这种形式。

接续规则：

  • 动词的ます形去掉ます，后接ながら。

例句：

  • 李さんはテレビを見ながら、食事をしている。（小李边看电视边吃饭(吃饭是正在进行的动作，用ている表进行时)）
  • あのことを考えながら、歩いていた。（一边思考那件事一边走着）

Ps：接续的两个动词都必须是可持续的动词，死ぬ等这些瞬时动词不能放进去。

小句+時

小句+時表一个时间节点，如中文语境中的：“在我小的时候”(私が子供の時)。

接续规则：

  • 与前文小句接续规则是一样的，都是简体形小句。
    形1/动词 –> 简体+時
    形2 –> + な+時
    名词 –> + の+時

这里要注意的是：如果是动词小句，那么情况就有点特殊。因为动词时态分为现在时态和过去时态，如果动词小句为现在时态，那么表示整个小句所描述的那件事还没有发生；如果是过去时态，则表示动词小句修饰的那件事已经发生了。

这里光文字描述可能有些空洞，看下面的例子：

  • 日本に行く時、たくさんお土産を買いました。（要去日本的时候买了很多礼物）
    这句话是动词现在时态小句，表示要去日本，但是在这个动作发生之前先发生了后面的购买礼物的动作。也就是说礼物不是在日本买的！
  • 日本に行った時、たくさんお土産を買いました。（去日本后买了很多礼物）
    动词过去时态小句，表示这个动作已经发生了。礼物是在去到日本之后才买的！

其它例句：

  • 天気がいい時、友達と野球をする。（天气好的时候会和朋友们一起打棒球）
  • 仕事が暇な時、残業しない。（工作不忙的时候不用加班）
  • 子供の時、横浜に住んでいた。（小时候住在横滨）

Ps：時后面跟に可以表示一次性的，个别的情况。例如：

  • この前、友達が病気の時に、私は看病しました。（前些天朋友生病时我照看了他）

名词+で　表原因、理由

助词で放到名词后可以表示原因、理由。例句：

  • 仕事で、楊さんとあっていたんですよ。（因为工作原因，我（那段时间）一直和杨先生见面来着）

动词 ている 形

前面我们学到了动词+ている表正在进行的动作。但是ている并不只有这一个用法，下面借此来梳理一下ている的多个用法：

  • 正在进行时态：李さんは今電話をかけている。（小李现在正在打电话）
  • 结果、状态的存续：森さんは車を持っている。（森有一辆车）
    直接按照中文语境根据不同动词译为”拥有、住在、认识、已婚”等等即可
  • 表示某种习惯的事：李さんは先月から、図書館で日本語を勉強している。（小李从上个月开始就日常在图书馆学日语）
  • 表反复、周期性的事件：週に1回日本語専門学校に通っている。（每周去一次日语培训学校）
  • 表职业：私は北京で日本語の教師をしています。（我是北京教日语的一名老师）

这里要注意：表示反复和习惯时，只要是单纯描述一个客观事实的情况下，也可用基本形进行替换。

例如：週に1回日本語専門学校に通う。表示的也是同一个意思。

て＋あげる／まらう／くれる　表抽象授受关系

在这之前已经学习过：あげる/まらう/くれる 用于授受关系。其中

  • あげる：表示说话人给他人某物，说话人做主语。
    私は李さんに韓国で買ったCDをあげました。（我把我在韩国买的CD给了小李）
  • まらう：表示说话人从他人那里获取某物，说话人做主语。
    このマフラーは私が誕生日に森さんにもらいました。(这条毛巾是我生日的时候从森那里拿到的)
  • くれる：他人给说话人某物，他人是主语。
    これは森さんが[私に]くれた本です。（这是森给我的书）

这些授受关系的词均可以译为中文里面的“给”，只要正确区分“给”的方向就行。

当这些授受关系词加上て之后，即：
动词て形 + あげる／まらう／くれる 则表示一类抽象的授受关系，不再表示物理上的得到和给予，而是请别人帮我做某事或我主动帮别人做某事，是抽象概念。

  • てあげる：说话人一方主动帮别人做事。
    森さんは年寄りの荷物を持ってあげました。（森帮老人拿了行李）
  • てまらう：表示说话人接收了对方的恩惠或对方对自己的一些行为，蕴含有一种感谢之意。
    私は森さんに東京を案内してもらいました。（森带我游览了东京）
  • てくれる：他人做主语给说话人做事，其反问形式可以表示说话人请求别人做某事。
    友達が面白い本を教えてくれました。(朋友给我介绍了一本有趣的书)
    ごみを出してくれますか。（能帮我倒一下垃圾吗）

这里要注意的是：

てあげる如果是说话人直接就是动作主体时，会给人一种强加于人的印象，不太礼貌，因此对关系不近或地位高的人尽量不使用。例如对老师说：この本をあなたに貸してあげます。（我把这本书借给你）这句话语法本身没错，但是类似于中文语境“这本书是我借给你的/这本书我就借给你吧”，给人一种自上而下的感觉（虽然我也不太明白怎么读出这种感觉的(lll￢ω￢)）。

てくれる 在使用反问形式请求别人帮自己做某事时，还有一种更礼貌的用法：てくれませんか。这比直接反问要礼貌不少。例如：森君、この資料をコピーしてくれませんか。（森先生，能否帮忙打印下这份资料？）

]]> https://r6blog.online/2026/10/02/%E6%97%A5%E8%AF%AD2026100201/ 2026-10-02T01:36:42.000Z 形容词/名词小句修饰名词

小句即类似于英语中的从句概念，例如：“我]]>

《新标日初级第三版》 第七单元梳理 2026-10-08T07:15:10.251Z R6bandito 引言

在IP网络环境中，我们已经知道：IP数据包的路由并不是完全可靠的，只是尽力而为。IP协议只负责尽可能将你的数据包送达对端，至于能否正确送达并不能完全保证。IP协议自身也并不提供任何的差错报告机制来保证数据递交的有效性，这就会出现一种情况：“我本机发出的数据包，对端是否正确收到？上层是否需要重新发一个过去？许久没和对端通信之后，对端是否还活着并正常提供服务？甚至我自己的网络环境怎么样，能不能和外界正常通信？”这些都是IP协议自身无法解决的问题。

因此我们就需要一个协议来传递整个通信过程中出现的异常行为，以及监控通信是否正常。这个协议就是：ICMP(Internet Control Message Protocol)。

什么是 ICMP？

ICMP 是网络层的一个重要的协议，负责传递网络层的差错和控制信息，不携带用户数据。虽然与IP、ARP协议同属于网络层，但是ICMP其实是依附在IP协议之上的一个更上层的协议。这一点就注定了ICMP的报文形式与ARP的报文形式有本质区别，下文将详细讲述。

这里要注意：ICMP不属于传输层，因此不涉及任何的端口概念。

ICMP有三大功能：IP重定向、差错信息传递（差错报文）、查询控制（查询报文）。

ICMP 报文格式

ICMP报文是基于IP协议为基础构建的，也就是说其实ICMP本质也是一个IP包，ICMP的报文部分就是这个IP包的数据段。只是协议栈内部设计了单独处理这种类型报文的逻辑，这也就是我们说的ICMP协议了。

ICMP和ARP虽然共处于网络层，但是在报文形式上的本质区别是：ARP报文直接封装在以太网帧中，不需要有IP头部，ARP在这种前提下可以认为是完全脱离IP协议而独立的；而ICMP报文封装在IP中，与IP协议是一个上下的依赖关系。

ICMP报文控制头部固定8字节，这8个字节的布局如下表所示：

字段长度说明
类型1 字节标识 ICMP 报文的大类
代码1 字节类型的子分类
校验和2 字节覆盖整个 ICMP 报文
其余字段4字节含义取决于类型和代码

这里讲讲数据部分取决于类型是什么意思：ICMP这8个字节的头部是固定不可变的。前四个字节（类型、代码、校验和）是完全通用的。后4个字节负载根据不同的ICMP报文类型，会采取不同的措施。

就以我们常见的Ping举例：对于Ping的Echo Request和Reply，ICMP数据负载那4个字节被划分为了——标识符(2字节)+序列号(2字节)；而对于重定向功能，后4个字节则被定义为新网关IP地址；而对于一些其它类型，则选择保留(全0)。所以总结就是：这4个字节始终存在于固定头部中，只是具体含义随报文类型而变化。

这里我还需要再说明一个地方：

先来看个示例，我们亲自抓一个Ping包看看。我们以Ping网关为例

1
2
3
4
5
6
7
8
9
10
Yukirin@DESKTOP-8BFBE1K:~$ ping -c 1 172.18.224.1
PING 172.18.224.1 (172.18.224.1) 56(84) bytes of data.
64 bytes from 172.18.224.1: icmp_seq=1 ttl=128 time=0.299 ms

--- 172.18.224.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.299/0.299/0.299/0.000 ms

Frame 1: Packet, 98 bytes on wire (784 bits), 98 bytes captured (784 bits) on interface eth0, id 0
....

发现了吗？ping输出了一个56(84)大小的数据，而我们tshark抓到的包却显示98字节捕获。这里讲讲这几个数据为什么会出现差异：

  • 56(84)：Ping中输出的56，指的是ICMP数据载荷长度，也就是我们上图中数据负载那一部分。而84指的是整个IP数据包的大小。此例中——我们 IP标准头(20字节)+ICMP控制头部(8字节)+ICMP数据负载部分(56字节) = 84字节。
  • 98：tshark在抓包时抓的是整个以太网帧的长度，是货真价实跑在物理传输线路上的，因此要算上MAC头部(14字节)。即：84 + 14 = 98字节。这里要注意：FCS校验和在抓包前通常已经被底层网卡硬件给校验完毕后去除了，所以抓不到也不显示。

讲这个示例目的是为了分清ICMP控制数据部分和ICMP数据负载部分。ICMP控制头8字节，不代表整个ICMP报文就只能是8个字节，控制头后面有时还跟得有数据负载的！你比如我们可以以下列命令构造一个1400字节负载的Ping包

1
2
3
4
5
6
7
Yukirin@DESKTOP-8BFBE1K:~$ ping -c 1 -s 1400 172.18.224.1
PING 172.18.224.1 (172.18.224.1) 1400(1428) bytes of data.
1408 bytes from 172.18.224.1: icmp_seq=1 ttl=128 time=0.374 ms

--- 172.18.224.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.374/0.374/0.374/0.000 ms

一定要正确区分控制头的数据部分和控制头之外的ICMP数据负载！

最后这里给出一个类型与代码对应表，后续将以该表为依据讲几个常用的类型：

类型名称代码说明
0Echo Reply0ping 应答
3Destination Unreachable0~15目标不可达
5Redirect0~3重定向
8Echo Request0ping 请求
11Time Exceeded0/1TTL 超时
12Parameter Problem0~2参数错误
13/14Timestamp0时间戳（很少使用）

ICMP 查询报文

ICMP查询机制里面，有多对查询类型报文：比如ping报文(类型8/0)、时间戳(13/14)这些都是ICMP查询机制里面包含的，但是其中很多均已废弃，并不常用。当前ICMP整个查询报文里面最常用的就是ping。

ping报文的作用是检测网络环境的连通性。其请求报文的类型(Type)为8，代码(Code)也为0；ping应答报文的类型为0，代码为0。ping报文ICMP控制头的低4字节数据部分是有使用的，这4个字节被拆分为了标识符(2字节)+序列号(2字节)。

  • 标识符：用于区分由哪个进程发起的本次ping通信。
  • 序列号：区分这是同一个进程的第几个ping包。

如下图就是一个ping请求与应答的ICMP报文部分

可以看到，对于ping的回复基本上是将请求数据包原封不动送回去。由于类型改变了，因此CheckSum要重算，其它地方全部不动。

再看一个实际的抓包示例：

1
2
3
4
5
6
Yukirin@DESKTOP-8BFBE1K:~$ ping -c 1 -s 700 172.18.224.1

tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
14:01:19.448455 IP 172.18.228.235 > DESKTOP-8BFBE1K.mshome.net: ICMP echo request, id 13872, seq 1, length 708
14:01:19.448852 IP DESKTOP-8BFBE1K.mshome.net > 172.18.228.235: ICMP echo reply, id 13872, seq 1, length 708

该示例中，标识符就是13872，序列号为1表示是本次ping通信的第一个包。

一次完整的ping通信流程如下:

  • 上层触发ping通信。
  • 协议栈内部构造ICMP Echo Request报文。
  • 将ICMP信息报装入IP数据包中。查路由表决定下一跳，确定IP数据包的发送方向。
  • 若目标设备处于同一网段，则对目标IP发起ARP解析以获取其MAC（若ARP表中无该条目或条目已过期，会先挂起发送动作并广播ARP。详见ARP地址解析协议）；若处于不同网段，则解析本网段网关的MAC，发给网关。
  • 目标设备收到后，构造ICMP Reply并回送。
  • 本机收到对方的回复后，计算往返时间。

ICMP 差错报文

差错信息上报机制是ICMP协议的三大功能之一，差错报文专门用来通告网络通信中出现的各种问题。与查询报文不同，差错报文是单向通信！差错报文不能主动请求发送，只能在网络出问题时协议栈内部自行发送。

差错报文主要有以下几个类型：

类型3

Code含义典型场景
0网络不可达没有路由
1主机不可达主机不存在/关机
2协议不可达目标不支持该协议
3端口不可达目标端口没人监听
4需要分片但 DF 置位MTU 问题
5源路由失败—
6目的网络未知—
7目的主机未知—
9/10网络/主机被管理员禁止防火墙
13通信被管理员禁止防火墙

类型3是平时见得最多的错误类型，例如错误访问了一个未被监听的端口，对端就会发来该类型的报文。这里以一个实际抓包为例：我们在Windows侧的UDP调试助手上发送一个UDP数据报给WSL2中Linux本机的未监听端口8081，同时抓取eth0网卡上的ICMP流量。抓到的数据如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
Frame 1: Packet, 75 bytes on wire (600 bits), 75 bytes captured (600 bits) on interface eth0, id 0
    Section number: 1
    Interface id: 0 (eth0)
        Interface name: eth0
    Encapsulation type: Ethernet (1)
......
Internet Protocol Version 4, Src: 172.18.228.235, Dst: 172.18.224.1
.......
    Protocol: ICMP (1)  #ICMP包
    Header Checksum: 0xde88 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: 172.18.228.235
    Destination Address: 172.18.224.1  #该ICMP包由172.18.228.235 发往--> 172.18.224.1
    [Stream index: 0]
Internet Control Message Protocol
    Type: Destination unreachable (3)
        [Expert Info (Note/Response): Type indicates an error]
            [Type indicates an error]
            [Severity level: Note]
            [Group: Response]
    Code: 3 (Port unreachable)  # Type3 Code3 目标端口不可达
    ....

这里重点来看ICMP部分。我们的UDP数据报从Windows虚拟网卡地址 172.18.224.1 发出，目标为 Linux 本机 172.18.228.235 的 8081 端口。由于Linux本机并未监听该端口，内核直接封装了一个 ICMP Type 3 Code 3（端口不可达） 报文，发送给发送方 172.18.224.1。注意，172.18.224.1 既是WSL的网关，也是Windows宿主机上虚拟网卡的IP，因此该ICMP报文直接到达宿主机，由宿主机的网络栈通知对应的UDP套接字，而无需经过额外的网关转发过程。

类型11:Time Exceed超时

Code含义
0TTL 耗尽（传输中）
1分片重组超时

类型11在平时也十分常见，当我们去尝试连接一个并不存在的地址、或在traceroute场景下经常会与该类型的包打交道。这里同样来看一个实际的抓包示例：这里我们尝试去连接一个不同网段的地址172.16.224.1看看会发生什么。

1
2
3
4
5
6
7
#终端1 构建SYN包尝试连接 172.16.224.1:1240
Yukirin@DESKTOP-8BFBE1K:~$ sudo hping3 -S -p 1240 -c 1 172.16.224.1

#终端2 抓通过网卡的ICMP流量
Yukirin@DESKTOP-8BFBE1K:~$ sudo tshark -i eth0 -x icmp
Running as user "root" and group "root". This could be dangerous.
Capturing on 'eth0'

执行后，两个终端分别得到如下输出：

1
2
3
4
5
6
7
8
9
10
11
#终端1
HPING 172.16.224.1 (eth0 172.16.224.1): S set, 40 headers + 0 data bytes
TTL 0 during transit from ip=10.3.255.38 name=UNKNOWN

#终端2 (抓到的ICMP流量原始数据(以太网帧))
0000  00 15 5d 2e 41 b5 00 15 5d 2e 1f 84 08 00 45 c0   ..].A...].....E.
0010  00 44 c0 bc 00 00 3c 01 23 15 0a 03 ff 26 ac 12   .D....<.#....&..
0020  e4 eb 0b 00 d6 4d 00 00 00 00 45 00 00 28 f1 33   .....M....E..(.3
0030  00 00 01 06 ab 8c ac 12 e4 eb ac 10 e0 01 04 c1   ................
0040  04 d8 42 0a 0d fa 65 71 57 19 50 02 02 00 b6 87   ..B...eqW.P.....
0050  00 00                                             ..

TTL 0 during transit from ip=10.3.255.38 name=UNKNOWN这里表示我们的包在传输途中TTL已经减为0了，被路由器丢弃。而丢弃该包的路由器正是 10.3.255.38，我们抓到的该包ICMP报文也是该路由器送出给我们的差错报文。

在捕获的原始报文中，我们可以按照格式解析出以下数据

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
IP头：
45 c0              ← 版本 4，首部长度 20 字节
00 44              ← 总长度 68 字节
c0 bc              ← 标识
00 00              ← 标志 + 分片偏移
3c                 ← TTL = 60
01                 ← 协议 = 1（ICMP!）
23 15              ← 首部校验和
0a 03 ff 26        ← 源 IP：10.3.255.38（中间路由器）
ac 12 e4 eb        ← 目标 IP：172.18.228.235（我们的地址）

ICMP控制头：
0b                 ← 类型 = 11（Time Exceeded，超时）
00                 ← 代码 = 0（TTL 超时）
d6 4d              ← 校验和
00 00 00 00        ← ICMP控制头数据部分（类型11保留）

这就是一个货真价实的类型11超时ICMP错误报文，由中间某段路由器发来告诉我们本地包已经被丢了，通信失败。

这里简单讲讲为什么会被丢。首先我们在WSL虚拟环境中的本机地址为 172.18.228.235，网关是172.18.224.1，本地网段的网络地址为172.18.224.0/20(子网掩码:255.255.240.0)。我们请求连接的对方是 172.16.224.1，我们用子网掩码去&一下对方地址，得到 172.16.224.0 != 172.18.224.0。

因此我们的SYN请求包先被发给了我们的网关，然后由网关来到我们宿主机Windows本地，Windows本机查自己的ARP表也找不到该地址，只能继续发给Windows的对外网关。公网路由器并不知道172.16.224.1在哪，只能按默认网关路由，于是该包在网络环境中被反复路由，直到TTL耗尽。

路径大致是这样的： WSL –> Windows –> 校园网/企业网 –> 外部网络。

这里需要再多说明一点：看抓包的源码你会发现ICMP控制头之后，还带有不少负载数据。这是因为差错报文不仅需要指明是何种错误，还需要携带原始IP包的IP头部以及原始包的IP数据段至少前8字节。为什么至少8字节？因为在传输层TCP/UDP头部中，前8字节刚好能够拿到源端口、目标端口以及序列号。如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
45 00 00 28        ← 原始 IP 头开始
f1 33 00 00        ← 标识 + 标志
01 06 ab 8c        ← TTL=1，协议=6（TCP）
ac 12 e4 eb        ← 原始源 IP：172.18.228.235（本机）
ac 10 e0 01        ← 原始目标 IP：172.16.224.1（目标）
04 c1              ← 原始源端口：1217
04 d8              ← 原始目标端口：1240
42 0a 0d fa        ← 原始序列号
65 71 57 19        ← 原始确认号
50 02              ← 原始数据偏移 + 标志（SYN）
02 00              ← 原始窗口大小
b6 87              ← 原始校验和
00 00              ← 紧急指针

这里数据段多从TCP头部中截取了12个字节。也就是说我们抓的该包中 原始IP头部(20字节) + 原始IP数据段（也就是TCP头）（20字节） = 40字节。多截取数据部分并没有问题，因为协议只规定了至少要8字节。

验算一下：

MAC头14字节 + IP头20字节 + ICMP控制头8字节 + 原始IP头20字节 + 截取的原始IP数据段20字节 = 82字节。正确

ICMP差错报文是有硬性约束的，目的是为了防止差错报文引发互联网环境灾难。

  • ICMP差错报文如果本身也出错，那么将直接丢弃，不允许再次发回ICMP报文描述这次差错。
    这个约束性质在很多网络资料中都会被简化为为了防止出现无限差错风暴而设计的，但是你实际去想一下拓扑会发现无限循环这种网络拓扑实际很难出现，这个特性更多是防止差错链变长占用带宽。

    试想一下：假如允许使用差错回复差错，那么一个差错报文在长达数十跳的路由环境中假如频繁出现差错，那么这一整条线上会多出数个因此而诞生的ICMP报文占用带宽。

  • 不为广播/多播发ICMP报文。

    目标地址是多播或广播的包，出错时不允许发送ICMP报文。源地址是广播/多播地址的包，也不会回复ICMP。

    比如我们向本地广播地址发一个ping包，从底层视角来看这个ping包实际是被该网段下每个设备的以太网路硬件都收到了的，但是包被移交上层时协议栈发现该ICMP报文目标竟然是广播，直接就静默丢弃了。

    这么做是为了防止攻击者利用广播进行攻击，假如攻击者伪造受害者不断ping广播，如果允许回复的话，那么受害者将瞬间被大量ICMP直接打瘫痪。

  • 不为非分片首片的包发差错。

    如果一个包被分片了，只有第一个分片（offset = 0）出错才回差错，后续分片不回。因为分片包只有首片携带了传输层的头部（TCP/UDP），其它分片只携带数据，就算回了差错报文，发送方拿到后也获取不了有效信息反而多个差错报文会干扰发送方，还会多余占用带宽。

重定向 Redirect

除了类型3和类型11这种纯粹的差错上报，ICMP还有一类特殊的报文——重定向（类型5），它不仅能报告异常，还能主动优化主机的路由表。

类型5

Code含义
0重定向网络
1重定向主机
2重定向服务类型 + 网络
3重定向服务类型 + 主机

重定向是ICMP报文的又一大应用之一，独特的点在于能够改变主机的路由表，影响主机的路由选择。

其原理是：当中间路由器发现主机使用的发送路径并不是最优且主机并未开启IP源路径选项时，路由器在向外递送报文的同时会向主机回复一个ICMP重定向报文，这个报文中涵盖了一个新的网关IP。主机收到该报文后，将自己的路由表的网关改为新网关IP，后续流量直接走新网关，不必再经过旧网关多绕一遍，提高通信效率。

例如下图所示：

示例中，我们本机默认网关为R1，当我们本机需要与公网10.12.4.4进行通信时，将数据包发给网关R1（图中蓝色箭头），由R1代发给公网。R1收到后查路由表发现去往10.0.0.0/8更优的下一跳是R2，而且R1与R2与本机都在同一个网段。于是R1在将本次收到的数据包递交给R2的同时也回复一个ICMP重定向给本机，本机收到后将网关改为重定向的IP。后续到10.12.4.4的通信全部直接走R2，就不需要再经过R1绕一遍了。

这里讲讲ICMP的重定向触发条件：

  • 首先肯定是主机和路由器双方都必须允许ICMP重定向，这是根本条件。假如双端有任何一端不允许重定向，那么整个动作都无法完成，无论是否满足剩余条件。
  • 入接口必须等于出接口：一个包从路由器进来，如果进来与出去的流量都是走同一个接口，那么说明发送方和路由器在同一个网段，且下一跳也在同一个网段，这才可能触发重定向。例如上述示例，假设一个网络包从R1(eth0)进来（主机发给R1），R1查路由表发现这个包得给R2，而R2刚好处于同一网段，eth0可以直达，于是包就从eth0进入，eth0发出。满足条件。
  • 下一跳IP和包的源IP处于同一网段：这是肯定的，否则就算你R1给推荐了一个路由，但是与本机不处于同一网段，本机够不到，也是白搭。
  • 包没有被源路由：如果发送方IP选项内部已经指明了该包必须按照指定的路径发，那么路由器就不得擅自修改。
  • 源包不是路由器自己发的：路由器自己发的包，谈不上告诉别人改路由这个情况。

在实验环境中，重定向很难出现，得在多路由环境下才能观测得到，所以此处不给出示例了。

当然，重定向和ARP的学习行为都是一把双刃剑。既然能改路由表，那就避免不了攻击。常见的重定向攻击便是攻击者伪造一个ICMP重定向报文，使得目标主机将路由改为攻击者，后续发给公网的数据全部被攻击者劫持和窃听。

所以当今互联网环境中，重定向功能基本都被主机默认关闭。关于优化问题现在也有不少可靠的动态路由协议，重定向的使用面已经比较窄了。

ICMP 其它应用

Traceroute

traceroute算是ICMP报文一个十分经典的应用了，主要用于跟踪数据包被路由的每一跳节点。其核心原理就是：靠ICMP类型11的超时报文，让包故意在路径上失活，然后依次暴露路径上的每一跳直到包到达目的端。

这里需要知道，IP头部有一个TTL字段，含义是包的生存时间。TTL每经过一跳就会被中间路由器减1，当TTL减到0时，路由器便会丢弃该包，并向源IP回复一个ICMP 类型11的差错报文（超时）。

因此，我们就可以故意发 TTL = 1、TTL = 2、TTL = 3….的包，每一跳路由器都会向我们回复一个ICMP报文，我们通过解析该报文即可获得对应的中间路由器的地址。每收到一个ICMP就暴露一跳，直到包到达目标。

来看下面一个推演流程，例如我们有以下网络拓扑：

1
主机 H ── R1 ── R2 ── R3 ── 目标 T
  • 第一跳：TTL = 1，由本机H->R1。R1收到包后TTL为0，向本机回复ICMP，本机收到ICMP后记录第一跳。
  • 第二跳：TTL = 2，本机H->R2。R2收到后TTL为0回ICMP。本机记录R2。
  • 第三跳：TTL = 3，同理本机收到ICMP后记录R3。
  • 第四跳：TTL = 4，成功到达目标，目标T回复ICMP。本机收到后记录，本轮traceroute探测终止。

关于traceroute的方法，可以自行构造ping包挨个递增TTL或自行构造UDP包访问对端未监听高端口，并自行递增TTL，这是手动的方法。目前也有许多自动化工具用于追踪，比如Linux上的traceroute工具。该工具并不预装，需要使用以下命令进行安装：

1
sudo apt install traceroute

接下来就以该工具演示trace百度的一个实例：

1
2
3
4
5
#终端1
Yukirin@DESKTOP-8BFBE1K:~$ sudo tshark -i eth0 icmp

#终端2
Yukirin@DESKTOP-8BFBE1K:~$ traceroute baidu.com

结果如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
#终端1
Capturing on 'eth0'
    1 0.000000000 172.18.224.1 → 172.18.228.235 ICMP 102 Time-to-live exceeded (Time to live exceeded in transit)
    2 0.000000270 172.18.224.1 → 172.18.228.235 ICMP 102 Time-to-live exceeded (Time to live exceeded in transit)
    3 0.000000340 172.18.224.1 → 172.18.228.235 ICMP 102 Time-to-live exceeded (Time to live exceeded in transit)
    4 0.002513097    10.32.0.1 → 172.18.228.235 ICMP 70 Time-to-live exceeded (Time to live exceeded in transit)
    5 0.002513378    10.32.0.1 → 172.18.228.235 ICMP 70 Time-to-live exceeded (Time to live exceeded in transit)
    6 0.002513448    10.32.0.1 → 172.18.228.235 ICMP 70 Time-to-live exceeded (Time to live exceeded in transit)
    7 0.002515427 10.50.255.253 → 172.18.228.235 ICMP 102 Time-to-live exceeded (Time to live exceeded in transit)
    .....
    
#终端2
traceroute to baidu.com (111.63.65.103), 30 hops max, 60 byte packets
 1  DESKTOP-8BFBE1K.mshome.net (172.18.224.1)  0.194 ms  0.150 ms  0.136 ms
 2  10.32.0.1 (10.32.0.1)  2.637 ms  2.589 ms  2.575 ms
 3  10.50.255.253 (10.50.255.253)  2.547 ms  2.507 ms  2.505 ms
 4  58.213.28.201 (58.213.28.201)  4.023 ms  2.861 ms  3.984 ms
 5  221.226.71.189 (221.226.71.189)  2.822 ms 221.226.71.193 (221.226.71.193)  2.826 ms  2.809 ms
 6  * * *
 7  * * *
 8  * 202.97.126.73 (202.97.126.73)  21.666 ms *
 9  * 202.97.75.130 (202.97.75.130)  23.262 ms 202.97.118.34 (202.97.118.34)  23.245 ms
10  221.183.187.161 (221.183.187.161)  25.720 ms 221.183.86.49 (221.183.86.49)  28.528 ms 221.183.177.109 (221.183.177.109)  21.959 ms
11  221.183.94.25 (221.183.94.25)  27.418 ms  27.320 ms  27.293 ms
12  221.183.148.158 (221.183.148.158)  61.837 ms 221.183.137.222 (221.183.137.222)  34.077 ms 221.183.148.158 (221.183.148.158)  72.360 ms
13  * * *
14  112.54.105.42 (112.54.105.42)  40.671 ms 112.54.105.102 (112.54.105.102)  34.486 ms 112.54.105.110 (112.54.105.110)  25.103 ms
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

这里可以看到我们的traceroute默认发的是ICMP。整个过程你会发现虽然确实暴露了不少中间路由节点，但是还有不少的***，这通常是正常现象，表示该跳中间节点并没有响应我们。

上述我们说过，每一跳会暴露对应中间路由，这是在理论推演的情况下进行的。实际上每个中间路由节点的配置不同，并不是每一个中间节点都会回复。这其中原因很多：有的服务器防火墙会拦截ICMP，导致探测包被挡、有的服务器默认不响应。你也可以采用UDP或TCP的形式进行追踪，不过此处不展开详细讨论。

关于Traceroute最后补充一点就是：

不只有ICMP可以进行探测，UDP/TCP都可以。

UDP模式的原理是：本机发UDP包访问对端高端口（这些端口往往不被监听），当UDP包处于中间路由器时，中间路由器回复ICMP超时。当包到达对端时触发ICMP：端口不可达，完成探测。

TCP模式是类似的：本机发起TCP握手连接，指定一个目标端口。当TCP包处于中间路由器时，中间路由器依旧回复ICMP超时。当包到达对端后，如果端口被监听，则对面会回复ACK；若端口未被监听，对面会回复RST。本机收到ACK/RST后即可判断成功抵达对端，本次trace结束。

TCP优点在于能够直连对方的服务端口，防火墙往往会拦截ICMP和UDP高端口访问，但是不会拦截TCP的正常端口访问，因此防火墙穿透能力很高。

PMTUD (路径MTU发现)

这也是一个很经典的应用：网络环境中，有时候底层链路的MTU往往是不同的，你比如以太网最大MTU为1500，假如我们为了效率都按照这个MTU来发包，看似没问题。但是数据包在网络中路由时会经过很多跳，有的跳底层MTU并没有1500，那么这个时候就会发生分片行为，降低效率。甚至当我们设置了不分片时，包会一直被丢弃，导致本机通信失败。

所以向对端发包时，我们需要知道整个路由上最小的一个MTU是多少，并以此为依据进行发送。这个时候就要用到PMTUD技术了。

其原理很简单：我们一开始先发一个大包，并设置不允许分片。大包发出去后若直达对端，说明是理想情况，整条路由路径上没有MTU瓶颈。若在中间某一跳卡住了，被卡住的那台中间路由器会回复ICMP类型3代码4（需要分片但不允许分片），并会携带一个MTU值，我们收到后就把包大小调整成新MTU的大小，继续发送。

循环上述操作，最终包会抵达对端，我们也成功探出了整条路径上最小的MTU大小。当然，这种方法肯定是有局限的，因为十分依赖ICMP报文。假如本地防火墙卡了ICMP、或中间路由器不响应ICMP、再或者ICMP路由时出错了，这些都是有可能的。

如果上层没有防御手段，那么表现就是通信挂掉了。本文只讲MTU的探测原理，所以这里不详细展开。

END

]]> https://r6blog.online/2026/09/28/%E5%B5%8C%E5%85%A5%E5%BC%8F2026092801/ 2026-09-28T01:27:41.000Z 引言

在IP网络环境中，我们已经知道：IP数据包的路由并不是完全可靠的，只是尽力而为。IP协议只负责尽可能将你的数据包送达对端，至于能否正确送达并]]>

ICMP Internet控制报文协议 2026-10-08T07:15:10.247Z R6bandito 前言

本篇文章用于记录一些Linux系统中的常用操作命令。Linux的命令系统是十分强大和复杂的，为了能够熟练进行系统操作，在这里归档一些常用命令以及常用参数，便于随时查看。如果需要更多更细节的一些操作命令，请自行查阅手册。

文件与目录操作命令

  • pwd：显示当前所处路径

    没有任何参数，单纯用来看自己当前处于什么位置。

    1
    2
    user:~/work$ pwd
    /home/Yukirin/work

  • cd：切换工作目录

    1
    2
    3
    4
    5
    6
    cd /home/user/project   # 进入绝对路径
    cd project              # 进入相对路径
    cd ..                   # 返回上一级
    cd ../..                # 返回上两级
    cd ~                    # 回到家目录（等价于 cd）
    cd -                    # 回到上一次所在目录

    这里要注意一下：cd - 不是进入上一级目录，而是类似于出栈撤回的操作。例如当前处于家目录，使用cd /user/project/subdir 跳转后，使用 cd - 回到的不是 /user/project，而是跳转之前的家目录。

  • ls：列出当前目录下内容

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    ls                  # 简单列出
    ls -l               # 长格式：权限、链接数、所有者、大小、时间、名字
    ls -a               # 显示隐藏文件（以 . 开头）
    ls -h               # 人类可读大小（配合 -l）
    ls -lh              # 最常用组合
    ls -alh             # 显示所有文件 + 长格式 + 易读大小
    ls -t               # 按修改时间排序（新的在前）
    ls -r               # 反向排序
    ls -S               # 按大小排序（大的在前）
    ls -R               # 递归列出子目录
    ls -d */            # 只列出目录本身，不展开内容
    ls -i               # 显示 inode 号

    实际开发中，最常用的组合是 ls -alh ，能够应对90%的使用场景。在一些Linux的发行版（例如我这个Ubuntu 26.04）会将该命令重定义为 ll，敲命令时直接使用ll更方便。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    Yukirin@DESKTOP-8BFBE1K:~$ ll
    total 76
    -rw------- 1 Yukirin Yukirin  5426 Sep 25 16:51  .bash_history
    -rw-r--r-- 1 Yukirin Yukirin   220 Sep 18 18:54  .bash_logout
    ....

    Yukirin@DESKTOP-8BFBE1K:~$ ls -alh
    total 76K
    -rw------- 1 Yukirin Yukirin 5.3K Sep 25 16:51  .bash_history
    -rw-r--r-- 1 Yukirin Yukirin  220 Sep 18 18:54  .bash_logout
    ....

    可使用type命令检查是否有绑定，如果没有，自己绑定一个就可以了。

    1
    2
    Yukirin@DESKTOP-8BFBE1K:~$ type ll
    ll is aliased to `ls -alF'

    我这里定义为 -alF ，给文件名加了类型标记。你也可以自己组合参数进行定义。

    这里讲讲关于 ls -alh 打印出来的各项的含义

    1
    2
    3
    4
    5
    6
    7
    8
    9
    -rw-rw-r--  1  Yukirin Yukirin  153  Sep 26 15:52  file1.txt
    │           │  │       │        │    │             │
    │           │  │       │        │    │             └─ 文件名
    │           │  │       │        │    └─ 最近一次修改时间
    │           │  │       │        └─ 大小（字节）
    │           │  │       └─ 所属组
    │           │  └─ 所有者
    │           └─ 硬链接计数
    └─ 权限

  • tree：树状图显示目录结构

    1
    2
    3
    4
    5
    6
    tree                # 递归显示
    tree -L 1           # 只显示 1 层
    tree -L 2           # 显示 2 层
    tree -d             # 只显示目录
    tree -a             # 显示隐藏文件
    tree -h             # 显示大小

    tree命令可能并没有自带，如果使用tree提示找不到该命令，那么使用下列命令进行安装

    1
    sudo apt install tree

    tree命令效果如下，在查看文件和目录时还是很方便的。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    Yukirin@DESKTOP-8BFBE1K:~$ tree
    .
    ├── C_Test
    │   └── new.c
    ├── Untitled
    ├── WSL-Neovim排查记录.md
    ├── snap
    │   └── glow
    │       ├── 90
    │       ├── common
    │       └── current -> 90

  • mkdir：目录创建

    1
    2
    3
    4
    mkdir test                  # 创建单个目录
    mkdir dir1 dir2 dir3        # 创建多个目录
    mkdir -p a/b/c              # 递归创建多级目录
    mkdir -m 755 test           # 创建时指定权限

    这里讲一下：父目录不存在，递归创建时必须带上 -p 参数。直接使用 mkdir dir1/dir2/dir3 是创建不了的

    1
    2
    3
    4
    5
    6
    7
    8
    Yukirin@DESKTOP-8BFBE1K:~$ mkdir dir1/dir2/dir3
    mkdir: No such file or directory

    Yukirin@DESKTOP-8BFBE1K:~$ mkdir -p dir1/dir2/dir3
    Yukirin@DESKTOP-8BFBE1K:~$ tree
    ├── dir1
    │   └── dir2
    │       └── dir3

    关于创建时指定权限：这里的 755 是八进制权限码，每一位对应一类用户的使用权限。

    7-5-5 三位分别代表：

    位置对应对象英文
    第 1 位文件所有者user (u)
    第 2 位所属组group (g)
    第 3 位其他人others (o)

    3位数字的各自计算方法：

    数字权限含义
    0---无权限
    1--x只可执行
    2-w-只可写
    3-wx可写+执行
    4r--只可读
    5r-x可读+执行
    6rw-可读+可写
    7rwx全部权限

    所以755在这里表示：

    1
    2
    3
    7        5        5
    rwx      r-x      r-x
    所有者    组       其他人

    需要时直接查表算就行了。其实mkdir在指定权限时也支持符号写法：

    1
    2
    mkdir -m u=rwx,g=rx,o=rx test    # 等价于 755
    mkdir -m a=rwx test              # a=所有人，等价于 777

    这些写法都是等价的，符号写法规律很明显，不用查表算数字，我比较喜欢这种方法；不过数字写法速度快，背下常规几种组合之后直接用就行。

  • rmdir：空目录删除

    1
    2
    rmdir test                  # 删除空目录
    rmdir -p a/b/c              # 递归删除空目录（a/b/c 都为空时）

    这个命令只能删除空目录，若目录内部有文件将删除失败。删除带文件的目录应该用下文的rm -r 命令，rmdir不是很常用，了解一下。

  • touch：文件创建

    1
    2
    3
    4
    5
    6
    touch file.txt              # 创建空文件
    touch file1 file2           # 创建多个
    touch -c file.txt           # 文件不存在时不创建
    touch -a file.txt           # 只更新访问时间
    touch -m file.txt           # 只更新修改时间
    touch -t 202609260830 file  # 指定时间戳：YYYYMMDDhhmm

    这里讲一个有意思的点：touch原意其实并不是创建文件，touch的英文是触摸，原本设计的目的是修改文件的时间戳。不过当touch的目标文件不存在时，会先创建一个新文件。后续慢慢的就都使用该命令来创建文件了。

  • rm：删除文件或目录

    1
    2
    3
    4
    5
    6
    rm file.txt                 # 删除文件
    rm -i file.txt              # 删除前询问
    rm -f file.txt              # 强制删除，不询问
    rm -r dir                   # 递归删除目录
    rm -rf dir                  # 递归强制删除（危险！）
    rm -v file.txt              # 显示删除过程
    1
    2
    3
    4
    5
    Yukirin@DESKTOP-8BFBE1K:~/work$ rm -i a.out
    rm: remove regular file 'a.out'? n
    Yukirin@DESKTOP-8BFBE1K:~/work$ ll
    total 36
    -rwxrwxr-x 1 Yukirin Yukirin 16608 Sep 25 16:41 a.out*

    这里要提醒一下：rm -rf / 是删除整个root跟目录的自杀式命令，永远不要执行。现在的发行版基本都会拒绝rm -rf /这个命令，但是最好自己在上层加入一些防误操作保护，不要依赖内部实现。

    -v参数会在终端打印删除了什么。如果需要知道具体删除了哪些文件，可以带上该参数。

    1
    2
    3
    Yukirin@DESKTOP-8BFBE1K:~/work$ rm -v -i a.out
    rm: remove regular file 'a.out'? y
    removed 'a.out'

    可以给rm命令加上别名，带上确认与反馈机制，防止误操作。

    1
    alias rm='rm -i'

    上面我们提到，rm -r 可以用于删除带文件的目录，日常使用删除目录的命令基本都是使用这个。

    这里关于 rm -rf 的使用要注意一下：rm -rfv dir1/dir2/dir3 执行这行命令之后只会删除dir3以及dir3的所有子级目录！而不是摘掉dir1/dir2/dir3整棵树，dir1/dir2 都还在。如果想要摘掉 dir1/dir2/dir3 整棵树应该使用 rm -rfv dir1。这个地方不弄清楚很容易用错。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    Yukirin@DESKTOP-8BFBE1K:~$ tree dir1/
    dir1/
    ├── dir2
    │   ├── dir3
    │   └── nana.lua
    └── lala.lua

    2 directories, 3 files
    Yukirin@DESKTOP-8BFBE1K:~$ rm -rfv dir1/
    removed 'dir1/dir2/nana.lua'
    removed 'dir1/dir2/dir3'
    removed directory 'dir1/dir2'
    removed 'dir1/lala.lua'
    removed directory 'dir1/'
    Yukirin@DESKTOP-8BFBE1K:~$ find dir1
    find: ‘dir1’: No such file or directory

  • cp：复制文件和目录

    1
    2
    3
    4
    5
    6
    7
    8
    cp file1 file2              # 复制文件
    cp file1 dir/               # 复制到目录
    cp -r dir1 dir2             # 递归复制目录
    cp -a dir1 dir2             # 归档复制，保留权限、时间、链接
    cp -p file1 file2           # 保留权限和时间
    cp -i file1 file2           # 覆盖前询问
    cp -u file1 file2           # 仅当源更新时才复制
    cp -v file1 file2           # 显示过程
    1
    2
    3
    4
    Yukirin@DESKTOP-8BFBE1K:~/dir1$ cp -vp /home/Yukirin/work/tcp_client.c ../dir1/
    '/home/Yukirin/work/tcp_client.c' -> '../dir1/tcp_client.c'
    Yukirin@DESKTOP-8BFBE1K:~/dir1$ ls /home/Yukirin/dir1/
    dir2  tcp_client.c

    -i参数可以在即将发生覆盖行为时提醒用户。cp默认覆盖是静默无声的，某些情况下可能会导致误冲刷重要文件，所以建议使用别名将 cp -i 封装起来使用。

    Ps：-r 只做递归复制，属性和链接等等不做保留、而 -a 不仅可以递归复制，同时还保留权限、所有者、时间戳、符号链接、硬链接、扩展属性等，尽量做到一模一样。你可以这么理解：-r 只管内容一样，-a 则是原封不动整个文件包括属性一起打包带走。所以做备份时首选 -a 。

    1
    2
    3
    Yukirin@DESKTOP-8BFBE1K:~/dir1$ cp -iv tcp_client.c tcp_back.c
    cp: overwrite 'tcp_back.c'? y
    'tcp_client.c' -> 'tcp_back.c'

  • mv：移动文件/重命名

    1
    2
    3
    4
    5
    6
    7
    mv file1 file2              # 重命名
    mv file1 dir/               # 移动到目录
    mv dir1 dir2                # 重命名目录
    mv -i file1 file2           # 覆盖前询问
    mv -f file1 file2           # 强制覆盖
    mv -v file1 file2           # 显示过程
    mv -u file1 file2           # 仅当源更新时才移动

    mv的用法和参数与cp是一样的。cp是复制，mv是剪切，知道这个就好。

  • file：查看文件类型

    1
    2
    3
    file file.txt               # 文本文件
    file image.png              # PNG 图片
    file /bin/ls                # ELF 可执行文件

    例如：

    1
    2
    Yukirin@DESKTOP-8BFBE1K:~/dir1$ file tcp_back.c
    tcp_back.c: C source, ASCII text

  • stat：查看文件详细数据

    1
    stat file.txt

    能够看到文件大小、权限、访问时间、修改时间等等。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    Yukirin@DESKTOP-8BFBE1K:~/dir1$ stat tcp_back.c
      File: tcp_back.c
      size: 1739            Blocks: 8          IO Block: 4096   regular file
    Device: 8,48    Inode: 79667       Links: 1
    Access: (0664/-rw-rw-r--)  Uid: ( 1000/ Yukirin)   Gid: ( 1000/ Yukirin)
    Access: 2026-09-26 14:11:45.248891782 +0800
    Modify: 2026-09-26 12:02:43.217786645 +0800
    Change: 2026-09-26 12:02:43.217786645 +0800
     Birth: 2026-09-26 12:01:09.162633570 +0800

  • ln：创建链接

    1
    2
    3
    4
    5
    ln file1 file2              # 硬链接
    ln -s file1 file2           # 软链接（符号链接）
    ln -sf file1 file2          # 强制创建软链接，覆盖已有
    ln -si file1 file2          # 覆盖前询问
    ln -sv file1 file2          # 显示过程

    创建链接分为硬链接和软链接。使用 ln 命令默认创建硬链接；使用 ln -s 创建软连接。

    软链接有点类似Windows桌面的快捷方式，是一个独立的小文件，其内容是指向目标的路径。软连接有自己的inode，如果软连接指向的目标被删除，那么访问软连接时会报：No such file or directory 错误。这是符合常理的，我们在Windows中若快捷方式失活（通常是指向的源文件已被删除），访问也是会报找不到文件错误的。

    硬链接inode是相同的，举个例子：假如原件为 source1，使用 ln 命令为其创建硬链接 source2、 source3，那么source1、source2、source3的inode全都是相同的。这点区别于软链接，我们上面提到过，软链接是一个独立小文件，有自己的inode。

    由于共享inode，硬链接相当于是给原数据上了份保险：上面示例中我们删除掉source1，源数据并不会受损，而这个特性是软链接做不到的。

    这个特性你可以这么理解：我们删除数据时并不是从底层直接销毁数据，而是销毁其指向该部分内存的指针。我们创建了两个硬链接，就相当于多维护了两个指向该块数据的指针。当我们删除source1时，由于2和3仍指向该块数据，所以我们仍然能够获取这块内存，在上层体现出来的就是未被删掉。只有当我们将1、2、3全部删除时，这块数据才是真正丢了，体现在上层就是数据被删除。这就是硬链接的一个特定和优势。

    这里要注意硬链接的两个限制：

    • 不能跨文件系统（因为 inode 只在同一文件系统内唯一）
    • 不能对目录创建硬链接

    软链接没有这个限制。

    上文一直在提到 inode，这里讲讲 inode 是怎么回事：inode全称为 index node(索引节点)，是Unix文件系统用来描述一个文件的数据结构。你可以把它理解为一个结构体，内部是所指文件的元数据——例如权限、文件大小、所有者、所属组、链接计数等。其内部还维护有指向文件数据块的指针。

    总的来说 inode = 描述数据的元数据结构体 + 指向数据块的索引。

文件查看

  • cat：打印输出整个文件

    1
    2
    3
    4
    5
    6
    7
    8
    cat file.txt                # 输出全部内容
    cat -n file.txt             # 显示行号（所有行）
    cat -b file.txt             # 显示行号（跳过空行）
    cat -s file.txt             # 连续空行压缩为一行
    cat -A file.txt             # 显示不可见字符（$ 表示行尾，^I 表示 Tab）
    cat file1 file2             # 拼接多个文件输出
    cat file1 file2 > merged    # 合并写入新文件
    cat > file.txt              # 从键盘输入，Ctrl+D 结束

    我们这里有如下两个示例文件

    1
    2
    3
    4
    5
    6
    7
    8
    9
    file1.txt
    The quick brown fox jumps over the lazy dog.
    This sentence contains every letter of the alphabet.
    It is often used for typing practice and font testing.

    file2.txt
    Linux 的 cat 命令全称是 concatenate，意思是连接。
    它最常见的用途是查看文件内容，也可以把多个文件拼在一起。
    配合重定向符号，还能快速创建或追加文件。

    使用 cat file1 file2 拼接输出可以得到：

    1
    2
    3
    4
    5
    6
    7
    Yukirin@DESKTOP-8BFBE1K:~/docTest$ cat file1.txt file2.txt
    The quick brown fox jumps over the lazy dog.
    This sentence contains every letter of the alphabet.
    It is often used for typing practice and font testing.
    Linux 的 cat 命令全称是 concatenate，意思是连接。
    它最常见的用途是查看文件内容，也可以把多个文件拼在一起。
    配合重定向符号，还能快速创建或追加文件。

    将拼接的输出创建为一个新文件 file3.txt

    1
    2
    3
    4
    5
    6
    7
    8
    Yukirin@DESKTOP-8BFBE1K:~/docTest$ cat file1.txt file2.txt > file3.txt
    Yukirin@DESKTOP-8BFBE1K:~/docTest$ cat file3.txt
    The quick brown fox jumps over the lazy dog.
    This sentence contains every letter of the alphabet.
    It is often used for typing practice and font testing.
    Linux 的 cat 命令全称是 concatenate，意思是连接。
    它最常见的用途是查看文件内容，也可以把多个文件拼在一起。
    配合重定向符号，还能快速创建或追加文件。

    使用 cat > 文件 命令可以创建一个新文件，并且文件内容为你在终端输入的内容。输入完毕后 Ctrl+D 落盘。

    一般小文件使用cat方便快速查看和编辑，对于大文件不要使用cat，会刷屏。如果不慎刷屏使用 Ctrl+C 强行终止本轮调用。

  • less：分页查看

    1
    2
    3
    4
    5
    less file.txt               # 打开文件
    less +F file.txt            # 实时跟踪（类似 tail -f）
    less -N file.txt            # 显示行号
    less -S file.txt            # 不换行，超长行横向滚动
    less -i file.txt            # 搜索时忽略大小写

    分页查看用于日常查看大文件，内部支持简单的文本搜索功能，可以当作是一个简易的记事本。

    进入分页模式后有如下几个常用命令：

    按键功能
    空格 / PageDown下一页
    b / PageUp上一页
    g跳到文件头
    G跳到文件尾
    /pattern向下搜索
    ?pattern向上搜索
    n下一个匹配
    N上一个匹配
    q退出
    F进入实时跟踪模式（Ctrl+C 退出）

    注意：这里less的默认搜索是大小写敏感的，大小写输入错误是匹配不到的；如果不需要大小写敏感，可以使用less -I 打开文件。参数搜索栏支持基本的正则表达式，以下的形式都是可以的：

    1
    2
    3
    4
    /^Error          # 以 Error 开头的行
    /error$          # 以 error 结尾的行
    /foo.*bar        # foo 后跟任意字符再到 bar
    /[0-9]\+         # 一个或多个数字（注意 + 号要转义）

    搜索特殊字符时要记得转义，例如搜索/本身要用：/\/。此处给一个文本中搜索IP地址的示例：

    1
    /[0-9]\+\.[0-9]\+\.[0-9]\+\.[0-9]\+

  • head：查看文件开头

    1
    2
    3
    4
    5
    head file.txt               # 默认前 10 行
    head -n 20 file.txt         # 前 20 行
    head -n -5 file.txt         # 除了最后 5 行，全部显示
    head -c 100 file.txt        # 前 100 字节
    head -q file1 file2         # 多文件时不显示文件名

    使用演示示例如下(还是以上文 file1.txt file2.txt 为例)：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    Yukirin@DESKTOP-8BFBE1K:~/docTest$ cat file1.txt
    The quick brown fox jumps over the lazy dog.
    This sentence contains every letter of the alphabet.
    It is often used for typing practice and font testing.

    Yukirin@DESKTOP-8BFBE1K:~/docTest$ head -n 1 file1.txt
    The quick brown fox jumps over the lazy dog.

    Yukirin@DESKTOP-8BFBE1K:~/docTest$ head -n -1 file1.txt
    The quick brown fox jumps over the lazy dog.
    This sentence contains every letter of the alphabet.

    Yukirin@DESKTOP-8BFBE1K:~/docTest$ head -c 30 file1.txt
    The quick brown fox jumps over

    Yukirin@DESKTOP-8BFBE1K:~/docTest$ head file1.txt file2.txt
    ==> file1.txt <==
    The quick brown fox jumps over the lazy dog.
    This sentence contains every letter of the alphabet.
    It is often used for typing practice and font testing.

    ==> file2.txt <==
    Linux 的 cat 命令全称是 concatenate，意思是连接。
    它最常见的用途是查看文件内容，也可以把多个文件拼在一起。
    配合重定向符号，还能快速创建或追加文件。

    Yukirin@DESKTOP-8BFBE1K:~/docTest$ head -n 2 file1.txt file2.txt
    ==> file1.txt <==
    The quick brown fox jumps over the lazy dog.
    This sentence contains every letter of the alphabet.

    ==> file2.txt <==
    Linux 的 cat 命令全称是 concatenate，意思是连接。
    它最常见的用途是查看文件内容，也可以把多个文件拼在一起。

  • tail：查看文件尾部

    1
    2
    3
    4
    5
    6
    7
    tail file.txt               # 默认后 10 行
    tail -n 20 file.txt         # 后 20 行
    tail -n +5 file.txt         # 从第 5 行开始，显示到末尾
    tail -c 100 file.txt        # 后 100 字节
    tail -f log.txt             # 实时跟踪新增内容（最常用！）
    tail -F log.txt             # 跟踪文件，文件被删除重建后继续跟踪
    tail -f -n 100 log.txt      # 先显示后 100 行，再实时跟踪

    该命令用法与head是一样的，此处不做过多阐述。这里讲讲什么叫实时跟踪：tail -f或 tail -F 可以启用实时跟踪功能。实时跟踪指的是，文件内容在增长时，终端自动跟随显示最新的追加内容。

    例如我们使用 tail -f log.txt 监控日志文件，该条命令被执行后终端立即被挂起。当应用程序产生新日志并且写入到 log.txt 中时，终端会立即显示出来。

    -f / -F 两个参数都是开启文件跟踪，区别在于-f跟踪的是文件描述符，当文件移走后（例如该文件日志已满，需要mv到别的地方，并在原地重新创建新日志文件），-f跟踪的是旧文件，看不到新文件。

    而-F跟踪的是文件名，所以旧文件移走并原地创建新文件后能够继续跟踪，而不会跟丢。日常看日志用 -f，如果日志会被轮转，移走重建，用 -F 更稳妥。

  • wc：统计文件行数、字数、字节数

    1
    2
    3
    4
    5
    6
    7
    wc file.txt                 # 输出：行数 单词数 字节数
    wc -l file.txt              # 只统计行数（最常用）
    wc -w file.txt              # 只统计单词数
    wc -c file.txt              # 只统计字节数
    wc -m file.txt              # 只统计字符数
    wc -L file.txt              # 最长行的长度
    ls | wc -l                  # 统计当前目录文件数

    示例如下：

    1
    2
    Yukirin@DESKTOP-8BFBE1K:~/docTest$ wc file3.txt
      6  34 362 file3.txt

    输出从左至右分别为：该文件内容行数、单词数、总字节数。

    这里讲讲 wc -c 与 wc -m 的区别：-c统计的是字节，-m统计的是字符。在全英文文本的情况下，二者是等价的，但是对于中文或其它语言等多字节字符时就完全不同。举个例子：文件1内容为：“Hello,World”，通过wc -c 或 wc -m 统计出来都是 11 个字节/字符；文件2内容为：“你好世界”，由于中文字符为宽字符，UTF8中通常占3个字节，因此 wc -c 统计出来应为12个字节，wc -m 统计出来应为4个字符。这就是二者的差别。

    wc -m 的解析依赖当前的locale编码来判断一个字符是几个字节，如果locale没设置对那么 -m 计算出的字符数就是不准确的，这里要注意。

  • du：查看文件及目录的磁盘占用空间

    1
    2
    3
    4
    5
    6
    du file.txt                 # 文件占用（块单位）
    du -h file.txt              # 人类可读（KB/MB/GB）
    du -sh dir/                 # 目录总大小（最常用）
    du -sh *                    # 当前目录下每个文件/目录大小
    du -h --max-depth=1         # 只显示 1 层深度
    du -ah dir/                 # 包含所有文件

    这里在使用时可能你会发现一个统计问题（还是以上述file1/2/3.txt为例）：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    Yukirin@DESKTOP-8BFBE1K:~/docTest$ ls -alh
    -rw-rw-r--  1 Yukirin Yukirin  153 Sep 26 15:52 file1.txt
    -rw-rw-r--  1 Yukirin Yukirin  209 Sep 26 15:52 file2.txt
    -rw-rw-r--  1 Yukirin Yukirin  362 Sep 26 16:05 file3.txt

    Yukirin@DESKTOP-8BFBE1K:~/docTest$ du -sh *
    4.0K    file1.txt
    4.0K    file2.txt
    4.0K    file3.txt

    Yukirin@DESKTOP-8BFBE1K:~/docTest$ cd ..
    Yukirin@DESKTOP-8BFBE1K:~$ du -sh docTest/
    16K     docTest/

    发现了吗？我们文件大小为 153/209/362，通过磁盘占用统计出来竟然是4Kb？这里要强调一下：du的占用统计是从磁盘的角度来计算的，而磁盘是由簇和扇区构成的，簇是整个文件系统最小的分配单位，而簇又由多个扇区构成。目前我们的几个文件都只有几百字节，大小是很小的，但是依然需要占用一个簇和其中一个扇区，所以统计出来才为4Kb。这也侧面说明我们当前这个系统的文件系统最小扇区为4.0Kb。

  • df：查看磁盘分区使用情况

    1
    2
    3
    4
    df -h                       # 人类可读（最常用）
    df -h /home                 # 只看指定挂载点
    df -i                       # 查看 inode 使用情况
    df -T                       # 显示文件系统类型

    这里要分清 du/df 的区别：du是针对单个文件以及目录进行磁盘占用统计，而df是从宏观上针对整个磁盘进行统计。

  • hexdump：十六进制查看

    1
    2
    3
    hexdump -C file.bin         # 标准十六进制 + ASCII（最常用）
    hexdump -C -n 64 file.bin   # 只看前 64 字节
    hexdump -C -s 128 file.bin  # 从偏移 128 开始

    这是Linux用来以16进制查看文件的原生工具，在平时分析一些协议时也很常用。默认情况下每行输出16字节，半字分组。最左侧是偏移量，中间是数据内容：

    1
    2
    3
    4
    5
    Yukirin@DESKTOP-8BFBE1K:~/docTest$ hexdump file3.txt
    0000000 6854 2065 7571 6369 206b 7262 776f 206e
    0000010 6f66 2078 756a 706d 2073 766f 7265 7420
    0000020 6568 6c20 7a61 2079 6f64 2e67 540a 6968
    ....

    不过这种方式不太直观，可以使用 hexdump -C 将其拆成标准16进制格式。

    1
    2
    3
    4
    Yukirin@DESKTOP-8BFBE1K:~/docTest$ hexdump -C file3.txt
    00000000  54 68 65 20 71 75 69 63  6b 20 62 72 6f 77 6e 20  |The quick brown |
    00000010  66 6f 78 20 6a 75 6d 70  73 20 6f 76 65 72 20 74  |fox jumps over t|
    00000020  68 65 20 6c 61 7a 79 20  64 6f 67 2e 0a 54 68 69  |he lazy dog..Thi|
    1
    2
    3
    4
    5
    6
    00000000  54 68 65 20 71 75 69 63  6b 20 62 72 ...         |Hello World.|
    │         │                        │                       │
    │         │                        │                       └─ ASCII 显示
    │         │                        └─ 后8个字节
    │         └─ 前8个字节
    └─ 偏移量（十六进制!）

    不过hexdump不只可以看16进制，也可以其它进制的方式进行查看。其命令参数如下所示：

    选项作用
    -C规范 hex + ASCII
    -b每字节显示为八进制
    -c每字节显示为字符（转义形式）
    -d每字节显示为十进制
    -o每字节显示为八进制（两位）
    -x每字节显示为十六进制
    -n N只显示前 N 字节
    -s N跳过前 N 字节再显示
    -v不省略重复行（默认连续相同行会显示 *）

  • xxd：十六进制查看

    1
    2
    3
    4
    xxd file.bin                # 十六进制 + ASCII
    xxd -l 64 file.bin          # 前 64 字节
    xxd -s 128 file.bin         # 从偏移 128 开始
    xxd -r hex.txt > file.bin   # 反向：十六进制文本还原为二进制

    这个命令与上面的hexdump是高度重合的。区别在于，hexdump是系统原装的，而xxd是vim编辑器的附件工具包。如果你没有装Vim的话可能没有这个工具。xxd有反色显示，我个人比较喜欢xxd的观感，所以常用xxd。

    xxd还有个hexdump做不到的特性，那就是能够进行反向还原：将16进制重新还原回2进制。

    1
    2
    xxd file.bin > dump.txt        # 导出为文本
    xxd -r dump.txt > back.bin     # 从文本还原为二进制

    hexdump没有这个功能，所以在做二进制<->文本转换时使用xxd。

  • grep：文本搜索

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    grep "error" log.txt            # 搜索包含 error 的行
    grep -i "error" log.txt         # 忽略大小写
    grep -n "error" log.txt         # 显示行号
    grep -v "error" log.txt         # 反向：不包含 error 的行
    grep -c "error" log.txt         # 统计匹配行数
    grep -r "error" dir/            # 递归搜索目录
    grep -rn "error" dir/           # 递归 + 行号
    grep -w "error" log.txt         # 只匹配整词
    grep -A 3 "error" log.txt       # 显示匹配行及后 3 行
    grep -B 3 "error" log.txt       # 显示匹配行及前 3 行
    grep -C 3 "error" log.txt       # 前后各 3 行
    grep -E "err|warn" log.txt      # 扩展正则（或）
    grep -l "error" *.txt           # 只显示匹配的文件名

    grep是Linux中最常用的搜索工具。使用场景十分广泛，例如我要在某个文件或某几个文件中找内容：

    1
    2
    grep "error" app.log
    grep -n "TODO" *.c          # -n 显示行号

    再或者配合管道，从输出中过滤出需要的内容：

    1
    2
    3
    ps aux | grep nginx         # 找 nginx 进程
    ls -alh | grep ".txt"       # 只看 txt 文件
    df -h | grep "/dev/sda"     # 只看某个磁盘

    grep还有个很强大的地方是支持基本正则表达式(BRE)和拓展正则表达式(ERE)，如果会用正则的话那么grep将非常高效和强大：

    1
    2
    3
    4
    5
    grep "^Error" app.log          # 以 Error 开头
    grep "done$" app.log           # 以 done 结尾
    grep -E "error|fail|warn" app.log   # 匹配多个词之一
    grep -E "[0-9]{3}-[0-9]{4}" file    # 电话格式
    grep "colou\?r" file           # 注意 ? 号转义

查找与定位

]]> https://r6blog.online/2026/09/26/%E5%B5%8C%E5%85%A5%E5%BC%8F2026092601/ 2026-09-26T01:28:47.000Z 前言

本篇文章用于记录一些Linux系统中的常用操作命令。Linux的命令系统是十分强大和复杂的，为了能够熟练进行系统操作，在这里归档一些常用命令]]>

Linux 常用命令归档 2026-10-08T07:15:10.247Z R6bandito 现象及原因

环境: WSL2 + Ubuntu(26.04)。在环境中装好LazyVim插件后，发现编辑器的智能补全功能并不完善，C头文件以及相关函数不能够在补全菜单中显示。经查，是我系统虽然安装了clangd等前置，但LazyVim并不会直接使用系统里安装的工具，而是通过Mason包管理工具来链接外部工具。具体来说：LazyVim的默认策略是不直接启用这类语言服务器，而是把启用工作交给Mason系的组件；而Mason系只认自己安装的服务器。我的clangd是apt装在系统里的，Mason管理的指定位置里并没有它——两头都不认，所以尽管系统已经正确安装clangd，却谁都没有把它启用起来，该功能也就失效了。

解决方法

  • 首先应该确保在系统中正确安装开发环境：
1
2
3
gcc --version
make --version
ld --version

并补一条真实编译测试：

1
2
printf '#include <stdio.h>\nint main(void){return 0;}\n' > /tmp/t.c \
  && gcc /tmp/t.c -o /tmp/t.bin && /tmp/t.bin && echo "编译链 OK"

确保基础编译工具链已被正确安装，若未安装请使用以下命令装前置：

1
2
sudo apt update
sudo apt install -y build-essential

  • 使用下列命令确保系统已安装clangd

    1
    sudo apt install clangd

    这里简单讲讲什么是clangd：clangd本质是一个常驻的C/C++语义分析引擎服务，由LLVM开发，是编辑器实现智能补全的核心。在我们使用编辑器对源文件进行编辑时，clangd会在后台实时解析你的代码——做的事情和编译器的前半程一样（展开头文件与宏、构建语法树），但不产出可执行文件，而是通过这个过程获取你当前的代码结构。当你输入部分关键字(例如str)时，clangd会收集当前光标所处作用域内的所有可见符号（局部变量、参数、函数名，以及#include引入的声明），按前缀过滤后返回给编辑器。这也是为什么你在光标处输入str后，补全菜单会自动跳出 strcmp、strcpy等等符号。

  • 前置全部正确安装之后，使用新增一个nvim的clangd.lua配置文件 ~/.config/nvim/lua/plugins/clangd.lua 。在新创建的文件中将下列代码复制进去：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    return {
      {
        "neovim/nvim-lspconfig",
        opts = {
          servers = {
            clangd = { mason = false }, 
          },
        },
      },
    }

    这段代码的含义是告诉LazyVim：clangd这个语言服务器不走Mason管理，直接使用本机系统已经装好的clangd。

  • 用LazyVim打开一个源文件，可见自动补全已经正常运行（也可以用:LspInfo查看clangd是否处于attached状态）：

关于智能补全

这里简单来聊聊LazyVim的智能补全机制，究竟是怎么做到智能补全的。首先得清楚：LazyVim本质上不是编辑器，而是针对Neovim打造的一套个性化配置。我们在使用编辑器时，用的是Neovim，而各种个性化以及智能化配置是由LazyVim配置而来的。

Neovim内置了LSP客户端，LSP是语言服务器协议，用于编辑器与语义分析服务(比如我们的clangd)之间的桥梁。其整个智能补全的简单工作流程如下：

  • 我们在编辑器中输入s-t-r三个字符，LSP会向clangd服务发送一条JSON信息，这条信息中包含文件路径和当前光标位置。注意，这里并不包含我们输入的内容——clangd会自己从文件内容里读取光标前的文本，提取出我们正在输入的词。
  • clangd收到信息后，定位到当前光标位置，并且收集所有可见的相关符号，过滤后返回给LSP。LSP收到后返回给上层服务进行综合排序，排序完毕后通过菜单呈现出来。这就是我们看到的智能补全菜单了。
]]> https://r6blog.online/2026/09/25/%E5%B5%8C%E5%85%A5%E5%BC%8F2026092501/ 2026-09-25T05:02:38.000Z 现象及原因

环境: WSL2 + Ubuntu(26.04)。在环境中装好LazyVim插件后，发现编辑器的智能补全功能并不完善]]>

LazyVim C开发环境智能补全问题 2026-10-08T07:15:10.247Z R6bandito 前言

本偏文章主要用于记录一些自己平时看到的觉得不错的笔面试题目，虽然偏八股但是仔细研究一下还是能从里面学到不少门道的。长期随缘更新，题目顺序不固定，目前先线性往下慢慢写吧。文章可能难免会有缺陷，若您发现问题还望通过邮箱及时与我联系，帮助我及时改正，不胜感激。

主目录

typdef int* INT_PTR; 和 #define INT_PTR int* 在声明多个变量时有什么不同？

这个题目有点意思，这里要清楚 #define 是宏替换，而 typedef 是类型重映射，这是二者的本质区别。看下面这个示例：

1
2
3
4
5
6
7
8
9
typedef int* INT_PTR;
#define INT_PPTR int*

void 
test( void )
{
    INT_PTR a,b;// a b 均为 INT_PTR 类型.
    INT_PPTR c,d;   // c 为 int*，d为int.
}

在IDE中写出上述示例，你查看变量类型会发现 a,b 均为 INT_PTR 类型；而 c 为 int* 类型，d 为 int 类型，二者很明显是有区别的。原因在于：在 #define 宏定义情况下，INT_PPTR c,d;被展开为了 int* c,d;，编译器将其理解为一个 int* c 变量和一个 d 变量（C语言中，声明变量若未显示指明类型则默认为 int 型）。因此才会出现c，d类型不一致的情况。

而在类型重映射情况下，INT_PTR a,b; 被编译器解释为了 INT_PTR a, INT_PTR b; 即 int* a, int* b;，因此二者都是同一个类型。

什么是整数提升？unsigned char a = 0xFF; if( a == ~0x00 )这个条件成立吗？

首先，这个条件肯定是永远不会成立的。

这里涉及到C语言中一个类型运算规则：在C语言中，只要是参与运算的参数类型小于int，那么会先将该类型提升到int或uint再参与运算。而~0x00经过按位取反后，得到的结果应为0xFFFFFFFF，同时a经过提升变为0x000000FF参与比较，0x000000FF 很显然不等于 0xFFFFFFFF。因此这个条件永远是false。

0x01 << 3 + 1 结果是多少？为什么？

嗯，很经典的一个问题，也很简单，考的是运算符优先级的问题。这里加法运算优先级高于位移优先级，因此实际等价于 0x01 << (3 + 1) = 0x01 << 4 = 16 。关于运算符优先级我这里不详细给出，只是强调一下：在实际运用中，如果不是很确定运算的优先级，那么请统一加括号，不要怕难看。哪怕是写成 return (...(0x01 << (3 + 1))...) 这样都没有问题，因为计算是明确的。

定义一个结构，同一块内存访问能够存放4个字节数组，也能够作为32位整数访问，同时还支持按位访问。

很明显，同一块内存在不同情况下要搭建不同的内存模型，我们需要用到union联合体结构。

union联合体是一种C语言构造类型，所有成员共享同一块内存空间，其大小等于最大成员的大小，用于在同一内存中存储不同类型的数据以节省空间。这题相关结构定义如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
typedef union {
    uint8_t array[4];
    uint32_t var;
    struct {
        uint32_t bit0 : 1;
        uint32_t bit1 : 1;
        uint32_t bit2 : 1;
        ...
        uint32_t bit30: 1;
        uint32_t bit31: 1;
    } bits;
} MyStructure;

这里强调一下：位域这个结构可以详细了解下理论，但是少用。原因在于位域移植性很糟糕，在不同的字节序主机上同一套代码是完全不同的逻辑。因此在进行位操作时请使用相关操作符，而不是使用位域。

字符串反转（不借助新数组，原地反转一个字符串）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
void 
reverse_string( char *str )
{
    if ( !str || strlen(str) < 2 ) return;

    char *start = str;
    char *end = str + strlen(str) - 1;

    while( start < end )
    {
        char temp = *start;
        *start = *end;
        *end = temp;

        start++;
        end--;
    }
}

这里不做过多讲解，直接给一轮流程图：

模拟实现 strcpy 与 memcpy

my_strcpy:

1
2
3
4
5
6
7
8
9
10
11
void 
my_strcpy( char *dest, const char *src )
{
    if ( !dest || !src )
        return;

    while( *src != '\0' )
        *dest++ = *src++;

    *dest = '\0';
}

my_memcpy:

1
2
3
4
5
6
7
8
9
10
11
void 
my_memcpy( void *dest, const void *src, size_t n )
{
    if ( !dest || !src || n == 0 )
        return;

    uint8_t *d = (uint8_t *)dest;
    const uint8_t *s = (const uint8_t *)src;
    while( n-- )
        *d++ = *s++;
}

都是很简单的手写题，有个思路就行，不做过多讲解。

冒泡排序

这里先简单讲讲冒泡排序的原理：

首先我们现在手上有一个待排无序数组arr[5, 1, 7, 3, 2, 4]。我们可以先在这6个数中，每两个数之间进行比较排序，将较大的数往后排。即：

  1. 5和1比较：(5>1) ? 结果为True，5和1交换一次，原数组变为 arr[1, 5, 7, 3, 2, 4].
  2. 再拿5和7比较：(5>7)? 结果为false，5和7不交换，数组保持不变.
  3. 7和3比较：(7>3)? 结果为True，7和3交换一次，数组变为 arr[1, 5, 3, 7, 2, 4].
  4. 7和2比较：(7>2)? 结果为True，7和2交换一次，数组变为 arr[1, 5, 3, 2, 7, 4].
  5. 7和4比较：(7>4)? 结果为True，7和4交换一次，数组变为 arr[1, 5, 3, 2, 4, 7].

可以看到我们进行了5次比较，成功将整个序列中最大的数放到了最后。以上整个流程我们称之为一轮排序。既然经过一轮能选出一个最大的，那么我们下次排序剔除掉排好的这个，是不是又可以选出一个次最大的数据出来？最后，我们整个数组序列有6个元素，我们通过5轮排序，就能够将整个数组按从小到大的顺序进行序列化了。这就是冒泡排序的原理。以下是冒泡排序的参考程序实现：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
void 
bubble_sort( int *arr, int len )
{
    if ( !arr || len < 2 )
        return;

    /* 外层循环：排序轮数. */
    for( uint8_t i = 0; i < len - 1; i++ )
    {
        uint8_t isSwapped = 0;
        /* 内层循环：每轮需要的比较次数. */
        for( uint8_t j = 0; j < len - 1 - i; j++ )
        {
            if ( arr[j] > arr[j + 1] )
            {
                int temp = arr[j];
                arr[j] = arr[j + 1];
                arr[j + 1] = temp;
                isSwapped = 1;
            }
        }

        if ( !isSwapped )
            break;
    }
}

这里讲一下 isSwapped 这个标志位：这是个优化标志位，当我们给出的数组本来就是有序数组，或经过某轮排序后整体已经变为有序序列时，就没必要继续往下进行了。该标志位在数组已经有序后，其在下一轮的遍历流程中不会被置1（数组已经有序，不会再进行任何交换操作），此时检测到该标志位没有置1后，直接提前退出就可以了。

Ps：这里循环变量用的是u8，有溢出风险。此处只做演示说明，实际使用时根据具体情况来决定其类型。

一些位操作相关逻辑

位操作算是嵌入式基本功了，此处给出一些位操作相关逻辑：

1
2
3
4
5
6
7
8
9
10
11
/* 将 reg 的第 x 位置1. */
#define SET_BIT(reg, x)      ((reg) |= (0x01u << (x)))

/* 将 reg 的第 x 位清0. */ 
#define CLEAR_BIT(reg, x)    ((reg) &= (~(0x01u << (x))))

/* 读取 reg 的第 x 位. */
#define GET_BIT(reg, x)      (((reg) >> (x)) & 0x01u)

/* 翻转 reg 的第 x 位. */
#define TOGGLE_BIT(reg, x)   ((reg) ^= (0x01u << (x)))

“统计一个字节里面有多少个1” 这是一道非常经典的笔试题目，一个很简单的位移使用，我曾今也碰到过：

1
2
3
4
5
6
7
8
9
10
11
12
uint8_t 
count_ones( uint8_t data )
{
    uint8_t count = 0;
    for( uint8_t i = 0; i < 8; i++ )
    {
        if ( (data & (0x01 << i)) )
            count++;
    }

    return count;
}

这是我曾经的写法，不能说是错的，但是还有一种更巧妙的写法：

1
2
3
4
5
6
7
8
9
10
11
12
uint8_t 
count_ones( uint8_t data )
{
    uint8_t count = 0;
    while( data > 0 )
    {
        data &= (data - 1);
        count++;
    }

    return count;
}

怎么样？不管data是什么数，data & (data - 1) 总能够把data最低位的一个1去丢。

例如data = 0b1101 1010、data - 1 = 0b1101 1001 。data & (data - 1) = 0b1101 1000 看到没？经过一次操作将其最低的一个1去掉了，此时count=1。继续while循环直到data = 0，刚好把5个1全部去掉，count=5，这不就统计出来了吗？ 这个方法比较巧妙，后续求一个数是否是2的幂等数时，也会用到类似的思想。

单链表反转

单链表反转也是个比较经典的考点，这里用文字叙述有些不易理解，所以先以下图进行一个情景带入：

翻转前链表的头节点为A，我们要求链表翻转后D为头节点，A为尾节点。这里我们采用三指针法进行翻转：

  • 定义三个指针 curr、next、prev。初始状态下，curr指向当前头节点，next与prev初始化为NULL。
  • 将next指向curr->next。也就是用next记住当前curr节点的下一个节点，防止翻转curr后丢掉后继节点。
  • 将curr当前节点翻转指向prev，并且同步更新prev和curr。
  • 重复上述操作，将next指向curr的next，然后对curr指向节点进行翻转，并同步更新curr与prev。
  • 一直循环该翻转操作，直到最后一个节点D也成功翻转，变为头节点。

下列是三指针法进行单链表翻转的参考示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
typedef struct Node Node;
struct Node {
    uint8_t data;
    Node *next;
};

Node *
list_reverse( Node *head )
{
    if ( !head )  return NULL;

    Node *curr = head;
    Node *next = NULL;
    Node *prev = NULL;

    while( curr != NULL )
    {
        next = curr->next;
        curr->next = prev;
        prev = curr;
        curr = next;
    }

    return prev;
}
数组单次遍历找最大值和次大值

数组找最值并不复杂，核心点在于一次循环必须找出最大和次大值。这里我们的思路是在给定数组的前两个元素中，先找出暂定最大值，剩下一个作为暂定次大值。后续从数组的第三个元素开始向后遍历，若找到一个比当前最大值还要大的元素，则更新当前最大值，同时用旧的最大值来更新次大值；若找到一个大于当前次大值，却又小于最大值的元素，则只更新次大值。一轮循环过后成功拿到最大、次大值。

程序示例如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
void 
find_max_sec( int *arr, int len, int *Omax, int *Osec )
{
    if ( !arr || len < 2 )
        return;

    /* 先在前两个元素中暂定最大值与次大值. */
    int max = arr[0];
    int sec = arr[1];
    if ( max < sec )
    {
        int temp = max;
        max = sec;
        sec = temp;
    }

    /* 从第三个元素开始遍历. */
    for( uint32_t i = 2; i < len; i++ )
    {
        /* 找到比当前最大值还大的元素. 更新最大值与次大值. */
        if ( arr[i] > max )
        {
            sec = max;
            max = arr[i];
        }
        else if ( (arr[i] > sec) && (arr[i] != max) )
        {
            /* 找到大于次大值且小于最大值的元素. 仅更新次大值. */
            sec = arr[i];
        }
    }

    /* 一轮遍历结束. 根据参数进行结果输出. */
    if ( Omax ) *Omax = max;
    if ( Osec ) *Osec = sec;
}
判断一个数是不是2的幂

判断一个数是否是2的幂等数，你可能会想：直接对2循环取余判断是否为0不就完了吗？这有啥难的？确实，不过我们这里要讲的是通过位操作来判断2的幂等数。通过位操作进行判断是一个经典的笔试题，同时也有确切的应用场景。你比如在环形缓冲区中我们进行优化时就会用到该方法（详见：环形缓冲区）

1
2
3
4
5
int 
is_power_of_two( uint32_t data )
{
    return ((data > 0) && (data & (data - 1)) == 0);
}

这里简单讲讲为什么2的幂等数能够使用 data & (data - 1) == 0 来判断：因为2的幂等数在2进制中只有一个1，例如64(0b0100 0000)、128(0b1000 0000) 。这些数减去1后会把那个1变成0，而把剩下的0变成1。比如 128 - 1 = 127(0b0111 1111)，这样两个一做与运算data & (data - 1) = 0b1000 0000 & 0b0111 1111 = 0 结果不就是0吗？

一条 data & (data - 1) 位运算在底层看来就是单纯一条指令，仅需一个时钟周期。而如果你采用循环取余的方式，由于底层没有专门的除法电路，其除法器通常是通过反复的减法、移位、试商等微码循环来实现的。这就意味着一条除法指令往往需要花费数十个时钟周期，还要涉及循环开销。这个性能帐我相信谁都能算明白。

#define SQUARE(x) x*x，那么 SQUARE(2+3) 等于多少？

这是个很典型的带参宏定义陷阱题。我们首先需要清楚宏定义的本质：在预处理阶段进行文本替换。也就是说你丢在括号里面的这一个表达式会原封不动的通过宏定义进行文本更换。

1
2
3
#define SQUARE(x)   x*x

SQUARE(2+3) -(宏定义展开)-> 2+3*2+3.

发现问题了吗？我们原意是计算5*5 = 25，结果宏定义展开后由于运算符优先级的作用，导致计算式变为了 2+6+3 = 11 ，这就是带参宏定义很容易出现的问题。所以在进行宏定义时，入参必须写成如下形式：

1
#define SQUARE(x)   ((x)*(x))

通过括号来保证运算有一个确定的优先级，而不受运算符优先级的影响。

大小端字节序判断

字节序判断这个已经无需多言了，相信只要看过笔试整理相关文章的100%都能遇到。这里简单讲讲什么是大小端字节序并给出两种判断方法。

大端字节序(MSB)：多字节数据的高位字节存放在内存的低地址，低位字节存放在内存的高地址。例如 0x12345678这个32位数据存储在 0x1000 ~ 0x1003 这四个字节的位置。那么在MSB字节序下 0x1000 存的就是 0x12(高位字节)，对应的 0x1003存的就是 0x78(低位字节)。

小端字节序(LSB)：多字节数据在内存中低地址存放低位字节，高地址存放高位字节的存储方式（低地址存低位，高地址存高位）。还是以上述 0x12345678 为例，在LSB字节序下面 0x1000 存的是 0x78(低位字节)，对应的 0x1003存的是 0x12(高位字节)。

二者的内存布局如下图所示：

以下给出两种方法来判断当前环境字节序：

  • 通过联合体(union)进行判断，这也是最为常见的一个方法。
1
2
3
4
5
6
7
8
9
10
11
12
union {
    uint32_t data;
    uint8_t array[4];
} uio;

int 
check_endian( void )
{
    uio.data = 0x12345678ul;
    /* 返回 1 为MSB字节序；返回 0 为LSB字节序. */
    return ((uio.array[0] == 0x12) ? 1 : 0);
}
  • 通过指针强转进行判断。
1
2
3
4
5
6
7
int 
check_endian( void )
{
    uint32_t i = 1;
    /* 返回 1 为MSB字节序；返回 0 为LSB字节序. */
    return (((*(uint8_t *)&i) == 0) ? 1 : 0);
}

我们所使用的 ARM Cortex-M 架构就是典型的LSB字节序，而网络字节序是典型的MSB字节序。

I2C为什么需要上拉电阻？一般阻值为多大比较合适？

首先从I2C的架构方面来入手，I2C可以用来进行多主多从组网，在多主机情况下，I2C总线上谁控制住时钟SCL谁就是本次通信的主机。I2C总线有线与仲裁机制，所以就算多个主机同时进行通信，最终在仲裁机制下只会有一个设备得以成功与从机建立通信。而在这仲裁期间，假如我们使用推挽输出，那么当一个设备输出高电平1，另一个设备接地输出低电平0时，那么在总线上就会出现一个从 VCC 直接短路到 GND 的回路，这回产生一个瞬时大电流很容易会导致GPIO口被烧毁。

因此在I2C上我们必须使用开漏输出，这意味着高电平无法输出到总线，那么这个时候就需要一个显式的外部上拉来完成总线电平输出高这个动作，这就是为什么需要外部上拉电阻。

这个上拉电阻的阻值在 3.3V 系统中，我们通常采用4.7kΩ比较合适。这个上拉电阻的阻值不能过大，也不能太小

  • 阻值过大的话由于RC电路特性，上升沿会变缓。若通信速率比较高的话很容易会出现在SCL还没充到高电平，SDA就可能已经被下拉到0了，导致通信误码、ACK丢失等问题。
  • 阻值过小上升沿陡峭，适合较高速率的通信。但是同时总线上电流比较大，器件功耗大发热大，甚至如果电流超过了I2C器件的承载值的话可能会烧器件。
I2C时钟拉伸

正常情况下，I2C总线的时钟SCL是由主机控制的，但在某些情况下，由于主机通信速率过快从机处理不过来，部分从机会主动抓住SCL时钟线（从机拉低SCL），让主机无法继续产生时钟脉冲。从机处理完毕后再松开SCL，将SCL控制权交还给主机，继续进行接下来的通信。

从机主动拽住SCL时钟线的这个机制就叫作I2C的时钟拉伸机制。

这里以一个具体的时序例子来看看时钟拉伸：

正常情况下，主机将依次发出A、B、C、D、E五个脉冲，在脉冲高电平期间，SDA数据线被锁存，从机在高电平期间读取SDA数据线上的数据，这正是I2C总线的主机向从机写数据行为。

但是在①处，由于从机需要执行一些耗时操作（例如从机内部E2PROM写入行为），因此必须拽住SCL时钟，防止主机继续发送导致数据丢失、通信失败。

主机在经过B、C之间的数据建立时间后，主动释放时钟线想要让SCL被上拉到高电平进行数据采样。但是释放后主机发现SCL并没有按照预期升到高电平，于是推测目前有从机正在进行时钟拉伸动作，于是主机便等待并定时轮询SCL状态。

等到从机释放SCL后，后续通信流程正常进行。上述就是一次I2C时钟拉伸的流程。

这里我再强调下I2C时钟拉伸的时机：时钟拉伸是发生在SCL低电平期间的！也就是时钟拉伸发生的同时主机也是在拉低SCL的。从机不能够在SCL高电平期间拉低SCL!因为I2C中高电平是采样时间，如果从机提前拉低SCL会产生一个下降沿，相当于新产生了一个时钟边沿，破坏了主机时钟的完整性，会导致后续通信出问题！

中断服务函数注意事项

中断ISR是硬实时上下文，阻塞中断会导致整个系统挂起，因此我们在编写ISR时要做到快、短、安全、可重入。

  • 中断内部不要调用延时或阻塞相关的API，会严重破坏系统实时性。
  • 中断内部不要调用不可重入API，标准C的malloc就是个典型例子，malloc是非线程安全的，假如主循环中某处malloc调用被ISR中断了，而在ISR中又调用malloc，很容易会导致堆结构损坏。
  • 对于一些需要在中断中修改，主程序判断使用的全局变量，请加上volatile。因为编译器在编译主循环代码时是感知不到ISR的，因此在某些极端条件下会过度优化导致程序逻辑出错。加上volatile禁止编译器进行重排和缓存。
  • 记得及时清除中断标志，正确做法是进入ISR后应首先清除标志再进行逻辑，否则可能会因为某些路径提前退出ISR或忘记清除标志导致无限ISR风暴。
  • 注意栈空间。ISR上下文使用的是MSP主栈指针，是会累积压栈的。什么叫累积压栈？举个例子：
    当你从main中调用 funcA()，内部再调用funcB()时，你的调用栈是这样的：main->funcA()->funcB()。
    这一整个调用链上的每个函数的内核通用寄存器以及栈局部数据结构都是压在MSP上的(裸机示例)，此时funcB()被ISR中断，ISR的整个栈是直接接着MSP中的funcB()继续往后压的。如果你的栈已经在前续调用中被使用得差不多了，此时ISR压上来很可能会栈溢出。这是个比较隐蔽的问题，要注意。
  • 中断中不要进行复杂的逻辑处理和运算。这一点可以和第一点归于一类，都违反了中断的快、短准则，会影响系统实时性。要利用好中断下半段处理，将耗时操作挪到中断后半段去（例如FreeRTOS，在PendSV中进行任务切换，这其实也是利用了中段下半部分的处理机制）。
I2C 死锁
]]> https://r6blog.online/2026/09/22/%E5%B5%8C%E5%85%A5%E5%BC%8F2026092201/ 2026-09-22T03:01:57.000Z 前言

本偏文章主要用于记录一些自己平时看到的觉得不错的笔面试题目，虽然偏八股但是仔细研究一下还是能从里面学到不少门道的。长期随缘更新，题目顺序不固]]>

一些嵌入式笔面试问题收录 2026-10-08T07:15:10.247Z R6bandito 前言

ARP全称为 Address Resolution Protocol 即地址解析协议。我们已经知道，IP网络中有IP地址这一概念。但是需要明白，在以太网环境中，数据帧在以太网上传输靠的是MAC地址，而IP只是逻辑地址负责逐跳传输。数据帧在传输过程中，不仅需要填上IP，还需要填上MAC地址才能正确在网络环境中路由。

那么在这个流程下，就会出现这样一个问题：我们知道对端的IP地址，但是不知道MAC地址，IP层在组帧的时候没有MAC组不了，自然这帧数据就无法通过网卡被发送出去。为了解决这个问题，我们就引入了ARP协议。

ARP协议的本质其实就是：通过IP逻辑地址来解析出设备的物理MAC地址。

ARP协议简介

了解ARP，首先得弄清楚其所处的位置。在通常情况下，我们可以认为ARP位于TCP/IP四层经典模型（详见OSI七层模型与TCP/IP四层经典模型）的网络层，与IP协议并列。

当我们在局域网中进行通信时，拿到的是目标主机的IP地址，但是IP只是逻辑地址，下层在通信时使用的是MAC地址。因此为了保证下一跳能够跳转到正确地址，IP层就会通过ARP协议获得对端的正确MAC地址，进而填入数据包发给下层去路由。

这里要提前说明一下：ARP协议只适用于同一网段，若两台设备位于不同网段，则不能够直接进行交互，需要交由网关进行代劳。

ARP报文格式

ARP报文格式如下图所示

（勘误：图中FCS校验部分实际应为4字节，图中笔误写成了6字节，下同）

报文中各数据区含义定义如下：

字段长度说明
硬件类型2 字节以太网为 1
协议类型2 字节IPv4 为 0x0800
硬件地址长度1 字节MAC 地址长度，6
协议地址长度1 字节IP 地址长度，4
操作码2 字节1=请求，2=应答
发送方 MAC6 字节请求方的 MAC
发送方 IP4 字节请求方的 IP
目标 MAC6 字节请求时填 0，应答时填对方 MAC
目标 IP4 字节要解析的目标 IP

这里要注意一下，IP协议与ARP协议是并列的，所以ARP协议的报文直接封装在以太网帧中，而不是像ICMP一样封装在IP数据报中。

以太网帧头部的帧类型：0x0800 为IP数据包；0x0806 为ARP数据包。在ARP通信中均为0x0806表示该包数据包为ARP包，请协议栈按照ARP的格式进行解析和应答。

在以太网帧头中有一个目标MAC地址，在ARP数据报中也有一个目标MAC地址，这两个地址是不一样的，注意区分！在ARP请求时，以太网帧的目标MAC会填充为FF:FF:FF:FF:FF:FF，即广播地址。而ARP数据报中的目标MAC以0做占位；ARP回复时ARP应答数据报中的源MAC会被替换为所查询IP设备的物理MAC。这里先提前了解下，后续在讲述ARP流程时会详细阐述。

ARP工作流程

这里先引入一个情景：我们处于 192.168.43.0 网段，设备本机IP为 192.168.43.114，MAC地址为 aa:bb:cc:dd:ee:ff。在该网段中也存在一台设备G，其IP地址为 192.168.43.127，MAC地址为 00:11:22:33:44:55。

当我们要向设备G发送一段UDP数据报时，其流程如下：

  • 待发数据在传输层打上UDP头部，派发到网络层。
  • UDP报文进入IP层后，IP在对其进行封装IP数据包时发现对端MAC地址未知，暂时挂起发送请求，并请求一次ARP响应。此时，ARP流程正式开始。

协议栈构建一帧ARP报文，将自己的MAC和IP填入到“源MAC”与“源IP”中，并将目标IP填入。对于目标MAC，用0占位。随后将以太网帧头部的MAC硬编码为 FF:FF:FF:FF:FF:FF 广播地址，通过网卡发送出去。具体如下图：

为什么ARP请求要发广播地址？

我们发起ARP请求目的是查询指定IP的MAC地址，因此必须发广播保证该网段下所有设备都能够收到，否则就失去了查询的意义。这里需要注意的是，这个广播只是本地网段广播，不会也不应该被网关转发。

  • 该网段中所有设备都收到该ARP请求帧，并判断自身是否是被请求IP。如果不是，则记录下发送方的IP和MAC后丢弃该包（这里涉及ARP学习，于下文展开）；如果自身就是被请求IP，则记录发送方后构建ARP应答包回复。

如上图所示，设备A、B收到ARP请求后，发现请求IP并非自己，于是记录发送方后丢弃；设备G收到ARP请求后，发现请求的IP正是自己，于是将请求方的MAC和IP记录下来，同时自身构建一帧ARP应答报文（操作码为2），并正确填入双方信息后单播回我们本机。

  • 本机接收到ARP应答包，交给协议栈ARP处理分支进行处理，将目标设备的MAC从数据报中提取出来放入ARP缓存表。
  • 现在我们本机已经有了目标IP设备的物理MAC地址，解挂之前的UDP数据报，正式封装发送。

以上就是一个常规的ARP查询流程。

ARP缓存表

当然，如果每发一次数据都要ARP广播找一次设备，那效率就太低了。为了解决这个问题，我们可以很自然的想到将对方的MAC永久记录下来，这样下次直接查表就可以了。但是这又引入了另一个问题：如果表项固定，那么意味着我们每和一台设备通信，就会在内存中记录下该设备。在真正的网络环境中，拓扑往往是比较复杂的，这就意味着我们设备需要花费大量内存空间来存储每一个通信设备的MAC表项。而且设备在网络环境中MAC是可以被修改的，假如同一台设备MAC变了，那按照原表去查到的是旧MAC，那么发送出去的数据包直接就丢在网络环境中了。种种这些都是要解决的问题。

针对这种情况，协议提供了ARP缓存表这一结构。接下来我将以LwIP的实现为例进行阐述。

表项结构

ARP缓存表结构本质上是一个C结构体，以下是LwIP中ARP缓存表结构：

1
2
3
4
5
6
7
8
9
10
struct etharp_entry {
#if ARP_QUEUEING
    struct etharp_q_entry *q;   /* 挂起的待发数据包队列 */
#endif
    ip4_addr_t ipaddr;          /* 目标 IP 地址 */
    struct netif *netif;        /* 从哪个网卡可以到达目标 */
    struct eth_addr ethaddr;    /* 目标 MAC 地址 */
    u16_t ctime;                /* 存活时间，用于老化 */
    u8_t  state;                /* 表项状态 */
};

通常，ARP缓存表一个表项的结构应当包含如下字段：

  • IP地址(ipaddr)：该条表项对应的是哪个IP的MAC映射？
  • MAC地址(ethaddr)：表项的核心，表示该IP设备对应的MAC地址。
  • 类型：ARP缓存表分为静态类型和动态类型，该字段用于指明该条表项的来源（手动静态配置的/学习到的）。
  • 表项老化时间(ctime)：表项清扫时间。这里要明白，内存就那么多（尤其是在嵌入式系统中），我们不可能让大量表项常驻在内存中，必须定时对旧的不活跃的连接进行清扫，释放内存。而清扫动作的根据就是表项老化时间。
  • 网络接口(netif)：记录该表项对应的对端设备通过哪个网卡可以到达。

这里你会发现LwIP的实现中并没有类型(type)字段，却多了一个state字段。其实LwIP内部是维护了一个状态机的，而“类型”作为其中一个状态被融合进了里面。关于LwIP的ARP状态机，本篇文章不展开说明。

动态表项与表项老化

缓存表分为了动态表项和静态表项，动态表项一个最大的特征就是具备表项老化的机制。

缓存表老化本质上就是：给每条ARP表项设定了一个生命周期，该周期通过每次通信进行重置。当该生命周期超时后将会被降级重新验证或删除以释放空间。

缓存表老化是维护系统稳健性的一个关键举措：在网络环境中MAC和IP是可能发生变化的（比如更换网卡/IP给另一台设备），而且每个设备自身的内存空间都是有限的。如果表项一直不老化，那么表项越积越多，新旧混杂，占用空间越来越大，将导致内存枯竭或网络帧错误路由。

缓存表老化流程：

  • 当我们通过ARP广播与一台设备建联时，此时ARP缓存表中该表项被正式建立并可用。此时协议栈内部会启动一个定时器记录从此刻开始的老化时间。
  • 在这个老化时间计数期间，若双方再次发生通信，则老化时间被重置（这是符合预期的，表示对端活跃在线，自然要重置老化时间），重新进行计数；若在此期间未发生通信，则定时器继续计数。
  • 若老化定时器超时，则该条表项将从就绪状态（STABLE）被撤下，转为待验证状态（状态改为STABLE_REREQUESTING）。此时，LwIP协议栈会立即广播一个ARP请求等待对方应答。若重复几次对方都无应答，则立即删除该表项并释放内存。

这里要说明一点：上述流程我们是采用LwIP的视角来叙述其行为的，然而在Linux这些现代系统中，其行为略有差异。在Linux中，老化定时器超时后表项状态将由 REACHABLE 变为 STALE，此时Linux并不会像LwIP一样广播ARP，而是继续维护STALE状态，并维护一个stale超时时间，当stale再次超时时该表项将会被删除。在STALE期间，若仍有数据需要发送，内核不会挂起数据等待验证结果，而是先把数据照常发出，同时启动一个短暂的验证窗口（详见下文）。

更重要的一点是：Linux 在验证机制上比 LwIP 更机智——STALE 表项并不会被周期性地主动保活，只有当它再次被使用（也就是恰好有数据要发往这个目标设备）时，内核才会启动验证流程，而且验证的第一步甚至不需要发 ARP：

  1. 状态先由 STALE 转为 DELAY，数据包照常发出；内核在默认 5 秒的窗口内等待”上层反馈”；
  2. 若窗口内上层协议给出了可达性确认（典型如 TCP 收到了对方的 ACK），内核直接认定该表项仍然 REACHABLE——一个 ARP 包都不需要发；
  3. 若窗口内没有任何确认，状态转为 PROBE，此时内核才主动发出单播ARP请求去探测对端，收到正确应答后恢复为 REACHABLE；连续探测失败则标记为不可达并最终回收。

这里还有一个容易忽略的细节：UDP流量触发验证时，必然走到第 3 步。因为 UDP 天生没有确认机制，5 秒窗口内不可能等到”上层反馈”，所以内核只能老老实实发 ARP 探测。

而 STALE 条目本身的回收是在 GC 周期中完成的：一段时间内没有被使用过的条目会被直接删除；若近期被使用过，则只会刷新其时间戳，使其继续存活。下面这条抓包记录就是一次 PROBE 探测的过程：

1
2
3
17:18:09.143971 00:15:5d:e6:af:b7 > 00:15:5d:e6:fc:69, ethertype ARP (0x0806), length 42: Request who-has 172.18.224.1 tell 172.18.228.235, length 28
    
17:18:09.144126 00:15:5d:e6:fc:69 > 00:15:5d:e6:af:b7, ethertype ARP (0x0806), length 42: Reply 172.18.224.1 is-at 00:15:5d:e6:fc:69, length 28

可以看到，该记录正是一次 PROBE 探测：内核为验证该表项是否仍然有效，主动向 172.18.224.1 发出了一个单播 ARP 请求，对方也正确回复了 ARP 应答，此后该条目恢复为 REACHABLE。相比 LwIP 过期广播重问的做法，Linux 这种策略更节省局域网带宽。

下面再来看一次完整的实测。实验里我们清空ARP表后先 ping 一次网关把表项建立起来，随后不再做任何操作，静置等待表项自然老化。期间系统后台进行了一次NTP校时（一次典型的UDP流量），恰好触发了上面这套验证流程：

1
2
3
4
5
6
7
8
9
10
11
12
13
// 抓包视角（时间戳为与上一行的间隔）
+18.236899  172.18.228.235.35583 > 185.125.190.122.123: NTPv4, Client, length 188
            // NTP 请求发出（此时表项为 STALE，转发时随即转入 DELAY）
+0.189621   185.125.190.122.123 > 172.18.228.235.35583: NTPv4, Server, length 188
            // NTP 应答到达（UDP 无确认机制，DELAY 窗口不会因此提前结束）
+4.823691   00:15:5d:e6:fc:69 > 00:15:5d:e6:af:b7, ethertype ARP: Request who-has 172.18.228.235
            // 网关也向我们发了一个 ARP 请求（网关侧行为，与本机验证流程无关）
+0.000015   00:15:5d:e6:af:b7 > 00:15:5d:e6:fc:69, ethertype ARP: Reply
            // 我们回复网关
+0.117068   00:15:5d:e6:af:b7 > 00:15:5d:e6:fc:69, ethertype ARP: Request who-has 172.18.224.1
            // DELAY 窗口超时转入 PROBE，向网关发出单播 ARP 请求
+0.000158   00:15:5d:e6:fc:69 > 00:15:5d:e6:af:b7, ethertype ARP: Reply
            // 网关回复，探测完成
1
2
3
4
// 状态视角（ip neigh show 逐秒采样）
19:35:44  172.18.224.1 dev eth0 lladdr 00:15:5d:e6:fc:69 STALE
19:35:47  172.18.224.1 dev eth0 lladdr 00:15:5d:e6:fc:69 DELAY       // NTP 请求触发验证
19:35:52  172.18.224.1 dev eth0 lladdr 00:15:5d:e6:fc:69 REACHABLE   // 探测成功，恢复就绪

可以看到，从NTP请求发出到单播ARP出现，前后恰好间隔约 5 秒，状态机完整走了一圈 STALE → DELAY → PROBE → REACHABLE。这里还有一个特别容易误判的点：由于 5 秒后 PROBE 一发即中，PROBE 状态只存在极短的一瞬间，逐秒采样时甚至完全看不到它。如果只看结果，很容易产生”内核在 STALE 很久之后突然自己发 ARP 保活”的错觉——实际上触发它的，往往只是后台一个不起眼的周期性UDP流量（如NTP、SSDP等），并不是内核在主动保活。

当ARP缓存表已满，但是又需要插入新表项时，会优先淘汰需要验证（也就是已经超时待验证的）表项。若所有表项均处于就绪状态时，则按LRU规则，以ctime老化时间为根据淘汰最旧的动态表项。

静态表项

动态表项的设计固然好，但是仍有部分尴尬的问题用动态表项处理起来并不方便：

  • 某些情况下我们的服务器、固定的上位机等这些设备的IP-MAC映射是不会轻易改变的，如果网段中设备每次与他们通信都从走一遍 “发现/验证” 流程的话，将会占用网络带宽，降低通信效率。
  • 有的设备可能处于安全考虑并不响应ARP（防火墙），或者设备裁切了一个十分精简的TCP/IP协议栈，甚至没有ARP处理逻辑。此时根本无法使用动态表逻辑建立有效的连接表项。

在这种情况下，我们就需要引入静态表项来解决问题。静态表项没有老化机制，由用户手段配置之后其内存永久生效。

LwIP中，关于静态表项的实现是采用了一个 ETHARP_STATE_STATIC 状态融入进表项的state字段来实现的。在协议栈内核表项老化处理逻辑中，会优先判断该条目状态是否为 ETHARP_STATE_STATIC ，如果是则直接跳过该条表项的老化检查逻辑（静态表项不允许老化）。其实现类似于下列伪代码：

1
2
3
4
5
6
7
8
9
10
11
void lwip_arp_timeoutLogic( void )
{
    ....
    for( 遍历所有表项 )
    {
      if ( arp_table[x].state == ETHARP_STATE_STATIC )
        continue;// 静态表项. 直接跳过老化逻辑.
        
      ....后续老化判断逻辑.
    }
}

LwIP内部也提供了对应的API接口来添加/删除一条静态ARP条目，由于本篇文章并不深究LwIP内部，因此此处不展开叙述。

这里要说明一下的是：静态表项不仅不会老化，还不会被淘汰。

当ARP缓存表满却又需要插入新表项时，ARP协议内核并不会动静态表项，而是按上述的淘汰规则来踢出动态表项。当整个ARP表都是静态表项时，新条目将分配失败，返回错误。

这里给一下静态表项与动态表项的区别：

维度动态表项静态表项
来源ARP 自动学习手动配置
状态STABLE / REREQUESTING (LwIP)STATIC (LwIP)
老化参与老化，超时降级重请求永不老化
淘汰表满时可能被 LRU 淘汰永不被淘汰
回收会被清理不会被清理
适用场景普通设备通信网关、固定上位机、不响应 ARP 的设备

这里还是要再次强调，静态表项不具备自动感知能力，在更换设备后不会自动更新。如果对端更换了IP-MAC映射，需要手动重新配置或者设计时直接使用动态表项去处理。应只给一些例如网关之类的必要设备配置静态表项，其余设备交给动态表项处理，不能都配置成静态表项。

ARP学习

在上文中我们多次提到过ARP学习，前面我们讲ARP工作流程时，本机广播请求，设备G回复应答，本机把设备G的映射存入缓存表——这个过程就叫作ARP学习。当然，ARP学习并不只局限于两个指定IP设备之间，实际上任何ARP报文到达时，设备都可以触发学习行为（具体是否学习，取决于协议栈的实现策略）。

还是回到上文工作流程中的例子：我们设备向本网段广播了一个ARP请求，设备A、B收到该ARP请求包后，发现目标并不是自己，但是ARP报文本身就携带了本机的IP-MAC映射，为什么不顺手存下来？这样的话假如A、B需要和本机之间通信就不用再ARP了。因此设备A、B都会将本机的IP-MAC映射作为新条目加入到各自的ARP缓存表中。

ARP自主学习行为的好处是很明显的：能够减少整个网段的ARP次数，提高网络通信效率。

不过ARP自主学习是有安全风险的，这也是为什么该功能作为可选功能而不是强制实施再每个设备上。

若设备无条件信任每一个ARP的IP-MAC映射，那么攻击者只需要伪造一份ARP报文，就能随意改写网段中其他设备的缓存表——这就是ARP欺骗。ARP协议本身没有任何认证机制，这个机制带来的副作用在协议层面是无解的。

ARP欺骗

ARP攻击方法很简单，一台普通主机就能发出来，主要有两种：

  • 伪造应答：将自己伪造为网关，直接广播一帧”网关IP的MAC是我”的ARP应答。收到应答的设备会更新已有表项，于是全段设备的网关映射当场被改写，这是最经典的手法。
  • 伪造请求：ARP请求报文同样携带发送方IP-MAC映射，攻击者只要构造一个源信息虚假的请求，收到请求的设备也会顺手把伪造映射记进缓存表。这条路径有时更隐蔽，因为它看起来只是一次普通的询问。

以冒充网关为例，看看一次广播的打击面到底有多大：所有已存在网关表项的设备，表项会被立即改写。这些设备发往网关的流量（也就是全部出网流量）都会先发给攻击者——从这个意义上讲，一次广播就完成了对全段设备出向流量的劫持。若攻击者再开启IP转发，重新将这些流量发回真正的网关，那么就会营造一种网络仍在正常运行的假象，实际上整个网段的流量已经被中间人劫持了。

不过即便如此，现代网络中大量流量都有HTTPS等加密保护，攻击者拿到的也只是密文，所以现实中纯粹的ARP攻击更多被用于断网DoS，或是把流量牵引到钓鱼页面。

防护思路

因此ARP自主学习这一机制在ARP协议中作为可选项给出，LwIP中也提供了编译选项ETHARP_TRUST_IP_MAC用于控制ARP的行为。当然，也有以下的一些方式来进行防护：

  • 使用静态表项：正如上文所说，给网关等关键设备配置静态表项，从根本上拒绝动态改写。
  • 交换机的安全机制：DHCP Snooping + 动态ARP检测（DAI），由交换机校验ARP报文的合法性、丢弃伪造报文；
  • 监控工具：arpwatch 之类的工具持续监听网段内的ARP活动，IP-MAC对应关系变化时及时告警；

可以看到，ARP的无条件学习问题在协议层面无解，所有防护手段的本质都是在协议之外给它补上信任：要么靠人工配置（静态表项），要么靠网络设备的行为约束（交换机安全机制）。

结语

写这篇文章时花了不少时间查阅网络资料，同时根据自己对ARP的理解尽可能的将其叙述清楚。文中涉及到的示例在我的本地环境中已经验证过了一遍，如果您在阅读时发现文章中出现理论错误，还望能够通过邮箱与我联系，帮助我及时修正，不胜感激。

]]> https://r6blog.online/2026/09/19/%E5%B5%8C%E5%85%A5%E5%BC%8F2026091902/ 2026-09-19T04:54:59.000Z 前言

ARP全称为 Address Resolution Protocol 即地址解析协议。我们已经知道，IP网]]>

ARP 地址解析协议 2026-10-08T07:15:10.247Z R6bandito 最近在Windows11上捣鼓WSL2，跑了一个ubuntu的26.04系统。在Windows上启动WSL服务后，发现我blog在本地跑不起来了，即构建后出现以下错误：

1
2
3
4
5
INFO  === Checking package dependencies ===
INFO  === Checking theme configurations ===
INFO  === Registering Hexo extensions ===
FATAL Permission denied. You can't use port 4000.
FATAL Something's wrong. Maybe you can find the solution here: https://hexo.io/docs/troubleshooting.html

根据FATAL日志可知我们的 localhost:4000 貌似在引入WSL之后被占用了。

进一步了解发现：我们的Windows作为宿主机，在启用Hyper-V服务后，系统的部分端口会被Hyper-V占用。终端使用以下命令查看被保留的端口：

1
netsh int ipv4 show excludedportrange protocol=tcp

输出

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
协议 tcp 端口排除范围

开始端口    结束端口
----------    --------
        80          80
      3421        3520
      3583        3682
      3683        3782
      3783        3882
      3883        3982
      3983        4082
      4083        4182
      4183        4282
      4283        4382
      4383        4482
      4483        4582
      4583        4682
      4683        4782
      5357        5357
     50000       50059     *

* - 管理的端口排除。

可以发现我们的4000端口处于 3983~4082 之间被保留了。这也是为什么我们的程序跑不起来的原因。

这里要说明一点：保留区是动态划分的，也就是说每次重启都会随机划分，所以我们程序端口越高，越不容易和保留区撞车。

解决方法：

  • 将我们程序端口开在保留区之外的区域，例如4800以上（4783 以上大片空闲，不容易撞上保留区）。
  • 修改动态端口范围
1
2
netsh int ipv4 set dynamicport tcp start=55000 num=10536
netsh int ipv6 set dynamicport tcp start=55000 num=10536

以上两行命令可以将动态端口保留区强制限制在 55000 ~ 65536 这个区间，这样就不容易和我们的程序冲突。

  • 对于我们一些常用端口，可以强制进行保留。
1
netsh int ipv4 add excludedportrange protocol=tcp startport=4000 numberofports=1

以上命令执行后，port4000将不会被划入保留端口。

不止是blog，端口随机保留会导致例如代理等服务不可访问，出现一些“有时可用，有时又不可用”的灵异问题。后续若再出现此类类似问题，应先从这方面考虑。

]]> https://r6blog.online/2026/09/19/%E5%B5%8C%E5%85%A5%E5%BC%8F2026091901/ 2026-09-19T00:35:06.000Z 最近在Windows11上捣鼓WSL2，跑了一个ubuntu的26.04系统。在Windows上启动WSL服务后，发现我blog在本地跑不起来了，即构建后出现以下错误：

Hyper-V 端口占用问题 2026-10-08T07:15:10.247Z R6bandito 什么是环形缓冲区?

嵌入式C中，环形缓冲区是一个基于数组的简单可靠的环回线性数据存取结构。核心是通过一个写指针(我习惯叫head)，一个读指针(tail)管理数据的写入和读取，并用循环取模或位与等操作实现回绕的特性。环形缓冲区解决了传统线性缓冲区频繁分配与释放导致的内存碎片、效率低下等问题。

接下来给一个简单流程示意图例：

  • 初始时，读写指针均位于缓冲区起始，此时缓冲区为空状态，如图
  • 数据由Head写入，写入后Head索引移动到下一待写入位置。
  • 缓冲区中数据由Tail读出，读出后Tail索引移动到下一待读取位置。
  • Head写满后回绕到缓冲区起始，Tail同理。

以上便是环形缓冲区正常工况下数据存取的一个简单模型。内部一些具体细节将在下文展开，上述流程只是为了简单了解下环形缓冲区的工作原理。从上述可看出：

  1. 环形缓冲区本质是一个FIFO队列，先进先出。
  2. 读写数据时间复杂度均为O(1)，无需移动任何数据。
  3. 读写索引到缓冲区边界后自动发生回绕。

环形缓冲区是嵌入式系统中十分重要且常用的一个数据结构，在串口收发场景；DMA数据缓冲场景；传感器数据缓存场景等均有很广泛的运用。

环形缓冲区的数据结构

要设计一个环形缓冲区，有3个要素是必须的：

  • 缓冲区数组：这就是我们的缓冲区物理空间，后续我们所有的操作均基于该缓冲区上进行。
  • 读/写索引：环形缓冲区灵魂所在，利用两个索引的平移和回绕在线性数组上天然实现环形特性。注意我们这里一直说的是“索引”，所以本质其实应该是一个u16/u32变量，不要定义为指针类型复杂化问题！

这里提前说明一下：还有一个要素是 有效数据长度 ，但是该要素是否必须取决于你的缓冲区实现策略，这里我使用的是牺牲槽判空法的策略，因此不需要该元素。

通过上面的叙述，我们可以定义出一个结构如下：

1
2
3
4
5
6
#define RING_BUF_SIZE(64u)
typedef struct {
    uint8_t buffer[RING_BUF_SIZE];/* 缓冲区 */
    uint16_t head;/* 写索引 */
    uint16_t tail;/* 读索引 */
} rBuf_t;

每向缓冲区写一次数据，head索引步进一格；每从缓冲区读一次数据，tail索引步进一格。这个流程是明确且易懂的，但是这其中涉及到几个问题需要考虑清楚：怎么判断缓冲区是空状态？怎么判断缓冲区是满状态？回绕具体是怎么个回绕法？接下来我们就来详细讲讲。

环形缓冲区判空判满策略

关于状态判断，你可能会这么想：“既然是环形缓冲区，那么当head追上tail时不就满了吗？那么等量关系很简单直接就是 head == tail 。” 这么想其实没错，但是忽略了一个前提：我们在初始化状态(也就是初始空状态)时已经满足等量关系 head == tail 。若 head == tail 也用来判满，那么会出现一个等量关系对应两种不同的状态，这肯定是不能成立的。

因此我们需要一个办法来区分空和满状态，这里有三种常见方法。这里详细讲讲我使用最多的方法：

  • 牺牲一个空槽位进行判满。

顾名思义，该方法的核心思想是：永久牺牲掉一个槽位用于判满操作，例如我们缓冲区大小为64个槽，那么在该方法下，我们最多可用的空间只有63个槽位。

原理是这样的，既然 head == tail 无法使用，那么我们使用 head + 1 == tail 不就可以了吗？在写入槽位之前提前判断下一个槽位是不是读索引，如果是那么说明除开当前这个空槽之外，缓冲区已经满了。此时我们牺牲掉这个空位置，并抛出缓冲区满事件供上层处理。

上图示例中，缓冲区总大小 Size == 8。但是在该方法下可用的大小永远只有7个槽。

Ps：这里要强调下，判满条件不能直接写 head + 1 == tail ，我们要将回绕考虑进去，因此正确的逻辑应该是 (head + 1) % Size == tail。上述的写法是我未将回绕考虑进去的简写，注意区分。

牺牲一个空槽位的方法在嵌入式实践中比较常见，因为其不需要维护额外的变量，简单可靠。其代价仅仅只是浪费一格存储单元，这个代价我们基本可以忽略不计。

  • 维护一个计数变量进行判满。

如前文所述，我们在缓冲区结构中可以多维护一个有效数据长度的要素。如下

1
2
3
4
5
6
7
#define RING_BUF_SIZE(64u)
typedef struct {
    uint8_t buffer[RING_BUF_SIZE];/* 缓冲区 */
    uint16_t head;/* 写索引 */
    uint16_t tail;/* 读索引 */
    uint16_t count;/* 缓冲区中有效数据条目计数 */
} rBuf_t;

每当往缓冲区写入一个数据时，count++；从缓冲区读出一个数据时，count--。可用 RING_BUF_SIZE == count ? 来判断缓冲区是否已满。 用 count == 0 来判断缓冲区是否已空。

这个方法就是多维护一个变量，多一次非原子的读写操作（生产者和消费者均需要访问该变量），但是只要保证在临界区操作或串行化访问的话，其实并不会出任何问题。这种方式其实并没有什么太大的弊端，也比较直观，所以可以采用该方法实现，不过我个人还是习惯上一种方式。

  • 镜像指示，标志翻转判满。

这个和第二个有些类似，需要在缓冲区结构中维护一个标志位flag。

1
2
3
4
5
6
7
#define RING_BUF_SIZE(64u)
typedef struct {
    uint8_t buffer[RING_BUF_SIZE];/* 缓冲区 */
    uint16_t head;/* 写索引 */
    uint16_t tail;/* 读索引 */
    uint16_t flag;/* 标志位(应初始化为0) */
} rBuf_t;

当初始为空状态时，我们用 (head == tail) && (flag == 0) 可判断当前缓冲区为空；当我们往缓冲区写入数据时，该次写入完毕后若 head == tail 则表示写索引追上了读索引，此时我们应将 flag = 1 表示缓冲区已满并向上层抛出一个事件；同样的，当本次读取完毕后若 head == tail 则表示读索引追上了写索引，应将 flag = 0 表示缓冲区为空。

镜像指示位法的优势在于单生产者单消费者场景下天然无锁安全：flag 只在“写追上读”时被写方置 1，只在“读追上写”时被读方置 0，不存在竞态。缺点是无法直接知道当前有多少数据。

这个方式了解一下即可，我个人并不建议使用这种方式，因为该方式类似于是上一个的下位替代，唯一的线程安全优势其实并不是那么绝对——在可能存在竞争的场景下我们均会采取临界区等手段来规避风险，所以在该种场景下采用count其实也是安全的，还能够精确进行计数。

环形缓冲区绕回特性

缓冲区在物理上是线性的，因此要实现环形缓冲，自动回绕就必须在软件逻辑上下功夫。我们通常使用对索引取余的方式来完成回绕，其计算公式如下：

1
2
3
关于写索引： (head + 1) % Size
关于读索引： (tail + 1) % Size
其中，Size为缓冲区大小.

举个例子：我们有一个32槽位的缓冲区，已经装了29个数据，其布局如下所示。目前head的值为31(注意不是30，因为写索引指向的是下一个待写的槽位)。

当再次发生写入操作时，该包数据被放入head指向的最后一个槽位(Buf[31])，随后执行 (head + 1) % Size更新索引。head + 1 = 32；32 % 32 = 0 看见了吗，索引自动的正确回绕到了Buf[0]。后续的写入操作又继续重复上述的缓冲区写入流程。tail读取索引也是同样的回绕方式。

这种取余的方式进行回环是通用且常见的方式，接下来介绍另一种效率更高的方式。

  • 通过按位与(&)操作进行逻辑绕回。

这里要说明一下：该方法并不通用，只有在缓冲区大小Size为2的幂等数情况下才可以使用。这是因为只有当Size是2的幂时，size - 1的二进制才是全1，按位与才能等价于取模。

其索引更新的计算公式为

1
(head + 1) & (Size - 1);

举个例子：

1
2
3
4
5
6
Size = 8  --> 0b1000
head = 7
(head + 1) = 0b1000;
(Size - 1) = 0b0111;
(head + 1) & (Size - 1) = 0b1000 & 0b0111;
很明显，最后按位与出来的结果是0. 索引正确回绕

这种方式最明显的优势就是速度极快，比通用的取余方式能快出不少，所以在设计缓冲区时其缓冲区大小尽量设置为2的幂等数，这样就能使用该方式进一步提升程序效率。

环形缓冲区本质上它就是一段线性数组加上两个索引，靠取模或位与实现逻辑上的首尾相连；判空判满的重点在于“如何区分空和满”，牺牲槽位法、计数变量法、镜像指示位法各有取舍，选哪个取决于你的场景。回绕是这套机制的灵魂——物理上是线性的，逻辑上却是环形的。

]]> https://r6blog.online/2026/09/17/%E5%B5%8C%E5%85%A5%E5%BC%8F2026091701/ 2026-09-17T06:35:09.000Z 什么是环形缓冲区?

嵌入式C中，环形缓冲区是一个基于数组的简单可靠的环回线性数据存取结构

环形缓冲区(Ring Buffer) 2026-10-08T07:15:10.247Z R6bandito 前言

入门网络通信的第一步，自然是IP地址体系。IP这个概念在网络通信中十分重要，是通信能否建立的必须前提。在现实世界里，我们要寄一封信，必须在信封上写清楚地址——哪个省、哪个市、哪条街、几号门。网络通信中也是一样的，每个设备都有自己的一个“门牌号”，数据包从你家送到他家，靠的就是这个地址。

要准确的送达数据包，在网络环境中每个设备就必须有一个唯一地址，这个地址就是IP地址。

IP地址分为 IPv4 与 IPv6，目前主流的依然是IPv4，本文所述的IP地址体系也是基于IPv4进行的。

IPv4地址由32位二进制组成，每个字节(8位)划分成一段，采用点分十进制书写便于阅读（例如：192.168.1.10）。一个IP地址内部包含两层信息：网络号与主机号。

网络号有点类似于小区中的楼栋，每一个网络号对应一个网络地址，也就是小区中的一个单元楼。楼里面有许多房间，每个房间就住着一个主机，也就是我们所说的主机号。同一单元楼的主机可以互相“串门”，但是不同单元楼的主机如果需要互相通信，则需要找门卫，也就是我们所说的网关代为传达。这里我们是以现实中小区进行一个比拟便于理解，实际行为也确实是这样的。

下面就以此为基础，详述IPv4的地址体系。

IPv4地址体系

IPv4地址的表示

地址的表述我们在前言其实已经讲过了，这里再说明一下。IPv4地址本质是一个 32位无符号整数：

1
11000000 10101000 00000001 00001010

为了便于表示，我们将其每字节隔开，采用点分十进制表述如下：

1
2
3
4
5
6
11000000 --> 0d192
10101000 --> 0d168
00000001 --> 0d1
00001010 --> 0d10
// 点分拼接后如下.
192.168.1.10

IPv4 地址总量有 2^32 = 4,294,967,296，约合 42.9亿。别看这么多，目前是已经枯竭了的，当前网络环境普遍采用了NAT技术来重映射IP地址，并划分公网与私网段。

关于该技术详见：NAT 地址转换。

IPv4相关核心概念

在详细了解IP地址之前，需要先厘清几个概念：

网络号与主机号：一个IP地址会被子网掩码划分为两个区域，分别为网络号和主机号。当IP地址中主机号全为0时，其代表的就是网络地址，标识的是整个网段的起始地址。主机号就是该网段中某一设备的编号。

子网掩码是目前划分网络地址与主机地址的“度量衡”。在当前网络环境中，普遍使用的是CIDR无类地址（详见下文）划分机制，其子网掩码可以按如下形式表示：

1
2
3
4
192.168.1.10/24
CIDR 划分： 前24位为网络位，后8位为主机位.
其子网掩码为 网络位全1，主机位全0. 即：
255.255.255.0

知道子网掩码后，我们就可以给出精确的网络地址与主机地址的划分机制：

使用IP地址与子网掩码进行与(&)运算，其运算结果就是网络地址。

例如：

1
2
3
4
192.168.43.1/24
子网掩码：255.255.255.0
192.168.43.1 & 255.255.255.0 = 192.168.43.0
192.168.43.0  即为网络地址.

主机号自然就是剩下的8位，总共就2^8 = 256个主机地址。值得注意的是：子网掩码还用来区分网段。如何确定两个设备是否处于同一网段？就用两个设备的IP地址分别去与（&）上子网掩码，若与出来的网络地址相同则说明两个设备处于同一网段。

广播地址是主机号全为1的地址，其作用是向本网段内所有设备广播数据。广播地址是一个特殊的地址，不能单独分给某一个设备。例如上述示例中：192.168.43.0这个网段的广播地址就在192.168.43.255。当该网段内某个设备向该地址发送一个数据包后，整个地址位于192.168.43.x(x!=0 && x!= 255)都能够收到该包数据。

可用主机范围是该网段中，所有能够划给使用使用的具体IP地址的一个范围。这其中需要剔除掉本网段广播地址与网络地址。例如在192.168.43.x网段中，需要剔除掉192.168.43.0(网络地址)和192.168.43.255(广播地址)。剩下的可分配地址范围为192.168.43.1~192.168.43.254，这就是可用的主机地址范围。

网关：网关是出网段的“大门”，不同网段之间需要通信必须经过网关转发。同时，网络拓扑有本地局域网与公网之分，本地局域网中的设备想要与公网服务器进行通信其流量必须经过本地网关出站，外部公网服务器回复的流量也必须经过本地网关入站才能路由到本地局域网的指定设备。

可以把网关理解为一栋“楼”的“楼长”，楼与楼之间的通信事务由网关进行管理，不能让楼中的“居民”直接插手楼间通信事务。

IP地址的分类
有类地址

早期，IP地址被划分为了五类地址，称作有类地址。如下表所示：

类别首位第一字节范围默认掩码用途
A01 ~ 126/8超大型网络
B10128 ~ 191/16中型网络
C110192 ~ 223/24小型网络
D1110224 ~ 239—组播
E1111240 ~ 255—保留/实验

比如我们家庭常见的192.168.1.2等等这类IP地址就属于C类地址，用于小型网络。一些网络例如10.124.12.10这类地址就属于A类大型网络。

但是目前这种分类已被废弃，原因是地址划分过于死板，不灵活。举个例子：假如南京某高校使用了A类地址，其网络地址为10.0.0.0，让我们算一下该网段拢共支持多少设备：

1
2
按掩码为 255.0.0.0 来算,其主机位有24位.
2^24 - 2 = 16,777,214.

看到了吗？一个网段能容纳1670万台设备，实际上远远用不到这么多。

这就说明旧式五类划分，要不就划分过大浪费；要不就划分过小不满足，例如C类地址一个网段才 2^8 - 2 = 254 台设备。

所以现代网络已抛弃有类划分，改用 CIDR。

CIDR (无类地址)

现代地址体系中，已不再按类进行IP地址的划分，取而代之的是CIDR无类地址机制。

无类地址：即用/n表示一个IP地址中的网络号的位数。也就是说我们可以将任何一个网络切分成一个子网络，按需进行切割。这个机制十分灵活，规避掉了按类型进行划分的弊端。

例如：

1
192.168.1.10/24

/24表示该IP地址中，前24位是网络号，后8位是主机号，所以可以计算出该网段中可用主机地址共有2^8 - 2 = 254个，对应原来的C类地址。

再来看一个示例：

1
2
10.20.30.40/12
--> 子网掩码：255.240.0.0

该IP中，第一个字节8位与第二个字节的高4位为网络号(\12)，剩下的20位为该网段中所有的主机号。

  • 网络地址：10.20.30.40 & 255.240.0.0 = 10.16.0.0。所以该网段起始地址为：10.16.0.0。
  • 广播地址：主机号全1，即：10.31.255.255（注：31是这么来的：0001 1111. 高四位是网络号，低四位主机号全1）。
  • 可用主机地址范围：10.16.0.1 ~ 10.31.255.254（去掉网络地址与广播地址）。
  • 可用主机数目：2^(32 - 12) - 2 = 2^20 - 2 = 1,048,574 。
路由表爆炸与超网合并

当然, CIDR除了让地址划分更灵活之外，还解决了有类时代另一个致命问题——路由表爆炸，这是导致有类划分被彻底废弃的根因。路由器在转发数据包时，内部会维护一个路由表——这个表类似于“指路标”一样，指明该包数据下一跳该路由到哪个位置。

在有类地址时代中，每一类网段都要单独写一条路由。而当时C类网络是全球被使用最多的网络类型，1990s拢共有接近几十万个C类网段。这就意味着核心路由器面临路由表膨胀的问题——路由表的体积极具增大，内存不够、查表变慢、CPU 负载爆炸。如果不解决，互联网会在几年内瘫痪。

CIDR正是用于解决这个问题的。其解法是超网合并：若多个连续网段下一跳相同，就把它们合并为一个大网段一并路由。来看个例子：

某公司有16个网段，这16个网段都接在同一台边界路由器后面。对于外部核心路由器而言，去往这16个网段的下一跳完全相同。其网络拓扑如下：

1
2
3
4
192.168.0.0/24
192.168.1.0/24
...
192.168.15.0/24

在旧式有类地址分类下来看，每个网段都要维护一条路由表，那么核心路由器为该公司就需要维护16个路由表条目。

但是在CIDR的视角下，我们会发现这些网络地址的前20位都是相同的，变化主要集中在20~23位。

1
2
3
4
5
1100 0000(192)1010 1000(168)0000 0000(0) 0000 0000(0) --> 192.168.0.0
1100 0000(192)1010 1000(168)0000 0001(1) 0000 0000(0) --> 192.168.1.0
1100 0000(192)1010 1000(168)0000 0010(2) 0000 0000(0) --> 192.168.2.0
....
1100 0000(192)1010 1000(168)0000 1111(15) 0000 0000(0) --> 192.168.15.0

这时我们可以用/20来将这16条路由合并为1条。即：192.168.0.0/20。现在我们来验算下看看对不对：

1
2
3
4
子网掩码：255.255.240.0
网络地址：192.168.0.0
广播地址：192.168.15.255
可用地址范围：192.168.0.1 ~ 192.168.15.254

看到没有？合并前后地址范围逻辑完全是正确的。但是以前我们需要维护16个表项，现在只需1个表项就OK。整整缩小了16倍！这个效率是很高的。同时还有个隐藏福利：

合并之前，16个网段，每个网段2^8 - 2 = 254个可用地址。总的下来有254 * 16 = 4064个IP地址可用。

而CIDR合并之后，2^12 - 2 = 4094个可用地址。为什么会这样？因为合并之前每个网段都有个网络地址与广播地址被占用，拢共有16 * 2 = 32个地址被占用。而合并之后只被占用了2个，那么自然多了30个空余位置出来。

超网合并的优势是很明显的：

  • 使得路由表地址缩小：多条路由压缩成一条，减轻核心路由器负担。
  • 地址利用率提高：原来每个 /24 浪费 2 个地址，合并后只浪费整个大网段的2个。
  • 互联网可扩展：全球路由表从几十万条降到几万条，互联网得以持续扩张。

Ps：CIDR超网合并的一个前提是地址连续，这是必要条件！还是上述公司的例子：如果地址不连续有空洞，即192.168.4.0该网段不属于该公司，那么在合并时不能直接合并为192.168.0.0/20，这么强行合并会把不属于自己的地址也圈进来，导致路由错误。这里尤其要注意。

IPv4私有地址

全球有三段公认的私有地址（也可以理解为局域网地址），这些地址在任何局域网段内部都是可以复用的。

类别地址范围CIDR
A10.0.0.0 ~ 10.255.255.25510.0.0.0/8
B172.16.0.0 ~ 172.31.255.255172.16.0.0/12
C192.168.0.0 ~ 192.168.255.255192.168.0.0/16
  • 10.0.0.0/8一般用于大型网络（例如校园网等等）需要组建很多子网的场景。
  • 172.16.0.0/12设备数量介于家庭和企业之间，比如一些公司的分支机构。
  • 192.168.0.0/16基本是家庭路由器的默认配置，地址空间小，够用，且不容易和外部网络冲突。

关于使用规定，并没有强制。只要满足：使用三段地址之一；内网地址不冲突；流量出站时经过NAT网关 就行。

在家用网络里面你也完全可以给本地设备划分一个10.0.0.0/8，只是完全没有这个必要。

IPv4特殊地址

除了私有地址，IPv4还有一批有特殊用途、不能随便分配的地址。

  • 0.0.0.0

这是本机任意地址的通配(IP_ADDR_ANY)，根据不同的场景有不同的用法。

你比如DHCP请求时，此时本机还没有IP地址，因此使用0.0.0.0进行填充，等待IP分配；同时，当本机作为服务器进行客户端监听时，使用0.0.0.0:80表示监听本机80端口的所有连接。

  • 127.0.0.0/8

本机本地环回地址。整个 127.0.0.0/8 都是回环地址，最常用的是 127.0.0.1（localhost）。

在这个地址下，数据包是发不出网卡的，会在内核內部兜一圈后重新发回给自己。只要协议栈正常，Ping127.0.0.1是一定能够通的。

环回地址只是在测试场景下使用，当移植协议栈之后可以尝试环回给自己发包，如果能正常接收说明协议栈出口和入口都是正常的。正常工况下不应该有设备被分配为环回地址。

  • 255.255.255.255 / x.x.x.255(定向广播)

两个都是广播地址，用于向网段广播数据包的。

对于255.255.255.255：在DHCP发现服务与ARP广播中都有使用，其作用效果仅限本网段，不会被网关转发。也就是说向本网段内所有设备广播，但不能够跨越路由器。

x.x.x.255是定向广播，也是广播的一种，与255.255.255.255的核心区别在于：理论上网关可以转发该数据包，进而广播到别的网段。例如 我们处于网段:192.168.2.0/24，我们可以向另一个网段的广播地址192.168.1.255发包，该包数据经过网关后会进入192.168.1.0/24网段中并且广播给该网段中所有设备。

不过理论是理论，实际是实际。为了安全起见，现代路由器普遍禁止转发定向广播，因此在常规使用过程中，这两个广播地址的效果其实是等价的。

  • 169.254.x.x/16 (链路本地地址)

这个地址用于在DHCP分配失败后的临时组网。当我们设备没能通过DHCP获取到地址时，就会从169.254.x.x/16中选出一个可用地址来分配给自己。此时设备只能和同网段其他 169.254.x.x 设备通信，上不了网。

举个例子：我们家庭网络地址为192.168.43.0/24。而某台设备在向路由器请求DHCP服务时失败，自己给自己分到了169.254.28.6，此时该设备和网段中的其它设备(192.168.43.x)是无法通信的，因为不处于同一个逻辑网段。此时若另一台设备也请求DHCP服务失败，同样给自己分配了一个169.254.28.3。此时，这两台设备处于同一网段，可以相互通信。

链路本地地址没有网关也上不了网，设备应定期重试DHCP服务，如果你发现你的设备IP地址一直为169.254.x.x，那么多半就是DHCP出问题了。

  • 224.0.0.0/4 (组播地址)

用于一对多通信。例如视频直播：一个源向一组接收者发送，用组播地址。这里关于组播不展开。

]]> https://r6blog.online/2026/09/14/%E5%B5%8C%E5%85%A5%E5%BC%8F2026091402/ 2026-09-14T11:34:46.000Z 前言

入门网络通信的第一步，自然是IP地址体系。IP这个概念在网络通信中十分重要，是通信能否建立的必须前提。在现实世界里，我们要寄一封信，必须在信]]>

IP 地址体系(IPv4) 2026-10-08T07:15:10.247Z R6bandito 引言

在网络通信中，IP地址是不可或缺的一环，无论是什么通信方式，均离不开IP地址。目前主流的IP地址协议为IPv4，一个IPv4地址由32位二进制组成，在表示上采用点分十进制的拆分成四段进行表示。让我们来计算下拢共有多少个IPv4地址可供分配：2^32 - 1 ≈ 42.9亿，考虑到网络地址、广播地址、保留地址等开销，实际可供分配给主机的地址还要更少。

在当今互联网飞速发展的情况下，IPv4地址已经枯竭，IPv6虽然可以从根本上解决IP地址不足的问题，但是目前仍有多数网络设备是基于IPv4的，因此在这个过渡期间就必须得有一个对应的技术来暂时解决这个问题。

NAT(Network Address Translation) 网络地址转换技术正是于此背景之下诞生的。该技术使每个网段更加独立：也就是网段内部私有域中的设备不再能够直接与互联网通信，而是必须走网关通过NAT转换之后才能与外部互联网建立通信。

NAT 技术就是在私网地址与公网地址之间相互转换的，说准确点就是：NAT 技术通过在网关处修改 IP 包的源地址或目标地址，实现私网与公网之间的地址映射。

多个私网地址可以共用一个公网地址，这样即保证了网络通信，又节省了公网地址，这就是NAT的优点。

NAT 做到了什么?

这里需要先声明一点：NAT != 网关。NAT与网关是包含关系——NAT是网关的一个功能子集。网关除了NAT之外，还能集成 DHCP、DNS、防火墙等网络与安全服务，不能简单认为NAT就是网关。

  • NAT 让内网与公网之间无法直接互访。内部私有 IP 地址对外不可见，天然隐藏内网拓扑。外网在没有端口映射的情况下无法主动连接到内网设备。
  • NAT允许灵活组网。私网段用户可以随意使用，本地局域网段无需申请公网IP，就算发生冲突也只限于该网段内部。
  • 极大节省公网IP。通过NAPT技术，一个公网IP可以让数十台，甚至上百台设备同时上网。

目前只要是接入了互联网的网关设备，大部分都集成了NAT技术。

当然，NAT的引入也带来了一定的副作用：

破坏了端到端的通信，增大了网关的负载，也使得P2P通信更加困难。以部分联机游戏举个例子，有的游戏提供 P2P 联机模式，理想情况下，联机双方设备只需要知道对方的IP和端口就能够发起直连，这是双向对称的。

但是，当处于NAT环境下时，由于双方的NAT类型和严格程度不同，所以很可能会出现A发往给B的包，在NAT处被丢掉或反之同理。这就是NAT引入之后带来的不便。

这里附一个常用私有地址域范围表：

类地址范围CIDR
A10.0.0.0 - 10.255.255.25510.0.0.0/8
B172.16.0.0 - 172.31.255.255172.16.0.0/12
C192.168.0.0 - 192.168.255.255192.168.0.0/16

这三类地址是全球公认的私有地址，本地网段中想怎么使用都行。即使两个不同的公司内部都用了 192.168.1.0/24，只要他们不直接合并网络，就绝不会冲突。

并且这三类地址也是不可直接路由的，任何公网核心路由器只要看到目标是这三类地址其中之一，就会直接丢弃数据包。所以这些地址只能在局域网内“自娱自乐”，上网必须经过NAT转换。

NAT 的类型与工作原理

静态NAT

静态NAT的规则很简单：永久将一个内网私有地址映射到一个公网地址，每个映射在配置时都是写死在NAT表中的。

如下图所示：

我们有两个本地设备分别为 192.168.1.1/24 与 192.168.1.2/24 需要上网，在静态NAT的规则下，节点1发送出的数据包(S:192.168.1.1/D:112.1.1.1) 经过网关NAT映射后，永久绑定了一个公网IP：200.10.10.1。Server侧收到的是200.10.10.1发来的数据包，当Server要向节点1回复时，是向200.10.10.1这个地址发送数据而不是向192.168.1.1直接发（如果这么发就发到服务端侧自己的本地网段中其它设备去了，很明显错误）！

Server回复的数据经过NAT重映射之后，目标IP从200.10.10.1被网关修改为了192.168.1.1，随后数据被路由给节点1，正确接收。节点2的收发流程也是同理。

在本例中：200.10.10.1 与 200.10.10.2这两个公网IP将被节点1和节点2永久占用。

也就是说一个设备吃掉一个公网IP，这是极其浪费的一种行为。因此静态NAT模式通常用于服务器这些需要对外提供服务的设备（作为服务器必须保证地址稳定可连接）。

动态NAT

动态NAT维护有一个IP地址池，该池中是目前空闲可使用的公网IP。其本质就是：从地址池中进行动态分配，谁先上网就先优先分给谁使用，用完后释放。

动态NAT和静态NAT流程上有相似之处。上例中，我们IP池中原本有 200.10.10.1~x 个空闲公网IP，节点1与节点2都需要上网，因此200.10.10.1被分配给了节点1，200.10.10.2被分配给了节点2。

与静态NAT一样，动态NAT一个公网IP一次只能服务一台设备，因此池中前两个IP被占用，假如此时节点3上线需要进行通信，那么节点池会将空闲的200.10.10.3分配给节点3使用。当地址池被用尽后，只能等待被占用的公用IP被释放后，其他主机才能使用它访问公网。

对于动态NAT而言，其实并没有解决公网IP浪费问题，因为本质上依然是一台设备对应一个公网IP。动态NAT定位十分尴尬：它比静态NAT省一点，但没省到点子上；比NAPT差很多，却没有任何额外优势。在NAPT普及后，纯动态NAT已很少单独使用。

NAPT(端口地址转换)

NAPT技术也叫做端口多路复用，是目前应用最广泛的NAT技术，也是最需要仔细了解的技术。NAPT与静态NAT/动态NAT不同，能够真正做到一个公网IP同时使数十台设备同时上网。

其原理是：使用传输层端口号区分不同的内网主机和会话，所有内网设备共享一个（或少量）公网 IP，通过不同的源端口映射出站连接。

你比如两台本地设备分别被映射到了公网IP 200.10.10.1:50341 和 200.10.10.1:46893，两台设备使用的都是 200.10.10.1这个公网IP，但是流量被接入到了不同端口。若公网Server需要向其中一台设备通信，则只需要向 200.10.10.1:50341/46893 这两个端口发送数据即可。目的IP都是一样的，但是端口号为50341的流量会经NAT转换后被网关路由给设备1，端口号46893则路由给设备2。

具体见下图：

示例中，节点1与节点2分别被分到了公网IP200.10.10.1的50341与46893端口，这两个设备通过一个公网IP上网。当Server回复50341端口时，其数据包来到网关处，NAT查表得到50341映射为本地 192.168.1.1:x 的设备，随后NAT将包中的公网地址修改为本地的地址，交给网关路由到对应设备。整个流程下来Server向200.10.10.1:50341这个地址的回复数据包就被我们本地192.168.1.1:x正确接收到了。

节点2以及其它更多节点的通信都是同样的道理。

三种类型之间的简单对比

类型映射关系是否改端口公网 IP 消耗典型场景
静态 NAT一对一，永久否1:1，最浪费对外服务器
动态 NAT多对多，动态否N:M，较浪费企业内网
NAPT多对一，动态是N:1，最省家用路由器、手机热点
]]> https://r6blog.online/2026/09/14/%E5%B5%8C%E5%85%A5%E5%BC%8F2026091401/ 2026-09-14T06:26:40.000Z 引言

在网络通信中，IP地址是不可或缺的一环，无论是什么通信方式，均离不开IP地址。目前主流的IP地址协议为IPv4，一]]>

NAT 地址转换 2026-10-08T07:15:10.247Z R6bandito OSI 七层模型

OSI七层模型，全称是开放系统互连参考模型。是国际标准化组织提出的一个用于管理网络通信的网络分层模型。

如下表所示，OSI模型十分详尽，理论背书充足。但是也正是因为过于理论这个原因，其实现十分复杂，缺乏实际落地应用的基础，且有的层次划分不尽合理。

所以在应用方面实际被广泛使用的是TCP的经典四层模型。

实际学习中，对于七层理论模型了解一下即可。

层级名称核心功能常见协议/设备
第7层应用层为用户提供网络服务接口HTTP、FTP、SMTP
第6层表示层数据格式转换、加密、压缩SSL/TLS、JPEG、ASCII
第5层会话层建立、管理、终止会话NetBIOS、RPC
第4层传输层端到端可靠传输TCP、UDP
第3层网络层路由选择、逻辑寻址IP、ICMP、路由器
第2层数据链路层帧封装、MAC寻址、差错检测以太网、交换机、PPP
第1层物理层比特流传输、电气特性网线、光纤、集线器

TCP/IP 四层经典模型

TCP/IP 四层模型才是真正的重头戏。与OSI理论模型不同，TCP经典模型是在不断的实践运用中逐渐积累起来的。主要分为以下几个层次：

层级对应 OSI 层核心功能常见协议
应用层5+6+7用户服务HTTP、FTP、DNS、SMTP
传输层4端到端传输TCP、UDP
网络层3路由寻址IP、ICMP、ARP
网络接口层1+2物理传输以太网、Wi-Fi、PPP
  • 应用层：囊括了理论模型的会话、表示层，统一收拢到应用层中。常见的上层应用协议（例如HTTP、MQTT、DNS等等）均在此层
  • 传输层：这和理论模型第四层是相同的，TCP/UDP的“老巢”，负责端到端（你也可以理解为 进程–>进程）之间的数据包寻址。
  • 网络层：同理论模型第三层，主要是IP协议，规定了数据包怎么走，走哪条路。该层还包含了ARP与ICMP等等次生协议用于辅助通信。
  • 网络接口层：对应理论模型的1、2层。负责将数据变为光电信号发出，网卡驱动以及物理线缆都属于这一层的范围。

总的来说，TCP/IP 四层把 OSI 的上三层（会话、表示、应用）合并成应用层，下两层（物理、数据链路）合并成网络接口层。这不是简单的“压缩”，而是按实际工程需要重新划分——OSI 的会话层和表示层在实际协议栈中几乎没有独立实现，它们的功能被直接塞进了应用层协议里（比如 TLS 做加密、HTTP 管会话）。

数据封装与解封装流程

四层模型每一层都对应这一个封装与解封装的过程：

  • 对于发送方而言，由应用层开始从上至下，每经过一层就加上该层的头部（或尾部），这个过程就叫封装。
  • 对于接收方而言，由物理层（接口层）开始从下至上往上递交，每经过一层都要剥去该层的头部（或尾部），这个过程叫解封装。

所以总的来说，分层的本质是：各层只关心自己的头部，只根据自身的头部进行对应操作，而不关心其它层的内容。其它层的内容相对于它们就视作普通数据负载。

以下是以HTTP为例的以太网数据包封装与解封装示意图：

发现了吗，封装流程与解封装流程基本上是一样的，只是方向不同罢了。

在传输过程中，传输层的PDU单位叫作“段”，也就是我们说的TCP报文段；网络层单位叫作“包”，IP数据包；在接口层叫作帧，以太网帧。了解一下就好。

关于数据发出与接收的详细流程，本文不做阐述，这些细节将在其余文章进行单独叙述。

为什么工程上用 TCP/IP 而不是 OSI？

因为OSI 是“先定标准，再写实现”，TCP/IP 是“先有实现，再总结标准”。这就导致：

  • OSI 的协议栈复杂、层次过多，实际部署极少；
  • TCP/IP 经过 ARPANET 和互联网几十年实战检验，实现轻量、兼容性好；
  • 但 OSI 的分层思想被 TCP/IP 完整继承——所以我们理论研究时可以用 OSI 进行阐述和理解，但是落实到实际工程中要用 TCP/IP 。
]]> https://r6blog.online/2026/09/13/%E5%B5%8C%E5%85%A5%E5%BC%8F2026091301/ 2026-09-13T03:24:51.000Z OSI 七层模型

OSI七层模型，全称是开放系统互连参考模型。是国际标准化组织提出的一个用于管理网络通信的网络]]>

OSI 七层模型与 TCP/IP 四层经典模型 2026-10-08T07:15:10.247Z R6bandito 引言

日常开发中，内存的管理自然是不可或缺的一环。例如 Ethernet 中要发送数据包要开辟发送缓冲区，接收数据包时要开辟接收缓冲区，并且使用完毕后需要及时归还，以免出现内存泄漏。这些操作均离不开一个可靠的内存管理机制。

标准C中已经给我们提供了一套由用户自行管理的内存分配机制，也就是我们常说的堆内存heap（动态分配机制）。但是由标准C提供的这一套机制在嵌入式开发中风险是比较高的，其中主要来自以下几个方面：

  • 不可重入特性：如果被竞争访问有很大风险会造成堆结构损坏，堆链断裂。在一些中间件的改造中(例如 FreeRTOS heap_3) 可能解决了这个问题，但是这仅仅只是取决于一些三方的实现。
  • 容易造成碎片化：标准C实现是没有前后相邻块合并吞食的，这也就意味着在大量分配与释放的操作下，产生微小难以利用的内存碎片的概率很大，导致程序不稳定。
  • 内存位置由链接器强行绑定：标准 C 的堆只有一个——就是由链接器分配的那块。如果想要管理例如 CCM_SRAM这类内存，那么标准C这套管理方法完全无法使用。

因此在很多情况下，嵌入式中的动态内存分配是被完全禁止的。这就需要我们手动打造一套自身的嵌入式专用的内存管理机制。

什么是内存堆？

常规的内存管理机制有 内存池、内存堆 等实现，内存堆其本质就是：在局部开辟一块巨大的静态内存数组，然后在这块数组之上，自行实现一套分配、释放、合并的规则。

1
2
/* 后续的所有内存堆逻辑都是基于该块内存空间上展开. */
static uint8_t __attribute__((aligned(ALIGNED))) ucHeap[HEAP_SIZE];

和内存池区别在于内存堆能够精细把握块粒度，而内存池只能够固定大小分配。

内存堆思想

内存堆的实现有多种变体，这里只阐述我常用的 First Fit(首次适配) + 前后合并 的设计模式。

这里需要先了解一下内存堆是怎么向用户划分空间的基本流程：

  • 用户调用 alloc() 向管理器请求一块内存。
  • 内存堆内部开始遍历所有内存块，直到找到第一块内存空间 > 请求空间的空闲内存。
  • 将该块空间取出，将用户所需部分取出标记使用后返回给用户；多余部分返回给内存堆中。
  • 用户使用完毕后，将空间返回内存堆中，合并前后可能的空闲块，并标记空间空闲。
块头结构

要进行管理，自然离不开对应的数据结构。块头结构就类似于”身份证“，每一块空闲或是正在被使用的内存块都需要维护一个该结构，以便管理逻辑能够正确找到它。其内部包含的元素通常需要含有如下几个：

  • 块大小(BlockSize)：这一块空间有多大？用于计算下一块的地址以及与用户申请空间做判断。
  • next、prev 双向指针：双向指针是必须的，用于前后合并以及内存堆遍历时的正向索引。
  • 使用标志(used)：这块内存目前是正在被使用还是空闲？要弄清楚这个状态我们就必须维护一个使用标记。这个标记也是我们后续分配以及前后合并时的一个重要参考。

综上所述我们可以拿出如下一个数据结构：

1
2
3
4
5
6
typedef struct heapCtrl {
uint32_t blockSize;
uint32_t used;
struct heapCtrl *next;
struct heapCtrl *prev;
} heapCtrl_t;

这里先记住这个结构，后续我会画图来进行阐述，这个结构尤其重要！

（Ps：这里有个细节要说明一下：尽管used的含义只是布尔型变量，但是此处要使用u32，目的在于结构体内存对齐，便于后续的地址计算。 在MCU中非对齐地址访问风险是很大的!轻则降低效率,重则直接硬件错误）

快速索引

接下来我们还需要一个快速索引（不知道这么叫是否合适，但是作用确实是提高效率），这个索引我来打个比方：在TCP/IP 的大部分实现中，网络层在查ARP表时往往会全局维护一个最近一次命中的IP地址。这样当我下一次向相同IP发包时，就不需要再去遍历ARP缓存表，而是直接一次命中！这就是我们所谓的缓存命中。

同理，我们在此处的索引也是这个道理：假如我们每次请求内存都从数组头开始逐块遍历，那其实效率是比较低的。我们维护一个变量专门指向当前最低地址的空闲块，那么后续遍历直接从该块开始向后遍历，就能提高不少效率。

这个全局索引我们这么来设计：

1
static void *minFree_List = NULL;
  • 分配时，从该地址开始后向遍历（该地址前面全是已经使用了的，没必要跑一遍）。
  • 释放时，若新空闲块地址 < 索引，则更新索引。
分配策略

这里来谈谈分配策略。我在之前已经说过，内存堆的实现不是唯一的。在这里，内存堆关于分配算法的实现主要有以下几类：首次适配（First Fit）、最佳适配（Best Fit）。其中

  • 首次适配：从头开始，找到第一块够大的就行。这是嵌入式里面的经典实现，FreeRTOS的heap_4以及lwIP的内存堆实现采用的都是首次适配的方法。这个方法速度快，而且实现简单，缺点就是在低地址空间中容易形成碎片。
  • 最佳适配：遍历整个链表，找“刚好够用且最小”的。这个方法优势很明显，碎片少；但是缺点也显而易见，时间复杂度更大，而且会产生更小的碎片。在FreeRTOS的heap_2中使用的就是该方式（目前heap_2已被heap_4全面替代）。

我们本文讲解与使用的正是 首次适配(First Fit)的方式。

分裂与合并

分裂

这是整个内存堆分配与回收的流程。上述我已经简述了分配的一个基本流程，此处不再赘述。直接上图能更加形象的呈现整个流程：

  1. 刚初始化时，整个内存堆都是空闲的。此时内存结构如下图所示：

其中，heapCTRL为内存块控制头，由于刚初始化没有产生过分配行为，因此只有一个控制头控制着

(HEAP_SIZE - sizeof(heapCTRL))大小的空闲内存块。

  1. 我们向初始化后的内存堆请求一块Size大小的空间。内存堆状态如下

看到了吗？我们请求一块Size大小的空间，首次分配从整个Free Space中划出来了一块Size大小返回给用户，同时检查剩余空间是否足以容纳下一个控制头（heapCTRL）以及最小数据块(Minimum_Heap_Size)。如果能够容纳，那么剩下部分被打上控制头后返回给内存堆中，供下一次分配使用。

这里提一嘴为什么需要设置Minimum_Heap_Size门槛：这是为了防止内存被割得太碎进而无法有效利用。如果当前遍历到的这块空闲空间，划分后剩下部分已经不足以维持一个控制头和最小数据块，那就索引整个分配给用户，不再切割了。

由于已经发生分配行为，因此我们的minFree_List也得更新到最低地址的空闲块，下次分配行为直接从minFree_List处开始，不再从头开始遍历。

(Ps：这里要提一下，我们展示的合并与分配链表操作其物理地址在空间上必须是连续的！使用链表结构只是为了更加清晰。你别把所有空闲块都串在一条链表上，而后对逻辑地址进行操作，那么整个就全错了！)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
/* 判断分配后该块剩余部分是否仍能组成最小单位内存块. */
/* 若可以则表示需要切分，split标志置1. */
if ( (ALIGNx((mark->blockSize - need)) >= MIN_HEAP + sizeof(heapCtrl_t)) )
split = 1;

if ( split )
{
       /* 新块切分流程. */
heapCtrl_t *new = (heapCtrl_t *)(((uint8_t *)mark + sizeof(heapCtrl_t)) + need);
       /* 新块块大小(不含控制头). */
new->blockSize = (mark->blockSize - need - sizeof(heapCtrl_t));
       /* 将新块链入. */
new->next = mark->next;
new->prev = mark;
mark->next = new;
if ( new->next != NULL )
new->next->prev = new;
       /* 更新新块状态与旧块 块大小(blockSize). */
new->used = 0;
mark->blockSize = need;
}
mark->used = 1;/* 标记旧块已被使用. */
/* 更新minFree_List. */
if ( minFree_List == (void *)mark )
{
heapCtrl_t *q = mark->next;
while ( q != NULL && q->used )
q = q->next;
minFree_List = (void *)q;
}

上面是该段过程的一个参考实现。关键的部分已经给出注释，此处不再赘述。

合并

涉及分配，自然也要涉及到归还。归还不是直接将已使用的块的used标志置0，这么做固然可以，但是久而久之会在低地址空间产生大量的细小内存碎片难以利用，更加暴露我们的First Fit的短板。所以需要想一个办法尽量减少微小内存碎片的产生。

我们的做法是在内存归还时检查其前后“邻居”，如果“邻居”都是空闲状态，那么为什么我们不将其合并成一整块呢？

来看下面：

我们请求分配一块SizeP大小的空间，管理逻辑从minFree_List开始后向遍历，发现n1部分的空间并不满足需求，因此向后继续找到了n2部分，n2满足需求，于是便从n2中取出SizeP + sizeof(heapCTRL)大小的部分用于返回给用户以及新块的控制头建立。对应图中的 ①—>② 这个过程。

假如我们SizeP部分暂时不需要了，需要归还呢？流程是怎么样的呢？

释放时，我们可以先将SizeP（即要归还部分）置空闲状态。也就是由 ① –> ② 状态。

此时，逻辑后向检查发现：n2部分依然是空闲的，因此将n2向SizeP合并，保留SizeP控制头，调整前后指针逻辑。

而前向检查，前面一块相邻内存已经被占用，因此不能进行前向合并。

具体见下面参考示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
/* 后向检查与合并. */
while ( p->next && !p->next->used )
{
p->blockSize += (p->next->blockSize + sizeof(heapCtrl_t));
if ( p->next->next )
p->next->next->prev = p;
p->next = p->next->next;
}

/* 前向检查与合并. */
while ( p->prev && !p->prev->used )
{
p->prev->blockSize += (p->blockSize + sizeof(heapCtrl_t));
p->prev->next = p->next;
if ( p->next )
p->next->prev = p->prev;

p = p->prev;
}
/* 状态置空闲. */
p->used = 0;
/* 检查并更新 minFree_List. */
if ( (minFree_List == NULL) || p < (heapCtrl_t *)minFree_List )
minFree_List = (void *)p;

本文我们展示的是释放时立即合并，其实还有一种合并方法就是 惰性合并。

所谓惰性合并就是指：在内存分配时直接进行合并。例如分配时，切下的空闲块后续仍是空闲，那就立即执行合并而不是等到释放时在进行合并。本质都是一样的，区别在于合并的时机不同，实现不同。

总结

这里详细给一下内存堆与内存池的对比：

维度内存池（Pool）内存堆（Heap）
块大小固定可变
分配O(1) 取链表头O(n) 搜索 + 分裂
释放O(1) 插回链表O(1) 插回 + 合并
碎片无有，必须管理
块头开销1 个指针大小 + 标志 + 链表指针（8~16 字节）
适用RTOS 栈、消息队列、固定结构不定长字符串、动态数组、协议解析

内存堆与内存池在LwIP中的运用是十分广泛的，想要更加深入了解的话可以具体去看一看其内存管理模块的源码实现。

文章上述的参考示例均是在裸机环境下定义的，如果要引入OS，需要考虑线程保护。

]]> https://r6blog.online/2026/09/12/%E5%B5%8C%E5%85%A5%E5%BC%8F2026091201/ 2026-09-12T07:02:48.000Z 引言

日常开发中，内存的管理自然是不可或缺的一环。例如 Ethernet 中要发送数据包要开辟发送缓冲区，接收数据包时要开辟接收缓冲区，并且使用完]]>

嵌入式内存管理： 内存堆 2026-10-08T07:15:10.243Z R6bandito 最近在写一个简易的内存管理逻辑用于 CCM_RAM 以及其余通用 RAM 管理。过程中涉及到了内存池的配置：如果需要添加一个新类型的内存池，常规做法是在相关 .c/.h 中再定义一个数组以及维护一套描述头结构。但是这涉及到多个文件的修改，如果漏改一个地方那么将导致程序编译不过。而且如果后续逻辑写大之后，维护将及其不便。此时便想起了可以使用 X-Macro 来解决这个问题。

什么是 X-Macro ？

X-Macro 是一种用宏来定义数据列表，然后反复重定义 X 来生成不同代码的预处理器技巧。是一种可靠维护代码或数据的并行列表的技术，你只需要维护一份数据列表，编译器自动帮你生成枚举、数组、函数声明、结构体、初始化代码等所有重复性内容。

X-Macro 并不是C语言的新特性，它本质其实就是普通的宏定义与展开，在这个基础之上才衍生出了 X-Macro，因此 X-Macro 准确来说应该是一个宏的使用技巧。

使用方法

单看概念会觉得十分抽象，这里我们给出一个简单的示例：

1
2
3
4
#define MY_DATA_LIST \
    X(ITEM_A, 100, "hello") \
    X(ITEM_B, 200, "world") \
    X(ITEM_C, 300, "foo")

上面我们定义了一个数据表，现在我们想要利用这个数据表，一次性定义3个变量，并使用表中的数值参数对其进行初始化，该怎么做？ 这里可以使用 X-Macro 来完成：

1
2
3
#define X(name, val, str) int name##_value = val;
MY_DATA_LIST
#undef X

上面逻辑中，我们定义了 X(参数) 为我们想做的操作（变量定义）：int 参数1##_value = 参数2;

在预处理阶段，MY_DATA_LIST 展开后得到下列程序：

1
2
3
int ITEM_A_value = 100;
int ITEM_B_value = 200;
int ITEM_C_value = 300;

发现没有？我们仅仅通过一次展开 MY_DATA_LIST 宏就得到了所有的变量定义，如果此刻我们想要加入第四个变量该怎么做？很简单，只需要在 MY_DATA_LIST 中多引入一个表项就行。

1
2
3
4
5
6
7
8
9
10
11
#define MY_DATA_LIST \
    X(ITEM_A, 100, "hello") \
    X(ITEM_B, 200, "world") \
    X(ITEM_C, 300, "foo") \
    X(ITEM_D, 400, "happy")
    
// 展开后：
int ITEM_A_value = 100;
int ITEM_B_value = 200;
int ITEM_C_value = 300;
int ITEM_D_value = 400;

我们通过一个简单的变量定义场景就阐述出了 X-Macro 宏的用法。相信你此刻已经见识到了这玩意儿的强大之处：没错，我们只需在 conf.h 中维护一个全局表项，后续的 数组声明/枚举定义 等等均采用 X-Macro 进行展开。如果后期需要对表项做出修改，只需要改 conf.h 文件就行，其余模块内部自适应变化！极大降低了维护工作量，且不易出错。

这里我就不以更多的示例来进行阐述，直接来看一个实际的应用场景：

目前需要设计一个内存池，且该内存池类型不固定（也就是说需要支持不同类型的内存池），且用户侧对于内存池的类型删减必须足够简便。很明显，这就是一个典型的 X-Macro 的用武之地了，一起来看。

我们先以一个默认的类型来入手，默认池采用每块512字节，供划分12块的配置。

1
2
3
4
5
6
/* This is default setting. */
#define DEFAULT_BLOCK_SIZE  (512ul)
#define DEFAULT_BLOCK_NUM   (12u)

#define MEM_POOL_LIST   \
X(DEFAULT, DEFAULT_BLOCK_SIZE, DEFAULT_BLOCK_NUM)

X(DEFAULT, DEFAULT_BLOCK_SIZE, DEFAULT_BLOCK_NUM)

这就是我们的数据列表了，后续用户所有对于内存池配置的操作都在此进行。

列表定义好之后首先我们需要的就是再定义一个枚举，该枚举是后续我们访问不同类型内存池的关键（也可以理解为池索引），接下来我们使用 X-Macro 进行第一次展开！

1
2
3
4
5
6
7
// 第一次 X-Macro 展开.
#define X(name, size, depth)  POOL_##name,
typedef enum {
MEM_POOL_LIST
POOL_MAX
} pool_id_t;
#undef X

展开后如下：

1
2
3
4
typedef enum {
POOL_DEFAULT,
POOL_MAX
} pool_id_t;

Ps:这里有个小细节要注意一下：POOL_MAX 是根据枚举型的递增特性，用来统计池类型数目的，后续用于循环计数。

现在索引有了，我们需要再定义物理数组，也就是这片内存池真正的空间来源。这是我们第二次 X-Macro 展开，注意看。

1
2
3
4
5
6
// 第二次 X-Macro 展开.
#define X(name, size, depth) \
static uint8_t __attribute__((section(POOL_SECTION))) __attribute__((aligned(4))) \
pool_##name##_heap[(size + sizeof(void *)) * (depth)];
MEM_POOL_LIST
#undef X

展开后，得到：

1
2
/* 这里 sizeof(void *)在32位下是4字节.一个小细节 */
static uint8_t pool_DEFAULT_heap[((512ul) + 4) * (12u)];

继续，要管理不同类型的池子，需要对应的描述头结构。这里我们描述头定义为：pool_desc_t，具体结构就不详细给出了。每个池子类型都要对应自己的描述头，因此描述头结构应该是一个对应结构数组中的表项。

这里我们第三次使用 X-Macro 展开：

1
2
3
4
5
6
7
// 第三次 X-Macro 展开.
static pool_desc_t pool_table[POOL_MAX] = 
{
#define X(name, size, depth){ (size) + sizeof(void*), depth, NULL },
MEM_POOL_LIST
#undef X
};

展开后得到：

1
2
3
4
static pool_desc_t pool_table[POOL_MAX] = 
{
{ (512ul) + 4, (12u), NULL },
};

至此，三次展开已经全部结束。 我们来总览一下 X-Macro 给我们带来了什么。

1
2
3
4
5
6
7
8
9
10
typedef enum {
    POOL_DEFAULT,
    POOL_MAX
} pool_id_t;

static uint8_t pool_DEFAULT_heap[((512ul) + 4) * (12u)];
static pool_desc_t pool_table[POOL_MAX] = 
{
{ (512ul) + 4, (12u), NULL },
};

看到了吧，一行数据列表给我们从结构声明到数据结构定义全部搞定。这就是 X-Macro 最大的意义：

零运行时开销，所有枚举、数组大小、地址排布在编译期就定了。且用户只需改一行列表，所有相关代码自动同步，不需要挨个模块去加实现。

假如我们目前需要加入 TEST 类型池子， 大小1024，深度15，怎么做呢？很简单，多加一个列表的事。

1
2
3
#define MEM_POOL_LIST   \
X(DEFAULT, DEFAULT_BLOCK_SIZE, DEFAULT_BLOCK_NUM) \
X(TEST, (1024ul), (15u))

X-Macro 将自动生成：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
typedef enum {
    POOL_DEFAULT,
    POOL_TEST,
    POOL_MAX
} pool_id_t;

static uint8_t pool_DEFAULT_heap[((512ul) + 4) * (12u)];
static uint8_t pool_TEST_heap[((1024ul) + 4) * (15u)];

static pool_desc_t pool_table[POOL_MAX] = 
{
{ (512ul) + 4, (12u), NULL },
{ (1024ul) + 4, (15u), NULL },
};

无需多言了，这就是 X-Macro 的魅力所在。

一些使用场景

我最早接触到 X-Macro 是在 LwIP 的内存管理算法源码中了解到的。LwIP 在内存池逻辑中就使用了 X-Macro 进行不同池类型的管理，其原理与我上述所说的本质是一样的：通过不断展开 X-Macro 来声明与定义数据结构，后续内存池类型的增删（比如 UDP/TCP 等等类型控制块其内存来源都是内存池）直接通过数据列表进行配置，无需改动内部逻辑。

这里我给一些 LwIP 源码中的具体实现，作为参考学习：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
LWIP_MEMPOOL(RAW_PCB,        1,   100, "RAW_PCB")
LWIP_MEMPOOL(TCP_PCB,        5,   200, "TCP_PCB")
LWIP_MEMPOOL(TCP_SEG,       10,   50,  "TCP_SEG")
// ... 后面还有很多
    
#define LWIP_MEMPOOL(name,num,size,desc)  MEMP_##name,
    
// 展开后.
typedef enum {
    MEMP_RAW_PCB,
    MEMP_TCP_PCB,
    MEMP_TCP_SEG,
    // ... 继续展开所有池
    MEMP_MAX
} memp_t;

/* **************************************************** */ 
const struct memp_desc *const memp_pools[MEMP_MAX] = {
#define LWIP_MEMPOOL(name,num,size,desc) &memp_ ## name,
#include "lwip/priv/memp_std.h"
};

// 展开后.
const struct memp_desc *const memp_pools[] = {
    &memp_RAW_PCB,
    &memp_TCP_PCB,
    &memp_TCP_SEG,
    // ... 
};

X-Macro 的适用场景其实很明确：同一份数据，需要在多个地方以不同形式出现——枚举、数组、字符串表、初始化代码。一旦用上，原来需要手工同步的重复代码全部可以删掉。

其技巧本身并不难，难在能不能够在具体业务场景中识别并运用。

]]> https://r6blog.online/2026/09/11/%E5%B5%8C%E5%85%A5%E5%BC%8F2026091101/ 2026-09-11T08:10:14.000Z 最近在写一个简易的内存管理逻辑用于 CCM_RAM 以及其余通用 RAM 管理。过程中涉及到了内存池的配置：如果需要添加一个新类型的内存池，常规做法是在相关 .c/.h 中再定义一个数组以及维护一套描述头结构。但是这涉及到多个文件的修改，如果漏改一个地方那么将导致]]> C黑魔法 X-Macro 宏 2026-10-08T07:15:10.243Z R6bandito 在上篇中（ISO-TP 通信流程(上)）我们详细介绍了 iso-tp 中的基础通信数据元（PDU）以及寻址模式，这些内容指导了我们 CAN 报文的组装方式。在下篇中，我们将在前述的基础上，详细讲讲 iso-tp 的状态机流转过程，帧是怎么发送的，时序上有哪些要求。

这里先给两个总状态机流转图：

(一) iso-tp 接收流程状态机(源自 ISO 15765-2:2016)

(二) iso-tp 发送流程状态机

后续我们将以该两图为基础，详细拆解其各个状态。

发送状态机

单帧传输

iso-tp 是具备单帧路由机制的。当待发数据量 <= 7字节(普通寻址模式/Classic CAN为例) / <= 6字节(拓展寻址/Classic CAN 为例)时，我们一个报文就可以将所有的数据全部打包带走，没有必要启动多帧传输。协议栈内部在满足上述条件后，会直接走单帧发送路径。以下是 SF 单帧传输的状态流程：

协议栈内部判定该包数据长度能够在该寻址模式下，通过一个 CAN 报文全部打包带走时，便会将待发送数据路由给单帧发送机制。单帧发送机制会构建 SF 类型的报文，向总线发出，并且在提交发送请求后会立即开启硬件定时计时器 N_As。此时连接控制块状态为 TX_SF 。

当 CAN 控制器成功发送出该帧报文时，将关闭定时器，并且复位状态为 IDLE 空闲状态。以此就完成了一次 SF 单帧的通信。当硬件因为某些原因没有发送出报文进而导致定时器超时后，协议栈应该通知上层，向上层上报错误，由上层来决定是否重启通信。

多帧传输

iso-tp 中，可靠的多帧重组传输机制才是协议的一大亮点。多帧传输是由 FF + CF + FC 共同构成的一个稳定的传输状态机，以下是多帧传输下的状态机流转图：

当协议栈发现要传输的数据量大于单帧所能承载的容量时，此时便会触发多帧传输。

其具体流程为：

  • 构建 FF 帧，用于启动一次多帧传输。

将 PCI + FF_DL + 首段数据(此处示例为 <= 4095 的情况，若 > 4095 且为 Classic CAN，因长度字段占据大量空间，FF 通常不携带有效数据，所有数据均从后续 CF 开始发送。) 打包进CAN报文中，并正确填充 TA/SA/TAType 等信息，提交硬件发送，并启动 N_Bs（流控超时计时器）与 N_As（硬件计时器）。此时状态由 IDLE 转为 TX_FF，当硬件发送确认后，N_As被关闭，状态转为 TX_WAIT_FC，等待接收方发回流控FC。
此时 N_Bs 计时器依然运行，用于监控接收方发回流控这一操作是否超时。

  • 收到接收方发回的 FC ，更新本次传输流控参数，停止 N_Bs 定时器。

收到 FC 之后，若收到的是 WAIT 流控，发送方不应停止 N_Bs，而是重启该定时器继续等待下一个 FC。其它情况下协议栈应该停掉并重置 N_Bs 计时器，同时将收到的 FC 中的流控参数(STmin/BS)以及流控状态提取出来。若对端返回 OVFLW 状态，表示缓冲区不足，应当终止本次传输。
在后续通信中，发送方将严格遵循 FC 中的 STmin（两个CF之间最小帧间隔）与 BS（块大小）的约束进行 CF 的发送。

这里有些细节要强调一下：

  1. STmin/BS 是允许均为0的，代表全速发送，要注意接收方处理速度能否跟上。
  2. 关于 FC 流控机制，标准里面给出了两种解释，详见下图：

iso-tp 允许接收方在同一个多帧传输过程中动态调整流控参数。也就是说，流控机制分为了静态流控与动态流控，不同的工程背景可以选用不同的流控机制。

动态流控：接收方在同一个多帧传输的不同流控帧（FC）中，可以改变 BS 和 STmin 的值（比如第一次 FC 告诉你 BS=5，下一次告诉你 BS=3）。也就是说，iso-tp 允许服务器根据负载动态掌控流控，如果服务器是分段消息的接收方，那么可以自由选择保持 BS/STmin 不变，或者在同一个多帧传输中改变这些值。

例如服务器 CPU 负载变高时，可以将流控缩小甚至关闭（发送Wait流控），以免缓冲区溢出。当空闲时再打开流控接收分段数据。

静态流控：在同一次多帧传输的所有 FC 帧中，BS 和 STmin 要保持不变。也就是说该次通信的流控取决于第一次发送给对方的流控，后续均基于这个流控参数的基础上进行通信。

这个流程中，流控主导权在接收方，发送方被迫适应。

在我的轻量化实现中，对于这个部分我是统一采用静态流控的。因为常规 MCU 之间的通信大部分情境下都不会使用到该功能，为此在发送方引入一个解析功能没必要。

  • 根据流控参数发送连续帧 CF。

从发送缓冲区中取出下一段待发数据，打包成 CF 帧向总线发出，并启动N_As等待控制器成功发到总线上后响应。在整个 CF 发送期间状态机都应该保持 TX_CF 状态。

同时，SN 序列码要递增，这是协议栈判断是否帧错位的重要依据。上一篇文章我们已经阐述了 SN 序列码的作用，此处仅简单提一下要点即可：一定要注意 SN 码是模16循环！因为 SN 的占位只有4位大小，如果忘记循环那么通讯将在第一次 SN 码触发临界时断裂，尤其要注意！

由于流控的作用，每帧 CF 之间需要间隔 STmin。且如果当前BS块发完（仅在 BS > 0 条件下）的话，需要回到 TX_WAIT_FC 状态，等待接收方通过流控 CTS 下发下一次的发送许可。

CF 发送的整体流程如下图所示：

图片内容展示了多帧传输 + 流控场景下的数据收发示意图。重点理解 BS与STmin的概念。

  • 数据发送完毕，传输结束

当最后一包 CF 发出后，协议栈内部判断读指针已经来到待发数据末尾，说明当前整个缓冲区数据已被发出。此时发送方将状态从 TX_CF 切换为 IDLE 空闲状态，通知上层传输完成（可通过回调等形式）并清扫连接内部的相关字段，为下一次通信做准备。

值得注意的是，iso-tp 与 IP 协议类似，只尽最大努力路由数据，至于对端是否接收到是不会管的。没有应用层的 ACK 确认机制（对端是否完全正确接收与组装不会发一帧报文来通知你）。

接收状态机

单帧接收

当协议栈接收到一帧 iso-tp 报文后，会取出 PCI 信息字节的高四位：帧类型识别码。若识别码为 0（即下图中 N_PCItype = 0），则表示该帧为 SF 单帧，走单帧处理流程。

  • 检查接收的CAN报文数据段是否 <= 8字节.(Classic CAN)

若数据长度 ≤ 8：可能是 Classic CAN，也可能是短 CAN FD，但两者 SF 格式一致，直接按 SF_DL 解析即可。此时若 SF_DL = 0，属于非法格式，按错误帧处理。

  • 若数据段 > 8字节，检查是否为 CANFD 的有效 SF 报文.

数据长度 > 8 时，必然是 CAN FD，且数据长度已超过短格式范围，因此必须使用扩展 SF_DL 格式：第一字节低 4 位（原 SF_DL）为 0，真正的长度在第二字节。

对于原4位 SF_DL 不为0的情况，当作错误帧进行处理（忽略）。

多帧接收

当协议栈收到帧类型识别码为 1 的报文时，表示接收到了一帧 FF 首帧。收到 FF 即表示一次多帧通信即将开始，接下来就是完整的多帧通信状态机。

  • 收到 FF 后，提取 FF_DL，回复流控。

收到一帧 FF 后，状态变为 RX_FF 。协议栈应提取出该报文中的 FF_DL，检查自身缓冲区是否足以容纳本次通信数据量（流式传输除外），以明确本次通信所要传输的数据量大小；提取出可能存在的由 FF 帧带来的部分数据；同时也要提取出发送方 SA 地址，便于后续回复流控。

所有数据提取后，根据自身设置，构建 FC 流控帧发往对端，同时启动 N_Cr(监控发送方是否按时发来下一个 CF) 与 N_Ar 计时器(监控 FC 是否被硬件成功发出)。FC流控成功被硬件确认后，此时状态变为 RX_CF ，准备接收接下来的 CF 数据包。

  • CF 数据包接收。

这里接收部分需要涉及到 SN 连续性检查，首帧隐含 SN = 0，因此收到的第一个 CF 期望 SN = 1。

若 SN 与期望值匹配 ，数据存入缓冲区，期望 SN 递增（模16循环）。

若 SN 不匹配（期望2却收到3） 丢弃该帧，保持当前状态，等待 N_Cr 超时后回到 Idle 状态并等待下一次 FF。标准规定此时接收方不主动发送错误码，沉默等待即可。

每收到一个 SN 匹配的 CF 都要重置 N_Cr 定时器。

  • 流控参数：BS。

若 BS != 0，则作为接收方，当BS阈值到达时，状态转换为 TX_FC 需要向对端发送一个 FC 报文。这里如同上文所述：分为静态流控与动态流控。具体怎么使用取决于你的工程实现。

  • 接收完成。

当累积的接收数据 == FF_DL 时，此时可认为已经收到完整的数据。协议栈应停掉 N_Cr 定时器，

状态回到 IDLE 空闲，并将完整的数据交付给上层（通过回调或消息队列）。最后打扫控制块中的对应字段，为下一次通信做准备。

整个流程中，对于 N_Cr 超时，接收方应丢弃已重组数据，状态回到 IDLE，并通知接收方上层。接收方不主动请求重传；是否重新发起多帧传输由发送方决定。

发送状态机与接收状态机其实是对称的：发送方在 TX_WAIT_FC 等流控，接收方在 RX_CF 等连续帧；发送方关心 N_Bs（等 FC），接收方关心 N_Cr（等 CF）。两者通过 FC 帧中的 BS 和 STmin 完成节奏协商，共同保证多帧数据在 CAN 总线上的可靠重组。

ISO-TP 定时器汇总

前面多次提到了定时器，这里给出 iso-tp 中的一些相关定时器以及分工表：

定时器生效方全称启动时机停止时机超时后果
N_As发送方发送方硬件确认超时每提交一帧（SF/FF/CF）给 CAN 控制器后收到 CAN 硬件发送完成中断（ACK）发送方传输中止，向上层报错
N_Ar接收方接收方硬件确认超时每提交一帧（FC）给 CAN 控制器后收到 CAN 硬件发送完成中断（ACK）接收方终止接收，向上层报错
N_Bs发送方流控等待超时发出 FF 后；每发完一个 BS 块后收到 CTS/OVFLW 时停止；收到 WAIT 时重启继续等待。终止多帧传输，向上层报错，状态回 IDLE
N_Cr接收方连续帧等待超时发出 FC 后（等待第一个 CF）；每收到一个有效 CF 后重置收到满足 FF_DL 的最后一个 CF丢弃已重组数据，状态回 IDLE，等待下一次 FF
  • N_Ar / N_As

两个都是记录底层硬件发送行为的计时器。区别在于 N_Ar 是接收方等硬件，N_As 是发送方等硬件。

比如对于 N_As ：“我发了，但是这帧有没有从总线上真正发出去？”不得而知，只有等硬件确认。

对于 N_Ar：“我回了 FC，但是有没有真正发出去？” 等硬件确认。

在我的实现中，这两个定时器我统一合并为了一个 N_As，并在 CAN 发送完成中断中进行状态推动。

  • N_Cr / N_Bs

这两个是记录软件层行为的计时器。

对于 N_Cr ：这是接收方等待 CF 的定时器——“对方软件到底什么时候给我发下一个 CF？”

对于 N_Bs：这是发送方等待接收方发来的 FC 的定时器——“对方软件到底什么时候回我 FC？”

这些定时器交织起来共同组成了一个超时网络，确保协议栈在通信的每一步都不会卡死，能够超时回退。

至此，iso-tp 的核心流程已经完结，从4个PDU到寻址模式，再到协议栈定时器与运行状态机。后续若有关于 iso-tp 的其它内容，将作为拓展单独篇幅叙述。

]]> https://r6blog.online/2026/09/09/%E5%B5%8C%E5%85%A5%E5%BC%8F2026090901/ 2026-09-09T00:41:37.000Z 在上篇中（ISO-TP 通信流程(上)）我们详细介绍了 iso-tp 中的基础通信数据元（PDU）以]]> ISO-TP 通信流程(下) 2026-10-08T07:15:10.243Z R6bandito 什么是 CCMRAM？

以 STM32F407 为例，平时我们在使用的时候总会听到 128Kb SRAM 以及 192Kb SRAM 的相关型号，

这里，不管是192还是128，其实代表的都是同一个型号。从192Kb的视角来看，其表征的是芯片内部物理上真实存在的全部 SRAM 总容量，其中可拆分为 (128Kb + 64Kb)。

  • 主SRAM(128Kb)

这128Kb的主SRAM是常规内存，可以被DMA以及我们CPU进行访问。其中，128可进一步拆分为(112Kb SRAM1 + 16Kb SRAM2)。此处对于 SRAM1/SRAM2 不详细展开。

  • CCM SRAM(内核耦合内存)

内核耦合内存是一块特殊的SRAM，其地址空间被映射在 Code 区的 0x1000 0000（关于 ARM Cortex-M的地址空间布局，详见：ARM Cortex-M4 地址空间布局）。这块内存最大的特点就是并没有被挂在AHB总线矩阵上，而是直接连接 Cortex 内核的 D-Code 总线。

上图是总线矩阵架构图，从图中可以看出：SRAM1/SRAM2 作为通用内存，DMA与CPU均能够访问，而CCM RAM直连 D-Code ，这也就意味着 只有CPU能够访问这块内存，DMA够不到这个地方！这是CCM RAM与 普通 RAM 的最大区别所在。

CCM 挂在 CPU 私有总线上，AHB 总线矩阵里根本没有它的地址。DMA 控制器作为 AHB 主设备，物理上完全看不到 0x1000 0000 这片区域。如果你把 DMA 的目标缓冲区（比如 ADC 采样数组）定义在 CCM 里，DMA 搬运时总线会直接返回一个错误响应，触发 HardFault。

总的来说：这一块内存最适合放那种 CPU频繁读写，但是却不需要 DMA 参与的数据。

CCMRAM 的使用

在默认内存布局的情况下，CCMRAM是不启用的。也就是说你定义的所有的数据结构均存放到了主 SRAM 中。在这里我们以 Keil 为例，讲讲CCMRAM的使用。

  • 要使用 CCMRAM，首先需要在 Keil 的分散加载文件夹中加入 CCMRAM 区域。打开 Keil 的.sct 分散加载文件，向其中加入以下字段：

    1
    2
    3
    RW_CCMRAM 0x10000000 0x00010000 {
     *(.ccmram)
    }

    加入后，整个 .sct 如下

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    ; *************************************************************
    ; *** Scatter-Loading Description File generated by uVision ***
    ; *************************************************************

    LR_IROM1 0x08000000 0x00100000  {    ; load region size_region
      ER_IROM1 0x08000000 0x00100000  {  ; load address = execution address
       *.o (RESET, +First)
       *(InRoot$$Sections)
       .ANY (+RO)
       .ANY (+XO)
      }
      RW_IRAM1 0x20000000 0x00020000  {  ; RW data
       .ANY (+RW +ZI)
      }
      RW_CCMRAM 0x10000000 0x00010000 {
       *(.ccmram)
      }
    }

    这里的含义就是：我们手动新定义了一块内存区域，其起始地址为0x10000000，大小为0x00010000（64Kb）。所有定义在 .ccmram 段的数据结构都将会被放到此内存区域中。

    这里要注意，RW_IRAM1 是 .ANY 属性的，如果定义了全局数据结构但是未显示指定段属性，都将被该区域捕获，即放入主 SRAM 中而不是 CCMRAM。

  • 设置好分散加载文件后，定义变量时，为其声明变量属性即可。

    1
    2
    3
    4
    5
    // 放普通变量.
    __attribute__((section(".ccmram"))) uint32_t my_buffer[1024];

    // 放结构体.
    __attribute__((section(".ccmram"))) MyStruct_t my_config;

    这里要声明一点：__attribute__((section(".ccmram"))) 不能够用于修饰函数。你比如以下的行为是绝对错误的。

    1
    __attribute__((section(".ccmram"))) void fast_isr(void) { ... }

    我们前面已经说过，CCMRAM 只连接到了 D-Code 总线，并未连接 I-Code 总线，而 CPU 取指执行是通过 I-Code 进行的。

    当 CPU 执行 BL 跳转指令试图跳转到 0x1000 0000时：

    1. CPU 内核会向 I-Code 总线发出取指请求。
    2. 总线矩阵发现根本找不到 0x1000 0000 这个地址。
    3. CPU 取回的指令错误，执行后触发 Hardfault。

你比如:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
__attribute__((section(".ccmram"))) void functionB( void );

int 
main( void )
{
    // ...
    
    functionB();
    while(1)
    {
        // ...
    }
}

void 
functionB( void )
{
    printf( "CCMRAM Run the Code!\n" );
}

上述程序执行到 functionB 后，触发 I-Code 取指将立即触发 BusFault ，若 BusFault 未使能则直接上升至 HardFault。

注:

CCM 里面可以放入常量，虽然没接入 I-Code，但是可以通过 D-Code总线进行读取访问。语法上没问题，但会占用宝贵的 CCM 空间，且没有性能提升（Flash取指已经很快）。

]]> https://r6blog.online/2026/09/07/%E5%B5%8C%E5%85%A5%E5%BC%8F2026090701/ 2026-09-07T07:57:14.000Z 什么是 CCMRAM？

以 STM32F407 为例，平时我们在使用的时候总会听到 128K]]>

STM32F4 CCM_RAM(内核耦合内存) 2026-10-08T07:15:10.243Z R6bandito Cortex-M4 地址空间布局

ARM-Cortex M系列的MCU是32位的，因此理论寻址空间也是32位的，达到了4GB（0x0000 0000 ~ 0xFFFF FFFF）。ARM 把这 4GB 按照功能划分成了 5 个固定的分区，不管是哪一家的设备，只要是 Cortex-M 架构，就必须遵从这个设计。然后各自芯片厂商再在此架构下，填充自身的具体设备。

这里以 Cortex-M4 为例，以下是 Cortex-M4 的 DataSheet 地址空间布局概览图：

代码区(Code)

先来看 0x0000 0000 ~ 0x1FFFF FFFF 部分

这里主要是代码区(Code)，也是 Flash 与 ROM的映射区，CPU 通过 I-Code/D-Code 总线取指与读常量。

这里首先要注意一下，CPU复位后，强制从0x0000 0000这个位置取向量，但是 0x0000 0000 这个地址只是一个映射地址，并不是一个有效的物理地址。至于 0x0000 0000映射到哪里，取决于你的BOOT0与BOOT1引脚的配置。

  • BOOT0 = 0：映射到 Flash（0x0800 0000）（正常启动流程）。
  • BOOT0 = 1, BOOT1 = 0：映射到 System Memory（0x1FFF_0000）（出厂固化的一个 Bootloader，也就是我们有时候会用到的串口烧录）。
  • BOOT0 = 1, BOOT1 = 1：映射到SRAM（0x2000_0000）（从 SRAM 启动）。

正是有了这种映射行为，我们才可以通过调整 BOOT 引脚来进入不同的程序模式。

由于我们使用的是 Cortex-M4 系列，因此有一个 CCM SRAM也被放到了 Code 区的内部。不过该段 RAM 只连接到了 D-Code 总线，因此可以供CPU快速取数据，但是不能将你的代码放入进去让CPU去取指执行，因为没有连接到 I-Code 总线。

选项字节(Option Bytes)也被放置到了该区域的 (0x1FFF C000)区域，这里了解就好。

其余部分 Reserved 保留。

SRAM区

SRAM区映射在 0x2000 0000 ~ 0x2002 0000（ 128Kb ）。这里是我们的片上 SRAM ，如果你用调试器监控过全局数据的话，会注意到其地址都是 0x200x xxxx 开头的，正是因为我们SRAM被映射到了这一块地址。我们的 .data、.bss、Heap、Stack 都被划分到了这一块空间中。

这里可以看到，我们的128 Kb SRAM 的来源并不是一整块大的空间，而是物理上焊了两块独立的 SRAM，并且把他们挂到了 AHB 总线的不同端口上。虽然逻辑上看起来是连续的，但是实际上是两块独立的物理设备。

这么做是为了提高访问效率，如果合并为一块用一个端口，那么当 DMA 和 CPU 均需要访问这块空间时，必须得有一个停下来等另一个操作完毕。而如果划分为独立的两块挂在不同的端口上，则二者可以走不同的通道，实现真正的并行访问。

在优化时，可以将需要 DMA 搬运的大容量数据放在SRAM 112Kb中，将需要CPU访问读取的数据放在 SRAM 16 Kb中，可以避免 CPU 访问和 DMA 搬数据时互相堵塞，有效提升运行效率。

其余部分 Reserved 保留。

外设区(Peripherals)

外设区就是用来映射外设寄存器地址的。我们常用的 GPIO、UART、CAN、SPI、DMA 等外设及其寄存器地址都映射在这块区域内。

从上面总概览图已经可以看出，APB1 APB2 AHB 这些总线依次映射在该块区域。

同一条总线上的外设，地址是按顺序连续分配的。比如 APB1 的 TIM2 基址是 0x4000_0000（起始），TIM3 是 0x4000_0400，TIM4 是 0x4000_0800……每个外设占 0x400（1KB）空间，里面存放该外设的所有寄存器。

这里只是展示地址布局，不展开讨论。

外部存储区(FSMC)

外部存储区是 Cortex-M 地址空间中的一块特定区域（0x6000_0000 ~ 0x9FFF_FFFF），由 FSMC 管理。它负责将外部的 SRAM、NOR Flash、NAND Flash 或 LCD 等并行设备，映射到 CPU 的地址空间，使 CPU 可以像访问内部 SRAM 一样，通过简单的指针读写来访问外部设备。

我们以 FSMC 驱动 8080 并口的LCD作为例子：
当你向 0x6000_0000 + 偏移量 写入一个 16 位数据时，FSMC 硬件会自动完成一些时序动作，比如：片选信号或数据电平，或者锁存寄存器等操作。这里我们不展开讨论，只需要知道这块区域的用途即可。

内核外设区(Internal Peripherals)

虽然此处字面翻译为这个，但是还是建议理解为系统私有寄存器映射区。这里是系统的控制空间，你比如我们常用的 NVIC，Systick，VTOR 以及一些调试组件等等，这些的配置全部映射在了这个区域中。

这里需要注意的是：这段空间是由 ARM 划定的固定地盘，也就是不管是哪一家的芯片(GD32/NXP等等)，只要是 ARM Cortex-M 的架构，这块区域都是一样的。在进行一些跨平台的芯片移植时，只要双方都是 Cortex-M，那么与这个地址部分相关的一些底层外设的程序是无需修改的。

]]> https://r6blog.online/2026/09/06/%E5%B5%8C%E5%85%A5%E5%BC%8F2026090602/ 2026-09-06T06:38:48.000Z Cortex-M4 地址空间布局

ARM-Cortex M系列]]>

ARM Cortex-M4 地址空间划分 2026-10-08T07:15:10.243Z R6bandito Flash布局

Cortex-M 架构中，Flash 主要可以细分为图上几类。文本段(.text)中包含可执行代码 (Executable Code)和常量 ，在文本段之后就是只读数据区域 (.rodata)，只读数据后紧跟着的就是全局数据(.data)。

被显式初始化的全局数据结构的初始化值就存放于 .data 处，每次上电 __main 都会从该区域将初始化值拷贝到 RAM 中对应的位置，进而全局数据结构可以在一进入用户程序流程就已经被显式赋值。

这里要强调一点就是：并不是所有MCU都是这么布局的，这里只针对 Cortex-M 架构。

  • 为什么中断向量表始终放在最低地址？

这是因为MCU复位后，固定会去 0x0000 0000 寻址 MSP 和 Reset Handler 进行启动流程，因此它第一眼必须看到向量表。在这里，0x0000 0000并不是真实的物理地址，而是经过 CPU 映射后的地址。

硬件复位时，CPU 自动将 Flash的首地址映射到 0x0000_0000。而后强制从 0x0000_0000 取四字节作为 MSP，再取四字节作为 Reset Handler。

  • .data 段的双重身份

在 Flash 中，.data 叫作 LMA (加载地址)。

在 RAM 中，.data 叫作 VMA（运行地址）。

很直白，每次都从 Flash 中加载到 RAM中，记住这一点就好。

RAM 布局

RAM中 .data 段是存放有初始化值的全局数据结构的具体内存位置，在 Flash 中 .data 段存放具体的初始化数值。上电后由启动脚本进行搬运，上述 Flash 处已经叙述得足够详细，此处不再赘述。

.bss 紧随 .data 之后，也是一段连续的内存空间，其主要存放未显式初始化初始化为0的全局数据或静态数据结构。上电流程中，__main 会将该区域清0。

Heap 是堆区，可由启动文件修改其大小。本质就是一块静态巨型数组，采用C标准的动态内存管理算法(malloc/calloc/free等)进行管理。由于会产生内存碎片，且分配时间不确定，不可重入等特性，因此该区域实际上会被修改得很小，基本用不上。

这里要重点关注的是栈(Stack)：

Cortex-M 的栈是满递减栈（Full Descending），也就是栈指针初始时在最高地址，每压入一个数据，SP 就减小，向低地址走。把栈放在最高地址，能让它向下生长时拥有最大的可用空间，避免一开始就撞到 .bss。

这种“两头往中间挤”的设计，最大限度地利用了 RAM 空间，但也带来了溢出碰撞的风险。

关于栈溢出：

由于栈的生长方向向下，因此我们假设栈一直往下生长（例如开辟了一个局部超级大数据结构），在实际布局中，空闲区剩不了多少，Heap也很小。此时 SP 会跨过空闲区直接击穿 Heap ，现象自然就是堆区数据结构被破坏，malloc/free 失败。而后侵入 .bss 所在位置，将全局数据进行篡改。

这也是为什么不允许在栈局部开辟大型结构的根本原因。

]]> https://r6blog.online/2026/09/06/%E5%B5%8C%E5%85%A5%E5%BC%8F2026090601/ 2026-09-06T01:11:27.000Z Flash布局 全局数据结构/静态局部数据结构/普通局部数据结构分别存储在程序的哪些段中？

在进行区分之前，我们先来看看在嵌入式C语言程序中都有哪些核心的内存段划分：

段名存放内容物理属性典型例子
.text代码段：所有可执行指令、函数体。Flash（只读）if、while、函数调用等等。
.rodata只读数据段：常量、字符串字面量。Flash（只读）const char *p = "Hello"; 中的字符串 "Hello"。
.data已初始化读写数据：全局/静态变量，且有非零初值。Flash存初值，启动时拷贝到RAMint a = 5; 中的 5 存在Flash，变量 a 在RAM。
.bss零初始化数据：全局/静态变量，无初值或初值为0。RAM（无Flash占用）int b; 或 static int c = 0;。启动时由 __main 循环清零。
Stack栈（由编译器管理）：局部变量、函数调用现场（返回地址、寄存器）。RAMuint8_t temp;（定义在函数内部的）。
Heap堆（由用户管理）：动态分配的内存。RAMmalloc(size) 申请的空间。注意：如果工程没用到标准 malloc，这个段通常很小甚至为0。
  • 对于全局数据结构：这里要考虑是否初始化为0。看下面的例子：
1
2
3
uint8_t g_verA;
uint8_t g_verB = 50;
static uint16_t g_init = 100;

三个变量均开辟在全局数据区，g_verA 默认初始化为0，g_verB 和 g_init 都进行了对应的初始化。对于 g_verA，由于没有进行显示初始化，因此被放在了 .bss 段，上电后由 __main 进行清零操作，并且在 Flash 中零占用；

g_verB 和 g_init 进行了显式初始化，因此被放入 .data 段中（这里要注意：被放入.data中的只是变量本身，初始化数据是被放入了 flash 中的）。系统上电后，__main 会将 flash 中的对应初始化数据拷贝到 .data 中对应的位置。这也是为什么我们的全局变量能够一进入程序就已经被赋予一个初始化值的原因。

  • 对于普通局部数据结构：是统一放在函数调用栈中的。
1
2
3
4
5
6
void 
funcA( void )
{
struct test myTestStructure;
    // ....
}

myTestStructure 这个结构我们是在函数局部空间进行定义的，因此其被压栈存入到函数栈中。只在当前的作用域有效，一旦函数运行周期结束出栈返回，这个变量的内存空间也随即跟着被销毁了。

由于栈大小是固定且通常比较小，因此不要在局部定义大型数据结构（例如大数组或大型结构体），注意堤防栈溢出。

  • 静态局部数据结构：前面我们说过，static 修饰局部数据结构时不改变其作用域，只规定其生命周期。
1
2
3
4
5
6
void 
funcA( void )
{
static struct test myTestStructure;
    // ....
}

此处，myTestStructure 虽然定义语句在局部，但是由于 static 的修饰，其真正的内存空间位置是被放在了 .bss 段(未显式进行初始化，因此默认初始化为0)。当程序流程进入 funcA 时，不会压栈 myTestStructure，而是从 RAM 中直接读出该变量，操作完毕后 funcA 返回，myTestStructure 依然有效。

这里要强调一点：.bss 和 .data 段一大区别就是是否在 flash 中有占用。.data段的数据在上电时需要来自 flash 中的初始化值，而 .bss 不需要，因此 .data 在 Flash 中和 RAM 中是双份空间占用！

堆和栈的主要区别

对比维度栈（Stack）堆（Heap）
管理方式自动管理。编译器自动插入入栈/出栈指令，用户不需要也不应该插手。手动管理。用户必须显式调用 malloc/calloc 申请，用完必须 free。
分配速度极快。仅涉及栈指针的移动。较慢。内部涉及搜索算法，需要遍历空闲链表寻找合适大小的内存块。
生命周期临时。函数执行完，里面的局部数据结构立即被销毁。长期。只要你不主动 free，内存一直有效（哪怕函数已经退出）。漏 free 就会造成内存泄漏。
内存碎片无碎片。后进先出（LIFO）机制。有碎片。多次申请释放会留下许多细小的空洞，无法被进一步使用（外部碎片）。
大小限制通常很小，由编译器或链接脚本固定。较大。

这里讲讲标准C和嵌入式C中的关于堆栈相关的一些差异：

  • 堆内存的来源不一样

标准C语言中堆由操作系统通过 brk/sbrk 系统调用动态扩充，堆区（.heap）位于链接器预留的虚拟地址空间，且在程序运行过程中可以向 OS 申请扩大。

但在嵌入式环境下，标准C没有所谓的操作系统层调用。其操作的本质是一块预先在编译期就定义好的巨型静态数组，形如 static uint8_t ucHeap[20 * 1024]; 这个数组被放在 .bss 或 .data 段，所以堆的大小在编译时就彻底固定了，无法动态扩充。

现在很多中间件你比如 FreeRTOS / lwIP 等等，内部都会实现自身的动态内存管理算法而不是直接使用标准C的实现。这些管理算法实现的本质其实也是在一块巨型静态数组上进行切割分配和回收。

  • 栈溢出后果不同

标准C栈通常很大（几 MB），且如果栈溢出，操作系统可能会分配新的内存页或触发段错误，程序会崩溃但是容易排查。

但是在嵌入式中，栈空间很小(通常1~4Kb)，栈溢出后会静默踩到相邻的全局数据结构或另一个任务栈，导致程序运行出现 HardFault 。比较难以排查。

  • 使用标准与安全性

嵌入式中， 标准 malloc 实现是不可重入的，不应该在多线程环境中使用。裸机环境下若不得不使用，应保证不在 ISR 中使用。因为 malloc 内部涉及搜索算法，其分配时间是不确定的，而 ISR 要求尽快返回。

同时，不管在任何环境，若必须使用malloc 请一定使用临界区/或互斥量等手段进行保护。因为不可重入性，若在分配过程中被打断并在别处再次调用 malloc 就很可能会造成整个堆管理结构直接损坏。

标准C的堆实现在实际运用中，基本不会被使用到。需要动态内存分配时，应优先考虑适用于嵌入式环境的三方内存分配算法。

]]> https://r6blog.online/2026/09/05/%E5%B5%8C%E5%85%A5%E5%BC%8F2026090501/ 2026-09-05T01:26:44.000Z