TCP连接的建立与关闭过程

TCP连接的建立与关闭过程可以概括为“三次握手，四次挥手”，但是具体的过程还是很复杂，也很难记住，就写下来帮助记忆吧。

先看图片

TCP连接建立与关闭的简单过程

这是《图解TCP_IP》的一张图，很简单，但是没有具体的过程和状态转换。

TCP状态转换图

这张图比较详细，就针对这张图详细分析一下TCP的状态转换，实线代表客户端，虚线代表服务器。

建立连接过程分析

第一次握手：建立连接时，客户端到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。这里注意：请求建立连接的一般都是客户端程序，而服务器空闲时处于LISTEN状态。

第二次握手
服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；RST:表示出现异常要强制断开连接。这里贴出全部8个控制位及其含义。

控制位（图解TCP_IP）

第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。

TCP连接建立过程总结

客户端状态：发送syn进入SYN_SENT→接收SYN,ACK并发送ACK进入ESTABLISHED状态。
服务器状态：接受SYN发送SYN,ACK进入SYN_RCVD→接收ACK进入ESTABLISHED状态或接受RST断开连接。

关闭连接过程分析

第一次挥手：主动关闭方发送一个FIN进入FIN_WAIT_1，用来关闭主动方到被动关闭方的数据传送，也就是主动关闭方告诉被动关闭方：我已经不 会再给你发数据了(当然，在fin包之前发送出去的数据，如果没有收到对应的ack确认报文，主动关闭方依然会重发这些数据)，但是，此时主动关闭方还可以接受数据。

第二次挥手：被动关闭方收到FIN包后，发送一个ACK给对方，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号）。

第三次挥手：被动关闭方发送一个FIN，用来关闭被动关闭方到主动关闭方的数据传送，也就是告诉主动关闭方，我的数据也发送完了，不会再给你发数据了。

第四次挥手：主动关闭方收到FIN后，发送一个ACK给被动关闭方，确认序号为收到序号+1，至此，完成四次挥手。

注意：1.设置2MSL超时的原因：如果直接关闭，而服务器没有接收到最后一个ACK，服务器会重发FIN，此时客户端已经关闭，服务器会认为连接发生错误，而事实上此时已经客户端已经正确关闭。
2.FIN_WAIT_2状态不一定进入。服务器和客户端可能同时关闭，不进入FIN_WAIT_2状态。

关闭连接总结

客户端：发送FIN进入FIN_WAIT_1状态客（客户端停止发送数据）→不同时关闭则接受ACK进入FIN_WAIT_2等待服务器关闭（或同时关闭进入TIME_WAIT）→接受到服务器发送的FIN进入TIME_WAIT（服务器停止发送数据）→等待2MSL→CLOSED
服务器：接受FIN发送ACK进入CLOSE_WAIT→发送FIN等待ACK进入LAST_ACK→接收ACK进入CLOSED

其他问题

（牛客网）
TCP的三次握手过程？为什么会采用三次握手，若采用二次握手可以吗？

答:建立连接的过程是利用客户服务器模式，假设主机A为客户端，主机B为服务器端。
（1）TCP的三次握手过程：主机A向B发送连接请求；主机B对收到的主机A的报文段进行确认；主机A再次对主机B的确认进行确认。
（2）采用三次握手是为了防止失效的连接请求报文段突然又传送到主机B，因而产生错误。失效的连接请求报文段是指：主机A发出的连接请求没有收到主机B的确认，于是经过一段时间后，主机A又重新向主机B发送连接请求，且建立成功，顺序完成数据传输。考虑这样一种特殊情况，主机A第一次发送的连接请求并没有丢失，而是因为网络节点导致延迟达到主机B，主机B以为是主机A又发起的新连接，于是主机B同意连接，并向主机A发回确认，但是此时主机A根本不会理会，主机B就一直在等待主机A发送数据，导致主机B的资源浪费。
（3）采用两次握手不行，原因就是上面说的实效的连接请求的特殊情况。