共计 2949 个字符，预计需要花费 8 分钟才能阅读完成。
前言
近期在工作中，遇到了一次很有意思的内存透露，把排查过程和思路记下来，供大家参考和学习，如有不正确的，欢送斧正。
起因
最近几天很多半托管客户，忽然报连贯服务失败，登上服务器后查看内存很高，为了让客户尽快恢复业务，运维共事第一工夫抉择了重启。
top 图
重启后，内存肉眼可见的速度涨了上来，研发共事判断后，可能之后又须要重启，长期给客户部署了备用服务。（不管三七二十一先扩容）
冰山一角
- • 日志
- 日志
Too many open files 代表曾经到了以后过程能够关上的最大文件数，第一工夫抉择了先加大以后过程关上的最大文件数，让后续的申请能够失常解决
echo - n "Max open files=85535:85535" > /proc/pid/limits通过命令查看以后曾经关上的文件数
lsof -p pid | wc -l
43326失常的过程不可能关上这么多 fd，所以应该存在连贯透露
lsof - p pid | grep can't identify protocoljstack 打印以后的堆栈
jstack -l pid > pid.txt找到以后堆栈中应用 http 中央，排查代码，查看代码有可能没 close 连贯的中央。
修复好代码，上线后，重启过程，在察看发现内存很安稳，关上的文件数也逐步安稳。
你认为这么简略就完事了？如果就这么简略，我就不会写这篇文章了。
第二天，第三天陆续有其余半托管客户找过去，同样的问题，内存透露，最大文件数始终居高不下，直到达到限度。
和下面的客户一样，修复同样的代码后，均都复原了失常。
发问
1、为什么都是半托管的客户报这个问题，私有云未有客户反馈
2、这些半托管的客户为了稳固，代码曾经很久没降级，代码都是 2021 年的，为什么都跟磋商好似的，一起报问题，难道我有 bug 吸引体质？
3、为什么这些客户，物理机房隔离，问题表象却都一样？
4、客户须要一个正当的解释，我总不能说网络抽风了吧？
所有不合理的中央，其实都有正当的解释
半托管：后端服务和敏感数据在客户机房，前端网页在私有云。
理性分析
因为都是半托管客户，又都是因为 fd 太多，导致的内存透露。
那咱们有一点是能够必定的，那就是连贯过多，导致 fd 激增，既然是网络问题，那咱们就应用 万能法令（遇事不决，先抓个包）
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”>HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Private-Network: true</pre>
或者
<pre class=”prettyprint hljs groovy”>HTTP/1.1 200 No Content
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Private-Network: true</pre>
10、服务端要不要兼容更新
答：我认为是有必要的，当初 chrome 发动 options 申请，你响应或者不响应都不会阻止后续的申请，然而如果他那天在自动更新，你如果未失常解决 options 申请，就不发送后续业务申请，
嗯。。。我曾经联想到了一大部分程序员连夜加班修 bug 的局面了。
