下面是以十六进制格式存储的一个 UDP 首部：~~~TCP连接使用1000字节的窗口值，而上一次的确认号是22001~~那么下一个报文段的序号是否就是 x + 1 呢？在本题中列出的 8 种情况下，画

5-10 试说明运输层中伪首部的作用
用于计算运输层数据报校验和
5-11 某个应用进程使用运输层的用户数据报UDP，然而继续向下交给IP层后，又封装成IP数据报。既然都是数据报，可否跳过UDP而直接交给IP层？哪些功能UDP提供了但IP没提提供？
不可跳过UDP而直接交给IP层。 IP数据报IP报承担主机寻址，提供报头检错；只能找到目的主机而无法找到目的进程。 UDP提供对应用进程的复用和分用功能，以及提供对数据差分的差错检验。
5-12 一个应用程序用UDP，到IP层把数据报在划分为4个数据报片发送出去，结果前两个数据报片丢失，后两个到达目的站。过了一段时间应用程序重传UDP，而IP层仍然划分为4个数据报片来传送。结果这次前两个到达目的站而后两个丢失。试问：在目的站能否将这两次传输的4个数据报片组装成完整的数据报？假定目的站第一次收到的后两个数据报片仍然保存在目的站的缓存中
答:不行 重传时, IP 数据报的标识字段会有另一个标识符,仅当标识符相同的 IP 数据报片才能组装成一个 IP 数据报。前两个 IP 数据报片的标识符与后两个 IP 数据报片的标识符不同,因此不能组装成一个 IP 数据报
5-13 一个UDP用户数据的数据字段为8192字节。在数据链路层要使用以太网来传送。试问应当划分为几个IP数据报片？说明每一个IP数据报字段长度和片偏移字段的值
答: 6 个 数据字段的长度:前 5 个是 1480 字节,最后一个是 800 字节。片偏移字段的值分别是: 0 , 1480 , 2960 , 4440 , 5920 和 7400
5-14 一UDP用户数据报的首部十六进制表示是：06 32 00 45 00 1C E2 17.试求源端口、目的端口、用户数据报的总长度、数据部分长度。这个用户数据报是从客户发送给服务器发送给客户？使用UDP的这个服务器程序是什么？

源端口1586,目的端口69,UDP用户数据报总长度28字节,数据部分长度20字节。 此UDP用户数据报是从客户发给服务器(因为目的端口号<1023,是熟知端口),服务器程序是tftp

5-49 下面是以十六进制格式存储的一个 UDP 首部：
CB84000D001C001C
试问：
（1）源端口号是什么？
（2）目的端口号是什么？
（3）这个用户数据报的总长度是什么？
（4）数据长度是多少？
（5）这个分组是从客户到服务器方向的，还是从服务器到客户方向的？
（6）客户进程是什么？
答：
（1）源端口52100,
（2）目的端口13,
（3）UDP用户数据报总长度28字节,
（4）数据部分长度20字节
（5）此UDP用户数据报是从客户发给服务器,
（6）DayTime应用进程

5-53 UDP 用户数据报的最小长度是多少？用最小长度的 UDP 用户数据构成的最短 IP 数据报的长度是多少？
以字节为单位，最小值为8字节，即没有数据时的长度。
最短IP数据报首部固定长度20字节所以等于20+8最短IP数据报28字节

5-54 某客户使用UDP将数据发送给一服务器，数据共16字节，试着计算在运输层的传输效率
UPD用户数据报的总长度=8+16=24字节。 因此,在运输层的传输效率=16/24=0.667

5-55 重做54，但在IP层计算传输效率。假定IP首部无选项
答：IP数据报的总长度=20+24=44字节。要在IP层的传输效率=16/44=0.324

5-56 重做54，但在数据链路层计算传输效率。假定IP首部无选项，在数据链路层使用以太网
答；以太网有14字节的首部，4字节的尾部（FCS字段）。但其数据字段的最小长度是46字节，而我们的IP数据报仅有44字节，因此还必须加上2字节的填充。这样，以太网的总长度=14+4+2+44=64字节
因此，在数据链路层的传输效率=16/64=0.25
如果再考虑到发送以太网的帧之前还有8字节的前同步码。把这8字节计入后，在数据链路层的传输效率=16/72=0.222

5-21 使用连续ARQ协议中，发送窗口大小事3，而序列范围[0,15],而传输媒体保证在接收方能够按序收到分组。在某时刻，接收方，下一个期望收到序号是5
试问：
（1）在发送方的发送窗口中可能有出现的序号组合有哪几种？
（2）接收方已经发送出去的、但在网络中（即还未到达发送方）的确认分组可能有哪些？说明这些确认分组是用来确认哪些序号的分组
答：
（1）序号到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的分组

5-22 主机A向主机B发送一个很长的文件，其长度为L字节。假定TCP使用的MSS有1460字节
（1）在TCP的序号不重复使用的条件下，L的最大值是多少？
（2）假定使用上面计算出文件长度，而运输层、网络层和数据链路层所使用的首部开销共66字节，链路的数据率为10Mb/s，试求这个文件所需的最短发送时间
答：
（ 1 ） L 的最大值是 2^ 32=4GB=4294967296 字节
因为TCP报文 序号 字段——占 4 字节（32位）。TCP 连接中传送的数据流中的每一个字节都编上一个序号。序号字段的值则指的是本报文段所发送的数据的第一个字节的序号。 L是让求文件的长度，即TCP报文 序号 字段最多可以表示的字节的总数
（2 ）每次发送的报文段为 1460 字节。因此必须分4294967296/1460 取整为2941758，因为有余数，所以29417598+1即 2941759 个报文段。（而不是2941758）发送的总字节数是 2941759*66+4294967296=4489123390 字节
发送 4489123390 字节需时间为 4489123390 × 8 ÷10Mb/s=3591.3 秒≈ 59.85 分≈ 1 小时
5-23 主机A向主机B连续发送了两个TCP报文段，其序号分别为70和100。试问：
（1）第一个报文段携带了多少个字节的数据？
（2）主机B 收到第一个报文段后发回的确认中的确认号应当是多少？
（3）如果主机B收到第二个报文段后发回的确认中的确认号是180，试问A发送的第二个报文段中的数据有多少字节？
（4）如果A发送的第一个报文段丢失了，但第二个报文段到达了B。B在第二个报文段到达后向A 发送确认。试问这个确认号应为多少？
答：
（1）第一个报文段的数据序号是70到99，共30字节的数据。
（2）确认号应为100。
（3）180-100=80 字节。
（4） 70

