2024/04/24说明：这篇暂时修改为粉丝可见，因为正在冲粉丝量，等到我弄完了粉丝量的要求，我就改回来！不方便看到全文的小伙伴不好意思！！ 2024/04/29说明：谢谢大家已经到2000了（虽然原本也只差个200），已经变成全部可见。

参考：英文版的原答案。 答案放gitee了，自取。 3-P18. 3.4.4 节我们学习的一般性 SR 协议中，只要报文可用(如果报文在窗口中) ，发送方就会不等待确认而传输报文。假设现在我们要求一个SR协议，一次发出一对报文，而且只有在知道第一对报文中的两个报文都正确到达后才发送第二对报文。

假设该信道中可能会丢失报文，但报文不会发生损坏和失序，试为报文的单向可靠传输 而设计一个差错控制协议：

（1）写出报文的最小序号空间（报文编号从0开始）；

（2）画出你的协议在无丢失情况的时序图；

（3）考虑分组和确认分组都可能丢失的情况下，协议是如何恢复报文丢失的，画出时序图 3-P27. 主机A和B 经一条TCP 连接通信，并且主机B已经收到了来自A的最长为 126 字节的所有字节。 假定主机A随后向主机B发送两个紧接着的报文段。第一个和第二个报文段分别包含了80字节和40 字节的数据。在第一个报文段中，序号是 127 ，源端口号是 302 ，目的地端口号是 80。无论何时主机B接收到来自主机A的报文段，它都会发送确认。

a. 在从主机A发往B的第二个报文段中，序号、源端口号和目的端口号各是什么？

b. 如果第一个报文段在第二个报文段之前到达，在第一个到达报文段的确认中，确认号、源端口号和目的端口号各是什么?

c. 如果第二个报文段在第一个报文段之前到达，在第一个到达报文段的确认中，确认号是什么?

d. 假定由A发送的两个报文段按序到达，第一个确认丢失了而第二个确认在第一个超时间隔之后到达。画出时序图，显示这些报文段和发送的所有其他报文段和确认。 (假设没有其他分组丢)对于图上每个报文段，标出序号和数据的字节数量;对于你增加的每个应答，标出确认号。

题c，第二个报文先到，所以第一个到达的报文是报文二，报文二的ack是127。

3-P31. 假设测量的 SampleRTT值(参见3.5.3节)是 106ms、120ms、140ms、90ms和115ms。在获得了每个SampleRTT的值后计算EstimatedRTT，使用α=0.125并且假设在刚获得前5个样本之后EstimatedRTT 的值为 10Oms。在获得每个样本之后，也计算 DevRTT，假设β= 0.25 ，并且假设在刚获得前5个样本之后 DevRTT 的值为 5ms。最后，在获得这些样本之后计算 TCP Timeoutlnterval。

3-P40 考虑图3-58。假设TCP Reno是一个经历如上所示行为的协议，回答下列问题。在各种情况中，简要地论证你的回答。 a. 指出TCP慢启动运行时的时间间隔。 b. 指出TCP拥塞避免运行时的时间间隔。 c. 在第16个传输轮回之后，报文段的丢失是根据3个冗余ACK还是根据超时检测出来的？ d. 在第22个传输轮回之后，报文段的丢失是根据3个冗余ACK还是根据超时检测出来的？ e. 在第1个传输轮回里，ssthresh的初始值设置为多少？ f. 在第18个传输轮回里，ssthresh的值设置为多少？ g. 在第24个传输轮回里，ssthresh的值设置为多少？ h. 在哪个传输轮回内发送第70个报文段？ i. 假定在第26个传输轮回后，通过收到3个冗余ACK检测出有分组丢失，拥塞的窗口长度和ssthresh的值应当是多少？ j. 假定使用TCP Tahoe （而不是TCP Reno），并假定在第16个传输轮回收到3个冗余ACK。在第19个传输轮回，ssthresh和拥塞窗口长度是什么？ k. 再次假设使用TCP Tahoe,在第22个传输轮回有一个超时事件。从第17个传输轮回到第22个传输轮回（包括这两个传输轮回），一共发送了多少分组？

a. 慢启动的时间间隔为[1,6]和[23,26]。 b. 拥塞避免的时间间隔为[6,16]和[17,22]。 c. 由于超时时ConWin的大小会变为1个MSS，因此报文段的丢失是根据3个重复确认检测出来的。 d. 由于ConWin的大小是变为一个MSS，因此报文段的丢失是根据超时检测出来的。 e. 因为拥塞窗口在达到32×MSS之后就开始拥塞避免阶段，因此ssthresh的初始值为32×MSS。 f. 检测到丢包之后ssthresh的值将为原来拥塞窗口长度的一半，在第16个周期时ConWin的值为42×MSS，因此在第18个传输周期里，ssthresh的值为21×MSS。 g. 检测到丢包之后ssthresh的值将为原来拥塞窗口长度的一半，在第22个传输周期时ConWin大小为29×MSS，因此在第24个传输周期里，ssthresh值为14×MSS(14.5向下取整)。 h. 在第6个传输周期时，已经发送了1+2+4+…+32=63个报文段，而在第7个传输周期ConWin大小为33，63+33=96>70,因此第70个报文段是在第7个传输周期内传送的。 i. 检测到丢包之后ssthresh的值将变成原来拥塞窗口长度的一半，如果是冗余ACK则新的拥塞窗口被置为ssthresh+3。在第26个传输周期时，拥塞窗口长度ConWin大小为8×MSS，因此ssthresh为4×MSS，拥塞窗口长度为7×MSS。 j. Tahoe的，遇到冗余ACK，ssthresh为当前ConWin大小的一半，即21×MSS。然后ConWin回到1×MSS，重新慢启动。因此在第19个传输轮回时拥塞窗口长度为4×MSS，ssthresh为21×MSS。 k. 紧接题j，第17个发了1个，第18个发了2个，第19个发了4个，第20个发了8个，第21个发了16个，第22个翻倍超过ssthresh，因此只发了21个，加起来一共发了52个分组。

