Gitlib

温故知新·内存管理单元MMU

发表于 2021-02-02 | 分类于计算机基础

MMU是Memory Management Unit的缩写，中文名是内存管理单元。它是一种负责处理中央处理器（CPU）的内存访问请求的计算机硬件。它的功能包括虚拟地址到物理地址的转换（即虚拟内存管理）、内存保护、中央处理器高速缓存的控制等。

总结：MMU是CPU芯片中的一个硬件模块，负责虚拟内存地址管理、内存保护等功能。

下面我们了解一下MMU中虚拟内存地址（VA)、物理内存地址（PA)和内存保护机制。

虚拟内存

现代操作系统普遍采用虚拟内存管理（Virtual Memory Management）机制，如果处理器没有MMU，或者有MMU但没有启用，CPU执行单元发出的内存地址将直接传到芯片引脚上，被内存芯片（以下称为物理内存，以便与虚拟内存区分）接收，这称为物理地址（Physical Address，以下简称PA），如下图所示。

如果处理器启用了MMU，CPU执行单元发出的内存地址将被MMU截获，从CPU到MMU的地址称为虚拟地址（Virtual Address，以下简称VA），而MMU将这个地址翻译成另一个地址发到CPU芯片的外部地址引脚上，也就是将VA映射成PA，如下图所示。

MMU将VA映射到PA是以页（Page）为单位的，32位处理器的页尺寸通常是4KB。例如，MMU可以通过一个映射项将VA的一页0xb7001000~0xb7001fff映射到PA的一页0x2000~0x2fff，如果CPU执行单元要访问虚拟地址0xb7001008，则实际访问到的物理地址是0x2008。

物理内存中的页称为物理页面或者页帧（Page Frame）。

虚拟内存的哪个页面映射到物理内存的哪个页帧是通过页表（Page Table）来描述的，页表保存在物理内存中，MMU会查找页表来确定一个VA应该映射到什么PA。

操作系统和MMU是这样配合的：

操作系统在初始化或分配、释放内存时会执行一些指令在物理内存中填写页表，然后用指令设置MMU，告诉MMU页表在物理内存中的什么位置。
设置好之后，CPU每次执行访问内存的指令都会自动引发MMU做查表和地址转换操作，地址转换操作由硬件自动完成，不需要用指令控制MMU去做。

我们在程序中使用的变量和函数都有各自的地址，程序被编译后，这些地址就成了指令中的地址，指令中的地址被CPU解释执行，就成了CPU执行单元发出的内存地址，所以在启用MMU的情况下，程序中使用的地址都是虚拟地址，都会引发MMU做查表和地址转换操作。

内存保护

MMU除了做地址转换之外，还提供内存保护机制。

各种体系结构都有用户模式（User Mode）和特权模式（Privileged Mode）之分，操作系统可以在页表中设置每个内存页面的访问权限，有些页面不允许访问，有些页面只有在CPU处于特权模式时才允许访问，有些页面在用户模式和特权模式都可以访问，访问权限又分为可读、可写和可执行三种。

这样设定好之后，当CPU要访问一个VA时，MMU会检查CPU当前处于用户模式还是特权模式，访问内存的目的是读数据、写数据还是取指令，如果和操作系统设定的页面权限相符，就允许访问，把它转换成PA，否则不允许访问，产生一个异常（Exception）。

通常操作系统把虚拟地址空间划分为用户空间和内核空间，例如x86平台的Linux系统虚拟地址空间是0x00000000~0xffffffff，前3GB（0x00000000~0xbfffffff）是用户空间，后1GB（0xc0000000~0xffffffff）是内核空间。

用户程序加载到用户空间，在用户模式下执行，不能访问内核中的数据，也不能跳转到内核代码中执行。这样可以保护内核，如果一个进程访问了非法地址，顶多这一个进程崩溃，而不会影响到内核和整个系统的稳定性。

温故知新·汇编语言

发表于 2021-02-01 | 分类于计算机基础

学习编程其实就是学高级语言，即那些为人类设计的计算机语言。但是，计算机不理解高级语言，必须通过编译器转成二进制代码，才能运行。学会高级语言，并不等于理解计算机实际的运行步骤。

计算机真正能够理解的是低级语言，它专门用来控制硬件。汇编语言就是低级语言，直接描述/控制 CPU 的运行。如果你想了解 CPU 到底干了些什么，以及代码的运行步骤，就一定要学习汇编语言。汇编语言不容易学习，就连简明扼要的介绍都很难找到。下面我尝试写一篇最好懂的汇编语言教程，解释 CPU 如何执行代码。

汇编语言是什么？

我们知道，CPU 只负责计算，本身不具备智能。你输入一条指令（instruction），它就运行一次，然后停下来，等待下一条指令。这些指令都是二进制的，称为操作码（opcode），比如加法指令就是00000011。编译器的作用，就是将高级语言写好的程序，翻译成一条条操作码。对于人类来说，二进制程序是不可读的，根本看不出来机器干了什么。为了解决可读性的问题，以及偶尔的编辑需求，就诞生了汇编语言。

汇编语言是二进制指令的文本形式，与指令是一一对应的关系。比如，加法指令00000011写成汇编语言就是 ADD。只要还原成二进制，汇编语言就可以被 CPU 直接执行，所以它是最底层的低级语言。

来历

最早的时候，编写程序就是手写二进制指令，然后通过各种开关输入计算机，比如要做加法了，就按一下加法开关。后来，发明了纸带打孔机，通过在纸带上打孔，将二进制指令自动输入计算机。为了解决二进制指令的可读性问题，工程师将那些指令写成了八进制。二进制转八进制是轻而易举的，但是八进制的可读性也不行。很自然地，最后还是用文字表达，加法指令写成 ADD。内存地址也不再直接引用，而是用标签表示。

这样的话，就多出一个步骤，要把这些文字指令翻译成二进制，这个步骤就称为 assembling，完成这个步骤的程序就叫做 assembler。它处理的文本，自然就叫做 aseembly code。标准化以后，称为 assembly language，缩写为 asm，中文译为汇编语言。

每一种 CPU 的机器指令都是不一样的，因此对应的汇编语言也不一样。本文介绍的是目前最常见的 x86 汇编语言，即 Intel 公司的 CPU 使用的那一种。

寄存器

学习汇编语言，首先必须了解两个知识点：寄存器和内存模型。先来看寄存器。CPU 本身只负责运算，不负责储存数据。数据一般都储存在内存之中，CPU 要用的时候就去内存读写数据。但是，CPU 的运算速度远高于内存的读写速度，为了避免被拖慢，CPU 都自带一级缓存和二级缓存。基本上，CPU 缓存可以看作是读写速度较快的内存。 但是，CPU 缓存还是不够快，另外数据在缓存里面的地址是不固定的，CPU 每次读写都要寻址也会拖慢速度。因此，除了缓存之外，CPU 还自带了寄存器（register），用来储存最常用的数据。也就是说，那些最频繁读写的数据（比如循环变量），都会放在寄存器里面，CPU 优先读写寄存器，再由寄存器跟内存交换数据。

寄存器不依靠地址区分数据，而依靠名称。每一个寄存器都有自己的名称，我们告诉 CPU 去具体的哪一个寄存器拿数据，这样的速度是最快的。有人比喻寄存器是 CPU 的零级缓存。

寄存器的种类

早期的 x86 CPU 只有8个寄存器，而且每个都有不同的用途。现在的寄存器已经有100多个了，都变成通用寄存器，不特别指定用途了，但是早期寄存器的名字都被保存了下来。

EAX: 累加寄存器，相对于其他寄存器，在运算方面比较常用
EBX: 基地址寄存器，作为内存偏移指针使用
ECX: 计数器，用于特定的技术
EDX: 作为EAX的溢出寄存器（除法产生的余数）
EDI
ESI
EBP: 基址指针，指栈的栈底指针
ESP: 指针的寄存器，用于堆栈操作。被形象地称为栈顶指针，堆栈的顶部是地址小的区域，压入堆栈的数据越多，ESP也就越来越小。在32位平台上，ESP每次减少4字节。

上面这8个寄存器之中，前面七个都是通用的。ESP 寄存器有特定用途，保存当前 Stack 的地址。

我们常常看到 32位 CPU、64位 CPU 这样的名称，其实指的就是寄存器的大小。32 位 CPU 的寄存器大小就是4个字节。

内存模型：Heap

寄存器只能存放很少量的数据，大多数时候，CPU 要指挥寄存器，直接跟内存交换数据。所以，除了寄存器，还必须了解内存怎么储存数据。程序运行的时候，操作系统会给它分配一段内存，用来储存程序和运行产生的数据。这段内存有起始地址和结束地址，比如从0x1000到0x8000，起始地址是较小的那个地址，结束地址是较大的那个地址。

程序运行过程中，对于动态的内存占用请求（比如新建对象，或者使用malloc命令），系统就会从预先分配好的那段内存之中，划出一部分给用户，具体规则是从起始地址开始划分（实际上，起始地址会有一段静态数据，这里忽略）。举例来说，用户要求得到10个字节内存，那么从起始地址0x1000开始给他分配，一直分配到地址0x100A，如果再要求得到22个字节，那么就分配到0x1020。

