1. 试说明运输层在协议栈中的地位和作用，运输层的通信和网络层的通信有什么重要区别？为什么运输层是必不可少的？
运输层处于面向通信部分的最高层，同时也是用户功能中的最低层，向它上面的应用层提供服务。运输层为应用进程之间提供端到端的逻辑通信，但网络层是为主机之间提供逻辑通信（面向主机，承担路由功能，即主机寻址及有效的分组交换）。 各种应用进程之间通信需要“可靠或尽力而为”的两类服务质量，必须由运输层以复用和分用的形式加载到网络层。
2.网络层提供数据报或虚电路服务对上面的运输层有何影响？
网络层提供数据报或虚电路服务不影响上面的运输层的运行机制。 但提供不同的服务质量。
3.当应用程序使用面向连接的 TCP 和无连接的 IP 时，这种传输是面向连接的还是面向无连接的？
都是。这要在不同层次来看，在运输层是面向连接的，在网络层则是无连接的。
4.试用画图解释运输层的复用。画图说明许多个运输用户复用到一条运输连接上，而这条运输连接有复用到IP数据报上。
5.试举例说明有些应用程序愿意采用不可靠的 UDP，而不用采用可靠的 TCP。
VOIP：由于语音信息具有一定的冗余度，人耳对 VOIP 数据报损失由一定的承受度，但对传输时延的变化较敏感。有差错的 UDP 数据报在接收端被直接抛弃，TCP 数据报出错则会引起重传，可能带来较大的时延扰动。因此 VOIP 宁可采用不可靠的 UDP，而不愿意采用可靠的 TCP。
原理：有差错的数据报 UDP 直接丢弃，而 TCP 则要求重传，TCP 会带来较大的时延
此外还有 DNS、SNMP 等都采用不可靠的 UDP 协议，而不愿意采用可靠的 TCP。
6.接收方收到有差错的 UDP 用户数据报时应如何处理
简单地丢弃
7.如果应用程序愿意使用 UDP 来完成可靠的传输，这可能吗？请说明理由。
可能，但应用程序中必须额外提供与 TCP 相同的功能
8.为什么说 UDP 是面向报文的，而 TCP 是面向字节流的？
① 发送方 UDP 对应用程序交下来的报文，在添加首部后就向下交付 IP 层。UDP 对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。接收方 UDP 对 IP 层交上来的 UDP 用户数据报，在去除首部后就原封不动地交付上层的应用进程，一次交付一个完整的报文。发送方 TCP 对应用程序交下来的报文数据块，视为无结构的字节流（无边界约束，课分拆/合并），但维持各字节。
② UDP 是面向报文的：发送方的 UDP 对应用程序交下来的报文，在添加了首部之后就向下交付，UDP 对应用层交付下来的报文即不合并也不拆分，而是保留这些报文的边界，应用层交给 UDP 多长的报文，UDP 就照样发送，即一次发送一个报文，接收方 UDP 对下方交上来的 UDP 用户数据报，在去除首部之后就原封不动的交付给上层的应用程序，一次交付一个完整报文，所以是 UDP 是面向报文的
③ TCP 是面向字节的：发送方 TCP 对应用程序交下来的报文数据块，视为无结构的字节流（无边界约束，可拆分/合并），但维持各字节流顺序（相对顺序没有变），TCP发送方有一个发送缓冲区，当应用程序传输的数据块太长，TCP 就可以把它划分端一些再传输，如果应用程序一次只传输一个字节，那么 TCP 可以等待积累足够多的字节后再构成报文端发送出去，所以 TCP 的面向字节的
9.端口的作用是什么？为什么端口要划分为三种？
端口的作用是对 TCP/IP 体系的应用进程进行统一的标志，使运行不同操作系统的计算机的应用进程能够互相通信。
熟知端口号：数值一般为 0~1023，标记常规的服务进程如 FTP 是 21，DNS 是 53，HTTP 是 80 等
登记端口号：数值为 1024~49151，标记没有熟知端口号的非常规的服务进程
短暂端口号：数值为 49152~65535，客户进程运行时动态选择
把端口划分为 3 类是因为：避免端口号重复，无法区分应用进程。二是因特网上的计算机通信都是采用 C/S 方式，在客户发起通信请求时，必须知道服务器的端口，对应一些重要的应用程序，必须让所有用户知道。
10.试说明运输层中伪首部的作用。
用于计算运输层数据报校验和。
伪首部(pseudo header)，通常有 TCP 伪首部和 UDP 伪首部。在 UDP 伪首部中，包含 32 位源 IP 地址，32 位目的 IP 地址，8 位协议，16 位 UDP 长度。通过伪首部的校验，UDP 可以确定该数据报是不是发给本机的，通过首部协议字段，UDP 可以确认有没有误传。
11.某个应用进程使用运输层的用户数据报 UDP，然而继续向下交给 IP 层后，又封装成 IP 数据报。既然都是数据报，可否跳过 UDP 而直接交给IP层？哪些功能 UDP 提供了但 IP 没提提供？
IP数据报只能找到目的主机而无法找到目的进程。UDP 提供对应用层的复用和分用功能，并提供对数据部分的差错检验。
12.一个应用程序用 UDP，到 IP 层把数据报在划分为 4 个数据报片发送出去，结果前两个数据报片丢失，后两个到达目的站。过了一段时间应用程序重传 UDP，而 IP 层仍然划分为 4 个数据报片来传送。结果这次前两个到达目的站而后两个丢失。试问：在目的站能否将这两次传输的 4 个数据报片组装成完整的数据报？假定目的站第一次收到的后两个数据报片仍然保存在目的站的缓存中。
不行。重传时，IP 数据报的标识字段会有另一个标识符。 仅当标识符相同的 IP 数据报片才能组装成一个 IP 数据报。前两个 IP 数据报片的标识符与后两个 IP 数据报片的标识符不同，因此不能组装成一个IP数据报。
13.一个 UDP 用户数据的数据字段为 8192 字节。在数据链路层要使用以太网来传送。试问应当划分为几个 IP 数据报片？说明每一个 IP 数据报字段长度和片偏移字段的值。
UDP 用户数据报的长度 = 8192 + 8 = 8200 B
以太网数据字段最大长度为 1500 B。若 IP 首部为 20 字节，则 IP 数据报的数据部分最多只能有 1480 B。8200=1480∗5+8008200=1480∗5+800，因此划分的数据报片共 6 个。
数据字段的长度：前 5 个是 1480字节，最后一个是 800 字节。
第 1 个数据报片的片偏移字节为 0 B；
第 2 个数据报片的片偏移字节为 1480 B。
第 3 个数据报片的片偏移字节为 2960 B。
第 4 个数据报片的片偏移字节为 4440 B。
第 5 个数据报片的片偏移字节为 5920 B。
第 6 个数据报片的片偏移字节为 7400 B。
把以上得出的片偏移字节数除以 8，就得出片偏移字段中应当填入的数值。因此最后的答案，片偏移字段的值是：0，185，370，555，740 和 925（字段数除以 8）
14.一 UDP 用户数据报的首部十六进制表示是：06 32 00 45 00 1C E2 17。试求源端口、目的端口、用户数据报的总长度、数据部分长度。这个用户数据报是从客户发送给服务器发送给客户？使用 UDP 的这个服务器程序是什么？
把首部的 8 个字节的数值写成二进制表示的数值，如下所示：
15.使用 TCP 对实时话音数据的传输有没有什么问题？使用 UDP 在传送数据文件时会有什么问题？
如果语音数据不是实时播放（边接收边播放）就可以使用 TCP，因为 TCP 传输可靠。接收端用 TCP 将话音数据接收完毕后，可以在以后的任何时间进行播放。但假定是实时传输，则必须使用 UDP。 UDP 不保证可靠交付，但 UDP 比 TCP 的开销要小很多。因此只要应用程序接收这样的服务质量就可以使用 UDP。
16.在停止等待协议中如果不使用编号是否可行？为什么？
分组和确认分组都必须进行编号，才能明确哪个分则得到了确认。
停止等待协议要点：
① 停止等待协议用于通信系统中，两个相连的设备相互发送信息时使用，以确保信息不因丢包或包乱序而丢失，是最简单的自动重传请求方法。
只有收到序号正确的确认帧 ACKn 后，才更新发送状态变量 V(S)一次，并发送新的数据帧。
② 接收端接收到数据帧时，就要将发送序号 N(S) 与本地的接收状态变量 V®相比较。
若二者相等就表明是新的数据帧，就收下，并发送确认。否则为重复帧，就必须丢弃。但这时仍须向发送端发送确认帧 ACKn，而接收状态变量V®和确认序号 n 都不变。
连续出现相同发送序号的数据帧，表明发送端进行了超时重传。连续出现相同序号的确认帧，表明接收端收到了重复帧。
③ 发送端在发送完数据帧时，必须在其发送缓存中暂时保留这个数据帧的副本。这样才能在出差错时进行重传。只有确认对方已经收到这个数据帧时，才可以清除这个副本。
实用的CRC 检验器都是用硬件完成的。
④ CRC 检验器能够自动丢弃检测到的出错帧。因此所谓的“丢弃出错帧”，对上层软件或用户来说都是感觉不到的。
发送端对出错的数据帧进行重传是自动进行的，因而这种差错控制体制常简称为ARQ(Automatic Repeat reQuest)，直译是自动重传请求，但意思是自动请求重传。
17.在停止等待协议中，如果收到重复的报文段时不予理睬（即悄悄地丢弃它而其他什么也没做）是否可行？试举出具体的例子说明理由。
19.试证明：当用 n 比特进行分组的编号时，若接收到窗口等于 1（即只能按序接收分组），当仅在发送窗口不超过 2n−12 n −1 时，连接 ARQ 协议才能正确运行。窗口单位是分组。
20.
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 连续发送了两个 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 就能发送一个窗口的数据。
25.为什么在 TCP 首部中要把 TCP 端口号放入最开始的 4 个字节？
在 ICMP 的差错报文中要包含 IP 首部后面的8个字节的内容，而这里面有 TCP 首部中的源端口和目的端口。当 TCP 收到 ICMP 差错报文时需要用这两个端口来确定是哪条连接出了差错。
26.为什么在 TCP 首部中有一个首部长度字段，而 UDP 的首部中就没有这个这个字段？
TCP 首部除固定长度部分外，还有选项，因此 TCP 首部长度是可变的。UDP 首部长度是固定的。
27.一个 TCP 报文段的数据部分最多为多少个字节？为什么？如果用户要传送的数据的字节长度超过 TCP 报文字段中的序号字段可能编出的最大序号，问还能否用 TCP 来传送？
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，问所能得到的最大吞吐量是多少?
32.什么是 Karn 算法?在 TCP 的重传机制中，若不采用 Karn 算法，而是在收到确认时都认为是对重传报文段的确认，那么由此得出的往返时延样本和重传时间都会偏小。试问：重传时间最后会减小到什么程度?
Karn 算法允许 TCP 能够区分开有效的和无效的往返时间样本，从而改进往返时间的估算。
若不采用 Karn 算法，而是在收到确认时都认为是对重传报文段的确认，那么由此得出的往返时间样本和重传时间都会偏小。如下图所示，TCP 发送了报文段后，没有收到确认，于是超时重传报文段。但刚刚重传了报文段后，马上就收到了确认。显然，这个确认是对原来发送的报文段的确认。
但是，根据题意，我们就认为这个确认是对重传的报文段的确认。这样得出的往返时间就会很小。这样的往返时间最后甚至可以减小到很接近于零、
因此，上述的这种做法是不可取的
33.假定 TCP 在开始建立连接时，发送方设定超时重传时间是 RTO = 6 s。
（1）当发送方接到对方的连接确认报文段时，测量出 RTT 样本值为 1.5 s。试计算现在的 RTO 值。
（2）当发送方发送数据报文段并接收到确认时，测量出RTT样本值为 2.5 s。试计算现在的 RTO 值。
34.已知第一次测得 TCP 的往返时延的当前值 RTT 是 30 ms。现在收到了三个接连的确认报文段，它们比相应的数据报文段的发送时间分别滞后的时间是：26 ms，32 ms 和24 ms。设 α = 0.1。试计算每一次的新的加权平均往返时间值 RTTSRTT S 。讨论所得出的结果。
35.试计算一个包括 5 段链路的运输连接的单程端到端时延。5 段链路程中有 2 段是卫星链路，有 3 段是广域网链路。每条卫星链路又由上行链路和下行链路两部分组成。可以取这两部分的传播时延之和为 250 ms。每一个广域网的范围为 1500 km，其传播时延可按 150000 km/s 来计算。各数据链路速率为 48 kb/s，帧长为 960 位。
36.重复 35 题，但假定其中的一个陆地上的广域网的传输时延为 150 ms。
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 次传输的各拥塞窗口大小。你能说明拥塞控制窗口每一次变化的原因吗？
拥塞窗口大小及变化原因见下表：
注解：
依照原理，首先执行 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 的关系如表 5.1 所示：
（1）试画出如教材中图 5-25 所示的拥塞窗口与传输轮次的关系曲线。
（2）指明 TCP 工作在慢开始阶段的时间间隔。
（3）指明 TCP 工作在拥塞避免阶段的时间间隔。
（4）在第 16 轮次和第 22 轮次之后发送方是通过收到三个重复的确认还是通过超时检测到丢失了报文段？
（5）在第 1 轮次，第 18 轮次和第 24 轮次发送时，门限 ssthresh 分别被设置为多大？
（6）在第几轮次发送出第 70 个报文段？
（7）假定在第 26 轮次之后收到了三个重复的确认，因而检测出了报文段的丢失，那么拥塞窗口 cwnd 和门限 ssthresh 应设置为多大？
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 状态。
【----- 三报文握手完成 -----】
【----- 开始数据传送 -----】
报文段 #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 这一信息）
如果 B 不再发送数据了，是可以把两个报文段合并成为一个，即只发送 FIN+ACK 报文段。但如果 B 还有数据报要发送，而且要发送一段时间，那就不行，因为 A 迟迟收不到确认，就会以为刚才发送的 FIN 报文段丢失了，就超时重传这个 FIN 报文段，浪费网络资源。
43.在图 5-30 中，在什么情况下会发生从状态 SYN-SENT 到状态 SYN-RCVD 的变迁？
当 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。
（提示：求证的第一个等式发生在发送窗口较大的情况，可以连续把文件发送完。求证的第二个等式发生在发送窗口较小的情况，发送几个报文段后就必须停顿下来，等收到确认后再继续发送。建议先画出双方交互的时间图，然后再进行推导。）
先看图（a）：
M/R 是一个报文段的发送时间（一个报文段的长度除以数据率）
nM 是窗口大小，nM/R 是把窗口内的数据都发送完所需要的时间。
如果 nM/R > M/R + RTT ，那么服务器在发送窗口内的数据还没有发送完，就收到客户的确认，因此，服务器可以连续发送，直到全部数据发送完毕。
这个不等式两边都乘以 R，就得出等效的条件：
当 nM > R(RTT) + M 发送窗口内的数据还没有发送完就收到确认，因此，服务器可以连续发送，直到全部数据发送完毕。
因此，客户接收全部数据所需的时间是：
T = 2RTT + L/R，当 nM > R(RTT) + M
再看图（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）报文段的传送应当使用滑动窗口协议（而不是停止等待协议），这样可得到较高的效率。
49.下面是以十六进制格式存储的一个 UDP 首部：
CB84000D001C001C
试问:
(1) 源端口号是什么？
(2) 目的端口号是什么？
(3) 这个用户数据报的总长度是什么？
(4) 数据长度是多少？
(5)这个分组是从客户到服务器还是从服务器到客户？
(6) 客户进程是什么
50.把教材上的图 5-7 计算 UDP 检验和的例子自己具体演算一下，看是否能够得出书上的计算结果。
可以使用两种方法进行二进制反码求和的运算。一种方法是把这 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 字节。试计算在运输层的传输效率（有用字节与总字节之比）。
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 个。号码小在后面，即在图的左方。另外一点要注意的是，发送方收到的确认号表示接收方期望能够收到序号。这个序号应当在发送窗口的最前面。
60.同上题，但在接收方收到的字节为 22401 的报文段时，其窗口字段变为 1200 字节。试用图来说明在这之前与之后的窗口情况
在这之前与之后的窗口情况如下图所示：
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 的确认报文段。
下图是发送窗口和可用窗口的变化情况。
（1）我们应当注意到，发送窗口 = 2 KB 就是 2∗1024=20482∗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 状态。这是被动关闭。请注意，这时客户端不会再发送数据了，但服务器端如还有数据要发送给客户端，那么还是可以继续发送的。
（2）应用程序发送 “关闭” 报文给服务器，表明没有数据要发送了。这时服务器就应当发送 FIN 报文段给客户，然后转换到 LAST-ACK 状态，并等待来自客户端的最后的确认。
以上的状态转换可参考教材上的图 5-30。
63.TCP 连接处于 SYN-RCVD 状态。以下的事件相继发生：
（1）应用程序发送 “关闭” 报文
（2）收到 FIN 报文段
在每一个事件之后，连接的状态是什么？在每一个事件之后发生的动作是什么？
（1）处于 SYN-RCVD 状态而又能够收到应用程序发送的 “关闭” 报文的，只有 TCP 的客户端而不会是服务器端。这时，客户端就应当向服务器端发送 FIN 报文段，然后进入到 FIN-WAIT-1 状态。
（2）当客户收到服务器端发送的 FIN 报文段后，就向服务器发送 ACK 报文段，并进入到 CLOSED 状态。
以上的状态转换可参考教材上的图 5-30。
64.TCP 连接处于 FIN-WAIT-1 状态。以下的事件相继发生：
（1）收到 ACK 报文段
（2）收到 FIN 报文段
（3）发生了超时
在每一个事件之后，连接的状态是什么？在每一个事件之后发生的动作是什么？
（1）处于 FIN-WAIT-1 状态的只有 TCP 的客户。当收到 ACK 报文段后，TCP 客户不发送任何报文段，只是从 FIN-WAIT-1 状态进入到 FIN-WAIT-2 状态。
（2）在收到 FIN 报文段后，TCP 客户发送 ACK 报文段，并进入到 TIME-WAIT 状态。
（3）当发生了超时，也就是经过了 2 MSL时间后，TCP 客户进入到 CLOSED 状态。
以上的状态转换可参考教材上的图 5-30。
65.假定主机 A 向 B 发送一个 TCP 报文段。在这个报文段中，序号是 50，而数据一共有 6 字节长。试问，在这个报文段中的确认字段是否应当写入 56？
在这个报文段中的确认字段应当写入的是 A 期望下次收到 B 发送的数据中的第一个字节的编号，而这个数值是 A 已经收到的数据的最后一个字节的编号加 1。然而这些在题目中并未给出。题目给出的是 A 向 B 发送的数据中第一个字节的编号是 50，并且在这个报文段中共有 6 字节的数据。这些都和此报文段中的确认字段是什么毫无关系。因此，现在我们无法知道这个报文段中的确认字段应当写入的数值。
66.主机 A 通过 TCP 连接向 B 发送一个很长的文件，因此这需要分成很多个报文段来发送。假定某一个 TCP 报文段的序号是 x，那么下一个报文段的序号是否就是 x + 1 呢？
假定某一个 TCP 报文段的序号是 x，那么下一个报文段的序号应当是 x+n，这里的 n 是这个报文段中的数据长度的字节数。如 n = 4000，那么下一个报文段的序号应当是 x + 400。若此报文段中仅有一个字节的数据，则下一个报文段的序号才是 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 秒。如果要尽可能快的传送数据，在我们的通信协议的首部中，发送窗口和序号字段至少各应当设为多大？
70.假定用 TCP 协议在 40 Gbit/s 的线路上传送数据。
（1）如果 TCP 充分利用了线路的带宽，那么需要多长的时间 TCP 会发生序号绕回？
（2）假定现在 TCP 的首部中采用了时间戳选项。时间戳占用了 4 字节，共 32 位。每隔一定的时间（这段时间叫做一个滴答）时间戳的数值加 1。假定设计的时间戳是每隔 859 微秒，时间戳的数值加 1。试问要经过多长时间才发生时间戳数值的绕回。
77.在教材上 5.5 节中指出：例如，若用 2.5 Gbit/s 速率发送报文段，则不到 14 秒钟序号就会重复。请计算验证这句话。
72.已知 TCP 的接收窗口大小是 600（单位是字节，为简单起见以后就省略了单位），已经确认了的序号是 300。试问，在不断的接收报文段和发送确认报文段的过程中，接收窗口也可能会发生变化（增大或缩小）。请用具体的例子（指出接收方发送的确认报文段中的重要信息）来说明哪些情况是可能发生的，而哪些情况是不允许发的。
（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）。因此，这种情况（在发送时数据是在发送窗口之内，但到达接收端，这些数据却落入到接收窗口之外）必须避免。总之，我们要记住，接收窗口是不允许后退的。
74.在上题中，如果接收方突然因某种原因不能够再接收数据了，可以立即向发送方发送把接收窗口置为零的报文段（即 rwnd = 0）。这时会导致接收窗口的前沿后退。试问这种情况是否允许？
这种情况是允许的。当发送方收到这样的信息，并不是把发送窗口缩回到零，而是立即停止发送。什么时候可以再发送数据，就要等接收方重新开放接收窗口，即给出一个非零的接收窗口。
74.流量控制和拥塞控制的最主要的区别是什么？发送窗口的大小取决于流量控制还是拥塞控制？
简单地说，流量控制是在一条 TCP 连接中的接收端才用的措施，用来限制对方（发送端）发送报文的速率，以免在接收端来不及接收。流量控制只控制一个发送端。
拥塞控制是用来控制 TCP 连接中发送端发送报文段的速率，以免使互联网中的某处产生过载。拥塞控制可能会同时控制许多个发送端，限制它们的发送速率。不过每一个发送端只知道自己应当怎样调整发送速率，而不知道在互联网中还有哪些主机被限制了发送速率。
我们知道，发送窗口的上限值是 Min [rwnd, cwnd]，即发送窗口的数值不能超过接收窗口和拥塞窗口中娇小的一个。接收窗口的大小体现了接收端对发送端施加的流量控制，而拥塞窗口的大小则是整个互联网的负载情况对发送端施加的拥塞控制。因此，当接收窗口小于拥塞窗口时，发送窗口的大小取决于流量控制，即取决于接收端的接收能力。但当拥塞窗口小于接收窗口时，则发送窗口的大小取决于拥塞控制，即取决于整个网络的拥塞状况。
75.假定在 TCP 连接中刚刚收到的最新的往返时间 RTT 1 秒，那么超时重传时间 RTO 是否当设置成大于或等于 1 秒？
这不一定。超时重传时间 RTO 应当根据教材上的公式（5-4）和（5-5）来计算，而不是根据某一个 RTT 样本来计算。如果仅根据一个 RTT 样本就确定了超时重传时间 RTO，那么 RTO 的数值就可能会经常大幅度地波动。这就会使超时重传时间 RTO 的数值很不准确，使 TCP 的传输性能变坏。