TCP连接的建立与释放----三次握手与四次挥手

一、TCP连接建立

1、TCP连接建立需要经过三次握手：

（1）首先由 Client （客户端）发出请求连接即 SYN=1 ACK=0 , TCP 规定SYN=1 时不能携带数据，但要消耗一个序号,因此声明自己的序号是 seq=x（随机产生且不为0），此时客户端进入SYN_SEND（准备发送）状态。

（2）然后 Server（服务器端） 进行回复确认，即 SYN=1 ACK=1 seq=y, 确认号ack=x+1（表示是对“连接请求报文（序号seq=x）的确认”），这时服务器进入SYN_RCVD（准备接收）状态。

（3）再然后 Client 再进行一次确认，但不用 SYN 了，按照TCP协议规定，这个“连接请求报文”的序号仍为seq=x+1，所以这时即为 ACK=1, seq=x+1,ack=y+1.，此时客户端进入ESTABLISHED（已建立连接）状态，服务器再收到ACK报文后也进入此状态。

2、为什么采用三次握手而不是采用两次握手？

之所以采取三次握手机制，不过是为了信息传输的可靠性，如果其中某个握手失败，这个过程将会重复，来确保其可靠性。
如果采取两次握手，相当于第二次握手结束便建立连接，如果发送SYN的一方不想连接了，也不会有反馈，另一方却一直在等待，浪费了时间。
当然可以采取4次甚至N次握手，但是有必要吗？建立连接的时间太长，效果也会大打折扣。
所以3次只是折中方案，保证了可靠性，又节俭了建立连接的时间，

谢希仁版《计算机网络》中的例子: "已失效的连接请求报文段”的产生在这样一种情况下：
client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。
本来这是一个早已失效的报文段,但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。
于是就向client发出确认报文段，同意建立连接。

假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。
由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据,但server却以为新的运输连接已经建立，并一直等待client发来数据。
这样，server的很多资源就白白浪费掉了。 采用“三次握手”的办法可以防止上述现象发生。
例如刚才那种情况，client不会向server的确认发出确认,server由于收不到确认，就知道client并没有要求建立连接。”
这个例子很清晰的阐释了“三次握手”对于建立可靠连接的意义。

二、TCP连接释放

1、TCP连接释放需要经过四次挥手：

注：图片来源于网络

TCP连接的释放较复杂，客户端和服务器端都可以主动提出连接释放请求，上面的图片以客户端主动发出释放请求为例：
（1）第一次挥手：客户端发送一个FIN，用来关闭主动方到被动关闭方的数据传送，也就是客户端告诉服务器端：我已经不会再给你发数据了(当然，在fin包之前发送出去的数据，如果没有收到对应的ack确认报文，主动关闭方依然会重发这些数据)，但是，此时主动关闭方还可以接受数据。客户端进入FIN-WAIT-1状态

（2）第二次挥手：服务器端收到FIN包后，发送一个ACK给对方，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号）。服务器端进入CLOSE-WAIT状态，客户端接收到ACK报文之后进入FIN-WAIT-2状态

（3）第三次挥手：服务器端发送一个FIN，用来关闭被动关闭方到主动关闭方的数据传送，也就是告诉客户端，我的数据也发送完了，不会再给你发数据了。服务器端进入LAST_ACK状态

（4）第四次挥手：客户端收到FIN后，发送一个ACK给服务器端，确认序号为收到序号+1，然后客户端进入TIME_WAIT状态，服务器端收到ACK报文段以后，就关闭连接。

2、为什么是四次挥手

因为TCP是全双工模式，假设A，B要释放连接，那么A发送一个连接释放报文给B，B收到后发送确认，这时A不再发送数据，但B如果发送数据，A还是要接收，然后B数据发完之后同样也要发送一个连接释放报文给A，然后A收到后发送确认，一共是4次。