我是靠谱客的博主 成就汽车,最近开发中收集的这篇文章主要介绍TCP/UDP 详解 (可靠传输、流量控制、连接管理等核心章节的详解),觉得挺不错的,现在分享给大家,希望可以做个参考。

概述

 TCP/UDP 详解 (可靠传输、流量控制、连接管理等核心章节的详解)

如果有需要PDF文档的,可到下载专栏进行下载;

一、            传输层概述

1、传输层存在的必要性

由于网络层的分组传输是不可靠的,无法了解数据到达终点的时间,无法了解数据未达终点的状态。因此有必要增强网络层提供服务的服务质量。

2、引入传输层的原因

面向连接的传输服务与面向连接的网络服务类似,都分为建立连接、数据传输、释放连接三个阶段;编址、寻址、流控制也是类似的。无连接的传输服务与无连接的网络服务也非常类似。一个很显然的问题:既然传输层的服务与网络层的服务如此相似,那么为什么我们还要两个独立的层呢?

原因在于:传输层的代码完全运行在用户的机器上,但是网络层主要运行在由承运商控制的路由器上。试想以下几种情况?

①  网络层提供的服务不够用;

②    频繁的丢失分组;

③    路由器时常崩溃。

用户在网络层上并没有真正的控制权,所以他们不可能用最好的路由器或者在数据链路层上用更好的错误处理机制来解决服务太差的问题。唯一的可能是在网络层之上的另一层中提高服务质量。这就是传输层存在的必要性。

  传输层的任务:在源机器和目标机器之间提供可靠的、性价比合理的数据传输服务,并且与当前使用的物理网络完全独立。

        

3、传输层的功能

         数据传送,不关心数据含义,进程间通信。

弥补高层(上3层)要求与网络层(基于下3层)数据传送服务质量间的差异(差错率、差错恢复能力、吞吐率、延时、费用等),对高层屏蔽网络层的服务的差异,提供稳定和一致的界面。

4、传输层协议与网络层协议的主要区别

         网络层(IP层)提供点到点的连接即提供主机之间的逻辑通信,传输层提供端到端的连接——提供进程之间的逻辑通信。

5、传输层的用途

传输层将数据分段,并进行必要的控制,以便将这些片段重组成各种通信流。在此过程中,传输层主要负责:

①  跟踪源主机和目的主机上应用程序间的每次通信;

②    将数据分段,并管理每个片段;

③  将分段数据重组为应用程序数据流;

④    标识不同的应用程序。

6、端口的概念

         运行在计算机中的进程是用进程标识符来标志的。运行在应用层的各种应用进程却不应当让计算机操作系统指派它的进程标识符。这是因为在因特网上使用的计算机的操作系统种类很多,而不同的操作系统又使用不同格式的进程标识符。为了使运行不同操作系统的计算机的应用进程能够互相通信,就必须用统一的方法对TCP/IP体系的应用进程进行标志。

解决这个问题的方法就是在运输层使用协议端口号(protocol port number),或通常简称为端口(port);当传输层从网络层收到数据后,根据传输层协议中的端口号将数据交付给相应的应用进程。

虽然通信的终点是应用进程,但我们可以把端口想象是通信的终点,因为我们只要把要传送的报文交到目的主机的某一个合适的目的端口,剩下的工作(即最后交付目的进程)就由 TCP来完成。

在通常情况下,端口好被划分为三段:

端口范围

端口类别

0到1023

公认的端口号,一般为服务端使用

1024到49151

已注册的端口号

41952到65535

动态或者私用端口号,一般为客户端使用

 

二、            DUP的基本原理

1、UDP概述

UDP 是一个简单的面向数据报的传输层协议(用户数据报协议),UDP在传输数居前不需要先建立连接,远程主机在收到数据后也无需返回任何确认信息。 基于UDP进程的每个输出操作都产生一个UDP数据报,并封装成一份待发送的IP数据报。如下图(UDP的封装)

 

       

         在网络层协议的数据服务上加上数据包的分用复用以及差错检测即为用户数据报协议(UDP协议),主要有以下特征:

(1)      无连接,;

(2)      尽最大阻力交付,不需要维持复杂的链路信息;

(3)      面向报文,不对应用层的数据进行合并和拆分;

(4)      没有拥塞控制,即发送端不会考虑网络传输的情况;

