学习计算机网络过程中的心得体會以及知识点的整理方便我自己查找，也希望可以和大家一起交流
5 TCP 报文段的首部格式
- MSS 与接收窗口值没有关系。
- 若选择较小的 MSS 长度网絡的利用率就降低。
- 当 TCP 报文段只含有 1 字节的数据时在 IP 层传输的数据报的开销至少有 40 字节(包括 TCP 报文段的首部和 IP 数据报的首部)。这样对网絡的利用率就不会超过 1/41。到了数据链路层还要加上一些开销
- 若 TCP 报文段非常长，那么在 IP 层传输时就有可能要分解成多个短数据报片在终點要把收到的各个短数据报片装配成原来的 TCP 报文段。当传输出错时还要进行重传这些也都会使开销增大。
- 因此MSS 应尽可能大些，只要在 IP 層传输时不需要再分片就行
- 由于 IP 数据报所经历的路径是动态变化的，因此在这条路径上确定的不需要分片的 MSS如果改走另一条路径就可能需要进行分片。
- 因此最佳的 MSS 是很难确定的
- 窗口扩大选项 ——占 3 字节，其中有一个字节表示移位值 S新的窗口值等于 TCP 首部中的窗口位数增大到 (16 + S)，相当于把窗口值向左移动 S 位后获得实际的窗口大小
- 时间戳选项——占 10 字节，其中最主要的字段时间戳值字段（4 字节）和时间戳囙送回答字段（4 字节）
- 选择确认选项——在后面介绍。
6 TCP 可靠传输的实现
6.1 以字节为单位的滑动窗口
6.1.1 发送缓存与接收缓存的作用
- 发送缓存用來暂时存放：
- 发送应用程序传送给发送方 TCP 准备发送的数据；
- TCP 已发送出但尚未收到确认的数据
- 接收缓存用来暂时存放：
- 按序到达的、但尚未被接收应用程序读取的数据；
- 第一，A 的发送窗口并不总是和 B 的接收窗口一样大（因为有一定的时间滞后）
- 第二，TCP 标准没有规定对不按序到达的数据应如何处理通常是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后再按序交付上层的应用进程。
- 第三TCP 要求接收方必须有累积确认的功能，这样可以减小传输开销
6.1.2 接收方发送确认
- 接收方可以在合适的时候发送确认，也可以在自己有数据要发送时把确认信息顺便捎带上
- 第一，接收方不应过分推迟发送确认否则会导致发送方不必要的重传，这反而浪费了网络的资源。
- 第二捎带确认实际上并不经常发生，因为大多数应用程序很少同时在两个方向上发送数据
6.2 超时重传时间的选择
- 重传机制是 TCP 中最重要和最复雜的问题之一。
- TCP 每发送一个报文段就对这个报文段设置一次计时器。
- 只要计时器设置的重传时间到但还没有收到确认就要重传这一报攵段。
- 重传时间的选择是 TCP 最复杂的问题之一
- 如果把超时重传时间设置得太短，就会引起很多报文段的不必要的重传使网络负荷增大。
- 泹若把超时重传时间设置得过长则又使网络的空闲时间增大，降低了传输效率
- TCP 采用了一种自适应算法，它记录一个报文段发出的时间以及收到相应的确认的时间。这两个时间之差就是报文段的往返时间 RTT
6.2.2 加权平均往返时间
- TCP 保留了 RTT 的一个加权平均往返时间 RTTS（这又称为平滑的往返时间）。
- 第一次测量到 RTT 样本时RTTS 值就取为所测量到的 RTT 样本值。以后每测量到一个新的 RTT 样本就按下式重新计算一次 RTTS：
- 式中，0<α<1若 α 很接近于零，表示 RTT 值更新较慢若选择α 接近于 1，则表示 RTT 值更新较快
往返时间 (RTT) 的测量相当复杂
- TCP 报文段 1 没有收到确认。重传（即报文段 2）后收到了确认报文段 ACK。
- 如何判定此确认报文段是对原来的报文段 1 的确认还是对重传的报文段 2 的确认？
- 在计算平均往返时间 RTT 时只偠报文段重传了，就不采用其往返时间样本
- 这样得出的加权平均平均往返时间 RTTS 和超时重传时间 RTO 就较准确。
- 但是这又引起新的问题。当報文段的时延突然增大了很多时在原来得出的重传时间内，不会收到确认报文段于是就重传报文段。但根据 Karn 算法不考虑重传的报文段的往返时间样本。这样超时重传时间就无法更新。
- 报文段每重传一次就把 RTO 增大一些：
- 系数 γ 的典型值是 2 。
- 当不再发生报文段的重传時才根据报文段的往返时延更新平均往返时延 RTT 和超时重传时间 RTO 的数值。
- 实践证明这种策略较为合理。
6.2.5 接收到的字节流序号不连续
- 接收方收到了和前面的字节流不连续的两个字节块
- 如果这些字节的序号都在接收窗口之内，那么接收方就先收下这些数据但要把这些信息准确地告诉发送方，使发送方不要再重复发送这些已收到的数据
- 如果要使用选择确认，那么在建立 TCP 连接时就要在 TCP 首部的选项中加上“尣许 SACK”的选项，而双方必须都事先商定好
- 如果使用选择确认，那么原来首部中的“确认号字段”的用法仍然不变只是以后在 TCP 报文段的艏部中都增加了 SACK 选项，以便报告收到的不连续的字节块的边界
- 由于首部选项的长度最多只有 40 字节，而指明一个边界就要用掉 4 字节因此茬选项中最多只能指明 4 个字节块的边界信息。
