网络IO

（一）I/O到底是什么?

I/O 其实就是 input 和 output 的缩写，即输入/输出。

那输入输出啥呢？

比如我们用键盘来敲代码其实就是输入，那显示器显示图案就是输出，这其实就是 I/O。

而我们时常关心的磁盘 I/O 指的是硬盘和内存之间的输入输出。

读取本地文件的时候，要将磁盘的数据拷贝到内存中，修改本地文件的时候，需要把修改后的数据拷贝到磁盘中。

网络 I/O 指的是网卡与内存之间的输入输出。

当网络上的数据到来时，网卡需要将数据拷贝到内存中。当要发送数据给网络上的其他人时，需要将数据从内存拷贝到网卡里。

那为什么都要跟内存交互呢?

我们的指令最终是由 CPU 执行的，究其原因是 CPU 与内存交互的速度远高于 CPU 和这些外部设备直接交互的速度。

因此都是和内存交互，当然假设没有内存，让 CPU 直接和外部设备交互，那也算 I/O。

总结下：I/O 就是指内存与外部设备之间的交互（数据拷贝）。

（二）为什么网络 I/O 会被阻塞？

其实了解了 Socket 的通讯内幕就能回答这个问题。

详细来看这个问题要从建连和通讯涉及到个各个方法来入手，分别是 accept、connect、read、write 。

我们慢慢分析下。

1.创建 socket

首先服务端需要先创建一个 socket。在 Linux 中一切都是文件，那么创建的 socket 也是文件，每个文件都有一个整型的文件描述符（fd）来指代这个文件。

int socket(
int domain, //这个参数用于选择通信的协议族，比如选择 IPv4 通信，还是 IPv6 通信等等
int type, //选择套接字类型，可选字节流套接字、数据报套接字等等。
int protocol);//指定使用的协议。

这个 protocol 通常可以设为 0 ，因为由前面两个参数可以推断出所要使用的协议。

比如socket(AF_INET, SOCK_STREAM, 0);，表明使用 IPv4 ，且使用字节流套接字，可以判断使用的协议为 TCP 协议。

这个方法的返回值为 int ，其实就是创建的 socket 的 fd。

2.bind

现在我们已经创建了一个 socket，但现在还没有地址指向这个 socket。

众所周知，服务器应用需要指明 IP 和端口，这样客户端才好找上门来要服务，所以此时我们需要指定一个地址和端口来与这个 socket 绑定一下。

int bind(int sockfd, const struct sockaddr *addr, socklen_t addrlen);

参数里的 sockfd 就是我们创建的 socket 的文件描述符，执行了 bind 参数之后我们的 socket 距离可以被访问又更近了一步。

3.listen

执行了 socket、bind 之后，此时的 socket 还处于 closed 的状态，也就是不对外监听的，然后我们需要调用 listen 方法，让 socket 进入被动监听状态，这样的 socket 才能够监听到客户端的连接请求。

int listen(int sockfd, int backlog);

传入创建的 socket 的 fd，并且指明一下 backlog 的大小。

这个 backlog看到了三种解释：

1. socket 有一个队列，同时存放已完成的连接和半连接，backlog为这个队列的大小。
2. socket 有两个队列，分别为已完成的连接队列和半连接队列，backlog为这个两个队列的大小之和。
3. socket 有两个队列，分别为已完成的连接队列和半连接队列，backlog仅为已完成的连接队列大小。

解释下什么叫半连接

我们都知道 TCP 建立连接需要三次握手，当接收方收到请求方的建连请求后会返回 ack，此时这个连接在接收方就处于半连接状态，当接收方再收到请求方的 ack 时，这个连接就处于已完成状态：

所以上面讨论的就是这两种状态的连接的存放问题。

所以上面讨论的就是这两种状态的连接的存放问题。

我查阅资料看到，基于 BSD 派生的系统的实现是使用的一个队列来同时存放这两种状态的连接， backlog 参数即为这个队列的大小。

而 Linux 则使用两个队列分别存储已完成连接和半连接，且 backlog 仅为已完成连接的队列大小

4.accept

现在我们已经初始化好监听套接字了，此时会有客户端连上来，然后我们需要处理这些已经完成建连的连接。

从上面的分析我们可以得知，三次握手完成后的连接会被加入到已完成连接队列中去。

这时候，我们就需要从已完成连接队列中拿到连接进行处理，这个拿取动作就由 accpet 来完成。

int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen);

这个方法返回的 int 值就是拿到的已完成连接的 socket 的文件描述符，之后操作这个 socket 就可以进行通信了。

如果已完成连接队列没有连接可以取，那么调用 accept 的线程会阻塞等待。

至此服务端的通信流程暂告一段落，我们再看看客户端的操作。

5.connect

