tp框架做餐饮网站,快速建站教程网,设计师免费资源导航,百度关键词价格文章目录 1.从一个问题说起2.多进程模型3.多线程模型4.I/O 多路复用5.select、poll、epoll 的区别#xff1f;5.1 select5.2 poll5.3 epoll5.4 两种事件触发模式 参考文献 1.从一个问题说起
互联网发展历史上#xff0c;曾经有一个著名的问题#xff1a;C10K 问题。
C 是 … 文章目录 1.从一个问题说起2.多进程模型3.多线程模型4.I/O 多路复用5.select、poll、epoll 的区别5.1 select5.2 poll5.3 epoll5.4 两种事件触发模式 参考文献 1.从一个问题说起
互联网发展历史上曾经有一个著名的问题C10K 问题。
C 是 Client 单词首字母缩写10K 指 1 万C10K 指单机同时处理 1 万个并发连接问题。
C10K 问题最早是在 1999 年由 Dan Kegel 提出并发布于其个人站点 http://www.kegel.com/c10k.html 。
C10K 问题是一个优化网络套接字以同时处理大量客户端连接的问题。注意这里的并发连接和每秒请求数不同虽然它们是相似的 每秒处理许多请求需要很高的吞吐量快速处理它们但是更大的并发连接数需要高效的连接调度。
为了解决该问题研究方向首先是网络 IO 模型的优化具体的思路就是通过单个进程或线程服务于多个客户端请求通过异步编程和事件触发机制替换轮询IO 采用非阻塞的方式减少不必要的性能损耗等等。
现在已经解决了 C10K 的问题。 epoll、kqueue、iocp 就是 IO 模型优化的一些最佳实践这几种技术实现分别对应于不同的系统平台。
epoll 主要用于 Linux 系统。使用一个文件描述符管理多个文件描述符的 I/O 事件。提供水平触发Level Triggered和边缘触发Edge Triggered两种模式。
kqueue 主要用于 BSD 系统如 FreeBSD、OpenBSD 和 macOS。使用一个内核事件队列管理多个文件描述符的 I/O 事件。支持水平触发和边缘触发也支持过滤器Filter概念可以监控多种类型的事件。
iocp (Input/Output Completion Port) 主要用于 Windows 系统。使用 I/O 完成端口来实现异步 I/O 多路复用。异步 I/O 模型采用回调方式支持 OVERLAPPED 结构体。
2.多进程模型
如果服务器要支持多个客户端连接其中比较传统的方式就是使用多进程模型也就是为每个客户端分配一个进程来处理请求。
服务器的主进程负责监听客户的连接一旦与客户端连接完成accept() 函数就会返回一个「已连接 Socket」这时就通过 fork() 函数创建一个子进程实际上把父进程所有相关的东西都复制一份包括文件描述符、内存地址空间、程序计数器、执行的代码等。
这两个进程刚复制完的时候几乎一摸一样。不过会根据返回值来区分是父进程还是子进程如果 fork() 返回值是 0则是子进程如果返回值是其他的整数则是父进程。
正因为子进程会复制父进程的文件描述符于是就可以直接使用「已连接 Socket 」和客户端通信了可以发现子进程不需要关心「监听 Socket」只需要关心「已连接 Socket」父进程则相反将客户服务交给子进程来处理因此父进程不需要关心「已连接 Socket」只需要关心「监听 Socket」。
下面这张图描述了从连接请求到连接建立父进程创建生子进程为客户服务。 另外当「子进程」退出时实际上内核里还会保留该进程的一些信息也会占用内存如果不做好“回收”工作就会变成僵尸进程。随着僵尸进程越多会慢慢耗尽系统资源。
因此父进程要“善后”自己的孩子怎么善后呢那么有两种方式可以在子进程退出后回收资源分别是调用 wait() 和 waitpid() 函数。
这种用多个进程来应付多个客户端的方式在应对 100 个客户端还是可行的但是当客户端数量高达一万时肯定扛不住的因为每产生一个进程必会占据一定的系统资源而且进程间上下文切换的“包袱”是很重的性能会大打折扣。
进程的上下文切换涉及到保存和恢复大量的状态信息不仅包含了虚拟内存、栈、全局变量等用户空间的资源还包括了内核堆栈、寄存器等内核空间的资源。
3.多线程模型
既然进程间上下文切换的“包袱”很重那我们就搞个比较轻量级的模型来应对多用户的请求 —— 多线程模型。
线程是运行在进程中的一个“逻辑流”单进程中可以运行多个线程同一个进程里的线程可以共享进程的部分资源比如地址空间代码段、数据段和堆等、文件描述符列表、共享库等这些共享些资源在上下文切换时是不需要切换而只需要切换线程的私有数据比如寄存器、栈等不共享的数据因此同一个进程下的线程上下文切换的开销要比进程小得多。
当服务器与客户端 TCP 完成连接后通过 pthread_create() 函数创建线程然后将「已连接 Socket」的文件描述符传递给线程函数接着在线程里和客户端进行通信从而达到并发处理的目的。
如果每来一个连接就创建一个线程线程运行完后还得操作系统销毁线程。虽说线程切换的上写文开销不大但是如果频繁创建和销毁线程系统开销也是不小的。
那么我们可以使用线程池的方式来避免线程的频繁创建和销毁。所谓的线程池就是提前创建若干个线程这样当由新连接建立时将这个已连接的 Socket 放入到一个队列里然后线程池里的线程负责从队列中取出已连接 Socket 进行处理。 需要注意的是这个队列是全局的每个线程都会操作为了避免多线程竞争线程在操作这个队列前要加锁。
上面基于进程或者线程模型的其实还是有问题的。新到来一个 TCP 连接就需要分配一个进程或者线程那么如果要达到 C10K意味着要一台机器维护 1 万个连接相当于要维护 1 万个进程/线程操作系统就算死扛也是扛不住的。
4.I/O 多路复用
既然为每个请求分配一个进程/线程的方式不合适那有没有可能只使用一个进程来维护多个 Socket 呢
答案是有的那就是 I/O 多路复用技术。
I/O 多路复用是通过一种机制通常是系统调用同时监视多个文件描述符sockets、文件、设备等的技术。它允许单个进程能够管理多个 I/O 操作而不必为每个 I/O 操作创建一个单独的线程或进程。
I/O 多路复用的 “多路” 指的是多个 I/O 操作通常是多个文件描述符复用指使用一个进程来处理多个 I/O 操作。 Linux 下有三种提供 I/O 多路复用的 API分别是 select、poll、epoll。
5.select、poll、epoll 的区别
select、poll 和 epoll 都是 Linux 实现 IO 多路复用提供的系统调用都能实现 C10K 吗接下来我们分别说说它们。
5.1 select
IO 多路复用这个概念被提出来以后 select 是第一个实现 1983 左右在 BSD 里面实现。
select 实现多路复用的方式是将已连接的 Socket 都放到一个文件描述符集合然后调用 select 函数将文件描述符集合拷贝到内核里让内核来检查是否有网络事件产生检查的方式很粗暴就是通过遍历文件描述符集合的方式当检查到有事件产生后将此 Socket 标记为可读或可写 接着再把整个文件描述符集合拷贝回用户态里然后用户态还需要再通过遍历的方法找到可读或可写的 Socket然后再对其处理。
所以对于 select 这种方式需要进行 2 次「遍历」文件描述符集合一次是在内核态里一个次是在用户态里 而且还会发生 2 次「拷贝」文件描述符集合先从用户空间传入内核空间由内核修改后再传出到用户空间中。
select 使用固定长度的 BitsMap表示文件描述符集合而且所支持的文件描述符的个数是有限制的在 Linux 系统中由内核中的 FD_SETSIZE 限制 默认最大值为 1024只能监听 0~1023 的文件描述符。
select 被实现以后很快暴露出了很多问题。
select 只能监视 1024 个连接Linux 定义在头文件中的参见 FD_SETSIZE。2 次「遍历」文件描述符集合性能低下。2 次「拷贝」文件描述符集合性能低下。
5.2 poll
因为 select 的诸多问题14 年后1997年一帮人又实现了 poll修复了 select 的很多问题。
比如 poll 不再用 BitsMap 来存储所关注的文件描述符取而代之用动态数组以链表形式来组织突破了 select 的文件描述符个数限制当然还会受到系统文件描述符数量限制。
但是 poll 和 select 并没有太大的本质区别都是使用「线性结构」存储进程关注的 Socket 集合因此都需要遍历文件描述符集合来找到可读或可写的 Socket时间复杂度为 O(n)而且也需要在用户态与内核态之间拷贝文件描述符集合这种方式随着并发数上来性能的损耗会呈指数级增长。
5.3 epoll
于是 5 年以后2002 年, 大神 Davide Libenzi 实现了 epoll。
epoll 可以说是 IO 多路复用最新的一个实现epoll 修复了 poll 和 select 绝大部分问题比如
1高效的数据结构。 epoll 在内核里使用红黑树跟踪进程所有待检测的文件描述符把需要监控的 socket 通过 epoll_ctl() 函数加入内核中的红黑树里红黑树是个高效的数据结构增删查一般时间复杂度是 O(logn)通过对这棵黑红树进行操作这样就不需要像 select/poll 每次操作时都传入整个 socket 集合只需要传入一个待检测的 socket减少了内核和用户空间大量的数据拷贝和内存分配。
2使用事件驱动机制。 内核里维护了一个链表来记录就绪事件当某个 socket 有事件发生时通过回调函数内核会将其加入到这个就绪事件列表中当用户调用 epoll_wait() 函数时只会返回有事件发生的 socket不需要像 select/poll 那样轮询扫描整个 socket 集合大大提高了检测效率。
也就是 epoll 现在不仅告诉你 Socket 组里面数据还会告诉你具体哪个 Socket 有数据不用自己去找了。
从下图你可以看到 epoll 相关的接口作用 epoll 监听的 Socket 数量越多效率不会大幅度降低能够同时监听的 Socket 的数目非常的多上限为系统定义的进程打开的最大文件描述符个数。因而epoll 被称为解决 C10K 问题的利器。
5.4 两种事件触发模式
epoll 支持两种事件触发模式分别是边缘触发edge-triggeredET和水平触发level-triggeredLT。
这两个术语还挺抽象的其实它们的区别还是很好理解的。
使用边缘触发模式时当被监控的 Socket 描述符上有可读事件发生时服务器端只会从 epoll_wait 中苏醒一次即使进程没有调用 read 函数从内核读取数据也依然只苏醒一次因此我们程序要保证一次性将内核缓冲区的数据读取完。使用水平触发模式时当被监控的 Socket 上有可读事件发生时服务器端不断地从 epoll_wait 中苏醒直到内核缓冲区数据被 read 函数读完才结束目的是告诉我们有数据需要读取。
举个例子你的快递被放到了一个快递箱里如果快递箱只会通过短信通知你一次即使你一直没有去取它也不会再发送第二条短信提醒你这个方式就是边缘触发如果快递箱发现你的快递没有被取出它就会不停地发短信通知你直到你取出了快递它才消停这个就是水平触发的方式。
这就是两者的区别水平触发的意思是只要满足事件的条件比如内核中有数据需要读就一直不断地把这个事件传递给用户而边缘触发的意思是只有第一次满足条件的时候才触发之后就不会再传递同样的事件了。
如果使用水平触发模式当内核通知文件描述符可读写时接下来还可以继续去检测它的状态看它是否依然可读或可写。所以在收到通知后没必要一次执行尽可能多的读写操作。
如果使用边缘触发模式I/O 事件发生时只会通知一次而且我们不知道到底能读写多少数据所以在收到通知后应尽可能地读写数据以免错失读写的机会。因此我们会循环从文件描述符读写数据。如果文件描述符是阻塞的没有数据可读写时进程会阻塞在读写函数那里程序就没办法继续往下执行。所以边缘触发模式一般和非阻塞 I/O 搭配使用程序会一直执行 I/O 操作直到系统调用如 read 和 write返回错误错误类型为 EAGAIN 或 EWOULDBLOCK。
一般来说边缘触发的效率比水平触发的效率要高因为边缘触发可以减少 epoll_wait 的系统调用次数系统调用也有开销毕竟也存在上下文的切换。
select/poll 只有水平触发模式epoll 默认是水平触发但可以根据应用场景设置为边缘触发模式。 参考文献
C10K 问题 程序员怎么会不知道C10K 问题呢- Medium I/O 多路复用select/poll/epoll - 小林 coding io-multiplexing(多路复用) - Colingo碎碎念
