TCP协议可靠性保证（确认应答机制，超时重传机制，流量控制，拥塞窗口）

一、综述

• 确认应答机制 
• 超时重传机制 
• 流量控制 
• 拥塞窗口

确认应答机制 

在将这部分的内容之前我们应该首先知道的一点就是，在TCP中，TCP将每个字节的数据都进行了编号，即为序列号（对每一个数据的编号）。 

由图分析：当主机1给主机2发送了1~1000这么多数据时，主机2如果收到了就会给主机1应答（ACK报文段，每一个ACK都带有对应的确认序列号），表示你给我发的1~1000的数据我已经全部收到了（收到哪些数据），下次你再给我发就给我从1001数据开始发（下次从哪里开始发）。那么主机1收到应答之后就知道对方已经收到了1~1000的全部数据，所以再一次发送数据的时候他就会从1001开始发，后面都是依此类推的情况。

当然了，当我们的主机1给主机2发送了数据之后，经过一端时间主机1并没有收到主机2的应答的情况也是有的，所以这个时候为了确保数据的准确到达，TCP就有了超时重传机制。 

超时重传机制 

主机1没有收到主机2的确认应答有以下两种情况： 
1、数据根本就没有传送到达主机2，因此主机2就不会回传一个确认应答的报文。

由图分析：主机1给主机2发送了数据，可能因为其他的原因数据无法到达主机2.（比如网络拥堵）。这个时候主机1等待了一个特定的时间间隔之后发现主机2还没有确认应答，于是就再一次将上一次的数据重新发送过去。

2、主机2收到了数据，也回传了确认应答报文，但是该报文丢失了。 

由图分析：主机2收到了主机1发来的数据，但是发给主机1的确认应答并没有准时到达主机1，所以主机1也会因为没有收到确认应答而再次重新将数据发送过去。但实际情况却是我们的主机2第一次就已经收到了主机1的数据。但是主机1依旧会重发数据已确保主机2已经收到数据，从而进行下一次的数据转发。可想而知主机2就会收到很多的重复数据，但是重复的数据显然是不需要的，那么TCP协议就需要能够识别那些重复的数据并且要将冲符的数据丢弃掉，这个时候序列号就发挥他的一项作用了——去重。每一个数据都有自己的序列号，如果主机2收到重复的数据那么必然机会产生多个序列号相同的数据，那么序列号相同的数据就必然是重复的数据。

我们提到一个特定的时间间隔，这个时间又是如何规定的？

最理想的情况下，找到一个最小的时间保证确认应答一定能在这时间内返回 
但是这个时间的长短，随着网络环境的不同，也是有差异的。 
如果超时时间设得太长，会影响整体的重传效率 
如果超时时间设的太短，有可能平凡的发送冲符的数据包。 
TCP为了抱枕个无论在何种环境下都能比较高性能的通信，因此会动态计算这个最大超时时间： 
Linux中，超时以500ms为一个单位进行控制，每次判定超时重发的超时时间都是500ms的整数倍。 
如果重发一次，任然得不到应答，就等待2*500ms后在进行重传 
如果还得不到应答，等待4*500ms再重传，一次类推，以指数形式递增。 
累积到一定的重传次数，TCP认为网络或者对端主机出现异常，就会强制关闭连接。

流量控制

接收端处理数据的速度是优先的，如果发送端发的太快，导致接收端的缓冲区被打满，这个时候如果发送端继续发送就会造成丢包，继而引起丢包重传等一系列连锁反应。因此TCP支持根据接收端的处理能力，来决定发送端的发送速度，这个机制就叫做流量控制。

接收端将自己可以接受的缓冲区大小放入TCP首部中的“窗口大小”字段，通过ACK段通知发送端； 
窗口大小字段越大，说明网络的吞吐量越高 
接收端一旦发现自己的缓冲区快满了就会将窗口大小设置成一个更小的值通知发送端。 
发送端接收到窗口大小以后，就会减慢自己的发送速度。 
如果接收缓冲区满了，就会将窗口置为0，这时发送方不再发送数据。 
但是需要定期的发送一个试探窗口，，目的是为了取探测数据段，是接收端把窗口大小告诉发送端。

 

接收端是如何把窗口大小告诉发送端的呢？在TCP的首部中有一个16位的窗口大小的字段，就是存放的窗口大小的信息。另外在TCP的首部中的40字节选项中还包含了一个窗口扩大因子M，实际的窗口大小是窗口字段的值左移M位。

拥塞窗口

