TCP三次握手和四次挥手详解

 

1. 序（列）号：seq序号，占32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记。

2. 确认号：ack序号，占32位，只有ACK标志位为1时，确认序号字段才有效，ack=seq+1。

3. 标志位：共6个，即URG、ACK、PSH、RST、SYN、FIN等，具体含义如下： * URG：紧急指针（urgent pointer）有效。 * ACK：确认序号有效。 * PSH：接收方应该尽快将这个报文交给应用层。 * RST：重置连接。 * SYN：发起一个新连接。 * FIN：释放一个连接。

解释一下

第一次握手需要建立连接，所以SYN=1，同时发送序号seq=J

第二次握手需要建立连接并且确认序号有效，所以SYN=1，ACK=1，此时ack=J+1，seq=K

第三次握手已经不需要建立连接了，只是确认号有效，所以ACK=1，ack=K+1

具体过程如下

1次握手：Client将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给Server，Client进入SYN_SENT状态，等待Server确认。

2次握手：Server收到数据包后由标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置为1，ack=J+1，随机产生一个值seq=K，并将该数据包发送给Client以确认连接请求，Server进入SYN_RCVD状态。

3次握手：Client收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给Server，Server检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，Client和Server进入ESTABLISHED状态，完成三次握手，随后Client与Server之间可以开始传输数据了。

 

这张图只是示意，其实不准确，混淆了FIN和seq以及ack，seq是序（列）号，ack是确认号，而ACK，SYN，FIN都是标志位

所谓四次挥手

1. 第一次挥手：Client发送一个FIN=1，seq=P用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。

2. 第二次挥手：Server收到FIN后，发送一个ack=P+1给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），ACK=1，seq=Q，Server进入CLOSE_WAIT状态。

3. 第三次挥手：Server发送一个FIN=1，seq=O，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。

4. 第四次挥手：Client收到FIN=1后，Client进入TIME_WAIT状态，接着发送一个ACK=1，ack=O+1，seq=P+1给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。

 为啥需要这么长的TIME_WAIT时间？

原因1：为了保证客户端发送的最后一个ack报文段能够到达服务器。因为这最后一个ack确认包可能会丢失，然后服务器就会超时重传第三次挥手的fin信息报，然后客户端再重传一次第四次挥手的ack报文。如果没有这2msl，客户端发送完最后一个ack数据报后直接关闭连接，那么就接收不到服务器超时重传的fin信息报(此处应该是客户端收到一个非法的报文段，而返回一个RST的数据报，表明拒绝此次通信，然后双方就产生异常，而不是收不到。)，那么服务器就不能按正常步骤进入close状态。那么就会耗费服务器的资源。当网络中存在大量的timewait状态，那么服务器的压力可想而知。

原因2：在第四次挥手后，经过2msl的时间足以让本次连接产生的所有报文段都从网络中消失，这样下一次新的连接中就肯定不会出现旧连接的报文段了。也就是防止已经失效的连接请求报文段出现在本次连接中。如果没有的话就可能这样：这次连接一挥手完马上就结束了，没有timewait。这次连接中有个迷失在网络中的syn包，然后下次连接又马上开始，下个连接发送syn包，迷失的syn包忽然又到达了对面，所以对面可能同时收到或者不同时间收到请求连接的syn包，然后就出现问题了。