Linux内核（七）轮询 *** 作

在用户程序中，select()和poll()也是与设备阻塞和非阻塞访问相关的内容。

使用非阻塞IO的应用程序通常会使用select()和poll()系统调用查询是否可以对设备进行无阻塞的访问。

select()和poll()系统调用最终会使设备驱动中的poll()函数执行，在后续的Linux内核版本中还引入了epoll(),即扩展的poll()。

select()和poll()系统调用的本质是一样的，前者在BSD Unix中引入，后者在System V中引入。

应用程序中使用最广泛的是BSD Unix中引入的select()系统调用，原型如下：

如下图所示，

第一次对n个文件进行select()的时候，若任何一个文件满足要求，select()就直接返回；

第二次再进行select()的时候，没有文件满足读写要求，select()的进程阻塞且睡眠。

由于调用select()的时候，每个驱动的poll()接口都会被调用到。实际上执行select()的进程被挂到了每个驱动的等待队列上，可以被任何一个驱动唤醒。如果FDn变得可读写，select()返回。

poll()的功能和实现原理与select()类似，其原型函数为：

当多路复用的文件数量庞大、IO流量频繁的时候，一般不太适合使用select()和poll()，这种情况下select()和poll()表现较差，推荐使用epoll()。

使用epoll()最大的好处就是不会随着fd数目的增长而降低效率，select()则会随着fd数量增大性能明显下降。

相关接口：

创建一个epoll()的句柄，size用来告诉内核要监听多少个fd，当创建好epoll()句柄时，它本身也会占用一个fd值，所以在使用完epoll()后，必须调用close()关闭。

告诉内核要监听什么类型的事件：

第一个参数epfd是epoll_create()的返回值，

第二个参数表示动作，包含：

第3个参数是需要监听的fd，

第4个参数是告诉内核需要监听的事件类型，struct_epoll_event结构如下：

events可以是以下几个宏的”或“：

一般来说，当涉及的fd数量较少时，使用select是合适的；如果涉及的fd很多，如在大规模并发的服务器中监听许多socket的时候，则不太适合选用select，适合使用epoll。

用浅显的话来说吧。

在一般的情况下，在系统和应用程序之间有一个请求队列层，起到调度的作用，应用程序不会直接访问系统，而是把访问请求放进队列层中；而系统也在不停的从队列层中提取请求然后不断的分发执行，这种请求方式就是阻塞式访问。

但是有些特殊的请求是不允许停止和等待的，这种请求就不会被放入队列层中，而是直接插入到系统的当前处理的前端，而被优先执行，这种请求方式就是非阻塞式访问。

这二者的区别是由于其工作性质决定的，单纯从理论角度来说，与CPU占用等没有任何关系，CPU占用只和和算法复杂度有关。

一般非阻塞功能都是使用在系统级的请求上，比如某些驱动级的中断请求或实时类请求，因为绕过了请求队列，编制不良的非阻塞程序可能会导致系统失去响应。

一个报文的产生和发送，都需要硬件和软件的完美配合。

硬件层面接收到报文之后，做一系列的初始化 *** 作，之后驱动才开始把一个封包封装为skb。

当然这是在x86架构下，如果是在cavium架构下，封包是wqe形式存在。

不管是skb还是wqe，都仅仅是一种手段，一种达到完成报文传输所采用的一种解决方案，一种方法而已。

或许处理方案的具体实现细节差别万千，但是基本的原理，都是殊途同归，万变不离其宗。

skb的产生，让Linux协议栈旅程的开启，具备了最基本的条件，接下来的协议栈之旅，才会更加精彩。

写作本文的原因是现在本机网络 IO 应用非常广。

在 php 中 一般 nginx 和 php-fpm 是通过 127.0.0.1 来进行通信的；

在微服务中，由于 side car 模式的应用，本机网络请求更是越来越多。

所以，如果能深度理解这个问题在各种网络通信应用的技术实践中将非常的有意义。

今天咱们就把 127.0.0.1 本机网络通信相关问题搞搞清楚！

为了方便讨论，我把这个问题拆分成3问：

1）127.0.0.1 本机网络 IO 需要经过网卡吗？

2）和外网网络通信相比，在内核收发流程上有啥差别？

