）颁发的证书对软件进行数字签名，开发人员可以向最终用户保证他们希望安装的软件是由已知且受信任的开发人员发布；并且签名后未被篡改或损害。

HTTPS 并不是一项新的应用层协议，只是 HTTP 通信接口部分由 SSL 和 TLS 替代而已。通常情况下，HTTP 会先直接和 TCP 进行通信。在使用 SSL 的 HTTPS 后，则会先演变为和 SSL 进行通信，然后再由 SSL 和 TCP 进行通信。也就是说，HTTPS 就是身披了一层 SSL 的 HTTP。（我都喜欢把骚粉留在最后。。。
SSL 是一个独立的协议，不只有 HTTP 可以使用，其他应用层协议也可以使用，比如 SMTP(电子邮件协议)、Telnet(远程登录协议) 等都可以使用。

SSL 即安全套接字层，它在 OSI 七层网络模型中处于第五层，SSL 在 1999 年被 IETF(互联网工程组)更名为 TLS ，即传输安全层，直到现在，TLS 一共出现过三个版本，时，浏览器去到dns服务器获取此url对应的ip，然后客户端连接上服务端的443端口，将此请求发送给到服务端，此时客户端同时将自己支持的加密算法带给服务端；

服务端收到这套加密算法的时候，和自己支持的加密算法进行对比（也就是和自己的私钥进行对比），如果不符合，就断开连接；如果符合，服务端就将CA证书发送给客户端，此证书中包括了数字证书包含的内容：1、证书颁发机构；2、使用机构；3、公钥；4、有效期；5、签名算法；6、签名hash算法；7、指纹算法；8、指纹。

这里服务端发送的东西是用私钥进行加密的，公钥都能解开，并不能保证发送的数据包不被别人看到，所以后面的过程会和客户端商量选择一个对称加密（只能用私钥解开，这里详情请移步非对称、对称加解密相关问题）来对传输的数据进行加密。

（3）客户端验证服务端发来的证书

客户端验证收到的证书，包括发布机构是否合法、过期，证书中包含的网址是否与当前访问网址一致等等。

客户端验证证书无误后（或者接受了不信任的证书），会生成一个随机数，用服务端发过来的公钥进行加密。如此一来，此随机数只有服务端的私钥能解开了。

用证书中的签名hash算法取握手信息的hash值，然后用生成的随机数对[握手信息和握手信息的hash值]进行加密，然后用公钥将随机数进行加密后，一起发送给服务端。其中计算握手信息的hash值，目的是为了保证传回到服务端的握手信息没有被篡改。

（4）服务端接收随机数加密的信息，并解密得到随机数，验证握手信息是否被篡改。

服务端收到客户端传回来的用随机数加密的信息后，先用私钥解密随机数，然后用解密得到的随机数解密握手信息，获取握手信息和握手信息的hash值，计算自己发送的握手信息的hash值，与客户端传回来的进行对比验证。

如果验证无误，同样使用随机字符串加密握手信息和握手信息hash值发回给到客户端。

（5）客户端验证服务端发送回来的握手信息，完成握手

客户端收到服务端发送过来的握手信息后，用开始自己生成的随机数进行解密，验证被随机数加密的握手信息和握手信息hash值。

验证无误后，握手过程就完成了，从此服务端和客户端就开始用那串随机数进行对称加密通信了（常用的对称加密算法有AES）。

（1）修改Linux内核参数

通过修改内核参数，控制队列大小和队满的时候应做什么处理。

• 当网卡接受数据包的速度大于内核处理速度时，会有一个队列保存这些数据包。控制该队列的最大值如下参数：

• 超出处理能力时，对新的SYN直接回报RST，丢弃连接：

先看一下syn队列与accept队列是如何工作的：

• 当服务端接受到客户端的SYN报文时，会将其加入到SYN队列
• 接着发送SYN+ACK给客户端，等待客户端回应ACK
• 服务端接受到ACK报文后，从SYN队列移除放入Acccept队列
• 应用通过调用accept()接口，从Accept队列中取出连接。

应用程序过慢时，会导致Accept队列被占满。

受到SYN攻击时，会导致SYN队列被占满

• 当SYN队列满了之后，后续服务收到SYN包，不进入SYN队列
• 计算出一个cookie值，再以SYN+ACK中的序列号返回客户端
• 服务端接收到客户端的应答报文时，服务器会检查这个ACK包的合法性。如果合法，直接放入Accept队列

