ios视频传输udp方案分析

基于iOS的网络音视频实时传输系统(H264+pcm+videoToolbox)无第三方实现
这篇文章中，视频的传输采用的是tcp 的方案来实现的

那么为什么不用udp来实现呢？
实际上，一开始采用的udp的方案，但实际在传输的过程中
出现了大量的丢包现象，还有乱序的可能性
丢包会导致花屏，乱序会导致视频抖动。

采用tcp 的好处是tcp不会丢包和乱序，但需要牺牲一定的网络延时。和包大小的不定长度。

当我完成了tcp的实现后
我想尝试用udp也实现这样的过程
那么，我必须考虑模拟tcp的过程
除了三次握手和4次挥手之外

重发变得非常重要，如果按照发送端发一 接收端 收1 再回复给发送端，
发送端再继续发二，当然能保证数据的完整有序，
但会出现效率低下的问题，怀疑会出现画面慢放的效果。

从图解tcp/ip的书中获得启发，我能够一次性发送五包，
然后接收端回复1-5 ，当1-5 都收到以后 我再继续发送
那么发送端和接收端都必须维护 缓冲队列 来应对某包的重发问题

到这里是不是结束了，可以开始编码了么？
不是的不为人知的网络编程(六)：深入地理解UDP协议并用好它
这篇文章告诉我们，udp收发每包是有大小范围限制的，局域网下应该控制在 1472字节内，
外网应该控制在576字节内，才能尽量的保证 不丢包，或者达到缓冲区的界限。
所以应用层会根据当前的网络状态来决定分包的大小

那么在发送端的分包，接收端的组包就变得非常重要。
在最简单的收发中，只需定义好 包头，序列号，包长度 就可以相互传输了，现在必须在后面
在加上本次分包总共分了多少个，当前发送到第几个，发送的长度，来完成这种二级协议的封装。

除此之外，还需要考虑udp 重发是否会导致网络拥塞，挤占其他业务的带宽，进而影响到其他业务的质量。

所以这次就暂时不做udp版本的视频通信了，等能够把这些上面的内容想清楚，
理顺之后才能再回来写这一块的内容
在此之前，就先使用tcp好了。