408 on SalmoneX Blog

计算机系统常见问题1

Fri, 10 Jan 2020 21:56:12 +0800

1. 死锁

什么是死锁？

所谓死锁，是指多个进程在运行过程中因争夺资源而造成的一种僵局，当进程处于这种僵持状态时，若无外力作用，它们都将无法再向前推进。

因此我们举个例子来描述，如果此时有一个线程A，按照先锁a再获得锁b的的顺序获得锁，而在此同时又有另外一个线程B，按照先锁b再锁a的顺序获得锁。如下图所示：

产生死锁的原因？

可归结为如下两点：

竞争资源

系统中的资源可以分为两类：
1. 可剥夺资源，是指某进程在获得这类资源后，该资源可以再被其他进程或系统剥夺，CPU和主存均属于可剥夺性资源；
2. 另一类资源是不可剥夺资源，当系统把这类资源分配给某进程后，再不能强行收回，只能在进程用完后自行释放，如磁带机、打印机等。
- 产生死锁中的竞争资源之一指的是竞争不可剥夺资源（例如：系统中只有一台打印机，可供进程P1使用，假定P1已占用了打印机，若P2继续要求打印机打印将阻塞）
- 产生死锁中的竞争资源另外一种资源指的是竞争临时资源（临时资源包括硬件中断、信号、消息、缓冲区内的消息等），通常消息通信顺序进行不当，则会产生死锁

进程间推进顺序非法

若P1保持了资源R1,P2保持了资源R2，系统处于不安全状态，因为这两个进程再向前推进，便可能发生死锁
例如，当P1运行到P1：Request（R2）时，将因R2已被P2占用而阻塞；当P2运行到P2：Request（R1）时，也将因R1已被P1占用而阻塞，于是发生进程死锁

死锁产生的4个必要条件

产生死锁的必要条件：

互斥条件：进程要求对所分配的资源进行排它性控制，即在一段时间内某资源仅为一进程所占用。互斥条件是指多个线程不能同时使⽤同⼀个资源
请求和保持条件：当进程因请求资源而阻塞时，对已获得的资源保持不放。当线程 A 已经持有了资源 1，⼜想申请资源 2，⽽资源 2 已经被线程 C 持有了，所以线程 A 就会处于等待状态，但是线程 A 在等待资源 2 的同时并不会释放⾃⼰已经持有的资源 1
不可剥夺条件：进程已获得的资源在未使用完之前，不能剥夺，只能在使用完时由自己释放。
循环等待条件：在发生死锁时，必然存在一个进程–资源的环形链。在死锁发⽣的时候，两个线程获取资源的顺序构成了环形链。

预防死锁：

资源一次性分配：一次性分配所有资源，这样就不会再有请求了：（破坏请求条件）
只要有一个资源得不到分配，也不给这个进程分配其他的资源：（破坏保持条件）
可剥夺资源：即当某进程获得了部分资源，但得不到其它资源，则释放已占有的资源（破坏不可剥夺条件）
资源有序分配法：系统给每类资源赋予一个编号，每一个进程按编号递增的顺序请求资源，释放则相反（破坏环路等待条件）

解决死锁的基本方法

1、以确定的顺序获得锁

如果必须获取多个锁，那么在设计的时候需要充分考虑不同线程之前获得锁的顺序。按照上面的例子，两个线程获得锁的时序图如下：

如果此时把获得锁的时序改成：

那么死锁就永远不会发生。针对两个特定的锁，开发者可以尝试按照锁对象的hashCode值大小的顺序，分别获得两个锁，这样锁总是会以特定的顺序获得锁，那么死锁也不会发生。

问题变得更加复杂一些，如果此时有多个线程，都在竞争不同的锁，简单按照锁对象的hashCode进行排序（单纯按照hashCode顺序排序会出现“环路等待”），可能就无法满足要求了，这个时候开发者可以使用银行家算法，所有的锁都按照特定的顺序获取，同样可以防止死锁的发生，该算法在这里就不再赘述了，有兴趣的可以自行了解一下。

2、超时放弃

当使用synchronized关键词提供的内置锁时，只要线程没有获得锁，那么就会永远等待下去然

而Lock接口提供了boolean tryLock(long time, TimeUnit unit) throws InterruptedException方法，该方法可以按照固定时长等待锁，因此线程可以在获取锁超时以后，主动释放之前已经获得的所有的锁。通过这种方式，也可以很有效地避免死锁。还是按照之前的例子，时序图如下：

pthread_mutex_t mutex_A = PTHREAD_MUTEX_INITIALIZER;pthread_mutex_t mutex_B = PTHREAD_MUTEX_INITIALIZER;int main(){    pthread_t tidA, tidB;    //创建两个线程    pthread_create(&tidA, NULL, threadA_proc, NULL);    pthread_create(&tidB, NULL, threadB_proc, NULL);    pthread_join(tidA, NULL);    pthread_join(tidB, NULL);    printf("exit\n");    return 0;}

//线程函数 Avoid *threadA_proc(void *data){    printf("thread A waiting get ResourceA \n");    pthread_mutex_lock(&mutex_A);    printf("thread A got ResourceA \n");    sleep(1);    printf("thread A waiting get ResourceB \n");    pthread_mutex_lock(&mutex_B);    printf("thread A got ResourceB \n");    pthread_mutex_unlock(&mutex_B);    pthread_mutex_unlock(&mutex_A);    return (void *)0;}

//线程函数 Bvoid *threadB_proc(void *data){    printf("thread B waiting get ResourceB \n");    pthread_mutex_lock(&mutex_B);    printf("thread B got ResourceB \n");    sleep(1);    printf("thread B waiting  get ResourceA \n");    pthread_mutex_lock(&mutex_A);    printf("thread B got ResourceA \n");    pthread_mutex_unlock(&mutex_A);    pthread_mutex_unlock(&mutex_B);    return (void *)0;}

避免死锁:

使用资源有序分配法，来破环环路等待条件。

预防死锁的几种策略，会严重地损害系统性能。因此在避免死锁时，要施加较弱的限制，从而获得较满意的系统性能。由于在避免死锁的策略中，允许进程动态地申请资源。

因而，系统在进行资源分配之前预先计算资源分配的安全性。若此次分配不会导致系统进入不安全的状态，则将资源分配给进程；否则，进程等待。其中最具有代表性的避免死锁算法是银行家算法。
银行家算法：首先需要定义状态和安全状态的概念。系统的状态是当前给进程分配的资源情况。因此，状态包含两个向量Resource（系统中每种资源的总量）和Available（未分配给进程的每种资源的总量）及两个矩阵Claim（表示进程对资源的需求）和Allocation（表示当前分配给进程的资源）。
安全状态是指至少有一个资源分配序列不会导致死锁。
当进程请求一组资源时，假设同意该请求，从而改变了系统的状态，然后确定其结果是否还处于安全状态。如果是，同意这个请求；如果不是，阻塞该进程知道同意该请求后系统状态仍然是安全的。

检测死锁

首先为每个进程和每个资源指定一个唯一的号码；
然后建立资源分配表和进程等待表。

在 Linux 下，我们可以使用 pstack + gdb 工具来定位死锁问题。

pstack 命令可以显示每个线程的栈跟踪信息（函数调用过程），它的使用方式也很简单，只需要 pstack <pid> 就可以了。

可以看到，Thread 2 和 Thread 3 一直阻塞获取锁（pthread_mutex_lock）的过程，而且 pstack 多次输出信息都没有变化，那么可能大概率发生了死锁。

解除死锁:

当发现有进程死锁后，便应立即把它从死锁状态中解脱出来，常采用的方法有：

剥夺资源：从其它进程剥夺足够数量的资源给死锁进程，以解除死锁状态；
撤消进程：可以直接撤消死锁进程或撤消代价最小的进程，直至有足够的资源可用，死锁状态.消除为止；所谓代价是指优先级、运行代价、进程的重要性和价值等。

2. 用户态和内核态

用户态变为内核态：

系统调用

这是用户态进程主动要求切换到内核态的一种方式，用户态进程通过系统调用申请使用操作系统提供的服务程序完成工作，比如前例中fork()实际上就是执行了一个创建新进程的系统调用。而系统调用的机制其核心还是使用了操作系统为用户特别开放的一个中断来实现，例如Linux的int 80h中断。
异常

当CPU在执行运行在用户态下的程序时，发生了某些事先不可知的异常，这时会触发由当前运行进程切换到处理此异常的内核相关程序中，也就转到了内核态，比如缺页异常。
外围设备的中断

当外围设备完成用户请求的操作后，会向CPU发出相应的中断信号，这时CPU会暂停执行下一条即将要执行的指令转而去执行与中断信号对应的处理程序，如果先前执行的指令是用户态下的程序，那么这个转换的过程自然也就发生了由用户态到内核态的切换。比如硬盘读写操作完成，系统会切换到硬盘读写的中断处理程序中执行后续操作等。

3. 堆和栈的区别

堆与栈的区别有：

1、栈由系统自动分配，而堆是人为申请开辟；

2、栈获得的空间较小，而堆获得的空间较大；

3、栈由系统自动分配，速度较快，但程序员是无法控制的. 而堆是由new分配的内存, 一般速度比较慢,而且容易产生内存碎片,不过用起来最方便；

4、栈是连续的空间，而堆是不连续的空间。

1、栈区（stack）— 由编译器自动分配释放，存放函数的参数值，局部变量的值等。其操作方式类似于数据结构中的栈。

2、堆区（heap） — 一般由程序员分配释放， 若程序员不释放，程序结束时可能由OS回收 。注意它与数据结构中的堆是两回事，分配方式倒是类似于链表

使用栈就象我们去饭馆里吃饭，只管点菜（发出申请）、付钱、和吃（使用），吃饱了就走，不必理会切菜、洗菜等准备工作和洗碗、刷锅等扫尾工作，他的好处是快捷，但是自由度小。

使用堆就象是自己动手做喜欢吃的菜肴，比较麻烦，但是比较符合自己的口味，而且自由度大。比喻很形象，说的很通俗易懂，不知道你是否有点收获。

栈： 在函数调用时，第一个进栈的是主函数中后的下一条指令（函数调用语句的下一条可执行语句）的地址，然后是函数的各个参数，在大多数的C编译器中，参数是由右往左入栈的，然后是函数中的局部变量。注意静态变量是不入栈的。

当本次函数调用结束后，局部变量先出栈，然后是参数，最后栈顶指针指向最开始存的地址，也就是主函数中的下一条指令，程序由该点继续运行。

JVM

栈内存:栈内存首先是一片内存区域，存储的都是局部变量，凡是定义在方法中的都是局部变量（方法外的是全局变量），**for循环内部定义的也是局部变量**，是先加载函数才能进行局部变量的定义，所以方法先进栈，然后再定义变量，变量有自己的作用域，一旦离开作用域，变量就会被释放。**栈内存的更新速度很快，因为局部变量的生命周期都很短。**

1
2

   堆内存:存储的是数组和对象（其实数组就是对象），凡是new建立的都是在堆中，**堆中存放的都是实体（对象**），实体用于封装数据，而且是封装多个（实体的多个属性），如果一个数据消失，这个实体也没有消失，还可以用，
   所以堆是不会随时释放的，但是栈不一样，栈里存放的都是单个变量，变量被释放了，那就没有了。**堆里的实体虽然不会被释放，但是会被当成垃圾**，**Java有垃圾回收机制不定时的收取。**

4. 程序、进程、线程

程序是含有指令和数据的文件，被存储在磁盘或其他的数据存储设备中，也就是说程序是静态的代码。

进程是程序的一次执行过程，是系统运行程序的基本单位，因此进程是动态的。系统运行一个程序即是一个进程从创建，运行到消亡的过程。简单来说，一个进程就是一个执行中的程序，它在计算机中一个指令接着一个指令地执行着，同时，每个进程还占有某些系统资源如CPU时间，内存空间，文件，文件，输入输出设备的使用权等等。换句话说，当程序在执行时，将会被操作系统载入内存中。

线程是进程划分成的更小的运行单位。线程和进程最大的不同在于基本上各进程是独立的，而各线程则不一定，因为同一进程中的线程极有可能会相互影响。从另一角度来说，进程属于操作系统的范畴，主要是同一段时间内，可以同时执行一个以上的程序，而线程则是在同一程序内几乎同时执行一个以上的程序段。

5. 动态库与静态库

静态（函数）库 一般扩展名为（.a或.lib）,这类的函数库通常扩展名为libxxx.a或xxx.lib 。 这类库在编译的时候会直接整合到目标程序中，所以利用静态函数库编译成的文件会比较大，这类函数库最大的优点就是编译成功的可执行文件可以独立运行，而不再需要向外部要求读取函数库的内容；但是从升级难易度来看明显没有优势，如果函数库更新，需要重新编译。

动态函数库 动态函数库的扩展名一般为（.so或.dll），这类函数库通常名为libxxx.so或xxx.dll 。与静态函数库被整个捕捉到程序中不同，动态函数库在编译的时候，在程序里只有一个“指向”的位置而已，也就是说当可执行文件需要使用到函数库的机制时，程序才会去读取函数库来使用；也就是说可执行文件无法单独运行。这样从产品功能升级角度方便升级，只要替换对应动态库即可，不必重新编译整个可执行文件。

静态库特点总结如下：

静态库对函数库的链接是放在编译时期完成的。
程序在运行时与函数库再无瓜葛，移植方便。
浪费空间和资源，因为所有相关的目标文件与牵涉到的函数库被链接合成一个可执行文件。

动态库特点总结：

动态库把对一些库函数的链接载入推迟到程序运行的时期。
可以实现进程之间的资源共享。（因此动态库也称为共享库）
将一些程序升级变得简单。
甚至可以真正做到链接载入完全由程序员在程序代码中控制（显式调用）。

6. 锁-互斥锁、⾃旋锁、读写锁、乐观锁、悲观锁

互斥锁加锁失败后，线程会释放 CPU ，给其他线程；

⾃旋锁加锁失败后，线程会忙等待，直到它拿到锁；自旋锁是通过 CPU 提供的 CAS 函数（Compare And Swap）需要注意，在单核 CPU 上，需要抢占式的调度器（即不断通过时钟中断一个线程，运行其他线程）。否则，自旋锁在单 CPU 上无法使用，因为一个自旋的线程永远不会放弃 CPU。

对于互斥锁加锁失败⽽阻塞的现象，是由操作系统内核实现的。

互斥锁加锁失败时，会从⽤户态陷⼊到内核态，让内核帮我们切换线程，虽然简化了使⽤锁的难度，但是存在⼀定的性能开销成本。

那这个开销成本是什么呢？会有**两次线程上下⽂切换的成本，**线程的上下文切换的是什么？当两个线程是属于同一个进程，因为虚拟内存是共享的，所以在切换时，虚拟内存这些资源就保持不动，只需要切换线程的私有数据、寄存器等不共享的数据。

如果你能确定被锁住的代码执⾏时间很短，就不应该⽤互斥锁，⽽应该选⽤⾃旋

当加锁失败时，互斥锁⽤「线程切换」来应对，**⾃旋锁则⽤「忙等待」**来应对。

如果**只读取共享资源⽤「读锁」加锁，如果要修改共享资源则⽤「写锁」**加锁。

当「写锁」没有被线程持有时，多个线程能够并发地持有读锁，这⼤⼤提⾼了共享资源的访问效率，因为「读锁」是⽤于读取共享资源的场景，所以多个线程同时持有读锁也不会破坏共享资源的数据。

但是，⼀旦「写锁」被线程持有后，读线程的获取读锁的操作会被阻塞，⽽且其他写线程的获取写锁的操作也会被阻塞。

公平读写锁⽐较简单的⼀种⽅式是：⽤队列把获取锁的线程排队，不管是写线程还是读线程都按照先进先出的原则加锁即可，这样读线程仍然可以并发，也不会出现「饥饿」的现象。

前⾯提到的互斥锁、⾃旋锁、读写锁，都是属于悲观锁。

悲观锁做事⽐较悲观，它认为多线程同时修改共享资源的概率⽐较⾼，于是很容易出现冲突，所以访问共享资源前，先要上锁。

如果多线程同时修改共享资源的概率⽐较低，就可以采⽤乐观锁。

乐观锁做事⽐较乐观，它假定冲突的概率很低，它的⼯作⽅式是：先修改完共享资源，再验证这段时间内有没有发⽣冲突，如果没有其他线程在修改资源，那么操作完成，如果发现有其他线程已经修改过这个资源，就放弃本次操作。

可⻅，乐观锁的⼼态是，不管三七⼆⼗⼀，先改了资源再说。另外，你会发现乐观锁全程并没有加锁，所以它也叫⽆锁编程，比如在线⽂档。

实际上，我们常见的 SVN 和 Git 也是用了乐观锁的思想，先让用户编辑代码，然后提交的时候，通过版本号来判断是否产生了冲突，发生了冲突的地方，需要我们自己修改后，再重新提交。

乐观锁虽然去除了加锁解锁的操作，但是⼀旦发⽣冲突，重试的成本⾮常⾼，所以只有在冲突概率⾮常低，且加锁成本⾮常⾼的场景时，才考虑使⽤乐观锁。

7. fork()函数

fork（）函数通过系统调用创建一个与原来进程几乎完全相同的进程，copy一个进程，包括代码、数据和分配给进程的资源。

也就是两个进程可以做完全相同的事，但如果初始参数或者传入的变量不同，两个进程也可以做不同的事。

一个进程调用fork（）函数后，系统先给新的进程分配资源，例如存储数据和代码的空间。然后把原来的进程的所有值都复制到新的新进程中，只有少数值与原来的进程的值不同。相当于克隆了一个自己。

fork的实现分为以下两步

1. 复制进程资源 2. 执行该进程

复制进程的资源包括以下几步

进程控制块（PCB）：包含了进程的基本信息，如进程状态、程序计数器、堆栈指针等。
程序体：即代码段、数据段等，表示进程的可执行程序和数据。
用户栈：包含了函数调用、局部变量等信息。
内核栈：用于处理系统调用和中断时保存现场信息。
虚拟内存池：包括进程的地址空间，即进程可以使用的虚拟内存范围。
页表：用于将虚拟地址映射到物理地址的数据结构。

除了上述资源外，还有一些其他的资源也会被复制：

文件描述符表：指向文件的引用会被复制，但文件本身不会被复制。
信号处理设置：父进程设置的信号处理函数和信号屏蔽字会被复制到子进程中。
环境变量：父进程的环境变量会被复制到子进程中。
资源限制：如文件描述符数、CPU 时间等资源限制会被复制。

进行进程的话就比较简单了，只需要将其加入到就绪队列即可，接下来就等待cpu的调度了。

8. 计算机启动的时候内存做了什么？

内存映射，CPU 地址总线的宽度决定了可访问的内存空间的大小。

比如 16 位的 CPU 地址总线宽度为 20 位，地址范围是 1M。32 位的 CPU 地址总线宽度为 32 位，地址范围是 4G。你可以算算我们现在的 64 位机的地址范围。

内存中划分出了一片一片区域分配给外设，BIOS(基本输入输出系统)

BIOS 更狠，不但其空间被映射到了内存 0xC0000 - 0xFFFFF 位置，其里面的程序还占用了开头的一些区域. BIOS 程序的入口地址也就是开始地址是 0xFFFF0（人家就那么写的）

在你开机的一瞬间，CPU 的 PC 寄存器被强制初始化为 0xFFFF0。如果再说具体些**，CPU 将段基址寄存器 cs 初始化为 0xF000，将偏移地址寄存器 IP 初始化为 0xFFF0**，根据实模式下的最终地址计算规则，将段基址左移 4 位，加上偏移地址，得到最终的物理地址也就是抽象出来的 PC 寄存器地址为 0xFFFF0。

BIOS 被映射到了内存的某个位置，并且开机一瞬间 CPU 强制将自己的 pc 寄存器初始化为 BIOS 程序的入口地址, 跳转到物理地址 0xfe05b 处开始执行

这块代码会检测一些外设信息，并初始化好硬件，建立中断向量表并填写中断例程

BIOS 把控制权转交给排在第一位的存储设备。

所以 BIOS 负责加载了启动区，而启动区又负责加载真正的操作系统内核

按下开机键，CPU 将 PC 寄存器的值强制初始化为 0xffff0，这个位置是 BIOS 程序的入口地址（一跳）
该入口地址处是一个跳转指令，跳转到 0xfe05b 位置，开始执行（二跳）
执行了一些硬件检测工作后，最后一步将启动区内容加载到内存 0x7c00，并跳转到这里（三跳）
启动区代码主要是加载操作系统内核，并跳转到加载处（四跳）

①加电→打开电源开关，给主板和内部风扇供电。

②启动引导程序→CPU开始执行存储在ROM BIOS（基本输入输出系统）中的指令。

③开机自检→计算机对系统的主要部件进行诊断测试。

④加载操作系统→计算机将操作系统文件从磁盘读到RAM中。

⑤检查配置文件，定制操作系统的运行环境→读取配置文件，根据用户的设置对操作系统进行定制。

⑥准备读取命令和数据→计算机等待用户输入命令

9. 数据是如何拷贝到网卡的

image-20210707232134178

10.冯诺依曼体系结构

计算机处理的数据和指令一律用二进制数表示；
指令和数据不加区别混合存储在同一个存储器中；
顺序执行程序的每一条指令；
计算机硬件由运算器、控制器、存储器、输入设备和输出设备五大部分组成。

12. 用户堆栈和系统堆栈

内核栈是属于操作系统空间的一块固定区域，可以用于保存中断现场、保存操作系统子程序间相互调用的参数、返回值等。

用户栈是属于用户进程空间的一块区域，用户保存用户进程子程序间的相互调用的参数、返回值等。

**系统栈（也叫核心栈、内核栈）**是内存中属于操作系统空间的一块区域，其主要用途为：

(1)保存中断现场，对于嵌套中断，被中断程序的现场信息依次压入系统栈，中断返回时逆序弹出；

(2)保存操作系统子程序间相互调用的参数、返回值、返回点以及子程序(函数)的局部变量。

用户栈是用户进程空间中的一块区域，用于保存用户进程的子程序间相互调用的参数、返回值、返回点以及子程序(函数)的局部变量。

那么为什么不直接用一个栈，何必浪费那么多的空间呢？？原因有二：

（1）如果只用系统栈。系统栈一般大小有限，如果中断有16个优先级，那么系统栈一般大小为15（只需保存15个低优先级的中断，另一个高优先级中断处理程序处于运行），但用户程序子程序调用次数可能很多，那样15次子程序调用以后的子程序调用的参数、返回值、返回点以及子程序(函数)的局部变量就不能被保存，用户程序也就无法正常运行了。

（2）如果只用用户栈。我们知道系统程序需要在某种保护下运行，而用户栈在用户空间（即cpu处于用户态，而cpu处于核心态时是受保护的），不能提供相应的保护措施（或相当困难）。

核心程序的工作栈就是当前运行的用户进程的系统栈。每个进程都有自己的用户栈和系统栈。而且系统栈的大小是确定的（取决于系统允许的中断嵌套数量，即中断优先级个数）。

当系统因为系统调用（软中断）或硬件中断，CPU切换到特权工作模式，进程陷入内核态，进程使用的栈也要从用户栈转向系统栈。

从用户态到内核态要两步骤，首先是将用户堆栈地址保存到内核堆栈中，然后将CPU堆栈指针寄存器指向内核堆栈。

当由内核态转向用户态，步骤首先是将内核堆栈中得用户堆栈地址恢复到CPU堆栈指针寄存器中。

13. 电脑32位和64位有什么区别

1、计算能力不同：64位的系统理论上比32位系统快一倍，并且它们的内存寻址也不一样。

2、支持的最大运行内存不同：32位的电脑最大只支持4G（一般情况只能用3.25G左右），而64位的电脑则可以支持128G甚至更大。

3、运行的软件不同：32位的电脑只能运行32位的软件，而64位的电脑可以运行32位的软件也可以运行64位的软件。

4、支持的系统不同：32位电脑支持32位的系统，而64位的电脑支持支持32位的系统也支持64位的系统。

64 位相比 32 位 CPU 的优势在哪吗？64 位 CPU 的计算性能一定比 32 位 CPU 高很多吗？

64 位相比 32 位 CPU 的优势主要体现在两个方面：

64 位 CPU 可以一次计算超过 32 位的数字，而 32 位 CPU 如果要计算超过 32 位的数字，要分多步骤进行计算，效率就没那么高。

但是大部分应用程序很少会计算那么大的数字，所以只有运算大数字的时候，64 位 CPU 的优势才能体现出来，否则和 32 位 CPU 的计算性能相差不大。
64 位 CPU 可以寻址更大的内存空间，32 位 CPU 最大的寻址地址是 4G，即使你加了 8G 大小的内存，也还是只能寻址到 4G，而 64 位 CPU 最大寻址地址是 2^64，远超于 32 位 CPU 最大寻址地址的 2^32。

你知道软件的 32 位和 64 位之间的区别吗？再来 32 位的操作系统可以运行在 64 位的电脑上吗？64 位的操作系统可以运行在 32 位的电脑上吗？如果不行，原因是什么？

64 位和 32 位软件，实际上代表指令是 64 位还是 32 位的：

如果 32 位指令在 64 位机器上执行，需要一套兼容机制，就可以做到兼容运行了。但是如果 64 位指令在 32 位机器上执行，就比较困难了，因为 32 位的寄存器存不下 64 位的指令；
操作系统其实也是一种程序，我们也会看到操作系统会分成 32 位操作系统、64 位操作系统，其代表意义就是操作系统中程序的指令是多少位，比如 64 位操作系统，指令也就是 64 位，因此不能装在 32 位机器上。

总之，硬件的 64 位和 32 位指的是 CPU 的位宽，软件的 64 位和 32 位指的是指令的位宽。

14. CPU 执行程序的过程

第一步，CPU 读取「程序计数器」的值，这个值是指令的内存地址，然后 CPU 的**「控制单元」操作「地址总线」指定需要访问的内存地址**，接着通知内存设备准备数据，数据准备好后通过「数据总线」将指令数据传给 CPU，CPU 收到内存传来的数据后，将这个指令数据存入到「指令寄存器」。
第二步，CPU 分析「指令寄存器」中的指令，确定指令的类型和参数，如果是计算类型的指令，就把指令交给**「逻辑运算单元」运算**；如果是存储类型的指令，则交由「控制单元」执行；
第三步，CPU 执行完指令后，「程序计数器」的值自增，表示指向下一条指令。这个自增的大小，由 CPU 的位宽决定，比如 32 位的 CPU，指令是 4 个字节，需要 4 个内存地址存放，因此「程序计数器」的值会自增 4；

一个程序执行的时候，CPU 会根据程序计数器里的内存地址，从内存里面把需要执行的指令读取到指令寄存器里面执行，然后根据指令长度自增，开始顺序读取下一条指令。

现代大多数 CPU 都使用来流水线的方式来执行指令，所谓的流水线就是把一个任务拆分成多个小任务，于是一条指令通常分为 4 个阶段，称为 4 级流水

四个阶段的具体含义：

CPU 通过程序计数器读取对应内存地址的指令，这个部分称为 Fetch（取得指令）；
CPU 对指令进行解码，这个部分称为 Decode（指令译码）；
CPU 执行指令，这个部分称为 Execution（执行指令）；
CPU 将计算结果存回寄存器或者将寄存器的值存入内存，这个部分称为 Store（数据回写）；

上面这 4 个阶段，我们称为指令周期（Instrution Cycle），CPU 的工作就是一个周期接着一个周期，周而复始。

15. Linux内核 vs Windows内核

Linux 内核设计的理念主要有这几个点：

MutiTask，多任务
SMP，对称多处理
ELF，可执行文件链接格式
Monolithic Kernel，宏内核

MutiTask 的意思是多任务，代表着 Linux 是一个多任务的操作系统。

多任务意味着可以有多个任务同时执行，这里的**「同时」可以是并发或并行：**

对于单核 CPU 时，可以让每个任务执行一小段时间，时间到就切换另外一个任务，从宏观角度看，一段时间内执行了多个任务，这被称为并发。
对于多核 CPU 时，多个任务可以同时被不同核心的 CPU 同时执行，这被称为并行。

SMP 的意思是对称多处理，代表着每个 CPU 的地位是相等的，对资源的使用权限也是相同的，多个 CPU 共享同一个内存，每个 CPU 都可以访问完整的内存和硬件资源。

这个特点决定了 Linux 操作系统不会有某个 CPU 单独服务应用程序或内核程序，而是每个程序都可以被分配到任意一个 CPU 上被执行。

ELF 文件

ELF（Executable and Linkable Format，可执行和可链接格式）是一种用于存储可执行程序、共享库、目标代码和核心转储文件的标准文件格式。ELF 文件是在类 Unix 系统中广泛使用的一种二进制文件格式，用于表示可执行程序和库。

ELF 文件包含了以下几个主要部分：

ELF 文件头：包含了描述文件类型、目标体系结构、入口点地址等信息的结构。
程序头表：描述了可执行文件的段（segment）和段在内存中的加载位置、大小等信息。
节区头表：描述了文件中各个节（section）的信息，如代码段、数据段、符号表等。
节区：包含了程序的实际数据和代码，如可执行代码、全局变量、字符串等。
符号表：包含了程序中定义和引用的符号（如变量、函数名）的信息，用于链接时的符号解析。

ELF 文件的优点包括了灵活性和可扩展性，它能够支持多种目标体系结构和操作系统，同时也支持调试信息和动态链接等特性。由于这些优点，ELF 成为了现代 Unix 和类 Unix 系统中标准的二进制文件格式。

Monolithic Kernel

Monolithic Kernel 的意思是宏内核，Linux 内核架构就是宏内核，意味着 Linux 的内核是一个完整的可执行程序，且拥有最高的权限。

宏内核的特征是系统内核的所有模块，比如进程调度、内存管理、文件系统、设备驱动等，都运行在内核态。

Windows 和 Linux 一样，同样支持 MutiTask 和 SMP，但不同的是，Window 的内核设计是混合型内核，

对于内核的架构一般有这三种类型：

宏内核，包含多个模块，整个内核像一个完整的程序；
微内核，有一个最小版本的内核，一些模块和服务则由用户态管理；
混合内核，是宏内核和微内核的结合体，内核中抽象出了微内核的概念，也就是内核中会有一个小型的内核，其他模块就在这个基础上搭建，整个内核是个完整的程序；

Linux 的内核设计是采用了宏内核，Window 的内核设计则是采用了混合内核。

这两个操作系统的可执行文件格式也不一样， Linux 可执行文件格式叫作 ELF，Windows 可执行文件格式叫作 PE。

16 守护进程孤儿进程僵尸进程

守护进程

守护进程指在后台运行的，没有控制终端与之相连的进程。

它独立于控制终端，周期性地执行某种任务。

Linux的大多数服务器就是用守护进程的方式实现的，如web服务器进程http等，udevd负责维护/dev目录下的设备文件 , acpid负责电源管理，syslogd负责维护/var/log下的日志文件,

可以看出守护进程通常采用以d结尾的名字,表示Daemon。

精灵进程作用：提供服务。eg:内核线程：完成操作系统级别服务.

创建守护进程要点：

（1）让程序在后台执行。方法是调用fork（）产生一个子进程，然后使父进程退出。

（2）调用setsid（）创建一个新对话期。控制终端、登录会话和进程组通常是从父进程继承下来的，守护进程要摆脱它们，不受它们的影响，

方法是调用setsid（）使进程成为一个会话组长。setsid（）调用成功后，进程成为新的会话组长和进程组长，并与原来的登录会话、进程组和控制终端脱离。

（3）禁止进程重新打开控制终端。经过以上步骤，进程已经成为一个无终端的会话组长，但是它可以重新申请打开一个终端。为了避免这种情况发生，可以通过使进程不再是会话组长来实现。再一次通过fork（）创建新的子进程，使调用fork的进程退出。

**（4）关闭不再需要的文件描述符。**子进程从父进程继承打开的文件描述符。如不关闭，将会浪费系统资源，造成进程所在的文件系统无法卸下以及引起无法预料的错误。首先获得最高文件描述符值，然后用一个循环程序，关闭0到最高文件描述符值的所有文件描述符。

（6）子进程从父进程继承的文件创建屏蔽字可能会拒绝某些许可权。为防止这一点，使用unmask（0）将屏蔽字清零。

（7）处理SIGCHLD信号。对于服务器进程，在请求到来时往往生成子进程处理请求。如果子进程等待父进程捕获状态，则子进程将成为僵尸进程（zombie），从而占用系统资源。

如果父进程等待子进程结束，将增加父进程的负担，影响服务器进程的并发性能。在Linux下可以简单地将SIGCHLD信号的操作设为SIG_IGN。这样，子进程结束时不会产生僵尸进程。

孤儿进程

如果父进程先退出，子进程还没退出，那么子进程的父进程将变为init进程。（注：任何一个进程都必须有父进程）。

一个父进程退出，而它的一个或多个子进程还在运行，那么那些子进程将成为孤儿进程。孤儿进程将被init进程(进程号为1)所收养，并由init进程对它们完成状态收集工作。

僵尸进程

如果子进程先退出，父进程还没退出，那么子进程必须等到父进程捕获到了子进程的退出状态才真正结束，否则这个时候子进程就成为僵尸进程。

设置僵尸进程的目的是维护子进程的信息，以便父进程在以后某个时候获取。这些信息至少包括进程ID，进程的终止状态，以及该进程使用的CPU时间，所以当终止子进程的父进程调用wait或waitpid时就可以得到这些信息。

如果一个进程终止，而该进程有子进程处于僵尸状态，那么它的所有僵尸子进程的父进程ID将被重置为1（init进程）。继承这些子进程的init进程将清理它们（也就是说init进程将wait它们，从而去除它们的僵尸状态）。

如何避免僵尸进程？

通过signal(SIGCHLD, SIG_IGN)通知内核对子进程的结束不关心，由内核回收。如果不想让父进程挂

起，可以在父进程中加入一条语句：signal(SIGCHLD,SIG_IGN);表示父进程忽略SIGCHLD信号，该

信号是子进程退出的时候向父进程发送的。

父进程调用wait/waitpid等函数等待子进程结束，如果尚无子进程退出wait会导致父进程阻塞。waitpid可以通过传递WNOHANG使父进程不阻塞立即返回。

如果父进程很忙可以用signal注册信号处理函数，在信号处理函数调用wait/waitpid等待子进程退出。

通过两次调用fork。父进程首先调用fork创建一个子进程然后waitpid等待子进程退出，子进程再fork一个孙进程后退出。这样子进程退出后会被父进程等待回收，而对于孙子进程其父进程已经退出所以孙进程成为一个孤儿进程，孤儿进程由init进程接管，孙进程结束后，init会等待回收。

第一种方法忽略SIGCHLD信号，这常用于并发服务器的性能的一个技巧因为并发服务器常常fork很多子进程，子进程终结之后需要服务器进程去wait清理资源。如果将此信号的处理方式设为忽略，可让内核把僵尸子进程转交给init进程去处理，省去了大量僵尸进程占用系统资源

————————————————

1. 程序、进程、线程概念分别是什么。

程序是含有指令和数据的文件，被存储在磁盘或其他的数据存储设备中，也就是说程序是静态的代码。

进程是资源分配的基本单位，它是程序执行时的一个实例，在程序运行时创建；

线程是程序执行的最小单位，是进程的子任务，是进程的一个执行流，一个线程由多个线程组成的

具体来说：

进程是操作系统分配资源的单位，而线程是进程的一个实体，是CPU调度和分派的基本单位。
线程没有独立的内存单元，不能够独立执行，必须依存在应用程序中。
资源开销：每个进程都有独立的代码和数据空间（程序上下文），程序之间的切换会有较大的开销；线程可以看做轻量级的进程，同一类线程共享代码和数据空间，每个线程都有自己独立的运行栈和程序计数器（PC），线程之间切换的开销小。

计算机系统常见问题2

Fri, 10 Jan 2020 21:56:12 +0800

Linux的I/O模型介绍以及同步异步阻塞非阻塞的区别（超级重要）

https://blog.csdn.net/sqsltr/article/details/92762279

https://www.cnblogs.com/euphie/p/6376508.html

（IO过程包括两个阶段：

（1）内核从IO设备读写数据和

（2）进程从内核复制数据）

阻塞：调用IO操作的时候，如果缓冲区空或者满了，调用的进程或者线程就会处于阻塞状态直到IO可用并完成数据拷贝。
非阻塞：调用IO操作的时候，内核会马上返回结果，如果IO不可用，会返回错误，这种方式下进程需要不断轮询直到IO可用为止，但是当进程从内核拷贝数据时是阻塞的。
IO多路复用就是同时监听多个描述符，一旦某个描述符IO就绪（读就绪或者写就绪），就能够通知进程进行相应的IO操作，否则就将进程阻塞在select或者epoll语句上。
同步IO：同步IO模型包括阻塞IO，非阻塞IO和IO多路复用。特点就是当进程从内核复制数据的时候都是阻塞的。
异步IO：在检测IO是否可用和进程拷贝数据的两个阶段都是不阻塞的，进程可以做其他事情，当IO完成后内核会给进程发送一个信号。

Epoll是Linux进行IO多路复用的一种方式，用于在一个线程里监听多个IO源，在IO源可用的时候返回并进行操作。它的特点是基于事件驱动，性能很高。

epoll将文件描述符拷贝到内核空间后使用红黑树进行维护，同时向内核注册每个文件描述符的回调函数，当某个文件描述符可读可写的时候，将这个文件描述符加入到就绪链表里，并唤起进程，返回就绪链表到用户空间，由用户程序进行处理。

Epoll有三个系统调用：epoll_create(),epoll_ctl()和epoll_wait()。

eoll_create()函数在内核中初始化一个eventpoll对象，同时初始化红黑树和就绪链表。
epoll_ctl()用来对监听的文件描述符进行管理。将文件描述符插入红黑树，或者从红黑树中删除，这个过程的时间复杂度是log(N)。同时向内核注册文件描述符的回调函数。
epoll_wait()会将进程放到eventpoll的等待队列中，将进程阻塞，当某个文件描述符IO可用时，内核通过回调函数将该文件描述符放到就绪链表里，epoll_wait()会将就绪链表里的文件描述符返回到用户空间。

（4） IO复用的三种方法（select,poll,epoll）深入理解，包括三者区别，内部原理实现？

（1）select的方法介绍：select把所有监听的文件描述符拷贝到内核中，挂起进程。当某个文件描述符可读或可写的时候，中断程序唤起进程，select将监听的文件描述符再次拷贝到用户空间，然select后遍历这些文件描述符找到IO可用的文件。下次监控的时候需要再次拷贝这些文件描述符到内核空间。select支持监听的描述符最大数量是1024.

（2）poll使用链表保存文件描述符，其他的跟select没有什么不同。

（3）epoll将文件描述符拷贝到内核空间后使用红黑树进行维护，同时向内核注册每个文件描述符的回调函数，当某个文件描述符可读可写的时候，将这个文件描述符加入到就绪链表里，并唤起进程，返回就绪链表到用户空间。

详见 https://www.cnblogs.com/Anker/p/3265058.html

coredump产生的条件

shell资源控制限制，使用 ulimit -c 命令查看shell执行程序时的资源，如果为0，则不会产生coredump。可以用ulimit -c unlimited设置为不限大小。
读写越界，包括：数组访问越界，指针指向错误的内存，字符串读写越界
使用了线程不安全的函数，读写未加锁保护
错误使用指针转换
堆栈溢出

Linux理论上最多可以创建多少个进程？一个进程可以创建多少线程，和什么有关

（3）冯诺依曼结构有哪几个模块？分别对应现代计算机的哪几个部分？（百度安全一面）

存储器：内存
控制器：南桥北桥
运算器：CPU
输入设备：键盘
输出设备：显示器、网卡

如果要你实现一个mutex互斥锁你要怎么实现？

https://blog.csdn.net/kid551/article/details/84338619

实现mutex最重要的就是实现它的lock()方法和unlock()方法。我们保存一个全局变量flag，flag=1表明该锁已经锁住，flag=0表明锁没有锁住。

实现lock()时，使用一个while循环不断检测flag是否等于1，如果等于1就一直循环。然后将flag设置为1；unlock()方法就将flag置为0；

static int flag=0;

void lock(){
  while(TestAndSet(&flag,1)==1);
  //flag=1;
}
void unlock(){
  flag=0;
}
123456789

因为while有可能被重入，所以可以用TestandSet()方法。

int TestAndSet(int *ptr, int new) {
    int old = *ptr;
    *ptr = new;
    return old;
}

线程之间通信：

使用全局变量
使用信号机制
使用事件

进程之间同步：

https://www.cnblogs.com/sonic4x/archive/2011/07/05/2098036.html

信号量
管程

什么时候用多进程，什么时候用多线程

https://blog.csdn.net/yu876876/article/details/82810178

频繁修改：需要频繁创建和销毁的优先使用多线程
计算量：需要大量计算的优先使用多线程 因为需要消耗大量CPU资源且切换频繁，所以多线程好一点
相关性：任务间相关性比较强的用多线程，相关性比较弱的用多进程。因为线程之间的数据共享和同步比较简单。
多分布：可能要扩展到多机分布的用多进程，多核分布的用多线程。

但是实际中更常见的是进程加线程的结合方式，并不是非此即彼的。

孤儿进程是父进程退出后它的子进程还在执行，这时候这些子进程就成为孤儿进程。孤儿进程会被init进程收养并完成状态收集。
僵尸进程是指子进程完成并退出后父进程没有使用wait()或者waitpid()对它们进行状态收集，这些子进程的进程描述符仍然会留在系统中。这些子进程就成为僵尸进程。

协程就是子程序在执行时中断并转去执行别的子程序，在适当的时候又返回来执行。

这种子程序间的跳转不是函数调用，也不是多线程执行，所以省去了线程切换的开销，效率很高，并且不需要多线程间的锁机制，不会发生变量写冲突。

那协程的底层是怎么实现的，怎么使用协程？

协程进行中断跳转时将函数的上下文存放在其他位置中，而不是存放在函数堆栈里，当处理完其他事情跳转回来的时候，取回上下文继续执行原来的函数。

在执行malloc申请内存的时候，操作系统是怎么做的？/内存分配的原理说一下/malloc函数底层是怎么实现的？/进程是怎么分配内存的？

https://blog.csdn.net/yusiguyuan/article/details/39496057

从操作系统层面上看，malloc是通过两个系统调用来实现的： brk和mmap

brk是将进程数据段(.data)的最高地址指针向高处移动，这一步可以扩大进程在运行时的堆大小
mmap是在进程的虚拟地址空间中寻找一块空闲的虚拟内存，这一步可以获得一块可以操作的堆内存。

通常，分配的内存小于128k时，使用brk调用来获得虚拟内存，大于128k时就使用mmap来获得虚拟内存。

进程先通过这两个系统调用获取或者扩大进程的虚拟内存，获得相应的虚拟地址，在访问这些虚拟地址的时候，通过缺页中断，让内核分配相应的物理内存，这样内存分配才算完成。

在网络编程中不同字节序的机器发送和接收的顺序不同。

实现二维码登录通常涉及以下步骤：

生成二维码：
- 服务器端生成一个唯一的登录标识（如随机生成的Token或临时会话ID）。
- 使用生成的标识创建一个包含标识信息的二维码图像。
- 将二维码图像发送给客户端，以便用户扫描。
扫描二维码：
- 用户打开登录应用或扫描工具，并选择扫描二维码选项。
- 使用手机或摄像头扫描服务器生成的二维码。
验证二维码：
- 服务器端需要不断地轮询或等待客户端扫描并验证二维码。
- 当客户端扫描到二维码后，将扫描到的信息（通常是登录标识）发送回服务器。
创建登录会话：
- 服务器接收到扫描信息后，验证该信息是否有效且未过期。
- 如果验证通过，服务器创建一个登录会话，将用户标识与会话关联，并生成一个会话密钥。
返回登录结果：
- 服务器返回登录成功的响应，其中包括会话密钥或其他用于标识用户的信息。
- 客户端接收到登录成功的响应后，将会话信息存储在本地，以备后续请求使用。
保持会话状态：
- 服务器和客户端都需要保持会话状态，以便在后续请求中验证用户身份。
- 客户端通常会将会话信息存储在本地，而服务器会维护会话状态并提供相应的会话管理机制。
处理登录超时或失败：
- 如果用户长时间未扫描或扫描失败，服务器可以定期清除未使用的登录标识。
- 如果扫描后验证失败，服务器应该返回登录失败的响应，并可能要求用户重新扫描。
安全性考虑：
- 实现时需要考虑安全性问题，包括数据的传输加密、二维码生成的随机性、会话标识的有效期限制等，以防止恶意攻击。

请注意，二维码登录是一种方便的登录方式，但需要确保安全性和用户体验。每个应用可能会根据自己的需求和安全标准来实现二维码登录的细节。此外，二维码登录通常与单点登录（SSO）等身份认证机制结合使用，以实现更高级的用户身份管理和认证。

8G的int型数据，计算机的内存只有2G，怎么对它进行排序？（外部排序）（百度一面）

我们可以使用外部排序来对它进行处理。首先将整个文件分成许多份，比如说m份，划分的依据就是使得每一份的大小都能放到内存里。然后我们用快速排序或者堆排序等方法对每一份数据进行一个内部排序，变成有序子串。接着对这m份有序子串进行m路归并排序。

取这m份数据的最小元素，进行排序，输出排序后最小的元素到结果中，同时从该元素所在子串中读入一个元素，直到所有数据都被输出到结果中为止。

BitMap算法评价

优点：
1. 运算效率高，不进行比较和移位；
2. 占用内存少，比如最大的数MAX=10000000；只需占用内存为MAX/8=1250000Byte=1.25M。
缺点：
1. 所有的数据不能重复，即不可对重复的数据进行排序。（少量重复数据查找还是可以的，用2-bitmap）。
2. 所需要的空间随着最大元素的增大而增大，当数据类似（1，1000，10万）只有3个数据的时候，用bitmap时间复杂度和空间复杂度相当大，只有当数据比较密集时才有优势。
布隆过滤器原理与优点
布隆过滤器是一个比特向量或者比特数组，它本质上是一种概率型数据结构，用来查找一个元素是否在集合中，支持高效插入和查询某条记录。常作为针对超大数据量下高效查找数据的一种方法。

它的具体工作过程是这样子的：

假设布隆过滤器的大小为m（比特向量的长度为m），有k个哈希函数，它对每个数据用这k个哈希函数计算哈希，得到k个哈希值，然后将向量中相应的位设为1。在查询某个数据是否存在的时候，对这个数据用k个哈希函数得到k个哈希值，再在比特向量中相应的位查找是否为1，如果某一个相应的位不为1，那这个数据就肯定不存在。但是如果全找到了，则这个数据有可能存在。

为什么说有可能存在呢？

因为不同的数据经过哈希后可能有相同的哈希值，在比特向量上某个位置查找到1也可能是由于某个另外的数据映射得到的。

支持删除操作吗

目前布隆过滤器只支持插入和查找操作，不支持删除操作，如果要支持删除，就要另外使用一个计数变量，每次将相应的位置为1则计数加一，删除则减一。

布隆过滤器中哈希函数的个数需要选择。如果太多则很快所有位都置为1，如果太少会容易误报。

布隆过滤器的大小以及哈希函数的个数怎么选择？

k 为哈希函数个数，m 为布隆过滤器长度，n 为插入的元素个数，p 为误报率

计算机网络常见问题2

Sat, 21 Dec 2019 12:19:27 +0800

1. 对路由协议的了解与介绍。内部网关协议IGP包括RIP，OSPF，和外部网关协议EGP和BGP.

A

路由协议是指在计算机网络中用于确定数据包如何从源节点传输到目标节点的规则集合。常见的路由协议包括内部网关协议（IGP）和外部网关协议（EGP）。
1. 内部网关协议（IGP）：
  - RIP（路由信息协议）：RIP是一种基于距离向量的路由协议，使用跳数作为度量标准。每隔一段时间，路由器会向相邻路由器发送路由更新信息。RIP“路由信息协议(Route Information Protocol)”的简写，主要传递路由信息，通过每隔30秒广播一次路由表，维护相邻路由器的位置关系，同时根据收到的路由表信息使用动态规划的方式计算自己的路由表信息。RIP是一个距离矢量路由协议,最大跳数为16跳,16跳以及超过16跳的网络则认为目标网络不可达。
  - OSPF（开放最短路径优先）：OSPF是一种基于链路状态的路由协议，使用最短路径优先算法（Dijkstra算法）计算最佳路由。OSPF支持VLSM（可变长度子网掩码）和路由聚合。
2. 外部网关协议（EGP）：
  - EGP（外部网关协议）：EGP是一种早期的外部网关协议，已经不再广泛使用。
  - BGP（边界网关协议）：BGP是一种路径矢量协议，用于在不同自治系统之间交换路由信息。BGP是互联网核心路由协议，负责在全球范围内的路由选择。
这些协议在计算机网络中起着至关重要的作用，帮助数据包在网络中正确快速地传

UDP如何实现可靠传输

因为UDP是无连接的协议，所以在传输层上无法保证可靠传输，要想实现可靠传输，只能从应用层实现。需要实现seq/ack机制，重传机制和窗口确认机制。

就要接收方收到UDP之后回复个确认包，发送方有个机制，收不到确认包就要重新发送，每个包有递增的序号，接收方发现中间丢了包就要发重传请求，当网络太差时候频繁丢包，防止越丢包越重传的恶性循环，要有个发送窗口的限制，发送窗口的大小根据网络传输情况调整，调整算法要有一定自适应性。

2. 流量控制的介绍，采用滑动窗口会有什么问题（死锁可能，糊涂窗口综合征）？

所谓流量控制就是让发送方发送速率不要过快，让接收方来得及接收。利用TCP报文段中的窗口大小字段来控制发送方的发送窗口不大于接收方发回的窗口大小就可以实施流量控制。

考虑一种特殊的情况，就是接收方若没有缓存足够使用，就会发送零窗口大小的报文，此时发送放将发送窗口设置为0，停止发送数据。之后接收方有足够的缓存，发送了非零窗口大小的报文，但是这个报文在中途丢失的，那么发送方的发送窗口就一直为零导致死锁。

解决这个问题，TCP为每一个连接设置一个持续计时器（persistence timer）。只要TCP的一方收到对方的零窗口通知，就启动该计时器，周期性的发送一个零窗口探测报文段。对方就在确认这个报文的时候给出现在的窗口大小（注意：TCP规定，即使设置为零窗口，也必须接收以下几种报文段：零窗口探测报文段、确认报文段和携带紧急数据的报文段）。

3. 一个机器能够使用的端口号上限是多少，为什么？可以改变吗？那如果想要用的端口超过这个限制怎么办？

因为TCP的报文头部中源端口号和目的端口号的长度是16位，也就是可以表示2^16=65536个

不同端口号，因此TCP可供识别的端口号最多只有65536个。但是由于0到1023是知名服务端口，所以实际上还要少1024个端口号。

而对于服务器来说，可以开的端口号与65536无关，其实是受限于Linux可以打开的文件数量，并且可以通过MaxUserPort来进行配置

4. 对称密码和非对称密码体系

https://blog.csdn.net/qq_29689487/article/details/81634057

对称加密：加密和解密使用的密钥是同一个
- 优点：计算量小，算法速度快，加密效率高
- 缺点：密钥容易泄漏。不同的会话需要不同的密钥，管理起来很费劲
- 常用算法：DES，3DES，IDEA，CR4，CR5，CR6，AES
非对称加密：需要公钥和私钥，公钥用来加密，私钥用来解密
- 优点：安全，不怕泄漏
- 缺点：速度慢
- 常用算法：RSA，ECC，DSA

5. 数字证书的了解（高频）

权威CA使用**私钥将网站A的信息和消息摘要（签名S）**进行加密打包形成数字证书。

公钥给客户端。

网站A将自己的信息和数字证书发给客户端，客户端用CA的公钥对数字证书进行解密，得到签名S，与手动将网站的信息进行消息摘要得到的结果S*进行对比，如果签名一致就证明网站A可以信任。

6. 消息摘要算法列举一下，介绍MD5算法，为什么MD5是不可逆的，有什么办法可以加强消息摘要算法的安全性让它不那么容易被破解呢？（百度安全一面）

消息摘要算法有MD家族（MD2，MD4，MD5），SHA家族（SHA-1,SHA-256）和CRC家族（CRC8,CRC16,CRC32）等等
MD5算法介绍：

MD5以512位分组来处理输入的信息，且每一分组又被划分为若干个小分组（16个32位子分组），经过一些列的处理后，算法输出由四个散列值（32位分组组成的128位散列值。）

MD5首先将输入的信息分成若干个512字节长度的分组，如果不够就填充1和若干个0。
对每个512字节的分组进行循环运算。使用四个幻数对第一个分组的数据进行四轮变换，得到四个变量。
接下来对其中三个使用线性函数进行计算，与剩下一个相加，并赋值给其中某个变量，得到新的四个变量，重复16次这个过程，得到的四个变量作为幻数，与下一个分组进行相似的计算。
遍历所有分组后得到的四个变量即为结果。

详见：https://blog.csdn.net/weixin_39640298/article/details/84555814

为什么不可逆：因为MD5在进行消息摘要的过程中，数据与原始数据相比发生了丢失，所以不能由结果进行恢复。
加强安全性：加盐（加随机数）

7. 单条记录高并发访问的优化

服务器端：

使用缓存，如redis等
使用分布式架构进行处理
将静态页面和静态资源存储在静态资源服务器，需要处理的数据使用服务器进行计算后返回
将静态资源尽可能在客户端进行缓存
采用ngnix进行负载均衡 （nginx读作恩静埃克斯 = Engine X）

数据库端：

数据库采用主从赋值，读写分离措施
建立适当的索引
分库分表

8. 介绍一下ping的过程，分别用到了哪些协议（百度安全等）

详见：Ping原理与ICMP协议

ping是使用ICMP协议来进行工作的。 ICMP:网络控制报文协议

首先，ping命令会构建一个ICMP请求数据包，然后由ICMP协议将这个数据包连同目的IP地址源IP地址一起交给IP协议。
然后IP协议就会构建一个IP数据报，并且在映射表中查找目的IP对应的mac地址，将其交给数据链路层。
然后数据链路层就会构建一个数据帧，附上源mac地址和目的mac地址发送出去。

目的主机接收到数据帧后，就会检查包上的mac地址与本机mac是否相符，如果相符，就接收并把其中的信息提取出来交给IP协议，IP协议就会将其中的信息提取出来交给ICMP协议。然后构建一个ICMP应答包，用相同的过程发送回去。

9. TCP/IP的粘包与避免介绍一下

因为TCP为了减少额外开销，采取的是流式传输，所以接收端在一次接收的时候有可能一次接收多个包。而TCP粘包就是发送方的若干个数据包到达接收方的时候粘成了一个包。多个包首尾相接，无法区分。

导致TCP粘包的原因有三方面：

发送端等待缓冲区满才进行发送，造成粘包
接收方来不及接收缓冲区内的数据，造成粘包
由于TCP协议在发送较小的数据包的时候，会将几个包合成一个包后发送

避免粘包的措施：

通过编程，强制使TCP发生数据传送，不必等到缓冲区满
优化接收方接收数据的过程，使其来得及接收数据包，包括提高接收进程优先级等
设置固定长度的报文 或者 设置报文头部指示报文的长度。

10. 说一下TCP的封包和拆包

因为TCP是无边界的流传输，所以需要对TCP进行封包和拆包，确保发送和接收的数据不粘连。

封包：封包就是在发送数据报的时候为每个TCP数据包加上一个包头，将数据报分为包头和包体两个部分。包头是一个固定长度的结构体，里面包含该数据包的总长度。
拆包：接收方在接收到报文后提取包头中的长度信息进行截取。

计算机系统学习总结

Thu, 19 Dec 2019 20:20:52 +0800

1. 总体概念

1.1 操作系统的特性

四个特性：并发、共享、虚拟、异步。

并发：同一段时间内(时间片轮转算法)多个程序执行。程序并发性体现在两个方面： 用户程序与用户程序之间的并发执行。用户程序与操作系统程序之间的并发。
共享：系统中的资源可以被内存中多个并发执行的进线程共同使用。
虚拟：通过时分复用（虚拟处理机、虚拟设备）以及空分复用（如虚拟内存，虚拟磁盘）技术实现把一个物理实体虚拟为多个。
异步：系统中的进程是以走走停停的方式执行的，且以一种不可预知的速度推进。（同步就是实时处理，比如打电话，异步就是分时处理，比如发短信）

1.2 操作系统的主要功能

操作系统的本质是对资源的管理。包括了：

处理器管理：以进程为单位分配资源，
存储器管理：也叫内存管理
设备管理：完成所有的IO请求
文件管理：包括磁盘存储空间管理，文件读写管理等等

1.3 用户态和内核态

从整体上讲，操作系统一般可分为**内核（kernel）和外壳（shell）**两大部分。

内核态与用户态是操作系统的两种运行级别,

用户态：当进程在执行用户自己的代码时，则称其处于用户态，这时cpu访问资源有限，运行在用户态下的程序不能直接访问操作系统内核数据结构和程序。

内核态：当一个任务(进程)执行系统调用而陷入内核代码中执行时，我们就称进程处于内核状态，这时cpu可以访问计算机的任何资源。

当程序运行在0级特权级上时，就可以称之为运行在内核态，CPU将指令分为特权指令和非特权指令，

对于那些危险的指令，只允许操作系统及其相关模块使用，普通的应用程序只能使用那些不会造成灾难的指令。比如清内存、设置时钟。运行在用户态下的程序不能直接访问操作系统内核数据结构和程序。

当程序运行在3级特权级上时，就可以称之为运行在用户态，因为这是最低特权级，是普通的用户进程运行的特权级，大部分用户直接面对的程序都是运行在用户态；

两种状态的主要区别

处于用户态执行时，进程所能访问的内存空间和对象受到限制，其所处于占有的处理机是可被抢占的 ；

而处于内核态执行中的进程，则能访问所有的内存空间和对象，且所占有的处理机是不允许被抢占的。

用户态切换到内核态有三种情况：主动，被动，被迫

系统调用：用户态进程主动要求切换到内核态申请使用操作系统提供的服务程序完成工作的一种方式，fork()实际上就是执行了一个创建新进程的系统调用。（主动）
异常：当前运行进程切换到处理此异常的内核相关程序（被迫）
外围设备中断：当外围设备完成用户请求的操作后，会向CPU发出相应的中断信号，这时CPU会暂停执行下一条即将要执行的指令转而去执行与中断信号对应的处理程序。 如果先前执行的指令是用户态下的程序，那么这个转换的过程自然也就发生了由用户态到内核态的切换。比如硬盘读写操作完成，系统会切换到硬盘读写的中断处理程序中执行后续操作等。（被动）

从触发方式上看，可以认为存在前述3种不同的类型。

但是从最终实际完成由用户态到内核态的切换操作上来说，涉及的关键步骤是完全一致的，没有任何区别。

都相当于执行了一个中断响应的过程，因为系统调用实际上最终是中断机制实现的，而异常和中断的处理机制基本上也是一致的，关于它们的具体区别这里不再赘述。关于中断处理机制的细节和步骤这里也不做过多分析。

涉及到由用户态切换到内核态的步骤：需要注意的是，内核态堆栈仅用于内核例程，Linux内核另外为中断提供了单独的硬中断栈和软中断栈 [1] 从当前进程的描述符中提取其内核栈的ss0及esp0信息。（ss0段选择子，用于指示内核堆栈所在的段描述符，esp堆栈是一个32位寄存器，存储了内核模式下的堆栈顶部地址指针) [2] 使用ss0和esp0指向的内核栈将当前进程的cs,eip,eflags,ss,esp信息保存起来，这个过程也完成了由用户栈到内核栈的切换过程，同时保存了被暂停执行的程序的下一条指令。 [3] 将先前由中断向量检索得到的中断处理程序的cs,eip信息装入相应的寄存器，开始执行中断处理程序，这时就转到了内核态的程序执行了。

