Nginx优化指南

简介:

未优化前服务器的状态
[root@ngx32 ~ "o">] "c"># netstat -na |awk '{print $6}'| sort |uniq -c |sort -nr
    490 ESTABLISHED
     44 SYN_RECV
     34 LAST_ACK
     10 CONNECTED
      5 LISTEN
      3 CLOSE_WAIT
      2
      1 established)
      1 and
      1 I-Node
      1 Foreign
      1 7894382
      1 6343
      1 6250
      1 6241
      1 3937508
      1 2837682
      1 1863

理论图

放一张图,要搞清楚怎么调整参数,这张图相当重要。看不太明白不要紧,后面会详细讲到这张图

14333130J-0.jpg

优化经验值

转一个金山张宴的贴子对/etc/sysctrl.conf的优化参数,后面会仔细介绍参数。


# Add
net.ipv4.tcp_max_syn_backlog = 65536
net.core.netdev_max_backlog =  32768
net.core.somaxconn = 32768

net.core.wmem_default = 8388608
net.core.rmem_default = 8388608
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 2

net.ipv4.tcp_tw_recycle = 1
#net.ipv4.tcp_tw_len = 1
net.ipv4.tcp_tw_reuse = 1

net.ipv4.tcp_mem  "o">= 94500000 915000000 927000000
net.ipv4.tcp_max_orphans = 3276800

#net.ipv4.tcp_fin_timeout = 30
#net.ipv4.tcp_keepalive_time = 120
net.ipv4.ip_local_port_range = 1024  65535

TCP三次握手以及其中的各种状态:

SYN(Synchronize Sequence Numbers)。

同步序列编号

ACK (ACKnowledge Character)

在数据通信传输中,接收站发给发送站的一种传输控制字符。它表示确认发来的数据已经接受无误。


=================================

client发送syn至server

此时客户端的状态变为SYN_SENT

client( "nv">syn=j "o">)====>server

server收到syn,并发送syn+ack到client,

这种过程server状态由listen变为SYN_RECV,并等待客户端再次发来ack数据

client<=========server "o">(syn "o">=k,ack=j+1 "o">)

client接收到server发过来的syn+ack,并向服务端发送ACK,服务器接收后由SYN_RECV变为ESTABLISHED

client(ACK "o">(ack "o">=k+1))========>server

此种情况下,服务端在三次握手的变迁是

LISTEN->SYN_RECV ->ESTABLISHED

客户端的三次握手的变迁是

SYN_SENT ->ESTABLISHED

====================================

注意问题

一、首先server有个用来接收client发送的syn并对syn进行排队的队列,如果队列满了,新的请求不被接受。

此队列长度控制参数:

net.ipv4.tcp_max_syn_backlog

对应文件(/proc/sys/net/ipv4/tcp_max_syn_backlog ) 默认是1024


1   [root@web "o">] "c"># cat /proc/sys/net/ipv4/tcp_max_syn_backlog
2   1024

二、然后是SYN-ACK重传:当server向client发送syn+ack没有收到相应,server将重传,然后再重传。。。控制这个重传次数的参数是


tcp_synack_retries



对应文件(/proc/sys/net/ipv4/tcp_synack_retries )默认值是5,对应于180秒左右时间


1   [root@web ~ "o">] "c"># cat /proc/sys/net/ipv4/tcp_synack_retries
2   5

关于tcp_synack_retries的英文解释:
The maximum number of times a SYN/ACK segment for a passive TCP connection will be retransmitted. This number should not be higher than 255. The default value is 5.

备注:与此相对应的client的参数是:
tcp_syn_retries
The maximum number of times initial SYNs for an active TCP connection attempt will be retransmitted. This value should not be higher than 255. The default value is 5, which corresponds to approximately 180 seconds.

三、关于tcp_syncookies

SYN Cookie是对TCP服务器端的三次握手协议作一些修改,专门用来防范SYN Flood攻击的一种手段。它的原理是,在TCP服务器收到TCP SYN包并返回TCP SYN+ACK包时,不分配一个专门的数据区,而是根据这个SYN包计算出一个cookie值。在收到TCP ACK包时,TCP服务器在根据那个cookie值检查这个TCP ACK包的合法性。如果合法,再分配专门的数据区进行处理未来的TCP连接。


1   [root@web~ "o">] "c"># cat /proc/sys/net/ipv4/tcp_syncookies
2   1

典型syn_recv故障处理

如果服务器syn_recv的条数过多,可以采取的操作是:

