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

第五章

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

在图中主机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
目的端口6900 45
用户数据报总长度28 字节00 1C其中首部占8字节
数据部分长度20 字节
这个用户数据报是从客户发送给服务器
服务器程序TFTP。
UDP数据报由首部字段和数据字段组成其中首部占8个字节TCP数据报首部占20字节格式如下:

以上求出的长度为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所示的双方交换报文段的过程。
答
我们可以看出旧的M0被当成是新的M0可见运输层不能使用停止等待协议编号只有 0 和1 两种。
19.试证明当用 n 比特进行分组的编号时若接收到窗口等于 1即只能按序接收分组当仅在发送窗口不超过$2^n-1$时连接 ARQ 协议才能正确运行。窗口单位是分组。
答

Ⅰ、设发送窗口记为 W_T接收窗口记为 W_R。假定用 3 比特进行编号。设接收窗口正好在 7 号分组处有阴影的分组。
Ⅱ、发送窗口 W_T的位置不可能比 ② 的位置更靠前。因为接收窗口的位置表明接收方正在等待接收 7 号分组而这时的发送方不可能已经收到了对 7 号分组的确认。因此发送窗口必须包括 7 号分组也就是不可能比 ② 的位置更靠前前方就是图的右方。
Ⅲ、发送窗口 W_T的位置不可能比 ③ 的位置更靠后。因为接收窗口的位置表明接收方已经对 6 号分组以及以前的分组发送了确认。但如果发送窗口 W_T的位置再靠后一个分组即在 6 号分组的左边那就表明还没有发送 6 号分组。但接收方的位置表明接收方已经发送了对 6 号分组的确认。这显然是不可能的。
Ⅳ、发送窗口 W_T的位置可能在某个位置的中间如 ①。
对于 ① 和 ② 的情况在 W_T的范围内必须无重复序号即 W_T ⩽ $2^n$。
对于 ③ 的情况在 W_T+ W_R的范围内无重复序号即 W_T + W_R ⩽ $2^n$。
现在 W_R = 1,故发送窗口的最大值W_T ⩽ $2^n-1$。
20.在连续 ARQ 协议中若发送窗口等于 7则发送端在开始时可连续发送 7 个分组。因此在每一分组发送后都要置一个超时计时器。现在计算机里只有一个硬时钟。设这 7 个分组发出的时间分别为 t₀,t₁,…t₆,且t_out都一样大。试问如何实现这 7 个超时计时器这叫软件时钟法
答
方法1可采用链表记录其信息域为分组的相对发送时间和分组编号来实现。当编号为 0 的分组定时时钟到期后修改链表指针并重发此分组同时将头指针指向编号为 1 的分组以此类推。此类方法相当于数据结构算法里的链表建立的过程。我有一篇C++的链表文章可以参考。