（因为内核控制路径使用很少的栈空间，所以只需要几千个字节的内核态堆栈。需要注意的是，内核态堆栈仅用于内核例程，Linux内核另外为中断提供了单独的硬中断栈和软中断栈）

寄存器常见缩写：

1. PC - Program Counter（程序计数器）
2. SP - Stack Pointer（栈指针）
3. IR - Instruction Register（指令寄存器）
4. PSW - Program Status Word（程序状态字）
5. ACC - Accumulator（累加器）
6. R0, R1, R2, ... - General Purpose Registers（通用寄存器）
7. MAR - Memory Address Register（存储器地址寄存器）
8. MDR - Memory Data Register（存储器数据寄存器）
9. MSR - Machine Status Register（机器状态寄存器）
10. SR - Status Register（状态寄存器）
11. CR - Control Register（控制寄存器）
12. EFLAGS - Extended Flags Register（扩展标志寄存器）
13. FLAGS - Flags Register（标志寄存器）
14. XMM - Extended Multimedia Register（扩展多媒体寄存器）
15. FPU - Floating Point Unit（浮点运算单元）
16. MMX - Multimedia Extensions（多媒体扩展寄存器）
17. GP - Global Pointer（全局指针）
18. BP - Base Pointer（基址指针）
19. SP - Stack Pointer（栈指针）
20. IP - Instruction Pointer（指令指针）

2. 线程与进程

2.1 线程，进程，协程

进程是资源分配的基本单位，它是程序执行时的一个实例，在程序运行时创建；

线程是程序执行的最小单位，是进程的子任务，是进程的一个执行流，一般来说一个进程由多个线程组成的。

具体来说：

定义，资源隔离，创建销毁开销，切换开销通信和同步，并发性和并行性，故障影响，使用场景

进程是操作系统分配资源的单位，而线程是进程的一个实体，是CPU调度和分派的基本单位。
线程没有独立的内存单元，只拥有一点在运行中必不可少的资源，如寄存器和运行栈，不能够独立执行，必须依存在进程中。
执行过程：每个独立的进程有程序运行的入口、顺序执行序列和程序出口。但是线程不能独立执行，必须依存在应用程序中，由应用程序提供多个线程执行控制，两者均可并发执行。
资源开销：每个进程都有独立的代码和数据空间（程序上下文），程序之间的切换会有较大的开销；
线程可以看做轻量级的进程，同一类线程共享代码和数据空间，每个线程都有自己独立的运行栈和程序计数器（PC），线程之间切换的开销小。
包含关系：如果一个进程内有多个线程，则执行过程不是一条线的，而是多条线（线程）共同完成的；线程是进程的一部分，所以线程也被称为轻权进程或者轻量级进程。
影响关系：一个进程崩溃后，在保护模式下不会对其他进程产生影响，但是一个线程崩溃整个进程都死掉。所以多进程要比多线程健壮。

对于操作系统来说，一个任务就是一个进程(Process)，比如使用Word。

而一个进程可能不只干一件事（比如word既要打字又要检查拼写），这种进程内的多个子任务就是线程（Thread），进程是程序的一次执行过程，是系统运行程序的基本单位，因此进程是动态的。

系统运行一个程序即是一个进程从创建，运行到消亡的过程。简单来说，一个进程就是一个执行中的程序，它在计算机中一个指令接着一个指令地执行着，同时，每个进程还占有某些系统资源如CPU时间，内存空间，文件，文件，输入输出设备的使用权等等。

换句话说，当程序在执行时，将会被操作系统载入内存中。

Q: 一个进程最多可以创建多少个线程？

进程的虚拟内存空间上限，因为创建一个线程，操作系统需要为其分配一个栈空间，如果线程数量越多，所需的栈空间就要越大，那么虚拟内存就会占用的越多。
系统参数限制，虽然 Linux 并没有内核参数来控制单个进程创建的最大线程个数，但是有系统级别的参数来控制整个系统的最大线程个数。

多线程

举个例子，假设要编写一个视频播放器软件，那么该软件功能的核心模块有三个：

从视频文件当中读取数据；
对读取的数据进行解压缩；
把解压缩后的视频数据播放出来；
播放出来的画面和声音会不连贯，因为当 CPU 能力不够强的时候，Read 的时候可能进程就等在这了，这样就会导致等半天才进行数据解压和播放；
各个函数之间不是并发执行，影响资源的使用效率；

Q: 多线程的好处:

并发执行，资源共享，核心利用，多任务场景，代码模块化，提高响应性

通俗地讲例子：

1.使用线程可以把占据时间长的程序中的任务放到后台去处理

2.用户界面更加吸引人,这样比如用户点击了一个按钮去触发某件事件的处理,可以弹出一个进度条来显示处理的进度

3.程序的运行效率可能会提高

4.在一些等待的任务实现上如用户输入,文件读取和网络收发数据等, 线程就比较有用了。

线程主要优点：

一个进程中可以同时存在多个线程；
各个线程之间可以并发执行；
各个线程之间可以共享地址空间和文件等资源；

Q: 多线程的缺点:

竞态条件，死锁和活锁，通信复杂，调试困难，性能下降，不确定性

如果有大量的线程,大量的上下文切换会影响性能,因为操作系统需要在它们之间切换.
更多的线程需要更多的内存空间
线程中止需要考虑对程序运行的影响. 当进程中的一个线程崩溃时，会导致其所属进程的所有线程崩溃（这里是针对 C/C++ 语言，Java语言中的线程奔溃不会造成进程崩溃）
通常块模型数据是在多个线程间共享的, 需要防止线程死锁情况的发生

Q1. 进程中的一个线程崩溃之后所有线程都会崩溃吗？

这个不是必定发生的，假设一个进程启动了a,b,c三个线程，只要这三个线程之间的其中一个在运行过程中触发了unix的信号，比如除0异常，违规访问内存触发段错误等等，都会使得os向进程发送特定的信号，进程默认的行为是在接收到这些信号的时候退出，表象就是你所说的一个线程奔溃导致其他线程奔溃了。

但是如果a线程的奔溃没有触发操作系统向进程发送信号或者在进程中已经提前注册了对应信号的回调函数(此时收到信号进程不会按默认行为退出而且执行预设的回调函数)，那么其他两个线程还是能正常地运行。

大部分情况下，其他线程并不会自己崩溃，而是操作系统检测到异常，会kill掉进程，其他线程就一起被干掉了。

小部分情况下，一个线程出错，破坏了进程中其他线程的内存，导致其他线程出现严重错误，被操作系统检测到，然后连同进程一起干掉。

进程是由内核管理和调度的，所以进程的切换只能发生在内核态。

进程上下文切换开销

Q: 为什么物理内存只有 2G，进程的虚拟内存却可以使用 25T 呢？

因为虚拟内存并不是全部都映射到物理内存的，

程序是有局部性的特性，也就是某一个时间只会执行部分代码，所以只需要映射这部分程序就好

32 位系统，用户态的虚拟空间只有 3G，如果创建线程时分配的栈空间是 10M，那么一个进程最多只能创建 300 个左右的线程。
64 位系统，用户态的虚拟空间大到有 128T，理论上不会受虚拟内存大小的限制，而会受系统的参数或性能限制。

总结：

一个程序至少有一个进程, 一个进程至少有一个线程。hh
进程在执行过程中拥有独立的内存单元，而多个线程共享内存。同一进程内的线程共享内存和文件，因此它们之间相互通信无须调用内核
引入线程的好处： 线程快！创建、终止、切换都很快！虽然线程拥有单独的程序运行入口，出口，但不能独立执行。

(1)用户级上下文: 正文、数据、用户堆栈以及共享存储区；

(2)寄存器上下文: 通用寄存器、程序寄存器(IP)、处理器状态寄存器(EFLAGS)、栈指针(ESP)；

(3)系统级上下文: 进程控制块task_struct、内存管理信息(mm_struct、vm_area_struct、pgd、pte)、内核栈。

协程和线程

一个线程可以多个协程，一个进程也可以单独拥有多个协程。
线程进程都是同步机制，而协程则是异步。
协程能保留上一次调用时的状态，每次过程重入时，就相当于进入上一次调用的状态。
线程是抢占式，而协程是非抢占式的，所以需要用户自己释放使用权来切换到其他协程，因此同一时间其实只有一个协程拥有运行权，相当于单线程的能力。
协程并不是取代线程, 而且抽象于线程之上, 线程是被分割的CPU资源, 协程是组织好的代码流程, 协程需要线程来承载运行, 线程是协程的资源, 但协程不会直接使用线程, 协程直接利用的是执行器(Interceptor), 执行器可以关联任意线程或线程池, 可以使当前线程, UI线程, 或新建新程.。
线程是协程的资源。协程通过Interceptor来间接使用线程这个资源。

2.2 进程有哪些状态，转换条件是什么？

就绪状态：进程获得了除CPU之外的一切所需资源

运行状态：一个CPU的一个核只能有一个进程处于运行状态。

阻塞状态，又称等待状态：进程需要其他资源或正在等待某一事件发生而暂停运行。如等待某资源为可用（不包括处理机）或等待输入/输出完成。即使处理机空闲，该进程也不能运行。

注意区别就绪状态和等待状态：

就绪状态是指进程仅缺少处理机，只要获得处理机资源就立即执行；而等待状态是指进程需要其他资源（除了处理机）或等待某一事件。

Sleep()函数和wait()函数的区别

（1）属于不同的两个类，sleep()方法是线程类（Thread）的静态方法，wait()方法是Object类里的方法。

（2）sleep()方法不会释放锁，wait()方法释放对象锁。

（3）sleep()方法可以在任何地方使用，wait()方法则只能在同步方法或同步块中使用。

（4）sleep()使线程进入阻塞状态（线程睡眠），wait()方法使线程进入等待队列（线程挂起），也就是阻塞类别不同。

join()方法： join()方法使调用该方法的线程在此之前执行完毕，也就是等待该方法的线程执行完毕后再往下继续执行。注意该方法也需要捕捉异常。

yield()方法:该方法与sleep()类似，都是可以让当前正在运行的线程暂停，区别在于yield()方法不会阻塞该线程，它只是将线程转换成就绪状态，让系统的调度器重新调度一次，并且yield()方法只能让优先级相同或许更高的线程有执行的机会。

2.3 进程间通信

IPC(Inter process communication)问题，主要是指进程间交换数据的方式。

进程是相互独立的，并不需要条件变量、互斥锁这些机制，要锁也是文件锁这种大锁。

而线程需要互斥锁的原因是：线程之间的资源室共享的，需要程序员来完成变量级别的同步。

进程间通信分为低级通信和高级通信。

低级通信：信号量
高级通信：
- 管道
- 消息队列
- 共享内存
信号套接字

管道(pipe)

管道是一种半双工的通信方式，数据只能单向流动，而且只能在具有亲缘关系的进程间使用。进程的亲缘关系通常是指父子进程关系。

管道是指用于连接一个读进程和一个写进程的一个共享文件，又名pipe文件，以字符流形式将数据写入文件。

管道分为无名管道和有名管道：匿名管道就是内核⾥⾯的⼀串缓存。从管道的⼀段写⼊的数据，实际上是缓存在内核中的，另⼀端读取，也就是从内核中读取这段数据。另外，管道传输的数据是⽆格式的流且⼤⼩受限。

