第五章、运输层

本章的习题

试说明运输层在协议栈中的地位和作用，运输层的通信和网络层的通信有什么重要区别？为什么运输层是必不可少的？
运输层处于面向通信部分的最高层，同时也是用户功能中的最低层，向它上面的应用层提供服务。运输层为应用进程之间提供端到端的逻辑通信，但网络层是为主机之间提供逻辑通信（面向主机，承担路由功能，即主机寻址及有效的分组交换）。各种应用进程之间通信需要“可靠或尽力而为”的两类服务质量，必须由运输层以复用和分用的形式加载到网络层。
网络层提供数据报或虚电路服务对上面的运输层有何影响？
网络层提供数据报或虚电路服务不影响上面的运输层的运行机制。但提供不同的服务质量。
当应用程序使用面向连接的 TCP 和无连接的 IP 时，这种传输是面向连接的还是面向无连接的？
都是。这要在不同层次来看，在运输层是面向连接的，在网络层则是无连接的。
试用画图解释运输层的复用。画图说明许多个运输用户复用到一条运输连接上，而这条运输连接有复用到IP数据报上。

主机 H3H_3H3 同时与主机 H1H_1H1 和 H2H_2H2 进行通信。H1H_1H1 和 H3H_3H3 的两个应用进程（HTTP 和 SMTP）进行通信，这需要使用两个 TCP 连接。这两个 TCP 连接所传送的报文段，使用下面的网络层的 IP 数据报传送。H2H_2H2 和 H3H_3H3 的应用进程（HTTP）进行通信，这需要使用一个 TCP 连接。这个 TCP 连接所传送的报文段，也要使用下面的网络层的 IP 数据报来传送。在网络层所传送的 IP 数据报已看不到运输层以上的复用情况。
试举例说明有些应用程序愿意采用不可靠的 UDP，而不用采用可靠的 TCP。
VOIP：由于语音信息具有一定的冗余度，人耳对 VOIP 数据报损失由一定的承受度，但对传输时延的变化较敏感。有差错的 UDP 数据报在接收端被直接抛弃，TCP 数据报出错则会引起重传，可能带来较大的时延扰动。因此 VOIP 宁可采用不可靠的 UDP，而不愿意采用可靠的 TCP。
原理：有差错的数据报 UDP 直接丢弃，而 TCP 则要求重传，TCP 会带来较大的时延
此外还有 DNS、SNMP 等都采用不可靠的 UDP 协议，而不愿意采用可靠的 TCP。
接收方收到有差错的 UDP 用户数据报时应如何处理？
简单地丢弃
如果应用程序愿意使用 UDP 来完成可靠的传输，这可能吗？请说明理由。
可能，但应用程序中必须额外提供与 TCP 相同的功能。
为什么说 UDP 是面向报文的，而 TCP 是面向字节流的？
① 发送方 UDP 对应用程序交下来的报文，在添加首部后就向下交付 IP 层。UDP 对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。接收方 UDP 对 IP 层交上来的 UDP 用户数据报，在去除首部后就原封不动地交付上层的应用进程，一次交付一个完整的报文。发送方 TCP 对应用程序交下来的报文数据块，视为无结构的字节流（无边界约束，课分拆/合并），但维持各字节。
② UDP 是面向报文的：发送方的 UDP 对应用程序交下来的报文，在添加了首部之后就向下交付，UDP 对应用层交付下来的报文即不合并也不拆分，而是保留这些报文的边界，应用层交给 UDP 多长的报文，UDP 就照样发送，即一次发送一个报文，接收方 UDP 对下方交上来的 UDP 用户数据报，在去除首部之后就原封不动的交付给上层的应用程序，一次交付一个完整报文，所以是 UDP 是面向报文的
③ TCP 是面向字节的：发送方 TCP 对应用程序交下来的报文数据块，视为无结构的字节流（无边界约束，可拆分/合并），但维持各字节流顺序（相对顺序没有变），TCP发送方有一个发送缓冲区，当应用程序传输的数据块太长，TCP 就可以把它划分端一些再传输，如果应用程序一次只传输一个字节，那么 TCP 可以等待积累足够多的字节后再构成报文端发送出去，所以 TCP 的面向字节的
端口的作用是什么？为什么端口要划分为三种？
端口的作用是对 TCP/IP 体系的应用进程进行统一的标志，使运行不同操作系统的计算机的应用进程能够互相通信。
熟知端口号：数值一般为 0~1023，标记常规的服务进程如 FTP 是 21，DNS 是 53，HTTP 是 80 等
登记端口号：数值为 1024~49151，标记没有熟知端口号的非常规的服务进程
短暂端口号：数值为 49152~65535，客户进程运行时动态选择
把端口划分为 3 类是因为：避免端口号重复，无法区分应用进程。二是因特网上的计算机通信都是采用 C/S 方式，在客户发起通信请求时，必须知道服务器的端口，对应一些重要的应用程序，必须让所有用户知道。
试说明运输层中伪首部的作用。
用于计算运输层数据报校验和。
伪首部(pseudo header)，通常有 TCP 伪首部和 UDP 伪首部。在 UDP 伪首部中，包含 32 位源 IP 地址，32 位目的 IP 地址，8 位协议，16 位 UDP 长度。通过伪首部的校验，UDP 可以确定该数据报是不是发给本机的，通过首部协议字段，UDP 可以确认有没有误传。
某个应用进程使用运输层的用户数据报 UDP，然而继续向下交给 IP 层后，又封装成 IP 数据报。既然都是数据报，可否跳过 UDP 而直接交给IP层？哪些功能 UDP 提供了但 IP 没提提供？
IP数据报只能找到目的主机而无法找到目的进程。UDP 提供对应用层的复用和分用功能，并提供对数据部分的差错检验。
一个应用程序用 UDP，到 IP 层把数据报在划分为 4 个数据报片发送出去，结果前两个数据报片丢失，后两个到达目的站。过了一段时间应用程序重传 UDP，而 IP 层仍然划分为 4 个数据报片来传送。结果这次前两个到达目的站而后两个丢失。试问：在目的站能否将这两次传输的 4 个数据报片组装成完整的数据报？假定目的站第一次收到的后两个数据报片仍然保存在目的站的缓存中。
不行。重传时，IP 数据报的标识字段会有另一个标识符。仅当标识符相同的 IP 数据报片才能组装成一个 IP 数据报。前两个 IP 数据报片的标识符与后两个 IP 数据报片的标识符不同，因此不能组装成一个IP数据报。
一个 UDP 用户数据的数据字段为 8192 字节。在数据链路层要使用以太网来传送。试问应当划分为几个 IP 数据报片？说明每一个 IP 数据报字段长度和片偏移字段的值。
UDP 用户数据报的长度 = UDP 首部（8 个字节） + UDP 数据字段
UDP 用户数据报的长度 = 8192 + 8 = 8200 B
以太网数据字段最大长度为 1500 B。若 IP 首部为 20 字节，则 IP 数据报的数据部分最多只能有 1480 B。8200=1480∗5+8008200 = 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）
一 UDP 用户数据报的首部十六进制表示是：06 32 00 45 00 1C E2 17。试求源端口、目的端口、用户数据报的总长度、数据部分长度。这个用户数据报是从客户发送给服务器发送给客户？使用 UDP 的这个服务器程序是什么？

把首部的 8 个字节的数值写成二进制表示的数值，如下所示：

左	右
00000110	00110010
00000000	01000101
00000000	00011100
11100010	00010111

源端口 00000110 00110010，其十进制表示是：(11000110010)2=(1586)10(11000110010)_2=(1586)_{10}(11000110010)2=(1586)10
目的端口 00000000 01000101，其十进制表示是：(1000101)2=(69)10(1000101)_2=(69)_{10}(1000101)2=(69)10
UDP 用户数据报总长度 00000000 00011100，其十进制表示是：(11100)2=(28)10(11100)_2=(28)_{10}(11100)2=(28)10
数据部分长度时 UDP 总长度减去首部长度 = 28 - 8 = 20 字节
此 UDP 用户数据报是从客户发给服务器（因为目的端口号 < 1023，是熟知端口）。服务器程序是 TFTP。

应用程序	FTP	TELNET	SMTP	DNS	TFTP	HTTP	SNMP	SNMP(trap)	HTTPS
熟知端口号	21	23	25	53	69	80	161	162	443