Reactor模式，是基于Java NIO的，在他的基础上，抽象出来两个组件——Reactor和Handler两个组件：
（1）Reactor：负责响应IO事件，当检测到一个新的事件，将其发送给相应的Handler去处理；新的事件包含连接建立就绪、读就绪、写就绪等。

下图十最简单的单Reactor单线程模型，Reactor线程是个多面手，负责多路分离套接字，Accept新连接，并分派请求到Handler处理器中。

当其中某个 handler 阻塞时， 会导致其他所有的 client 的 handler 都得不到执行， 并且更严重的是， handler 的阻塞也会导致整个服务不能接收新的 client 请求(因为 acceptor 也被阻塞了)。 因为有这么多的缺陷， 因此单线程Reactor 模型用的比较少。这种单线程模型不能充分利用多核资源，所以实际使用的不多。

在单线程Reactor模式基础上，做如下改进：

• 将Handler处理器的执行放入线程池，多线程进行业务处理。
• 而对于Reactor而言，可以仍为单个线程。如果服务器为多核的CPU，为充分利用系统资源，可以将Reactor拆分为两个线程。
  

在linux中的Java进程中，默认情况下所有的socket都是blocking IO。在阻塞式 I/O 模型中，应用程序在从IO系统调用开始，一直到到系统调用返回，这段时间是阻塞的。返回成功后，应用进程开始处理用户空间的缓存数据

举个栗子，发起一个blocking socket的read读操作系统调用，流程大概是这样：

（1）当用户线程调用了read系统调用，内核（kernel）就开始了IO的第一个阶段：准备数据。很多时候，数据在一开始还没有到达（比如，还没有收到一个完整的Socket数据包），这个时候kernel就要等待足够的数据到来。

（2）当kernel一直等到数据准备好了，它就会将数据从kernel内核缓冲区，拷贝到用户缓冲区（用户内存），然后kernel返回结果。

（3）从开始IO读的read系统调用开始，用户线程就进入阻塞状态。一直到kernel返回结果后，用户线程才解除block的状态，重新运行起来

所以，blocking IO的特点就是在内核进行IO执行的两个阶段，用户线程都被block了。

在linux系统下，可以通过设置socket使其变为non-blocking。NIO 模型中应用程序在一旦开始IO系统调用，会出现以下两种情况：

（1）在内核缓冲区没有数据的情况下，系统调用会立即返回，返回一个调用失败的信息
（2）在内核缓冲区有数据的情况下，是阻塞的，直到数据从内核缓冲复制到用户进程缓冲。复制完成后，系统调用返回成功，应用进程开始处理用户空间的缓存数据。

举个栗子。发起一个non-blocking socket的read读操作系统调用，流程是这个样子：

（1）在内核数据没有准备好的阶段，用户线程发起IO请求时，立即返回。用户线程需要不断地发起IO系统调用。
（2）内核数据到达后，用户线程发起系统调用，用户线程阻塞。内核开始复制数据。它就会将数据从kernel内核缓冲区，拷贝到用户缓冲区（用户内存），然后kernel返回结果。
（3）用户线程才解除block的状态，重新运行起来。经过多次的尝试，用户线程终于真正读取到数据，继续执行。

优点：每次发起的 IO 系统调用，在内核的等待数据过程中可以立即返回。用户线程不会阻塞，实时性较好。
缺点：需要不断的重复发起IO系统调用，这种不断的轮询，将会不断地询问内核，这将占用大量的 CPU 时间，系统资源利用率较低。

总之，NIO模型在高并发场景下，也是不可用的。一般 Web 服务器不使用这种 IO 模型。一般很少直接使用这种模型，而是在其他IO模型中使用非阻塞IO这一特性。java的实际开发中，也不会涉及这种IO模型。

如何避免同步非阻塞NIO模型中轮询等待的问题呢？这就是IO多路复用模型。

IO多路复用模型，就是通过一种新的系统调用，一个进程可以监视多个文件描述符，一旦某个描述符就绪（一般是内核缓冲区可读/可写），内核kernel能够通知程序进行相应的IO系统调用。

目前支持IO多路复用的系统调用，有 select，epoll等等。select系统调用，是目前几乎在所有的操作系统上都有支持，具有良好跨平台特性。epoll是在linux 2.6内核中提出的，是select系统调用的linux增强版本。

