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