使用 TCP 对实时话音数据的传输有没有什么问题？使用 UDP 在传送数据文件时会有什么问题？
如果语音数据不是实时播放（边接收边播放）就可以使用 TCP，因为 TCP 传输可靠。接收端用 TCP 将话音数据接收完毕后，可以在以后的任何时间进行播放。但假定是实时传输，则必须使用 UDP。 UDP 不保证可靠交付，但 UDP 比 TCP 的开销要小很多。因此只要应用程序接收这样的服务质量就可以使用 UDP。
在停止等待协议中如果不使用编号是否可行？为什么？
分组和确认分组都必须进行编号，才能明确哪个分则得到了确认。
停止等待协议要点：
① 停止等待协议用于通信系统中，两个相连的设备相互发送信息时使用，以确保信息不因丢包或包乱序而丢失，是最简单的自动重传请求方法。
只有收到序号正确的确认帧 ACKn 后，才更新发送状态变量 V(S)一次，并发送新的数据帧。
② 接收端接收到数据帧时，就要将发送序号 N(S) 与本地的接收状态变量 V(R)相比较。
若二者相等就表明是新的数据帧，就收下，并发送确认。否则为重复帧，就必须丢弃。但这时仍须向发送端发送确认帧 ACKn，而接收状态变量V(R)和确认序号 n 都不变。
连续出现相同发送序号的数据帧，表明发送端进行了超时重传。连续出现相同序号的确认帧，表明接收端收到了重复帧。
③ 发送端在发送完数据帧时，必须在其发送缓存中暂时保留这个数据帧的副本。这样才能在出差错时进行重传。只有确认对方已经收到这个数据帧时，才可以清除这个副本。
实用的CRC 检验器都是用硬件完成的。
④ CRC 检验器能够自动丢弃检测到的出错帧。因此所谓的“丢弃出错帧”，对上层软件或用户来说都是感觉不到的。
发送端对出错的数据帧进行重传是自动进行的，因而这种差错控制体制常简称为ARQ(Automatic Repeat reQuest)，直译是自动重传请求，但意思是自动请求重传。
在停止等待协议中，如果收到重复的报文段时不予理睬（即悄悄地丢弃它而其他什么也没做）是否可行？试举出具体的例子说明理由。
收到重复帧不确认相当于确认丢失
不可行。例如：发送方发送 M1M_1M1，接收方收到 M1M_1M1，确认 M1M_1M1，确认 M1M_1M1 丢失。发送方超时重传 M1M_1M1，如果接收方收到重复的 M1M_1M1，不理睬，发送方又超时，又重传 M1M_1M1，如此重复下去了。
假定在运输层使用停止等待协议。发送发在发送报文段 M0M_0M0 后再设定的时间内未收到确认，于是重传 M0M_0M0，但 M0M_0M0 又迟迟不能到达接收方。不久，发送方收到了迟到的对 M0M_0M0 的确认，于是发送下一个报文段 M1M_1M1，不久就收到了对 M1M_1M1 的确认。接着发送方发送新的报文段 M0M_0M0，但这个新的 M0M_0M0 在传送过程中丢失了。正巧，一开始就滞留在网络中的 M0M_0M0 现在到达接收方。接收方无法分辨 M0M_0M0 是旧的。于是收下 M0M_0M0 ，并发送确认。显然，接收方后来收到的 M0M_0M0 是重复的，协议失败了。
试画出双方交换报文的过程。

我们可以看出，旧的 M0M_0M0 被当成是新的 M0M_0M0！可见运输层不能使用停止等待协议（编号只有 0 和1 两种）。
试证明：当用 n 比特进行分组的编号时，若接收到窗口等于 1（即只能按序接收分组），当仅在发送窗口不超过 2n−12^n-12n−1 时，连接 ARQ 协议才能正确运行。窗口单位是分组。

Ⅰ、设发送窗口记为 WTW_TWT，接收窗口记为 WRW_RWR。假定用 3 比特进行编号。设接收窗口正好在 7 号分组处（有阴影的分组）。
Ⅱ、发送窗口 WTW_TWT 的位置不可能比 ② 的位置更靠前。因为接收窗口的位置表明接收方正在等待接收 7 号分组，而这时的发送方不可能已经收到了对 7 号分组的确认。因此发送窗口必须包括 7 号分组，也就是不可能比 ② 的位置更靠前（前方就是图的右方）。
Ⅲ、发送窗口 WTW_TWT 的位置不可能比 ③ 的位置更靠后。因为接收窗口的位置表明接收方已经对 6 号分组（以及以前的分组）发送了确认。但如果发送窗口 WTW_TWT 的位置再靠后一个分组，即在 6 号分组的左边，那就表明还没有发送 6 号分组。但接收方的位置表明接收方已经发送了对 6 号分组的确认。这显然是不可能的。
Ⅳ、发送窗口 WTW_TWT 的位置可能在某个位置的中间，如 ①。
对于 ① 和 ② 的情况，在 WTW_TWT 的范围内必须无重复序号，即 WT⩽2nW_{T}\leqslant2^nWT⩽2n。
对于 ③ 的情况，在 WT+WRW_T+W_RWT+WR 的范围内无重复序号，即 WT+WR⩽2nW_T+W_R\leqslant2^nWT+WR⩽2n。
现在 WR=1W_R=1WR=1，故发送窗口的最大值：WT⩽2n−1W_{T}\leqslant2^n-1WT⩽2n−1。
心得：① 和 ② 包含了 WRW_RWR，所以不用减发送方窗口的 1，而 ③ 未包含 WRW_RWR，所以必须小于等于无重复序号减去发送方窗口的1
在连续 ARQ 协议中，若发送窗口等于 7，则发送端在开始时可连续发送 7 个分组。因此，在每一分组发送后，都要置一个超时计时器。现在计算机里只有一个硬时钟。设这 7 个分组发出的时间分别为 t0,t1…t6t_0,t_1…t_6t0,t1…t6，且 toutt_{out}tout 都一样大。试问如何实现这 7 个超时计时器（这叫软件时钟法）？
方法1：可采用链表记录，其信息域为分组的相对发送时间和分组编号来实现。当编号为 0 的分组定时时钟到期后，修改链表指针并重发此分组，同时将头指针指向编号为 1 的分组，以此类推。

方法2：可以定义一个含有7个数据的数组，数组中的数据表示时间，当该组数据发送出去时，在对应序号的数组中填入时间值，该时间值是该组发送出去的时间+超时时间得到，如何不停的对该数组的值进行扫描，当接收到接收端的确认分组时，即将对应数组序号的时间值设置为空，准备记录下一个数据发发送时间，当系统时间大于数组中某一个时间值时，说明该分组以及超时了，需要进行重传
使用连续 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 的分组的。
主机 A 向主机 B 发送一个很长的文件，其长度为 L 字节。假定 TCP 使用的 MSS 有 1460 字节。
（1）在 TCP 的序号不重复使用的条件下，L 的最大值是多少？
（2）假定使用上面计算出文件长度，而运输层、网络层和数据链路层所使用的首部开销共 66 字节，链路的数据率为 10 Mb/s，试求这个文件所需的最短发送时间。
（1）可能的序号共 232=42949672962^{32}=4294967296232=4294967296 个。TCP 的序号是数据字段中每一个字节的编号，而不是每一个报文段的编号。因此，这一小题与报文段的长度无关，即用不到题目给出的 MSS 值。这个文件 L 的最大值就是可能的序号数，即 4294967296 字节。若 1GB=230B1 GB = 2^{30}B1GB=230B，则 L 的最大值为 4 GB。
（2）2321460=2941758.422\frac{2^{32}}{1460}=2941758.4221460232=2941758.422，需要发送 2941759 个帧。
帧首部的开销是 66∗2941759=19415609466*2941759 =19415609466∗2941759=194156094 字节。
发送的总字节数 = 232+194156094=44891233902^{32}+194156094=4489123390232+194156094=4489123390 字节。
数据率 10 Mbilt/s = 1.25 MB/s = 1250000 字节/秒。
发送 4489123390 字节需时间为：44891233901250000=3591.3\frac{4489123390}{1250000}=3591.312500004489123390=3591.3 秒。
即 59.85 分，约 1 小时。
主机 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】
一个 TCP 连接下面使用 256 kb/s 的链路，其端到端时延为 128 ms。经测试，发现吞吐量只有 120 kb/s。试问发送窗口 W 是多少？（提示：可以有两种答案，取决于接收端发出确认的时机）。
设发送窗口 = W（bit），再设发送端连续发送完窗口内的数据所需要的时间 = T。有两种情况：
（a）接收端在收完一批数据的最后才发出确认，因此发送端经过 (256 ms + T) 后才能发送下一个窗口的数据。
（b）接收端每收到一个很小的报文段就发回确认，因此发送端经过比 256 ms 略多一些的时间即可在发送数据。因此每经过 256 ms 就能发送一个窗口的数据。

