计算机网络原理（谢希仁第八版）第五章课后习题答案

男娘i 2023-10-02 12:20 22阅读 0赞

## 第五章 ##

**35题，36题已经做了更正，特别感谢粉丝奈七七的答案。**  
**1.试说明运输层在协议栈中的地位和作用，运输层的通信和网络层的通信有什么重要区别？为什么运输层是必不可少的？**  
答：运输层处于面向通信部分的最高层，同时也是用户功能中的最低层，向它上面的应用层提供服务 运输层为应用进程之间提供端到端的逻辑通信，但网络层是为主机之间提供逻辑通信（面向主机，承担路由功能，即主机寻址及有效的分组交换）。 各种应用进程之间通信需要“可靠或尽力而为”的两类服务质量，必须由运输层以复用和分用的形式加载到网络层。  
**2.网络层提供数据报或虚电路服务对上面的运输层有何影响？**  
答：网络层提供数据报或虚电路服务不影响上面的运输层的运行机制。 但提供不同的服务质量。  
**3.当应用程序使用面向连接的TCP和无连接的IP时，这种传输是面向连接的还是面向无连接的？**  
答：都是。这要在不同层次来看，在运输层是面向连接的，在网络层则是无连接的。  
**4.试用画图解释运输层的复用。画图说明许多个运输用户复用到一条运输连接上，而这条运输连接有复用到IP数据报上。**  
答：  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16]  
在图中，主机H3同时和主机H1和主机H2进行通信。H1和H3两个应用进程（HTTP和SMTP）进行通信，这需要使用两个TCP连接。这两个TCP连接所传送的报文段，使用下面的网络层IP数据报进行传送。H2和H3的应用进程（HTTP）进行通信，这需要使用一个TCP进行连接。这个TCP连接所传送的报文段，也要使用下面的网络层IP数据报进行传送。在网络层所传送的IP数据报已看不到运输层以上的复用情况。  
**5.试举例说明有些应用程序愿意采用不可靠的UDP，而不用采用可靠TCP。**  
答：VOIP：由于语音信息具有一定的冗余度，人耳对VOIP数据报损失由一定的承受度，但对传输时延的变化较敏感。有差错的UDP数据报在接收端被直接抛弃，TCP数据报出错则会引起重传，可能带来较大的时延扰动。因此VOIP宁可采用不可靠的UDP，而不愿意采用可靠的TCP。  
**6.接收方收到有差错的UDP用户数据报时应如何处理？**  
答：丢弃。  
**7.如果应用程序愿意使用UDP来完成可靠的传输，这可能吗？请说明理由。**  
答：可能，但应用程序中必须额外提供与TCP相同的功能。  
**8.为什么说UDP是面向报文的，而TCP是面向字节流的？**  
答：发送方 UDP 对应用程序交下来的报文，在添加首部后就向下交付 IP 层。UDP 对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。接收方 UDP 对 IP 层交上来的 UDP 用户数据报，在去除首部后就原封不动地交付上层的应用进程，一次交付一个完整的报文。发送方TCP对应用程序交下来的报文数据块，视为无结构的字节流（无边界约束，课分拆/合并），但维持各字节。  
**9.端口的作用是什么？为什么端口要划分为三种？**  
答：端口的作用是对TCP/IP体系的应用进程进行统一的标志，使运行不同操作系统的计算机的应用进程能够互相通信。熟知端口，数值一般为0——1023.标记常规的服务进程；登记端口号，数值为1024——49151，标记没有熟知端口号的非常规的服务进程。  
**10.试说明运输层中伪首部的作用。**  
答：用于计算运输层数据报校验和。  
**11.某个应用进程使用运输层的用户数据报UDP，然而继续向下交给IP层后，又封装成IP数据报。既然都是数据报，可否跳过UDP而直接交给IP层？哪些功能UDP提供了但IP没提提供？**  
答：不可跳过UDP而直接交给IP层IP数据报IP报承担主机寻址，提供报头检错；只能找到目的主机而无法找到目的进程。UDP提供对应用进程的复用和分用功能，以及提供对数据差分的差错检验。  
**12.一个应用程序用UDP，到IP层把数据报在划分为4个数据报片发送出去，结果前两个数据报片丢失，后两个到达目的站。过了一段时间应用程序重传UDP，而IP层仍然划分为4个数据报片来传送。结果这次前两个到达目的站而后两个丢失。试问：在目的站能否将这两次传输的4个数据报片组装成完整的数据报？假定目的站第一次收到的后两个数据报片仍然保存在目的站的缓存中。**  
答：不行。重传时，IP数据报的标识字段会有另一个标识符。仅当标识符相同的IP数据报片才能组装成一个IP数据报。前两个IP数据报片的标识符与后两个IP数据报片的标识符不同，因此不能组装成一个IP数据报。  
**13.一个UDP用户数据的数据字段为8192字节。在数据链路层要使用以太网来传送。试问应当划分为几个IP数据报片？说明每一个IP数据报字段长度和片偏移字段的值。**  
答：UDP数据报 = 首部8字节 + 数据部分组成。  
因为数据字段为8192字节，所以数据报总长度 = 8192 + 8 = 8200 字节。  
以太网的最大传输单元MTU = 1500。  
因为要划分为几个IP数据报，而每个IP数据报的首部占20字节，所以字段部分最大占1480字节。  
划分的时候，可以划分为 8200 / 1480 = 5，余 800 字节。  
所以应当划分为 6 个IP数据报片，前 5 个都是 1480 字节，第 6 个是 800 字节。一个字段即为8个字节。  
第一个IP数据报字段长度：1480，第一片偏移字段：1480 \* 0 / 8 = 0  
*第二个IP数据报字段长度：1480，第二片偏移字段：1480 \* 1 / 8 = 185*  
第三个IP数据报字段长度：1480，第三片偏移字段：1480 \* 2 / 8 = 370  
*第四个IP数据报字段长度：1480，第四片偏移字段：1480 \* 3 / 8 = 555*  
第五个IP数据报字段长度：1480，第五片偏移字段：1480 \* 4 / 8 = 740  
*第六个IP数据报字段长度：800， 第六片偏移字段：1480 \* 5 / 8 = 925*  
UDP数据报的首部存在于第一个IP数据报片中，所以第一个IP数据报字段为：首部8字节 + 1472数据部分。  
**14.一UDP用户数据报的首部十六进制表示是：06 32 00 45 00 1C E2 17.试求源端口、目的端口、用户数据报的总长度、数据部分长度。这个用户数据报是从客户发送给服务器还是服务器发送给客户？使用UDP的这个服务器程序是什么？**  
解：源端口：1586（前4个字节0632）  
目的端口：69（00 45）  
用户数据报总长度：28 字节（00 1C，其中首部占8字节）  
数据部分长度：20 字节  
这个用户数据报是：从客户发送给服务器  
服务器程序：TFTP。  
UDP数据报由首部字段和数据字段组成，其中首部占8个字节（TCP数据报首部占20字节），格式如下:  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 1]  
以上求出的长度为UDP数据报的总长度28字节，由于UDP数据报的首部占8字节，所以数据字段长度占20字节  
因为目的端口号 69 < 1023，是常用的服务端口，所以这个数据报是发往服务器端的  
0~1023：常用的服务端口  
1024~49151是被注册的端口，也成为“用户端口”  
其中 1024~5000为临时端口  
因为端口号为69，所以使用 UDP 的这个服务器程序是TFTP  
TFTP：是TCP/IP协议族中的一个用来在客户机与服务器之间进行简单文件传输的协议，提供不复杂、开销不大的文件传输服务。端口号为69。  
**15.使用TCP对实时话音数据的传输有没有什么问题？使用UDP在传送数据文件时会有什么问题？**  
答：如果语音数据不是实时播放（边接受边播放）就可以使用TCP，因为TCP传输可靠。接收端用TCP讲话音数据接受完毕后，可以在以后的任何时间进行播放。但假定是实时传输，则必须使用UDP。 UDP不保证可靠付，但UCP比TCP的开销要小很多。因此只要应用程序接受这样的服务质量就可以使用UDP。  
**16.在停止等待协议中如果不使用编号是否可行？为什么？**  
答:不可行，分组和确认分组都必须进行编号，才能明确哪个分则得到了确认。  
**17.在停止等待协议中，如果收到重复的报文段时不予理睬（即悄悄地丢弃它而其他什么也没做）是否可行？试举出具体的例子说明理由。**  
答:可行，比如收到重复的报文段不确认相当于确认丢失。  
**18.假定在运输层使用停止等待协议。发送发在发送报文段M0后再设定的时间内未收到确认，于是重传M0，但M0又迟迟不能到达接收方。不久，发送方收到了迟到的对M0的确认，于是发送下一个报文段M1，不久就收到了对M1的确认。接着发送方发送新的报文段M0，但这个新的M0在传送过程中丢失了。正巧，一开始就滞留在网络中的M0现在到达接收方。接收方无法分辨M0是旧的。于是收下M0，并发送确认。显然，接收方后来收到的M0是重复的，协议失败了。试画出类似于图5-9所示的双方交换报文段的过程。**  
答：![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 2]  
我们可以看出，旧的M0被当成是新的M0！可见运输层不能使用停止等待协议（编号只有 0 和1 两种）。  
**19.试证明：当用 n 比特进行分组的编号时，若接收到窗口等于 1（即只能按序接收分组），当仅在发送窗口不超过 2 n − 1 2^n-1 2n−1时，连接 ARQ 协议才能正确运行。窗口单位是分组。**  
答：  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 3]  
Ⅰ、设发送窗口记为 WT，接收窗口记为 WR。假定用 3 比特进行编号。设接收窗口正好在 7 号分组处（有阴影的分组）。  
Ⅱ、发送窗口 WT的位置不可能比 ② 的位置更靠前。因为接收窗口的位置表明接收方正在等待接收 7 号分组，而这时的发送方不可能已经收到了对 7 号分组的确认。因此发送窗口必须包括 7 号分组，也就是不可能比 ② 的位置更靠前（前方就是图的右方）。  
Ⅲ、发送窗口 WT的位置不可能比 ③ 的位置更靠后。因为接收窗口的位置表明接收方已经对 6 号分组（以及以前的分组）发送了确认。但如果发送窗口 WT的位置再靠后一个分组，即在 6 号分组的左边，那就表明还没有发送 6 号分组。但接收方的位置表明接收方已经发送了对 6 号分组的确认。这显然是不可能的。  
Ⅳ、发送窗口 WT的位置可能在某个位置的中间，如 ①。  
对于 ① 和 ② 的情况，在 WT的范围内必须无重复序号，即 WT ⩽  2 n 2^n 2n。  
对于 ③ 的情况，在 WT\+ WR的范围内无重复序号，即 WT \+ WR ⩽  2 n 2^n 2n。  
现在 WR = 1,故发送窗口的最大值：WT ⩽  2 n − 1 2^n − 1 2n−1。  
**20.在连续 ARQ 协议中，若发送窗口等于 7，则发送端在开始时可连续发送 7 个分组。因此，在每一分组发送后，都要置一个超时计时器。现在计算机里只有一个硬时钟。设这 7 个分组发出的时间分别为 t0,t1,…t6,且tout都一样大。试问如何实现这 7 个超时计时器（这叫软件时钟法）？**  
答：  
**方法1**：可采用链表记录，其信息域为分组的相对发送时间和分组编号来实现。当编号为 0 的分组定时时钟到期后，修改链表指针并重发此分组，同时将头指针指向编号为 1 的分组，以此类推。此类方法相当于数据结构算法里的链表建立的过程。我有一篇C++的链表文章，可以参考。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 4]  
**方法2**：可以定义一个含有7个数据的数组，数组中的数据表示时间，当该组数据发送出去时，在对应序号的数组中填入时间值，该时间值是该组发送出去的时间+超时时间得到，如何不停的对该数组的值进行扫描，当接收到接收端的确认分组时，即将对应数组序号的时间值设置为空，准备记录下一个数据发发送时间，当系统时间大于数组中某一个时间值时，说明该分组以及超时了，需要进行重传。  
**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 的分组的。  
**22.主机 A 向主机 B 发送一个很长的文件，其长度为 L 字节。假定 TCP 使用的 MSS 有 1460 字节。  
（1）在 TCP 的序号不重复使用的条件下，L 的最大值是多少？  
（2）假定使用上面计算出文件长度，而运输层、网络层和数据链路层所使用的首部开销共 66 字节，链路的数据率为 10 Mb/s，试求这个文件所需的最短发送时间**  
答：（1）可能的序号共  2 32 2^\{32\} 232=4294967296 个。TCP 的序号是数据字段中每一个字节的编号，而不是每一个报文段的编号。因此，这一小题与报文段的长度无关，即用不到题目给出的 MSS 值。这个文件 L 的最大值就是可能的序号数，即 4294967296 字节。若1GB=  2 30 2^\{30\} 230B，则 L 的最大值为 4 GB。  
（2）发送帧数等于数据字节/每帧的数据字节= 2 32 2^\{32\} 232/1460=2941758.422，需要发送 2941759 个帧。  
帧首部的开销是 66×2941759 = 194156094 字节。  
发送的总字节数 =  2 32 2^\{32\} 232 \+ 194156094 = 4489123390字节。  
数据率 10 Mbilt/s = 1.25 MB/s = 1250000 字节/秒。  
发送 4489123390 字节需时间为：4489123390/1250000 =3591.3 秒。  
即 59.85 分，约 1 小时。  
23.主**机 A 向主机 B 连续发送了两个 TCP 报文段，其序号分别为 70 和 100。试问：  
（1）第一个报文段携带了多少个字节的数据？  
（2）主机 B 收到第一个报文段后发回的确认中的确认号应当是多少？  
（3）如果主机 B 收到第二个报文段后发回的确认中的确认号是 180，试问 A 发送的第二个报文段中的数据有多少字节？  
（4）如果 A 发送的第一个报文段丢失了，但第二个报文段到达了 B。B 在第二个报文段到达后向 A 发送确认。试问这个确认号应为多少？**  
答：  
（1）第一个报文段的数据序号是 70 到 99，共 30 字节的数据。  
（2）B 期望收到下一个报文段的第一个数据字节的序号为 100，因此确认号为 100。  
（3）A 发送的第二个报文段中的数据中的字节数是 180 - 100 = 80 字节（**实际上，就是序号 100 到序号 179 的字节，即 179 - 100 + 1 = 80 字节**）  
（4）B 在第二个报文段到达后向 A 发送确认，其确认号应为 70。**（报文段丢失，就会重复发送确认上一个未收到的报文段第一个序号，即 70）**  
**24.一个 TCP 连接下面使用 256 kb/s 的链路，其端到端时延为 128 ms。经测试，发现吞吐量只有 120 kb/s。试问发送窗口 W 是多少？（提示：可以有两种答案，取决于接收端发出确认的时机）。**  
答：设发送窗口 = W（bit），再设发送端连续发送完窗口内的数据所需要的时间 = T。有两种情况：  
（a）接收端在收完一批数据的最后才发出确认，因此发送端经过 (256 ms + T) 后才能发送下一个窗口的数据。  
（b）接收端每收到一个很小的报文段就发回确认，因此发送端经过比 256 ms 略多一些的时间即可在发送数据。因此每经过 256 ms 就能发送一个窗口的数据。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 5]  
**（a）**：吞吐量=数据量/时间  
数据量=W；时间=发送时延+往返时延=W/256kbit/s+256ms；  
吞吐量=W/\[(W/256kbit/s)+256ms\]=120kbit/s;  
求得W=57825.88bit，约等于7228字节。  
**（b）**：吞吐量=数据量/时间  
数据量=W；时间=发送时延+往返时延=256ms（这里b是发送一点就确认接收一点，所以发送时延可以忽略不计。）  
吞吐量=W/256ms=120kbit/s；  
求得W=30720bit=3840字节。  
**25.为什么在 TCP 首部中要把 TCP 端口号放入最开始的 4 个字节？**  
答：在 ICMP 的差错报文中要包含 IP 首部后面的8个字节的内容，而这里面有 TCP 首部中的源端口和目的端口。当 TCP 收到 ICMP 差错报文时需要用这两个端口来确定是哪条连接出了差错。  
**26.为什么在 TCP 首部中有一个首部长度字段，而 UDP 的首部中就没有这个这个字段？**  
TCP 首部除固定长度部分外，还有选项，因此 TCP 首部长度是可变的。UDP 首部长度是固定的。  
**27.一个 TCP 报文段的数据部分最多为多少个字节？为什么？如果用户要传送的数据的字节长度超过 TCP 报文字段中的序号字段可能编出的最大序号，问还能否用 TCP 来传送？**  
答：（1） 一个 TCP 那段的数据部分最多为 65495 字节，此数据部分加上 TCP 首部的 20 字节，再加上 IP 首部的 20 字节，正好是 IP 数据报的最大长度 65535。（当然，若 IP 首部包含了选择，则 IP 首部长度超过20字节，这时 TCP 报文段的数据部分的长度将小于 65495 字节。）  
（2）如果数据的字节长度超过 TCP 报文段中的序号字段可能编出的最大序号，仍可用 TCP 传送。编号用完后可重复使用。但应设法保证不出现编号的混乱。  
**IP 数据报的最大长度 =  2 1 6 2^16 216 − 1 = 65535 字节  
TCP 报文段的数据部分 = IP 数据报的最大长度 - IP 数据报的首部 - TCP 报文段的首部 = 65535 - 20 - 20 = 65495 字节  
一个 TCP 报文段的最大载荷是 65515 字节.  
IP数据报的最大长度为  2 1 6 2^16 216 − 1= 65535 字节，减去 IP 数据报首部 20 字节和 TCP 首部 20 字节后的 TCP 报文段的数据部分为 65495 字节。**  
**28.主机 A 向主机 B 发送 TCP 报文段，首部中的源端口是 m 而目的端口是n。当 B 向 A 发送回信时，其 TCP 报文段的首部中源端口和目的端口分别是什么？**  
答：当 B 向 A 发送回信时，其 TCP 报文段的首部中得到源端口就是 A 发送的 TCP 报文段首部的目的端口 n，而 B 发送的 TCP 报文段首部中的目的端口就是 A 发送的 TCP 报文段首都的源端口 m。  
**29.在使用 TCP 传送数据时，如果有一个确认报文段丢失了，也不一定会引起与该确认报文段对应的数据的重传。试说明理由。**  
答：还未重传就收到了对更高序号的确认。因为 TCP 接收方只会对按序到达的最后一个分组发送确认。当对更高的序号确认了，意味着已经到达了，即不用重传了。  
**30.设 TCP 使用的最大窗口为 65535 字节，而传输信道不产生差错，带宽也不受限制。若报文段的平均往返时延为 20 ms，问所能得到的最大吞吐量是多少?**  
解： 最大吞吐量那就是单位时间内的最大发送数据量。  
即每20ms可以发送65535×8=524280bit。  
吞吐量=524280bit/20ms=26.2Mb/s。  
**31.通信信道带宽为 1 Gb/s，端到端时延为 10 ms。TCP 的发送窗口为 65535 字节。试问:可能达到的最大吞吐量是多少?信道的利用率是多少?**  
解：吞吐量=发送数据/时间  
发送数据最大=65535×8=524280bit。  
时间=发送时延+往返时延=524280bit/(1Gbit/s)+20ms=20.524ms。  
最大吞吐量=524280bit/20.524ms=25.5Mbit/s。  
信道利用率=吞吐量/带宽=(25.5Mbit/s)/(1Gbit/s)×100%=2.55%。  
**32.什么是 Karn 算法?在 TCP 的重传机制中，若不采用 Karn 算法，而是在收到确认时都认为是对重传报文段的确认，那么由此得出的往返时延样本和重传时间都会偏小。试问：重传时间最后会减小到什么程度?**  
答：Karn 算法允许 TCP 能够区分开有效的和无效的往返时间样本，从而改进往返时间的估算。  
若不采用 Karn 算法，而是在收到确认时都认为是对重传报文段的确认，那么由此得出的往返时间样本和重传时间都会偏小。如下图所示，TCP 发送了报文段后，没有收到确认，于是超时重传报文段。但刚刚重传了报文段后，马上就收到了确认。显然，这个确认是对原来发送的报文段的确认。  
但是，根据题意，我们就认为这个确认是对重传的报文段的确认。这样得出的往返时间就会很小。这样的往返时间最后甚至可以减小到很接近于零、  
因此，上述的这种做法是不可取的。  
**33.假定 TCP 在开始建立连接时，发送方设定超时重传时间是RTO = 6秒。  
（1）当发送方接到对方的连接确认报文段时，测量出 RTT 样本值为1.5秒。试计算现在的RTO值。  
（2）当发送方发送数据报文段并接收到确认时，测量出RTT样本值为2.5秒。试计算现在的RTO值。**  
解：（1）当第一次测量RTT样本时，RTTS就取值RTT样本值为1.5s。RTTS=1.5s  
根据RFC2988的建议，RTTD取值为RTT样本值的一半。  
RTTD=0.75s  
根据公式可得：RTO=RTTS\+4RTTD=1.5s+3s=4.5s  
（2）新的RTT样本为2.5s。**（根据RFC6298推荐，α取1/8，β取1/4。）**  
即新的RTTS=（1-α）×（旧的RTTS)+α×（新的RTT样本）=1.625s  
新的RTTD=（1-β）×（旧的RTTD)+β×|RTTS\-新的RTT样本|=0.78s  
根据公式：RTO=RTTS\+4RTTD=1.625s+4×0.78s=4.75s  
**34.已知第一次测得 TCP 的往返时延的当前值 RTT 是 30 ms。现在收到了三个接连的确认报文段，它们比相应的数据报文段的发送时间分别滞后的时间是：26 ms，32 ms 和24 ms。设 α = 0.1。试计算每一次的新的加权平均往返时间值RTTS。讨论所得出的结果。**  
解：公式：即新的RTTS=（1-α）×（旧的RTTS)+α×（新的RTT样本）  
第一次：RTTs=（1-0.1）×30ms+0.1×26ms=29.6ms  
第二次：RTTS=（1-0.1）×29.6ms+0.1×32ms=29.86ms  
第三次：RTTS=（1-0.1）×29.86ms+0.1×24ms=29.256ms  
三次的加权平均时间相差不大，当RTT样本值变化不大时，RTTs的变化也是很小的。  
**35.用TCP通过速率为1Gbit/s的链路传送一个10MB的文件。假定链路的往返时延RTT=50ms。TCP选用了窗口扩大选项，使窗口达到可选用的最大值。在接收端，TCP的接收窗口为1MB，而发送端采用拥塞控制算法，从慢开始传送。假定拥塞窗口以分组为单位计算，在一开始发送1个分组，而每个分组长度都是1KB.假定网络不会发生拥塞和分组丢失，并且发送端发送数据的速率足够快，因此发送时延可以忽略不计，而接收端每一次收完一批分组后就立即发送确认ACK分组。  
(1)经过多少个RTT后，发送窗口大小达到1MB？  
(2)发送端把整个10MB文件传送成功共需要多少个RTT？传送成功是指发送完整个文件，并收到所有的确认。TCP扩大的窗口够用么？  
(3)根据整个文件发送成功所花费的时间（包括收到所有的确认），计算此传输链路的有效吞吐率。链路带宽的利用率是多少？**  
解：(1)根据拥塞算法，就是每一次接收端发出确认时，发送端口就会增加为原来的2倍。则1MB=1024KB。那么就是 2 10 2^\{10\} 210KB=1MB，也就是来回十次就可以了，经过10个RTT，发送窗口大小达到1MB。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 6]  
(2)从图中可看出，当第10个RTT结束时，已传送成功的分组是 2 10 − 1 2^\{10\}-1 210−1个分组，正好比1MB少一个分组。一个分组只有1KB，可先不考虑。可以这样分析:在第10个RTT结束时，发送窗口为1MB，已传送成功的数据量约为1MB（准确的是1MB-1 KB)，因此在此基础上，我们还需要再传送9MB（实际上还需要再传送9MB+ 1 KB)。由于每经过一个RTT，发送窗口就加倍，因此在第11个RTT结束时，又成功发送了1MB。第12个RTT结束时，又成功发送了2MB。第13个RTT结束时，又成功发送了4MB。至此，一共又成功传送了I+2+4=7MB。与9MB 相比还差2MB。因此还要经过一个RTT。在第14个RTT开始时把所有剩下的数据2MB(实际上是2MB+1KB）都发送完毕。这样，全部10MB的数据成功发送完毕需要14个 RTT。  
(3)吞吐率=数据量/时间  
数据量=10MB=10× 2 20 2^\{20\} 220B=10× 2 20 2^\{20\} 220×8bit  
时间=14×50ms=0.7s  
有效吞吐率=10× 2 20 2^\{20\} 220×8bit/0.7s=119.8Mbit/s  
带宽利用率=吞吐量/带宽  
带宽利用率=119.8Mbit/s/1Gbit/s×100%=11.98%  
**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。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 7]  
**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 大小，使拥塞窗口缓慢增大，以防止网络过早出现拥塞。  
**38.设 TCP 的 ssthresh 的初始值为 8 (单位为报文段)。当拥塞窗口上升到 12 时网络发生了超时，TCP 使用慢开始和拥塞避免。试分别求出第 1 次到第 15 次传输的各拥塞窗口大小。你能说明拥塞控制窗口每一次变化的原因吗？**  
答：拥塞窗口大小及变化原因见下表：

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