3-P45 回想 TCP 吞吐量的宏观描述。在链接速率从 W/(2 x RTT) 变化到 W/RTT 的周期内，只丢失了一个分组（在该周期结束）。 a. 证明其丢包率（分组丢失的比率）等于： L = 丢包率 = 1 / ( 3/8 x W^2 + 3/4 x W ) b. 如果一条连接的丢包率为 L，使用上面的结果，则它的平均速率近似由下式给出： 平均速率 ~ 1.22 x MSS / (RTT x sqrt(L))

3-P56 在这个习题中，我们考虑由 TCP 慢启动阶段引入的时延。考虑一个客户和一个 Web 服务器直接连接到速率为 R 的一条链路。假定该客户要取回一个对象，其长度正好等于 15 S，其中 S 是最大报文段长度(MSS)。客户和服务器之间的往返时间表示为 RTT（假设为常数）。忽略协议首部，确定在下列情况下取回该对象的时间（包括 TCP 连接创建）： a. 4S/R > S/R + RTT > 2S/R b. S/R + RTT > 4S/R c. S/R > RTT

a) 3S/R > RTT > S/R；b) RTT > 3S/R；c) S/R > RTT。 a) 始终站在客户端的角度可以更好地理解整个过程，上图是题a的分析过程。 初始化建立连接需要2×RTT。第一个RTT是①客户端请求+②服务端回应请求，第二个RTT是③客户端响应服务端的回应+④服务端确认客户端的响应。如果是客户端主动向服务器发送数据，则第③个报文即可承载有效载荷；但这里是客户端需要服务器返回数据，因此服务器只有等待接收到③报文之后才能进行数据包的收发。如果初始化建立连接是从客户端发送请求报文①开始、到客户端接收服务器的确认报文④结束，则可认为初始化建立连接需要2×RTT。 在服务器收到③报文后，便可以将传输对象下放到链路中，这个过程耗时S/R。 —— 慢启动最开始只能发一个分组，意思是，服务器接收到客户端对该分组的响应之后才能发送下一个分组。再次站在客户端的角度理解这个过程，从客户端接收服务器的确认报文④、到客户端接收服务器对第一个分组的响应的确认报文为止，耗时S/R+RTT。 如果从客户端开始发送请求算起(也就是报文①被发送时)，到现在客户端已经接收第一个分组的响应的确认为止，一共耗时3RTT+S/R。 —— 然后服务器可以发2个分组，由于RTT>S/R，服务器成功传输第三个分组到链路中并发送后，第二个分组的响应报文还没发回来，所以服务器陷入等待。此时服务器没有发第四个分组，是受限于第二个分组的响应报文还没传过来，而不是受限于第三个分组还没传输完成。 服务器在什么情况能发送下一个分组？答：窗口有空的时候。慢启动时，服务器每接收一个ACK，窗口大小都增加1，而且接收一个正确的ACK也会使窗口移动到下一位，即窗口多出来两个空位，可以继续发分组。 站在客户端的立场，从客户端接收服务器对第一个分组的响应的确认报文、到客户端接收到第三组报文，耗时S/R+RTT。 —— 接下来依次可以发4个、8个，以窗口为4举例，传第一个分组到链路上花了S/R，第一个分组的响应报文被服务器接收到需要RTT，但是S/R+RTT4S/R，则拥塞窗口长度为4的时候，第一个分组的响应报文还没回来，所以服务器要等响应报文，会被RTT限制。窗口为8时则不会被限制。总时长为2×RTT+(S/R+RTT)+(S/R+RTT)+(S/R+RTT)+8×S/R=5×RTT + 11×S/R。 c) 同理， 从第二次发送开始每次发送都不会被RTT限制，总时长为2×RTT+(S/R+RTT)+(2+4+8)×S/R=3×RTT + 15×S/R。

如果想图文并茂地了解怎么回事，请看github_YangXiaoHei/Networking/计算机网络自顶向下/03 运输层/习题_34_56.md。

本账号所有文章均为原创，欢迎转载，请注明文章出处：https://blog.csdn.net/qq_46106285/article/details/121449290。百度和各类采集站皆不可信，搜索请谨慎鉴别。技术类文章一般都有时效性，本人习惯不定期对自己的博文进行修正和更新，因此请访问出处以查看本文的最新版本。