TCP提高可靠性&性能的一些机制

TCP之所以比UDP复杂，是因为它要保证可靠性，又要尽可能地提高性能。所以就产生了许多机制，用以实现可靠性及提高性能，其中：
保证可靠性：校验和、序列号（按序到达）、确认应答、超时重传、连接管理、流量控制、拥塞控制
提高性能：滑动窗口、快速重传、延迟应答、捎带应答
下面，稍微详细的为大家介绍一些上述机制。
1. 校验和
在TCP的首部字段有一个”16位的校验和“字段，它是由发送端填充的，由接收端验证的CRC校验，用以保证数据是正确的。若是接收端校验不通过，则认为数据有问题，接收端就会直接将相应的TCP数据丢弃。且TCP的校验和是必须的，而UDP是可选择的。
2. 序列号
TCP将每个字节的数据都进行了编号，即序列号。因为TCP是面向字节流的，因为网络问题，不能保证数据是按照顺序到达接收端的接收缓冲区，所以序列号可以将到达接收缓冲区的数据重新变得有序。
3.确认应答
每一个ACK都带有对应的确认序号，它可以告诉发送端，接收端已经接收到了哪些数据，接下来从哪里开始发数据。
4.超时重传
主机A发送给主机B的数据，可能因为网络问题导致数据很长的时间无法到达主机B，所以主机A迟迟接收不到主机B发送的ACK；或者是主机B接收到了数据，但是主机B发送给A的ACK丢失。上述情况造成的主机A在一个特定的时间间隔内没有收到B发来的确认应答，此时A认为B没收到数据，就会重发数据。
所以，若是B发送的ACK丢失所造成的重发，这会导致B收到很多的重复数据。这是我们就可以利用前面提到的序列号，将重复的数据包丢弃，达到去重的目的。
超时的时间怎么确定呢？一般情况，我们要找到，在正常情况下确认应答一定能够返回的时间。但是随着网络状态的不同，这个时间是不同的。如果超时时间设置过长，会影响整体的重传效率；若设置过短，就会造成频繁的发送重复的数据包。
所以，TCP为了保证在任何情况下都较高性能的通信，它会动态的计算这个超时时间。在Linux下，以500ms作为一个单位，每次判断超时都是500ms的整数倍。第一次等待500ms，得不到ACK，就触发第一次重传；若仍得不到应答，等待2*500ms再重传；若还是得不到应答，再等待4*500ms进行重传……依次类推，以指数形式进行增长。累计到一定的重传次数，TCP会认为网络异常或是对端主机异常，强制关闭连接。

5.连接管理
该部分见博客TCP的连接管理机制，有详细介绍。
6.流量控制
接收端的接收能力是有限的。如果发送端发的太快，接收端又来不及处理，就有可能导致接收端的接收缓冲区满的情况。这个时候，发送端若是继续发数据，就会造成丢包，而后引发重传等一系列连锁反应。
所以，TCP会根据接收端的处理能力，来决定发送端的发送速度，这个机制即为流量控制。
接收端将自己还能接收的缓冲区大小放入TCP首部中的”16位窗口大小“字段，通过ACK告诉发送端；窗口大小字段越大，说明网络的吞吐量越高；当接收端的接收缓冲区要满时，就会将窗口大小设置为一个更小的值通知发送端，发送端就会减慢自己的发送速度；当接收缓冲区满了，就会将窗口大小设置为0，此时发送端停止发送数据，但是会定期的发送一个窗口探测数据段，了解接收缓冲区的情况，以便等接收缓冲区有空时，发送端可以继续发送数据。
7.拥塞控制
我们可以通过滑动窗口高效可靠的发送大量数据，但是若是在一开始就发送大量的数据，仍然有可能引发问题。因为一开始，并不了解当前的网络情况，网络上有很多的计算机，如果当前网络已经很拥堵了，再一次性发送大量数据，就会让网络”雪上加霜“。
TCP引入慢启动机制，先发少量的数据，探查当前的网络状况，再决定按照多大的速度传输数据。所以引入”拥塞窗口“，开始时，拥塞窗口为1，每次收到一个ACK，拥塞窗口加1。每次发送数据时，将拥塞窗口与接收端反馈的窗口大小比较，取最小值作为实际发送的窗口。但是这样，拥塞窗口的增长速度就会非常快，为了不让它那么快，我们引入慢启动的”阈值“，当达到阈值之前，拥塞窗口以指数方式增长，达到阈值之后，线性增长（一次增加1）。直至达到网络拥塞的拥塞窗口最大值，就会触发超时重传机制，此时将拥塞窗口置为1，慢启动阈值变成原来的一半。当TCP开始启动时，阈值为窗口的最大值。
在这里，少量的丢包我们仅仅触发超时重传机制；大量的丢包，我们认为网络堵塞。归根结底，拥塞控制即是TCP想尽快的将数据传给对方，又要避免给网络很大压力的折中方法。
8.滑动窗口&快速重传
对于确认应答机制来讲，是对于每一个发送的数据段，给予一个ACK应答，收到ACK之后再发送下一个数据段，这样性能就比较差了，尤其是数据往返时间比较长的时候。
所以引入”滑动窗口“。窗口大小是无需等待确认应答可以继续发送数据的最大值比如发送端可以一次向接收端发送序列号为1~1000的数据，此时接收端若全部接收到，就向发送端发送确认应答，告诉发送端下一个是1001，发送端就知道1~1000的数据接收端全部接到了，就可以继续发送了。操作系统为了维护这个滑动窗口，需要开辟发送缓冲区来记录当前还有哪些数据没有应答，哪些数据应答过了，哪些数据是等待要发送的。只有确认应答过的数据，才能从缓冲区删掉。窗口越大，网络吞吐量就越高。
但是这里若是出现丢包情况，如何重发呢？
第一种情况，接收端接收到数据了，只是它返回给发送端的ACK丢失。这种情况并不要紧，它可以通过后续的ACK进行确认。
第二种情况，发送端发送的数据包丢失，接收端并没接到。当某一段报文比如1~1000的丢失了，发送端会一直接收到1001这样的ACK（可能重复好几次收到），所以发送端会重发1~1000的数据。当接收端接收到数据，发送端再次接收到ACK，可能就是7001的ACK了。因为在前面发送端重复接收到1001的ACK时，其实就是2001~7001已经正常收到了，只是没收到1~1000，所以返回的ACK一直是1001。这种重传机制叫做”快重传“。
9.延迟应答
假设接收缓冲区为1M，一次收到了500K的数据，此时若立刻应答，返回的窗口大小为500K。但是若接收端的处理速度很快，10ms内就将500K的数据从缓冲区消费了，此时再应答，窗口大小就是1M。这就是延迟应答。
但是也不是所有的包都延迟应答：我们有数量限制即每隔N个包就应答一次；还有时间限制即超过最大延迟时间就应答一次。一般N取2，超时时间取200ms。
10.捎带应答
因为TCP的一个连接，既有发送缓冲区，也有接收缓冲区，所以对于这样一个连接，既可以读也可以写，这种叫做”全双工”方式。所以主机A可以向主机B发数据，同时主机B也可以向主机A发数据。当主机B作为接收端要给A发送ACK时，它可以搭个顺风车，和B要发给A的数据一起发给A。