企业类网站模版网站接入商查询

当前位置： 首页 > news >正文

企业类网站模版,网站接入商查询,阿里云服务器可以做彩票网站吗,多层分销网站建设网络模型 IO模型主要就是用户空间和内核空间数据交换的形式。 IO模型 阻塞 I/O 模型#xff08;Blocking I/O#xff09; 应用程序发起 I/O 请求后#xff0c;会被阻塞#xff0c;直到 I/O 操作完成。 非阻塞 I/O 模型#xff08;Non-blocking I/O#xff09; 应用程序…网络模型 IO模型主要就是用户空间和内核空间数据交换的形式。 IO模型 阻塞 I/O 模型Blocking I/O 应用程序发起 I/O 请求后会被阻塞直到 I/O 操作完成。 非阻塞 I/O 模型Non-blocking I/O 应用程序发起 I/O 请求后不会阻塞可以立即返回。如果 I/O 操作未完成应用程序需要不断轮询检查 I/O 操作的状态。 I/O 复用模型I/O Multiplexing 通过系统调用如 select、poll 或 epoll应用程序可以同时监视多个 I/O 通道当任何一个通道有数据可读或可写时系统调用返回。 信号驱动 I/O 模型Signal-Driven I/O 应用程序发起 I/O 请求后可以继续执行其他任务。当 I/O 操作完成时操作系统会发送一个信号给应用程序通知其 I/O 操作已经完成。 异步 I/O 模型Asynchronous I/O 应用程序发起 I/O 请求后可以立即返回并继续执行其他任务。I/O 操作由操作系统在后台完成完成后操作系统会通知应用程序。
阻塞IO 阻塞IO就是两个阶段都必须阻塞等待。 非阻塞IO 非阻塞IO的recvfrom操作会立即返回结果而不是阻塞用户进程。 虽然是非阻塞但是性能并没有提升。而且忙等机制会导致CPU空转CPU使用率暴增。 IO多路复用 比如服务器处理客户端Socket请求时在单线程情况下只能依次处理一个socket如果正在处理的socket恰好未就绪数据不可读或不可写线程就会被阻塞所有其他的线程客户端socket都必须等性能自然会差。 如何提高效率呢 方案一使用多线程进行处理。方案二数据就绪了用户就去读取数据。 那么如何知道内核中的数据就绪了 文件描述符(File Descriptor) 简称FD是一个从0开始递增的无符号整数用来关联Linux中的一个文件。在Linux中一切皆文件例如常规文件、视频、硬件设备等当然也包括网络套接字(Socket)。 IO多路复用 : 是利用单个线程来同时监听多个FD,并在某个FD可读、可写时得到通知从而避免无效的等待,充分利用CPU资源。 recvfrom 只能监听一个fd而select可以一次性传多个fd效率比 recvfrom 高。 监听FD的方式、通知的方式又有多种实现常见有 selectpollepoll 差异: select和poll只会通知用户进程有FD就绪,但不确定具体是哪个FD需要用户进程逐个遍历FD来确认epoll则会在通知用户进程FD就绪的同时把已就绪的FD写入用户空间 select select是Linux最早是由的I/O多路复用技术 简单说就是我们把需要处理的数据封装成FD然后在用户态时创建一个fd的集合这个集合的大小是要监听的那个FD的最大值1但是大小整体是有限制的 这个集合的长度大小是有限制的同时在这个集合中标明出来我们要控制哪些数据 比如要监听的数据是1,2,5三个数据此时会执行select函数然后将整个fd发给内核态内核态会去遍历用户态传递过来的数据如果发现这里边都数据都没有就绪就休眠直到有数据准备好时就会被唤醒唤醒之后再次遍历一遍看看谁准备好了然后再将处理掉没有准备好的数据最后再将这个FD集合写回到用户态中去此时用户态就知道了奥有人准备好了但是对于用户态而言并不知道谁处理好了所以用户态也需要去进行遍历然后找到对应准备好数据的节点再去发起读请求我们会发现这种模式下他虽然比阻塞IO和非阻塞IO好但是依然有些麻烦的事情 比如说频繁的传递fd集合频繁的去遍历FD等问题 select模式存在的三个问题 能监听的FD最大不能超过1024发生2次「拷贝」文件描述符集合先从用户空间传入内核空间由内核修改后再传出到用户空间中。每次都要遍历所有FD来判断就绪装填 poll poll 不再用 BitsMap 来存储所关注的文件描述符取而代之用动态数组以链表形式来组织突破了select 的文件描述符个数限制当然还会受到系统文件描述符限制。 poll模式问题 使用「线性结构」存储进程关注的 Socket 集合因此都需要遍历文件描述符集合来找到可读或可写的 Socket时间复杂度为 O(n)而且也需要在用户态与内核态之间拷贝文件描述符集合这种方式随着并发数上来性能的损耗会呈指数级增长。 epoll 先用epoll_create 创建一个 epol l对象 epfd再通过 epoll_ctl 将需要监视的 socket 添加到epfd中最后调用 epoll_wait 等待数据。
epoll 通过两个方面很好解决了 select/poll 的问题。 第一点epoll 在内核里使用红黑树来跟踪进程所有待检测的文件描述字把需要监控的 socket 通过 epoll_ctl() 函数加入内核中的红黑树里红黑树是个高效的数据结构增删改一般时间复杂度是 O(logn)。而 select/poll 内核里没有类似 epoll 红黑树这种保存所有待检测的 socket 的数据结构所以 select/poll 每次操作时都传入整个 socket 集合给内核而 epoll 因为在内核维护了红黑树可以保存所有待检测的 socket所以只需要传入一个待检测的 socket减少了内核和用户空间大量的数据拷贝和内存分配。第二点epoll 使用事件驱动的机制内核里维护了一个链表来记录就绪事件当某个 socket 有事件发生时通过回调函数内核会将其加入到这个就绪事件列表中当用户调用 epoll_wait() 函数时只会返回有事件发生的文件描述符的个数不需要像 select/poll 那样轮询扫描整个 socket 集合大大提高了检测的效率。 epoll 的 边缘触发和水平触发有什么区别 使用边缘触发模式时当被监控的 Socket 描述符上有可读事件发生时服务器端只会从 epoll_wait 中苏醒一次即使进程没有调用 read 函数从内核读取数据也依然只苏醒一次因此我们程序要保证一次性将内核缓冲区的数据读取完。使用水平触发模式时当被监控的 Socket 上有可读事件发生时服务器端不断地从 epoll_wait 中苏醒直到内核缓冲区数据被 read 函数读完才结束目的是告诉我们有数据需要读取。 信号驱动IO 信号驱动IO是与内核建立SIGIO的信号关联并设置回调当内核有FD就绪时会发出SIGIO信号通知用户期间用户应用可以执行其它业务无需阻塞等待。 当有大量I0操作时信号较多SIGIO处理函数不能及时处理可能导致信号队列溢出 而且内核空间与用户空间的频繁信号交互性能也较低。 异步IO