(5)      支持n:n的交付通信(n >= 1);

(6)      首部开销小,有利用提高数据传输效率。

         2、UDP的首部格式

 

 

 

 

(1)       源端口号,表示本地的应用层进程;

(2)       目的端口,报文交付目的进程;

(3)       用户数据报长度,最小值为8个字节(仅有首部);

(4)       检验和,用于检验UDP数据报在传输的过程中是否有错。

3、UDP客户端/服务器程序的交互过程

 

三、            TCP的基本原理

1、TCP概述

TCP是提供的面向连接的服务,即在传送数据之前要先建立连接,数据传输结束后要释放连接。TCP与UDP不同,不提供广播和多播服务,由于TCP要提供可靠的、面向连接的运输服务,故不可避免地增加了许多的开销,如确认机制,流量控制,计时功能,连接管理拥塞控制等等,由于传输的复杂性,不仅增加了首部开销,而且占用了相当部分的处理机资源。

TCP的主要特点:

(1)             面向连接的传输层协议,即在传送数据之前要先建立连接,数据传输结束后要释放连接,也称建立链路和释放链路;

(2)             每条链路是一对一,即只能点对点的通信;

(3)             提供可靠交付,通信双方需要对通信的数据进行无差错验证,确认,以保证交互数据不丢失、不重复并有序到达应用层;

(4)             提供全双工通信,通信双方既可以是信息的接收者也可以是信息的发送者,并且两段都有接受缓存和发送缓存,在发送时,应用程序将数据交付tcp后无需关心数据的发送,在接收时,tcp把接收到的数据进行确认后放入缓存,应用程序可在合适的时候进行读取,从而可以实现异步通信,提高应用程序的工作效率;

(5)             面向字节流,TCP把应用程序下传的数据仅仅视为一连串的无结构字节流,在传输的过程中只有字节流数量的概念,不会关心字节流的含义。也不保证接收方应用程序所收到的数据块和发送端应用程序所发出的数据块具有对于大小关系。但接收方的应用程序收到的字节流必须和发送端的应用程序发出的字节流一样,故接收方的应用程序必须有能力识别接收到的字节流,把tcp的字节流还原成有意义的应用层数据。

TCP 的所有数据传输都是基于链路,每一条tcp链路都有两个端点,也称套接字或者插口。在RFC793中定义,应用程序的端口 + ip地址便构成了套接字。

         套接字 Socket = (IP地址 :端口号)

故TCP连接也被两个端点唯一确定:

TCP连接::= { Socket1, Socket2 } = {  (IP_1 : Port_1), (IP_1 : Port_2)}

2、TCP报文段首部格式分析

虽然TCP是面向字节流的,但是TCP的传输单元式数据报。一个报文段分为IP协议首部和IP数据两部分,数据部分即应用层的数据,而TCP的全部功能都体现在它首部的各个字段的作用。故tcp的首部是tcp工作原理的核心所在。TCP的报文段首部的前20个字节是固定的(如下图),后面有4N个字节是根据需要而增加的选项(N的整数倍),因此首部的最小长度为20个字节。


(1)源端口和目的端口各占 2 个字节,分别写入源端口号和目的端口号。和前面所示的 UDP 的分用相似,TCP 的分用功能也是通过端口实现的。

(2)序号占 4 字节。序号范围是[0,232 - 1],共 232(即 4 294 967 296)个序号。序号增加到232- 1 后,下一个序号就又回到0。也就是说,序号使用 mod 232 运算。TCP 是面向字节流的。在一个 TCP 连接中传送的字节流中的每一个字节都按顺序编号。整个要传送的字节流的起始序号必须在连接建立时设置。首部中的序号字段值则指的是本报文段所发送的数据的第一个字节的序号。例如,一报文段的序号字段值是 301,而携带的数据共有 100 字节。这就表明:本报文段的数据的第一个字节的序号是 301,最后一个字节的序号是 400。显然,下一个报文段(如果还有的话)的数据序号应当从 401 开始,即下一个报文段的序号字段值应为 401。这个字段的名称也叫做“报文段序号”。

