精华内容
下载资源
问答
  • 同步传输和异步传输的区别及优缺点同步传输数据块单位...同步传输是一种数据块为传输单位的数据传输方式,该方式下数据块与数据块之间的时间间隔是固定的,必须严格地规定它们的时间关系。每个数据块的头部和...

    同步传输和异步传输的区别及优缺点

    同步传输以数据块为单位进行数据传输,数据块与数据块之间的时间间隔是固定的,每个数据块带有时序信息,接收方可以用时序信息进行校验。

    异步传输一般以字符为单位,接收方通过字符起始和停止码确定接收信息,不需要与发送方按照同一时序工作。

    同步传输是一种以数据块为传输单位的数据传输方式,该方式下数据块与数据块之间的时间间隔是固定的,必须严格地规定它们的时间关系。每个数据块的头部和尾部都要附加一个特殊的字符或比特序列,标记一个数据块的开始和结束,一般还要附加一个校验序列,以便对数据块进行差错控制。

    同步传输是以同步的时钟节拍来发送数据信号的,因此在一个串行的数据流中,各信号码元之间的相对位置都是固定的(即同步的)。

    在同步传输的模式下,数据的传送是以一个数据区块为单位,因此同步传输又称为区块传输。

    在传送数据时,需先送出2个同步字符,然后再送出整批的数据。

    同步传输的比特分组要大得多。它不是独立地发送每个字符,每个字符都有自己的开始位和停止位,而是把它们组合起来一起发送。我们将这些组合称为数据帧,或简称为帧。

    数据帧的第一部分包含一组同步字符,它是一个独特的比特组合,类似于前面提到的起始位,用于通知接收方一个帧已经到达,但它同时还能确保接收方的采样速度和比特的到达速度保持一致,使收发双方进入同步。

    帧的最后一部分是一个帧结束标记。与同步字符一样,它也是一个独特的比特串,类似于前面提到的停止位,用于表示在下一帧开始之前没有别的即将到达的数据了。

    同步传输对收发两端对时间的精确度要求高。 “同步通信”的通信双方必须先建立同步,即双方的时钟要调整到同一个频率。收发双方不停地发送和接收连续的同步比特流。但这时还有两种不同的同步方式。一种是使用全网同步,用一个非常精确的主时钟对全网所有结点上的时钟进行同步。另一种是使用准同步,各结点的时钟之间允许有微小的误差,然后采用其他措施实现同步传输。

    同步传输通常要比异步传输快速得多。接收方不必对每个字符进行开始和停止的操作。一旦检测到帧同步字符,它就在接下来的数据到达时接收它们。另外,同步传输的开销也比较少。例如,一个典型的帧可能有500字节(即4000比特)的数据,其中可能只包含100比特的开销。这时,增加的比特位使传输的比特总数增加2.5%,这与异步传输中25 %的增值要小得多。随着数据帧中实际数据比特位的增加,开销比特所占的百分比将相应地减少。但是,数据比特位越长,缓存数据所需要的缓冲区也越大,这就限制了一个帧的大小。另外,帧越大,它占据传输媒体的连续时间也越长。在极端的情况下,这将导致其他用户等得太久。

    综上,介绍了同步传输,同步传输是以同步的时钟节拍来发送数据信号的,因此在一个串行的数据流中,各信号码元之间的相对位置都是固定的(即同步的)。同步传输通常要比异步传输快速得多。

    异步传输将比特分成小组进行传送,小组可以是8位的1个字符或更长。发送方可以在任何时刻发送这些比特组,而接收方从不知道它们会在什么时候到达。一个常见的例子是计算机键盘与主机的通信。按下一个字母键、数字键或特殊字符键,就发送一个8比特位的ASCII代码。键盘可以在任何时刻发送代码,这取决于用户的输入速度,内部的硬件必须能够在任何时刻接收一个键入的字符。

    异步传输是数据传输的一种方式。由于数据一般是一位接一位串行传输的,例如在传送一串字符信息时,每个字符代码由7位二进制位组成。但在一串二进制位中,每个7位又从哪一个二进制位开始算起呢?异步传输时,在传送每个数据字符之前,先发送一个叫做开始位的二进制位。当接收端收到这一信号时,就知道相继送来7位二进制位是一个字符数据。在这以后,接着再给出1位或2位二进制位,称做结束位。接收端收到结束位后,表示一个数据字符传送结束。这样,在异步传输时,每个字符是分别同步的,即字符中的每个二进制位是同步的,但字符与字符之间的间隙长度是不固定的。

    异步传输一般以字符为单位,不论所采用的字符代码长度为多少位,在发送每一字符代码时,前面均加上一个“起”信号,其长度规定为1个码元,极性为“0”,即空号的极性;字符代码后面均加上一个“止”信号,其长度为1或者2个码元,极性皆为“1”,即与信号极性相同,加上起、止信号的作用就是为了能区分串行传输的“字符”,也就是实现了串行传输收、发双方码组或字符的同步。

    使用异步串口传送一个字符的信息时,对数据格式有如下约定:规定有空闲位、起始位、数据位、奇偶校验位、停止位。

    其中各位的意义如下:

    起始位:先发出一个逻辑”0”信号,表示传输字符的开始。

    数据位:紧接着起始位之后。资料位的个数可以是4、5、6、7、8等,构成一个字符。通常采用ASCⅡ码。从最低位开始传送,靠时钟定位。

    奇偶校验位:资料位加上这一位后,使得“1”的位数应为偶数(偶校验)或奇数(奇校验),以此来校验资料传送的正确性。

    停止位:它是一个字符数据的结束标志。可以是1位、1.5位、2位的高电平。

    空闲位:处于逻辑“1”状态,表示当前线路上没有资料传送。

    波特率:是衡量数据传送速率的指针。表示每秒钟传送的二进制位数。例如资料传送速率为120字符/秒,而每一个字符为10位,则其传送的波特率为10×120=1200位/秒=1200波特。

    注:异步通信是按字符传输的,接收设备在收到起始信号之后只要在一个字符的传输时间内能和发送设备保持同步就能正确接收。下一个字符起始位的到来又使同步重新校准(依靠检测起始位来实现发送与接收方的时钟自同步的)。

    异步传输存在一个潜在的问题,即接收方并不知道数据会在什么时候到达。在它检测到数据并做出响应之前,第一个比特已经过去了。这就像有人出乎意料地从后面走上来跟你说话,而你没来得及反应过来,漏掉了最前面的几个词。因此,每次异步传输的信息都以一个起始位开头,它通知接收方数据已经到达了,这就给了接收方响应、接收和缓存数据比特的时间;在传输结束时,一个停止位表示该次传输信息的终止。按照惯例,空闲(没有传送数据)的线路实际携带着一个代表二进制1的信号,异步传输的开始位使信号变成0,其他的比特位使信号随传输的数据信息而变化。最后,停止位使信号重新变回1,该信号一直保持到下一个开始位到达。例如在键盘上数字“1”,按照8比特位的扩展ASCⅡ编码,将发送“00110001”,同时需要在8比特位的前面加一个起始位,后面一个停止位。

    异步传输的实现比较容易,由于每个信息都加上了“同步”信息,因此计时的漂移不会产生大的积累,但却产生了较多的开销。在上面的例子,每8个比特要多传送两个比特,总的传输负载就增加25%。对于数据传输量很小的低速设备来说问题不大,但对于那些数据传输量很大的高速设备来说,25%的负载增值就相当严重了。因此,异步传输常用于低速设备。

    同步传输方式中发送方和接收方的时钟是统一的、字符与字符间的传输是同步无间隔的。

    异步传输方式并不要求发送方和接收方的时钟完全一样,字符与字符间的传输是异步的。

    区别点

    1,异步传输是面向字符的传输,而同步传输是面向比特的传输。

    2,异步传输的单位是字符而同步传输的单位是帧。

    3,异步传输通过字符起始和停止码抓住再同步的机会,而同步传输则是在数据中抽取同步信息。

    4,异步传输对时序的要求较低,同步传输往往通过特定的时钟线路协调时序。

    5,异步传输相对于同步传输效率较低。

    简单形容

    同步传输就是,数据没有被对方确认收到则调用传输的函数就不返回。

    接收时,如果对方没有发送数据,则你的线程就一直等待,直到有数据了才返回,可以继续执行其他指令

    异步传输就是,你调用一个函数发送数据,马上返回,你可以继续处理其他事,

    接收时,对方的有数据来,你会接收到一个消息,或者你的相关接收函数会被调用。

    形象形容

    异步传输: 你传输吧,我去做我的事了,传输完了告诉我一声

    同步传输: 你现在传输,我要亲眼看你传输完成,才去做别的事

    所有传输介质都易受干扰和由介质本身引进的问题的影响,如电阻和信号衰减。外来干扰可以由背景噪声、大气辐射、机器甚至故障设备引起。受干扰影响的比特数随传输速率的增力而增加,因为在干扰的时帧中涉及到更多的比特。要更正这些问题,需使用检错与纠错方法。

    在奇偶校验时,各组中1的数目必须总是相同(无论奇或偶),以表示一组比特正确无误地传输。逐个字符的检查叫做VRC (垂直冗余校验)。逐块检查叫做LRC(纵向冗余校验)。在传输开始之前,两个系统的奇偶校验方法必须达成一致。有偶校验(1的数目必须为偶数)、奇校验(1的数目必须为奇数)、空号奇偶校验(校验位始终为0)和传号奇偶校验(校验位始终为1)。

    异步通信指两个互不同步的设备通过计时机制或其他技术进行数据传输。异步通信中两个字符之间的时间间隔是不固定的,而在一个字符内各位的时间间隔是固定的。基本上,发送方可以随时传输数据,而接收方必须在信息到达时准备好接收。相反,同步传输是一个精确同步的位流,其中字符的起始是由计时机制来定位的。

    在大量使用异步与同步传输的大型机/终端环境中,异步传输用于传输来自用户周期性按键的终端的字符。接收系统知道等待下一次按键,即使这会花费较多的时间。相反,同步传输用作定期传输大量信息的大型系统之间的数据链路。协议为在公用电话系统上利用慢速链路而进行了优化,因此无关位将从传输中删除,并且时钟用于隔开字符。

    在异步通信中,字符作为比特串编码,由起始位(start bit)、数据位(data bit)、奇偶校验位(parity)和停止位(stop bit)组成。这种用起始位开始,停止位结束所构成的一串信息称为帧(frame)。校验比特有时用于检错和纠错。传输的“起始一停止”模式意味着对于每个新字符,传输都重新从头开始,而消除在上次传输过程中可能出现的任意计时差异。当差异确实出现时,检错和纠错机制能够请求重传。

    在传送一个字符时,由一位低电平的起始位开始,接着传送数据位,数据位的位数为5~8。在传输时,按低位在前,高位在后的顺序传送。奇偶校验位用于检验数据传送的正确性,也可以没有,可由程序来指定。最后传送的是高电平的停止位,停止位可以是1位、1.5位或2位。停止位结束到下一个字符的起始位之间的空闲位要由高电平2来填充(只要不发送下一个字符,线路上就始终为空闲位)。

    异步通信中典型的帧格式是:1位起始位,7位(或8位)数据位,1位奇偶校验位,2位停止位。

    在异步通信中,每接收一个字符,接收方都要重新与发送方同步一次,所以接收端的同步时钟信号并不需要严格地与发送方同步,只要它们在一个字符的传输时间范围内能保持同步即可,这意味着对时钟信号漂移的要求要比同步信号低得多,硬件成本也要低的多,但是异步传送一个字符,要增加大约20%的附加信息位,所以传送效率比较低。异步通信方式简单可靠,也容易实现,故广泛地应用于各种微型机系统中。

    综上,介绍了异步传输,异步传输是数据传输的一种方式。由于数据一般是一位接一位串行传输的,在传送每个数据字符之前,先发送一个叫做开始位的二进制位。当接收端收到这一信号时,就知道相继送来7位二进制位是一个字符数据。在这以后,接着再给出1位或2位二进制位,称做结束位。接收端收到结束位后,表示一个数据字符传送结束。这样,在异步传输时,每个字符是分别同步的,即字符中的每个二进制位是同步的,但字符与字符之间的间隙长度是不固定的。

    展开全文
  • RTP(Real-time Transport Protocol)是由IETF开发的实时传输协议,可以在面向连接或无连接的下层协议上工作,通常和UDP协议一起使用。RTP的工作机理与RSVP不同,主要实现一种端到端的多媒体流同步控制机制,既不...

       RTP(Real-time Transport Protocol)是由IETF开发的实时传输协议,可以在面向连接或无连接的下层协议上工作,通常和UDP协议一起使用。RTP的工作机理与RSVP不同,主要实现一种端到端的多媒体流同步控制机制,既不需要事先建立连接,也不需要中间节点的参与,为其保留资源。在网络带宽充足的情况下,RTP具有一定的带宽调控能力,保证端到端的多媒体流同步。在网络带宽不足时,RTP的带宽调控能力将受到一定的限制。ITU(国际电信联合会)的视频会议标准 H.323采用了RTP协议。

       RTP定义了两种报文:RTP报文和RTCP报文,RTP报文用于传送媒体数据(如音频和视频),它由 RTP报头和数据两部分组成,RTP数据部分称为有效载荷(payload);RTCP报文用于传送控制信息,以实现协议控制功能。RTP报文和RTCP 报文将作为下层协议的数据单元进行传输。如果使用UDP,则RTP报文和RTCP报文分别使用两个相邻的UDP端口,RTP报文使用低端口,RTCP报文使用高端口。如果使用其它的下层协议,RTP报文和RTCP报文可以合并,放在一个数据单元中一起传送,控制信息在前,媒体数据在后。通常,RTP是由应用程序实现的。


    1 RTP报文格式

        RTP报文由两部分组成:报头和有效载荷。RTP报头格式如下图所示,其中:

                     

     ·V:RTP协议的版本号,占2位,当前协议版本号为2。

        ·P:填充标志,占1位,如果P=1,则在该报文的尾部将填充一个或多个额外的八位组,它们不是有效载荷的一部分。

        ·X:扩展标志,占1位,如果X=1,则在RTP报头后跟有一个扩展报头。

        ·CC:CSRC计数器,占 4位,指示CSRC 标识符的个数。

        ·M: 标记,占1位,不同的有效载荷有不同的含义,对于视频,标记一帧的结束;对于音频,标记会话的开始。

        ·PT: 有效载荷类型,占7位,用于说明RTP报文中有效载荷的类型,如GSM音频、JPEM图像等。

        ·序列号:占16位,用于标识发送者所发送的RTP报文的序列号,每发送一个报文,序列号增1。接收者通过序列号来检测报文丢失情况,重新排序报文,恢复数据。

        ·时戳 (Timestamp):占32位,时戳反映了该RTP报文的第一个八位组的采样时刻。接收者使用时戳来计算延迟和延迟抖动,并进行同步控制。

        ·同步信源(SSRC)标识符:占32位,用于标识同步信源。该标识符是随机选择的,参加同一视频会议的两个同步信源不能有相同的SSRC。

        ·特约信源(CSRC)标识符:每个CSRC标识符占32位,可以有0~15个。每个CSRC标识了包含在该RTP报文有效载荷中的所有特约信源。

        这里的同步信源是指产生媒体流的信源,它通过RTP报头中的一个32位数字SSRC标识符来标识,而不依赖于网络地址,接收者将根据SSRC标识符来区分不同的信源,进行RTP报文的分组。特约信源是指当混合器接收到一个或多个同步信源的RTP报文后,经过混合处理产生一个新的组合RTP报文,并把混合器作为组合RTP报文的 SSRC,而将原来所有的SSRC都作为CSRC传送给接收者,使接收者知道组成组合报文的各个SSRC。

        在发送端,上层应用程序以分组形式将编码后的媒体数据传给RTP通信模块,作为RTP报文的有效载荷,RTP通信模块将根据上层应用提供的参数在有效载荷前添加RTP报头,形成 RTP报文,通过Socket接口选择UDP协议发送出去。

        在接收端,RTP通信模块通过Socket接口接收到RTP报文后,将RTP报头分离出来作相应处理,再将RTP报文的有效载荷作为数据分组传递给上层应用。

        考虑到在Internet这种复杂的环境中举行视频会议,RTP定义了两种中间系统:混合器(Mixer)和转换器(Translator)。

        在Internet上举行视频会议时,可能有少数参加者通过低速链路与使用高速网络的多数参加者相连接。为了不强制所有会议参加者都使用低带宽和低质量的数据编码,RTP允许在低带宽区域附近使用混合器作为RTP级中继器。混合器从一个或多个信源接收RTP 报文,对到达的数据报文进行重新同步和重新组合,这些重组的数据流被混合成一个数据流,将数据编码转化为在低带宽上可用的类型,并通过低速链路向低带宽区域转发。为了对多个输入信源进行统一的同步,混合器在多个媒体流之间进行定时调整,产生它自己的定时同步,因此所有从混合器输出的报文都把混合器作为同步信源。为了保证接收者能够正确识别混合器处理前的原始报文发送者,混合器在RTP报头中设置了CSRC标识符队列,以标识那些产生混和报文的原始同步信源。

        在Internet环境中,一些会议的参加者可能被隔离在应用级防火墙的外面,这些参加者被禁止直接使用 IP组播地址进行访问,虽然他们可能是通过高速链路连接的。在这些情况下,RTP允许使用转换器作为RTP级中继器。在防火墙两端分别安装一个转换器,防火墙之外的转换器过滤所有接收到的组播报文,并通过一条安全的连接传送给防火墙之内的转换器,内部转换器将这些组播报文再转发送给内部网络中的组播组成员。


    2 基于RTP的带宽控制方法

        为了实时传输数据,RTP利用了简单而快捷的UDP协议实现网络传输。由于UDP协议是一种无连接传输协议,不保证报文传输的正确性和有序性,也不提供流量控制功能。另一方面,在多媒体通信中,由于多媒体数据的特殊性,不宜采用通常的重传纠错法来提供正确性,而是采用控制传送带宽方式来减少报文丢失,以满足多媒体应用所需的QoS。     在RTP协议中,通过 RTCP报文提供了基于无连接传输协议的端到端控制机制,这是一种基于接收者反馈的网络传输QoS监测机制,在RTCP的接收报告中包含了当前网络传输 QoS有关信息,如报文丢失率、报文丢失累计、接收到的最高序列号、平均延迟抖动以及用于计算发布接收报告往返所需时间的时间标签等。发送者可通过这些信息监测和评价网络传输QoS状况,并可采取适当的策略实施同步控制。 

        RTP协议规定,每个RTP 系统必须实现RTCP的控制功能,由内部功能模块定期自动执行。RTCP报文是轻载信息,其信息量与最低的数据通信量相平衡,它所产生的通信量只是数据通信量的5%左右。

        要实施端到端的强制同步控制,其前提条件是发送端要能够获取网络失调状态信息。一种可行的同步控制策略是:各个接收端将一种轻载的网络失调状态信息(如 QoS参数状态)反馈给发送端,发送端据此进行强制性同步控制,以满足接收端演示质量的要求。 

        基于RTP的带宽控制算法正是利用这种控制策略来实施强制性同步控制的,其基本思想是在RTP协议机制支持下,发送端通过接收端周期反馈的接收报告来评价当前网络传输的QoS,并以此对数据发送速率进行适当调整。端点之间利用RTP报文和RTCP报文来实现带宽控制:

        (1) RTP报文的序号字段可用于排序RTP报文分组,以消除重复分组,保持视频或音频流内同步和连续地播放。

        (2)RTP报文的时戳字段可作为流间同步标识,以保持视频和音频流间同步和连续地播放。 

        (3) 发送者可利用接收者反馈的RTCP报文来制实施端到端的强制性同步控制,以改善当前网络传输的QoS。


    2.1.接收端的控制策略

        接收端通过RTP协议实施如下的控制策略:

            

     

        ①SSRC字段用于标识不同的信源,以支持多对一或多对多的多媒体通信。

       ②时戳字段作为流间同步标识,用于媒体流间的流间控制,以保持视频和音频流间同步和连续地播放,并作为时间量用于计算报文分组的传输延时、延时抖动以及数据更新周期等,滤除严重延时的RTP报文分组。 

        ③序号字段作为流内同步标识,用于排序RTP报文分组,消除重复报文分组,保持视频或音频流内同步和连续地播放。

       ④将接收端检测到的当前网络 QoS状况通过RTCP的接收报告周期地反馈给发送端。 


    2.2.发送端的控制策略

        发送端将采用如下的控制算法来调整传送带宽。

        ①设bs为发送端当前的带宽,bmin和bmax分别为应用所设置的最小带宽和最大带宽,且bs?[bmin,bmax]。

       ②在每个发送带宽级上保持一个时间片,超时后将根据网络QoS状况提高或降低一个带宽级,以避免带宽频繁波动。这里使用报文丢失率作为QoS指示器,并设置一个阈值。如果QoS指示器超阈,说明网络发生阻塞,通过改变发送速率来调整传送带宽,疏导网络交通。 

        ③初始时按最大带宽发送报文分组,即bs?bmax,以提高网络通道的利用率。

        ④如果在规定的时间片内 QoS指示器超阈,说明网络发生阻塞,则在超时后需要降低一个带宽级,即bs? max { bs-μ, bmin },其中μ为比例因子。

       ⑤如果在规定的时间片内 QoS指示器未超阈,说明网络交通状况良好,则在超时后应当提高一个带宽级,即bs? min { bs+μ, bmax }。 

        ⑥在点到多点通信场合中,发送者将面对多个不同网段上的接收者,而每个网段的交通状况又不尽相同。因此,在改变带宽时可采用多数表决法,即当报文丢失率超阈的接收者超过一定比例时再改变带宽。

        这种方法的特点是:利用 RTP协议机制来传送网络状态信息,不需要另外构造网络检测机构,易于实现;RTCP报文是一种轻载报文,占用较少的通信带宽。


    RTP与RTCP协议介绍

    1流媒体( Streaming Media)

    1.1流媒体概念

    流媒体技术是网络技术和多媒体技术发展到一定阶段的产物。术语流媒体既可以指在网上传输连续时基媒体的流式技术,也可以指使用流式技术的连续时基媒体本身。在网上传输音频、视频等多媒体信息目前主要有两种方式:下载和流式传输。采用下载方式,用户需要先下载整个媒体文件,然后才能进行播放。由于网络带宽的限制,下载常常要花很长时间,所以这种处理方式延迟很大。而流媒体实现的关键技术是流式传输。传输之前首先对多媒体进行预处理(降低质量和高效压缩) ,然后使用缓存系统来保证数据连续正确地进行传输。使用流式传输方式,用户不必像采用下载方式那样要等到整个文件全部下载完毕,而是只需经过几秒到几十秒的启动延时即可在客户端进行播放和观看。此时媒体文件的剩余部分将在后台继续下载。与单纯的下载方式相比,这种对多媒体文件边下载边播放的流式传输方式不仅使启动延时大幅度地缩短,而且对系统缓存容量的需求也大大降低。使用流式传输的另一个好处是使传输那些事先不知道或无法知道大小的媒体数据(如网上直播、视频会议等) 成为可能。

    到目前为止,Internet 上使用较多的流式视频格式主要有以下三种:RealNetworks 公司的RealMedia ,Apple 公司的QuickTime 以及Microsoft 公司的Advanced Streaming Format (ASF) 。

     

    1.2支持流媒体的协议

    多媒体应用的一个显著特点是数据量大,并且许多应用对实时性要求比较高。传统的TCP 协议是一个面向连接的协议,它的重传机制和拥塞控制机制都是不适用于实时多媒体传输的。RTP 是一个应用型的传输层协议,它并不提供任何传输可靠性的保证和流量的拥塞控制机制。RTP 位于UDP(User Datagram Protocol) 之上。UDP 虽然没有TCP 那么可靠,并且无法保证实时业务的服务质量,需要RTCP 实时监控数据传输和服务质量。但是,由于UDP 的传输时延低于TCP ,能与音频和视频很好地配合。因此,在实际应用中,RTP/ RTCP/ UDP 用于音频/ 视频媒体,而TCP 用于数据和控制信令的传输。目前,支持流媒体传输的协议主要有实时传输协议RTP( Real-Time Transport Protocol) 、实时传输控制协议RTCP(Real-Time Transport Control Protocol) 和实时流协议RTSP(Real-Time Streaming Protocol) 等。下面分别对这三种协议作简要介绍。流媒体协议栈如图1 所示。

    图1 流媒体协议栈

     

     

    2实时传输协议RTP(Real-Time Transport Protocol):

    RTP是针对Internet上多媒体数据流的一个传输协议, 由IETF(Internet工程任务组)作为RFC1889发布。RTP被定义为在一对一或一对多的传输情况下工作,其目的是提供时间信息和实现流同步。RTP的典型应用建立在UDP上,但也可以在TCP或ATM等其他协议之上工作。RTP本身只保证实时数据的传输,并不能为按顺序传送数据包提供可靠的传送机制,也不提供流量控制或拥塞控制,它依靠RTCP提供这些服务。

     

    2.1 RTP工作机制

    威胁多媒体数据传输的一个尖锐的问题就是不可预料数据到达时间。但是流媒体的传输是需要数据的适时的到达用以播放和回放。rtp协议就是提供了时间标签,序列号以及其它的结构用于控制适时数据的流放。在流的概念中”时间标签”是最重要的信息。发送端依照即时的采样在数据包里隐蔽的设置了时间标签。在接受端收到数据包后,就依照时间标签按照正确的速率恢复成原始的适时的数据。不同的媒体格式调时属性是不一样的。但是rtp本身并不负责同步,rtp只是传输层协议,为了简化运输层处理,提高该层的效率。将部分运输层协议功能(比如流量控制)上移到应用层完成。同步就是属于应用层协议完成的。它没有运输层协议的完整功能,不提供任何机制来保证实时地传输数据,不支持资源预留,也不保证服务质量。rtp报文甚至不包括长度和报文边界的描述。同时rtp协议的数据报文和控制报文的使用相邻的不同端口,这样大大提高了协议的灵活性和处理的简单性。

    rtp协议和udp二者共同完成运输层协议功能。udp协议只是传输数据包,不管数据包传输的时间顺序。 rtp的协议数据单元是用udp分组来承载的。在承载rtp数据包的时候,有时候一帧数据被分割成几个包具有相同的时间标签,则可以知道时间标签并不是必须的。而udp的多路复用让rtp协议利用支持显式的多点投递,可以满足多媒体会话的需求。

    rtp协议虽然是传输层协议但是它没有作为osi体系结构中单独的一层来实现。rtp协议通常根据一个具体的应用来提供服务,rtp只提供协议框架,开发者可以根据应用的具体要求对协议进行充分的扩展。

     

    2.2  RTP协议的报文结构

    RTP头格式如图2所示:

     

     

    开始12个八进制出现在每个RTP包中,而CSRC标识列表仅出现在混合器插入时。各段含义如下:

    ①版本(V)

    2位,标识RTP版本。

     

    ②填充标识(P)

    1位,如设置填充位,在包尾将包含附加填充字,它不属于有效载荷。填充的最后一个八进制包含应该忽略的八进制计数。某些加密算法需要固定大小的填充字,或为在底层协议数据单元中携带几个RTP包。

     

    ③扩展(X)

    1位,如设置扩展位,固定头后跟一个头扩展。

     

    ④CSRC计数(CC)

    4位,CSRC计数包括紧接在固定头后CSRC标识符个数。

     

    ⑤标记(M)

    1位,标记解释由设置定义,目的在于允许重要事件在包流中标记出来。设置可定义其他标示位,或通过改变位数量来指定没有标记位。

     

    ⑥载荷类型(PT)

    7位,记录后面资料使用哪种 Codec , receiver 端找出相应的 decoder 解碼出來。

     

    常用 types:

    Payload Type

    Codec

    0

    PCM μ -Law

    8

    PCM-A Law

    9

    G..722 audio codec

    4

    G..723 audio codec

    15

    G..728 audio codec

    18

    G..729 audio codec

    34

    G..763 audio codec

    31

    G..761 audio codec

     

    ⑦系列号

    16位,系列号随每个RTP数据包而增加1,由接收者用来探测包损失。系列号初值是随机的,使对加密的文本攻击更加困难。

     

    ⑧时标

    32位,时标反映RTP数据包中第一个八进制数的采样时刻,采样时刻必须从单调、线性增加的时钟导出,以允许同步与抖动计算。时标可以让receiver端知道在正确的时间将资料播放出来。

     

    由上图可知,如果只有系列号,并不能完整按照顺序的将data播放出来,因为如果data中间有一段是没有资料的,只有系列号的话会造成错误,需搭配上让它知道在哪个时间将data正确播放出来,如此我们才能播放出正确无误的信息。

     

    ⑨SSRC

    32位,SSRC段标识同步源。此标识不是随机选择的,目的在于使同一RTP包连接中没有两个同步源有相同的SSRC标识。尽管多个源选择同一个标识的概率很低,所有RTP实现都必须探测并解决冲突。如源改变源传输地址,也必须选择一个新SSRC标识以避免插入成环行源。

     

    ⑩CSRC列表

    0到15项,每项32位。CSRC列表表示包内的对载荷起作用的源。标识数量由CC段给出。如超出15个作用源,也仅标识15个。CSRC标识由混合器插入,采用作用源的SSRC标识。

     

    3.实时传输控制协议RTCP(Real-Time Transport Control Protocol)

    RTCP负责管理传输质量在当前应用进程之间交换控制信息。在RTP会话期间,各参与者周期性地传送RTCP包,包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料。因此,服务器可以利用这些信息动态地改变传输速率,甚至改变有效载荷类型。RTP和RTCP配合使用,能以有效的反馈和最小的开销使传输效率最佳化,故特别适合传送网上的实时数据。

     

    3.1 RTCP工作机制

    当应用程序开始一个rtp会话时将使用两个端口:一个给rtp,一个给rtcp。rtp本身并不能为按顺序传送数据包提供可靠的传送机制,也不提供流量控制或拥塞控制,它依靠rtcp提供这些服务。在rtp的会话之间周期的发放一些rtcp包以用来传监听服务质量和交换会话用户信息等功能。rtcp包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料。因此,服务器可以利用这些信息动态地改变传输速率,甚至改变有效载荷类型。rtp和rtcp配合使用,它们能以有效的反馈和最小的开销使传输效率最佳化,因而特别适合传送网上的实时数据。根据用户间的数据传输反馈信息,可以制定流量控制的策略,而会话用户信息的交互,可以制定会话控制的策略。

     

    3.2 RTCP数据报

    在RTCP通信控制中,RTCP协议的功能是通过不同的RTCP数据报来实现的,主要有如下几种类型:

    ①SR:发送端报告,所谓发送端是指发出RTP数据报的应用程序或者终端,发送端同时也可以是接收端。

    ②RR:接收端报告,所谓接收端是指仅接收但不发送RTP数据报的应用程序或者终端。

    ③SDES:源描述,主要功能是作为会话成员有关标识信息的载体,如用户名、邮件地址、电话号码等,此外还具有向会话成员传达会话控制信息的功能。

    ④BYE:通知离开,主要功能是指示某一个或者几个源不再有效,即通知会话中的其他成员自己将退出会话。

    ⑤APP:由应用程序自己定义,解决了RTCP的扩展性问题,并且为协议的实现者提供了很大的灵活性。

     

    4资源预订协议RSVP (Resorce Reservation Protocol)

    由于音频和视频数据流比传统数据对网络的延时更敏感,要在网络中传输高质量的音频、视频信息,除带宽要求之外,还需其他更多的条件。RSVP是Internet上的资源预订协议,使用RSVP预留部分网络资源(即带宽),能在一定程度上为流媒体的传输提供QoS。


     

    第1章.     RTP概述

    1.1.  RTP是什么

    RTP全名是Real-time Transport Protocol(实时传输协议)。它是IETF提出的一个标准,对应的RFC文档为RFC3550(RFC1889为其过期版本)。RFC3550不仅定义了RTP,而且定义了配套的相关协议RTCP(Real-time Transport Control Protocol,即实时传输控制协议)。RTP用来为IP网上的语音、图像、传真等多种需要实时传输的多媒体数据提供端到端的实时传输服务。RTP为Internet上端到端的实时传输提供时间信息和流同步,但并不保证服务质量,服务质量由RTCP来提供。

    1.2.  RTP的应用环境

    RTP用于在单播或多播网络中传送实时数据。它们典型的应用场合有如下几个。

    简单的多播音频会议。语音通信通过一个多播地址和一对端口来实现。一个用于音频数据(RTP),另一个用于控制包(RTCP)。

    音频和视频会议。如果在一次会议中同时使用了音频和视频会议,这两种媒体将分别在不同的RTP会话中传送,每一个会话使用不同的传输地址(IP地址+端口)。如果一个用户同时使用了两个会话,则每个会话对应的RTCP包都使用规范化名字CNAME(Canonical Name)。与会者可以根据RTCP包中的CNAME来获取相关联的音频和视频,然后根据RTCP包中的计时信息(Network time protocol)来实现音频和视频的同步。

    翻译器和混合器。翻译器和混合器都是RTP级的中继系统。翻译器用在通过IP多 播不能直接到达的用户区,例如发送者和接收者之间存在防火墙。当与会者能接收的音频编码格式不一样,比如有一个与会者通过一条低速链路接入到高速会议,这 时就要使用混合器。在进入音频数据格式需要变化的网络前,混合器将来自一个源或多个源的音频包进行重构,并把重构后的多个音频合并,采用另一种音频编码进 行编码后,再转发这个新的RTP包。从一个混合器出来的所有数据包要用混合器作为它们的同步源(SSRC,见RTP的封装)来识别,可以通过贡献源列表(CSRC表,见RTP的封装)可以确认谈话者。

    1.3.  相关概念

    1.3.1.  流媒体

    流媒体是指Internet上使用流式传输技术的连续时基媒体。当前在Internet上传输音频和视频等信息主要有两种方式:下载和流式传输两种方式。

    下载情况下,用户需要先下载整个媒体文件到本地,然后才能播放媒体文件。在视频直播等应用场合,由于生成整个媒体文件要等直播结束,也就是用户至少要在直播结束后才能看到直播节目,所以用下载方式不能实现直播。

    流式传输是实现流媒体的关键技术。使用流式传输可以边下载边观看流媒体节目。由于Internet是基于分组传输的,所以接收端收到的数据包往往有延迟和乱序(流式传输构建在UDP上)。要实现流式传输,就是要从降低延迟和恢复数据包时序入手。在发送端,为降低延迟,往往对传输数据进行预处理(降低质量和高效压缩)。在接收端为了恢复时序,采用了接收缓冲;而为了实现媒体的流畅播放,则采用了播放缓冲。

    使用接收缓冲,可以将接收到的数据包缓存起来,然后根据数据包的封装信息(如包序号和时戳等),将乱序的包重新排序,最后将重新排序了的数据包放入播放缓冲播放。

    为什么需要播放缓冲呢?容易想到,由于网络不可能很理想,并且对数据包排序需要处理时耗,我们得到排序好的数据包的时间间隔是不等的。如果不用播放缓冲,那么播放节目会很卡,这叫时延抖动。相反,使用播放缓冲,在开始播放时,花费几十秒钟先将播放缓冲填满(例如PPLIVE),可以有效地消除时延抖动,从而在不太损失实时性的前提下实现流媒体的顺畅播放。

    到目前为止,Internet 上使用较多的流式视频格式主要有以下三种:RealNetworks 公司的RealMedia ,Apple 公司的QuickTime 以及Microsoft 公司的Advanced Streaming Format (ASF) 。

    上面在谈接收缓冲时,说到了流媒体数据包的封装信息(包序号和时戳等),这在后面的RTP封装中会有体现。另外,RealMedia这些流式媒体格式只是编解码有不同,但对于RTP来说,它们都是待封装传输的流媒体数据而没有什么不同。

    第2章.     RTP详解

    2.1.  RTP的协议层次

    2.1.1.  传输层的子层

    RTP(实时传输协议),顾名思义它是用来提供实时传输的,因而可以看成是传输层的一个子层。图 1给出了流媒体应用中的一个典型的协议体系结构。

     

    图 1 流媒体体系结构

    从图中可以看出,RTP被划分在传输层,它建立在UDP上。同UDP协议一样,为了实现其实时传输功能,RTP也有固定的封装形式。RTP用来为端到端的实时传输提供时间信息和流同步,但并不保证服务质量。服务质量由RTCP来提供。这些特点,在第4章可以看到。

    2.1.2.  应用层的一部分

    不少人也把RTP归为应用层的一部分,这是从应用开发者的角度来说的。操作系统中的TCP/IP等协议栈所提供的是我们最常用的服务,而RTP的实现还是要靠开发者自己。因此从开发的角度来说,RTP的实现和应用层协议的实现没不同,所以可将RTP看成应用层协议。

    RTP实现者在发送RTP数据时,需先将数据封装成RTP包,而在接收到RTP数据包,需要将数据从RTP包中提取出来。

    2.2.  RTP的封装

    一个协议的封装是为了满足协议的功能需求的。从前面提出的功能需求,可以推测出RTP封装中应该有同步源和时戳等字段,但更为完整的封装是什么样子呢?请看图2。

    图 2 RTP的头部格式

    版本号(V):2比特,用来标志使用的RTP版本。

    填充位(P):1比特,如果该位置位,则该RTP包的尾部就包含附加的填充字节。

    扩展位(X):1比特,如果该位置位的话,RTP固定头部后面就跟有一个扩展头部。

    CSRC计数器(CC):4比特,含有固定头部后面跟着的CSRC的数目。

    标记位(M):1比特,该位的解释由配置文档(Profile)来承担.

    载荷类型(PT):7比特,标识了RTP载荷的类型。

    序列号(SN):16比特,发送方在每发送完一个RTP包后就将该域的值增加1,接收方可以由该域检测包的丢失及恢复包序列。序列号的初始值是随机的。

    时间戳:32比特,记录了该包中数据的第一个字节的采样时刻。在一次会话开始时,时间戳初始化成一个初始值。即使在没有信号发送时,时间戳的数值也要随时间而不断地增加(时间在流逝嘛)。时间戳是去除抖动和实现同步不可缺少的。

    同步源标识符(SSRC):32比特,同步源就是指RTP包流的来源。在同一个RTP会话中不能有两个相同的SSRC值。该标识符是随机选取的 RFC1889推荐了MD5随机算法。

    贡献源列表(CSRC List):0~15项,每项32比特,用来标志对一个RTP混合器产生的新包有贡献的所有RTP包的源。由混合器将这些有贡献的SSRC标识符插入表中。SSRC标识符都被列出来,以便接收端能正确指出交谈双方的身份。

    2.3.  RTCP的封装

    RTP需要RTCP为其服务质量提供保证,因此下面介绍一下RTCP的相关知识。

    RTCP的主要功能是:服务质量的监视与反馈、媒体间的同步,以及多播组中成员的标识。在RTP会话期间,各参与者周期性地传送RTCP包。RTCP包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料,因此,各参与者可以利用这些信息动态地改变传输速率,甚至改变有效载荷类型。RTP和RTCP配合使用,它们能以有效的反馈和最小的开销使传输效率最佳化,因而特别适合传送网上的实时数据。

    从图 1可以看到,RTCP也是用UDP来传送的,但RTCP封装的仅仅是一些控制信息,因而分组很短,所以可以将多个RTCP分组封装在一个UDP包中。RTCP有如下五种分组类型。

    类型

    缩写表示

    用途

    200

    SR(Sender Report)

    发送端报告

    201

    RR(Receiver Report)

    接收端报告

    202

    SDES(Source Description Items)

    源点描述

    203

    BYE

    结束传输

    204

    APP

    特定应用

    表 1 RTCP的5种分组类型

    上述五种分组的封装大同小异,下面只讲述SR类型,而其它类型请参考RFC3550。

    发送端报告分组SR(Sender Report)用来使发送端以多播方式向所有接收端报告发送情况。SR分组的主要内容有:相应的RTP流的SSRC,RTP流中最新产生的RTP分组的时间戳和NTP,RTP流包含的分组数,RTP流包含的字节数。SR包的封装如图3所示。

    图 3 RTCP头部的格式

    版本(V):同RTP包头域。

    填充(P):同RTP包头域。

    接收报告计数器(RC):5比特,该SR包中的接收报告块的数目,可以为零。

    包类型(PT):8比特,SR包是200。

    长度域(Length):16比特,其中存放的是该SR包以32比特为单位的总长度减一。

    同步源(SSRC):SR包发送者的同步源标识符。与对应RTP包中的SSRC一样。

    NTP Timestamp(Network time protocol)SR包发送时的绝对时间值。NTP的作用是同步不同的RTP媒体流。

    RTP Timestamp:与NTP时间戳对应,与RTP数据包中的RTP时间戳具有相同的单位和随机初始值。

    Sender’s packet count:从开始发送包到产生这个SR包这段时间里,发送者发送的RTP数据包的总数. SSRC改变时,这个域清零。

    Sender`s octet count:从开始发送包到产生这个SR包这段时间里,发送者发送的净荷数据的总字节数(不包括头部和填充)。发送者改变其SSRC时,这个域要清零。

    同步源n的SSRC标识符:该报告块中包含的是从该源接收到的包的统计信息。

    丢失率(Fraction Lost):表明从上一个SR或RR包发出以来从同步源n(SSRC_n)来的RTP数据包的丢失率。

    累计的包丢失数目:从开始接收到SSRC_n的包到发送SR,从SSRC_n传过来的RTP数据包的丢失总数。

    收到的扩展最大序列号:从SSRC_n收到的RTP数据包中最大的序列号,

    接收抖动(Interarrival jitter):RTP数据包接受时间的统计方差估计

    上次SR时间戳(Last SR,LSR):取最近从SSRC_n收到的SR包中的NTP时间戳的中间32比特。如果目前还没收到SR包,则该域清零。

    上次SR以来的延时(Delay since last SR,DLSR):上次从SSRC_n收到SR包到发送本报告的延时。

    2.4.  RTP的会话过程

    当应用程序建立一个RTP会话时,应用程序将确定一对目的传输地址。目的传输地址由一个网络地址和一对端口组成,有两个端口:一个给RTP包,一个给RTCP包,使得RTP/RTCP数据能够正确发送。RTP数据发向偶数的UDP端口,而对应的控制信号RTCP数据发向相邻的奇数UDP端口(偶数的UDP端口+1),这样就构成一个UDP端口对。 RTP的发送过程如下,接收过程则相反。

    1)        RTP协议从上层接收流媒体信息码流(如H.263),封装成RTP数据包;RTCP从上层接收控制信息,封装成RTCP控制包。

    2)        RTP将RTP 数据包发往UDP端口对中偶数端口;RTCP将RTCP控制包发往UDP端口对中的接收端口。

    第3章.     相关的协议

    3.1.  实时流协议RTSP

    实时流协议RTSP(Real-Time Streaming Protocol)是IETF提出的协议,对应的RFC文档为RFC2362。

    从图 1可以看出,RTSP是一个应用层协议(TCP/IP网络体系中)。它以C/S模式工作,它是一个多媒体播放控制协议,主要用来使用户在播放流媒体时可以像操作本地的影碟机一样进行控制,即可以对流媒体进行暂停/继续、后退和前进等控制。

    3.2.  资源预定协议RSVP

    资源预定协议RSVP(Resource Reservation Protocol)是IETF提出的协议,对应的RFC文档为RFC2208。

    从图 1可以看出,RSVP工作在IP层之上传输层之下,是一个网络控制协议。RSVP通过在路由器上预留一定的带宽,能在一定程度上为流媒体的传输提供服务质量。在某些试验性的系统如网络视频会议工具vic中就集成了RSVP。

    第4章.     常见的疑问

    4.1.  怎样重组乱序的数据包

    可以根据RTP包的序列号来排序。

    4.2.  怎样获得数据包的时序

    可以根据RTP包的时间戳来获得数据包的时序。

    4.3.  声音和图像怎么同步

    根据声音流和图像流的相对时间(即RTP包的时间戳),以及它们的绝对时间(即对应的RTCP包中的RTCP),可以实现声音和图像的同步。

    4.4.  接收缓冲和播放缓冲的作用

    如1.3.1所述,接收缓冲用来排序乱序了的数据包;播放缓冲用来消除播放的抖动,实现等时播放。

    第5章.     实现方案

    ID

    Protocol

    Captured contents

    Account

    password

    Local telephone

    number

    Opponents

    Telephone

    Number

    audio

    login

    logout

    36

    Rtp

     

     

     

     

     

     

    表 2 协议分析要求

    表 2给出了协议分析要求。容易看出要获取RTP音频包中的音频信息很容易,直接将RTP包的包头去掉即可。当然,要成功地播放解码获取到的音频流,需要知道其编码,这可从RTP包包头的有效载荷类型字段(PT)获得。

    第6章.     参考资料

    [1]      RFC文档:RFC3550对应RTP/RTCP,RFC2362对应RTSP,RFC2208对应RSVP

    [2]      http://www.faqs.org/rfcs/,上面有全面的英文RFC文档

    [3]      http://www.cnpaf.net/,有不少协议分析文档,也有中文RFC文档,但质量不是特别高。


    RTP传输中的时间戳

        首先,了解几个基本概念:

        时间戳单位:时间戳计算的单位不是秒之类的单位,而是由采样频率所代替的单位,这样做的目的就是为了是时间戳单位更为精准。比如说一个音频的采样频率为8000Hz,那么我们可以把时间戳单位设为1 / 8000。
        时间戳增量:相邻两个RTP包之间的时间差(以时间戳单位为基准)。
        采样频率:  每秒钟抽取样本的次数,例如音频的采样率一般为8000Hz
        帧率:      每秒传输或者显示帧数,例如25f/s

        再看看RTP时间戳课本中的定义:


        RTP包头的第2个32Bit即为RTP包的时间戳,Time Stamp ,占32位。
        时间戳反映了RTP分组中的数据的第一个字节的采样时刻。在一次会话开始时的时间戳初值也是随机选择的。即使是没有信号发送时,时间戳的数值也要随时间不 断的增加。接收端使用时间戳可准确知道应当在什么时间还原哪一个数据块,从而消除传输中的抖动。时间戳还可用来使视频应用中声音和图像同步。
        在RTP协议中并没有规定时间戳的粒度,这取决于有效载荷的类型。因此RTP的时间戳又称为媒体时间戳,以强调这种时间戳的粒度取决于信号的类型。例如, 对于8kHz采样的话音信号,若每隔20ms构成一个数据块,则一个数据块中包含有160个样本(0.02×8000=160)。因此每发送一个RTP分 组,其时间戳的值就增加160。

        官方的解释看懂没?没看懂?没关系,我刚开始也没看懂,那就听我的解释吧。

        首先,时间戳就是一个值,用来反映某个数据块的产生(采集)时间点的,后采集的数据块的时间戳肯定是大于先采集的数据块的。有了这样一个时间戳,就可以标记数据块的先后顺序。
        第二,在实时流传输中,数据采集后立刻传递到RTP模块进行发送,那么,其实,数据块的采集时间戳就直接作为RTP包的时间戳。
        第三,如果用RTP来传输固定的文件,则这个时间戳就是读文件的时间点,依次递增。这个不再我们当前的讨论范围内,暂时不考虑。
        第四,时间戳的单位采用的是采样频率的倒数,例如采样频率为8000Hz时,时间戳的单位为1 / 8000 ,在Jrtplib库中,有设置时间戳单位的函数接口,而ORTP库中根据负载类型直接给定了时间戳的单位(音频负载1/8000,视频负载1/90000)
        第五,时间戳增量是指两个RTP包之间的时间间隔,详细点说,就是发送第二个RTP包相距发送第一个RTP包时的时间间隔(单位是时间戳单位)。
        如果采样频率为90000Hz,则由上面讨论可知,时间戳单位为1/90000,我们就假设1s钟被划分了90000个时间块,那么,如果每秒发送25 帧,那么,每一个帧的发送占多少个时间块呢?当然是 90000/25 = 3600。因此,我们根据定义“时间戳增量是发送第二个RTP包相距发送第一个RTP包时的时间间隔”,故时间戳增量应该为3600。
        在 Jrtplib中好像不需要自己管理时间戳的递增,由库内部管理。但在ORTP中每次数据的发送都需要自己传入时间戳的值,即自己需要每次发完一个RTP 包后,累加时间戳增量,不是很方便,这就需要自己对RTP的时间戳有比较深刻地理解,我刚开始就是因为没搞清楚,随时设置时间戳增量导致传输一直有问题, 困扰我好久。


    为什么要使用RTP

    一提到流媒体传输、一谈到什么视频监控、视频会议、语音电话(VOIP),都离不开RTP协议的应用,但当大家都根据经验或者别人的应用而选择RTP协议的时候,你可曾想过,为什么我们要使用RTP来进行流媒体的传输呢?为什么我们一定要用RTP?难道TCP、UDP或者其他的网络协议不能达到我们的要求么?

    本文就是根据我在RTP协议的学习和应用过程中整理出来的思考,希望对大家有所启发,同时,也欢迎大家留言探讨,提出自己的想法和思考。

    1.      维基百科的相关解释

    Reliable protocols, such as the Transmission Control Protocol (TCP), guarantee correct delivery of each bit in the media stream. However, they accomplish this with a system of timeouts and retries, which makes them more complex to implement. It also means that when there is data loss on the network, the media stream stalls while the protocol handlers detect the loss and retransmit the missing data. Clients can minimize this effect by buffering data for display. While delay due to buffering is acceptable in video on demand scenarios, users of interactive applications such as video conferencing will experience a loss of fidelity if the delay that buffering contributes to exceeds 200 ms.

    像TCP这样的可靠传输协议,通过超时和重传机制来保证传输数据流中的每一个bit的正确性,但这样会使得无论从协议的实现还是传输的过程都变得非常的复杂。而且,当传输过程中有数据丢失的时候,由于对数据丢失的检测(超时检测)和重传,会数据流的传输被迫暂停和延时。

    或许你会说,我们可以利用客户端构造一个足够大的缓冲区来保证显示的正常,这种方法对于从网络播放音视频来说是可以接受的,但是对于一些需要实时交互的场合(如视频聊天、视频会议等),如果这种缓冲超过了200ms,将会产生难以接受的实时性体验。

    2.  为什么RTP可以解决上述时延问题

    RTP协议是一种基于UDP的传输协议,RTP本身并不能为按顺序传送数据包提供可靠的传送机制,也不提供流量控制或拥塞控制,它依靠RTCP提供这些服务。这样,对于那些丢失的数据包,不存在由于超时检测而带来的延时,同时,对于那些丢弃的包,也可以由上层根据其重要性来选择性的重传。比如,对于I帧、P帧、B帧数据,由于其重要性依次降低,故在网络状况不好的情况下,可以考虑在B帧丢失甚至P帧丢失的情况下不进行重传,这样,在客户端方面,虽然可能会有短暂的不清晰画面,但却保证了实时性的体验和要求。

    3. 多播功能

    多播在网络视频会议方面有着很广泛的应用,它主要应用于这样一种环境,即:

     

    假 设红色的圆为存放有视频数据的流媒体服务器,其他的圆为连接到该服务器的各个客户端,当所有的绿色的客户端要求同时观看红色服务器上的某一个视频时,如果 服务器为每一路客户端单独建立连接进行数据的传输,这样明显不太合理浪费带宽,因此,多播技术可以很好地解决这种问题,即同一份数据,由服务器发送到公共 的多播地址,各个客户端均监听同一个多播地址来获取数据,这样,既节省了带宽,同时也保证了各个客户端所观看的视频的同步。

    这样的多播应用TCP协议是不支持的,而RTP协议在最初就是为了实现类似的视频会议的应用而诞生的,对其有非常好的支持。

    4.  RTP包头中的流媒体特性

    首先,我们看看RTP的包头。

     

    V ― 版本。识别 RTP 版本。

    P ― 填充。设置1时,数据包包含一个或多个附加填充比特,填充比特不属于有效载荷。
         X ― 扩展位。设置1时,在固定头后面,跟随一个头扩展。
         CSRC Count ― 包含 CSRC 标识符(在固定头后)的数目。
         M ― 标志。标志由描述文件(profile)文件定义。允许在比特流中标记重要的事件,如帧边界。

    Payload Type ― 负载类型。由具体的应用决定其解释。某些profile 文件规定了从 Payload 编码到 Payload 格式的缺省静态映射。另外的 Payload Type 编码也可以通过非 RTP 方法实现动态定义。

    Sequence Number ― 序列号。每发送一个 RTP 数据包,序列号增加1。接收端可以据此检测丢包和重建包序列。

    Timestamp ―时间戳。反映了RTP 数据包中第一个字节的采样时间。时钟频率依赖于负载数据格式,并在描述文件(profile)中进行描述。

    SSRC ― 同步源。该标识符随机生成,旨在确保在同一个 RTP 会话中不存在两个同步源具有相同的 SSRC 标识符。

    CSRC ― 贡献源标识符。识别该数据包中的有效载荷的贡献源。

     

    从RTP包头的规定中,我们可以非常清晰地看出,在RTP协议中,添加了非常多专为流媒体传输所使用的特性,更加有助于应用于流媒体的传输。

    比如用于帧边界标记的M标志位,方便接收端快速定位帧边界;比如负载类型字段,用来告诉接收端(或者播放器)传输的是哪种类型的媒体(例如G.729,H.264,MPEG-4等),这样接收端(或者播放器)就知道数据流是什么格式,然后使用对应的解码器去解码或者播放;比如时间戳字段,标识了数据流的时间戳,接收端可以利用这个时间戳来去除由网络引起的信息包的抖动,并且在接收端为播放提供同步功能,等等。

    因此,相比于直接使用TCP或者UDP来进行流媒体传输,这样一个专门为传输音视频而诞生的网络协议更加合适。

    5. RTP的profile机制

    RTP为具体的应用提供了非常大的灵活性,它将传输协议与具体的应用环境、具体的控制策略分开,传输协议本身只提供完成实时传输的机制,开发者可以根据不同的应用环境,自主选择合适的配置环境、以及合适的控制策略。

    这里所说的控制策略指的是你可以根据自己特定的应用需求,来实现特定的一些RTCP控制算法,比如前面提到的丢包的检测算法、丢包的重传策略、一些视频会议应用中的控制方案等等(这些策略我可能将在后续的文章中进行描述)。

    对于上面说的合适的配置环境,主要是指RTP的相关配置和负载格式的定义。RTP协议为了广泛地支持各种多媒体格式(如 H.264, MPEG-4, MJPEG, MPEG),没有在协议中体现出具体的应用配置,而是通过profile配置文件以及负载类型格式说明文件的形式来提供。对于任何一种特定的应用,RTP定义了一个profile文件以及相关的负载格式说明,相关的文件如下所示:

    《RTP Profile for Audio and Video Conferences with Minimal Control》(RFC3551)

    《RTP Payload Format for H.264 Video》(RFC3984)

    《RTP Payload Format for MPEG-4 Audio/Visual Streams》(RFC3016)

    等等,想了解更多可以点击这里:http://en.wikipedia.org/wiki/RTP_audio_video_profile

    说明,如果应用程序不使用专有的方案来提供有效载荷类型(payload type)、顺序号或者时间戳,而是使用标准的RTP协议,应用程序就更容易与其他的网络应用程序配合运行,这是大家都希望的事情。例如,如果有两个不同的公司都在开发因特网电话软件,他们都把RTP合并到他们的产品中,这样就有希望:使用不同公司电话软件的用户之间能够进行通信。

    6. RTP其他的一些良好特性

    (1)RTP协议在设计上考虑到安全功能,支持加密数据和身份验证功能。

    (2)有较少的首部开销

         TCP和XTP相对RTP来说具有过多的首部开销(TCP和XTP3.6是40字节,XTP4.0是32字节,而RTP只有12字节)

    (3)……(等待补充)

    7. 相关资源列表

    这里有些相关的RTP资源,希望对大家有所帮助。

    (1)维基百科对RTP的介绍:

       http://en.wikipedia.org/wiki/Real-time_Transport_Protocol

    (2)维基百科对流媒体的介绍:

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

    (3)stackoverflows论坛关于RTP vs TCP的讨论

       http://stackoverflow.com/questions/361943/why-does-rtp-use-udp-instead-of-tcp

    (4)关于RTP的负载类型和时间戳的讲解

       http://ticktick.blog.51cto.com/823160/350142

      (5) RTP FAQ

       Some Frequently Asked Questions about RTP


    IP/TCP/UDP/RTP/RTCP包结构图

    IP 包头结构:

     

    TCP 包头结构:

    UDP 包头结构: 

     

    RTP 包头结构:

    RTCP 包头结构:

     

     

     另附RTP/UDP/TCP协议总结:http://wenku.baidu.com/view/3580ad6648d7c1c708a145e1.html

     

     

    展开全文
  • 传输协议

    千次阅读 2018-10-20 21:53:56
    1 传输协议 网络层只把分组发送到目的主机,但是真正通信的并不是主机而是主机中的进程。传输层提供了进程间的逻辑通信,传输层向高层用户屏蔽了下面网络层的核心细节,使应用程序看起来像是在两个传输层实体之间...

    传输层

    1 传输层协议

    网络层只把分组发送到目的主机,但是真正通信的并不是主机而是主机中的进程。传输层提供了进程间的逻辑通信,传输层向高层用户屏蔽了下面网络层的核心细节,使应用程序看起来像是在两个传输层实体之间有一条端到端的逻辑通信信道。

    传输层主要协议:UDP、TCP

    UDP 和 TCP 的特点

    用户数据报协议 UDP(User Datagram Protocol)是无连接的,尽最大可能交付,没有拥塞控制,面向报文(对于应用程序传下来的报文不合并也不拆分,只是添加 UDP 首部),支持一对一、一对多、多对一和多对多的交互通信。
    
    传输控制协议 TCP(Transmission Control Protocol)是面向连接的,提供可靠交付,有流量控制,拥塞控制,提供全双工通信,面向字节流(把应用层传下来的报文看成字节流,把字节流组织成大小不等的数据块),每一条 TCP 连接只能是点对点的(一对一)。
    

    2 UDP 首部格式

    首部字段只有 8 个字节,包括源端口、目的端口、长度、检验和。12 字节的伪首部是为了计算检验和临时添加的。

    3 TCP 首部格式

    TCP报文段首部的前20个字节是固定的,后面有4N字节是根据需要而增加的选项。因此TCP报文段的最小长度为20个字节。

    首部固定部分的各字段的意义如下:

    1. 源端口和目的端口:加上IP首部的源IP地址和目的IP地址,确定唯一的一个TCP连接。另外通过目的端口来决定TCP将数据报交付于那个应用程序,从而实现TCP的分用功能。

    2. 序号:占4个字节,序号的范围为[0,4284967296]。由于TCP是面向字节流的,在一个TCP连接中传送的字节流中的每一个字节都按顺序编号,首部中的序号字段则是指本报文段所发送的数据的第一个字节的序号。另外,序号是循环使用的,当序号增加到最大值时,下一个序号就又回到了0。

    3. 确认号:当ACK标志位为1时有效,表示期望收到的下一个报文段的第一个数据字节的序号。确认号为N,则表明到序号N-1为止的所有数据字节都已经被正确地接收到了。

    4. 头部长度:TCP报文段的头部长度,它指出TCP报文段的数据部分的起始位置与TCP报文段的起始位置的距离。头部长度占4个字节,但它的单位是32位字,即以4字节为计算单位,因此头部长度的最大值为15*4=60个字节,这就意味着选项的长度不超过40个字节。

    5. 保留位:必须为0.

    6. 下面的六个控制位说明报文段的性质

    1)URG:与首部中的紧急指针字段配合使用。URG为1时,表明紧急指针字段有效,发送应用进程告诉发送方的TCP有紧急数据要传送,于是发送方TCP就把紧急数据插入到本报文段数据的最前面,而其后面仍是普通数据。

    2)ACK:仅当ACK=1时确认号字段才有效,当ACK=0时,确认号无效。TCP规定,在连接建立后所有的传送报文段都必须把ACK置1。

    3)PSH:如果发送的报文段中PSH为1,则接收方接受到该报文段后,直接将其交付给应用进程,而不再等待整个缓存都填满后再向上交付。

    4)RST:复位标志,RST=1时,表明TCP连接中出现严重差错,必须释放连接,然后重新建立运输连接。

    5)SYN:同步序号,用来发起一个连接。当SYN=1而ACK=0时,表明这是一个连接请求报文段,若对方同意建立连接,则应在响应的报文段中使SYN=1和ACK=1。

    6)FIN:用来释放一个连接。当FIN=1时,表明此报文段的发送方的数据已发送完毕,并要求释放连接。

    1. 窗口:接收方让发送方下次发送报文段时设置的发送窗口的大小。

    2. 校验和:校验的字段范围包括首部和数据这两部分。

    3. 紧急指针:紧急指针当URG=1时才有效,它指出本报文段中的紧急数据的字节数。值得注意的是,即使窗口为0时,也可发送紧急数据。

    4. 选项与填充:选项应该为4字节的整数倍,否则用0填充。最常见的可选字段是最长报文大小MSS(Maximum Segment Size),每个连接方通常都在通信的第一个报文段中指明这个选项。它指明本端所能接收的最大长度的报文段。该选项如果不设置,默认为536(20+20+536=576字节的IP数据报),其中ip首部和tcp首部各20个字节,而internet 上标准的MTU (最小)为576B。

    3. TCP 的三次握手

    假设 A 为客户端,B 为服务器端。

    首先 B 处于 LISTEN(监听)状态,等待客户的连接请求。

    A 向 B 发送连接请求报文,SYN=1,ACK=0,选择一个初始的序号 x。

    B 收到连接请求报文,如果同意建立连接,则向 A 发送连接确认报文,SYN=1,ACK=1,确认号为 x+1,同时也选择一个初始的序号 y。

    A 收到 B 的连接确认报文后,还要向 B 发出确认,确认号为 y+1,序号为 x+1。

    B 收到 A 的确认后,连接建立。

    三次握手的原因

    第三次握手是为了防止失效的连接请求到达服务器,让服务器错误打开连接。

    客户端发送的连接请求如果在网络中滞留,那么就会隔很长一段时间才能收到服务器端发回的连接确认。客户端等待一个超时重传时间之后,就会重新请求连接。但是这个滞留的连接请求最后还是会到达服务器,如果不进行三次握手,那么服务器就会打开两个连接。如果有第三次握手,客户端会忽略服务器之后发送的对滞留连接请求的连接确认,不进行第三次握手,因此就不会再次打开连接。

    4. TCP 的四次挥手

    以下描述不讨论序号和确认号,因为序号和确认号的规则比较简单。并且不讨论 ACK,因为 ACK 在连接建立之后都为 1。

    A 发送连接释放报文,FIN=1。

    B 收到之后发出确认,此时 TCP 属于半关闭状态,B 能向 A 发送数据但是 A 不能向 B 发送数据。

    当 B 不再需要连接时,发送连接释放报文,FIN=1。

    A 收到后发出确认,进入 TIME-WAIT 状态,等待 2 MSL(最大报文存活时间)后释放连接。

    B 收到 A 的确认后释放连接。


    四次挥手的原因

    客户端发送了 FIN 连接释放报文之后,服务器收到了这个报文,就进入了 CLOSE-WAIT 状态。这个状态是为了让服务器端发送还未传送完毕的数据,传送完毕之后,服务器会发送 FIN 连接释放报文。

    TIME_WAIT

    客户端接收到服务器端的 FIN 报文后进入此状态,此时并不是直接进入 CLOSED 状态,还需要等待一个时间计时器设置的时间 2MSL。这么做有两个理由:

    确保最后一个确认报文能够到达。如果 B 没收到 A 发送来的确认报文,那么就会重新发送连接释放请求报文,A 等待一段时间就是为了处理这种情况的发生。

    等待一段时间是为了让本连接持续时间内所产生的所有报文都从网络中消失,使得下一个新的连接不会出现旧的连接请求报文。

    5 客户端、服务端状态变更

    客户端状态变更


    服务端状态变更

    6. TCP 的性质

    6.1 TCP 可靠传输

    TCP 使用超时重传来实现可靠传输:如果一个已经发送的报文段在超时时间内没有收到确认,那么就重传这个报文段。

    一个报文段从发送再到接收到确认所经过的时间称为往返时间 RTT,加权平均往返时间 RTTs 计算如下:

    其中 RTTd 为偏差。

    6.2 交互数据流和成块数据流

    交互数据类型,如:Telnet,这类协议一般只做小流量的数据交换,比如每按下一个键,要回显一些字符。

    成块数据类型,如:FTP,这类协议需要传输的数据比较多,一般传输的数据量比较大。

    6.2.1 交互数据流

    针对交互性要求比较高的应用,每发送一个字节到服务端,并回显到客户端的过程如下:

    1. 客户端产生一个41bit长的报文(20字节的IP首部,20字节的TCP首部,1字节的数据),发送到服务端;

    2. 服务端发送过来一个40bit的确认报文;

    3. 服务端发送回显的字符,报文长为41bit;

    4. 客户端发送确认报文,报文长为40bit。

    如果在局域网中,通常不会有什么麻烦,因为局域网一般不会出现拥塞,但在广域网中,这些小分组则会增加网络拥塞出现的可能。为了提高这类数据的发送效率和降低网络负担,TCP采用了两种策略:捎带ACKNagle算法

    捎带 ACK :
       捎带ACK的意思是,当接收端接收到TCP报文段后,并不立即发送ACK报文,而是等上一段时间,如果这段时间里该主机有数据要发送到远程主机,就将该数据捎带上ACK一起发送过去,很明显,这样可以减少传输开销。为了防止产生超时重传,绝大多数情况下,这个等待时间为200ms,超过了200ms,如果没有数据要一起发送,就直接发送ACK报文。

    捎带ACK的策略一般也只有在交互性比较高的应用中才会使用,对于成块数据流,一般大多数应用程序不会同时在两个方向上发送数据。

    Nagle算法
      该算法的重点是要求在TCP连接上组多只能有一个未被确认的数据报在传输。算法的大致思路如下:应用程序把要发送的数据逐个字节地从到TCP的发送缓存,发送方把前面的一部分数据先发送出去,并把后面到达的字节继续缓存起来,当发送方收到前面字节的确认后,再把发送缓冲中的所有数据组装成一个报文段发送出去,同时继续对随后到来的数据进行缓存。只有收到前一个报文段的确认后才能继续发送下一个报文段。另外,Nagle算法还规定,当发送缓存中的数据已达到发送窗口大小的一半或已达到报文段的MSS值时,就立即发送一个报文段。
      当数据到达较快而网络速率较慢时,用这种方法可明显地减少所用的网络带宽。很明显,该算法也是专门为交互性高的应用而设计的,对于成块数据流,如果每收到一次确认才能发送下一个报文段,那么传输速率就会很低。

    6.2.2 成块数据流

    对于一些数据吞吐量要求较高的应用,总是希望每次发送尽可能多的数据到主机,对于这类应用,TCP使用滑动窗口协议,该协议允许发送方在停止发送前和等待确认前可以连续发送多个分组,因此可以加速数据的传输。

    滑动窗口

    滑动窗口的滑动是以字节为单位的,发送方A和接收方B在TCP三次握手的前两次握手时协商好了发送窗口和接受窗口的大小,发送方A根据B发送来的确认连接报文中标明的窗口的大小,来确定收到确认前的最大发送数据量,如果A接收到的B发来的确认报文中标明的窗口大小为0,则停止发送数据,直到收到不为0的确认报文,再继续发送。发送窗口表示在没有收到B的确认的情况下,A可以连续把窗口内的数据都发送出去,凡是已发送过的数据,在没有收到确认前都要暂时保留,以便超时重传时使用。

    需要注意的一点是:使用TCP滑动窗口协议时,接收方不必确认每一个收到的分组,在TCP中,ACK确认是累积的,可以在接收到几个序号连续的报文段后只发送一个ACK确认报文,但累积等待的时间最长不能超过0.5秒,以防止发送端超时重传。

    另外,要注意滑动窗口的三种变化:

    1. 窗口合拢。窗口左边沿向右边沿靠近,这种情况发生在数据被发送后收到确认时;

    2. 窗口张开。窗口右边沿向右移动,说明允许发送更多的数据,这种情况发生在另一端的接收进程从TCP接收缓存中读取了已经确认的数据时;

    3. 窗口收缩。窗口右边沿向左移动,一般很少发生,RFC也强烈不建议这么做,因为很可能会产生一些错误,比如一些数据已经发送出去了,又要收缩窗口,不让发送这些数据。

    另外,窗口的左边沿是肯定不可能左移的,如果接收到一个指示窗口左边沿向左移动的ACK,则它被认为是一个重复ACK,并被丢弃。

    总结以下几点:

    1. 发送方不必发送一个全窗口大小的数据,一次发送一部分即可。

    2. 窗口的大小可以减小,但是窗口的右边沿却不能向左移动。

    3. 接收方在发送一个ACK前不必等待窗口被填满。

    4. 窗口的大小是相对于确认序号的,收到确认后的窗口的左边沿从确认序号开始。

    发送接收缓冲区

    1. 缓冲空间和序号空间都是有限的,并且都是循环使用的。

    2. 窗口大小一定不大于收发缓冲区的大小

    3. 发送缓冲区用来暂存发送方准备发送的TCP报文段和已发送但尚未收到确认的数据。

    4. 接收缓冲区用来暂按序到达但尚未被上层应用程序读取的数据合未按序到达的数据。

    6.3 四大定时器

    对于每个TCP连接,TCP一般要管理4个不同的定时器:重传定时器坚持定时器保活定时器2MSL定时器

    6.3.1 重传定时器

    很明显重传定时器是用来计算TCP报文段的超时重传时间的(至于超时重传时间的确定,这里涉及到一大堆的算法,书上有说,我这里不细谈了)。每发送一个报文段就会启动重传定时器,如果在定时器时间到后还没收到对该报文段的确认,就重传该报文段,并将重传定时器复位,重新计算;如果在规定时间内收到了对该报文段的确认,则撤销该报文段的重传定时器。

    6.3.2 坚持定时器

    上篇文章中已经提到了,主要是为了应付零窗口大小通知可能导致的死锁问题。如果接收端在向发送端发送了零窗口报文段后不久,接收端的接收缓存又有了一些存储空间,于是接收端向发送端发送了一个非零窗口大小的报文段,然而这个报文段在传送过程中丢失了,发送端没有收到该报文段,就一直等待接收端发送非零窗口的报文通知,而接收端并不知道报文段丢失了,而是觉得已经告诉发送端了,就会一直等待发送端发送数据,如果没有任何措施的话,这话死锁的局面会一直延续下去。

    为了解决这个问题,TCP为每一个连接设有一个坚持定时器(也叫持续计数器)。只要TCP连接的一方收到对方的零窗口通知,就启动坚持定时器。若坚持定时器设置的时间到期,就发送一个零窗口控测报文段(该报文段只有一个字节的数据,它有一个序号,但该序号永远不需要确认,因此该序号可以持续重传),之后会出现以下三种情况:

    1. 对方在收到探测报文段后,在对该报文段的确认中给出现在的窗口值,如果窗口值仍未零,则收到这个报文段的一方将坚持定时器的值加倍并重启。坚持计数器最大只能增加到约60秒,在此之后,每次收到零窗口通知,坚持计数器的值就定位60秒。

    2. 对方在收到探测报文段后,在对该报文段的确认中给出现在的窗口值,如果窗口不为零,那么死锁的僵局就被打破了。

    3. 该探测报文发出后,会同时启动重传定时器,如果重传定时器的时间到期,还没有收到接收到发来的响应,则超时重传探测报文。

    6.3.3 保活定时器

    保活定时器是为了应对两个TCP连接间出现长时间的没有数据传输的情况。如果客户已与服务器建立了TCP连接,但后来客户端主机突然故障,则服务器就不能再收到客户端发来的数据了,而服务器肯定不能这样永久地等下去,保活定时器就是用来解决这个问题的。服务器每收到一次客户端的数据,就重新设置保活定时器,通常为2小时,如果2小时没有收到客户端的数据,服务端就发送一个探测报文,以后每隔75秒发送一次,如果连续发送10次探测报文段后仍没有收到客户端的响应,服务器就认为客户端出现了故障,就可以终止这个连接。

    #### 6.3.4 2MSL定时器

    2MSL定时器测量一个连接处于TIME—WAIT黄台的时间,通常为2MSL(报文段寿命的两倍)。2MSL定时器的设置主要是为了确保发送的最后一个ACK报文段能够到达对方,并防止之前与本连接有关的由于延迟等原因而导致已失效的报文被误判为有效。

    6.4 TCP 滑动窗口

    窗口是缓存的一部分,用来暂时存放字节流。发送方和接收方各有一个窗口,接收方通过 TCP 报文段中的窗口字段告诉发送方自己的窗口大小,发送方根据这个值和其它信息设置自己的窗口大小。

    发送窗口内的字节都允许被发送,接收窗口内的字节都允许被接收。如果发送窗口左部的字节已经发送并且收到了确认,那么就将发送窗口向右滑动一定距离,直到左部第一个字节不是已发送并且已确认的状态;接收窗口的滑动类似,接收窗口左部字节已经发送确认并交付主机,就向右滑动接收窗口。

    接收窗口只会对窗口内最后一个按序到达的字节进行确认,例如接收窗口已经收到的字节为 {31, 34, 35},其中 {31} 按序到达,而 {34, 35} 就不是,因此只对字节 31 进行确认。发送方得到一个字节的确认之后,就知道这个字节之前的所有字节都已经被接收。

    6.5 TCP 流量控制

    一般来说,我们总是希望数据传输的更快一些,但如果发送方把数据发送的很快,而接收方来不及接收,这就可能造成数据的丢失。流量控制就是让发送方的发送速率不要太快,让接收方来得及接收。

    接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小,从而影响发送方的发送速率。将窗口字段设置为 0,则发送方不能发送数据。

    6.6 TCP 拥塞控制

    如果网络出现拥塞,分组将会丢失,此时发送方会继续重传,从而导致网络拥塞程度更高。因此当出现拥塞时,应当控制发送方的速率。这一点和流量控制很像,但是出发点不同。流量控制是为了让接收方能来得及接收,而拥塞控制是为了降低整个网络的拥塞程度

    TCP 主要通过四个算法来进行拥塞控制:慢开始、拥塞避免、快重传、快恢复

    名词

    rwnd	滑动窗口
    cwnd 拥塞窗口
    ssthresh 慢启动门限
    MMS 最大报文段
    RRT 往返时间
    

    发送方需要维护一个叫做拥塞窗口(cwnd)的状态变量,注意拥塞窗口与发送方窗口的区别:拥塞窗口只是一个状态变量,实际决定发送方能发送多少数据的是发送方窗口。

    为了便于讨论,做如下假设:

    接收方有足够大的接收缓存,因此不会发生流量控制;
    虽然 TCP 的窗口基于字节,但是这里设窗口的大小单位为报文段。

    1. 慢开始与拥塞避免

    发送的最初执行慢开始,令 cwnd = 1,发送方只能发送 1 个报文段;当收到确认后,将 cwnd 加倍,因此之后发送方能够发送的报文段数量为:2、4、8 …(*慢启动, cwnd = 2)

    注意到慢开始每个轮次都将 cwnd 加倍,这样会让 cwnd 增长速度非常快,从而使得发送方发送的速度增长速度过快,网络拥塞的可能性也就更高。设置一个慢开始门限 ssthresh,当 cwnd >= ssthresh 时,进入拥塞避免,每个轮次只将 cwnd 加 1。(当cwnd < ssthresh时,*2,否则 +1 )

    如果出现了超时,则令 ssthresh = cwnd / 2,然后重新执行慢开始。

    1. 快重传与快恢复

    快重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认(重复发送对前面有序部分的确认),而不是等待自己发送数据时才进行稍待确认,也不是累积收到的报文发送累积确认,如果发送方连续收到三个重复确认,就应该立即重传对方未收到的报文段(有收到重复确认,说明后面的报文段都送达了,只有中间丢失的报文段没送达)。

    在接收方,要求每次接收到报文段都应该对最后一个已收到的有序报文段进行确认。例如已经接收到 M1 和 M2,此时收到 M4,应当发送对 M2 的确认。
    在发送方,如果收到三个重复确认,那么可以知道下一个报文段丢失,此时执行快重传,立即重传下一个报文段。例如收到三个 M2,则 M3 丢失,立即重传 M3。
    在这种情况下,只是丢失个别报文段,而不是网络拥塞。因此执行快恢复,令 ssthresh = cwnd / 2 ,cwnd = ssthresh,注意到此时直接进入拥塞避免。

    慢开始和快恢复的快慢指的是 cwnd 的设定值,而不是 cwnd 的增长速率。慢开始 cwnd 设定为 1,而快恢复 cwnd 设定为 ssthresh。


    问题1】为什么连接的时候是三次握手,关闭的时候却是四次握手?
    答:因为当Server端收到Client端的SYN连接请求报文后,可以直接发送SYN+ACK报文。其中ACK报文是用来应答的,SYN报文是用来同步的。但是关闭连接时,当Server端收到FIN报文时,很可能并不会立即关闭SOCKET,所以只能先回复一个ACK报文,告诉Client端,“你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了,我才能发送FIN报文,因此不能一起发送。故需要四步握手。

    问题2】为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态?

    1. 为了保证A发送的最后一个ACK报文段能够到达B。该ACK报文段很有可能丢失,因而使处于在LAST—ACK状态的B收不到对已发送的FIN+ACK报文段的确认,B可能会重传这个FIN+ACK报文段,而A就在这2MSL时间内收到这个重传的FIN+ACK报文段,接着A重传一次确认,重新启动2MSL计时器,最后A和B都进入CLOSED状态。如果A在TIME—WAIT状态不等待一段时间就直接释放连接,到CLOSED状态,那么久无法收到B重传的FIN+ACK报文段,也就不会再发送一次确认ACK报文段,B就无法正常进入CLOSED状态。
       2. 防止已失效的请求连接出现在本连接中。在连接处于2MSL等待时,任何迟到的报文段将被丢弃,因为处于2MSL等待的、由该插口(插口是IP和端口对的意思,socket)定义的连接在这段时间内将不能被再用,这样就可以使下一个新的连接中不会出现这种旧的连接之前延迟的报文段。

    补充:
       当客户端执行主动关闭并进入TIME—WAIT是正常的,服务端执行被动关闭,不会进入TIME—WAIT状态,这说明,如果终止了一个客户程序,并立即重启该客户程序,则新的客户程序将不再重用相同的本地端口,而是使用新的端口,这不会带来什么问题,因为客户端使用本地端口,而并不关心这个端口是多少。但对于服务器来说,情况就不同了,服务器总是用我们熟知的端口,那么在2MSL时间内,重启服务器就会出错,为了避免这个错误,服务器给出了一个平静时间的概念,这是说在2MSL时间内,虽然可以重新启动服务器,但是这个服务器还是要平静的等待2MSL时间的过去才能进行下一次连接。

    问题三】TCP和UDP的优缺点及区别

    TCP的优点: 可靠,稳定 TCP的可靠体现在TCP在传递数据之前,会有三次握手来建立连接,而且在数据传递时,有确认、窗口、重传、拥塞控制机制,在数据传完后,还会断开连接用来节约系统资源。

    TCP的缺点: 慢,效率低,占用系统资源高,易被攻击 TCP在传递数据之前,要先建连接,这会消耗时间,而且在数据传递时,确认机制、重传机制、拥塞控制机制等都会消耗大量的时间,而且要在每台设备上维护所有的传输连接,事实上,每个连接都会占用系统的CPU、内存等硬件资源。 而且,因为TCP有确认机制、三次握手机制,这些也导致TCP容易被人利用,实现DOS、DDOS、CC等攻击。

    UDP的优点: 快,比TCP稍安全 UDP没有TCP的握手、确认、窗口、重传、拥塞控制等机制,UDP是一个无状态的传输协议,所以它在传递数据时非常快。没有TCP的这些机制,UDP较TCP被攻击者利用的漏洞就要少一些。但UDP也是无法避免攻击的,比如:UDP Flood攻击

    UDP的缺点: 不可靠,不稳定 因为UDP没有TCP那些可靠的机制,在数据传递时,如果网络质量不好,就会很容易丢包。 基于上面的优缺点,那么: 什么时候应该使用TCP: 当对网络通讯质量有要求的时候,比如:整个数据要准确无误的传递给对方,这往往用于一些要求可靠的应用,比如HTTP、HTTPS、FTP等传输文件的协议,POP、SMTP等邮件传输的协议。 在日常生活中,常见使用TCP协议的应用如下: 浏览器,用的HTTP FlashFXP,用的FTP Outlook,用的POP、SMTP Putty,用的Telnet、SSH QQ文件传输

    什么时候应该使用UDP: 当对网络通讯质量要求不高的时候,要求网络通讯速度能尽量的快,这时就可以使用UDP。 比如,日常生活中,常见使用UDP协议的应用如下: QQ语音 QQ视频 TFTP ……

    有些应用场景对可靠性要求不高会用到UPD,比如长视频,要求速率

    TCP与UDP的区别

    1. 基于连接与无连接;
    2. 对系统资源的要求(TCP较多,UDP少);
    3. UDP程序结构较简单;
    4. 流模式与数据报模式 ;
    5. TCP保证数据正确性,UDP可能丢包,TCP保证数据顺序,UDP不保证。

    问题四】 为什么一定要进行三次握手?

    前两次的握手很显然是必须的,主要是最后一次,即客户端收到服务端发来的确认后为什么还要想服务端再发送一次确认呢?这主要是为了防止已失效的请求报文段突然又传送到了服务端而产生连接的误判。
    考虑如下的情况:客户端发送了一个连接请求报文段到服务端,但是在某些网络节点上长时间滞留了,而后客户端又超时重发了一个连接请求报文段该服务端,而后正常建立连接,数据传输完毕,并释放了连接。如果这时候第一次发送的请求报文段延迟了一段时间后,又到了服务端,很显然,这本是一个早已失效的报文段,但是服务端收到后会误以为客户端又发出了一次连接请求,于是向客户端发出确认报文段,并同意建立连接。假设不采用三次握手,这时服务端只要发送了确认,新的连接就建立了,但由于客户端比你更没有发出建立连接的请求,因此不会理会服务端的确认,也不会向服务端发送数据,而服务端却认为新的连接已经建立了,并在一直等待客户端发送数据,这样服务端就会一直等待下去,直到超出保活计数器的设定值,而将客户端判定为出了问题,才会关闭这个连接。这样就浪费了很多服务器的资源。而如果采用三次握手,客户端就不会向服务端发出确认,服务端由于收不到确认,就知道客户端没有要求建立连接,从而不建立该连接。

    展开全文
  • 几种常用的网络传输协议

    千次阅读 2019-10-07 10:36:08
    数据链路层是建立在物理传输能力的基础上,为单位传输数据,它的主要任务就是进行数据封装和数据链接的建立。封装的数据信息中,地址段含有发送节点和接收节点的地址,控制段用来表示数据连接帧的类型,数据段...

    一、OSI模型

    名称            层次                功能

    物理层          1               实现计算机系统与网络间的物理连接(网线)

    数据链路层   2               进行数据打包与解包,形成信息帧

    网络层          3               提供数据通过的路由(路由器、交换机)

    传输层          4               提供传输顺序信息与响应(TCP、UDP)

    会话层          5               建立和中止连接(避免用户去调用TCP和UDP)

    表示层          6               数据转换、确认数据格式(linux和window等系的差异)

    应用层          7               提供用户程序接口(HTTP、FTP等)

    二、协议层次

    网络中常用协议以及层次关系

    1、 进程/应用层的协议

    平时最广泛的协议,这一层的每个协议都由客程序和服务程序两部分组成。程序通过服务器与客户机交互来工作。常见协议有:Telnet、FTP、SMTP、HTTP、DNS等。

    Telnet:对应Windows系统中的telnet指令,可以用于在本地调用另一台电脑上的程序

    FTP:文件传输协议

    SMTP:简单邮件传输协议,是在网络上传输邮件的标准。

    HTTP:超文本传输协议,广泛应用于网页请求。

    DNS:域名解析协议.

    2、 传输层协议

    建立并且维护连接,用于保证主机间数据传输的安全性。这一层主要有两个协议:

    TCP(Transmission Control Protocol:传输控制协议;面向连接,可靠传输

    UDP(User Datagram Protocol):用户数据报协议;面向无连接,不可靠传输

    3、 Internet层协议

    负责数据的传输,在不同网络和系统间寻找路由,分段和重组数据报文,另外还有设备寻址。网络层包括如下协议:

    IP(Internet Protocol):Internet协议,负责TCP/IP主机间提供数据报服务,进行数据封装并产生协议头,TCP与UDP协议的基础。

    ICMP(Internet Control Message Protocol):Internet控制报文协议。ICMP协议其实是IP协议的的附属协议,IP协议用它来与其它主机或路由器交换错误报文和其它的一些网络情况,在ICMP包中携带了控制信息和故障恢复信息。

    ARP(Address Resolution Protocol)协议:地址解析协议。

    RARP(Reverse Address Resolution Protocol):逆向地址解析协议。

    OSI 全称(Open System Interconnection)网络的OSI七层结构
    (1)物理层——Physical 
    这是整个OSI参考模型的最底层,它的任务就是提供网络的物理连接。所以,物理层是建立在物理介质上(而不是逻辑上的协议和会话),它提供的是机械和电气接口。主要包括电缆、物理端口和附属设备,如双绞线、同轴电缆、接线设备(如网卡等)、RJ-45接口、串口和并口等在网络中都是工作在这个层次的。 
    物理层提供的服务包括:物理连接、物理服务数据单元顺序化(接收物理实体收到的比特顺序,与发送物理实体所发送的比特顺序相同)和数据电路标识。

    (2)数据链路层——DataLink 
    数据链路层是建立在物理传输能力的基础上,以帧为单位传输数据,它的主要任务就是进行数据封装和数据链接的建立。封装的数据信息中,地址段含有发送节点和接收节点的地址,控制段用来表示数据连接帧的类型,数据段包含实际要传输的数据,差错控制段用来检测传输中帧出现的错误。 
    数据链路层可使用的协议有SLIP、PPP、X.25和帧中继等。常见的集线器和低档的交换机网络设备都是工作在这个层次上,Modem之类的拨号设备也是。工作在这个层次上的交换机俗称“第二层交换机”。 
    具体讲,数据链路层的功能包括:数据链路连接的建立与释放、构成数据链路数据单元、数据链路连接的分裂、定界与同步、顺序和流量控制和差错的检测和恢复等方面。简单的说就是规定了几个位或几个字节表示一个数据.

    (3)网络层——Network 
    网络层属于OSI中的较高层次了,从它的名字可以看出,它解决的是网络与网络之间,即网际的通信问题,而不是同一网段内部的事。网络层的主要功能即是提供路由,即选择到达目标主机的最佳路径,并沿该路径传送数据包。除此之外,网络层还要能够消除网络拥挤,具有流量控制和拥挤控制的能力。网络边界中的路由器就工作在这个层次上,现在较高档的交换机也可直接工作在这个层次上,因此它们也提供了路由功能,俗称“第三层交换机”。 
    网络层的功能包括:建立和拆除网络连接、路径选择和中继、网络连接多路复用、分段和组块、服务选择和流量控制。

    (4)传输层——Transport 
    传输层解决的是数据在网络之间的传输质量问题,它属于较高层次。传输层用于提高网络层服务质量,提供可靠的端到端的数据传输,如常说的QoS就是这一层的主要服务。这一层主要涉及的是网络传输协议,它提供的是一套网络数据传输标准,如TCP协议。 
    传输层的功能包括:映像传输地址到网络地址、多路复用与分割、传输连接的建立与释放、分段与重新组装、组块与分块。 
    根据传输层所提供服务的主要性质,传输层服务可分为以下三大类: 
    A类:网络连接具有可接受的差错率和可接受的故障通知率(网络连接断开和复位发生的比率),A类服务是可靠的网络服务,一般指虚电路服务。 
    C类:网络连接具有不可接受的差错率,C类的服务质量最差,提供数据报服务或无线电分组交换网均属此类。 
    B类:网络连接具有可接受的差错率和不可接受的故障通知率,B类服务介于A类与C类之间,在广域网和互联网多是提供B类服务。

    网络服务质量的划分是以用户要求为依据的。若用户要求比较高,则一个网络可能归于C型,反之,则一个网络可能归于B型甚至A型。例如,对于某个电子邮件系统来说,每周丢失一个分组的网络也许可算作A型;而同一个网络对银行系统来说则只能算作C型了。

    (5)会话层——Senssion 
    会话层利用传输层来提供会话服务,会话可能是一个用户通过网络登录到一个主机,或一个正在建立的用于传输文件的会话。 
    会话层的功能主要有:会话连接到传输连接的映射、数据传送、会话连接的恢复和释放、会话管理、令牌管理和活动管理。

    (6)表示层——Presentation 
    表示层用于数据管理的表示方式,如用于文本文件的ASCII和EBCDIC,用于表示数字的1S或2S补码表示形式。如果通信双方用不同的数据表示方法,他们就不能互相理解。表示层就是用于屏蔽这种不同之处。 
    表示层的功能主要有:数据语法转换、语法表示、表示连接管理、数据加密和数据压缩。

    (7)应用层——Application 
    这是OSI参考模型的最高层,它解决的也是最高层次,即程序应用过程中的问题,它直接面对用户的具体应用。应用层包含用户应用程序执行通信任务所需要的协议和功能,如电子邮件和文件传输等,在这一层中TCP/IP协议中的FTP、SMTP、POP等协议得到了充分应用。 
    SNMP(Simple Network Management Protocol,简单网络管理协议)的前身是简单网关监控协议(SGMP),用来对通信线路进行管理。随后,人们对SGMP进行了很大的修改,特别是加入了符合Internet定义的SMI和MIB:体系结构,改进后的协议就是著名的SNMP。SNMP的目标是管理互联网Internet上众多厂家生产的软硬件平台,因此SNMP受Internet标准网络管理框架的影响也很大。现在SNMP已经出到第三个版本的协议,其功能较以前已经大大地加强和改进了。

    SNMP的体系结构是围绕着以下四个概念和目标进行设计的:保持管理代理(agent)的软件成本尽可能低;最大限度地保持远程管理的功能,以便充分利用Internet的网络资源;体系结构必须有扩充的余地;保持SNMP的独立性,不依赖于具体的计算机、网关和网络传输协议。在最近的改进中,又加入了保证SNMP体系本身安全性的目标。 
    OSPF(Open Shortest Path First开放式最短路径优先)是一个内部网关协议(Interior Gateway Protocol,简称IGP),用于在单一自治系统(autonomous system,AS)内决策路由。与RIP相对,OSPF是链路状态路由协议,而RIP是距离向量路由协议。
    RIP(Routing information Protocol)是应用较早、使用较普遍的内部网关协议(Interior Gateway Protocol,简称IGP),适用于小型同类网络,是典型的距离向量(distance-vector)协议。文档见RFC1058、RFC1723。 
    RIP通过广播UDP报文来交换路由信息,每30秒发送一次路由信息更新。RIP提供跳跃计数(hop count)作为尺度来衡量路由距离,跳跃计数是一个包到达目标所必须经过的路由器的数目。如果到相同目标有二个不等速或不同带宽的路由器,但跳跃计数相同,则RIP认为两个路由是等距离的。RIP最多支持的跳数为15,即在源和目的网间所要经过的最多路由器的数目为15,跳数16表示不可达
    CSMA/CD(Carrier Sense Multiple Access/Collision Detect)
    即载波监听多路访问/冲突检测方法

    展开全文
  • 传输控制协议(TCP)、IP协议

    千次阅读 2019-06-03 12:07:05
    传输控制协议(TCP) 传输控制协议( Transmission Control Protocol),简称TCP协议,它在...字节流的服务:使用TCP协议进行传输的应用程序之间传输的数据可视无结构的字节流,基于字节流的服务没有字节序问题的困扰...
  • 流媒体及流媒体传输协议简介

    千次阅读 多人点赞 2019-06-01 22:26:10
    流媒体(streaming media):是指将一连串的媒体数据压缩后,经过网上分段发送数据,在网上即时传输影音供观赏的一种技术与过程,此技术使得数据包得以像流水一样发送;如果不使用此技术,就必须在使用前下载整个...
  • 前面讲解了PS、TS、FLV这三种媒体封装格式,现在新开一个系列讲解下传输协议,这里面会包含RTP、RTSP、HLS、RTMP等。当然最复杂的封装格式MP4在准备中,后面会把封装格式这个系列讲完。今天要说的RTP传输协议,有人...
  • udp协议什么_有什么

    千次阅读 2021-08-14 00:14:36
    UDP简介UDP 是User Datagram Protocol的简称, 中文名是用户数据报协议,是OSI(Open System InterconnecTIon,开放式系统互联) 参考模型中一种无连接的传输协议,提供面向事务的简单不可靠信息传送服务,IETF RFC ...
  • 几种常用网络传输协议

    千次阅读 2018-12-07 16:19:00
    一、OSI模型 名称 层次 功能 物理层 1 实现计算机系统与网络间的物理连接 数据链路层 2 进行数据打包与解包,形成信息帧 网络层 3 提供数据通过的路由 传输层 4...
  • TCP/IP协议传输

    千次阅读 2019-05-06 00:04:58
    网络层只把分组发送到目的主机,但是真正通信的并不是主机而是主机中的进程。传输层提供了进程间的逻辑通信,传输层向...传输控制协议 TCP(Transmission Control Protocol)是面向连接的,可靠的流协议; 分段 编...
  • I2C总线传输协议

    万次阅读 多人点赞 2017-08-20 19:50:10
    如果两个master都想在同一条空闲总线上传输,此时必须能够使用某种机制来选择将总线控制权交给哪个master,这是通过时钟同步和仲裁来完成的,而被迫让出控制权的master则需要等待总线空闲后再继续传输。在单一master...
  • 传输层---TCP协议

    千次阅读 2018-08-19 15:14:39
    1.TCP协议段格式 源端口号/目的端口号:知道数据从哪进程中来,要到哪个进程中去 32位序号/32位确认序号:传输数据时按字节进行编号,序号保证数据按序到达,而双方都需要确认,所以有序号和确认序号 4位首部...
  • UDP协议 UDP协议端格式: 16位UDP长度, 表示整个数据报(UDP首部+UDP数据)的最大长度; 如果校验和出错, 就会直接丢弃。 UDP的特点: UDP传输的过程类似于寄信. 无连接: 知道对端的IP和端口号就直接进行传输, 不需要...
  • 详解ActiveMQ的传输协议种类

    千次阅读 2019-08-10 17:29:48
    ActiveMQ允许客户端使用多种协议来连接,配置Transport Connector的文件在activeMQ安装目录的conf/activemq.xml中的<transportConnectors>标签之内。官方默认提供的: <transportConnectors> <!-...
  • 原文地址:... 有一些情况需要很多设备同步时钟。 一些无线协议如蓝牙对底层的射频硬件实现了优秀的抽象。这使得顶层的开发者无需关心底层的具体实现。直接调用send函数就可...
  • TCP/IP是普遍使用的网络互连标准协议,可在不同环境和不同节点之间进行彼此通信,是连入Internet的所有计算机在网络上进行各种信息交换和传输所必须采用的协议,也是Windows NT、Windows 2000 Server、NetWare及UNIX...
  • TCP/IP之传输协议详解

    千次阅读 2019-03-14 10:26:20
    Linux中(BSD Unix和Windows也是如此), 超时500ms一个单位进行控制, 每次判定超时重发的超时时间都是500ms的整数倍. 如果重发一次之后, 仍然得不到应答, 等待 2*500ms 后再进行重传. 如果仍然得不到应答, ...
  • 传输协议之TCP和UDP详细说明

    千次阅读 2020-12-16 11:13:20
    传输传输层功能介绍 传输层: 标明上层所使用什么样的应用 端口号(2字节) SYN(1bit) ACK(1bit) ...传输层的功能: ...session multiplexing——会话多路复用 Identification of different ...为什么一个IP地址可
  • USB协议传输结构

    千次阅读 2017-02-08 10:34:36
    USB协议传输结构 集合关系:传输类型 -> 事务 -> 包 -> 域 传输类型: 控制、中断、同步、批量 事务: IN、OUT、SETUP 包: 令牌包、数据包、握手包 域: 同步序列域、包标识域、地址域、端点域、帧号域、数据域、...
  • 详情见下图: 其中MQTT协议是20世纪90年代中期,IBM帮助石油和天然气公司客户实现数千英里长的石油和天然气管道的无人值守监控,将管道上的传感器数据通过卫星通信传输到监控中心而设计的数据传输协议。...
  • TCP/IP协议分析(传输层安全缺陷)

    千次阅读 2020-01-12 00:50:03
    传输应用进程之间提供端到端的逻辑通信(网络层主机之间提供逻辑通信)。 传输层需要对收到的报文进行差错检测。 运输层需要有两种不同的运输协议,即面向连接的 TCP 和无连接的 UDP。 传输控制协议(Transmi....
  • 二流媒体网络传输协议 1RTP 2RTCP 3RTSP 4RSVP 三流媒体播放方式 1单播 2组播 3点播与广播 四业界中流媒体系统的简介 一、音视频编解码技术1、MPEG4 MPEG全称是Moving Pictures Experts Group,它是“动态图象专家...
  • 在这篇博客中介绍了有关传输层,端口号以及传输层UDP协议的相关概念,本文将介绍传输层的另一重要协议------TCP协议的相关内容。传输控制协议TCP的特点1. TCP协议是面向连接的。即在进行数据通信之前,发送进程要与...
  • 通信协议详解(一):IIC总线协议传输时序+数据格式+设计实现)IIC(是一种具有两线传输的串行通信总线,使用多主从架构,由飞利浦公司在1980年代为了让主板、嵌入式系统或手机连接低速周边设备而发展,适用于数据...
  • 传输层的本质就是分布在不同地理位置的计算机的进程通信提供可靠的端-端连接和数据传输服务,作用是实现分布式进程通信,它的传输单位是报文 屏蔽了传输网实现技术的差异性,使得应用层在设计各种网络应用系统时,...
  •  实时传输协议RTP(Real-time Transport Protocol)是一个网络传输协议,它是由IETF的多媒体传输工作小组1996年在RFC 1889中公布的,后在RFC3550中进行更新。  国际电信联盟ITU-T也发布了自己的RTP文档,作为H....
  • 1.UDP用户数据报协议 首先,说明UDP的几个主要特点: ①UDP是无连接的; ②UDP尽最大努力交付,但不保证数据可靠性; ③UDP是面向报文的; ④UDP没有拥塞控制(网络出现拥塞状况并不会导致源主机的发送速率降低); ...
  • TCP传输控制协议总结

    千次阅读 2016-03-22 00:51:57
    TCP位于TCP/IP四层协议的第三层,属于传输协议。它提供面向连接的 可靠的字节流服务。  TCP通过一下方式提供服务:  1. 应用数据被分割成TCP认为最合适发送的数据块。这和UDP完全不一样,应用程序产生的数据报...
  • SPI总线协议概述

    万次阅读 多人点赞 2018-12-05 13:58:39
    SPI(serial peripheral interface)是一种同步串行通信协议,由一个主设备和一个或多个从设备组成,主设备启动与从设备的同步通信,从而完成数据的交换。SPI是一种高速全双工同步通信总线,标准的SPI仅仅使用4个引脚...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 66,276
精华内容 26,510
关键字:

同步协议以什么为传输单位