对于匿名管道，它的通信范围是存在⽗⼦关系的进程。因为管道没有实体，也就是没有管道⽂件，只能通过 fork 来复制⽗进程 fd ⽂件描述符，来达到通信的⽬的。

另外，对于命名管道，它可以在不相关的进程间也能相互通信。因为命令管道，提前创建了⼀个类型为管道的设备⽂件，在进程⾥只要使⽤这个设备⽂件，就可以相互通信。在 shell ⾥⾯执⾏ A | B 命令的时候，A 进程和 B 进程都是 shell 创建出来的⼦进程，A 和 B 之间不存在⽗⼦关系，它俩的⽗进程都是 shell。

匿名管道是半双工的通信方式，数据只能单向流动，只能在父子进程中流通；
有名管道也是半双工，但是它允许无亲缘关系进程间通信。

通信⽅式是效率低的，因此管道不适合进程间频繁地交换数据。

所谓的管道，就是内核⾥⾯的⼀串缓存。 读写效率低，因此管道不适合进程间频繁地交换数据。

创建的⼦进程会复制⽗进程的⽂件描述符。

对于匿名管道，它的通信范围是存在⽗⼦关系的进程，

对于命名管道，它可以在不相关的进程间也能相互通信。

不管是匿名管道还是命名管道，进程写⼊的数据都是缓存在内核中，另⼀个进程读取数据时候⾃然也是从内核中获取，同时通信数据都遵循先进先出原则。

消息队列(messagequeue)

消息队列是由消息的链表，存放在内核中并由消息队列标识符标识，消息体是⽤户⾃定义的数据类型。

消息队列克服了信号传递信息少、管道只能承载无格式字节流以及缓冲区大小受限等缺点。

消息队列指的是进程间的数据交换是以格式化的消息(Message)为单位的，再由消息组成的链表，形成队列。

消息队列是保存在内核中的消息链表

⼀：通信不及时

⼆：消息也有⼤⼩限制，这同样也是消息队列通信不⾜的点，

三：消息队列通信过程中，存在⽤户态与内核态之间的数据拷⻉开销。

消息队列不适合⽐较⼤数据的传输，因为在内核中每个消息体都有⼀个最⼤⻓度的限制，同时所有队列所包含的全部消息体的总⻓度也是有上限。

共享内存(shared memory)

共享内存的机制，就是拿出⼀块虚拟地址空间来，映射到相同的物理内存中，这段共享内存由一个进程创建，但多个进程都可以访问。

共享内存是最快的 IPC 方式，它是针对其他进程间通信方式运行效率低而专门设计的。

⽤了共享内存通信⽅式，带来新的问题，那就是如果多个进程同时修改同⼀个共享内存，很有可能就冲突

例如两个进程都同时写⼀个地址，那先写的那个进程会发现内容被别⼈覆盖了。

它往往与其他通信机制，如信号量，配合使用，来实现进程间的同步和通信。

共享内存指在通信的进程之间存在一块可直接访问的共享空间，通过对这片共享空间进行写/读操作实现进程之间的信息交换。

在对共享空间进行写/读操作时，需要使用同步互斥工具**（如 P操作、V操作）**，对共享空间的写/读进行控制。

P（S）：①将信号量S的值减1，即S=S-1；

②如果S>=0，则该进程继续执行；否则该进程置为等待状态，排入等待队列。

V（S）：①将信号量S的值加1，即S=S+1；

②如果S>0，则该进程继续执行；否则释放队列中第一个等待信号量的进程。

信号量(semaphore)

信号量是一个计数器，可以用来控制多个进程对共享资源的访问。它常作为一种锁机制，防止某进程正在访问共享资源时，其他进程也访问该资源。因此，主要作为进程间以及同一进程内不同线程之间的同步手段。

信号量是一个计数器，防止多个进程将资源拿光，防止某进程正在访问共享资源时，其他进程也访问该资源。

为了防⽌多进程竞争共享资源，⽽造成的数据错乱，所以需要保护机制，使得共享的资源，在任意时刻只能被⼀个进程访问。正好，信号量就实现了这⼀保护机制。

⼀个是 P 操作，这个操作会把信号量减去 1，相减后如果信号量 < 0，则表明资源已被占⽤，进程需

阻塞等待；相减后如果信号量 >= 0，则表明还有资源可使⽤，进程可正常继续执⾏。

另⼀个是 V 操作，这个操作会把信号量加上 1，相加后如果信号量 <= 0，则表明当前有阻塞中的进程，于是会将该进程唤醒运⾏；相加后如果信号量 > 0，则表明当前没有阻塞中的进程；

信号初始化为 1 ，就代表着是互斥信号量，它可以保证共享内存在任何时刻只有⼀个进程在访问，这就很好的保护了共享内存。

信号初始化为 0 ，就代表着是同步信号量，它可以保证进程 A 应在进程 B 之前执⾏

信号 (sinal)

**信号是一种比较复杂的通信方式，用于通知接收进程某个事件已经发生。**上⾯说的进程间通信，都是常规状态下的⼯作模式。

**对于异常情况下的⼯作模式，就需要⽤「信号」的⽅**式来通知进程。信号是进程间通信机制中唯⼀的异步通信机制，

1.执⾏默认操作。Linux 对每种信号都规定了默认操作，例如，上⾯列表中的 SIGTERM 信号，就是终⽌进程的意思。

2.捕捉信号。我们可以为信号定义⼀个信号处理函数。当信号发⽣时，我们就执⾏相应的信号处理函数。

3.忽略信号。当我们不希望处理某些信号的时候，就可以忽略该信号，不做任何处理。

有两个信号是应⽤进程⽆法捕捉和忽略的，即 SIGKILL 和 SEGSTOP ，它们⽤于在任何时候中断或结束某⼀进程。

Socket(套接字)

套接口也是一种进程间通信机制，与其他通信机制不同的是，它可用于不同设备及其间的进程通信。

那要想跨⽹络与不同主机上的进程之间通信，就需要 Socket 通信了。

服务端和客户端初始化 socket，得到文件描述符；
服务端调用 bind，绑定 IP 地址和端口，协议;
服务端调用 listen，进行监听；
服务端调用 accept，等待客户端连接；
客户端调用 connect，向服务器端的地址和端口发起连接请求；
服务端 accept 返回用于传输的 socket 的文件描述符；
客户端调用 write 写入数据；服务端调用 read 读取数据；
客户端断开连接时，会调用 close，那么服务端 read 读取数据的时候，就会读取到了 EOF，待处理完数据后，服务端调用 close，表示连接关闭。

image-20210706201229857

2.4 进程间同步（通信主要为了同步）

多进程虽然提高了系统资源利用率和吞吐量，但是由于进程的异步性可能造成系统的混乱。进程同步的任务就是对多个相关进程在执行顺序上进行协调。

进程是相互独立的，所以进程间通信大多不需要锁，需要的锁也是文件锁之类的“大锁”，并不需要条件变量、互斥锁这些机制来同步

2.5 线程间同步和通信

由于线程间的资源可以共享，同步的方式就会更加细致：

互斥量 互斥与临界区很相似，但是使用时相对复杂一些（互斥量为内核对象），不仅可以在同一应用程序的线程间实现同步，还可以在不同的进程间实现同步，从而实现资源的安全共享。由于互斥量是内核对象，因此其可以进行进程间通信，同时还具有一个很好的特性，就是在进程间通信时完美的解决了“遗弃”问题
信号量，只能用于一个资源的互斥访问，不能实现多个资源的多线程互斥问题。信号量的用法和互斥的用法很相似，不同的是它可以同一时刻允许多个线程访问同一个资源，PV操作。
读写锁，可以被多个读者拥有，但是只能被一个写者拥有的锁
条件变量，线程 A 等待某个条件并挂起，直到线程 B 设置了这个条件，并通知条件变量，然后线程 A 被唤醒
原子操作PV：
通道：
事件：

1. 临界区

每个进程中访问临界资源的那段程序称为临界区，一次仅允许一个进程使用的资源称为临界资源。

解决冲突的办法：

如果有若干进程要求进入空闲的临界区，一次仅允许一个进程进入，如已有进程进入自己的临界区，则其它所有试图进入临界区的进程必须等待；
进入临界区的进程要在有限时间内退出。
如果进程不能进入自己的临界区，则应让出CPU，避免进程出现“忙等”现象。

临界区指的是一个访问共用资源（例如：共用设备或是共用存储器）的程序片段，而这些共用资源又无法同时被多个线程访问的特性

任何想进⼊临界区的线程，必须先执⾏加锁操作。 若加锁操作顺利通过，则线程可进⼊临界区；

在完成对临界资源的访问后再执⾏解锁操作，以释放该临界资源。

互斥锁加锁失败后，线程会释放 CPU ，给其他线程；
自旋锁加锁失败后，线程会忙等待，直到它拿到锁；

当获取不到锁时，线程就会⼀直 wile 循环，不做任何事情，所以就被称为**「忙等待锁」，也被称为⾃旋锁（spin lock）**。

既然不想⾃旋，那当没获取到锁的时候，就把当前线程放⼊到锁的等待队列，然后执⾏调度程序，把 CPU让给其他线程执⾏。（互斥锁）

临界区对应着一个CcriticalSection对象。当线程需要访问保护数据时，调用EnterCriticalSection函数；当对保护数据的操作完成之后，调用LeaveCriticalSection函数释放对临界区对象的拥有权，以使另一个线程可以夺取临界区对象并访问受保护的数据。

关键段对象会记录拥有该对象的线程句柄即其具有“线程所有权”概念，即进入代码段的线程在leave之前，可以重复进入关键代码区域。所以关键段可以用于线程间的互斥，但不可以用于同步（同步需要在一个线程进入，在另一个线程leave）

2. 互斥量

