---

一、TCP协议原理（二）

1.解决TIME_WAIT状态引起的bind失败的方法

我们之前实现tcp服务器的时候发现，服务器经常有时候断开可以立即重启，有时候断开必须换端口号才能重新启动，这实际上就是因为服务器是先断开连接的一方，最后的状态是TIME_WAIT状态，这个时候服务器并没有真的关闭，还会等待一段时间确认另一方没有因为丢包等问题而重新向服务器发送FIN报文，服务器等待的时间是2*MSL（报文从一端到另一端的时间），在这期间内连接和端口依旧存在，端口依旧被占用所以导致我们无法绑定成功，下面我们可以看看绑定不成功的样例：

 首先建立连接，然后我们让服务端直接关闭，然后我们就发现重启服务器这个8080端口号不能用了。在生活中一般出现这样的情景都是服务器压力过大，由于客户端连接的太多，最后导致服务器崩溃退出，这个时候退出服务器就会维持大量的TIME_WAIT，如果这个时候服务器无法立即重启就会导致公司造成大量损失，要解决这个问题实际上很简单，只需要调用系统接口setsockopt:

 下面我们解决这个问题：

 下面我们运行起来试一下：

 可以看到当我们将服务器退出后，立即重启服务器不会像之前那样bind error了。

2.流量控制

1.滑动窗口一定会向右滑动吗？会向左滑动吗？

2.窗口一定会一直不变吗？会变大吗？会变小吗？为什么？变的依据是什么？

3.收到应答确认的时候，如果不是最左侧发送的报文的确认，而是中间的，结尾的等怎么办？要滑动吗？

4.滑动窗口必须要滑动吗？会不会不动了？或者变为0了？

下面我们解决以上4个问题：

 实际上滑动窗口滑动的原理就是下标的移动，而滑动窗口的大小和对方的接收能力有关，并且我们的滑动窗口是肯定不会向左滑动的，因为新数据存放的位置一定是在已发送但是没有应答区域的右边。那么一定会向右滑动吗？不一定，可能会保持不变。当对方的接收缓冲区越来越小时，我们要让win_start指针向右移动缩小滑动窗口，但是win_end指针不变所以这个时候窗口并没有滑动。

当需要更新滑动窗口的时候，我们假设win_start的报文对方已经收到并且应答了，这个时候我们只需要让win_start变成ACK_SEQ(确认报文的序号),win_end指向win_end+对方接受能力大小。当收到确认应答的时候如果是滑动窗口中间的或者结尾的，我们只需要让win_start下标移动到确认应答报文的序号位置即可，因为序号表示这个序号前面所有的报文都收到了，所以可以从序号位置开始。如果出现丢包问题，那么分为两种情况，1.数据没丢，应答丢了，这个情况不需要管，下次的确认应答收到后会直接移动到下次报文序号的位置。2.数据丢了，那么win_start下标必须移动到丢了的数据报文序号位置。

实际上滑动窗口并不是线性结构，是一个环形结构，所以可以一直滑动。

下面我们用图理解一下滑动窗口中的两种情况：

1.数据包没丢，ack丢了

 2.数据包丢了

这种机制被称为 "高速重发控制"(也叫 "快重传").

4.拥塞控制

前面我们讲TCP报头的时候看到过里面有16位窗口大小，这个16位窗口大小实际上就是拥塞窗口。而我们在网络拥塞中每次发送数据包的时候，实际上是取对方接受能力大小和拥塞窗口之前的较小值，这样既不会超过窗口值引起网络拥塞，也不会影响发送的效率。

为什么要引入慢启动的阈值呢？因为当网络逐步恢复，窗口大小再继续以指数级增长就没有意义了，网络恢复后我们只需要看对方接受缓冲区大小是多少我们就能最大发送多少，即使窗口再大也还是受对方缓冲区大小的限制。所以一旦拥塞窗口大小增加到慢启动阈值的时候我们就开始线性增长，不再进行指数增长了。

当TCP开始启动的时候，慢启动阈值等于窗口最大值。在每次超时重发的时候，慢启动阈值会减小到原来的一半，同时拥塞窗口置为1. 

下面我们讲解一下上图：横坐标是传输轮次，纵坐标是我们发送方的拥塞窗口大小。第一次我们的网络拥塞发生在发送24个报文的情况下，然后我们开始慢启动，先出两个报文开始，然后4个报文，指数增长到16个报文后受到慢启动阈值限制开始线性增长，当我们增长到24个报文的时候又一次发生了网络拥塞，这个时候重新慢启动，阈值进行乘法减小，拥塞窗口置为1，然后从1个报文开始指数增长，到达新的阈值后开始线性增长。在网络中我们可能会多次遇到网络拥塞情况，所以每次都会重复慢启动的步骤。

5.延迟应答

6.捎带应答

7.面向字节流

8.粘包问题

9.TCP异常情况

---

总结

TCP的可靠性是通过各种优秀的机制实现的，重要的保证可靠性的机制有：序列号(按序到达),校验和，确认应答，超时重传，拥塞控制，连接管理，流量控制。

提升性能的机制有：滑动窗口，捎带应答，延迟应答，快速重传。

tcp的粘包问题主要是没有明确报文边界：

在传输层的角度：tcp就是一个一个的报文，按照序号存放在缓冲区中。

在应用层的角度：看到的是一串连续的字节数据，所以需要定制协议确认每一个数据包。

明确报文边界的方法：

对于定长的包，保证每次读取固定大小即可。

对于变长的包，约定在包头添加包总长度的字段，这样就明确包的结束部分。

对于变长的包，可以在包和包之间使用明确的分隔符。（只要保证分隔符不和正文冲突即可）