起因

最近几天很多半托管客户，突然报连接服务失败，登上服务器后查看内存很高，为了让客户尽快恢复业务，运维同事第一时间选择了重启。

top图

重启后，内存肉眼可见的速度涨了上来，研发同事判断后，可能之后又需要重启，临时给客户部署了备用服务。

冰山一角

• • 日志

• 日志

Too many open files 代表已经到了当前进程可以打开的最大文件数，第一时间选择了先加大当前进程打开的最大文件数，让后续的请求可以正常处理

 <pre class="hljs nginx" style=" padding : 0.5em; font-family: Menlo, Monaco, Consolas, " Courier  New", monospace; color: rgb(68, 68, 68); border-radius: 4px; display: block;  margin : 0px 0px 0.75em; font-size: 14px;  line-height : 1.5em; word-break: break-all; overflow-wrap: break-word; white-space: pre; background-color: rgb(246, 246, 246); border: none; overflow-x: auto; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px;  text-decoration -style: initial; text-decoration-color: initial;">echo - n "Max open files=85535:85535" > /proc/pid/limits
  

通过命令查看当前已经打开的文件数

 <pre class="hljs nginx" style="padding: 0.5em; font-family: Menlo, Monaco, Consolas, "Courier New", monospace; color: rgb(68, 68, 68); border-radius: 4px; display: block; margin: 0px 0px 0.75em; font-size: 14px; line-height: 1.5em; word-break: break-all; overflow-wrap: break-word; white-space: pre; background-color: rgb(246, 246, 246); border: none; overflow-x: auto; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-style: initial; text-decoration-color: initial;">lsof -p pid | wc -l
43326
  

正常的进程不可能打开这么多 fd ，所以应该存在连接泄漏

 <pre class="hljs nginx" style="padding: 0.5em; font-family: Menlo, Monaco, Consolas, "Courier New", monospace; color: rgb(68, 68, 68); border-radius: 4px; display: block; margin: 0px 0px 0.75em; font-size: 14px; line-height: 1.5em; word-break: break-all; overflow-wrap: break-word; white-space: pre; background-color: rgb(246, 246, 246); border: none; overflow-x: auto; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-style: initial; text-decoration-color: initial;">lsof - p pid | grep can't identify protocol
  

jstack打印当前的堆栈

 <pre class="hljs tcl" style="padding: 0.5em; font-family: Menlo, Monaco, Consolas, "Courier New", monospace; color: rgb(68, 68, 68); border-radius: 4px; display: block; margin: 0px 0px 0.75em; font-size: 14px; line-height: 1.5em; word-break: break-all; overflow-wrap: break-word; white-space: pre; background-color: rgb(246, 246, 246); border: none; overflow-x: auto; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-style: initial; text-decoration-color: initial;">jstack -l pid > pid.txt
  

找到当前堆栈中使用http地方，排查代码，检查代码有可能没close连接的地方。

修复好代码，上线后，重启进程，在观察发现内存很平稳，打开的文件数也逐渐平稳。

第二天，第三天陆续有其他半托管客户找过来，同样的问题， 内存泄漏 ，最大文件数一直居高不下，直到达到限制。

和上面的客户一样，修复同样的代码后，均都恢复了正常。

提问

1、为什么都是半托管的客户报这个问题，公有云未有客户反馈

2、这些半托管的客户为了稳定，代码已经很久没升级，代码都是2021年的，为什么都跟商量好似的，一起报问题，难道我有bug吸引体质？

3、为什么这些客户，物理机房隔离，问题表象却都一样？

4、客户需要一个合理的解释，我总不能说网络抽风了吧？

所有不合理的地方，其实都有合理的解释

半托管：后端服务和敏感数据在客户机房，前端网页在公有云。

理性分析

由于都是半托管客户，又都是因为fd太多，导致的内存泄漏。

那我们有一点是可以肯定的，那就是连接过多，导致fd激增，既然是网络问题，那我们就使用 万能法则 （遇事不决，先抓个包）

 <pre class="hljs nginx" style="padding: 0.5em; font-family: Menlo, Monaco, Consolas, "Courier New", monospace; color: rgb(68, 68, 68); border-radius: 4px; display: block; margin: 0px 0px 0.75em; font-size: 14px; line-height: 1.5em; word-break: break-all; overflow-wrap: break-word; white-space: pre; background-color: rgb(246, 246, 246); border: none; overflow-x: auto; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-style: initial; text-decoration-color: initial;">tcpdump -i any tcp -w tcp.pcap
  

抓完包后使用 wireshark 进行分析，发现有很多OPTIONS请求。

wireshak分析options

waht? 这个请求是使用 jsonp 的方式，为什么会存在options请求

