目录
一、简述TCP连接和关闭的状态转移
二、简述TCP慢启动
三、简述TCP如何保证有序
四、简述TCP常见的拥塞控制算法
五、简述TCP超时重传
一、简述TCP连接和关闭的状态转移
图中上半部分是TCP的三次握手过程的状态变迁，下半部分是TCP四次挥手过程的状态变迁。
1、CLOSED。起始点，在超时或者连接关闭时进入此状态，这并不是一个真正的状态，而是这个状态图的假想起点和终点。
2、LISTEN。服务器端等待连接的状态。服务器经过socket，bind，listen函数之后进入此状态，开始监听客户端发过来的连接请求。这称为应用程序被动打开（等待客户端连接请求）。
3、SYN_SENT。第一次握手发生阶段，客户端发起连接。客户端调用connect，发送SYN给服务器端，然后进入SYN_SENT状态，等待服务器端确认（三次握手中的第二个报文）。如果服务器端不能连接，则直接进入CLOSED状态。
4、SYN_RCVD。第二次握手发生阶段，与3相对应，这里是服务器端接收到了客户端的SYN，此时服务器由LISTEN进入SYN_RCVD状态，同时服务器端回应一个ACK，然后再发送一个SYN即SYN+ACK给客户端。状态图中还描述了这样一种情况，当客户端在发送SYN的同时也收到服务器端的SYN请求，即同时发起连接请求，那么客户端就会从SYN_SENT转换到SYN_RCVD状态。
5、ESTABLISHED。第三次握手发生阶段，客户端接收到服务器端的ACK包（ACK，SYN）之后，也会发送一个ACK确认包，客户端进入ESTABLISHED状态，表明客户端这边已经准备好，但TCP需要两端都准备好才可以进行数据传输。服务器端收到客户端的ACK之后会从SYN_RCVD状态转换到ESTABLISHED状态，表明服务器端也准备好进行数据传输了。这样客户端和服务器端都是ESTABLISHED状态，就可以进行后面的数据传输了。所以ESTABLISHED也可以说是一个数据传送状态。
下面介绍TCP四次挥手过程的状态变迁：
1、FIN_WAIT_1。第一次挥手，主动关闭的一方（执行主动关闭的一方既可以是客户端，也可以是服务器端。这里以客户端执行主动关闭为例），终止连接时，发送FIN给对方，然后等待对方返回ACK。调用close()第一次挥手就进入此状态。
2、CLOSE_WAIT。接收到FIN之后，被动关闭的一方进入此状态。具体动作是接收到FIN，同时发送ACK。之所以叫CLOSE_WAIT，可以理解为被动关闭的一方此时正在等待上层应用程序发出关闭连接指令。TCP关闭是全双工过程，这里客户端执行了主动关闭，被动方服务器端接收到FIN后也需要调用close关闭，这个CLOSE_WAIT就是处于这个状态，等待发送FIN，发送了FIN则进入LAST_ACK状态。
3、FIN_WAIT_2。主动端（这里是客户端）先执行主动关闭发送FIN，然后接收到被动方返回的ACK后进入此状态。
4、LAST_ACK。被动方（服务器端）发起关闭请求，由状态2进入此状态，具体动作是发送FIN给对方，同时在接收到ACK时进入CLOSED状态。
5、CLOSING。两边同时发起关闭请求时（即主动方发送FIN，等待被动方返回ACK，同时被动方也发送了FIN，主动方接收到FIN之后，发送ACK给被动房），主动方会由FIN_WAIT_1进入此状态，等待被动方返回ACK。
6、TIME_WAIT。从状态变迁图中看到，四次挥手操作最后都会经过这样一个状态然后进入CLOSED状态。
| *状态* | 描述 |
| CLOSED | 阻塞或关闭状态，表示主机当前没有正在传输或者建立的链接 |
| LISTEN | 监听状态，表示服务器做好准备，等待建立传输链接 |
| SYN_RECV | 收到第一次传输请求，还未进行确认 |
| SYN_SENT | 发送完第一个SYN报文，等待收到确认 |
| ESTABLISHED | 链接正常建立之后进入数据传输阶段 |
| FIN_WAIT_1 | 主动发送第一个FIN报文之后进入该状态 |
| FIN_WAIT_2 | 已经收到第一个FIN的确认信号，等待对方发送关闭请求 |
| TIMED_WAIT | 完成双向链接关闭，等待分组消失 |
| CLOSING | 双方同时关闭请求，等待对方确认 |
| CLOSING_WAIT | 收到对方的关闭请求并进行确认进入该状态 |
| LAST_ACK | 等待最后一次确认关闭的报文 |
二、简述TCP慢启动
慢启动（Slow Start），是传输控制协议（TCP）使用的一种阻塞控制机制。慢启动也叫做指数增长期。慢启动是指每次TCP接收窗口收到确认时都会增长。增加的大小就是已确认段的数目。这种情况一直保持到要么没有收到一些段，要么窗口大小到达预先定义的阈值。如果发生丢失事件，TCP就认为这是网络阻塞，就会采取措施减轻网络拥挤。一旦发生丢失事件或者到达阈值，TCP就会进入线性增长阶段。这时，每经过一个RTT窗口增长一个段。
三、简述TCP如何保证有序
1、主机每次发送数据时，TCP就给每个数据包分配一个序列号并且在一个特定的时间内等待接收主机对分配的这个序列号进行确认，如果发送主机在一个特定时间内没有收到接收主机的确认，则发送主机会重传此数据包。接收主机利用序列号对接收数据进行确认，以便检测对方发送的数据是否有丢失或者乱序等。接收主机一旦收到已经顺序化的数据，它就将这些数据按正确的顺序重组成数据流并传递给高层进行处理。
2、具体的步骤为：
（1）为了保证数据包的可靠传递，发送方必须把已经发送的数据包保留在缓冲区；
（2）并为每个已发送的数据包启动一个超时定时器；
（3）如在定时器超时之前收到了对方发来的应答信息（可能是对本包的应答，也可能是对本包后续包的应答），则释放该数据包占用的缓冲区；
（4）否则，重传数据包，直到收到应答或重传次数超过规定的最大次数为止；
（5）接收方收到数据包后，先进行CRC校验，如果正确则把数据交给上层协议，然后发送方发送一个累计应答包，表明该数据已经收到，如果接收方正好也有数据要发给发送方，应答包也可以在数据包中捎带过去。
四、简述TCP常见的拥塞控制算法
1、TCP Tahoe/Reno
最初的实现，包括慢启动、拥塞避免两个部分。基于重传超时（retransmission timeout/RTO）和重复确认为条件判断是否发生了丢包。两者的区别在于：Tahoe算法下如果收到三次重复确认，就进入快重传立即重发丢失的数据包，同时将慢启动阈值设置为当前拥塞窗口的一半，将拥塞窗口设置为1MSS，进入慢启动状态；而Reno算法如果收到三次重复确认，就进入快重传，但不进入慢启动状态，而是直接将拥塞窗口减半，进入拥塞控制阶段，这称为“快恢复”。
2、TCP BBR（Bottleneck Bandwidth and Round-trip propagation time）
BBR是由Google设计，于2016年发布的拥塞算法。以往大部分拥塞算法是基于丢包来作为降低传输速率的信号，而BBR则基于模型主动探测。该算法使用网络最近出站数据分组当时的最大带宽和往返时间来建立网络的显式模型。数据包传输的每个累积或选择性确认用于生成记录在数据包传输过程和确认返回期间的时间内所传送数据量的采样率。该算法认为随着网络接口控制器逐渐进入千兆速度时，分组丢失不应该被认为是识别拥塞的主要决定因素，所以基于模型的拥塞控制算法能有更高的吞吐量和更低的延迟，可以用BBR来替代其它流行的拥塞算法，例如CUBIC。
五、简述TCP超时重传
TCP可靠性中最重要的一个机制是处理数据超时和重传。
TCP协议要求在发送端每发送一个报文段，就启动一个定时器并等待确认信息。接收端成功接收到新数据后返回确认信息。若在定时器超时前数据未能被确认，TCP就认为报文段中的数据已丢失或损坏，需要对报文段中的数据重新组织和重传。
