正在学习计算机网络课程，以下是学习《计算机网络-自顶向下方法》的一些笔记，部分图片来自mooc网 哈尔滨工业大学 计算机网络课程：https://www.icourse163.org/course/HIT-154005

1. TCP:面向连接的传输协议

1.1 TCP概述

• 面向连接的( connection- oriented) ：这两个进程必须先相互"握手"，即它们必须相互发送某些预备报文段，以建立确保数据传输的参数。
  • TCP 协议只在端系统中运行，而不在中间的网络元素(路由器和链路层交换机)中运行
  • 中间的网络元素不会维持 TCP 连接状态。 事实上，中间路由器对 TCP 连接完全视而不见，它们看到的是数据报，而不是连接。
• 连接建立过程常被称为三次握手 ( three-way handshake)
• 点对点：一个发送方，一个接收方
• 全双工服务(full-duplex service) ：同一连接能传输双向的数据流
• 发起连接的进程被称为客户进程，而另一个进程被称为服务器进程。
• TCP 连接的组成：两台主机上的缓存、连接状态变量、socket等
  

1.2 TCP报文段结构

• 源端口号(source port)和目的端口号(dest port)：被用于多路复用/分解来自或送到上层应用的数据。
• 同 UDP 一样， TCP 首部也包括检验和字段( checksum field)
• 序号字段 (sequence number field) 和 确认号字段( acknowledgment number field) ：这些字段被 TCP 发送方和接收方用来实现可靠数据传输服务，讨论见后。
• 接收窗口字段 (receive window field) ：应用与流量控制，该字段用于指示接收方愿意接受的字节数量。
• 4 bit 的首部长度字段 (header length field) ： 有选项字段，所以 TCP 首部的长度是可变的。 (通常，选项字段为空，所以 TCP 首部的典型长度就是 20 字节 )
• 选项字段 ( options field) ：可选与变长的，用于双方协商最大报文段长度时，或在高速网络环境下用作窗口调节因子时使用。
• 6 bit 的 标志字段 (flag field) ：
  • ACK 比特用于指示确认字段中的值是有效的；
  • RST、 SYN 和 FIN 比特用于连接建立和拆除；
  • 当 PSH 比特被设置的时候，就指示接收方应立即将数据交给上层（一般不用）；
  • URG 比特用来指示报文段里存在着被发送端的上层实体置为"紧急"的数据（一般不用），紧急数据的最后一个字节由 16 比特的紧急数据指针字段指出 。
• 序号与确认号：这两个字段是 TCP 可 靠传输服务的关键部
  • 1）序号：建立在传送的字节流之上，而不是建立在传送的报文段的序列之上。 因此一个报文段的序号是该报文段首字节的字节流编号。
    • 例如：TCP 将某数据流构建成 500 个报文段，最大报文段长度为1000字节，则第一个报文段分配序号 0 ，第二个序号 1000 … ，每一个序号被填入到相应 TCP 报文段首部的序号字段中
    • 建立TCP连接时，双方随机选择***
  • 2）确认号：TCP 是全双工的，因此确认号是希望接收到的下一个字节的序号
    • 例1：主机 A 已收到了来自主机 B 的编号为 0-535 的所有宇节，同时假设它打算发送一个报文段给主机 B。 主机 A 等待主机 B 的数据流中字节 536 及之后的所有字节。 所以主机 A 就会在它发往主机 B 的报文段的确认号字段中填 上 536。
    • 例2：主机 A 己收到一个来自主机 B 的包含字节 0-535 的报文段，以 及另一个包含字节 900 -1000 的报文段。但主机 A 还没有收到字节 536 -899 的报文段。主机 A 为了重新构建主机 B 的数据流，仍在等待字节 536 (和其后的字节) 。因此，A 到 B 的下一个报文段将在确认号字段中包含 536。
    • 由例2看出，TCP 只确认该流中至第一个丢失字节为止的字节，所以 TCP 被称为提供累积确认( cumulative acknowledgment) 。
    • 在例2中，乱序到达的第三个报文段(字节 900 - 1000) 怎么处理呢？即TCP 连接中收到失序报文段时该怎么办?—— TCP 规范中没有规定，由 TCP 的编程人员做出决策（丢弃或暂时保存）

1.3 TCP可靠数据传输

1.3.1 概述

• TCP 在 IP 层提供的不可靠服务基础上实现可靠数据传输，TCP 提供可靠数据传输的方法涉及我们在之前所学的许多原理。
• 使用了流水线机制
• 使用了累积确认
• 使用了单一的重传计时器（与 SR 不一样，因为定时器的管理需要相当大的开销）
• 触发重传的事件：超时、收到重复 ACK

1.3.2 合理的重传超时时间

• 如何设置定时器的合理的超时时间？
  • 设置过短：不必要的重传
  • 设置过长：对段丢失的反应太慢
  • 但是一定要大于 RTT( round trip time)，而 RTT 又是变化的
