Tcp的三次握手及四次挥手

Tcp的三次握手

TCP报文头：
TCP报文：

传输控制协议TCP简介：

面向连接的，可靠的，基于字节流的传输层通信协议
将应用层的数据流分割成报文段并发送给目标节点的TCP层
数据包都有序号，对方收到则发送ACK确认,未收到则重传
使用校验和来检验数据在传输过程中是否有误

TCP Flags

URG : 紧急指针标志
ACK : 确认序号标志
PSH : push标志
RST : 重置连接标志
SYN : 同步序号标志,用于建立连接过程
FIN : Finsh标志，用于释放连接

TCP三次握手

三次握手详细过程
客户端主动打开连接 ：
先创建一个传输控制块tcp ， 然后向服务器发出一个连接请求报文【SYN包】：该报文首部中 SYN=1, ACK=0 ,seq=x(随机正整数):【发送顺序号】，然后进入同步已发出状态 。（第一次握手）
当tcp客户进程收到服务器确认报文后还会向服务器发送一个确认报文【ACK包】：该报文首部SYN=0,ACK=1,seq=x+1:【发送顺序号】,ack=y+1 :【接收顺序号】 然后进入连接状态 。（第三次握手）
服务器被动打开连接 ：
先创建一个传输控制块tcp 然后处于监听状态。
服务器接收到客户端连接请求后，如果同意连接就会向客户端发送一个确认报文【SYN ACK包】：该报文首部SYN=1,ACK=1,seq=y(随机正整数): 发送顺序号，ack=x+1：接收顺序号 然后进入同步已发出状态 。（第二次握手）
服务器收到客户端的确认报文后 进入连接状态。

抓包截图

三次握手简述
在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接。
第一次握手: 建立连接时，客户端发送SYN包（seq=x）到服务器，并进入SYN_SEND状态,等待服务器确认。
第二次握手：服务器收到SYN包 ,必须确认客户端SYN包（ack=x+1）,同时自己也发送一个SYN包（seq=y),即SYN+ACK包,此时服务器进入SYN_RECV状态。
第三次握手：客户端收到服务器端SYN+ACK包,向服务器发送确认包ACK (ack=y+1 seq=x+1)，此包发送完毕,客户端和服务器进入ESTABLISHED状态,完成三次握手。

为什么需要三次握手才能建立起连接
为了初始化Sequence Number的值

首次握手的隐患——SYN超时
问题起因：
Server收到Client的SYN,回复SYN-ACK的时候未收到ACK的确认
Server不断重试直至超时,Linux默认等待63秒才断开连接针对SYN Flood的防护措施
SYN队列满后, Server通过tcp_syncookies参数回发SYN Cookies
若为正常连接则Client会回发SYN Cookies，直接建立连接（就不通过SYN队列来建立连接）

建立连接后,Client出现故障怎么办
保活机制
向对方发送保活特测报文，如果未收到响应则继续发送 。
尝试次数达到保活探测数仍未收到响应则中断连接。

Tcp的四次挥手

TCP四次挥手简述
TCP采用四次挥手来释放连接
第一次挥手: Client 发送一个FIN包，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。
第二次挥手: Server收到FIN包后，发送一个ACK包给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号), Server进入CLOSE_WAIT状态 。Client收到ACK包后进入FIN_WAIT_2状态
第三次挥手：Server发送一个FIN,用来关闭Server到Client的数据传送,Server进入LAST_ACK状态
第四次挥手：Client收到服务器的FIN包后进入TIME_WAIT状态,接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态,完成四次挥手。

为什么会有TIME_WAIT状态
原因：
确保有足够的时间让对方接受ACK包
避免新旧连接混淆

为什么需要四次握手才能断开连接
因为全双工，发送方和接收方都需要FIN报文和ACK报文来确定连接的断开

服务器出现大量CLOSE_WAIT状态的原因
对方关闭socket连接 我方忙于读写没有及时关闭连接