计算机网络(第7版)-谢希仁之学习笔记

注:本文章基本上都是复制《计算机网络(第7版)-谢希仁》这本书,我只把自己认为重点的部分复制过来。详细内容请参考《计算机网络(第7版)-谢希仁》。

第4章 网络层

本章重点内容
(1) 虚拟互连网络 的概念。
(2) IP地址与物理地址的关系。
(3)传统的分类的IP地址(包括子网掩码)和无分类域间路由选择CIDR。
(4)路由选择协议的工作原理。

4.1 网络层提供的两种服务

互联网采用的设计思路是这样的: 网络层向上只提供简单灵活的、 无连接的、 尽最大努力交付的数据报服务。
网络在发送分组时不需要先建立连接。 每一个分组(也就是IP 数据报)独立发送, 与其前后的分组无关(不进行编号)。 网络层不提供服务质量的承诺。 也就是说, 所传送的分组可能出错、 丢失、 重复和失序(即不按序到达终点), 当然也 不保证分组交付的时限。 如果主机(即端系统) 中的进程之间的通信需要是可靠的,那么就由网络的主机中的运输层负责(包括差错处理、 流量控制等)。

4.2 网际协议IP

网际协议IP是TCP/IP体系中两个最主要的协议之一, 也是最重要的互联网标准协议之一。
与IP协议配套使用的还有三个协议:
• 地址解析协议ARP (Address Resolution Protocol)
• 网际控制报文协议ICMP(Internet Control Message Protocol)
• 网际组管理协议IGMP(Internet Group Management Protocol

图4-2画出了这三个协议和网际协议IP的关系。在这一层中,ARP画在最下面,因为IP经常 要使用这个协议。ICMP和IGMP画在这一层的上 部,因为它们要使用IP协议。由于网际协议IP是用来使互连起来的许多计算机网络能够进行通信的,因此TCP/IP体系中的网络层常常被称为网际层(internetlayer), 或IP层
在这里插入图片描述

4.2.1 虚拟互联网络

从一般的概念来讲, 将网络互相连接起来要使用一些中间设备。 根据中间设备所在的层次可以有以下四种不同的中间设备:
(1) 物理层使用的中间设备叫做转发器(repeater)
(2) 数据链路层使用的中间设备叫做网桥桥接器(bridge)
(3) 网络层使用的中间设备叫做路由器(router)
(4) 在网络层以上使用的中间设备叫做网关(gateway)
图4-3(a)表示有许多计算机网络通过一些路由器进行互连。 由于参加互连的计算机网络 都使用相同的网际协议IP (Internet Protocol), 因此可以把互连以后的计算机网络看成如图 4-3(b)所示的一个虚拟互连网络(internet)。所谓虚拟互连网络也就是逻辑互连网络, 它的意 思就是互连起来的各种物理网络的异构性本来是客观存在的, 但是我们利用 IP协议就可以使这些性能各异的网络在网络层上看起来好像是一个统一的网络。 这种使用IP协议的虚拟互连网络可简称为IP网(Ip网是虚拟的, 但平常不必每次都强调 “虚拟” 二字)。 使用IP 网的好处是: 当IP 网上的主机进行通信时, 就好像在一个单个网络上通信一样, 它们看不 见互连的各网络的具体异构细节(如具体的编址方案、 路由选择协议, 等等)。 如果在这种 覆盖全球的IP网的上层使用TCP协议, 那么就是现在的互联网(Internet)
在这里插入图片描述

4.2.2 IP地址及其表示方法

1. IP地址及其表示方法
整个的互联网就是一个单一的、抽象的网络。IP地址就是给互联网上的每一台主机(或路由器)的每一个接口分配一个在全世界范围内是唯一的32位的标识符。IP地址的结 构使我们可以在互联网上很方便地进行寻址。
IP地址的编址方法共经过了三个历史阶段。
(1) 分类的IP地址:这是最基本的编址方法,在1981年就通过了相应的标准协议。
(2) 子网的划分:这是对最基本的编址方法的改进,其标准RFC950在1985年通过。
(3) 构成超网:这是比较新的无分类编址方法。 1993年提出后很快就得到推广应用。
本节只讨论最基本的分类的IP地址。 后两种方法将在4.3节中讨论。
所谓 “分类的IP地址” 就是将IP地址划分为若干个固定类, 每一类地址都由两个固定长度的字段组成, 其中第一个宇段是网络号(net-id), 它标志主机(或路由器)所连接到的网 络。 一个网络号在整个互联网范围内必须是唯一的。 第二个字段是主机号(host-id), 它标志该主机(或路由器)。一台主机号在它前面的网络号所指明的网络范围内必须是唯一的。由此可见, 个IP地址在整个互联网范围内是唯一的。
这种两级的IP地址可以记为: P地址::={<网络号>,<主机号>} (4-1)
式(4-1)中的符号 “:: =” 表示 “定义为”。图4-5 给出了各种IP地址的网络号宇段和主机号宇段, 这里A类、B类和C类地址都是单播地址(一对一 通信), 是最常用的。
在这里插入图片描述

4.2.3 IP地址与硬件地址

在学习IP地址时, 很重要的一点就是要弄懂主机的IP地址与硬件地址的区别。(注:在局域网中, 由于硬件地址己固化在网卡上的ROM中, 因此常常将硬件地址称为物理地址。 因为在局域网的MAC帧中的源地址和目的地址都是硬件地址, 因此硬件地址又称为MAC地址。 在本书中, 物理地址、 硬件地址和MAC地址 常常作为同义词出现。)
图4-8说明了这两种地址的区别。 从层次的角度看, 物理地址是数据链路层和物理层使用的地址, 而IP地址是网络层和以上各层使用的地址, 是一种逻辑地址(称IP地址为逻辑 地址是因为IP地址是用软件实现的)。
在这里插入图片描述
这里要强调指出以下几点:
(1)在IP层抽象的互联网上只能看到IP数据报
(2)虽然在IP数据报首部有源站IP地址, 但路由器只根据目的站的IP地址的网络号进行路由选择
(3)在局域网的链路层, 只能看见MAC帧
(4)尽管互连在一起的网络的硬件地址体系各不相同, 但IP 层抽象的互联网却屏蔽了 下层这些很复杂的细节。 只要我们在网络层上讨论问题, 就能够使用统一的、 抽象的 IP 地 址研究主机和主机或路由器之间的通信。

4.2.4 地址解析协议ARP

地址解析协议 ARP根据已经知道的 一个机器(主机或路由器) 的IP地址, 找出其相应的硬件地址。 图4-10说明了 ARP协议的作用。
在这里插入图片描述

下面就介绍ARP协议的要点。
我们知道, 网络层使用的是 IP 地址, 但在实际网络的链路上传送数据帧时, 最终还是必须使用该网络的硬件地址。 但IP地址和下面的网络的硬件地址之间由于格式不同而不存在简单的映射关系(例如,IP地址有32 位, 而局域网的硬件地址是48位)。此外, 在一个网络上可能经常会有新的主机加入进来, 或撤走一些主机。 更换网络适配器也会使主机的硬件地址改变。 地址解析协议ARP解决这个问题的方法是在主机ARP高速缓存中存放一个从 IP地址到硬件地址的映射表, 并且这个映射表还经常动态更新(新增或超时删除)。
每一台主机都设有 个ARP高速缓存(ARP cache), 里面有本局域网上的各主机和路由器的IP 地址到硬件地址的映射表, 这些都是该主机目前知道的一些地址。那么主机怎样知道这些地址呢?我们可以通过下面的例子来说明。
当主机A 要向本局域网上的某台主机B发送IP数据报时, 就先在其ARP高速缓存中查看有无主机B的IP地址。 如有, 就在ARP高速缓存中查出其对应的硬件地址, 再把这个硬件地址写入MAC帧, 然后通过局域网把该MAC帧发往此硬件地址。
也有可能查不到主机B的IP地址的项目。 这可能是主机B才入网, 也可能是主机A刚刚加电, 其高速缓存还是空的。 在这种情况下, 主机A 就自动运行 ARP.,然后按以下步骤找出主机B的硬件地址。
(1) ARP进程在本局域网上广播发送一个ARP请求分组。图4-11(a)是主机A 广播发送ARP 请求分组的示意图。 ARP请求分组的主要内容是: 我的 IP 地址是 209.0.0.5 ,硬件地址是00-00- C0-15-AD-18。我想知道IP 地址为209.0.0.6 的主机的硬件地址。”
(2) 在本局域网上的所有主机上运行的ARP进程都收到此ARP请求分组。
(3) 主机B的IP地址与ARP请求分组中要查询的IP地址一致, 就收下这个ARP请求分组, 并向主机A发送ARP响应分组, 同时在这个ARP响应分组中 写入自己的硬件地址。 由于其余的所有主机的IP地址都与ARP请求分组中要查询的IP地址不一致, 因此都不理睬这个ARP请求分组, 见图4-11例。 ARP响应分组的主要内容是: “我的IP地址是209.0.0.6,我的硬件地址是08-00-2B-00-EE-0A。”请注意,虽然ARP请求分组是广播发送的,但ARP响应分组是普通的单播, 即从一个源地址发送到一个目的地址。
在这里插入图片描述
(4)主机A收到主机B的ARP响应分组后 ,就在其ARP高速缓存中写入主机B的IP地址到硬件地址的映射。
当主机A向B发送数据报时, 很可能以后不久主机B还要向A发送数据报 ,因而主机B也可能要向A发送ARP请求分组。 为了减少网络上的通信量, 主机A在发送其ARP请求分组时, 就把自己的IP地址到硬件地址的映射写入ARP请求分组。 当主机B收到A的ARP请求分组时,就把主机A这一地址映射写入主机B自己的ARP高速缓存中,以后主机B向A发送数据报时就很方便了。
ARP对保存在高速缓存中的每一个映射地址项目都设有生存时间(例如,10~20分钟)。凡超过生存时间的项目就从高速缓存中删除掉。
请注意,ARP是解决同-个局域网上的主机或路由器的 IP地址和硬件地址的映射问题。
从IP 地址到硬件地址的解析是自动进行的, 主机的用户对这种地址解析过程是不知道 的。只要主机或路由器要和本网络上的另一个己知IP地址的主机或路由器进行通信,ARP协议就会自动地把这个IP地址解析为链路层所需要的硬件地址。

4.2.5 IP数据报的格式

IP数据报的格式能够说明IP协议都具有什么功能。在TCP/IP的标准中,各种数据格 式常常以32位(即4字节)为单位来描述。图4-13是IP数据报的完整格式。
在这里插入图片描述
1. IP数据报首部的固定部分中的各宇段
(1)版本 占4位,指IP协议的版本。通信双方使用的IP协议的版本必须致。目前广泛使用的IP协议版本号为4(即1Pv4)。
(2)首部长度 占4位,可表示的最大十进制数值是15。请注意,首部长度字段所表示数的单位是32位字(1个32位宇长是4字节)。因为IP首部的固定长度是20字节,因此首部长度字段的最小值是5(即二进制表示的首部长度是0101)。而当首部长度为最大值1111时(即十进制数的15),就表明首部长度达到最大值15个32位字长,即60字节。当 IP分组的首部长度不是4字节的整数倍时,必须利用最后的填充字段加以填充。因此IP数 据报的数据部分永远在4宇节的整数倍时开始,这样在实现IP协议时较为方便。首部长度 限制为60字节的缺点是有时可能不够用。但这样做是希望用户尽量减少开销。最常用的首 部长度是20字节(即首部长度为0101),这时不使用任何选项。
(3)区分服务 占8位,用来获得更好的服务。在一般情况下都不使用这个字段。
这个字段[盯C2474, 3168, 3260]。
(4)总长度 总长度指首部和数据之和的长度,单位为字节。总长度字段为16位,因此数据报的最大长度为65535(2的16次方减1)字节。然而实际上传送这样长的数据报在现实中是极少遇到的。
我们知道, 在 IP层下面的每一种数据链路层协议都规定了一个数据帧中的数据字段的 最大长度,这称为最大传送单元 MTU (Maximum Transfer Unit)。当一个IP数据报封装成链路层的帧时, 此数据报的总长度(即首部加上 数据部分) 一定不能超过下面的数据链路层所规定的 MTU 值。例如, 最常用的以太网就规定其 MTU 值是 1500 字节。若所传送的数据报 长度超过数据链路层的 MTU 值, 就必须把过长的数据报进行分片处理。
(5)标识(identification) 占 16 位。IP 软件在存储器中维持一个计数器, 每产生一个数据报, 计数器就加1, 并将此值赋给标识字段。但这个 “标识” 并不是序号, 因为 IP 是 无连接服务, 数据报不存在按序接收的问题。当数据报由于长度超过网络的 MTU 而必须分片时, 这个标识字段的值就被复制到所有的数据报片的标识字段中。相同的标识字段的值使分片后的各数据报片最后能正确地重装成为原来的数据报。
(6)标志(flag) 占 3 位, 但目前只有两位有意义。
• 标志字段中的最低位记为 MF (More Fragment)。MF = 1 即表示后面 “还有分片 ” 的数据报。MF=0 表示这己是若干数据报片中的最后一个。
• 标志字段中间的一位记为 DF (Don’t Fragment),意思是 “ 不能分片”。只有当 DF= 0时才允许分片。
(7)片偏移 占13位。片偏移指出:较长的分组在分片后, 某片在原分组中的相对位置。也就是说, 相对于用户数据字段的起点, 该片从何处开始。片偏移以8个字节为偏移 单位。这就是说, 每个分片的长度一定是8字节(64 位) 的整数倍。
(8)生存时间 占8位,生存时间字段常用的英文缩写是TTL(Time To Live),表明这是数据报在网络中的寿命。由发出数据报的源点设置这个字段。其目的是防止无法交付的 数据报无限制地在互联网中兜圈子(例如从路由器R1转发到R2,再转发到R3,然后又转发到R1),因而白白消耗网络资源。最初的设计是以秒作为TTL值的单位。每经过一个路由 器时,就把TTL减去数据报在路由器所消耗掉的一段时间。若数据报在路由器消耗的时间 小于1秒,就把TTL值减1。当TTL值减为零时,就丢弃这个数据报。
然而随着技术的进步,路由器处理数据报所需的时间不断在缩短,一般都远远小于1秒,后来就把TTL宇段的功能改为**“跳数限制”(但名称不变)。路由器在每次转发数据报之前就把TTL值减1。若TTL值减小到零,就丢弃这个数据报,不再转发。因此,现在TTL的单位不再是秒,而是跳数**。TTL的意义是指明数据报在互联网中至多可经过多少个 路由器。显然,数据报能在互联网中经过的路由器的最大数值是255。若把TTL的初始值 设置为1,就表示这个数据报只能在本局域网中传送。因为这个数据报一传送到局域网上的某个路由器,在被转发之前TTL值就减小到零,因而就会被这个路由器丢弃。
9)协议 占8位,协议字段指出此数据报携带的数据是使用何种协议,以便使目的 主机的IP层知道应将数据部分上交给哪个协议进行处理。
常用的一些协议和相应的协议字段值如下:
在这里插入图片描述
(10)首部检验和 占16位。这个字段只检验数据报的首部,但不包括数据部分。这是因为数据报每经过一个路由器,路由器都要重新计算一下首部检验和(一些字段,如生存时间、标志、片偏移等都可能发生变化)。不检验数据部分可减少计算的工作量。
(11)源地址 占32位。
(12)目的地址 占32位。