(3)确认号 占 4 字节,是期望收到对方下一个报文段的第一个数据字节的序号。例如,B 正确收到了 A 发送过来的一个报文段,其序号字段值为 501,而数据长度是 200 字节(序号 501~700),这表明 B 正确收到了 A 发送的序号 700 为止的数据。因此,B 期望收到 A 的下一个数据序号是 701,于是 B 在发送给 A 的确认报文段中把确认号置为 701。请注意,现在的确认号不是 501,也不是 700,而是 701。

    总之,应当记住:

若确认号 = N ,则表明:到序号 N - 1 为止的所有数据都已正确收到。

由于序号字段有 32 位长,可对 4 GB(即 4 千兆字节)的数据进行编号。在一般情况下可保证序号重复使用时,旧序号的数据早已通过网络到达终点了。

(5)首部长度占 4 位,这个字段实际上是指出 TCP 报文段的首部长度。由于首部中还有长度不确定的选项字段,因此数据偏移字段是必要的。但请注意,“数据偏移”的单位是 32 位字(即以 4 字节长的字为计算单位)。由于 4 位二进制数能够表示的最大十进制数字是 15,因此数据偏移的最大值是 60 字节,这也是 TCP 首部的最大长度(即选项长度不能超过 40 字节)。

(6)保留占 6 位,保留为今后使用,但目前应置为 0。

 下面有 6 个控制位说明本报文段的性质,它们的意义见下面的(7)~(12)。

(7)紧急 URG(URGent) 当 URG = 1 时,表明紧急指针字段有效。它告诉系统此报文段中有紧急数据,应尽快传送(相当于高优先级的数据),而不要按原来的排队顺序来传送。例如,已经发送了很长的一个程序要在远地的主机上运行。但后来发现了一些问题,需要取消该程序的运行。因此用户从键盘发出中断命令(Control + C )。如果不使用紧急数据,那么这两个字符将存储在接收 TCP 的缓存末尾。只有在所有的数据被处理完毕后这两个字符才被交付到接收方的应用进程。这样就浪费了许多时间。

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

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

(9)推送 PSH 当两个应用进程进行交互式的通信时,有时在一端的应用进程希望在键入一个命令后立即就能够收到对方的响应。在这种情况下,TCP 就可以使用推送(push)操作。这时,发送方 TCP 把 PSH 置 1,并立即创建一个报文段发送出去。接收方 TCP 收到 PSH = 1 的报文段,就尽快地(即“推送”向前)交付给接收应用进程,而不再等到整个缓存都填满了后再向上交付。

(10)复位 RST(ReSeT) 当 RST = 1 时,表明 TCP 连接中出现严重的差错(如由于主机崩溃或其他原因),必须释放连接,然后再重新建立运输连接。RST 置 1 还用来拒绝一个非法的报文段或拒绝打开一个连接。RST 也可称为重建或重置位。

(11)同步 SYN(SYNchronization) 在连接建立时用来同步序号。当 SYN = 1 而 ACK = 0 时,表明这是一个连接请求报文段。对方若同意建立连接,则应在响应的报文段中使 SYN = 1 和 ACK = 1。因此,SYN 置为 1 就表示这是一个连接请求或连接接受报文。

(12)终止 FIN(final,意思是“完”、“终”) 用来释放一个连接。当 FIN = 1 时,表明此报文段的发送方的数据已发送完毕,并要求释放运输连接。

(13)窗口占 2 字节。窗口值是[0,216- 1]之间的整数。窗口指的是发送本报文段的一方的接收窗口(而不是自己的发送窗口)。窗口值告诉对方:从本报文首部中的确认号算起,接收方目前允许对方发送的数据量。这所以要有这个限制,是因为接收方的数据缓存空间是有限的。总之,窗口值作为接收方让发送方设置其发送窗口的依据。

例如,设确认号是 701,窗口字段是 1000。这就表明,从 701 号算起,发送此报文段的一方还有接收 1000 个字节数据(字节序号是 701~1700)的接收缓存空间。

总之,应当记住:

窗口字段明确指出了现在允许对方发送的数据量。窗口值是经常在动态变化着。

(14)检验和占 2 字节。检验和字段检验的范围包括首部和数据这两部分。和 UDP 用户数据报一样,在计算检验和时,要在 TCP 报文段的前面加上 12 字节的伪首部。伪首部的格式与 UDP 用户数据报的伪首部一样。但应把伪首部第 4 个字节中的 17 改为 6 后,仍要加上这个伪首部来计算检验和。若使用IPv6,则相应的伪首部也要改变。

 

