各种网络架构的分类和分析.pdf

目前的系统messenger类的处理过程： 各种网络架构的分类和分析 ⼀、分类依据。服务器的网络模型分类主要依据以下几点 （1）是否阻塞方式处理请求，是否多路复用，使用哪种多路复用函数 （2）是否多线程，多线程间如何组织 （3）是否多进程，多进程的切入点⼀般都是accept函数前(apache的处理方法） 二、分类。首先根据是否多路复用分为三大类： （1）阻塞式模型 （2）多路复用模型 （3）实时信号模型（可以忽略） 三、详细分类。 1、阻塞式模型根据是否多线程分四类： （1）单线程处理。 也就是所有的io事件（包括listen ，read ，write）都在多路复用函数（select ，poll ，epoll） 下wait ，当有唤醒后，遍历响应的fd ，处理不同类型的io请求。 （2）⼀个请求⼀个线程。 主线程阻塞在accept处，新连接到来，实时生成线程处理新连接。受限于进程的线程数，以 及实时创建线程的开销，过多线程后上下文切换的开销，该模型也就是有学习上价值。 （3）预派生⼀定数量线程，并且所有线程阻塞在accept处。 该模型与下面的（4）类似与线程的领导者/追随者模型。 传统的看法认为多进程（linux上线程仍然是进程方式）同时阻塞在accept处，当新连接到 来时会有“惊群”现象发生，即所有都被激活，之后有⼀个获取连接描述符返回，其它再次转 为睡眠。linux从2.2.9版本开始就不再存在这个问题，只会有⼀个被激活，其它平台依旧可 能有这个问题，甚至是不支持所有进程直接在accept阻塞。 （4）预派生⼀定数量线程，并且所有线程阻塞在accept前的线程锁处。 ⼀次只有⼀个线程能阻塞在accept处。避免不支持所有线程直接阻塞在accept ，并且避免 惊群问题。特别是当前linux2.6的线程库下，模型（3）没有存在的价值了。另有文件锁方 式，不具有通用性，并且效率也不高，不再单独列举。 （5）主线程处理accept ，预派生多个线程（线程池）处理连接。 类似与线程的半同步/半异步模型。 主线程的accept返回后，将clientfd放入预派生线程的线程消息队列，线程池读取线程消息 队列处理clientfd。主线程只处理accept ，可以快速返回继续调用accept ，可以避免连接爆 发情况的拒绝连接问题，另加大线程消息队列的长度，可以有效减少线程消息队列处的系统 调用次数。 （6）预派生多线程阻塞在accept处，每个线程又有预派生线程专门处理连接。 （3）和（4）/ （5）的复合体。 经测试，（5）中的accept线程处理能力非常强，远远大于业务线程，并发10000的连接数 也毫无影响，因此该模型没有实际意义。【实际上是指太浪费，后面的处理线程跟不上处 理】 总结：就前五模型而言，性能最好的是模型（5）。模型（3）/(4)可以⼀定程度上改善模型 （1）的处理性能，处理爆发繁忙的连接，仍然不理想。。阻塞式模型因为读的阻塞性，容 易受到攻击，⼀个死连接（建立连接但是不发送数据的连接）就可以导致业务线程死掉。因 此内部服务器的交互可以采用这类模型，对外的服务不适合。优先（5），然后是（4）， 然后是（1），其它不考虑。 2 、多路复用模型根据多路复用点、是否多线程分类： 以下各个模型依据选用select/poll/epoll又都细分为3类。下面个别术语采用select中的，仅 为说明。 （1）accept函数在多路复用函数之前，主线程在accept处阻塞，多个从线程在多路复用函 数处阻塞。主线程和从线程通过管道通讯，主线程通过管道依次将连接的clientfd写入对应 从线程管道，从线程把管道的读端pipefd作为fd_set的第⼀个描述符，如pipefd可读，则读 数据，根据预定义格式分解出clientfd放入fd_set ，如果clientfd可读，则read之后处理业 务。 此方法可以避免select的fd_set上限限制，具体机器上select可以支持多少个描述符，可以 通过打印sizeof(fd_set)查看，我机器上是512字节，则支持512×8 ＝4096个。为了支持多余 4096的连接数，此模型下就可以创建多个从线程分别多路复用，主线程accept后平均放入 （顺序循环）各个线程的管道中。创建5个从线程以其对应管道，就可以支持2w的连接，足 够了。另⼀方面相对与单线程的select ，单⼀连接可读的时候，还可以减少循环扫描fd_set 的次数。单线程下要扫描所有fd_set