TCP拥塞控制和流量控制相关知识点

面向连接

l两个使用TCP的应用（通常是一个客户和一个服务器）在彼此交换数据之前必须先建立一个TCP连接

可靠

l应用数据被分割成TCP认为最适合发送的数据块。

l当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。

l当TCP收到发自TCP连接另一端的数据，它将发送一个确认。

lTCP将计算首部和数据的检验和。如果收到段的检验和有差错，T CP将丢弃这个报文段和不确认收到此报文段（希望发端超时并重发）

l如果必要，TCP将对收到的数据进行重新排序，将收到的数据以正确的顺序交给应用层。

l既然IP数据报会发生重复， TCP的接收端必须丢弃重复的数据。

lTCP还能提供流量控制。TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据。这将防止较快主机致使较慢主机的缓冲区溢出。

窗口字段

窗口字段 —— 占 2 字节。窗口字段用来控制对方发送的数据量，单位为字节。TCP连接的一端根据设置的缓存空间大小确定自己的接收窗口大小，然后通知对方以确定对方的发送窗口的上限。

选项字段—— 长度可变

选项字段—— 长度可变。TCP的一种选项是最大报文段长度MSS (Maximum Segment Size)。MSS 告诉对方 TCP：“我所能接收的报文段的数据字段的最大长度是 MSS 个字节。” 

MSS是 TCP 报文段中的数据字段的最大长度。数据字段加上 TCP 首部才等于整个的 TCP 报文段。

TCP有三种基本机制来控制报文段的发送

l只要发送缓存从发送进程得到的数据达到最大报文段长度MSS字节时就组装TCP报文段并发送//主要是提高带宽的利用率

l发送端的应用进程指明要求发送报文段，即TCP支持的推送（push）操作

l发送端的一个计时器时间到了，就把当前已有的混存数据组装成TCP报文段发送出去

关于确认

l若发送方在规定的设置时间内没有收到确认，就要将未被确认的报文段重新发送。

l接收方若收到有差错的报文段，则丢弃此报文段（不发送否认信息）。

l接收方若收到重复的报文段，也要将其丢弃，但要发回（或稍带发回）确认消息。//因为这个重复很有可能是因为我们的ack丢失了导致的，所以要在发送ack。

l若收到的报文段无差错，只是未按照序号，如何处理？TCP对此未作明确规定。实现者可以将不按序的报文段丢弃，可以先将其暂存于接收缓存内，待所缺序号的报文段收弃后再一起交给应用层。

接收确认的延迟

l系统即使在连接上没有应发送的数据，也必须对从对方收到的数据进行应答。

l由于使用的接收确认分组本身不携带应用数据，在某种意义上浪费了网络带宽。

l为了使这种带宽的浪费减少到最低程度，TCP不要求每个分组到达后立即对其进行接收确认。系统可以延迟片刻发送接收确认分组。

l或许，在延迟的期间内，该系统的应用也有数据要发送（应用等待对方应答是常事）。倘若如此，该应答数据就能传送最新的接收确认号码，可以完全避免浪费带宽。即使应从该系统发送的数据还没有来到，可能又有来自对方的数据到达。在这种情况下，TCP能够对收到的全部数据一次性地进行接收确认，这样处理至少能够减少接收确认的分组数。

l无论在哪种情况下，TCP 都能减少网络的使用带宽。

2MSL后释放

TCP链接必须经过2MSL之后才能释放掉，也就是发送了对FIN的ack之后，再经过2MSL才能释放掉链接。

l第一，为了保证 A 发送的最后一个 ACK 报文段能够到达 B。

l第二，防止 “已失效的连接请求报文段”出现在连接中。

lA 在发送完最后一个 ACK 报文段后，再经过时间2MSL，就可以使本连接持续的时间内所产生的所有报文段，都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。

两次握手

l假定TCP使用两次握手代替三次握手来建立连接，也就是说，不需要第三个报文，行不行？

l三次握手完成两大功能：让双方做好发送数据的准备工作，就初始序列号进行协商

l两次握手可能发生死锁。假定A给B发送连接请求报文段，B收到后回送一个连接确认报文段。按两次握手协定，B此时就认为连接已经建立成功。但如果该确认报文段丢失， A将不知道B是否收到请求，也不知B发送的初始序列号。此时，A认为连接没有建立成功，将忽略B发来的任何报文段，只等连接确认报文段。而B在发出的报文段超时后，不断重复发送。从而形成死锁！

拥塞的概念

l在某段时间，若对网络中某资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏——产生 拥塞(congestion)。

l出现资源拥塞的条件：

       对资源需求的总和 > 可用资源      