客户端也需要创建一个 socket，也就是调用 socket()，这里就不赘述了，我们直接开始建连操作。

客户端需要与服务端建立连接，在 TCP 协议下开始经典的三次握手操作

客户端创建完 socket 并调用 connect 之后，连接就处于 SYN_SEND 状态，当收到服务端的 SYN+ACK 之后，连接就变为 ESTABLISHED 状态，此时就代表三次握手完毕。

int connect(int sockfd, const struct sockaddr *addr, socklen_t addrlen);

调用connect需要指定远程的地址和端口进行建连，三次握手完毕之后就可以开始通信了。

客户端这边不需要调用 bind 操作，默认会选择源 IP 和随机端口。

可以看到这里的两个阻塞点：

• connect：需要阻塞等待三次握手的完成。
• accept：需要等待可用的已完成的连接，如果已完成连接队列为空，则被阻塞。

6.read、write

连接建立成功之后，就能开始发送和接收消息了

read 为读数据，从服务端来看就是等待客户端的请求，如果客户端不发请求，那么调用 read 会处于阻塞等待状态，没有数据可以读，这个应该很好理解。

write 为写数据，一般而言服务端接受客户端的请求之后，会进行一些逻辑处理，然后再把结果返回给客户端，这个写入也可能会被阻塞。

这里可能有人就会问 read 读不到数据阻塞等待可以理解，write 为什么还要阻塞，有数据不就直接发了吗？

因为我们用的是 TCP 协议，TCP 协议需要保证数据可靠地、有序地传输，并且给予端与端之间的流量控制。

所以说发送不是直接发出去，它有个发送缓冲区，我们需要把数据先拷贝到 TCP 的发送缓冲区，由 TCP 自行控制发送的时间和逻辑，有可能还有重传什么的。

如果我们发的过快，导致接收方处理不过来，那么接收方就会通过 TCP 协议告知：别发了！忙不过来了。发送缓存区是有大小限制的，由于无法发送，还不断调用 write 那么缓存区就满了，满了就不然你 write 了，所以 write 也会发生阻塞。

综上，read 和 write 都会发生阻塞。

（三）所以为什么网络 I/O 会发生阻塞？

因为建连和通信涉及到的 accept、connect、read、write 这几个方法都可能会发生阻塞。

阻塞会占用当前执行的线程，使之不能进行其他操作，并且频繁阻塞唤醒切换上下文也会导致性能的下降。

由于阻塞的缘故，起初的解决的方案就是建立多个线程，但是随着互联网的发展，用户激增，连接数也随着激增，需要建立的线程数也随着一起增加，到后来就产生了 C10K 问题。

服务端顶不住了呀，咋办？

优化呗！

所以后来就弄了个非阻塞套接字，然后 I/O多路复用、信号驱动I/O、异步I/O。

（四）I/O模型有哪些？

以 read 调用，即读取网络数据为例子来展开 I/O 模型。

1.同步阻塞 I/O

当用户程序的线程调用 read 获取网络数据的时候，首先这个数据得有，也就是网卡得先收到客户端的数据，然后这个数据有了之后需要拷贝到内核中，然后再被拷贝到用户空间内，这整一个过程用户线程都是被阻塞的。

假设没有客户端发数据过来，那么这个用户线程就会一直阻塞等着，直到有数据。即使有数据，那么两次拷贝的过程也得阻塞等着。

所以这称为同步阻塞 I/O 模型。

它的优点很明显，简单。调用 read 之后就不管了，直到数据来了且准备好了进行处理即可。

缺点也很明显，一个线程对应一个连接，一直被霸占着，即使网卡没有数据到来，也同步阻塞等着。

我们都知道线程是属于比较重资源，这就有点浪费了。

所以我们不想让它这样傻等着。

于是就有了同步非阻塞 I/O。

2.同步非阻塞 I/O

同步非阻塞I/O 基于同步阻塞I/O 进行了优化：

从图中我们可以很清晰的看到，同步非阻塞I/O 基于同步阻塞I/O 进行了优化：

在没数据的时候可以不再傻傻地阻塞等着，而是直接返回错误，告知暂无准备就绪的数据！

这里要注意，从内核拷贝到用户空间这一步，用户线程还是会被阻塞的。

这个模型相比于同步阻塞 I/O 而言比较灵活，比如调用 read 如果暂无数据，则线程可以先去干干别的事情，然后再来继续调用 read 看看有没有数据。

但是如果你的线程就是取数据然后处理数据，不干别的逻辑，那这个模型又有点问题了。

等于你不断地进行系统调用，如果你的服务器需要处理海量的连接，那么就需要有海量的线程不断调用，上下文切换频繁，CPU 也会忙死，做无用功而忙死。

那怎么办？

