让前端飞Web前端之路

浏览器请求最大并发数

2020-04-02  本文已影响0人  pengji

又到了三月,处于一些众所周知的原因。把之前没有完成的文章往出放一放,增加一些大家对我的了解。

问题背景

有一天被pm小姐姐反馈网站无法打开,一直是白屏; 我再本地打开了一下是正常的,而且展示速度也是正常的;查了下日志报错也没有啥问题;这个页面中只有一个展示二维码,扫码登录的功能;

于是开始了我的debug之旅:

  1. 收集了报错现场 ---小姐姐的错误请求的curl以及截图;发现请求一直pending,直到30s之后才会正常返回,于是排除了网络导致的请求延迟之后,开始考虑是什么因素致使请求一直被挂起呢?

    收集的请求
    30s后返回
  2. 分析了一下每个请求的 Timing之后发现:每个请求的Stalled时间都很久,但是又都可以发送成功。

    image.png

所以要了解一下Timing之中各个参数的意义,这个参数其实在优化网络请求时我们也有了解过,顺手做一下复习:

画一画重点 请求等待发送所用的时间。Queuing中的所有原因加上代理协商所用的任何时间。

在查看我的请求为何被挂起的过程中,突然发现我的请求优先级是medium ,话说会不会是被更高优先级的请求摆了一道呢?

关于请求被挂起页面加载缓慢问题的追查 这篇文章中了解到,chrome有cache_lock的机制,并且可以通过查看chrome 网络日志的方式来查看,并且在其中可以查看请求的优先级;

  1. 于是NetLog 粉墨登场

虽然在网络日志这里没有解决问题,但是还是发现了一个重要的表象 ---- 校验二维码的请求怎么会这么多? ( 列文虎克

校验请求
  1. 震惊的发现在浏览器的其他tab下,打开了一个闲置的登录页面,失控了一样发送校验请求。关掉之后,本页面的登录、加载也回归了正常。(如此,我们也抓到了本次bug的真凶!)可是真凶的成因不在本篇文章的了解范围内,按下不表了。( 已手刃

探究下为什么会出现这个情况?

排除代码中的bug本身,造成这个现象的原因其实是因为浏览器对同一域名请求是有最大并发数限制的。正是因为疯狂发起的请求超过了请求阈值,并且这个检查接口本身返回就比较慢,造成了后续请求的挂起而不是直接失败。

  1. 不同浏览器对并发限制也不尽相同:


    各浏览器并发统计
  1. 究其原因是处于多方面因素的优化考量:
  1. 同样涉及到的优化方式也比较多:
  1. 夹带一些这方面的面试题附送给各位:
    https://juejin.im/post/5d59ffe46fb9a06ad0056ddf

以上。

参考链接:

上一篇 下一篇

猜你喜欢

热点阅读