计算机网络自顶向下方法 第三章 作业习题答案

https://github.com/jzplp/Computer-Network-A-Top-Down-Approach-Answer

• P1
  设主机A的telnet会话端口号为x，主机B的telnet会话端口号为y
  a. 源端口号：x，目的端口号：23
  b. 源端口号：y，目的端口号：23
  c. 源端口号：23，目的端口号：x
  d. 源端口号：23，目的端口号：y
  e. 可能相同
  f. 不可能相同

• P2
  服务器到客户A:
  源端口号:80, 目的端口号:26145, 源IP:B, 目的IP:A
  服务器到客户C，会话1:
  源端口号:80, 目的端口号:7532, 源IP:B, 目的IP:C
  服务器到客户C，会话2:
  源端口号:80, 目的端口号:26145, 源IP:B, 目的IP:C

• P3
  01010011+01100110=10111001
  10111001+01110100=00101110
  反码为 11010001
  使用反码对接收方非常方便，只需将所有数据包含校验码加起来，计算和为全1即可。
  如果不是全1则说明出现了差错。
  1比特的差错肯定可以检查出，2比特的差错存在检测不出的情况。

• P4
  a. 00111110
  b. 10111111
  c. 两个字节的最后一位变化: 01011101 01100100

• P5
  接收方不能完全确认没有比特差错，如P4c题目所示，出现多个差错时存在检测不出的情况

• P6
  发送方发送序号0的报文，进入等待ACK0状态。接收方收到，并且回复ACK，进入等待状态1。 回复的ACK受损了。此时发送方重传报文0，接收方收到报文0，认为序号不对，回复NAK。 发送方收到NAK，发送方重传报文0，接收方依然认为序号不对，回复NAK。
  产生死锁。

• P7
  因为ACK和确认序号已经可以完整的标识这个分组，而且ACK的缺失会导致重传，因此最终ACK可以确保到达。

• P8
  与rdt2.2的接收方相同

• P9
  数据分组发生篡改时：
  正在上传…重新上传取消
  确认分组发生篡改时：
  正在上传…重新上传取消

• P10
  如果不使用NAK，则协议正如rdt3.0所示。
  如果使用NAK，则协议如下：
  正在上传…重新上传取消
  接收方与rdt2.1接收方相同

• P11

1. 在等待来自下层的1中删除
   会正常工作。因为上一步状态转换时已经生成了sndpkt
2. 在等待来自下层的0中删除
   在第一次进入时，会工作不正常。此时sndpkt还没有生成，如果接收了一个校验错误的报文，那么无法返回一个分组。

• P12
  如果定时器正常，那么协议可以正常运行。
  如果定时器过早超时：

1. 发送1报文。
2. 首先超时，重传1次。
3. 收到ACK报文，发送2报文。
4. 收到上一个ACK报文，重传1次。
5. 超时，重传2次。
6. 收到ACK报文，发送3报文。
7. 收到上一个ACK报文，重传1次。
8. 收到上一个ACK报文，重传2次。
9. 超时，重传3次。
10. 收到ACK报文，发送4报文。
    ....
    对于第n个分组，重传n次。

• P13
  无法工作的一个例子： 正在上传…重新上传取消
  中间两个报文没有被接收方正确接收就继续发送下面的报文了。

• P14

1. 不合适。因为发送端如果接收不到数据，无法判定是丢包还是正确接收了。
2. 不存在丢包的情况下，采用停等协议不适合使用只用NAK的协议。因为发送方必须等待最长的RTT时间，才能确认接收方已经收到。因此相比于ACK协议，时间的花费会更长。
   不存在丢包的情况下，如果采用流水线协议，那么发送方发送的报文如果损坏，接收方无法判断其序号，无法发送NAK报文，发送方会认为这个报文已经正确接收。因此发生错误。
   如果存在少量丢包的情况下，那么只用NAK的协议就更不如使用ACK的协议了

• P15
  L/R = 15 * 8000 / 109 = 0.012
  U = X(L/R) / (RTT + L/R) = 0.9
  X ~= 2251

