2011年3月13日星期日

UDP TCP 包头(Headers)和其效率(efficiency)分析

这篇文章将非常简单地讨论UDP TCP 包头(Headers)和它们的效率(efficiency)分析,尽可能的利用图表进行说明。

使用以太网(Ethernet)的一个优点是它具有非常低的错误率。这对UDP很有利,这是因为UDP没有纳入纠错。让我们深入看看一个以太网帧,下图为Ethernet Header:

Ethernet_header

在这个图中我们可以看到,以太网实现FCS(帧校验序列 Frame Check Sequence)。由此产生的头18个字节(Bytes)(4字节的CRC(循环冗余校验 Cyclic redundancy check) + 14字节)。

我们已知的最小的IP header有20 Bytes并且UDP有8 Bytes。如下图所示Packet encapsulation:

UDP_packet_encapsulation 

对比TCP/IP,我们可以得出 28/40 = 40% 更多的header Bytes对比UDP/IP。

由下图可知“n”的最大值为7。 使用这个值, 我们可以得到最大效率(maximum
efficiency), 因为这样是最优的. 更高的值将超出MTU(Maximum Transmission Unit)。

Header RTP with MPEG2-TS encapsulated 如下图所示:

Header RTP with MPEG2-TS

数据长度取决于MPEG2的Codec,但在MPEG2-TS传输中有188Bytes加上4个Bytes的Playload。理论上最高效率:(Ethernet/IP/UDP/RTP/MPEG2-TS)是94%。

mpeg-ts-header

 

以下图表显示了最大理论Efficiency对于TCP/UDP RTP:

Max Theoretically Efficiency

 

参考:

http://en.wikipedia.org/wiki/Internet_Protocol

http://en.wikipedia.org/wiki/Cyclic_redundancy_check

http://en.wikipedia.org/wiki/Frame_Check_Sequence

http://en.wikipedia.org/wiki/MPEG_transport_stream

http://vbrickvip.com/topics/transport_stream.htm

2011年3月10日星期四

为什么RTP往往是使用UDP,而不是使用TCP封装

继续完成“流媒体技术系列”,接上一篇提出的问题:为什么RTP往往是使用UDP,而不是使用TCP封装,接下来简单的解释一下,先摘录一些基本概念,然后使用一个表格进行对比,进一步探讨这个问题。

计算机网络OSI模型中,TCP和UDP为第四层传输层的功能。

简单的说:TCP传输控制协议(Transmission Control Protocol)是基于连接的协议,也就是说,在正式收发数据前,必须和对方建立可靠的连接。TCP协议能为应用程序提供可靠的通信连接,使一台计算机发出的字节流无差错地发往网络上的其他计算机,对可靠性要求高的数据通信系统往往使用TCP协议传输数据。

必须要经过三次“对话”才能建立。
第1次对话
A-->    发连接请求数据包                       -->B

第2次对话
A<--    发送同意连接和要求同步          <--B

第3次对话
A-->    发数据包确认B的要求的同步    -->B

UDP用户数据报协议(User Data Protocol)是与TCP相对应的协议。它是面向非连接的协议,它不与对方建立连接,而是直接就把数据包发送过去!UDP适用于一次只传送少量数据、对可靠性要求不高的应用环境。
UDP例子:“ping”命令测试两台主机之间TCP/IP通信是否正常,就是向对方主机发送UDP数据包,然后对方主机确认收到数据包,如果数据包是否到达的消息及时反馈回来,那么网络就是通的。

几个使用TCP重要的优点
1.TCP速率控(TCP rate control)制有经过证明是具有的稳定性和可扩展性。
2.TCP提供保证delivery, deleting the packet loss efficiently。
3.TCP是可以助于的越过防火墙。
4.流量控制(The flow control)。
5.The transmission windows system有助于优化网络资源的使用。

从网上摘抄一段关于TCP协议的主要功能
TCP协议的主要功能是完成对数据报的确认、流量控制和网络拥塞;自动检测数据报,并提供错误重发的功能;将多条路径传送的数据报按照原来的顺序进行排列,并对重复数据进行择取;控制超时重发,自动调整超时值;提供自动恢复丢失数据的功能。

相对TCP,UDP显然更好地使用于实时应用,原因如下:
1.最低开销(Minimum overhead)。
2.在最大数据从传输速率开始发送。
3.不重复请求,所以就没有重传(一个单一的数据包丢失在一个的实时应用中并不重要)。
4.低处理时间(low processing time)。不需要缓冲(No buffers)。

与TCP不同,UDP并不提供对IP协议的可靠机制、流控制以及错误恢复功能等。由于UDP 比较简单,UDP头包含很少的字节,比TCP负载消耗少。下图为TCP的头和UDP的头的格式:

TCP-Header 

UDP-Header