减少server==>client重传syn+ack的次数。

加大syn队列长度,防止无法响应新的连接


1   echo  "s2">"net.ipv4.tcp_max_syn_backlog = 4096" >>/etc/sysctl.conf
2   echo  "s2">"net.ipv4.tcp_synack_retries = 1" >>/etc/sysctl.conf
3   sysctl -p

当受到syn攻击的时候,启用syn-cookie(默认启用,在/etc/sysctl.conf里本身就有参数配置)


1    "nb">echo 1 >/proc/sys/net/ipv4/tcp_syncookies

TCP四次握手

下面说tcp/ip的第四次握手,分析主动关闭和被动关闭两种。

A:因为如果是CLIENT端主动断掉当前连接,那么双方关闭这个TCP连接共需要四个packet:


setup
Client     --->   FIN(M)   --->   Server

client发送一个FIN给server,(说它不跟你玩了),client由ESTABLISHED->FIN_WAIT1

Client    <---  ACK(M+1 "o">)  <---   Server

SER VER收到fin后发送ack确认(拿出两人信物),状态由ESTABLISHED->close_wait


client收到server的ack确认,只是改变状态ESTABLISHED->FIN_WAIT1->FIN_WAIT2,继续等server发送数据。

Client  <--  FIN(N "o">)    <--  Server

server继续发送FIN到client(好就不玩了吧),状态ESTABLISHED->close_wait->LAST_ACK,等待client发送ack做最后的确认

Client  -->  ACK(N+1 "o">)  -->  Server

client收到FIN,马上发送ack确认,状态ESTABLISHED->FIN_WAIT1->FIN_WAIT2->TIME_WAIT[2MSL超时]->closed

server收到ack确认,状态ESTABLISHED->close_wait->LAST_ACK->CLOSED.

keepalive_timeout

client关闭连接很好想,有点要搞清楚的是,server端什么时候会发起丢掉连接的操作:

有些是应用程序控制的。nginx.conf为例


keepalive_timeout  0;
[root@lvs-2 ~ "o">]# curl -I http://www.XXX.com
Connection: close


keepalive_timeout  600;
[root@lvs-2 ~ "o">]# curl -I http://www.XXX.com
Connection: keep-alive

这种规定了连接时间的,到了时间连接会断掉。

如果没有规定的,则按照系统keepalived定时器的设置进行,具体参数如下:


[root@ngx32 ~ "o">]# sysctl -a|grep tcp_keepalive
net.ipv4.tcp_keepalive_intvl = 75
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_keepalive_time = 30

连接两端一直没发送数据,间隔半分钟,后开始第一次探测,间隔75秒后第二次探测,探测9次,最后放弃连接。

四种状况其实最后一种没什么意义,能考虑到下面三种就行了


1 client正常,每进行一次通讯,net.ipv4.tcp_keepalive_time重置一次。


2 一直到7200+75*9后也无法获取client反馈信息,则认为client已经关闭并终止连接(连接超时)


3 client重启, 收到探测后返回一个复位(RST)信息。server收到后终止连接(连接被对方复位)



典型timewait故障处理

一、网站服务器访问速度变慢,查看网站服务器连接,看到连接至数据库的连接中出现大量time_wait,多达400个。分析是网站服务器定时任务做大量读取数据库操作的时候产生的。
此情况出现在client.

根据上面讲的,time_wait对应2MSL超时,什么是2MSL?,是在client在四次握手的时候最后发送了ack确认给服务器后必然经过的一个时间。TIME_WAIT状态的目的是为了防止最后client发出的ack丢失,让server处于LAST_ACK超时重发FIN。配置2MSL时间长短的服务器参数,但这里不是优化的重要参数,我们需要的是Time_wait的连接可以重用,并且能迅速关闭。

2MSl的解释:


    MSL是Maximum Segment Lifetime英文的缩写,中文可以译为“报文最大生存时间”,他是任何报文在网络上存在的最长时间,超过这个时间报文将被丢弃。因为tcp报文(segment)是ip数据报(datagram)的数据部分,具体称谓请参见《数据在网络各层中的称呼》一文,而ip头中有一个TTL域,TTL是time to live的缩写,中文可以译为“生存时间”,这个生存时间是由源主机设置初始值但不是存的具体时间,而是存储了一个ip数据报可以经过的最大路由数,每经过一个处理他的路由器此值就减1,当此值为0则数据报将被丢弃,同时发送ICMP报文通知源主机。RFC 793中规定MSL为2分钟,实际应用中常用的是30秒,1分钟和2分钟等。