对于（a）：
吞吐量=WW256kbit/s+256ms=120kbit/s吞吐量=\frac{W}{\frac{W}{256kbit/s}+256ms}=120kbit/s吞吐量=256kbit/sW+256msW=120kbit/s
发送窗口 W120=W256+256\frac{W}{120}=\frac{W}{256}+256120W=256W+256
256W=120W+256∗256∗120256W=120W+256*256*120256W=120W+256∗256∗120
发送窗口 W=256∗256∗120136=57825.88bitW=\frac{256*256*120}{136}=57825.88bitW=136256∗256∗120=57825.88bit，约为 7228 字节
【256 kbit/s 指的是链路速率；256 ms 指的是往返 RTT，即 128 * 2 = 256 ms】
对于（b）：
吞吐量=W256ms=120kbit/s吞吐量=\frac{W}{256ms}=120kbit/s吞吐量=256msW=120kbit/s
发送窗口 W=256∗120=30720bit=3840BW=256*120=30720bit=3840BW=256∗120=30720bit=3840B
吞吐量（throughput）表示在单位时间内通过某个网络（或信道、接口）的实际的数据量。
为什么在 TCP 首部中要把 TCP 端口号放入最开始的 4 个字节？
在 ICMP 的差错报文中要包含 IP 首部后面的8个字节的内容，而这里面有 TCP 首部中的源端口和目的端口。当 TCP 收到 ICMP 差错报文时需要用这两个端口来确定是哪条连接出了差错。
为什么在 TCP 首部中有一个首部长度字段，而 UDP 的首部中就没有这个这个字段？
TCP 首部除固定长度部分外，还有选项，因此 TCP 首部长度是可变的。UDP 首部长度是固定的。
一个 TCP 报文段的数据部分最多为多少个字节？为什么？如果用户要传送的数据的字节长度超过 TCP 报文字段中的序号字段可能编出的最大序号，问还能否用 TCP 来传送？
① 一个 TCP 那段的数据部分最多为 65495 字节，此数据部分加上 TCP 首部的 20 字节，再加上 IP 首部的 20 字节，正好是 IP 数据报的最大长度 65535。（当然，若 IP 首部包含了选择，则 IP 首部长度超过20字节，这时 TCP 报文段的数据部分的长度将小于 65495 字节。）
② 如果数据的字节长度超过 TCP 报文段中的序号字段可能编出的最大序号，仍可用 TCP 传送。编号用完后可重复使用。但应设法保证不出现编号的混乱。
扩展阅读：
IP 数据报的最大长度 = 216−12^{16}-1216−1 = 65535 字节
TCP 报文段的数据部分 = IP 数据报的最大长度 - IP 数据报的首部 - TCP 报文段的首部 = 65535 - 20 - 20 = 65495 字节
一个 TCP 报文段的最大载荷是 65515 字节.
IP数据报的最大长度为 216−12^{16}-1216−1 = 65535 字节，减去 IP 数据报首部 20 字节和 TCP 首部 20 字节后的 TCP 报文段的数据部分为 65495 字节。
主机 A 向主机 B 发送 TCP 报文段，首部中的源端口是 m 而目的端口是n。当 B 向 A 发送回信时，其 TCP 报文段的首部中源端口和目的端口分别是什么？
当 B 向 A 发送回信时，其 TCP 报文段的首部中得到源端口就是 A 发送的 TCP 报文段首部的目的端口 n，而 B 发送的 TCP 报文段首部中的目的端口就是 A 发送的 TCP 报文段首都的源端口 m。
在使用 TCP 传送数据时，如果有一个确认报文段丢失了，也不一定会引起与该确认报文段对应的数据的重传。试说明理由。
还未重传就收到了对更高序号的确认。
因为 TCP 接收方只会对按序到达的最后一个分组发送确认
当对更高的序号确认了意味着已经到达了，即不用重传了。
设 TCP 使用的最大窗口为 65535 字节，而传输信道不产生差错，带宽也不受限制。若报文段的平均往返时延为 20 ms，问所能得到的最大吞吐量是多少?
在发送时延可忽略的情况下，每 20 ms 可发送 65535∗8=52428065535 * 8=52428065535∗8=524280 bit
最大数据率 = 524280bit20ms≈26.2Mb/s\frac{524280bit}{20ms}\approx26.2Mb/s20ms524280bit≈26.2Mb/s
通信信道带宽为 1 Gb/s，端到端时延为 10 ms。TCP 的发送窗口为 65535 字节。试问:可能达到的最大吞吐量是多少?信道的利用率是多少?
发送一个窗口的比特数为 65535∗8=52428065535*8=52428065535∗8=524280 bit
所需时间为 524280bit1000000000bit/s=0.524∗0.001s=0.524\frac{524280bit}{1000000000bit/s}=0.524*0.001s=0.5241000000000bit/s524280bit=0.524∗0.001s=0.524 ms
往返时间为 20 ms
最大吞吐量为 0.524280Mbit/s20ms+0.524ms=0.524280Mbit/s20.524ms≈25.5\frac{0.524280Mbit/s}{20ms+0.524ms}=\frac{0.524280Mbit/s}{20.524ms}\approx25.520ms+0.524ms0.524280Mbit/s=20.524ms0.524280Mbit/s≈25.5 Mbit/s
信道利用率为 25.5Mbit/s1000Mbit/s=2.55\frac{25.5Mbit/s}{1000Mbit/s}=2.551000Mbit/s25.5Mbit/s=2.55 %
注解：
TCP每发送一个窗口，需要进行等待确认信息回来，所以每发送完一个窗口，最快需要经过一个往返时延才可以发送下一个窗口（确认信息很小不考虑发送时延），所以在一个传输轮次中，包含一个发送时延和一个往返时延，而传输的数据量是一个窗口的大小（这里不考虑TCP、IP首部和帧的构成)。所以最大吞吐量为一个窗口的大小除以一个传输轮次的时间。
什么是 Karn 算法?在 TCP 的重传机制中，若不采用 Karn 算法，而是在收到确认时都认为是对重传报文段的确认，那么由此得出的往返时延样本和重传时间都会偏小。试问：重传时间最后会减小到什么程度?
Karn 算法允许 TCP 能够区分开有效的和无效的往返时间样本，从而改进往返时间的估算。
若不采用 Karn 算法，而是在收到确认时都认为是对重传报文段的确认，那么由此得出的往返时间样本和重传时间都会偏小。如下图所示，TCP 发送了报文段后，没有收到确认，于是超时重传报文段。但刚刚重传了报文段后，马上就收到了确认。显然，这个确认是对原来发送的报文段的确认。
但是，根据题意，我们就认为这个确认是对重传的报文段的确认。这样得出的往返时间就会很小。这样的往返时间最后甚至可以减小到很接近于零、
因此，上述的这种做法是不可取的。
假定 TCP 在开始建立连接时，发送方设定超时重传时间是 RTO = 6 s。
（1）当发送方接到对方的连接确认报文段时，测量出 RTT 样本值为 1.5 s。试计算现在的 RTO 值。
（2）当发送方发送数据报文段并接收到确认时，测量出RTT样本值为 2.5 s。试计算现在的 RTO 值。
（1）当第一次测量到 RTT 样本时，RTTSRTT_SRTTS 值·就取为这个测量到的 RTT 样本值。
因此，RTTSRTT_SRTTS = 1.5 s。
根据 RFC 2988 的建议，当第一次测量时，RTTDRTT_DRTTD 值取为这个测量到的 RTT 样本值的一半。
因此，RTTD=12∗1.5sRTT_D=\frac{1}{2}*1.5sRTTD=21∗1.5s = 0.75 s。
根据式子，RTO=RTTS+4∗RTTD=1.5s+4∗0.75=4.5sRTO=RTT_S+4*RTT_D=1.5s+4*0.75=4.5sRTO=RTTS+4∗RTTD=1.5s+4∗0.75=4.5s
（2）新的 RTT 样本 = 2.5 s
新的RTTS=(1−α)∗(旧的RTTs)+α∗(新的RTT样本)新的 RTT_S=(1-α)*(旧的RTT_s)+α*(新的RTT样本)新的RTTS=(1−α)∗(旧的RTTs)+α∗(新的RTT样本)
=(1−18)∗1.5s+18∗2.5s=1.625s=(1-\frac{1}{8})*1.5s+\frac{1}{8}*2.5s=1.625s=(1−81)∗1.5s+81∗2.5s=1.625s
新的RTTD=(1−β)∗(旧的RTTD)+β∗∣新的RTTS−新的RTT样本∣新的 RTT_D=(1-β)*(旧的RTT_D)+β*|新的RTT_S-新的RTT样本|新的RTTD=(1−β)∗(旧的RTTD)+β∗∣新的RTTS−新的RTT样本∣
=(1−14)∗0.75s+14∗∣1.625s−2.5s∣=0.78125s≈0.78s=(1-\frac{1}{4})*0.75s+\frac{1}{4}*|1.625s-2.5s|=0.78125s\approx0.78s=(1−41)∗0.75s+41∗∣1.625s−2.5s∣=0.78125s≈0.78s
根据式子，RTO=RTTS+4∗RTTD=1.625s+4∗0.78=4.75sRTO=RTT_S+4*RTT_D=1.625s+4*0.78=4.75sRTO=RTTS+4∗RTTD=1.625s+4∗0.78=4.75s
已知第一次测得 TCP 的往返时延的当前值 RTT 是 30 ms。现在收到了三个接连的确认报文段，它们比相应的数据报文段的发送时间分别滞后的时间是：26 ms，32 ms 和24 ms。设 α = 0.1。试计算每一次的新的加权平均往返时间值 RTTSRTT_SRTTS。讨论所得出的结果。
公式：新的RTTS=(1−α)∗(旧的RTTs)+α∗(新的RTT样本)新的 RTT_S=(1-α)*(旧的RTT_s)+α*(新的RTT样本)新的RTTS=(1−α)∗(旧的RTTs)+α∗(新的RTT样本)
第一次算出：RTTS=(1−0.1)∗30+0.1∗26=29.6msRTT_S=(1-0.1)*30+0.1*26=29.6msRTTS=(1−0.1)∗30+0.1∗26=29.6ms
第二次算出：RTTS=(1−0.1)∗29.6+0.1∗32=29.86msRTT_S=(1-0.1)*29.6+0.1*32=29.86msRTTS=(1−0.1)∗29.6+0.1∗32=29.86ms
第三次算出：RTTS=(1−0.1)∗29.86+0.1∗24=29.256msRTT_S=(1-0.1)*29.86+0.1*24=29.256msRTTS=(1−0.1)∗29.86+0.1∗24=29.256ms
三次算出加权平均往返时间分别为 29.6，29.84 和 29.256 ms。
可以看出，RTT 的样本值变化多达 20 % 时( (30−24)30=630=15=20\frac{(30-24)}{30}=\frac{6}{30}=\frac{1}{5}=2030(30−24)=306=51=20 % )，加权平均往返 RTTSRTT_SRTTS 的变化却很小。
试计算一个包括 5 段链路的运输连接的单程端到端时延。5 段链路程中有 2 段是卫星链路，有 3 段是广域网链路。每条卫星链路又由上行链路和下行链路两部分组成。可以取这两部分的传播时延之和为 250 ms。每一个广域网的范围为 1500 km，其传播时延可按 150000 km/s 来计算。各数据链路速率为 48 kb/s，帧长为 960 位。

