计算机网络运输层（中）

Posted 2021-06-24 My heart will go ~~

运输层（中）

• 5.TCP报文段的首部格式
• 6.TCP可靠传输的实现
• • 6.1 以字节为单位的滑动窗口
  • 6.2 超时重传时间的选择
  • 6.3 选择确认 SACK
• 7. TCP的流量控制
• • 7.1 利用滑动窗口实现流量控制
  • 7.2 TCP的传输效率

继： 运输层（上）

5.TCP报文段的首部格式

注释：

1. 源端口和目的端口字段——各占 2 字节。端口是运输层与应用层的服务接口。运输层的复用和分用功能都要通过端口才能实现。
2. 序号字段——占 4 字节。TCP 连接中传送的数据流中的每一个字节都编上一个序号。序号字段的值则指的是本报文段所发送的数据的第一个字节的序号。
3. 确认号字段——占 4 字节，是期望收到对方的下一个报文段的数据的第一个字节的序号。
4. 数据偏移（即首部长度）——占 4 位，它指出 TCP 报文段的数据起始处距离 TCP 报文段的起始处有多远。“数据偏移”的单位是 32 位字（以 4 字节为计算单位）。
5. 保留字段——占 6 位，保留为今后使用，但目前应置为 0。
6. 紧急 URG —— 当 URG = 1 时，表明紧急指针字段有效。它告诉系统此报文段中有紧急数据，应尽快传送(相当于高优先级的数据)。
7. 确认 ACK —— 只有当 ACK =1 时确认号字段才有效。当 ACK =0 时，确认号无效。
8. 推送 PSH (PuSH) —— 接收 TCP 收到 PSH = 1 的报文段，就尽快地交付接收应用进程，而不再等到整个缓存都填满了后再向上交付。
9. 复位 RST (ReSeT) —— 当 RST=1 时，表明 TCP 连接中出现严重差错（如由于主机崩溃或其他原因），必须释放连接，然后再重新建立运输连接。
10. 同步 SYN —— 同步 SYN = 1 表示这是一个连接请求或连接接受报文。
11. 终止 FIN (FINish) —— 用来释放一个连接。FIN=1 表明此报文段的发送端的数据已发送完毕，并要求释放运输连接。
12. 窗口字段 —— 占 2 字节，用来让对方设置发送窗口的依据，单位为字节。
13. 检验和 —— 占 2 字节。检验和字段检验的范围包括首部和数据这两部分。在计算检验和时，要在 TCP 报文段的前面加上 12 字节的伪首部。
14. 紧急指针字段 —— 占 16 位，指出在本报文段中紧急数据共有多少个字节（紧急数据放在本报文段数据的最前面）。
15. 选项字段 —— 长度可变。TCP 最初只规定了一种选项，即最大报文段长度 MSS。MSS 告诉对方 TCP：“我的缓存所能接收的报文段的数据字段的最大长度是 MSS 个字节。”
16. 填充字段 —— 这是为了使整个首部长度是 4 字节的整数倍。

6.TCP可靠传输的实现

6.1 以字节为单位的滑动窗口

TCP滑动窗口是以字节为单位。

发送缓存用于存放：1.发送应用程序传送给发送方 TCP 准备发送的数据；2. TCP 已发送出但尚未收到确认的数据。
接收缓存用于存放：1.按序到达的、但尚未被接收应用程序读取的数据；2.不按序到达的数据。
强调

1. 发送窗口不总是和接收窗口一样大（因为由一定的时间滞后
2. TCP没有规定对不按序到达的数据如何处理。通常是先存放在接收窗口中，等所缺少的字节流收到后再按序交付。
3. TCP要求接收方必须有累计确认功能，才能减小传输开销

接收方可以在合适的时候发送确认，也可以在有数据要发送的时候顺便带上确认信息。
注意：

1. 接收方不应该过分推迟发送确认，否则导致重传
2. 捎带确认并不经常发生，因为应用程序很少同时在两个方向上发送数据

6.2 超时重传时间的选择

存在问题：如果超时重传时间太短会造成很多重传，如果时间太长会增大网络空闲，降低传输效率。因此，TCP采用了自适应算法。
加权平均往返时间（RTTs）：

超时重传时间RTO，应略大于RTTs。

其中，RTTd是RTT的偏差的加权平均值。

问题：报文段1没有收到确认，重传报文段2，收到了确认报文段ACK，如何判定此ACK是报文1的确认还是报文2的确认。
在计算平均往返时间 RTT 时，只要报文段重传了，就不采用其往返时间样本，这样得到的RTTs和RTO就较为准确。但是报文段突然增多时，超时重传时间无法更新。
修正Karn算法：报文段每重传一次，就增大一些RTO

6.3 选择确认 SACK

注释：

1. 第一个字节块的左边界 L1 = 1501，右边界 R1 = 3001。左边界指出字节块的第一个字节的序号，右边界减 1 才是字节块中的最后一个序号。
2. 第二个字节块的左边界 L2 = 3501，而右边界 R2 = 4501。

存在问题：若收到的报文段无差错，只是未按序号，中间还缺少一些序号的数据，那么能否设法只传送缺少的数据而不重传已经正确到达接收方的数据？
解决方法：选择确认SACK。如果使用选择确认，那么在建立TCP时，就要在TCP首部选项中加上“”允许SACK“选项。由于首部选项长度最多为40字节，指明一个边界用掉4字节，所以选项中最多只能指明4个字节快的边界信息

7. TCP的流量控制

7.1 利用滑动窗口实现流量控制

存在问题：如果发送发数据发送得过快，接收方来不及接收，会造成数据的丢失。
流量控制：发送速率不太快，既要能及时接收，也不使网络拥塞。滑动窗口可实现

存在死锁情况：最后B发送给A的报文段丢失了，A等B发送的非零窗口通知，B等A发送的数据。
解决方案：为每一个连接设置一个持续计时器。
使用思路：

1. 只要一方收到对方的零窗口通知，就启动持续计时器。
2. 如果计时器时间到期，就发送一个零窗口探测报文段，对方确认时给出现窗口值
3. 若窗口是0，收到报文段的一方重置计时器
4. 窗口不是0，打破死锁。

7.2 TCP的传输效率

三种不同机制控制TCP报文发送时机：

1. TCP 维持一个变量，等于最大报文段长度 MSS。只要缓存中存放的数据达到 MSS 字节时，就组装成一个 TCP 报文段发送出去。
2. 发送方的应用进程指明要求发送报文段，即 TCP 支持的推送 (push) 操作。
3. 发送方的一个计时器期限到了，这时就把当前已有的缓存数据装入报文段（但长度不能超过 MSS）发送出去。

存在问题：每次仅发送一个字节或很少的几个字节时，有效数据传输效率很低。
解决方法：使用Nagle算法

（个人理解：保证每次传输的数据比较大

存在问题：如果每次接收方发送一个窗口大小为一个字节的更新报文，发送方就发送一个字节的数据，再次降低了传输效率。
解决方法：让接收方等待一段时间，使得缓存能容纳一个最长报文段或者缓存有一半空闲的时间。此时接收方发出确认报文，并向发送方通知当前窗口大小。