TCP简介

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

三次握手

“握手”是用来建立连接的，TCP三次握手的流程图如下：

在TCP/IP协议中。TCP协议提供可靠的连接服务，采用三次握手建立一个连接。

流程解读

第一次握手：建立连接时，客户端发送SYN包【SYN=i】到服务器，并进入SYN_SEND状态，等待服务器服务器确认

第二次握手：服务器收到SYN包，必须确认客户的SYN（ack=i+1），同时自己也发送一个SYN包（SYN=k），即SYN+ACK包，此时服务器进入SYN_RECV状态

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

为什么要进行三次握手才能建立连接呢？

为了初始化Sequence Number的初始值，双方要互相通知自己的初始化Sequence Number，即图上的x和y，这个号码要作为以后的数据通信的序号，以保证应用层接收到的数据不会因为网络上的传输层问题而乱序，即TCP会用这个序号来拼接数据。

首次握手的隐患----SYN超时

问题起因分析：Server接受到clien的SYN，回复SYN、ACK的时候，即客户端断开连接，导致未收到ACK确认， Server不断重试直至超时，Linux默认等待63秒，才断开连接。

为什么等待63秒呢？ 进行5次重试，第一次1秒，第二次2秒，第三次4秒，第四次8秒，第5次16秒，在第5次发出后还需要等待32秒才能判定超时，所以总共是63秒

后果：会出现SYN Flood的风险，用脚本一直开启第一次握手后就断开，影响其它正常的连接

建立连接后，Clien出现故障会怎么办？

保活机制：向对方发送保活探测报文，如果未收到响应，则继续发送，尝试次数达到保活探测数仍未收到响应则中断连接

四次挥手

“挥手”是为了终止连接

流程图如下：

流程解读：

第一次挥手：client发送一个FIN，用来关闭client到server的数据传送，cient进入FIN_WAIT_1状态

第二次挥手：Server收到FIN后，发送一个ACK给client，确认序号为收到序号+1（与SYN相同一个FIN占用一个序号），Server进入close_wait状态

第三次挥手：server发送一个FIN，用来关闭server到client的数据传送，server进入LAST_ACK状态

第四次挥手：client收到FIN后，client进入到TIME-WAIT状态，接着发送一个ACK给server，确认序号为收到的序号+1，server进入CLOSE状态，完成四次挥手

为什么会有TIME-WAIT状态？

原因：确保有足够的使劲按让对方手收到ACK包，避免新旧连接的混淆

为什么需要四次挥手才能断开连接？

因为全双工连接，发送方和接收方都需要FIN报文和ACK报文。

服务器出现大量的CLOSE_WAIT状态的原因？

对方关闭socket连接，我方由于忙着读或者写，没有及时关闭连接

检查代码，特别是释放资源的代码

检查配置，特别是处理请求的现场配置