互斥锁(又名互斥量）强调的是资源的访问互斥：互斥锁是用在多线程多任务互斥的，一个线程占用了某一个资源，那么别的线程就无法访问，直到这个线程unlock，其他的线程才开始可以利用这个资源。

比如对全局变量的访问，有时要加锁，操作完了，在解锁。有的时候锁和信号量会同时使用的。

也就是说，信号量不一定是锁定某一个资源，而是流程上的概念，比如：有A,B两个线程，B线程要等A线程完成某一任务以后再进行自己下面的步骤，这个任务并不一定是锁定某一资源，还可以是进行一些计算或者数据处理之类。而线程互斥量则是“锁住某一资源”的概念，在锁定期间内，其他线程无法对被保护的数据进行操作。在有些情况下两者可以互换。

在linux下, 线程的互斥量数据类型是pthread_mutex_t. 在使用前, 要对它进行初始化:

对于静态分配的互斥量, 可以把它设置为PTHREAD_MUTEX_INITIALIZER, 或者调用pthread_mutex_init.

对于动态分配的互斥量, 在申请内存(malloc)之后, 通过pthread_mutex_init进行初始化, 并且在释放内存(free)前需要调用pthread_mutex_destroy.采用互斥对象机制

只有拥有了互斥对象的线程才有访问资源的权限。因为互斥对象只有一个

所以可以保证公共资源不会被多个线程同时访问，互斥量本质上是一把锁，在访问共享资源前对互斥量进行加锁，在访问完成后释放互斥量上的锁。

哲学家进餐问题：

拿起叉⼦⽤ P 操作，代表有叉⼦就直接⽤，没有叉⼦时就等待其他哲学家放回叉⼦。

不过，这种解法存在一个极端的问题：假设五位哲学家同时拿起左边的叉子，桌面上就没有叉子了，这样就没有人能够拿到他们右边的叉子，也就说每一位哲学家都会在 P(fork[(i + 1) % N ]) 这条语句阻塞了，很明显这发生了死锁的现象。

上⾯程序中的互斥信号量的作⽤就在于，只要有⼀个哲学家进⼊了「临界区」，也就是准备要拿叉⼦时，

其他哲学家都不能动，只有这位哲学家⽤完叉⼦了，才能轮到下⼀个哲学家进餐

会导致只能允许⼀个哲学家就餐，那么我们就不⽤它。

⽅案⼀的问题在于，会出现所有哲学家同时拿左边⼑叉的可能性，那我们就避免哲学家可以同时拿

左边的⼑叉，采⽤分⽀结构，根据哲学家的编号的不同，⽽采取不同的动作。

即让偶数编号的哲学家「先拿左边的叉⼦后拿右边的叉⼦」，奇数编号的哲学家「先拿右边的叉⼦后拿左边的叉⼦」。

在 P 操作时，根据哲学家的编号不同，拿起左右两边叉⼦的顺序不同。另外，V 操作是不需要分⽀的，因为 V 操作是不会阻塞的。

方案三即不会出现死锁，也可以两人同时进餐。

方案四

在这里再提出另外一种可行的解决方案，我们用一个数组 state 来记录每一位哲学家的三个状态，分别是在进餐状态、思考状态、饥饿状态（正在试图拿叉子）。

那么，一个哲学家只有在两个邻居都没有进餐时，才可以进入进餐状态。

第 i 个哲学家的左邻右舍，则由宏 LEFT 和 RIGHT 定义：

LEFT : ( i + 5 - 1 ) % 5
RIGHT : ( i + 1 ) % 5

比如 i 为 2，则 LEFT 为 1，RIGHT 为 3。

3.信号量

信号量允许同一时刻多个线程访问同一个资源，但是要控制最大线程数量

Ctrl+C 产生 SIGINT 信号，表示终止该进程；
Ctrl+Z 产生 SIGTSTP 信号，表示停止该进程，但还未结束；

对于两个并发线程，互斥信号量的值仅取 1、0 和 -1 三个值，分别表示：

如果互斥信号量为 1，表示没有线程进入临界区；
如果互斥信号量为 0，表示有一个线程进入临界区；
如果互斥信号量为 -1，表示一个线程进入临界区，另一个线程等待进入。

通过互斥信号量的方式，就能保证临界区任何时刻只有一个线程在执行，就达到了互斥的效果。

如果进程在后台运行，可以通过 kill 命令的方式给进程发送信号，但前提需要知道运行中的进程 PID 号，例如：

kill -9 1050 ，表示给 PID 为 1050 的进程发送 SIGKILL 信号，用来立即结束该进程；

所以，信号事件的来源主要有硬件来源（如键盘 Cltr+C ）和软件来源（如 kill 命令）。

4. 信号

信号是进程间通信机制中唯一的异步通信机制，因为可以在任何时候发送信号给某一进程，一旦有信号产生，我们就有下面这几种，用户进程对信号的处理方式。

1.执行默认操作。Linux 对每种信号都规定了默认操作，例如，上面列表中的 SIGTERM 信号，就是终止进程的意思。

2.捕捉信号。我们可以为信号定义一个信号处理函数。当信号发生时，我们就执行相应的信号处理函数。

3.忽略信号。当我们不希望处理某些信号的时候，就可以忽略该信号，不做任何处理。

有两个信号是应用进程无法捕捉和忽略的，即 SIGKILL 和 SEGSTOP，它们用于在任何时候中断或结束某一进程

5. 读写锁

读写锁与互斥量类似，不过读写锁允许更高的并行性。

互斥量要么是锁住状态要么是不加锁状态，而且一次只有一个线程可以对其加锁。

读写锁可以由三种状态：读模式下加锁状态、写模式下加锁状态、不加锁状态。

先进先出，一次只有一个线程可以占有写模式的读写锁，但是多个线程可以同时占有读模式的读写锁。

既然读者优先策略和写者优先策略都会造成饥饿的现象，那么我们就来实现。

6. 条件变量(condition)

条件变量是用来等待而不是用来上锁的，条件变量是利用线程间共享的全局变量进行同步的一种机制，条件变量与互斥量一起使用时，允许线程等待特定的条件发生。条件变量与互斥量一起使用时，允许线程以无竞争的方式等待特定的条件发生。

条件本身是由互斥量保护的。线程在改变条件状态前必须首先锁住互斥量，其它线程在获得互斥量之前不会察觉到这种改变，因此必须锁定互斥量以后才能计算条件。

条件的检测是在互斥锁的保护下进行的。如果一个条件为假，一个线程自动阻塞，并释放等待状态改变的互斥锁。如果另一个线程改变了条件，它发信号给关联的条件变量，唤醒一个或多个等待它的线程，重新获得互斥锁，重新评价条件。

如果两进程共享可读写的内存，条件变量可以被用来实现这两进程间的线程同步。

如果线程正在等待共享数据内某个条件出现，那会发生什么呢？

代码可以反复对互斥对象锁定和解锁，以检查值的任何变化。同时，还要快速将互斥对象解锁，以便其它线程能够进行任何必需的更改。需要一种方法以唤醒因等待满足特定条件而睡眠的线程。

7. 事件

通过通知操作的方式来保持线程的同步

事件是内核对象，可以解决线程间同步问题，因此也能解决互斥问题。

1
2
3

事件机制，则允许一个线程在处理完一个任务后，主动唤醒另外一个线程执行任务。
比如在某些网络应用程序中，一个线程如A负责侦听通信端口，另外一个线程B负责更新用户数据，利用事件机制，
则线程A可以通知线程B何时更新用户数据。每个Cevent对象可以有两种状态：有信号状态和无信号状态。

1、使用全局变量

主要由于多个线程可能更改全局变量，因此全局变量最好声明为volatile。

2、使用消息实现通信

在Windows程序设计中，每一个线程都可以拥有自己的消息队列（UI线程默认自带消息队列和消息循环，工作线程需要手动实现消息循环），因此可以采用消息进行线程间通信sendMessage，postMessage。

2.7 线程的分类

内核级线程：

这类线程依赖于内核，又称为内核支持的线程或轻量级进程。

无论是在用户程序中的线程还是系统进程中的线程，它们的创建、撤销和切换都由内核实现。

比如英特尔i5-8250U是4核8线程，这里的线程就是内核级线程。

内核线程是由操作系统管理的，线程对应的 TCB ⾃然是放在操作系统⾥的，这样线程的创建、终⽌和管理都是由操作系统负责。

内核线程的优点：

在⼀个进程当中，如果某个内核线程发起系统调⽤⽽被阻塞，并不会影响其他内核线程的运⾏；
分配给线程，多线程的进程获得更多的 CPU 运⾏时间；

内核线程的缺点：

在⽀持内核线程的操作系统中，由内核来维护进程和线程的上下⽂信息，如 PCB 和 TCB；
线程的创建、终⽌和切换都是通过系统调⽤的⽅式来进⾏，因此对于系统来说，系统开销⽐较⼤；

用户级线程：

它仅存在于用户级中，这种线程是不依赖于操作系统核心的。应用进程利用线程库来完成其创建和管理，速度比较快，操作系统内核无法感知用户级线程的存在。

⽤户线程是基于⽤户态的线程管理库来实现的，那么线程控制块（Thread Control Block, TCB） 也是在库⾥⾯来实现的，对于操作系统⽽⾔是看不到这个 TCB 的，它只能看到整个进程的 PCB。

⽤户线程的优点：

每个进程都需要有它私有的线程控制块（TCB）列表，⽤来跟踪记录它各个线程状态信息（PC、栈指针、寄存器），TCB 由⽤户级线程库函数来维护，可⽤于不⽀持线程技术的操作系统；
⽤户线程的切换也是由线程库函数来完成的，⽆需⽤户态与内核态的切换，所以速度特别快；

⽤户线程的缺点：

由于操作系统不参与用户级线程的调度，如果⼀个线程发起了系统调⽤⽽阻塞，那**进程所包含的⽤户线程都不能执⾏**了。
当⼀个线程开始运⾏后，除⾮它主动地交出 CPU 的使⽤权，否则它所在的进程当中的其他线程⽆法运⾏，因为⽤户态的线程没法打断当前运⾏中的线程，它没有这个特权，只有操作系统才有，但是⽤户线程不是由操作系统管理的。
由于时间⽚分配给进程，故与其他进程⽐，在多线程执⾏时，每个线程得到的时间⽚较少，执⾏会⽐较慢；

轻量级进程（Light-weight process，LWP）

是内核⽀持的⽤户线程，⼀个进程可有⼀个或多个** LWP，每个 LWP 是跟内核线程⼀对⼀映射的，也就是 LWP 都是由⼀个内核线程⽀持。

另外，LWP 只能由内核管理并像普通进程⼀样被调度，Linux 内核是⽀持 LWP 的典型例⼦。

在⼤多数系统中，LWP与普通进程的区别也在于它只有⼀个最⼩的执⾏上下⽂和调度程序所需的统计信息。

⼀般来说，⼀个进程代表程序的⼀个实例，⽽ LWP 代表程序的执⾏线程.

因为⼀个执⾏线程不像进程那样需要那么多状态信息，所以 LWP 也不带有这样的信息。

在 LWP 之上也是可以使⽤⽤户线程的，那么 LWP 与⽤户线程的对应关系就有三种：

1 : 1 ，即⼀个 LWP 对应⼀个⽤户线程；

N : 1 ，即⼀个 LWP 对应多个⽤户线程；

M : N ，即多个 LMP 对应多个⽤户线程；

2.8 线程池

线程池就是提前创建若干个线程，如果有任务需要处理，线程池里的线程就会处理任务，处理完之后线程并不会被销毁，而是等待下一个任务。

为了减少创建和销毁线程的次数，让每个线程可以多次使用，同时可根据系统情况调整执行的线程数量，防止消耗过多内存。

由于创建和销毁线程都是消耗系统资源的，所以池化技术能提升性能。

线程池的组成主要分为 3 个部分，这三部分配合工作就可以得到一个完整的线程池：

任务队列，存储需要处理的任务，由工作的线程来处理这些任务
1. 通过线程池提供的 API 函数，将一个待处理的任务添加到任务队列，或者从任务队列中删除
2. 已处理的任务会被从任务队列中删除
3. 线程池的使用者，也就是调用线程池函数往任务队列中添加任务的线程就是生产者线程
工作的线程（任务队列任务的消费者），N个
- 1.线程池中维护了一定数量的工作线程，他们的作用是是不停的读任务队列，从里边取出任务并处理.
- 2.工作的线程相当于是任务队列的消费者角色，
- 3.如果任务队列为空，工作的线程将会被阻塞 (使用条件变量 / 信号量阻塞)
- 4.如果阻塞之后有了新的任务，由生产者将阻塞解除，工作线程开始工作
管理者线程（不处理任务队列中的任务），1个
1. 它的任务是周期性的对任务队列中的任务数量以及处于忙状态的工作线程个数进行检测
2. 当任务过多的时候，可以适当的创建一些新的工作线程
3. 当任务过少的时候，可以适当的销毁一些工作的线程

2.9 进程调度

批处理系统、分时系统和实时系统中，各采用哪几种进程（作业）调度算法？

批处理系统常用调度算法：

①、先来先服务：FCFS ②、最短作业优先 ③、最短剩余时间优先 ④、响应比最高者优先

分时系统调度算法：

①、轮转调度 ②、优先级调度 ③、多级队列调度 ④、彩票调度

实时系统调度算法：

①、单比率调度 ②、限期调度 ③、最少裕度法

2.10 多线程冲突了怎么办

由于多线程执行操作共享变量的这段代码可能会导致竞争状态，因此我们将此段代码称为临界区（critical section），它是访问共享资源的代码片段，一定不能给多线程同时执行。

我们希望这段代码是互斥（mutualexclusion）的，也就说保证一个线程在临界区执行时，其他线程应该被阻止进入临界区，说白了，就是这段代码执行过程中，最多只能出现一个线程。

锁：加锁、解锁操作；
信号量：P、V 操作；

根据锁的实现不同，可以分为「忙等待锁」和「无忙等待锁」。

那什么是原子操作呢？原子操作就是要么全部执行，要么都不执行，不能出现执行到一半的中间状态

PV 操作的算法描述

多线程，为什么要用多线程

提高系统的并发性：多线程可以使系统同时执行多个任务，提高系统的并发性和响应能力。当一个线程被阻塞或等待某个操作完成时，其他线程可以继续执行，充分利用处理器的资源，提高系统整体的吞吐量。
改善用户体验：多线程可以使复杂的任务在后台运行，而不阻塞用户界面的响应。例如，在图形界面应用程序中，可以使用一个线程来处理用户界面事件和响应，另一个线程来执行耗时的计算或网络操作，这样用户可以同时进行交互而不会感到应用程序卡顿。
提高程序的执行效率：通过并行执行多个任务，可以充分利用多核处理器的能力，加快程序的执行速度。对于需要进行大量计算或密集的I/O操作的任务，通过多线程可以将任务分解为多个子任务并行执行，从而减少总体执行时间。
实现异步编程：多线程可以用于实现异步编程模型，其中一个线程可以执行长时间运行的操作，而其他线程可以继续执行其他任务。这种模型在处理网络请求、文件操作、数据库查询等需要等待外部资源响应的情况下非常有用，可以提高应用程序的性能和响应能力。
分解复杂任务：多线程可以将一个复杂的任务分解为多个独立的子任务，并使用不同的线程同时执行这些子任务。这样可以简化任务的管理和实现，并且可以更好地利用系统资源。

3. 内存管理

内存(memory)资源永远都是稀缺的，当越来越多的进程需要越来越来内存时，某些进程会因为得不到内存而无法运行；
内存容易被破坏，一个进程可能误踩其他进程的内存空间；

为了在多进程环境下，使得进程之间的内存地址不受影响，相互隔离，内存短缺 + 内存访问需要做保护，于是操作系统就为每个进程独立分配一套虚拟地址空间。

操作系统引入了虚拟内存，进程持有的虚拟地址会通过 CPU 芯片中的内存管理单元（MMU）的映射关系，来转换变成物理地址，然后再通过物理地址访问内存

每个进程都有自己的虚拟空间，而物理内存只有一个，所以当启用了大量的进程，物理内存必然会很紧张，于是操作系统会通过内存交换技术，把不常使用的内存暂时存放到硬盘（换出），在需要的时候再装载回物理内存（换入）。

高效使用内存：VM将主存看成是存储在磁盘上的地址空间的高速缓存，主存中保存热的数据，根据需要在磁盘和主存之间传送数据；
简化内存管理：VM为每个进程提供了一致的地址空间，从而简化了链接、加载、内存共享等过程；
内存保护：通过在页表条目中加入保护位，保护每个进程的地址空间不被其他进程破坏。

3.1 逻辑地址、线性地址和物理地址的区别？

逻辑地址（Logic Address）是指由程序产生的与段相关的偏移地址部分，因此一个逻辑地址由段标识符和段内偏移量组成，有时也称虚拟地址。

比如，在C程序中，可以使用&操作读取指针变量本身的值，实际上这个值就是逻辑地址。逻辑地址和绝对的物理地址不相干。

程序经过编译后，每个目标模块都是从0号单元开始编址，称为该目标模块的相对地址（或逻辑地址）。要通过分段地址的变化处理+分页后才会对应到相应的物理内存地址。

线性地址（Linear Address）是逻辑地址到物理地址变换之间的中间层。

程序代码会产生逻辑地址，或说是段中的偏移地址，加上相应段的基地址就生成了一个线性地址。如果启用了分页机制，那么线性地址可以再经过变换产生物理地址。

若是没有采用分页机制，那么线性地址就是物理地址。

物理地址（Physical Address）是指内存中物理单元的集合，它是地址转换的最终地址，是CPU外部地址总线上的地址。进程在运行时执行指令和访问数据都要通过物理地址从主存中存取

逻辑（虚拟）地址经过分段（查询段表）转化为线性地址。线性地址经过分页（查询页表）转为物理地址。

分页是把整个虚拟和物理内存空间切成一段段固定尺寸的大小。

这样一个连续并且尺寸固定的内存空间，我们叫页（Page）。在 Linux 下，每一页的大小为 4KB。

虚拟地址与物理地址之间通过页表来映射。

3.2 寻址方式有哪些？

寻址寻的都是物理地址。

分三组：立即寻址+寄存器寻址；

直接间接寻址；相对寻址+2个基变址寻址。

3.3 什么是虚拟内存？

虚拟内存是一种计算机系统内存管理技术。它使得应用程序认为它拥有连续可用的内存，即一个连续完整的地址空间。

而实际上，它通常是被分隔成多个物理内存碎片，还有部分暂时存储在外部磁盘存储器上，在需要时进行数据交换。多任务会带来进程对内存的操作冲突，需要虚拟内存来解决。

假设现在有一块物理内存，操作系统让两个进程共用这一块内存，彼此并不打扰。

虚拟内存地址空间是连续的，没有碎片
虚拟内存的最大空间就是cpu的最大寻址空间，不受内存大小的限制，能提供比内存更大的地址空间

电脑中所运行的程序均需经过内存执行，若执行的程序占用的内存很大很多，则会导致内存消耗殆尽，为解决该问题，WINDOWS运用了虚拟内存技术，即拿出一部分硬盘空间来充当内存使用，这部分空间即称为虚拟内存。

优点：可以弥补物理内存大小的不足；加载或交换每个用户程序到内存所需的 I/O 会更少一定程度的提高反映速度；

用户可以为一个巨大的虚拟地址空间编写程序，同时运行更多的程序，进而增加 CPU 利用率和吞吐量，但没有增加响应时间或周转时间**，减少对物理内存的读取从而保护内存延长内存使用寿命**；
缺点：占用一定的物理硬盘空间；加大了对硬盘的读写；设置不得当会影响整机稳定性与速度。

虚拟内存技术允许执行进程不必完全处于内存。

这种方案的一个主要优点就是，程序可以大于物理内存。

此外，虚拟内存将内存抽象成一个巨大的、统一的存储数组，进而实现了用户看到的逻辑内存与物理内存的分离。这种技术使得程序员不再担忧内存容量的限制。

虚拟内存还允许进程轻松共享文件和实现共享内存

3.3.1 虚拟内存作用

1、安全隔离，进程访问自身的私有内存片

2、共享内存，在进程之间有效共享代码库

3、善用碎片空间，更有效率地使用主存能够创建给主存更多的空间，每个进程都独有一个虚拟内存，并且解决主存非连续空间分配内存给某进程善用碎片空间

4、可作为缓存用，但需要进程通过页表进行翻译，这个时候需要在通过硬件进行缓存如TLB

Q: 假设没有虚拟内存会怎么样？

1、当一个进程需要的空间少于主存的时候，运行正常

2、当一个进程需要读取非常大的文件的时候，主存不够大，这个时候就出现缺页，切换进行效率好差

3、当有3个进程，划分了n分空间，第四个进程没有连续空间进行划分这个时候就会出现创建不了进程，甚至出现频繁切换进程

【总结】

运行更安全进程独立内存地址空间，善用碎片的内存空间，从而运行更多进程提高效率

3.4 什么是交换空间？

操作系统把物理内存(physical RAM)分成一块一块的小内存，每一块内存被称为页(page)。

当内存资源不足时，Linux把某些页的内容转移至硬盘上的一块空间上，以释放内存空间。

硬盘上的那块空间叫做交换空间(swap space), 而这一过程被称为交换(swapping)。

物理内存和交换空间的总容量就是虚拟内存的可用容量。

用途：

物理内存不足时一些不常用的页可以被交换出去，腾给系统。
程序启动时很多内存页被用来初始化，之后便不再需要，可以交换出去。

3.5 什么是分页？

把内存空间划分为大小相等且固定的块，作为主存的基本单位。

因为程序数据存储在不同的页面中，而页面又离散的分布在内存中，因此需要一个页表来记录映射关系，以实现从页号到物理块号的映射。

访问分页系统中内存数据需要两次的内存访问.

(第一次是从内存中访问页表，从中找到指定的物理块号，加上页内偏移得到实际物理地址；

第二次就是根据第一次得到的物理地址访问内存取出数据。)

分段的好处就是能产生连续的内存空间，但是会出现内存碎片和内存交换的空间太大的问题。

分页是把整个虚拟和物理内存空间切成一段段固定尺寸的大小。这样一个连续并且尺寸固定的内存空间，我们叫页（Page）。在 Linux 下，每一页的大小为 4KB。

页表是存储在内存里的，内存管理单元 （MMU）就做将虚拟内存地址转换成物理地址的工作。

而当进程访问的虚拟地址在页表中查不到时，系统会产生一个缺页异常，进入系统内核空间分配物理内存、更新进程页表，最后再返回用户空间，恢复进程的运行。

由于内存空间都是预先划分好的，也就不会像分段会产生间隙非常小的内存，这正是分段会产生内存碎片的原因。

而采用了分页，那么释放的内存都是以页为单位释放的，也就不会产生无法给进程使用的小内存。

如果内存空间不够，操作系统会把其他正在运行的进程中的「最近没被使用」的内存页面给释放掉，也就是暂时写在硬盘上，称为换出（Swap Out）。

一旦需要的时候，再加载进来，称为换入（Swap In）。所以，一次性写入磁盘的也只有少数的一个页或者几个页，不会花太多时间，内存交换的效率就相对比较高。

总结一下，对于一个内存地址转换，其实就是这样三个步骤：

把虚拟内存地址，切分成页号和偏移量；
根据页号，从页表里面，查询对应的物理页号；
直接拿物理页号，加上前面的偏移量，就得到了物理内存地址。

因为操作系统是可以同时运行非常多的进程的，那这不就意味着页表会非常的庞大。

在 32 位的环境下，虚拟地址空间共有 4GB（2^32），假设一个页的大小是 4KB（2^12），那么就需要大约 100 万（2^20）个页

每个「页表项」需要 4 个字节大小来存储，那么整个 4GB 空间的映射就需要有 4MB 的内存来存储页表。

这 4MB 大小的页表，看起来也不是很大。但是要知道每个进程都是有自己的虚拟地址空间的，也就说都有自己的页表。

那么，100 个进程的话，就需要 400MB 的内存来存储页表，这是非常大的内存了，更别说 64 位的环境了。

3.6 什么是分段？

分页是为了提高内存利用率，而分段是为了满足程序员在编写代码的时候的一些逻辑需求(比如数据共享，数据保护，动态链接等)。

分段内存管理当中，地址是二维的，一维是段号，二维是段内地址；其中每个段的长度是不一样的，而且每个段内部都是从0开始编址的。

由于分段管理中，每个段内部是连续内存分配，但是段和段之间是离散分配的，因此也存在一个逻辑地址到物理地址的映射关系，相应的就是段表机制。

段选择⼦就保存在段寄存器⾥⾯。段选择⼦⾥⾯最重要的是段号，⽤作段表的索引。

段表⾥⾯保存的是这个段的基地址、段的界限和特权等级等。

虚拟地址中的段内偏移量应该位于 0 和段界限之间，如果段内偏移量是合法的，就将段基地址加上段内偏移量得到物理内存地址

第⼀个就是**外部内存碎⽚**的问题。

第⼆个就是内存交换的效率低的问题。

分段机制下的虚拟地址由两部分组成，段选择子和段内偏移量。

段选择子就保存在段寄存器里面。段选择子里面最重要的是段号，用作段表的索引。段表里面保存的是这个段的基地址、段的界限和特权等级等。
虚拟地址中的段内偏移量应该位于 0 和段界限之间，如果段内偏移量是合法的，就将段基地址加上段内偏移量得到物理内存地址。

这里的内存碎片的问题共有两处地方：

外部内存碎片，也就是产生了多个不连续的小物理内存，导致新的程序无法被装载；
内部内存碎片，程序所有的内存都被装载到了物理内存，但是这个程序有部分的内存可能并不是很常使用，这也会导致内存的浪费；
对于多进程的系统来说，用分段的方式，内存碎片是很容易产生的，产生了内存碎片，那不得不重新 Swap 内存区域，这个过程会产生性能瓶颈。

因为硬盘的访问速度要比内存慢太多了，每一次内存交换，我们都需要把一大段连续的内存数据写到硬盘上。

所以，如果内存交换的时候，交换的是一个占内存空间很大的程序，这样整个机器都会显得卡顿。

为了解决内存分段的内存碎片和内存交换效率低的问题，就出现了内存分页。

3.7 分页分段的区别是什么？

属性：页是信息的物理单位，对用户不可见，段是逻辑单位，用户可见。
大小：分页固定，分段不固定
决定权：分页在于系统，分段在于用户
目的：分页有利于资源的利用，分段方便用户管理内存

目的

页是信息的物理单位，分页是为实现离散分配方式，以消减内存的外零头，提高内存的利用率。或者说，分页是出于系统管理的需要而不是用户需要。

段是信息的逻辑单位，它含有一组其意义相对完整的信息。分段的目的是为了更好地满足用户的需要。
长度

页的大小固定而且由系统决定，由系统把逻辑地址划分为页号和页内地址两部分，是由机器硬件实现的，因而在系统中只能有一种大小的页面。

段的长度不固定，决定于用户所编写的程序，通常由编译程序在对程序进行编译时，根据信息的性质来划分。
地址空间

页的地址空间是一维的，即单一的线形地址空间，程序员只要利用一个记忆符就可以表示一个地址。

作业段地址空间是二维的，程序员在标识一个地址时，既需要给出段名，又需给出段内地址。
碎片

分页有内部碎片无外部碎片

分段有外部碎片无内部碎片
绝对地址

处理器使用页号和偏移量计算绝对地址

处理器使用段号和偏移量计算绝对地址
管理方式

对于分页，操作系统必须为每个进程维护一个页表，以说明每个页对应的的页框。

当进程运行时，它的所有页都必须在内存中，除非使用覆盖技术或虚拟技术，另外操作系统需要维护一个空闲页框列表。

对于分段，操作系统必须为每个进程维护一个段表，以说明每个段的加载地址和长度。当进程运行时，它的所有短都必须在内存中，除非使用覆盖技术或虚拟技术，另外操作系统需要维护一个内存中的空闲的空洞列表。

特别的，当使用虚拟技术是，把一页或一段写入内存时可能需要把一页或几个段写入磁盘。
共享和动态链接

分页不容易实现，分段容易实现。

3.8 有哪些页面置换算法？

缺页中断：在请求分页系统中，可以通过查询页表中的状态位来确定所要访问的页面是否存在于内存中。每当所要访问的页面不在内存是，会产生一次缺页中断，此时操作系统会根据页表中的外存地址在外存中找到所缺的一页，将其调入内存。

有时候操作系统必须在内存选择一个页面将其移出内存，以便为即将调入的页面让出空间。而用来选择淘汰哪一页的规则叫做页面置换算法。

最佳置换算法（OPT）（理想置换算法）：从主存中移出永远不再需要的页面；如无这样的页面存在，则选择最长时间不需要访问的页面。于所选择的被淘汰页面将是以后永不使用的，或者是在最长时间内不再被访问的页面，这样可以保证获得最低的缺页率。最佳页面置换算法作用是为了衡量你的算法的效率，你的算法效率越接近该算法的效率，那么说明你的算法是高效的。
先进先出FIFO：总是选择在主存中停留时间最长（即最老）的一页置换
LRU：选择在最近一段时间里最久没有使用过的页面予以置换最佳页面置换算法作用是为了衡量你的算法的效率，你的算法效率越接近该算法的效率，那么说明你的算法是高效的。
LFU(least )：统计页的使用频率，选择在最近时期使用最少的页面作为淘汰页
NRU(Not Recently Used)：最近未用算法，通过给每一个访问的页面关联一个附加位(reference bit)，有些地方也叫做使用位(use bit)。

主要思想是：当某一页装入主存时，将use bit置成1；如果该页之后又被访问到，使用位也还是标记成1。对于页面置换算法，候选的帧集合可以看成是一个循环缓冲区，并且有一个指针和缓冲区相关联。遇到页面替换时，指针指向缓冲区的下一帧。如果这页进入主存后发现没有空余的帧(frame)，即所有页面的使用位均为1，那么这时候从指针开始循环一个缓冲区，将之前的使用位都清0，并且留在最初的位置上，换出该桢对应的页。
改进NRU：在之前的CLOCK算法上面除了使用位(used bit)，还增加了一个修改位(modified bit)，有些地方也叫做dirty bit。现在每一页有两个状态，分别**是(使用位，修改位)***，可分为以下四种情况考虑：

刚刚换出的页面马上又要换入内存，刚刚换入的页面马上又要换出外存，这种频繁的页面调度行为称为抖动，或颠簸。

产生抖动的主要原因是进程频繁访问的页面数目高于可用的物理块数（分配给进程的物理块不够）

3.9 段⻚式内存管理

先将程序划分为多个有逻辑意义的段，也就是前⾯提到的分段机制；

接着再把每个段划分为多个⻚，也就是对分段划分出来的连续空间，再划分固定⼤⼩的⻚；

第⼀次访问段表，得到⻚表起始地址；

第⼆次访问⻚表，得到物理⻚号；

第三次将物理⻚号与⻚内位移组合，得到物理地址。

可用软、硬件相结合的方法实现段页式地址变换，这样虽然增加了硬件成本和系统开销，但提高了内存的利用率。

Linux 内存主要采⽤的是⻚式内存管理，但同时也不可避免地涉及了段机制。

这主要是上⾯ Intel 处理器发展历史导致的，因为 Intel X86 CPU ⼀律对程序中使⽤的地址先进⾏段式映射，然后才能进⾏⻚式映射。既然 CPU 的硬件结构是这样，Linux 内核也只好服从 Intel 的选择。

但是事实上，Linux 内核所采取的办法是使段式映射的过程实际上不起什么作⽤。也就是说，“上有政策，下有对策”，若惹不起就躲着⾛。

Linux 系统中的每个段都是从 0 地址开始的整个 4GB 虚拟空间（32 位环境下），也就是所有的段的起始地址都是⼀样的。这意味着，Linux 系统中的代码，包括操作系统本身的代码和应⽤程序代码，所⾯对的

地址空间都是线性地址空间（虚拟地址），这种做法相当于屏蔽了处理器中的逻辑地址概念，段只被⽤于访问控制和内存保护。这样虽然增加了硬件成本和系统开销，但提⾼了内存的利⽤率。

3.10 Cache

多级⻚表虽然解决了空间上的问题，但是虚拟地址到物理地址的转换就多了⼏道转换的⼯序，这显然就降低了这俩地址转换的速度，也就是带来了时间上的开销。

CPU 芯⽚中，加⼊了⼀个专⻔存放程序最常访问的⻚表项的 Cache，这个 Cache 就是 TLB

（Translation Lookaside Buffer），通常称为⻚表缓存、转址旁路缓存、快表等。

在 CPU 芯片里面，封装了内存管理单元（Memory Management Unit）芯片，它用来完成地址转换和 TLB 的访问与交互。

有了 TLB 后，那么 CPU 在寻址时，会先查 TLB，如果没找到，才会继续查常规的页表。

TLB 的命中率其实是很高的，因为程序最常访问的页就那么几个。

3.11 Linux内存分布

程序文件段，包括二进制可执行代码；
已初始化数据段，包括静态常量；
未初始化数据段，包括未初始化的静态变量；
堆段，包括动态分配的内存，从低地址开始向上增长；
文件映射段，包括动态库、共享内存等，从低地址开始向上增长（跟硬件和内核版本有关）；
栈段，包括局部变量和函数调用的上下文等。栈的大小是固定的，一般是 8 MB。当然系统也提供了参数，以便我们自定义大小；

在这 6 个内存段中，堆和文件映射段的内存是动态分配的。比如说，使用 C 标准库的 malloc()（br()）或者 mmap() ，就可以分别在堆和文件映射段动态分配内存。

3.12 malloc 是如何分配内存的？

实际上，malloc() 并不是系统调用，而是 C 库里的函数，用于动态分配内存。

malloc 申请内存的时候，会有两种方式向操作系统申请堆内存。

方式一：通过 brk() 系统调用从堆分配内存
方式二：通过 mmap() 系统调用在文件映射区域分配内存；

方式一实现的方式很简单，就是通过 brk() 函数将「堆顶」指针向高地址移动，获得新的内存空间。如下图：

方式二通过 mmap() 系统调用中「私有匿名映射」的方式，在文件映射区分配一块内存，也就是从文件映射区“偷”了一块内存。如下图：

malloc() 源码里默认定义了一个阈值：

如果用户分配的内存小于 128 KB，则通过 brk() 申请内存；
如果用户分配的内存大于 128 KB，则通过 mmap() 申请内存；

3.13 malloc() 分配的是物理内存吗？

不是的，malloc() 分配的是虚拟内存。

如果分配后的虚拟内存没有被访问的话，是不会将虚拟内存不会映射到物理内存，这样就不会占用物理内存了。

只有在访问已分配的虚拟地址空间的时候，操作系统通过查找页表，发现虚拟内存对应的页没有在物理内存中，就会触发缺页中断，然后操作系统会建立虚拟内存和物理内存之间的映射关系

我们在上面的进程往下执行，看看通过 free() 函数释放内存后，堆内存还在吗？

这是因为与其把这 1 字节释放给操作系统，不如先缓存着放进 malloc 的内存池里，当进程再次申请 1 字节的内存时就可以直接复用，这样速度快了很多。

当然，当进程退出后，操作系统就会回收进程的所有资源。

上面说的 free 内存后堆内存还存在，是针对 malloc 通过 brk() 方式申请的内存的情况。

如果 malloc 通过 mmap 方式申请的内存，free 释放内存后就会归还给操作系统

malloc() 在分配内存的时候，并不是老老实实按用户预期申请的字节数来分配内存空间大小，而是会预分配更大的空间作为内存池。

3.14 为什么不全部使用 mmap 来分配内存？

因为向操作系统申请内存，是要通过系统调用的，执行系统调用是要进入内核态的，然后在回到用户态，运行态的切换会耗费不少时间。

所以，申请内存的操作应该避免频繁的系统调用，如果都用 mmap 来分配内存，等于每次都要执行系统调用。

另外，因为 mmap 分配的内存每次释放的时候，都会归还给操作系统，于是每次 mmap 分配的虚拟地址都是缺页状态的，然后在第一次访问该虚拟地址的时候，就会触发缺页中断。

频繁通过 mmap 分配的内存话，不仅每次都会发生运行态的切换，还会发生缺页中断（在第一次访问虚拟地址后），这样会导致 CPU 消耗较大。

为了改进这两个问题，malloc 通过 brk() 系统调用在堆空间申请内存的时候，由于堆空间是连续的，所以直接预分配更大的内存来作为内存池，当内存释放的时候，就缓存在内存池中。

等下次在申请内存的时候，就直接从内存池取出对应的内存块就行了，而且可能这个内存块的虚拟地址与物理地址的映射关系还存在，这样不仅减少了系统调用的次数，也减少了缺页中断的次数，这将大大降低 CPU 的消耗

但是如果下次申请的内存大于 30k，没有可用的空闲内存空间，必须向 OS 申请，实际使用内存继续增大。

因此，随着系统频繁地 malloc 和 free ，尤其对于小块内存，堆内将产生越来越多不可用的碎片，导致“内存泄露”。而这种“泄露”现象使用 valgrind 是无法检测出来的。

所以，malloc 实现中，充分考虑了 sbrk 和 mmap 行为上的差异及优缺点，默认分配大块内存 (128KB) 才使用 mmap 分配内存空间

3.15 free() 函数只传入一个内存地址，为什么能知道要释放多大的内存？

还记得，我前面提到， malloc 返回给用户态的内存起始地址比进程的堆空间起始地址多了 16 字节吗？

这个多出来的 16 字节就是保存了该内存块的描述信息，比如有该内存块的大小。

这样当执行 free() 函数时，free 会对传入进来的内存地址向左偏移 16 字节，然后从这个 16 字节的分析出当前的内存块的大小，自然就知道要释放多大的内存了。

4. 系统中断

在CPU执行程序的过程中，出现了某种紧急情况或异常的事件时，暂停正在执行的程序，转去处理该事件，并在处理完该事件之后返回断点处（指返回主程序时执行的第一条指令的地址）继续执行刚刚被暂停的程序。

软中断和硬中断

我们通常所说的中断指的是硬中断(hardirq)。

软中断是执行中断指令产生的，而硬中断是由外设引发的。

硬中断的中断号是由中断控制器提供的，软中断的中断号由指令直接指出，无需使用中断控制器。

硬中断是可屏蔽的，软中断不可屏蔽。

硬中断处理程序要确保它能快速地完成任务，这样程序执行时才不会等待较长时间，称为上半部。

软中断处理硬中断未完成的工作，是一种推后执行的机制，属于下半部。

4.1 中断的处理过程

中断请求

中断源向CPU发出中断请求，

发生在CPU内部的中断（内部中断），不需要中断请求，CPU内部的中断控制逻辑直接接收处理。

软中断是执行中断指令产生的， 而硬中断是由外设引发的，比如当网卡收到数据包的时候，就会发出一个中断。

外部中断请求由中断源提出。外部中断源利用CPU的中断输入引脚输入中断请求信号。

一般CPU设有两个中断请求输入引脚：可屏蔽中断请求输入引脚和不可屏蔽中断请求输入引脚。

中断请求触发器

每个中断源发中断请求信号的时间是不确定的，而CPU在何时响应中断也是不确定的。

所以，每个中断源都有一个中断请求触发器，锁存自己的中断请求信号，并保持到CPU响应这个中断请求之后才将其清除。

在CPU内部有一个中断允许触发器，当其为“1”时，允许CPU响应中断，称为开中断。

若其为“0”，不允许CPU响应中断，中断被屏蔽，称为关中断

中断响应

① 保护硬件现场（PC）和（PSW）；把CPU的状态保存在寄存器中。

程序计数器（Program Counter，PC）用来指出下一条指令在主存储器中的地址，

程序状态字（Program Status Word，PSW）用来表征当前运算的状态及程序的工作方式。

② 关中断；

中断服务处理阶段

1）保护现场。 在中断服务程序的起始部分安排若干条入栈指令，再将各寄存器的内容压入堆栈保存。

2）开中断。 在中断服务程序执行期间允许级别更高的中断请求中断现行的中断服务程序，实现中断嵌套。

3）中断服务。 获得中断服务程序的入口地址。完成中断源的具体要求，根据中断类型码在中断向量表中找到相应中断服务程序的入口地址。

4）恢复现场。 中断服务程序结束前，必须恢复主程序的中断现场。通常是将保存在堆栈中的现场信息弹出到原来的寄存器中。 返回到原程序的断点处，恢复硬件现场，继续执行原程序。

5）中断返回。 返回到原程序的断点处，恢复硬件现场,继续执行原程序。

4.2 中断和轮询有什么区别？

轮询：CPU对特定设备轮流询问。中断：通过特定事件提醒CPU。

轮询：效率低等待时间长，CPU利用率不高。中断：容易遗漏问题，CPU利用率不高。

CPU要和外设进行通信，可以采用轮询和中断两种方式。

因为轮询方式需要CPU轮询外设，查询外设是否发生中断，效率不高显而易见。于是增加了如下图的中断系统来减轻CPU负担，但是这样做效率就高了吗？

本质上，采用中断系统后，CPU仍然需要每隔一小段时间去查询中断控制寄存器TCON的各位状态，以判断是否有外设中断发生，否则CPU仍旧无法知道外设的当前状态。

如上所述，中断和轮询，好像又没啥区别，CPU仍旧摆脱不了查询的命运。

但是让CPU直接和各个外设逐一沟通，和让CPU只与中断控制系统机构沟通，效率是完全不一样的。

为了证明我的推断，我们假设, CPU外接20个不同的设备，这20个外设中在某一刻有两个外设同时中断，正好这个时候CPU来查看外设的状态，如果是轮询方式，CPU需要一一遍历20种不同的外设控制器，才能判断哪些外设刚才申请过中断，哪些外设没有申请中断。如果采用中断方式处理呢？

CPU只需查询一下中断标志位，处理最高优先级的那个中断，其他的事情全交给中断系统去处理，效率提高了20倍！

从中，我们也可以发现一个现象，不论硬件设计如何巧妙，软件产品如何复杂，在设计原则上仍然是在不断的做加法。

异常与中断不同，它在产生时必须考虑与处理器时钟同步。实际上，异常也称为同步中断。

比如，在处理器执行到由于编程失误而导致的错误指令的时候，或者在执行期间出现特殊情况(缺页)，必须靠内核来处理的，处理器就产生一个异常。

和中断的的工作方式类似，其差异只在于中断是由硬件而不是软件引起的。

5. 磁盘空间

5.1 磁盘调度

先来先服务算法，先到来的请求，先被服务。
最短寻道时间优先算法，优先选择从当前磁头位置所需寻道时间最短的请求，还是以这个序列为例子：
扫描算法算法，最短寻道时间优先算法会产生饥饿的原因在于：磁头有可能再一个小区域内来回得移动。为了防止这个问题，可以规定：磁头在一个方向上移动，访问所有未完成的请求，直到磁头到达该方向上的最后的磁道，才调换方向，这就是扫描（Scan）算法
循环扫描算法，只有磁头朝某个特定方向移动时，才处理磁道访问请求，而返回时直接快速移动至最靠边缘的磁道，也就是复位磁头，这个过程是很快的，并且返回中途不处理任何请求，该算法的特点，就是磁道只响应一个方向上的请求。
LOOK 与 C-LOOK 算法，那这其实是可以优化的，优化的思路就是磁头在移动到「最远的请求」位置，然后立即反向移动。

6. 文件系统

6.1 软硬链接

和普通文件不同的是，普通文件的块里面保存的是文件数据，而目录文件的块里面保存的是目录里面一项一项的文件信息。

有时候我们希望给某个文件取个别名，那么在 Linux 中可以通过硬链接（Hard Link） 和软链接（Symbolic Link） 的方式来实现，它们都是比较特殊的文件，但是实现方式也是不相同的。

硬链接是多个目录项中的「索引节点」指向一个文件，也就是指向同一个 inode，但是 inode 是不可能跨越文件系统的，每个文件系统都有各自的 inode 数据结构和列表，所以硬链接是不可用于跨文件系统的。

由于多个目录项都是指向一个 inode，那么只有删除文件的所有硬链接以及源文件时，系统才会彻底删除该文件。

软链接相当于重新创建一个文件，这个文件有独立的 inode，但是这个文件的内容是另外一个文件的路径，所以访问软链接的时候，实际上相当于访问到了另外一个文件，所以软链接是可以跨文件系统的，甚至目标文件被删除了，链接文件还是在的，只不过指向的文件找不到了而已。

6.2 直接io与非直接io

直接 I/O，不会发生内核缓存和用户程序之间数据复制，而是直接经过文件系统访问磁盘。
非直接 I/O，读操作时，数据从内核缓存中拷贝给用户程序，写操作时，数据从用户程序拷贝给内核缓存，再由内核决定什么时候写入数据到磁盘。

以下几种场景会触发内核缓存的数据写入磁盘：
- 在调用 write 的最后，当发现内核缓存的数据太多的时候，内核会把数据写到磁盘上；
- 用户主动调用 sync，内核缓存会刷到磁盘上；
- 当内存十分紧张，无法再分配页面时，也会把内核缓存的数据刷到磁盘上；
- 内核缓存的数据的缓存时间超过某个时间时，也会把数据刷到磁盘上；

6.3. 同步IO，异步IO

在前⾯我们知道了，I/O 是分为两个过程的：

1
2
3

  1. 数据准备的过程

  2. 数据从内核空间拷⻉到⽤户进程缓冲区的过程

阻塞 I/O 会阻塞在「过程 1 」和「过程 2」，

⽽⾮阻塞 I/O 和基于⾮阻塞 I/O 的多路复⽤只会阻塞在「过程2」，所以这三个都可以认为是同步 I/O。

异步 I/O 则不同，「过程 1 」和「过程 2 」都不会阻塞。

食堂打饭例子

举个你去饭堂吃饭的例⼦，你好⽐⽤户程序，饭堂好⽐操作系统。

阻塞 I/O 好⽐，你去饭堂吃饭，但是饭堂的菜还没做好，然后你就⼀直在那⾥等啊等，等了好⻓⼀段时间 终于等到饭堂阿姨把菜端了出来（数据准备的过程），但是你还得继续等阿姨把菜（内核空间）打到你的饭盒⾥（⽤户空间），经历完这两个过程，你才可以离开。

⾮阻塞 I/O 好⽐，你去了饭堂，问阿姨菜做好了没有，阿姨告诉你没，你就离开了，过⼏⼗分钟，你**⼜来饭堂问阿姨，阿姨说做好了**，于是阿姨帮你把菜打到你的饭盒⾥，这个过程你是得等待的。基于⾮阻塞的 I/O 多路复⽤好⽐，你去饭堂吃饭，发现有⼀排窗⼝，饭堂阿姨告诉你这些窗⼝都还没做好菜，等做好了再通知你，于是等啊等（ select 调⽤中），过了⼀会阿姨通知你菜做好了，但是不知道哪个窗⼝的菜做好了，你⾃⼰看吧。于是你只能⼀个⼀个窗⼝去确认，后⾯发现 5 号窗⼝菜做好了，于是你让 5 号窗⼝的阿姨帮你打菜到饭盒⾥，这个打菜的过程你是要等待的，虽然时间不⻓。打完菜后，你⾃然就可以离开了。

异步 I/O 好⽐，你让饭堂阿姨将菜做好并把菜打到饭盒⾥后，把饭盒送到你⾯前，整个过程你都不需要任何等待.

同步和异步IO的概念：

同步是用户线程发起I/O请求后需要等待或者轮询内核I/O操作完成后才能继续执行

异步是用户线程发起I/O请求后仍需要继续执行，当内核I/O操作完成后会通知用户线程，或者调用用户线程注册的回调函数。

阻塞和非阻塞IO的概念：

阻塞是指I/O操作需要彻底完成后才能返回用户空间。

非阻塞是指I/O操作被调用后立即返回一个状态值，无需等I/O操作彻底完成。

IO模型

这里统一使用Linux下的系统调用recv作为例子，它用于从套接字上接收一个消息，因为是一个系统调用，所以调用时会从用户进程空间切换到内核空间运行一段时间再切换回来。

默认情况下recv会等到网络数据到达并且复制到用户进程空间或者发生错误时返回，而第4个参数flags可以让它马上返回。

套接字(Socket)，就是对网络中不同主机上的应用进程之间进行双向通信的端点的抽象。

一个套接字就是网络上进程通信的一端，提供了应用层进程利用网络协议交换数据的机制

阻塞IO模型

使用recv的默认参数，会一直等数据直到拷贝到用户空间，这段时间内进程始终阻塞。

A同学用杯子装水，打开水龙头装满水然后离开。这一过程就可以看成是使用了阻塞IO模型。

因为如果水龙头没有水，他也要等到有水并装满杯子才能离开去做别的事情。很显然，这种IO模型是同步的。

非阻塞IO模型

改变flags，让recv不管有没有获取到数据都返回，如果没有数据那么一段时间后再调用recv看看，如此循环。

B同学也用杯子装水，打开水龙头后发现没有水，它离开了，过一会他又拿着杯子来看看……在中间离开的这些时间里，B同学离开了装水现场(回到用户进程空间)，可以做他自己的事情。这就是非阻塞IO模型。

但是它只有是检查有无数据的时候是非阻塞的，在数据到达的时候依然要等待复制数据到用户空间(等着水将水杯装满)，因此它还是同步IO。

IO复用模型

这里在调用recv前先调用select或者poll，这2个系统调用都可以在内核准备好数据(网络数据到达内核)时告知用户进程，这个时候再调用recv一定是有数据的。

因此这一过程中它是阻塞于select或poll，而没有阻塞于recv，有人将非阻塞IO定义成在读写操作时没有阻塞于系统调用的IO操作 (不包括数据从内核复制到用户空间时的阻塞，因为这相对于网络IO来说确实很短暂)，如果按这样理解，这种IO模型也能称之为非阻塞IO模型，但是按POSIX来看，它也是同步IO，那么也和楼上一样称之为同步非阻塞IO吧。

这种IO模型比较特别，因为它能同时监听多个文件描述符(fd)

一旦某个文件描述符就绪（一般是读就绪或者写就绪），能够通知程序进行相应的读写操作（这样就不需要每个用户进程不断的询问内核数据准备好了没）

这个时候C同学来装水，发现有一排水龙头，舍管阿姨告诉他这些水龙头都还没有水，等有水了告诉他。于是等啊等(select调用中)，过了一会阿姨告诉他有水了，但不知道是哪个水龙头有水，自己看吧。于是C同学一个个打开，往杯子里装水(recv)。

这里再顺便说说鼎鼎大名的epoll(高性能的代名词啊)，epoll也属于IO复用模型，

主要区别在于舍管阿姨会告诉C同学哪几个水龙头有水了，不需要一个个打开看(当然还有其它区别)。

信号驱动IO模型

通过调用sigaction注册信号函数，等内核数据准备好的时候系统中断当前程序，执行信号函数(在这里面调用recv)。

D同学让舍管阿姨等有水的时候通知他(注册信号函数)，没多久D同学得知有水了，跑去装水。是不是很像异步IO？很遗憾，它还是同步IO(省不了装水的时间啊)。

异步IO模型

调用aio_read，让内核等数据准备好，并且复制到用户进程空间后执行事先指定好的函数。

E同学让舍管阿姨将杯子装满水后通知他。整个过程E同学都可以做别的事情(没有recv)，这才是真正的异步IO。

最后，总结比较下五种IO模型：

总结

IO分两阶段：

1
2

1.数据准备阶段
2.内核空间复制回用户进程缓冲区阶段

一般来讲：阻塞IO模型、非阻塞IO模型、IO复用模型(select/poll/epoll)、信号驱动IO模型都属于同步IO，因为阶段2是阻塞的(尽管时间很短)。

只有异步IO模型是符合POSIX异步IO操作含义的，不管在阶段1还是阶段2都可以干别的事。

IO分两阶段（一旦拿到数据后就变成了数据操作，不再是IO）：

1.数据准备阶段

2.内核空间复制数据到用户进程缓冲区（用户空间）阶段

同步是用户线程发起I/O请求后需要等待或者轮询内核I/O操作完成后才能继续执行

异步是用户线程发起I/O请求后仍需要继续执行，当内核I/O操作完成后会通知用户线程，或者调用用户线程注册的回调函数

在操作系统中，程序运行的空间分为内核空间和用户空间。

应用程序都是运行在用户空间的，所以它们能操作的数据也都在用户空间。

阻塞IO和非阻塞IO的区别在于第一步发起IO请求是否会被阻塞：如果阻塞直到完成那么就是传统的阻塞IO，如果不阻塞，那么就是非阻塞IO。

同步IO和异步IO的区别就在于第二个步骤是否阻塞：如果不阻塞，而是操作系统帮你做完IO操作再将结果返回给你，否则就是异步IO

异步io的实现

来看一下基本的异步读的操作流程，我们假定发起任务的时候运行是由主线程启动的，那么：

注册者申请一个异步读任务，同时将自身的一个回调注册给异步读管理器。调用者在Dispose时，必须也将自身从异步读管理器中注销。（主线程）
管理器在收到任务后，将相关数据封包，并启动一个新的线程（或者从线程池提取一个线程）来执行异步读任务。（主线程）
在子线程异步读完毕后，通知管理器提取数据。（子线程）
管理器处理封包，并通过调用注册者的回调来将数据重新推送下去（子线程）

可以看到，在这个过程中，发起任务和处理任务分别是在主线程和子线程进行的，所以管理器自身必须有相应的同步机制来保证在不同线程上可以正确的运行。

我们还需要考虑一个注册者同时发起多个读取任务的可能性。所以需要一定的机制来保证正确的区分这些任务。

在这里，我们可以选用一个较为简单的方法，即为每个注册者开辟一个单独的std::vector<>，并将这些任务按顺序放在vector中，同时将每个任务对应的下标返回给注册者。这样当读任务完成时，我们可以通过下标来告知注册者是哪个任务完成了。

读取缓冲区的分配与释放应该统一由管理器负责，而不是注册者。

因此注册者只能拿到一个const状态的缓冲区，如果需要使用内容则需要将其复制到自有的缓冲区。

6.4 如何服务更多的用户

相信你知道 TCP 连接是由四元组唯一确认的，这个四元组就是：本机IP, 本机端口, 对端IP, 对端端口。

服务器作为服务方，通常会在本地固定监听一个端口，等待客户端的连接。因此服务器的本地 IP 和端口是固定的，于是对于服务端 TCP 连接的四元组只有对端 IP 和端口是会变化的，所以最大 TCP 连接数 = 客户端 IP 数×客户端端口数。

对于 IPv4，客户端的 IP 数最多为 2 的 32 次方，客户端的端口数最多为 2 的 16 次方，也就是服务端单机最大 TCP 连接数约为 2 的 48 次方。

这个理论值相当“丰满”，但是服务器肯定承载不了那么大的连接数，主要会受两个方面的限制：

文件描述符，Socket 实际上是一个文件，也就会对应一个文件描述符。
- 在 Linux 下，单个进程打开的文件描述符数是有限制的，没有经过修改的值一般都是 1024，不过我们可以通过 ulimit 增大文件描述符的数目；
系统内存，每个 TCP 连接在内核中都有对应的数据结构，意味着每个连接都是会占用一定内存的；

那如果服务器的内存只有 2 GB，网卡是千兆的，能支持并发 1 万请求吗？

并发 1 万请求，也就是经典的 C10K 问题，C 是 Client 单词首字母缩写，C10K 就是单机同时处理 1 万个请求的问题。

从硬件资源角度看，对于 2GB 内存千兆网卡的服务器，如果每个请求处理占用不到 200KB 的内存和 100Kbit 的网络带宽就可以满足并发 1 万个请求。

不过，要想真正实现 C10K 的服务器，要考虑的地方在于服务器的网络 I/O 模型，效率低的模型，会加重系统开销，从而会离 C10K 的目标越来越远。

基于最原始的阻塞网络 I/O，如果服务器要支持多个客户端，其中比较传统的方式，就是使用多进程模型，也就是为每个客户端分配一个进程来处理请求。

服务器的主进程负责监听客户的连接，一旦与客户端连接完成，accept() 函数就会返回一个「已连接 Socket」，这时就通过 fork() 函数创建一个子进程，实际上就把父进程所有相关的东西都复制一份，包括文件描述符、内存地址空间、程序计数器、执行的代码等。

这两个进程刚复制完的时候，几乎一摸一样。

不过，会根据返回值来区分是父进程还是子进程，如果返回值是 0，则是子进程；如果返回值是其他的整数，就是父进程。

正因为子进程会复制父进程的文件描述符，于是就可以直接使用「已连接 Socket 」和客户端通信了，可以发现，子进程不需要关心「监听 Socket」，只需要关心「已连接 Socket」；父进程则相反，将客户服务交给子进程来处理，因此父进程不需要关心「已连接 Socket」，只需要关心「监听 Socket」。

下面这张图描述了从连接请求到连接建立，父进程创建生子进程为客户服务。

另外，当「子进程」退出时，实际上内核里还会保留该进程的一些信息，也是会占用内存的，如果不做好“回收”工作，就会变成僵尸进程，随着僵尸进程越多，会慢慢耗尽我们的系统资源。

因此，父进程要“善后”好自己的孩子，怎么善后呢？那么有两种方式可以在子进程退出后回收资源，分别是调用 wait() 和 waitpid() 函数。

这种用多个进程来应付多个客户端的方式，在应对 100 个客户端还是可行的，但是当客户端数量高达一万时，肯定扛不住的，因为每产生一个进程，必会占据一定的系统资源，而且进程间上下文切换的“包袱”是很重的，性能会大打折扣。

进程的上下文切换不仅包含了虚拟内存、栈、全局变量等用户空间的资源，还包括了内核堆栈、寄存器等内核空间的资源。

那么，我们可以使用线程池的方式来避免线程的频繁创建和销毁，所谓的线程池，就是提前创建若干个线程，这样当由新连接建立时，将这个已连接的 Socket 放入到一个队列里，然后线程池里的线程负责从队列中取出已连接 Socket 进程处理。

一个进程虽然任一时刻只能处理一个请求，但是处理每个请求的事件时，耗时控制在 1 毫秒以内，这样 1 秒内就可以处理上千个请求，

把时间拉长来看，多个请求复用了一个进程，这就是多路复用，这种思想很类似一个 CPU 并发多个进程，所以也叫做时分多路复用。

我们熟悉的 select/poll/epoll 内核提供给用户态的多路复用系统调用，进程可以通过一个系统调用函数从内核中获取多个事件。

select/poll/epoll 是如何获取网络事件的呢？

在获取事件时，先把所有连接（文件描述符）传给内核，再由内核返回产生了事件的连接，然后在用户态中再处理这些连接对应的请求即可。

select/poll/epoll 这是三个多路复用接口，都能实现 C10K 吗？接下来，分别说说它们。

6.5 select，poll，epoll的原理、区别

I/O多路复用就通过一种机制，可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或者写就绪），能够通知程序进行相应的读写操作。

select，poll，epoll都是IO多路复用的机制。但select，poll，epoll本质上都是同步I/O，因为他们都需要在读写事件就绪后自己负责进行读写，也就是说这个读写过程是阻塞的。

而异步I/O则无需自己负责进行读写，异步I/O的实现会负责把数据从内核拷贝到用户空间

select 的核心功能是调用tcp文件系统的poll函数，不停的查询，如果没有想要的数据，主动执行一次调度（防止一直占用cpu），直到有一个连接有想要的消息为止。从这里可以看出select的执行方式基本就是不同的调用poll,直到有需要的消息为止。

select:

将已连接的 Socket 都放到一个文件描述符集合，然后调用 select 函数将文件描述符集合拷贝到内核里，让内核来检查是否有网络事件产生，检查的方式很粗暴，就是通过遍历文件描述符集合的方式，

当检查到有事件产生后，将此 Socket 标记为可读或可写， 接着再把整个文件描述符集合拷贝回用户态里，然后用户态还需要再通过遍历的方法找到可读或可写的 Socket，然后再对其处理。

所以，对于 select 这种方式，需要进行 2 次「遍历」文件描述符集合，一次是在内核态里，一个次是在用户态里，而且还会发生 2 次「拷贝」文件描述符集合，先从用户空间传入内核空间，由内核修改后，再传出到用户空间中。

select 使用固定长度的 BitsMap，表示文件描述符集合，而且所支持的文件描述符的个数是有限制的，在 Linux 系统中，由内核中的 FD_SETSIZE 限制，默认最大值为 1024，只能监听 0~1023 的文件描述符

缺点：

1、每次调用select，都需要把fd集合从用户态拷贝到内核态，这个开销在fd很多时会很大；

2、同时每次调用select都需要在内核遍历传递进来的所有fd，这个开销在fd很多时也很大；

3、select支持的文件描述符数量太小了，默认是1024。

优点：

1、select的可移植性更好，在某些Unix系统上不支持poll()。

2、select对于超时值提供了更好的精度：微秒，而poll是毫秒。

Poll

poll本质上和select没有区别，poll 不再用 BitsMap 来存储所关注的文件描述符，取而代之用动态数组，以链表形式来组织，突破了 select 的文件描述符个数限制，当然还会受到系统文件描述符限制。

它将用户传入的数组拷贝到内核空间，然后查询每个fd对应的设备状态，如果设备就绪则在设备等待队列中加入一项并继续遍历，如果遍历完所有fd后没有发现就绪设备，则挂起当前进程，直到设备就绪或者主动超时，被唤醒后它又要再次遍历fd。这个过程经历了多次无谓的遍历。

poll还有一个特点是“水平触发”，如果报告了fd后，没有被处理，那么下次poll时会再次报告该fd。

缺点：

1、大量的fd的数组被整体复制于用户态和内核地址空间之间，而不管这样的复制是不是有意义；

2、与select一样，poll返回后，需要轮询pollfd来获取就绪的描述符。

优点：

1、poll() 不要求开发者计算最大文件描述符加一的大小。

2、poll() 在应付大数目的文件描述符的时候速度更快，相比于select。

3、它没有最大连接数的限制，原因是它是基于链表来存储的。

但是 poll 和 select 并没有太大的本质区别，都是使用「线性结构」存储进程关注的 Socket 集合，因此都需要遍历文件描述符集合来找到可读或可写的 Socket，时间复杂度为 O(n)，而且也需要在用户态与内核态之间拷贝文件描述符集合，这种方式随着并发数上来，性能的损耗会呈指数级增长。

epoll

epoll同样只告知那些就绪的文件描述符，而且当我们调用epoll_wait()获得就绪文件描述符时， 返回的不是实际的描述符，而是一个代表就绪描述符数量的值，你只需要去epoll指定的一个数组中依次取得相应数量的文件描述符即可.

这里也使用了内存映射技术，这样便彻底省掉了这些文件描述符在系统调用时复制的开销。

epoll 在内核里使用红黑树来跟踪进程所有待检测的文件描述字，把需要监控的 socket 通过 epoll_ctl() 函数加入内核中的红黑树里（红黑树是个高效的数据结构，增删查一般时间复杂度是 O(logn)）

通过对这棵黑红树进行操作，这样就不需要像 select/poll 每次操作时都传入整个 socket 集合，只需要传入一个待检测的 socket，减少了内核和用户空间大量的数据拷贝和内存分配。
epoll 使用事件驱动的机制，内核里维护了一个链表来记录就绪事件，当某个 socket 有事件发生时，通过回调函数内核会将其加入到这个就绪事件列表中，当用户调用 epoll_wait() 函数时，只会返回有事件发生的文件描述符的个数，不需要像 select/poll 那样轮询扫描整个 socket 集合，大大提高了检测的效率。

epoll 被称为解决 C10K 问题的利器。

epoll的优点就是改进了前面所说缺点：

支持一个进程打开大数目的socket描述符：

相比select**，epoll则没有对FD的限制，它所支持的FD上限是最大可以打开文件的数目**，这个数字一般远大于2048,举个例子,在1GB内存的机器上大约是10万左右，具体数目可以cat /proc/sys/fs/file-max察看,一般来说这个数目和系统内存关系很大。
IO效率不随FD数目增加而线性下降：epoll不存在这个问题，它只会对“活跃”的socket进行操作— 这是因为在内核实现中epoll是根据每个fd上面的callback函数实现的。

那么，只有“活跃”的socket才会主动的去调用 callback函数，其他idle状态socket则不会，在这点上，epoll实现了一个“伪”AIO，因为这时候推动力在os内核。

在一些 benchmark中，如果所有的socket基本上都是活跃的—比如一个高速LAN环境，epoll并不比select/poll有什么效率，相反，如果过多使用epoll_ctl,效率相比还有稍微的下降。但是一旦使用idle connections模拟WAN环境,epoll的效率就远在select/poll之上了。
使用mmap加速内核与用户空间的消息传递：这点实际上涉及到epoll的具体实现了。

无论是select,poll还是epoll都需要内核把FD消息通知给用户空间，如何避免不必要的内存拷贝就很重要，在这点上，epoll是通过内核于用户空间mmap同一块内存实现的。

执行epoll_ create时，创建了红黑树和就绪链表；

执行epoll_ ctl时，如果增加socket句柄，则检查在红黑树中是否存在，存在立即返回，不存在则添加到树干上。

然后向内核注册回调函数，用于当中断事件来临时向准备就绪链表中插入数据。执行epoll_wait时立刻返回准备就绪链表里的数据即可。

(1) select==>时间复杂度O(n)

它仅仅知道了，有I/O事件发生了，却并不知道是哪那几个流（可能有一个，多个，甚至全部），我们只能无差别轮询所有流，找出能读出数据，或者写入数据的流，对他们进行操作。所以select具有O(n)的无差别轮询复杂度，同时处理的流越多，无差别轮询时间就越长。

(2) poll==>时间复杂度O(n)

poll本质上和select没有区别，它将用户传入的链式数组拷贝到内核空间，然后查询每个fd对应的设备状态， 但是它没有最大连接数的限制，原因是它是基于链表来存储的.

(3) epoll==>时间复杂度O(1)

epoll可以理解为event poll，不同于忙轮询和无差别轮询，epoll会把哪个流发生了怎样的I/O事件通知我们。所以我们说epoll实际上是事件驱动（每个事件关联上fd）的，此时我们对这些流的操作都是有意义的。（复杂度降低到了O(1)）

水平触发(level-triggered，也被称为条件触发)LT: 只要满足条件，就触发一个事件 (只要有数据没有被获取，内核就不断通知你)

边缘触发(edge-triggered)ET: 每当状态变化时，触发一个事件。

epoll 支持边缘触发和水平触发的方式，而 select/poll 只支持水平触发，

一般而言，边缘触发的方式会比水平触发的效率高。

6.6 DMA和零拷贝

可以看到，整个数据的传输过程，都要需要 CPU 亲自参与搬运数据的过程，而且这个过程，CPU 是不能做其他事情的。

简单的搬运几个字符数据那没问题，但是如果我们用千兆网卡或者硬盘传输大量数据的时候，都用 CPU 来搬运的话，肯定忙不过来。

计算机科学家们发现了事情的严重性后，于是就发明了 DMA 技术，也就是直接内存访问（Direct Memory Access） 技术。

什么是 DMA 技术？简单理解就是，在进行 I/O 设备和内存的数据传输的时候，数据搬运的工作全部交给 DMA 控制器，而 CPU 不再参与任何与数据搬运相关的事情，这样 CPU 就可以去处理别的事务。

用户进程调用 read 方法，向操作系统发出 I/O 请求，请求读取数据到自己的内存缓冲区中，进程进入阻塞状态；
操作系统收到请求后，进一步将 I/O 请求发送 DMA，然后让 CPU 执行其他任务；
DMA 进一步将 I/O 请求发送给磁盘；
磁盘收到 DMA 的 I/O 请求，把数据从磁盘读取到磁盘控制器的缓冲区中，当磁盘控制器的缓冲区被读满后，向 DMA 发起中断信号，告知自己缓冲区已满；
DMA 收到磁盘的信号，将磁盘控制器缓冲区中的数据拷贝到内核缓冲区中，此时不占用 CPU，CPU 可以执行其他任务；
当 DMA 读取了足够多的数据，就会发送中断信号给 CPU；
CPU 收到 DMA 的信号，知道数据已经准备好，于是将数据从内核拷贝到用户空间，系统调用返回；

可以看到，整个数据传输的过程，CPU 不再参与数据搬运的工作，而是全程由 DMA 完成，

但是 CPU 在这个过程中也是必不可少的，因为传输什么数据，从哪里传输到哪里，都需要 CPU 来告诉 DMA 控制器。

早期 DMA 只存在在主板上，如今由于 I/O 设备越来越多，数据传输的需求也不尽相同，所以每个 I/O 设备里面都有自己的 DMA 控制器。

传统 I/O 的工作方式是，数据读取和写入是从用户空间到内核空间来回复制，而内核空间的数据是通过操作系统层面的 I/O 接口从磁盘读取或写入。

第一次拷贝，把磁盘上的数据拷贝到操作系统内核的缓冲区里，这个拷贝的过程是通过 DMA 搬运的。
第二次拷贝，把内核缓冲区的数据拷贝到用户的缓冲区里，于是我们应用程序就可以使用这部分数据了，这个拷贝到过程是由 CPU 完成的。
第三次拷贝，把刚才拷贝到用户的缓冲区里的数据，再拷贝到内核的 socket 的缓冲区里，这个过程依然还是由 CPU 搬运的。
第四次拷贝，把内核的 socket 缓冲区里的数据，拷贝到网卡的缓冲区里，这个过程又是由 DMA 搬运的。

如何实现零拷贝？

零拷贝技术实现的方式通常有 2 种：

mmap + write
sendfile

下面就谈一谈，它们是如何减少「上下文切换」和「数据拷贝」的次数。

mmap() 系统调用函数会直接把内核缓冲区里的数据「映射」到用户空间，这样，操作系统内核与用户空间就不需要再进行任何的数据拷贝操作。

应用进程调用了 mmap() 后，DMA 会把磁盘的数据拷贝到内核的缓冲区里。接着，应用进程跟操作系统内核「共享」这个缓冲区；
应用进程再调用 write()，操作系统直接将内核缓冲区的数据拷贝到 socket 缓冲区中，这一切都发生在内核态，由 CPU 来搬运数据；
最后，把内核的 socket 缓冲区里的数据，拷贝到网卡的缓冲区里，这个过程是由 DMA 搬运的

我们可以得知，通过使用 mmap() 来代替 read()，可以减少一次数据拷贝的过程。

但这还不是最理想的零拷贝，因为仍然需要通过 CPU 把内核缓冲区的数据拷贝到 socket 缓冲区里，而且仍然需要 4 次上下文切换，因为系统调用还是 2 次

你可以在你的 Linux 系统通过下面这个命令，查看网卡是否支持 scatter-gather 特性：

`1`	`$ ethtool -k eth0 \| grep scatter-gatherscatter-gather: on`

于是，从 Linux 内核 2.4 版本开始起，对于支持网卡支持 SG-DMA 技术的情况下， sendfile() 系统调用的过程发生了点变化，具体过程如下：

第一步，通过 DMA 将磁盘上的数据拷贝到内核缓冲区里；
第二步，缓冲区描述符和数据长度传到 socket 缓冲区，这样网卡的 SG-DMA 控制器就可以直接将内核缓存中的数据拷贝到网卡的缓冲区里，此过程不需要将数据从操作系统内核缓冲区拷贝到 socket 缓冲区中，这样就减少了一次数据拷贝；
所以，这个过程之中，只进行了 2 次数据拷贝

这就是所谓的零拷贝（Zero-copy）技术，因为我们没有在内存层面去拷贝数据，也就是说全程没有通过 CPU 来搬运数据，所有的数据都是通过 DMA 来进行传输的。

零拷贝技术的文件传输方式相比传统文件传输的方式，减少了 2 次上下文切换和数据拷贝次数，只需要 2 次上下文切换和数据拷贝次数，就可以完成文件的传输，而且 2 次的数据拷贝过程，都不需要通过 CPU，2 次都是由 DMA 来搬运。

所以，总体来看，零拷贝技术可以把文件传输的性能提高至少一倍以上。

零拷贝技术是基于 PageCache 的，PageCache 会缓存最近访问的数据，提升了访问缓存数据的性能。

同时，为了解决机械硬盘寻址慢的问题，它还协助 I/O 调度算法实现了 IO 合并与预读，这也是顺序读比随机读性能好的原因。这些优势，进一步提升了零拷贝的性能。PageCache 使用了「预读功能」。

比如，假设 read 方法每次只会读 32 KB 的字节，虽然 read 刚开始只会读 0 ～ 32 KB 的字节，但内核会把其后面的 32～64 KB 也读取到 PageCache，这样后面读取 32～64 KB 的成本就很低，如果在 32～64 KB 淘汰出 PageCache 前，进程读取到它了，收益就非常高。

事实上，Kafka 这个开源项目，就利用了「零拷贝」技术，从而大幅提升了 I/O 的吞吐率，这也是 Kafka 在处理海量数据为什么这么快的原因之一。

另外，Nginx 也支持零拷贝技术，一般默认是开启零拷贝技术，这样有利于提高文件传输的效率，是否开启零拷贝技术的配置如下：

6.7 大文件传输

应用程序已经实现了磁盘数据的缓存，那么可以不需要 PageCache 再次缓存，减少额外的性能损耗。在 MySQL 数据库中，可以通过参数设置开启直接 I/O，默认是不开启；
传输大文件的时候，由于大文件难以命中 PageCache 缓存，而且会占满 PageCache 导致「热点」文件无法充分利用缓存，从而增大了性能开销，因此，这时应该使用直接 I/O。

另外，由于直接 I/O 绕过了 PageCache，就无法享受内核的这两点的优化：

内核的 I/O 调度算法会缓存尽可能多的 I/O 请求在 PageCache 中，最后「合并」成一个更大的 I/O 请求再发给磁盘，这样做是为了减少磁盘的寻址操作；
内核也会「预读」后续的 I/O 请求放在 PageCache 中，一样是为了减少对磁盘的操作；

于是，**传输大文件的时候，使用「异步 I/O + 直接 I/O」**了，就可以无阻塞地读取文件了。

所以，传输文件的时候，我们要根据文件的大小来使用不同的方式：

传输大文件的时候，使用「异步 I/O + 直接 I/O」；
传输小文件的时候，则使用「零拷贝技术」；

另外，当传输大文件时，不能使用零拷贝，因为可能由于 PageCache 被大文件占据，而导致「热点」小文件无法利用到 PageCache，并且大文件的缓存命中率不高，这时就需要使用「异步 IO + 直接 IO 」的方式。

在 Nginx 里，可以通过配置，设定一个文件大小阈值，针对大文件使用异步 IO 和直接 IO，而对小文件使用零拷贝。

6.8 Socket模型

要想客户端和服务器能在网络中通信，那必须得使用 Socket 编程，它是进程间通信里比较特别的方式，特别之处在于它是可以跨主机间通信。

服务端和客户端初始化 socket，得到文件描述符；
服务端调用 bind，将绑定在 IP 地址和端口;
服务端调用 listen，进行监听；
服务端调用 accept，等待客户端连接；
客户端调用 connect，向服务器端的地址和端口发起连接请求；
服务端 accept 返回用于传输的 socket 的文件描述符；
客户端调用 write 写入数据；服务端调用 read 读取数据；
客户端断开连接时，会调用 close，那么服务端 read 读取数据的时候，就会读取到了 EOF，待处理完数据后，服务端调用 close，表示连接关闭。

创建 Socket 的时候，可以指定网络层使用的是 IPv4 还是 IPv6，传输层使用的是 TCP 还是 UDP。

主线程：

创建完成端口对象
创建工作者线程（这里工作者线程的数量是按照CPU核的个数来决定，这样可以达到最佳性能）
创建监听套接字，绑定，监听，然后程序进入循环
在循环中，做了以下几件事情：

(1) 接受一个客户端连接

(2) 将该客户端套接字与完成端口绑定到一起(还是调用CreateIoCompletionPort，但这次的作用不同)。

注意，按道理来讲，此时传递给CreateIoCompletionPort的第三个参数应该是一个完成键，一般来讲，**程序都是传递一个单句柄数据结构的地址，**该单句柄数据包含了和该客户端连接有关的信息，由于我们只关心套接字句柄，所以直接将套接字句柄作为完成键传递；

(3) 触发一个WSARecv异步调用，这次又用到了“尾随数据”，使接收数据所用的缓冲区紧跟在WSAOVERLAPPED对象之后，此外，还有操作类型等重要信息。

7. 设备管理

我们的电脑设备可以接非常多的输入输出设备，比如键盘、鼠标、显示器、网卡、硬盘、打印机、音响等等，每个设备的用法和功能都不同，那操作系统是如何把这些输入输出设备统一管理的呢?

为了屏蔽设备之间的差异，每个设备都有一个叫设备控制器（Device Control） 的组件，比如硬盘有硬盘控制器、显示器有视频控制器等。

数据寄存器，CPU 向 I/O 设备写入需要传输的数据，比如要打印的内容是「Hello」，CPU 就要先发送一个 H 字符给到对应的 I/O 设备。
命令寄存器，CPU 发送一个命令，告诉 I/O 设备，要进行输入/输出操作，于是就会交给 I/O 设备去工作，任务完成后，会把状态寄存器里面的状态标记为完成。
状态寄存器，目的是告诉 CPU ，现在已经在工作或工作已经完成，如果已经在工作状态，CPU 再发送数据或者命令过来，都是没有用的，直到前面的工作已经完成，状态寄存标记成已完成，CPU 才能发送下一个字符和命令。

7.1 键盘敲入字母时，期间发生了什么？

那当用户输入了键盘字符，键盘控制器就会产生扫描码数据，并将其缓冲在键盘控制器的寄存器中，紧接着键盘控制器通过总线给 CPU 发送中断请求。

CPU 收到中断请求后，操作系统会保存被中断进程的 CPU 上下文，然后调用键盘的中断处理程序。

键盘的中断处理程序是在键盘驱动程序初始化时注册的，那键盘中断处理函数的功能就是从键盘控制器的寄存器的缓冲区读取扫描码，再根据扫描码找到用户在键盘输入的字符，**如果输入的字符是显示字符，那就会把扫描码翻译成对应显示字符的 ASCII 码（**比如用户在键盘输入的是字母 A，是显示字符，于是就会把扫描码翻译成 A 字符的 ASCII 码）

得到了显示字符的 ASCII 码后，就会把 ASCII 码放到「读缓冲区队列」，接下来就是要把显示字符在屏幕上了，显示设备的驱动程序会定时从「读缓冲区队列」读取数据放到「写缓冲区队列」，最后把「写缓冲区队列」的数据一个一个写入到显示设备的控制器的寄存器中的数据缓冲区，最后将这些数据显示在屏幕里。

显示出结果后，恢复被中断进程的上下文。

计算机网络常见问题1

Mon, 18 Nov 2019 21:45:27 +0800

问题

7.1 浏览器中输入URL地址到显示主页的过程是什么？

URL解析

地址解析：

首先判断你输入的是一个合法的 URL 还是一个待搜索的关键词，并且根据你输入的内容进行自动完成、字符编码等操作。

HSTS

由于安全隐患，会使用 HSTS 强制客户端使用 HTTPS 访问页面。详见：你所不知道的 HSTS。

其他操作

浏览器还会进行一些额外的操作，比如安全检查、访问限制（之前国产浏览器限制 996.icu）。

检查缓存304
DNS解析

1. 浏览器缓存

浏览器会先检查是否在浏览器缓存中，没有则调用系统库函数进行查询。

2. 操作系统缓存

操作系统也有自己的 DNS缓存，但在这之前，会向检查域名是否存在本地的 Hosts 文件里，没有则向 DNS 服务器发送查询请求。

3. 路由器缓存

路由器也有自己的缓存。

4. ISP DNS 缓存

ISP DNS 就是在客户端电脑上设置的首选 DNS 服务器，它们在大多数情况下都会有缓存。

根域名服务器查询

在前面所有步骤没有缓存的情况下，本地 DNS 服务器会将请求转发到互联网上的根域，下面这个图很好的诠释了整个流程：

根域名服务器：维基百科

需要注意的点
1. 递归方式：一路查下去中间不返回，得到最终结果才返回信息（浏览器到本地DNS服务器的过程）
2. 迭代方式，就是本地DNS服务器到根域名服务器查询的方式。
3. 什么是 DNS 劫持
  
  DNS劫持又叫域名劫持,指攻击者利用其他攻击手段,篡改了某个域名的解析结果,使得指向该域名的IP变成了另一个IP,导致对相应网址的访问被劫持到另一个不可达的或者假冒的网址,从而实现非法窃取用户信息或者破坏正常网络服务的目的
4. 前端 dns-prefetch 优化
  
  DNS预获取，是前端优化的一部分。一个是减少DNS的请求次数
TCP连接

根据IP建立TCP连接（三次握手）。
发送HTTP请求
服务器处理请求并返回HTTP报文
浏览器解析渲染页面

渲染页面，构建DOM树
连接结束

关闭TCP连接（四次挥手）。

7.2 ping命令的具体过程是什么？

简单来说，「ping」是用来探测本机与网络中另一主机之间是否可达的命令，如果两台主机之间ping不通，则表明这两台主机不能建立起连接。ping是定位网络通不通的一个重要手段。

ping 命令是基于 ICMP 协议来工作的，「 ICMP 」全称为 Internet 控制报文协议（ Internet Control Message Protocol）。

ping 命令会发送一份ICMP回显请求报文给目标主机，并等待目标主机返回ICMP回显应答。因为ICMP协议会要求目标主机在收到消息之后，必须返回ICMP应答消息给源主机，如果源主机在一定时间内收到了目标主机的应答，则表明两台主机之间网络是可达的。

假设现在有ABCD四台主机，一台路由，子网掩码为255.255.255.0，默认路由为192.168.0.1

在主机 A 上运行Ping 192.168.0.5后,

Ping命令会构建一个ICMP协议的数据包，交到网络层的IP协议中。IP层协议将目的地址和源地址和一些其它的控制信息打包后，形成IP数据包
通过ARP映射表获取192.168.0.5的MAC地址
交到数据链路层，添加一些控制信息，构建数据帧
交到物理层，通过以太网访问

主机B收到后，

检查目的地址，不相符就丢弃
将IP数据包提取后送入网络层的IP层协议，IP层检查后将有用的信息提取后送入ICMP协议
ICMP协议马上构建一个ICMP应答包以之前的相同方式发送给主机

根据条件：是否在同一网段内，流程可能有所不同，区别在于MAC的获取方式，具体参见ARP协议。

7.3 什么是负载均衡，负载均衡算法有哪些？

负载均衡是高可用网络基础架构的关键组件，通常用于将工作负载分布到多个服务器来提高网站、应用、数据库或其他服务的性能和可靠性

多台服务器以对称的方式组成一个服务器集合，每台服务器都具有等价的地位，能互相分担负载。

轮询法：将请求按照顺序轮流的分配到服务器上。大锅饭，不能发挥某些高性能服务器的优势
随机法：随机获取一台，和轮询类似
哈希法：通过ip地址哈希化来确定要选择的服务器编号。好处是，每次客户端访问的服务器都是同一个服务器，能很好地利用session或者cookie
加权轮询：根据服务器性能不同加权
一致性哈希

不同的负载均衡算法适用的业务场景也不同的。

轮询这类的策略只能适用与每个节点的数据都是相同的场景，访问任意节点都能请求到数据。但是不适用分布式系统，因为分布式系统意味着数据水平切分到了不同的节点上，访问数据的时候，一定要寻址存储该数据的节点。

哈希算法虽然能建立数据和节点的映射关系，但是每次在节点数量发生变化的时候，最坏情况下所有数据都需要迁移，这样太麻烦了，所以不适用节点数量变化的场景。

为了减少迁移的数据量，就出现了一致性哈希算法。

一致性哈希是指将「存储节点」和「数据」都映射到一个首尾相连的哈希环上，如果增加或者移除一个节点，仅影响该节点在哈希环上顺时针相邻的后继节点，其它数据也不会受到影响。

但是一致性哈希算法不能够均匀的分布节点，会出现大量请求都集中在一个节点的情况，在这种情况下进行容灾与扩容时，容易出现雪崩的连锁反应。

为了解决一致性哈希算法不能够均匀的分布节点的问题，就需要引入虚拟节点，对一个真实节点做多个副本。不再将真实节点映射到哈希环上，而是将虚拟节点映射到哈希环上，并将虚拟节点映射到实际节点，所以这里有「两层」映射关系。

引入虚拟节点后，可以会提高节点的均衡度，还会提高系统的稳定性。所以，带虚拟节点的一致性哈希方法不仅适合硬件配置不同的节点的场景，而且适合节点规模会发生变化的场景。

7.4 SSL的工作原理

SSL与TLS SSL：（Secure Socket Layer，安全套接字层），位于可靠的面向连接的网络层协议和应用层协议之间的一种协议层。

SSL通过互相认证、使用数字签名确保完整性、使用加密确保私密性，以实现客户端和服务器之间的安全通讯。该协议由两层组成：SSL记录协议和SSL握手协议。

TLS：(Transport Layer Security，传输层安全协议)，TLS（传输层安全）是更为安全的升级版 SSL，用于两个应用程序之间提供保密性和数据完整性。该协议由两层组成：TLS记录协议和TLS握手协议。

传统的 TLS 握手基本都是使用 RSA 算法来实现密钥交换的，在将 TLS 证书部署服务端时，证书文件中包含一对公私钥，其中公钥会在 TLS 握手阶段传递给客户端，私钥则一直留在服务端，一定要确保私钥不能被窃取。在 RSA 密钥协商算法中，客户端会生成随机密钥，并使用服务端的公钥加密后再传给服务端.

SSL/TLS历史 1994年，NetScape公司设计了SSL协议（Secure Sockets Layer）的1.0版，但是未发布。

1995年，NetScape公司发布SSL 2.0版，很快发现有严重漏洞。

1996年，SSL 3.0版问世，得到大规模应用。 1999年，**互联网标准化组织ISOC接替NetScape公司，**发布了SSL的升级版TLS 1.0版。

2006年和2008年，TLS进行了两次升级，分别为TLS 1.1版和TLS 1.2版。最新的变动是2011年TLS 1.2的修订版，在2018年也发布了TLS1.3版本。 TLS 1.0通常被标示为SSL 3.1，TLS 1.1为SSL 3.2，TLS 1.2为SSL 3.3。

目前应用的最广泛的 TLS 是 1.2，而之前的协议（TLS1.1/1.0、SSLv3/v2）都已经被认为是不安全的了。

SSL/TLS协议的基本过程

（1） 客户端向服务器端索要并验证公钥。

（2） 双方协商生成“对话密钥”。

（3） 双方采用“对话密钥”进行加密通信。上面过程的前两步，又称为**“握手阶段”（handshake）**

TLS/SSL的功能实现主要依赖于三类基本算法：

散列函数 Hash、对称加密DES、3DES、IDEA、AES和非对称加密RSA、DSA、ECC、Diffie-Hellman，

其利用非对称加密实现身份认证和密钥协商，对称加密算法采用协商的密钥对数据加密，基于散列函数验证信息的完整性。

CA证书

现实中，通过CA（Certificate Authority）来保证public key的真实性。CA也是基于非对称加密算法来工作。

有了CA，B会先把自己的public key（和一些其他信息）交给CA。CA用自己的private key加密这些数据，加密完的数据称为B的数字证书。

现在B要向A传递public key，B传递的是CA加密之后的数字证书。A收到以后，会通过CA发布的CA证书（包含了CA的public key），来解密B的数字证书，从而获得B的public key。

但是等等，A怎么确保CA证书不被劫持。C完全可以把一个假的CA证书发给A，进而欺骗A。

CA的大杀器就是，CA把自己的CA证书集成在了浏览器和操作系统里面。A拿到浏览器或者操作系统的时候，已经有了CA证书，没有必要通过网络获取，那自然也不存在劫持的问题。

TLS 握手

TLS第一次握手

客户端首先会发一个「Client Hello」消息

消息里面有客户端使用的 TLS 版本号、支持的密码套件列表，以及生成的随机数（Client Random）

这个随机数会被服务端保留，它是生成对称加密密钥的材料之一

TLS 第二次握手

当服务端收到客户端的「Client Hello」消息后，会确认 TLS 版本号是否支持，和从密码套件列表中选择一个密码套件，以及生成随机数（Server Random）。

接着，返回「Server Hello」消息，消息里面有服务器确认的 TLS 版本号，也给出了随机数（Server Random），然后从客户端的密码套件列表选择了一个合适的密码套件。

这个密码套件看起来真让人头晕，好一大串，但是其实它是有固定格式和规范的。基本的形式是「密钥交换算法 + 签名算法 + 对称加密算法 + 摘要算法」

Diffie-Hellman密钥交换算法:

Diffie-Hellman密钥交换算法是一种用于在不安全的通信信道上安全地交换密钥的算法。它允许两个通信方在没有事先共享密钥的情况下协商出一个共享的对称密钥，该密钥可以用于后续的加密通信。

Diffie-Hellman算法的基本思想是利用数论中的离散对数问题。具体步骤如下：

1. **参数选择**：选择两个大素数p和g，其中p是一个素数，g是一个原根（即对于任意小于p的正整数a，都存在一个整数k使得$g^k ≡ a \mod p$）。
2. **密钥生成**：
    - 选择私密参数：每个通信方选择一个私密参数（私钥）。假设Alice选择私钥a，Bob选择私钥b。
    - 计算公开参数：计算公开参数（公钥）。Alice计算$A = g^a \mod p$，Bob计算$B = g^b \mod p$。
    - 交换公开参数：Alice将A发送给Bob，Bob将B发送给Alice。
3. **密钥协商**：
    - 计算共享密钥：Alice使用Bob发送的B和自己的私钥a计算共享密钥$K = B^a \mod p$，Bob使用Alice发送的A和自己的私钥b计算共享密钥$K = A^b \mod p$。

由于离散对数问题的困难性，即使攻击者能够截获Alice和Bob之间的通信，也很难从A、B和p中推导出共享密钥K，因此Diffie-Hellman算法能够安全地协商出一个共享密钥，用于后续的加密通信。

TLS 第三次握手

公钥；
持有者信息；
证书认证机构（CA）的信息；
CA 对这份文件的数字签名及使用的算法；
证书有效期；
还有一些其他额外信息；
数字证书的作用，是用来认证公钥持有者的身份，以防止第三方进行冒充。说简单些，证书就是用来告诉客户端，该服务端是否是合法的，因为只有证书合法，才代表服务端身份是可信的。

客户端验证完证书后，认为可信则继续往下走。接着，客户端就会生成一个新的随机数 (pre-master)，用服务器的 RSA 公钥加密该随机数，通过**「Change Cipher Key Exchange」消息传给服务端。**

那这个随机数有啥用呢？其实这两个随机数是后续作为生成「会话密钥」的条件

所谓的会话密钥就是数据传输时，所使用的对称加密密钥。

于是，双方根据已经得到的三个随机数，生成会话密钥（Master Secret），它是对称密钥，用于对后续的 HTTP 请求/响应的数据加解密。

TLS 第四次握手

服务器也是同样的操作，发「Change Cipher Spec」和「Encrypted Handshake Message」消息，如果双方都验证加密和解密没问题，那么握手正式完成。

HTTPS ECDHE 握手解析

分别是 RSA 和 ECDHE 算法。

RSA 和 ECDHE 握手过程的区别：

RSA 密钥协商算法「不支持」前向保密，ECDHE 密钥协商算法「支持」前向保密，非对称密钥；
使用了 RSA 密钥协商算法，TLS 完成四次握手后，才能进行应用数据传输
而对于 ECDHE 算法，**客户端可以不用等服务端的最后一次 TLS 握手，就可以提前发出加密的 HTTP 数据，**节省了一个消息的往返时间；
使用 ECDHE，在 TLS 第 2 次握手中，会出现服务器端发出的「Server Key Exchange」消息，而 RSA 握手过程没有该消息；

7.5 路由器是如何选择最佳路径的

路由器是一种用于网络互连的专用计算机设备,在网路建设中有着重要的地位.

路由器工作在OSI参考模型的第三层(网络层),主要的作用是为收到的报文寻找正确的路径,并把他们转发出去.

在这个过程中,路由器被认为执行了两个最重要的基本功能:路由功能和交换功能.

对于一个特定的路由协议,可以发现到达目的网络的所有路径, 根据选路算法赋予每一条路径metric值,比较metric值,选择metric值最小的路径为最佳路径;

在路由器的交换过程中查找路由时可能会发现能匹配上多条路由条目.

此时路由器将根据掩码长度最长匹配原则进行数据的转发.路由器会进行匹配最深的,也就是说可以匹配的掩码长度最长的一条路由进行转发。

第一，最长掩码匹配原则；例如，查找去往192.168.1.1的路径时，发现路由表有如下两个表项 192.168.1.0 mask 255.255.255.0 next hop 10.1.1.1

192.168.1.0 mask 255.255.0.0 next hop 172.16.1.1

路由器会选择第一条路由转发，因为第一条的IP地址范围更小

第二，如果路由表中目的网段的范围相同，路由优先级高者优先（优先级数值越小，优先级越高）

第三，如果路由表中目的网段的范围相同，并且路由优先级也相同，开销（metric）小的优先（metric值越小，开销越小）

路由选择算法可分为：

全局式路由选择算法：所有路由器掌握完整的网络拓扑和链路费用信息，例如链路状态(LS)路由算法，链路状态路由选择算法可以用Dijksua算法实现。
分散式路由选择算法；路由器只掌握物理相连的邻居以及链路费用，例如距离向量(DV)路由算法，距离向量路由选择算法可以用Bellman-Ford方程dx(y) = min {c(x,v) + dv(y)}实现。

7.6 子网掩码的作用

1、一是用于屏蔽IP地址的一部分以区别网络标识和主机标识，并说明该IP地址是在局域网上，还是在远程网上。

2、二是用于将一个大的IP网络划分为若干小的子网络。

使用子网是为了减少IP的浪费。因为随着互联网的发展，越来越多的网络产生，有的网络多则几百台，有的只有区区几台，这样就浪费了很多IP地址，所以要划分子网。使用子网可以提高网络应用的效率。

7.7 HTTP请求报文和响应报文分别由哪些部分组成？

HTTP请求报文

由请求行（request line）、请求头部（header）、空行和请求数据4个部分组成，下图给出了请求报文的一般格式。

img

1.请求头

请求行由请求方法字段、URL字段和HTTP协议版本字段3个字段组成，它们用空格分隔。例如，GET /index.html HTTP/1.1。

2.请求头部

请求头部由关键字/值对组成，每行一对，关键字和值用英文冒号“:”分隔。请求头部通知服务器有关于客户端请求的信息，典型的请求头有：

User-Agent：产生请求的浏览器类型。

Accept：客户端可识别的内容类型列表。

Host：请求的主机名，允许多个域名同处一个IP地址，即虚拟主机。

3.空行

最后一个请求头之后是一个空行，发送回车符和换行符，通知服务器以下不再有请求头。

4.请求数据

请求数据不在GET方法中使用，而是在POST方法中使用。POST方法适用于需要客户填写表单的场合。与请求数据相关的最常使用的请求头是Content-Type和Content-Length。

GET /search?hl=zh-CN&source=hp&q=domety&aq=f&oq= HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-silverlight, application/x-shockwave-flash, */*
Referer: <a href="http://www.google.cn/">http://www.google.cn/</a>
Accept-Language: zh-cn
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; TheWorld)
Host: <a href="http://www.google.cn">www.google.cn</a>
Connection: Keep-Alive
Cookie: PREF=ID=80a06da87be9ae3c:U=f7167333e2c3b714:NW=1:TM=1261551909:LM=1261551917:S=ybYcq2wpfefs4V9g; NID=31=ojj8d-IygaEtSxLgaJmqSjVhCspkviJrB6omjamNrSm8lZhKy_yMfO2M4QMRKcH1g0iQv9u-2hfBW7bUFwVh7pGaRUb0RnHcJU37y-FxlRugatx63JLv7CWMD6UB_O_r

POST /search HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-silverlight, application/x-shockwave-flash, */*
Referer: <a href="http://www.google.cn/">http://www.google.cn/</a>
Accept-Language: zh-cn
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; TheWorld)
Host: <a href="http://www.google.cn">www.google.cn</a>
Connection: Keep-Alive
Cookie: PREF=ID=80a06da87be9ae3c:U=f7167333e2c3b714:NW=1:TM=1261551909:LM=1261551917:S=ybYcq2wpfefs4V9g; NID=31=ojj8d-IygaEtSxLgaJmqSjVhCspkviJrB6omjamNrSm8lZhKy_yMfO2M4QMRKcH1g0iQv9u-2hfBW7bUFwVh7pGaRUb0RnHcJU37y-FxlRugatx63JLv7CWMD6UB_O_r

