一、TCP
TCP是面向连接（连接导向） 的、可靠的、基于字节流的。局域网中使用TCP传输流比较靠谱，TCP在复杂互联网环境应用性比较窄，目前都采用码流自适应来解决网络质量等外在因素对流传输的影响。安防行业的网络摄像头（IPC）、DVR等设备一般会为一个通道提供多种码流，可配置不同是分辨率、码率、帧率来适应不同的网络带宽环境。RTP/RTSP、HLS均可基于TCP来传输码流，TCP传输流媒体一般用于网络环境较好的场景。
二、UDP
UDP是OSI参考模型中一种无连接的传输层协议，它主要用于不要求分组顺序到达的传输中，提供面向事务的简单不可靠信息传送服务。在网络质量令人不十分满意的环境下，UDP协议数据包丢失会比较严重。但是由于UDP的特性：它不属于连接型协议，因而具有资源消耗小，处理速度快的优点，所以通常音频、视频和普通数据在传送时使用UDP较多，因为它们即使偶尔丢失一两个数据包，也不会对接收结果产生太大影响。如果选择UDP传输流媒体，就必须得接受丢包乱序的问题，当然我们也可以在UDP上建立包序号检查和超时重传机制，满足场景需要就行，如果这些机制做的过于严苛还不如直接用TCP来传输了。数字电视行业的转码器（例如envivio/思科）基本都是基于UDP传输TS封装的码流，可提供不同码率的码流，采集到转码器的流以后需要自行解复用，选择适应客户端网络传输的码流播放。
UDP丢包乱序问题分析：
UDP在局域网丢包不明显，在公网环境中丢包很普遍。UDP是无连接的传输协议，与TCP相比，会存在丢包和乱序的问题。
1.发送数据包太大或者太频繁
通过控制报文大小来解决报文过大导致丢包，以太网的MTU通常是1500 bytes，所以最好控制发送报文长度在1000左右，可根据环境适当斟酌。
如果要发送的数据过多或者过大，那么在缓冲区满的那个瞬间要发送的报文就很有可能被丢失。
修改缓冲区大小可以适当缓解丢包；在每个报文都加上报文编号，以报文编号判断丢包和乱序，RTP包头有sequence number、TS包头有continuity_counter，如果传输的数据没有明确的包序列号，可自定义报文包头，出现丢包后可向对端发送重传消息。UDP的丢包和乱序是确确实实存在的，只能通过自行定义协议做类TCP的重传机制和超时机制。
2.接收方处理时间太长，接收来不及
重构数据接收和处理逻辑，不能让接收数据由于应用层的事务阻塞，接收数据模块和处理模块应该是异步的构建，共同维护一个数据队列，确保数据及时获取和处理。
三、工具介绍
VLC media player是做流媒体开发必不可少的工具，可做HLS、RTSP、UDP等常见协议的网络播放和本地播放，亦可做流媒体推流服务器，将本地文件转码后推送到指定的网络地址。
四、场景介绍
下面就介绍下两种流媒体传输模式：
1.对接某国外安防监控品牌的DVR设备，RTCP over TCP用作设备管理控制命令协议，RTSP over TCP作为流传输控制命令协议， RTP封装H.264 over TCP作为流传输协议。
设备端RTCP端口号一般为555,连接该端口，并进行登录设备、获取设备信息、注册权限验证、心跳机制;
设备端RTSP端口号一般为554,连接该端口，并进行DESCRIBE、OPTIONS、SETUP、PLAY、PAUSE、TEARDOWN等流传输控制命令;
设备端RTP端口号一般为556,连接该端口，接收RTP协议的码流数据传输。
当时的功能需求是登录设备、获取信息、直播通道码流、按时间回放通道的录像以及暂停、开始、拖拽、停止等控制方式，就直接用非阻塞socket的select模式做超时机制实现了RTCP/RTSP/RTP，当然也可引入jrtp这个开源库来实现。
2.linux流媒体服务器，转码器向网内组播多个频道多种码率的流数据TS Over UDP，从而需要采集这个多路复用的流，并按不同节目不同码率转发出去。
bind组播端口5842，加入组播，采集UDP数据，解复用，按照不同的program_map_PID（节目PID）解析不同的elementary_PID(音视频PID)。具体解析方法参照另一篇文章TS格式解析。然后按照HLS协议封装playlist.m3u8和多个ts文件切片，达到码流自适应。具体封装方法参照另一篇文章HTTP Live Streaming协议。