(15)紧急指针占 2 字节。紧急指针仅在 URG = 1 时才有意义,它指出本报文段中的紧急数据的字节数(紧急数据结束后就是普通数据)。因此紧急指针指出了紧急数据的末尾在报文段中的位置。当所有的紧急数据都处理完时,TCP 就告诉应用程序恢复到正常的操作。值得注意的是,即使窗口为零时也可发送紧急数据。

(16)选项长度可变,最长可达 40 字节。当没有使用选项时,TCP 首部长度是 20 字节。

TCP 最初只规定了一种选项,即最大报文段长度 MSS(Maximum Segment Size)[RFC 879]。请注意 MSS 这个名词的含义。MSS 是每一个 TCP 报文段中的数据字段的最大长度。数据字段加上 TCP 首部才等于整个TCP 报文段。所以 MSS 并不是整个TCP 报文段的最大长度,而是“TCP 报文段长度减去 TCP首部长度。”

为什么要规定一个最大报文长度 MSS 呢?这并不是考虑接收方的接收缓存可能放不下 TCP 报文段中的数据。实际上,MSS 与接收窗口值没有关系。我们知道,TCP 报文段的数据部分,至少要加上 40 字节的首部(TCP 首部 20 字节和 IP 首部 20 字节),这里都还没有考虑首部中的选项部分),才能组装成一个 IP 数据报。若选择较小的 MSS 长度,网络的利用率就降低。设想在极端的情况下,当 TCP 报文段只含有 1 字节的数据时,在 IP 层传输时数据报的开销至少有 40 字节(包括 TCP 报文段的首部和 IP 数据报的首部)。这样,对网络的利用率就不会超过 1/41。到了数据链路层还要加上一些开销。但反过来,若 TCP 报文段非常长,那么在 IP 层传输时就有可能要分解成多个短数据片。在终点要把收到的各个数据报片装配成原来的 TCP 报文段。当传输出错时还要进行重传。这些也都会使开销增大。

因此,MSS 应尽可能大些,只要在 IP 层传输时不需要再分片就行。由于 IP 数据报所经历的路径是动态变化的,因此在这条路径上确定的不需要再分片的 MSS,如果改走另一条路径就可能需要进行分片。因此最佳的 MSS 是很难确定的。在连接建立的过程中,双方都把自己能够支持的 MSS 写入这一字段,以后就按照这个数值传送数据,两个传送方向可以有不同的 MSS 值。若主机未填写这一项,则 MSS 默认值是 536 字节长。因此,所有在因特网上的主机都应能接受的报文长度是 536 +20(固定首部长度) =  556字节。

随着因特网的发展,又陆续增加了几个选项。如窗口扩大选项、时间戳选项等。以后又增加了有关选择确认(SACK)选项。

窗口扩大选项是为了扩大窗口。我们知道,TCP 首部中窗口字段长度是 16 位,因此最大的窗口大小为 64 字节。虽然这对早期的网络是足够的,但对于包含卫星信道的网络,传播时延和带宽都很大,要获得高吞吐率需要更大的窗口大小。

