页面“Nginx反向代理获取用户真实ip”与“PHP的pm、pm.max requests、memory limit参数优化说明”之间的差异

来自linux中国网wiki
(页面间的差异)
跳到导航 跳到搜索
docker>Evan
(创建页面,内容为“==nginx中的几个变量== <pre> remote_addr 代表客户端的IP,但它的值不是由客户端提供的,而是服务端根据客户端的ip指定的,当你...”)
 
(导入1个版本)
 
第1行: 第1行:
==nginx中的几个变量==
+
=pm、pm.max_requests andmemory_limit=
<pre>
 
remote_addr
 
代表客户端的IP,但它的值不是由客户端提供的,而是服务端根据客户端的ip指定的,当你的浏览器访问某个网站时,假设中间没有任何代理,那么网站的web服务器(Nginx,Apache等)就会把remote_addr设为你的机器IP,如果你用了某个代理,那么你的浏览器会先访问这个代理,然后再由这个代理转发到网站,这样web服务器就会把remote_addr设为这台代理机器的IP,除非代理将你的IP附在请求header中一起转交给web服务器。
 
  
X-Forwarded-For(简称XFF)
+
==1、php-fpm.conf中的pm==
X-Forwarded-For 是一个 HTTP 扩展头部。HTTP/1.1(RFC 2616)协议并没有对它的定义,它最开始是由 Squid 这个缓存代理软件引入,用来表示 HTTP 请求端真实 IP。如今它已经成为事实上的标准,被各大 HTTP 代理、负载均衡等转发服务广泛使用,并被写入 RFC 7239(Forwarded HTTP Extension)标准之中。
+
pm是来控制php-fpm的工作进程数到底是一次性产生固定不变(static)还是在运行过程中随着需要动态变化(dynamic)。众所周知,工作进程数与服务器性能息息相关,太少则不能及时处理请求,太多则会占用内存过大而拖慢系统。因为php-fpm处理请求时会随着处理的请求数的增加而占用越来越多的内存,所以static模式下往往不好判断启动的能使内存利用最大化的固定进程数,所以想到了dynamic模式。可是为什么我们不用dynamic模式呢,试想某个时刻请求数比较低,20个进程足够应付,突然压力增大了,出现了40个并发PHP请求,按照最小5个空闲进程的设置就需要45个进程,也就是说需要在短时间内创建出25个进程,我们知道创建进程的操作是比较消耗系统资源的,再加上40个并发PHP请求肯定也会给MySQL带来一定的压力,此时再创建25个进程无疑是雪上加霜,所以我在这里还是选择了static模式。
 +
 +
==2、php-fpm.conf中的pm.max_requests==
 +
根据说明我们知道这个参数的含义是php-fpm工作进程处理完多少请求后自动重启,主要目的就是为了控制请求处理过程中的内存溢出,使得内存占用在一个可接受的范围内。从这里我们感觉这个数字似乎设置的小一点更加有利于性能提升,但是当这个数字非常小的时候会发生一种情况,由于PHP请求是平均地分配给各个工作进程的,如果这个值太小就会导致所有的工作进程几乎同时达到这个值并且进入需要重启的状态,当所有的工作进程都在同一时刻重启就会发生在数秒内甚至更长的时间PHP将停止响应直到所有的进程均重启完为止。这是不能接受的,所以我一般会把这个值设置为PHP启动后第一批工作进程达到此值需要重启时,第一个进程重启与最后一个进程重启之间的时间相差1分钟以上,一般在压力比较大的晚上这个差值将会扩大到5分钟左右,此时对进程重启对服务器的负面影响就可以忽略了。
 +
 +
==3、php.ini中的memory_limit==
 +
顾名思义,这个值是用来限制PHP所占用的内存的,具体一点说就是一个PHP工作进程即php-fpm所能够使用的最大内存,默认是128MB,一开始在虚拟机中我设置为PHP 5.1.6的默认值16MB,发现大于16MB的附件将无法下载,也就是说PHP 5.3中附件是从硬盘完整读取到PHP内存中再传给nginx的,这跟PHP 5.1.6+Apache 2.2.3不同,后者读取附件是PHP并不加载这个附件而是直接交给Apache来加载,这就使得php-fpm占用内存大了不少。当php-fpm占用内存达到了memory_limit所限制的值时,当前进程会被fpm主进程使用TERM信号终止掉,此时被处理的PHP请求将返回客户端502错误,nginx的error log中将记录出错原因是“Connection reset by peer”。可是更加令人难以理解的事情发生了,在使用了eAccelerator的PHP 5.3上,居然发生了当php-fpm内存达到memory_limit所限制的值时,所有进程都开始疯狂重启而不再接受任何请求,此时除非使用kill命令杀死主进程,否则php-fpm永远都不会恢复响应,可想而知nginx必然出现无止境的502错误了。。。
  
XFF的格式为:
+
总结 一般用static
  
X-Forwarded-For: client, proxy1, proxy2
 
XFF 的内容由「英文逗号 + 空格」隔开的多个部分组成,最开始的是离服务端最远的设备 IP,然后是每一级代理设备的 IP。(注意:如果未经严格处理,可以被伪造)
 
如果一个 HTTP 请求到达服务器之前,经过了三个代理 Proxy1、Proxy2、Proxy3,IP 分别为 IP1、IP2、IP3,用户真实 IP 为 IP0,那么按照 XFF 标准,服务端最终会收到以下信息:
 
X-Forwarded-For: IP0, IP1, IP2
 