IO多路复用模型的基本原理就是select/epoll系统调用，单个线程不断的轮询select/epoll系统调用所负责的成百上千的socket连接，当某个或者某些socket网络连接有数据到达了，就返回这些可以读写的连接。因此，好处也就显而易见了——通过一次select/epoll系统调用，就查询到到可以读写的一个甚至是成百上千的网络连接。

举个栗子。发起一个多路复用IO的的read读操作系统调用，流程是这个样子：

在这种模式中，首先不是进行read系统调动，而是进行select/epoll系统调用。当然，这里有一个前提，需要将目标网络连接，提前注册到select/epoll的可查询socket列表中。然后，才可以开启整个的IO多路复用模型的读流程。

(1)进行select/epoll系统调用，查询可以读的连接。kernel会查询所有select的可查询socket列表，当任何一个socket中的数据准备好了，select就会返回。

(2)用户线程获得了目标连接后，发起read系统调用，用户线程阻塞。内核开始复制数据。它就会将数据从kernel内核缓冲区，拷贝到用户缓冲区（用户内存），然后kernel返回结果.

(3)用户线程才解除block的状态，用户线程终于真正读取到数据，继续执行。

select的调用复杂度是线性的，即O(n)。举个例子，一个保姆照看一群孩子，如果把孩子是否需要尿尿比作网络IO事件，select的作用就好比这个保姆挨个询问每个孩子：你要尿尿吗？如果孩子回答是，保姆则把孩子拎出来放到另外一个地方。当所有孩子询问完之后，保姆领着这些要尿尿的孩子去上厕所（处理网络IO事件）。

还是以保姆照看一群孩子为例，在epoll机制下，保姆不再需要挨个的询问每个孩子是否需要尿尿。取而代之的是，每个孩子如果自己需要尿尿的时候，自己主动的站到事先约定好的地方，而保姆的职责就是查看事先约定好的地方是否有孩子。如果有小孩，则领着孩子去上厕所（网络事件处理）。因此，epoll的这种机制，能够高效的处理成千上万的并发连接，而且性能不会随着连接数增加而下降。

select本质上是通过设置或检查存放fd标志位的数据结构进行下一步处理。 这带来缺点： - 单个进程可监视的fd数量被限制，即能监听端口的数量有限 单个进程所能打开的最大连接数由FD_SETSIZE宏定义，其大小是32个整数的大小（在32位的机器上，大小就是3232，同理64位机器上FD_SETSIZE为3264），当然我们可以对进行修改，然后重新编译内核，但是性能可能会受到影响，这需要进一步的测试 一般该数和系统内存关系很大，具体数目可以cat

对socket是线性扫描，即轮询，效率较低： 仅知道有I/O事件发生，却不知是哪几个流，只会无差异轮询所有流，找出能读数据或写数据的流进行操作。同时处理的流越多，无差别轮询时间越长 - O(n)。

当socket较多时，每次select都要通过遍历FD_SETSIZE个socket，不管是否活跃，这会浪费很多CPU时间。如果能给 socket 注册某个回调函数，当他们活跃时，自动完成相关操作，即可避免轮询，这就是epoll与kqueue。

select方法本质其实就是维护了一个文件描述符（fd）数组，以此为基础，实现IO多路复用的功能。这个fd数组有长度限制，在32位系统中，最大值为1024个，而在64位系统中，最大值为2048个，这个配置可以调用

select方法被调用，首先需要将fd_set从用户空间拷贝到内核空间，然后内核用poll机制（此poll机制非IO多路复用的那个poll方法，可参加附录）直到有一个fd活跃，或者超时了，方法返回。

• 如果返回值为-1，表明发生了错误
• 如果返回值为0，表明超时了
• 如果返回值为正数，表明有n个fd准备就绪了

select方法返回后，需要轮询fd_set，以检查出发生IO事件的fd。这样一套下来，select方法的缺点就很明显了：

• fd_set在用户空间和内核空间的频繁复制，效率低
• 单个进程可监控的fd数量有限制，无论是1024还是2048，对于很多情景来说都是不够用的。
• 基于轮询来实现，效率低

poll本质上和select没有区别，依然需要进行数据结构的复制，依然是基于轮询来实现，但区别就是，select使用的是fd数组，而poll则是维护了一个链表，所以从理论上，poll方法中，单个进程能监听的fd不再有数量限制。但是轮询，复制等select存在的问题，poll依然存在