广域网的传播时延 = 1500km150000km/s=0.01s=10ms\frac{1500km}{150000km/s}=0.01s=10ms150000km/s1500km=0.01s=10ms
每一个节点的传播时延 = 960bit48000bit/s=0.02s=20ms\frac{960 bit}{48000 bit/s} = 0.02s = 20ms48000bit/s960bit=0.02s=20ms

	WAN	WAN	WAN	卫星网	卫星网	合计
传播时延	10 ms	10 ms	10 ms	250 ms	250 ms	530 ms
发送时延	20 ms	20 ms	20 ms	20 ms	20 ms	100 ms

可见总共需时：630 ms

重复 35 题，但假定其中的一个陆地上的广域网的传输时延为 150 ms。

	WAN	WAN	WAN	卫星网	卫星网	合计
传播时延	10 ms	10 ms	10 ms	250 ms	250 ms	530 ms
发送时延	150 ms	20 ms	20 ms	20 ms	20 ms	230 ms

可见总共需时：760 ms

在 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 大小，使拥塞窗口缓慢增大，以防止网络过早出现拥塞。
设 TCP 的 ssthresh 的初始值为 8 (单位为报文段)。当拥塞窗口上升到 12 时网络发生了超时，TCP 使用慢开始和拥塞避免。试分别求出第 1 次到第 15 次传输的各拥塞窗口大小。你能说明拥塞控制窗口每一次变化的原因吗？

拥塞窗口大小及变化原因见下表：

轮次	拥塞窗口	拥塞窗口变化的原因
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

注解：
依照原理，首先执行 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。

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 应设置为多大？

拥塞窗口 cwnd 大小与传输轮次 n 的关系

n	1	2	3	4	5	6	7	8	9	10	11	12	13
cwnd	1	2	4	8	16	32	33	34	35	36	37	38	39
n	14	15	16	17	18	19	20	21	22	23	24	25	26
cwnd	40	41	42	21	22	23	24	25	26	1	2	3	4

（1）拥塞窗口与传输轮次的关系曲线如下图所示：

（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。

TCP 在进行流量控制时是以分组的丢失作为产生拥塞的标志。有没有不是因拥塞而引起的分组丢失的情况?如有，请举出三种情况。
不是因为拥塞而引起分组丢失的情况是有的，举例如下：
① 当 IP 数据报在传输过程中需要分片，但其中一个数据报片未能及时到达终点，而终点组装 IP 数据报已超时，因而只能丢弃该数据报。
② IP 数据报已经到达终点，但终点的缓存没有足够的空间存放此数据报。
③ 数据报在转发过程中经过一个局域网的网桥，但网桥在转发该数据报的帧时没有足够的储存空间而只好丢弃。
用 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。但这个确认报文段并不消耗序号。
【-----四报文挥手结束-----】
在图 5-29 中所示的连接释放过程中，主机 B 能否先不发送 ACK = x + 1 的确认?（因为后面要发送的连接释放报文段中仍有 ACK = x + 1 这一信息）

如果 B 不再发送数据了，是可以把两个报文段合并成为一个，即只发送 FIN+ACK 报文段。但如果 B 还有数据报要发送，而且要发送一段时间，那就不行，因为 A 迟迟收不到确认，就会以为刚才发送的 FIN 报文段丢失了，就超时重传这个 FIN 报文段，浪费网络资源。
在图 5-30 中，在什么情况下会发生从状态 SYN-SENT 到状态 SYN-RCVD 的变迁？

