基于实时传输协议和传输控制协议的流媒体传输实现方法

1.一种基于实时传输协议和传输控制协议的流媒体传输实现方法，包括以下步骤：1)流媒体发送端对传输控制协议协议进行配置，关闭Nagle算法，使传输控制协议数据报文严格按照顺序发送；2)删除实时传输协议协议中的实时传输控制协议的传输控制功能，以使在流媒体发送端和接收端禁止相互传送发送报告和接收报告；3)重新定义实时传输协议协议数据报文头部参数，修改序列号参数空间内容，使其负载内容由序列号改为数据报文长度；4)流媒体发送端按照修改后的实时传输协议数据报文头部格式发送流媒体数据报文；5)流媒体接收端根据实时传输协议数据报文头部参数提供的数据报文长度对传输控制协议报文中的RTP报文进行分段接收；6)流媒体接收端根据实时传输协议数据报文头部参数提供的数据报文长度，对接收到的不完整的实时传输协议报文进行拼装，以形成完整的实时传输协议数据报文；7)流媒体接收端按顺序对完整的实时传输协议报文中的数据进行解码；所说的对接收到的不完整的实时传输协议报文进行拼装的方法为：如果检测到所接收数据比实际实时传输协议数据报文长度小，将继续循环接收所缺少长度的数据报文，直至检测到所接收数据与实际实时传输协议数据报文长度相等，进行拼接，即为完整的实时传输协议数据报文。

