计算机网络——20面向连接的传输：TCP-编程知识

面向连接的传输：TCP

TCP：概述

点对点

一个发送方、一个接收方

可靠的、按顺序的字节流

没有报文边界

管道化（流水线）

TCP拥塞控制和流量控制设置窗口大小

发送和接收缓存

全双工数据

在同一连接中数据流双向流动
MSS：最大报文段大小

面向连接

在数据交换之前，通过握手（交换控制报文）初始化发送方、接收方的状态变量

有流量控制

发送方不会淹没接收方

TCP报文段结构

在这里插入图片描述

TCP序号，确认号

序号

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

确认号

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

接收方如何处理乱序的报文段-没有规定

在这里插入图片描述

TCP往返延时（RTT）和超时

怎样设置TCP超时

比RTT要长
- 但RTT是变化的
太短：太早超时
- 不必要的重传
太长：对报文段丢失反应太慢，消极

怎样估计RTT

SampleRTT：测量从报文段发出到收到确认的时间
- 如果有重传，忽略此次测量
SampleRTT会变化，因此估计的RTT应该比较平滑
- 对几个最近的测量值求平均，而不是仅用当前的SampleRTT

TCP序号和确认号

在这里插入图片描述

TCP往返延时和超时

$E s t ima t e d RTT = (1 - a) * E s t ima t e d RTT + a * S am pl e RTT$

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

在这里插入图片描述

设置超时

$E s t im t e d RTT$ + 安全边界时间
- $E s t ima t e d RTT$ 变化大(方差大) → 较大的安全边界时间
$S am pl e RTT$ 会偏离 $E s t ima t e d RTT$ 多远：
- $De v RTT = (1 - β) * De v RTT + β * ∣ S am pl e RTT - E s t ima t e d RTT ∣$
- 推荐值： $β = 0.25$

超时时间间隔设置为：

$T im eo u t I n t er v a l = E s t ima t e d RTT + 4 * De v RTT$

TCP：可靠数据传输

TCP在IP不可靠服务的基础上建立了rdt
- 管道化的报文段
  - GBN or SR
- 累计确认
- 单个重传定时器
- 是否可以接受乱序的，没有规范
通过以下事件触发重传
- 超时（只重发那个最早的未确认段：SR）
- 重复的确认
首先考虑简化的TCP发送方：
- 忽略重复的确认
- 忽略流量控制和拥塞控制

TCP发送方（简化版）

在这里插入图片描述

TCP发送方事件

<font color=red从应用层接收数据：

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

超时：

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

收到确认：

如果是对尚未确认的报文段确认
- 更新已被确认的报文序号（后沿移动）
- 如果当前还有未被确认的报文段，重新启动定时器 (发完，就关掉定时器)

在这里插入图片描述

伪代码

上述操作的伪代码

// 初始化
NextSeqNum = InitialSeqNum
SendBase = InitialSeqNum// 一直循环
loop (forever) {// 判断事件switch(event)// 如果收到了应用层的数据event: data received from application above// 用NextSeqNum创建TCPsegmentcreate TCP segment with sequence number NextSeqNum// 如果定时器不在运行的话，开始if (timer currently not running)start timer// 传给IPpass segment to IP// 前沿移动NextSeqNum = NextSeqNum + length(data)event: timer timeoutretransmit not-yet-acknowledged segment withsmallest sequence numberstart timerevent: ACK received, with ACK field value of yif (y > SendBase) {SendBase = yif (there are currently not-yet-acknowledged segments)start timer}
} /* end of loop forever */

注释：

SendBase-1: 最后一个累积确认的字节
例：
- SendBase-1 = 71；y= 73, 因此接收方期望73+ ; y是ACK的值
- y > SendBase，因此新的数据被确认

TCP：重传

在这里插入图片描述

接收方产生TCP ACK的建议

接收方的事件	TCP接收方动作	补充
所期望序号的报文段按序到达。所有在期望序号之前的数据都已经被确认	延迟发送ACK（提高效率，少发一个ACK）。对另一个按序报文段的到达最多等待500ms。如果下一个报文段在这个时间间隔内没有到达，则发送一个ACK。	就是当接受到y0之后，不发送ACK=y0+1，而是当顺序接受到y1之后，发送ACK=y1+1注意必须是顺序接受到，如果是乱序，仍然请求y0+1,如果超时还未接受到，再发y0+1
有期望序号的报文段到达。另一个按序报文段等待发送ACK	立即发送单个累积ACK，以确认两个按序报文段。	就是上一条说的情况
比期望序号大的报文段乱序到达。检测出数据流中的间隔	立即发送重复的ACK，指明下一个期待字节的序号	如果收到了y0，然后乱序收到了y2，那么重新请求ACK=y0 + 1
能部分或完全填充接收数据间隔的报文段到达	若该报文段起始于间隔（gap）的低端，则立即发送ACK（给确认。反映下一段的需求）。	请求ACK=y0+1，此时已经乱序收到了y2的内容请求之后得到的gap并不能填充y0到y2的空间，只能达到y1，因此重新请求ACK=y1 + 1

快速重传

超时周期往往太长
- 在重传丢失报文段之前的延时太长
通过<font color=red重复的ACK来检测报文段丢失
- 发送方通常连续发送大量报文段
- 如果报文段丢失，通常会引起多个重复的ACK

在这里插入图片描述

如果发送方收到同一数据的3个冗余ACK，重传最小序号的段：
- 快速重传：在定时器过时之前重发报文段
- 它假设跟在被确认的数据后面的数据丢失了
  - 第一个ACK是正常的；（比如第一个ACK=50，表明收到了49，是正常的，请求50）
  - 收到第二个该段的ACK，表示接收方收到一个该段后的乱序段；（因为再次请求50）
  - 收到第3，4个该段的ack，表示接收方收到该段之后的2个，3个乱序段，可能性非常大段丢失了

在这里插入图片描述

快速重传算法

event: ACK received, with ACK field value of yif (y > SendBase) {SendBase = yif (there are currently not-yet-acknowledged segments)start timer}else { // 已确认报文段的一个重复确认increment count of dup ACKs received for yif (count of dup ACKs received for y = 3) {resend segment with sequence number y  // 快速重传}

TCP 流量控制

接收方控制发送方，不让发送方发送的太多、太快以至于让接收方的缓冲区溢出

在这里插入图片描述

接收方在其向发送方的TCP段头部的rwnd字段“通告”其空闲buffer大小
- RcvBuffer大小通过socket选项设置 (典型默认大小为4096 字节)
- 很多操作系统自动调整 RcvBuffer
- 发送方限制未确认(“inflight”)字节的个数≤接收方发送过来的 rwnd 值
保证接收方不会被淹没

在这里插入图片描述