2. unix网络编程5种IO模型

linux 的内核将所有外部设备都可以看做一个文件来操作，我们对外部设备的操作都可以看做对文件进行操作。
我们对一个文件的读写，都通过调用提供的系统调用。内核给我们返回一个file descriptor（fd 文件描述符）。
对一个socket的读写也会用相应的描述符，称为socketfd。描述符就是一个数字，指向内核中的一个结构体(文件路径、数据区等一些属性)。

2.1 阻塞IO

• 缺省情况下，所有的操作都是阻塞的

• 在进程空间中调用recvform，其系统调用直到数据报到达且被拷贝到应用程序的缓冲区中或者发生错误才返回。期间一直等待。

  
  

2.2 非阻塞IO

recvfrom 从应用层到内核的时候，如果该缓冲区没有数据的话，就直接返回一个 EWOULDBLOCK，一般都是对非阻塞IO模型进行轮询检查这个状态，看内核是不是有数据到来。

2.3 IO复用

• linux 提供select/poll，进程通过将一个或多个fd传递给select或poll系统调用，阻塞在select。这样select/poll可以帮我们侦测许多fd是否就绪。

• 但是select/poll是循序扫描fd是否就绪，而且支持的fd数量有限。linux还提供了一个epoll系统调用。epoll是基于事件驱动方式，而不是顺序扫描。
  当有fd就绪时，立即回调函数rollback。

2.4 信号驱动的IO

• 首先开启套接字信号驱动IO功能，并通过系统调用sigaction执行一个信号处理函数(此系统调用立即返回，进程继续工作，它是非阻塞的)

• 当数据准备就绪时，就为该进程生成一个SIGIO信号。随即可以在信号处理程序中调用recvfrom来读数据，并通过主循环函数处理数据。

  
  
  

2.5 异步IO

• 告知内核启动某个操作，并让内核在整个操作完成后（包括将数据从内核拷贝到用户缓存区）

• 信号驱动IO：由内核通过我们解释介意启动一个IO操作。异步IO：由内核通知我们IO操作何时完成。

  
  image.png

3. BIO、NIO、AIO

https://www.bilibili.com/video/BV1JT4y1u71v?p=4
https://www.bilibili.com/video/BV15g4y167Dy?p=3

BIO还是NIO是内核决定的，而不是编程语言的API决定的

通信协议 TCP通信

2.1 1:1 同步阻塞IO通信模型 BIO

• 服务端，通常由一个独立的Acceptor线程负责监听客户端的连接。接收到客户端的连接后为客户端连接创建一个新的线程处理请求。

• 处理完成之后，返回消息给客户端，线程销毁。典型的一请求一应答。

• 不具备弹性伸缩能力，当并发访问量增加后，服务端的线程个数和并发访问数成线性正比。

• JVM中线程数膨胀后，系统的性能急剧下降，随着并发量的急剧增加，可能会导致句柄移除、线程堆栈移除等问题，并导致服务器最终宕机。

为甚不让一个线程处理多个socket连接

当某个Socket链路的读写操作没有完成时，排在后面的Socket连接是无法得到处理的，长时间的等待可能会导致超时，因此，在同步阻塞模型下，一个线程处理多个客户端连接没有意义，反而会导致后面排队的Socket连接处理不及时引起客户端超时，所以通常会采用每个Socket链路独占一个线程的模型。

strace -ff -o out /usr/java/jdk1.8.0_131/bin/java ServerDemo

2.2 M:N 形式的同步阻塞IO模型

Netty实战之核心概念.md

1. 服务端线程接收到客户端连接之后，不创建独立的线程，而是将socket连接封装成Task，将task放入线程池的任务队列中执行，这样就可以有效控制线程规模，
   防止线程膨胀导致的系统崩溃，利用线程池，可以重用线程，性能相比于传统的一连接一线程有很大的提升。

2. 伪异步通信框架能够缓解BIO面临的问题，但是无法从根本上解决问题。
   由于IO的读写操作会被阻塞，当并发量增加或者网络IO时延增大了之后，线程的执行时间会被拉长，导致缓存在任务队列中的任务不断堆积，
   最终导致内存溢出或者拒绝新任务的执行。

3. 由于网络的时延、客户端的执行速度和服务器的处理能力不同，导致网络IO的执行时间不可控，如果IO读写被阻塞，阻塞的时间往往也是不可控的（或者超时）。
   它会导致IO线程的不可预期性额阻塞，降低系统的处理能力和网络吞吐量。
   在大规模高并发、高性能的服务器端，使用JAVA的同步IO来构建服务端是无法满足性能、可拓展性和可靠性要求的。

2.3 非阻塞IO模型 NIO(同步非阻塞)+单线程Reactor模式

image.png

2.4 非阻塞IO模型 NIO+多线程Reactor模式

2.5 NIO+主从多线程Reactor模式

image.png

2.6 AIO

2.7 对比

NIO 服务端

NIO 客户端

netty架构

netty的IO是同步的，处理是异步的

第一层：Reactor通信调度层

• 由一些列辅助类完成，包括Reactor线程 NioEventLoop 以及其父类、NioSocketChannel/NioServerSocketChannel以及其父类、
  ByteBuffer以及其衍生出来的各种 Buffer、Unsafe以及其衍生出来的各种内部类等

• 该层的主要职责就是监听网络的读写和连接操作，负责将网络层的数据读取到内存缓存中，然后触发各种网络事件

• 例如连接池、连接激活、读事件、写事件。将这些事件触发到pipeLine中，由PipeLine充当的职责链进行后续的处理。

第二层：职责链PipeLine

• 负责事件在职责链中的有序传播，同时负责动态的编排责任链，职责链可以选择监听和处理自己关心的事情，它可以拦截处理和向前/向后传播事件。

• 不同应用的Handler节点的功能也不同。通常情况下，往往会触发编解码Handler用于消息的编解码，它可以将外部的协议消息转换成内部的POJO对象

• 这样上层业务侧只需要关心处理业务逻辑即可。不需要感知底层的协议差异和线程模型差异，实现了架构层面的分层隔离

第三层：业务逻辑编排层

• 一类是纯粹的业务逻辑编排

• 一类是其他的应用层协议插件，用于特性协议相关的会话和链路管理。例如CMPP协议，用于管理和中国移动短信的对接。