由于媒体推流客户端所在地域不同、所接入网络运营商不同、就近接入原则等因素，导致不同的视频推流客户端会推流至不同的流媒体服务器(本文主要针对目前WEB或手机的基于TCP的流媒体服务器)，在某流媒体服务器收到媒体拉流客户端的拉流请求时，其本身可能由于不存在该流，导致该流媒体先通过流调度服务器定位到该请求流，然后向有该流的流媒体服务器发出拉流请求，在收到流数据后该流媒体服务器向媒体拉流客户端转发该媒体流，再给合流媒体的分级结构等其它因素，这种基于即时建立TCP的连接的媒体流在大量推流与拉流用户时往往会有很多路媒体流在不同的流媒体服务器之间传输，这样会存在如下缺点：

1  由于每路媒体流就一个TCP连接，而TCP连接的建立需要一定开销且会带来一定时延，在大量媒体流在流媒体服务器之间互相转发时，这个叠加开销会更大了

2  基于TCP连接只传输一路媒体流，不利于按消息的不同保证优先传送 3 在基于分块协议流传输时，音频小包（一个音频帧一个块基于是够了）的封装块与视频帧（特别是1KB至3KB大小的P、B帧）的太多尾块，都达不到MTU的大小，加之考虑到实时性，往往会关闭Nagle算法，这样导致网络传输效率低下、服务器软中断升高。

为克服上述问题，可以这样做： 流媒体服务器启动后通过流调度管理服务器拿到其它所有同级或其上级流媒体的相关网络地扯信息，然后预先建立5个TCP连接，这样互相发起建立连接后，每两台流媒体服务器之间预先建立10个连接（5个主动、5个被动），每个连接可以传输100路左右的媒体流，这样流媒体服务器集群内部的流媒体服务器之间像高速公路一样一个内部静态网络连接结构已经预先建立起来，随时静待汽车经过，同时启动一个单独的低优先级线程监控当前连接数与每个连接承载的媒体流数，若有断开连接或不能满足目前的媒体流数且低于一定阀值，由该线程负责在后台默默建立TCP连接（单TCP连接具体承载的媒体流数在TCP正在建立等特别时机允许超过100，只要不达到最大设定的阀值即可）。 在有媒体流拉流客户端向某流媒体服务器发起播放请求后，该流媒体通过流调度管理服务器拿到所请求媒体流所在的目标流媒体地扯信息后，通过预先建立的TCP连接中的一个TCP连接直接向该目标流媒体服务器发送播放流请求，目标流媒体服务器通过基于块协议的多路复用、合包技术将该媒体流与其它早期选定的媒体流合包后一起发送给该流媒体服务器，该流媒体解包解复用后再转后给相应的媒体流拉流客户端。从媒体流转发端或源端所在的流媒体服务器角度来看，转发过程是这样的：由于是基于单个TCP连接传送多路媒体流，这样相较于传统以输入流连接驱动模式变成了以输出流连接驱动模式了，媒体流处理线程扫描所有的输出流连接，针对其中某个连接查看所有由该连接传送的输入媒体流，首先看是否有控制指令要传输，若有放入发送缓冲区，若无，接着查看是否有音频帧要传送，若有放入发送缓冲区，最后再查看是否有视频帧要传输，若有放入发送缓冲区，且前述几步每当发送缓冲区有新数据时都判断一下是否达到了MTU上限，若达不到继续，若达到立即发送，然后判断下一个输出流连接的处理方式同前面一个一样，如此循环，这样就做到了控制指令消息的传送优先级大于音频传送优先级了，而音频传送优先级又高于视频传送优先级。

预期收益：有效提升流媒体服务器之间传输效率、流量降低10%（主要是头部数据）、提高实时性、保证重要数据优先处理