TCP三次握手四次挥手

一、TCP三次握手四次挥手

1.三次握手：

第一次握手：客户端发送syn包(seq=x)到服务器，并进入SYN_SEND(发送)状态，等待服务器确认；

第二次握手：服务器收到syn包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（seq=y），即SYN+ACK包，此时服务器进入SYN_RECV（接收）状态；

第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=y+1)，此包发送完毕，客户端和服务器进入ESTABLISHED（已建立）状态，完成三次握手。

2.四次挥手：

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

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

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

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

3.TCP握手为什么是三次，两次行不行？

首先，为什么是三次握手而不是四次或者更多？这个问题是比较简单的，因为既然三次能够解决的问题，为什么非要用四次来浪费资源？

但其实问题的重点在于，为什么不能只用两次？第三次握手去掉不行吗？

总的来说，三次握手是为了防止当已失效的连接请求报文段突然又传到服务端，造成双方的不一致，导致资源的浪费。

“已失效的连接请求报文段”指的是这样的情况，客户端发出一个SYN报文段，由于阻塞或者其他原因在网络中滞留，以至于客户端认为丢包了（其实并没有丢），于是重新发出一个SYN报文段，假设这一次顺利完成了，那么双方建立连接。这看起来似乎没什么问题，但网络中有一个隐患，就是那个还在网络中传输的SYN报文段，如果这个SYN在连接期间被服务端收到了，那服务端只会无视它，这样就万事大吉了，但如果是在连接释放之后被收到呢？此时服务端认为有人向他发出连接请求，于是响应一个SYNACK回去，如果采用两次握手的话，那么服务器认为此时连接已经建立好了。但是当客户端收到这个SYNACK时，如果他并没有发起连接，那么他不会理睬这个SYNACK，就当没事发生过（如果客户端此时正好发起连接，那其实他也不会理睬这个SYNACK，因为确认号不对啊。）。那问题就大了，这时候服务器以为连接好了，向客户端发送数据，而客户端处于CLOSED状态，会丢弃这些包，这样就很浪费了。并且还有一个尴尬的问题，就是这个时候当客户端打算发起连接时，服务端又不理睬了，在这里尬这，他们就别想互发数据了。当然这些问题似乎不是不可解决的，当客户端发现服务端老是向自己发数据，而自己总是丢弃，可能会向服务端发一个RST（报文段的RST标记号为1），强制服务端关闭连接。但资源总归是浪费了一会了。而用三次握手就不会出现这样的问题。

4.为什么是四次挥手，三次行不行？（做了解，需要详细TCP四次挥手全过程）

因为当服务端收到客户端的 SYN 连接请求报文后，可以直接发送 SYN+ACK 报文。其中 ACK 报文是用来应答的，SYN 报文是用来同步的。但是关闭连接时，当服务端收到 FIN 报文时，很可能并不会立即关闭 SOCKET，所以只能先回复一个 ACK 报文，告诉客户端，“你发的 FIN 报文我收到了”。只有等到我服务端所有的报文都发送完了，我才能发送 FIN 报文，因此不能一起发送。故需要四次挥手。