记一次瞬时网络挂起和XMLHttpRequest: 网络错误 0x2eff

男孩里欧

于 2022-07-07 11:00:35 发布

阅读量1.3k

点赞数

分类专栏： java linux 浏览器文章标签：网络服务器 nginx

本文链接：https://blog.csdn.net/son_of_a__bitch/article/details/125651471

版权

java 同时被 3 个专栏收录

21 篇文章 0 订阅

订阅专栏

linux

4 篇文章 0 订阅

订阅专栏

浏览器

3 篇文章 0 订阅

订阅专栏

HTTP请求网络挂起

事发经过
- 场景1-并发场景
- 场景2-并发量翻倍
问题处理
结果

事发经过

场景1-并发场景

一个B/S服务网站，在一次并发场景中，偶发出现个别客户端请求网络无反应，查看客户端发现并无具体网络请求，可能是浏览器的某些原因导致的。（并发量在预计之内，更高的并发都无问题，因此将服务端优化或者性能不足排除），服务端日志信息无异常、nginx正常，连接数正常，通过zabbix查看系统性能无波动。因此断定为偶发，并无具体关注。

场景2-并发量翻倍

Again，第二天同样的并发场景，量级达到了之前的一倍。（同样在预计之内）此次并不是个别客户端发生问题，几乎所有客户端都无法访问，在具体查看客户端状态发现请求异常的诡异，请求无响应，之后出现大批量的网络挂起，尽管如此，检查的服务端日志、nginx、连接数、zabbix、数据库依然异常的平稳，并无异常的波动，这就和类似场景下的服务不一致了。具体操作某个客户端发现请求都被挂起，但是静态资源加载正常，多个请求并不是所有都挂起，个别会请求成功返回200。再次查看服务端相关信息后，排除服务端问题。

问题处理

排查过程1

从请求过程入手，先看了下负载服务器的上游是否有什么问题，在咨询了相关人员后，得到的回复是并无任何防护，只是做了数据转发。此时，一种无力感涌上心头，期望直接破灭。上游无拦截，客户端请求挂起，服务端未正常接收到请求，nginx无错误日志，也无接收到请求。那挂载到底是谁返回的呐？再次找自身问题，重启系统，重启服务器，想着可以释放资源，结果**“失败”**。如果是服务端返回的挂载，至少也会收到请求。

排查过程2

在排查和沟通无果后，到服务器供应商现场去。真实了解下，具体的请求转发是何时、何地、何种方式到达我们的服务器的。再次沟通后，发现存在SLB负载服务器（我真是***）负载有一个限制并发的QPS初始值为1000。因此很少出现超过QPS1000的场景，所以就没有调整过。将QPS调高至1W…想着大工搞成。NND，客户端请求已经不挂起了，出现了一个新型错误信息。

因业务特殊使用的IE11浏览器，
XMLHttpRequest: 网络错误 0x2eff
XMLHttpRequest: 网络错误 0x2eff
XMLHttpRequest: 网络错误 0x2eff

同时使用谷歌、火狐、360极速模式可以正常发起请求（诡异的很）。
发起的请求F12已经不出现在网络上了，全跑控制台了。
请求的都是错误，抓紧收集相关错误的资料。

翻阅了很多，说是IE自身的BUG，那我只能用IE没招啊。还有说再同一个页面内加载的请求数挂载超过一定范围就会出现类似错误，也就是同一个请求一直点一次无正常反馈，就会出现网络错误0x2eff的代码。在之后的场景中并无高并发情况，因此一度无法重现此问题，经过多轮的压力测试也是无法重现此问题。
为了复现类似挂载问题，做了一个特殊接口，接口请求后直接等待，最后再统一释放。在多次尝试后，发现IE浏览器在挂载数量达到“12”后就不会继续去真实的请求接口，服务端也只接收到了12个发起请求，其余的请求服务端并未真实的接收到具体请求。但是，在客户端的F12网络里却看到了相关请求，请求也是挂起。网络是有请求，服务端没接收到。那就是浏览器自身将请求拦截了。将浏览器关闭和缓存清楚后，也是同样的结果。

浏览器同域名请求并发限制数
http、https请求

浏览器	请求并发限制
IE8、IE10、IE11、Firefox/chrome4+	6
safari3，4	4
Opear	8
iphone2,4,Android2-4	4
iphone3,5	6

浏览器的最大并发连接数

浏览器	请求并发限制
IE11	默认100
Firefox	默认900

首先从得出的信息看，可能是之前的请求挂起的太多，已经到达默认的100了。所以无法请求，再加上
XMLHttpRequest: 网络错误 0x2eff可能是请求失败的过多就不会真是去发送请求直接报代码错误了。
但是到目前为止只能是之前有一个限制，导致浏览器挂载的请求过多，大于100没有真实的释放掉。导致之后的请求都不正常这个结论了。

排查过程3

排查的结果是不令人满意的，因无法复现类似问题，无法确保SLB的QPS调高后就可以正常使用。没人可以打这个包票。那就从请求过程中任何一个参与过请求转发的上游主体联系。找到负责人，无法提供网络拓扑图，那就是先从最近的上游开始，在沟通到SLB的上游存在哪些主体时，又发现了一个新的上游。新的上游存在一个防护措施，抗D防护。在对下一级的IP做防护策略和检测发现我们出现问题的那一段时间直接将对应的IP都封闭了。请求拦截的源头看来找到了啊，希望就在眼前。他们的防护是将大批量请求的IP直接封禁，在请求就无响应，过一段时间自行解除。默认的PPS限制是1000，直接吐血。