11 TCP如何实现可靠传输

回顾chapter5 运输层（传输层）【上】 中讲的可靠传输

现在来仔细讲解，如何实现可靠传输：

• 1. 以字节为单位的滑动窗口技术

11.1 以字节为单位的滑动窗口技术

数据报无丢失情况下的可靠传输：

• 发送窗口能传输的最大数据量 由 接收窗口的容量决定的。
• 在接受端得到确认的数据，就可以被接收端的应用程序接收；同时发送端可以将被确认的数据从发送缓存中删除。

• 在每次发送的数据量可以是不相同的（如第一次发送3字节，第二次可以是4字节）。 数据报在传输时有丢失的情况下的可靠传输：

• SACK（选择性确认）：当丢包时，会有选择性确认来指出丢失的那段数据段的第一个数据的 序号。

  11.2 超时重传时间的选择

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

• RTT（报文段的往返时间）：记录一个报文段 发出的时间，以及收到相应的确认时间，这个两个时间之差。
• RTT**（平滑往返时间，或 加权平均往返时间）：

RFC2988推荐的α值为1/8 = 0.125

• 其中：0≤α<1。若α很接近于0，表示新的RTT与旧的相比变化不大，而对新的RTT 样本影响不大（RTT值更新较慢）。
• 若α很接近于1，表示新的RTT值受新的RTT样本影响较大（RTT值更新较快）。

12 TCP协议如何实现流量控制

流量控制：让发送方的发送速率不要过快，要让接收方来得及接受。 当接收端（B）的窗口发送给发送端（A）的数据报中关于接收窗口的大小为假设为400字节（在此的上一个数据报中接收端口的大小为0），但是这个数据报不小心丢失了（丢包）。此时会造成：传送过程中丢失了。A一直等待收到B发送的非零窗口的通知，而B也一直等待A发送的数据。如果没有其他措施，这种互相等待的死锁局面将一直延续下去。

为了解决这个问题，TCP每一个连接设有一个“持续时间器”。只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器。若持续计时器设置的时间到期，就发送一个零窗口探测报文段（仅携带Ⅰ字节的数据）R，而对方就在确认这个探测报文段时给出了现在的窗口值。如果窗口仍然是零，那么收到这个报文段的一方就重新设置持续计时器。如果窗口不是零，那么死锁的僵局就可以打破了。

13 TCP的拥塞控制

在计算机网络中的链路容量（即带宽)、交换结点中的缓存和处理机等，都是网络的资源。在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫做拥塞(congestion)。可以把出现网络拥塞的条件写成如下的关系式：

若网络中有许多资源同时呈现供应不足，网络的性能就要明显变坏，整个网络的吞吐量将随输入负荷的增大而下降。 **

13.1 TCP的“拥塞控制”与“流量控制”的区别

• 拥塞控制是一个全局性的过程，涉及到所有的主机，所有的路由器，以及与降低网络传输性能有关的所有因素。
• 流量控制往往指在给定的 发送端 和 接收端 之间的点对点通信量的控制，它所要做的就是抑制发送端发送数据的速率，以便使接收端来得及接收。

13.2 拥塞控制所起到的作用

提供的负载均衡：表示单位时间内输入给网络的分组（数据）数目。（又称：“输入负载”、“网络负载”）
吞吐量：表示在单位时间内通过某个网络(或信道、接口)的实际的数据量。

带宽相当于理论上能通过的数据量；吞吐量表示实际情况下通过的数据量。

• 理想的拥塞控制：
  • 在吞吐量饱和之前，网络吞吐量应等于提供的负载，故吞吐量曲线是45°的斜线。
  • 当提供的负载超过某一限度时，由于网络资源受限，吞吐量不再增长而保持水平线，即吞吐量达到饱和。（这就表示当提供的负载为150M时，有50M会被丢弃，只传输100M的数据量。）

在这种理想的拥塞控制作用下，网络的吞吐量仍然未知在其所能达到的最大值。

• 无拥塞控制：
  • 但是，实际网络的情况就很不相同了。随着提供的负载的增大，网络吞吐量的增长速率逐渐减小。也就是说，在网络吞吐量还未达到饱和时，就已经有一部分的输入分组被丢弃了。当网络的吞吐量明显地小于理想的吞吐量时，网络就进入了轻度拥塞的状态。
  • 当提供的负载达到某一数值时，网络的吞吐量反而随提供的负载的增大而下降，这时网络就进入了拥塞状态。
  • 当提供的负载继续增大到某一数值时，网络的吞吐量就下降到零，网络已无法工作，这就是所谓的死锁(deadlock)。

• 实际的拥塞控制：
  • 就是要讲的TCP拥塞控制。

13.3 TCP拥塞控制的实现

TCP进行拥塞控制的算法有四种，即慢开始(slow-start)、拥塞避免(congestion
avoidance)、快重传(fast retransmit)和快恢复(fast recovery)（见2009年9月公布的草案标准
RFC 5681)。下面就介绍这些算法的原理。为了集中精力讨论拥塞控制，我们假定：

