互联网络程序设计结束篇VIP免费

网络编程的模型与技术模型总结基本结论高效技术模型总结迭代方式并发方式–进程并发–线程并发–线程池/进程池–多核并发（绑定CPU核+流水线）IO模型–阻塞IO–非阻塞IO–IO复用–信号驱动IO–异步IO线程池/进程池缘起并发进程池/线程池技术–基本思想：准备一个池子，容纳预先创建的进程或线程，好处是省去了创建新进程或线程的时间–关键问题是如何把新连接分发给进程池中的一个进程？accept无上锁进程池中的所有空闲进程侦听服务端口，在accept()函数阻塞等待新连接建立，所有进程池中的进程被唤醒。系统调度进程池中的某个进程，从accept函数中返回，该进程为新进客户服务其余进程呢？依次被调度，但是由于listen队列中为空，再次被阻塞4.4BSD中的惊群效应（thunderingherd）accept的另一种方案使用IO复用模型——阻塞在select函数上–基本模型同accept–但是比accept方案更糟糕，原因是事件的发生新连接到达引发的，select更绕行一次accept上锁改进思路：让进程池中的进程依次访问accept函数，从而避免了为获得连接进程的调度开销，也就消除了惊群效应惊群效应的开销转嫁为锁的开销与锁的实现机制有关–文件锁–线程互斥锁进程池，分发连接描述符基本思想：–一个父进程负责侦听，子进程阻塞–当有新的连接，父进程把新socket传递给一个子进程与前述的accept方案相比，父子进程之间分工明确，避免了惊群效应子进程阻塞在进程间通信的管道上（不一定是PIPE）增加了进程间通信的开销，同时父进程必须跟踪子进程的状态，看它是否处于空闲描述符、空闲状态的传递线程池技术与进程池技术类似教材中省去了阻塞在accept函数的情况池技术与即时创建的对比并发的开销——调度+上下文切换+竞争与保护–相对于迭代方式，多出来的开销–调度，Linux的O(1)调度器–上下文切换–公共资源的保护如果连接数超过线程池的size，怎么办？教材中的结论：与其采用进程池/线程池技术，还不如直接采用即时创建线程进程池/线程池的例子apatch服务器Java线程池IO复用与非阻塞IO模型对比12.3sec,selectandblockingI/O(Figure6.13)6.9sec,nonblockingI/O(Figure16.3)8.7sec,fork(Figure16.10)8.5sec,threadedversion(Figure26.2)非阻塞IO程序设计复杂稍微复杂些应该采用多线程技术？C10K问题《ScalableNetworkProgramming》在服务器重负荷的情况下，采用多线程技术存在着如下的问题：–调度开销无法避免–共享资源保护的开销也无法避免–可扩展性受到限制线程控制块栈堆。。。这些开销加在一起，再乘以10000个客户？结论是：–在重负荷的服务器设计中IO复用和AIO模型是一个非常关键的要素。IO复用细节select函数的设计问题–受限于FD_SETSIZE–拷贝数据、O(n)的检查、多次检查poll解决了FD_SETSIZE的问题，但是设计仍然低效最佳的选择是：epoll、kqueue–epoll当前只支持文件上的读、写等事件，eventfd、signalfd、timerfd–kqueue支持文件添加、删除，AIO，进程fork、终止等，是一种更一般的事件通知机制。超时处理三种方法–alarm–select–SO_RCVTIMEO与SO_SNDTIMEO选项alarm采用异步信号机制select是同步机制alarm和select在多客户连接的情况下，如何管理？参考ACE简单的方法，推荐采用SO_RCVTIMEO与SO_SNDTIMEO，可惜与实现相关零拷贝技术应用程序内核网卡，报文零拷贝底层硬件scatter-gather支持内核mbuf/skbufreadv、writev、sendfile、TCP_CORK(Linux),TCP_NOPUSH(BSD)更多的参考C10K网站、《ScalableNetworkProgramming》、libevent、lighttpd、Boostasio库、ACE库。