• P16
  可以增加信道利用率，因为发送方接收到大量的ACK，便认为发送的报文已经被正确接收了，然后继续发送后续报文。
  问题：如果发生丢包，损坏等现象，那么接收到的数据是不完整的。

• P17
  正在上传…重新上传取消
  正在上传…重新上传取消

• P18
  报文格式:与SR协议相同
  正在上传…重新上传取消
  正在上传…重新上传取消
  正在上传…重新上传取消

• P19
  报文格式与rdt3.0相比，增加了一个指示ACK报文的来源字段，值为B或C
  正在上传…重新上传取消
  正在上传…重新上传取消

• P20
  报文格式与rdt3.0相比，增加了一个指示数据报文的来源字段，值为A或B
  正在上传…重新上传取消
  正在上传…重新上传取消

• P21
  转存失败重新上传取消
  转存失败重新上传取消

• P22
  a.
  k-4, k-3, k-2, k-1, k, k+1, k+2, k+3
  k-4, k-3, k-2, k-1的极端情况：
  此时发送端发送了k-4, k-3, k-2, k-1的报文，接收方收到，但是ACK报文接收方还没有收到。 k, k+1, k+2, k+3的极端情况：
  发送方发送了k, k+1, k+2, k+3报文，接收方还没有收到。
  b.
  k-5, k-4, k-3, k-2, k-1
  k-4, k-3, k-2, k-1, k的极端情况：
  发送方发送k-5，接收方收到并且返回ACK(k-5)。发送方收到之前就超时，重发k-5。 发送方收到ACK(k-5)， 发送k-4, k-3, k-2, k-1。
  接收方收到重发k-5，返回ACK(k-5)。收到k-4, k-3, k-2, k-1，返回ACK(k-4)，ACK(k-3)，ACK(k-2)，ACK(k-1)

• P23
  如果报文在信道中不会重新排序：
  对于GBN协议，发送方窗口最大为k-1。
  如果窗口为k，就会出现书中图3-27的情况，如果窗口的所有报文的ACK丢失，都被重传，接收方会认为是新报文。
  对于SR协议，发送方窗口最大为k/2。
  如果大于k-2。就会出现书中图3-27的情况，如果窗口的所有报文的ACK丢失，都被重传。接收方会认为是新报文。

• P24
  a. 正确
  假设窗口为0,1，发送方发送0，1后，接收方回复ACK0,1。但是发送方收到ACK0和1之前，就进行了超时重传，发送0，1。
  发送方收到ACK0和1。窗口变为2，3。接收方收到重传的0，1，重新回复ACK0,1。此时发送方收到了ACK0，1，在发送方窗口之外。
  b. 正确
  假设窗口为0,1，发送方发送0，1后，接收方回复ACK0,1。但是发送方收到ACK1之前，就进行了超时重传，发送1。
  发送方收到ACK1。窗口变为2，3。接收方收到重传的1，重新回复ACK1。此时发送方收到了ACK1，在发送方窗口之外。
  c. 正确
  d. 正确

• P25
  a. UDP不会对报文进行分片，而TCP会进行分片。
  b. UDP没有拥塞控制和流量控制，可以自己调整发送速度。

• P26
  a. 如果序号不重复利用，最多232字节。但是TCP的序号是可以重复利用的。
  b. 报文数 232 / 536 ~= 8,012,999
  (232 + 66 * 8,012,999) * 8 / 155 * 10242 ~= 237s

• P27
  a. 序号 207 源端口号 302 目的端口号 80
  b. 确认号 207 源端口号 80 目的端口号 302
  c. 确认号 247
  d.
  转存失败重新上传取消

• P28
  发送方维护一个接收窗口来实现流量控制，接收方提供给发送方指示接收方缓存还有多少可用空间。
  在实际的运行中，一开始接收方缓存为空，接收窗口很大。发送方发送许多数据。但是接收方读取速度较慢，因此缓存逐渐变满，接收窗口越来越小。
  发送方的速率逐渐下降，最后与接收方读取数据的速率相同。