这种因为用户主动请求而划分出来的内存区域，叫做 Heap（堆）。它由起始地址开始，从低位（地址）向高位（地址）增长。Heap 的一个重要特点就是不会自动消失，必须手动释放，或者由垃圾回收机制来回收。

内存模型：Stack

除了 Heap 以外，其他的内存占用叫做 Stack（栈）。简单说，Stack 是由于函数运行而临时占用的内存区域。

请看下面的例子。

int main() {
   int a = 2;
   int b = 3;
}

上面代码中，系统开始执行main函数时，会为它在内存里面建立一个帧（frame），所有main的内部变量（比如a和b）都保存在这个帧里面。main函数执行结束后，该帧就会被回收，释放所有的内部变量，不再占用空间。

如果函数内部调用了其他函数，会发生什么情况？

int main() {
   int a = 2;
   int b = 3;
   return add_a_and_b(a, b);
}

上面代码中，main函数内部调用了add_a_and_b函数。执行到这一行的时候，系统也会为add_a_and_b新建一个帧，用来储存它的内部变量。也就是说，此时同时存在两个帧：main和add_a_and_b。一般来说，调用栈有多少层，就有多少帧。

等到add_a_and_b运行结束，它的帧就会被回收，系统会回到函数main刚才中断执行的地方，继续往下执行。通过这种机制，就实现了函数的层层调用，并且每一层都能使用自己的本地变量。

所有的帧都存放在 Stack，由于帧是一层层叠加的，所以 Stack 叫做栈。生成新的帧，叫做”入栈”，英文是 push；栈的回收叫做”出栈”，英文是 pop。Stack 的特点就是，最晚入栈的帧最早出栈（因为最内层的函数调用，最先结束运行），这就叫做”后进先出“的数据结构。每一次函数执行结束，就自动释放一个帧，所有函数执行结束，整个 Stack 就都释放了。

Stack 是由内存区域的结束地址开始，从高位（地址）向低位（地址）分配。比如，内存区域的结束地址是0x8000，第一帧假定是16字节，那么下一次分配的地址就会从0x7FF0开始；第二帧假定需要64字节，那么地址就会移动到0x7FB0。

CPU指令

了解寄存器和内存模型以后，就可以来看汇编语言到底是什么了。下面是一个简单的程序hello.c。

int add_a_and_b(int a, int b) {
   return a + b;
}

int main() {
   return add_a_and_b(2, 3);
}

gcc 将这个程序转成汇编语言。

1	gcc -S hello.c

上面的命令执行以后，会生成一个文本文件hello.s，里面就是汇编语言，包含了几十行指令。这么说吧，一个高级语言的简单操作，底层可能由几个，甚至几十个 CPU 指令构成。CPU 依次执行这些指令，完成这一步操作。

hello.s经过简化以后，大概是下面的样子。

_add_a_and_b:
   push   %ebx
   mov    %eax, [%esp+8] 
   mov    %ebx, [%esp+12]
   add    %eax, %ebx 
   pop    %ebx 
   ret  

_main:
   push   3
   push   2
   call   _add_a_and_b 
   add    %esp, 8
   ret

可以看到，原程序的两个函数add_a_and_b和main，对应两个标签_add_a_and_b和_main。每个标签里面是该函数所转成的 CPU 运行流程。

每一行就是 CPU 执行的一次操作。它又分成两部分，就以其中一行为例。

push   %ebx

这一行里面，push是 CPU 指令，%ebx是该指令要用到的运算子。一个 CPU 指令可以有零个到多个运算子。下面我就一行一行讲解这个汇编程序，建议读者最好把这个程序，在另一个窗口拷贝一份，省得阅读的时候再把页面滚动上来。

push指令

根据约定，程序从_main标签开始执行，这时会在 Stack 上为main建立一个帧，并将 Stack 所指向的地址，写入 ESP 寄存器。后面如果有数据要写入main这个帧，就会写在 ESP 寄存器所保存的地址。

然后，开始执行第一行代码。

push   3

push指令用于将运算子放入 Stack，这里就是将3写入main这个帧。

虽然看上去很简单，push指令其实有一个前置操作。它会先取出 ESP 寄存器里面的地址，将其减去4个字节，然后将新地址写入 ESP 寄存器。使用减法是因为 Stack 从高位向低位发展，4个字节则是因为3的类型是int，占用4个字节。得到新地址以后， 3 就会写入这个地址开始的四个字节。

push 2

第二行也是一样，push指令将2写入main这个帧，位置紧贴着前面写入的3。这时，ESP 寄存器会再减去 4个字节（累计减去8）。

call 指令

第三行的call指令用来调用函数。

1	call _add_a_and_b

上面的代码表示调用add_a_and_b函数。这时，程序就会去找_add_a_and_b标签，并为该函数建立一个新的帧。

下面就开始执行_add_a_and_b的代码。

push   %ebx

这一行表示将 EBX 寄存器里面的值，写入_add_a_and_b这个帧。这是因为后面要用到这个寄存器，就先把里面的值取出来，用完后再写回去。

mov 指令

mov指令用于将一个值写入某个寄存器。

1	mov %eax, [%esp+8]

这一行代码表示，先将 ESP 寄存器里面的地址加上8个字节，得到一个新的地址，然后按照这个地址在 Stack 取出数据。根据前面的步骤，可以推算出这里取出的是2，再将2写入 EAX 寄存器。

下一行代码也是干同样的事情。

1	mov %ebx, [%esp+12]

上面的代码将 ESP 寄存器的值加12个字节，再按照这个地址在 Stack 取出数据，这次取出的是3，将其写入 EBX 寄存器。

add 指令

add指令用于将两个运算子相加，并将结果写入第一个运算子。

1	add %eax, %ebx

上面的代码将 EAX 寄存器的值（即2）加上 EBX 寄存器的值（即3），得到结果5，再将这个结果写入第一个运算子 EAX 寄存器。

pop 指令

pop指令用于取出 Stack 最近一个写入的值（即最低位地址的值），并将这个值写入运算子指定的位置。

pop    %ebx

上面的代码表示，取出 Stack 最近写入的值（即 EBX 寄存器的原始值），再将这个值写回 EBX 寄存器（因为加法已经做完了，EBX 寄存器用不到了）。

注意，pop指令还会将 ESP 寄存器里面的地址加4，即回收4个字节。

ret 指令

ret指令用于终止当前函数的执行，将运行权交还给上层函数。也就是，当前函数的帧将被回收。

ret

可以看到，该指令没有运算子。随着add_a_and_b函数终止执行，系统就回到刚才main函数中断的地方，继续往下执行。

1	add %esp, 8

上面的代码表示，将 ESP 寄存器里面的地址，手动加上8个字节，再写回 ESP 寄存器。这是因为 ESP 寄存器的是 Stack 的写入开始地址，前面的pop操作已经回收了4个字节，这里再回收8个字节，等于全部回收。

ret

最后，main函数运行结束，ret指令退出程序执行。

温故知新·CPU

发表于 2021-01-30 | 分类于计算机基础

CPU 的核心是从程序或应用程序获取指令并执行计算。此过程可以分为三个关键阶段：提取，解码和执行。CPU从系统的 RAM 中提取指令，然后解码该指令的实际内容，然后再由 CPU 的相关部分执行该指令。

CPU 的内部结构

说了这么多 CPU 的重要性，那么 CPU 的内部结构是什么呢？又是由什么组成的呢？下图展示了一般程序的运行流程（以 C 语言为例），可以说了解程序的运行流程是掌握程序运行机制的基础和前提。

在这个流程中，CPU 负责的就是解释和运行最终转换成机器语言的内容。

CPU 主要由两部分构成：控制单元 和 算术逻辑单元（ALU）

控制单元：从内存中提取指令并解码执行
算数逻辑单元（ALU）：处理算数和逻辑运算

CPU 是计算机的心脏和大脑，它和内存都是由许多晶体管组成的电子部件。它接收数据输入，执行指令并处理信息。它与输入/输出（I / O）设备进行通信，这些设备向 CPU 发送数据和从 CPU 接收数据。 从功能来看，CPU 的内部由寄存器、控制器、运算器和时钟**四部分组成，各部分之间通过电信号连通。

寄存器是中央处理器内的组成部分。它们可以用来暂存指令、数据和地址。可以将其看作是内存的一种。根据种类的不同，一个 CPU 内部会有 20 - 100个寄存器。
控制器负责把内存上的指令、数据读入寄存器，并根据指令的结果控制计算机
运算器负责运算从内存中读入寄存器的数据
时钟 负责发出 CPU 开始计时的时钟信号

CPU 是寄存器的集合体

在 CPU 的四个结构中，我们程序员只需要了解寄存器就可以了，其余三个不用过多关注，为什么这么说？因为程序是把寄存器作为对象来描述的。

说到寄存器，就不得不说到汇编语言，说到汇编语言，就不得不说到高级语言，说到高级语言就不得不牵扯出语言这个概念。

计算机语言

计算机是由二进制构成的，它只能听的懂二进制也就是机器语言，但是普通人是无法看懂机器语言的，这个时候就需要一种电脑既能识别，人又能理解的语言，最先出现的就是汇编语言。但是汇编语言晦涩难懂，所以又出现了像是 C，C++，Java 的这种高级语言。所以计算机语言一般分为两种：低级语言（机器语言，汇编语言）和高级语言。使用高级语言编写的程序，经过编译转换成机器语言后才能运行，而汇编语言经过汇编器才能转换为机器语言。

