面向连接的传输 TCP

可靠数据传输

概述

TCP在IP不可靠的尽力而为服务之上创建了一种可靠数据传输服务

• 单个重传定时器（定时器的管理需要相当大的开销，类似于 GBN）
• 累计确认，累计确认 ACK 以前的所有分组（不包括本身，类似于 GBN，但是有区别，区别在于 GBN 包括分组本身的确认）

超时重传的条件

• 超时，重传具有最小序号但仍未应答的报文段
• 重复的确认，例如收到同一分组数据的3个重复的 ACK

TCP 发送方事件（以下为为伪代码）

• 从应用层接收到数据
• 定时器超时
• 收到确认号

// 假设发送方不受 TCP流量 和 拥塞控制 的限制，来自上层数据的长度小于 MSS,且数据传送只在一个方向进行
NextSeqNum = InitialSeqNumber
SendBase = InitialSeqNumber
loop(永远){
    switch(事件)
    	事件：从上面应用程序接收到数据 e
    		生成具有序号 NextSeqNum 的TCP报文段
    		if(定时器当前没有运行)
    			启动定时器
             向IP传递报文段
    		NextSeqNum = NextSeqNum + length(data)
    		break;
    
    	事件：定时器超时
    		重传具有最小序号但仍未应答的报文段（不像 SR，需要重传所有未确认的段）
    		启动定时器
    		break;
    
    	事件：收到ACK，具有ACK字段值 y
    		if(y > SendBase) {
   				SendBase = y
    			if(当前仍无任何应答报文段)
    				启动定时器
            }
            break;
}

快速重传

超时触发重传存在的问题：当一个报文段丢失时，这种相对较长超时周期迫使发送方延迟重传丢失的分组，因而增加了端到端的时延

快速重传就是在没有超时重传的情况下就进行重传已知丢失的分组（通常可在超时事件发生之前通过注意所谓冗余ACK来较好地检测到丢包
情况），伪代码如下

loop(永远){
    事件：收到ACK，具有ACK字段值 y
        if (y > SendBase){
        	SendBase = y
            if(当前仍无任何应答报文段)
                启动定时器
        }else{
            // 对已经确认的报文段的一个冗余ACK
            对 y 收到的冗余 ACK 数加 1
            1f(对 y == 3 收到的冗余ACK数)
                // TCP快速重传
                重新发送具有序号 y 的报文段
        }
        break;
}

TCP 流量控制

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

TCP通过让发送方维护一个称为接收窗口的变量来提供流量控制。通俗地说，接收窗口用于给发送方一个指示（该接收方还有多少可用的缓存空间）

• RcvBuffer：接收缓冲区，包括接受窗口和TCP 缓存数据（典型默认大小为 4096 字节）
• LastByteRead：主机上的应用进程从缓存读出的数据流的最后一个字节的编号（相当于后沿）
• LastByteRcvd：从网络中到达的并且已放入主机接收缓存中的数据流的最后一个字节的编号（相当于前沿）
• 由于TCP不允许已分配的缓存溢出，下式必须成立： LastByteRcvd - LastByteRead < RcvBuffer
• 接收窗口 rwnd = RcvBuffer - [LastByteRcvd - LastByteRead]（根据缓存可用空间的数量来设置）

注意：对于这个方案还存在一个小小的技术问题。假设主机B 的接收缓存已经存满，使得 rwnd = 0，再将 rwmd = 0 通告给主机A 之后，还要假设主机B 没有任何数据要发给主机 A

• 因为主机B 上的应用进程将缓存清空，并不向主机A 发送带有 rwnd 新值的新报文段（TCP仅当在它有数据或有确认要发时才会发送报文段给主机A）
• 这样，主机A 不可能知道主机B 的接收缓存已经有新的空间了，即主机A 被阻塞而不能再发送数据！

解决方案（TCP规范中要求）

当主机B 的接收窗口为 0 时，主机A 继续发送只有一个字节数据的报文段，这些报文段将会被接收方确认；最终缓存将开始清空，并且确认报文里将包含一个非 0 的 rwnd 值

TCP 连接管理

三次握手

在正式交换数据之前，发送方和接收方通过三次握手建立通信关系

• 同意建立连接（每一方都知道对方愿意建立连接）
• 同意连接参数

为什么需要三次握手，而不是二次握手？

