以前开发会议服务器是基于sip，rtp协议的，网络处理模块写的特别简单，对每路呼叫中的媒体流都是采用一个线程处理，一路呼叫中包含两路流，一路视频流，一路音频流，对应的一路呼叫就需要两个线程，这样算下来，一次会议中的有4个成员，对应的有8路流，光数据收发线程就需要8个。线程多了，线程上下文切换就会耗费大量资源。这种模型显然是不可取的，特别是设计媒体服务器时，往往过多的只考虑了媒体处理模块的架构，怎么样去尽可能多的去兼容媒体协议及媒体格式，而往往忽略了作为底层基础模块，网络层的架构。
其实在服务器编程领域一些通用技术及设计模型通常是适应于流媒体系统的。可以说服务器编程的知识是流媒体系统中的底层基础，典型的像直播系统中，媒体服务器的高并发，低延迟就是构建于服务器编程技术之上。所以我觉得流媒体领域基本架构应该如下：
网络处理模块是流媒体服务器的性能基石，这也是一个很大领域，我有服务器开发领域的基础，但是这块的知识也放了好几年了，对一些技术都模拟两可了，所以作为学习流媒体架构的开端，我决定再重新捡起来学习。以上的模块架构图也相当于我学习流媒体领域知识的一个路线图，先从网络模块开始，再对流媒体协议的学习，再到编解码的学习，再到媒体处理的学习。