加入收藏 | 设为首页 | 会员中心 | 我要投稿 湖南网 (https://www.hunanwang.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 业界 > 正文

署理处事器和Web处事器通讯中的504题目

发布时间:2018-12-08 02:43:32 所属栏目:业界 来源:虞大胆的叽叽喳喳
导读:对付一个Web开拓者来说,504和502题目看上去仿佛很简朴,每小我私人也也许都碰着过,但把题目说清晰并不那么轻易,也但愿这两篇文章可以或许辅佐您。 两台装备只要通过proxy或fastcgi协议相互通讯,城市碰着504题目,好比Nginx+PHP-FPM会碰着;署理处事器毗连后端We
副问题[/!--empirenews.page--]

对付一个Web开拓者来说,504和502题目看上去仿佛很简朴,每小我私人也也许都碰着过,但把题目说清晰并不那么轻易,也但愿这两篇文章可以或许辅佐您。

两台装备只要通过proxy或fastcgi协议相互通讯,城市碰着504题目,好比Nginx+PHP-FPM会碰着;署理处事器毗连后端Web处事也会碰着。我本次碰着的场景属于后者,重点讲授署理导致的504题目。

署理处事器和Web处事器通讯中的504题目

题目说明

为了把题目说清晰,先先容下我单元处事陈设架构,如下图:

署理处事器和Web处事器通讯中的504题目


许多读者看到https会见,揣摩504题目是不是因它而起,现实上完全没有相关,但整个陈设架构却由于引入了ssl,导致体系伟大化了。将来ssl必定是主流,假如你这张图的陈设感乐趣,可以看看我的新书《深入浅出HTTPS:从道理到拭魅战》,内里描写的很具体,此处也算作个告白。

在本文引入这张图的基础缘故起因是想让读者可以或许清楚的相识我碰着的题目,假如没有这张图,读者在领略的时辰会很坚苦。但也不要想的过于伟大,简朴领略就是nginx作为署理处事器毗连后端的web处事器(apache/mod_php)。

接下来描写详细碰着题目,在赏识器中会见https://mail.sina.net/x.php的时辰,该接口上传文件然后存储到阿里云OSS上,假如传输的文件很是大,执行时刻将会很长,一旦到20秒到时辰,肯定会呈现呈现504错误,详细如下图:

署理处事器和Web处事器通讯中的504题目

顺带说一下,其他页面和接口没有碰着该题目,在那一刻会猜疑是不是x.php措施处理赏罚有题目(大部门人会这么领略)。

那到底上面是504错误呢,看下wiki的引用:

4 Gateway Timeout

The server was acting as a gateway or proxy and did not receive a timely response from the upstream server

它的意思就是一个网关或署理处事器可以或许毗连后端处事器,但在读取处事器相应的时辰超时了。碰着504题目一样平常是后端处事的题目,好比:

  • 后端历程无端退出了(也许是代码非常,也也许是apache或nginx历程非常),导致署理处事器吸取不到后端相应。
  • 后端相应迟钝,导致署理处事器吸取后端相应超时了。

办理题目

凭证上述也许的两个环境,一一说明。

(1)x.php措施在特定的环境下,确实运行迟钝,但apache的access log在25秒阁下的时辰乐成记录了200会见日记(因为php代码执行竣事后才记录日记,一开始也许看不到access日记,导致开始误以为是后端措施的题目)。

(2)在x.php措施中记录应用日记,应用日记和access log日记一样,没有任何非常。

这声名代码并没有题目(但措施执行时刻过长,有优化的空间),固然在20秒发生504错误(由nginx处理赏罚),,后端代码历程如故继承运行,并在25秒乐成运行。

解除这个题目后,最有也许是署理处事器认为后端相应过于迟钝,主动封锁了该毗连,是不是署理处事器配置的超时时刻过短?因为公司的署理处事器(ssl nginx)是由专人维护的,我看不到详细的设置,邮件扣问了同事,获得回覆如下:

  1. proxy_read_timeout 60 
  2. proxy_send_timeout 60 

起首看下 proxy_read_timeout 的官方先容:

  • Defines a timeout for reading a response from the proxied server. The timeout is set only between two successive read operations, not for the transmission of the whole response. If the proxied server does not transmit anything within this time, the connection is closed.

先容的很具体了,获得这个复原我就很迷惑了,超时时刻是60秒,但504在20秒的时辰就发生了,大大的问号悬我脑壳上,又细心看了下官方文档,是不是 proxy_read_timeout 参数的值写的不严谨,官方写的是60s,可纵然写错了,nginx 默认的超时时刻也是60秒;是不是nginx 版本默认超时时刻纷歧致?官方文档也并没有对该指令有非凡的声名。

最后同事将该值修改为:

  1. proxy_read_timeout 300  
  2. proxy_send_timeout 300 

题目最终办理了,必定是proxy读取超时了,但详细的设置如故让我迷惑。

进一步测试

因为我看不到公司署理处事器的详细设置,以是我安装了一个署理处事器,感乐趣的同窗也可以进一步相识nginx的proxy设置,假如没有非凡的需求,设置很是简朴。

  1. server { 
  2.     listen  443 ssl; 
  3.     server_name  www.simplehttps.com; 
  4.  
  5.     location / { 
  6.         access_log access.log  main; 
  7.         error_log  error.log; 
  8.  
  9.         proxy_pass http://127.0.0.1:8080; 
  10.         proxy_read_timeout 5; 
  11.     } 

proxy_pass 可所以一个host、内部域名、ip地点,不消是一个对外的域名。

(编辑:湖南网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读