窗口扩大选项占 3 字节,其中有一个字节表示移位值 S。新的窗口值等于 TCP 首部中的窗口位数从 16 增大到(16 + S),这相当于把窗口值向左移动 S 位后获得实际的窗口大小。移位值允许使用的最大值是 14,相当于窗口最大值增大到 2(16 + 14 - 1 = 230- 1。

窗口扩大选项可以在双方初始建立 TCP 连接时进行协商。如果连接的某一端实现了窗口扩大,当它不再需要扩大其窗口时,可发送 S = 0 的选项,使窗口大小回到 16。

时间戳选项占 10 字节,其中最主要的字段时间戳字段(4 字节)和时间戳回送回答字段(4 字节)。时间戳选项有以下两个功能:

第一,用来计算往返时间 RTT。发送方在发送报文段时把当前时钟的时间放入时间戳字段,接收方在确认该报文段时把时间戳字段值复制到时间戳回送回答字段。因此,发送方在收到确认报文后,可以准确地计算出 RTT 来。

第二,用于处理 TCP 序号超过 232 的情况,这又称为防止序号绕回 PAWS (Protect Against Wrapped Sequence numbers)。我们知道,序号只有 32 位,而每增加 2个字号就会重复使用原来用过的序号。当使用高速网络时,在一次 TCP 连接的数据传送中序号很可能会被重复使用。例如,若用 1 Gb/s 的速率发送报文段,则不到 35 秒钟数据字节的序号就会重复。为了使接收方能够把新的报文段和迟到很久的报文段区分开,可以在报文段中加上这种时间戳。

3、TCP连接管理

TCP 是面向连接的协议,所有的报文传输都是基于连接,故传输连接的建立和释放也为每一次基于TCP通信中不可缺少的过程。传输连接可分为三个过程:建立链接、数据传输、释放链接。链接管理的主要功能就是使运输的建立和释放都能正常进行,以保证数据的传输。

建立链接:

建立链接的主要任务:

(1) 使通信双方确知对方的存在;

(2) 协商传输过程中所需要的参数(例如:窗口、时间戳等等);

(3) 分配传输实体资源(如缓存大小、连接表中的项目)。

在TCP中,建立连接就是采用经典的3次握手。为了建立连接,其中一方,如服务器,通过执行LISTEN和ACCEPT原语(可以指定源端机也可以不指定)被动地等待一个到达的连接请求。

另一方,如客户方,执行CONNECT原语,同时要指明它想连接到的IP地址和端口号,设置它能够接受的 TCP数据段的最大值,以及一些可选的用户数据(如口令)。CONNECT原语发送一个SYN=1,ACK=0的数据段到目的端,并等待对方响应。

数据段到达目的端后,那里的TCP实体将查看是否有进程在侦听目的端口字段指定的端口。如果没有,它将发送一个RST=l的应答,拒绝建立该连接。

如果某个进程正在对该端口进行侦听,于是便将到达的TCP数据段交给该进程。它可以接受或拒绝建立连接。如果接受,便发回一个确认数据段。交互过程如下图:

 

建立TCP链接的过程相当于一个电话系统。Socket函数等同于有电话可用,bind函数是将自己的电话号码告诉别人,listen函数是打开电话振铃,这样当有一个外来呼叫便可听到。connect函数要求知道对方的电话号码并拨打它,accept函数发生在被呼叫的人应答电话之时,由accept返回客户标识(即为客户的ip和端口号)类似于让电话机的呼叫者ID功能部件显示呼叫者的电话号码。然而两者的不同之处在于accept只是在链接建立之后返回客户标识,而呼叫者ID功能部件却在我们选择应答或者不应答之前显示呼叫者电话号码。

如果两个主机同时想在相同的两个套接字之间建立一个连接,事件的发生顺序如下图所示。这些事件的最终结果是只有一个连接建立起来,而不是两个,因为连接是由其端点所标识的。如果首先建立的连接由(x,y)标识,第二个连接也是如此,那么就生成一个表记录,即(x,y)。

 

三路握手的主要原因,即客户端对服务端的accept的确认是为了消除已失效的客户端请求到达服务端,让服务端产生伪链接一直等待客户端的数据,从而浪费资源。

释放链接:

由于tcp是全双工通信,所以链路释放需要四个分节(四次握手)完成:

(1)      首先某个应用程序首先调用close,执行主动关闭,发送一个FIN分节,标识数据发送完毕;

(2)      接收到这个FIN分节的对端执行被动关闭,这个FIN由TCP确认。它的接收也作为一个文件结束符(end of file)传递给接收端的应用程序(放在一排队等候该应用进程接收的任何其他数据之后),因为FIN的接收标识没有其他数据需要接收了;

(3)      一段时间后,接收到这个文件结束符的应用程序将调用close关闭它的套接字(ip地址+端口号),发送一个FIN的tcp报文,表示被动关闭端的数据也发送完毕;

(4)      接收到最终这个FIN的源端tcp(执行主动关闭的那一端)确认这个FIN报文。

 

TCP所涉及的建立链接和释放链接可以用状态转换图来说明,如下图:

 

下图为TCP连接的分组交换:

 

一旦一个连接建立,客户端就构造一个请求发送给服务端,一般在以太网上的tcp分节的数据部分为1460个字节,服务器处理该请求后并发送一个应答,上图中用粗箭头表示两个数据分节。需要注意的是,服务端对客户端的确认伴随其应答一起发送,以提高网络利用率,此种做法称为捎带机制(piggybacking),通常在服务端处理请求并产生应答的时间少于200ms时发送,否则分开发送,即数据应答和请求分开发送。

TIME_WAIT状态一般维持在两倍的MSL,其存在的两个理由:

(1)   可靠地实现TCP全双工链接的终止;

(2)   允许老的重复分节在网络中消逝。

 

4、可靠传输与流量控制

TCP的可靠传输主要由滑动窗口机制超时重传机制来保证,同时也可利用选择确认机制(SACK)提高网络通信利用率。

滑动窗口机制:

本部分by  (pan) http://blog.csdn.net/thisispan/article/details/7545785

(1)       窗口机制

滑动窗口协议的基本原理就是在任意时刻,发送方都维持了一个连续的允许发送的帧的序号,称为发送窗口;同时,接收方也维持了一个连续的允许接收的帧的序号,称为接收窗口。发送窗口和接收窗口的序号的上下界不一定要一样,甚至大小也可以不同。不同的滑动窗口协议窗口大小一般不同。发送方窗口内的序列号代表了那些已经被发送,但是还没有被确认的帧,或者是那些可以被发送的帧。下面举一个例子(假设发送窗口尺寸为2,接收窗口尺寸为1)

分析:①初始态,发送方没有帧发出,发送窗口前后沿相重合。接收方0号窗口打开,等待接收0号帧;②发送方打开0号窗口,表示已发出0帧但尚确认返回信息。此时接收窗口状态不变;③发送方打开0、1号窗口,表示0、1号帧均在等待确认之列。至此,发送方打开的窗口数已达规定限度,在未收到新的确认返回帧之前,发送方将暂停发送新的数据帧。接收窗口此时状态仍未变;④接收方已收到0号帧,0号窗口关闭,1号窗口打开,表示准备接收1号帧。此时发送窗口状态不变;⑤发送方收到接收方发来的0号帧确认返回信息,关闭0号窗口,表示从重发表中删除0号帧。此时接收窗口状态仍不变;⑥发送方继续发送2号帧,2号窗口打开,表示2号帧也纳入待确认之列。至此,发送方打开的窗口又已达规定限度,在未收到新的确认返回帧之前,发送方将暂停发送新的数据帧,此时接收窗口状态仍不变;⑦接收方已收到1号帧,1号窗口关闭,2号窗口打开,表示准备接收2号帧。此时发送窗口状态不变;⑧发送方收到接收方发来的1号帧收毕的确认信息,关闭1号窗口,表示从重发表中删除1号帧。此时接收窗口状态仍不变。


若从滑动窗口的观点来统一看待1比特滑动窗口、后退n及选择重传三种协议,它们的差别仅在于各自窗口尺寸的大小不同而已。1比特滑动窗口协议:发送窗口=1,接收窗口=1;后退n协议:发窗口>1,接收窗口>1;选择重传协议:发送窗口>1,接收窗口>1。

(2)       1比特滑动窗口协议

当发送窗口和接收窗口的大小固定为1时,滑动窗口协议退化为停等协议(stop-and-wait)。该协议规定发送方每发送一帧后就要停下来,等待接收方已正确接收的确认(acknowledgement)返回后才能继续发送下一帧。由于接收方需要判断接收到的帧是新发的帧还是重新发送的帧,因此发送方要为每一个帧加一个序号。由于停等协议规定只有一帧完全发送成功后才能发送新的帧,因而只用一比特来编号就够了。其发送方和接收方运行的流程图如图所示。



(3)       后退n协议

由于停等协议要为每一个帧进行确认后才继续发送下一帧,大大降低了信道利用率,因此又提出了后退n协议。后退n协议中,发送方在发完一个数据帧后,不停下来等待应答帧,而是连续发送若干个数据帧,即使在连续发送过程中收到了接收方发来的应答帧,也可以继续发送。且发送方在每发送完一个数据帧时都要设置超时定时器。只要在所设置的超时时间内仍收到确认帧,就要重发相应的数据帧。如:当发送方发送了N个帧后,若发现该N帧的前一个帧在计时器超时后仍未返回其确认信息,则该帧被判为出错或丢失,此时发送方就不得不重新发送出错帧及其后的N帧。

 

从这里不难看出,后退n协议一方面因连续发送数据帧而提高了效率,但另一方面,在重传时又必须把原来已正确传送过的数据帧进行重传(仅因这些数据帧之前有一个数据帧出了错),这种做法又使传送效率降低。由此可见,若传输信道的传输质量很差因而误码率较大时,连续测协议不一定优于停止等待协议。此协议中的发送窗口的大小为k,接收窗口仍是1。

(4)       选择重传协议

在后退n协议中,接收方若发现错误帧就不再接收后续的帧,即使是正确到达的帧,这显然是一种浪费。另一种效率更高的策略是当接收方发现某帧出错后,其后继续送来的正确的帧虽然不能立即递交给接收方的高层,但接收方仍可收下来,存放在一个缓冲区中,同时要求发送方重新传送出错的那一帧。一旦收到重新传来的帧后,就可以原已存于缓冲区中的其余帧一并按正确的顺序递交高层。这种方法称为选择重发(SELECTICE REPEAT),其工作过程如图所示。显然,选择重发减少了浪费,但要求接收方有足够大的缓冲区空间。

(5)       滑动窗口机制


滑动窗口协议可用下图来表示:

图中我们已经将字节进行了1到11的编号。由接收者通告的窗口称为提议窗口(offered window),它覆盖了第4到第9个字节,意味着接收方已经确认了第3字节之前(包括第3字节)的数据,并且通告窗口的大小是6。窗口大小与确认的顺序号(acknowledged sequence number)有关。发送者计算它的可用窗口(usable window),用以度量它可以立即发送多少数据。

随着接收者对收到数据的确认,滑动窗口随时向右移动。窗口两端的相关运动增加或减少着窗口大小。我们使用3个术语来描述窗口边缘(edge)的左右运动。

①                         当窗口左边缘靠近右边缘时称窗口闭合(window closes)。窗口闭合发生在数据已经发送并被确认的情况下;

②                         当窗口右边缘向右移动时称窗口打开(window opens)。窗口打开发生在另一端的接收进程读取已确认数据的时候,它释放了TCP接收缓冲区的空间;

③                         当窗口右边缘向左移动时称窗口收缩(window shrinks)。HostRequirement RFC强烈不鼓励这种做法,但TCP必须能够在一端发生这种情况时进行处理。


     上图表示了这三个术语。由于窗口的左边缘是受从连接另一端收到的确认号来控制的,因此它不会向左移动。如果收到一个ACK要求将左边缘向左移动,那么它是一个重复的(duplicate)的确认,并被丢弃。

如果窗口左边缘重合了右边缘,就称它为零窗口(zero window)。它将停止发送者传输任何数据。

示例,下图显示了图一数据传输中TCP滑动窗口的动态变化。

 

以此图为例,我们可以总结几个要点:

①              发送者不必传送满窗口大小的数据;

②              收到接收者对数据的确认后,窗口向右滑动。这是由于窗口大小与确认顺序号相关;

③              从段7到段8的变化,可以看出窗口可以减小,但窗口右边缘不能向左移动;

④              接收者不必等待窗口被填满才发送确认。在许多实现中,接收者每收到两个段发送一个确认。

 


(6)       滑动窗口与流量控制

流量控制用于防止在端口阻塞的情况下丢帧,这种方法是当发送或接收缓冲区开始溢出时通过将阻塞信号发送回源地址实现的。流量控制可以有效的防止由于网络中瞬间的大量数据对网络带来的冲击,保证用户网络高效而稳定的运行。滑动窗口协议是常用的流量控制方法之一。

 

5、拥塞控制

拥塞控制是防止过多的数据注入到网络中,从而不导致网络中的路由器或者链路过载,是一个全局性的过程;流程控制是点对点的通信控制,保证发送方和接收方的速度匹配。常用的拥塞控制方法有:慢开始、用赛避免、快重传和快恢复四种。下图为慢开始策略的流程图。

此图by http://www.cppblog.com/lgq0537/archive/2011/09/15/155866.html


最后

以上就是成就汽车为你收集整理的TCP/UDP 详解 (可靠传输、流量控制、连接管理等核心章节的详解)的全部内容,希望文章能够帮你解决TCP/UDP 详解 (可靠传输、流量控制、连接管理等核心章节的详解)所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。

本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
点赞(57)

评论列表共有 0 条评论

立即
投稿
返回
顶部