HTTP之TCP三次握手及四次挥手

TCP协议应该所有开发人员都听过，至于有没有搞清楚就不知道了。今天分享一下自己理解的思路。

TCP协议是传输层的协议，除了TCP协议之外，应用层还是UDP协议。相对比，UDP协议不可靠，TCP丢包之后会重新传输，UDP不会，而且UDP是无序的。两者之间还是有很多区别的，UDP也有自己的优点，比如传输速度快。现在大部分都是由TCP协议。

先明白TCP协议作用：

为了在不可靠的网络上提供可靠的端到端字的传输协议，网络的结构、带宽、延迟、数据包大小和其他参数等都有很大的不同，TCP的作用是能够动态地适应网络的这些不同，拥有面对各种故障时的健壮性。而且对应的数据包如果已丢失，TCP将会被进行重传。简单记忆就是保证数据通信的完整性和可靠性，防止丢包。

TCP三次握手：

三次握手主要的目的是为了确认两个应用层都具备收和发的能力。

第一次握手，发送方发送SYN=1、SEQ=X，证明了发送方能发数据；

第二次握手，接收方发送SYN=1、ACK=X+1、SEQ=Y，ACK确保了接收方能收数据，SYN确保了接收方能发数据；

第三次握手，接收方发送ACK=Y+1、SEQ=Z，证明了发送方能接收。

所以这就是为什么需要三次握手而不是两次四次五次，大于三次浪费，少于三次不能保证双方同时具备收和发。

当然，三次握手的SYN、ACK、SEQ都有深层次的解释和意义，比如数据包的组装、慢启动等，自己觉得不需要去了解那么深。三次握手还有一个作用，就是节省服务器的开销，如果三次握手中间有一个是失败的，那么服务器就不会一直等待，浪费性能，而是直接关闭这个连接。

TCP四次挥手：

跟三次握手差不多，也是为了让发送方和接收方知道数据状态。

第一次挥手，发送方发送FIN告诉接收方发送完毕，要关闭传输；

第二次挥手，接收方发送ACK=FIN+1告诉发送方知道发完了；

第三次挥手，接受方发送FIN告诉发送方，接收完了，要关闭数据传输；

第四次挥手，发送方发送ACK告诉接收方知道了。

四次挥手其实不单单只有FIN和ACK，还有其他的数据包，比如STN和SEQ等。这边只是以FIN和ACK为主介绍一下。那为什么需要四次呢？因为当发送方告诉接收方发完了的时候，接收方还有可能没接收完消息，所以只能先回复一部分，告诉发送方已经收到发完了的消息了。当消息完全接收完毕之后，才会告诉发送方已经接收完了。

这只是三次握手和四次挥手，TCP协议是非常复杂的，什么对应的状态、报文、数据分类、传输技术、滑动窗口协议、超时重传SACK方法等。这边只是分享了最简单的三次握手和四次挥手，而且连这两个部分都只是简单的介绍。