三次握手能够解决半连接和接收老数据问题，比如：当发送方发送连接的分组给接收方，但是由于阻塞原因导致触发了发送方超时重传的机制，重传了一个连接的分组，这个时候接收方的确认接收达到，建立连接，然后很快的终止连接，而这个时候那个重传的连接分组会再一次和接收方建立连接，但是没有办法终止

三次握手的建立过程

第一步：客户端的TCP 首先向服务器端的TCP 发送一个特殊的TCP 报文段。该报文段中不包含应用层数据，但是在报文段的首部中的一个标志位
SYN 比特被置为 1。另外客户会随机地选择一个 初始序号 并将此编号放置于特殊的TCP 报文段的序号字段中，并通过下层服务发送给服务器

第二步：一旦特殊的TCP 报文段到达服务器主机，服务器将为该TCP连接分配TCP缓存和变量，并向该客户TCP发送允许连接的报文段（该允许连接的报文段被称为SYNACK报文段，该报文段也不包含应用层数据，但是在报文段的首部却包含3个重要的信息）

• SYN 比特 被置为1
• 该TCP报文段首部的 确认号字段 被置为客户端随机序号+1
• 服务器选择自己的 初始序号 并将其放置到TCP报文段首部的序号字段中

第三步：在收到 SYNACK 报文段后，客户端也要给该连接分配缓存和变量。然后向服务器发送另外一个报文段

• SYN 比特 被置为 0（因为连接已经建立了）
• 对服务器的允许连接的报文段进行了确认，确认号字段为服务端初始序号+1
• 在报文段负载中可以携带客户端到服务器的应用层数据

注意：图中的 client_isn 为客户端的初始序号、server_isn 为服务端的初始序号

四次挥手

参与一条TCP连接的两个进程中的任何一个都能终止该连接。某一方需要发送终止报文段，就将 FIN 比特置为 1 ，然后等待另外一方确认，当连接结束后，主机中的资源（即缓存和变量）将被释放

TCP 状态序列

注意：当一台主机接收到一个TCP报文段，其端口号或源 IP地址与该主机上进行中的套接字都不匹配的情况。例如，假如一台主机接收了具有目的端口80 的一个TCP SYN分组，但该主机在端口80不接收连接（即它不在端口80上运行Wb服务器)，则该主机将发送一个特殊重置报文段（该TCP报文段将 RST 标志位置为 1）

拥塞控制原理

概述

“太多的数据需要网络传输，超过了网络的处理能力”

与流量控制不同，流量控制是为了控制发送方和接收方之间速率传输（对象是发送方和接收方），拥塞控制的表现如下

• 分组丢失（路由器缓冲区溢出）
• 分组经历比较长的延迟（在路由器的队列中排队）

分析三个发生拥塞的情况

• 情况1：两个发送方和一台具有无穷大缓存的路由器（输出链路带宽 R、没有重传）
• 当发送速率在0~R/2之间时，接收方的吞吐量等于发送方的发送速率，即发送方发送的所有数据经有限时延后到达接收方。然而当发送速率超过R/2时，它的吞吐量只能达R/2（这个吞吐量上限是由两条连接之间共享链路容量造成的）

• 虽然从吞吐量角度看，运行在总吞吐量接近R的状态也许是一个理想状态，但从时延角度看，却远不是一个理想状态

• 情况2：两个发送方和一台具有有限缓存的路由器
• 运输层向网络中发送报文段（含有初始数据或重传数据）可以被称为网络的供给载荷

• 网络拥塞的代价
• 发送方必须执行重传以补偿因为缓存溢出而丢弃（丢失）的分组
• 发送方在遇到大时延时所进行的不必要重传会引起路由器利用其链路带宽来转发不必要的分组副本
• 情况3：四个发送方和具有有限缓存的多台路由器及多跳路径
• 如果每个主机占用一个最近的路由设备并不断增大供给载荷，将会导致类似 死锁 的效果，比如：主机A想要传输数据给主机C，主机B传输数据给主机D，以此类推，随着流量的增大，各自主机都会占用离自己较近的路由设备，导致相互之间都被阻塞

• 拥塞的代价
• 当分组丢失时，任何关于这个分组的上游传输能力都被浪费了

拥塞控制方法

端到端拥塞控制（TCP 采用的方法）

