网络基本功（八）：细说TCP滑动窗口

网络基本功（八）：细说TCP滑动窗口

 

转载请在文首保留原文出处：EMC中文支持论坛https://community.emc.com/go/chinese 

 

介绍

 

将TCP与UDP这样的简单传输协议区分开来的是它传输数据的质量。TCP对于发送数据进行跟踪，这种数据管理须要协议有如下两大关键功能：

可靠性：保证数据确实到达目的地。若是未到达，可以发现并重传。

数据流控：管理数据的发送速率，以使接收设备不致于过载。

要完成这些任务，整个协议操做是围绕滑动窗口确认机制来进行的。所以，理解了滑动窗口，也就是理解了TCP。

更多信息

 

TCP面向流的滑动窗口确认机制:

 

TCP将独立的字节数据看成流来处理。一次发送一个字节并接收一次确认显然是不可行的。即便重叠传输（即不等待确认就发送下一个数据），速度也仍是会很是缓慢。

TCP消息确认机制如上图所示，首先，每一条消息都有一个识别编号，每一条消息都可以被独立地确认，所以同一时刻能够发送多条信息。设备B按期发送给A一条发送限制参数，制约设备A一次能发送的消息最大数量。设备B能够对该参数进行调整，以控制设备A的数据流。

为了提升速度，TCP并无按照字节单个发送而是将数据流划分为片断。片断内全部字节都是一块儿发送和接收的，所以也是一块儿确认的。确认机制没有采用message ID字段，而是使用的片断内最后一个字节的sequence number。所以一次能够处理不一样的字节数，这一数量即为片断内的sequence number。

 

TCP数据流的概念划分类别

假设A和B之间新创建了一条TCP链接。设备A须要传送一长串数据流，但设备B没法一次所有接收，因此它限制设备A每次发送分段指定数量的字节数，直到分段中已发送的字节数获得确认。以后，设备A能够继续发送更多字节。每个设备都对发送，接收及确认数据进行追踪。

若是咱们在任一时间点对于这一过程作一个“快照”，那么咱们能够将TCP buffer中的数据分为如下四类，并把它们看做一个时间轴：

1.    已发送已确认 数据流中最先的字节已经发送并获得确认。这些数据是站在发送设备的角度来看的。以下图所示，31个字节已经发送并确认。

2.    已发送但还没有确认 已发送但还没有获得确认的字节。发送方在确认以前，不认为这些数据已经被处理。下图所示14字节为第2类。

3.    未发送而接收方已Ready 设备还没有将数据发出，但接收方根据最近一次关于发送方一次要发送多少字节确认本身有足够空间。发送方会当即尝试发送。如图，第3类有6字节。

4.    未发送而接收方Not Ready 因为接收方not ready，还不容许将这部分数据发出。

接收方采用相似的机制来区分已接收并已确认，还没有接受但准备好接收，以及还没有接收并还没有准备好接收的数据。实际上，收发双方各自维护一套独立的变量，来监控发送和接收的数据流落在哪一类。

 

Sequence Number设定与同步：

 

发送方和接收方必须就它们将要为数据流中的字节指定的sequence number达成一致。这一过程称为同步，在TCP链接创建时完成。为了简化假设第一个字节sequence number是1，按照上图示例，四类字节以下：

1.     已发送已确认字节1至31。

2.     已发送但还没有确认字节32至45。

3.     未发送而接收方已Ready字节46至51。

4.     未发送而接收方Not Ready字节52至95。

 

发送窗口与可用窗口：

 

整个过程关键的操做在于接收方容许发送方一次能容纳的未确认的字节数。这称为发送窗口，有时也称为窗口。该窗口决定了发送方容许传送的字节数，也是2类和3类的字节数之和。所以，最后两类（接收方准备好而还没有发送，接收方未准备好）的分界线在于添加了从第一个未确认字节开始的窗口。本例中，第一个未确认字节是32，整个窗口大小是20。

可用窗口的定义是：考虑到正在传输的数据量，发送方仍被容许发送的数据量。实际上等于第3类的大小。左边界就是窗口中的第一个字节（字节32），右边界是窗口中最后一个字节（字节51）。概念的详细解释看下图。

 

可用窗口字节发送后TCP类目与窗口大小的改变：

 

当上图中第三类的6字节当即发送以后，这6字节从第3类转移到第2类。字节变为以下：

1.     已发送已确认字节1至31。

2.     已发送但还没有确认字节32至51。

3.     未发送而接收方已Ready字节为0。

4.     未发送而接收方Not Ready字节52至95。

 

确认处理以及窗口缩放：

 

过了一段时间，目标设备向发送方传回确认信息。目标设备不会特别列出它已经确认的字节，由于这会致使效率低下。目标设备会发送自上一次成功接收后的最长字节数。

 

例如，假设已发送未确认字节（32至45）分为4段传输：32-34，35-36，37-41，42-45。第1，2，4已经到达，而3段没有收到。接收方只会发回32-36的确认信息。接收方会保留42-45但不会确认，由于这会表示接收方已经收到了37-41。这是很必要的，由于TCP的确认机制是累计的，只使用一个数字来确认数据。这一数字是自上一次成功接收后的最长字节数。假设目标设备一样将窗口设为20字节。

 

当发送设备接收到确认信息，则会将一部分第2类字节转移到第1类，由于它们已经获得了确认。因为5个字节已被确认，窗口大小没有改变，容许发送方多发5个字节。结果，窗口向右滑动5个字节。同时5个字节从第二类移动到第1类，5个字节从第4类移动至第3类，为接下来的传输建立了新的可用窗口。所以，在接收到确认信息之后，看起来以下图所示。字节变为以下：

1.     已发送已确认字节1至36。

2.     已发送但还没有确认字节37至51。

3.     未发送而接收方已Ready字节为52至56。

4.     未发送而接收方Not Ready字节57至95。

每一次确认接收之后，这一过程都会发生，从而让窗口滑动过整个数据流以供传输。

 

处理丢失确认信息：

 

可是丢失的42-45如何处理呢？在接收到第3段（37-41）以前，接收设备不会发送确认信息，也不会发送这一段以后字节的确认信息。发送设备能够将新的字节添加到第3类以后，即52-56。发送设备以后会中止发送，窗口停留在37-41。

TCP包括一个传输及重传的计时机制。TCP会重传丢失的片断。但有一个缺陷是：由于它不会对每个片断分别进行确认，这可能会致使其余实际上已经接收到的片断被重传（好比42至45）。