l若网络中有许多资源同时产生拥塞，网络的性能就要明显变坏，整个网络的吞吐量将随输入负荷的增大而下降。

拥塞控制与流量控制的关系 

l拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。

l拥塞控制是一个全局性的过程，涉及到所有的主机、所有的路由器，以及与降低网络传输性能有关的所有因素。

l流量控制往往指在给定的发送端和接收端之间的点对点通信量的控制，是局部问题。

l流量控制所要做的就是抑制发送端发送数据的速率，以便使接收端来得及接收。 

滑动窗口

lTCP 采用大小可变的滑动窗口进行流量控制。窗口大小的单位是 字节。

l在 TCP报文段首部的窗口字段写入的数值就是当前给对方设置的发送窗口数值的上限。

l发送窗口在连接建立时由双方商定。但在通信的过程中，接收端可根据自己的资源情况， 随时动态地调整对方的发送窗口上限值(可增大或减小)。  

零窗口探测

l不重发接收确认分组会出现以下危险

l工作站将窗口置成0，处于至少在短时间内一个字节也不能从连接上接收的状态。

l拥塞消除后，工作站重新发送接收确认分组，再次打开窗口。 假定该分组在传输中丢失。PC没有收到该分组，故无法知道窗口又被打开。

l这时，此连接出现了问题。如果工作站没有要发送的数据，它就没有理由发送其他TCP分组。另一方面，PC误认为窗口被关闭，不允许发送其他分组。

l为了消除 这种死锁（deadlock）状态，要求PC 侧的TCP发起特殊的操作。也就是说，在窗口完全关闭的情况下，TCP 总是定时地发送分组。

l当然， 因该分组在窗口之外，所以预料对方会拒绝该分组。其结果不外乎以下二种情况，一种是对方以接收确认分组形式传来拒绝信息，利用它可以确认零窗口（zerowindow）仍然存在，另一种实际上是重发那个丢失的带有打开窗口信息的接收确认分组。

l在TCP规范中，推荐在该连接当前的重发定时器设定的时间内若窗口处于关闭状态时，发送第一个零窗口探测分组。然后，应以指数增大的间隔发送其后的探测分组直至某一最大值。

lPC收到关闭窗口的第一个接收确认分组后，立即启动定时器。当定时器超时而窗口依然被关闭时，PC 发送1 字节的数据，即序列号为200的字节。此时，因窗口依然处于关闭状态，工作站可通过对该分组应答进行确认。

l此后当工作站变为能够接收下一个数据的状态时，就发送接收确认分组以开放窗口。图中此分组丢失。幸好，PC再次进行零窗口探测。在进行该操作时，工作站应收到第200 号字节。PC 收到它的确认分组时，窗口已经打开。于是连接上的数据流重新流动。

慢开始和拥塞避免

l发送端的主机在确定发送报文段的速率时，既要根据接收端的接收能力，又要从全局考虑不要使网络发生拥塞。

l因此，每一个 TCP 连接需要有以下两个状态变量：

l接收端窗口 rwnd (receiver window) 又称为通知窗口(advertised window)。

l拥塞窗口 cwnd (congestion window)。

l(1)接收端窗口 rwnd    这是接收端根据其目前的接收缓存大小所许诺的最新的窗口值，是来自接收端的流量控制。接收端将此窗口值放在 TCP报文的首部中的窗口字段，传送给发送端。

l(2)拥塞窗口 cwnd (congestion window)   是发送端根据自己估计的网络拥塞程度而设置的窗口值，是来自发送端的控制。

发送窗口的上限值

l发送端的发送窗口的上限值应当取为接收端窗口 rwnd 和拥塞窗口cwnd 这两个变量中较小的一个，即应按以下公式确定：

发送窗口的上限值= Min [rwnd, cwnd]                 (7-1)

l当 rwnd < cwnd时，是接收端的接收能力限制发送窗口的最大值。

l当 cwnd < rwnd时，则是网络的拥塞限制发送窗口的最大值。

慢开始算法的原理

l在主机刚刚开始发送报文段时可先将拥塞窗口 cwnd设置为一个最大报文段 MSS 的数值。

l在每收到一个对新的报文段的确认后，将拥塞窗口增加至多一个 MSS的数值。

l用这样的方法逐步增大发送端的拥塞窗口cwnd，可以使分组注入到网络的速率更加合理。 

拥塞窗口有个门限值：

当拥塞窗口 cwnd 增长到慢开始门限值 ssthresh时（即当 cwnd = 16 时），就改为执行拥塞避免算法，拥塞窗口按线性规律增长（每经过一个往返时延就将门限值和拥塞窗口加1个mss的大小）。 

