操作系统(五)网络 I/O

2024 年 7 月 23 日 星期二
/
40
1

操作系统(五)网络 I/O

Linux五种IO模型

  • 阻塞I/O: 这是最常见的I/O模型。在此模式中,当应用程序执行I/O操作时,如果数据还没有准备好,应用程序就会被阻塞(挂起),直到数据准备好为止。这期间,应用程序不能做其他事情。
  • 非阻塞I/O:在此模式中,如果I/O操作的数据还没有准备好,操作会立即返回一个错误,而不是阻塞应用程序。应用程序可以继续执行其他操作,也可以反复尝试该I/O操作。
  • I/O多路复用:也常称为事件驱动I/O。在此模式中,应用程序可以同时监控多个I/O描述符(比如,socket),当任何一个I/O描述符准备好数据时,应用程序就可以对其进行处理。这可以在一个单独的进程或线程中同时处理多个I/O操作,并且不需要阻塞或轮询。select、poll、epoll都是这种模型的实现。
  • 信号驱动:在此模型中,应用程序可以向操作系统注册一个信号处理函数,当数据准备好时,操作系统会发送一个信号,应用程序可以在接收到信号时读取数据。这种模式避免了阻塞和轮询,但是编程复杂性较高。
  • 异步I/O:在此模型中,应用程序发起I/O操作后,可以立即开始做其他事情,当数据准备好时,操作系统会将数据复制到应用程序的缓冲区,并通知应用程序。这种模型的优点是应用程序不需要等待I/O操作的完成,缺点是编程复杂性较高。

5 种 I/O 模型主要是阻塞 I/O、非阻塞 I/O、信号驱动式 I/O、I/O 多路复用、异步 I/O,其中前四个都属于同步I/O模型。

阻塞同步I/O模型和非阻塞同步I/O模型的区别在于:进程发起系统调用后,是会被挂起直到收到数据后在返回、还是立即返回成功或错误。

同步I/O 和异步I/O 的区别在于:将数据从内核复制到用户空间时,用户进程是否会阻塞,如果用户进程会阻塞,则是同步I/O,如果不会阻塞就是异步 I/O。

阻塞IO和非阻塞IO的应用场景问题,有一个计算密集型的场景,和一个给用户传视频的场景,分别应该用什么io?

计算密集型的场景,需要消耗的是 CPU 资源,用阻塞 IO 会比较好,如果用非阻塞 IO,在非阻塞IO模型中,用户线程需要不断地询问内核数据是否就绪,也就说非阻塞IO不会交出CPU,而会一直占用CPU。

用户传视频的场景,瓶颈不是 CPU 资源,用非阻塞 IO 比较好,使用非阻塞IO可以避免阻塞在传输函数上,提高程序的并发性和响应时间。

谈谈你对 I/O 多路复用的理解

如果不使用 I/O 多路复用,服务端要并发处理多个客户端的 I/O 事件的话,需要通过创建子进程或者线程的方式来实现,也就是针对每一个连接的 I/O 事件要需要一个子进程或者线程来处理,但是随着客户端越来越多,意味着服务端需要创建更多的子进程或者线程,这样对系统的开销太大了。

那么有了 I/O 多路复用就可以解决这个问题,I/O 多路复用可以实现是多个I/O复用一个进程,也就是只需要一个进程就能并发处理多个客户端的 I/O 事件, 进程可以通过select、poll、epoll这类 I/O 多路复用系统调用接口从内核中获取有事件发生的 socket 集合,然后应用程序就可以遍历这个集合,对每一个 socket 事件进行处理。

Redis 单线程也能做到高性能的原因,也跟 I/O 多路复用有关系。

select、poll、epoll 有什么区别?

select 和 poll 内部都是使用「线性结构」来存储进程关注的 Socket 集合,在使用的时候,首先需要把关注的 Socket 集合通过 select/poll 系统调用从用户态拷贝到内核态,然后由内核检测事件,当有网络事件产生时,内核需要遍历进程关注 Socket 集合,找到对应的 Socket,并设置其状态为可读/可写,然后把整个 Socket 集合从内核态拷贝到用户态,用户态还要继续遍历整个 Socket 集合找到可读/可写的 Socket,然后对其处理。 很明显发现,select 和 poll 的缺陷在于,当客户端越多,也就是 Socket 集合越大,Socket 集合的遍历和拷贝会带来很大的开销,epoll 通过两个方面解决了 select/poll 的问题。

epoll 在内核里使用「红黑树」来关注进程所有待检测的 Socket,通过 epoll_ctl() 函数加入内核中的红黑树里,红黑树是个高效的数据结构,增删改一般时间复杂度是 O(logn),通过对这棵黑红树的管理,不需要像 select/poll 在每次操作时都传入整个 Socket 集合,只需要传入一个待检测的 socket,减少了内核和用户空间大量的数据拷贝和内存分配。

epoll 使用事件驱动的机制,内核里维护了一个链表来记录就绪事件,当某个 socket 有事件发生时,通过回调函数内核会将其加入到这个就绪事件列表中,当用户调用 epoll_wait()函数时,只会返回有事件发生的文件描述符链表表,不需要像 select/poll 那样轮询扫描整个 socket 集合,大大提高了检测的效率。

select、poll、epoll 适合哪些应用场景?

在连接数较少并且都十分活跃的情况下,选择 select 或者 poll 会比 epoll 性能好,因为 epoll 中的所有描述符都存储在内核中,必须使用epoll_ctl来添加到内核的红黑树中,这就意味着每一个新的连接都需要两次系统调用(epoll_ctl+epoll_wait),而在select 和poll中只需要一次,频繁系统调用降低效率。

