深刻理解select、poll、epoll

看了这篇文章：https://blog.csdn.net/weixin_47282449/article/details/122463764?spm=1001.2014.3001.5502，对网络io又有了更深的了解，做一下个人总结。

网络数据接收过程

这个是直接拷贝过来的图。总结一下：

1. 网络数据首先达到网卡设备
2. 网卡设备使用硬件DMA把网络数据拷贝到一个环形缓冲区
3. 数据拷贝完成之后使用硬中断通知内核
4. 内核把步骤1中的环形缓冲区数据拷贝到一个叫sk_buff的缓冲区中
5. 然后使用一些列的内核协议从数据中提取出tcp层的荷载数据
6. 把荷载数据拷贝到对应socket中存放数据的队列中
7. socket种还有一个等待队列，里边存的是调用当前socket被阻塞的线程，这个时候有数据来了应该要把他们唤醒
8. 被唤醒的线程把数据从socket队列(在内核空间)中拷贝到用户空间中(应该是进程的堆空间，这个堆不是jvm的堆)
9. 被唤醒的线程此时还处于内核态，要切换回用户态，然后就可以去用户空间读取刚才拷贝的数据了

上述步骤中的内核应该指的是一种直属于操作系统的进程(或线程)，与我们应用中的用户线程或者内核线程应该不是一个东西。

再来看看各种网络模型（以读取数据为例）

1.阻塞io

传统的阻塞io，因为我们也不知道对方什么时候会发送数据过来，当我们要读取数据的时候调用read()，如果还没有收到数据就只能阻塞住等待了，为了能同时服务多个用户，就要用多个线程去服务每个用户的网络连接，这会有什么问题就不多说了。

2.非阻塞io

非阻塞io和阻塞io的区别在调用read()的时候，如果没有数据发送过来，不会傻乎乎的阻塞等待了，而是直接返回一个常量值，告诉程序这个socket当前没有数据可读。要想不错过这个socket的消息，我们就只能不断的轮询调用read()直到读到数据未知，那这样似乎还不如阻塞io呢，其实我们可以用一个线程去轮询多个socket，这样可以解决阻塞io的线程数量问题。但是这样还会遇到新的问题，因为每次调用read()的时候都要切换到内核态，而且我们是轮询操作，效率肯定不是很好。

3.select、poll

遇到非阻塞io的这种问题，类比一下我们写业务代码的时候，要查询id等于一个list的时候，如果每次就查询一个id，然后轮询整个list，这样的效率肯定没有直接使用in list的效率高。既然我们要轮询一组socket和这个业务场景非常相似，我们也可以用类似的方法来优化，当然这也离不开操作系统的支持，就像数据库不支持in的语法我们也没办法一样。

select和poll就是使用了类似的方法，使用操作系统提供的函数，一次性传入多个socket，只使用一次系统调用就可以检查多个socket是否有数据可读。select和poll的做法是在传入的socket列表中，对有数据可读的socket进行标记，然后返回标记过的列表给应用程序，应用程序再去便利这个列表找出有数据可读的socket，后续的步骤和前边的都一样。

select和poll区别在于，select传入的socket列表是固定大小，好像是1024，而poll是一个可以扩增的列表。

但是不管是select还是poll，都存在的问题是在调用系统函数的时候，会传输整个socket列表，这是一个系统调用，会把整个列表拷贝到内核空间中，而且每次返回也会把内核空间的数据拷贝到用户空间。返回的整个列表我们还要在用户态去遍历找到有数据的socket，时间复杂度是O(n)，还有一点是系统函数去判断socket上是否有数据可读的时候，也是一个一个去遍历，只是减少了用户态和内核态的切换次数，本质和非阻塞io的方式什么区别。

4.epoll

epoll虽然和poll只多了一个字母，但是他们的架构完全不同。操作系统提供一个epoll对象：

struct eventpoll {
 
    //等待队列，阻塞在epoll上的进程会放在这里
    wait_queue_head_t wq;
 
    //就绪队列，IO就绪的socket连接会放在这里
    struct list_head rdllist;
 
    //红黑树用来管理所有监听的socket连接
    struct rb_root rbr;
 
    ......
}

还有一个epoll_wait()的方法，调用的时候会返回就绪队列，就绪队列没有的时候会阻塞住。
每创建一个socket的时候，就把它交给epoll管理，当socket上有数据到达的时候，在前边介绍的会去唤醒阻塞在这个socket上的线程，而在这个时候socket是去调用epoll的函数，把这个socket放到就绪队列中，同时去唤醒阻塞在epoll上的线程。
这样全都是socket有数据到达的时候才会去执行业务代码，而不是我们的线程去一次又一次的轮询询问是否有数据到达，也解决了select、poll的问题。

个人思考

我们看到网络io数据接收的时候，会有很多次的数据拷贝，其中损耗最大我感觉应该是在socket数据队列拷贝至用户空间这一步，如果能直接第6步中把数据拷贝到socket队列改为拷贝到socket对应的进程的堆空间是不是好一些？首先根据socket是可以定位到对应的进程空间，而且也不会存在其他进程访问这个socket的可能，其次如果把数据直接拷贝到用户态空间，一些socket的系统调用也可以不用进行用户态到内核态的切换，不过这样可能会让用户态拥有了之前没有的权限。以上仅是个人思考，如有想法可以留言讨论。