• 网络层没有为运输层拥塞控制提供显示反馈
• 端系统根据延迟和丢失事件判断是否发生拥塞

网络辅助拥塞控制（ATM 体系结构中被采用）

• 路由器提供给端系统反馈信息

网络辅助拥塞控制案例：ATM ABR

• 如果发送端的路径"轻载"，则发送方使用可用带宽
• 如果放送端路径拥塞，则会限制器发送速度到一个最小保障的速率上

资源管理信元 RM

• 由发送端发送，在数据信元中间隔插入
• RM信元中的比特被交换机设置
• BI bit：轻微阻塞，速率不要增加了
• CI bit：拥塞指示，限制其发送的速度到一个最小保障速率上
• 发送端发送的RM 信元被接收端返回，接收端不做任何改变

注意区别数据信元和资源管理信元：数据信元通常指的是在通信过程中传递的具体数据单元；资源管理信元则主要用于管理和控制通信资源的分配、调度和回收

拥塞控制 TCP

概述

TCP通常使用端到端拥塞控制而不是使网络辅助的拥塞控制，因为 IP层不向端系统提供显式的网络拥塞反馈

如何检测拥塞？

• 拥塞：某个报文段超时了
• 轻微拥塞：某报文段出现三次重复的 ACK

如何控制发送端发送的速率？

• 维持一个拥塞窗口的值：cwnd；接收窗口 rwnd
• 在一个发送方中未被确认的数据量不会超过 cwnd 与 rwnd 中的最小值，即 LastByteSent - LastByteAcked < min{cwnd,rwnd}

拥塞控制策略

目的：尽可能提高传输速度的同时不发生拥塞状态

慢启动（SS阶段，启动初值很低，但是加速是指数性的）

当连接开始时，指数性增加（每个RTT）发送速率直到发生丢失事件

• 拥塞窗口的值以 1 MSS 开始
• 如果没有发生拥塞，报文段加倍增加（每个RTT），如下图的增长方式
• 超时或者三个重复 ACK超时：拥塞窗口的值降为 1 MSS，进入慢启动（SS 阶段）然后再倍增到 上次标记发生拥塞时候窗口一半的值（每个RTT），然后进入拥塞避免策略（CA 阶段）三个重复 ACK：拥塞窗口的值降为原来的一半，然后进入拥塞避免策略（CA 阶段）

拥塞避免（CA阶段，线性增加）

• 从上次标记发生拥塞时候窗口值的一半的位置（称作 ssthresh）开始累计（续接上面超时/三个重复ACK的时候，CA阶段的操作）
• 每个RTT只将拥塞窗口的值增加一个MSS
• 超时或者三个重复 ACK（和上面的情况一样）

快速恢复（不是必须的）

• 在快速恢复中，对收到的每个冗余的ACK，拥塞窗口的值增加一个MSS
• 如果出现超时事件，快速恢复在执行如同在慢启动和拥塞避免中相同的动作后，迁移到慢启动状态

如下图是超时或者三个重复 ACK所发生情况（TCP Remo 起点的位置原本应该是 6 个MSS，因为三个重复ACK，所以在快速恢复状态下变为 9 个MSS）

注意：慢启动和拥塞避免是TCP的强制部分；快速恢复是推荐部分，对TCP发送方并非是必需的

TCP 公平性

目标：如果K个TCP会话分享一个链路带宽为R的瓶颈，每一个会话的有效带宽为 R/K

实践中，客户-服务器应用通常获得非常不平等的链路带宽份额，特别是当多条连接共享一个共同的瓶颈链路时，那些具有较小RTT的连接能够在链路空闲时更快地抢到可用带宽（即较快地打开其拥塞窗口）

随着上述拥塞控制，会如下图所示的趋势，连接1和连接2达到均衡的带宽共享状态

• 加性增加，斜率为1，吞吐量增加
• 乘性减，吞吐量比例减少

网络辅助拥塞控制 ECN

对 TCP 的网络层 IP 实现了网络辅助拥塞控制

• TOS 字段中2个bit被路由器标记，用于指示是否发生拥塞
• 拥塞指示被传送到接收主机
• 在接收方到发送方的ACK中，接收方(在 IP 数据报中看到了拥塞指示）设置ECE bit，指示发送方发生了拥塞

嗨喽！网络基础篇的传输层就讲到这里先了，下一阶段开始介绍网络层相关知识！