当 A 和 B 都作为客户，即同时主动打开 TCP 连接。这时的每一方的状态变迁都是：
CLOSED -> SYN-SENT -> SYN-RCVD -> ESTABLISHED
试以具体例子说明为什么一个运输连接可以有多种方式释放。可以设两个互相通信的用户分别连接在网络的两结点上。
设 A，B建立了运输连接。
协议应考虑一下实际可能性： A 或 B 故障，应设计超时机制，使对方退出，不至于死锁；
A主动退出，B被动退出
B主动退出，A被动退出
解释为什么突然释放运输连接就可能会丢失用户数据，而使用 TCP 的连接释放方法就可保证不丢失数据。
当主机 1 和主机 2 之间连接建立后，主机 1 发送了一个 TCP 数据段并正确抵达主机 2，接着主机 1 发送另一个TCP数据段，这次很不幸，主机 2 在收到第二个 TCP 数据段之前发出了释放连接请求，如果就这样突然释放连接，显然主机 1 发送的第二个 TCP 报文段会丢失。
而使用 TCP 的连接释放方法，主机 2 发出了释放连接的请求，那么即使收到主机 1 的确认后，只会释放主机 2 到主机 1 方向的连接，即主机 2 不再向主机 1 发送数据，而仍然可接收主机 1 发来的数据，所以可保证不丢失数据。
试用具体例子说明为什么在运输连接建立时要使用三次握手。说明如不这样做可能会出现什么情况。
3 次握手完成两个重要的功能，既要双方做好发送数据的准备工作（双方都知道彼此已准备好），也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。
假定 B 给 A 发送一个连接请求分组，A 收到了这个分组，并发送了确认应答分组。按照两次握手的协定，A 认为连接已经成功地建立了，可以开始发送数据分组。可是，B 在 A 的应答分组在传输中被丢失的情况下，将不知道 A 是否已准备好，不知道 A 建议什么样的序列号，B 甚至怀疑 A 是否收到自己的连接请求分组，在这种情况下，B 认为连接还未建立成功，将忽略 A 发来的任何数据分组，只等待连接确认应答分组。而 A 发出的分组超时后，重复发送同样的分组。这样就形成了死锁。
一个客户向服务器请求建立 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
网络允许的最大报文段长度为 128 字节，序号用 8 比特表示，报文段在网络中的寿命为 30 s。求发送报文段的一方所能达到的最高数据率。
根据题意，先可以做出以下一些假设：
（1）本题不是使用 TCP 协议，因为序号字段是 8 位，而不是 TCP 的 32 位。
（2）既然不是使用 TCP 协议，当然也不是使用 TCP 协议得到首部。现在的报文段的首部是什么样子，和我们解题没有关系。我们不用管它。我们只需要知道的是，现在的报文段的首部有一个序号字段。
（3）显然，现在不是给报文中的每一个字节编上序号，而是给每一个报文编上序号。
（4）报文段的传送应当使用滑动窗口协议（而不是停止等待协议），这样可得到较高的效率。
我们知道，在使用滑动窗口协议时，在没有收到确认的情况下，8 位的序号字段可连续发送 255 个序号（2n−12^n-12n−1）的报文段。
这样，一共可发送的比特数 = 255∗128∗8=261120255*128*8=261120255∗128∗8=261120 bit
算出发送报文段的一方所能达到的最高数据率是：
261120bit30s=8704bit/s=8.704kbit/s\frac{261120bit}{30s}=8704bit/s=8.704kbit/s30s261120bit=8704bit/s=8.704kbit/s
下面是以十六进制格式存储的一个 UDP 首部：
CB84000D001C001C
试问:
(1) 源端口号是什么？
(2) 目的端口号是什么？
(3) 这个用户数据报的总长度是什么？
(4) 数据长度是多少？
(5)这个分组是从客户到服务器还是从服务器到客户？
(6) 客户进程是什么
（1）源端口号室最前面的四位十六进制数字 (CB84)16(CB84)_{16}(CB84)16，算出十进制的源端口号是：(CB84)16=(52100)10(CB84)_{16}=(52100)_{10}(CB84)16=(52100)10。
（2）目的端口号室最二个四位十六进制数字 (000D)16(000D)_{16}(000D)16，算出十进制的目的端口号是：(000D)16=(13)10(000D)_{16}=(13)_{10}(000D)16=(13)10。
（3）第三个四位十六进制数字 (001C)16(001C)_{16}(001C)16 定义了整个 UDP 分组的长度，算出是：(001C)16=(28)10(001C)_{16}=(28)_{10}(001C)16=(28)10 字节。
（4）数据的长度时整个分组的长度减去首部的长度，也就是 28 - 8 = 20 字节。
（5）因为目的端口是 13 （熟知端口），所以这个分组是从客户到目的端口。
（6）从 RFC 867 可以得知，这个客户进程是 Daytime。当 Daytime 服务器收到客户发送的 UDP 用户数据报后，就把现在的日期和时间以 ASCII 码字符串的形式返回给客户。
把教材上的图 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 用户数据报（也可以上交应用层，但附上出现差错的警告）。
在以下几种情况下，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 再发送出去。
UDP 和 IP 的不可靠程度是否相同? 请加以解释。
① UDP 和 IP 都是无连接的协议和不可靠传输的协议。UDP 用户数据报和 IP 数据报的首部都有检验和字段。当检验出现差错时，就把收到的 UDP 用户数据报或 IP 数据报丢弃。这是它们的相同之处。
② 但 UDP 和 IP 的可靠性是有些区别的。UDP 用户数据报的检验和是既检验 UDP 用户数据报的首部又检验整个的 UDP 用户数据报的数据部分，而 IP 数据报的检验和仅仅检验 IP 数据报的首部。UDP 用户数据报的检验和还增加了伪首部，即还检验了下面的 IP 数据报的源 IP 地址和目的 IP 地址。
UDP 用户数据报的最小长度是多少？用最小长度的 UDP 用户数据报构成的最短 IP 数据报的长度是多少？
UDP 用户数据报的最小长度是 8 字节，即仅有首部而没有数据。用最小长度的 UDP 源用户数据报构成的最短 IP 数据报的长度为 28 字节。此 IP 数据报具有 20 字节的固定首部，首部中没有可选字段。
某客户使用 UDP 将数据发送给一服务器，数据共 16 字节。试计算在运输层的传输效率（有用字节与总字节之比）。
UPD 用户数据报的总长度 = 8 + 16 = 24 字节。
因此，在运输层的传输效率 = 1624\frac{16}{24}2416 = 0.667。
重做 54，但在 IP 层计算传输效率。假定 IP 首部无选项。
IP数据报的总长度 = 20 + 24 = 44 字节。
因此，在IP层的传输效率 = 1644\frac{16}{44}4416 = 0.324。
重做 54，但在数据链路层计算传输效率。假定 IP 首部无选项，在数据链路层使用以太网。
以太网有 14 字节的首部，4 字节的尾部（FCS 字段）。但其数据字段的最小长度是 46 字节，而我们的 IP 数据报仅有 44 字节，因此还必须加上 2 字节的填充。这样，以太网的总长度 = 14 + 4 + 2 + 44 = 64 字节。
因此，在数据链路层的传输效率 = 1664\frac{16}{64}6416 = 0.25。
如果再考虑到发送以太网的帧之前还有 8 字节的前同步码。把这 8 字节计入后，在数据链路层的传输效率 = $\frac{16}{72} = 0.222。
某客户有 67000 字节的分组。试说明怎样使用 UDP 用户数据将这个分组进行传送。
一个 UDP 用户数据报的最大长度为 65535 字节。现在的长度超过了这个限度，因此不能使用一个 UDP 用户数据报来传送。必须进行切割（例如，分割为两个 UDP 用户数据报），使其长度不超过以上的限度。
TCP 在 4:30:20 发送了一个报文段。它没有收到确认。在 4:30:25 它重传了前面这个报文段。它在 4:30:27 收到确认。若以前的 RTT 值为 4 秒，根据 Karn 算法，新的 RTT 值为多少？
根据 Karn 算法，只要是 TCP 报文段重传了，就不采用其往返时间样本。本题中收到的确认是在重传后收到的。因此 RTT 没有变化，仍然是以前的数值（4 秒）。
Karn算法：运输层用来控制流量算法。在计算平均往返时延 RTT 时，只要报文段重传了，就不采用其往返时延样本。这样得出的平均往返时延 RTT 和重传时间就较准确。
TCP 连接使用 1000 字节的窗口值，而上一次的确认号是 22001。它收到了一个报文段，确认号是 22401.。试用图来说明在这之前与之后的窗口情况。
在这之前和在这之后的窗口情况如下图所示。
这里要注意的是：发送窗口为 1000 字节，窗口里面的序号也正好是 1000 个。号码小在后面，即在图的左方。另外一点要注意的是，发送方收到的确认号表示接收方期望能够收到序号。这个序号应当在发送窗口的最前面。
同上题，但在接收方收到的字节为 22401 的报文段时，其窗口字段变为 1200 字节。试用图来说明在这之前与之后的窗口情况。
在这之前与之后的窗口情况如下图所示：
在本题中列出的 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=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 号字节。整个发送窗口也就是可用窗口。
TCP 连接处于 ESTABLISHED 状态。以下的事件相继发生：
（1）收到一个 FIN 报文段
（2）应用程序发送 “关闭” 报文
在每一个事件之后，连接的状态是什么？在每一个事件之后发生的动作是什么？

（1）处于 ESTABLISHED 状态又能够收到一个 FIN 报文段，只有 TCP 的服务器端而不会是客户端。当这个服务器端收到 FIN 时，服务器就向客户端发送 ACK 报文段，并进入到 CLOSE-WAIT 状态。这是被动关闭。请注意，这时客户端不会再发送数据了，但服务器端如还有数据要发送给客户端，那么还是可以继续发送的。
（2）应用程序发送 “关闭” 报文给服务器，表明没有数据要发送了。这时服务器就应当发送 FIN 报文段给客户，然后转换到 LAST-ACK 状态，并等待来自客户端的最后的确认。
以上的状态转换可参考教材上的图 5-30。
TCP 连接处于 SYN-RCVD 状态。以下的事件相继发生：
（1）应用程序发送 “关闭” 报文
（2）收到 FIN 报文段
在每一个事件之后，连接的状态是什么？在每一个事件之后发生的动作是什么？

