最近部署服务器集群的时候查看了下原来单节点的配置，4核8G+8M带宽占用跟领导申请是否需要保持配置，领导让根据实际情况调整下尤其带宽占用部分，带宽占用太贵叻主要是

登录服务器之后，top下发现cpu、内存占用并不高，iftop -i eth0,之后发现带宽占用占用居然有5M检查在线人数发现，并没有太多这个流量有4M來自某个ip，登录嫌疑ip服务器检查端口占用情况:

发现存在大量TIME_WAIT状态的连接，统计下有3w多
常规情况下，通过调整内核参数解决

编辑文件加入以下内容：

可惜我们的内核已经调整成该配置，问题仍然存在

具体现象是对于一个处理大量短连接的服务器,如果是由服务器主动关閉客户端的连接,将导致服务器端存在大量的处于TIME_WAIT状态的socket, 甚至比处于Established状态下的socket多的多,严重影响服务器的处理能力,甚至耗尽可用的socket,停止服务. TIME_WAIT是TCP協议用以保证被重新分配的socket不会受到之前残留的延迟重发报文影响的机制,是必要的逻辑保证.

TCP结束的过程如下:

Time_Wait的默认时间是2倍的MLS，就是240秒钟MLS是TCP片在网上的最长存活时间。
TIME_Wait的主要作用是保证关闭的TCP端口不立即被使用因为当网络存在延迟时，可能当某个端口被关闭后网络中還有一些重传的TCP片在发向这个端口，如果这个端口立即建立新的TCP连接则可能会有影响。所以使用2倍的MSL时间来限制这个端口立即被使用

這说明有大量的短连接没来得及回收，又产生了新的连接

抓个包看看,1s抓了1M的数据。。分析包发现几乎都是3次握手，4次断开的真正囿用的数据不多。流量都是被这种无意义的包占满的找同事确认逻辑之后，他是一个业务就需要发送几十个消息所以才会占用如此多嘚带宽占用。

协商之后让同事将接口调用改成了长连接。消息改走mns消息队列带宽占用恢复正常。