1.连续ARQ协议
【5-21】 假定使用连续ARQ 协议，发送窗口大小是3,而序号范围是[0,15],而传输媒
体保证在接收方能够按序收到分组。在某一时刻，在接收方，下一个期望收到的 序号是5。试问：
(1)在发送方的发送窗口中可能出现的序号组合有哪些?
(2)接收方已经发送出的、但仍滞留在网络中(即还未到达发送方)的确认分
组可能有哪些?说明这些确认分组是用来确认哪些序号的分组。
解 答：分别回答如下：
(1)在接收方，下一个期望收到的序号是5。这表明序号到4为止的分组都已收到。若这 些确认都已到达发送方，则发送窗口最靠前，其范围是[5,7]。假定所有的确认都丢失了，发送方都没有收到这些确认。这时，发送窗口最靠后，应为[2, 4]。因此，发送窗口可以是[2,4],[3,5],[4,6],[5,7]中的任何一个。
(2)接收方期望收到序号5的分组，说明序号为2,3,4的分组都已收到，并且发送了确认。 对序号为1的分组的确认肯定被发送方收到了，否则发送方不可能发送4号分组。可见，对序 号为2,3,4的分组的确认有可能仍滞留在网络中。这些确认是用来确认序号为2,3,4的分组的。
2.报文段和确认号
【5-23】 主 机A 向主机B 连续发送了两个TCP 报文段，其序号分别是70和100。试问：
(1)第一个报文段携带了多少字节的数据?
(2)主机B 收到第一个报文段后发回的确认中的确认号应当是多少?
(3)如果B 收到第二个报文段后发回的确认中的确认号是180,试问A 发送的 第二个报文段中的数据有多少字节?
(4)如果A 发送的第一个报文段丢失了，但第二个报文段到达了B 。B 在第二 个报文段到达后向A 发送确认。试问这个确认号应为多少?
解答：
(1)第一个报文段的数据序号是70到99,共30字节的数据。
100B-70B=30B
(2)B 期望收到下一个报文段的第一个数据字节的序号是100,因此确认号应为100。
(3)A 发送的第二个报文段中的数据的字节数是180-100=80字节。
(4)A 发送的第一个报文段丢失了，但第二个报文段到达了B 。也就是说100这个确认号已经收到了，其实就是在问，下一波B期待收到什么，期待收到的是丢失的第一个报文段，所以确认号应为70。
3.TCP可靠运输--超时重传时间RTO
【5-33】假定TCP 在开始建立连接时，发送方设定超时重传时间RTO=6s。
(1)当发送方收到对方的连接确认报文段时，测量出RTT 样本值为1.5s。试 计 算现在的RTO 值。
(2)当发送方发送数据报文段并收到确认时，测量出RTT 样本值为2.5s。试 计 算现在的RTO 值。
解答：RTO 值计算如下：
(1)当第一次测量到RTT 样本时，RTTs 值就取为这个测量到的RTT 样本值。 因 此 ，RTTs=1.5s。
根据RFC 2988的建议，当第一次测量时，RTTp 值取为测量到的RTT 样本值的一半。
因 此 ，RTTp=(1/2)×1.5s=0.75s
根据式子,RTO=RTTs+4×RTTp
=1.5s+4×0.75s=4.5s
(2)新的RTT 样本=2 . 5s
根据RFC推荐,α值为1/8，β值为1/4
根据式子,新的RTTs=(1-α) × (旧的RTTs)+α × (新的RTT 样本)
=(1-1/8) × 1.5s+1/8×2.5s=1.625 s
根据式子,新的RTTp=(1-β) × ( 旧 的RTTp)+β × | RTTs- 新 的RTT 样 本 |
=(1-1/4)×0.75s+1/4×|1.625s-2.5s|=0.78125≈0.78s
根据式子,RTO=RTTs+4×RTTp
=1.625s+4×0.78s≈4.75s
4.TCP可靠运输--加权平均往返时间RTTs
【5-34】已知第一次测得TCP 的往返时间RTT（RTTs） 是30 ms。接着收到了三个确认报文段， 用它们测量出的往返时间样本RTT 分别是：26 ms,32 ms和24 ms。设α=0.1。 试计算每一次新的加权平均往返时间值RTTs。讨论所得出的结果。
解答：
新的RTTs=(1- α)× (旧的RTTs)+α×(新的RTT 样本)
第一次算出：RTTs=(1-0.1)×30+0.1×26=29.6 ms
第二次算出：RTTs=(1-0.1)×29.6+0.1×32=29.84 ms
第三次算出：RTTs=(1-0.1)×29.84+0.1×24=29.256 ms
三次算出加权平均往返时间分别为29.6,29.84和29.256 ms。
可以看出，RTT 的样本值变化多达20%时(30-24)/30=6/30=1/5=20%),加权平均往返 时间RTTs 的变化却很小。
5.拥塞窗口--拥塞避免、窗口的变化
【5-38】 设 TCP 的 ssthresh 的初始值为8(单位为报文段)。当拥塞窗口上升到12时网络发生了超时，TCP使用慢开始和拥塞避免。试分别求出RTT=1 到 RTT=15时 的各拥塞窗口大小。你能说明拥塞窗口每一次变化的原因吗?
解答：拥塞窗口大小及变化原因见表
| RTT | 拥塞窗口 | 拥塞窗口变化的原因 |
| 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 |
【5-39】TCP 的拥塞窗口cwnd 大小与RTT 的关系如表T-5-39 所示。
表T-5-39 拥塞窗口cwnd 大小与RTT 的关系
| cwnd | 1 | 2 | 4 | 8 | 16 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 |
| RTT | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| cwnd | 40 | 41 | 42 | 21 | 22 | 23 | 24 | 25 | 26 | 1 | 2 | 4 | 8 |
| RTT | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 |
(1)试画出如教材的图5-25所示的拥塞窗口与RTT 的关系曲线。
(2)指明TCP 工作在慢开始阶段的时间间隔。
(3)指明TCP 工作在拥塞避免阶段的时间间隔。
(4)在RTT=16 和 RTT=22 之后发送方是通过收到三个重复的确认还是通过超时 检测到丢失了报文段?
(5)在RTT=1,RTT=18 和RTT=24 时，门限ssthresh分别被设置为多大?
(6)在RTT 等于多少时发送出第70个报文段?
(7)假定在RTT=26 之后收到了三个重复的确认，因而检测出了报文段的丢失， 那么拥塞窗口cwnd 和门限ssthresh 应设置为多大?
解 答 ：
(1)拥塞窗口与RTT的关系曲线如图T-5-39所示。
(2)慢开始时间间隔：[RTT=1,RTT=6] 和 [RTT=23,RTT=26]。
(3)拥塞避免时间间隔：[RTT=6,RTT=16] 和 [RTT=17,RTT=22]。
(4)在RTT=16 之后发送方通过收到三个重复的确认检测到丢失了报文段，因为题目给 出，下一个RTT的拥塞窗口减半了。
在RTT=22 之后发送方通过超时检测到丢失了报文段，因为题目给出，下一个RTT 的拥 塞窗口下降到1了。
(5)在RTT=1 时，门限ssthresh 被设置为32,因为从RTT=6 起，就进入了拥塞避免状 态，每经过一个RTT, 拥塞窗口就加1。
在RTT=18 时，门限ssthresh被设置为发生拥塞时拥塞窗口42的一半，即21。 在RTT=24 时，门限ssthresh 被设置为发生拥塞时拥塞窗口26的一半，即13。
(6)RTT=1 时，发送报文段1。(cwnd=1) RTT=2 时，发送报文段2,3。(cwnd=2) RTT=3 时，发送报文段4~7。(cwnd=4)
RTT=4 时，发送报文段8~15。(cwnd=8)
RTT=5 时，发送报文段16~31。(cwnd=16) RTT=6 时，发送报文段32~63。(cwnd=32) RTT=7 时，发送报文段64~94。(cwnd=33) 因此，第70报文段在RTT=7 时发送出。
(7)检测出报文段丢失时，拥塞窗口cwnd 是8,因此拥塞窗口cwnd 的数值应当减半，等 于4,而门限ssthresh 应设置为检测出报文段丢失时拥塞窗口8的一半，即4。
请注意，只有当RTT 为整数值时，图T-5-39 的曲线才有意义。图中圆点之间的连线只是 为了便于我们观察拥塞窗口的变化。例如，当RTT=3 时 ，cwnd=32 。 当 RTT=4 时 ，cwnd= 8。但是当RTT 为3~4之间的任何值时，cwnd 是多少我们都无法得知。
6.源端口、目的端口、用户数据报总长度、数据长度
【5-49】 下面是以十六进制格式存储的一个UDP 首部：
CB84000D001C001C 试问：
(1)源端口号是什么?
(2)目的端口号是什么?
(3)这个用户数据报的总长度是多少?
(4)数据长度是多少?
(5)这个分组是从客户到服务器方向的，还是从服务器到客户方向的?
(6)客户进程是什么?
解答：
(1)源端口号是最前面的四位十六进制数字(CB8416), 算出十进制的源端口号是 12×16³+11×16²+8×16¹+4×16⁰=49152+2816+128+4=52100。
(2)目的端口号是第二个四位十六进制数字(000D₁6), 算出十进制的目的端口号是13。
(3)第三个四位十六进制数字(001C16) 定义了整个 UDP分组的长度，转换成十进制数是
1×16¹+12×16⁰=28字节。
(4)数据的长度是整个分组的长度减去首部的长度，也就是28-8=20字节。
(5)因为目的端口号是13(熟知端口),所以这个分组是从客户到服务器的。
(6)从RFC 867可以得知，这个客户进程是Daytime。当 Daytime 服务器收到客户发送的 UDP用户数据报后，就把现在的日期和时间以ASCII 码字符串的形式返回给客户。
7.发送窗口的变化
【5-61】 在本题中列出的8种情况下，画出发送窗口的变化，并标明可用窗口的位置。已
知主机A 要向主机B 发送3 KB 的数据。在TCP 连接建立后，A 的发送窗口大 小是2 KB 。A的初始序号是0。
(1)一开始A 发送1 KB 的数据。
( 2 ) 接 着A 就一直发送数据，直到把发送窗口用完。
(3)发送方A 收到对第1000号字节的确认报文段。
(4)发送方A 再发送850B 的数据。
(5)发送方A 收到ack=900 的确认报文段。
(6)发送方A 收到对第2047号字节的确认报文段。
(7)发送方A 把剩下的数据全部都发送完。
(8)发送方A 收到ack=3072 的确认报文段。
解 答：下图是发送窗口和可用窗口的变化情况。
(1)我们应当注意到，发送窗口=2 KB就是2×1024=2048字节。因此，发送窗口应当 从0到第2047字节为止，长度是2048字节。A 开始就发送了1024字节，因此发送窗口中左边 的1024个字节已经用掉了(窗口的这部分为灰色),而可用窗口是白色的，从第1024字节到第2047字节为止。请注意，不是到第2048字节为止，因为第一个字节的编号是0而不是1。
(2)发送方A 一直发送数据，直到把发送窗口用完。这时，整个窗口都已用掉了，可用窗 口的大小已经是零了， 一个字节也不能再发送了。
(3)发送方A 收到对第1000号字节的确认报文段，表明A 收到确认号ack=1001 的确认 报文段。这时，发送窗口的后沿向前移动，发送窗口从第1001字节(不是从第1000字节)到 第3048字节(不是第3047字节)为止。可用窗口从第2048字节到第3048字节。
(4)发送方A 再发送850字节，使得可用窗口的后沿向前移动850字节，即移动到2898 字节。现在的可用窗口从第2898字节到第3048字节。
(5)发送方A 收 到ack=900 的确认报文段，不会对其窗口状态有任何影响。这是个迟到 的确认。
(6)发送方A 收到对第2047号字节的确认报文段。A 的发送窗口再向前移动。现在的发 送窗口从第2048字节开始到第4095字节。可用窗口增大了，从第2898字节到第4095字节。
(7)发送方A 把剩下的数据全部都发送完。发送方A 共 有 3KB (即3072字节)的数据， 其编号从0到3071。因此现在的可用窗口变小了，从第3072字节到第4095字节。
(8)发送方A 收 到ack=3072 的确认报文段，表明序号在3071和这以前的报文段都收到 了，后面期望收到的报文段的序号从3072开始。因此新的发送窗口的位置又向前移动，从第 3072号到第5119号。整个发送窗口也就是可用窗口。