5
6       2MSL即两倍的MSL,TCP的TIME_WAIT状态也称为2MSL等待状态,当TCP的一端发起主动关闭,在发出最后一个ACK包后,即第3次握手完成后发送了第四次握手的ACK包后就进入了TIME_WAIT状态,必须在此状态上停留两倍的MSL时间,等待2MSL时间主要目的是怕最后一个ACK包对方没收到,那么对方在超时后将重发第三次握手的FIN包,主动关闭端接到重发的FIN包后可以再发一个ACK应答包。在TIME_WAIT状态时两端的端口不能使用,要等到2MSL时间结束才可继续使用。当连接处于2MSL等待阶段时任何迟到的报文段都将被丢弃。不过在实际应用中可以通过设置SO_REUSEADDR选项达到不必等待2MSL时间结束再使用此端口。
7
8       TTL与MSL是有关系的但不是简单的相等的关系,MSL要大于等于TTL。
1   [root@bjweba ~ "o">] "c"># sysctl -a | grep time | grep wait
2   net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 120
3   net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 60
4   net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 120

关于 ip_ct_tcp_timeout_time_wait


1   3.7.15. ip_ct_tcp_timeout_time_wait
2
3   The ip_ct_tcp_timeout_time_wait variable defines the timeout value of the TIME-WAIT state as defined by RFC 793. This is the final state possible in a TCP connection. When a connection is closed in both directions, the server and client enters the TIME-WAIT state, which is used so that all stale packets have time to enter the client or server. One example of the usage of this may be if packets are reordered during transit between the hosts and winds up in a different order at either side. In such a case, the timewindow defined in the ip_ct_tcp_timeout_time_wait variable is used so that those packets may reach their destinations anyways. When the timeout expires, the conntrack entry is destroyed and we enter the state CLOSED, which means that there is no conntrack data at all for the connection in question.
4
5   The default value of the ip_ct_tcp_timeout_time_wait variable is set to 120 seconds, or 2 minutes. You should generally want to keep this value if you know that you live on a connection that is slow and that often reorders the packets in question. If this value is too low you will often experience corrupt downloads or missing data in downloaded data, you should definitely avoid tuning this value down in such a case, and you may most definitely consider raising the timeout of this value in such case. If you never experience such behaviour or any other problems like that, you may most probably lower this value so that conntrack entries die faster, and hence recycle the conntrack entry space faster.
6   3.7.15.3.7.15. ip_ct_tcp_timeout_time_wait

如何解决?

控制重用和迅速回收的参数是net.ipv4.tcp_tw_reuse和net.ipv4.tcp_tw_recycle。

这两个参数的具体英文解释和作用等我查到了再补充,网上讲的也不怎么清楚。

net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接,默认为0

net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收,默认为0。


1   echo  "s2">"net.ipv4.tcp_tw_reuse = 1" >>/etc/sysctl.conf
2   echo  "s2">"net.ipv4.tcp_tw_recycle = 1" >>/etc/sysctl.conf
3   sysctl -p

出现FIN_WAIT_2状态

现象描述

服务器端运行服务9090的c,或java程序用killall -9 服务名 kill掉后,出现

FIN_WAIT_2状态,新的服务无法启动。因为这个状态占据了服务端口。时间默认1分钟。


1   [root@web ~ "o">] "c"># sysctl -a | grep time | grep fin
2   net.ipv4.tcp_fin_timeout = 60

主要就是服务端主动发起关闭,此时服务端相当于一个client,在最后等对方发送最后一个FIN的却一直等不到,直至超时,控制这个超时的时间参数是tcp_fin_timeout

tcp_fin_timeout(0S)


How many seconds to wait  "k">for a final FIN packet before the socket is forcibly closed. This is strictly a violation of the TCP specification, but required to prevent denial-of-service (DoS) attacks. The default value in 2.4 kernels is 60, down from 180 in 2.2.

备注:TCP_LINGER2(tcp socket编程选项 "o">)
The lifetime of orphaned FIN_WAIT2 state sockets. This option can be used to override the system wide sysctl tcp_fin_timeout on this socket. This is not to be confused with the socket (7) level option SO_LINGER. This option should not be used in code intended to be portable.


1   echo  "s2">"net.ipv4.tcp_fin_timeout = 30"  >>/etc/sysctl.conf
2   sysctl -p
3    "c">#echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout 

