面向连接的传输： TCP

TCP：概述

• 提供的是点对点的服务： 一个发送方，一个接收方
• 可靠的、按顺序的字节流 ： 没有报文边界
• 管道化（流水线）： TCP拥塞控制和流量控制设置 窗口大小
• 发送和接收：

• 全双工数据 ： 在同一连接中数据流双向流动 ，两者可以互相发 ( ==MSS：最大报文段大小 [任意一个网络都有它最大的传输部分，如果应用交互的报文非常长的话，就必须打成一个个MSS的大小。每层都要加上头部信息==])
• 面向连接： 在数据交换之前，通过握手（交换控制报文） 初始化发送方、接收方的状态 变量
• 有流量控制： 发送方不会淹没接收方

段结构

TCP报文段结构

源端口号：16bit

目标端口号： 16bit

序号： 32bit

TCP序号，确认号：

序号：

• 报文段首字节 的在字节流的编号

如果初始序号为X， 那么第n个序号就是X + n*MSS

序号具体就是： 上层交互的报文 ，我们按照MSS为单位，切割成为一个个的MSS报文段。 每个TCP都有头部和Body部分， Body部分就是MSS的载荷部分。载荷部分(Body)中的第一个字节就是MSS在整个报文中的偏移量.

确认号:

• 期望从另一方收到的下一个字节的序号
• 累积确认

发送方发送， 接收方接收， 假设接收方发送了ACK为555， 那么就说明接收方接收到了554及其之前的所有字节。而且期望发送方从556的序号开始发送

首部长度：

• 4bit

保留未用：不太清楚

标志位： UAPRSF

接收窗口 ： 用于流量控制。 （如果接收窗口为 X， 那么就表示能接收 Xbit的数据）

紧急指针： 不怎么用。

TCP面临的通信场景(往返延时（RTT）和超时 )

采用自适应的策略和计算。

1.怎样设置TCP 超时？

如果比RTT要长 ， 但RTT是变化的

如果太短：太早超时 会产生不必要的重传

如果太长：对报文段丢失 反应太慢，消极

2.怎样估计RTT？

SampleRTT：测量从报文段发出到 收到确认的时间

如果有重传，忽略此次测量

SampleRTT会变化，因此估计的 RTT应该比较平滑

对几个最近的测量值求平均，而 不是仅用当前的SampleRTT

3.EStimatedRTT（估计的往返延迟时间）的计算：

EstimatedRTT = (1- a)*EstimatedRTT + a*SampleRTT

• 指数加权移动平均
• 过去样本的影响呈指数衰减
• 推荐值：a = 0.125

往返延迟时间分布：

设置超时

平均值越大， 我们设置的超时时间就需要变大

往返延迟的变化越大， 就会越分散 ， 超时时间就需要设置的越大。

EstimtedRTT + 安全边界时间

• EstimatedRTT变化大 (方差大 ) -> 较大的安全边界时间

SampleRTT会偏离EstimatedRTT多远：

当前的采样值， 离偏差程度的一个平均值。

可靠数据传输（TCP怎么实现RDT）

我们知道IP提供的是不可靠的服务 ，而TCP向上层提供的确是可靠的服务， 那么这是如何实现的呢 ？

TCP在IP不可靠服务的基础上 建立了rdt

• 管道化的报文段 • GBN or SR (它实现了两者的混合体)
• 累积确认（像GBN）
• 单个超时重传定时器（像GBN）
• 是否可以接受乱序的，没有规范

通过以下事件触发重传

• 超时（只重发那个最早的未确认 段：SR）
• 重复的确认 ( 例子：收到了ACK50,之后又收到3 个ACK50 )

首先考虑简化的TCP发 送方：

• 忽略重复的确认
• 忽略流量控制和拥塞控 制

TCP 发送方(简化版)

TCP发送方事件：

从应用层接收数据：

• 用nextseq创建报文段
• 序号nextseq为报文段首字 节的字节流编号
• 如果还没有运行，启动定 时器
• 定时器与最早未确认的报文 段关联
• 过期间隔： TimeOutInterval

超时：

• 重传后沿最老的报文段
• 重新启动定时器

收到确认：

• 如果是对尚未确认的报 文段确认
• 更新已被确认的报文序号
• 如果当前还有未被确认的 报文段，重新启动定时器

ACK7: 表示7之前的都发送了并且已经得到了确认。接下来就需要从8号开始

TCP： 重传