国外网站平台,海珠区pc端网站建设,wordpress 整体搬家,如何创建商业网站文章目录 一、统计各类状态的tcp连接数量二、TIME_WAIT应用服务器上#xff0c;来自反向代理的连接反向代理上#xff0c;访问应用服务的连接反向代理上#xff0c;来自用户的连接 三、SYN_SENT反向代理上#xff0c;访问位于防火墙另一侧的目标反向代理上#xff0c;访问… 文章目录 一、统计各类状态的tcp连接数量二、TIME_WAIT应用服务器上来自反向代理的连接反向代理上访问应用服务的连接反向代理上来自用户的连接 三、SYN_SENT反向代理上访问位于防火墙另一侧的目标反向代理上访问无防火墙阻断的目标 四、CLOSE_WAIT应用服务器上来自反向代理的连接 本文记录在nginx、tomcat服务器上一些处理异常TCP连接的方案 一、统计各类状态的tcp连接数量
ss、netstat两个工具都能统计
ss -ant | awk {print $1} | sort | uniq -cnetstat -ant | awk /^tcp/ {S[$NF]} END {for(a in S) print a, S[a]}二、TIME_WAIT
应用服务器上来自反向代理的连接
原因从nginx发起的请求申明的是http 1.0版本的协议或者请求头的Connection字段指是Close则tomcat响应完请求后会主动断开tcp连接
方案nginx http_proxy模块的proxy_http_version配置默认使用http 1.0协议访问upstream实例需要修改为1.1
proxy_connect_timeout 3s;
proxy_http_version 1.1;
# 通知客户端连接保持60s服务端实际在75s后才会主动关闭连接
# 如果不设置第二个参数来返回空闲长连接的超时建议有的客户端不会利用http连接池来长期保持空闲连接
keepalive_timeout 75s 60s;
# 要与请求端保持http1.1通讯就不能关闭chunked机制
# 否则nginx会在完成响应后主动关闭与请求端的tcp连接相当于退化为http1.0协议
chunked_transfer_encoding on;upstream myapp {# nginx与upstream服务器之间的空闲长连接数量(默认最多保持60s)keepalive 20;server 10.0.0.1:8080;server 10.0.0.2:8080;
}server {listen 80 default;location / {proxy_pass http://myapp;# 请求头指定HTTP 1.1协议并且Connection不为Close时# 对方完成响应后才不会主动断开TCP连接proxy_http_version 1.1;proxy_set_header Connection ;proxy_set_header Cookie $http_cookie;proxy_set_header Host $host;proxy_set_header X-Forwarded-For ${proxy_add_x_forwarded_for};}
}反向代理上访问应用服务的连接
原因nginx使用http 1.1协议访问upstream实例后如果未开启空闲连接复用机制就会主动关闭tcp连接
方案nginx upstream模块的keepalive配置默认未开启需要主动提供一个数值
反向代理上来自用户的连接
原因1在请求端浏览器、http请求框架默认开启连接池并使用http 1.1协议的情况下如果nginx关闭了http 1.1协议的chunked_transfer_encoding机制那么在完成请求后nginx会主动断开与请求端的连接
方案不要关闭chunked_transfer_encoding
原因2未返回建议客户端保持连接的时长response header里的Keep-Alive: timeouttime导致用户的客户端迟迟不断开空闲连接最终由nginx来主动断开连接把TIME_WAIT留在了nginx服务器上
方案keepalive_timeout配置最长空闲时间和建议客户端保持连接的时长让客户端知道应该在什么时间之前关闭空闲连接
三、SYN_SENT
反向代理上访问位于防火墙另一侧的目标
原因telnet目标端口时命令阻塞未立即得到目标未开通此端口的响应证明SYN包被防火墙drop了
方案申请防火墙策略
反向代理上访问无防火墙阻断的目标
原因1目标tomcat服务器已接收springboot应用的server.tomcat.max-connections配置默认10000的http连接数量、在服务端口排队等待accept操作系统的net.core.somaxconn配置默认128或1024的tcp socket数量都达到上限后后续到达服务端口的SYN包会被丢弃请求端的连接状态保持为SYN_SENT
方案在使用webflux、websocket等响应式IO框架时可调大server.tomcat.max-connections配置
原因2telnet目标端口时命令阻塞未立即得到目标未开通此端口的响应证明目标服务器上使用iptables对访问服务端口的请求进行了DROP处理
方案使用iptables规则把请求方IP加入放行名单
原因3应用服务的进程已处理的文件句柄包含tcp socket数量超过限额
# 查看当前用户下单进程的文件句柄限额
ulimit -n方案编辑/etc/security/limits.conf文件重启应用服务进程
四、CLOSE_WAIT
应用服务器上来自反向代理的连接
原因应用程序开了端口但是后续初始化失败比如没有成功连接配置中心、服务注册中心、数据库等原因accept socket的逻辑没运行起来 已建立的请求放在服务端口待accept的backlog操作系统的net.core.somaxconn配置里收到的请求内容放在操作系统tcp buffer里 迟迟得不到应用程序处理并响应后客户端发出FIN指令服务端响应ACK后服务端连接进入CLOSE_WAIT状态由于tcp buffer里的数据没有被处理所以服务端没有继续回复FIN连接以CLOSE_WAIT状态滞留在服务端口待accept的backlog里 在backlog塞满之前应用服务端口实际处于可以连接但是不能响应的假死状态
方案对部署的应用进行readyness定时探测及时发现未成功初始化的应用