• 数据是单方向传送的，对方只传送确认报文。
• 接收方总是有足够大的缓存空间，因而发送窗口的大小由网络拥塞程度来决定。

13.3.1 慢开始和拥塞避免

下面讨论的拥塞控制也叫做基于窗口的拥塞控制。为此，发送方维持一个叫做拥塞窗cwnd(congestion window)的状态变量。【】

• 拥塞窗口的大小：取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口。 慢开始算法
  慢开始算法的思路：

• 当主机开始发送数据时，由于并不清楚网络的负荷情况，所以如果立即把大量数据字节注入到网络，那么就有可能引起网络发生拥塞。经验证明，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是说，由小到大逐渐增大拥塞窗口数值。

拥塞避免算法：
的思路是让拥塞窗口cwnd缓慢地增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是像慢开始阶段那样加倍增长。因此在拥塞避免阶段就有“加法增大”AI (Additive Increase)的特点。这表明在拥塞避免阶段，拥塞窗口cwnd按线性规律缓慢增长，比慢开始算法的拥塞窗口增长速率缓慢得多。

注意：

• “拥塞避免”并非指完全避免了拥塞。利用以上措施要完全避免网络拥塞还是不可能的。
• “拥塞避免”是说在拥塞避免阶段把拥塞窗口控制为按线性规律增长，是网络比较不容易出现拥塞。

13.3.2 快重传和快恢复

在慢开始算法出现之后，又发明了快重传 和 快恢复。

接收方窗口又称为通知窗口。发送方的发送窗口一定不能超过对方给出的接收方窗口值rwnd。

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

当发送端收到连续三个重复的确认时，就执行“乘法减小”算法，把慢开始门限ssthresh减半，但拥塞窗口cwnd现在不设置为1，而是设置为慢开始门限ssthresh 减半后的数值，然后开始执行拥塞避免算法（“加法增大”），使拥塞窗口缓慢地线性增大。

• 加法增大：在拥塞避免阶段，拥塞窗口是按照线性规律增大的，这常称为加法增大AI (Additive Increase)。
• 乘法减小：而一旦出现超时或3个重复的确认，就要把门限值设置为当前拥塞窗口值的一半，并大大减小拥塞窗口的数值。这常称为“乘法减小”MD(Multiplicative Decrease)。

二者合在一起就是所谓的AIMD 算法。

快恢复算法
与快重传对应的避免拥塞的算法：快恢复

13.3.3 发送窗口的实际上限值

发送方的窗口的上限值应当取为接收方窗口rwnd和拥塞窗口cwnd这两个变量中较小的一
个，也就是说：

14 TCP的传输连接管理

TCP是面向连接的协议。它是可靠传输的。运输连接是用来传送TCP报文的。TCP运输连接的建立和释放是每一次面向连接的通信中必不可少的过程。因此，运输连接就有三个阶段，即：连接建立、数据传送和连接释放。运输连接的管理就是使运输连接的建立和释放都能正常地进行。

TCP连接的建立采用客户服务器方式。主动发起连接建立的应用进程叫做客户(client)，而被动等待连接建立的应用进程叫做服务器(server)。

在TCP连接建立过程中要解决以下三个问题：

1. 要使每一方能够确知对方的存在。
2. 要允许双方协商一些参数（如最大窗口值、是否使用窗口扩大选项和时间戳选项以及服务质量等）。
3. 能够对运输实体资源（如缓存大小、连接表中的项目等）进行分配。

14.1 TCP的连接建立：三次握手

TCP建立连接的过程叫做握手，握手需要在客户和服务器之间交换三个TCP报文段。图5-28画出了三报文握手建立TCP连接的过程。

假定主机A运行的是TCP’客户程序，而B运行TCP服务器程序。最初两端的TCP进程都处于CLOSED（关闭）状态。图中在主机下面的方框分别是TCP进程所处的状态。请注意，在本例中，A主动打开连接，而B被动打开连接。

• 一开始，B的TCP服务器进程先创建传输控制块TCB，准备接受客户进程的连接请求。然后**服务器**进程就处于**LISTEN**（收听）状态，等待客户的连接请求。如有，即作出响应。A的TCP客户进程也是首先创建传输控制模块TCB。然后，在打算建立TCP连接时，向B发出连接请求报文段，这时首部中的同步位SYN= 1，同时选择一个初始序号seq =X。这时，TCP客户进程进入SYN-SENT（同步已发送）状态。

  TCP规定，SYN报文段（即SYN= 1的报文段）不能携带数据，但要消耗掉一个序号。

• B收到连接请求报文段后，如同意建立连接，则向A发送确认。在确认报文段中应把SYN位和ACK位都置1，确认号是ack = x+1，同时也为自己选择一个初始序号seq=y。这时**TCP服务器进程**进入**SYN-RCVD（同步收到）**状态。

  请注意，这个报文段也不能携带数据，但同样要消耗掉一个序号。

