目录
4.IO多路复用，select、poll、epoll 的区别？
用户态（User Mode）和内核态（Kernel Mode）是操作系统中的两种特权级别，它们有以下几个区别：
访问权限：在用户态下，应用程序只能访问受限的资源和执行受限的操作，例如用户空间的内存、文件和设备。而在内核态下，操作系统具有完全的访问权限，可以访问系统的所有资源和执行所有操作。
CPU指令集：在用户态下，CPU只能执行非特权指令，例如算术运算、逻辑运算等。而在内核态下，CPU可以执行特权指令，例如访问设备、修改系统状态等。
中断和异常处理：在用户态下，当发生中断或异常时，操作系统会进行中断处理，将控制权转移到内核态下的中断处理程序中。而在内核态下，操作系统可以直接处理中断和异常，并进行相应的处理操作。
内存保护：在用户态下，应用程序只能访问自己的内存空间，无法访问其他应用程序的内存空间和操作系统的内存空间。而在内核态下，操作系统可以访问所有的内存空间，包括应用程序的内存空间。
安全性：由于用户态的应用程序受到限制，操作系统可以对其进行隔离和保护，防止恶意代码对系统造成损害。而内核态下的操作系统具有更高的权限，需要对其进行严格的安全管理，以防止非法访问和恶意操作。
01 先来先服务调度算法
最简单的一个调度算法，就是非抢占式的先来先服务（*First Come First Serve, FCFS*）算法。
顾名思义，先来后到，每次从就绪队列选择最先进入队列的进程，然后一直运行，直到进程退出或被阻塞，才会继续从队列中选择第一个进程接着运行。
这似乎很公平，但是当一个长作业先运行了，那么后面的短作业等待的时间就会很长，不利于短作业。FCFS 对长作业有利，适用于 CPU 繁忙型作业的系统，而不适用于 I/O 繁忙型作业的系统
02 最短作业优先调度算法
最短作业优先（*Shortest Job First, SJF*）调度算法同样也是顾名思义，它会优先选择运行时间最短的进程来运行，这有助于提高系统的吞吐量。
这显然对长作业不利，很容易造成一种极端现象。
比如，一个长作业在就绪队列等待运行，而这个就绪队列有非常多的短作业，那么就会使得长作业不断的往后推，周转时间变长，致使长作业长期不会被运行。
03 高响应比优先调度算法
前面的「先来先服务调度算法」和「最短作业优先调度算法」都没有很好的权衡短作业和长作业。
那么，高响应比优先 （*Highest Response Ratio Next, HRRN*）调度算法主要是权衡了短作业和长作业。
每次进行进程调度时，先计算「响应比优先级」，然后把「响应比优先级」最高的进程投入运行，「响应比优先级」的计算公式
如果两个进程的「等待时间」相同时，「要求的服务时间」越短，「响应比」就越高，这样短作业的进程容易被选中运行；
如果两个进程「要求的服务时间」相同时，「等待时间」越长，「响应比」就越高，这就兼顾到了长作业进程，因为进程的响应比可以随时间等待的增加而提高，当其等待时间足够长时，其响应比便可以升到很高，从而获得运行的机会；
最古老、最简单、最公平且使用最广的算法就是时间片轮转（*Round Robin, RR*）调度算法。
每个进程被分配一个时间段，称为时间片（*Quantum*），即允许该进程在该时间段中运行。
如果时间片用完，进程还在运行，那么将会把此进程从 CPU 释放出来，并把 CPU 分配给另外一个进程；
如果该进程在时间片结束前阻塞或结束，则 CPU 立即进行切换；
另外，时间片的长度就是一个很关键的点：
如果时间片设得太短会导致过多的进程上下文切换，降低了 CPU 效率；
如果设得太长又可能引起对短作业进程的响应时间变长。将
一般来说，时间片设为 20ms~50ms 通常是一个比较合理的折中值。
05 最高优先级调度算法
前面的「时间片轮转算法」做了个假设，即让所有的进程同等重要，也不偏袒谁，大家的运行时间都一样。
但是，对于多用户计算机系统就有不同的看法了，它们希望调度是有优先级的，即希望调度程序能从就绪队列中选择最高优先级的进程进行运行，这称为最高优先级（*Highest Priority First，HPF*）调度算法。
进程的优先级可以分为，静态优先级和动态优先级：
静态优先级：创建进程时候，就已经确定了优先级了，然后整个运行时间优先级都不会变化；
动态优先级：根据进程的动态变化调整优先级，比如如果进程运行时间增加，则降低其优先级，如果进程等待时间（就绪队列的等待时间）增加，则升高其优先级，也就是随着时间的推移增加等待进程的优先级。
该算法也有两种处理优先级高的方法，非抢占式和抢占式：
非抢占式：当就绪队列中出现优先级高的进程，运行完当前进程，再选择优先级高的进程。
抢占式：当就绪队列中出现优先级高的进程，当前进程挂起，调度优先级高的进程运行。
但是依然有缺点，可能会导致低优先级的进程永远不会运行
06 多级反馈队列调度算法
多级反馈队列（*Multilevel Feedback Queue*）调度算法是「时间片轮转算法」和「最高优先级算法」的综合和发展。
多级」表示有多个队列，每个队列优先级从高到低，同时优先级越高时间片越短。
「反馈」表示如果有新的进程加入优先级高的队列时，立刻停止当前正在运行的进程，转而去运行优先级高的队列。
来看看，它是如何工作的：
设置了多个队列，赋予每个队列不同的优先级，每个队列优先级从高到低，同时优先级越高时间片越短；
新的进程会被放入到第一级队列的末尾，按先来先服务的原则排队等待被调度，如果在第一级队列规定的时间片没运行完成，则将其转入到第二级队列的末尾，以此类推，直至完成；
当较高优先级的队列为空，才调度较低优先级的队列中的进程运行。如果进程运行时，有新进程进入较高优先级的队列，则停止当前运行的进程并将其移入到原队列末尾，接着让较高优先级的进程运行；
可以发现，对于短作业可能可以在第一级队列很快被处理完。对于长作业，如果在第一级队列处理不完，可以移入下次队列等待被执行，虽然等待的时间变长了，
但是运行时间也变更长了，所以该算法很好的兼顾了长短作业，同时有较好的响应时间
由于每个进程的用户空间都是独立的，不能相互访问，这时就需要借助内核空间来实现进程间通信，原因很简单，每个进程都是共享一个内核空间。
Linux 内核提供了不少进程间通信的方式，其中最简单的方式就是管道，管道分为「匿名管道」和「命名管道」。、匿名管道顾名思义，它没有名字标识，匿名管道是特殊文件只存在于内存，没有存在于文件系统中，
shell 命令中的「|」竖线就是匿名管道，通信的数据是无格式的流并且大小受限，通信的方式是单向的，数据只能在一个方向上流动，如果要双向通信，需要创建两个管道，再来匿名管道是只能用于存在父子关系的进程间通信，匿名管道的生命周期随着进程创建而建立，随着进程终止而消失。
命名管道突破了匿名管道只能在亲缘关系进程间的通信限制，因为使用命名管道的前提，需要在文件系统创建一个类型为 p 的设备文件，
那么毫无关系的进程就可以通过这个设备文件进行通信。另外，不管是匿名管道还是命名管道，进程写入的数据都是缓存在内核中，另一个进程读取数据时候自然也是从内核中获取，
同时通信数据都遵循先进先出原则，不支持 lseek 之类的文件定位操作。
消息队列克服了管道通信的数据是无格式的字节流的问题，消息队列实际上是保存在内核的「消息链表」，消息队列的消息体是可以用户自定义的数据类型，发送数据时，
会被分成一个一个独立的消息体，当然接收数据时，也要与发送方发送的消息体的数据类型保持一致，这样才能保证读取的数据是正确的。消息队列通信的速度不是最及时的，
毕竟每次数据的写入和读取都需要经过用户态与内核态之间的拷贝过程。
共享内存可以解决消息队列通信中用户态与内核态之间数据拷贝过程带来的开销，它直接分配一个共享空间，每个进程都可以直接访问，就像访问进程自己的空间一样快捷方便，
不需要陷入内核态或者系统调用，大大提高了通信的速度，享有最快的进程间通信方式之名。但是便捷高效的共享内存通信，带来新的问题，多进程竞争同个共享资源会造成数据的错乱
那么，就需要信号量来保护共享资源，以确保任何时刻只能有一个进程访问共享资源，这种方式就是互斥访问。信号量不仅可以实现访问的互斥性，还可以实现进程间的同步，
信号量其实是一个计数器，表示的是资源个数，其值可以通过两个原子操作来控制，分别是 P 操作和 V 操作。
与信号量名字很相似的叫信号，它俩名字虽然相似，但功能一点儿都不一样。信号是异步通信机制，信号可以在应用进程和内核之间直接交互，
内核也可以利用信号来通知用户空间的进程发生了哪些系统事件，信号事件的来源主要有硬件来源（如键盘 Cltr+C ）和软件来源（如 kill 命令），一旦有信号发生，进程有三种方式响应信号 1. 执行默认操作、2. 捕捉信号、3. 忽略信号。有两个信号是应用进程无法捕捉和忽略的，即 SIGKILL 和 SIGSTOP，这是为了方便我们能在任何时候结束或停止某个进程。
前面说到的通信机制，都是工作于同一台主机，如果要与不同主机的进程间通信，那么就需要 Socket 通信了。Socket 实际上不仅用于不同的主机进程间通信，
还可以用于本地主机进程间通信，可根据创建 Socket 的类型不同，分为三种常见的通信方式，一个是基于 TCP 协议的通信方式，一个是基于 UDP 协议的通信方式，一个是本地进程间通信方式。
select 实现多路复用的方式是，将已连接的 Socket 都放到一个文件描述符集合，然后调用 select 函数将文件描述符集合拷贝到内核里，让内核来检查是否有网络事件产生，检查的方式很粗暴，就是通过遍历文件描述符集合的方式，当检查到有事件产生后，
将此 Socket 标记为可读或可写， 接着再把整个文件描述符集合拷贝回用户态里，然后用户态还需要再通过遍历的方法找到可读或可写的 Socket，然后再对其处理。
所以，对于 select 这种方式，需要进行 2 次「遍历」文件描述符集合，一次是在内核态里，一个次是在用户态里 ，而且还会发生 2 次「拷贝」文件描述符集合，先从用户空间传入内核空间，由内核修改后，再传出到用户空间中。
select 使用固定长度的 BitsMap，表示文件描述符集合，而且所支持的文件描述符的个数是有限制的，在 Linux 系统中，由内核中的 FD_SETSIZE 限制， 默认最大值为 1024，只能监听 0~1023 的文件描述符。
poll 不再用 BitsMap 来存储所关注的文件描述符，取而代之用动态数组，以链表形式来组织，突破了 select 的文件描述符个数限制，当然还会受到系统文件描述符限制。
但是 poll 和 select 并没有太大的本质区别，都是使用「线性结构」存储进程关注的 Socket 集合，因此都需要遍历文件描述符集合来找到可读或可写的 Socket，时间复杂度为 O(n)，而且也需要在用户态与内核态之间拷贝文件描述符集合，这种方式随着并发数上来，性能的损耗会呈指数级增长。
epoll 通过两个方面，很好解决了 select/poll 的问题。
第一点，epoll 在内核里使用红黑树来跟踪进程所有待检测的文件描述字，把需要监控的 socket 通过 epoll_ctl() 函数加入内核中的红黑树里，红黑树是个高效的数据结构，增删改一般时间复杂度是 O(logn)。
而 select/poll 内核里没有类似 epoll 红黑树这种保存所有待检测的 socket 的数据结构，所以 select/poll 每次操作时都传入整个 socket 集合给内核，而 epoll 因为在内核维护了红黑树，
可以保存所有待检测的 socket ，所以只需要传入一个待检测的 socket，减少了内核和用户空间大量的数据拷贝和内存分配。
第二点， epoll 使用事件驱动的机制，内核里维护了一个链表来记录就绪事件，当某个 socket 有事件发生时，通过回调函数内核会将其加入到这个就绪事件列表中，当用户调用 epoll_wait() 函数时，只会返回有事件发生的文件描述符的个数，不需要像 select/poll 那样轮询扫描整个 socket 集合，大大提高了检测的效率。
epoll 的方式即使监听的 Socket 数量越多的时候，效率不会大幅度降低，能够同时监听的 Socket 的数目也非常的多了，上限就为系统定义的进程打开的最大文件描述符个数。因而，epoll 被称为解决 C10K 问题的利器。
如果没有虚拟内存，程序直接操作物理内存的话
在这种情况下，要想在内存中同时运行两个程序是不可能的。如果第一个程序在 2000 的位置写入一个新的值，将会擦掉第二个程序存放在相同位置上的所有内容，所以同时运行两个程序是根本行不通的，这两个程序会立刻崩溃。
这里关键的问题是这两个程序都引用了绝对物理地址，而这正是我们最需要避免的。
我们可以把进程所使用的地址「隔离」开来，即让操作系统为每个进程分配独立的一套「虚拟地址」，人人都有，大家自己玩自己的地址就行，互不干涉。但是有个前提每个进程都不能访问物理地址，至于虚拟地址最终怎么落到物理内存里，
对进程来说是透明的，操作系统已经把这些都安排的明明白白了。
操作系统会提供一种机制，将不同进程的虚拟地址和不同内存的物理地址映射起来。如果程序要访问虚拟地址的时候，由操作系统转换成不同的物理地址，这样不同的进程运行的时候，写入的是不同的物理地址，这样就不会冲突了。
资源分配：进程是操作系统中的一个执行实体，拥有独立的地址空间、文件描述符、打开的文件等资源。每个进程都被分配了独立的系统资源。而线程是进程中的一个执行单元，
多个线程共享同一个进程的地址空间和其他资源，包括文件描述符、打开的文件等。
调度和切换：进程的调度是由操作系统内核进行的，切换进程需要进行上下文切换，涉及用户态和内核态之间的切换，开销相对较大。而线程的调度是在用户程序中完成，切换线程可以在用户态下快速切换，减少了系统调用的开销。
并发性：进程是独立的执行实体，不同进程之间通过进程间通信（IPC）来进行数据交换和共享。进程间通信的方式包括管道、信号量、共享内存等。而线程是在同一个进程中执行的，
多个线程之间共享同一进程的资源，可以通过共享内存的方式进行数据交换和共享
通过这张图你可以看到，用户空间内存，从低到高分别是 6 种不同的内存段：
代码段，包括二进制可执行代码；
数据段，包括已初始化的静态常量和全局变量；
BSS 段，包括未初始化的静态变量和全局变量；
堆段，包括动态分配的内存，从低地址开始向上增长；
文件映射段，包括动态库、共享内存等；
栈段，包括局部变量和函数调用的上下文等。栈的大小是固定的，一般是 8 MB。当然系统也提供了参数，以便我们自定义大小；
上图中的内存布局可以看到，代码段下面还有一段内存空间的（灰色部分），这一块区域是「保留区」，之所以要有保留区这是因为在大多数的系统里，
我们认为比较小数值的地址不是一个合法地址，例如，我们通常在 C 的代码里会将无效的指针赋值为 NULL。因此，这里会出现一段不可访问的内存保留区，
防止程序因为出现 bug，导致读或写了一些小内存地址的数据，而使得程序跑飞。
在这 7 个内存段中，堆和文件映射段的内存是动态分配的。比如说，使用 C 标准库的 malloc() 或者 mmap() ，就可以分别在堆和文件映射段动态分配内存。
寄存器上下文：线程切换时需要保存和恢复线程所使用的寄存器的值，以便切换后能够继续执行。常见的寄存器包括通用寄存器（如EAX、EBX、ECX等）、指令指针寄存器（如EIP）、堆栈指针寄存器（如ESP）等。
栈：线程的栈用于保存局部变量、函数调用信息等。在线程切换时，需要保存和恢复当前线程的栈指针，以及相应的栈帧信息。
线程上下文信息：线程切换时，需要保存和恢复与线程相关的其他上下文信息，如线程状态、调度优先级等。
调度方式：线程的调度是由操作系统内核进行的，而协程的调度是由程序员或者特定的协程调度器进行的。线程的调度是由操作系统内核控制，
切换线程需要进行系统调用，涉及用户态和内核态之间的切换，相对较为耗时。而协程的调度是在用户程序中完成，切换协程可以在用户态下快速切换，减少了系统调用的开销。
并发性：线程是操作系统提供的轻量级进程，多个线程之间可以并发执行，但在多核处理器上，线程的并发性是通过操作系统的线程调度实现的。
而协程是在单个线程中执行的，多个协程之间通过协程调度器进行切换，实现了更细粒度的并发性。
内存消耗：线程的创建和销毁需要操作系统进行一系列的资源分配和回收，包括线程的栈空间和线程控制块等。而协程在单个线程中执行，
不需要额外的系统资源分配，只需要协程调度器保存和恢复协程的上下文。
同步方式：线程之间的通信和同步需要使用锁、条件变量等机制来进行，这些机制需要进行加锁和解锁的操作，容易引发死锁和竞态条件等问题。
而协程可以使用更轻量级的方式进行通信和同步，如使用通道（Channel）来实现协程之间的消息传递。
TCP 是面向连接的协议，所以使用 TCP 前必须先建立连接，而建立连接是通过三次握手来进行的。三次握手的过程如下图：
一旦完成三次握手，双方都处于 ESTABLISHED 状态，此时连接就已建立完成，客户端和服务端就可以相互发送数据了。
客户端收到服务端报文后，还要向服务端回应最后一个应答报文，首先该应答报文 TCP 首部 ACK 标志位置为 1 ，其次「确认应答号」字段填入 server_isn + 1 ，最后把报文发送给服务端，这次报文可以携带客户到服务端的数据，之后客户端处于 ESTABLISHED 状态。
服务端收到客户端的应答报文后，也进入 ESTABLISHED 状态。
服务端收到客户端的 SYN 报文后，首先服务端也随机初始化自己的序号（server_isn），将此序号填入 TCP 首部的「序号」字段中，其次把 TCP 首部的「确认应答号」字段填入 client_isn + 1, 接着把 SYN 和 ACK 标志位置为 1。最后把该报文发给客户端，该报文也不包含应用层数据，之后服务端处于 SYN-RCVD 状态。
客户端会随机初始化序号（client_isn），将此序号置于 TCP 首部的「序号」字段中，同时把 SYN 标志位置为 1，表示 SYN 报文。接着把第一个 SYN 报文发送给服务端，表示向服务端发起连接，该报文不包含应用层数据，之后客户端处于 SYN-SENT 状态。
一开始，客户端和服务端都处于 CLOSE 状态。先是服务端主动监听某个端口，处于 LISTEN 状态。
TCP（Transmission Control Protocol）拥塞控制是一种用于管理和控制数据在网络中传输的机制，以避免网络拥塞，确保数据传输的可靠性和性能。下面是TCP拥塞控制的具体过程：
初始设置：
在TCP连接建立时，拥塞窗口（Congestion Window）被初始化为一个较小的值，通常为1个MSS（最大段大小，即一个TCP数据包的最大长度）。
慢启动（Slow Start）：
在连接建立后的初始阶段，TCP发送方采用慢启动算法。
发送方每收到一个接受发过来确认（ACK）时，将拥塞窗口的大小加倍，这导致发送方逐渐增加发送速率。
这个阶段的目标是逐渐探测网络的可用带宽，并确保不引发拥塞。
拥塞避免（Congestion Avoidance）：
一旦拥塞窗口大小达到一个阈值（通常是慢启动门限，Slow Start Threshold，SSThresh）时，TCP进入拥塞避免阶段。
在拥塞避免阶段，拥塞窗口的大小不再以指数方式增加，而是以线性方式增加。
发送方每收到一个确认时，拥塞窗口增加一个MSS的大小。
拥塞检测（Congestion Detection）：
TCP发送方使用一些标志来检测网络拥塞的迹象，例如丢失的数据包或超时事件。
当发现可能存在拥塞时，TCP发送方会减小拥塞窗口的大小，以减缓数据传输速率。
快速重传和快速恢复：
如果发送方检测到数据包丢失，它可以通过触发快速重传（Fast Retransmit）来更快地重新发送丢失的数据包。
同时，发送方可以进入快速恢复（Fast Recovery）状态，逐渐增加拥塞窗口的大小，而不必回到慢启动阶段。
丢包处理：
当发生数据包丢失时，TCP发送方会减小拥塞窗口的大小，并使用快速重传来尽早重新发送丢失的数据包。
数据包丢失通常表明网络中存在拥塞，所以减小拥塞窗口是必要的。
周期性拥塞检测：
定期检测网络拥塞是TCP的一部分，以适应网络条件的变化。
TCP发送方会定期将拥塞窗口的大小增加，以测试网络的可用带宽，并适应网络性能的变化。
总的来说，TCP拥塞控制通过动态调整拥塞窗口的大小来适应网络条件的变化，以确保数据传输的可靠性和性能。这一过程包括慢启动、拥塞避免、拥塞检测、快速重传、快速恢复等步骤，以应对不同网络情况下的拥塞问题
。拥塞控制是TCP协议的关键特性之一，有助于维护互联网上数据传输的稳定性和可靠性。
拥塞控制主要是四个算法：
慢启动
拥塞避免
拥塞发生
快速恢复
一、慢启动
慢启动的算法记住一个规则就行：当发送方每收到一个 ACK，拥塞窗口 cwnd 的大小就会加 1。
这里假定拥塞窗口 cwnd 和发送窗口 swnd 相等，下面举个栗子：
连接建立完成后，一开始初始化 cwnd = 1，表示可以传一个 MSS 大小的数据。
当收到一个 ACK 确认应答后，cwnd 增加 1，于是一次能够发送 2 个
当收到 2 个的 ACK 确认应答后， cwnd 增加 2，于是就可以比之前多发2 个，所以这一次能够发送 4 个
当这 4 个的 ACK 确认到来的时候，每个确认 cwnd 增加 1， 4 个确认 cwnd 增加 4，于是就可以比之前多发 4 个，所以这一次能够发送 8 个。
可以看出慢启动算法，发包的个数是指数性的增长。
那慢启动涨到什么时候是个头呢？
有一个叫慢启动门限 ssthresh （slow start threshold）状态变量。
当 cwnd < ssthresh 时，使用慢启动算法。
当 cwnd >= ssthresh 时，就会使用「拥塞避免算法」。
二、拥塞避免算法
前面说道，当拥塞窗口 cwnd 「超过」慢启动门限 ssthresh 就会进入拥塞避免算法。
一般来说 ssthresh 的大小是 65535 字节。那么进入拥塞避免算法后，它的规则是：**每当收到一个 ACK 时，cwnd 增加 1/cwnd。*接上前面的慢启动的栗子，现假定 ssthresh 为 8：
当 8 个 ACK 应答确认到来时，每个确认增加 1/8，8 个 ACK 确认 cwnd 一共增加 1，于是这一次能够发送 9 个 MSS 大小的数据，变成了线性增长。
三、拥塞发生
当网络出现拥塞，也就是会发生数据包重传，重传机制主要有两种：
超时重传
快速重传
这两种使用的拥塞发送算法是不同的，接下来分别来说说。
3.1 当发生了「超时重传」，则就会使用拥塞发生算法。
这个时候，ssthresh 和 cwnd 的值会发生变化：
ssthresh 设为 cwnd/2，
cwnd 重置为 1 （是恢复为 cwnd 初始化值，我这里假定 cwnd 初始化值 1）
四、快速恢复
快速重传和快速恢复算法一般同时使用，快速恢复算法是认为，你还能收到 3 个重复 ACK 说明网络也不那么糟糕，所以没有必要像 RTO 超时那么强烈。
正如前面所说，进入快速恢复之前，cwnd 和 ssthresh 已被更新了：
cwnd = cwnd/2 ，也就是设置为原来的一半;
ssthresh = cwnd;
然后，进入快速恢复算法如下：
拥塞窗口 cwnd = ssthresh + 3 （ 3 的意思是确认有 3 个数据包被收到了）；
重传丢失的数据包；
如果再收到重复的 ACK，那么 cwnd 增加 1；
如果收到新数据的 ACK 后，把 cwnd 设置为第一步中的 ssthresh 的值，原因是该 ACK 确认了新的数据，说明从 duplicated ACK 时的数据都已收到，该恢复过程已经结束，可以回到恢复之前的状态了，也即再次进入拥塞避免状态。
HTTP 是超文本传输协议，信息是明文传输，存在安全风险的问题。HTTPS 则解决 HTTP 不安全的缺陷，在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议，使得报文能够加密传输。
HTTP 连接建立相对简单， TCP 三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。
两者的默认端口不一样，HTTP 默认端口号是 80，HTTPS 默认端口号是 443。
HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。
SSL/TLS 协议基本流程：
客户端向服务器索要并验证服务器的公钥。
双方协商生产「会话秘钥」。
双方采用「会话秘钥」进行加密通信。
前两步也就是 SSL/TLS 的建立过程，也就是 TLS 握手阶段。
基于 RSA 算法的 TLS 握手过程比较容易理解，所以这里先用这个给大家展示 TLS 握手过程，如下图：
TLS 协议建立的详细流程：
1. ClientHello
首先，由客户端向服务器发起加密通信请求，也就是 ClientHello 请求。
在这一步，客户端主要向服务器发送以下信息：
（1）客户端支持的 TLS 协议版本，如 TLS 1.2 版本。
（2）客户端生产的随机数（Client Random），后面用于生成「会话秘钥」条件之一。
（3）客户端支持的密码套件列表，如 RSA 加密算法。
2. SeverHello
服务器收到客户端请求后，向客户端发出响应，也就是 SeverHello。服务器回应的内容有如下内容：
（1）确认 TLS 协议版本，如果浏览器不支持，则关闭加密通信。
（2）服务器生产的随机数（Server Random），也是后面用于生产「会话秘钥」条件之一。
（3）确认的密码套件列表，如 RSA 加密算法。
（4）服务器的数字证书。
3.客户端回应
客户端收到服务器的回应之后，首先通过浏览器或者操作系统中的 CA 公钥，确认服务器的数字证书的真实性。
如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它加密报文，向服务器发送如下信息：
（1）一个随机数（pre-master key）。该随机数会被服务器公钥加密。
（2）加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。
（3）客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供服务端校验。
上面第一项的随机数是整个握手阶段的第三个随机数，会发给服务端，所以这个随机数客户端和服务端都是一样的。
服务器和客户端有了这三个随机数（Client Random、Server Random、pre-master key），接着就用双方协商的加密算法，各自生成本次通信的「会话秘钥」。
4. 服务器的最后回应
服务器收到客户端的第三个随机数（pre-master key）之后，通过协商的加密算法，计算出本次通信的「会话秘钥」。
然后，向客户端发送最后的信息：
（1）加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。
（2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供客户端校验。
至此，整个 TLS 的握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的 HTTP 协议，只不过用「会话秘钥」加密内容。
Redis 提供了丰富的数据类型，常见的有五种数据类型：String（字符串），Hash（哈希），List（列表），Set（集合）、Zset（有序集合）
随着 Redis 版本的更新，后面又支持了四种数据类型：BitMap（2.2 版新增）、HyperLogLog（2.8 版新增）、GEO（3.2 版新增）、Stream（5.0 版新增）。Redis 五种数据类型的应用场景：
String 类型的应用场景：缓存对象、常规计数、分布式锁、共享 session 信息等。
List 类型的应用场景：消息队列（但是有两个问题：1. 生产者需要自行实现全局唯一 ID；2. 不能以消费组形式消费数据）等。
Hash 类型：缓存对象、购物车等。
Set 类型：聚合计算（并集、交集、差集）场景，比如点赞、共同关注、抽奖活动等。
Zset 类型：排序场景，比如排行榜、电话和姓名排序等。
Zset 类型的底层数据结构是由压缩列表或跳表实现的：
如果有序集合的元素个数小于 128 个，并且每个元素的值小于 64 字节时，Redis 会使用压缩列表作为 Zset 类型的底层数据结构；
如果有序集合的元素不满足上面的条件，Redis 会使用跳表作为 Zset 类型的底层数据结构；
在 Redis 7.0 中，压缩列表数据结构已经废弃了，交由 listpack 数据结构来实现了。
B+ 树就是对 B 树做了一个升级，MySQL 中索引的数据结构就是采用了 B+ 树，B+ 树结构如下图：
叶子节点（最底部的节点）才会存放实际数据（索引+记录），非叶子节点只会存放索引；
所有索引都会在叶子节点出现，叶子节点之间构成一个有序链表；
非叶子节点的索引也会同时存在在子节点中，并且是在子节点中所有索引的最大（或最小）。
非叶子节点中有多少个子节点，就有多少个索引；
MySQL 默认的存储引擎 InnoDB 采用的是 B+ 作为索引的数据结构，原因有：
B+ 树的非叶子节点不存放实际的记录数据，仅存放索引，因此数据量相同的情况下，相比存储即存索引又存记录的 B 树，B+树的非叶子节点可以存放更多的索引，因此 B+ 树可以比 B 树更「矮胖」，查询底层节点的磁盘 I/O次数会更少。
B+ 树有大量的冗余节点（所有非叶子节点都是冗余索引），这些冗余索引让 B+ 树在插入、删除的效率都更高，比如删除根节点的时候，不会像 B 树那样会发生复杂的树的变化；
B+ 树叶子节点之间用链表连接了起来，有利于范围查询，而 B 树要实现范围查询，因此只能通过树的遍历来完成范围查询，这会涉及多个节点的磁盘 I/O 操作，范围查询效率不如 B+ 树。
怎么做能使得查询不需要3次io？
把节点缓存在内存中，这样下次查询数据的时候，直接在内存进行索引查找就可以了。