epoll就是对select和poll的改进了。它的核心思想是基于事件驱动来实现的，实现起来也并不难，就是给每个fd注册一个回调函数，当fd对应的设备发生IO事件时，就会调用这个回调函数，将该fd放到一个链表中，然后由客户端从该链表中取出一个个fd，以此达到O（1）的时间复杂度

• epoll_create：epoll_create相当于在内核中创建一个存放fd的数据结构。在select和poll方法中，内核都没有为fd准备存放其的数据结构，只是简单粗暴地把数组或者链表复制进来；而epoll则不一样，epoll_create会在内核建立一颗专门用来存放fd结点的红黑树，后续如果有新增的fd结点，都会注册到这个epoll红黑树上。
• epoll_ctr:另一点不一样的是，select和poll会一次性将监听的所有fd都复制到内核中，而epoll不一样，当需要添加一个新的fd时，会调用epoll_ctr，给这个fd注册一个回调函数，然后将该fd结点注册到内核中的红黑树中。当该fd对应的设备活跃时，会调用该fd上的回调函数，将该结点存放在一个就绪链表中。这也解决了在内核空间和用户空间之间进行来回复制的问题。
• epoll_wait:epoll_wait的做法也很简单，其实直接就是从就绪链表中取结点，这也解决了轮询的问题，时间复杂度变成O(1)

所以综合来说，epoll的优点有：

• 没有最大并发连接的限制，远远比1024或者2048要大。（江湖传言1G的内存上能监听10W个端口）
• 效率变高。epoll是基于事件驱动实现的，不会随着fd数量上升而效率下降

水平触发 ：水平触发的意思就是说，只要条件满足，对应的事件就会一直被触发。所以如果条件满足了但未进行处理，那么就会一直被通知
边缘触发：边缘触发的意思就是说，条件满足后，对应的事件只会被触发一次，无论是否被处理，都只会触发一次。

• EPOLLLT（默认状态）：也就是水平触发。在该模式下，只要这个fd还有数据可读，那么epoll_wait函数就会返回该fd
• EPOLLET（高速模式）：也就是边缘触发。在该模式下，当被监控的fd上有可读写事件发生时，epoll_wait会通知程序去读写，若本次读写没有读完所有数据，或者甚至没有进行处理，那么下一次调用epoll_wait时，也不会获取到该fd。这种效率比水平触发的要高，系统中不会充斥着大量程序不感兴趣的fd，不感兴趣直接忽视就行，下次不会再触发

• select，poll是基于轮询实现的，将fd_set从用户空间复制到内核空间，然后让内核空间以poll机制来进行轮询，一旦有其中一个fd对应的设备活跃了，那么就把整个fd_set返回给客户端（复制到用户空间），再由客户端来轮询每个fd的，找出发生了IO事件的fd
• epoll是基于事件驱动实现的，加入一个新的fd，会调用epoll_ctr函数为该fd注册一个回调函数，然后将该fd结点注册到内核中的epoll红黑树中，当IO事件发生时，就会调用回调函数，将该fd结点放到就绪链表中，epoll_wait函数实际上就是从这个就绪链表中获取这些fd。
• epoll分为EPOLLLT（水平触发，默认状态）和EPOLLET（边缘触发，效率高）
• 并不是所有的情况中epoll都是最好的，比如当fd数量比较小的时候，epoll不见得就一定比select和poll好

• 一致性（consistency）：保持所有节点在同一个时刻具有相同的、逻辑一致的数据。
• 可用性（availability）：保证每个请求不管成功还是失败都有响应。
• 分区容忍性（partition tolerance）：系统中任何的信息丢失或者失败都不会影响系统的继续运作

针对这3个特点，Eric Brewer教授在2000年提出了CAP原则，也称为CAP定理。该原则指出，任何分布式系统都不能同时满足3个特点，如图1-6所示。
根据CAP原则，从图1-6中可以看出分布式系统只能满足3种情况。

• CA：满足一致性和可用性的系统。在可扩展性上难有建树。
• CP：满足一致性和分区容忍性的系统。通常性能不是特别高。
• AP：满足可用性和分区容忍性的系统。通常对一致性要求低一些，但性能会比较高。

• 强一致性：当用户完成数据更新操作之后，任何后续线程或者其他节点都能访问到最新值。这样的设计是最友好的，即用户上一次的操作，下一次都能读到。但根据CAP原则，这种实现需要对性能做出较大的牺牲。
• 弱一致性：当用户完成数据更新操作之后，并不能保证后续线程或者其他节点马上访问到最新值。它只能通过某种方法来保证最后的一致性。