此外,还有控制tcp发送缓冲区,接收缓冲区大小的设置,能够使用端口范围的设置。


1   [root@web~ "o">] "c"># cat /proc/sys/net/ipv4/ip_local_port_range
2   32768   61000

这个是本地连接外地端口时开的动态端口,个人觉得默认就够了。如果有很频繁的要连接外面端口,可以设大。


1    "c">#echo "5000 65535" > /proc/sys/net/ipv4/ip_local_port_range
2   echo  "s2">"net.ipv4.ip_local_port_range = 5000    65000" >> /etc/sysctl.conf
3   sysctl -p

总结经验值
net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.ip_local_port_range = 5000    65000






     本文转自yzy121403725 51CTO博客,原文链接:http://blog.51cto.com/lookingdream/1836088 ,如需转载请自行联系原作者




相关实践学习
容器服务Serverless版ACK Serverless 快速入门:在线魔方应用部署和监控
通过本实验,您将了解到容器服务Serverless版ACK Serverless 的基本产品能力,即可以实现快速部署一个在线魔方应用,并借助阿里云容器服务成熟的产品生态,实现在线应用的企业级监控,提升应用稳定性。
云原生实践公开课
课程大纲 开篇:如何学习并实践云原生技术 基础篇: 5 步上手 Kubernetes 进阶篇:生产环境下的 K8s 实践 相关的阿里云产品:容器服务&nbsp;ACK 容器服务&nbsp;Kubernetes&nbsp;版(简称&nbsp;ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情:&nbsp;https://www.aliyun.com/product/kubernetes
相关文章
|
6月前
|
应用服务中间件 nginx
nginx优化:URI过长或request header过大导致400或414报错
当出现URI过长或请求头过大导致400或414报错时,可以通过以下方式对Nginx进行优化: 1. 调整client_max_body_size参数:该参数用于限制请求体的大小。默认情况下,Nginx的client_max_body_size参数设置为1M。如果请求体超过这个大小,Nginx会返回400错误。您可以根据实际需求适当增加这个值,例如设置为10M或更大。 ``` http { client_max_body_size 10M; } ``` 2. 调整large_client_header_buffers参数:该参数用于调整请求头缓冲区的大
867 0
|
6月前
|
应用服务中间件 Linux PHP
|
7月前
|
缓存 安全 应用服务中间件
百度搜索:蓝易云【Nginx的搭建和优化详细教程。】
通过以上步骤,你已经成功搭建和优化了Nginx服务器。你可以根据自己的需求进行进一步的配置和调整,以满足你的网站的性能和安全需求。
262 3
|
1天前
|
缓存 负载均衡 安全
深入探索Nginx高性能Web服务器配置与优化
【5月更文挑战第7天】本文深入探讨了Nginx的配置与优化,重点介绍了基础配置参数如`worker_processes`、`worker_connections`和`keepalive_timeout`,以及优化策略,包括使用epoll事件驱动模型、开启gzip压缩、启用缓存、负载均衡和安全配置。此外,还提到了性能调优工具,如ab、nginx-stats和nmon,以助于提升Nginx的性能和稳定性。
|
15天前
|
安全 应用服务中间件 Linux
高并发下Nginx优化(一)
【4月更文挑战第15天】高并发下Nginx优化
18 0
|
15天前
|
运维 Java 应用服务中间件
Nginx+Tomcat动静分离及Nginx优化(企业案例)
Nginx+Tomcat动静分离及Nginx优化(企业案例)
|
29天前
|
前端开发 应用服务中间件 nginx
使用nginx-http-concat资源请求合并功能 优化网站响应
使用nginx-http-concat资源请求合并功能 优化网站响应
12 0
|
3月前
|
JavaScript 前端开发 应用服务中间件
vue项目加载慢,Nginx页面优化
vue项目加载慢,Nginx页面优化
55 0
|
5月前
|
数据可视化 应用服务中间件 Linux
Nginx 可视化管理工具与 cpolar 配置:实现远程访问本地服务的优化
Nginx 可视化管理工具与 cpolar 配置:实现远程访问本地服务的优化
Nginx 可视化管理工具与 cpolar 配置:实现远程访问本地服务的优化
|
5月前
|
缓存 负载均衡 算法
百度搜索:蓝易云【如何优化Nginx服务进程详细。
优化Nginx服务进程是一个持续的过程,需要不断地监测和调整。建议在优化之前备份配置文件,并逐步应用和测试每个优化步骤的效果,以确保服务的稳定性和可靠性。
27 0