• TCP客户进程收到B的确认后，还要向B给出确认。确认报文段的ACK置1，确认号ack =y+1，而自己的序号seq=x+1。这时，TCP连接已经建立，A进入 ESTABLISHED(已建立连接）状态。

  TCP的标准规定，ACK报文段可以携带数据。但如果不携带数据则不消耗序号，在这种情况下，下一个数据报文段的序号仍是seq=x+1。

注意： 上面给出的连接建立过程叫做三报文握手。请注意，在图5-28中B发送给A的报文段，也可拆成两个报文段。可以先发送一个确认报文段（ACK= 1, ack = x +1)，然后再发送一个同步报文段（SYN = 1, seq = y)。这样的过程就变成了四报文握手，但效果是一样的。

14.1.1 为什么需要第三次握手

为什么A最后还要发送一次确认呢？这主要是为了防止已失效的连接请求报文段突然又传送到了B，因而产生错误。

• 所谓“已失效的连接请求报文段”是这样产生的。考虑一种正常情况，A发出连接请求，但因连接请求报文丢失而未收到确认。于是A再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接。A共发送了两个连接请求报文段，其中第一个丢失，第二个到达了B，没有“已失效的连接请求报文段”。
• 现假定出现一种异常情况，即A发出的第一个连接请求报文段并没有丢失，而是在某些网络结点长时间滞留了，以致延误到连接释放以后的某个时间才到达B。本来这是一个早已失效的报文段。但B收到此失效的连接请求报文段后，就误认为是A又发出一次新的连接请求。于是就向A发出确认报文段，同意建立连接。假定不采用报文握手，那么只要B发出确认，新的连接就建立了。
• 由于现在A并没有发出建立连接的请求，因此不会理睬B的确认，也不会向B发送数据。但B却以为新的运输连接已经建立了，并一直等待A发来数据。B的许多资源就这样白白浪费了。

  14.1.2 TCP建立连接时的各种状态

  可以使用命令：netstat -n查看建立会话的状态
  

14.2 TCP的连接释放

TCP连接释放整个过程的示意图：

1、

数据传输结束后，通信双方都可释放连接。现在A和B都处于ESTABLISHED状态。

请注意，TCP规定，FIN报文段即使不携带数据，它也消耗掉一个序号。

2、

此时，A就不能给B发送数据了(A已经释放连接了)。但是B还没有释放连接，B还可以继续发送数据给A，A仍要接收。
A收到来自B的确认后，A就进入**FIN-WAIT-2**（终止等待2）状态，等待B发出的连接释放报文段。

3、

若B已经没有要向A发送的数据，其应用进程就通知TCP释放连接。这时B发出的连接释放报文段必须使FIN=1。
现假定B的序号为w(在半关闭状态B可能又发送了一些数据)。B还必须重复上次已发送过的确认号ack = u+1。这时B就进入**LAST-ACK**(最后确认）状态，等待A的确认。

4、

A在收到B的连接释放报文段后，必须对此发出确认。在确认报文段中把ACK置1，确认号ack = w +l，而自己的序号是seq = u+1(前面发送过的FIN报文要消耗一个序号），然后进入到TIME-WAIT（时间等待）状态。

注意：此时TCP连接还没有释放掉。必须经过时间等待计时器（TIME-WAIT timer）设置的时间2MSL后，A才进入到**CLOSED***状态。

MSL：最长报文段寿命，RFC793建议设置为2分钟。

14.2.1 为什么A在 TIME-WAIT状态必须等待2MSL的时间呢?

**

• 第一，为了保证A发送的最后一个ACK 报文段能够到达B。这个ACK报文段有可能丢失，因而使处在LAST-ACK状态的B收不到对已发送的FIN +ACK报文段的确认。B会超时重传这个FIN + ACK报文段，而A就能在2MSL时间内收到这个重传的FIN+ACK 报文段。接着A重传一次确认，重新启动2MSL计时器。最后，A和B都正常进入到CLOSED状态。如果A在TIME-WAIT状态不等待一段时间，而是在发送完ACK报文段后立即释放连接，那么就无法收到B重传的FIN +ACK报文段，因而也不会再发送一次确认报文段。这样，B就无法按照正常步骤进入CLOSED状态。
• 第二，防止上一节提到的“已失效的连接请求报文段”出现在本连接中。A在发送完最后一个ACK报文段后，再经过时间2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。B只要收到了A发出的确认，就进入CLOSED状态。同样，B在撤销相应的传输控制块TCB后，就结束了这次的TCP连接。我们注意到，B结束TCP连接的时间要比A早一些。

14.3 TCP的有限状态机

为了更清晰地看出TCP连接的各种状态之间的关系，图5-30给出了TCP的有限状态机。

• 图中每一个方框即TCР可能具有的状态。
• 每个方框中的大写英文字符串是TCP标准所使用的TCP连接状态名。
• 状态之间的箭头表示可能发生的状态变迁。
• 箭头旁边的字，表明引起这种变迁的原因，或表明发生状态变迁后又出现什么动作。
• 请注意图中有三种不同的箭头：
  • 粗实线箭头表示对客户进程的正常变迁。
  • 粗虚线箭头表示对服务器进程的正常变迁。
  • 另一种细线箭头表示异常变迁。