在后面会讲到TCP提高性能的滑动窗口，滑动窗口能够高效可靠的发送大量的数据，但是如果在一开始就发送大量的数据任然可能引发问题。要知道在网络上有很多的计算机，有可能当前的网络状态已经很拥堵，在不清楚当前的网络状态下，贸然发送大量的数据，这样对于已经很拥堵的网络来说无疑是雪上加霜。 
由此，TCP引入了慢启动机制：先发送少量的数据，由此取探测当前的网络的拥堵状态，在决定按照多大的速度传输数据。 

拥塞窗口： 
发送开始的时候定义拥塞窗口大小为1 
每当收到一个ACK应答以后拥塞窗口加1 
每次发送数据包的时候，将拥塞窗口和接收端主机反馈的窗口大小作比较，取较小值作为实际发送的窗口。 
如图，拥塞窗口的增长速度呈指数形式增长，我们提到说慢启动，只是说出事的时候慢而已，但是增长速度非常的快。为了增长的不那么快，因此我们不能让拥塞窗口单纯的加倍，这里引入一个慢启动的阈值，当同色窗口超过这个阈值的时候，不再按照指数方式增长，而是改为按照线性的方式增长。 
当TCP开始启动的时候，慢启动阈值等于窗口最大值，在每次超时重发的时候，慢启动阈值会变成原来的一半，同时拥塞窗口置为1。

少量的丢包，仅仅只会触发超时重传，而大量的丢包就认为是网络拥堵，当TCP通信开始后，网络吞吐量会逐渐的上升，随着网络发生拥堵，吞吐量会立刻下降，拥塞控制说到底就是TCP协议想尽可能快的将数据传输给对方，但又要避免给网络造成太大的压力的折中解决办法。

TCP滑动窗口和拥塞控制机制详解

滑动窗口的定义：	1.“窗口”对应的是一段可以被发送的字节序列，其连续的范围称为窗口；2.“滑动”则是指这段“允许发送的范围”是可以随着发送的过程而变化的，方式就是按顺序“滑动”。
滑动窗口的作用：	是一种流量控制方法，该协议允许发送方在停止等待确认前可以连续发送发个分组。由于发送方不必每发送一个分组就停下来等待确认，因此该协议可以加速数据的传输。

在了解具体的例子之前我们先来了解几个重要的前提

基本概念

-1 TCP协议的两端分别是发送者A和接受者B，由于是全双工通讯的，因此A and B应该同时维护着一个独立的发送缓冲区和接受缓冲区，由于对等性，我们以A发送B接受的情况作为例子；

-2 发送窗口是发送缓存的一部分，是可以被TCP协议发送的那部分，其实应用层需要发送的所有数据都被放进了发送者的发送缓冲区了；当接收方确认数据后，这个滑动窗口不时地向右移动。窗口两个边沿的相对运动增加或减少了窗口的大小。

-3 发送窗口相关的四个概念：已发送并收到确认的数据（不再发送窗口和发送缓冲区之内）；已发送但未收到确认的数据（位于发送窗口之中）；允许发送但尚未发送的数据以及发送窗口外发送缓冲区内暂时不需要发送的数据。

-4 每次成功发送数据之后，发送窗口就会在发送缓冲区中按顺序移动，将新的数据包含到窗口中准备发送。

窗口移动

1.称 窗口左边沿 向右边沿 靠近为 窗口合拢 这种现象发生在数据被发送和确认时 2.当 窗口右边沿 向 右移动时将允许发送更多的数据，我们称之为窗口张开 这种现象发生在另一端的接受进程读取已经确认的数据并释放了TCP的接收缓存时 3.当 右边沿 向左移动时，我们称之为窗口收缩 Host Requirements RFC强烈建议不要使用这种方式。但TCP必须能够在某一端产生这种情况时进行处理。

如果左边沿到达右边沿，则称其为一个零窗口，此时发送方不能够发送任何数据。

滑动窗口的几个特点

1.发送方不必发送一个全窗口大小的数据。

2.来自接收方的一个报文段确认数据并把窗口向右滑动，这是因为窗口的大小是相对于确认序号的。

3.正如从报文段7到8中的变化那样，窗口的大小可以减小，但是窗口的右边沿却不能向左移动。

4.接收方在发送一个ACK前不必等待窗口被填满。在前面可以得知许多实现每收到两个报文段就会发送一个ACK。

TCP建立连接的初始，B会告诉A自己的接受窗口的大小，比如‘20’：字节31 - 50为发送窗口。

A发送11个字节后，发送窗口的位置不变，B接收到乱序的数据分组。

只有当A成功发送了数据，并且需要得到B的确认（ACK）之后，才会移动滑动窗口离开已发送的数据；同时B则确认连续的数据分组（只有这样窗口才能移动），对于乱序的分组则先接受下来，避免网络重复传递。

只有当接收方 新的ACK对于发送窗口中后续字节的确认时，窗口滑动，滑动原理如下：窗口的左边沿可以滑动到36的位置。