汇编语言能够帮助你理解计算机做了什么工作，机器语言级别的程序是通过寄存器来处理的，上面代码中的 eax,ebp 都是表示的寄存器，是 CPU 内部寄存器的名称，所以可以说 CPU 是一系列寄存器的集合体。在内存中的存储通过地址编号来表示，而寄存器的种类则通过名字来区分。

不同类型的 CPU ，其内部寄存器的种类，数量以及寄存器存储的数值范围都是不同的。不过，根据功能的不同，可以将寄存器划分为下面这几类 **

种类	功能
累加寄存器	存储运行的数据和运算后的数据。
标志寄存器	用于反应处理器的状态和运算结果的某些特征以及控制指令的执行。
程序计数器	程序计数器是用于存放下一条指令所在单元的地址的地方。
基址寄存器	存储数据内存的起始位置
变址寄存器	存储基址寄存器的相对地址
通用寄存器	存储任意数据
指令寄存器	储存正在被运行的指令，CPU内部使用，程序员无法对该寄存器进行读写
栈寄存器	存储栈区域的起始位置

其中程序计数器、累加寄存器、标志寄存器、指令寄存器和栈寄存器都只有一个，其他寄存器一般有多个

程序计数器（PC)

程序计数器(Program Counter)是用来存储下一条指令所在单元的地址。程序执行时，PC的初值为程序第一条指令的地址，在顺序执行程序时，控制器首先按程序计数器所指出的指令地址从内存中取出一条指令，然后分析和执行该指令，同时将PC的值加1指向下一条要执行的指令。我们还是以一个事例为准来详细的看一下程序计数器的执行过程

这是一段进行相加的操作，程序启动，在经过编译解析后会由操作系统把硬盘中的程序复制到内存中，示例中的程序是将 123 和 456 执行相加操作，并将结果输出到显示器上。由于使用机器语言难以描述，所以这是经过翻译后的结果，实际上每个指令和数据都可能分布在不同的地址上，但为了方便说明，把组成一条指令的内存和数据放在了一个内存地址上。地址 0100 是程序运行的起始位置。Windows 等操作系统把程序从硬盘复制到内存后，会将程序计数器作为设定为起始位置 0100，然后执行程序，每执行一条指令后，程序计数器的数值会增加1（或者直接指向下一条指令的地址），然后，CPU 就会根据程序计数器的数值，从内存中读取命令并执行，也就是说，程序计数器控制着程序的流程。

条件分支和循环机制

我们都学过高级语言，高级语言中的条件控制流程主要分为三种：顺序执行、条件分支、循环判断三种，顺序执行是按照地址的内容顺序的执行指令。条件分支是根据条件执行任意地址的指令。循环是重复执行同一地址的指令。

顺序执行的情况比较简单，每执行一条指令程序计数器的值就是 + 1。
条件和循环分支会使程序计数器的值指向任意的地址，这样一来，程序便可以返回到上一个地址来重复执行同一个指令，或者跳转到任意指令。

下面以条件分支为例来说明程序的执行过程（循环也很相似）

程序的开始过程和顺序流程是一样的，CPU 从0100处开始执行命令，在0100和0101都是顺序执行，PC 的值顺序+1，执行到0102地址的指令时，判断0106寄存器的数值大于0，跳转（jump）到0104地址的指令，将数值输出到显示器中，然后结束程序，0103 的指令被跳过了，这就和我们程序中的 if() 判断是一样的，在不满足条件的情况下，指令会直接跳过。所以 PC 的执行过程也就没有直接+1，而是下一条指令的地址。

标志寄存器

条件和循环分支会使用到 jump（跳转指令），会根据当前的指令来判断是否跳转，上面我们提到了标志寄存器，无论当前累加寄存器的运算结果是正数、负数还是零，标志寄存器都会将其保存（也负责溢出和奇偶校验）

溢出（overflow）：是指运算的结果超过了寄存器的长度范围奇偶校验（parity check）：是指检查运算结果的值是偶数还是奇数

CPU 在进行运算时，标志寄存器的数值会根据当前运算的结果自动设定，运算结果的正、负和零三种状态由标志寄存器的三个位表示。标志寄存器的第一个字节位、第二个字节位、第三个字节位各自的结果都为1时，分别代表着正数、零和负数。

CPU 的执行机制比较有意思，假设累加寄存器中存储的 XXX 和通用寄存器中存储的 YYY 做比较，执行比较的背后，CPU 的运算机制就会做减法运算。而无论减法运算的结果是正数、零还是负数，都会保存到标志寄存器中。结果为正表示 XXX 比 YYY 大，结果为零表示 XXX 和 YYY 相等，结果为负表示 XXX 比 YYY 小。程序比较的指令，实际上是在 CPU 内部做减法运算。

函数调用机制

接下来，我们继续介绍函数调用机制，哪怕是高级语言编写的程序，函数调用处理也是通过把程序计数器的值设定成函数的存储地址来实现的。函数执行跳转指令后，必须进行返回处理，单纯的指令跳转没有意义，下面是一个实现函数跳转的例子

图中将变量 a 和 b 分别赋值为 123 和 456 ，调用 MyFun(a,b) 方法，进行指令跳转。图中的地址是将 C 语言编译成机器语言后运行时的地址，由于1行 C 程序在编译后通常会变为多行机器语言，所以图中的地址是分散的。在执行完 MyFun(a,b)指令后，程序会返回到 MyFun(a,b) 的下一条指令，CPU 继续执行下面的指令。函数的调用和返回很重要的两个指令是 call 和 return 指令，再将函数的入口地址设定到程序计数器之前，call 指令会把调用函数后要执行的指令地址存储在名为栈的主存内。函数处理完毕后，再通过函数的出口来执行 return 指令。return 指令的功能是把保存在栈中的地址设定到程序计数器。MyFun 函数在被调用之前，0154 地址保存在栈中，MyFun 函数处理完成后，会把0154的地址保存在程序计数器中。这个调用过程如下

在一些高级语言的条件或者循环语句中，函数调用的处理会转换成 call 指令，函数结束后的处理则会转换成 return 指令。

通过地址和索引实现数组

接下来我们看一下基址寄存器和变址寄存器，通过这两个寄存器，我们可以对主存上的特定区域进行划分，来实现类似数组的操作，首先，我们用十六进制数将计算机内存上的 00000000 - FFFFFFFF 的地址划分出来。那么，凡是该范围的内存地址，只要有一个 32 位的寄存器，便可查看全部地址。但如果想要想数组那样分割特定的内存区域以达到连续查看的目的的话，使用两个寄存器会更加方便。例如，我们用两个寄存器（基址寄存器和变址寄存器）来表示内存的值

这种表示方式很类似数组的构造，数组是指同样长度的数据在内存中进行连续排列的数据构造。用数组名表示数组全部的值，通过索引来区分数组的各个数据元素，例如: a[0] - a[4]，[]内的 0 - 4 就是数组的下标。

CPU 指令执行过程

那么 CPU 是如何执行一条条的指令的呢？几乎所有的冯·诺伊曼型计算机的CPU，其工作都可以分为5个阶段：取指令、指令译码、执行指令、访存取数、结果写回。

取指令阶段是将内存中的指令读取到 CPU 中寄存器的过程，程序寄存器用于存储下一条指令所在的地址
指令译码阶段，在取指令完成后，立马进入指令译码阶段，在指令译码阶段，指令译码器按照预定的指令格式，对取回的指令进行拆分和解释，识别区分出不同的指令类别以及各种获取操作数的方法。
执行指令阶段，译码完成后，就需要执行这一条指令了，此阶段的任务是完成指令所规定的各种操作，具体实现指令的功能。
访问取数阶段，根据指令的需要，有可能需要从内存中提取数据，此阶段的任务是：根据指令地址码，得到操作数在主存中的地址，并从主存中读取该操作数用于运算。
结果写回阶段，作为最后一个阶段，结果写回（Write Back，WB）阶段把执行指令阶段的运行结果数据“写回”到某种存储形式：结果数据经常被写到CPU的内部寄存器中，以便被后续的指令快速地存取；

温故知新·寄存器

发表于 2021-01-29 | 分类于计算机基础

寄存器是 CPU 内部的构造，它主要用于信息的存储。除此之外，CPU 内部还有运算器，负责处理数据；控制器控制其他组件；外部总线连接 CPU 和各种部件，进行数据传输；内部总线负责 CPU 内部各种组件的数据处理。所有的CPU都拥有一定数量的寄存器作为存储单元。寄存器的读写速度非常快——比其他任何类型的存储器访问速度都快。

那为什么会出现寄存器？因为我们知道，程序在内存中装载，由 CPU 来运行，CPU 的主要职责就是用来处理数据。那么这个过程势必涉及到从存储器中读取和写入数据，因为它涉及通过控制总线发送数据请求并进入存储器存储单元，通过同一通道获取数据，这个过程非常的繁琐并且会涉及到大量的内存占用，而且有一些常用的内存页存在，其实是没有必要的，因此出现了寄存器，存储在 CPU 内部。