基于实时传输协议和传输控制协议的流媒体传输实现方法\n技术领域\n本发明属于计算机多媒体技术领域，特别涉及流媒体传输方法。\n背景技术\n在网络上传输音频、视频等多媒体信息，目前主要有下载和流式传输两种方案。音视频文件一般都较大，所以需要的存储容量也较大，同时由于网络带宽的限制，下载时间也很长。近年来，为解决以上问题，适应网络多媒体化的发展趋势，流媒体技术应运而生。\n流媒体技术的流式传输方式，实现了声音、影像或动画等多媒体由音视频服务器向用户计算机的连续、实时传送，用户不必等到整个文件全部下载完毕，而只需经过几秒或十数秒的启动延时即可进行观看。流媒体技术不仅使启动延时成十倍、百倍地缩短，而且不需要太大的缓存容量，节省用户资源。流媒体适用于各种网络带宽环境(14.4Kbps-10Mbps)，因此，流媒体在互联网上的应用也十分广泛，如多媒体新闻发布、在线直播、网络视频广告、电子商务、视频点播、远程教育、网络电台、实时视频会议等。在宽带环境下，流媒体不仅可以进行单向流式传输，还能够提供以互动技术为基础的交互网络服务，如互动游戏、三维动画、互动培训等等。互联网技术的发展决定了流媒体市场的广阔前景，目前，流媒体技术的应用正处于高速持续增长时期。\n实时传输协议RTP(Real time Transport Protocol)是最典型、最广泛的服务于流媒体数据传输的一种网络传输层协议，它包括两部分：RTP数据传输协议和RTCP传输控制协议。RTP协议本身主要是为流媒体提供时间信息和实现流同步，但是，并不能实现完整的网络数据传输功能。通常情况下，RTP配合底层用户数据报协议(UDP协议)完成数据传输。\nRTP/UDP模式的主要优势在于传输延迟时间较短，音视频流能够较好的匹配。同时，UDP传输的不可靠性主要依靠实时传输控制协议RTCP服务来弥补。RTCP周期的传送RTCP数据报文，监视RTP传输的服务质量。在RTCP报文中，含有已发送的数据包的数量、丢失的数据包的数量等统计资料，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型，实现流量控制和拥塞控制服务。\nRTP/UDP传输模式存在以下不足之处：首先，UDP协议本身不提供任何传输可靠性保证，传输层的可靠性完全依靠RTCP协议，RTCP协议为松散控制方式，数据发送方只能依靠反馈机制根据已经发送的数据报文对带宽进行调整、优化，不能真正解决不可靠性，不能确保每一个数据报文的传送。\n其次，RTCP报文的传输虽然与RTP使用不同的端口，但是RTCP的反馈数据报文本身基于UDP，其反馈速度直接受到网络环境的影响，其反馈控制效果不理想。\n最后，RTCP协议本身比较新，其拥塞控制算法与TCP相比，还有很大差距。因此，在庞大的音视频数据传输过程中，流媒体传输的可靠性与基于TCP传输协议的其它应用相比，还有很大差距。\n发明内容\n本发明的目的是为克服已有技术的不足之处，提出一种基于实时传输协议(RTP)和传输控制协议(TCP)的流媒体传输实现方法。通过对RTP协议进行修改，使用TCP协议传输RTP数据报文，可提高流媒体传输的可靠性。\n本发明提出的一种基于实时传输协议(RTP)和传输控制协议(TCP)的流媒体传输实现方法，包括以下步骤：1)流媒体发送端对TCP协议进行配置，关闭Nagle算法，使TCP数据报文严格按照顺序发送；2)删除RTP协议中的实时传输控制协议(RTCP)的传输控制功能，以使在流媒体发送端和接收端禁止相互传送发送报告SR和接收报告RR；3)重新定义RTP协议数据报文头部参数，修改序列号(Sequence Number)参数空间内容，使其负载内容由序列号改为数据报文长度(Length)；4)流媒体发送端按照修改后的RTP数据报文头部格式发送流媒体数据报文；5)流媒体接收端根据RTP数据报文头部参数提供的数据报文长度对TCP报文中的RTP报文进行分段接收；6)流媒体接收端根据RTP数据报文头部参数提供的数据报文长度，对接收到的不完整的RTP报文进行拼装，以形成完整的RTP数据报文；7)流媒体接收端按顺序对完整的RTP报文中的数据进行解码。\n所说的对接收到的不完整的RTP报文进行拼装的方法可为：如果检测到所接收数据比实际RTP数据报文长度小，将继续循环接收所缺少长度的数据报文，直至检测到所接收数据与实际RTP数据报文长度相等，进行拼接，即为完整的RTP数据报文。\n本发明的工作原理：TCP/IP网络传输结构是目前最成熟，最可靠，应用最广泛的传输方式，本发明在RTP/TCP模式下，使用TCP协议负载RTP数据报文，流媒体的传输可靠性完全交给底层的TCP协议来实现，TCP协议是目前应用最广，最成熟的传输层协议。TCP协议采用基于窗口的(window-based)端到端(end-to-end)的算法提供可靠的拥塞控制机制，其算法也比较成熟，主要有两种Tahoe和Reno，分别对通过重复应答所判断出的丢包现象进行不同的处理，后来随着网络技术的发展在Reno算法的基础上出现了New-Reno算法和Sack算法。这些算法都在特定的环境中有效的保证传输的可靠性。\n要实现RTP/TCP传输模式，必须解决以下问题：如何将独立的RTP数据报文完整地传送到接收端，原因是TCP传输机制以数据流的格式传输，数据报文无边界，如果不加以控制，无法得到独立的RTP数据报文，并产生严重的报文丢失。\n本发明在修改上层RTP协议的基础上根据RTP数据报文头部参数提供的数据报文长度对TCP报文中的RTP报文进行分段接收和拼装。\n1.RTP数据报文的分段：为了将RTP数据报文分段，必须在RTP报文头部增加包含RTP数据报文长度的参数，本发明利用RTP原报文头部的参数序列号(Sequence Number)传输RTP报文长度信息。原因如下：使用TCP负载RTP数据报文后，发送端将按照数据报文的顺序依次发送，在接收端，RTP数据报文将被逐一进行确认，并按照发送的顺序依次被接收，因此，RTP/TCP传输模式下，RTP数据报文的传输是严格有序的。RTP协议规定，RTP报文头部参数序列号(Sequence Number)用于数据报文的重新排序，原因是在RTP/UDP模式下，UDP协议无法按照顺序依次传送报文。因此，在RTP/TCP模式下，RTP报文头部参数序列号(SequenceNumber)已经失去意义，因此可以修改Sequence Number参数内容，用Sequence Number参数负载RTP数据报文的长度，实现报文分段。此外，Sequence Number参数在RTP报文头部占用两个字节空间，足以用于传输RTP数据报文的长度。\n2.RTP数据报文的拼装：使用TCP报文负载RTP数据报文所面临的第二个问题是RTP数据报文的拼装，拼装的目的是根据RTP数据报文的长度参数，把接收到的不完整的RTP数据报文进行拼装，保证每一个RTP数据报文的完整性。\n在对RTP报文进行分段后，接收端根据RTP报文头部参数的RTP长度从TCP协议栈读取数据，但是接收函数并不能保证读取的数据报文长度一定是参数规定的所需长度，例如：报文分段或缓冲区溢出都可能导致RTP数据报文不完整。如果TCP协议栈中的RTP数据不完整，接收函数所接收到的数据报文实际长度将小于RTP数据报文长度，对这样的报文如果不进行拼装，将导致上层音视频解码错误，甚至接收端的崩溃。\n实现拼装的工作主要在流媒体接收端，接收端如果检测到所接收数据比实际RTP数据报文长度小，将继续循环接收所缺少长度的数据报文，进行拼接，直至接收到完整的RTP数据报文，这一过程得以实现的前提是TCP的可靠传输机制。\n3.删除RTCP多余的传输控制功能在RTP/TCP模式下，传输控制功能主要由TCP协议完成，RTP中的RTCP协议本身的许多冗余功能应该删除。RTCP数据报文分为5种：(1)SR：发送报告，当前活动发送者发送、接收统计。(2)RR：接收报告，非活动发送者接收统计。(3)SDES：源描述项，包括CNAME。(4)BYE：表示结束。(5)APP：应用特定函数。RTCP执行四大功能：提供数据发布的质量反馈，发送带有称作规范名字的RTP源持久传输层标识，提供用于控制RTCP包数量的数量用语和传送最小连接控制信息。\n使用TCP协议实现控制功能后，RTCP协议的最主要功能：提供数据发布的质量反馈已经没有意义，必须进行删除，因此，发送端和接收端的发送报告SR和接收报告RR将被删除。\n在RTP/UDP传输模式下，RTCP数据控制报文约占报文总数量的5％，而发送报告SR和接收报告RR数据报文占所有RTCP数据控制报文总量的99％。因此，在RTP/TCP传输模式下，由于RTCP只保留了很少的控制功能，将继续使用UDP协议作为底层传输协议，其报文数量不会对网络负载造成影响。\n4.TCP协议中Nagle算法的关闭TCP协议中的Nagle算法规定一个启发式的避免发送特别小的IP报文的算法。Nagle算法通过将未确认的数据存入缓冲区直到蓄足一个包一起发送的方法，来减少主机发送的零碎小数据报文的数目。对于流媒体应用来说，接收端必须按照多媒体数据的顺序依次播放，因此，这种算法将降低系统性能。Nagle算法的超时定时器为200ms，在接收端，由于播放程序对TCP数据，即RTP数据报文的需求是实时的，因此接收程序很有可能在200ms的时间内清空接收缓冲区。导致播放不连续，甚至接收数据报文的不完整。因此，在数据传送之前，应当将Nagle算法关闭。\n本发明的特点及效果：本发明对RTP实时传输协议进行修改，将RTP数据报文头部参数进行修改，用序列号(Sequence Number)参数空间存储RTP报文长度信息，实现RTP数据报文的分段，并配合底层的TCP协议，实现流媒体数据的可靠传输。同时，为了保证传输效率，对RTCP和TCP协议进行了优化配置。\n使用本发明的RTP/TCP传输模式进行流媒体传输，与传统的RTP/UDP传输模式相比，在传输的可靠性方面有很大优势。\n附图说明\n图1为本发明方法的总体流程框图。\n具体实施方式\n本发明提出的基于RTP和TCP协议的流媒体传输实现方法结合附图及其实施例详细说明如下：本实施例的实现方法如图1所示，包括以下步骤包括：1)流媒体发送端对TCP协议进行配置，使用套接字(socket)配置程序将Nagle算法关闭，使TCP数据报文严格按照顺序发送。\n2)修改发送端和接收端RTCP传输控制协议，将负载、处理发送报告SR和接收报告RR的功能删除。\n3)流媒体发送端对RTP报文头部参数序列号(Sequence Number)内容进行修改，使其负载内容由序列号改为数据报文长度Length。\n4)流媒体发送端按照修改后的RTP数据报文头部格式发送数据报文。\n5)媒体接收端根据RTP报文头部参数提供的数据报文长度(Length)对RTP数据报文进行分段接收。\n6)流媒体接收端根据RTP报文头部参数提供的数据报文长度，对接收到的RTP报文进行检验，如果检测到所接收数据比实际RTP数据报文长度小，将继续循环接收所缺少长度的数据报文，直至检测到所接收数据与实际RTP数据报文长度相等，进行拼接，即为完整的RTP数据报文。\n7)流媒体接收端顺序对完整的RTP报文数据进行解码。\n3.运行结果本实施例在局域网环境中用视频点播的方式分别对RTP/TCP流媒体传输模式进行了运行，监视服务器发送状况，播放效果和传输层三方面的情况。\n视频点播码率为512kbps的MPEG4流媒体文件，接收端播放画面流畅，图像清晰。视频点播码率为1100kbps的MPEG4流媒体文件，接收端在整个播放过程中图像流畅，清晰，接收端的跟踪数据显示，没有任何报文丢失现象，也没有因为TCP传输效率和控制机制导致的图像停顿、跳动现象，服务器端的跟踪数据显示，流媒体数据并没有连续发送，而是在TCP控制机制的作用下发送速率有较大波动，甚至短时间的停顿，保证了传输的可靠性。\n本实施例环境：服务器端的硬件配置及操作系统：CPU：Intel PIII 1GHz内存：128M网卡：10M/100M自适应操作系统：RedHat7.1 Linux Server接收端的配置及操作系统：CPU：Intel PIII 800MHz内存：128M网卡：10M/100M自适应操作系统：Windows2000 Professional软件环境：实现本实施例方法的服务器和接收端的Linux流媒体视频服务器系统软件，提供RTP/TCP和RTP/UDP两种流媒体传输模式。为了保证两种传输模式的可比较性，两种传输模式软件仅传输层实现方式有所不同。服务器片源为基于MPEG4编码的可流化视频文件，码率范围为110Kpbs-1100Kpbs。\n本实施例实现了流媒体传输层RTP/TCP模式的设计，证明了RTP/TCP传输模式在流媒体传输可靠性方面的优势。