（1）处于 SYN-RCVD 状态而又能够收到应用程序发送的 “关闭” 报文的，只有 TCP 的客户端而不会是服务器端。这时，客户端就应当向服务器端发送 FIN 报文段，然后进入到 FIN-WAIT-1 状态。
（2）当客户收到服务器端发送的 FIN 报文段后，就向服务器发送 ACK 报文段，并进入到 CLOSED 状态。
以上的状态转换可参考教材上的图 5-30。
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。
假定主机 A 向 B 发送一个 TCP 报文段。在这个报文段中，序号是 50，而数据一共有 6 字节长。试问，在这个报文段中的确认字段是否应当写入 56？
在这个报文段中的确认字段应当写入的是 A 期望下次收到 B 发送的数据中的第一个字节的编号，而这个数值是 A 已经收到的数据的最后一个字节的编号加 1。然而这些在题目中并未给出。题目给出的是 A 向 B 发送的数据中第一个字节的编号是 50，并且在这个报文段中共有 6 字节的数据。这些都和此报文段中的确认字段是什么毫无关系。因此，现在我们无法知道这个报文段中的确认字段应当写入的数值。
主机 A 通过 TCP 连接向 B 发送一个很长的文件，因此这需要分成很多个报文段来发送。假定某一个 TCP 报文段的序号是 x，那么下一个报文段的序号是否就是 x + 1 呢？
假定某一个 TCP 报文段的序号是 x，那么下一个报文段的序号应当是 x+n，这里的 n 是这个报文段中的数据长度的字节数。如 n = 4000，那么下一个报文段的序号应当是 x + 400。若此报文段中仅有一个字节的数据，则下一个报文段的序号才是 x + 1。
TCP 的吞吐量应当是每秒发送的数据字节数，还是每秒发送的首部和数据之和的字节数？吞吐量应当是每秒发送的字节数，还是每秒发送的比特数？
① TCP 的吞吐量本来并没有标准的定义，可以计入首部，也可以不计入首部，但应当说清楚。不过，从拥塞控制来看，拥塞窗口和发送窗口针对的都是 TCP 报文段中的数据字段，而重要的参数 MSS 也是指 TCP 报文段中的数据字段的长度，因此，把 TCP 的吞吐量定义为每秒发送的数据字节数是比较方便的。
② 计算机内部的数据传送是以每秒多少字节作为单位的，而在通信线路上的数据率则常用每秒多少比特作为单位。这两种表示方法并无实质上的差别。在上面的习题中，因为 MSS 用字节作为单位，因此，用每秒发送多少字节作为 TCP 吞吐量的单位就比较简单一些。
在 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 发送的第二个仅仅是确认的报文段，是个可以省略的报文段，即使丢失了也无妨，只要下面紧接着就可以发送数据报文段即可。
现在假定使用类似 TCP 的协议（即使用滑动窗口可靠传送字节流），数据传输速率是 1 Gbit/s，而网络的往返时间 RTT = 140 ms。假定报文段的最大生存时间是 60 秒。如果要尽可能快的传送数据，在我们的通信协议的首部中，发送窗口和序号字段至少各应当设为多大？
发送窗口至少应当能够容纳的比特数
= 往返时间 * 数据率
= RTT∗1Gbit/s=140∗10−3s∗109bit/s=140∗106bit=17.5∗106RTT *1Gbit/s=140*10^{-3}s*10^9bit/s=140*10^6bit=17.5*10^6RTT∗1Gbit/s=140∗10−3s∗109bit/s=140∗106bit=17.5∗106 字节
我们知道，每一个字节的数据需要有一个编号。假定发送窗口一共有 w 位，那么总的号码数应当大于 17.5∗10617.5*10^617.5∗106 字节，即：
2w⩾175000002^w\geqslant175000002w⩾17500000
那么，w⩾log2(17500000)=24.06w\geqslant log_2(17500000)=24.06w⩾log2(17500000)=24.06
可见只用 24 位的发送窗口差一点，必须使用 w = 25 位的发送窗口才行。TCP 的窗口字段为 16 位。
再看看 60 秒钟以 1 Gbit/s 的速率可以发送 60s∗109bit/s=7.5∗10960s*10^9bit/s=7.5*10^960s∗109bit/s=7.5∗109 字节的数据。
假定需要 n 位的序号字段，那么总的序号数应当大于 7.5∗1097.5*10^97.5∗109 字节，即：
2n⩾7.5∗1092^n\geqslant7.5*10^92n⩾7.5∗109
解出 n⩾log2(7.5∗109)=32.8n\geqslant log_2(7.5*10^9)=32.8n⩾log2(7.5∗109)=32.8
因此，取序号字段长度 n = 33 位即可保证在报文段的最大生产时间内没有重复的序号。TCP 的序号字段为 32 位。
假定用 TCP 协议在 40 Gbit/s 的线路上传送数据。
（1）如果 TCP 充分利用了线路的带宽，那么需要多长的时间 TCP 会发生序号绕回？
（2）假定现在 TCP 的首部中采用了时间戳选项。时间戳占用了 4 字节，共 32 位。每隔一定的时间（这段时间叫做一个滴答）时间戳的数值加 1。假定设计的时间戳是每隔 859 微秒，时间戳的数值加 1。试问要经过多长时间才发生时间戳数值的绕回。
（1）40 Gbit/s 的线路上传送数据，每秒可传送 5∗1095*10^95∗109 字节的数据。
TCP 的序号字段有 32 位，共有 2322^{32}232 个不同序号，可以发送的时间是
2325000000000=0.859s=859ms\frac{2^{32}}{5000000000}=0.859s=859ms5000000000232=0.859s=859ms
（2）时间戳数据绕回的时间是：
232∗859∗10−6s=3.69∗106s=42.72^{32}*859*10^{-6}s=3.69*10^6s=42.7232∗859∗10−6s=3.69∗106s=42.7 天，比原来的绕回时间大大增加了。
（3）现在每一个 TCP 的数据报文段在其首部有两个字段用来标志这个报文段。一个是序号，另一个是时间戳。但发送方发送了 2322^{32}232 个字节的数据后，序号又绕回到初始的数值了，但这时时间戳还没有绕回（因为在本例中，这需要 42.7 天才绕回），而是指在某个数值，这和一开始的时间戳初始值肯定是不一样的。这样，即使是序号一样，接收方也能够根据时间戳判断这是一个新的数据报文段，而不是以前发送过得旧的数据报文段。
在教材上 5.5 节中指出：例如，若用 2.5 Gbit/s 速率发送报文段，则不到 14 秒钟序号就会重复。请计算验证这句话。
在 2.5 Gbit/s 的线路上传送数据，每秒可传送 0.3125∗1090.3125*10^90.3125∗109 字节的数据
TCP 报文段的序号字段有 32 2，共有 2322^{32}232 个不同序号，可以发送的时间是
232312500000=13.74s\frac{2^{32}}{312500000}=13.74s312500000232=13.74s
也就是不到 14 数据字段的序号就会重复。
已知 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）。因此，这种情况（在发送时数据是在发送窗口之内，但到达接收端，这些数据却落入到接收窗口之外）必须避免。总之，我们要记住，接收窗口是不允许后退的。
在上题中，如果接收方突然因某种原因不能够再接收数据了，可以立即向发送方发送把接收窗口置为零的报文段（即 rwnd = 0）。这时会导致接收窗口的前沿后退。试问这种情况是否允许？
这种情况是允许的。当发送方收到这样的信息，并不是把发送窗口缩回到零，而是立即停止发送。什么时候可以再发送数据，就要等接收方重新开放接收窗口，即给出一个非零的接收窗口。
流量控制和拥塞控制的最主要的区别是什么？发送窗口的大小取决于流量控制还是拥塞控制？
简单地说，流量控制是在一条 TCP 连接中的接收端才用的措施，用来限制对方（发送端）发送报文的速率，以免在接收端来不及接收。流量控制只控制一个发送端。
拥塞控制是用来控制 TCP 连接中发送端发送报文段的速率，以免使互联网中的某处产生过载。拥塞控制可能会同时控制许多个发送端，限制它们的发送速率。不过每一个发送端只知道自己应当怎样调整发送速率，而不知道在互联网中还有哪些主机被限制了发送速率。
我们知道，发送窗口的上限值是 Min [rwnd, cwnd]，即发送窗口的数值不能超过接收窗口和拥塞窗口中娇小的一个。接收窗口的大小体现了接收端对发送端施加的流量控制，而拥塞窗口的大小则是整个互联网的负载情况对发送端施加的拥塞控制。因此，当接收窗口小于拥塞窗口时，发送窗口的大小取决于流量控制，即取决于接收端的接收能力。但当拥塞窗口小于接收窗口时，则发送窗口的大小取决于拥塞控制，即取决于整个网络的拥塞状况。
假定在 TCP 连接中刚刚收到的最新的往返时间 RTT 1 秒，那么超时重传时间 RTO 是否当设置成大于或等于 1 秒？
这不一定。超时重传时间 RTO 应当根据教材上的公式（5-4）和（5-5）来计算，而不是根据某一个 RTT 样本来计算。如果仅根据一个 RTT 样本就确定了超时重传时间 RTO，那么 RTO 的数值就可能会经常大幅度地波动。这就会使超时重传时间 RTO 的数值很不准确，使 TCP 的传输性能变坏。
在教材附录 C[KURO13] 中的运输层这一章给出了 TCP 连接的平均吞吐量 R 的公式如下：
R=0.75WRTTR=\frac{0.75W}{RTT}R=RTT0.75W
这里的 RTT 是往返时间，W 是发生报文段丢失时的拥塞窗口值。试推导上面的公式，并给出必要的假设条件。这里的吞吐量指的是每秒发送的数据字节（不包括首部）。