认识寄存器

认识寄存器之前，我们首先先来看一下 CPU 内部的构造。

CPU 从逻辑上可以分为 3 个模块，分别是控制单元、运算单元和存储单元，这三部分由 CPU 内部总线连接起来。几乎所有的冯·诺伊曼型计算机的 CPU，其工作都可以分为5个阶段：「取指令、指令译码、执行指令、访存取数、结果写回」。

取指令阶段是将内存中的指令读取到 CPU 中寄存器的过程，程序寄存器用于存储下一条指令所在的地址
指令译码阶段，在取指令完成后，立马进入指令译码阶段，在指令译码阶段，指令译码器按照预定的指令格式，对取回的指令进行拆分和解释，识别区分出不同的指令类别以及各种获取操作数的方法。
执行指令阶段，译码完成后，就需要执行这一条指令了，此阶段的任务是完成指令所规定的各种操作，具体实现指令的功能。
访问取数阶段，根据指令的需要，有可能需要从内存中提取数据，此阶段的任务是：根据指令地址码，得到操作数在主存中的地址，并从主存中读取该操作数用于运算。
结果写回阶段，作为最后一个阶段，结果写回（Write Back，WB）阶段把执行指令阶段的运行结果数据写回到 CPU 的内部寄存器中，以便被后续的指令快速地存取；

我们以 intel 8086 处理器为例，8086 处理器有 14 个寄存器，每个寄存器都有一个特有的名称，即**「AX，BX，CX，DX，SP，BP，SI，DI，IP，FLAG，CS，DS，SS，ES」。

这 14 个寄存器有可能进行具体的划分，按照功能可以分为三种

通用寄存器
段寄存器
索引寄存器
状态和控制寄存器

下面分别介绍一下这几种寄存器

通用寄存器

通用寄存器主要有四种，即「AX、BX、CX、DX」同样的，这四个寄存器也是 16 位的，能存放两个字节。AX、BX、CX、DX 这四个寄存器一般用来存放数据，也被称为 数据寄存器。它们的结构如下

AX(Accumulator Register) ：累加寄存器，保存算术和逻辑操作的结果。
BX(Base Register)：基址寄存器，用来存储基础访问地址
CX(Count Register)：计数寄存器，CX 寄存器在迭代的操作中会循环计数
DX(data Register)：数据寄存器，它也用于输入/输出操作。它还与 AX 寄存器以及 DX 一起使用，用于涉及大数值的乘法和除法运算。

这四种寄存器可以分为上半部分和下半部分，用作八个 8 位数据寄存器

「AX 寄存器可以分为两个独立的 8 位的 AH 和 AL 寄存器；」
「BX 寄存器可以分为两个独立的 8 位的 BH 和 BL 寄存器；」
「CX 寄存器可以分为两个独立的 8 位的 CH 和 CL 寄存器；」
「DX 寄存器可以分为两个独立的 8 位的 DH 和 DL 寄存器；」

除了上面 AX、BX、CX、DX 寄存器以外，其他寄存器均不可以分为两个独立的 8 位寄存器

如下图所示。

合起来就是

AX 的低位（0 - 7）位构成了 AL 寄存器，高 8 位（8 - 15）位构成了 AH 寄存器。AH 和 AL 寄存器是可以使用的 8 位寄存器，其他同理。

在认识了寄存器之后，我们通过一个示例来看一下数据的具体存储方式。

比如数据 19 ，它在 16 位存储器中所存储的表示如下

寄存器的存储方式是先存储低位，如果低位满足不了就存储高位，如果低位能够满足，高位用 0 补全，在其他低位能满足的情况下，其余位也用 0 补全。

AX 寄存器

我们上面探讨过，AX 的另外一个名字叫做累加寄存器或者简称为累加器，其可以分为 2 个独立的 8 位寄存器 AH 和 AL；在编写汇编程序中，AX 寄存器可以说是使用频率最高的寄存器。下面是几段汇编代码 mov ax,20 /* 将 20 送入寄存器 AX*/ mov ah,80 /* 将 80 送入寄存器 AH*/ add ax,10 /* 将寄存器 AX 中的数值加上 8 */

BX 寄存器

BX 被称为数据寄存器，即表明其能够暂存一般数据。同样为了适应以前的 8 位 CPU ，而可以将 BX 当做两个独立的 8 位寄存器使用，即有 BH 和 BL。BX 除了具有暂存数据的功能外，还用于 寻址，即寻找物理内存地址。BX 寄存器中存放的数据一般是用来作为偏移地址 使用的，因为偏移地址当然是在基址地址上的偏移了。偏移地址是在段寄存器中存储的，关于段寄存器的介绍，后面再说。

CX 寄存器

CX 也是数据寄存器，能够暂存一般性数据。同样为了适应以前的 8 位 CPU ，而可以将 CX 当做两个独立的 8 位寄存器使用，即有 CH 和 CL。除此之外，CX 也是有其专门的用途的，CX 中的 C 被翻译为 Counting 也就是计数器的功能。当在汇编指令中使用循环 LOOP 指令时，可以通过 CX 来指定需要循环的次数，每次执行循环 LOOP 时候，CPU 会做两件事

一件事是计数器自动减 1
还有一件就是判断 CX 中的值，如果 CX 中的值为 0 则会跳出循环，而继续执行循环下面的指令，当然如果 CX 中的值不为 0 ，则会继续执行循环中所指定的指令。

DX 寄存器

DX 也是数据寄存器，能够暂存一般性数据。同样为了适应以前的 8 位 CPU ，DX 的用途其实在前面介绍 AX 寄存器时便已经有所介绍了，那就是支持 MUL 和 DIV 指令。同时也支持数值溢出等。

段寄存器

CPU 包含四个段寄存器，用作程序指令，数据或栈的基础位置。

段寄存器主要包含

CS(Code Segment) ：代码寄存器，程序代码的基础位置
DS(Data Segment)：数据寄存器，变量的基本位置
SS(Stack Segment)：栈寄存器，栈的基础位置
ES(Extra Segment)：其他寄存器，内存中变量的其他基本位置。

索引寄存器

索引寄存器主要包含段地址的偏移量，索引寄存器主要分为

BP(Base Pointer)：基础指针，它是栈寄存器上的偏移量，用来定位栈上变量
SP(Stack Pointer): 栈指针，它是栈寄存器上的偏移量，用来定位栈顶
SI(Source Index): 变址寄存器，用来拷贝源字符串
DI(Destination Index): 目标变址寄存器，用来复制到目标字符串

状态和控制寄存器

就剩下两种寄存器还没聊了，这两种寄存器是指令指针寄存器和标志寄存器：**

IP(Instruction Pointer)：指令指针寄存器，它是从 Code Segment 代码寄存器处的偏移来存储执行的下一条指令
FLAG : Flag 寄存器用于存储当前进程的状态，这些状态有
- 位置 (Direction)：用于数据块的传输方向，是向上传输还是向下传输
- 中断标志位 (Interrupt) ：1 - 允许；0 - 禁止
- 陷入位 (Trap) ：确定每条指令执行完成后，CPU 是否应该停止。1 - 开启，0 - 关闭
- 进位 (Carry) : 设置最后一个无符号算术运算是否带有进位
- 溢出 (Overflow) : 设置最后一个有符号运算是否溢出
- 符号 (Sign) : 如果最后一次算术运算为负，则设置 1 =负，0 =正
- 零位 (Zero) : 如果最后一次算术运算结果为零，1 = 零
- 辅助进位 (Aux Carry) ：用于第三位到第四位的进位
- 奇偶校验 (Parity) : 用于奇偶校验

温故知新·存储设备

发表于 2021-01-29 | 分类于计算机基础

存储器是计算机中用于存储数据和指令（程序）的单元，不同类型的存储器作用不同，造价也不同，人们根据不同的需求产生了不同的存储器。

寄存器

寄存器位于CPU中，主要用于CPU内部临时数据、指令等的存储，与cpu相同材质制造，所以相对造价比较高，数量也不会特别多。依据寄存器存储空间大小不同，分为32位和64位。

高速缓存

高速缓存也是位于CPU中，是寄存器之外最快的存储设备。分为L1缓存、L2缓存、L3缓存，每层速度按数量级递减、容量也越来越大。

CPU每执行一条指令前都需要从内存中将指令读取到CPU内并执行。而寄存器的运行速度相比内存读写要快很多,为了性能, CPU就集成了一个高速缓存存储区域.当程序在运行时，先将要执行的指令代码以及数据复制到高速缓存中去(由操作系统完成).CPU直接从高速缓存依次读取指令来执行。

每核心都有一个自己的L1缓存。L1缓存分两种：L1指令缓存(L1-icache)和L1数据缓存(L1-dcache)。L1指令缓存用来存放已解码指令，L1数据缓存用来放访问非常频繁的数据。 L2缓存用来存放近期使用过的内存数据。更严格地说，存放的是很可能将来会被CPU使用的数据。多数多核CPU的各核都各自拥有一个L2缓存，但也有多核共享L2缓存的设计。无论如何，L1是各核私有的(但对某核内的多线程是共享的)。

内存（RAM）

