首先，你要确定使用环境，LAN OR WAN：若是LAN就没必要使用RTP(实时传输协议)，RTCP(实时传输控制协议)，建议视频，音频分开传输用UDP(因为视频，音频数据量大，打包在一起一帧放不下)，字幕数据用TCP(保证可靠性)，这里需要注意的是视音同步的问题，你可以大致计算同一时间段内视音频数据的比例，依照这个比例建立视频音频数据的缓冲区大小，一般来说，同步的问题比较好解决。若是WAN就需要使用RTP,RTCP了，这个需要去看具体的协议标准。简单来讲，RTP就是在UDP的基础上再封装一层，主要是一些控制信息；而RTCP根据这些控制信息，调整带宽，提高优先权等等，以达到改善传输质量的目的。
2，数据丢包的问题可以用超时重发，定义一定的时间等待返回数据，（当然这种情况要设计自己的协议返回），你也可以设计一个协议检查当前的网络速度，比如发送一个数据到对方再到返回要用的时间，然后你可以用该时间的几倍作为超时的时间，我时这样实现的。
希望以上对你有所帮助！
如果，数据包丢失不是很严重的话，就不是太要紧。
如果，你要求数据包丢失很少的话，你可以对udp进行封装
然后，在接收端和发送端设计设计超时，
对于接收端，如果收到指定序号的数据包，
就给接收端发确认的数据包。并设为已收到标志。
如果，接收到的数据包为已收到的，就抛弃。
等多长时间收不到，就设超时值。(此时网络必定很坏)
对于发送端，如果收到指定序号的数据包，这不在发送它。
隔一段时间，如果收不到确认的数据包，就重发。直到收到它。
如果网络很坏的话，这就要设一个超时值了。否则，越来越坏。
比如，发多少次后，丢弃数据包。(语音的话，少数据包不太要紧吧)
网络的就这些了。
另外，多线程是一个好主意，不过，语音和文本分开。
也是一个不错的想法。
和audio不允许重传，而字幕可以重传.UDP传输的可靠性应该不是很好。
比较容易控制。
丢包的问题，可以分开看，
如果是在局域网内，网络链路很快，那倒无所谓校验的问题。
如果是在广域网，或是网络链路丢包严重，那就要校验。
由于传递的是实时的数据，还要考虑时间间隔丢弃的问题。
可以用异步的方式进行校验，数据报上带时间戳。
至于UDP还是TCP或是RSTP,sorry,RSTP什么东西我都不知道。
但是UDP和TCP只是和应用的CPU占用率有关，对网络的压力其实差的并不多。
其中一个tcp,两个udp的
用户验证用tcp
其他的传输用udp
感觉还可以呀
传输的文字信息不大，没什么丢失现象
服务器是一对多的，可以接受多个客户端的点播。对了，用udp发送数据，一个包（或是一次发送数据），多大为好呢？现在我是没有处理的，压缩的视频数据，当是关键帧时就可能有10K多，非关键帧就少一些。我以前也试过，把发送大的包分小，但在局域网里没看多少差别，是不是在网络差一些就会十分明显了？ 到底每次多大为好呢？
1： 将接受缓冲区开大点可能有好处。 2： 开3个SOCKET可能控制更灵活，而且可以减少每个SOCKET的处理复杂程度，加快SOCKET的处理、响应。 我做UDP的感觉。 个人观点！ 谢谢你的QQ程序
基本同意用多个SOCKET，多个线程
ISO-IEC 13818-1标准
www.videolan.org上找到,
还是一个SOCKET、单个线程
我认为先自己试试，我们也没太多的经验。
至于是否需要多个SOCKET，我还是倾向只用一个就够了。
2。同意explorer007(KKcat)的意见
即使你在应用层使用了多个Socket，也就是在应用层能一次提交多个包给数据发送层，这样对驱动程序处理这种请求的能力要很好，这样包怎么丢失的你更不知道了，驱动也是程序员（只是较牛一点罢了）写的嘛，这个纯粹个人无机之想！
其实，我对这个嘛...还真不是很懂！
音频模块测试时就做了一个 UDP 的，效果跟我们用的 RTP 差不多。我
门做的是多线程的。各模块一个线程。丢数据的问题是不可避免的，音
频如果用的是 windows 的低级音频函数的话要做到比较好的效果要注
意线程的安排，缓冲块最好用数组，我试过的版本数组是最好的。另外
rtp 协议栈国外有教授写了一个现成的，找找看。
请发至[email protected]，多谢
如果能经常联系指导我，也请留下联系方式，菜鸟感激不尽^=^
UDP丢包是必然的，没办法！
很是抱歉，希望你早点找到答案