投屏直播系统从入门到入坑系列二：数据传输方案的全方位探索

因为考虑到数据的保密性和安全性，需求方很明确的要求“推流服务”在运行在数据发送的手机端。并且在传输方式上，需求方先后要求要以“蓝牙”，手机热点连接，内网wifi连接等方式进行组网，协议上也先后要求对TCP，UDP等方式上进行尝试。所以，这篇文章会简单介绍一下这几个方式上的特点。
因为时间关系，就不从原理等层面进行分析，以后有时间会再做理深入的补充。

1.蓝牙传输上的试水。

蓝牙传输方式上，理论上可以实现一对多的连接，在连接稳定性方面没做过很完善的测试，但当时办公室几十人的手机都被我写的蓝牙连接程序进行过不同程度上的骚扰。所以，理论上可以满足开会时的多人场景。

在传输协议上，蓝牙传输以报文的方式进行数据传输。512byte包大小限制会直接导致在应用层协议定制上产生了很大的限制。一个I帧的发送几呼要发送几十次才能发送完，效率令人失望。而且因为解决数据报接收后重组的问题，每一个报文中也要加入事先定义好的包头信息，也进一步了数据量上的细微的负担。

2. UDP报文传输。

UDP在传输方式上有“多播”“组播”“点对点”的方式。

1.多播：数据发送端把数据发送到多播地址 255.255.255.255, 连接端连接到多播地址对数据报进行监听接收。安全性上无法满足需求方的要求。

2.组播：安全性上会比多播高一点点。在连接之前，组播地址和端口由“发送端”机于一定的规则随机生成，在“接收端”成功进行login操作后，返回对应的地址和端口。

3.一对一：一定程序上要有一个第三方的登记机制，“发送端”login成功后完成登记，服务端实现连接。

尽管传输方式多样，但依然无法逾越报文传输上的弱点，同样512byte的报文大小限制以及服务端50m内存限制，对于大文件数据发送效率相对效低，容易对服务端缓存在发送和接收的时候产生大量的数据包的堆积。

3.TCP流式传输。

这个也是最后先择的推流方式。在其他方面，我们也同时结合对UDP多播和组播方式的使用，实现了推流端的服务发现机制，以及用户安全验证机制。以后会符上图片加以说明。
进行数据流进行传输在开发的上层就不必过多考虑包大小的问题了，但的包大小，也是有所讲究的。一次性发送过大的媒体流就手机端而言会时不时产生发送不出发送失败的情况，这方面的内容后其会专门写一编相关的博文。