BASE并非一个英文单词，而是几个英文单词的简写。

• Available，基本可用）：在分布式系统中，最重要的需求是保证基本可用，有响应结果返回。例如，在“双十一抢购”的苛刻环境下，用户到电商处进行抢购。即使抢购失败，系统也会提示“系统繁忙，请过会儿再来”。我们分析一下这样的场景。用户是来购买商品的，而在抢购的环境下可能因为资源瓶颈，无法完成。为了避免用户长时间等待，系统会提示用户过会儿再来。这里的提示信息不需要消耗太多的系统资源，因而这样的场景就是典型的降级服务。虽然没有完成客户需要的抢购，但是却给了用户明确的信息，避免了用户长时间等待的情况，这样会给用户带来良好的体验
• S（Soft State，软状态）：其意义在于允许系统存在中间状态。一般来说，系统之间的数据通信都会存有副本，而这些副本都会存在一定的延迟。这时推荐使用弱一致性代替强一致性。这样的好处在于，提高系统的可用和性能。在网站用户的体验中，快速显示结果往往比一致性更为重要，因为没人愿意使用一个几十秒都不能响应的网站。
• E（Eventual Consistency，最终一致性）：是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态，以保证数据的正确性。

IOC即控制反转， 是一种设计思想，而不是一个具体的技术实现。IoC 的思想就是将原本在程序中手动创建对象的控制权，交由 Spring 框架来管理。不过， IoC 并非 Spirng 特有，在其他语言中也有应用。是基于反射来实现的

AOP(Aspect-Oriented Programming:面向切面编程)能够将那些与业务无关，却为业务模块所共同调用的逻辑或责任（例如事务处理、日志管理、权限控制等）封装起来，便于减少系统的重复代码，降低模块间的耦合度，并有利于未来的可拓展性和可维护性。是基于代理来实现的。

AOP最为典型的应用实际就是数据库事务的管控。例如，当我们需要保存一个用户时，可能要连同它的角色信息一并保存到数据库中。于是，可以看到图4-4所示的一个流程图。

这里的用户信息和用户角色信息，我们都可以使用面向对象编程（OOP）进行设计，但是它们在数据库事务中的要求是，要么一起成功，要么一起失败，这样OOP就无能为力了。数据库事务毫无疑问是企业级应用关注的核心问题之一，而使用AOP可以解决这些问题。AOP还可以减少大量重复的工作。在Spring流行之前，我们可以使用JDBC代码实现很多的数据库操作，例如，插入一个用户的信息，我们可以用JDBC代码来实现。

• 选取可用的Zone，并随机挑选一个Zone出来，然后根据此Zone的名称来获取负载均衡器。

• 判断是否启用了Zone的功能，如果没有Zone或者是Zone的数量只有1个，就采用BaseLoadBalancer的chooseServer方法来选择具体的服务，结束流程。
• 按照负载阈值来排除Zone，排除最高负载20%的Zone。
• 按照故障率阈值来排除Zone，排除故障率大于99.999%的Zone。
• 如果以上步骤都存在可用Zone，就采用随机算法获取Zone，选中Zone后，再通过负载均衡器（zoneLoadBalancer）的chooseServer方法选择服务。

下面展示了一个Bean的构造过程
如上图所示，Bean 的生命周期还是比较复杂的，下面来对上图每一个步骤做文字描述:

• Spring启动，查找并加载需要被Spring管理的bean，进行Bean的实例化
• Bean实例化后对将Bean的引入和值注入到Bean的属性中

用户在编制程序时并不知道主存的使用状况，用户编程时使用的地址就是虚地址或逻辑地址，其对应的空间即徐空间或逻辑空间。而计算机物理内存的访问地址称为实地址或物理地址。程序将虚地址转换为实地址的过程称为程序的再定位。

以页为单位的虚拟存储器，称为页式虚拟存储器。它的虚拟空间跟主存空间都将被划分为相同大小的页。主存中的页，称为实页，虚存中的页，称为虚页。虚拟地址被分为两个字段，虚页号和页内偏移。为了对每个虚拟页的存放位置，存取位置，使用情况，修改情况等等进行等进行说明，操作系统在主存中给每个进程都生成一个页表。因此，每个虚拟页表都对应有一个页表项。页表是一张存放在主存中的，虚拟页与实页对照的映射表。其中存放位置字段用来建立虚拟页与实页之间的映射，进而进行地址转换。有效位用来表示对应页面是否存在。