注：依照原理，首先执行 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。  
**39.TCP 的拥塞窗口 cwnd 大小与传输轮次 n 的关系如表所示：**  
![在这里插入图片描述][af649358836844d1a341ad5e895f7da7.png]  
**（1）试画出如教材中图 5-25 所示的拥塞窗口与传输轮次的关系曲线。  
（2）指明 TCP 工作在慢开始阶段的时间间隔。  
（3）指明 TCP 工作在拥塞避免阶段的时间间隔。  
（4）在第 16 轮次和第 22 轮次之后发送方是通过收到三个重复的确认还是通过超时检测到丢失了报文段？  
（5）在第 1 轮次，第 18 轮次和第 24 轮次发送时，门限 ssthresh 分别被设置为多大？  
（6）在第几轮次发送出第 70 个报文段？  
（7）假定在第 26 轮次之后收到了三个重复的确认，因而检测出了报文段的丢失，那么拥塞窗口 cwnd 和门限 ssthresh 应设置为多大？**  
答：(1)![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 8]  
（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 数据报已经到达终点，但终点的缓存没有足够的空间存放此数据报。  
③ 数据报在转发过程中经过一个局域网的网桥，但网桥在转发该数据报的帧时没有足够的储存空间而只好丢弃。  
**41.用 TCP 传送 512 字节的数据。设窗口为 100 字节，而 TCP 报文段每次也是传送 100 字节的数据。再设发送端和接收端的起始序号分别选为 100 和 200，试画出类似于教材中图 5-31 的工作示意图。从连接建立阶段到连接释放都要画上。**  
要传送的 512 B 的数据必须划分为 6 个报文段传送，前 5 个报文段各 100 B，最后一个报文段传送 12 B。下图是双方交互的示意图。下面进行简单的解释。  
【----- 进行三报文握手 -----】  
**报文段 \#1**：A 发起主动打开，发送 SYN 报文段，除以 SYN-SENT 状态，并选择初始序号 seq = 100。B 处于 LISTEN 状态。  
**报文段 \#2**：B 确认 A 的 SYN 报文段，因此 ack = 101（是 A 的初始序号加 1）。B选择初始序号 seq = 200。B 进入到 SYN-RCVD 状态。  
**报文段 \#3**：A 发送 ACk 报文段来确认报文段 \#2，ack = 201（是 B 的初始序号加 1）。A 没有在这个报文段中放入数据。因为 SYN 报文段 \#1 消耗了一个序号，因此报文段 \#3 的序号是 seq = 101。这样，A 和 B 都进入了 ESTABLISHED 状态。  
【----- 三报文握手完成 -----】  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 9]  
【----- 开始数据传送 -----】  
**报文段 \#4**：A 发送 100 字节的数据。报文段 \#3 是确认报文段，没有数据发送，报文段 \#3 并不消耗序号，因此报文段 \#4 的序号仍然是 seq = 101。A 在发送数据的同时，还确认 B 的报文段 \#2，因此 ack = 201。  
**报文段 \#5**：B 确认 A 的报文段 \#4。由于收到了从序号 101 到 200 共 100 字节的数据，因此在报文段 \#5 中，ack = 201（所期望收到的下一个数据字节的序号）。B 发送的 SYN 报文段 \#2 消耗了一个序号，因此报文段 \#5 的序号是 seq = 201，比报文段 \#2 的序号多了一个序号。在这个报文段中，B 给出了接收窗口 rwnd = 100。  
**从报文段 \#6** 到报文段 \# 13 都不需要更多的解释。到此为止，A 已经发送了 500 字节 的数据。值得注意的是，B 发送的所有确认报文都不消耗序号，其序号都是 seq = 201。  
**报文段 \#14**：A 发送最后 12 字节的数据，报文段 \#14 的序号是 seq = 601。  
**报文段 \#15**：B 发送对报文段 \#14 的确认。B 收到从序号 601 到 602 共 12 字节的数据。因此，报文段 \#15 的确认号是 ack = 613（所期望收到的下一个数据字节的序号）。  
需要注意的是，从报文段 \#5 一直到 报文段 \#15，B 一共发送了 6 个确认，都不消耗序号，因此 B 发送的报文段 \#15 的序号仍然和报文段 \#5 的序号一样，即 seq = 201。  
【-----数据传送完毕-----】  
【-----进行四报文挥手------】  
**报文段 \#16**：A 发送 FIN 报文段。前面所发送的数据报文段 \#14 已经用掉了序号 601 到 612，因此报文段 \#16 序号是 seq = 613。A 进入 FIN-WAIT-1 状态。报文段 \#16 的确认号 ack = 202。  
**报文段 \#17**：B发送确认报文段，确认号为 614，进入 CLOSE-WAIT 状态。由于确认报文段不消耗序号，因此报文段 \#17 的序号仍然和报文段 \#15 的一样，即 seq = 201  
**报文段 \#18**：B 没有数据要发送，就发送 FIN 报文段 \#18，其序号仍然是 seq = 201。这个 FIN 报文会消耗一个报文。  
**报文段 \#19**：A 发送最后的确认报文段。报文段 \#16 的序号是 613，已经消耗掉了。因此，现在的序号是 seq = 614。但这个确认报文段并不消耗序号。  
【-----四报文挥手结束-----】  
**42.在图 5-29 中所示的连接释放过程中，主机 B 能否先不发送 ACK = x + 1 的确认?（因为后面要发送的连接释放报文段中仍有 ACK = x + 1 这一信息）**  
答：![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 10]  
如果 B 不再发送数据了，是可以把两个报文段合并成为一个，即只发送 FIN+ACK 报文段。但如果 B 还有数据报要发送，而且要发送一段时间，那就不行，因为 A 迟迟收不到确认，就会以为刚才发送的 FIN 报文段丢失了，就超时重传这个 FIN 报文段，浪费网络资源。  
**43.在图 5-30 中，在什么情况下会发生从状态 SYN-SENT 到状态 SYN-RCVD 的变迁？**  
答：  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 11]  
当 A 和 B 都作为客户，即同时主动打开 TCP 连接。这时的每一方的状态变迁都是：  
CLOSED -> SYN-SENT -> SYN-RCVD -> ESTABLISHED  
**44.试以具体例子说明为什么一个运输连接可以有多种方式释放。可以设两个互相通信的用户分别连接在网络的两结点上。**  
答：设 A，B建立了运输连接。  
协议应考虑一下实际可能性： A 或 B 故障，应设计超时机制，使对方退出，不至于死锁；  
A主动退出，B被动退出  
B主动退出，A被动退出  
**45.解释为什么突然释放运输连接就可能会丢失用户数据，而使用 TCP 的连接释放方法就可保证不丢失数据。**  
答：当主机 1 和主机 2 之间连接建立后，主机 1 发送了一个 TCP 数据段并正确抵达主机 2，接着主机 1 发送另一个TCP数据段，这次很不幸，主机 2 在收到第二个 TCP 数据段之前发出了释放连接请求，如果就这样突然释放连接，显然主机 1 发送的第二个 TCP 报文段会丢失。  
而使用 TCP 的连接释放方法，主机 2 发出了释放连接的请求，那么即使收到主机 1 的确认后，只会释放主机 2 到主机 1 方向的连接，即主机 2 不再向主机 1 发送数据，而仍然可接收主机 1 发来的数据，所以可保证不丢失数据。  
**46.试用具体例子说明为什么在运输连接建立时要使用三次握手。说明如不这样做可能会出现什么情况。**  
答：3 次握手完成两个重要的功能，既要双方做好发送数据的准备工作（双方都知道彼此已准备好），也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。  
假定 B 给 A 发送一个连接请求分组，A 收到了这个分组，并发送了确认应答分组。按照两次握手的协定，A 认为连接已经成功地建立了，可以开始发送数据分组。可是，B 在 A 的应答分组在传输中被丢失的情况下，将不知道 A 是否已准备好，不知道 A 建议什么样的序列号，B 甚至怀疑 A 是否收到自己的连接请求分组，在这种情况下，B 认为连接还未建立成功，将忽略 A 发来的任何数据分组，只等待连接确认应答分组。而 A 发出的分组超时后，重复发送同样的分组。这样就形成了死锁。  
**47.一个客户向服务器请求建立 TCP 连接。客户在 TCP 连接建立的三次握手中的最后一个报文段中捎带上一些数据，请求服务器发送一个长度为 L 字节的文件。假定：  
（1）客户和服务器之间的数据传输速率是 R 字节/秒，客户与服务器之间的往返时间是 RTT（固定值）。  
（2）服务器发送的 TCP 报文段的长度都是 M 字节，而发送窗口大小是 nM 字节。  
（3）所有传送的报文段都不会出错（无重传），客户收到服务器发来的报文段后就及时发送确认。  
（4）所有的协议首部开销都可忽略，所有确认报文段和连接建立阶段的报文段的长度都可忽略（即忽略这些报文段的发送时间）。  
试证明，从客户开始发起连接建立到接收服务器发送的整个文件多需的时间 T 是：T = 2RTT + L/R，当 nM > R(RTT) + M  
或 T= 2RTT + L/R + (K - 1)\[ M/R + RTT - nM/R\]，当 nM < R(RTT) + M  
其中，K=『L/nM』，符号『x』表示若 x 不是整数，则把 x 的整数部分加 1。  
（提示：求证的第一个等式发生在发送窗口较大的情况，可以连续把文件发送完。求证的第二个等式发生在发送窗口较小的情况，发送几个报文段后就必须停顿下来，等收到确认后再继续发送。建议先画出双方交互的时间图，然后再进行推导。）**  
答：  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 12]  
先看图（a）：  
M/R 是一个报文段的发送时间（一个报文段的长度除以数据率）  
nM 是窗口大小，nM/R 是把窗口内的数据都发送完所需要的时间。  
如果 nM/R > M/R + RTT ，那么服务器在发送窗口内的数据还没有发送完，就收到客户的确认，因此，服务器可以连续发送，直到全部数据发送完毕。  
这个不等式两边都乘以 R，就得出等效的条件：  
当 nM > R(RTT) + M 发送窗口内的数据还没有发送完就收到确认，因此，服务器可以连续发送，直到全部数据发送完毕。  
因此，客户接收全部数据所需的时间是：  
T = 2RTT + L/R，当 nM > R(RTT) +  
再看图（b）：  
当 nM > R(RTT) + M 时，服务器把发送窗口内的数据发送完毕时还收不到确认，因此必须停止发送。从图中可知，停止的时间间隔是 M/R + RTT - nM/R。  
整个文件 L 要划分为 K =『L/nM』次传送，停止的时间间隔有（K-1）个。这样就证明了求证的公式：  
T = 2RTT + L/R + (K-1)\[M/R + RTT - nM/R\]，当 nM < R(RTT) + M  
**48.网络允许的最大报文段长度为 128 字节，序号用 8 比特表示，报文段在网络中的寿命为 30 s。求发送报文段的一方所能达到的最高数据率。**  
解：根据题意，先可以做出以下一些假设：  
（1）本题不是使用 TCP 协议，因为序号字段是 8 位，而不是 TCP 的 32 位。  
（2）既然不是使用 TCP 协议，当然也不是使用 TCP 协议得到首部。现在的报文段的首部是什么样子，和我们解题没有关系。我们不用管它。我们只需要知道的是，现在的报文段的首部有一个序号字段。  
（3）显然，现在不是给报文中的每一个字节编上序号，而是给每一个报文编上序号。  
（4）报文段的传送应当使用滑动窗口协议（而不是停止等待协议），这样可得到较高的效率。  
我们知道，在使用滑动窗口协议时，在没有收到确认的情况下，8 位的序号字段可连续发送 255 个序号( 2 n − 1 2^n-1 2n−1)的报文段。  
那么一共可以发送的比特数为255×128×8=261120bit  
数据率=比特数/时间  
最高数据率=261120bit/30s=8704bit/s  
**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 码字符串的形式返回给客户。  
**50.把教材上的图 5-7 计算 UDP 检验和的例子自己具体演算一下，看是否能够得出书上的计算结果。**  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 13]可以使用两种方法进行二进制反码求和的运算。一种方法是把这 14 行的 16 位数据一起从低位到高位逐位相加。另一种方法是把这 14 行的 16 位数据两行两行地相加（即二进制反码求和）  
我们这里使用后一种方法，这里要相加 13 次。  
第 1 行和 第 2 行相加，得 10100001 01111011  
再和第 3 行相加，得 1 01001100 011111110。请注意，最左边（最高位）的 1 是进位得到的 1，这要和最低位相加。因此和第 3 行相加后，得 01001100 01111111。最低位的 1 就是由最高位的进位得到的。这叫做 “回卷”。  
再和第 4 行相加，得 01011010 10001010。  
再和第 5 行相加，得 01011010 10011011。  
再和第 6 行相加，得 01011010 10101010。  
再和第 7 行相加，得 01011110 11101001。  
再和第 8 行相加，得 01011110 11110110。  
再和第 9 行相加，得 01011111 00000101。  
第 10 行是全 0，不用再计算相加。  
再和第 11 行相加，得 10110011 01001010。  
再和第 12 行相加，得 00000110 10011111。这里的最低位的 1 由最高位的进位回卷得到的。  
再和第 13 行相加，得 01001111 11101101。  
再和第 14 行相加，得 10010110 11101101。这就是二进制反码求和的结果。把这个结果求反码（1 换成 0 而 0 换成 1），得出：01101001 00010010。这就是应当写在检验和字段的数。和书上给出的结果是一致的。  
UDP 用户数据报传送到接收端后，再进行检验和计算。这就是把收到的 UDP 用户数据报连同伪首部（以及可能的填充全零字节）一起，按二进制反码求这些 16 位字的和。当无差错时其结果应当全 1。否则就表明有差错出现，接收方就应丢弃这个 UDP 用户数据报（也可以上交应用层，但附上出现差错的警告）。  
**51.在以下几种情况下，UDP 的检验和在发送时数值分别是多少？  
（1）发送方决定不使用检验和。  
（2）发送方使用检验和，检验和的数值是全 1。  
（3）发送方使用检验和，检验和的数值是全 0。**  
答：（1）UDP 规定，UDP 的上层用户可以关闭检验和的计算（即在 UDP 的传送过程中，不使用检验和这个检错功能）。这样做的好处是可以提高 UDP 的传送速度（但要牺牲一些可靠性）。如果发送方决定不使用检验和，那么发送方的检验和的值应当置为全 0。这表示这个数值不是计算出来的，而是发送方关闭了检验和这个功能。  
（2）如果发送方使用检验和，但检验和的数值是全 1。  
我们可以想一想，怎么会出现这种情况。如果计算检验和最后的结果是全 1，就表明得出这个结果的前一个步骤（即二进制反码求和）的结果是全 0。在什么情况下，伪首部和整个 UDP 按 16 位字进行二进制反码求和的结果是全 0 ？这就是伪首部和整个 UDP 的所有字段都是 0。但很明显，这是不可能的。所有的地址和数据都是 0，还有什么意义？不要以为两个 1 相加就是 0。不对。两个 1 相加按二进制反码求和的结果是 1 0。这里的 1 是进位。因为此按照计算检验和的规矩来计算，对真实的 UDP 用户数据报不可能得出检验和的数值是全 1。  
但是，计算检验和时的倒数第二步，即按二进制反码求和的结果却有可能是全 1。在这种情况下，最后一步求反码，就会得出检验和是全 0。但是前面我们已经讲过，检验和置为全 0是表示发送方不使用检验和。这样就产生了疑问：如果检验和是全 0，是发送方不使用检验和？还是使用了检验和但检验和的结果碰巧全是 0？无法确定。于是 UDP 协议就规定：如果计算检验和的结果刚好是全 0，那么就把它人为的置为全 1。因为前面已经讲过，全 1 的检验和是不可能由计算出来的。因此接收方一旦收到检验和为全 1 的 UDP 用户数据报，就知道这是人为的，真正地检验和其实是全 0。  
（3）发送方使用检验和，检验和的数值是全 0。  
前面已经讲过，这是不可能的。如果发送方计算出来的检验和是全 0，那也要把它变成全 1 再发送出去。  
**52.UDP 和 IP 的不可靠程度是否相同? 请加以解释。**  
答：① UDP 和 IP 都是无连接的协议和不可靠传输的协议。UDP 用户数据报和 IP 数据报的首部都有检验和字段。当检验出现差错时，就把收到的 UDP 用户数据报或 IP 数据报丢弃。这是它们的相同之处。  
② 但 UDP 和 IP 的可靠性是有些区别的。UDP 用户数据报的检验和是既检验 UDP 用户数据报的首部又检验整个的 UDP 用户数据报的数据部分，而 IP 数据报的检验和仅仅检验 IP 数据报的首部。UDP 用户数据报的检验和还增加了伪首部，即还检验了下面的 IP 数据报的源 IP 地址和目的 IP 地址。  
**53.UDP 用户数据报的最小长度是多少？用最小长度的 UDP 用户数据报构成的最短 IP 数据报的长度是多少？**  
答：UDP 用户数据报的最小长度是 8 字节，即仅有首部而没有数据。用最小长度的 UDP 源用户数据报构成的最短 IP 数据报的长度为 28 字节。此 IP 数据报具有 20 字节的固定首部，首部中没有可选字段。  
**54.某客户使用 UDP 将数据发送给一服务器，数据共 16 字节。试计算在运输层的传输效率（有用字节与总字节之比）。**  
解：UDP的数据报总长度=16+8=24字节  
传输效率=(16/24)×100%=66.7%  
**55.重做 54，但在 IP 层计算传输效率。假定 IP 首部无选项。**  
解：IP数据报总长度=24+20=44字节  
传输效率=(16/44)×100%=32.4%  
**56.重做 54，但在数据链路层计算传输效率。假定 IP 首部无选项，在数据链路层使用以太网。**  
解：以太网有 14 字节的首部，4 字节的尾部（FCS 字段），发送以太网的帧之前还有 8 字节的前同步码。但其数据字段的最小长度是 46 字节，而我们的 IP 数据报仅有 44 字节，因此还必须加上 2 字节的填充。这样，以太网的总长度 = 14 + 4 + 8 + 2 + 44 = 72 字节。  
传输效率=(16/72)×100%=22.2%  
**57.某客户有 67000 字节的分组。试说明怎样使用 UDP 用户数据将这个分组进行传送。**  
答：一个 UDP 用户数据报的最大长度为 65535 字节。现在的长度超过了这个限度，因此不能使用一个 UDP 用户数据报来传送。必须进行切割（例如，分割为两个 UDP 用户数据报），使其长度不超过以上的限度。  
**58.TCP 在 4:30:20 发送了一个报文段。它没有收到确认。在 4:30:25 它重传了前面这个报文段。它在 4:30:27 收到确认。若以前的 RTT 值为 4 秒，根据 Karn 算法，新的 RTT 值为多少？**  
解：根据 Karn 算法，只要是 TCP 报文段重传了，就不采用其往返时间样本。本题中收到的确认是在重传后收到的。因此 RTT 没有变化，仍然是以前的数值（4 秒）。  
Karn算法：运输层用来控制流量算法。在计算平均往返时延 RTT 时，只要报文段重传了，就不采用其往返时延样本。这样得出的平均往返时延 RTT 和重传时间就较准确。  
**59.TCP 连接使用 1000 字节的窗口值，而上一次的确认号是 22001。它收到了一个报文段，确认号是 22401.。试用图来说明在这之前与之后的窗口情况。**  
答：在这之前和在这之后的窗口情况如下图所示。  
这里要注意的是：发送窗口为 1000 字节，窗口里面的序号也正好是 1000 个。号码小在后面，即在图的左方。另外一点要注意的是，发送方收到的确认号表示接收方期望能够收到序号。这个序号应当在发送窗口的最前面。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 14]  
**60.同上题，但在接收方收到的字节为 22401 的报文段时，其窗口字段变为 1200 字节。试用图来说明在这之前与之后的窗口情况。**  
答：在这之前与之后的窗口情况如下图所示：  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 15]  
**61.在本题中列出的 8 种情况下，画出发送窗口的变化。并标明可用窗口的位置。已知主机 A 要向主机 B 发送 3 KB 的数据。在 TCP 连接建立后，A 的发送窗口大小是 2 KB。A 的初始序号是 0。  
(1) 一开始 A 发送 1 KB的数据。  
(2) 接着 A 就一直发送数据，直到把发送窗口用完。  
(3) 发送方 A 收到对第 1000 号字节的确认报文段。  
(4) 发送方 A 再发送 850 B的数据。  
(5) 发送方 A 收到 ack = 900 的确认报文段。  
(6) 发送方 A收到对第 2047 号字节的确认报文段。  
(7) 发送方 A把剩下的数据全部都发送完。  
(8) 发送方 A 收到 ack = 3072 的确认报文段。**  
答：![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 16]  
（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 字节。【注意，因为从 1001 起，3048 - 1001 + 1 = 2048】  
（4）发送方 A 再发送 850 字节，使得可用窗口的后沿向前移动 850 字节，即移动到 2898 字节。现在的可用窗口从第 2898 字节到 3048 字节。  
（5）发送方 A 收到 ack = 900 的确认报文段，不会对其窗口状态有任何影响。这是个迟到的确认。  
（6）发送方 A 收到对第 2047 号字节的确认报文段。A 的发送窗口再向前移动。现在的发送窗口从第 2048 字节开始到第 4095 字节。可用窗口增大了，从第 2898 字节第 4095 字节。  
（7）发送方 A 把剩下的数据全部发送完。发送方 A 共有 3 KB（即 3072 字节）的数据，其编号从 0 到 3071。因此现在的可用窗口变小了，从第 3072 字节到第 4095 字节。  
（8）发送方 A 收到 ack = 3072 的确认报文段，表明序号在 3071 和这以前的报文段都收到了，后面期望收到的报文段的序号熊 3072 开始。因此新的发送窗口的位置又向前移动，从第 3072 号字节到第 5119 号字节。整个发送窗口也就是可用窗口。  
**62.TCP 连接处于 ESTABLISHED 状态。以下的事件相继发生：  
（1）收到一个 FIN 报文段。  
（2）应用程序发送 “关闭” 报文。  
在每一个事件之后，连接的状态是什么？在每一个事件之后发生的动作是什么？**  
答：（1）处于 ESTABLISHED 状态又能够收到一个 FIN 报文段，只有 TCP 的服务器端而不会是客户端。当这个服务器端收到 FIN 时，服务器就向客户端发送 ACK 报文段，并进入到 CLOSE-WAIT 状态。这是被动关闭。请注意，这时客户端不会再发送数据了，但服务器端如还有数据要发送给客户端，那么还是可以继续发送的。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 17]  
（2）应用程序发送 “关闭” 报文给服务器，表明没有数据要发送了。这时服务器就应当发送 FIN 报文段给客户，然后转换到 LAST-ACK 状态，并等待来自客户端的最后的确认。  
以上的状态转换可参考教材上的图 5-30。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 18]  
**63.TCP 连接处于 SYN-RCVD 状态。以下的事件相继发生：  
（1）应用程序发送 “关闭” 报文。  
（2）收到 FIN 报文段。  
在每一个事件之后，连接的状态是什么？在每一个事件之后发生的动作是什么？**  
答：（1）处于 SYN-RCVD 状态而又能够收到应用程序发送的 “关闭” 报文的，只有 TCP 的客户端而不会是服务器端。这时，客户端就应当向服务器端发送 FIN 报文段，然后进入到 FIN-WAIT-1 状态。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 19]  
（2）当客户收到服务器端发送的 FIN 报文段后，就向服务器发送 ACK 报文段，并进入到 CLOSED 状态。  
以上的状态转换可参考教材上的图 5-30。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 20]  
**64.TCP 连接处于 FIN-WAIT-1 状态。以下的事件相继发生：  
（1）收到 ACK 报文段。  
（2）收到 FIN 报文段。  
（3）发生了超时。  
在每一个事件之后，连接的状态是什么？在每一个事件之后发生的动作是什么？**  
答：（1）处于 FIN-WAIT-1 状态的只有 TCP 的客户。当收到 ACK 报文段后，TCP 客户不发送任何报文段，只是从 FIN-WAIT-1 状态进入到 FIN-WAIT-2 状态。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 21]  
（2）在收到 FIN 报文段后，TCP 客户发送 ACK 报文段，并进入到 TIME-WAIT 状态。  
（3）当发生了超时，也就是经过了 2 MSL时间后，TCP 客户进入到 CLOSED 状态。  
以上的状态转换可参考教材上的图 5-30。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 22]  
**65.假定主机 A 向 B 发送一个 TCP 报文段。在这个报文段中，序号是 50，而数据一共有 6 字节长。试问，在这个报文段中的确认字段是否应当写入 56？**  
答：在这个报文段中的确认字段应当写入的是B期望下次收到A发送的数据中的第一个字节的编号，而这个数值是B已经收到的数据的最后一个字节的编号加 1。然而这些在题目中并未给出。题目给出的是 A 向 B 发送的数据中第一个字节的编号是 50，并且在这个报文段中共有 6 字节的数据。这些都和此报文段中的确认字段是什么毫无关系。因此，现在我们无法知道这个报文段中的确认字段应当写入的数值。  
**66.主机 A 通过 TCP 连接向 B 发送一个很长的文件，因此这需要分成很多个报文段来发送。假定某一个 TCP 报文段的序号是 x，那么下一个报文段的序号是否就是 x + 1 呢？**  
答：假定某一个 TCP 报文段的序号是 x，那么下一个报文段的序号应当是 x+n，这里的 n 是这个报文段中的数据长度的字节数。如 n = 4000，那么下一个报文段的序号应当是 x + 4000。若此报文段中仅有一个字节的数据，则下一个报文段的序号才是 x + 1。  
**67.TCP 的吞吐量应当是每秒发送的数据字节数，还是每秒发送的首部和数据之和的字节数？吞吐量应当是每秒发送的字节数，还是每秒发送的比特数？**  
答:① TCP 的吞吐量本来并没有标准的定义，可以计入首部，也可以不计入首部，但应当说清楚。不过，从拥塞控制来看，拥塞窗口和发送窗口针对的都是 TCP 报文段中的数据字段，而重要的参数 MSS 也是指 TCP 报文段中的数据字段的长度，因此，把 TCP 的吞吐量定义为每秒发送的数据字节数是比较方便的。  
② 计算机内部的数据传送是以每秒多少字节作为单位的，而在通信线路上的数据率则常用每秒多少比特作为单位。这两种表示方法并无实质上的差别。在上面的习题中，因为 MSS 用字节作为单位，因此，用每秒发送多少字节作为 TCP 吞吐量的单位就比较简单一些。  
**68.在 TCP 的连接建立的三报文握手过程中，为什么第三个报文段不需要对方的确认？这会不会出现问题？**  
答：① 关于这个问题，还不能简单地用 “是” 或 “否” 来回答。  
② 我们假定 A 是客户端，是发起 TCP 连接建立一方。现在假定三报文握手过程中的第三个报文段（也就是 A 发送的第二个报文段 —— 确认报文）丢失了，而 A 并不知道。这是，A 以为对方收到了这个报文段，以为 TCP 连接已经建立，于是就开始发送数据报文段给 B。  
③ B 由于没有收到三报文握手中的最后一个报文段（A 发送的确认报文段），因此 B 就不能进入 TCP 的 ESTABLISHED 状态（“连接已建立” 状态）。B 的这种状态可以叫做 “半开连接” ，即仅仅把 TCP 连接打开了一半。在这种状态下，B 虽然已经初始化了连接变量和缓存，但是不能接收数据。通常，B 在经过一段时间后（例如，一分钟后） ，如果还没有收到来自 A 的确认报文段，就终止这个半开连接状态，那么 A 就必须重新建立 TCP 连接。因此，在这种情况下，第三个报文段（A 发送的第二个报文段）的丢失，就导致了 TCP 连接无法建立。  
④ 但是，假定 A 在这段时间内，紧接着就发送了数据。我们知道，TCP 具有累计确认的功能。在 A 发送的数据报文段中，自己的序号也没有改变，仍然是和丢失的确认真的序号一样（丢失的那个确认帧不消耗序号），并且确认位 ACK = 1，确认号也是 B 的初始序号加 1。当 B 收到这个报文段后，从 TCP 的首部就可以知道，A 已确认了 B 刚才发送的 SYN + ACK 报文段，于是就进入了 ESTABLISHED 状态（“连接已建立” 状态）。接着，就接收 A 发送的数据。在这种情况下，A 丢失的第二个报文段对 TCP 的连接建立就没有影响。  
⑤ 大家知道，A 在发送第二个报文段时，可以有两种选择：  
（1）仅仅是确认而不携带数据，数据接着在后面发送。  
（2）不仅是确认，而且携带上自己的数据。  
⑥ 在第一种选择时，A 在下一个报文段发送自己的数据。但下一个报文的首部中仍然包括了对 B 的 SYN + ACK 报文段的确认，即和第二种选择发送的报文段一样。  
⑦ 在第二种选择时，A 省略了单独发送一个确认报文段。  
从这里也可以看出，A 发送的第二个仅仅是确认的报文段，是个可以省略的报文段，即使丢失了也无妨，只要下面紧接着就可以发送数据报文段即可。  
**69.现在假定使用类似 TCP 的协议（即使用滑动窗口可靠传送字节流），数据传输速率是 1 Gbit/s，而网络的往返时间 RTT = 140 ms。假定报文段的最大生存时间是 60 秒。如果要尽可能快的传送数据，在我们的通信协议的首部中，发送窗口和序号字段至少各应当设为多大？**  
解：发送窗口至少能够容纳的比特数=传输速率×RTT=1Gbit/s × 140ms=1.75× 1 0 7 10^7 107bit  
我们知道，每一个字节的数据需要有一个编号。假定发送窗口一共有 w 位，那么总的号码数应当大于1.75× 1 0 7 10^7 107字节，即： 2 w 2^w 2w>17500000，那么w>24.06，那么发送窗口至少为25位。  
可见只用 24 位的发送窗口差一点，必须使用 w = 25 位的发送窗口才行。TCP 的窗口字段为 16 位。  
再看看 60 秒钟以1Gbit/s 的速率可以发送 60s× 1 0 9 10^9 109bit/s=7.5× 1 0 9 10^9 109字节的数据。  
假定需要 n 位的序号字段，那么总的序号数应当大于 7.5× 1 0 9 10^9 109字节，即：  
 2 n 2^n 2n > 7.5 ×  1 0 9 10^9 109,求得n=32.8  