内存又称为主存，具有存取速度快、造价相对（寄存器）便宜等优点，但内存是基于电工作的，断电后数据会全部消失。

除了RAM存储器外，还有一种ROM只读存储器，这种存储器在生产时就被写入指定程序，数据再也不能被修改；ROM的速度快且便宜，重点是它耗电量极低，它主要应用于动计算机的引导加载模块就存放在ROM中；比如：主板中的BIOS电池就可以为它提供5、6年的用电，所以我们每次打开电脑，都能显示正确的时间。

磁盘

磁盘主要基于磁工作，造价便宜而且断电数据不会消失；但磁盘是一种机械装置，它的存取速度相较内存慢很多；磁盘以每分钟5400，7200的速度旋转进行数据的读取、存储。

速度对比

访问速度：寄存器> 高速缓存 > 内存 > 磁盘

温故知新·冯诺依曼体系结构

发表于 2021-01-29 | 分类于计算机基础

冯·诺伊曼体系结构是现代计算机组成理论基础，是美籍匈牙利数学家冯·诺伊曼于1946年提出。冯·诺伊曼理论的要点是：把程序本身当作数据来对待，程序和该程序处理的数据用同样的方式储存，计算机的数制采用二进制，计算机应该按照程序顺序执行。人们把冯·诺伊曼的这个理论称为冯·诺伊曼体系结构。冯·诺依曼体系主要由五大部件组成：

存储器：用来存放数据和程序
运算器：主要运行算数运算和逻辑运算，并将中间结果暂存到运算器中
控制器：主要用来控制和指挥程序和数据的输入运行，以及处理运算结果
输入设备：用来将人们熟悉的信息形式转换为机器能够识别的信息形式，常见的有键盘，鼠标等
输出设备：可以将机器运算结果转换为人们熟悉的信息形式，如打印机输出，显示器输出等

冯诺依曼体系结构的指令和数据均采用二进制码表示；指令和数据以同等地位存放于存储器中，均可按地址寻访；指令由操作码和地址码组成，操作码用来表示操作的性质，地址码用来表示操作数所在存储器中的位置；指令在存储器中按顺序存放，通常指令是按顺序执行的，特定条件下，可以根据运算结果或者设定的条件改变执行顺序；机器以运算器为中心，输入输出设备和存储器的数据传送通过运算器。

C语言学习·编译过程

发表于 2020-10-01 | 分类于 C

# 预处理器 cpp, 展开通文件, 宏替换, 去掉注释
gcc -E hello.c -o hello.i
# 编译器 gcc, c文件 -> 汇编文件
gcc -S hello.i -o hello.s
# 汇编器 as, 汇编文件 -> 二进制文件
gcc -c hello.s -o hello.o
# 链接器 ld, 将函数库中的代码组合到目标文件中
gcc hello.o -o hello

编译参数

指定宏

#include <iostream>
int main() {
#ifdef DEBUG
    std::cout << "hello world\n";
#endif
    return 0;
}Copy to clipboardErrorCopied

1	gcc sum.c -o sum -D DEGUBCopy to clipboardErrorCopied

输出警告信息

1	gcc sum.c -o sum -WallCopy to clipboardErrorCopied

优化代码

1 2	# 优化等级分为o1、 o2、 o3 gcc sum.c -o sum -o3 Copy to clipboardErrorCopied

生成调试信息
1
gcc sum.c -o sum -g

静态库

创建静态库

// include/head.h 
#ifndef HEAD_H
#define HEAD_H
int sum(int, int);
int mul(int, int);
#endifCopy to clipboardErrorCopied

// ./sum.c
#include "head.h"
int sum(int a, int b) {
    return a + b;
}
// ./mul.c
#include "head.h"
int mul(int a, int b) {
    return a * b;
}Copy to clipboardErrorCopied

生成.o文件

1	gcc -c *.c -I includeCopy to clipboardErrorCopied

打包静态库

1	ar rcs lib/libtest.a *.oCopy to clipboardErrorCopied

使用静态库

// ./main.c
#include "head.h"
#include "stdio.h"
int main()
{
    int a = sum(2, 4);
    int b = mul(2, 4);
    printf("%d %d\n", a, b);
    return 0;
}Copy to clipboardErrorCopied

使用静态库编译文件

1 2	gcc main.c lib/libtest.a -I include -o main gcc main.c -I include -L lib -l test -o mainCopy to clipboardErrorCopied

查看查看文件中符号

1	nm mainCopy to clipboardErrorCopied

优缺点

静态库在使用的时候，会根据程序中用的到函数，将对应函数所在的.o打包到程序中。

发布程序的时候，不需要提供对应的库。
加载库的速度快

将这些库打包到可执行文件中同时也会造成：

可执行程序的体积大
库发生改变，需要重新编译程序

动态库

创建动态库

生成与位置无关的目标文件

1	gcc -fPIC -c *.c -I includeCopy to clipboardErrorCopied

打包动态库.so

1	gcc -shared -o lib/libtest.so *.o -I includeCopy to clipboardErrorCopied

使用动态库

1 2	gcc main.c lib/libtest.so -I include -o main gcc main.c -L lib -l test -I include -o mainCopy to clipboardErrorCopied

在使用第二种方法，执行可执行文件时，会出现找不到路径的问题，这是因为动态库在加载的时候，需要动态链接器进行加载，可以适应ldd命令查看可执行程序需要的动态库。

动态链接器在加载库的时候，根据环境变量中的目录惊进行查找，可以添加自己的目录到环境变量中。

动态库的搜索路径的顺序

编译目标代码时指定的动态库搜索路径
环境变量LD_LIBRARY_PATH指定的动态库搜索路径
配置文件/etc/ld.so.conf中指定的动态库搜索路径
默认的动态库搜索路径/lib和/usr/lib

添加到LD_LIBRARY_PATH，这种方法是临时的。

1	export LD_LIBRARY_PATH=./lib:$LD_LIBRARY_PATHCopy to clipboardErrorCopied

可以将命令写到bash配置文件里面，这样每次加载shell之前，都会配置目录。

1 2	vim ~/.bashrc export LD_LIBRARY_PATH=./lib:$LD_LIBRARY_PATHCopy to clipboardErrorCopied

另外也可以配置ld.so.conf。

1
2
3

sudo vim /etc/ld.so.conf
/home/user/linux/lib
sudo ldconfig -vCopy to clipboardErrorCopied

查看可执行文件依赖的动态库

1	ldd appCopy to clipboardErrorCopied

优缺点

动态库只是在内存地址的共享库中标记，在程序运行时才加载。

可执行程序体积小
动态库更新，不需要重新编译
发布程序需要将库提供给用户
动态库没有打包应用程序中，加载速度相对慢

GDB调试

全称		功能
list	l	显示多行源代码
break	b	设置断点
delete	d	删除断点
info	i	描述程序的状态
run	r	开始运行程序
display	disp	跟踪查看某个变量，每次停下来都显示它的值
undisplay		停止追踪
step	s	执行下一条语句,如果该语句为函数调用,则进入函数执行其中的第一条语句
finish		跳出本次函数
next	n	执行下一条语句,如果该语句为函数调用,不会进入函数内部执行(即不会一步步地调试函数内部语句)
print	p	打印内部变量值
ptype		打印变量类型
continue	c	继续程序的运行,直到遇到下一个断点
	u	跳出本次循环
set var name=v		设置变量的值
start	st	开始执行程序,在main函数的第一条语句前面停下来
file		装入需要调试的程序
kill	k	终止正在调试的程序
watch		监视变量值的变化
backtrace	bt	产看函数调用信息(堆栈)
frame	f	查看栈帧
quit	q	退出GDB环境

生成调试程序

1	gcc *.c -o app -gCopy to clipboardErrorCopied

查看代码

1	l main.c:mainCopy to clipboardErrorCopied

设置断点

设置断点

1 2	b 22 b 15 if i == 15Copy to clipboardErrorCopied

查看断点

1	i bCopy to clipboardErrorCopied

删除断点

1 2	d 1 d 1-5Copy to clipboardErrorCopied

执行程序

开始

1	startCopy to clipboardErrorCopied

单步

1	nCopy to clipboardErrorCopied

下个断点

1	cCopy to clipboardErrorCopied

单步调试

进入函数内部

1	sCopy to clipboardErrorCopied

跳出本次循环

1	uCopy to clipboardErrorCopied

退出函数

1	finishCopy to clipboardErrorCopied

查看变量

查看变量的值

1	p varCopy to clipboardErrorCopied

查看变量类型

1	ptype varCopy to clipboardErrorCopied

设置变量的值

1	set var i=10Copy to clipboardErrorCopied

追踪变量

追踪变量

1 2	display i display jCopy to clipboardErrorCopied

查看追踪的变量

1	i displayCopy to clipboardErrorCopied

删除追踪的变量

1	undisplay 1 # 对应变量的编号Copy to clipboardErrorCopied

多进程调试

在fork之前设置mode。

set follow-fork-mode child，跟踪子进程
set follow-fork-mode parent 跟踪父进程

makefile

普通版

app: main.o sum.o sub.o
     gcc main.o sum.o sub.o -o app
main.o: main.c
    gcc -c main.c
sum.o: sum.c
    gcc -c sum.c
