TCP/IP三次握手、四次挥手

我们在使用互联网和别的网站进行通信的时候，都要依赖TCP/IP协议。甚至有时候网不太好，浏览器会显示当前状态：正在与某某网站握手...当网络状态很好的时候，就会一闪而过。本文将详细总结笔者在学习三次握手四次挥手时的各个状态以及过程。

首先，状态图如下。

 

• 3次握手

初始时，客户端和服务端都是CLOSED状态。这时，客户端请求连接，作为整个三次握手的开端。

1.客户端向服务器端发送请求连接报文，SYN=1，seq序列码设为x。客户端的状态变为SYN_SENT。在这个报文到达服务器之前，服务器的状态一直是LISTEN，收到报文后状态变为SYN_RCVD。

2.服务器将向客户端返回确认报文。将ACK设为1，SYN=1，seq=y，ack=x+1.

3.客户端收到服务器的确认报文。再向服务器确认一次，ACK=1，seq=x+1，ack=y+1.此时两边建立连接，状态变为ESTABLISHED。

 

看完三次握手的过程，可能会有一个想法：前两次握手完毕之后，不是已经可以直接建立链接了吗？为什么最后还要确认一遍，变成三次握手呢？

假如客户端向服务器发送第一次请求，结果网络不好，这个请求在网络节点中停留了很久，也没有到达服务器端。客户端看服务器端没有回应就重发了一次（这次网络顺畅），正常完成连接后断开。这时，那个第一次发送的请求才到达。假设我们只有两次挥手，那么服务器收到这个请求后会直接和客户端建立连接，但这并不是客户端的本意。造成了资源的浪费以及不必要的错误。

所以加入第三次握手的确认。发生这种情况时，客户端就不会再给服务器发送确认报文，服务端收不到确认报文也就明白了其实客户端并没有请求连接。

 

• 四次挥手

在某一方认为数据已经传输完成后，将会请求断开连接。此时先请求的作为主动方，另一端为被动方。一般是客户端请求断开连接。

1.客户端发出断开请求，FIN=1,seq=u，状态变为FIN_WAIT_1。

2.服务器端收到请求，返回ACK=1，seq=v，ack=u+1代表已经收到客户端的请求。但是此时可能还有没有传输完的数据，需要传输完之后再关闭自己的链接。从服务器返回报文到传输所有数据完毕并再次向客户端发出断开请求之前的这段时间内(CLOSE_WAIT状态)，都在传输没有传输完毕的数据。而客户端在这段等待时间内，处于FIN_WAIT_2状态。

3.此时所有数据传输完成。服务端向客户端发送断开报文，FIN=1，seq=w，ack=u+1，并进入LAST_ACK状态。

4.当客户端收到断开报文后，向服务器确认。ACK=1，seq=u+1，ack=w+1.服务器收到后立即CLOSED，客户端将进入TIME_WAIT状态。在等待2MSL后，断开连接。四次挥手结束。

 

TIME_WAIT状态的作用

1.在最后向服务端发送的ACK这一阶段，ACK可能会丢失。如果没有TIME_WAIT，服务器端没有收到确认报文将再次发送一次断开报文，此时客户端由于没有WAIT已经断开，服务器端也因此不知是否应该关闭。

有了TIME_WAIT，服务器重发后客户端仍然在2MSL（2个报文最大生存周期）内，确保能收到这个重发请求，于是进行重发，并重置2MSL的计时器。这个过程直到2MSL内没有再收到重发请求（即服务器成功断开）时，自己才会CLOSE。

2.和3次握手的第三次原理相同，在2MSL时间段内所有在挥手过程中因为网络问题而滞留的报文将全部消亡，这就保证了下次连接不会被干扰。