TCP三次握手，四次挥手及潜在问题，netstat排查服务器各状态连接数

 

查看TCP 三次握手 报文工具 wireshark

首次所致手的隐患-- SYN超时：

起因分析：server收到Clinet的SYN。回复SYN-ACK的时候未收到ACK确认。

Server不断重试直至超时。linux默认等待63秒才断开连接。（等待1秒，2秒，4秒，8秒，16秒，32秒）

针对SYN flood的防护措施 linux

SYN队列满后，通过tcp_syncookies参数回发SYN Cookie

若为正常连接，则Client会回发SYN Cookie直接建立连接。即使SYN队列满了，本次请求不在对队中依然能建立连接。

 建立连接后，Client出现故障怎么办？ 保活机制

向对方发送保活探测报文，如果未收到响应则继续发送

尝试次数达到保活探测数仍未收到响应则中断连接。

 

 

为什么会有TIME_WAIT状态

确保有足够的时间让对方收到ACK包

避免新旧连接混淆。

为什么需要四次握手才能断开

因为全双工，发送方和接收方都需要FIN报文和ACK报文。即发送方和接收方都需要两次挥手。所以是4次

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

对方关闭socket连接，我方忙于读或写，没有及时关闭连接(没有发送ack).于是资源被直被程序占着

遇到这种情况多数是程序里有BUG,通常是某些连接没有及时释放

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

@检查配置，特别是处理请求的线程配置。如线程池中的线程数配置不合理。

 

netstat 查看网络状态，网络连接的指令（必会）

netstat -n ｜awk '/^tcp/{++S[$NF]}END{for(a in S) print a, S[a]}'  获取当前服务器处理各个状态下的连接数

重点关注CLOSE_WAIT ，如果很多比如几千，需要排查问题。 linux给每个用户分配有限的文件句柄数。连接与文件句柄一一对应。ClOSE_WAIT状态如果一直被保持意味着对应数目的通道一直被占用着.一旦达到上限则新的请求无法被处理。接着就是大量的too many open files异常。紧接着有可能造成软件的崩溃，即有可能造成tomcat或者apache的crash。