您当前位置: 首页 » 2019-06-10
按日期归档: 2019-06-10

RUDP的多分支选择

先来说说什么是RUDP,RUDP全称Reliable User Datagram Protocol,译文为可靠的UDP传输。

准确的说RUDP应该是一种概念,而不是某个开源库。他是利用UDP无连接的特性中的优点,通过模拟TCP的可靠性传输来实现。

换句话说,从OSI模型或常规的四层网络模型的角度说,本质上就是一个UDP协议的通讯机制,只不过认为的加入了TCP中的握手、重传等功能。虽然有相应的标准规范给了RUDP一个身份,但可以看做一种应用层协议。

RUDP概念实现的协议有很多,由最初的RUDP库,也有后来用的较多的UDT,也有现在的SRT等等。

UDT:起初在做P2P网络传输的时候,当时用的是UDT(已经停更很久了),现在网上放眼望去也出现很多RUDP概念的实现。这个库据说是,当年提出RUDP概念的作者所做,由于是半路参与P2P传输这块,也就无从得知为何要选择UDT,但后来从UDT的写代码来看,UDT实现的侧重点在于如何模拟TCP进行可靠的传输,并尽量处理好UDP的分组问题,对于传输的效率方便考虑并不是考虑很多。在非实时和大吞吐量传输中还是具备一定的优势(尤其是可靠性方面)。

RUDP(非开源):这是当前接触到的,看着代码不太像网上某个具体的库,而很像多个库中的实现理论依据“粘合”出来。这个代码与业务的耦合性非常高,不是一套纯粹协议栈的代码,其中比较“机智”的利用了业务特性来节省掉纯协议上的可靠性实现,代码看上去要去UDT在协议实现部分会“短小精干”不少,估计在所谓“性能”上应该会比UDT好一些(cpu执行效率,因为要传输音视频数据),但这个库存在的问题实际上要比“UDT”严重很多,因为这套代码并没有在传输上做太大优化,导致在需要做稍微大一点的吞吐时,数据经常被拥塞(堵住)。随着现在带宽越来越大,小运营商也越来越让人抓狂,加上网络承载数据逐渐增加,这套RUDP代码已经不够用了,除了所谓的CPU执行效率较高以外,网络传输效率低的可怜,对带宽的有效利用率非常低。

SRT:从官方的README来看,并通过和最后一个版本的UDT代码做了比较之后发现,事实上SRT的代码确实源自UDT,并且在这个基础上做了ARQ,Buffer控制的改进,加密功能。

并没有完完整整的去看并理解SRT,仅从代码差异上的走马观花式的来看,SRT确实有着跟灵敏的丢包感知和处理,这也是ARQ的一个特性之一。同时在Buffer的控制上,增加了Buffer的双端反馈机制。主观上理解,SRT的吞吐能力应该会比原始的UDT代码弱一些,并且带宽的有效利用率可能会差一些。因为侧重点在于实时性,因此可能会对带宽的有效利用率做出一定的牺牲,在P2P传输场景下,可能还好说,但对于P2SP的情况下,可能会对服务器带宽的需求有一定的增加。

尤其是这个buffer控制,很耐人寻味,没有详细看,不是很清楚有没有特意做了数据的分段/分组优化。

后续还需要认真看看SRT的代码,详细的了解一下整个机制的发挥情况。不过看官方文档的介绍,给人感觉借鉴了不少RTCP/RTP的协议特点。不晓得有没有拿了一些RTSP,毕竟三者是可以放在一起做组合的。

2019-06-10 | | 未分类

RUDP的多分支选择已关闭评论

Why We Created SRT and the Difference Between SRT and UDT

Article Form :
https://www.haivision.com/blog/broadcast-video/created-srt-difference-srt-udt/

Editor’s Note: This post originally appeared on the GitHub Wiki for SRT. It has been slightly modified for formatting. 