于是就有了I/O 多路复用。

3.I/O 多路复用

从图上来看，好像和上面的同步非阻塞 I/O 差不多啊，其实不太一样，线程模型不一样。

既然同步非阻塞 I/O 在太多的连接下频繁调用太浪费了， 那就招个专员吧。

这个专员工作就是管理多个连接，帮忙查看连接上是否有数据已准备就绪。

也就是说，可以只用一个线程查看多个连接是否有数据已准备就绪。

具体到代码上，这个专员就是 select ，我们可以往 select 注册需要被监听的连接，由 select 来监控它所管理的连接是否有数据已就绪，如果有则可以通知别的线程来 read 读取数据，这个 read 和之前的一样，还是会阻塞用户线程。

这样一来就可以用少量的线程去监控多条连接，减少了线程的数量，降低了内存的消耗且减少了上下文切换的次数，很舒服。

想必到此你已经理解了什么叫 I/O 多路复用。

所谓的多路指的是多条连接，复用指的是用一个线程就可以监控这么多条连接。

看到这，你再想想，还有什么地方可以优化的？

4.信号驱动式I/O

上面的 select 虽然不阻塞了，但是他得时刻去查询看看是否有数据已经准备就绪，那是不是可以让内核告诉我们数据到了而不是我们去轮询呢？

信号驱动 I/O 就能实现这个功能，由内核告知数据已准备就绪，然后用户线程再去 read（还是会阻塞）。

听起来是不是比 I/O 多路复用好呀？那为什么好像很少听到信号驱动 I/O？

为什么市面上用的都是 I/O 多路复用而不是信号驱动?

因为我们的应用通常用的都是 TCP 协议，而 TCP 协议的 socket 可以产生信号事件有七种。

也就是说不仅仅只有数据准备就绪才会发信号，其他事件也会发信号，而这个信号又是同一个信号，所以我们的应用程序无从区分到底是什么事件产生的这个信号。

那就麻了呀！

所以我们的应用基本上用不了信号驱动 I/O，但如果你的应用程序用的是 UDP 协议，那是可以的，因为 UDP 没这么多事件。

因此，这么一看对我们而言信号驱动 I/O 也不太行。

5.异步 I/O

信号驱动 I/O 虽然对 TCP 不太友好，但是这个思路对的：往异步发展，但是它并没有完全异步，因为其后面那段 read 还是会阻塞用户线程，所以它算是半异步。

因此，我们得想下如何弄成全异步的，也就是把 read 那步阻塞也省了。

其实思路很清晰：让内核直接把数据拷贝到用户空间之后再告知用户线程，来实现真正的非阻塞I/O！

所以异步 I/O 其实就是用户线程调用 aio_read ，然后包括将数据从内核拷贝到用户空间那步，所有操作都由内核完成，当内核操作完毕之后，再调用之前设置的回调，此时用户线程就拿着已经拷贝到用户控件的数据可以继续执行后续操作。

在整个过程中，用户线程没有任何阻塞点，这才是真正的非阻塞I/O。

那么问题又来了:

为什么常用的还是I/O多路复用，而不是异步I/O？

因为 Linux 对异步 I/O 的支持不足，你可以认为还未完全实现，所以用不了异步 I/O。

这里可能有人会说不对呀，像 Tomcat 都实现了 AIO的实现类，其实像这些组件或者你使用的一些类库看起来支持了 AIO(异步I/O)，实际上底层实现是用 epoll 模拟实现的。

而 Windows 是实现了真正的 AIO，不过我们的服务器一般都是部署在 Linux 上的，所以主流还是 I/O 多路复用。

（五）同步和异步的区别？

同步和异步指的是：当前线程是否需要等待方法调用执行完毕。

比如你调用一个搬运一百块石头的方法：

• 同步指的是调用这个方法，你的线程需要等待这一百块石头搬完，然后得到搬完了的结果，接着再继续执行剩下的代码逻辑。

//同步方式

result = 搬一百块石头();
//需等待搬完的结果，才能执行下面的逻辑
if(result) {
石头搬完了发工资();
}
计算下一次搬石头的任务()；

• 异步指的是调用这个方法，立马就直接返回，不必等候这一百块石头还未搬完，可以立马执行后面的代码逻辑，然后利用回调或者事件通知的方式得到石头已经搬完的结果。

//异步方式

搬一百块石头({
    //回调
    石头搬完了发工资();
});
//不必等待石头搬完，立马执行下面的逻辑
计算下一次搬石头的任务()；

可以很直观的看出，同步和异步就是调用方式的不同，这使得我们的编码方式也有所不同。

在异步调用下的代码逻辑相对而言不太直观，需要借助回调或事件通知，这在复杂逻辑下对编码能力的要求较高。而同步调用就是直来直去，等待执行完毕然后拿到结果紧接着执行下面的逻辑，对编码能力的要求较低，也更不容易出错。