因此，取序号字段长度 n = 33 位即可保证在报文段的最大生产时间内没有重复的序号。但TCP 的序号字段为 32 位(因为TCP的序号字段范围是0~32位)。  
**70.假定用 TCP 协议在 40 Gbit/s 的线路上传送数据。  
（1）如果 TCP 充分利用了线路的带宽，那么需要多长的时间 TCP 会发生序号绕回？  
（2）假定现在 TCP 的首部中采用了时间戳选项。时间戳占用了 4 字节，共 32 位。每隔一定的时间（这段时间叫做一个滴答）时间戳的数值加 1。假定设计的时间戳是每隔 859 微秒，时间戳的数值加 1。试问要经过多长时间才发生时间戳数值的绕回。**  
解：(1)40Gbit/s的线路上每秒可以传送5× 1 0 9 10^9 109个字节。TCP序号共有 2 32 2^\{32\} 232个。那么需要经过 2 32 2^\{32\} 232/ 5 × 1 0 9 5×10^9 5×109=0.859s就会发生TCP序号绕回。  
(2)时间戳绕回时间： 2 3 2 2^32 232×0.000859s=3.69× 1 0 6 10^6 106=42.7天。  
**71. 5.5 节中指出：例如，若用 2.5 Gbit/s 速率发送报文段，则不到 14 秒钟序号就会重复。请计算验证这句话。**  
证明：2.5Gbit/s的速率，那么每秒就可以发送0.3125× 1 0 9 10^9 109个字节，一共有 2 32 2^\{32\} 232个序号， 2 32 2^\{32\} 232/0.3125× 1 0 9 10^9 109=13.74S。所以这不到14秒，TCP序号就会发生绕回。  
**72.已知 TCP 的接收窗口大小是 600（单位是字节，为简单起见以后就省略了单位），已经确认了的序号是 300。试问，在不断的接收报文段和发送确认报文段的过程中，接收窗口也可能会发生变化（增大或缩小）。请用具体的例子（指出接收方发送的确认报文段中的重要信息）来说明哪些情况是可能发生的，而哪些情况是不允许发的。**  
答：![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 23]  
（1）这是题目开始的情况。接收方发送的确认报文段中的接收窗口 rwnd = 600。已确认的序号是 300。接收方发送的确认报文段的 ack = 301，表示期望收到开始的序号为 301 的数据。我们看到，序号 301 到 900 都在接收窗口内。  
（2）接收窗口增大总是不受限制的。这就是说，只要接收端的 TCP 能够拿出更多的空间来接收发来的数据，就可以这样做。图中给出的例子是：已确认的序号是 400，接收方发送的确认报文段为 ack = 401。假定现在接收窗口从情况（1）的 600 增大到了 700，即 rwnd = 700。现在接收窗口的范围是从 401 到 1100。当接收窗口增大时，接收窗口的前沿总是向前移动的。  
（3）这种情况是接收窗口变小了，但接收窗口的前沿没有变化。例如，现在的已确认的序号是 400，接收方发送的确认报文段的 ack = 401。假定现在接收窗口从情况（1）的 600 减少到了 500，即 rwnd = 500。接收窗口的范围是从 501 到 1000。  
（4）这种情况是接收窗口变小了，同时接收窗口的前言页向前移动了。例如，现在已确认的序号是 500，接收方发送的确认报文段的 ack = 501。假定现在接收窗口从情况 (1) 的 600 减少到了 500，即 rwnd = 500。接收窗口的范围是从 501 到 1000。  
（5）这种情况是接收窗口变小了，但接收窗口的前沿是后退的。例如，现在已确认的序号是 500，接收方发送的确认报文段的 ack = 501。假定现在接收窗口从情况（1）的 600 减小到了 300，即 rwnd = 300。接收窗口的范围是从 501 到800。但请注意，这种情况是不允许出现的。也就是说，接收窗口的前沿是不允许后退的。在开始时，接收窗口的前沿的编号是 900。不管是接收窗口是变大还是变小，这个窗口的前沿的编号可以不动，也可以前移，但是不允许后退。  
为什么不允许出现这种情况呢？可以先观察一下发送方的情况。在一开始，发送方收到接收窗口 = 600 的报文段后（其中 ack = 301），发送方就把发送窗口设置为 600，可以发送的数据的序号从 301 到 900。假定发送方发送了在发送窗口内的全部数据。这本来正好落入到接收窗口之内。但这些数据正在网络中传输时，接收方却缩小了接收窗口，只接收序号从 501 到 800 之间的数据。这就导致最后的一些数据（编号从 801 到 900）落入接收窗口之外，使得接收方只能丢弃这些数据（编号从 801 到 900）。因此，这种情况（在发送时数据是在发送窗口之内，但到达接收端，这些数据却落入到接收窗口之外）必须避免。总之，我们要记住，接收窗口是不允许后退的。  
**73.在上题中，如果接收方突然因某种原因不能够再接收数据了，可以立即向发送方发送把接收窗口置为零的报文段（即 rwnd = 0）。这时会导致接收窗口的前沿后退。试问这种情况是否允许？**  
答：这种情况是允许的。当发送方收到这样的信息，并不是把发送窗口缩回到零，而是立即停止发送。什么时候可以再发送数据，就要等接收方重新开放接收窗口，即给出一个非零的接收窗口。  
**74.流量控制和拥塞控制的最主要的区别是什么？发送窗口的大小取决于流量控制还是拥塞控制？**  
简单地说，流量控制是在一条 TCP 连接中的接收端才用的措施，用来限制对方（发送端）发送报文的速率，以免在接收端来不及接收。流量控制只控制一个发送端。  
拥塞控制是用来控制 TCP 连接中发送端发送报文段的速率，以免使互联网中的某处产生过载。拥塞控制可能会同时控制许多个发送端，限制它们的发送速率。不过每一个发送端只知道自己应当怎样调整发送速率，而不知道在互联网中还有哪些主机被限制了发送速率。  
我们知道，发送窗口的上限值是 Min \[rwnd, cwnd\]，即发送窗口的数值不能超过接收窗口和拥塞窗口中娇小的一个。接收窗口的大小体现了接收端对发送端施加的流量控制，而拥塞窗口的大小则是整个互联网的负载情况对发送端施加的拥塞控制。因此，当接收窗口小于拥塞窗口时，发送窗口的大小取决于流量控制，即取决于接收端的接收能力。但当拥塞窗口小于接收窗口时，则发送窗口的大小取决于拥塞控制，即取决于整个网络的拥塞状况。

