计算机网络复习（五）

考点：

UDP

拥塞控制

TCP 三次握手四次握手 P247

熟知端口号 P215

TCP 报文计算

5-36.假定TCP采用一种仅使用线性增大和乘法减小的简单拥塞控制算法，而不使用慢开始。发送窗口不采用字节为计算单位，而是使用分组pkt为计算单位。在一开始发送窗口为1pkt。假定分组的发送时延非常小，可以忽略不计。所有产生的时延就是传播时延。假定发送窗口总是小于接收窗口。接收端每收到一分组后，就立即发回确认ACK。假定分组的编号为i，在一开始发送的是i=1的分组。以后当i=9，25，30，38，50时，发生了分组的丢失。再假定分组的超时重传时间正好是下一个RTT开始的时间。试画出拥塞窗口（也就是发送窗口）与RTT的关系曲线，画到发送第51个分组为止。
答：开始时拥塞窗口（发送窗口)为1 pkt，发送编号为1的分组。
        当RTT=1时(即第1个RTT结束时),收到确认，拥塞窗口增大到2 pkt,发送2个分组，其编号为2和3。
        当RTT=2时(即第2个RTT结束时),收到确认,拥塞窗口增大到3 pkt,发送3个分组，其编号为4~～6。
        当RTT=3时(即第3个RTT结束时),收到确认,拥塞窗口增大到4 pkt,发送4个分组，其编号为7~10。
        但在RTT=4时(即第4个RTT结束时),发送端发现编号为9的分组丢失了,没有收到相应的确认。

于是这时把拥塞窗口减半，从前面的4减到2。请注意，拥塞窗口的值仅在RTT为整数值时才有意义。因为只有在这些时刻，确定了发送端能够发送几个分组。分组一旦发送出去，发送窗口就不再起作用。只有到了下一个RTT 结束时，发送窗口才再次起作用。
后面的分组发送，在图中表示，就不再作过多的解释了。但最后，在RTT=18时，由于编号为50的分组丢失，拥塞窗口应减半，从5 pkt减小到2.5 pkt。但分组组不能只发送半个，因此实际上拥塞窗口就是2。如果在图中把拥塞窗口设定为2.5 pkt，那么在发送时也只能发送2个分组。因此在RTT -18时，发送的分组编号是50和51。

5-37.在 TCP 的拥塞控制中，什么是慢开始、拥塞避免、快重传和快恢复算法?这里每一种算法各起什么作用? “乘法减小”和“加法增大”各用在什么情况下?
答：
① 慢开始：
在主机刚刚开始发送报文段时可先将拥塞窗口 cwnd 设置为一个最大报文段 MSS 的数值。在每收到一个对新的报文段的确认后，将拥塞窗口增加至多一个 MSS 的数值。用这样的方法逐步增大发送端的拥塞窗口 cwnd，可以分组注入到网络的速率更加合理。
② 拥塞避免：
当拥塞窗口值大于慢开始门限时，停止使用慢开始算法而改用拥塞避免算法。拥塞避免算法使发送的拥塞窗口每经过一个往返时延 RTT 就增加一个 MSS 的大小。
③ 快重传算法规定：
发送端只要一连收到三个重复的 ACK 即可断定有分组丢失了，就应该立即重传丢手的报文段而不必继续等待为该报文段设置的重传计时器的超时。
④ 快恢复算法：
当发送端收到连续三个重复的 ACK 时，就重新设置慢开始门限 ssthresh 与慢开始不同之处是拥塞窗口 cwnd 不是设置为 1，而是设置为 ssthresh 若收到的重复的 ACK 为 n 个（n>3），则将 cwnd 设置为 ssthresh 若发送窗口值还容许发送报文段，就按拥塞避免算法继续发送报文段。若收到了确认新的报文段的 ACK，就将 cwnd 缩小到 ssthresh。
⑤ 乘法减小：
是指不论在慢开始阶段还是拥塞避免阶段，只要出现一次超时（即出现一次网络拥塞），就把慢开始门限值 ssthresh 设置为当前的拥塞窗口值乘以 0.5。当网络频繁出现拥塞时，ssthresh 值就下降得很快，以大大减少注入到网络中的分组数。
⑥ 加法增大：
是指执行拥塞避免算法后，在收到对所有报文段的确认后（即经过一个往返时间），就把拥塞窗口 cwnd 增加一个 MSS 大小，使拥塞窗口缓慢增大，以防止网络过早出现拥塞。

