TCP的三次握手和四次挥手，打太极，有来有回

1.先来看一下三次握手流程

为何说TCP是可靠的连接

第一次握手：建立连接时候，客户端A发送SYN（SYN=j）包到服务器B，并且进入SYN-SEND待发送状态，等待服务器确认；

第二次握手：服务器收到SYN包，必须确认客户端的SYN（ack=j+1），同时自己也发送一个SYN包（SYN=k），即SYN+ACK的包，然后服务器进入SYN-RECV等待状态；

第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK（ack=k+1），此包发送完毕，客户端和服务器进入ESTABLISHED建立连接状态，完成了三次握手；

大家发现了一个特点没有，就是客户端A发送了SYN包，服务器收到的话就会发送一个SYN包（在收到客户端A的SYN包的基础上+1），而且顺带添加了一个ACK的回复确认消息包，然后客户端收到服务器的ACK的包会向服务器发送一个ACK确认包，也就是在服务器的ACK包基础上+1然后发送给服务器，说明我收到了你的消息啦；

这就很好理解了，为何要在收到对方包的基础上+1，首先确保了我收到你该收到的东西，我连接的是你，而不是其他人，而且我连接的时候要确保顺序，客户端发送了一个消息给你，我要先收到你的回复说你收到了我的回复，你确认了收到，而不是说直接建立连接，跳到第三次握手；

  所以！！总结：三次握手时确保连接的是想要连接的对象，而且确保每次建立连接的顺序；

1.1.但是三次握手时间这么长，繁杂，那如果服务端收到客户端发送的消息然后回复给客户端的时候，客户端掉线了怎么办？

 2.1：服务器会不断重试直到超时（重试次数是5次并且，每次重试等待时间在原来的基础上翻倍），所以linux服务器默认等待63（1+2+4+8+16+32）秒才断开连接。

2.2：既然如此重试机制这么多次，那么就会耗费资源，可能会存在的问题就是，恶意人通过客户端一直发送SYN报文，然后下线，导致服务器一直重试，占用大部分资源，但是linux服务器做了一个特殊处理，就是SYN队列满了后，通过tcp-syncookies参数回发SYN Cookie，如果是正常连接则Client会回发SYN Cookie，直接建立连接，而那些恶意连接会丢失处理

2.3：为了防止客户端突然故障掉线，还做了一个机制，叫保活机制，就是我们常说的，刺探，服务端会向对方发送一些暗号报文，叫保活探测报文，如果未收到响应，则继续发送，但发送的次数是有规定的，达到一定次数没有收到响应则中断连接。

2.四次挥手，挥了挥再见，不带走一片云彩！

老规矩，先看图，资源有限，图片有点模糊，见谅一下

 第一次挥手：客户端发送一个FIN，用来关闭客户端到服务器的数据传送通道，客户端进入FIN-WAIT-1状态；

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

第三次挥手：服务器发送一个FIN，用来关闭服务器到客户端的数据传送通道，服务器进去LAST-ACK状态；

第四次挥手：客户端收到FIN后，客户端进入TIME-WAIT状态，接着发送一个ACK给服务器，确认序号为收到序号+1，服务器进入CLOSED状态，完成四次挥手；

这里为啥客户端最后的时候要进行2MSL（2个TIME-WAIT状态）时间的等待呢？

 原因：

        1.TIME-WAIT状态是确保有足够的时间让对方收到ACK包，而大家想想一来一去是不是两个TIME-WAIT时间，那等待2个TIME-WAIT时间就是确保能收到对方消息；

 那为什么需要四次握手才可以断开连接？

 1.因为全双工，就是说发送方和接收方都需要FIN报文和ACK报文，所以各需要两次