5-27一个TCP报文段的数据部分最多为多少个字节？为什么？如果用户要传送的数据的字节长度超过TCP报文字段中的序号字段可能编出的最大序号，问还能否用TCP来传送？
TCP报文段的数据部分=IP数据报的最大长度-IP数据报的首部-TCP报文段的首部=65535-20-20=65495（字节）
一个tcp报文段的最大载荷是65515字节
IP数据报的最大长度为2^16-1=65536B,减去IP数据报首部20B和TCP首部20B后的TCP报文段的数据部分为65495B

5-28主机A向主机B发送TCP报文段，首部中的源端口是m而目的端口是n。当B向A发送回信时，其TCP报文段的首部中源端口和目的端口分别是什么？
答：源端口n和目的端口m

5-46 试用具体例子说明为什么在运输连接建立时要使用三次握手。说明如不这样做可能会出现什么情况
正确答案：我们知道3次握手完成两个重要的功能既要双方做好发送数据的准备工作(双方都知道彼此已准备好)也要允许双方就初始序列号进行协商这个序列号在握手过程中被发送和确认。 现在把三次握手改成仅需要两次握手死锁是可能发生的。例如考虑计算机A和B之间的通信。假定B给A发送一个连接请求分组A收到了这个分组并发送了确认应答分组。按照两次握手的协定A认为连接已经成功地建立了可以开始发送数据分组。可是在A的应答分组在传输中被丢失的情况下B将不知道A是否已准备好不知道A建议什么样的序列号B甚至怀疑A是否收到自己的连接请求分组。在这种情况下B认为连接还未建立成功将忽略A发来的任何数据分组只等待连接确认应答分组。而A在发出的分组超时后重复发送同样的分组。这样就形成了死锁。 本题考查在面向连接的TCP通行时，采用“三次握手”的必要性。

5-29 在使用TCP传送数据时，如果有一个确认报文段丢失了，也不一定会引起与该确认报文段对应的数据的重传。试说明理由

答：还未重传就收到了对更高序号的确认
因为TCP接收方只会对按序到达的最后一个分组发送确认
当对更高的序号确认了 意味着已经到达了，即不用重传了

5-59 TCP连接使用1000字节的窗口值，而上一次的确认号是22001。它收到了一个报文段，确认了字节22401。试用图来说明在这之前与之后的窗口情况

5-60 同上题，但在接收方收到的字节为22401的报文段时，其窗口字段变为1200字节。试用图来说明在这之前与之后的窗口情况

5-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 的确认报文段。
下图是发送窗口和可用窗口的变化情况。

5-65假定主机 A 向 B 发送一个 TCP 报文段。在这个报文段中，序号是 50，而数据一共有 6 字节长。试问，在这个报文段中的确认字段是否应当写入 56 ？
错误。主机A向主机B发送报文（序号为50，字节数为6），假如B成功收到该报文段，并向复A发送确认报文段，这个确认报文段中的确认号才是56（告诉A，我现在收到这个你发的报文段了，你可以发从制56开始发送了），而不是最初从A发向B的那个报文段的确认号是56。即主机A填充进报文段的确认号是主机A期望从主机B收到的下一字节的序号

5-62 TCP 连接处于 ESTABLISHED 状态。以下的事件相继发生：
（1）收到一个 FIN 报文段
（2）应用程序发送 “关闭” 报文
在每一个事件之后，连接的状态是什么？在每一个事件之后发生的动作是什么？

（1）收到FIN=1进入关闭等待
（2）客户机收到应用程序的关闭报文，进入终止等待1状态

5-63 TCP 连接处于 SYN-RCVD 状态。以下的事件相继发生：
（1）应用程序发送 “关闭” 报文
（2）收到 FIN 报文段
在每一个事件之后，连接的状态是什么？在每一个事件之后发生的动作是什么？

答：在收到一个FIN报文段后连接的状态是CLOSEWAIT，发生的动作是发送ACK确认报文段；
在应用程序发送“关闭”报文后的连接状态是LAST-ACK状态，发生的动作是发送FIN报文段。

5-64 TCP 连接处于 FIN-WAIT-1 状态。以下的事件相继发生：
（1）收到 ACK 报文段
（2）收到 FIN 报文段
（3）发生了超时
在每一个事件之后，连接的状态是什么？在每一个事件之后发生的动作是什么？

在应用程序发送“关闭”报文后的连接状态是FIN WAIT状态，之后发生的动作是发送FIN报文段；
收到一个FIN报文段之后，连接状态是CLOSING，之后发生的动作是发送ACK确认报文段。

5-66主机 A 通过 TCP 连接向 B 发送一个很长的文件，因此这需要分成很多个报文段来发送。假定某一个 TCP 报文段的序号是 x ，那么下一个报文段的序号是否就是 x + 1 呢？
不是，因为可能后边的是重传的数据报，因为报文段被分开了

祝您万事顺心，没事点个赞呗，关注一下也行啊，有啥要求您评论哈