在连接数较多并且有很多的不活跃连接时,epoll 会比 select 和 poll 性能好,因为 epoll 在内核用红黑树来关注所有待检测的 socket,不需要像 select/poll 在每次操作时都传入整个 Socket 集合,减少了内核和用户空间大量的数据拷贝和内存分配,再加上 epoll 有就绪队列,也不需要像 select/poll 那样轮询扫描整个集合(包含有和无事件的 Socket ),大大提高了检测的效率。

epoll ET 模式和 LT 模式有什么区别?哪一个更高效?

ET 模式和 LT 模式 区别如下:

  • 边缘触发(ET,Edge Trigger):当描述符从未就绪变为就绪时,只会通知一次,之后不会再通知,因此我们程序要保证一次性将事件处理完。
  • 水平触发(LT,Level Trigger):当文件描述符就绪时,会触发通知,如果用户程序没有一次性把数据读/写完,下次还会发出可读/可写信号进行通知。

    边缘触发的效率比水平触发的效率要高,因为边缘触发可以减少 epoll_wait 的系统调用次数。

零拷贝技术了解过吗?说一下原理

传统文件传输

  • 共发生了 4 次用户态与内核态的上下文切换,因为发生了两次系统调用,一次是 read() ,一次是 write(),每次系统调用都得先从用户态切换到内核态,等内核完成任务后,再从内核态切换回用户态。
  • 其次,还发生了 4 次数据拷贝,其中两次是 DMA 的拷贝,另外两次则是通过 CPU 拷贝的。

sendfile

#include <sys/socket.h> 
ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count);

它的前两个参数分别是目的端和源端的文件描述符,后面两个参数是源端的偏移量和复制数据的长度,返回值是实际复制数据的长度。

  • 首先,它可以替代前面的 read() 和 write() 这两个系统调用,这样就可以减少一次系统调用,也就减少了 2 次上下文切换的开销。
  • 其次,该系统调用,可以直接把内核缓冲区里的数据拷贝到 socket 缓冲区里,不再拷贝到用户态,这样就只有 2 次上下文切换,和 3 次数据拷贝

零拷贝

对于支持网卡支持 SG-DMA 技术的情况下, sendfile()系统调用的过程发生了点变化,具体过程如下:

  • 第一步,通过 DMA 将磁盘上的数据拷贝到内核缓冲区里;
  • 第二步,缓冲区描述符和数据长度传到 socket 缓冲区,这样网卡的 SG-DMA 控制器就可以直接将内核缓存中的数据拷贝到网卡的缓冲区里,此过程不需要将数据从操作系统内核缓冲区拷贝到 socket 缓冲区中,这样就减少了一次数据拷贝,这个过程之中,只进行了 2 次数据拷贝;

这就是所谓的零拷贝(Zero-copy)技术,因为我们没有在内存层面去拷贝数据,也就是说全程没有通过 CPU 来搬运数据,所有的数据都是通过 DMA 来进行传输的。

零拷贝技术的文件传输方式相比传统文件传输的方式,减少了 2 次上下文切换和数据拷贝次数,只需要 2 次上下文切换和数据拷贝次数,就可以完成文件的传输,而且 2 次的数据拷贝过程,都不需要通过 CPU,2 次都是由 DMA 来搬运。

所以零拷贝技术主要是为了提升文件传输的效率,Kafka 消息队列 I/O 的吞吐量高的原因,也是因为使用了零拷贝技术。

传统文件传输

传统文件传输
senfile-3次拷贝

senfile-3次拷贝
senfile-零拷贝

senfile-零拷贝

reactor 模式有哪些方案?

常见的 Reactor 实现方案有三种。

第一种方案单 Reactor 单进程 / 线程,不用考虑进程间通信以及数据同步的问题,因此实现起来比较简单,这种方案的缺陷在于无法充分利用多核 CPU,而且处理业务逻辑的时间不能太长,否则会延迟响应,所以不适用于计算机密集型的场景,适用于业务处理快速的场景,比如 Redis(6.0之前 ) 采用的是单 Reactor 单进程的方案。

第二种方案单 Reactor 多线程,通过多线程的方式解决了方案一的缺陷,但它离高并发还差一点距离,差在只有一个 Reactor 对象来承担所有事件的监听和响应,而且只在主线程中运行,在面对瞬间高并发的场景时,容易成为性能的瓶颈的地方。

第三种方案多 Reactor 多进程 / 线程,通过多个 Reactor 来解决了方案二的缺陷,主 Reactor 只负责监听事件,响应事件的工作交给了从 Reactor,Netty 和 Memcache 都采用了「多 Reactor 多线程」的方案,Nginx 则采用了类似于 「多 Reactor 多进程」的方案。

proactor 和 reactor 模式有什么区别?

  • Reactor 是非阻塞同步网络模式,感知的是就绪可读写事件。在每次感知到有事件发生(比如可读就绪事件)后,就需要应用进程主动调用 read 方法来完成数据的读取,也就是要应用进程主动将 socket 接收缓存中的数据读到应用进程内存中,这个过程是同步的,读取完数据后应用进程才能处理数据。
  • Proactor 是异步网络模式, 感知的是已完成的读写事件。在发起异步读写请求时,需要传入数据缓冲区的地址(用来存放结果数据)等信息,这样系统内核才可以自动帮我们把数据的读写工作完成,这里的读写工作全程由操作系统来做,并不需要像 Reactor 那样还需要应用进程主动发起 read/write 来读写数据,操作系统完成读写工作后,就会通知应用进程直接处理数据。

因此,Reactor 可以理解为「来了事件操作系统通知应用进程,让应用进程来处理」,而 Proactor 可以理解为「来了事件操作系统来处理,处理完再通知应用进程」

参考:

https://xiaolincoding.com/os/

使用社交账号登录

  • Loading...
  • Loading...
  • Loading...
  • Loading...
  • Loading...