[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16]: https://img-blog.csdnimg.cn/5a702f78278e46cb97bcd727b49f6e77.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA54ix5qCX5Yib,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 1]: https://img-blog.csdnimg.cn/98176c0cc96649d984c1528911f8aab6.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA54ix5qCX5Yib,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 2]: https://img-blog.csdnimg.cn/e7642d37edea4d858fc82e72a1905e57.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA54ix5qCX5Yib,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 3]: https://img-blog.csdnimg.cn/9ebd990d207c456e846880ca97a2ff2c.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA54ix5qCX5Yib,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 4]: https://img-blog.csdnimg.cn/4d9beefe27754db4a5993e363f7c28be.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA54ix5qCX5Yib,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 5]: https://img-blog.csdnimg.cn/032d67be8f12470999889cafd53976b6.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA54ix5qCX5Yib,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 6]: https://img-blog.csdnimg.cn/0beccd509d844bce9ec3d57d8639961a.jpg?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA54ix5qCX5Yib,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 7]: https://img-blog.csdnimg.cn/fc853f1fc3644b8bba00c9e93c876627.jpg?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA54ix5qCX5Yib,size_20,color_FFFFFF,t_70,g_se,x_16
[af649358836844d1a341ad5e895f7da7.png]: https://img-blog.csdnimg.cn/af649358836844d1a341ad5e895f7da7.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 8]: https://img-blog.csdnimg.cn/d3dc0b88a79e40c3ad30dc29c8de5a33.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA54ix5qCX5Yib,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 9]: https://img-blog.csdnimg.cn/7778de9cc0c4440d9ff661eaabbe4091.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA54ix5qCX5Yib,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 10]: https://img-blog.csdnimg.cn/8c18153c3026484997ea504273015cf5.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA54ix5qCX5Yib,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 11]: https://img-blog.csdnimg.cn/202338aa41794d228fcc0618a9635d64.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA54ix5qCX5Yib,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 12]: https://img-blog.csdnimg.cn/9f00628c53604b36a143d48527dcc363.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA54ix5qCX5Yib,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 13]: https://img-blog.csdnimg.cn/e057c07291a64336b75cf23eaf51de19.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA54ix5qCX5Yib,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 14]: https://img-blog.csdnimg.cn/4c65ee75edd64b2d853c8733a7299fc9.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA54ix5qCX5Yib,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 15]: https://img-blog.csdnimg.cn/24e7d886f85d4ee8b6b61ec9714ef5ae.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA54ix5qCX5Yib,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 16]: https://img-blog.csdnimg.cn/b8d1486351894d54b286a929d1e245ea.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA54ix5qCX5Yib,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 17]: https://img-blog.csdnimg.cn/43fa92c1253a487cbf7211b77c152d01.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA54ix5qCX5Yib,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 18]: https://img-blog.csdnimg.cn/98236c4690e941d398251f9a2bc77841.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA54ix5qCX5Yib,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 19]: https://img-blog.csdnimg.cn/b3ab1f6e41164c98bc31f5313917c214.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA54ix5qCX5Yib,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 20]: https://img-blog.csdnimg.cn/77d981988e5d401ebb529b3025b2e5ba.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA54ix5qCX5Yib,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 21]: https://img-blog.csdnimg.cn/4bd01a9dd4ae4d50a3f118ededf87390.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA54ix5qCX5Yib,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 22]: https://img-blog.csdnimg.cn/bb4d777125d14149af7ac6255d3df9c3.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA54ix5qCX5Yib,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA54ix5qCX5Yib_size_20_color_FFFFFF_t_70_g_se_x_16 23]: https://img-blog.csdnimg.cn/29a9b6330cd1467594f99550c8b53a7c.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA54ix5qCX5Yib,size_20,color_FFFFFF,t_70,g_se,x_16