5-38.设 TCP 的 ssthresh 的初始值为 8 (单位为报文段)。当拥塞窗口上升到 12 时网络发生了超时，TCP 使用慢开始和拥塞避免。试分别求出第 1 次到第 15 次传输的各拥塞窗口大小。你能说明拥塞控制窗口每一次变化的原因吗？

拥塞窗口大小及变化原因见下表：

轮次   拥塞窗口   拥塞窗口变化的原因
1            1            网络发生了超时，TCP 使用慢开始算法
2            2            拥塞窗口值加倍
3            4            拥塞窗口值加倍
4            8            拥塞窗口值加倍，这是 ssthresh 的初始值
5            9            TCP 使用拥塞避免算法，拥塞窗口值加 1
6            10 TCP 使用拥塞避免算法，拥塞窗口值加 1
7            11 TCP 使用拥塞避免算法，拥塞窗口值加 1
8            12   TCP 使用拥塞避免算法，拥塞窗口值加 1
9            1         网络发生了超时，TCP 使用慢开始算法
10          2            拥塞窗口值加倍
11          4            拥塞窗口值加倍
12          6            拥塞窗口值加倍，但到达 12 的一半时，改为拥塞避免算法
13 7            TCP 使用拥塞避免算法，拥塞窗口值加 1
14          8            TCP 使用拥塞避免算法，拥塞窗口值加 1
15          9            TCP 使用拥塞避免算法，拥塞窗口值加 1

注：依照原理，首先执行 TCP 连接初始化，将拥塞窗口 cwnd 值置为 1；其次执行慢开始算法，cwnd 按指数规律增长，因此随后窗口大小分别为 2，4，8。当拥塞窗口 cwnd = ssthresh 时，进入拥塞避免阶段，其窗口大小依次是 9，10，11，12，直到上升到 12 为止发生拥塞；然后把门限值 ssthresh 设置为当前的拥塞窗口值乘以 0.5，门限值 ssthresh 变为6,；然后进入慢开始，cwnd 值置为1，cwnd 按指数规律增长，随后窗口大小分别为 1，2，4，6。当拥塞窗口 cwnd = ssthresh 时，进入拥塞避免阶段，其窗口大小依次是 7，8，9。

5-39.TCP 的拥塞窗口 cwnd 大小与传输轮次 n 的关系如表所示：
1）试画出如教材中图 5-25 所示的拥塞窗口与传输轮次的关系曲线。
（2）指明 TCP 工作在慢开始阶段的时间间隔。
（3）指明 TCP 工作在拥塞避免阶段的时间间隔。
（4）在第 16 轮次和第 22 轮次之后发送方是通过收到三个重复的确认还是通过超时检测到丢失了报文段？
（5）在第 1 轮次，第 18 轮次和第 24 轮次发送时，门限 ssthresh 分别被设置为多大？
（6）在第几轮次发送出第 70 个报文段？
（7）假定在第 26 轮次之后收到了三个重复的确认，因而检测出了报文段的丢失，那么拥塞窗口 cwnd 和门限 ssthresh 应设置为多大？
答：(1)

（2）慢开始时间间隔：[1, 6] 和 [23, 26]
（3）拥塞避免时间间隔：[6, 16] 和 [17, 22]
（4）在第 16 轮次之后发送方通过收到三个重复的确认，检测到丢失了报文段，因为题目给出，下一个轮次的拥塞窗口减半了。在第 22 轮次之后发送方通过超时，检测到丢失了报文段，因为题目给出，下一个轮次的拥塞窗口下降到 1了。
（5）在第 1 轮次发送时，门限 ssthresh 被设置为 32，因为从第 6 轮次起就进入了拥塞避免状态，拥塞窗口每个轮次加 1。
在第 18 轮次发送时，门限 ssthresh 被设置为发生拥塞时拥塞窗口 42 的一半，即 21。
在第 24 轮次发送时，门限 ssthresh 被设置为发生拥塞时拥塞窗口 26 的一半，即 13。
（6）第 1 轮次发送报文段 1。（cwnd = 1）
第 2 轮次发送报文段 2， 3。（cwnd = 2）
第 3 轮次发送报文段 4 ~ 7。（cwnd = 4）
第 4 轮次发送报文段 8 ~ 15。（cwnd = 8）
第 5 轮次发送报文段 16 ~ 31。（cwnd = 16）
第 6 轮次发送报文段 32 ~ 63。（cwnd = 32）
第 7 轮次发送报文段 64 ~ 96。（cwnd = 33）
因此第 70 报文段在第 7 轮次发送出。
（7）检测出了报文段的丢失时拥塞窗口 cwnd 是 8，因此拥塞窗口 cwnd 的数值应当减半，等于 4，而门限 ssthresh 应设置为检测出报文段丢失时的拥塞窗口 8 的一半，即 4。
40.TCP 在进行流量控制时是以分组的丢失作为产生拥塞的标志。有没有不是因拥塞而引起的分组丢失的情况?如有，请举出三种情况。
答：不是因为拥塞而引起分组丢失的情况是有的，举例如下：
① 当 IP 数据报在传输过程中需要分片，但其中一个数据报片未能及时到达终点，而终点组装 IP 数据报已超时，因而只能丢弃该数据报。
② IP 数据报已经到达终点，但终点的缓存没有足够的空间存放此数据报。
③ 数据报在转发过程中经过一个局域网的网桥，但网桥在转发该数据报的帧时没有足够的储存空间而只好丢弃。