2. IP数据报首部的可变部分
IP 数据报首部的可变部分就是一个选项字段。 选项字段用来支持排错、 测量以及安全等措施, 内容很丰富。 此字段的长度可变, 从1个字节到40个字节不等, 取决于所选择的 项目。 某些选项项目只需要1个字节, 它只包括1个字节的选项代码。 而有些选项需要多个字节, 这些选项一个个拼接起来, 中间不需要有分隔符, 最后用全0的填充宇段补齐成为4 字节的整数倍。

4.2.6 IP层转发分组的流程

可以把整个的网络拓扑简化为图4-16(b)所示的那样。 在简化图中, 网络变成了一条链路, 但每一个路由器旁边都注明其IP 地址。这样的简化图强调了在互联网上转发分组时, 是从一个路由器转发到下一个 路由器
总之, 在路由表中, 对每一条路由最主要的是以下两个信息:(目的网络地址, 下一跳地址)
在这里插入图片描述

于是, 我们就根据目的网络地址来确定下一跳路由器, 这样做可得出以下的结果。
(1) IP数据报最终一定可以找到目的主机所在目的网络上的路由器(可能要通过多次的间接交付)。
(2)只有到达最后一个路由器时, 才试图向目的主机进行直接交付。
这里我们应当强调指出, 在IP数据报的首部中没有地方可以用来指明 “ 下一跳路由器的IP地址”。在IP数据报的首部写上的IP地址是源IP地址和目的IP地址, 而没有中间经过的路由器的IP地址。 既然IP数据报中没有下一跳路由器的IP地址, 那么待转发的数据报又怎样能够找到下一跳路由器呢?
当路由器收到一个待转发的数据报, 在从路由表得出下一跳路由器的IP地址后, 不是把这个地址填入IP数据报, 而是送交数据 链路层的网络接口软件。 网络接口软件负责把下 一跳路由器的IP地址转换成硬件地址(必须使用ARP), 并将此硬件地址放在链路层的MAC帧的首部, 然后根据 这个硬件地址找到下一跳路由器。 由此可见, 当发送一连串的数据报时, 上述的这种查找路由表、 用ARP得到硬件地址、 把硬件地址写入MAC帧的首部 等过程, 将不断地重复进行, 造成了一定的开销。
根据以上所述, 可归纳出分组转发算法如下:
(1) 从数据报的首部提取目的主机的IP地址D,得出目的网络地址为N。
(2) 若N 就是与此路由器直接相连的某个网络地址, 则进行直接交付, 不需要再经过其他的路由器, 直接把数据报交付目的主机(这里包括把目的主机地址 D转换为具体的硬件 地址, 把数据报封装为MAC帧, 再发送此帧);否则就是间接交付, 执行(3)。
(3) 若路由表中有目的地址为D的特定主机路由, 则把数据报传送给路由表中所指明的 下一跳路由器:否则, 执行(4)。
(4)若路由表中有到达网络N 的路由, 则把数据报传送给路由表中所指明的下一跳路由器;否则,执行(5)。
(5)若路由表中有一个默认路由, 则把数据报传送给路由表中所指明的默认路由器:否则, 执行(6)。
(6)报告转发分组出错。
这里我们要再强调一下, 路由表并没有给分组指明到某个网络的完整路径(即先经过 哪一个路由器, 然后再经过哪一个路由器, 等等)。 路由表指出, 到某个网络应当先到某个路由器(即下一跳路由器), 在到达下一跳路由器后, 再继续查找其路由表, 知道再下一步应当到哪一个路由器。 这样一步一步地查找下去, 直到最后到达目的网络。

4.3 划分子网和构造超网

4.3.1 划分子网