Proxy3 直连服务器,它会给 XFF 追加 IP2,表示它是在帮 Proxy2 转发请求。列表中并没有 IP3,IP3 可以在服务端通过 Remote Address 字段获得。我们知道 HTTP 连接基于 TCP 连接,HTTP 协议中没有 IP 的概念,Remote Address 来自 TCP 连接,表示与服务端建立 TCP 连接的设备 IP,在这个例子里就是 IP3。Remote Address 无法伪造,因为建立 TCP 连接需要三次握手,如果伪造了源 IP,无法建立 TCP 连接,更不会有后面的 HTTP 请求。但是在正常情况下,web服务器获取Remote Address只会获取到上一级的IP,本例里则是proxy3 的 IP3,这里先埋个伏笔。
 
  
X-Real-IP
+
=SEE ALSO=
这又是一个自定义头部字段,通常被 HTTP 代理用来表示与它产生 TCP 连接的设备 IP,这个设备可能是其他代理,也可能是真正的请求端,这个要看经过代理的层级次数或是是否始终将真实IP一路传下来。(注意:如果未经严格处理,可以被伪造)
+
[http://www.cnblogs.com/adu0409/articles/3620748.html PHP的pm、pm.max_requests、memory_limit参数优化说明]
</pre>
+
[[category:php]]
 
 
 
 
 
 
 
 
==常用配置==
 
<pre>##这个我打包已加上了的 
 
proxy_set_header Host $host;
 
proxy_set_header X-Real-IP $remote_addr;
 
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 
</pre>
 
 
 
 
 
==参考==
 
nginx反向代理获取用户真实ip
 
http://www.nginx.cn/4646.html
 
 
 
NGINX多层转发或使用CDN之后如何获取用户真实IP
 
http://www.wkii.org/nginx-cdn-get-user-real-ip.html
 
 
 
获取用户真实 ip 地址的 nginx 相关配置
 
https://my.oschina.net/moooofly/blog/295853
 
 
 
HTTP 请求头中的 X-Forwarded-For
 
https://imququ.com/post/x-forwarded-for-header-in-http.html
 
 
 
CDN下nginx获取用户真实IP地址
 
https://www.ttlsa.com/nginx/nginx-get-user-real-ip/
 
 
 
 
 
 
 
[[category:nginx]]
 

2019年10月14日 (一) 13:52的最新版本

pm、pm.max_requests andmemory_limit

1、php-fpm.conf中的pm

pm是来控制php-fpm的工作进程数到底是一次性产生固定不变(static)还是在运行过程中随着需要动态变化(dynamic)。众所周知,工作进程数与服务器性能息息相关,太少则不能及时处理请求,太多则会占用内存过大而拖慢系统。因为php-fpm处理请求时会随着处理的请求数的增加而占用越来越多的内存,所以static模式下往往不好判断启动的能使内存利用最大化的固定进程数,所以想到了dynamic模式。可是为什么我们不用dynamic模式呢,试想某个时刻请求数比较低,20个进程足够应付,突然压力增大了,出现了40个并发PHP请求,按照最小5个空闲进程的设置就需要45个进程,也就是说需要在短时间内创建出25个进程,我们知道创建进程的操作是比较消耗系统资源的,再加上40个并发PHP请求肯定也会给MySQL带来一定的压力,此时再创建25个进程无疑是雪上加霜,所以我在这里还是选择了static模式。

2、php-fpm.conf中的pm.max_requests

根据说明我们知道这个参数的含义是php-fpm工作进程处理完多少请求后自动重启,主要目的就是为了控制请求处理过程中的内存溢出,使得内存占用在一个可接受的范围内。从这里我们感觉这个数字似乎设置的小一点更加有利于性能提升,但是当这个数字非常小的时候会发生一种情况,由于PHP请求是平均地分配给各个工作进程的,如果这个值太小就会导致所有的工作进程几乎同时达到这个值并且进入需要重启的状态,当所有的工作进程都在同一时刻重启就会发生在数秒内甚至更长的时间PHP将停止响应直到所有的进程均重启完为止。这是不能接受的,所以我一般会把这个值设置为PHP启动后第一批工作进程达到此值需要重启时,第一个进程重启与最后一个进程重启之间的时间相差1分钟以上,一般在压力比较大的晚上这个差值将会扩大到5分钟左右,此时对进程重启对服务器的负面影响就可以忽略了。

3、php.ini中的memory_limit

顾名思义,这个值是用来限制PHP所占用的内存的,具体一点说就是一个PHP工作进程即php-fpm所能够使用的最大内存,默认是128MB,一开始在虚拟机中我设置为PHP 5.1.6的默认值16MB,发现大于16MB的附件将无法下载,也就是说PHP 5.3中附件是从硬盘完整读取到PHP内存中再传给nginx的,这跟PHP 5.1.6+Apache 2.2.3不同,后者读取附件是PHP并不加载这个附件而是直接交给Apache来加载,这就使得php-fpm占用内存大了不少。当php-fpm占用内存达到了memory_limit所限制的值时,当前进程会被fpm主进程使用TERM信号终止掉,此时被处理的PHP请求将返回客户端502错误,nginx的error log中将记录出错原因是“Connection reset by peer”。可是更加令人难以理解的事情发生了,在使用了eAccelerator的PHP 5.3上,居然发生了当php-fpm内存达到memory_limit所限制的值时,所有进程都开始疯狂重启而不再接受任何请求,此时除非使用kill命令杀死主进程,否则php-fpm永远都不会恢复响应,可想而知nginx必然出现无止境的502错误了。。。

总结 一般用static


SEE ALSO

PHP的pm、pm.max_requests、memory_limit参数优化说明