5-49.下面是以十六进制格式存储的一个 UDP 首部：
CB84000D001C001C
试问:
(1) 源端口号是什么？
(2) 目的端口号是什么？
(3) 这个用户数据报的总长度是什么？
(4) 数据长度是多少？
(5)这个分组是从客户到服务器还是从服务器到客户？
(6) 客户进程是什么？
答：(1)源端口号是最前面的四位十六进制数(CB84)16=(52100)10
(2)目的端口号是五到八位的十六进制数(000D)16=(13)10
(3)用户数据报的长度由九到十二位十六进制数决定(001C)16=(28)10字节。
(4)数据长度=数据报长度-首部长度=28字节-8字节=20字节。
(5)因为目的端口是 13 （熟知端口），所以这个分组是从客户到目的端口。
(6)从 RFC 867 可以得知，这个客户进程是 Daytime。当 Daytime 服务器收到客户发送的 UDP 用户数据报后，就把现在的日期和时间以 ASCII 码字符串的形式返回给客户。

5-52.UDP 和 IP 的不可靠程度是否相同? 请加以解释。
答：① UDP 和 IP 都是无连接的协议和不可靠传输的协议。UDP 用户数据报和 IP 数据报的首部都有检验和字段。当检验出现差错时，就把收到的 UDP 用户数据报或 IP 数据报丢弃。这是它们的相同之处。
② 但 UDP 和 IP 的可靠性是有些区别的。UDP 用户数据报的检验和是既检验 UDP 用户数据报的首部又检验整个的 UDP 用户数据报的数据部分，而 IP 数据报的检验和仅仅检验 IP 数据报的首部。UDP 用户数据报的检验和还增加了伪首部，即还检验了下面的 IP 数据报的源 IP 地址和目的 IP 地址。

5-62.TCP 连接处于 ESTABLISHED 状态。以下的事件相继发生：
（1）收到一个 FIN 报文段。
（2）应用程序发送 “关闭” 报文。
在每一个事件之后，连接的状态是什么？在每一个事件之后发生的动作是什么？
答：（1）处于 ESTABLISHED 状态又能够收到一个 FIN 报文段，只有 TCP 的服务器端而不会是客户端。当这个服务器端收到 FIN 时，服务器就向客户端发送 ACK 报文段，并进入到 CLOSE-WAIT 状态。这是被动关闭。请注意，这时客户端不会再发送数据了，但服务器端如还有数据要发送给客户端，那么还是可以继续发送的。
（2）应用程序发送 “关闭” 报文给服务器，表明没有数据要发送了。这时服务器就应当发送 FIN 报文段给客户，然后转换到 LAST-ACK 状态，并等待来自客户端的最后的确认。

5-66.主机 A 通过 TCP 连接向 B 发送一个很长的文件，因此这需要分成很多个报文段来发送。假定某一个 TCP 报文段的序号是 x，那么下一个报文段的序号是否就是 x + 1 呢？
答：假定某一个 TCP 报文段的序号是 x，那么下一个报文段的序号应当是 x+n，这里的 n 是这个报文段中的数据长度的字节数。如 n = 4000，那么下一个报文段的序号应当是 x + 4000。若此报文段中仅有一个字节的数据，则下一个报文段的序号才是 x + 1。