计算机网络——20面向连接的传输：TCP

面向连接的传输：TCP

TCP：概述

点对点

一个发送方、一个接收方

可靠的、按顺序的字节流

没有报文边界

管道化（流水线）

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

发送和接收缓存

全双工数据

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

面向连接

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

有流量控制

发送方不会淹没接收方

TCP报文段结构

TCP序号，确认号

序号

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

确认号

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

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

TCP往返延时（RTT）和超时

怎样设置TCP超时

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

怎样估计RTT

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

TCP序号和确认号

TCP往返延时和超时

E s t i m a t e d R T T = ( 1 − a ) ∗ E s t i m a t e d R T T + a ∗ S a m p l e R T T EstimatedRTT = (1- a)*EstimatedRTT + a*SampleRTT EstimatedRTT=(1−a)∗EstimatedRTT+a∗SampleRTT

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

设置超时

E s t i m t e d R T T EstimtedRTT EstimtedRTT + 安全边界时间
- E s t i m a t e d R T T EstimatedRTT EstimatedRTT变化大(方差大) → 较大的安全边界时间
S a m p l e R T T SampleRTT SampleRTT会偏离 E s t i m a t e d R T T EstimatedRTT EstimatedRTT多远：
- D e v R T T = ( 1 − β ) ∗ D e v R T T + β ∗ ∣ S a m p l e R T T − E s t i m a t e d R T T ∣ DevRTT = (1-β)*DevRTT + β*|SampleRTT-EstimatedRTT| DevRTT=(1−β)∗DevRTT+β∗∣SampleRTT−EstimatedRTT∣
- 推荐值： β = 0.25 β = 0.25 β=0.25

超时时间间隔设置为：

T i m e o u t I n t e r v a l = E s t i m a t e d R T T + 4 ∗ D e v R T T TimeoutInterval = EstimatedRTT + 4*DevRTT TimeoutInterval=EstimatedRTT+4∗DevRTT

TCP：可靠数据传输

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

TCP发送方（简化版）

TCP发送方事件

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

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

超时：

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

收到确认：

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

伪代码

上述操作的伪代码

c 复制代码

// 初始化
NextSeqNum = InitialSeqNum
SendBase = InitialSeqNum

// 一直循环
loop (forever) {
	// 判断事件
	switch(event)
	
	// 如果收到了应用层的数据
    event: data received from application above
    	// 用NextSeqNum创建TCPsegment
		create TCP segment with sequence number NextSeqNum
		// 如果定时器不在运行的话，开始
		if (timer currently not running)
			start timer
		// 传给IP
		pass segment to IP
		// 前沿移动
		NextSeqNum = NextSeqNum + length(data)

    event: timer timeout
		retransmit not-yet-acknowledged segment with
		smallest sequence number
	start timer

    event: ACK received, with ACK field value of y
		if (y > SendBase) {
			SendBase = y
			if (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个乱序段，可能性非常大段丢失了

快速重传算法

c 复制代码

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

TCP 流量控制

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

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