TCP三次握手、四次挥手

1. 说具体过程之前，我们先解释一下TCP几个标志位

 SYN:建立联机
 ACK:确认
 FIN：关闭连接
 RST:重置
 URG：紧急

2. 三次握手具体过程如下：

第一次握手：客户端发送一个请求建立连接数据包，其中SYN=1,并随机产生一个序列号。当服务端收到这个数据包后，由SYN=1得知客户端想建立连接，
第二次握手：服务端对客户端的连接请求进行确认，向客户端发送确认包，其中ACK=1,SYN=1,确认序列号为客户端序列号加1，并产生一个自己随机序列号。
第三次握手：客户端对收到的服务器端的建立联机的数据包进行确认，告诉服务端，你的请求连接被确认。

3.四次挥手具体过程如下：

第一次挥手：客户端数据传输完毕时，客户端向服务端发送FIN=1的数据包，相当于告诉服务端，我的数据传输完了，请求释放连接。
第二次挥手：由于建立的连接时全双工的，服务端收到客户端释放连接请求的时候并不会马上向客户端传FIN=1的的数据包，他要等他的数据传完之后才发送FIN=1的数据包，而是先对客户端释放连接的请求进行确认，令ACK=1,告诉他你释放连接的请求我已经收到了，但是我还有数据没有传完，等我传完在释放连接。
第三次挥手：服务端数据传输完成后，向客户端发送标志位FIN=1的数据包，表示自己数据传输完毕请求释放连接，
第四次挥手：客户端收到服务端释放连接的请求后，对他的释放请求进行确认，把自己设置成TIME-WAIT状态，并启动定时器，当服务端没有收到来自客户端的确认，当它的定时器超时后会要求客户端重新发送ACK。当服务端收到客户端的确认时候，服务端就断开连接，客户端等待2MSL（报文最大生存时间）时候没有收到服务端的重传请求后，他就知道服务端已经收到ACK，并且客户端也关闭连接。

4.关于三次握手、四次挥手有几个要说的是问题

TCP建立连接为什么是三次握手？
在谢希仁版的计算机网络中解释为“为了防止已经失效的连接请求报文突然又传到了服务器端，因而产生错误”：当客户端发送建立连接的报文段，在网络中某个节点滞留时间太长，以至于客户端认为它丢失了，重新发送一个建立连接的报文，后发送的这个报文成功建立连接之后，之前误认为丢失的报文又到达了服务端，服务端认为是客户端新的建立连接的请求报文，如果不采用三次握手机制，这样服务端会与之建立连接。服务端会一直等待客户端发来请求，但是客户端并没有想与之建立连接， 这样服务端很多资源都白白浪费掉。

四次挥手之后客户端为什么不能立刻关闭连接，而是要等2MSL？
为了防止第四次确认连接释放的报文丢失，客户端关闭连接之后，确认报文丢失，那么服务端会重新发送释放连接的报文，但是客户端已经关闭，所以，服务端永远收不到来自客户端的确认。