基于TCP、UDP网络传输的实例分析

本人最近结合项目研究了一下网络传输的应用开发，虽然在这方面的经验不是很丰富，也不专业，但通过这段时间的学习还是有一定收获，希望分享给大家，同时也希望大家互相交流讨论。

 

一 网络传输的三种应用

    1、IPTV：网络电视，由电台按照节目单在网络中播放节目，每一个网络上的客户只需打开接收软件，就可以在本地收看节目。

    2、IP-Surveillance：网络视频监控，客户通过网络对终端设备的控制，实现音视频的监控。

    3、IP-Phone：网络电话，双方通过网络实现点到点的通信。

 

    这三种网络应用有很多不同，这里我仅从媒体流（音频、视频压缩后的比特流）的走向来简单的说明一下。在IPTV中，电台相当于Server 端负责发送节目，网络客户就是Client端接收并解码播放节目，即媒体流的方向是Server--> Client；在IP-Surveillance中，如果认为监控台是Server，而终端监控设备是Client，则记录的媒体流的方向是Client-->Server；在IP-Phone中，双方是点对点传输地位相同，媒体流的走向是Server<-->Client。这里暂且忽略一对多、多对一和一对一传输方式。

 

二 选择TCP，还是UDP

    网络传输是采用基于TCP传输，还是基于UDP传输是个老生常谈的问题，主要还是根据实际项目需求决定。TCP是面向连接的可靠性传输，但传输的效率较差；UDP是面向非连接的传输，数据包非常容易发生丢失，但传输的效率高。这里简要总结三个需要考虑的因素：

    1、可实现性

     通常在一对多或多对一传输模型下，不适宜采用TCP传输方式，一方面由于音视频数据包比较大，容易丢失，TCP丢包后反复确认、重新发包等容易加重网络负载，造成网络瘫痪；另一方面，网络上Client的数量动态范围较大，不利于Server端软件设计和硬件的配置。

     2、可实时性

     对于实时性要求较高的需求，多采用UDP传输模式；就音视频品质来说，对于网络情况良好时，TCP、UDP都没有问题，对于网络不太好时，采用TCP传输通常屏幕不会花，但延时会很大；采用UDP传输通常屏幕会由于丢包而出现马赛克花屏。

     3、音视频同步问题

     对于TCP来说，并没有音视频同步问题，它可以将音视频一起发送，一起接收，一起解码播放；对于UDP来说通常会把音视频分成两个流去传输，这样接收的时候就有了同步问题。如果将音视频合成一个流传输，就增加了接收端软件设计的复杂度，因为若发生数据丢包，对于接收端要正确的解析音视频流就比较困难了，这样音视频解码就都会出现问题。一般需求中往往希望当网络条件变差时，声音实时性优先（所需带宽小更容易保证传输），然后图像可以慢慢调整。音视频同步问题可以通过时间戳等方法处理。

 

三 网络应用的简化

    在对以上三种应用实现过程中，都需要进行简化：

    a、在局域网中实现数据传输；

    b、都采用一对一传输，忽略一对多和多对一的情况；

    c、Server端在PC上实现，Client端用嵌入式CPU上实现（如TI DSP）；

    d、PC端可以MFC实现简单的UI，DirectShow实现AV的解码播放，嵌入式方面更是提供了现成的软件包使用；

   

    1、IPTV：首先要保证播放的节目具有清晰的品质，其次是节目的流畅性和同步。因此，可以采用基于TCP的网络传输，值得注意的是要保证发送的音视频流本身同步和音视频流的解析；

 

    2、IP-Surveillance：首先要求实时性和同步性，然后是监控的声音和画面品质。这里，可以采用基于UDP的网络传输，值得注意的是接收端要尽量快的接收来自网络的数据包，否则就会丢失，因此音视频要分别有接收的线程、解码播放的线程，接收的线程要尽量简单并控制好缓冲buffer，线程之间不要出现互锁。另外，音视频同步问题也需要设计较好的策略解决，如时间戳的比较，数据包严重不同步时的反馈、调整。

 

    3、IP-Phone：这个目前还没有具体评估实现，暂不讨论了。

 

四 总结

    1、实际需求决定了选用哪种传输方式；

    2、采用UDP传输需要注意的细节更多一些，如同步问题、接收缓冲buffer的管理等；   

    3、心跳信号是必不可少的，随时检测通信双方的状态。

    4、虽然PC、DSP上提供的软件越来越强大，系统开发越来越容易，但是在特殊情况下仍然保证品质并不容易，例如在出现网络条件比较糟糕下，希望音视频依然有较好的效果就比较困难，也正是这些问题才是我们值得花时间去解决，从而增长经验的地方。

 

一家之言，欢迎指正！