1. 从两级IP地址到三级IP地址
在今天看来, 在ARPANET的早期,IP地址的设计确实不够合理。
第一,IP地址空间的利用率有时很低。
第二, 给每一个物理网络分配一个网络号会使路由表变得太大因而使网络性能变坏。
第三,两级IP地址不够灵活。
为解决上述问题, 从1985年起在IP地址中又增加了一个 “子网号字段”,使两级IP地址变成为三级 IP 地址, 它能够较好地解决上述问题, 并且使用起来也很灵活。 这种做法叫做划分子网(subnetting) , 或子网寻址子网路由选择。 划分子网已成为互联网的 正式标准协议。
划分子网的基本思路如下:
(1)一 个拥有许多物理网络的单位, 可将所属的物理网络划分为若干个子网(subnet)。 划分子网纯属一个单位内部的事情。 本单位以外的网络看不见这个网络是由多少个子网组成, 因为这个单位对外仍然表现为一个网络
(2) 划分子网的方法是从网络的主机号借用若干位作为子网号(subnet-id), 当然主机号 也就相应减少了同样的位数。 于是两级IP地址在本单位内部就变为三级IP地址 :网络号、 子网号和主机号。 也可以用以下记法来表示 :
IP地址:: = { 〈网络号〉, 〈子网号〉, <主机号〉}
(3)凡是从其他网络发送给本单位某台主机的IP数据报, 仍然是根据IP数据报的目的网络号找到连接在本单位网络上的路由器。 但此路由器在收到IP数据报后, 再按目的网络号和子网号找到目的子网, 把IP数据报交付目的主机。
总之,当没有划分子网时,IP地址是两级结构。划分子网后IP地址变成了三级结构。划分子网只是把IP地址的主机号这部分进行再划分,而不改变E地址原来的网络号。

2. 子网掩码
现在剩下的问题就是:假定有一个数据报(其目的地址是145.13.3.10)已经到达了路由器R1。那么这个路由器如何把它转发到子网145.13.3.0昵?

4.3.2 使用子网时分组的转发

在划分子网的情况下, 分组转发的算法必须做相应的改动。
我们应当注意到, 使用子网划分后, 路由表必须包含以下三项内容: 目的网络地址子网掩码下一跳地址
在划分子网的情况下, 路由器转发分组的算法如下:
(1) 从收到的数据报的首部提取目的IP地址D。
(2) 先判断是否为直接交付。对路由器直接相连的网络逐个进行检查: 用各网络的子网掩码和D逐位相 “ 与 ”(AND操作), 看结果是否和相应的网络地址匹配。 若匹配, 则把分 组进行直接交付(当然还需要把D转换成物理地址, 把数据报封装成帧发送出去), 转发任务结束。 否则就是间接交付, 执行(3)。
(3) 若路由表中有目的地址为D 的特定主机路由, 则把数据报传送给路由表中所指明的 下一跳路由器;否则, 执行(4)。
(4) 对路由表中的每一行(目的网络地址, 子网掩码, 下一跳地址), 用其中的子网掩码和D逐位相 “ 与 ”(AND操作), 其结果为N。 若N与该行的目的网络地址匹配, 则把数 据报传送给该行指明的下一跳路由器:否则, 执行(5)。
(5)若路由表中有一个默认路由, 则把数据报传送给路由表中所指明的默认路由器:否 则, 执行(6)。
(6)报告转发分组出错。

4.3.3

1. 网络前缀
划分子网在一定程度上缓解了互联网在发展中遇到的困难。然而在1992年互联网仍然面临三个必须尽早解决的问题,这就是:
(1) B类地址在1992年己分配了近一半,眼看很快就将全部分配完毕!
(2) 互联网主干网上的路由表中的项目数急剧增长(从几千个增长到几万个)。
(3) 整个1Pv4的地址空间最终将全部耗尽。在2011年2月3日,IANA宣布1Pv4地址已经耗尽了。
当时预计前两个问题将在1994年变得非常严重。因此IETF很快就研究出采用无分类编址 的方法来 解决前两个问题。
使用变长子网掩码VLSM(Variable Length Subnet M臼k)可进一步提高IP地址资源的利用率。 在VLSM的基础上又进一步研究出无分类编址方法,它的正式名字是无分类域间路由选择CIDR(Classless Inter-Domain Routing, CIDR的读音是 “sider ”)。
IDR最主要的特点有两个:
(1) CIDR消除了传统的A类、 B类和C类 地址以及划分子网的概念, 因而能更加有效地分配IPv4 的地址空间。 CIDR把32位的 IP 地址划分为前后两个 部分。 前面部分是 “网络前缀” (network-prefix)(或简称为“前缀“), 用来指明网络, 后面部分则用来指明主机。 其记法是:
IP地址 ::= {〈网络前缀〉, 〈主机号〉}
CIDR还使用 “斜线记法” (slashnotation), 或称为CIDR记法, 即在IP地址后面加上 斜线 “/”,然后写上网络前缀所占的位数。
(2) CIDR把网络前缀都相同的连续的IP地址组成一个 “ CIDR地址块” 。 我们只要知道CIDR地址块中的任何一 个地址, 就可以知道这个地址块的起始地址(即最小地址) 和最大地址, 以及地址块中的地址数。
由于一个CIDR地址块中有很多地址, 所以在路由表中就利用CIDR地址块来查找目的网络。 这种地址的聚合常称为路由聚合(route aggregation), 它使得路由表中的一个项目可以表示原来传统分类地址的很多个(例如上千个) 路由。 路由 聚合也称为构成超网 ( supemetting) 。

2. 最长前缀匹配
在使用CIDR时, 由 于采用了网络前缀这种记法 ,IP地址由 网络前缀和主机号这两个部分组成,因此在路由表中的项目也要有相应的改变。 这时, 每个项目由 “ 网络前缀” 和“下一跳地址”组成。但是在查找路由表时可能会得到不止一个匹配结果。这样就带来一个问题:我们应当从这些匹配结果中选择哪一条路由呢?
正确的答案是:应当从匹配结果中选择具有最长网络前缀的路由。 这叫做最长前缀匹 (longest-prefix matching), 这是因为网络前缀越长, 其地址块就越小,因而路由就越具体(more specific)。 最长前缀匹配又称为最长匹配最佳匹配

3. 使用二叉线索查找路由表
使用CIDR后, 由于要寻找最长前缀匹配, 使路由表的查找过程变得更加复杂了。为了进行更加有效的查找, 通常是把无分类编址的路由表存放在一种层次的数据结构中, 然后自上而下地按层次进行查找。 这里最常用的就是二叉线索(binary trie), 它是一种特殊结构树。IP地址中从左到右的比特值决定了从根节点逐层向下层延伸的路径, 而二 叉线索中的各个路径就代表路由表中存放的各个地址。

4.4 网际控制报文协议ICMP

为了更有效地转发IP数据报和提高交付成功的机会,在网际层使用了网际控制报文协议ICMP(Internet Control Message Protocol) 。ICMP允许主机或路由器报告差错情况和提供有关异常情况的报告。ICMP是互联网的标准协议。但ICMP不是高层协议,是IP 层的协议。ICMP报文作为IP层数据报的数据,加上数据报的首部,组成IP数据报发送出去。ICMP报文格式如图4-27所示。
在这里插入图片描述

4.4.1 ICMP报文的种类

ICMP报文的种类有两种, 即ICMP差错报告报文ICMP询问报文
ICMP报文的前4个字节是统一的格式, 共有三个字段: 类型、 代码和检验和。 接着的 4个字节的内容与ICMP的类型有关。 最后面是数据字段, 其长度取决于ICMP的类型。 表4-8给出了几种常用的ICMP报文类型。
在这里插入图片描述
ICMP报文的代码字段是为了进一步区分某种类型中的几种不同情况。 检验和宇段用来检验整个ICMP 报文。 我们应当还记得, IP数据报首部的检验和并不检验 IP数据报的内 容, 因此不能保证经过传输的ICMP报文不产生差错。
表4-8给出的ICMP差错报告报文共有四种, 即:
(1 )终点不可达 当路由器或主机不能交付数据报时就向源点发送终点不可达报文。
(2 )时间超过 当路由器收到生存时间为零的数据报时, 除丢弃该数据报外, 还要向 源点发送时间超过报文。 当终点在预先规定的时间内不能收到一个数据报的全部数据报片时, 就把己收到的数据报片都丢弃, 并向源点发送时间超过报文。
(3 )参数问题 当路由器或目的主机收到的数据报的首部中有的宇段的值不正确时,就丢弃该数据报, 并向源点发送参数问题报文。
(4)改变路由(重定向) 路由器把改变路由报文发送给主机, 让主机知道下次应将数据报发送给另外的路由器(可通过更好的路由)。
常用的ICMP询问报文有两种, 即:
(1)回送请求和回答 ICMP回送请求报文是由主机或路由器向一个特定的目的主机发出的询问 。 收到此报文的主机必须给源主机或路由器发送ICMP回送回答报文。 这种询问报文用来测试目的站是否可达以及了解其 有关状态。
(2)时间戳请求和回答 ICMP 时间戳请求报文是请某台主机或路由器回答当前的日期和时间。 在ICMP时间戳回答报文中有一个32位的宇段, 其中写入的整数代表从1900年 1月1日起到当前时刻一共有多少秒。 时间戳请求与回答可用于时钟同步和时间测量。

4.4.2 ICMP的应用举例

ICMP的 一个重要应用就是分组网间探测PING (Packet InterNet Groper), 用来测试两台主机之间的连通性。 PING使用了ICMP回送请求与回送回答报文。 PING是 应用层直接使用网络层ICMP的 一个例子。 它没有通过运输层 的TCP或UDP。

4.5 互联网的路由选择协议

