你知道吗？Chrome自动更新到104版本，其实是Java服务内存泄露，欢迎指正。原因是这几天突然有不少半托管客户反映连接服务失败。登录服务器后，内存非常高。为了让客户尽快恢复业务，运维同事第一时间选择了重启。上图重启后，肉眼可见的内存速度变快了。研发同事判断后面可能需要重启后，临时给客户部署了备份服务。（不管3721，先扩容）冰山一角?LogToomanyopenfiles表示已经达到当前进程可以打开的最大文件数，所以选择增加最大文件数在第一时间被当前进程打开，以便后续的请求能够正常处理。echo-n"Maxopenfiles=85535:85535">/proc/pid/limits通过命令查看当前打开的文件数lsof-ppid|wc-l43326一个正常的进程是不可能打开这么多fd的。因此，应该存在连接泄漏。lsof-ppid|grepcan'tidentifyprotocoljstack打印当前栈jstack-lpid>pid.txt找到当前栈中使用http的地方，排查代码，查看代码可能没有关闭连接的地方。修复代码后，上线后重启进程，发现内存稳定，打开文件数也逐渐稳定。你觉得有那么简单吗？如果真的那么容易，我就不会写这篇文章了。第二天、第三天，陆续有其他半托管客户来找我。同样的问题，内存泄漏，最大文件数一直居高不下，直到达到限制。和上面那个客户一样，修复了同样的代码后，一切都恢复正常了。问题1.为什么都是半托管的客户反映这个问题，公有云上也没有客户反馈。2、这些半托管的客户，为了稳定他们的代码，已经很久没有升级代码了。代码都是2021年的，怎么好像都在讨论？一起反馈问题，我是不是有吸引体质的BUG？3、为什么这些客户在物理机房隔离的情况下出现同样的问题？4.客户需要一个合理的解释。我总不能说网络抽风吧？所有不合理的地方其实都有一个合理的半托管解释：后端服务和敏感数据在客户机房，前端网页在公有云。理性分析是由于客户半托管，fd过多导致的内存泄露。那么我们可以确定一件事，就是连接过多导致fd激增。既然是网络问题，那我们就用万能规则（犹豫不决先抓个包）tcpdump-ianytcp-wtcp。pcap抓包后，用wireshark分析，发现有很多OPTIONS请求。Wireshak分析选项是什么？此请求使用jsonp。为什么会有选项请求？查看原始GET请求内容后，在此处插入图片描述，在公有云同一台服务器上抓包，发现只有get请求，没有options请求。这可以解释选项请求仅在出现问题的半托管计算机上可用。但是我们这么多半托管的客户，却只有少数几个大胆报题的假设，我们都知道options是浏览器发送的跨域预检请求，那么就说明这件事离不开浏览器。根据抓包文件，发送options请求的浏览器版本为chrome104版本。嗯，chrome又更新了。我们大胆假设内存泄漏与chrome版本有关。为了验证我的假设，我找到了chrome的升级说明。好吧，果然，只有假设性的答案才会附上chrome升级说明。如果做不出来，也可以看看github上的说明。大概意思是：如果你从公网访问私网，那么在chrome104版本中，会发送option进行pre-checking。该请求有一个新的标头(Access-Control-Request-Private-Network:true)。在这个初始阶段，这个请求是发送的，但是这个阶段你收到的时候可能没有响应，后续的请求还是会正常发送，不会影响你的业务，只是在DevTools中会有一个警告定义一个私有网络私网好人我看到我处理的半托管客户IP地址分别是192x、172x、10x，都是私网的，都是从公有云网站发起请求的，这就发生了要符合版本104.条件的描述。而且，该服务的代码比较陈旧。收到options请求后，没有正常释放，导致内存泄露。天哪，你能想到由chrome自动更新引起的内存泄漏吗？总结1.为什么都是半托管的客户反映这个问题，公有云上没有客户反馈？答：只有半托管客户满足公网IP访问私网IP的条件，部分用户的chrome浏览器会自动更新。2、这些半托管客户为了稳定客户，代码已经很久没有升级了。代码都是2021年的，怎么好像都在一起讨论，一起报告问题？我有吸引体质的BUG吗？答：chrome是自动更新的。3、为什么这些客户隔离在物理机房，却出现同样的问题？答：由于chrome自动更新，代码版本比较旧。4.客户需要一个合理的解释。总不能说网络抽风了吧？答：不知道chrome发布的versionnotes，能说服客户吗？5、是否只有chrome104版本受影响？答：其他和chrome104同版本的浏览器也会受到影响，testedge也会受到影响。6、如何判断我的网站受到影响。答：首先，您需要满足从公网访问私网的条件。其次可以查看请求头是否有chrome请求或者抓包中的header。在此处插入图片说明。7、HTTPS访问内网不受影响。访问https服务将受到影响。8.设置chrome://flags/#block-insecure-private-network-requests来避免它。无人回答：我测试了104版，没用。9、服务器兼容性如何？答案：服务器应检查是否存在Access-Control-Request-Private-Network:true标头。如果请求中存在此标头，服务器应检查Origin标头和请求路径，以及任何其他相关信息（例如Access-Control-Request-Headers）以确保请求是安全的。通常，您应该允许访问您控制下的单一来源。一旦您的服务器决定允许该请求，它应该使用必要的CORS标头和新的PNA标头以204NoContent（或200OK）响应。这些标头包括Access-Control-Allow-Origin和Access-Control-Allow-Private-Network:true，以及其他所需的标头。响应示例
