计算机网络课后作业

课后作业2

1.一个UDP报文的数据部分有8102个字节，使用以太网传输，假

定IP数据报无选项字段，试问要划分为多少个IP数据报？每个IP 数据报数据字段长度为多少？（共4分）以太网默认的MTU=1500,所以携带的数据1500-20=1480字节

需加上UDP的8个字节首部（8102+8）/1480=5.48，因此需要分成6数据报片。每个IP数据报数据字段长度如下表所示：

2.一个TCP首部数据为：0x 0D 28 00 15 50 5F A9 06 00 00 00 00

70 02 40 00 C0 29 00 00(注：共20个字节，0x代表数据为16

进制)，分析数据，试求：这两个字节,总共16bit，

a）源端口和目的端口（2分）

源端口是3368目的端口是21

b）序列号和确认号（16进制）（2分）

序号50 5F A9 06

确认号00 00 00 00

c）应用层的协议类型（2分）

文件传输协议(File Transfer Protocol）：向FTP站点发送连接请求

d)指出该报文段是处于TCP会话的哪个阶段（建立连接/数据传输/释放连接），并说明理由。（2分）（共8分）建立连接：三次握手（ThreeWay-Handshake）的第一步

TCP数据为：SEQ=50 5f a9 06，ACKNUM=00 00 00 00，SYN=1，ACK=0。

SYN：（Synchronize sequence numbers）用来建立连接，在连接请求中，SYN=1，ACK=0，连接响应时，SYN=1，ACK=1。即，SYN和ACK来区分Connection Request和Connection Accepted。

“70 02”，转换为二进制“0111 0000 0000 0010”

第一个4bit“0111”，是TCP头长，十进制为7，表示28个字节

接着的6bit现在TCP协议没有用上，都为0

3.什么是TCP拥塞控制？（2分）请列举三种拥塞控制算法，并简

述其中一种的工作原理。（注意标明参考文献出处）（6分）

（共8分）网络拥塞控制方法-------《深入理解计算机网络》王达著

TCP拥塞控制简介

顾名思义，拥塞控制（congestion control）就是要控制“网络拥塞”的出现。什么情况下会出现网络拥塞呢？简单地说，网络中各个部分输入的流量大于输出的流量时就会出现网络拥塞。打一个比较类似的比喻（之所以说是“类似”，因为它更像“流量控制”类的比喻），就像在公路上发生塞车的一个根本原因就是出口道路太窄，而入口道路又比较宽，导致同一时间驶入的车辆数大于驶出的车辆数，最终使得这条路上排队并挤满

了各种车辆，车辆的行驶速度自然会降下来。最坏的情况是什么，那就是完全“堵死”，车辆根本出不去，也进不来。这就类似网络中通常所说的“死锁”现象。

当然，道路上发生塞车的原因不仅只有上面所说的那一个，还有像上游驶入的车辆太多、中间或下游正在进行车辆检查、中间某些车辆行驶速度太慢，或者发生了交通事故而占用了部分道路等。就像道路发生塞车的原因有多种一样，网络上发生拥塞的原因也可能是多方面的，而且网络结构越复杂，发生拥塞的原因也可能越复杂。如TCP连接的整个链路中有结点设备的缓存空间太小、数据转发能力太低、某段链路带宽太小、对端数据接收能力低等，都可能引起网络拥塞。而且往往是多个因素同时存在的，因此，处理拥塞控制问题不能简单地针对某一方面来加以解决，必须从全局角度来寻找解决方案，否则可能不仅不能解决拥塞现象，反而会形成新的瓶颈，使网络更加拥塞。

例如，用户想单方面地提高中间路由器结点的数据转发能力，而忽视了所经路径上各段链路的带宽，结果是虽然提高了路由器转发性能，也提高了数据转发速度，但也同时造成了在链路上排队前行的数据不断增多，这样不仅没有解决网络拥塞问题，反而使网络拥塞得更严重。再如，用户想单方面地提高路由器的缓存能力，但没有同步考虑路由器的数据转发能力和链路的带宽，结果是虽然可以使更多的数据在路由器上暂时缓存，但在缓存中排队的数据所需等待的时间会更长，因为队列比以前更长了，结果会因为超时重传这些数据。重传数据越多，网络负荷超越重，最终导致拥塞更加严重。就像我们在车站买票，如果售票员的售票速度没有提高，仅增加了用于排除等候的空间，就会让队列排得更长，这样是不能解决长时间排队买票难题的，反而使排在后面的人买到票的时间更长，同时使得售票厅更加拥挤。