TCP协议和UDP协议的差别(以表格的形式):

 

  TCP UDP 和流媒体的关系
Header 20 Byte 8 Bytes UDP更好,少overhead
Connection Connection Oriented,在数据传输前需要建立connection。 Connectionless,没有connection需要被建立。 对于Multicast,Connection Oriented是不适合
Reliability 可靠 ACK 不可靠 可靠性比时间延迟(time delay)不重要。TCP会增加延迟
Communication Two-way双向 One way单向

In UDP, RTCP implements the feedback

Errors Error Correction FEC在整个packet Error Correction只在Header Checksum UDP使用较少处理Errors时间
Data flow 控制data flow用于管理下载速度 没有控制

UDP sends to the same data flow as is encoded the media.

Re-transmit 需要Repeat 不需要Repeat Repeat也会产生延迟,不适合实时应用
Delivery Rate 没有预设。TCP将一直增加直到数据丢失或发现堵塞 传输速度和流的编码率相吻合

UDP适应性更好

Client Buffer

Receive buffer
overflow: 如果数据到得太快,receiver发送一个信息给server,使其减慢传输

没有local caching,packet到了媒体播放器直接被处理。

Client Buffers也产生延迟

 

参考:
深入浅出讲解TCP/UDP协议:http://tech.163.com/05/0913/11/1THDB8DO00091589.html
http://zh.wikipedia.org/zh-cn/传输控制协议
http://zh.wikipedia.org/zh-cn/用户数据报协议

2011年3月3日星期四

实时传输协议RTP (Real-time Transport Protocol)

继续完成hanyionet的长期计划,在博客中完成“流媒体技术”系列文章,今天谈谈RTP,其实以前的文章也提到过这个协议。

RTP是一个传输协议,具体制定了数据流如何通过IP网络,并且它是流媒体中最重要的标准。所有的媒体流封装在RTP包。它通常是封装在UDP/IP如下图,并与其他譬如ATM或IPv6协议兼容。

rtp_Location

RTP主要用于实时数据多播(multicast),但它也可用于单播(unicast)(例如,如视频点播单向传输)。

也许我们都有一个疑问,为什么RTP往往是使用UDP,而不是在TCP封装,hanyionet将在以后的文章做一些解释。

 

RTP的特征

RTP提供多媒体应用正确传输所需的信息:时间戳(timestamp),序列编号(sequence numbering),安全(security),内容识别(content identification)和其他机制。这些服务必须在执行应用层(Application level),但它不是RTP所负责。因此,RTP协议只是有助于低层(lower layers)对资源的控制和增加可靠性,流量/拥塞控制(flow/congestion control)与其他机制对于实时信息。

RTP协议传输实时数据包通过网络,这意味着丢失或损坏的数据包将不重发(not retransmitted)。客户端软件要解决这个问题。另一个问题是,如果连接速度(connection speed)比媒体数据传输速率(media data rate)慢,那么传输播放会不佳或者不能播放。

下图为RTP data in an IP packet:

rtp_packet

下图为RTP的Header Format:

rtp_header 

具体说明请查阅:http://en.wikipedia.org/wiki/Real-time_Transport_Protocol

 

RTP是如何工作的?

这其实是我们比较关心的问题。时间戳(timestamp)是实时应用(real-time applications)领域最重要的信息。时间戳将增加,在第一个字节的数据包被传输,并当每一个包被发送它也将增加。接收器(receiver)使用它来重建原始的时间,并且可以使用正确的速率来播放数据。时间戳也可用于同步不同的数据流,不同的时间属性,如音频和视频数据在MPEG中。

另一个重要域是序列号(sequence number)。UDP不提供数据包在一个时序(in timely order),所以有必要使用序列号,是接受的数据包放置传入正确的顺序,用于数据包丢失时的检测。此外,例如,一些视频格式,当一帧分割成几个RTP包,它们都可以有相同的时间戳。

负载类型(payload type)编码/压缩格式(encoding/compression format)是必要的负载识别码(payload identifier)。但是,一个RTP发送者每次传输只可以发送一个有效载荷类型,虽然负载类型(payload type)在传输过程中可能会发生变化,例如,调整网络拥塞。

MTU“最大传输单位”(Maximum Transmission Unit)。也就是通过TCP/IP协议所传输的数据包最大有多少字节,MTU值越大,封包就越大,理论上可增加传送速率,但MTU值又不能设得太大,因为封包太大,传送时出现错误的机会大增。
考虑MTU很重要,不要超过它。因为如果一个RTP包超过MTU,它会被路由器分割,这个过程被称为分裂(fragmentation),如果其中之一丢失了,所有剩余的也将丢失。分裂(fragmentation)也会增加资源的使用。MTU是因网络类型而定,譬如以太网为1500字节。

 

参考资料:
http://www.ietf.org/rfc/rfc1889.txt