• P29
  a. 因为使用这种特殊的序号使得服务器不用记忆初始序号，不用为连接保存状态信息。
  b. 如果攻击者不知道生成cookie的函数，那么就不能成功创建一个全开或者半开连接。
  c. 是可以使得服务器产生全开连接的。

• P30
  a. 当初始数据被发送到套接字的速率大时，时延高会导致丢包率过大，从而减小吞吐量。
  如果路由器缓存长度增加，速度不变，那么报文在路由器缓存中的时间边长，如果时间超过固定的超时值，那么路由器就会转发不必要的分组副本，从而降低吞吐量。
  b. 路由器缓存更多的报文，可以出现更少的丢包情况，有助于增加吞吐量。

• P31
  我认为书上翻译错误，应该是给出了5个样本之前的初值。

	初值	1	2	3	4	5
SampleRTT	/	106	120	140	90	115
EstimatedRTT	100	100.75	103.16	107.77	105.55	106.73
DevRTT	5	5.06	8.00	14.06	14.43	12.89
TimeoutInterval	120	120.99	135.16	164.01	163.27	158.29

• P32
  a.
  EstimatedRTT1 = 0.9 * EstimatedRTT0 + 0.1 * SampleRTT1
  EstimatedRTT2 = 0.92 * EstimatedRTT0 + 0.1 * 0.9 * SampleRTT1 + 0.1 * SampleRTT2
  EstimatedRTT3 = 0.93 * EstimatedRTT0 + 0.1 * 0.92 * SampleRTT1 + 0.1 * 0.9 * SampleRTT2 + 0.1 * SampleRTT3
  EstimatedRTT4 = 0.94 * EstimatedRTT0 + 0.1 * 0.93 * SampleRTT1 + 0.1 * 0.92 * SampleRTT2 + 0.1 * 0.9 * SampleRTT3 + 0.1 * SampleRTT4
  b.
  转存失败重新上传取消

c. 当n趋于无穷时，离n越近的EstimatedRT的影响越大。

• P33
  TCP估计正常时间的RTT，对于重传报文，可能并不是因为丢失而是单纯超时，如果重传报文发送后初始报文的ACK立即抵达，那么求得的RTT会比真实的RTT小很多。

• P34
  两者之差是在网络传送中还未到达的字节数，包括损坏的，丢失的等等。

• P35
  假设TCP接收方丢弃失序的报文段的场合：
  在生成ACK的时间，y等于LastByteRcvd，当ACK报文传回发送方的时候，因为可能有新的报文到达接收方，所以y <= LastByteRcvd

• P36
  如果收到一个冗余ACK旧快速重传，那么两个连续发送的报文，在反序到达时，就会发生重传情况。也就是说协议不允许非序到达报文。
  因此这种设计是不良的。

• P37
  a.
  GBN协议：发送报文段9次，ACK8次
  SR协议：发送报文段6次，ACK5次
  TCP协议：发送报文段6次，ACK5次
  b. TCP协议时间最短

• P38
  正确。

• P39
  对于图3-46b，λout不能超过R/3。如果λ'in超过R/2，因为超过网络所能提供的速率，因此必然会发生更严重的丢包现象，因此λout反而会降低。
  对于图3-46c，如果假定平均转发两次是固定值，那么如果λ'in超过R/2，λout能超过R/4。但是在实际情况中，如果λ'in超过R/2，丢包现象会增加，因此平均转发会超过两次，λout会小于R/4。

• P40
  a. 慢启动的时间为：1-6，23-26
  b. 拥塞避免的时间为：6-16，17-22
  c. 根据3个冗余ACK检测出来的
  d. 根据超时检测出来的
  e. 32
  f. 21
  g. 14
  h. 7
  i. 窗口长度为1，ssthresh为4
  j. 窗口长度为4，ssthresh为21
  k. 令j的假设成立，也就是16轮回时发生了快速重传，但是没有快速恢复的情况，与图中的折线不同。一共发送了52个分组。