推到这个公式需要三个假设条件：
（1）忽略在超时事件后（即网络开始拥塞并引起报文段的丢失）的慢开始阶段。做出这样的假设是合理的，因为慢开始阶段通常是非常短的，发送方很快就会离开慢开始阶段（发送的报文段以指数增长方式进入网络）。但 TCP 的拥塞窗口增长到门限值 ssthresh 的一半时就会进入拥塞避免阶段，拥塞窗口每经过一个传输轮次就加 1 个 MSS。
（2）假设当拥塞窗口值到达 W（这也就是门限值 ssthresh 的数值）时，发生报文段的丢失（而在这以前都没有发生报文段的丢失），并且每次都是当拥塞窗口值到达 W 时就发生报文段的丢失。在实际的互联网中，发生报文段的丢失时的拥塞窗口应当是在变化的，这是由于整个网络的拥塞情况，取决于分布在各地的所有用户的行为。一个用户无法知道其他用户在什么时候向网络注入大量的数据。但为了简化计算，只好假定拥塞窗口的数值在整个 TCP 连接期间都不会发生变化，都是恒定的 W（即门限值 ssthresh 的数值）。
（3）假定在整个 TCP 连接期间，每一个传输轮次的 RTT 时间都是不变的。例如，在某一个传输轮次，拥塞窗口是 4 个 MSS，那么 RTT 值就是发送方连续发送 4 个报文段，并收到对方对最后一个字节的确认所经历的时间。下一个轮次拥塞窗口就增加到 5。这时的 RTT 值是发送方连续发送 5 个报文段，并收到对方对最后一个字节的确认所经历的时间。这个 RTT 显然应当会发生变化。但为了分析的方便，我们假定所有的 RTT 值都是恒定不变的。当连续发送的报文段的数目较多，发送速率较高而传播距离较远时，这样的假设还是合理的。
有了这三个假设，我们就可以得出拥塞窗口变化的情况，如下图所示：

在每一个拥塞避免阶段的刚开始时，拥塞窗口的数值是 W 的一半，即 0.5W。因此在往返时间 RTT 内可以发送的数据字节数是 0.5W 字节。这样就得出 TCP 在这段往返时间的吞吐量（这是吞吐量的最小值），它等于 0.5WRTT\frac{0.5W}{RTT}RTT0.5W。
以后每隔一个传输轮次，拥塞窗口就加 1 个 MSS。这样，拥塞窗口线性地增加到 W 时再次发生报文段的丢失。TCP 又进入到下一轮的拥塞避免。因此，TCP 的在最后这段往返时间的吞吐量（每秒发送的数据字节数）达到最大值，即 WRTT\frac{W}{RTT}RTTW
由于 TCP 吞吐量是线性增长的，因此 TCP 连接的平均吞吐量 R 是吞吐量的最小值和最大值之和的一半，即
R=[0.5+12]∗WRTT=0.75WRTTR=[\frac{0.5+1}{2}]*\frac{W}{RTT}=0.75\frac{W}{RTT}R=[20.5+1]∗RTTW=0.75RTTW
同上题一样的假定。
（1）试证明，如果拥塞窗口线性地增加到 W 时，那么下面的公式可用来计算在拥塞避免阶段的报文段丢失率 p。在下面的公式中，N 表示在拥塞窗口增加到 W 时，在时间 RTT 内，TCP 可以发送的报文段数。
p=138N2+34Np=\frac{1}{\frac{3}{8}N^2+\frac{3}{4}N}p=83N2+43N1
（2）如果 TCP 发送的每一个报文段的数据字段的长度都等于 MSS，那么一条 TCP 连接的平均吞吐量 R（每秒发送的数据字节数）可近似用下面的公式表示：
R≈1.22∗MSSRTT∗pR\approx\frac{1.22*MSS}{RTT*\sqrt{p}}R≈RTT∗p1.22∗MSS