3）使用 127.0.0.1 能比 192.168.x.x 更快吗？

在上面这幅图中，我们看到用户数据被拷贝到内核态，然后经过协议栈处理后进入到了 RingBuffer 中。随后网卡驱动真正将数据发送了出去。当发送完成的时候，是通过硬中断来通知 CPU，然后清理 RingBuffer。

当数据包到达另外一台机器的时候，Linux 数据包的接收过程开始了。

当网卡收到数据以后，CPU发起一个中断，以通知 CPU 有数据到达。

当CPU收到中断请求后，会去调用网络驱动注册的中断处理函数，触发软中断。

ksoftirqd 检测到有软中断请求到达，开始轮询收包，收到后交由各级协议栈处理。

当协议栈处理完并把数据放到接收队列的之后，唤醒用户进程（假设是阻塞方式）。

关于跨机网络通信的理解，可以通俗地用下面这张图来总结一下：

前面，我们看到了跨机时整个网络数据的发送过程 。

在本机网络 IO 的过程中，流程会有一些差别。

为了突出重点，本节将不再介绍整体流程，而是只介绍和跨机逻辑不同的地方。

有差异的地方总共有两个，分别是路由和驱动程序。

对于本机网络 IO 来说，特殊之处在于在 local 路由表中就能找到路由项，对应的设备都将使用 loopback 网卡，也就是我们常见的 lO。

从上述结果可以看出，对于目的是 127.0.0.1 的路由在 local 路由表中就能够找到了。

对于是本机的网络请求，设备将全部都使用 lo 虚拟网卡，接下来的网络层仍然和跨机网络 IO 一样。

本机网络 IO 需要进行 IP 分片吗？

因为和正常的网络层处理过程一样，如果 skb 大于 MTU 的话，仍然会进行分片。

只不过 lo 的 MTU 比 Ethernet 要大很多。

通过 ifconfig 命令就可以查到，普通网卡一般为 1500，而 lO 虚拟接口能有 65535。

为什么我把“驱动”加个引号呢，因为 loopback 是一个纯软件性质的虚拟接口，并没有真正意义上的驱动。

在邻居子系统函数中经过处理，进入到网络设备子系统，只有触发完软中断，发送过程就算是完成了。

在跨机的网络包的接收过程中，需要经过硬中断，然后才能触发软中断。

而在本机的网络 IO 过程中，由于并不真的过网卡，所以网卡实际传输，硬中断就都省去了。直接从软中断开始，送进协议栈。

网络再往后依次是传输层，最后唤醒用户进程，这里就不多展开了。

我们来总结一下本机网络通信的内核执行流程：

回想下跨机网络 IO 的流程：

通过本文的叙述，我们确定地得出结论，不需要经过网卡。即使了把网卡拔了本机网络是否还可以正常使用的。

总的来说，本机网络 IO 和跨机 IO 比较起来，确实是节约了一些开销。发送数据不需要进 RingBuffer 的驱动队列，直接把 skb 传给接收协议栈（经过软中断）。

但是在内核其它组件上可是一点都没少：系统调用、协议栈（传输层、网络层等）、网络设备子系统、邻居子系统整个走了一个遍。连“驱动”程序都走了（虽然对于回环设备来说只是一个纯软件的虚拟出来的东东）。所以即使是本机网络 IO，也别误以为没啥开销。

先说结论：我认为这两种使用方法在性能上没有啥差别。

我觉得有相当大一部分人都会认为访问本机server 的话，用 127.0.0.1 更快。原因是直觉上认为访问 IP 就会经过网卡。

其实内核知道本机上所有的 IP，只要发现目的地址是本机 IP 就可以全走 loopback 回环设备了。

本机其它 IP 和 127.0.0.1 一样，也是不用过物理网卡的，所以访问它们性能开销基本一样！

How SKBs work - Linux kernel

http://vger.kernel.org/~davem/skb.html

一篇解读Linux网络协议栈

https://zhuanlan.zhihu.com/p/475319464

你真的了解127.0.0.1和0.0.0.0的区别？

http://www.52im.net/thread-2928-1-1.html

深入 *** 作系统，彻底搞懂127.0.0.1本机网络通信

http://www.52im.net/thread-3590-1-1.html

---