网络IO核心原理

Unix网络编程中的I/O模型

阻塞式I/O模型

阻塞I/O(blocking I/O）模型，进程调用recvfrom，其系统调用直到数据报到达且被拷贝到应用进程的缓冲区中或者发生错误才返回。进程从调用recvfrom开始到它返回的整段时间内是被阻塞的。

非阻塞式I/O模型

当一个应用进程像这样对一个非阻塞描述字循环调用recvfrom时，我们称之为轮询（polling）。应用进程持续轮询内核，以查看某个操作是否就绪。

I/O多路复用（事件驱动）模型

信号驱动式I/O(SIGIO)

异步I/O模型

I/O模型的比较

比较结论:
- 前4种模型-阻塞IO、非阻塞IO、IO复用、信号驱动IO都是同步I/O模型。
- 因为其中真正的I/O操作（recvfrom）将阻塞进程，在内核数据copy到用户空间时都是阻塞的。

Unix网络编程对IO模型的理解

如何区分同步IO、异步IO、阻塞IO、非阻塞IO

一个IO操作可以分为 $\color{red}{两个步骤}$ ：发起 $\color{red}{IO请求}$ 和实际的 $\color{red}{IO操作}$
例如：

(1) 操作系统的一次写操作分为两步：将数据从用户空间拷贝到系统空间；从系统空间往网卡写。
(2) 一次读操作分为两步：将数据从网卡拷贝到系统空间；将数据从系统空间拷贝到用户空间。
阻塞IO和非阻塞IO的区别
区别在于第一步，发起IO请求是否会被阻塞，如果阻塞直到完成那么就是传统的阻塞IO，如果不阻塞，那么就是非阻塞IO。
同步IO和异步IO的区别
区别在于第二步，如果请求进程被实际的IO读写阻塞，那么就是同步IO，如果不阻塞，而是操作系统做完两个阶段的IO操作再将结果返回，那就是异步IO。

IO多路复用机制

多路复用的概念
IO多路复用，就是通过一种机制，一个进程可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或者写就绪），能够通知程序进行相应的读写操作。
多路复用IO模型被称为异步阻塞IO模型的原因
因为select函数是阻塞的，这里所说的阻塞是指select函数执行时线程被阻塞，而不是指socket。一般在使用IO多路复用模型时，socket都是设置为NONBLOCK的，不过这并不会产生影响，因为用户发起IO请求时，数据已经到达了，用户线程一定不会被阻塞。
IO多路复用的优势
IO多路复用方式允许单线程内处理多个IO请求，但是每个IO请求的过程还是阻塞的（在select函数上阻塞），平均时间甚至比同步阻塞IO模型还要长。如果用户线程只注册自己感兴趣的socket或者IO请求，然后去做自己的事情，等到数据到来时再进行处理，则可以提高CPU的利用率。
Linux支持的IO多路复用
Linux支持IO多路复用的系统调用有select、poll、epoll，这些调用都是内核级别的。但select、poll、epoll本质上都是同步I/O，先是block住等待就绪的socket，再是block住将数据从内核拷贝到用户内存。select、poll、epoll之间的区别，如下表：
I/O多路复用模式
一般地,I/O多路复用机制都依赖于一个事件多路分离器(Event Demultiplexer)。分离器对象可将来自事件源的I/O事件分离出来，并分发到对应的read/write事件处理器(Event Handler)。
- Reactor模式
  (1) Reactor模式下说明你可以进行读写（收发）操作了。
  (2) Reactor关注的是I/O操作的就绪事件。
  (3) Reactor模式采用同步IO。
  (4) 在Reactor中，事件分离器负责等待文件描述符或socket为读写操作准备就绪，然后将就绪事件通知给对应的处理器，最后由处理器负责完成实际的读写工作。
- Proactor模式
  (1) Proactor模式下说明已经完成读写（收发）操作了，具体内容在给定缓冲区中，可以对这些内容进行其他操作了。
  (2) Proactor关注的是I/O操作的完成事件。
  (3) Proactor采用异步IO
  (4) 在Proactor模式中，处理器或者兼任处理器的事件分离器，只负责发起异步读写操作。IO操作本身由操作系统来完成。传递给操作系统的参数需要包括用户定义的数据缓冲区地址和数据大小，操作系统才能从中得到写出操作所需数据，或写入从socket读到的数据。事件分离器捕获IO操作完成事件，然后将事件传递给对应处理器。比如，在windows上，处理器发起一个异步IO操作，再由事件分离器等待IOCompletion事件。典型的异步模式实现，都建立在操作系统支持异步API的基础之上，我们将这种实现称为“系统级”异步或“真”异步，因为应用程序完全依赖操作系统执行真正的IO工作。
- 总结
  Reactor和Proactor模式的主要区别就是真正的读取和写入操作是有谁来完成的，Reactor中需要应用程序自己读取或者写入数据，而Proactor模式中，应用程序不需要进行实际的读写过程，它只需要从缓存区读取或者写入即可，操作系统会读取缓存区或者写入缓存区到真正的IO设备。

Java网络编程对IO模型的理解

对NIO的非阻塞的理解

注意，select是阻塞的，无论是通过操作系统的通知（epoll）还是不停的轮询(select，poll)，这个函数是阻塞的。所以你可以放心大胆地在一个while(true)里面调用这个函数而不用担心CPU空转。
NIO采用Reactor模式，一个Reactor线程聚合一个多路复用器Selector，它可以同时注册、监听和轮询成百上千个Channel，一个IO线程可以同时并发处理N个客户端连接，线程模型优化为1：N（N < 进程可用的最大句柄数）或者M : N (M通常为CPU核数 + 1， N < 进程可用的最大句柄数)。
JAVA NIO 不是同步非阻塞I/O吗，为什么说JAVA NIO提供了基于Selector的异步网络I/O？
(1) java nio的io模型是同步非阻塞，这里的同步异步指的是真正io操作（数据内核态用户态的拷贝）是否需要进程参与。
(2) 而说java nio提供了异步处理，这个异步应该是指编程模型上的异步。基于reactor模式的事件驱动，事件处理器的注册和处理器的执行是异步的。
AIO(Async I/O)里面会更进一步：不但等待就绪是非阻塞的，就连数据从网卡到内存的过程也是异步的。
换句话说，BIO里用户最关心“我要读”，NIO里用户最关心"我可以读了"，在AIO模型里用户更需要关注的是“读完了”。
NIO一个重要的特点是：socket主要的读、写、注册和接收函数，在等待就绪阶段都是非阻塞的，真正的I/O操作是同步的（消耗CPU但性能非常高）。

如何结合事件模型使用NIO非阻塞特性

BIO模型，之所以需要多线程，是因为在进行I/O操作的时候，一是没有办法知道到底能不能写、能不能读，只能"傻等"，即使通过各种估算，算出来操作系统没有能力进行读写，也没法在socket.read()和socket.write()函数中返回，这两个函数无法进行有效的中断。所以除了多开线程另起炉灶，没有好的办法利用CPU。
NIO的读写函数可以立刻返回，这就给了我们不开线程利用CPU的最好机会：如果一个连接不能读写（socket.read()返回0或者socket.write()返回0），我们可以把这件事记下来，记录的方式通常是在Selector上注册标记位，然后切换到其它就绪的连接（channel）继续进行读写。
我们大概可以总结出NIO是怎么解决掉线程的瓶颈并处理海量连接的：
NIO由原来的阻塞读写（占用线程）变成了单线程轮询事件，找到可以进行读写的网络描述符进行读写。除了事件的轮询是阻塞的（没有可干的事情必须要阻塞），剩余的I/O操作都是纯CPU操作，没有必要开启多线程。并且由于线程的节约，连接数大的时候因为线程切换带来的问题也随之解决，进而为处理海量连接提供了可能。

理解异步非阻塞I/O

很多人喜欢将JDK1.4提供的NIO框架称为异步非阻塞I/O，但是，如果严格按照UNIX网络编程模型和JDK的实现进行区分，实际上它只能被称为非阻塞I/O，不能叫异步非阻塞I/O。在早期的JDK1.4和1.5 update10版本之前，JDK的Selector基于select/poll模型实现，它是基于I/O复用技术的非阻塞I/O，不是异步I/O。在JDK1.5 update10和Linux core2.6以上版本，Sun优化了Selctor的实现，它在底层使用epoll替换了select/poll，上层的API并没有变化，可以认为是JDK NIO的一次性能优化，但是它仍旧没有改变I/O的模型。
由JDK1.7提供的NIO2.0，新增了异步的套接字通道，它是真正的异步I/O，在异步I/O操作的时候可以传递信号变量，当操作完成之后会回调相关的方法，异步I/O也被称为AIO。NIO类库支持非阻塞读和写操作，相比于之前的同步阻塞读和写，它是异步的，因此很多人习惯于称NIO为异步非阻塞I/O，包括很多介绍NIO编程的书籍也沿用了这个说法。为了符合大家的习惯，我们也将NIO称为异步非阻塞I/O或者非阻塞I/O。

Java几种IO模型的对比

Java网络编程

NIO的核心组成

通道(Channel) 和缓冲区(Buffer)
所有的 IO 在NIO 中都从一个Channel 开始。Channel 有点象流。数据可以从Channel读到Buffer中，也可以从Buffer 写到Channel中。
和流不同，通道是双向的。NIO可以通过Channel进行数据的读，写和同时读写操作。通道与流之间不同之处是通道是双向的，流只能一个方向移动（一个流必须是InputStream或者OutputStream的子类）。通道分为两大类：一类是网络读写（SelectableChannel），一类是用于文件操作（FileChannel），我们使用的SocketChannel和ServerSocketChannel都是SelectableChannel的子类。
多路复用器（Selector）
Selector允许单线程处理多个Channel。如果你的应用打开了多个连接（通道），但每个连接的流量都很低，使用Selector就会很方便。(比如聊天)
要使用Selector，得向Selector注册Channel，然后调用它的select()方法。这个方法会一直阻塞到某个注册的通道有事件就绪。一旦这个方法返回，线程就可以处理这些事件，事件的例子有如新连接进来，数据接收等。
Selector会不断地轮询注册在其上的通道（Channel），如果某个通道处于就绪状态，会被Selector轮询出来，然后通过SelectionKey可以取到就绪的Channel集合，从而进行后续的IO操作。服务器端只要提供一个线程负责Selector的轮询，就可以接入成千上万个客户端，这就是JDK NIO库的巨大进步。

BIO

在JDK1.4之前，用Java编写网络请求，都是建立一个ServerSocket，然后，客户端建立Socket时就会询问是否有线程可以处理，如果没有，要么等待，要么被拒绝。即：一个连接，要求Server对应一个处理线程。

NIO

在Java里的由来，在JDK1.4及以后版本中提供了一套API来专门操作非阻塞I/O，我们可以在java.nio包及其子包中找到相关的类和接口。由于这套API是JDK新提供的I/O API，因此，也叫New I/O，这就是包名nio的由来。这套API由三个主要的部分组成：缓冲区（Buffers）、通道（Channels）和非阻塞I/O的核心类组成。在理解NIO的时候，需要区分，说的是New I/O还是非阻塞IO,New I/O是Java的包，NIO是非阻塞IO概念。这里讲的是后面一种。
NIO本身是基于事件驱动思想来完成的，其主要想解决的是BIO的大并发问题：在使用同步I/O的网络应用中，如果要同时处理多个客户端请求，或是在客户端要同时和多个服务器进行通讯，就必须使用多线程来处理。也就是说，将每一个客户端请求分配给一个线程来单独处理。这样做虽然可以达到我们的要求，但同时又会带来另外一个问题。由于每创建一个线程，就要为这个线程分配一定的内存空间（也叫工作存储器），而且操作系统本身也对线程的总数有一定的限制。如果客户端的请求过多，服务端程序可能会因为不堪重负而拒绝客户端的请求，甚至服务器可能会因此而瘫痪。( $\color{red}{这一段介绍的是NIO的由来没耐心可以不看}$ )
NIO基于Reactor，当socket有流可读或可写入socket时，操作系统会相应的通知引用程序进行处理，应用再将流读取到缓冲区或写入操作系统。也就是说，这个时候，已经不是一个连接就要对应一个处理线程了，而是有效的请求，对应一个线程，当连接没有数据时，是没有工作线程来处理的。
Java NIO的工作原理
(1) 由一个专门的线程来处理所有的IO事件，并负责分发。
(2) 事件驱动机制: 事件到的时候触发，而不是同步的去监视事件
(3) 线程通信: 线程之间通过wait、notify等方式通信。保证每次上下文切换都是有意义的，减少无谓的线程切换。

AIO

与NIO不同，操作系统负责处理内核区/用户区的内存数据迁移和真正的IO操作，应用程序只须直接调用API的read或write方法即可。这两种方法均为异步的，对于读操作而言，当有流可读取时，操作系统会将可读的流传入read方法的缓冲区，并通知应用程序；对于写操作而言，当操作系统将write方法传递的流写入完毕时，操作系统主动通知应用程序。即可以理解为，read/write方法都是异步的，完成后会主动调用回调函数。
在JDK1.7中，这部分内容被称作NIO.2，主要在java.nio.channels包下增加了下面四个异步通道：
AsynchronousSocketChannel
AsynchronousServerSocketChannel
AsynchronousFileChannel
AsynchronousDatagramChannel
其中的read/write方法，会返回一个带回调函数的对象，当执行完读取/写入操作后，直接调用回调函数。

在Linux 2.6以后，Java底层的变化

java NIO的实现，是通过epoll来实现的，这点可以通过jdk的源代码发现。
而AIO，在windows上是通过IOCP实现的，在linux上通过新的API来实现。