• P41
  转存失败重新上传取消
  如图所示，吞吐量将在B和C来回变动，不能收敛于平衡。

• P42
  拥塞是解决的当前接收窗口很大，但是发送速率却不能很大的情况，这种情况超时时间加倍并不能解决。

• P43
  如果不会发生丢失和定时器超时，那么拥塞控制便无法解决此类问题。可以使用类似流量控制的方法，控制发送方已发送未确认的字节数量小于接收缓存，且小于等于链路传输速率R的要求。比如小于等于R*RTT。

• P44
  a. 6RTT
  b. 平均吞吐量8.5MSS

• P45
  a.
  假设是拥塞避免状态。一个周期发送的数据量从W/2变为W。
  转存失败重新上传取消
  b.
  转存失败重新上传取消

• P46
  a.
  1个RTT发送的字节数为10M * 150ms = 1.5Mb
  窗口长度最大为1.5Mb / (1500 * 8) = 125
  b.
  平均窗口为长度最大为 0.75 * 125 ~= 93
  平均吞吐量 93 * 1500 * 8 / 150ms = 7.44Mbps
  c.
  不考虑慢启动状态，即直接从W/2开始拥塞避免状态，窗口从62到125，经历63个RTT，9.45s

• P47
  不会做

• P48
  a.
  1个RTT发送的字节数为10G * 150ms = 1.5Gb
  窗口长度最大为1.5Gb / (1500 * 8) = 125K
  b.
  平均窗口为长度最大为 0.75 * 125K ~= 93K
  平均吞吐量 93K * 1500 * 8 / 150ms = 7.44Gbps
  c.
  不考虑慢启动状态，即直接从W/2开始拥塞避免状态，窗口从62.5K到125K，经历62.5K个RTT，9375s
  解决方案

1. 超时时，ssthresh的值可以不设为W/2，而是设为更大的数字。
2. 拥塞避免状态一个RTT可以不仅增加一个窗口，而是增加更多窗口

• P49
  设平均吞吐量为W平均
  T = W/2， W平均 = 0.75 * (W * RTT / MSS) / RTT = 0.75W / MSS
  T = W平均 * MSS / 0.75

• P50
  a.
  在t0，C1的速率为10/50ms = 200，C1的速率为10/100ms = 100，远远超过链路速率，因此他们都要减半
  又注意到，假设C1和C2的拥塞窗口为1，他们的速率为20和10，正好与链路速率相等，因此C1和C2会一直减半到1。
  b.
  考虑到一旦C1和C2的拥塞窗口超过1，那么就会发生丢包而减半，因此C1和C2的拥塞窗口都稳定为1。
  此时C1的带宽为20报文/s，C2的带宽为10报文/s，不能共享相同的带宽

• P51
  a.

时间	RTT数	C1窗口	C1速率	C2窗口	C2速率	是否拥塞
0	0	15	150	10	100	是
100ms	1	7	70	5	50	是
200ms	2	3	30	2	20	是
300ms	3	1	10	1	10	否
400ms	4	2	20	2	20	是
500ms	5	1	10	1	10	否

因此，两者的拥塞窗口长度还是1。
b.
两条连接共享相同的带宽
c.
两条连接是同步的，看a的表格即可得。
d.
这种同步可能不能改善利用率，试想如下的窗口长度：

C1窗口	C1速率	C2窗口	C2速率	是否拥塞
2	20	1	10	否

如果能稳定这种状态，可以使得当遇到拥塞时一方减半，另一方不减半，那么可以改善利用率。