在查看原本GET请求的内容

在这里插入图片描述

然后在公有云相同的服务器抓了个包，发现只有get请求，没有options请求，那可以说明这个options请求，只有在出现问题的半托管机器上有

但是我们有那么多半托管客户，报问题的却只有几个

大胆假设

我们都知道options是浏览器发的跨域预检请求，那说明这件事和浏览器脱不了干系，通过 抓包 文件来看，发options请求的浏览器的版本都是chrome 104版本。

嗯， chrome 居然又更新了，我们大胆假设一下，内存泄漏和chrome版本有关系。

为了验证我的假设，我找到了chrome的升级说明。

嗯，果然只有假设才会有答案

附上 chrome的升级说明 。如果打不过也可以看下 github 的这个说明

• • 大概意思就是说：

如果你从公网访问私有网络，那么会在chrome104版本，发option进行预检，该请求带有一个新的标头（Access-Control- Request – private -Network: true）。 在这个初始阶段，这个请求被发送，但是目前阶段你收到可以不响应，后续的请求还是会正常发送，并不会影响到你的业务，只会在 DevTools 中显示警告

下图带有private的为私有网络

私有网络定义

我处理的半托管客户，ip地址都为192x，172x，10x，全都属于私有网络，又都从公有云的网站发起请求，正好符合104版本描述的条件。

而且服务的代码比较老，收到options请求，没有正常释放，导致了内存泄漏。

你能想到一个内存泄漏，居然是因为chrome自动更新导致的吗？

总结

1、为什么都是半托管的客户报这个问题，公有云未有客户反馈

答：只有半托管客户满足公有ip访问私有ip的条件，且部分用户的chrome浏览器自动更新了

2、这些半托管的客户为了稳定，代码已经很久没升级，代码都是2021年的，为什么都跟商量好似的，一起报问题，难道我有bug吸引体质？

答：chrome自动更新导致

3、为什么这些客户，物理机房隔离，问题表象却都一样？

答：chrome自动更新导致，代码版本都比较老

4、客户需要一个合理的解释，我总不能说网络抽风了吧？

答：不知道chrome发表的版本说明，能不能说服客户

5、是不是只有chrome104版本受影响？

答：应该和chrome104同版本的其他浏览器也会受影响，测试 edge 也会有影响

6、如何判断我的网站受到影响。

答：首先需要满足公网访问私有网络的条件，其次可以在chrome请求或者抓包中，查看请求头有没有该标头

在这里插入图片描述

7、访问内网的https受影响不

答：上图就是访问https的服务，会受到影响

8、设置chrome://flags/#block-insecure-private-network-requests 可以避免不

答：我测试104版本没效果

9、服务端如何兼容

答：服务器应检查是否存在Access-Control-Request-Private-Network: true标头。如果请求中存在此标头，则服务器应检查Origin标头和请求路径以及任何其他相关信息（例如Access-Control-Request-Headers）以确保请求是安全的。通常，您应该允许访问您控制下的单个源。

一旦您的服务器决定允许该请求，它应该响应204 No Content（或200 OK）必要的 CORS 标头和新的 PNA 标头。这些标头包括Access-Control-Allow-Origin和Access-Control-Allow-Private-Network: true，以及其他需要的标头。

响应示例

 <pre class="prettyprint hljs groovy" style="padding: 0.5em; font-family: Menlo, Monaco, Consolas, "Courier New", monospace; color: rgb(68, 68, 68); border-radius: 4px; display: block; margin: 0px 0px 1.5em; font-size: 14px; line-height: 1.5em; word-break: break-all; overflow-wrap: break-word; white-space: pre; background-color: rgb(246, 246, 246); border: none; overflow-x: auto; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-style: initial; text-decoration-color: initial;">HTTP/1.1 204 No Content
Access-Control-Allow-Origin: 
Access-Control-Allow-Private-Network: true
  

或者

 <pre class="prettyprint hljs groovy" style="padding: 0.5em; font-family: Menlo, Monaco, Consolas, "Courier New", monospace; color: rgb(68, 68, 68); border-radius: 4px; display: block; margin: 0px 0px 1.5em; font-size: 14px; line-height: 1.5em; word-break: break-all; overflow-wrap: break-word; white-space: pre; background-color: rgb(246, 246, 246); border: none; overflow-x: auto; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-style: initial; text-decoration-color: initial;">HTTP/1.1 200 No Content
Access-Control-Allow-Origin: 
Access-Control-Allow-Private-Network: true
  

10、服务端要不要兼容更新

答：我认为是有必要的，现在chrome发起options请求，你响应或者不响应都不会阻止后续的请求，但是如果他那天在自动更新，你如果未正常处理options请求，就不发送后续业务请求，