计算机网络：自顶向下方法读书笔记（八）

3.5 面向连接的运输：TCP

3.5.1 TCP连接

• TCP主要采用连接式的（基于连接的）(connection-based)。
• TCP连接支持全双工通信（full-duplex communication）。
• 三次握手(three-way handshake)。
• 最大传输数据量（Maximum Segment Size, MSS）：通常由本地发送主机预先确定的最大报文长度设定为MSS值。确保每个TCP报文段加上40字节的首部后仍能容纳在一个链路层帧内。
• 最大传输单元（Maximum Transmission Unit, MTU）：即链路层的最大数据包长度。

3.5.2 TCP报文段结构

序号字段(sequence number field)

确认号字段(acknowledgment number field)

接收窗口字段(receive window field)：十六位二进制数用于流量控制，并指示接收方愿意接受的字节数量。

其中**header length field（首部长度字段）**占用了4比特位宽，在每32-bit字为单位地编码网络数据包头信息。其可变性源于TCP选项字段的存在。通常情况下，默认情况下若无选项数据，则该类数据包头的实际大小固定为20字节。

此字段为选项字段变量 ，其作用是在协商MSS的场景中使用，并在高速网络环境下作为窗口调节因子使用。（具体信息请参阅[RFC 854]和[RFC 1323]）

标志字段(flag field) ：ACK字段用于确认相关字段中的值是否有效；RST、SYN和FIN字段用于建立或拆除连接；CWR和ECE字段明确地发送拥塞通知；PSH字段表明接收方是否应立即转发给上层；URG字段用于指示包含紧急数据的报文段。其中，在实际应用中，并未使用PSH字段以及URG字段所指定的功能特性。紧急数据的末尾位置则由16位的紧急数据指针字段来指定。（实践中，并未采用这些功能特性）

序号和确认号 * 基于传送过程中的连续二进制数据流（即所谓的"字节流"），而并非基于以特定顺序排列好的数据包（即所谓的"报文序列"）。每一个数据包的第一个字节数组位置标识其所属序列。

• 主机A将下一期望到达的数据块的位置信息注入到当前报文块中。由于TCP协议的特点，在数据传输过程中一旦出现不可靠传输的情况（即某个数据块未能按顺序到达目的地），则后续的所有数据块都将被视为未正确接收。
• 由于TCP协议的特点，在数据传输过程中一旦出现不可靠传输的情况（即某一个或多个数据块未能按顺序到达目的地），则后续的所有数据块都将被视为未正确接收。因此，在这种情况下 TCP 被认为提供了累计确认功能

Telnet([RFC 854])

3.5.3 往返时间的估计与超时

估算往返时间 *用于衡量单次报文段传输效率的关键指标SampleRTT(Sample RTt)：从某报文段被发送到IP节点开始计算…到该报文段被IP节点确认接收完成为止的时间长度。TCP协议仅用于衡量单次发送的报文数据包的时间开销。

• Sample RTt均值(Estimated RTt)：根据递推公式计算得到Estimated RTt = (1 - α) × 前一次估计值 + α × 当前采样值

  • 其中α取值建议为0.125（参考文献[ RFC 6298 ]）

    • RTT偏差(DevRTT)：DevRTT= (1 - β) * DevRTT+ β) * |SampleRTT - EstimatedRTT|
      • β推荐值是0.25（[RFC 6298]）

配置和调节重传超时间隔的时间间隔 TimeoutInterval = EstimatedRTT + 4 \times DevRTT

• 建议将初始值设定为1秒。一旦接收报文段并更新EstimatedRTT，则依据公式重新计算TimeoutInterval（[RFC 6298]）

3.5.4 可靠数据传输