方法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 的分组说明序号为 234 的分组都已收到并且发送了确认。对序号为 1 的分组的确认肯定被发送方收到了否则发送方不可能发送 4 号分组。可见对序号为 234 的分组的确认有可能仍滞留在网络中。这些确认是用来确认序号为 234 的分组的。
22.主机 A 向主机 B 发送一个很长的文件其长度为 L 字节。假定 TCP 使用的 MSS 有 1460 字节。
1在 TCP 的序号不重复使用的条件下L 的最大值是多少
2假定使用上面计算出文件长度而运输层、网络层和数据链路层所使用的首部开销共 66 字节链路的数据率为 10 Mb/s试求这个文件所需的最短发送时间
答1可能的序号共 $2^{32}$=4294967296 个。TCP 的序号是数据字段中每一个字节的编号而不是每一个报文段的编号。因此这一小题与报文段的长度无关即用不到题目给出的 MSS 值。这个文件 L 的最大值就是可能的序号数即 4294967296 字节。若1GB= $2^{30}$B则 L 的最大值为 4 GB。
2发送帧数等于数据字节/每帧的数据字节=$2^{32}$/1460=2941758.422需要发送 2941759 个帧。
帧首部的开销是 66×2941759 = 194156094 字节。
发送的总字节数 = $2^{32}$ + 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 字节的数据。
2B 期望收到下一个报文段的第一个数据字节的序号为 100因此确认号为 100。
3A 发送的第二个报文段中的数据中的字节数是 180 - 100 = 80 字节实际上就是序号 100 到序号 179 的字节即 179 - 100 + 1 = 80 字节
4B 在第二个报文段到达后向 A 发送确认其确认号应为 70。报文段丢失就会重复发送确认上一个未收到的报文段第一个序号即 70
24.一个 TCP 连接下面使用 256 kb/s 的链路其端到端时延为 128 ms。经测试发现吞吐量只有 120 kb/s。试问发送窗口 W 是多少提示可以有两种答案取决于接收端发出确认的时机。
答设发送窗口 = Wbit再设发送端连续发送完窗口内的数据所需要的时间 = T。有两种情况
a接收端在收完一批数据的最后才发出确认因此发送端经过 (256 ms + T) 后才能发送下一个窗口的数据。
b接收端每收到一个很小的报文段就发回确认因此发送端经过比 256 ms 略多一些的时间即可在发送数据。因此每经过 256 ms 就能发送一个窗口的数据。

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$ − 1 = 65535 字节
TCP 报文段的数据部分 = IP 数据报的最大长度 - IP 数据报的首部 - TCP 报文段的首部 = 65535 - 20 - 20 = 65495 字节
一个 TCP 报文段的最大载荷是 65515 字节.
IP数据报的最大长度为 $2^{1}6$ − 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样本时RTT_S就取值RTT样本值为1.5s。RTT_S=1.5s
根据RFC2988的建议RTT_D取值为RTT样本值的一半。
RTT_D=0.75s
根据公式可得RTO=RTT_S+4RTT_D=1.5s+3s=4.5s
2新的RTT样本为2.5s。根据RFC6298推荐α取1/8β取1/4。
即新的RTT_S=1-α×旧的RTT_S)+α×新的RTT样本=1.625s
新的RTT_D=1-β×旧的RTT_D)+β×|RTT_S-新的RTT样本|=0.78s
根据公式RTO=RTT_S+4RTT_D=1.625s+4×0.78s=4.75s
34.已知第一次测得 TCP 的往返时延的当前值 RTT 是 30 ms。现在收到了三个接连的确认报文段它们比相应的数据报文段的发送时间分别滞后的时间是26 ms32 ms 和24 ms。设 α = 0.1。试计算每一次的新的加权平均往返时间值RTT_S。讨论所得出的结果。
解公式即新的RTT_S=1-α×旧的RTT_S)+α×新的RTT样本
第一次RTT_s=1-0.1×30ms+0.1×26ms=29.6ms
第二次RTT_S=1-0.1×29.6ms+0.1×32ms=29.86ms
第三次RTT_S=1-0.1×29.86ms+0.1×24ms=29.256ms
三次的加权平均时间相差不大当RTT样本值变化不大时RTT_s的变化也是很小的。
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}$KB=1MB也就是来回十次就可以了经过10个RTT发送窗口大小达到1MB。

(2)从图中可看出当第10个RTT结束时已传送成功的分组是$2^{10}-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}$B=10×$2^{20}$×8bit
时间=14×50ms=0.7s
有效吞吐率=10×$2^{20}$×8bit/0.7s=119.8Mbit/s
带宽利用率=吞吐量/带宽
带宽利用率=119.8Mbit/s/1Gbit/s×100%=11.98%
36.假定TCP采用一种仅使用线性增大和乘法减小的简单拥塞控制算法而不使用慢开始。发送窗口不采用字节为计算单位而是使用分组pkt为计算单位。在一开始发送窗口为1pkt。假定分组的发送时延非常小可以忽略不计。所有产生的时延就是传播时延。假定发送窗口总是小于接收窗口。接收端每收到一分组后就立即发回确认ACK。假定分组的编号为i在一开始发送的是i=1的分组。以后当i=925303850时发生了分组的丢失。再假定分组的超时重传时间正好是下一个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。

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 按指数规律增长因此随后窗口大小分别为 248。当拥塞窗口 cwnd = ssthresh 时进入拥塞避免阶段其窗口大小依次是 9101112直到上升到 12 为止发生拥塞然后把门限值 ssthresh 设置为当前的拥塞窗口值乘以 0.5门限值 ssthresh 变为6,然后进入慢开始cwnd 值置为1cwnd 按指数规律增长随后窗口大小分别为 1246。当拥塞窗口 cwnd = ssthresh 时进入拥塞避免阶段其窗口大小依次是 789。
39.TCP 的拥塞窗口 cwnd 大小与传输轮次 n 的关系如表所示

