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 连接处于状态 。以下的事件相继发生：
（1）收到一个 FIN 报文段
（2）应用程序发送 “关闭” 报文
在每一个事件之后，连接的状态是什么？在每一个事件之后发生的动作是什么？
（1）收到FIN=1进入关闭等待
（2）客户机收到应用程序的关闭报文，进入终止等待1状态
5-63 TCP 连接处于 SYN-RCVD 状态 。以下的事件相继发生：
（1）应用程序发送 “关闭” 报文
（2）收到 FIN 报文段
在每一个事件之后，连接的状态是什么？在每一个事件之后发生的动作是什么？
答：在收到一个FIN报文段后连接的状态是，发生的动作是发送ACK确认报文段；
在应用程序发送“关闭”报文后的连接状态是LAST-ACK状态，发生的动作是发送FIN报文段 。
5-64 TCP 连接处于 FIN-WAIT-1 状态 。以下的事件相继发生：
（1）收到 ACK 报文段
（2）收到 FIN 报文段
（3）发生了超时
在每一个事件之后，连接的状态是什么？在每一个事件之后发生的动作是什么？
在应用程序发送“关闭”报文后的连接状态是FIN WAIT状态，之后发生的动作是发送FIN报文段；
收到一个FIN报文段之后，连接状态是，之后发生的动作是发送ACK确认报文段 。
5-66主机 A 通过 TCP 连接向 B 发送一个很长的文件，因此这需要分成很多个报文段来发送 。假定某一个 TCP 报文段的序号是 x，那么下一个报文段的序号是否就是 x + 1 呢？
不是，因为可能后边的是重传的数据报，因为报文段被分开了
【下面是以十六进制格式存储的一个 UDP 首部：~~~TCP连接使用1000字节的】