• P52
  RTT 0时，窗口长度W/2
  RTT 1时，窗口长度W/2 + α* W/2 = (1 + α)W/2
  RTT 2时，窗口长度(1 + α)W/2 + α(1 + α)W/2 = (1 + α)2W/2
  RTT 3时，窗口长度(1 + α)2W/2 + α(1 + α)2W/2 = (1 + α)3W/2
  ...... RTT n时，窗口长度((1 + α)nW/2
  设n时达到W，此时((1 + α)nW/2 = W
  n = log2(1 + α)
  因此，当log2(1 + α) * RTT时到达W，与吞吐量无关

• P53
  转存失败重新上传取消

• P54
  优点是安全，保险。
  缺点是t1时刻因为发送方有大量数据要发送，因此拥塞窗口较小，但经过一段时间的空闲，可能链路中并不拥塞了（或者更加拥塞了），因此直接使用他们的值会有无法最大利用链路的问题。
  可以在t2时刻使用慢启动，重新计算cwnd和ssthresh值。

• P55
  a. 服务器将向Y发送响应
  b. 可以确认，因为SYNACK是发送给Y的，X并不知道ACK应该发送什么。

• P56
  a.

时间	活动	窗口大小	剩余窗口大小
0	发送SYN	0	0
RTT	接收SYNACK	0	0
1RTT + S/R	服务器发送数据报文1	1	0
2RTT + S/R	服务器接收ACK1，准备发送数据报文2	2	2
2RTT + 2S/R	服务器发送数据报文2	2	1
2RTT + 3S/R	服务器发送数据报文3	2	0
3RTT + 2S/R	服务器接收到ACK2，准备发送数据报文4	3	2
3RTT + 3S/R	服务器发送数据报文4，同时接收到ACK3	4	3
3RTT + 4S/R	服务器发送数据报文5	4	2

后面一直剩余窗口大小一直大于0，因此一直不停发送报文，发送的同时也接收ACK。发送所有报文后，再等待一个RTT时间，即传送完成。
最后时间为 3RTT + 4S/R + RTT + 10S/R = 4RTT + 14S/R

b.

时间	活动	窗口大小	剩余窗口大小
0	发送SYN	0	0
RTT	接收SYNACK	0	0
1RTT + S/R	服务器发送数据报文1	1	0
2RTT + S/R	服务器接收ACK1，准备发送数据报文2	2	2
2RTT + 2S/R	服务器发送数据报文2	2	1
2RTT + 3S/R	服务器发送数据报文3	2	0
3RTT + 2S/R	服务器接收到ACK2，准备发送数据报文4	3	2
3RTT + 3S/R	服务器发送数据报文4，同时接收到ACK3	4	3
3RTT + 4S/R	服务器发送数据报文5	4	2
3RTT + 5S/R	服务器发送数据报文6	4	1
3RTT + 6S/R	服务器发送数据报文7	4	0
4RTT + 3S/R	服务器接收到ACK4，准备发送数据报文8	5	2
4RTT + 4S/R	服务器发送数据报文8，同时接收到ACK5	6	3
4RTT + 5S/R	服务器发送数据报文9，同时接收到ACK6	7	4
4RTT + 6S/R	服务器发送数据报文10，同时接收到ACK7	8	5

此时剩余窗口为5，服务器只需一直发送所有报文，再等待一个RTT即可。
最后时间为 4RTT + 6S/R + RTT + 5S/R = 5RTT + 11S/R

c.

时间	活动	窗口大小	剩余窗口大小
0	发送SYN	0	0
RTT	接收SYNACK	0	0
1RTT + S/R	服务器发送数据报文1	1	0
2RTT + S/R	服务器接收ACK1，准备发送数据报文2	2	2
2RTT + 2S/R	服务器发送数据报文2，准备发送数据报文3	2	1
3RTT + 2S/R	服务器接收ACK2	3	2
2RTT + 3S/R	服务器发送数据报文3，准备发送数据报文4	3	2
3RTT + 3S/R	服务器接收ACK3	4	3
2RTT + 4S/R	服务器发送数据报文4，准备发送数据报文5	4	3

由于发送时间大于RTT，因此发送下一个之前，ACK已经收到。服务器只需一直发送所有报文，再等待一个RTT即可。
最后时间为 2RTT + 4S/R + RTT + 11S/R = 3RTT + 15S/R