hl=zh-CN&source=hp&q=domety

HTTP报文

HTTP响应也由三个部分组成，分别是：状态行、消息报头、响应正文。

正如你所见，在响应中唯一真正的区别在于第一行中用状态信息代替了请求信息。状态行（status line）通过提供一个状态码来说明所请求的资源情况。

状态行格式如下：

HTTP-Version Status-Code Reason-Phrase CRLF

其中，HTTP-Version表示服务器HTTP协议的版本；Status-Code表示服务器发回的响应状态代码；Reason-Phrase表示状态代码的文本描述。

状态代码由三位数字组成，第一个数字定义了响应的类别，且有五种可能取值。

1xx：指示信息–表示请求已接收，继续处理。
2xx：成功–表示请求已被成功接收、理解、接受。
3xx：重定向–要完成请求必须进行更进一步的操作。
4xx：客户端错误–请求有语法错误或请求无法实现。
5xx：服务器端错误–服务器未能实现合法的请求。

HTTP/1.1 200 OK
Date: Sat, 31 Dec 2005 23:59:59 GMT
Content-Type: text/html;charset=ISO-8859-1
Content-Length: 122

＜html＞
＜head＞
＜title＞Wrox Homepage＜/title＞
＜/head＞
＜body＞
＜!-- body goes here --＞
＜/body＞
＜/html＞