……
本章的重要概念
• TCP/IP体系中的网络层向上只提供简单灵活的、 无连接的、 尽最大努力交付的数据报服务。 网络层不提供服务质量的承诺, 不保证分组交付的时限, 所传送的分组 可能出错、 丢失、 重复和失序。 进程之间通信的可靠性由运输层负责。
• IP网是虚拟的, 因为从网络层上看, E网就是一个统一的、 抽象的网络(实际上是异构的)。 E层抽象的互联网屏蔽了• 下层网络很复杂的细节, 使我们能够使用统一的、 抽象的IP地址处理主机之间的通信问题。
在互联网上的交付有两种:在本网络上的直接交付(不经过路由器〉和到其他网络 的间接交付(经过至少一个路由器, 但最后一次一定是直接交付)。
• 一个IP地址在整个互联网范围内是唯一的。 分类的E地址包括A类、 B类和C类地址(单播地址〉, 以及D类地址(多播地址)。 E类地址未使用。
• 分类的IP地址由网络号宇段(指明网络) 和主机号宇段(指明主机) 组成。 网络号宇段最前面的类别位指明IP地址的类别。
• IP地址是一种分等级的地址结构。IP地址管理机构在 分配E地址时只分配网络号, 而主机号则由得到该网络号的单位自行分配。 路由器仅根据目的主机所连接的网络号来转发分组。
• IP地址标志一台主机(或路由器) 和一条链路的接口。 多归属主机同时连接到两个或更多的网络上。 这样的主机同时具有两个或更多的 IP地址, 其网络号必须是不同的。 由于一个路由器至少应当连接到两个网络, 因此一个路由器至少应当有两 个不同的IP地址。
• 按照互联网的观点, 用转发器或网桥连接起来的若干个局域网仍为一个网络。 所有分配到网络号的网络(不管是范围很小的局域网, 还是可能覆盖很大地理范围的广域网)都是平等的。
• 物理地址(即硬件地址〉是数据链路层和物理层使用的地址, 而E地址是网络层和以上各层使用的地址, 是一种逻辑地址(用软件实现的), 在数据链路层看不见数据报的IP地址。
• IP数据报分为首部和数据两部分。首部的前一部分是固定长度, 共20 宇节, 是所有IP数据报必须具有的(源地址、 目的地址、 总长度等重要宇段都在固定首部中)。一些长度可变的可选字段放在固定首部的后面。
• IP首部中的生存时间宇段给出了IP数据报在互联网中所能经过的最大路由器数,可防止E数据报在互联网中无限制地兜圈子。
• 地址解析协议ARP把 E地址解析为硬件地址, 它解决同一个局域网上的主机或路由 器的E地址和硬件地址的映射问题。ARP的高速缓存可以大大减少网络上的通信量。
• 在互联网中, 我们无法仅根据硬件地址寻找到在某个网络上的某台主机。因此, 从IP地址到硬件地址的解析是非常必要的。
• 无分类域间路由选择CIDR 是解决目前 IP 地址紧缺的一个好方法。CIDR记法把IP地址后面加上斜线 “ /”,然后写上前缀所占的位数。前缀(或网络前缀)用来指明网络, 前缀后面的部分是后缀, 用来指明主机。CIDR把前缀都相同的连续的IP地址组成一个 “CIDR地址块”。IP地址的分配都以CIDR地址块为单位。
• CIDR的32位地址掩码(或子网掩码)由一串1和一串0组成,而1的个数就是前缀的长度。只要把IP地址和地址掩码逐位进行“逻辑与(AND)”运算,就很容易得出网络地址。A类地址的默认地址掩码是255.0.0.0。B类地址的默认地址掩码是255.255.0.0。C类地址的默认地址掩码是255.255.255.0。
• 路由聚合( 把许多前缀相同的地址用一个来代替)有利于减少路由表中的项目, 减少路由器之间的路由选择信息的交换, 从而提高了整个互联网的性能。
• 转发 和 路由选择 有区别。 转发” 是单个路由器的动作。"路由选择” 是许多路由器共同协作的过程, 这些路由器相互交换信息, 目的是生成路由表, 再从路由表导出转发表。若采用自适应路由选择算法, 则当网络 拓扑变化时, 路由表和转
发表都能够自动更新。在许多情况下, 可以不考虑转发表和路由表的区别, 而都使用路由表这一名词。
……

第5章 运输层

运输层是整个网络体系结构中的关键层次之一。 一定要弄清以下一些重要概念:
(1) 运输层为相互通信的应用进程提供逻辑通信。
(2) 端口和套接字的意义。
(3) 无连接的UDP的特点。
(4) 面向连接的TCP的特点。
(5) 在不可靠的网络上实现可靠传输的工作原理, 停止等待协议和ARQ协议。
(6) TCP的滑动窗口、 流量控制、 拥塞控制和连接管理。

5.1 运输层协议概述

5.1.1 进程之间的通信

两台主机进行通信就是两台主机中的应用进程互相通信。IP协议虽然能把分组送到目的主机, 但是这个分组还停留在主机的网络层而没有 交付主机中的应用进程。 从运输层的角度看, 通信的真正端点并不是主机而是主机中的进程。 也就是说, 端到端 的通信是应用进程之间的通信。
一台主机中经常有多个应用进程同时分别和另一台主机中的多个应用进程通信。 这表明运输层有一个很重要的功能一一复用(multiplexing)和分用(demultiplexing)。这里的 “ 复用 ” 是指在发送方不同的应用进程都可以使用同一个运输层协议传送数据(当然需要加上适当的首部), 而 “分用” 是指接收方的运输层在剥去报文的首部后能够把这些数据正确交付目的应用进程。
网络层为主机之间提供逻辑通信,而 运输层为应用进程之间提供端到端的逻辑通信。“逻辑通信” 的意思是:从应用层来看, 只要把应用层报文交给下面的运输层, 运输层就可以把这报文传送到对方的运输层(哪怕双方相距很远, 例如几千公里), 好像这 种通信就是沿水平方向直接传送数据。 但事实上这两个运输层之间并没有一条水平方向的物理连接。 数据的传送是沿着图中的虚线方向(经过多个层次)传送的
运输层向高层用户屏蔽了下面网络核心的细节(如网络拓扑、 所采用的路由选择协议等), 它使应用进程看见的就是好像在两个运输层实体之间有一条端到端的逻辑通信信道 。

5.1.2 运输层的两个主要协议

TCP/IP运输层的两个主要协议都是互联网的正式标准,即:
(1)用户数据报协议UDP(User Datagram Protocol) [RFC 768]
(2)传输控制协议TCP(Transmission Control Protocol) [RFC 793]
图5-3给出了这两种协议在协议战中的位置。
在这里插入图片描述
按照OSI的术语, 两个对等运输实体在通信时传送的数据单位叫做运输协议数据单元 TPDU (Transport Protocol Data Unit)。 但在TCP/IP体系中 , 则根据所使用的协议是TCP或UDP, 分别称之为TCP报文段(segment)或UDP用户数据报
UDP在传送数据之前不需要先建立连接。 远地主机的运输层在收到UDP报文后, 不需要给出任何确定。虽然UDP不提供可靠交付,但在某些情况下UDP却是一种最有效的工作方式。
TCP则提供面向连接的服务。在传送数据之前必须先建立连接 , 数据传送结束后要释放连接。 TCP不提供广播或多播服务。 由于TCP要提供可靠的、 面向连接的运输服务 ,因此不可避免地增加了许多的开销, 如确认、 流量控制、 计时器以及连接管理等。 这不仅使协议数据单元的首部增大很多 , 还要占用许多的处理机资源。

5.1.3 运输层的端口

运输层使用协议端口号(protocol port number), 或通常简称为端口(port)。这就是说, 虽然通信的终点是应用进程, 但只要把所传送的报文交到目的主 机的某个合适的目的端口, 剩下的工作(即最后交付目的进程〉就由 TCP 或 UDP 来完成。
TCP/IP的运输层用一个16位端口号来标志一个端口。 但请注意, 端口号只具有本地意 义, 它只是为了标志本计算机应用层中的各个进程在和运输层交互时的层间接口。 在互联网 不同计算机中, 相同的端口号是没有关联的。
互联网上的计算机通信是采用客户-服务器方式。 客户在 发起通信请求时, 必须先知道对方服务器的IP地址和端口号。 因此运输层的端口号分为下面的两大类。
(1)服务器端使用的端口号 这里又分为两类, 最重要的一类叫做熟知端口号(well-known port number)或系统端口号, 数值为0~1023。 这些数值可在网址www.iana.org查到。 IANA把这些端口号指派给 了 TCP/IP最重要的一些应用程序, 让所有的用户都知道。 当一种新的应用程序出现后,IANA必须为它指派一个熟知端口, 否则互联网上的其他应用进程 就无法和它进行通信。 表5-2给出了一些常用的熟知端口号。
在这里插入图片描述

另一类叫做登记端口号, 数值为1024~49151。 这类端口号是为没有熟知端口号的应用程序使用的。使用这类端口号必须 在IANA按照规定的手续登记,以防止重复。
(2)客户端使用的端口号 数值为49152~65535。由于这类端口号仅在客户进程运行时才动态选择,因此又叫做短暂端口号。这类端口号留给客户进程选择暂时使用。当服务器进程收到客户进程的报文时,就知道了客户进程所使用的端口号,因而可以把数据发送给客户进程。通信结束后,刚才己使用过的客户端口号就不复存在,这个端口号就可以供其他客户进程使用。

5.2 用户数据报协议UDP

5.2.1 UDP概述

用户数据报协议UDP只在IP的数据报服务之上增加了很少一点的功能,这就是复用和分用的功能以及差错检测的功能。UDP的主要特点是:
(1) UDP是无连接的, 即发送数据之前 不需要建立连接(当然, 发送数据结束时也没有 连接可释放), 因此减少了开销和发送数据之前的时延。
(2) UDP使用尽最大努力交付, 即不保证可靠交付, 因此主机 不需要维持复杂的连接状态表(这里面有许多参数)。
(3) UDP是面向报文的。 发送方的UDP 对应用 程序交下来的报文,在添加首部后就向下交付IP层 。UDP对应用层交下来的报文, 既不 合并, 也不拆分,而是保留这些报文的边界。 这就是说, 应用层交给UDP多长的报文,UDP 就照样发送, 即一次发送一个报文,如图5-4所示。在接收方的UDP,对IP层交上来的UDP用户数据报 ,在去除首部后就原封不动地交付上层的应用进程,也就是说,UDP一次交付一完整的报文。因此,应用程序必须选择合适大小的报文。若报文太长 ,UDP把它交给IP层后,IP层在传送时可能要进行分片,这会降低IP层的效率。 反之,若报文太短,UDP把它交给IP层后, 会使IP 数据报的首部的相对长度太大 , 这也降低了IP层的效率。
在这里插入图片描述
(4) UDP没有拥塞控制, 因此网络出现的拥塞不 会使源主机的发送速率降低。 这对某些实时应用是很重要的。 很多的实时应用(如IP电话、 实时视频会议等)要求源主机 以恒定的速率发送数据,并且允许在网络发生拥塞时丢失一些数据,但却不允许数据有太大的时延。UDP正好适合这种要求。
(5)UDP支持一对一、一对多、多对一和多对多的交互通信。
(6)UDP的首部开销小,只有8个字节,比TCP的20个字节的首部要短。

5.2.2 UDP的首部格式

用户数据报UDP有两个字段:数据宇段和首部宇段。 首部字段很简单, 只有8个宇节(图5-5),由四个字段组成, 每个字段的长度都是两个字节。 各宇段意义如下:
(1)源端口 源端口号。 在需要对方回信时选用。 不需要时可用全0。
(2)目的端口 目的端口号。 这在终点交付报文时必须使用。
(3) 长度 UDP用户数据报的长度, 其最小值是8 (仅有首部)。
(4) 检验和 检测UDP用户数据报在传输中是否有错。 有错就丢弃。
在这里插入图片描述
当运输层从IP层收到UDP数据报时, 就根据首部中的目的端口, 把UDP数据报通过相应的端口, 上交最后的终点一一应用进程。 图5-6是UDP基于端口分用的示意图。
在这里插入图片描述
如果接收方 UDP发现收到的报文中的目的端口号不正确(即不存在对应于该端口号的 应用进程), 就丢弃该报文, 并由网际控制报文协议ICMP发送 “端口不可达” 差错报文给发送方。
UDP用户数据报首部中检验和的计算方法有些特殊。 在计算检验和时, 要在UDP用户数据报之前增加12个字节的伪首部。 所谓 “伪首部” 是因为这种伪首部并不是UDP用户数据报真正的首部。 只是在计算检验和时, 临时添加在UDP用户数据报前面, 得到→个临时的 UDP用户数据报。 检验和就是按照这个临时的UDP用户数据报来计算的。 伪首部既不向下传送也不向上递交 , 而仅仅是为了计算检验和。

5.3 传输控制协议TCP概述

5.3.1 TCP最主要的特点

TCP是TCP/IP体系中非常复杂的一个协议。下面介绍TCP最主要的特点。
(1) TCP是面向连接的运输层协议。 这就是说, 应用程序在使用TCP协议之前, 必须先建立TCP连接。 在传送数据完毕后, 必须释放已经建立的TCP连接。 也就是说, 应用进程之间的通信好像在 “ 打电话”:通话前要先拨号建立连接, 通话结束后要挂机释放连接。
(2) 每一条TCP连接只能有两个端点(endpoint), 每一条TCP连接只能是点对点的(一对一 )。 这个问题后面还要进一步讨论。
(3) TCP提供可靠交付的服务。 通过TCP连接传送的数据, 无差错、 不丢失、 不重复,并且按序到达。
(4) TCP 提供全双工通信。 TCP允许通信双方的应用进程在任何时候都能发送数据。 TCP连接的两端都设有发送缓存和接收缓存, 用来临时存放双向通信的数据。 在发送时,应用程序在把数据传送给TCP的缓存后, 就可以做自己的事, 而TCP在合适的时候把数据发送出去。 在接收时, TCP把收到的数据放入缓存, 上层的应用进程在合适的时候读取缓 存中的数据。
(5)面向字节流。 TCP中的 “ ” (stream)指的是流入到进程或从进程流出的字节序列。 面向字节流” 的含义是: 虽然应用程序和TCP的交互是一次 一个数据块(大小不等), 但TCP把应用程序交下来的数据仅仅看成是一连串的无结构的字节流。 TCP并不知道所传送的字节流的含义。 TCP不保证接收方应用程序所收到的数据块和发送方应用程序所发出的数据块具有对应大小的关系(例如, 发送方应用程序交给发送方的TCP共10个数据块, 但接收方的TCP可能只用了4个数据块就把收到的字节流交付上层的应用程序)。但接收方应用程序收到的字节流必须和发送方应用程序发出的字节流完全 一样。 当然, 接收方的应用程序必须有能力识别收到的宇节流, 把它还原成有意义的应用层数据。 图5-8是上述概念的示意图。
在这里插入图片描述
为了突出示意图的要点, 我们只画出了一个方向的数据流。 但请注意, 在实际的网络中, 一个TCP报文段包含上千个字节是很常见的, 而图中的各部分都只画出了几个字节,这仅仅是为了更方便地说明 “面向宇节流” 的概念。 另一点很重要的是: 图5-8中的TCP 连接是一条虚连接(也就是逻辑连接〉, 而不是一条真正的物理连接。 TCP报文段先要传送
到IP层, 加上IP首部后, 再传送到数据链路层。 再加上数据链路层的首部和尾部后, 才离开主机发送到物理链路。

5.3.2 TCP的连接

TCP把连接作为最基本的抽象。TCP的许多特性都与TCP是面向连接的这个基本特性有关。 因此我们对TCP连接需要有更清楚的了解。
前面已经讲过, 每一条TCP连接有两个端点。 那么,TCP连接的端点是什么呢?不是主机, 不是主机的 IP 地址, 不是应用进程,也不是运输层的协议端口。TCP连接的端点叫做套接字(socket)或插口。 根据盯C 793的定义: 端口号拼接到( concatenated with) IP地址即构成了套接字。 因此, 套接字的表示方法是在点分十进制的 IP 地址后面写上端口号, 中间用冒号或逗号隔开。 例如, 若IP地址是192.3.4.5而端口号是 80, 那么得到的套接字就是 ( 192.3.4.5: 80)。 总之, 我们有:套接宇socket = (IP地址: 端口号)
每一条TCP连接唯一地被通信两端的两个端点(即两个套接宇〉所确定。 即:
TCP连接 ::= {socket 1, socket 2} = {( IP1: port1), (IP2: port2)}
这里IP1和 IP2分别是两个端点主机的IP地址, 而po矶和port2分别是两个端点主机中的端口号。TCP连接的两个套接字就是socket 1和socket 2。 可见套接宇socket 是个很抽象的概念。 在下一章的6.8节还要对套接字进行更多的介绍。
总之,TCP 连接就是由协议软件所提供的一种抽象。 虽然有时为了方便, 我们也可以 说, 在一个应用进程和另一个应用进程之间建立了一条TCP连接, 但一定要记住:TCP连 接的端点是个很抽象的套接字, 即(IP地址:端口号)。也还应记住: 同一个IP地址可以有多个不同的TCP连接,而同一个端口号也可以出现在多个不同的TCP连接中。

5.4 可靠传输的工作原理

5.4.1 停止等待协议

我们仅考虑A发送数据而B接收数据并发送确认。 因此A叫做发送方, 而B叫做接收方。 因为这里是讨论可靠传输的原理, 因此把传送的数据单元都称为分组, 而并不考虑数据是在哪一个层次上 传送的。“停止等待” 就是每发送完一个分组就停止发送, 等待对方的确认。 在收到确认后再发送下一个分组。
1. 无差错情况
停止等待协议可用图5-9来说明。 图5-9(a)是最简单的无差错情况。A发送分组M1,发完就暂停发送, 等待B的确认。B收到了M1 就向A发送确认。A在收到了对M1 的确认 后, 就再发送下一个分组M2。 同样, 在收到B对M2的确认后, 再发送M3 。
在这里插入图片描述

2. 出现差错
图5-9(b)是分组在传输过程中出现差错的情况。 B接收M1 时检测出了差错, 就丢弃 M1, 其他什么也不做(不通知A 收到有差错的分组) 。也可能是M1在传输过程中丢失了, 这时B当然什么都不知道。 在这两种情况下, B都不会发送任何信息。 可靠传输协议是这样设计的: A只要超过了一段时间仍然没有收到确认, 就认为刚才发送的分组丢失了,因而重传前面发送过的分组。 这就叫做超时重传。 要实现超时重传, 就要在每发送完一个分组时设置一个超时计时器。 如果在超时计时器到期之前收到了对方的确认, 就撤销己设置的 超时计时器。
这里应注意以下三点。
第一,A在发送完一个分组后,必须暂时保留已发送的分组的副本(在发生超时重传时使用)。只有在收到相应的确认后才能清除暂时保留的分组副本。
第二, 分组和确认分组都必须进行编号。这样才能明确是哪一个发送出去的分组收到 了确认, 而哪一个分组还没有收到确认。
第三, 超时计时器设置的重传时间应当比数据在分组传输的平均往返时间更长一些

3. 确认丢失和确认迟到
图5-10(a)功说明的是另一种情况。 B所发送的对M1的确认丢失了。 A在设定的超时重传时间内没有收到确认, 并无法知道是自己发送的分组出错、 丢失, 或者是B发送的确认丢 失了。 因此A在超时计时器到期后就要重传M1。 现在应注意B的动作。 假定B又收到了 重传的分组M1。 这时应采取两个行动。
第一,丢弃这个重复的分组M1,不像上层交付。
第二, 向A发送确认。 不能认为己经发送过确认就不再发送, 因为A之所以重传M1就表示A没有收到对M1的确认。
在这里插入图片描述
图5-10(b)也是一种可能出现的情况。 传输过程中没有出现差错, 但B对分组 M1的确认迟到了。 A会收到重复的确认。 对重复的确认的处理很简单:收下后就丢弃。B仍然会收到重复的M1, 并且同样要丢弃重复的M1, 并重传确认分组。
通常A最终总是可以收到对所有发出的分组的确认。如果A不断重传分组但总是收不 到确认, 就说明通信线路太差, 不能进行通信。
使用上述的确认和重传机制, 我们就可以在不可靠的传输网络上实现可靠的通信
像上述的这种可靠传输协议常称为自动重传请求ARQ(Automatic Repeat reQuest)。意思 是重传的请求是自动进行的。接收方不需要请求发送方重传某个出错的分组。

4. 信道利用率
停止等待协议的优点是简单, 但缺点是信道利用率太低。
在这里插入图片描述
从图 5-11 还可看出, 当往返时间RTT远大于分组发送时间TD 时, 信道的利用率就会非常低。 还应注意的是, 图 5-11 并没有考虑出现差错后的分组重传。 若出现重传, 则对传送有用的数据信息来说, 信道的利用率就还要降低。
为了提高传输效率, 发送方可以不使用低效率的停止等待协议, 而是采用流水线传输 (如图5-12所示)。流水线传输就是发送方可连续发送多个分组, 不必每发完一个分组就停 顿下来等待对方的确认。 这样可使信道上一直有数据不间断地在传送。 显然, 这种传输方式 可以获得很高的信道利用率。
在这里插入图片描述

当使用流水线传输时, 就要使用下面介绍的连续ARQ协议滑动窗口协议

5.4.2 连续ARQ协议

滑动窗口协议比较复杂, 是TCP协议的精髓所在。 这里先给出连续ARQ协议最基本的概念, 但不涉及许多细节问题。 详细的滑动窗口协议将在后面的5.6节中讨论。
图5-13(a)表示发送方维持的发送窗口, 它的意义是:位于 发送窗口内的5个分组都可连续发送出去, 而不需要等待对方的确认。 这样, 信道利用率就提高了。
在讨论滑动窗口时, 我们应当注意到, 图中还有一个时间坐标(但以后往往省略这样的时间坐标)。 按照习惯, 向前” 是指 “向着时间增大的方向”,而“向后 ” 则是 “向着时间减少的方向”。分组发送是按照分组序号从小到大发送的。
在这里插入图片描述
连续 ARQ 协议规定, 发送方每收到一个确认, 就把发送窗口向前滑动一个分组的位置。 图5-13(b)表示发送方收到了对第1个分组的确认, 于是把发送窗口向前移动一个分组的位置。如果原来己经发送了前5个分组, 那么现在就可以发送窗口内的第6个分组了。
接收方一般都是采用累积确认的方式。 这就是说, 接收方不必对收到的分组逐个发送, 而是在收到几个分组后,对按序到达的最后一个分组发送确认。这就表示:到这个分组为止的所有分组都已正确收到了。
累积确认有优点也有缺点。 优点是: 容易实现, 即使确认丢失也不必重传。 但缺点是不能向发送方反映出接收方已经正确收到的所有分组的信息。
例如, 如果发送方发送了前5个分组, 而中间的第3个分组丢失了。 这时接收方只能对前两个分组发出确认。 发送方无法知道后面三个分组的下落, 而只好把后面的三个分组都再重传一次。这就叫做Go-back-N(回退N), 表示需要再退回来重传已发送过的N个分组。 可见当通信线路质量不好时, 连续ARQ协议会带来负面的影响。
在深入讨论TCP的可靠传输问题之前, 必须先了解TCP的报文段首部的格式。

5.5 TCP报文段的首部格式

TCP虽然是面向字节流的, 但TCP传送的数据单元却是报文段。一 个TCP报文段分为 首部和数据两部分, 而TCP 的全部功能都体现在它首部中各字段的作用。 因此, 只有弄清TCP首部各字段的作用才能掌握TCP的工作原理。 下面讨论TCP报文段的首部格式。
TCP报文段首部的前20个字节是固定的(图5-14),后面有 4n 字节是根据需要而增加的选项(n是整数)。 因此TCP首部的最小长度是20字节。
在这里插入图片描述
首部固定部分各宇段的意义如下:
(1)源端口和目的端口 各占2个字节, 分别写入源端口号和目的端口号。 和前面图5- 6所示的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千兆字节〉的数据进行编号。 在一般情况下 可保证当序号重复使用时, 旧序号的数据早己通过网络到达终点了。
(4)数据偏移 占4位, 它指出TCP报文段的数据起始处距离TCP报文段的结尾处有多远。 这个字段实际上是指出TCP报文段的首部长度。 由于首部中还有长度不确定的选项字段, 因此数据偏移字段是必要的。 但应注意, “数据偏移” 的单位是32位字(即以4字节长的字 为计算单位)。 由于4位二进制数能够表示的最大十进制数字是 15,因此数据偏移 的最大值是60 宇节, 这也是TCP首部的最大长度(即选项长度不能超过40 字节)。
(5)保留 占 6位, 保留为今后使用 , 但目前应置为 0。
下面有 6 个控制位, 用来说明 本报文段的性质, 它们的意义见下面的(6)~(11)。
(6)紧急URG(URGent) 当URG= 1时, 表明紧急指针字段有效。 它告诉系统此报文段中有紧急数据, 应尽快传送(相当于高优先级的数据), 而不要按原来的排队顺序来传送。
当URG置 1 时, 发送应用进程就告诉发送方的TC P有紧急数据要传送。 于是发送方 TCP就把紧急数据插入到本报文段数据的最前面, 而在紧急数据后面的数据仍是普通数据。 这时要与首部中紧急指针(Urgent Pointer)宇段配合使用。
(7)确认ACK(ACKnow led gment) 仅当ACK=1时确认号字段才有效。 当ACK=0时, 确认号无效。TCP规定, 在连接建立后所有传送的报文段都必须把ACK置1。
(8)推送PSH(PuSH) 当两个应用进程进行交互式的通信时, 有时在一端的应用进程希望在键入一个命令后 立即就能够收到对方的响应。 在这种情况下,TCP就可以使用推送 (push)操作。 这时, 发送方 TCP把 PSH置1,并立即创建一个报文段发送出去。 接收方TCP收到 PSH= 1的报文段, 就尽快地(即 “推送 ” 向前)交付接收应用进程, 而不再等到整个缓存都填满了后再向上交付。
虽然应用程序可以选择推送操作, 但推送操作很少使用。
(9)复位RST(ReSeT) 当RST = 1时, 表明 TCP连接中出现严重差错(如由于主机崩溃或其他原因〉, 必须释放连接, 然后再重新建立运输连接。 RST置1 还用来拒绝一个非法的报文段或拒绝打开一个连接。 RST也可称为重建位或重置位。
(1 0)同步SYN(SYNchronization) 在连接建立时用来同步序号。 当SYN= 1而ACK= 0时, 表明这是一个连接请求报文段。 对方若同意建立连接, 则应在响应的报文段中使SYN=l和ACK= 1。 因此, SYN置为1就表示这是一个连接请求或连接接受报文。 关于连接的建立 和释放, 在后面的5.9节还要进行详细讨论。
(11)终止FIN (FINis, 意思是 “完”、“终 ” ) 用来释放一个连接。 当FIN= 1时, 表明此报文段的发送方的数据己发送完毕, 并要求释放运输连接。
(12) 窗口 占2 字节。 窗口值是[0, 216 -1]之间的整数。 窗口指的是发送本报文段的 一方的接收窗口〈而不是自己的发送窗口〉。 窗口值告诉对方: 从本报文段首部中的确认号算起, 接收方目前允许对方发送的数据量(以字节为单位)。 之所以要有这个限制, 是因为接收方的数据缓存空间是有 限的。 总之, 窗口值作为接收方让发送方设置其发送窗口的 依据。
例如, 发送了一个报文段, 其确认号是701,窗口字段是 1000。这就是告诉对方: “ 从701号算起, 我(即 发送此报文段的一方) 的接收缓存空间还可接收 1000 个字节数据〈字 节序号是701~1700), 你在给我发送数据时, 必须考虑到这一点。”
总之, 应当记住:
窗口宇段明确指出了现在允许对方发送的数据量。 窗口值经常在动态变化着。
(13)检验和 占2 宇节。 检验和字段检验的范围包括首部和数据这两部分。 和UDP用户数据报一样, 在计算检验和时, 要在 TCP报文段的前面加上12字节的伪首部。 伪首部 的格式与图 5-5 中UDP用户数据报的伪首部一样。 但应把伪首部第4 个字段中的 17改为6(TCP 的协议号是 6), 把第5字段中的UDP长度改为 TCP长度。 接收方收到此报文段后, 仍要加上这个伪首部来计算检验和。 若使用1Pv6, 则相应的伪首部也要改变。
(14)紧急指针 占2 宇节。 紧急指针仅在URG = 1时才有意义, 它指出本报文段中的紧急数据的字节数(紧急数据结束后就是普通数据〉。 因此, 紧急指针指出了紧急数据的末尾在报文段中的 位置。 当所有紧急数据都处理完时, TCP就告诉应用程序恢复到正常操作。 值得注意的是, 即使窗口 为零时 也可发送紧急数据。
(15)选项 长度可变, 最长可达40字节。 当没有使用 “选项 “ 时, TCP的首部长度是20字节。
TCP选项包括最大报文段长度MSS (Maximum Segment Size)窗口扩大选项时间戳选项有关选择确认(S ACK)选项等,(详细内容请参考书本)

5.6 TCP可靠传输的实现

我们首先介绍以字节为单位的滑动窗口。 为了讲述可靠传输原理的方便, 我们假定数据传输只在一个方向进行, 即A发送数据, B给出确认。 这样的好处是使讨论限于两个窗 口, 即发送方A的发送窗口和接收方B的接收窗口。

5.6.1 以字节为单位的滑动窗口

TCP的滑动窗口是以字节为单位的。为了便于说明滑动窗口的工作原理,我们故意把后面图5-15至图5-18中的字节编号都取得很小。现假定A收到了B发来的确认报文段,其中 窗口是20字节,而确认号是31(这表明B期望收到的下一个序号是31,而序号30为止的数 据已经收到了)。根据这两个数据,A就构造出自己的发送窗口,如图5-15所示。
在这里插入图片描述
我们先讨论发送方A的发送窗口。 发送窗口表示:在没有收到B的确认的情况下,A可以连续把窗口内的数据都发送出去。 凡是己经发送过的数据, 在未收到确认之前都必须暂时保留, 以便在超时重传时使用。
发送窗口里面的序号表示允许发送的序号。显然,窗口越大,发送方就可以在收到对方确认之前连续发送更多的数据,因而可能获得更高的传输效率。在上面的5.5节我们已经讲过,接收方会把自己的接收窗口数值放在窗口字段中发送给对方。因此,A的发送窗口一 定不能超过B的接收窗口数值。在后面的5.8节我们将要讨论,发送方的发送窗口大小还要受到当时网络拥塞程度的制约。但在目前,我们暂不考虑网络拥塞的影响。
发送窗口后沿的后面部分表示己发送且己收到了确认。这些数据显然不需要再保留 了。而发送窗口前沿的前面部分表示不允许发送的,因为接收方都没有为这部分数据保留临时存放的缓存空间。
发送窗口的位置由窗口前沿和后沿的位置共同确定。发送窗口后沿的变化情况有两种可能,即不动(没有收到新的确认)和前移(收到了新的确认)。发送窗口后沿不可能向后移动, 因为不能撤销掉已收到的确认。 发送窗口前沿通常是不断向前移动, 但也有可能不动。 这对应于两种情况: 一是没有收到新的确认, 对方通知的窗口大小也不变: 二是收到了新的确认但对方通知的窗口缩小了, 使得发送窗口前沿正好不动。
发送窗口前沿也有可能向后收缩。 这发生在对方通知的窗口缩小了。 但TCP的标准强烈不赞成这样做。 因为很可能发送方在收到这个通知以前已经发送了窗口中的许多数据, 现 在又要收缩窗口, 不让发送这些数据, 这样就会产生一些错误。
现在假定A发送了序号为31~41的数据。 这时, 发送窗口位置并未改变(图5-16), 但发送窗口内靠后面有 11个字节(灰色小方框表示)表示 已发送但未收到确认。 而发送窗口内靠前面的9个字节(42~50)是允许发送但尚未发送的。
在这里插入图片描述
从以上所述可以看出, 要描述一个发送窗口的状态需要三个指针:Pi, P2 和 P3 (图 5-16)。 指针都指向字节的序号。 这三个指针指向的几个部分的意义如下:
小于P1的是已发送并己收到确认的部分, 而大于P3 的是不允许发送的部分。
P3-P1 =A的发送窗口
P2-P1 =已发送但尚未收到确认的宇节数
P3 -P2 =允许发送但当前尚未发送的字节数(又称为可用窗口有效窗口
再看一下B的接收窗口。B的接收窗口大小是20。 在接收窗口外面, 到30 号为止的数据是已经发送过确认, 并且已经交付主机了。 因此在B 可以不再保留这些数据。 接收窗口内的序号。(31~ 50)是允许接收的。 在图5-16中,B收到了序号为32 和 33 的数据。 这些 数据没有按序到达, 因为序号为 31 的数据没有收到(也许丢失了, 也许滞留在网络中的某处)。 请注意,B只能对按序收到的数据中的最高序号给出确认, 因此B发送的确认报文段中的确认号仍然是31(即期望收到的序号), 而不能是32或33。
现在假定B收到了序号为31的数据, 并把序号为31 ~33的数据交付主机, 然后B删除这些数据。 接着把接收窗口向前移动3个序号(图5-17), 同时给A发送确认, 其中窗口 值仍为20, 但确认号是34。 这表明B己经收到了到序号33为止的数据。 我们注意到,B还收到了序号为37, 38 和 40 的数据, 但这些都没有按序到达, 只能先暂存在接收窗口中。 A收到B的确认后, 就可以把发送窗口向前滑动3个序号, 但指针P2不动。 可以看出, 现在A的可用窗口增大了, 可发送的序号范围是42~53。
在这里插入图片描述
A在继续发送完序号42~53的数据后, 指针P2向前移动和P3重合。 发送窗口内的序号都己用完, 但还没有再收到确认(图5-18)。由于A的发送窗口己满, 可用窗口己减小到零, 因此必须停止发送。 请注意, 存在下面这种可能性, 就是发送窗口内所有的数据都己正确到达B, B也早己发出了确认。 但不幸的是, 所有这些确认都滞留在网络中。 在没有收到 B的确认时, A不能猜测:“ 或许B收到了吧! ” 为了保证可靠传输, A只能认为B还没有收到这些数据。 于是, A在经过一段时间后(由超时计时器控制) 就重传这部分数据, 重新设置超时计时器, 直到收到B的确认为止。 如果A收到确认号落在发送窗口内, 那么A就 可以使发送窗口继续向前滑动, 并发送新的数据。
在这里插入图片描述
我们在前面的图5-8中曾给出了这样的概念:发送方的应用进程把字节流写入TCP的发送缓存, 接收方的应用进程从TCP的接收缓存中读取字节流。 下面我们就进一步讨论前面讲的窗口和缓存的关系。图5-19画出了发送方维持的发送缓存和发送窗口, 以及接收方维持的接收缓存和接收窗口。 这里首先要明确两点:
在这里插入图片描述
第一,缓存空间和序号空间都是有限的, 并且都是循环使用的。 最好是把它们画成圆环状的。 但这里为了画图的方便, 我们还是把它们画成长条状的。
第二, 由于实际上缓存或窗口中的字节数是非常之大的, 因此图 5-19仅仅是个示意图, 没有标出具体的数值。 但用这样的图来说明缓存和发送窗口以及接收窗口的关系是很清楚的。
我们先看一下图5-19(a)所示的发送方的情况。
发送缓存用来暂时存放:
(1) 发送应用程序传送给发送方TCP准备发送的数据:
(2) TCP己发送出但尚未收到确认的数据。
发送窗口通常只是发送缓存的一部分。已被确认的数据应当从发送缓存中删除, 因此发送缓存和发送窗口的后沿是重合的。 发送应用程序最后写入发送缓存的字节减去最后被确认的字节, 就是还保留在发送缓存中的被写入的字节数。 发送应用程序必须控制写入缓存的速率, 不能太快, 否则发送缓存就会没有存放数据的空间。
再看一下图5-19(b)所示的接收方的情况。
接收缓存用来暂时存放:
(1) 按序到达的、 但尚未被接收应用程序读取的数据:
(2)未按序到达的数据。
如果收到的分组被检测出有差错, 则要丢弃。 如果接收应用程序来不及读取收到的数据, 接收缓存最终就会被填满, 使接收窗口减小到零。 反之, 如果接收应用程序能够及时从 接收缓存中读取收到的数据, 接收窗口就可以增大, 但最大不能超过接收缓存的大小。 图5-19(b)中还指出了下一个期望收到的字节号。 这个字节号也就是接收方给发送方的报文段的首部中的确认号。
根据以上所讨论的, 我们还要再强调以下三点。
第一,虽然A的发送窗口是根据B的接收窗口设置的, 但在同一时刻,A的发送窗口并不总是和B的接收窗口一样大。 这是因为通过网络传送窗口值需要经历一定的时间滞后(这个时间还是不确定的)。 另外, 正如后面5.7节将要讲到的, 发送方A还可能根据网络 当时的拥塞情况适当减小自己的发送窗口数值。
第二, 对于不按序到达的数据应如何处理, TCP标准并无明确规定。 如果接收方把不按序到达的数据 律丢弃, 那么接收窗口的管理将会比较简单, 但这样做对网络资源的利用 不利(因为发送方会重复传送较多的数据)。 因此TCP通常对不按序到达的数据是先临时存放在接收窗口中, 等到字节流中所缺少的字节收到后, 再按序交付上层的应用进程
第三, TCP要求接收方必须有累积确认的功能, 这样可以减小传输开销。 接收方可以在合适的时候发送确认, 也可以在自己有数据要发送时把确认信息顺便捎带上。 但请注意两点。一是接收方不应过分推迟发送确认, 否则会导致发送方不必要的重传, 这反而浪费了网络的资源。 TCP标准规定, 确认推迟的时间不应超过0.5秒。 若收到一连串具有最大长度的报文段, 则必须每隔 一个报文段就发送一个确认。二是捎带确认实际上并不经常发生, 因为大多数应用程序很少同时在两个方向上发送数据。
最后再强调一下, TCP的通信是全双工通信。通信中的每一方都在发送和接收报文段。因此,每一方有自己的发送窗口和接收窗口。 在谈到这些窗口时,一定要弄清楚是哪一个方的窗口。

5.6.2 超时重传时间的选择

TCP的发送方在规定的时间内没有收到确认就要重传已发送的报文段。 那么, 运输层的超时计时器的超时重传时间究竟应设置为多大呢?

5.6.3 选择确认SACK

现在还有一个问题没有讨论。 这就是若收到的报文段无差错, 只是未按序号, 中间还缺少一些序号的数据,那么能否设法只传送缺少的数据而不重传己经正确到达接收方的数据?答案是可以的。 选择确认就是一种可行的处理方法。

5.7 TCP的流量控制

5.7.1 利用滑动窗口实现流量控制

一般说来, 我们总是希望数据传输得更快一些。 但如果发送方把数据发送得过快, 接收方就可能来不及接收, 这就会造成数据的丢失。 所谓流量控制(flow control)就是让发送方 的发送速率不要太快,要让接收方来得及接收。
利用滑动窗口机制可以很方便地在TCP连接上实现对发送方的流量控制。下面通过圈子22的例子说明如何利用滑动窗口机制进行流量控制。
在这里插入图片描述设A向B发送数据。 在连接建立时, B告诉了A: “我的接收窗口rwnd= 40。 ”(这里rwnd表示receiver window )。 因此, 发送方的发送窗口不能超过接收方给出的接收窗口的数值。 请注意, TCP的窗口单位是字节, 不是报文段。 TCP连接建立时的窗口协商过程 在图中没有显示出来。 再设每一个报文段为 100 字节长, 而数据报文段序号的初始值设为 1 (见图中第一个箭头上面的序号seq= 1。 图中右边的注释可帮助理解整个过程)。 请注意,图中箭头上面大写ACK表示首部中的确认位ACK, 小写ack表示确认字段的值。
我们应注意到, 接收方的主机B进行了三次流量控制 。 第一次把窗口减小到rwnd= 300, 第二次又减到rwnd= 100, 最后减到rwnd= 0, 即不允许发送方再发送数据了。 这种使发送 方暂停发送的状态将持续到 主机B 重新发出一个新的窗口值为止。 我们还应注意到,B 向A发送的三个报文段都设置了ACK= 1, 只有在ACK=1时确认号字段才有意义。
现在我们考虑一种情况。 在图5-22中,B向A发送了零窗口的报文段后不久,B的接收缓存又有了一些存储空间。 于是B向A发送了rwnd= 400 的报文段。 然而这个报文段在传送过程中丢失了。 A一直等待收到 B发送的非零窗口的通知, 而B也一直等待A发送的 数据。 如果没有其他措施, 这种互相等待的死锁局面将一直延续下去。
为了解决这个问题, TCP为每一个连接设有一个持续计时器(persistence timer)。 只要TCP连接的一 方收到 对方的零窗口通知, 就启动持续计时器。 若持续计时器设置的时间到
期, 就发送一个零窗口探测报文段(仅携带 1字节的数据) ,而对方就在确认这个探测报 文段时给出了现在的窗口值。 如果窗口仍然是零, 那么收到这个报文段的一方就重新设置持续计时器。 如果窗口不是零, 那么死锁的僵局就可以打破了。

5.7.2 TCP的传输效率

详情请参考原文

5.8 TCP的拥塞控制

5.8.1 拥塞控制的一般原理

在计算机网络中的链路容量(即带宽)、 交换结点中的缓存和处理机等, 都是网络的资源。 在某段时间, 若对网络中某一资源的需求超过了该资源所能提供的可用部分, 网络的性能就要变坏。 这种情况就叫做拥塞(congestion)。 可以把出现网络拥塞的条件写成如下的关系式:
在这里插入图片描述
在图 5-23 中的横坐标是提供的负载(offered load),代表单位时间内输入给网络的分组数 目。 因此提供的负载也称为输入负载网络负载。 纵坐标是吞吐量(由oughput),代表单位时间内从网络输出的分组数目。 具有理想拥塞控制的网络, 在吞吐量饱和之前, 网络吞吐量应等于提供的负载, 故吞吐量曲线是45。的斜线。 但当提供的负载超过某一限度时, 由于网络资源受眼, 吞吐量不再增长而保持为水平线, 即吞吐量达到饱和。 这就表明提供的负载中有一部分损失掉了(例如, 输入到网络的某些分组被某个结点丢弃了)。 虽然如此, 在这种理想的拥塞控制作用下, 网络的吞吐量仍然维持在其所能达到的最大值。
在这里插入图片描述但是, 实际网络的情况就很不相同了。 从图5-23可看出, 随着提供的负载的增大, 网络吞吐量的增长速率逐渐减小。 也就是说, 在网络吞吐量还未达到饱和时, 就己经有一部分的输入分组被丢弃了。 当网络的吞吐量明显地小于理想的吞吐量时, 网络就进入了轻度拥塞 的状态。 更值得注意的是, 当提供的负载达到某一数值时, 网络的吞吐量反而随提供的负载 的增大而下降, 这时网络就进入了拥塞状态。 当提供的负载继续增大到某一数值时, 网络的 吞吐量就下降到零, 网络己无法工作,这就是所谓的死锁(deadlock)。

5.8.2 TCP的拥塞控制方法

TCP进行拥塞控制的算法有四种, 即慢开始(slow-start)拥塞避免(congestion avoidance)快重传(fast retransmit)快恢复(fast recovery)
下面就介绍这些算法的原理。 为了集中精力讨论拥塞控制, 我们假定:
(1) 数据 是单方向传送的, 对方只传送确认报文。
(2) 接收方总是有足够大的缓存空间, 因而发送窗口的大小由网络的拥塞程度来决定。

  1. 慢开始和拥塞避免
    下面讨论的拥塞控制也叫做基于窗口的拥塞控制。 为此, 发送方维持一个叫做拥塞窗口 cwnd (congestion window)的状态变量。 拥塞窗口的大小取决于网络的拥塞程度, 并且动态地在变化。 发送方让自己的发送窗口等于拥塞窗口。
    慢开始算法的思路是这样的:当主机开始发送数据 时, 由于并不清楚网络的负荷情况, 所以如果立即把大量数据字节注入到网络, 那么就有可能引起网络发生拥塞。 经验证明, 较好的方法是先探测一下, 即由小到大逐渐增大发送窗口, 也就是说, 由小到大逐渐增 大拥塞窗口数值。
    图5-25用具体例子说明了在拥塞控制的过程中, TCP的拥塞窗口 cwnd是怎样变化的。 图中的的数字1至5是 特别要注意的几个点。现假定TCP的发送窗口等于拥塞窗口。当TCP连接进行初始化时, 把拥塞窗口cwnd置为1。 为了便于理解, 图中的窗口单位不使用字节而使用报文段的个数。 在本例中, 慢开始门限的初始值设置为 16个报文段, 即ssthresh = 16。 在执行慢开始算法时, 发送方每收到一个对新报文段的确认ACK,就把拥塞窗口值加1, 然后开始下一轮的传输(请注意, 图5-25的横坐标是 传输轮次, 不是时间)。因此 拥塞窗口cwnd随着传输轮次按指数规律增长。 当拥塞窗口cwnd增长到慢开始门限值ssthresh时(图中的点。, 此时拥塞窗口cwnd = 16),就改为执行拥塞避免算法, 拥塞窗口按线性规律增长。 但请注意, “ 拥塞避免” 并非完全能够避免了拥塞。 “拥塞避免” 是说把拥塞窗口控制为按线性规律增长, 使网络比较不容易出现拥塞。
    在这里插入图片描述当拥塞窗口cwnd = 24时, 网络出现了超时(图中的点2), 发送方判断为网络拥塞。于是调整门限值ssthresh = cwnd/2 = 12, 同时设置拥塞窗口cwnd =1, 进入慢开始阶段。
    按照慢开始算法, 发送方每收到一个对新报文段的确认 ACK,就把拥塞窗口值加1。当拥塞窗口cwnd = ssthresh = 12时(图中的点3, 这是新的ssthresh 值), 改为执行拥塞避免算法, 拥塞窗口按线性规律增大。
    当拥塞窗口cwnd= 16时(图中的点4), 出现了一个新的情况, 就是发送方一连收到3个对同一个报文段的重复确认(图中记为3 -ACK)。 关于这个问题要解释如下。
    有时, 个别报文段会在网络中丢失, 但实际上网络并未发生拥塞。 如果发送方迟迟收不到确认, 就会产生超时, 就会误认为网络发生了拥塞。 这就导致发送方错误地启动慢开始, 把拥塞窗口cwnd又设置为1, 因而降低了传输效率。
    采用快重传算法可以让发送方尽早知道发生了个别报文段的丢失。 快重传算法首先要求接收方不要等待自己发送数据时才进行捎带确认, 而是要立即发送确认, 即使收到了失序 的报文段也要立即发出对己收到的报文段的重复确认。 如图5-2 6所示, 接收方收到了M1和 M2 后部分别及时发出了确认。 现假定接收方没有收到M3 但却收到了M4。 本来接收方可以什么都不做。 但按照快重传算法, 接收方必须立即发送对M2 的重复确认, 以便让发送方及 早知道接收方没有收到报文段M3。发送方接着发送M5和M6。 接收方收到后也仍要再次分别发出对M2 的重复确认。 这样, 发送方共收到了接收方的4个对M2 的确认, 其中后3个 都是重复确认。 快重传算法规定, 发送方只要一连收到3个重复确认, 就知道接收方确实没有收到报文段M3,因而应当立即进行重传(即 “ 快重传”), 这样就不会出现超时, 发送方也不就会误认为出现了网络拥塞。 使用快重传可以使整个网络的吞吐量提高约20%。
    在这里插入图片描述因此,在图5-25 中的点4, 发送方知道现在只是丢失了个别的报文段。 于是不启动慢 开始, 而是执行快恢复算法。 这时, 发送方调整门限值ssthresh = cwnd/2 = 8, 同时设置拥塞窗口cwnd= ssthresh = 8(见图5-25中的点5), 并开始执行拥塞避免算法。
    采用这样的拥塞控制方法使得TCP的性能有明显的改进。
    根据以上所述, TCP的拥塞控制可以归纳为图5-27的流程图。这个流程图就比图5-25所示的特例要更加全面些。 例如, 图5-25没有说明在慢开始阶段如果出现了超时(即出现了网络拥塞〉或出现3-ACK, 发送方应采取什么措施。 但从图5-27的流程图就可以很明确地知道发送方应采取的措施。
    在这里插入图片描述

5.8.3 主动队列管理AQM

5.9 TCP的运输连接管理

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值