TCP流控和拥塞

今天我们来了解一下TCP的流控处理和拥塞处理机制。

 

上两节我们提到了TCP传输中建立连接和数据传输的一些基本流程，但是在传输数据的过程中可能出现一些意外情况，比如，一段数据发送到服务端后，服务端一直不返回任何的ACK,或者数据中的某一段如200-300这段过去后，服务器一直没有返回301，出现这种情况TCP协议是怎么进行处理的呢？接下来我们就来详细的说说这个问题。

 

针对上述情况，在TCP协议中，客户端和服务端建立连接后，双方都保有一个缓冲区，服务器会告诉客户端它自身的缓冲区的大小，我们现在以8K为假设，1K我们看作一小块。然后客户端知道服务端的缓冲大小后，也不是一次就直接传输这么大数据过去的，而是有一个慢启动的过程，TCP协议中有一个拥塞窗口，它会从1个字节开始发送数据进行试探，等待服务器返回ACK，确定能收到对应的ACK后，然后再逐渐2K,4K,8K这样爆炸式的递增，同时用于流控的滑动窗口Window也结合拥塞窗口的大小，两者取小的一个为window窗口的大小来进行数据传输。当最后到达服务器缓冲区的整体大小时， 这个时候服务器处理所有数据没有多余的空间来接受新数据，对客户端发来的新数据就不会有ACK进行返回了。就会出现之后提出的问题。

如下图，就是一个window的示意图：

 

下面来解决之前提到的两个问题：

当客户端发送数据的过程中某一个时候一直收不到服务端的ACK，会触发重发机制，这在上面的两篇中有提到，每次等待的时间是1S,2S,4S,8S,16S，经过5次重传，最后一次还要等待32S，这样经过1分钟后，如果还是没收到，则表示超时了。然后客户端继续进行这样一个过程，当几次都超时后，会判定为服务器已经断开或者服务器拥堵非常严重处理不了数据了， 就会断开连接。

另一种情况，当客户端发送一段数据，我们假设分为100-200，201-300，301-400，401-500，501-600.我们抽象的假设window大小为400Bit，那么window起始时再100-500之间的。当100-200到达服务器，服务器返回了201，表示确认收到了这段数据，这个时候window会整体往后移动100，注意：在数据传输的过程中，服务器是会一直告诉客户端自己的缓冲区大小的，客户端会根据这个值来改变每次window的大小。如果缓冲区大小没变的话，window变成从201-600，然后201-300服务器没收到，一直没返回301，服务器会等待这个数据包，会不间断的一直返回201给到客户端，后面异步传输的301-400收到后也会返回201，401-500到达后也会返回201，当客户端三次接收到201的时候就会判断window卡在了201-300这个位置，数据丢失了， 就会启动高速重传201-300这个数据段给到服务器，服务器如果收到了，会返回最后收到的数据的ACK码，即501给到客户端，然后整体window继续往后移。整个高速传输的过程就是这样的。这就是流控。

以上的过程另外衍生出的问题点有：

1.我们有定义一个RTT为一个数据来回的时间(这个时间是通过多次传输算出来的，丢失的数据包不算入里面)，等待时间是通过RTT算出来的比如为2S等。当客户端在等待的时间内没收到ACK，而这个时候服务端的ACK其实已经在返回给客户端的路上的时候，客户端收到ACK的时候已经重发了这段数据，服务端的SYC就是用来去重复的数据和保持数据顺序的。

2.拥塞窗口和滑动窗口的大小是一直在变动的，比如拥塞窗口发去的包一直通过试探在增长最后总会到达缓冲区的极限，这个时候可能会导致服务器数据处理不了，网络拥堵，服务器就会自动告诉客户端将缓冲大小将为原来的一半，当拥塞窗口再次从1个包增长到原来的一半时就不会再爆炸式的增长，而是开始缓慢增加试探到底什么时候开始会出现丢包和无法收到ACK的情况，这样滑动窗口的大小也在跟随着发生变化。

 

这种高速重传可能还存在的一个问题点：

上述讲述的是201-300丢失，卡在201，后面的都传输成功了， 当201-300重传成功后直接返回了501，全部数据都过去了。那么加入201-300，301-400，401-500，都是丢失的包呢， 那么当201-300成功后，又要重新重传301-400，然后重传401-500，这是很影响效率的。那么有没有机制能记录哪些数据段是没有传输成功的， 然后将连续的几段数据一起重传呢。这就有了后来的SACK。即在window卡住的地方后面会多处一个变量，专门用来记录之后没有收到的包的ACK，然后判断之后是否需要一起重传。