特别之处：在书中对TCP的简化的模型描述中也隐藏着一些细节。
第一种情况：当定时器间隔内未接收到主机B的ACK报文时, 该主机会尝试重传该数据段。
若主机B在此前已接收到此数据段, 则会放弃重传包含这些字节的数据包。
第二种情况：当该主机连续发送了两个数据段, 假设两者均已成功到达目标端口并均获得相应的ACK响应, 在超时之前这两个ACK信号均未到达发送端, 因此一旦检测到超时现象, 该主机将仅重传第一个数据段并重启定时器; 只要在这个时间周期内接收到第二个数据段的ACK信号, 则无需进行第二次重传。
第三种情况：当某次发送的数据包丢失其ACK确认（即第一个数据包丢失），而第二个数据包却成功接收到了ACK确认及之前的所有字节时, 由于第二个数据包已经表明主机B已接收全部前导信息, 因此在这种情况下无需进行任何重传操作。

• 超时间隔加倍
• 快速重传[RFC 5681]
• 选择确认[REF 2018]

3.5.5 流量控制

• 流量控制服务（flow-control service）与拥塞控制（congestion control）虽然采取的行为非常相近，但本质上是不相同的。
  • 接收窗口（receive window）是一个提供流量控制功能的变量，在此框架下给发送方指示：该接收端还有多少容量可供接收数据。
  • 其中：
    rwnd = RcvBuffer - \left[ LastByteRcvd - LastByteRead \right] （其中LastByteRcvd - LastByteRead \leq RcvBuffer）
    • RceBuffer：接收缓存容量
    • LastByteRcvd：从网络中到达并被计入主机B接收缓存中的数据流的最后一个字节标记
    • LastByteRead：主机B的应用进程从缓存中读取的数据流的最后一个字节标记
    • rwnd：表示当前的有效接收窗口大小

3.5.6 TCP连接管理

随机化选择client_isn的有趣研究[CERT 2001-09]

SYNACK报文段（SYNACK segment）

三次握手：

四次挥手：

SYN洪泛攻击

3.6 拥塞控制原理

3.6.1 拥塞原因与代价

3.6.2 拥塞控制方法

• 端到端拥塞控制：
  在传统的互联网架构中，在无确定性传输介质的情况下，默认采用的是基于窗口协议的数据分组传输机制。
• 网络辅助的拥塞控制：
  动态路由协议通常会在发现路径可用时自动触发流量重定向机制。
• 直接反馈信息：
  直接反馈的信息包括阻塞分组（commonly referred to as choke packets），这些特殊数据包通常会被发送源主机标记以避免进一步重传。
• 经由接收方的网络反馈：
  当数据链路层检测到链路状况恶化时，在经过以太网或其他媒体访问层协议后会将相关的状态更新信息传递给相关应用层。

3.7 TCP拥塞控制

• Three key challenges: how to limit, how to sense, and how to alter?

  • How to manage:

    • Congestion window (congestion window): The difference between LastByteSent and LastByteAcked must not exceed the minimum of cwnd and rwnd.

  • 如何感知：

    • 超时 or 3个冗余ACK，则发送方认为路径上出现了拥塞

• 如何改变（算法）：

• 指导性原则：

  • 丢失报文段表表明存在网络拥塞状态，在此情况下应当减少TCP协议下发送端的数据传输速率
  • 存在确认报文段表明接收端已接收到所有待传输数据块，在此情形下能够允许发送端提升其数据传输速率
  • 进行带宽探测

• TCP拥塞控制算法基于Jacobson在1988年的研究以及RFC 5681的标准。

• 该算法采用"慢速增益机制"（slow-start），即从每个最大分段序列（MSS）开始，并在每次首次确认传输的数据报后递增一个 MSS。

• 当检测到丢包超时时，则将慢启动重置为1；当达到阈值 ssthresh 值时则结束慢启动。

• 检测到3个冗余确认 acknowledged 则立即执行快速重传，并迅速恢复状态。

  复制代码

  * 拥塞避免
  * 快速恢复

• TCP分割（TCP split）

• 动态窗口控制机制（Additive-Increase, Multiplicative-Decrement, AIMD）流量管理方案

3.7.1 公平性

*K个TCP连接沿具有Rbps限制的链路传输着一个巨大的文件，在没有UDP流量干扰的情况下（即所有这些连接都以接近R/K的速度运行），则认为这种拥塞控制机制在这种情况下被认为是公平的。

3.7.2 明确拥塞通告：网络辅助拥塞控制