1试画出如教材中图 5-25 所示的拥塞窗口与传输轮次的关系曲线。
2指明 TCP 工作在慢开始阶段的时间间隔。
3指明 TCP 工作在拥塞避免阶段的时间间隔。
4在第 16 轮次和第 22 轮次之后发送方是通过收到三个重复的确认还是通过超时检测到丢失了报文段
5在第 1 轮次第 18 轮次和第 24 轮次发送时门限 ssthresh 分别被设置为多大
6在第几轮次发送出第 70 个报文段
7假定在第 26 轮次之后收到了三个重复的确认因而检测出了报文段的丢失那么拥塞窗口 cwnd 和门限 ssthresh 应设置为多大
答(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。
40.TCP 在进行流量控制时是以分组的丢失作为产生拥塞的标志。有没有不是因拥塞而引起的分组丢失的情况?如有请举出三种情况。
答不是因为拥塞而引起分组丢失的情况是有的举例如下
① 当 IP 数据报在传输过程中需要分片但其中一个数据报片未能及时到达终点而终点组装 IP 数据报已超时因而只能丢弃该数据报。
② IP 数据报已经到达终点但终点的缓存没有足够的空间存放此数据报。
③ 数据报在转发过程中经过一个局域网的网桥但网桥在转发该数据报的帧时没有足够的储存空间而只好丢弃。
41.用 TCP 传送 512 字节的数据。设窗口为 100 字节而 TCP 报文段每次也是传送 100 字节的数据。再设发送端和接收端的起始序号分别选为 100 和 200试画出类似于教材中图 5-31 的工作示意图。从连接建立阶段到连接释放都要画上。
要传送的 512 B 的数据必须划分为 6 个报文段传送前 5 个报文段各 100 B最后一个报文段传送 12 B。下图是双方交互的示意图。下面进行简单的解释。
【----- 进行三报文握手 -----】
报文段 #1A 发起主动打开发送 SYN 报文段除以 SYN-SENT 状态并选择初始序号 seq = 100。B 处于 LISTEN 状态。
报文段 #2B 确认 A 的 SYN 报文段因此 ack = 101是 A 的初始序号加 1。B选择初始序号 seq = 200。B 进入到 SYN-RCVD 状态。
报文段 #3A 发送 ACk 报文段来确认报文段 #2ack = 201是 B 的初始序号加 1。A 没有在这个报文段中放入数据。因为 SYN 报文段 #1 消耗了一个序号因此报文段 #3 的序号是 seq = 101。这样A 和 B 都进入了 ESTABLISHED 状态。
【----- 三报文握手完成 -----】

【----- 开始数据传送 -----】
报文段 #4A 发送 100 字节的数据。报文段 #3 是确认报文段没有数据发送报文段 #3 并不消耗序号因此报文段 #4 的序号仍然是 seq = 101。A 在发送数据的同时还确认 B 的报文段 #2因此 ack = 201。
报文段 #5B 确认 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。
报文段 #14A 发送最后 12 字节的数据报文段 #14 的序号是 seq = 601。
报文段 #15B 发送对报文段 #14 的确认。B 收到从序号 601 到 602 共 12 字节的数据。因此报文段 #15 的确认号是 ack = 613所期望收到的下一个数据字节的序号。
需要注意的是从报文段 #5 一直到 报文段 #15B 一共发送了 6 个确认都不消耗序号因此 B 发送的报文段 #15 的序号仍然和报文段 #5 的序号一样即 seq = 201。
【-----数据传送完毕-----】
【-----进行四报文挥手------】
报文段 #16A 发送 FIN 报文段。前面所发送的数据报文段 #14 已经用掉了序号 601 到 612因此报文段 #16 序号是 seq = 613。A 进入 FIN-WAIT-1 状态。报文段 #16 的确认号 ack = 202。
报文段 #17B发送确认报文段确认号为 614进入 CLOSE-WAIT 状态。由于确认报文段不消耗序号因此报文段 #17 的序号仍然和报文段 #15 的一样即 seq = 201
报文段 #18B 没有数据要发送就发送 FIN 报文段 #18其序号仍然是 seq = 201。这个 FIN 报文会消耗一个报文。
报文段 #19A 发送最后的确认报文段。报文段 #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.试以具体例子说明为什么一个运输连接可以有多种方式释放。可以设两个互相通信的用户分别连接在网络的两结点上。
答设 AB建立了运输连接。
协议应考虑一下实际可能性 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) +
再看图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$)的报文段。
那么一共可以发送的比特数为255×128×8=261120bit
数据率=比特数/时间
最高数据率=261120bit/30s=8704bit/s
49.下面是以十六进制格式存储的一个 UDP 首部
CB84000D001C001C
试问:
(1) 源端口号是什么
(2) 目的端口号是什么
(3) 这个用户数据报的总长度是什么
(4) 数据长度是多少
(5)这个分组是从客户到服务器还是从服务器到客户
(6) 客户进程是什么
答(1)源端口号是最前面的四位十六进制数(CB84)₁₆=(52100)₁₀
(2)目的端口号是五到八位的十六进制数(000D)₁₆=(13)₁₀
(3)用户数据报的长度由九到十二位十六进制数决定(001C)₁₆=(28)₁₀字节。
(4)数据长度=数据报长度-首部长度=28字节-8字节=20字节。
(5)因为目的端口是 13 熟知端口所以这个分组是从客户到目的端口。
(6)从 RFC 867 可以得知这个客户进程是 Daytime。当 Daytime 服务器收到客户发送的 UDP 用户数据报后就把现在的日期和时间以 ASCII 码字符串的形式返回给客户。
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。
答1UDP 规定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 个。号码小在后面即在图的左方。另外一点要注意的是发送方收到的确认号表示接收方期望能够收到序号。这个序号应当在发送窗口的最前面。

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 = 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
答在这个报文段中的确认字段应当写入的是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×$10^7$bit
我们知道每一个字节的数据需要有一个编号。假定发送窗口一共有 w 位那么总的号码数应当大于1.75×$10^7$字节即$2^w$>17500000那么w>24.06那么发送窗口至少为25位。
可见只用 24 位的发送窗口差一点必须使用 w = 25 位的发送窗口才行。TCP 的窗口字段为 16 位。
再看看 60 秒钟以1Gbit/s 的速率可以发送 60s×$10^9$bit/s=7.5×$10^9$字节的数据。
假定需要 n 位的序号字段那么总的序号数应当大于 7.5×$10^9$字节即
$2^n$ > 7.5 × $10^9$,求得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×$10^9$个字节。TCP序号共有$2^{32}$个。那么需要经过$2^{32}$/$5\times 10^9$=0.859s就会发生TCP序号绕回。
(2)时间戳绕回时间$2^{3}2$×0.000859s=3.69×$10^6$=42.7天。
71. 5.5 节中指出例如若用 2.5 Gbit/s 速率发送报文段则不到 14 秒钟序号就会重复。请计算验证这句话。
证明2.5Gbit/s的速率那么每秒就可以发送0.3125×$10^9$个字节一共有$2^{32}$个序号$2^{32}$/0.3125×$10^9$=13.74S。所以这不到14秒TCP序号就会发生绕回。
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。因此这种情况在发送时数据是在发送窗口之内但到达接收端这些数据却落入到接收窗口之外必须避免。总之我们要记住接收窗口是不允许后退的。
73.在上题中如果接收方突然因某种原因不能够再接收数据了可以立即向发送方发送把接收窗口置为零的报文段即 rwnd = 0。这时会导致接收窗口的前沿后退。试问这种情况是否允许
答这种情况是允许的。当发送方收到这样的信息并不是把发送窗口缩回到零而是立即停止发送。什么时候可以再发送数据就要等接收方重新开放接收窗口即给出一个非零的接收窗口。
74.流量控制和拥塞控制的最主要的区别是什么发送窗口的大小取决于流量控制还是拥塞控制
简单地说流量控制是在一条 TCP 连接中的接收端才用的措施用来限制对方发送端发送报文的速率以免在接收端来不及接收。流量控制只控制一个发送端。
拥塞控制是用来控制 TCP 连接中发送端发送报文段的速率以免使互联网中的某处产生过载。拥塞控制可能会同时控制许多个发送端限制它们的发送速率。不过每一个发送端只知道自己应当怎样调整发送速率而不知道在互联网中还有哪些主机被限制了发送速率。
我们知道发送窗口的上限值是 Min [rwnd, cwnd]即发送窗口的数值不能超过接收窗口和拥塞窗口中娇小的一个。接收窗口的大小体现了接收端对发送端施加的流量控制而拥塞窗口的大小则是整个互联网的负载情况对发送端施加的拥塞控制。因此当接收窗口小于拥塞窗口时发送窗口的大小取决于流量控制即取决于接收端的接收能力。但当拥塞窗口小于接收窗口时则发送窗口的大小取决于拥塞控制即取决于整个网络的拥塞状况。