服务器技术系列综述（一）

本人职业是linux上网络服务器的开发，本文就网络服务器的系统架构设计的细枝末节展开讨论。欢迎任何的点评指导和讨论，尤其是对文中的缺点或者更好的方案。
一 系统框架概述
网络上的服务器，无论是嵌入式的网络设备，还是pc上服务器，整体结构以及主要思想都大体相同：根据业务模型确定主要数据结构，根据数据结构确定线程模型，在各个业务线程内根据围绕主要数据结构进行的操作确定状态机模型，低层使用网络层收发数据完成和其它网元的通讯。线程交互模型简单描述如下图：

其中网络层包括收发模块，收数据模块是单独线程，而发数据模块则被业务线程调用在其本身线程中发送数据，网络层收到数据后也可能向多个业务线程发送消息，业务线程可能1个，也可能多个，业务线程之间可能存在消息发送，最终会调用网络层的发送方法完成本server的功能。
二 网络层
相对而言，网络层的实现相对呆板、模式化，这个层面的要点在系统调用，实现方式要符合操作系统提供的api允许的使用方式，而不能天马行空想当然，因此提高这部分能力的重点在于系统性的学习（《unix网络编程》），不再于经验。
网络层有3部分构成：连接细节、多路复用函数、协议解析。
（1）连接细节。要实现各个协议的网络层（协议栈），首先要面对的就是承载该协议的传输层协议，udp还是tcp，理论本身就不再多说了。简单说下编程上的差异：udp的网络连接简单、收数据简单，tcp的则网络连接复杂、收数据需要在应用层面确定是否一个收包完毕，tcp部分可以参见《【原创】技术系列之 网络模型（一）基础篇》。
（2）多路复用函数。除了处理udp、tcp本身网络连接的系统调用之外，还存在和udp/tcp无关的多路复用函数（select等），它们可以监控tcp的网络事件，也可以监控udp的网络事件，属于网络层的核心驱动部分。可以参见《【原创】技术系列之 网络模型（三）多路复用模型》
（3）协议解析。这部分相对独立，是网络层中和网络连接、收发消息无关的部分，主要功能则是对该协议各种消息的解包(decode)、打包（encode)。
网络层的主要线程是多路复用监控线程（select/poll/epoll_wait等），网络消息触发该线程的运转，如果是收包，则调用read类函数，收包完毕，进行解包操作，之后根据需要向业务线程发送消息（也可以收包完毕后即把数据包裹在消息中发送给业务线程，由业务线程解包，单仍把解包打包操作归在网络层中）。
性能方面：为了描述方便，引入使用场景：转发rtp码流，这个场景需要尽量大的并发行和实时性。
（1）高性能函数。如果系统支持，使用epoll/port/kqueue等高性能多路复用函数。在此，将多路复用监控线程封装在RtpService类中，将rtp连接，封装在RtpConnection类中。使用模型可以参见《【原创】技术系列之 网络模型（二）》
（2）多线程支持。启动多个RtpService示例，也既是启动多个多路复用监控线程。将RtpConnection对象均匀的插入到各个RtpService中，同时在RtpConnection中记录它属于的RtpService，便于删除的时候找到它所在的RtpService。
（3）收数据线程直接转发。处于实时性的需要，一定要在收数据的线程转发数据，而不是向其它线程发送消息，让其它线程完成发送。这样做一是避免不必要的内存复制，最重要