正文
摘要
最近发现某项目的Nginx负载服务器上面有很多Time_wait的TCP连接
可以使用命令
netstat -n |awk '/^tcp/ {++S[$NF]} END{for (a in S) print a , S[a]}'
当时反馈过来 time_wait的连接特别多.
我比较菜, 没有进行过特别深入的研究.
本来今天准备学习研究systemtap的.
但是想能不能帮一下在乐不思蜀现场的栋哥就先看看这一块内容.
结论可能不准确, 需要有实际压测进行支撑.
关于长连接
keepalive
长连接其实有两种
第一种是TCP层的长连接, 第二种是http的长连接.
HTTP 的 Keep-Alive 也叫 HTTP 长连接，
该功能是由「应用程序」实现的，
可以使得用同一个 TCP 连接来发送和接收多个 HTTP 请求/应答，
减少了 HTTP 短连接带来的多次 TCP 连接建立和释放的开销。
TCP 的 Keepalive 也叫 TCP 保活机制，
该功能是由「内核」实现的，
当客户端和服务端长达一定时间没有进行数据交互时，
内核为了确保该连接是否还有效，就会发送探测报文，
来检测对方是否还在线，然后来决定是否要关闭该连接。
Study From ：https://blog.csdn.net/ThinPikachu/article/details/128177194
Http 长连接的配置
Http 1.1 之后自动开启了长连接, 会在http头上面增加一个配置节:
Connection: Keep-Alive
一般默认的超时时间是 60s 是需要应用层来进行维护.
一般可以采用 keepalive_timeout的参数进行修改.
注意虽然Http的长连接可以避免 建立连接时的资源损耗.
但是如果客户并发量特别高, 并且大部分人用完就不在处理了.
应用服务器保留很多长连接会导致多余的性能开销.
这一块时间还是需要有一定的业务含义, 不建议太过随意的处理.
Tcp长连接
如果两端的 TCP 连接一直没有数据交互，
达到了触发 TCP 保活机制的条件，那么内核里的 TCP 协议栈就会发送探测报文。
1. 如果对端程序是正常工作的。当 TCP 保活的探测报文发送给对端,
对端会正常响应，这样 TCP 保活时间会被重置，等待下一个 TCP 保活时间的到来。
2. 如果对端主机崩溃，或对端由于其他原因导致报文不可达。
当 TCP 保活的探测报文发送给对端后，石沉大海，没有响应，连续几次，
达到保活探测次数后，TCP 会报告该 TCP 连接已经死亡。
注意TCP的保活机制是内核来提供的.他也有一些缺点:
因为TCP协议中的SO_KEEPALIVE有几个致命的缺陷：
1. keepalive只能检测连接是否存活，不能检测连接是否可用。
比如服务器因为负载过高导致无法响应请求但是连接仍然存在，
此时keepalive无法判断连接是否可用
2. 如果TCP连接中的另一方因为停电突然断网，我们并不知道连接断开，
此时发送数据失败会进行重传，由于重传包的优先级要高于keepalive的数据包，
因此keepalive的数据包无法发送出去。只有在长时间的重传失败之后我们才能判断此连接断开了。
Study From ：https://www.zhihu.com/question/40602902/answer/209148428
注意长连接与Websocket的区别
websocket 实现的是 应用段端推送数据
长连接是websocket的实现基础.
但是websocket有更广阔的用途.
proxy_pass模块的长连接.
官方文档里面有对应的描述:
http://nginx.org/en/docs/http/ngx_http_upstream_module.html
可以在upstream 模块里面添加keepalive的数量.
需要注意的是这个数量仅是定义idle的进程数量,而不是max的数量.
所以基本上没有特别大的风险.
但是需要注意的是如果在upstream里面定义了 keepalive 需要在proxy_pass中增加定义配置.
第一个是 proxy_http_version 1.1 ; 第二个是 proxy_set_header Connection "" ;
因为proxy_pass 的默认 http version是1.0 需要增加配置节.
upstream http_backend {
server 127.0.0.1:8080;
keepalive 16;
}
server {
...
location /http/ {
proxy_pass http://http_backend;
proxy_http_version 1.1;
proxy_set_header Connection "";
...
}
}
Proxy_pass 对应的时间和超时时间
第一个是keepavlie的默认时间
默认是一个小时.
Syntax: keepalive_time time;
Default:
keepalive_time 1h;
Context: upstream
This directive appeared in version 1.19.10.
Limits the maximum time during which requests can be processed through one keepalive connection.
After this time is reached, the connection is closed following the subsequent request processing.
第二个是空闲的keepalive的默认超时时间.
默认是60秒, 我理解超过了 keepalive的数量时就利用他来进行关闭idle进程.
Syntax: keepalive_timeout timeout;
Default:
keepalive_timeout 60s;
Context: upstream
This directive appeared in version 1.15.3.
Sets a timeout during which an idle keepalive connection to an upstream server will stay open.
Nginx的其他超时时间设置
http 下面的
#每个 TCP 连接最多可以保持多长时间
keepalive_timeout 60;
#客户端向服务端发送一个完整的 request header
client_header_timeout 10;
#客户端发送服务端发送一个完整的 request bod
client_body_timeout 20;
#服务端向客户端传输数据的超时时间。
send_timeout 30;
location下面的
proxy_connect_timeout 4;
# 没有接收数据关闭 等候后端服务器响应时间 这个可以响应的时间
proxy_read_timeout 4; # 秒
# 没有发送数据关闭 后端服务器数据回传时间
proxy_send_timeout 60;
Study From: https://www.cnblogs.com/sunxun/p/15476377.html