在线性增长阶段，慢开始门限指也是一起增长的，当发生拥塞的时候，将门限值设置为原来值的一半，将拥塞窗口重新设为1，开始新的一轮慢开始。

乘法减小

l“乘法减小“是指不论在慢开始阶段还是拥塞避免阶段，只要出现一次超时（即出现一次网络拥塞），就把慢开始门限值ssthresh 设置为当前的拥塞窗口值乘以 0.5。

l当网络频繁出现拥塞时，ssthresh值就下降得很快，以大大减少注入到网络中的分组数。 

加法增大

l“加法增大”是指执行拥塞避免算法后，当收到对所有报文段的确认就将拥塞窗口cwnd增加一个 MSS 大小，使拥塞窗口缓慢增大，以防止网络过早出现拥塞。 

l“拥塞避免”并非指完全能够避免了拥塞。利用以上的措施要完全避免网络拥塞还是不可能的。

l“拥塞避免”是说在拥塞避免阶段把拥塞窗口控制为按线性规律增长，使网络比较不容易出现拥塞。 

快重传和快恢复

l 快重传算法首先要求接收方 每收到一个失序的报文段后就立即发出重复确认 。这 样做可以让发送方及早知道有报文段没有到达接收方 。

l 发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段。

l不 难看出，快重传并非取消重传计时器，而是在某些情况下可更早地重传丢失的报文段 。 

快恢复算法 

)当发送端收到连续三个重复的确认时，就执行“乘法减小”算法，把慢开始门限 ssthresh 减半。但接下去不执行慢开始算法。

(2)由于发送方现在认为网络很可能没有发生拥塞，因此现在不执行慢开始算法，即拥塞窗口cwnd 现在不设置为 1，而是设置为减半后的数值，然后开始执行拥塞避免算法“加

法增大”），使拥塞窗口缓慢地线性增大。

TCP 的重传机制

lTCP每发送一个报文段，就对这个报文段设置一次计时器。只要计时器设置的重传时间到但还没有收到确认，就要重传这一报文段。

l由于 TCP 的下层是一个互连网环境，IP数据报所选择的路由变化很大。因而运输层的往返时延的方差也很大。

往返时延的自适应算法 

l记录每一个报文段发出的时间，以及收到相应的确认报文段的时间。这两个时间之差就是报文段的往返时延。

l 将各个报文段的往返时延样本加权平均，就得出报文段的平均往返时延RTT。

l每测量到一个新的往返时延样本，就按下式重新计算一次平均往返时延RTT：

平均往返时延RTT  =a ´(旧的RTT) + (1 -a) ´(新的往返时延样本)   

l在上式中，0 <=a< 1。   典型的 a值为7/8。 

超时重传时间 RTO 

lRTO应略大于上面得出的加权平均往返时间 RTTS。

lRFC2988 建议使用下式计算 RTO：

l                   RTO = RTTS+ 4 ´ RTTD                 

lRTTD 是 RTT 的偏差的加权平均值。

lRFC 2988 建议这样计算 RTTD。第一次测量时，RTTD 值取为测量到的 RTT样本值的一半。在以后的测量中，则使用下式计算加权平均的 RTTD：

  新的 RTTD= (1 - b)*(旧的RTTD)

                     + b * |RTTS- 新的 RTT 样本l

b 是个小于 1 的系数，其推荐值是 1/4，即 0.25。

 往返时间的测量相当复杂 

TCP 报文段 1 没有收到确认。重传（即报文段 2）后，收到了确认报文段 ACK。

如何判定此确认报文段是对原来的报文段 1 的确认，还是对重传的报文段 2 的确认？

l在计算平均往返时延 RTT时，只要报文段重传了，就不采用其往返时延样本。

l这样得出的 平均往返时延 RTT 和重传时间就较准确。 

l报文段每重传一次，就将重传时间增大一些：

新的重传时间 =g ´(旧的重传时间)             (7-4)

l系数 g的典型值是2。

l当不再发生报文段的重传时，才根据报文段的往返时延更新平均往返时延RTT 和重传时间的数值。

l实践证明，这种策略较为合理。 

MSS选项

l此选项只在准备建立连接时使用，表示接收方能接收的最大分组的尺寸（单位是字节，不包括TCP首部，只是数据部分的尺寸）。

lTCP连接的二个端点可以自由地指定各自的最大报文段长度。

每次最大只能发送窗口大小的数据包。

 2MSL等待状态

TIME_WAIT状态也称为2MSL等待状态

每个具体TCP实现必须选择一个报文段最大生存时间MSL（Maximum Segment Lifetime）。它是任何报文段被丢弃前在网络内的最长时间。

RFC 793 [Postel 1981c] 指出MSL为2分钟。然而，实现中的常用值是30秒，1分钟，或2分钟。