（1）在拥塞避免阶段的报文的丢失率 p 等于在拥塞避免阶段丢失的报文段与发送的报文段的总数之比。从图中可知，由于报文段的丢失是周期性出现的，因此我们只需计算在两次丢失之间的报文段丢失率即可。在一个拥塞避免阶段，报文段仅丢失了一个（这发生在拥塞避免阶段的最后时刻）。现在计算一下，在一个拥塞避免阶段一共发送了多少个报文段。
根据已知，在拥塞避免阶段的最后，拥塞窗口是 W 时，可以在时间 RTT 内发送 N 个报文段，那么在拥塞避免阶段的一开始，拥塞窗口是 W2\frac{W}{2}2W ，可以在时间 RTT 内发送 N2\frac{N}{2}2N 个报文段。以后每隔一个 RTT 时间，可以多发送一个报文段。这样一直线性增长到最后，在发生丢失时，在时间 RTT 内可发送 N 个报文段。因此，在一个拥塞避免阶段一共能够发送的报文段数是：
N2+[N2+1]]+...++[N2+N2]=∑0N2[N2+n]=[N2+1]N2+∑0N2n\frac{N}{2}+[\frac{N}{2}+1]]+...++[\frac{N}{2}+\frac{N}{2}]=\sum_{0}^{\frac{N}{2}}[\frac{N}{2}+n]=[\frac{N}{2}+1]\frac{N}{2}+\sum_{0}^{\frac{N}{2}}n2N+[2N+1]]+...++[2N+2N]=0∑2N[2N+n]=[2N+1]2N+0∑2Nn
=[N2+1]∗N2+12∗N2[N2+1]=N24+N2+N28+N4=38N2+34N=[\frac{N}{2}+1]*\frac{N}{2}+\frac{1}{2}*\frac{N}{2}[\frac{N}{2}+1]= \frac{N^2}{4}+\frac{N}{2}+\frac{N^2}{8}+\frac{N}{4}=\frac{3}{8}N^2+\frac{3}{4}N=[2N+1]∗2N+21∗2N[2N+1]=4N2+2N+8N2+4N=83N2+43N
在拥塞避免阶段一共只丢失了一个报文段（在拥塞避免阶段的最后时刻），因此酒店的处在拥塞避免阶段的报文段丢失率 p：
p=138N2+34Np=\frac{1}{\frac{3}{8}N^2+\frac{3}{4}N}p=83N2+43N1
根据前面得出的结果，当 N 远大于 1 时，上式分母中后一项可以忽略。这样就得出：
p=83N2p = \frac{8}{3N^2}p=3N28
或 N≈83pN\approx\sqrt{\frac{8}{3p}}N≈3p8
在上一题中已经得出了 TCP 连接的平均吞吐量是
R=0.75WRTTR=\frac{0.75W}{RTT}R=RTT0.75W
但 W = N(MSS)，再把上面的推导出的 N 和 p 的关系代入，得出：
R≈0.75∗83p∗MSSRTT=1.22∗MSSRTT∗pR\approx0.75*\sqrt{\frac{8}{3p}}*\frac{MSS}{RTT}=\frac{1.22*MSS}{RTT*\sqrt{p}}R≈0.75∗3p8∗RTTMSS=RTT∗p1.22∗MSS
假定在 TCP 的拥塞避免阶段要得到 TCP 的吞吐量是 R = 10 Gbit/s，而最大报文段长度 MSS = 1460 字节，在拥塞避免阶段报文段丢失率是 p=2∗10−10p = 2*10^{-10}p=2∗10−10。试问对报文段的往返时间 RTT 是否应当提示什么要求？如果应当提出，那么应当提出什么要求？讨论所得结果。提示：利用习题 77 第（2）部分的公式：
R≈1.22∗MSSRTT∗pR\approx\frac{1.22*MSS}{RTT*\sqrt{p}}R≈RTT∗p1.22∗MSS
从概念上看，在拥塞避免阶段，如果 RTT 数值越大，那么就需要等待更长的时间才能发送下一个轮次的报文段。这就使得 TCP 的吞吐量下降。因此，要得到一定的吞吐量，报文段的往返时间 RTT 一定不能太大、
根据已知的条件，RTT 的上限值是：
RTTmax=1.22∗MSSR∗p=1.22∗1460∗810∗1092∗10−10=0.10077s≈100msRTT_{max}=\frac{1.22*MSS}{R*\sqrt{p}}=\frac{1.22*1460*8}{10*10^{9}\sqrt{2*10^{-10}}}=0.10077s\approx100msRTTmax=R∗p1.22∗MSS=10∗1092∗10−101.22∗1460∗8=0.10077s≈100ms
我们简单讨论一下所得的结果。
一个报文段的长度是 1460 字节，等于 11680 比特。若以 10 Gbit/s 速率发送，则需要时间约为 1.17 微妙，远远小于往返时间 RTT。因此，认为在整个拥塞避免阶段的 RTT 都是一样大的假设是合理的。顺便指出，若 TCP 的吞吐量是 10 Gbit/s，那么单独考虑 TCP 每一个报文段的发送速率，那还要比吞吐量 10 Gbit/s 更高一些（因为发送方还有停顿的时间）
报文段的丢失率是 p=2∗10−10p = 2*10^{-10}p=2∗10−10 是个怎样的概念呢？那就是平均每发送 5∗1095*10^95∗109 个报文段才丢失一个，这是个非常小的数值。但从以上计算可以看出，若继续提高 TCP 的吞吐量，而 RTT 仍然保持不变，那么就必须增大发送窗口来更多地发送一些报文段，使报文段的丢失率 p 减小。从上面的公式可看出，TCP 的吞吐量与可容忍的报文段丢失率的平方根成反比。TCP 的吞吐量若提高到 10 倍，即提高到 100 Gbit/s，那么可容忍的报文段的丢失率就必须减小到原来熟知的百分之一，即 p=2∗10−12p=2*10^{-12}p=2∗10−12。
TCP 对拥塞控制采用的是动态调整的策略。能否给出动态调整的要点？
TCP 的拥塞控制的动态调整策略的要点有以下三个：。
（1）探测网络的拥塞水平。慢开始就是从发送一个报文段开始探测网络的。
（2）如果网络没有拥塞，就加快发送速率。在慢开始和拥塞避免都是这样。
（3）如果网络发生了拥塞，就降低发送速率。例如，回到慢开始，或让门限值 ssthresh 减半。
请用框图的表示方法来说明 TCP 的拥塞控制流程。
下图给出了 TCP 的拥塞控制流程图。
① 整个流程图可分为三大阶段，即慢开始阶段、拥塞避免阶段和出现拥塞阶段。出现拥塞阶段在图中是最下方的虚线框，里面分为两种不同的情况，一种是出现超时，另一种是收到了 3 个重复的确认 ACK。
② 这里应当强调的是，当网络出现拥塞时，并没有一个什么机构来通知发送端使其降低发送速率。发送端探测网络是否发生了拥塞是根据能否及时收到对方发来的确认。如果出现了超时（就是在设定的时间内收不到对方发来的确认），就说明发生了报文段的丢失。TCP 认为，报文段的丢失就是网络发生拥塞的重要信息。因此，不管 TCP 处在哪一个阶段（慢开始阶段或拥塞避免阶段），只要出现超时，就要把慢开始阶段的门限值 ssthresh 减半，然后就进入到慢开始阶段。拥塞窗口从 1 开始逐渐增大。

③ 但有时还没有到超时重传的时候，就收到了重复的确认 ACK。收到了重复的 ACK 表明某个报文段没有达到接收端，但它后续的报文段却到达了。这就有两种可能性：一种是这个报文段是在途中的某个路由器排队耽误了一些时间，过些时间就会到达接收端；而另一种可能性是这个报文段已经丢失了，以后也不会到达接收端。TCP 认为，如果只收到了一个或两个重复的 ACK，那么这个报文段还可能没有丢失，还应当再等待一下。但是，如果一连收到了 3 个重复的 ACK，那么就应当认为这个报文段大概是丢失了。于是立即重传这个报文段，并把门限值减半，然后进入拥塞避免阶段。为什么报文段丢失了还不进入到慢开始阶段呢？这是因为，虽然发生了报文段的丢失，但并没有出现超时，而且接收端还能够连续收到 3 个重复的 ACK。这表明虽然出现了拥塞，但拥塞的程度并不像出现超时那样严重。因此，TCP 没有必要从一个报文段开始发送，而是可以在拥塞窗口减半的基础上把更多的报文段注入到网络中。

部分答案转自： 计算机网络第五章答案复习五（运输层）
转载自《计算机网络（第7版）》著者：谢希仁

点我回顶部 ☚

Fin.

计算机网络（第7版） - 第五章运输层 - 习题相关推荐

计算机网络教程第五版|微课版 - 第五章运输层 - 习题【补充】
第五章.运输层[补充] 本章的习题在 "滑动窗口" 概念中,"发送窗口" 和 "接受窗口" 的作用是什么?如果接受方的接受能力不断地发生变 ...
计算机网络（BYSEE）第五章运输层学习笔记（0606）
第 5 章运输层 5.1 运输层协议概述 5.1.1 进程之间的通信向应用层提供通信服务运输层属于面向通信部分的最高层,同时也是用户功能中的最低层只有网络边缘部分的主机的协议栈才有运输层,网络 ...
材料力学Ⅰ(第六版)第五章课后习题答案
第一章绪论第二章拉伸.压缩与剪切第三章扭转第四章弯曲内力第五章弯曲应力第六章弯曲变形第七章应力和应变分析强度理论第八章组合变形第九章压杆稳定
计算机网络第七版第三章课后习题,《计算机网络·自顶向下方法》第七版第三章课后习题与问题答案...
非官方答案,本人已尽最大努力(包括参考官方答案),使结果正确,如有错误,请大佬指出正文: ###3.1~3.3节 ####R1 a.如果只是简单想把信件送到,那么所有的头部信息只需要一个目的地址就够 ...
微机原理与接口技术[第三版]——第五章课后习题答案
5. 1k×1--16k×8 (1)1位变8位,一组需要8个芯片.1k变16k,需要16组芯片,因此一共128芯片. (2)1k=,需要10位片内寻址. (3)16=,需要4位片选信号. 6. 4K× ...
【计算机网络】南航计算机网络第五章运输层
文章目录计算机网络第五章运输层 5.1 运输层协议概述运输层运输层的重要功能--分用和复用运输层的两个主要协议运输层的端口 5.2 用户数据报协议UDP UDP与IP协议的区别? UDP首 ...
04737 c++ 自学考试2019版第五章程序设计题 1
/* * 04737 c++ 自学考试2019版第五章课后练习 * 程序设计题 1 * 需求:交通工具包含汽车,汽车又包含..... */#include<iostream> #incl ...
贝叶斯统计第二版第五章答案_贝叶斯统计第二部分
贝叶斯统计第二版第五章答案 In this post, I will compare the output of frequentist and Bayesian statistics, and ex ...
数据库系统概念第六版第五章练习题 2 4
数据库系统概念第六版第五章练习题 2 4 5.2 写一个使用JDBC元数据特性的JAVA函数,该函数用ResultSet作为输入参数,并把结果输出为用合适的名字作为列名的表格形式. (对JAVA不太 ...

计算机网络（第7版） - 第五章运输层 - 习题

第五章、运输层

本章的习题

点我回顶部 ☚

计算机网络（第7版） - 第五章运输层 - 习题相关推荐

最新文章

热门文章

计算机网络（第7版） - 第五章 运输层 - 习题

第五章、运输层

本章的习题

点我回顶部 ☚

计算机网络（第7版） - 第五章 运输层 - 习题相关推荐

最新文章

热门文章

计算机网络（第7版） - 第五章运输层 - 习题

计算机网络（第7版） - 第五章运输层 - 习题相关推荐