TCP三次握手目的及流程

三次握手的目的是为了建立可靠的通信连接，而通信简单来说就是数据的发送与接收，三次握手最根本的目的就是确认双方的发送与接收能力是否正常。

最开始的时候客户端和服务器都处于CLOSED状态，主动打开连接的是客户端，被动打开连接的是服务端

服务端TCP进程先创建传输控制块TCB，时刻准备接收客户端进程的连接请求，此时服务端为LISTEN状态

第一次握手：
客户端进程创建传输控制块TCB，发送同步序号SYN=1，随机产生初始序列号seq number=x的请求报文到服务端，并进入SYN_SENT状态，等待服务端确认。TCP规定，SYN报文段（SYN=1的报文段）不能携带数据，但要消耗一个序号seq，这也是为什么ack number = seq + 1
服务端由SYN=1知道客户端要求建立联机。

第二次握手：
服务端收到请求报文后需要确认联机信息，于是向客户端发送包含同步序号SYN=1，随机产生序列号seq number=y，确认序号ACK=1，ack number=x+1的数据包，并由LISTEN状态进入SYN_RECV状态。这个报文也不能携带数据，但是同样要消耗一个seq

第三次握手：
客户端收到服务端发送的数据包后检查ack number是否正确（ack number是否为为第一次发送的seq+1以及ACK是否为1），校验成功后向服务端发送包含确认序号ACK=1，ack number=y+1，自己的序列号seq=x+1的数据包，此包发送完成后，客户端和服务器进入ESTABLISHED状态，完成三次握手。TCP规定，ACK报文段可以携带数据，但是如果不携带数据则不消耗序号seq

为什么TCP是三次握手而不是两次？

三次握手完成了两个重要的功能：
①确认双方都知道彼此已经做好了发送数据的准备工作。
②允许双方就初始序列号seq进行协商，这个序列号在握手过程中被发送和确认。

如果不是三次握手而是两次，死锁是可能发生的。假设客户端给服务端发送一个连接请求报文，服务端成功接收并给客户端发送了确认应答报文，此时服务端并不能确认该应答报文是否成功到达了客户端，但因为两次握手的协定，服务端此时已经处于成功建立连接的状态（ESTABLISHED），并给客户端发送数据报文。但如果客户端并未收到服务端的应答报文，则不知道服务器是否准备好建立连接，也不知道服务器建立什么样的序列号，甚至不知道自己发送给服务端的报文是否成功抵达，此时客户端会认为连接并未成功建立，会忽略服务端发送过来的任何数据报文，只进行等待服务端的确认应答报文。而服务端在发出的数据报文未得到响应超时后，会重复发送同样的数据报文，这样就形成了死锁。

如果成功建立了连接，但客户端突然出现故障怎么办？

如果客户端突然出现故障，服务端是不可能一直等待下去的。此时就需要TCP的保活机制来进行判断
TCP的保活机制：
在保活时间tcp_keepalive_time中，即此时连接处于非活动状态，在此期间服务器每收到一次客户端的请求后都会重新复位计时器，通常设定为2小时。若2小时未收到客户端任何数据，则开启保活功能的一端（假设为服务端），将给客户端发送保活探测报文，如果服务端未收到响应，经过保活时间间隔tcp_keepalive_intvl（默认为75s）后，服务端继续发送保活探测报文，直到发送次数为保活探测数tcp_keepalive_probes（默认为9次）。若依旧没有收到回复，则客户端确认不可达，连接也将中断。