Some people have asked us why we’re using the UDT library within our SRT protocol. Actually, some people claimed that SRT is just a slightly modified version of UDT and that UDT is known to be useless for live video transmission. Guess what, the latter is true. UDT has been designed for high throughput file transmission over public networks. However, SRT is far from being a slightly modified version of UDT. I’ll get into the details, but will start with a little bit of history.

Haivision has always been known for lowest latency video transmission across IP based networks — typically MPEG-TS unicast or multicast streams over the UDP protocol. This solution is perfect for protected networks and if packet lossbecame a problem, enabling forward error correction (FEC) fixed it. At some point we were getting questioned as to whether it would be possible to achieve the same latency between customer sites in different locations, between different cities, countries or even continents.

Of course it’s possible with satellite links or dedicated MPLS networks, but those are quite expensive solutions, so people wanted to use their public internet connectivity instead. While it’s possible to go with FEC in some cases, that’s not a reliable solution, as the amount of recoverable packet loss is limited, unless you accept a significant amount of bandwidth overhead.

After evaluating the pros and cons of different third party solutions, we found that none satisfied all our requirements. The lack of insight into the underlying technology drove us to the the decision to develop our own solution, which we then could deeply integrate into products. That way, it would become the “glue” that enables us to transmit streams between all our different products, locally or across far distances, while maintaining our low latency proposition.

There were a few of possible choices to consider:

  • The TCP based approach. Problem for live streaming: Network congestion, too slow packet loss recovery.
  • The UDP based Approach. General problem: Packet lossjitter, packet re-ordering, delay
  • Reliable UDP. Adds framing and selective retransmit.

Having had a history with UDT for data transmission, I remembered its packet loss recovery abilities and just started playing with it. Though not designed for live streaming at all, it kind of worked when using really big buffers. I handed it over to one of our extremely talented networking guys in the embedded software team (thanks, Jean!) and asked him whether he’d be able to make this a low latency live streaming solution. I didn’t hear anything back for quite a while and had almost lost my hope, when he contacted me to tell me he had to rewrite the whole packet retransmissionfunctionality in order to be able to react to packet loss immediately when it happens and that he added an encryption protocol, which he had specified and implemented for other use cases before. Nice 🙂

We started testing sending low latency live streams back and forth between Germany and Montreal and it worked! However, we didn’t get the latency down to a level we had hoped to achieve. The problem we faced turned out to be timing related (as it often is in media).

Bad Signal

What happened was this: 

The characteristics of the original stream on the source network got completely changed by the transmission over the public internet. The reasons are delay, jitterpacket loss and its recovery on the dirty network. The signal on the receiver side had completely different characteristics, which led to problems with decoding, as the audio and video decoders didn’t get the packets at the expected times. This can be handled by buffering, but that’s not what you want in low latency setups.

The solution was to come up with a mechanism that recreates the signal characteristics on the receiver side. That way we were able to dramatically reduce the buffering. This functionality is part of the SRT protocol itself, so once the data comes out of the SRT protocol on the receiver side, the stream characteristics have been properly recovered.

The result is a happy decoder: 

Good Signal

We publicly showed SRT (Secure Reliable Transport) for the first time at IBC 2013, where we were the only ones to show an HEVC encoded live stream, camera to glass, from a hotel suite outside the exhibition directly onto the show floor, using the network provided by the RAI. Everybody who has been at a show like this knows how bad these networks can get. And the network was bad. So bad that we expected the whole demo to fall apart, having pulled the first trial version of SRT directly from the labs. The excitement was huge, when we realized that the transmission still worked fine!

Since then, we added SRT to all our products, enabling us to send high quality, low latency video from and to any endpoint, including our mobile applications. Of course there were improvements to be made and the protocol matured on the way. Until NAB 2017, where we announced that SRT is now Open Source.

You can learn more about SRT at the SRT Alliance website here.

To view the SRT on GitHub and start contributing to this open-source movement, click here!

2019-06-10 | | udt, 网络协议, 音视频_图像相关

Why We Created SRT and the Difference Between SRT and UDT已关闭评论