7.8 代理服务器的工作原理是怎样的？代理和网关有什么区别？

代理服务器和网关都会把网络内部的数据的数据发送到因特网上。

如果把网关比作一扇通向因特网的门，代理服务器就是一堵墙，能够避免暴露网络内部的一些重要信息。

代理服务器会过滤一些网络连接，只允许那些可以访问的通过。而网关却不做任何的过滤。

网关：

如果两个网络要进行通讯，那么每个网络都需要一个网关。网关区分了一个网络的内部和外部。如果一台电脑需要访问网络外的其他电脑，那么就需要配置网关来获得访问网络外部的权限。如果没有网关，电脑就无法访问局域网之外的网络部分，就像是被锁在家里一样。

代理服务器：

对于网络外部来说，代理服务器代表了整个内部网络。任何用户想访问带有代理服务器的网络，都只能看到代理服务器的IP。当把电脑的Internet选项配置成通过代理服务器访问因特网，代理服务器就能隐藏你的网络信息。它使网络内部的电脑变成匿名的。

功能区别：

如果代理服务器不做任何信息过滤，那么它就和网关一样，传递从电脑到因特网的请求。

然后代理服务器是一个比网关更强大的网络组建，除了有网关的功能之外，还能保护网络免受外部的威胁。网关却有暴露网络内部信息的危险，因为它没有任何过滤机制。它仅仅把网络内的信息发送到网络外。

屏蔽网站：

网关不能屏蔽网站。只要网关配置正确，电脑就能从网络内部访问因特网上的任何网站。

代理服务器能把网络请求重定向到网络内部的网站上，从而屏蔽网站。

管理员可以设置在某个时段或者全天时间屏蔽一些网站。访问这些被屏蔽的网站会重定向到特定的网站上，表示你试图访问一个被屏蔽的网站。

其他代理服务器的功能：

代理服务器也能缓存一些电脑经常访问的网站。它能跟踪网站点击量并使用这些信息储存每天访问的网站信息。当你第二次访问你之前访问过的网站时，代理服务器会返回缓存中的网站信息，而不会访问因特网。这个功能可以有效的减少访问外部网络的流量，节省带宽资源。可以设置每天几次获取因特网的新内容来刷新代理服务器的缓存信息。

在HTTP通信链上，客户端和目标服务器之间通常存在某些**中转代理服务器，**它们提供对目标资源的中转访问。’

一个HTTP请求可能被多个代理服务器转发，后面的服务器称为前面服务器的上游服务器。

代理服务器按照其使用方式和作用，分为正向代理服务器，反向代理服务器和透明代理服务器。

正向代理要求客户端自己设置代理服务器的地址。客户的每次请求都将直接发送到该代理服务器，并由代理服务器来请求目标资源。比如处于防火墙内的局域网机器要访问Internet，或者要访问一些被屏蔽掉的国外网站，就需要使用正向代理服务器。

反向代理则被设置在服务器端，因而客户端无需进行任何设置。反向代理是指用代理服务器来接收Internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从内部服务器上得到的结果返回给客户端。

这种情况下，代理服务器对外就表现为一个真实的服务器。

各大网站通常分区域设置了多个代理服务器，所以在不同的地方ping同一个域名可能得到不同的IP地址，因为这些IP地址实际上是代理服务器的IP地址。

如图所示，正向代理服务器和客户端主机处于同一个逻辑网络中。该逻辑网络可以是一个本地LAN，也可以是一个更大的网络。

反向代理服务器和真正的Web服务器也位于同一个逻辑网络中**，这通常由提供网站的公司来配置和管理。**

透明代理只能设置在网关上。用户访问Internet的数据报必然都经过网关，如果在网关上设置代理，则该代理对用户来说显然是透明的。透明代理可以看作正向代理的一种特殊情况。

代理服务器通常还提供缓存目标资源的功能，这样用户下次访问同一资源时速度将很快。优秀的开源软件squid，varnish都是提供了缓存能力的代理服务器软件，其中squid支持所有代理方式，而varnish仅能用作反向代理。

7.9 浏览器输入百度地址，中间具体访问过程是怎么样的？

1.客户端浏览器获取用户在地址栏输入的域名,URL解析。

2.客户端浏览器将域名发送给DNS域名系统，请求解析,DNS解析 。

3.DNS解析域名得到相应的IP，返回给客户端浏览器。

4.客户端浏览器根据IP向服务器发起TCP三次握手，建立TCP连接。

5.客户端浏览器向服务器发送HTTP请求，请求百度首页。

6.服务器通过HTTP响应向客户端浏览器返回百度首页文件。

7.释放TCP连接。

8.客户端浏览器解析HTML文件，根据文件内容获取CSS、JS等资源文件，将页面渲染展示给用户。

7.10 网卡网桥，网关，路由器，交换机

路由器可以根据IP地址寻找下一个设备，可以处理TCPIP协议

交换机是根据MAC地址寻址的。

路由器是用于在不同网段之间转发数据（网络层）

二层交换机是用于在同网段转发数据（数据链路层）

三层交换机是可以在不同网段转发数据但在同网段转发数据能力特别强的交换机 即可理解为路由器➕交换机（网络层）

一个网关可以是路由器可以是三层交换机

交换机是分配网络数据，路由器可以给网络分配IP地址，分配给你地址而且可以随时通过地址过来找到你。

路由器可以在不同时间内把一个IP分配给多台主机使用。

交换机是通过MAC地址和识别各个不同的主机。工作在OSI第二层（数据链路层）

一、中继器

中继器（Repeater）工作于OSI的第一层（物理层），中继器是最简单的网络互联设备，连接同一个网络的两个或多个网段，主要完成物理层的功能，负责在两个网络节点的物理层上按位传递信息，完成信号的复制、调整和放大功能，以此从而增加信号传输的距离，延长网络的长度和覆盖区域，支持远距离的通信。

一般来说，中继器两端的网络部分是网段，而不是子网。中继器只将任何电缆段上的数据发送到另一段电缆上，并不管数据中是否有错误数据或不适于网段的数据。大家最常接触的是网络中继器，在通讯上还有微波中继器、激光中继器、红外中继器等等，机理类似，触类旁通。

二、集线器

集线器也称HUB，工作在OSI七层结构的第一层物理层，属于共享型设备，接收数据广播发出，在局域网内一般都是星型连接拓扑结构，每台工作站都连接到集线器上。由于集线器的带宽共享特性导致网络利用效率极低，一般在大中型的网络中不会使用到集线器。现在的集线器基本都是全双工模式，市面上常见的集线器传输速率普遍都为100Mbps。

三、网桥

网桥和交换机一样都是工作在OSI模型的第二层（数据链路层），可以看成是一个二层路由器（真正的路由器是工作在网络层，根据IP地址进行信包转发）。

网桥可有效的将两个局域网（LAN）连起来，根据MAC地址（物理地址）来转发帧，使本地通信限制在本网段内，并转发相应的信号至另一网段，网桥通常用于联接数量不多的、同一类型的网段。

四、交换机

交换机顾名思义以交换为主要功能，工作在OSI第二层（数据链路层），根据MAC地址进行数据转发。交换机的每一个端口都属于一个冲突域，而集线器所有端口属于一个冲突域。

交换机通过分析Ethernet包的包头信息（其中包含了源MAC地址、目标MAC地址、信息长度等），取得目标MAC地址后，查找交换机中存储的地址对照表（MAC地址对应的端口），确认具有此MAC地址的网卡连接在哪个端口上，然后将信包送到对应端口，有效的抑制IP广播风暴。并且信息包处于并行状态，效率较高。

数据包通过交换机转发抵达了路由器，准备要离开土生土长的子网了。此时，数据包和交换机离别时说道：“感谢交换机兄弟，帮我转发到出境的大门，我要出远门啦！”

交换机的转发延迟非常小，主要的得益于其硬件设计机理非常高效，为了支持各端口的最大数据传输速率，交换机内部转发信包的背板带宽都必须远大于端口带宽，具有强大的整体吞吐率，才能为每台工作站提供更高的带宽和更高的网络利用率，可以满足大型网络环境大量数据并行处理的要求。

五、路由器

路由器跟集线器和交换机不同，是工作在OSI的第三层（网络层），根据IP进行寻址转发数据包。

路由器是一种可以连接多个网络或网段的网络设备，能将不同网络或网段之间（比如局域网——大网）的数据信息进行转换，并为信包传输分配最合适的路径，使它们之间能够进行数据传输，从而构成一个更大的网络。

路由器具有最主要的两个功能，即数据通道功能和控制功能。

数据通道功能包括转发决定、背板转发以及输出链路调度等，一般由特定的硬件来完成；

控制功能一般用软件来实现，包括与相邻路由器之间的信息交换、系统配置、系统管理等。实在找不到匹配路由时，就会选择默认路由，路由表中子网掩码为 0.0.0.0 的记录表示「默认路由」。

六、网关

网关（Gateway）又叫协议转换器，网关是一种复杂的网络连接设备，可以支持不同协议之间的转换，实现不同协议网络之间的互连。

在网络中，路由器为第三层网络层设备，其主要功能是根据最佳路由把数据包转发到下一站，实现从源IP到目标IP的端到端数据传输服务；
网关早期的时候就是路由器的别名，但是在现在的网络模型中把它归为应用层设备。主要功能是过滤数据包信息以实现相应的功能网关的概念实际上跟上面的设备型不是一类问题，但是为了方便参考还是放到这里一并介绍。

网关具有对不兼容的高层协议进行转换的能力，为了实现异构设备之间的通信，网关需要对不同的链路层、专用会话层、表示层和应用层协议进行翻译和转换。所以网关兼有路由器、网桥、中继器的特性。

若要使两个完全不同的网络（异构网）连接在一起，一般使用网关，在Internet中两个网络也要通过一台称为网关的计算机实现互联。这台计算机能根据用户通信目标计算机的IP地址，决定是否将用户发出的信息送出本地网络，同时，它还将外界发送给属于本地网络计算机的信息接收过来，它是一个网络与另一个网络相联的通道。为了使TCP/IP协议能够寻址，该通道被赋予一个IP地址，这个IP地址称为网关地址。

所以，网关的作用就是将两个使用不同协议的网络段连接在一起的设备，对两个网络段中的使用不同传输协议的数据进行互相的翻译转换。在互连设备中，由于协议转换的复杂性，一般只能进行一对一的转换，或是少数几种特定应用协议的转换。

网卡：

网络包只是存放在内存中的一串二进制数字信息，没有办法直接发送给对方。

因此，我们需要将数字信息转换为电信号，才能在网线上传输，也就是说，这才是真正的数据发送过程。负责执行这一操作的是网卡，要控制网卡还需要靠网卡驱动程序。

网卡驱动获取网络包之后，会将其复制到网卡内的缓存区中，接着会在其开头加上报头和起始帧分界符，在末尾加上用于检测错误的帧校验序列。

最后网卡会将包转为电信号，通过网线发送出去。

网关和路由器区别：

1、本质区别

网关这种设备它主要是用来连接两种不同的网络，同时，网关它还能够同时与两边的主机之间进行通信。但是两边的主机是不能够直接进行通信，是必须要经过网关才能进行通信。网关的工作是在应用层当中。

路由器它是属于网络层设备，通常是以包为单位进行数据的发送。

在路由器的子接口，是有分割广播域的作用，所以当我们用交换机做VLAN以后，都是要在路由器上做一个三层的路由。

2、使用方式的区别

网关它可以是路由器，交换机或者是PC。在同一网段之内进行通信，是不需要将网关介入其中，只有当主机个非本网段设备进行通信的时候，才需要将数据包全部发给网关设备，再经由网关设备进行转发或者是有路由处理等。

路由器它是一个网络层系统，路由器在现在市场上一般是被分成了两大类，一类是单协议路由器，另一类是多协议路由器。路由器它可以进行数据格式的转换，成为不同于协议之间的网络互连的必要设备。

3、功能上的区别

网关可以分为传输型网关和应用型网关，它的功能是充当转换重任，实质上就是一个网络通向其他网络的IP地址。

路由器的功能主要有：连通不同的网络和信息传输作用。按照使用可分为：接入、企业级、骨干级、太比特、多WAN以及3G无线等。

7.11 HTTP缓存技术

HTTP 缓存有两种实现方式，分别是强制缓存和协商缓存。

强制缓存

强缓存指的是只要浏览器判断缓存没有过期，则直接使用浏览器的本地缓存，决定是否使用缓存的主动性在于浏览器这边。

如下图中，返回的是 200 状态码，但在 size 项中标识的是 from disk cache，就是使用了强制缓存。

强缓存是利用下面这两个 HTTP 响应头部（Response Header）字段实现的，它们都用来表示资源在客户端缓存的有效期：

Cache-Control，是一个相对时间；
Expires，是一个绝对时间；

如果 HTTP 响应头部同时有 Cache-Control 和 Expires 字段的话，Cache-Control的优先级高于 Expires 。

Cache-control 选项更多一些，设置更加精细，所以建议使用 Cache-Control 来实现强缓存。具体的实现流程如下：

当浏览器第一次请求访问服务器资源时，服务器会在返回这个资源的同时，在 Response 头部加上 Cache-Control，Cache-Control 中设置了过期时间大小；
浏览器再次请求访问服务器中的该资源时，会先通过请求资源的时间与 Cache-Control 中设置的过期时间大小，来计算出该资源是否过期，如果没有，则使用该缓存，否则重新请求服务器；
服务器再次收到请求后，会再次更新 Response 头部的 Cache-Control。

协商缓存

当我们在浏览器使用开发者工具的时候，你可能会看到过某些请求的响应码是 304，这个是告诉浏览器可以使用本地缓存的资源，通常这种通过服务端告知客户端是否可以使用缓存的方式被称为协商缓存。

上图就是一个协商缓存的过程，所以协商缓存就是与服务端协商之后，通过协商结果来判断是否使用本地缓存。

协商缓存可以基于两种头部来实现。

第一种：请求头部中的 If-Modified-Since 字段与响应头部中的 Last-Modified 字段实现，这两个字段的意思是：

响应头部中的 Last-Modified：标示这个响应资源的最后修改时间；
请求头部中的 If-Modified-Since：当资源过期了，发现响应头中具有 Last-Modified 声明，则再次发起请求的时候带上 Last-Modified 的时间，服务器收到请求后发现有 If-Modified-Since 则与被请求资源的最后修改时间进行对比（Last-Modified），如果最后修改时间较新（大），说明资源又被改过，则返回最新资源，**HTTP 200 OK；**如果最后修改时间较旧（小），说明资源无新修改，响应 HTTP 304 走缓存。

第二种：请求头部中的 If-None-Match 字段与响应头部中的 ETag 字段，这两个字段的意思是：

响应头部中 Etag：唯一标识响应资源；
请求头部中的 If-None-Match：当资源过期时，浏览器发现响应头里有 Etag，则再次向服务器发起请求时，会将请求头If-None-Match 值设置为 Etag 的值。服务器收到请求后进行比对，如果资源没有变化返回 304，如果资源变化了返回 200。

第一种实现方式是基于时间实现的，第二种实现方式是基于一个唯一标识实现的，相对来说后者可以更加准确地判断文件内容是否被修改，避免由于时间篡改导致的不可靠问题。

如果 HTTP 响应头部同时有 Etag 和 Last-Modified 字段的时候， Etag 的优先级更高，也就是先会判断 Etag 是否变化了，如果 Etag 没有变化，然后再看 Last-Modified。

注意，协商缓存这两个字段都需要配合强制缓存中 Cache-control 字段来使用，只有在未能命中强制缓存的时候，才能发起带有协商缓存字段的请求。

使用 ETag 字段实现的协商缓存的过程如下；

当浏览器第一次请求访问服务器资源时，服务器会在返回这个资源的同时，在 Response 头部加上 ETag 唯一标识，这个唯一标识的值是根据当前请求的资源生成的；
当浏览器再次请求访问服务器中的该资源时，首先会先检查强制缓存是否过期，如果没有过期，则直接使用本地缓存；如果缓存过期了，会在 Request 头部加上 If-None-Match 字段，该字段的值就是 ETag 唯一标识；
服务器再次收到请求后，

会根据请求中的 If-None-Match 值与当前请求的资源生成的唯一标识进行比较
- 如果值相等，则返回 304 Not Modified，不会返回资源；
- 如果不相等，则返回 200 状态码和返回资源，并在 Response 头部加上新的 ETag 唯一标识；
如果浏览器收到 304 的请求响应状态码，则会从本地缓存中加载资源，否则更新资源

计算机网络学习小结

Wed, 16 Oct 2019 19:32:27 +0800

#1. 网络结构

1.1 计算机网络结构？

计算机网络一共有3种模型。

OSI七层结构
TCP/IP结构
五层协议结构

OSI是Open Systems Interconnect，也就是开放的互联系统，将复杂的互联网系统划分为不同块，方便处理。

实际应用中，并没有采用这个理论模型，而是使用TCP/IP协议的四层模型。

而5层模型是一个理论上的网络通信模型，方便教学的时候理解，实际上并不存在。

1.2 计算机网络中各层作用

（1）应用层

应用层的任务是通过应用进程间的交互来完成特定网络应用，访问OSI环境的手段，应用层协议定义的是应用进程（进程:主机中正在运行的程序）间的通信和交互的规则。

常见的协议有域名系统DNS，万维网应用的HTTP协议，支持电子邮件的SMTP协议。

应用层是不用去关心数据是如何传输的，就类似于，我们寄快递的时候，只需要把包裹交给快递员，由他负责运输快递，我们不需要关心快递是如何被运输的。

把应用层交互的数据单元称为报文。

（2）运输层

为两台主机进程之间的通信提供**通用的数据传输服务，端对端的可靠报文传递和错误恢复。**主要包含两种协议：

传输控制协议 TCP（Transmisson Control Protocol）。

面向连接面向字节流可靠传输慢流量控制阻塞控制 1v1

**面向连接（三次握手四次挥手），面向字节流（把应用层传下来的报文看成字节流，把字节流组织成大小不等的数据块），可靠（握手、ACK和重传机制），传输慢，**有流量控制阻塞控制。
用户数据报协议 UDP（User Datagram Protocol）。

无连接，面向报文，不可靠尽最大可能交付，传输快，没有流量控制和拥塞控制，可1vn to nv1

无连接的，尽最大可能交付，不可靠，面向报文（对于应用程序传下来的报文不合并也不拆分，只是添加 UDP 首部），支持一对一、一对多、多对一和多对多的交互通信，传输快，没有流量控制拥塞控制。

当然，UDP 也可以实现可靠传输，把 TCP 的特性在应用层上实现就可以，不过要实现一个商用的可靠 UDP 传输协议，也不是一件简单的事情。

应用需要传输的数据可能会非常大，如果直接传输就不好控制，因此当传输层的数据包大小超过 MSS（TCP 最大报文段长度），就要将数据包分块，这样即使中途有一个分块丢失或损坏了，只需要重新发送这一个分块，而不用重新发送整个数据包。

在 TCP 协议中，我们把每个分块称为一个 TCP 段（TCP Segment）。

当设备作为接收方时，传输层则要负责把数据包传给应用，但是一台设备上可能会有很多应用在接收或者传输数据，因此需要用一个编号将应用区分开来，这个编号就是端口。

比如 80 端口通常是 Web 服务器用的，22 端口通常是远程登录服务器用的。

而对于浏览器（客户端）中的每个标签栏都是一个独立的进程，操作系统会为这些进程分配临时的端口号。由于传输层的报文中会携带端口号，因此接收方可以识别出该报文是发送给哪个应用。

（3）网络层

网络层的任务就是选择合适的网间路由和交换结点，确保数据及时传送，数据包传递与网际互连。

网络层最常使用的是 IP 协议（Internet Protocol），IP 协议会将传输层的报文作为数据部分，再加上 IP 包头组装成 IP 报文，如果 IP 报文大小超过 MTU（最大传输单元，Maximum Transmission Unit）以太网中一般为 1500 字节）就会再次进行分片，得到一个即将发送到网络的 IP 报文。

使用IP协议，ARP协议，IP协议，ICMP协议，IGMP协议等。

网络层有两个任务：

把运输层产生的报文段或用户数据报 封装成分组和包进行传送。在 TCP/IP 体系结构中，由于网络层使用 IP 协议，因此分组也叫 IP 数据报 ，简称 数据报。
注意：不要把运输层的用户数据报UDP和网络层的IP数据报弄混。
选择合适的路由，找到目的主机。

网络层负责将数据从一个设备传输到另一个设备，世界上那么多设备，又该如何找到对方呢？因此，网络层需要有区分设备的编号。

我们一般用 IP 地址给设备进行编号，对于 IPv4 协议， IP 地址共 32 位，分成了四段（比如，192.168.100.1），每段是 8 位。只有一个单纯的 IP 地址虽然做到了区分设备，但是寻址起来就特别麻烦，全世界那么多台设备，难道一个一个去匹配？这显然不科学。

因此，需要将 IP 地址分成两种意义：

一个是网络号，负责标识该 IP 地址是属于哪个「子网」的；
一个是主机号，负责标识同一「子网」下的不同主机；

（4）数据链路层

数据链路层的任务是确保在直接相连的两个节点之间可靠地传输数据，并处理与物理层交互和链路管理相关的事务

两台主机之间的数据传输，总是在一段一段的链路上传送的，这就需要使用专门的链路层的协议。

在两个相邻节点之间传送数据时，数据链路层将网络层交下来的 IP 数据报组装程帧，在两个相邻节点间的链路上传送帧。

主要协议：1、Point-to-Point Protocal——PPP点到点。2、Ethernet——以太网。3、High-Level Data Link Control Protocal——高级链路控制协议。4、Frame Relay——帧中继。5、Asynchronous Transfer Mode——异步传输模式。

每一帧包括数据和必要的控制信息（如同步信息，地址信息，差错控制等）。

（5）物理层

物理层的任务就是透明地传输比特流，尽可能屏蔽掉具体传输介质和物理设备的差异，确定电气规范，使其上面的数据链路层不必考虑网络的具体传输介质是什么。换句话说实际电路传送后比特流没有发生变化。

Tips:

网络接口层

生成了 IP 头部之后，接下来要交给**网络接口层（Link Layer）在 IP 头部的前面加上 MAC 头部，**并封装成数据帧（Data frame）发送到网络上。

主要为网络层提供「链路级别」传输的服务，负责在以太网、WiFi 这样的底层网络上发送原始数据包，工作在网卡这个层次，使用 MAC 地址来标识网络上的设备。

2. TCP/IP协议

2.1 TCP/IP协议的结构

1、源端口号（Source Port） 16位的源端口字段包含初始化通信的端口号。源端口和IP地址的作用是标识报文的返回地址。

2、目的端口号（Destination Port）　16位的目的端口字段定义传输的目的。这个端口指明接收方计算机上的应用程序接口。

3、序列号（Sequence Number）该字段用来标识TCP源端设备向目的端设备发送的字节流，它表示在这个报文段中的第几个数据字节。序列号是一个32位的数。

4、确认号（Acknowledge Number）　　TCP使用32位的确认号字段标识期望收到的下一个段的第一个字节，并声明此前的所有数据已经正确无误地收到，因此，确认号应该是上次已成功收到的数据字节序列号加1。收到确认号的源计算机会知道特定的段已经被收到。确认号的字段只在ACK标志被设置时才有效。 5、首部长度长度为4位，用于表示TCP报文首部的长度。用4位（bit）表示，十进制值就是[0,15]，一个TCP报文前20个字节是必有的，后40个字节根据情况可能有可能没有。如果TCP报文首部是20个字节，则该位应是20/4=5。 6、保留位（Reserved）长度为6位，必须是0，它是为将来定义新用途保留的。 7、标志（Code Bits）长度为6位，在TCP报文中不管是握手还是挥手还是传数据等，这6位标志都很重要。6位从左到右依次为： 1. • URG：紧急标志位，说明紧急指针有效； • ACK：确认标志位，多数情况下空，说明确认序号有效；取1时表示应答字段有效，也即TCP应答号将包含在TCP段中，为0则反之。 • PSH：推标志位，置位时表示接收方应立即请求将报文交给应用层； • RST：复位标志，用于重建一个已经混乱的连接，用来复位产生错误的连接，也会用来拒绝错误和非法的数据包。 • SYN：同步标志，该标志仅在三次握手建立TCP连接时有效 • FIN：结束标志，表示发送端已经发送到数据末尾，数据传送完成，发送FIN标志位的TCP段，连接将被断开。 8、窗口大小（Window Size）长度为16位，TCP流量控制由连接的每一端通过声明的窗口大小来提供。 9、检验和（Checksum）长度为16位，该字段覆盖整个TCP报文端，是个强制性的字段，是由发送端计算和存储，到接收端后，由接收端进行验证。 10、紧急指针（Urgent Pointer）长度为16位，指向数据中优先部分的最后一个字节，通知接收方紧急数据的长度，该字段在URG标志置位时有效。 11、选项（Options）长度为0-40B（字节），必须以4B为单位变化，必要时可以填充0。通常包含：最长报文大小（MaximumSegment Size，MSS）、窗口扩大选项、时间戳选项、选择性确认（Selective ACKnowlegement，SACK）等。 12、数据可选报文段数据部分。

首先，源端口号和目标端口号是不可少的，如果没有这两个端口号，数据就不知道应该发给哪个应用。
接下来有包的序号，这个是为了解决包乱序的问题。
还有应该有的是确认号，目的是确认发出去对方是否有收到。如果没有收到就应该重新发送，直到送达，这个是为了解决不丢包的问题。
接下来还有一些状态位flag。例如 SYN 是发起一个连接，ACK 是回复，RST 是重新连接，FIN 是结束连接等。 TCP 是面向连接的，因而双方要维护连接的状态，这些带状态位的包的发送，会引起双方的状态变更。
还有一个重要的就是窗口大小。TCP 要做流量控制，通信双方各声明一个窗口（缓存大小），标识自己当前能够的处理能力，别发送的太快，撑死我，也别发的太慢，饿死我。
除了做流量控制以外，TCP还会做拥塞控制，对于真正的通路堵车不堵车，它无能为力，唯一能做的就是控制自己，也即控制发送的速度。不能改变世界，就改变自己嘛。

UDP报头

每个 UDP 报文分为 UDP 报头和 UDP 数据区两部分。报头由 4 个 16 位长（2 字节）字段组成，分别说明该报文的源端口、目的端口、报文长度和校验值。

UDP 报文中每个字段的含义如下：

源端口：这个字段占据 UDP 报文头的前 16 位，通常包含发送数据报的应用程序所使用的 UDP 端口。接收端的应用程序利用这个字段的值作为发送响应的目的地址。这个字段是可选的，所以发送端的应用程序不一定会把自己的端口号写入该字段中。如果不写入端口号，则把这个字段设置为 0。这样，接收端的应用程序就不能发送响应了。
目的端口：接收端计算机上 UDP 软件使用的端口，占据 16 位。
长度：该字段占据 16 位，表示 UDP 数据报长度**，包含 UDP 报文头和 UDP 数据长度**。因为 UDP 报文头长度是 8 个字节，所以这个值最小为 8。
校验值：该字段占据 16 位，可以检验数据在传输过程中是否被损坏。

IP数据报的首部

注：IP数据报的格式，能够说明IP协议都具有什么功能。

IP数据报首部——固定部分

1.1 版本 占4位，指IP协议的版本。 通信双方使用的IP协议的版本必须一致。 IP协议版本号为4(即IPv4)，IP协议版本号为6(即IPv6)。
1.2 首部长度占4位，可表示的最大十进制数值是15。 这个字段所表示数的单位是32位字(即4字节)，因此，当IP的首部长度为1111(即十进制的15)时，首部长度就达到最大值60个字节。

最常用的首部长度就是20个字节(即首部长度为0101)，这时不使用任何选项，是固定首部的长度。当IP分组的首部长度不是4字节的整数倍时，必须利用最后的填充字段加以填充。
1.3 区分服务 占8位，用来获得更好的服务。

1.4 总长度 占16位，指首部和数据之和的长度。 数据报的最大长度为2^16 -1 = 65535字节。“MTU是Maximum Transmission Unit的缩写。意思是网络上传送的最大数据包

在IP层下面的每一种数据链路层都有其自己的帧格式，其中包括帧格式中的数据字段的最大长度，这称为最大传送单元MTU(Maximum Transfer Unit)。
当一个IP数据报封装成数据链路层的帧时，此数据报的总长度(即首部加上数据部分)，一定不能**超过下面的数据链路层的MTU值。**
虽然使用尽可能长的数据报会使传输效率提高，但由于以太网的普遍应用，所以实际上使用的**数据报长度很少有超过1500字节的。**
为了不使IP数据报的传输效率降低，有关IP的标准文档规定，所有的**主机和路由器必须能够处理的IP数据报的长度不得少于576字节。这个数值也就是最小的IP数据报的总长度。**
当数据报长度超过网络所容许的最大传送单元MTU时，就必须把**过长的数据报进行分片后才能在网络上传送(“片偏移”字段相关)。**
这时，**数据报首部中的总长度不是指未分片前的数据报长度，而是指分片后的每一个分片的首部长度与数据长度的总和。**

1.5 标识 占16位，指IP软件在存储器中维持一个计数器，每产生一个数据报，计数器就加1，并将此值付给标识字段。

但这个标识并不是序号，因为IP是无连接服务，数据报不存在按序接收的问题。当数据报由于长度超过网络的MTU而必须分片时，这个标识字段的值就会被复制到所有的数据报片的标识字段中。相同的标识字段的值使分片后的各数据报片最后能正确地重装成为原来的数据报。
1.6 标志 占3位，但目前只有两位有意义。 标志字段中的最低位记为MF(More Fragment)。

(1) MF=1即表示后面“还有分片”的数据报。

(2)MF=0即表示这已是若干数据报片中的最后一个。

标志字段中的中间位DF(Don’t Fragment)，意思是**“不能分片”**，只有当DF=0时才允许分片。
1.7 片偏移 占13位，指出较长的分钟再分片后，某片在原分组中的相对位置。 也就是说，相对于用户数据字段的起点，该片从何处开始。 片偏移以8个字节为偏移单位。

也就是说，每个分片的长度一定是8字节(64位)的整数倍。 例子：一数据报的总长度为3820字节，其数据部分为3800字节长(使用固定首部)，需要分片为长度不超过1420字节的数据报片。

因固定首部长度为20字节，因此每个数据报片的数据部分长度不能超过1400字节。于是分成3个数据报片，其数据部分的长度分别分为1400,1400和1000字节。原始数据报首部被复制为各数据报片的首部，但必须修改有关字段的值。
1.8 生存时间 占8位，常用的英文缩写是TTL(Time To Live)，表明数据报在网络中的寿命。

由发出数据报的源点设置这个字段。其目的是为了防止无法交付的数据报无限制地在因特网中兜圈子，因而白白浪费网络资源。

随着技术的发展，TTL字段的功能改为“跳数限制”。路由器在转发数据报之前就把TTL值减1。若TTL值减少到零，就丢弃这个数据报，不再转发。

因此，现在TTL的单位不再是秒，而是跳数。

TTL的意义是指明数据报在因特网中至多可经过多少个路由器。显然，数据报能在因特网中经过的路由器的最大数是255。

若把TTL的初始值设置为1，就表示这个数据报只能在本局域网中传送。
1.9 协议 占8位，指出此数据报携带的数据是使用何种协议，一遍使目的主机的IP层知道应将数据部分上交给哪个处理过程。 常用的一些协议和相应协议的字段值。
1.10 首部检验和 占16位，只检验数据报的首部，但不包括数据部分。

这是因为数据报每经过一个路由器，路由器都要重新计算一下首部检验和(一些字段，如生存时间、标志、片偏移等都可能发生变化)。 不检验数据部分可减少计算的工作量。

为了进一步减少计算检验和的工作量，IP首部的检验和不采用复杂的CRC检验码而是采用以下算法： (1)在发送方，先把IP数据报首部划分为许多16位字的序列，并把检验和字段置零。 (2)用反码算术运算把所有16位字相加后，将得到的和的反码写入检验和字段， (3)接收方收到数据报后，将首部的所有16位字再使用反码算术运算相加一次。将得到的和取反码，即得出接收方检验和的计算结果。若首部未发生任何变化，则此结果必为0，于是就保留这个数据报，否则即认为出错，并将此数据报丢弃。
1.11 源地址 占32位。
1.12 目的地址 占32位。

IP数据报首部——可变部分

IP首部的可变部分就是一个选项字段。

2.1 可选字段(长度可变) 选项字段用来支持排错、测量以及安全等措施，内容很丰富。

此字段的长度可变，从1~40个字节不等，取决于所选择的项目。某些选项项目只需要1个字节，它只包括1个字节的选项代码。但还有些选项需要多个字节，这些选项一个个拼接起来，中间不需要有分隔符。
2.2 填充 最后用全0的填充字段补齐成为4字节的整数倍。 注：增加首部的可变部分是为了增加IP数据报的功能，但这同时也使得IP数据报的首部长度成为可变的。

这就增加了每一个路由器处理数据报的开销。实际上这些选项很少被使用。新的IP版本IPv6就把IP数据报的首部长度做成固定的。

2.2 TCP和UDP的区别

TCP：面向连接（三次握手四次挥手），可靠（握手、ACK和重传机制），面向字节流（把应用层传下来的报文看成字节流，把字节流组织成大小不等的数据块），传输慢， 有流量控制阻塞控制。
UDP：无连接的，尽最大可能交付不可靠，面向报文（对于应用程序传下来的报文不合并也不拆分，只是添加 UDP 首部），支持一对一、一对多、多对一和多对多的交互通信, 传输快，没有流量控制拥塞控制，

解释一下报文和字节流的区别：

字节流：**发送次数和接收次数可以不相同。**比如向水池倒了20盆水，可以开水龙头一次性全放出。
报文：发送次数和接收次数必须相同。

两者的应用场景：

TCP：效率要求相对低，但对准确性要求相对高的场景。
- 比如邮件，远程登录，文件传输等对准确性要求较高的地方, 远程控制（SSH）,File Transfer Protocol（FTP）,邮件（SMTP、IMAP）等,点对点文件传出（微信等）
UDP：效率要求相对高，传输快速，对准确性要求相对低的场景。
- 比如QQ聊天、在线视频、网络语音电话等响应速度要求高的场景，广播通信（广播、多播）。网络游戏, 音视频传输, DNS, Ping, 直播

**第三类：模糊地带（TCP、UDP 都可以考虑），HTTP（目前以 TCP 为主），**文件传输？

TCP报文段