如果把整个网络有效处理负荷的能力称为“吞吐量”（throughout），而把网络中发送端输入的负荷称为“输入负荷”（input load），则理想情况下它们之间有如图10-46所示的线性关系（吞吐量是呈45°斜线上升的）。

在开始时，网络系统的吞吐量随着输入负荷的增加呈同步提高态势（两者的提高量是一样的），但当到了一定时期（在输入负荷达到了网络的最大吞吐量时），输入负载再怎么增加，网络系统的吞吐量也不再提高了，而是保持在一个不变的水平。这时就出现了轻度拥塞现象。就像一条河流最初是没有水的，当上游河流放水时，它的水速会随着上游流入水的水速提高而提高，但当这条河流满了以后，也就是到了它的最大负荷水平时，它的水速不会再有提高了，尽管上游流入的水速仍在提高。从上游新增的那部分水哪里去了呢？肯定是溢出了，就像网络达到最大吞吐量时，从发送端发来的超出吞吐量那部分的数据会被丢弃一样。

TCP拥塞控制方案

虽然已经了解了发生拥塞的原因，也知道了网络系统吞吐量与输入负荷之间的关系，但要真正设计一套有效的拥塞控制方案却不是一件容易的事，因为拥塞的出现和所引起的因素都是动态的，是在不断发生变化的。发生网络拥塞的一个最明显的征兆就是出现了数据的丢失。于是，为了防止网络出现拥塞现象，出现了一系列的TCP拥塞控制机制。最初是由V. Jacobson在1988年的论文中提出的TCP的拥塞控制，由“慢启动”（slow start）和“拥塞避免”（congestion avoidance）组成，后来在TCP Reno版本中又针对性地加入了“快速重传”（fast retransmit）、“快速恢复”（fast recovery）算法。为了方便介绍，现假设数据是单方面发送的，另一个方向只传送确认数据段，而且假设接收端的窗口足够大，发送端的窗口大小由网络拥塞程度决定。

1. 慢启动

慢启动是指为了避免出现网络拥塞而采取的一种TCP拥塞初期预防方案。其基本思想就是在TCP连接正式传输数据时，每次可发送的数据大小（这就是“拥塞窗口”的含义）是逐渐增大的，也就是先发送一些小字节数的试探性数据，在收到这些数据段的确认后，再慢慢增加发送的数据量，直到达到了某个原先设定的极限值（也就是下面将要提到的“慢启动阈值”（SSTHRESH））为止。

在“慢启动”拥塞解决方案中，发送端除了要维护正常情况下根据接收端发来的“窗口大小”字段值而调整的“发送窗口”外，还要维护一个“拥塞窗口”（Congestion Window，CWND），它是为了避免发生拥塞而设置的窗口，最终允许发送的字节数是这两个窗口中的最小值。如果从接收端返回的“窗口大小”字段值是100，而当时设置的“拥塞窗口”大小为50，此时只能发送50字节的数据。相反，如果从接收端返回的“窗口大小”字段值是100，而当时设置的“拥塞窗口”大小为200，则此时只能发送100字节的数据。下面仅假设“拥塞窗口”总是小于从接收端返回的“窗口大小”字段值（也就是“发送窗口”大小）。具体步骤如下：

1）在一个TCP传输连接建立时，发送端将“拥塞窗口”初始化为该连接上当前使用的最大数据段大小（Maximum Segment Size，MSS），即CWND=MSS。然后它发送一个大小为MSS的数据段。

2）如果在定时器过期前发送端收到了该数据段的确认，则发送端将“拥塞窗口”大小再增加一个MSS，也就是此时CWND大小为2MSS。然后发送2MSS大小的数据。

3）如果这次发送的2MSS数据段也都被确认了，则“拥塞窗口”大小再增加两个MSS （此时相当于达到了4MSS），依此类推。

图10-48是一个采用“慢启动”方案的示例，其中M代表MSS，表示“最大数据段大小”。第一次发送一个MSS（即M1），收到M1的确认后，再连续发送两个MSS（即M2和M3），当收到M3的确认（因为后面的已经确认的话，预示前面的都已正确接收，下同）后再发送四个MSS（即M4～M7），当收到M7的确认时，后面将发送8个MSS（即M8～M15）……

图10-48 “慢启动”解决方案TCP数据发送示例