所以你会发现有很多方法它是异步调用的方式，但是最终的使用还是异步转同步。

比如你向线程池提交一个任务，得到一个 future，此时是异步的，然后你在紧接着在代码里调用 future.get()，那就变成等待这个任务执行完成，这就是所谓的异步转同步，像 Dubbo RPC 调用同步得到返回结果就是这样实现的。

（六）阻塞和非阻塞的区别？

阻塞和非阻塞指的是：当前接口数据还未准备就绪时，线程是否被阻塞挂起。

何为阻塞挂起？就是当前线程还处于 CPU 时间片当中，调用了阻塞的方法，由于数据未准备就绪，则时间片还未到就让出 CPU。

所以阻塞和同步看起来都是等，但是本质上它们不一样，同步的时候可没有让出 CPU。

而非阻塞就是当前接口数据还未准备就绪时，线程不会被阻塞挂起，可以不断轮询请求接口，看看数据是否已经准备就绪。

至此我们可以得到一个结论：

• 同步&异步指：当数据还未处理完成时，代码的逻辑处理方式不同。
• 阻塞&非阻塞指：当数据还未处理完成时(未就绪)，线程的状态。

所以同步&异步其实是处于框架这种高层次维度来看待的，而阻塞&非阻塞往往针对底层的系统调用方面来抉择，也就是说两者是从不同维度来考虑的。

（七）同步、异步、阻塞、非阻塞的I/O的区别？

前提：程序和硬件之间隔了个操作系统，而为了安全考虑，Linux 系统分了：用户态和内核态

在这个前提下，我们再明确 I/O 操作有两个步骤：

1. 发起 I/O 请求
2. 实际 I/O 读写，即数据从内核缓存拷贝到用户空间

阻塞 I/O 和非阻塞 I/O。按照上文，其实指的就是用户线程是否被阻塞，这里指代的步骤1（发起I/O请求）。

• 阻塞 I/O，指用户线程发起 I/O 请求的时候，如果数据还未准备就绪（例如暂无网络数据接收），就会阻塞当前线程，让出 CPU。
• 非阻塞 I/O，指用户线程发起 I/O 请求的时候，如果数据还未准备就绪（例如暂无网络数据接收），也不会阻塞当前线程，可以继续执行后续的任务。

可以发现，这里的阻塞和非阻塞其实是指用户线程是否会被阻塞。

同步 I/O 和异步 I/O。按照上文，我们可以得知这就是根据 I/O 响应方式不同而划分的。

• 同步 I/O，指用户线程发起 I/O 请求的时候，数据是有的，那么将进行步骤2（实际 I/O 读写，即数据从内核缓存拷贝到用户空间），这个过程用户线程是要等待着拷贝完成。
• 异步 I/O，指用户线程发起 I/O 请求的时候，数据是有的，那么将进行步骤2（实际 I/O 读写，即数据从内核缓存拷贝到用户空间），拷贝的过程中不需要用户线程等待，用户线程可以去执行其它逻辑，等内核将数据从内核空间拷贝到用户空间后，用户线程会得到一个“通知”。

再仔细思考下，在 I/O 场景下同步和异步说的其实是内核的实现，因为拷贝的执行者是内核，一种是同步将数据拷贝到用户空间，用户线程是需要等着的。一个是通过异步的方式，用户线程不用等，在拷贝完之后，内核会调用指定的回调函数。

如果不理解上面，就只需记住：

• 同步I/O：指的是用户线程会需要等待步骤 2 执行完毕。
• 异步I/O：指的是用户线程不需要等待步骤 2 执行。

好了，如果以上的概念你都已经理解了的话，那么平日里我们所说的同步阻塞I/O，同步非阻塞I/O等其实就是把上面的两个步骤合起来看，应该不难理解。

我再简单的总结一下，关于 I/O 的阻塞、非阻塞、同步、异步：

• 阻塞和非阻塞指的是发起 I/O 请求后，用户线程状态的不同，阻塞I/O在数据未准备就绪的时候会阻塞当前用户线程，而非阻塞 I/O 会立马返回一个错误，不会阻塞当前用户线程。
• 同步和异步是指，内核的 I/O 拷贝实现，当数据准备就绪后，需要将内核空间的数据拷贝至用户空间，如果是同步 I/O 那么用户线程会等待拷贝的完成，而异步 I/O则这个拷贝过程用户线程该干嘛可以去干吗，当内核拷贝完毕之后会“通知”用户线程。

要注意，不同场景下同一个名词意义可能不同。我这篇关于同步、异步、阻塞、非阻塞这几个概念是基于 I/O 场景下讲的。