序号：用于对字节流进行编号，例如序号为 301，表示第一个字节的编号为301，如果携带的数据长度为 100 字节，那么下一个报文段的序号应为 401，没有携带数据就是302。
确认号ack ：期望收到的下一个报文段的序号。例如 B 正确收到 A 发送来的一个报文段，序号为 501，携带的数据长度为 200 字节，因此 B 期望下一个报文段的序号为 701，B 发送给 A 的确认报文段中确认号就为 701，没有携带数据就是502。
数据偏移 ：指的是数据部分距离报文段起始处的偏移量，实际上指的是首部的长度。
确认 ACK ：当 ACK=1 时确认号字段ack有效，否则无效。TCP 规定，在连接建立后所有传送的报文段都必须把 ACK 置 1。
同步 SYN ：在连接建立时用来同步序号。当 SYN=1，ACK=0 时表示这是一个连接请求报文段。若对方同意建立连接，则响应报文中 SYN=1，ACK=1。
终止 FIN ：用来释放一个连接，当 FIN=1 时，表示此报文段的发送方的数据已发送完毕，并要求释放连接。
窗口：窗口值作为接收方让发送方设置其发送窗口的依据。之所以要有这个限制，是因为接收方的数据缓存空间是有限的。
MTU：一个网络包的最大长度，以太网中一般为 1500 字节。
MSS：除去 IP 和 TCP 头部之后，一个网络包所能容纳的 TCP 数据的最大长度。

如何查看 TCP 的连接状态？

TCP 的连接状态查看，在 Linux 可以通过 netstat -napt 命令查看。

2.4 三次握手和四次挥手

https://jiangren.work/2019/08/01/Socket%E7%BD%91%E7%BB%9C%E7%BC%96%E7%A8%8B%E5%8E%9F%E7%90%86/

三次握手

所谓三次握手是指建立一个TCP连接时，需要客户端和服务器发送3个包。

名词解释：

SYN：Synchronize，同步标志位，为1时表示序列号有效
ACK：Acknowledgment，确认标志位
seq：Synchronize Sequence Number，同步序列号
ack：确认序列号

握手过程：

第一次握手：客户端发送SYN标志为1的包，以及同步序列号x，并指明打算连接的服务器端口。此时，connect进入阻塞状态。

客户端会随机初始化序号（client_isn），将此序号置于 TCP 首部的「序号」字段中，同时把 SYN 标志位置为 1 ，表示 SYN 报文。接着把第一个 SYN 报文发送给服务端，表示向服务端发起连接，该报文不包含应用层数据，之后客户端处于 SYN-SENT 状态。
第二次握手：服务器收到后，发送SYN和ACK标志为1的包，同时也发送一个自己的同步序列号y，外加一个确认序列号ack=x+1。此时accept进入阻塞状态。

服务端收到客户端的 SYN 报文后，首先服务端也随机初始化自己的序号（server_isn），将此序号填入 TCP 首部的「序号」字段中，其次把 TCP 首部的「确认应答号」字段填入 client_isn + 1, 接着把 SYN 和 ACK 标志位置为 1。最后把该报文发给客户端，该报文也不包含应用层数据，之后服务端处于 SYN-RCVD 状态。
第三次握手：客户端收到后，再次发送ACK=1，以及同步序列号seq(x+1)和确认序列号ack(y+1)，与此同时，connect返回。当服务器收到ACK=1时，accept返回。

客户端收到服务端报文后，还要向服务端回应最后一个应答报文，首先该应答报文 TCP 首部 ACK 标志位置为 1 ，其次「确认应答号」字段填入 server_isn + 1 ，最后把报文发送给服务端，这次报文可以携带客户到服务器的数据，之后客户端处于 ESTABLISHED 状态。
服务器收到客户端的应答报文后，也进入 ESTABLISHED 状态。

从上面的过程可以发现第三次握手是可以携带数据的，前两次握手是不可以携带数据的，这也是面试常问的题。

四次挥手

客户端打算关闭连接，此时会发送一个 TCP 首部 FIN 标志位被置为 1 的报文，也即 FIN 报文，之后客户端进入 FIN_WAIT_1 状态。
服务端收到该报文后，就向客户端发送 ACK 应答报文，接着服务端进入 CLOSED_WAIT 状态。
客户端收到服务端的 ACK 应答报文后，之后进入 FIN_WAIT_2 状态。
等待服务端处理完数据后，也向客户端发送 FIN 报文，之后服务端进入 LAST_ACK 状态。
客户端收到服务端的 FIN 报文后，回一个 ACK 应答报文，之后进入 TIME_WAIT 状态
服务器收到了 ACK 应答报文后，就进入了 CLOSED 状态，至此服务端已经完成连接的关闭。
客户端在经过 2MSL 一段时间后，自动进入 CLOSED 状态，至此客户端也完成连接的关闭

Q1. 为什么不能用两次握手连接

三次握手才可以阻止重复历史连接的初始化（主要原因）
三次握手才可以同步双方的初始序列号
三次握手才可以避免资源浪费

原因一：避免历史连接

一个「旧 SYN 报文」比「最新的 SYN 」报文早到达了服务端；
那么此时服务端就会回一个 SYN + ACK 报文给客户端；
客户端收到后可以根据自身的上下文，判断这是一个历史连接（序列号过期或超时），那么客户端就会发送 RST 报文给服务端，表示中止这一次连接。

主要是因为在两次握手的情况下，「被动发起方」没有中间状态给「主动发起方」来阻止历史连接，导致「被动发起方」可能建立一个历史连接，造成资源浪费。

两次握手的情况下，「被动发起方」在收到 SYN 报文后，就进入 ESTABLISHED 状态，意味着这时可以给对方发送数据给，但是「主动发」起方此时还没有进入 ESTABLISHED 状态，假设这次是历史连接，主动发起方判断到此次连接为历史连接，那么就会回 RST 报文来断开连接，而「被动发起方」在第一次握手的时候就进入 ESTABLISHED 状态，所以它可以发送数据的，但是它并不知道这个是历史连接，它只有在收到 RST 报文后，才会断开连接

原因二：同步双方初始序列号

TCP 协议的通信双方，都必须维护一个「序列号」，序列号是可靠传输的一个关键因素，它的作用：

接收方可以去除重复的数据；
接收方可以根据数据包的序列号按序接收；
可以标识发送出去的数据包中，哪些是已经被对方收到的（通过 ACK 报文中的序列号知道）；

四次握手其实也能够可靠的同步双方的初始化序号，但由于第二步和第三步可以优化成一步，所以就成了「三次握手」。

而两次握手只保证了一方的初始序列号能被对方成功接收，没办法保证双方的初始序列号都能被确认接收。

原因三：避免资源浪费

如果只有「两次握手」，当客户端的 SYN 请求连接在网络中阻塞，客户端没有接收到 ACK 报文，就会重新发送 SYN ，由于没有第三次握手，服务器不清楚客户端是否收到了自己发送的建立连接的 ACK 确认信号，所以每收到一个 SYN 就只能先主动建立一个连接，这会造成什么情况呢？

如果客户端的 SYN 阻塞了，重复发送多次 SYN 报文，那么服务器在收到请求后就会建立多个冗余的无效链接，造成不必要的资源浪费。这样就会造成死锁。也有可能打开两个连接或更多。

如果握手只是两次，服务器端在没有确定客户端是否对自己做出了正确应答的情况下就建立了连接，此时客户端因为意外连接请求报文早就失效了，也不可能再理服务器端，但是服务器端会一直傻傻地等待客户端会发来点数据，造成了资源的浪费。这真是服务器端自己自作多情啊。

三次握手如果第三次失败了会怎么样：

失败了服务端收到不确认包，会超时重发5次，若还是没有收到确认包，或者收到了数据包，则服务端直接发送reset重置包结束本次连接。

Q2. 为什么连接是三次握手，而关闭时是四次挥手

为什么连接是三次握手：

为了保证服务端能收接受到客户端的信息并能做出正确的应答而进行前两次(第一次和第二次)握手。

为了保证客户端能够接收到服务端的信息并能做出正确的应答而进行后两次(第二次和第三次)握手。

具体原因见Q1：

关闭时四次挥手：

关闭连接时，服务端需要回复两次。

四次挥手之所以结束时需要多一次请求是因为：客户端单方面无数据发送认为可以结束了，但是服务端不一定没有数据发送。

所以服务端要将确信信息和自身发起断开分作两步。

再来回顾下四次挥手双方发 FIN 包的过程，就能理解为什么需要四次了。

关闭连接时，客户端向服务端发送 FIN 时，仅仅表示客户端不再发送数据了但是还能接收数据。
服务器收到客户端的 FIN 报文时，先回一个 ACK 应答报文，而服务端可能还有数据需要处理和发送，等服务端不再发送数据时，才发送 FIN 报文给客户端来表示同意现在关闭连接。

Q3. 为什么TIME_WAIT状态需要经过2MSL？

2MSL是一次发送和回复的最大时间 (Maximum Segment Lifetime报文最大生存时间)

主要目的是怕最后一个ACK包对方没收到，那么对方在超时后将重发第三次握手的FIN包，主动关闭端接到重发的FIN包后可以再发一个ACK应答包，客户端最后一次发送ACK可能会丢失，如果此时冒然关闭，会导致服务器没收到ACK，然后一直不断地发Fin。

所以需要等2MSL，如果超过这个时间，都还没有收到服务器的信息，说明已经完成，可以关闭。

MSL 是 Maximum Segment Lifetime，报文最大生存时间，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。

因为 TCP 报文基于是 IP 协议的，而 IP 头中有一个 TTL 字段，是 IP 数据报可以经过的最大路由数，每经过一个处理他的路由器此值就减 1，当此值为 0 则数据报将被丢弃，同时发送 ICMP 报文通知源主机。

MSL 与 TTL 的区别： MSL 的单位是时间，而 TTL 是经过路由跳数。所以 MSL 应该要大于等于 TTL 消耗为 0 的时间，以确保报文已被自然消亡。

TTL 的值一般是 64，Linux 将 MSL 设置为 60秒，意味着 Linux 认为数据报文经过 64 个路由器的时间不会超过 30 秒，如果超过了，就认为报文已经消失在网络中了。

Q4. 为什么每次建立 TCP 连接时，初始化的序列号都要求不一样呢？

主要原因有两个方面：

为了防止历史报文被下一个相同四元组的连接接收（主要方面）；
为了安全性，防止黑客伪造的相同序列号的 TCP 报文被对方接收；

Q5. 初始序列号 ISN 是如何随机产生的？

起始 ISN 是基于时钟的，每 4 微秒 + 1，转一圈要 4.55 个小时。

RFC793 提到初始化序列号 ISN 随机生成算法：ISN = M + F(localhost, localport, remotehost, remoteport)。

M 是一个计时器，这个计时器每隔 4 微秒加 1。
F 是一个 Hash 算法，根据源 IP、目的 IP、源端口、目的端口生成一个随机数值。要保证 Hash 算法不能被外部轻易推算得出，用 MD5 算法是一个比较好的选择。

可以看到，随机数是会基于时钟计时器递增的，基本不可能会随机成一样的初始化序列号。

Q6. 既然 IP 层会分片，为什么 TCP 层还需要 MSS 呢？

MTU：一个网络包的最大长度，以太网中一般为 1500 字节；
MSS：除去 IP 和 TCP 头部之后，一个网络包所能容纳的 TCP 数据的最大长度；

如果在 TCP 的整个报文（头部 + 数据）交给 IP 层进行分片，会有什么异常呢？

当 IP 层有一个超过 MTU 大小的数据（TCP 头部 + TCP 数据）要发送，那么 IP 层就要进行分片，把数据分片成若干片，保证每一个分片都小于 MTU。

把一份 IP 数据报进行分片以后，由目标主机的 IP 层来进行重新组装后，再交给上一层 TCP 传输层。

这看起来井然有序，但这存在隐患的，那么当如果一个 IP 分片丢失，整个 IP 报文的所有分片都得重传。

因为 IP 层本身没有超时重传机制，它由传输层的 TCP 来负责超时和重传。

所以，为了达到最佳的传输效能 TCP 协议在建立连接的时候通常要协商双方的 MSS 值，当 TCP 层发现数据超过 MSS 时，则就先会进行分片，当然由它形成的 IP 包的长度也就不会大于 MTU ，自然也就不用 IP 分片了。

Q7. 第一次，第二次，第三次握手丢失了，会发生什么？

第一次握手丢失了，会发生什么？

当客户端想和服务端建立 TCP 连接的时候，首先第一个发的就是 SYN 报文，然后进入到 SYN_SENT 状态。在这之后，如果客户端迟迟收不到服务端的 SYN-ACK 报文（第二次握手），就会触发「超时重传」机制，重传 SYN 报文。

不同版本的操作系统可能超时时间不同，有的 1 秒的，也有 3 秒的，这个超时时间是写死在内核里的，如果想要更改则需要重新编译内核，比较麻烦。当客户端在 1 秒后没收到服务端的 SYN-ACK 报文后，客户端就会重发 SYN 报文，那到底重发几次呢？

在 Linux 里，客户端的 SYN 报文最大重传次数由 tcp_syn_retries内核参数控制，这个参数是可以自定义的，默认值一般是 5。

通常，第一次超时重传是在 1 秒后，第二次超时重传是在 2 秒，第三次超时重传是在 4 秒后，第四次超时重传是在 8 秒后，第五次是在超时重传 16 秒后。没错，每次超时的时间是上一次的 2 倍。

当第五次超时重传后，会继续等待 32 秒，如果服务端仍然没有回应 ACK，客户端就不再发送 SYN 包，然后断开 TCP 连接。

所以，总耗时是 1+2+4+8+16+32=63 秒，大约 1 分钟左右。

第二次握手丢失了，会发生什么？

当第二次握手丢失了，客户端和服务端都会重传：

客户端会重传 SYN 报文，也就是第一次握手，最大重传次数由 tcp_syn_retries内核参数决定；
服务端会重传 SYN-ACK 报文，也就是第二次握手，最大重传次数由 tcp_synack_retries 内核参数决定。

如果第二次握手丢失了，服务端就收不到第三次握手，于是服务端这边会触发超时重传机制，重传 SYN-ACK 报文。

在 Linux 下，SYN-ACK 报文的最大重传次数由 tcp_synack_retries内核参数决定，默认值是 5。

当服务端收到客户端的第一次握手后，就会回 SYN-ACK 报文给客户端，这个就是第二次握手，此时服务端会进入 SYN_RCVD 状态。

第二次握手的 SYN-ACK 报文其实有两个目的：

第二次握手里的 ACK，是对第一次握手的确认报文；
第二次握手里的 SYN，是服务端发起建立 TCP 连接的报文；

所以，如果第二次握手丢了，就会发送比较有意思的事情，具体会怎么样呢？

因为第二次握手报文里是包含对客户端的第一次握手的 ACK 确认报文。

如果客户端迟迟没有收到第二次握手，那么客户端就觉得可能自己的 SYN 报文（第一次握手）丢失了，于是客户端就会触发超时重传机制，重传 SYN 报文。

然后，因为第二次握手中包含服务端的 SYN 报文，所以当客户端收到后，需要给服务端发送 ACK 确认报文（第三次握手），服务端才会认为该 SYN 报文被客户端收到了。

第三次握手丢失了，会发生什么？

当第三次握手丢失了，服务端那一方迟迟收不到这个确认报文，就会触发超时重传机制，重传 SYN-ACK 报文，直到收到第三次握手，或者达到最大重传次数。

客户端收到服务端的 SYN-ACK 报文后，就会给服务端回一个 ACK 报文，也就是第三次握手，此时客户端状态进入到 ESTABLISH 状态。

因为这个第三次握手的 ACK 是对第二次握手的 SYN 的确认报文，所以当第三次握手丢失了，如果服务端那一方迟迟收不到这个确认报文，就会触发超时重传机制，重传 SYN-ACK 报文，直到收到第三次握手，或者达到最大重传次数。

注意，ACK 报文是不会有重传的，当 ACK 丢失了，就由对方重传对应的报文。

Q8. 第一次，第二次，第三次，第四次挥手丢失了，都会发生什么？

第一次挥手丢失了，会发生什么？

如果第一次挥手丢失了，那么客户端迟迟收不到被动方的 ACK 的话，也就会触发超时重传机制，重传 FIN 报文，重发次数由 tcp_orphan_retries 参数控制。当客户端重传 FIN 报文的次数超过 tcp_orphan_retries 后，就不再发送 FIN 报文，直接进入到 close 状态。

当客户端（主动关闭方）调用 close 函数后，就会向服务端发送 FIN 报文，试图与服务端断开连接，此时客户端的连接进入到 FIN_WAIT_1 状态。正常情况下，如果能及时收到服务端（被动关闭方）的 ACK，则会很快变为 FIN_WAIT2状态。

第二次挥手丢失了，会发生什么？

所以如果服务端的第二次挥手丢失了，客户端就会触发超时重传机制，重传 FIN 报文，直到收到服务端的第二次挥手，或者达到最大的重传次数。

当服务端收到客户端的第一次挥手后，就会先回一个 ACK 确认报文，此时服务端的连接进入到 CLOSE_WAIT 状态。在前面我们也提了，ACK 报文是不会重传的。

这里提一下，当客户端收到第二次挥手，也就是收到服务端发送的 ACK 报文后，客户端就会处于 FIN_WAIT2 状态，在这个状态需要等服务端发送第三次挥手，也就是服务端的 FIN 报文。

对于 close 函数关闭的连接，由于无法再发送和接收数据，所以FIN_WAIT2 状态不可以持续太久，而 tcp_fin_timeout 控制了这个状态下连接的持续时长，默认值是 60 秒。

这意味着对于调用 close 关闭的连接，如果在 60 秒后还没有收到 FIN 报文，客户端（主动关闭方）的连接就会直接关闭。

但是注意，如果主动关闭方使用 shutdown 函数关闭连接且指定只关闭发送方向，而接收方向并没有关闭，那么意味着主动关闭方还是可以接收数据的。

如果主动关闭方一直没收到第三次挥手，那么主动关闭方的连接将会一直处于 FIN_WAIT2 状态（tcp_fin_timeout 无法控制 shutdown 关闭的连接）。

第三次挥手丢失了，会发生什么？

如果迟迟收不到这个 ACK，服务端就会重发 FIN 报文，重发次数仍然由 tcp_orphan_retries 参数控制，这与客户端重发 FIN 报文的重传次数控制方式是一样的。

当服务端（被动关闭方）收到客户端（主动关闭方）的 FIN 报文后，内核会自动回复 ACK，同时连接处于 CLOSE_WAIT 状态，顾名思义，它表示等待应用进程调用 close 函数关闭连接。

此时，内核是没有权利替代进程关闭连接，必须由进程主动调用 close 函数来触发服务端发送 FIN 报文。

服务端处于 CLOSE_WAIT 状态时，调用了 close 函数，内核就会发出 FIN 报文，同时连接进入 LAST_ACK 状态，等待客户端返回 ACK 来确认连接关闭。

第四次挥手丢失了，会发生什么？

如果第四次挥手的 ACK 报文没有到达服务端，服务端就会重发 FIN 报文，重发次数仍然由前面介绍过的 tcp_orphan_retries 参数控制。

当客户端收到服务端的第三次挥手的 FIN 报文后，就会回 ACK 报文，也就是第四次挥手，此时客户端连接进入 TIME_WAIT 状态。

在 Linux 系统，TIME_WAIT 状态会持续 2MSL 后才会进入关闭状态。

然后，服务端（被动关闭方）没有收到 ACK 报文前，还是处于 LAST_ACK 状态。

Q9. 为什么需要 TIME_WAIT 状态？

避免连接混淆或者连接冲突，防止历史连接中的数据，被后面相同四元组的连接错误的接收；
保证「被动关闭连接」的一方，能被正确的关闭，确保最后的数据包被接收，或处理延迟包；

TIME_WAIT 过多有什么危害？

过多的 TIME-WAIT 状态主要的危害有两种：

第一是内存资源占用；
第二是对端口资源的占用，一个 TCP 连接至少消耗「发起连接方」的一个本地端口；

2.5 TCP协议如何保证可靠性

TCP 是通过序列号、确认应答、重发控制、连接管理以及窗口控制等机制实现可靠性传输的

（1）采用三次握手四次挥手保证建立的传输信道是可靠的。

（2）采用了ARQ自动(超时)重传请求协议数据传输的可靠性。

（3）采用滑动窗口协议进行流量控制。

（4）使用慢开始、拥塞避免、快重传和快恢复来进行拥塞控制.

（5）校验和CRC计算方式：在数据传输的过程中，将发送的数据段都当做一个16位的整数。将这些整数加起来。并且前面的进位不能丢弃，补在后面，最后取反，得到校验和。

发送方：在发送数据之前计算检验和，并进行校验和的填充。

接收方：收到数据后，对数据以同样的方式进行计算，求出校验和，与发送方的进行比对。

（6）确认应答与序列号

序列号：TCP传输时将每个字节的数据都进行了编号。

确认应答：TCP传输的过程中，每次接收方收到数据后，都会对传输方进行确认应答。也就是发送ACK报文。这个ACK报文当中带有对应的确认序列号，告诉发送方，接收到了哪些数据，下一次的数据从哪里发。

自动超时重传机制

简单理解就是发送方在发送完数据后等待一个时间，时间到达没有接收到ACK报文，那么对刚才发送的数据进行重新发送。

由于TCP传输时保证能够在任何环境下都有一个高性能的通信，因此这个最大超时时间（也就是等待的时间）是动态计算的。

在Linux中（BSD Unix和Windows下也是这样）超时以500ms为一个单位进行控制，每次判定超时重发的超时时间都是500ms的整数倍。重发一次后，仍未响应，那么等待2500ms的时间后，再次重传。等待4500ms的时间继续重传。以一个指数的形式增长。累计到一定的重传次数，TCP就认为网络或者对端出现异常，强制关闭连接。

具体步骤如下：

（1）为了保证数据包的可靠传递，发送方必须把已发送的数据包保留在缓冲区；

（2）并为每个已发送的数据包启动一个超时定时器；

（3）如在定时器超时之前收到了对方发来的应答信息（可能是对本包的应答，也可以是对本包后续包的应答），则释放该数据包占用的缓冲区;

（4）否则，重传该数据包，直到收到应答或重传次数超过规定的最大次数为止。

（5）接收方收到数据包后，先进行CRC校验，如果正确则把数据交给上层协议，然后给发送方发送一个累计应答包，表明该数据已收到，如果接收方正好也有数据要发给发送方，应答包也可方在数据包中捎带过去。

如果接收方收到二次重发的数据后，便进行ACK应答。

如果接收方发现接收的数据已存在（判断存在的根据就是序列号，所以上面说序列号还有去除重复数据的作用），那么直接丢弃，仍旧发送ACK应答。

2.6 TCP协议如何进行流量控制？

