502 VS 504

r囧r小猫 2021-09-20 09:00 220阅读 0赞

本文同时发表在[https://github.com/zhangyachen/zhangyachen.github.io/issues/89][https_github.com_zhangyachen_zhangyachen.github.io_issues_89]

首先看一下概念：

*  502：作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。
 *  504：作为网关或者代理工作的服务器尝试执行请求时，未能及时从上游服务器（URI标识出的服务器，例如HTTP、FTP、LDAP）或者辅助服务器（例如DNS）收到响应。　　注意：某些代理服务器在DNS查询超时时会返回400或者500错误。

通俗的来说，nginx作为一个代理服务器，将请求转发到其他服务器或者php-cgi来处理，当nginx收到了无法理解的响应时，就返回502。当nginx超过自己配置的超时时间还没有收到请求时，就返回504错误。

### 502 ###

上面说到nginx收到了无法理解的响应，什么是无法理解的响应呢？

*  nginx无法与php-fpm进行连接。
 *  nginx在连接php-fpm一段时间后发现与php-fpm的连接被断开。

那么什么时候会出现上面的情况呢？

*  php-fpm没有启动,nginx无法将请求交给php-fpm
 *  php-fpm运行脚本超时，php-fpm终止了脚本的执行和执行脚本的Worker进程，nginx发现自己与php-fpm的连接断开。

我们逐一实验上述的情况：

##### php-fpm没有启动 #####

我们关闭php-fpm。

[root@localhost ~]# service php-fpm stop
    Stopping php-fpm:                                          [  OK  ]

刷新页面，发现返回502错误：  
![screenshot][]

nginx的error\_log：

2016/11/06 11:03:01 [error] 3860#0: *37 connect() failed (111: Connection refused) while connecting to upstream, client: 127.0.0.1, server: _, request: "GET /www/muke/index.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "127.0.0.1"

##### php-fpm请求超时 #####

我们首先将php-fpm.conf中的`max_terminate_request`改成5s：

request_terminate_timeout = 5

在php脚本中添加如下语句：

sleep(20);

刷新页面，发现返回502错误：  
![screenshot][screenshot 1]

查看php-fpm的error\_log，有如下日志：

[06-Nov-2016 12:26:07] WARNING: [pool www] child 6669, script '/usr/share/nginx/html/www/muke/index.php' (request: "GET /www/muke/index.php") execution timed out (5.482902 sec), terminating
    [06-Nov-2016 12:26:07] WARNING: [pool www] child 6669 exited on signal 15 (SIGTERM) after 647.401329 seconds from start
    [06-Nov-2016 12:26:07] NOTICE: [pool www] child 6774 started

查看nginx的error\_log，有如下日志：

2016/11/06 12:26:07 [error] 6228#0: *46 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 127.0.0.1, server: _, request: "GET /www/muke/index.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "127.0.0.1"

##### php-fpm max\_children #####

另外，关于网上说的适当增加max\_children参数可能会解决502的问题，我没有实验出来，但是说一下我的实验过程：

关于502与max\_children之间的关系，有这样的说法：

> max\_children最大子进程数，在高并发请求下，达到php-fpm最大响应数，后续的请求就会出现502错误的。

首先我很怀疑这样的说法，因为假设php-fpm的max\_children设置为10，即有10个worker子进程。那么假设此时同时有10个并发请求都在占用worker进程进行处理，那么这时第11个请求到来时，就直接拒绝这个请求，连一个等待队列都没有吗？

为了证实我的想法，首先修改max\_children的选项如下：

pm.max_children = 1

具体修改过程conf里有详细的说明，pm的值在这里需要为static。

重启php-fpm，查看worker子进程的数量：

[root@localhost ~]# ps aux | grep php-fpm
    root       7596  0.0  0.1 245812  3808 ?        Ss   14:10   0:00 php-fpm: master process (/etc/php-fpm.conf)
    apache     7597  0.0  0.3 245844  6120 ?        S    14:10   0:00 php-fpm: pool www

确实变为了一个。

为了增加实验效果，在php文件中增加：

sleep(20);

此时同时打开三个页面，同时发3个请求。如果按照上面的说法，只有一个请求被worker进程处理，其余2个请求因为没有多余的worker处理而被拒绝，返回502。但是实验的结果并不是如此，三个页面最终都返回了http code 200。说明是有一个等待队列存在的。那么这个等待队列是什么呢？

在网上搜寻了一段时间，发现有如下的想法：

> 当backlog队列满了，会出现502错误

什么是backlog队列呢？  
首先我们使用[ss命令][ss]，观察当前活跃的套接字：

[root@localhost ~]# ss -ln
    State       Recv-Q Send-Q                                              Local Address:Port                                                Peer Address:Port 
    LISTEN      0      128                                                     127.0.0.1:6942                                                           *:*     
    LISTEN      0      128                                                             *:56517                                                          *:*     
    LISTEN      0      128                                                     127.0.0.1:9000                                                           *:*     
    LISTEN      0      50                                                              *:3306                                                           *:*     
    LISTEN      0      128                                                     127.0.0.1:63342                                                          *:*     
    LISTEN      0      128                                                            :::111                                                           :::*     
    LISTEN      0      128                                                             *:111                                                            *:*     
    LISTEN      0      128                                                             *:80                                                             *:*     
    LISTEN      0      128                                                            :::60816                                                         :::*     
    LISTEN      0      128                                                            :::22                                                            :::*     
    LISTEN      0      128                                                             *:22                                                             *:*     
    LISTEN      0      128                                                     127.0.0.1:631                                                            *:*     
    LISTEN      0      128                                                           ::1:631                                                           :::*     
    LISTEN      0      100                                                           ::1:25                                                            :::*     
    LISTEN      0      100                                                     127.0.0.1:25                                                             *:*

我们观察`127.0.0.1:9000`这一行：

LISTEN      0      128                                                     127.0.0.1:9000                                                           *:*

关注`Recv-Q`和`Send-Q`这两个字段。啥意思呢？我也不懂。参考[TCP queue 的一些问题][TCP queue]的说法：

*  LISTEN 状态: Recv-Q 表示的当前等待服务端调用 accept 完成三次握手的 listen backlog 数值，也就是说，当客户端通过 connect() 去连接正在 listen() 的服务端时，这些连接会一直处于这个 queue 里面直到被服务端 accept()；Send-Q 表示的则是最大的 listen backlog 数值，这就就是上面提到的 min(backlog, somaxconn) 的值。
 *  其余状态: 非 LISTEN 状态之前理解的没有问题。Recv-Q 表示 receive queue 中的 bytes 数量；Send-Q 表示 send queue 中的 bytes 数值。

其余的细节查看刚才贴出的参考链接。

于是，将php-fpm的conf中的`listen.backlog`修改为1：

; Set listen(2) backlog. A value of '-1' means unlimited.
    ; Default Value: -1
    listen.backlog = 1

重启php-fpm，查看修改结果：

[root@localhost ~]# ss -ln | grep 9000
    LISTEN     0      1                 127.0.0.1:9000                     *:*

修改成功。php-fpm目前的backlog为1，即php-fpm的等待队列里只能有一个请求在等待worker进程进行处理。

同时发三个请求，查看结果：  
结果为：三个请求又最终成功返回http code 200。与我猜想的不符和啊，不是backlog为1吗？  
最后发现下面一段话：

> 当 queue 满了之后，服务器并不会按照理论所述，不再对 SYN 进行应答，返回 ETIMEDOUT。根据这篇文档的描述，实际情况并非如此，服务器会随机的忽略收到的 SYN，建立起来的连接数可以无限的增加，只不过客户端会遇到延时以及超时的情况。

再实验一次，同时运行`ss -ln`：

[root@localhost ~]# ss -ln | grep 9000
    LISTEN     2      1                 127.0.0.1:9000                     *:*

过一段时间后：

[root@localhost ~]# ss -ln | grep 9000
    LISTEN     1      1                 127.0.0.1:9000                     *:*

发现Recv-Q字段的值为2，过一段时间变为1，说明php-fpm并没有拒绝后两次请求。

**看看nginx的backlog配置，不能光看php-fpm的**

那么最终的结论是：适当增加max\_children还是有用的，这样的话php-fpm能同时处理的请求增加，客户端的延迟等待时间也会相应的减小。

##### fastcgi\_buffer系列 #####

还有种说法是当nginx的fastcgi的buffer设置过小时，也会有502。

fastcgi_buffer_size 1k;
    fastcgi_buffers 2 1k;
    fastcgi_busy_buffers_size 1k;

这个自己也没有实验出来，自己理解的是如果buffer开启过小的话，work进程需要将response body中在buffer放不下的部分放到磁盘上，降低了效率，work进程的响应时间会变慢，效率降低。假如此时有高并发的请求，可能会出现502错误。

### 504 ###

504即nginx超过了自己设置的超时时间，不等待php-fpm的返回结果，直接给客户端返回504错误。但是此时php-fpm依然还在处理请求（在没有超出自己的超时时间的情况下）。

这里有三个相关的配置：

*  fastcgi\_connect\_timeout 300;  
    指定连接到后端FastCGI的超时时间。
 *  fastcgi\_send\_timeout 300;  
    nginx进程向fastcgi进程发送request的整个过程的超时时间
 *  fastcgi\_read\_timeout 300;  
    fastcgi进程向nginx进程发送response的整个过程的超时时间

这里我们将`fastcgi_read_timeout`设置为1s，后端还是延迟20s，观测效果：  
![screenshot][screenshot 2]

nginx返回504错误。

参考资料：http://jaseywang.me/2014/07/20/tcp-queue-%E7%9A%84%E4%B8%80%E4%BA%9B%E9%97%AE%E9%A2%98/

转载于:https://www.cnblogs.com/zhangyachen/p/8030289.html

[https_github.com_zhangyachen_zhangyachen.github.io_issues_89]: https://github.com/zhangyachen/zhangyachen.github.io/issues/89
[screenshot]: /images/20210726/d5fddccfdfaf4ac783a25cec031c2482.png
[screenshot 1]: /images/20210726/140f645bb582493c98235ee4001686d2.png
[ss]: http://man.linuxde.net/ss
[TCP queue]: http://jaseywang.me/2014/07/20/tcp-queue-%E7%9A%84%E4%B8%80%E4%BA%9B%E9%97%AE%E9%A2%98/
[screenshot 2]: /images/20210726/1136740986ba48caa59feb6804e45c6d.png