摘自 2023/11/07 笔记
最近在回归直播插件状态上报情况时,发现时不时会出现一次耗时6分钟的请求,让人匪夷所思

一开始以为是接口问题,联系接口负责同学排查。重启服务后还是多次出现这种情况。查看请求 `timeline` 发现阻塞发生在”stalled”状态

学习一下官方文档中对network请求各个阶段的解释
Stalled. The request could be stalled after connection start for any of the reasons described in Queueing.
翻译一下:由于排队中描述的任何原因,请求可能会在连接启动后停滞,似懂非懂,在搜一下 stack overflow 怎么说的:
Time the request spent waiting before it could be sent. This time is inclusive of any time spent in proxy negotiation. Additionally, this time will include when the browser is waiting for an already established connection to become available for re-use, obeying Chrome’s maximum six TCP connection per origin rule.
翻译一下:Stalled 是请求在发送前等待所花费的时间(也就是说跟接口一点关系都没有)。 该时间包括协商代理所花费的任何时间(检查本地代理!)。
此外,这个时间还包括浏览器等待已建立的连接可供重复使用的时间,遵守 Chrome 的每个源最多 6 个 TCP 连接的规则。(理解为连接池,如果6个连接都被占满了,就只能等待资源释放)。
如果是网络不稳定造成的等待,就不会每次都是相同的6分钟,每次都是等待6分钟,对应Chrome 6个TCP连接规则。破案了!

解决
为每个请求设置超时时间,当超过设置等待时间则cancel请求,减少资源占用。
const xhr = new XMLHttpRequest();
xhr.timeout = 60 * 1000; // 设置超时时间
xhr.open('POST', url);


发表回复