控制流量的前提当然需要保证正确率可靠性，因此首先要引入ARQ(自动重传请求（Automatic Repeat-reQuest，ARQ）协议。

TCP采用大小可变的滑动窗口进行流量控制，窗口大小的单位是字节。

数据接收端将自己可以接受的缓冲区大小放入TCP首部中“窗口大小”字段，通过ACK来通知数据传输。（在TCP的首部，有一个16位窗口字段，此字段就是用来存放窗口大小信息的。）

无差错时，A向B发送分组M1，B收到M1后向A回复，A收到回复后，发送下一个M2…..

如果出现差错，B没有收到信息，自然不会回复，A等待超时后，自动重传一个信息M，这就是所谓的ARQ。

但停止等待ARQ协议信道利用率太低。

所以需要使用连续ARQ协议来进行改善。这个协议会连续发送一组数据包，然后再等待这些数据包的ACK。

连续ARQ协议通常是结合滑动窗口协议来使用的，发送方需要维持一个发送窗口，如下图所示：

位于发送窗口内的5个分组都可以连续发送出去，而不需要等待对方的确认，这样就提高了信道利用率。、

发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。

接收方一般都是采用累积确认的方式。收到几个分组后，对按序到达的最后一个分组发送确认。

滑动窗口需掌握的知识点：

A、数据接收端将自己可以接受的缓冲区大小放入TCP首部中“窗口大小”字段，通过ACK来通知数据传输端。

B、窗口大小字段越大，说明网络的吞吐率越高。

C、窗口大小指的是无需等待确认应答而可以继续发送数据的最大值，即就是说不需要数据接收端的应答，可以一次连续的发送数据。

D、操作系统内核为了维护滑动窗口，需要开辟发送缓冲区，来记录当前还有哪些数据没有应答，只有确认应答过的数据，才能从缓冲区删除。 (PS：发送缓冲区如果太大，会有空间开销）

E、数据接收端一旦发现自己的缓冲区快满了，就会将窗口大小设置成一个更小的值通知给数据传输端，数据传输端收到这个值后，就会减慢自己的发送速度。

F、如果数据接收端发现自己的缓冲区满了，就会将窗口大小设置为0，此时数据传输端不再传输数据，但是需要定期发送一个窗口探测数据段，将数据接收端把窗口大小告诉数据传输端。

TCP 规定是不允许同时减少缓存又收缩窗口的，而是采用先收缩窗口，过段时间再减少缓存，这样就可以避免了丢包情况。

Q1. TCP 是如何解决窗口关闭时，潜在的死锁现象呢？

为了解决这个问题，TCP 为每个连接设有一个持续定时器，只要 TCP 连接一方收到对方的零窗口通知，就启动持续计时器。

如果持续计时器超时，就会发送窗口探测 ( Window probe ) 报文，而对方在确认这个探测报文时，给出自己现在的接收窗口大小。

窗口探测的次数一般为 3 次，每次大约 30-60 秒（不同的实现可能会不一样）。

如果 3 次过后接收窗口还是 0 的话，有的 TCP 实现就会发 RST 报文来中断连接。

2.7 TCP协议如何进行拥塞控制？

下载时我们的速度一般都是由慢变快，原因就是拥塞控制。

网络拥塞是指在分组交换网络中传送分组的数目太多时，由于存储转发节点的资源有限而造成网络传输性能下降的情况。

常见的拥塞控制有：慢开始，拥塞避免，快重传，快恢复

慢开始：不要一开始就发送大量的数据，由小到大逐渐增加拥塞窗口的大小, 一次RTT(RTT(Round-Trip Time)：往返时延)后，也就是收到一次ACK后拥塞窗口就翻倍，也就是指数型增长。

**拥塞避免：**拥塞避免算法让拥塞窗口缓慢增长，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1而不是加倍。这样拥塞窗口按线性规律缓慢增长。

发送方维持一个叫做拥塞窗口cwnd（congestion window）的状态变量。

当cwnd到达ssthresh（慢启动阈值）时，改用拥塞避免算法。

拥塞窗口 cwnd是发送方维护的一个的状态变量，它会根据网络的拥塞程度动态变化的。

我们在前面提到过发送窗口 swnd 和接收窗口 rwnd 是约等于的关系，那么由于加入了拥塞窗口的概念后，此时发送窗口的值是swnd = min(cwnd, rwnd)，也就是拥塞窗口和接收窗口中的最小值。

拥塞窗口 cwnd 变化的规则：

只要网络中没有出现拥塞，cwnd 就会增大；
但网络中出现了拥塞，cwnd 就减少；

快重传：我们可以剔除一些不必要的拥塞报文，提高网络吞吐量。比如接收方在收到一个失序的报文段后就立即发出重复确认，而不要等到自己发送数据时捎带确认。

快重传规定：发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。

**快恢复：**主要是配合快重传。当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把ssthresh门限减半（为了预防网络发生拥塞）

但接下来并不执行慢开始算法，因为如果网络出现拥塞的话就不会收到好几个重复的确认，收到三个重复确认说明网络状况还可以。

快速重传机制只解决了一个问题，就是超时时间的问题，但是它依然面临着另外一个问题。

就是重传的时候，是重传之前的一个，还是重传所有的问题。

比如对于上面的例子，是重传 Seq2 呢？还是重传 Seq2、Seq3、Seq4、Seq5 呢？因为发送端并不清楚这连续的三个 Ack 2 是谁传回来的。

根据 TCP 不同的实现，以上两种情况都是有可能的。可见，这是一把双刃剑。

为了解决不知道该重传哪些 TCP 报文，于是就有 SACK 方法。

SACK 方法

一种实现重传机制的方式叫：SACK（ Selective Acknowledgment 选择性确认）。

这种方式需要在 TCP 头部「选项」字段里加一个 SACK 的东西，它可以将缓存的地图发送给发送方，这样发送方就可以知道哪些数据收到了，哪些数据没收到，知道了这些信息，就可以只重传丢失的数据。

如某图例子(发送方收到了三次同样的 ACK 确认报文，于是就会触发快速重发机制，通过 SACK 信息发现只有 200~299 这段数据丢失，则重发时，就只选择了这个 TCP 段进行重复。

2.8 Socket编程TCP

服务端和客户端初始化 socket，得到文件描述符；
服务端调用 bind()，将文件描述符绑定在 IP 地址和端口;
服务端调用 listen，进行监听；
服务端调用 accept，等待客户端连接；
客户端调用 connect，向服务器端的地址和端口发起连接请求；
服务端 accept 返回用于传输的 socket 的文件描述符；
客户端调用 write 写入数据；服务端调用 read 读取数据；
客户端断开连接时，会调用 close，那么服务端 read 读取数据的时候，就会读取到了 EOF，待处理完数据后，服务端调用 close，表示连接关闭。

Linux内核中会维护两个队列：

半连接队列（SYN 队列）：接收到一个 SYN 建立连接请求，处于 SYN_RCVD 状态；
全连接队列（Accpet 队列）：已完成 TCP 三次握手过程，处于 ESTABLISHED 状态；

从上面的描述过程，我们可以得知客户端 connect 成功返回是在第二次握手，服务端 accept 成功返回是在三次握手成功之后。

客户端调用 close 了，连接是断开的流程是什么？

我们看看客户端主动调用了 close，会发生什么？

客户端调用 close 过程
- 客户端调用 close，表明客户端没有数据需要发送了，则此时会向服务端发送 FIN 报文，进入 FIN_WAIT_1 状态；
- 服务端接收到了 FIN 报文，TCP 协议栈会为 FIN 包插入一个文件结束符 EOF 到接收缓冲区中，应用程序可以通过 read 调用来感知这个 FIN 包。
  - 这个 EOF 会被放在已排队等候的其他已接收的数据之后，这就意味着服务端需要处理这种异常情况，因为 EOF 表示在该连接上再无额外数据到达。此时，服务端进入 CLOSE_WAIT 状态；
- 接着，当处理完数据后，自然就会读到 EOF，于是也调用 close 关闭它的套接字，这会使得服务端发出一个 FIN 包，之后处于 LAST_ACK 状态；
- 客户端接收到服务端的 FIN 包，并发送 ACK 确认包给服务端，此时客户端将进入 TIME_WAIT 状态；
- 服务端收到 ACK 确认包后，就进入了最后的 CLOSE 状态；
- 客户端经过 2MSL 时间之后，也进入 CLOSE 状态。

2.9 增大 TCP 半连接队列和全连接队列的方式

增大 TCP 半连接队列的方式是增大 /proc/sys/net/ipv4/tcp_max_syn_backlog；
增大 TCP 全连接队列的方式是增大 listen() 函数中的 backlog；

Linux系统中，则使用两个队列syn queue, accept queue分别存储状态为SYN_REVD和ESTABLISHED的连接，并且在linux2.2及以后，backlog表示accept queue的大小，而syn queue大小由 /proc/sys/net/ipv4/tcp_max_syn_backlog配置。

内核参数somaxconn
全称：socket max connections 位置：/proc/sys/net/core/somaxconn 这是系统层面对于backlog的控制，实际上accept queue的大小 = min(somaxconn, backlog)。

因此在listen这个系统调用层面，backlog最终还是受限于somaxconn。

查看队列
`ss -l

Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port tcp LISTEN 0 128 [::]:ssh [::]:*`

在LISTEN状态下 Recv-Q 表示当前accept queue中的已连接数。Send-Q 表示总大小

2.10 如何优化 TCP

你可以根据网络的稳定性和目标服务器的繁忙程度修改 **SYN 的重传次数**，**调整客户端的三次握手时间上限**。TCP 三次握手的性能提升；TCP 四次挥手的性能提升；TCP 数据传输的性能提升；

Q1: 三次握手优化

客户端的优化

当客户端发起 SYN 包时，可以通过 tcp_syn_retries 控制其重传的次数。

服务端的优化

当服务端 SYN 半连接队列溢出后，会导致后续连接被丢弃，可以通过 netstat -s 观察半连接队列溢出的情况。

如果 SYN 半连接队列溢出情况比较严重，可以通过 tcp_max_syn_backlog、somaxconn、backlog 参数来调整 SYN 半连接队列的大小。

服务端回复 SYN+ACK 的重传次数由 tcp_synack_retries 参数控制。

如果遭受 SYN 攻击，应把 tcp_syncookies 参数设置为 1，表示仅在 SYN 队列满后开启 syncookie 功能，可以保证正常的连接成功建立。

服务端收到客户端返回的 ACK，会把连接移入 accpet 队列，等待进行调用 accpet() 函数取出连接。

可以通过 ss -lnt 查看服务端进程的 accept 队列长度

如果 accept 队列溢出，系统默认丢弃 ACK，如果可以把 tcp_abort_on_overflow 设置为 1 ，表示用 RST 通知客户端连接建立失败。

如果 accpet 队列溢出严重，可以通过 listen 函数的 backlog 参数和 somaxconn 系统参数提高队列大小，accept 队列长度取决于 min(backlog, somaxconn)。

绕过三次握手

TCP Fast Open 功能可以绕过三次握手，使得 HTTP 请求减少了 1 个 RTT 的时间，Linux 下可以通过 tcp_fastopen 开启该功能，同时必须保证服务端和客户端同时支持。

Q2: TCP 四次挥手的性能提升

针对 TCP 四次挥手的优化，我们需要根据主动方和被动方四次挥手状态变化来调整系统 TCP 内核参数。

四次挥手的优化策略

主动方的优化

主动发起 FIN 报文断开连接的一方，如果迟迟没收到对方的 ACK 回复，则会重传 FIN 报文，重传的次数由 tcp_orphan_retries 参数决定。
当主动方收到 ACK 报文后，连接就进入 FIN_WAIT2 状态，根据关闭的方式不同，优化的方式也不同：

如果这是 close 函数关闭的连接，那么它就是孤儿连接。如果 tcp_fin_timeout 秒内没有收到对方的 FIN 报文，连接就直接关闭。同时，为了应对孤儿连接占用太多的资源，tcp_max_orphans 定义了最大孤儿连接的数量，超过时连接就会直接释放。
反之是 shutdown 函数关闭的连接，则不受此参数限制；

当主动方接收到 FIN 报文，并返回 ACK 后，主动方的连接进入 TIME_WAIT 状态。这一状态会持续 1 分钟，为了防止 TIME_WAIT 状态占用太多的资源，tcp_max_tw_buckets 定义了最大数量，超过时连接也会直接释放。
当 TIME_WAIT 状态过多时，还可以通过设置 tcp_tw_reuse 和 tcp_timestamps 为 1 ，将 TIME_WAIT 状态的端口复用于作为客户端的新连接，注意该参数只适用于客户端。

被动方的优化

被动关闭的连接方应对非常简单，它在回复 ACK 后就进入了 CLOSE_WAIT 状态，等待进程调用 close 函数关闭连接。因此，出现大量 CLOSE_WAIT 状态的连接时，应当从应用程序中找问题。

当被动方发送 FIN 报文后，连接就进入 LAST_ACK 状态，在未等到 ACK 时，会在 tcp_orphan_retries 参数的控制下重发 FIN 报文。

Q3: TCP 数据传输的性能提升

2.11 如何解决粘包？

（1）发送方引起的粘包是由TCP协议本身造成的，TCP为提高传输效率，发送方往往要收集到足够多的数据后才发送一包数据。

若连续几次发送的数据都很少，通常TCP会根据优化算法把这些数据合成一包后一次发送出去，这样接收方就收到了粘包数据。

UDP不存在粘包问题, 是由于UDP发送的时候, 没有经过Negal算法优化, 不会将多个小包合并一次发送出去。

另外，在UDP协议的接收端,采用了链式结构来记录每一个到达的UDP包，这样接收端应用程序一次recv只能从socket接收缓冲区中读出一个数据包。

也就是说,发送端send了几次，接收端必须recv几次(无论recv时指定了多大的缓冲区)

（2）接收方引起的粘包是由于接收方用户进程不及时接收数据，从而导致粘包现象。

这是因为接收方先把收到的数据放在系统接收缓冲区，用户进程从该缓冲区取数据，若下一包数据到达时前一包数据尚未被用户进程取走，则下一包数据放到系统接收缓冲区时就接到前一包数据之后，而用户进程根据预先设定的缓冲区大小从系统接收缓冲区取数据，这样就一次取到了多包数据。

粘包的问题出现是因为不知道一个用户消息的边界在哪，如果知道了边界在哪，接收方就可以通过边界来划分出有效的用户消息。

一般有三种方式分包的方式：

固定长度的消息；
特殊字符作为边界；
自定义消息结构。

固定长度的消息固定长度的消息

这种是最简单方法，即每个用户消息都是固定长度的，比如规定一个消息的长度是 64 个字节，当接收方接满 64 个字节，就认为这个内容是一个完整且有效的消息。

但是这种方式灵活性不高，实际中很少用。
特殊字符作为边界

我们可以在两个用户消息之间插入一个特殊的字符串，这样接收方在接收数据时，读到了这个特殊字符，就把认为已经读完一个完整的消息。

HTTP 是一个非常好的例子。

HTTP 通过设置回车符、换行符作为 HTTP 报文协议的边界。

有一点要注意，这个作为边界点的特殊字符，如果刚好消息内容里有这个特殊字符，我们要对这个字符转义，避免被接收方当作消息的边界点而解析到无效的数据。

自定义消息结构

我们可以自定义一个消息结构，由包头和数据组成，其中包头包是固定大小的，而且包头里有一个字段来说明紧随其后的数据有多大。

比如这个消息结构体，首先 4 个字节大小的变量来表示数据长度，真正的数据则在后面。
1 2 3 4

struct { u_int32_t message_length; char message_data[]; } message;
当接收方接收到包头的大小（比如 4 个字节）后，就解析包头的内容，于是就可以知道数据的长度，然后接下来就继续读取数据，直到读满数据的长度，就可以组装成一个完整到用户消息来处理了。

2.12 SYN 报文什么时候情况下会被丢弃？

开启 tcp_tw_recycle 参数，并且在 NAT 环境下，造成 SYN 报文被丢弃，由于 NAT 环境中的客户端可能有不同的时间戳时钟和值，tcp_tw_recycle 在这种环境中可能会导致合法的 SYN 报文被误丢弃。因此，如果你的服务器有 NAT 后面的客户端连接，通常建议不要启用 tcp_tw_recycle。
TCP 两个队列满了（半连接队列和全连接队列），造成 SYN 报文被丢弃

4.8 SYN 报文什么时候情况下会被丢弃？ | 小林coding (xiaolincoding.com)

在 Linux 操作系统下，TIME_WAIT 状态的持续时间是 60 秒，这意味着这 60 秒内，客户端一直会占用着这个端口。要知道，端口资源也是有限的，一般可以开启的端口为 32768~61000 ，也可以通过如下参数设置指定范围：

不过，Linux 操作系统提供了两个可以系统参数来快速回收处于 TIME_WAIT 状态的连接，这两个参数都是默认关闭的：

net.ipv4.tcp_tw_reuse，如果开启该选项的话，客户端（连接发起方）在调用 connect() 函数时，内核会随机找一个 time_wait 状态超过 1 秒的连接给新的连接复用，所以该选项只适用于连接发起方。
net.ipv4.tcp_tw_recycle，如果开启该选项的话，允许处于 TIME_WAIT 状态的连接被快速回收；

要使得这两个选项生效，有一个前提条件，就是要打开 TCP 时间戳，即net.ipv4.tcp_timestamps=1（默认即为 1）。

但是，tcp_tw_recycle 在使用了 NAT 的网络下是不安全的！

3. DNS协议和ARP协议

这两个协议都是用于地址间的转化，起到了“翻译官”的职责。

3.1 DNS解析过程是什么？

DNS (Domain Name System) 是 域名系统 的英文缩写，是一种组织成域层次结构的计算机和网络服务命名系统。

它用于 TCP/IP 网络，它从事将主机名或域名转换为实际 IP 地址的工作，类似于翻译官。

DNS查询时优先考虑本地的Host文件和本地的DNS解析器是否保留有缓存映射，如果没有就向上一级请求。

依次按照DNS根服务器，DNS顶层服务器，DNS管理方服务器的顺序请求。

所谓递归查询就是变更查询者，迭代查询则没有变更。

3.2 什么是MAC地址？

MAC地址是数据链路层和物理层使用的地址（硬件地址），IP地址网络层和以上各层使用的地址，是一种逻辑地址。

在发送数据时，数据从高层到低层，然后才到通信链路上传输。使用IP地址的IP数据报一旦交给了数据链路层，就被封装成了MAC帧。

MAC帧在传送时使用的源地址和目的地址都是硬件地址。

有了IP，为啥还需要MAC地址？

事实上，IP协议的产生并不只是为解决上述的“广播问题”。

还解决了很多其他网络传输过程会遇到的问题，比如一次传输的消息过大时，如何对消息进行分组等问题。

由于历史原因，MAC 地址及相关技术先出现，但是后来发现它并不能解决所有（已知）的问题，所以，先驱们发明了 IP 地址及相关技术来解决。
另一个角度，个人认为，由于 MAC 地址没有办法表达网络中的子网的概念，而 IP 地址可以。

如果网络互换设备（比如路由器）能从目标 MAC 地址中分析出目标网络，而不是只是目标主机，IP 地址还会出现吗？

有另一个有趣的问题：**如果历史反过来，**一开始就使用的是 IP 地址，而不是 MAC 地址，我们现在的网络世界会怎么样？

3.3 ARP协议工作机制是什么？

ARP（Address Resolution Protocol）即地址解析协议，用于实现从 IP 地址到 MAC 地址的映射，即询问目标IP对应的MAC地址。

在每台安装有TCP/IP协议的电脑或路由器里都有一个ARP缓存表，表里的IP地址与MAC地址是一对应的，如下表所示。

解析MAC地址时，主机A首先在其ARP高速缓存中查找有无主机B的IP地址。

如果没有就就向本地网段发起一个ARP请求的广播包，查询此目的主机对应的MAC地址。

网络中所有的主机收到这个ARP请求后，会检查数据包中的目的IP是否和自己的IP地址一致。

如果相同，该主机首先将发送端的MAC地址和IP地址添加到自己的ARP列表中，如果ARP表中已经存在该IP的信息，则将其覆盖，然后给源主机发送一个ARP响应数据包，告诉对方自己是它需要查找的MAC地址。

源主机收到后在其ARP高速缓存中写入主机B的IP地址到硬件地址的映射。

并且采用LRU机制，及时淘汰。

查看 ARP 缓存内容

在 Linux 系统中，我们可以使用 arp -a 命令来查看 ARP 缓存的内容。

4. HTTP协议

4.1 HTTP常见的请求方法和状态码

OPTIONS

返回服务器针对特定资源所支持的HTTP请求方法，也可以利用向web服务器发送‘*’的请求来测试服务器的功能性。
HEAD

向服务器索与GET请求相一致的响应，只不过响应体将不会被返回。

这一方法可以再不必传输整个响应内容的情况下，就可以获取包含在响应小消息头中的元信息。
GET

向特定的资源发出请求。注意：GET方法不应当被用于产生“副作用”的操作中，例如在Web Application中，其中一个原因是GET可能会被网络蜘蛛等随意访问。Loadrunner中对应get请求函数：web_link和web_url
POST

向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。

数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。 Loadrunner中对应POST请求函数：web_submit_data,web_submit_form
PUT

向指定资源位置上传其最新内容
DELETE

请求服务器删除Request-URL所标识的资源
TRACE

回显服务器收到的请求，主要用于测试或诊断
CONNECT

HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。

注意：

1）方法名称是区分大小写的，当某个请求所针对的资源不支持对应的请求方法的时候，服务器应当返回状态码405（Mothod Not Allowed）；

当服务器不认识或者不支持对应的请求方法时，应返回状态码501（Not Implemented）。

2）HTTP服务器至少应该实现GET和HEAD/POST方法，其他方法都是可选的，此外除上述方法，特定的HTTP服务器支持扩展自定义的方法。

100 客户端必须继续发出请求 101 客户端要求服务器根据请求转换HTTP协议版本

200 交易成功 201 提示知道新文件的URL 202 接受和处理、但处理未完成

203 返回信息不确定或不完整 204 请求收到，但返回信息为空

205 服务器完成了请求，用户代理必须复位当前已经浏览过的文件 206 服务器已经完成了部分用户的GET请求

300 请求的资源可在多处得到 301 永久重定向，在Location响应首部的值仍为当前URL(隐式重定向) 302 临时重定向，在Location响应首部的值仍为新的URL(显示重定向)

303 建议客户端访问其他URL或访问方式 304 Not Modified 请求的资源没有改变可以继续使用缓存 305 请求的资源必须从服务器指定的地址得到

306 前一版本HTTP中使用的代码，现行版本中不再使用 307 声明请求的资源临时性删除

400 错误请求，如语法错误 401 未授权402 保留有效ChargeTo头响应 403 禁止访问

404 没有发现文件、查询或URL 405 用户在Request-Line字段定义的方法不允许

406 根据用户发送的Accept拖，请求资源不可访问 407 类似401，用户必须首先在代理服务器上得到授权

500 - 内部服务器错误 HTTP 500.100 - 内部服务器错误 HTTP 500-11 服务器关闭 HTTP

500-12 应用程序重新启动 HTTP 500-13 - 服务器太忙 HTTP 500-14 - 应用程序无效 HTTP 500-15 - 不允许请求

501 - 未实现 502 - 网关错误 503 - 服务不可用 504 - 网关超时。

4.2 HTTP协议和其他协议之间的关系

HTTP(超文本传输协议)是利用TCP在两台电脑(通常是Web服务器和客户端)之间传输信息的协议。

如果把TCP比作是高速路，HTTP就是卡车。

Socket是对TCP/IP协议的封装，Socket本身并不是协议，而是一个调用接口（API Application Programming Interface,应用程序编程接口）。

通过Socket，我们能方便地使用TCP/IP协议。

4.3 HTTP长连接和短连接

短连接：客户端和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。

长连接：客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。有一个保持时间，

通过Keep-Alive头字段, 服务器配置Nginx, 应用程序代码设置

4.4 HTTP和HTTPS（安全性，端口，证书，URL，明密)

HTTP 是超文本传输协议，信息是明文传输，存在安全风险的问题。HTTPS 则解决 HTTP 不安全的缺陷，在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议，使得报文能够加密传输。
HTTP 连接建立相对简单无状态的， TCP 三次握手之后便可进行 HTTP 的报文传输。

而 HTTPS 在 TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。
HTTP 的端口号是 80，HTTPS 的端口号是 443。
HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的，一般免费证书较少，因而需要一定费用。

HTTP：运行在TCP之上，明文传输，客户端与服务器端都无法验证对方的身份。

HTTPS：Https是身披SSL(Secure Socket Layer)外壳的Http，运行于SSL上，SSL运行于TCP之上，是添加了加密和认证机制的HTTP。

「HTTPS 是先进行 TCP 三次握手，再进行 TLS v1.2四次握手」

ps: 这句话一点问题都没有，怀疑这句话是错的人，才有问题。

「HTTPS 中的 TLS 握手过程可以同时进行三次握手」

这个场景是可能存在到，但是在没有说任何前提条件，而说这句话就等于耍流氓。需要下面这两个条件同时满足才可以：

客户端和服务端都开启了 TCP Fast Open 功能，且 TLS 版本是 1.3；
客户端和服务端已经完成过一次通信；

4.4.1 HTTPS 是如何建立连接的？其间交互了什么？

HTTPS 在HTTP的基础上加入了SSL/TLS协议，SSL/TLS依靠证书来验证服务器的身份，并为浏览器和服务器之间的通信加密。

SSL/TLS 协议基本流程：

客户端向服务器索要并验证服务器的公钥。
双方协商生产「会话秘钥」。
双方采用「会话秘钥」进行加密通信。

HTTPS的缺点，虽然说HTTPS有很大的优势，但其相对来说，还是存在不足之处的：

（耗电，效率，证钱，IP，范围)

（1）HTTPS协议握手阶段比较费时，会使页面的加载时间延长近50%，增加10%到20%的耗电；

（2）HTTPS连接缓存不如HTTP高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响；

（3）SSL证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用。

（4）SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗。

（5）HTTPS协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。

最关键的，SSL证书的信用链体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人攻击一样可行。

4.5 GET和POST的区别

GET和POST本质上就是TCP链接，并无差别。但是由于HTTP的规定和浏览器/服务器的限制，导致他们在应用过程中体现出一些不同。

GET在浏览器回退或者刷新时时无害的，而POST会再次提交请求，因为GET请求是安全幂等的，而POST不是
GET参数通过URL传递，POST放在Request body中
GET请求在URL中传送的参数是有长度限制的；而POST没有，因为大多数浏览器通常都会限制url长度在2K个字节，而大多数服务器最多处理64K大小的url
GET请求只能进行url编码，而POST支持多种编码方式，form， json， xml
对参数的数据类型，GET只接受ASCII字符，而POST没有限制
GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息
GET请求参数会被完整保留在浏览器历史记录里，可被收藏为书签，而POST中的参数不会被保留
GET请求会被浏览器主动cache，而POST不会，除非手动设置
GET产生一个TCP数据包；POST产生两个TCP数据包。

对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；

而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。

get方式的安全性较Post方式要差些，包含机密信息的话，建议用Post数据提交方式；
在做数据查询时，建议用Get方式；而在做数据添加、修改或删除时，建议用Post方式；

安全的是指没有明显的对用户有影响的副作用(包括修改该资源的状态)仅指该方法的多次调用不会产生副作用，不涉及传统意义上的“安全”，这里的副作用是指资源状态。

即，安全的方法不会修改资源状态，尽管多次调用的返回值可能不一样(被其他非安全方法修改过)。HTTP方法里的GET和HEAD都是安全的。
幂等指的是一个方法不论多少次操作，结果都是一样。

**PUT(把内容放到指定URL)，**DELETE(删除某个URL代表的资源)，虽然都修改了资源内容，但多次操作，结果是相同的，因此和HEAD，GET一样都是幂等的。

4.6 Cookie和Session的区别

Cookie和Session都是客户端与服务器之间保持状态的解决方案

具体来说，cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案。

Cookie实际上是一小段文本信息。客户端请求服务器，如果服务器需要记录该用户状态，就向客户端浏览器颁发一个Cookie。

客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同该Cookie一同提交给服务器，服务器检查该Cookie，以此来辨认用户状态。

Cookie对象使用key-value属性对的形式保存用户状态，一个Cookie对象保存一个属性对。

一个request或者response同时使用多个Cookie。

因为Cookie类位于包javax.servlet.http.*下面，所以JSP中不需要import该类。每个属性对应一个getter方法与一个setter方法。

Cookie并不提供修改、删除操作。

如果要修改某个Cookie，只需要新建一个同名的Cookie，添加到response中覆盖原来的Cookie。

Session的区别在于，会话状态完全保存在服务器。客户端请求服务器，如果服务器记录该用户状态，就获取Session来保存状态，这时，如果服务器已经为此客户端创建过session就按照sessionid把这个session检索出来使用。

服务器Session常常依赖于Cookie机制检索ID。

但Cookie被禁用时也有其他方法比如URL重写机制，使用上比Cookie简单一些，相应的也增加了服务器的存储压力。

Session对应的类为javax.servlet.http.HttpSession类。每个来访者对应一个Session对象，所有该客户的状态信息都保存在这个Session对象里。

Session对象是在客户端第一次请求服务器的时候创建的。

Session也是一种key-value的属性对，通过getAttribute(Stringkey)和setAttribute(String key，Objectvalue)方法读写客户状态信息。Servlet里通过request.getSession()方法获取该客户的Session，

为了获得更高的存取速度，服务器一般把Session放在内存里。每个用户都会有一个独立的Session。如果Session内容过于复杂，当大量客户访问服务器时可能会导致内存溢出。因此，Session里的信息应该尽量精简。

由于会有越来越多的用户访问服务器，因此Session也会越来越多。

为防止内存溢出，服务器会把长时间内没有活跃的Session从内存删除。这个时间就是Session的超时时间。如果超过了超时时间没访问过服务器，Session就自动失效了。

它的正常运行仍然需要客户端浏览器的支持。这是因为Session需要使用Cookie作为识别标志。

HTTP协议是无状态的，Session不能依据HTTP连接来判断是否为同一客户，因此服务器向客户端浏览器发送一个名为JSESSIONID的Cookie，它的值为该Session的id（也就是HttpSession.getId()的返回值）。Session依据该Cookie来识别是否为同一用户。

该Cookie为服务器自动生成的，它的maxAge属性一般为–1，表示仅当前浏览器内有效，并且各浏览器窗口间不共享，关闭浏览器就会失效。

因此同一机器的两个浏览器窗口访问服务器时，会生成两个不同的Session。

但是由浏览器窗口内的链接、脚本等打开的新窗口（也就是说不是双击桌面浏览器图标等打开的窗口）除外。这类子窗口会共享父窗口的Cookie，因此会共享一个Session。

URL地址重写是对客户端不支持Cookie的解决方案。URL地址重写的原理是将该用户Session的id信息重写到URL地址中。

服务器能够解析重写后的URL获取Session的id。这样即使客户端不支持Cookie，也可以使用Session来记录用户状态。

4.7 HTTP请求报文和响应报文的格式

请求报文格式：

请求行（请求方法+URI协议+版本）
请求头部
空行
请求主体

GET/sample.jsp HTTP/1.1 请求行
Accept:image/gif.image/jpeg, 请求头部
Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)
Accept-Encoding:gzip,deflate

username=jinqiao&password=1234 请求主体

响应报文：

状态行（版本+状态码+原因短语）
响应首部
空行
响应主体

HTTP/1.1 200 OK
Server:Apache Tomcat/5.0.12
Date:Mon,6Oct2003 13:23:42 GMT
Content-Length:112

<html>
    <head>
        <title>HTTP响应示例<title>
    </head>
    <body>
        Hello HTTP!
    </body>
</html>

4.8 HTTP/1.1、HTTP/2、HTTP/3 演变

HTTP/1.1 相比 HTTP/1.0 性能上的改进：

(长连接，管道网络)
- 使用 TCP 长连接的方式改善了 HTTP/1.0 短连接造成的性能开销。
- 支持管道（pipeline）网络传输，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。
但 HTTP/1.1 还是有性能瓶颈：

(头部未压缩，相同首部浪费，依然有响应的队头阻塞，无请求优先级，服务器只能被动响应)
- 请求 / 响应头部（Header）未经压缩就发送，首部信息越多延迟越大。只能压缩 Body 的部分；
- 发送冗长的首部。每次互相发送相同的首部造成的浪费较多；
- 服务器是按请求的顺序响应的，如果服务器响应慢，会导致客户端一直请求不到数据，也就是响应的队头阻塞；
- 没有请求优先级控制；
- 请求只能从客户端开始，服务器只能被动响应。
HTTP/1.1 管道解决了请求的队头阻塞，但是没有解决响应的队头阻塞。
HTTP/2 相比 HTTP/1.1 性能上的改进：

HTTP/2 协议是基于 HTTPS 的，所以 HTTP/2 的安全性也是有保障的。

(双向数据流（同一连接并行请求响应)，资源处理优先级，服务器推送，压缩头部二进制）
- 可以使用同一个连接并行发送多个请求和相应，可以承接双向数据流
- 允许设定数据流中不同资源的优先级，明确资源处理的先后顺序
- 打破了请求-响应的束缚，除了最初的请求响应外，服务器还能向客户端推送额外的资源（客户端没有明确要求的情况下）
- 压缩头部，头信息和数据体都是二进制格式

1. 头部压缩

HTTP/2 会压缩头（Header）如果你同时发出多个请求，他们的头是一样的或是相似的，那么，协议会帮你消除重复的部分。

这就是所谓的 HPACK 算法：在客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就提高速度了。

2. 二进制格式

HTTP/2 不再像 HTTP/1.1 里的纯文本形式的报文，而是全面采用了二进制格式，头信息和数据体都是二进制，并且统称为帧（frame）：头信息帧（Headers Frame）和数据帧（Data Frame）。

这样虽然对人不友好，但是对计算机非常友好，因为计算机只懂二进制，那么收到报文后，无需再将明文的报文转成二进制，而是直接解析二进制报文，这增加了数据传输的效率。

HTTP/1.1 中的管道（ pipeline）虽然解决了请求的队头阻塞，但是没有解决响应的队头阻塞，因为服务端需要按顺序响应收到的请求，如果服务端处理某个请求消耗的时间比较长，那么只能等相应完这个请求后，才能处理下一个请求，这属于 HTTP 层队头阻塞。
HTTP/2 虽然通过多个请求复用一个 TCP 连接解决了 HTTP 的队头阻塞 ，但是一旦发生丢包，就会阻塞住所有的 HTTP 请求，这属于 TCP 层队头阻塞。

HTT/1 ~ HTTP/2

HTTP/2 队头阻塞的问题是因为 TCP，所以 HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP！

HTTP/1 ~ HTTP/3

UDP 发生是不管顺序，也不管丢包的，所以不会出现像 HTTP/2 队头阻塞的问题。

大家都知道 UDP 是不可靠传输的，但基于 UDP 的 QUIC 协议 可以实现类似 TCP 的可靠性传输。

4.9 如何减少 HTTP 请求次数？

减少 HTTP 请求次数自然也就提升了 HTTP 性能，可以从这 3 个方面入手：

（减少重定向请求次数，合并请求，延迟发送请求）

减少重定向请求次数；服务器上的一个资源可能由于迁移、维护等原因从 url1 移至 url2 后，而客户端不知情，它还是继续请求 url1，这时服务器不能粗暴地返回错误，而是通过 302 响应码和 Location 头部，告诉客户端该资源已经迁移至 url2 了，于是客户端需要再发送 url2 请求以获得服务器的资源。
合并请求；如果把多个访问小文件的请求合并成一个大的请求，虽然传输的总资源还是一样，但是减少请求，也就意味着减少了重复发送的 HTTP 头部。
延迟发送请求；请求网页的时候，没必要把全部资源都获取到，而是只获取当前用户所看到的页面资源，当用户向下滑动页面的时候，再向服务器获取接下来的资源，这样就达到了延迟发送请求的效果。

4.10 如何减少 HTTP 响应的数据大小？

（有损无损压缩，质量因子）

我们可以考虑对响应的资源进行压缩，这样就可以减少响应的数据大小，从而提高网络传输的效率。

压缩的方式一般分为 2 种，分别是：无损压缩；有损压缩；

无损压缩

无损压缩是指资源经过压缩后，信息不被破坏，还能完全恢复到压缩前的原样，适合用在文本文件、程序可执行文件、程序源代码。

gzip 就是比较常见的无损压缩。（客户端支持的压缩算法，会在 HTTP 请求中通过头部中的 Accept-Encoding 字段告诉服务器）

有损压缩

与无损压缩相对的就是有损压缩，经过此方法压缩，解压的数据会与原始数据不同但是非常接近。

有损压缩主要将次要的数据舍弃，牺牲一些质量来减少数据量、提高压缩比，这种方法经常用于压缩多媒体数据，比如音频、视频、图片。

可以通过 HTTP 请求头部中的 Accept 字段里的「 q 质量因子」，告诉服务器期望的资源质量。

关于图片的压缩，目前压缩比较高的是 Google 推出的 WebP 格式

4.11 Http如何优化

对于硬件优化的方向，因为 HTTPS 是属于计算密集型，应该选择计算力更强的 CPU，而且最好选择支持 AES-NI 特性的 CPU，这个特性可以在硬件级别优化 AES 对称加密算法，加快应用数据的加解密。

对于软件优化的方向，如果可以，把软件升级成较新的版本，比如将 Linux 内核 2.X 升级成 4.X，将 openssl 1.0.1 升级到 1.1.1，因为新版本的软件不仅会提供新的特性，而且还会修复老版本的问题。

对于协议优化的方向：

密钥交换算法应该选择 ECDHE 算法，而不用 RSA 算法，因为 ECDHE 算法具备前向安全性，而且客户端可以在第三次握手之后，就发送加密应用数据，节省了 1 RTT。
将 TSL1.2 升级 TSL1.3，因为 TSL1.3 的握手过程只需要 1 RTT，而且安全性更强。

对于证书优化的方向：

服务器应该选用 ECDSA 证书，而非 RSA 证书，因为在相同安全级别下，ECC 的密钥长度比 RSA 短很多，这样可以提高证书传输的效率；
服务器应该开启 OCSP Stapling 功能，由服务器预先获得 OCSP 的响应，并把响应结果缓存起来，这样 TLS 握手的时候就不用再访问 CA 服务器，减少了网络通信的开销，提高了证书验证的效率；

对于重连 HTTPS 时，我们可以使用一些技术让客户端和服务端使用上一次 HTTPS 连接使用的会话密钥，直接恢复会话，而不用再重新走完整的 TLS 握手过程。

常见的会话重用技术有 Session ID 和 Session Ticket，用了会话重用技术，当再次重连 HTTPS 时，只需要 1 RTT 就可以恢复会话。

对于 TLS1.3 使用 Pre-shared Key 会话重用技术，只需要 0 RTT 就可以恢复会话。这些会话重用技术虽然好用，但是存在一定的安全风险，它们不仅不具备前向安全，而且有重放攻击的风险，所以应当对会话密钥设定一个合理的过期时间。

4.12 HSTS协议

HSTS（HTTP Strict Transport Security）是一种安全协议，旨在增强网站的安全性，特别是针对HTTPS连接。HSTS通过强制客户端（如浏览器）只能通过加密连接（HTTPS）与服务器通信来防止中间人攻击和SSL剥离攻击。

HSTS的工作原理是在服务器的响应头中包含一个特殊的HTTP头部字段（Strict-Transport-Security），该字段告知浏览器在未来一段时间内（例如一年）只能通过HTTPS连接访问该网站。一旦浏览器接收到这个头部字段，它将会记住并在接下来的请求中自动使用HTTPS连接。

使用HSTS可以有效减少网站受到中间人攻击和SSL剥离攻击的风险，提高网站的安全性。

5. IP地址

5.1 IP地址的格式是什么？

什么是IP地址？IP协议提供的一种统一的地址格式，它为互联网上的每一个网络和每一台主机分配一个逻辑地址，以此来屏蔽物理地址的差异。

IP地址编址方案将IP地址空间划分为A、B、C、D、E五类，其中A、B、C是基本类，D、E类作为多播和保留使用，为特殊地址。

每个IP地址包括两个标识码（ID）：网络ID和主机ID。

同一个物理网络上的所有主机都使用同一个网络ID，网络上的一个主机（包括网络上工作站，服务器和路由器等）有一个主机ID与其对应。3字节的网络地址 + 1字节主机地址的意思就是：前三段号码为网络号码，剩下的一段号码为本地计算机的号码。

A类地址：1字节的网络地址 + 3字节主机地址，网络地址的最高位必须是0。A类IP地址的地址范围1.0.0.0到127.255.255.255，IP地址的子网掩码为255.0.0.0，每个网络支持的最大主机数为256^3-2
B类地址：2字节的网络地址 + 2字节主机地址，网络地址的最高位必须是10。B类IP地址地址范围**128.0.0.0-191.255.255.255，**B类IP地址的子网掩码为255.255.0.0，每个网络支持的最大主机数为256^2-2。注：1000 0000=128
C类地址：3字节的网络地址 + 1字节主机地址，网络地址的最高位必须是110。C类IP地址范围**192.0.0.0-223.255.255.255。**每个网络支持的最大主机数为256-2。适用于小规模局域网络。
D类地址：多播地址，用于1对多通信，最高位必须是1110。范围从224.0.0.0到239.255.255.255。
E类地址:：为保留地址，最高位必须是“11110”

IPv4 首部与 IPv6 首部

IPv4 首部与 IPv6 首部的差异如下图：

IPv6 相比 IPv4 的首部改进：

(取消了首部校验和字段, 取消了中间路由分片/重新组装相关字段，取消选项字段）

取消了首部校验和字段。 因为在数据链路层和传输层都会校验，因此 IPv6 直接取消了 IP 的校验。
取消了分片/重新组装相关字段。 分片与重组是耗时的过程，IPv6 不允许在中间路由器进行分片与重组，这种操作只能在源与目标主机，这将大大提高了路由器转发的速度。
取消选项字段。 选项字段不再是标准 IP 首部的一部分了，但它并没有消失，而是可能出现在 IPv6 首部中的「下一个首部」指出的位置上。删除该选项字段使的 IPv6 的首部成为固定长度的 40 字节。

5.2 单播广播多播的区别是什么？

单播：主机间一对一通信。优点：个性化服务，及时响应；缺点：流量压力大。

广播：主机间一对所有通信。优点：布局简单，维护方便，流量负载低。缺点：缺乏个性化服务，无法在Internet宽带上传播。

多播（组播）：主机间一对一组通信。优点：兼具流量负载和个性化的优点，允许在Internet宽带上传播。缺点：与单播协议相比没有纠错机制。

5.3 如何划分子网？

划分子网的方法是从主机号借用若干个位作为子网号，而主机号也就相应减少了若干个位。

于是两级IP地址在本单位内部就变为三级IP地址：网络号、子网号和主机号。

区分子网号和主机号的办法是：通过子网掩码将网络号和子网号全设为1的IP地址为子网掩码。

假设公司有4个部门，A部门有10台主机，B部门有15台主机，C部门有30台主机，D部门有20台主机。分配了一个总的网段为：192.168.2.0/24。请问该如何划分子网？

网段前面的数字是我们的网络地址，后面的24表示用24位来表示网络位，用32-24=8位来表示主机位。

主机数目不多，可以小型组网，因此采用C类地址(最大254个主机)，默认掩码为225.255.255.0。

首先假设借用主机位2位来划分4个子网，则子网掩码组合为：

11111111.11111111.11111111.00 000000
11111111.11111111.11111111.01 000000
11111111.11111111.11111111.10 000000
11111111.11111111.11111111.11 000000

然而全为0和全为1的地址不能用，所以我们需要借用主机位3位，划分8-2=6个子网：

11111111.11111111.11111111.00100000
11111111.11111111.11111111.01000000
11111111.11111111.11111111.01100000
11111111.11111111.11111111.10000000
11111111.11111111.11111111.10100000
11111111.11111111.11111111.11000000

验证一下：最后提供的主机位数是2^5=32，也就是说每个子网最大的主机数是32-2=30，符合题目要求。所以子网划分如下：

（1）255.255.255.32:    192.168.2.33~ 192.168.2.62
（2）255.255.255.64:   192.168.2.65~ 192.168.2.94
（3）255.255.255.96:   192.168.2.97~ 192.168.2.126
（4）255.255.255.128:  192.168.2.129~ 192.168.2.158
（5）255.255.255.160:  192.168.2.161~ 192.168.2.190
（6）255.255.255.192:  192.168.2.193~ 192.168.2.222

子网掩码是：

1
2

11111111.11111111.11111111.111 00000
255.255.255.224

6. 网络安全

6.1 什么是DDos攻击？

DDos全称Distributed Denial of Service，分布式拒绝服务攻击。最基本的DOS攻击过程如下：

客户端向服务端发送请求链接数据包
服务端向客户端发送确认数据包
客户端不向服务端发送确认数据包，服务器一直等待来自客户端的确认

DDoS则是采用分布式的方法，通过在网络上占领多台“肉鸡”，用多台计算机发起攻击。

DOS攻击现在基本没啥作用了，因为服务器的性能都很好，而且是多台服务器共同作用，1V1的模式黑客无法占上风。对于DDOS攻击，预防方法有：

减少SYN timeout时间。在握手的第三步，服务器会等待30秒-120秒的时间，减少这个等待时间就能释放更多的资源。
限制同时打开的SYN半连接数目。

6.2 什么是XSS攻击？

XSS也称 cross-site scripting，跨站脚本。攻击者在web页面中会插入一些恶意的script代码。当用户浏览该页面的时候，那么嵌入到web页面中script代码会执行，因此会达到恶意攻击用户的目的。

那么XSS攻击最主要有如下分类：反射型、存储型、及 DOM-based型。

反射性和DOM-baseed型可以归类为非持久性XSS攻击，存储型可以归类为持久性XSS攻击。

比如一个存在XSS漏洞的论坛，用户发帖时就可以引入带有＜script＞标签的代码，导致恶意代码的执行。

预防措施有：

前端：过滤
后端：转义，比如go自带的处理器就具有转义功能。

反射性xss一般指攻击者通过特定的方式来诱惑受害者去访问一个包含恶意代码的URL。当受害者点击恶意链接url的时候，恶意代码会直接在受害者的主机上的浏览器执行。

存储型XSS的原理是：主要是将恶意代码上传或存储到服务器中，下次只要受害者浏览包含此恶意代码的页面就会执行恶意代码。

6.3 什么是注入SQL攻击？

XSS是将脚本代码注入，而SQL注入攻击顾名思义就是注入SQL语句。

SQL注入是通过客户端的输入把SQL命令注入到一个应用的数据库中，从而执行恶意的SQL语句。

如果通过参数进行拼接，拼接后的sql语句就是： select * from user where username = ’’ and password = ’ ’ or ‘123’ = ‘123’;

这样的了，那么会有一个or语句，只要这两个有一个是正确的话，就条件成立，因此 123 = 123 是成立的。因此验证就会被跳过。

这只是一个简单的列子，比如还有密码比如是这样的：’; drop table user;, 这样的话，那么sql命令就变成了：

select * from user where username = ’’ and password = ’‘; drop table user;’ , 那么这个时候我们会把user表直接删除了。

比如代码：

1
2
3

username:=r.Form.Get("username")
password:=r.Form.Get("password")
sql:="SELECT * FROM user WHERE username='"+username+"' AND password='"+password+"'"

当用户输入myuser' or 'foo' = 'foo' --，那么SQL就变成了：

`1`	`SELECT * FROM user WHERE username='myuser' or 'foo'=='foo' --'' AND password='xxx'`

在SQL里面--是注释标记，所以查询语句会在此中断。

这就让攻击者在不知道任何合法用户名和密码的情况下成功登录了。

预防方法：

限制数据库权限，给用户提供仅仅能够满足其工作的最低权限。
对进入数据库的特殊字符（’”&*;等）转义处理。
提供参数化查询接口，不要直接使用原生SQL。

永远不要信任用户的输入。对用户的输入进行校验，可以通过正则表达式，或限制长度；对单引号和双“-”进行转换等。
永远不要使用动态拼装sql，可以使用参数化的sql或者直接使用存储过程进行数据查询存取。
永远不要使用管理员权限的数据库连接，为每个应用使用单独的权限有限的数据库连接。
不要把机密信息直接存放，加密或者hash掉密码和敏感的信息。
应用的异常信息应该给出尽可能少的提示，最好使用自定义的错误信息对原始错误信息进行包装
sql注入的检测方法一般采取辅助软件或网站平台来检测，软件一般采用sql注入检测工具jsky，网站平台就有亿思网站安全平台检测工具。MDCSOFT SCAN等。采用MDCSOFT-IPS可以有效的防御SQL注入，XSS攻击等。