sub.o: sub.c
    gcc -c sub.cCopy to clipboardErrorCopied

自动变量

1
2
3

$@: 规则中的目标
$<: 规则中的第一个依赖
$^: 规则中的所有依赖Copy to clipboardErrorCopied

obj = main.o sum.o sub.o
target = app
# makefile系统变量
CC = gcc
$(target):$(obj)
$(CC) $(obj) -o $(target)
%.o: %.c
$(CC) -c $< -o $@Copy to clipboardErrorCopied

makefile函数

target = app
# 得到所有.c文件
src = $(wildcard ./*.c)
# 将.c替换为.o
obj = $(patsubst ./%.c, ./%.o, $(src))
CC = gcc
$(target): $(obj)
    $(CC) $(obj) -o $(target)
%.o: %.c
    $(CC) -c $< -o $@
# 声明伪目标
.PHONY:clean
clean:
    rm $(obj) $(target)Copy to clipboardErrorCopied

静态模型

c194a9eg(objects)中获取， “%.o”表示以”.o”结尾的目标, 即foo.o bar.o, 依赖模式就是把”%.o”中的”%”拿来加上”.c”

objects = foo.o bar.o
all: $(objects)
$(objects): %.o: %.c
    $(CC) -c $(CFLAGS) &< -o $@Copy to clipboardErrorCopied

等价于

foo.o : foo.c
$(CC) -c $(CFLAGS) foo.c -o foo.o
bar.o : bar.c
$(CC) -c $(CFLAGS) bar.c -o bar.oCopy to clipboardErrorCopied

Docker数据持久化总结

发表于 2020-09-12 | 分类于 Docker

Docker的数据持久化即数据不随着container(容器)的结束而结束，如果要想达成此目的，则数据必须得持久化存储在host(宿主机)上，依据存储的数据的管理方式不同，Docker上有两种数据持久化方式：

存在于host的某个指定目录中（使用bind mount）
使用docker自己管理的volume（/var/lib/docker/volumes下）

bind mount

bind mount自docker早期便开始为人们使用了，用于将host机器的目录mount到container中。

1 2	# 将host机器上当前目录下的host-data目录mount到container中的/container-data目录 docker run -it -v $(pwd)/host-dava:/container-data alpine sh

有几点需要注意：

如果host机器上的目录不存在，docker会自动创建该目录
如果container中的目录不存在，docker会自动创建该目录
如果container中的目录已经有内容，那么docker会使用host上的目录将其覆盖掉

volume

volume(卷)也是绕过container的文件系统，直接将数据写到host机器上，只是volume是被docker管理的，docker下所有的volume都在host机器上的指定目录下/var/lib/docker/volumes。

dev@devops:~$ sudo ls -al /var/lib/docker/volumes
total 220
drwx------  5 root root  45056 Apr 15 23:09 .
drwx--x--x 14 root root   4096 Apr 10 15:03 ..
drwxr-xr-x  3 root root   4096 Jan 30 11:46 4f5936b11140b7664aa4dcb5f7043fdef96b80d76b23b0410da8ee9e7caa653d
drwxr-xr-x  3 root root   4096 Jan 30 11:46 c501e25d1cde249a7fbd7f2e2c3155ca2fd876b7a28df1b8eddbaa7175ab3d00
-rw-------  1 root root 262144 Apr 15 23:09 metadata.db
drwxr-xr-x  3 root root   4096 Apr 15 23:09 my-volume

可以查看到my-volume的信息：

dev@devops:~$ docker volume ls
DRIVER              VOLUME NAME
local               4f5936b11140b7664aa4dcb5f7043fdef96b80d76b23b0410da8ee9e7caa653d
local               c501e25d1cde249a7fbd7f2e2c3155ca2fd876b7a28df1b8eddbaa7175ab3d00
local               my-volume
dev@devops:~$ docker volume inspect my-volume
[
    {
        "CreatedAt": "2021-04-15T23:09:18+08:00",
        "Driver": "local",
        "Labels": {},
        "Mountpoint": "/var/lib/docker/volumes/my-volume/_data",
        "Name": "my-volume",
        "Options": {},
        "Scope": "local"
    }
]

可以看到，volume在host机器的目录为/var/lib/docker/volumes/my-volume/_data。此时，如果my-volume不存在，那么docker会自动创建my-volume，然后再挂载。

也可以不指定host上的volume：

1	docker run -it -v /mydata alpine sh

此时docker将自动创建一个匿名的volume，并将其挂载到container中的/mydata目录。匿名volume在host机器上的目录路径类似于：/var/lib/docker/volumes/4f5936b11140b7664aa4dcb5f7043fdef96b80d76b23b0410da8ee9e7caa653d/_data。

除了让docker帮我们自动创建volume，我们也可以自行创建：

1	docker volume create my-volume-2

然后将这个已有的my-volume-2挂载到container中:

1	docker run -it -v my-volume-2:/mydata alpine sh

需要注意的是，与bind mount不同的是，如果volume是空的而container中的目录有内容，那么docker会将container目录中的内容拷贝到volume中，但是如果volume中已经有内容，则会将container中的目录覆盖。

Docker网络模式深度解读

发表于 2020-09-11 | 分类于 Docker

Docker的网络模式介绍

docker默认提供4种网络模式：

host模式：使用 –net=host 指定。
none模式：使用 –net=none 指定。
bridge模式：使用 –net=bridge 指定，默认设置。
container模式：使用 –net=container:NAME_or_ID 指定。

可以通过命令 docker network ls 查看

NETWORK ID          NAME                    DRIVER              SCOPE
2e3311e3fd75        bi                      bridge              local
04a7022e57fd        bridge                  bridge              local
207a0c0b75b6        game                    bridge              local
f6be0ad892a5        host                    host                local
7760fc2ba11d        none                    null                local

bridge桥接模式

桥接模式是docker默认的网络模式。当docker服务启动后，会创建一个名字叫docker0的虚拟网桥，然后选一个与宿主机不一样的网络ip地址以及子网分配给docker0。

1
2
3

dev@devops:~$ brctl show docker0
bridge name	bridge id		STP enabled	interfaces
docker0		8000.0242fc6483f2	no

另外每创建一个容器就会新增一个容器网卡，然后以桥接方式架到docker0网桥中，docker0会以NAT地址转换的方式通过宿主机的网卡，从而与公网进行通信。

如下图所示：

下面进行测试演示：

启动docker服务后，通过命令 ip addr 发现docker0网卡ip为172.17.0.1

9: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:fc:64:83:f2 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever

启动一个docker容器 docker run -itd redis /bin/bash ，再进行一次 ip addr, 发现新增了一个虚拟网卡veth6e7c4ad@if157

1 2	158: veth6e7c4ad@if157: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default link/ether ee:36:2b:3b:df:7c brd ff:ff:ff:ff:ff:ff link-netnsid 40

使用命令 brctl show 查看一下桥接情况，可以看到容器的网卡桥接到docker0上

1	docker0 8000.0242fc6483f2 no veth6e7c4ad

host主机模式

主机模式是指docker容器与公网通信时使用的是宿主机的ip与端口，同时容器自己不会有ip地址，所以在这模式下容器与宿主机之间并没有隔离很分明。

在容器启动命令时用参数–net=host指定当前容器网络模式 docker run -d –net=host mongo

1
2
3

dev@devops:~$ nc 127.0.0.1 27017
dev@devops:~$ netstat antp | grep 27017
tcp        0      0 localhost:45624         localhost:27017         TIME_WAIT

这时外界要访问容器中的应用，则直接使用{host0.ip}:port即可，不用任何NAT转换，就像直接跑在宿主机中一样。但是，容器的其他方面，如文件系统、进程列表等还是和宿主机隔离的。

container网络模式

Docker网络container模式是指，创建新容器的时候，通过–net container参数，指定其和已经存在的某个容器共享一个 Network Namespace。

用–net container:xx参数，指定该容器的网络模型为container模式，和xx容器共用相同的网络命名空间。

1 2	dev@devops:~$ docker run -d --name redis --net container:ga-test redis c5b1febc0b20965f2339557d3d92e5558f2a894a0b8f8546f788620b5e0588eb

none无网络模式

无网络模式下相当于容器处于断网状态下，同样没有自己的ip地址。创建容器时通过参数 –net=none 设置，这比较少使用。

Docker的内部通信

在实际的项目环境中，肯定会存在多个容器之间通信对情况，举个例子，例如多个服务访问一个mysql数据库。通常只需要在多个服务之间配置数据库的地址就可以了，它们都是通过默认的bridge进行通信的。

现在启动两个服务centos01和centos02

[root@localhost ~]# docker run -itd --name=centos01 mycentos:nettools /bin/bash
982a3d4cdb131bf33d217218c04aad278ac762376337e4180fd2eadc63599541
[root@localhost ~]# docker run -itd --name=centos02 mycentos:nettools /bin/bash
e1c43e2000915b8256b1f0b6793b6f4bd1b2ff33ae1f32c6872ce21d4c5c8e4e

查看一下centos02的ip地址 docker inspect e1c43e2000915 ，发现是172.17.0.3。

[
    {
        "Id": "e1c43e2000915b8256b1f0b6793b6f4bd1b2ff33ae1f32c6872ce21d4c5c8e4e",
        "Created": "2020-02-18T08:17:13.893194133Z",
        "Path": "/bin/bash",
        "Args": [],
        "State": {
            "Status": "running",
            "Running": true,
            "Paused": false,
            "Restarting": false,
            "OOMKilled": false,
            "Dead": false,
            "Pid": 19853,
            "ExitCode": 0,
            "Error": "",
            "StartedAt": "2020-02-18T08:17:14.24517605Z",
            "FinishedAt": "0001-01-01T00:00:00Z"
        },
        "Image": "sha256:b92ca30f601cb7b594210e041eed8753aabb72dc5c2a18905b6272f5176ffdc0",
        "ResolvConfPath": "/var/lib/docker/containers/e1c43e2000915b8256b1f0b6793b6f4bd1b2ff33ae1f32c6872ce21d4c5c8e4e/resolv.conf",
        "HostnamePath": "/var/lib/docker/containers/e1c43e2000915b8256b1f0b6793b6f4bd1b2ff33ae1f32c6872ce21d4c5c8e4e/hostname",
        "HostsPath": "/var/lib/docker/containers/e1c43e2000915b8256b1f0b6793b6f4bd1b2ff33ae1f32c6872ce21d4c5c8e4e/hosts",
        "LogPath": "/var/lib/docker/containers/e1c43e2000915b8256b1f0b6793b6f4bd1b2ff33ae1f32c6872ce21d4c5c8e4e/e1c43e2000915b8256b1f0b6793b6f4bd1b2ff33ae1f32c6872ce21d4c5c8e4e-json.log",
        "Name": "/centos02",
        "RestartCount": 0,
        "Driver": "overlay2",
        "Platform": "linux",
        "MountLabel": "",
        "ProcessLabel": "",
        "AppArmorProfile": "",
        "ExecIDs": null,
        "HostConfig": {
            "Binds": null,
            "ContainerIDFile": "",
            "LogConfig": {
                "Type": "json-file",
                "Config": {}
            },
            "NetworkMode": "default",
            "PortBindings": {},
            "RestartPolicy": {
                "Name": "no",
                "MaximumRetryCount": 0
            },
            "AutoRemove": false,
            "VolumeDriver": "",
            "VolumesFrom": null,
            "CapAdd": null,
            "CapDrop": null,
            "Capabilities": null,
            "Dns": [],
            "DnsOptions": [],
            "DnsSearch": [],
            "ExtraHosts": null,
            "GroupAdd": null,
            "IpcMode": "private",
            "Cgroup": "",
            "Links": null,
            "OomScoreAdj": 0,
            "PidMode": "",
            "Privileged": false,
            "PublishAllPorts": false,
            "ReadonlyRootfs": false,
            "SecurityOpt": null,
            "UTSMode": "",
            "UsernsMode": "",
            "ShmSize": 67108864,
            "Runtime": "runc",
            "ConsoleSize": [
                0,
                0
            ],
            "Isolation": "",
            "CpuShares": 0,
            "Memory": 0,
            "NanoCpus": 0,
            "CgroupParent": "",
            "BlkioWeight": 0,
            "BlkioWeightDevice": [],
            "BlkioDeviceReadBps": null,
            "BlkioDeviceWriteBps": null,
            "BlkioDeviceReadIOps": null,
            "BlkioDeviceWriteIOps": null,
            "CpuPeriod": 0,
            "CpuQuota": 0,
            "CpuRealtimePeriod": 0,
            "CpuRealtimeRuntime": 0,
            "CpusetCpus": "",
            "CpusetMems": "",
            "Devices": [],
            "DeviceCgroupRules": null,
            "DeviceRequests": null,
            "KernelMemory": 0,
            "KernelMemoryTCP": 0,
            "MemoryReservation": 0,
            "MemorySwap": 0,
            "MemorySwappiness": null,
            "OomKillDisable": false,
            "PidsLimit": null,
            "Ulimits": null,
            "CpuCount": 0,
            "CpuPercent": 0,
            "IOMaximumIOps": 0,
            "IOMaximumBandwidth": 0,
            "MaskedPaths": [
                "/proc/asound",
                "/proc/acpi",
                "/proc/kcore",
                "/proc/keys",
                "/proc/latency_stats",
                "/proc/timer_list",
                "/proc/timer_stats",
                "/proc/sched_debug",
                "/proc/scsi",
                "/sys/firmware"
            ],
            "ReadonlyPaths": [
                "/proc/bus",
                "/proc/fs",
                "/proc/irq",
                "/proc/sys",
                "/proc/sysrq-trigger"
            ]
        },
        "GraphDriver": {
            "Data": {
                "LowerDir": "/var/lib/docker/overlay2/fe38b48216b0e036c8a594635f6392d0f06f5da202e695a7052aa36ca510ddc1-init/diff:/var/lib/docker/overlay2/0dd6db3d6d6ee7fc48b4e13654a8d4414b545834df6e1524475649f2d67454de/diff:/var/lib/docker/overlay2/c9ac4844a5f33fad6a906ae9b4b86fa9f058c7ed1048bffad5b7a4aca454b33b/diff",
                "MergedDir": "/var/lib/docker/overlay2/fe38b48216b0e036c8a594635f6392d0f06f5da202e695a7052aa36ca510ddc1/merged",
                "UpperDir": "/var/lib/docker/overlay2/fe38b48216b0e036c8a594635f6392d0f06f5da202e695a7052aa36ca510ddc1/diff",
                "WorkDir": "/var/lib/docker/overlay2/fe38b48216b0e036c8a594635f6392d0f06f5da202e695a7052aa36ca510ddc1/work"
            },
            "Name": "overlay2"
        },
        "Mounts": [],
        "Config": {
            "Hostname": "e1c43e200091",
            "Domainname": "",
            "User": "",
            "AttachStdin": false,
            "AttachStdout": false,
            "AttachStderr": false,
            "Tty": true,
            "OpenStdin": true,
            "StdinOnce": false,
            "Env": [
                "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
            ],
            "Cmd": [
                "/bin/bash"
            ],
            "Image": "mycentos:nettools",
            "Volumes": null,
            "WorkingDir": "",
            "Entrypoint": null,
            "OnBuild": null,
            "Labels": {
                "org.label-schema.build-date": "20191001",
                "org.label-schema.license": "GPLv2",
                "org.label-schema.name": "CentOS Base Image",
                "org.label-schema.schema-version": "1.0",
                "org.label-schema.vendor": "CentOS"
            }
        },
        "NetworkSettings": {
            "Bridge": "",
            "SandboxID": "e8d1342d5dab4b15608ef4be8cacc83c30ca579c8ce676c39a91683da5e662b5",
            "HairpinMode": false,
            "LinkLocalIPv6Address": "",
            "LinkLocalIPv6PrefixLen": 0,
            "Ports": {},
            "SandboxKey": "/var/run/docker/netns/e8d1342d5dab",
            "SecondaryIPAddresses": null,
            "SecondaryIPv6Addresses": null,
            "EndpointID": "f335c5cfcf7110d793f546ac44cf18bfd079f990ad3820646149f2adc28be692",
            "Gateway": "172.17.0.1",
            "GlobalIPv6Address": "",
            "GlobalIPv6PrefixLen": 0,
            "IPAddress": "172.17.0.3",
            "IPPrefixLen": 16,
            "IPv6Gateway": "",
            "MacAddress": "02:42:ac:11:00:03",
            "Networks": {
                "bridge": {
                    "IPAMConfig": null,
                    "Links": null,
                    "Aliases": null,
                    "NetworkID": "76342053278e2345a41515f3c5728095c5a97f6230f7a3edf5e41017c67a0a9f",
                    "EndpointID": "f335c5cfcf7110d793f546ac44cf18bfd079f990ad3820646149f2adc28be692",
                    "Gateway": "172.17.0.1",
                    "IPAddress": "172.17.0.3",
                    "IPPrefixLen": 16,
                    "IPv6Gateway": "",
                    "GlobalIPv6Address": "",
                    "GlobalIPv6PrefixLen": 0,
                    "MacAddress": "02:42:ac:11:00:03",
                    "DriverOpts": null
                }
            }
        }
    }
]

接下来进入centos01然后尝试ping一下172.17.0.3，发现是ping成功的

[root@localhost ~]# docker exec -it centos01 /bin/bash
[root@982a3d4cdb13 /]# ping 172.17.0.3
PING 172.17.0.3 (172.17.0.3) 56(84) bytes of data.
64 bytes from 172.17.0.3: icmp_seq=1 ttl=64 time=0.154 ms
64 bytes from 172.17.0.3: icmp_seq=2 ttl=64 time=0.105 ms
64 bytes from 172.17.0.3: icmp_seq=3 ttl=64 time=0.121 ms
64 bytes from 172.17.0.3: icmp_seq=4 ttl=64 time=0.071 ms
64 bytes from 172.17.0.3: icmp_seq=5 ttl=64 time=0.070 ms
^C
--- 172.17.0.3 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3999ms
rtt min/avg/max/mdev = 0.070/0.104/0.154/0.032 ms
[root@982a3d4cdb13 /]#

然后尝试ping一下centos02，发现是ping失败的

1 2	[root@982a3d4cdb13 /]# ping centos02 ping: centos02: Name or service not known

也就是说目前在默认bridge下是没法通过容器名称来进行通信的回到宿主机查看一下bridge的信息，发现配置容器的相关网络信息。

[root@localhost ~]# docker network inspect bridge
[
    {
        "Name": "bridge",
        "Id": "76342053278e2345a41515f3c5728095c5a97f6230f7a3edf5e41017c67a0a9f",
        "Created": "2020-02-17T07:17:21.082636014+08:00",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.17.0.0/16",
                    "Gateway": "172.17.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {
            "982a3d4cdb131bf33d217218c04aad278ac762376337e4180fd2eadc63599541": {
                "Name": "centos01",
                "EndpointID": "6d05788dc1e1ae12d6048879d5a0dc5012db828258e2de3ca91a7a1e1bc7cc33",
                "MacAddress": "02:42:ac:11:00:02",
                "IPv4Address": "172.17.0.2/16",
                "IPv6Address": ""
            },
            "e1c43e2000915b8256b1f0b6793b6f4bd1b2ff33ae1f32c6872ce21d4c5c8e4e": {
                "Name": "centos02",
                "EndpointID": "f335c5cfcf7110d793f546ac44cf18bfd079f990ad3820646149f2adc28be692",
                "MacAddress": "02:42:ac:11:00:03",
                "IPv4Address": "172.17.0.3/16",
                "IPv6Address": ""
            }
        },
        "Options": {
            "com.docker.network.bridge.default_bridge": "true",
            "com.docker.network.bridge.enable_icc": "true",
            "com.docker.network.bridge.enable_ip_masquerade": "true",
            "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
            "com.docker.network.bridge.name": "docker0",
            "com.docker.network.driver.mtu": "1500"
        },
        "Labels": {}
    }
]

在docker中容器间直接通过ip进行服务访问是存在弊端的。假如上面例子中mysql的突然挂掉重启也失败，只能重新run一个。这时ip可能会发生变化，那就需要进去直接跟mysql通信的服务修改相关配置信息，就很不友好。因此Docker也提供了基于容器名来与其它容器通信。

基于link实现单向通信

所谓单向通信是指只能单方面发起网络请求。例如一个功能服务请求mysql服务器，通常mysql服务器不需要访问功能服务。同样启动两个服务进行模拟操作。一个模拟mysql，一个模拟tomcat。tomcat服务通过 –link mysql link到mysql服务中，记住，mysql服务要首先启动，不然会报错！

[root@localhost ~]# docker run -itd --name mysql mycentos:nettools /bin/bash
97ad026117718a0524eec1eb7db04a0dc3317b228b44abcc2b65a857919d8589
[root@localhost ~]# docker run -itd --name tomcat --link mysql mycentos:nettools /bin/bash
14c127543930d9c992f38514ba1b3db30a9e350272f41800e3e6870be5357450

接着进入tomcat容器中,通过容器名mysql使用ping命令

[root@localhost ~]# docker exec -it 14c12754393 /bin/bash
[root@14c127543930 /]# ping mysql
PING mysql (172.17.0.2) 56(84) bytes of data.
64 bytes from mysql (172.17.0.2): icmp_seq=1 ttl=64 time=0.109 ms
64 bytes from mysql (172.17.0.2): icmp_seq=2 ttl=64 time=0.118 ms
64 bytes from mysql (172.17.0.2): icmp_seq=3 ttl=64 time=0.140 ms
^C
--- mysql ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.109/0.122/0.140/0.015 ms

在网络中通过ping域名解析，无非就是通过本地hosts文件配置路由规则进行解析，还有就是通过DNS服务器解析查看一下该hosts文件，发现配置了mysql容器的ip地址信息

[root@14c127543930 /]# cat /etc/hosts
127.0.0.1       localhost
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
172.17.0.2      mysql 97ad02611771
172.17.0.3      14c127543930

接下来进入mysql容器尝试ping一下tomcat容器，发现ping失败：

1
2
3

[root@localhost ~]# docker exec -it 97ad026117 /bin/bash
[root@97ad02611771 /]# ping tomcat
ping: tomcat: Name or service not known

也就是说通过–link实现单向通信，路由规则是通过改写hosts文件实现。

利用bridge网桥实现双向通信

从 Docker1.10 以后，docker daemon 实现了一个内嵌的 docker dns server，使容器可以直接通过“容器名”通信。不过不能使用默认bridge，需要自定义网桥。

1、创建一个新的网桥def_bridge:

1 2	[root@localhost ~]# docker network create -d bridge def_bridge faeddc1fbfbf98f6572766003ff2cc27a023d43699fd994397013e09077c3784

2、启动两个容器名字分别为mysql和tomcat

[root@localhost ~]# docker run -itd --name mysql mycentos:nettools /bin/bash
6a9f1e9d0bb051ea31e5727193a1aed99b8039c2cde629fe2bd387def1abb5bd
[root@localhost ~]# docker run -itd --name tomcat mycentos:nettools /bin/bash
3e5950876d69712c3e2f8fd10268c9a21f1f21dd9937d1010ad2d5f709932831

3、然后将两个启动的容器都加入新增的网桥

1 2	[root@localhost ~]# docker network connect def_bridge mysql [root@localhost ~]# docker network connect def_bridge tomcat

4、分别进入两个容器通过容器名互ping, 发现ping成功

[root@localhost ~]# docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
3e5950876d69        mycentos:nettools   "/bin/bash"         6 minutes ago       Up 6 minutes                            tomcat
6a9f1e9d0bb0        mycentos:nettools   "/bin/bash"         6 minutes ago       Up 6 minutes                            mysql
[root@localhost ~]# docker exec -it 6a9f1e9d0bb0 /bin/bash
[root@6a9f1e9d0bb0 /]# ping tomcat
PING tomcat (172.18.0.3) 56(84) bytes of data.
64 bytes from tomcat.def_bridge (172.18.0.3): icmp_seq=1 ttl=64 time=0.100 ms
64 bytes from tomcat.def_bridge (172.18.0.3): icmp_seq=2 ttl=64 time=0.057 ms
64 bytes from tomcat.def_bridge (172.18.0.3): icmp_seq=3 ttl=64 time=0.097 ms
64 bytes from tomcat.def_bridge (172.18.0.3): icmp_seq=4 ttl=64 time=0.060 ms
--- tomcat ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3002ms
rtt min/avg/max/mdev = 0.057/0.078/0.100/0.021 ms
[root@6a9f1e9d0bb0 /]# exit
exit
[root@localhost ~]# docker exec -it 3e5950876d69 /bin/bash
[root@3e5950876d69 /]# ping mysql
PING mysql (172.18.0.2) 56(84) bytes of data.
64 bytes from mysql.def_bridge (172.18.0.2): icmp_seq=1 ttl=64 time=0.040 ms
64 bytes from mysql.def_bridge (172.18.0.2): icmp_seq=2 ttl=64 time=0.067 ms
64 bytes from mysql.def_bridge (172.18.0.2): icmp_seq=3 ttl=64 time=0.055 ms
64 bytes from mysql.def_bridge (172.18.0.2): icmp_seq=4 ttl=64 time=0.130 ms
--- mysql ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 0.040/0.073/0.130/0.034 ms

然后检查一下tomcat容器的hosts文件以及resolv.conf文件发现hosts文件没有配置路由规则，而resolv.conf中配置了dns server 127.0.0.11

[root@3e5950876d69 /]# cat /etc/hosts
127.0.0.1       localhost
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
172.17.0.3      3e5950876d69
172.18.0.3      3e5950876d69
[root@3e5950876d69 /]# cat /etc/resolv.conf 
nameserver 127.0.0.11
options ndots:0

也就是说通过自定义bridge双向通信是通过内置的dns服务实现IP地址的解析工作。

计算机网络知识总结

发表于 2020-03-17 | 分类于 Liunx

虚拟内存

内存保护

汇编语言是什么？

来历

寄存器

寄存器的种类

内存模型：Heap

内存模型：Stack

CPU指令

push指令

call 指令

mov 指令

add 指令

pop 指令

ret 指令

CPU 的内部结构

CPU 是寄存器的集合体

计算机语言

程序计数器（PC)

条件分支和循环机制

标志寄存器

函数调用机制

通过地址和索引实现数组

CPU 指令执行过程

认识寄存器

通用寄存器

AX 寄存器

BX 寄存器

CX 寄存器

DX 寄存器

段寄存器

索引寄存器

状态和控制寄存器

寄存器

高速缓存

内存（RAM）

磁盘

速度对比

编译参数

静态库

创建静态库

使用静态库

优缺点

动态库

创建动态库

使用动态库

优缺点

GDB调试

生成调试程序

查看代码

设置断点

执行程序

单步调试

查看变量

追踪变量

多进程调试

makefile

普通版

自动变量

makefile函数

静态模型

bind mount

volume

Docker的网络模式介绍

bridge桥接模式

host主机模式

container网络模式

none无网络模式

Docker的内部通信

基于link实现单向通信

利用bridge网桥实现双向通信

分层模型

三次握手和四次挥手

拥塞控制

TCP流量控制

广播路由

广播路由算法

广播风暴

HTTPS原理