记一次服务器事件

记一次服务器timewait事件

之前对TCP不太在意，直到这次企业的恶性事件，这才开始逐渐走向科研，学习TCP的相关专业知识。中间尝试了很多方法，也留下了很多死角，所以把这篇文章记录下来，方便以后再回头看。

先说网络结构

NGX和jetty都会有相同的网络服务器，Nginx代理HTTP的总流量被几个jetty使用，这是基本情况。

首先，在大家看来，怎么会有时间等待的状态呢？

当客户端主动关闭连接时，会推送最后一个ack，然后进入TIME_WAIT状态，再停留两个MSL小时进入关闭状态。

换句话说，一般情况下，timewait总是出现在客户端(由于主动关机)，服务器不容易关闭连接(认为是一直被监控)。

据此，我查询分析了网络服务器的状态。

发现nginx的opentcp连接状态一切正常，但问题出在jetty的线程数异常，没有发布。

第一个百度解决方案，基于基金会的结果是核心主要参数的一个改变(不强烈推荐)。

net.ipv4.tcp_tw_reuse=1

#表示重量已打开。允许等待时间套接字再次用于新的TCP连接，默认设置为0，这意味着它被关闭

net.ipv4.tcp_tw_recycle=1

#表示开启TCP连接中时间等待套接字的快速获取，默认设置为0，表示关闭。

可以快速获取插座，但是检查材料后发现存在安全隐患。

1.针对net.ipv4.tcp_tw_recycle，Linux核心文本文档中的实战演练和旁白。

TCP_tw_recycle(Boolean；默认:禁用；从Linux2.4开始)【解释者注:来自linuxmantcp的描述】

启用时间等待套接字的快速回收。不建议启用此选项，因为这会导致

使用NAT(网络地址转换)时出现的问题。

打开时间等待套接字的快速获取，不强烈推荐。在NAT(网络地址转换)互联网下，许多TCP连接会被错误地创建。

2.一些文字文档也有说在移动wifi上浏览会出现一些问题，因为wifi上的浏览时间格式会跳来跳去，导致浏览被拒绝。

根据以上两个安全隐患，不适用此方法。

我又查了一下，发现nginx和jetty的连接大部分都是短连接(因为nginx的默认设置也适用短连接)。所以有可能nginx作为客户端会很快释放，所以nginx的套接字总是来自timewait状态。所以去nginx官网查询资料，配备nginx在三层交换机的情况下应用长连接。

实际设备是:

上游本地主机{

……

keepalive30

}

位置/{

……

proxy_http_version1.1

proxy_set_header连接“”

}

在服务器的位置控制模块中添加上述信息内容。

注意:nginx代理需要的http协议版本信息必须设置为1.1，连接请求头必须去掉。

官方网络文本文档描述:

对于HTTP，proxy_http_version指令应该设置为“1.1”，并且应该清除“连接”头字段

由于http协议1.1的默认设置应用长连接，因此不使用连接的报头和顶部信息内容。nginx和jetty之间的长连接就这样打开后，timewait的状态就低了很多。

总结:我们遇到问题，百度搜索遇到的解决方法一定要具体分析，不能简单套用。因为别人的自然环境可能和你的不一样，即使当时的困难可以解决，后来造成的问题恐怕会更加难以察觉和处理。

最后，热烈欢迎大家一起交流学习培训。[/s2/]