“慢启动”方案的基本规律：当“拥塞窗口”大小达到了n个MSS时，如果所有n个数据段都被及时确认，则新的“拥塞窗口”大小再增加n个MSS，也就是新的“拥塞窗口”大小是旧的“拥塞窗口”大小的2倍关系，即“拥塞窗口”大小与最大数据段大小（MSS）的关系是2的指数关系，即1MSS、2MSS、4MSS、8MSS、16MSS、32MSS……但是“拥塞窗口”不可能无限制地继续增大，即使CWND值仍小于从接收端返回的“窗口大小”字段值，都有可能在某个时刻出现数据丢失的现象。这个“拥塞窗口”大小是一个临界点，于是引入了“慢启动”方案的另一个重要参数—“慢启动阈值”（Slow Start Threshold，SSTHRESH），其初始值为64KB，即65535字节。当发生一次数据丢失时，SSTHRESH设为当前CWND的一半，而CWND又重新置为1MSS。然后继续使用“慢启动”方案来解决网络拥塞问题，不过当CWND再次增长到SSTHRESH（此时仅为原来CWND 的一半）时便停止使用“慢启动”方案，需采用下面将要介绍的“拥塞避免”解决方案。

2. 拥塞避免

当CWND再次大于或等于SSTHRESH时，启动“拥塞避免”解决方案。它的基本思想是在CWND值第二次达到SSTHRESH时，让“拥塞窗口”大小每经过一个RTT（一个数据段往返接收端和发送端所需的时间）时间仅值加1（即新的CWND只增加一个MSS大小，而不是原来CWND的几倍），使其以线性方式慢慢地增大，而不是继续像“慢启动”方案中那样以指数方式快速增大。显然，这种CWND增长速度明显要慢于“慢启动”方案中的CWND增长速度。当再次发生数据丢失时，又会把SSTHRESH减为当前CWND的一半，同时把CWND置为1，重新进入“慢启动”数据发送过程，依此类推。

图10-49是一个“慢启动”和“拥塞避免”两种拥塞控制方案的控制示例。假设最初在某个时间的“拥塞窗口”大小（CWND）为64KB，而就在此后发生了数据丢失，没有收到后面发送的数据的确认，于是（SSTHRESH）减为CWND的一半，即32KB（即图10-49中的“第一次调整的阈值”），同时把新的CWND设为1MSS，从坐标原点开始重新采用“慢启动”方案进行数据发送，当达到了SSTHRESH值（即32KB）时，采用“拥塞避免”方案进行数据发送，每个RTT时间CWND只增加一个MSS。但在第11次传输过程中（此时CWND=38KB）又发生了一次数据丢失，于是SSTHRESH再次降为当前CWND （即38KB）的一半（即19KB），并且重新开始采用“慢启动”方案发送数据，直到达到新的SSTHRESH值（19KB），然后从这点开始又采用“拥塞避免”方案发送数据，以此类推。

3. 快速重传/快速恢复

上面介绍的“慢启动”和“拥塞避免”是1988年提出的拥塞控制方案，而1990年又新增了两种拥塞控制方案，就是下面要介绍的“快速重传”和“快速恢复”拥塞控制方案。“快速重传”方案的基本思想：当接收端收到一个不是按序到达的数据段时，TCP实体迅速发送一个重复ACK数据段，而不用等到有数据需要发送时顺带发出确认；在重复收到三个重复ACK数据段后，即认为对应“确认号”字段的数据段已经丢失，TCP不等重传定时器超时就重传看来已经丢失的数据段。

为了进一步理解“快速重传”原理，现举一个如图10-50所示的示例。假设每次只发送一个大小等于MSS的数据段，并假设在第一次、第二次发送M1、M2后，发送端都从接收端收到了确认，但第三次发送的M3在途中丢失了，而后面第四次发送的M4又收到了。正常情况，接收端是不会再发送任何确认数据段的，直到收到M3为止。然而，发送端此时并不知道M3丢失了，继续发送M4，在接收端收到M4时，为了尽快通知发送端M3还没有收到，于是再次发送一个M2确认数据段（其中的“确认号”字段值是M3的序号），相当于再次提醒发送端M3数据段没收到。但此时发送端还不会重发M3，希望再等等看，仍然继续依次发送M5、M6，在接收端每收到一个数据段后均会有一个重复的M2确认。在发送端收到了四个针对M2数据段的确认（一个确认M2，三个重复确认M2）时，发送端就会立即发送M3，尽管此时可能M3的重传定时器还没过期。在“快速重传”算法发送了看似已经丢失的数据段后，“快速恢复”算法同时开始发挥作用。“快速恢复”算法的基本思想：在收到第三个重复ACK时，把当前CWND 值设为当前SSTHRESH值的一半，以减轻网络负荷，然后执行前面介绍的“拥塞避免”算法，使CWND值慢慢增大，以避免再次出现网络拥塞。