• TCP 是如何测量估计 RTT ？
  • 报文段的样本 RTT( SampleRTT) ：从某报文段被发出(即交给 IP) 到对该报文段的确认被收到之间的时间量
  • TCP 维持一个 SampleRTT 均值 (称为 EstimatedRTT) ，EstimatedRTT是一个 SampleRTT 值的加权平均值，α 参考值是 0.125
  • EstimatedRTT = (1 -α) · EstimatedRTT + α · SampleRTT
  • 即考虑了历史信息也考虑了最新的测量值，这种平均被称为指数加权移动平均 (Exponential Weighted Moving Average , EWMA)
• 除了估算 RTT 外，测量 RTT 的变化也是有价值：
  • RTT 偏差 DevRTT，用于估算 SampleRTT 一般会偏离 EstimaLedRTT 的程度:
  • DevRTT = (1 -β) · DevRTT +β · | SampleRTT - EstimatedRTT |
  • 同样是指数加权移动平均
• 最终得出定时器超时时间的设置：
  • EstimatedRTT 加上一定余量。 当 SampleRTT 值波动较大时，这个余量应该大些；当波动较小时，这个余量应该小些。 因此， DevRTT值应该在这里发挥作用了。
  • TimeoutInterval = EstimatedRTT + 4 · DevRTT

1.3.3 可靠数据传输的实现

• TCP 发送方的三个事件
  • 从应用层收到数据：
    • 将数据封装在一个报文段中并把该报文段交给 IP
    • 报文段包含一个序号，就是该报文段第一个数据字节的字节流编号
    • 如果定时器还没有为某些其他报文段而 运行，则当报文段被传给 E 时， TCP 就启动该定时器。
    • 该定时器的过期间隔是 TimeoutInterval
  • 超时：
    • 重传引起超时的报文段
    • 重启定时器
  • 收到 ACK：
    • TCP 将 ACK 的值 y 与它的变量 SendBase 进行比较
      • 状态变量 SendBase 是最早未被确认的字节的序号
      • SendBase -1 是指接收方已正确按序接收到的数据的最后一个字节的序号
      • TCP 采用累积确认，所以 y 确认了字节编号在 y 之前的所有字节都已经收到
    • 如果 y > SendBase，则该 ACK 是在确认一个或多个先前未被确认的报文段。
    • 更新 SendBase
    • 如果窗口中还有未被确认的分组，则重新启动定时器
  • 几个例子：
    • 例1：由于确认丢失而重传
      
    • 例2：报文段100没有重传
    • 例3：累积确认避免了第一个报文段的重传
      

1.3.4超时间隔加倍

• 这是大多数 TCP 实现中所做的一些修改
• 当超时事件发生时， TCP 重传具有最小序号的还未被确认的报文段。只是每次 TCP 重传时都会将下一次的超时间隔设为先前值的两倍。因此，超时间隔在每次重传后会呈指数型增长
• 然而，每当定时器在另两个事件（即收到上层应用的数据和收到 ACK）中的任意一 个启动时， Timeoutlnterval 由最近的 EstimatedRTT 值与 DevRTT 值推算得到。
• 这种修改提供了一个形式受限的拥塞控制。
  • 定时器超时很可能是由网络拥塞引起的
  • 在拥塞的时候，如果发送方持续重传分组，会使拥塞更加严重
  • 因此，TCP 使用更文雅的方式，每个发送方的重传都是经过越来越长的时间间隔后进行的。

1.3.5快速重传机制

• 超时触发重传存在的问题之一是超时周期可能相对较长。 当一个报文段丢失时，这种较长的超时周期迫使发送方延迟重传丢失的分组，因而增加了端到端时延。
• 先看一下 TCP 接收方的 ACK 生成策略：
  
• 发送方一个接一个地发送大量的报文段，如果一个报文段丢失，就很可能引起许多一个接一个的冗余 ACK
• 如果 TCP 发送方接收到对相同数据的 3 个冗余 ACK，则假定在该报文段之后的报文段已经丢失，TCP 就执行快速重传(fast retransmit) ：即在该报文段的定时器过期之前重传丢失的报文段

1.3.6 GBN or SR？

• TCP 是一个 GBN 协议 还是一个 SR 协议?
• 前面讲过， TCP 确认是累积式的，正确接收但失序的报文段是不会被接收方逐个确认的
• 因此，TCP 发送方仅需维持已发送过但未被确认的字节的最小序号 ( SendBase) 和下一个要发送的字节的序号 ( NextSeqNum) 。 在这种意义下， TCP 看起来更像一个 GBN 风格的协议
• 但是， 许多 TCP 实现会将正确接收但失序的报文段缓存起来。假设 n（n < N）的确认报文丢失，但是其余 N-1个确认报文在分别超时以前到达发送端，
  • GBN 不仅会重传分组 n， 还会重传所有后继的分组 n+1， n+2， … ， N
  • TCP 则将重传至多一个报文段，即报文段 n
  • 此外，如果对报文段 n +1 的确认报文在报文段 n 超时之前到达， TCP 甚至不会重传报文段 n
• 对 TCP 提出的一种修改意见是所谓的选择确认 ，它允许 TCP 接收方有选择地确认失序报文段，而不是累积地确认最后一个正确接收的有序报文段。此时，TCP 看起来就很像我们通常的 SR 协议。
• 因此， TCP 的差错恢复机制也许最好被分类为 GBN 协议与 SR 协议的混合体。

1.4 TCP的流量控制