心跳请求getMsg每秒请求一次，所有卡住的请求会突然一下子全通，如下图
好久才发现是浏览器的问题，下图右边为双核浏览器正常。
只有坐席电脑出现这个问题。
参考这篇文章：
关于页面请求发起后，通过F12查看到，被挂起页面中stalled花费很长时间问题的追查
通过chrome自带抓包
chrome://net-internals/#events
下图左不正常，右正常。5261为耗时毫秒
发现是公司数据防泄漏拦截导致的
反馈给公司网络部dlp
后续果然是这个问题，他们升级了一下客户端就好了
完。
另发现公司另一个系统也Stalled时间过长
再次抓包
t= 1 [st= 1] URL_REQUEST_DELEGATE [dt=0] t= 1 [st= 1] HTTP_CACHE_GET_BACKEND [dt=0] t= 1 [st= 1] HTTP_CACHE_OPEN_ENTRY [dt=0] t= 1 [st= 1] HTTP_CACHE_ADD_TO_ENTRY [dt=20002] --> net_error = -409 (ERR_CACHE_LOCK_TIMEOUT) t=20003 [st=20003] +HTTP_STREAM_REQUEST [dt=0] t=20003 [st=20003] HTTP_STREAM_JOB_CONTROLLER_BOUND --> source_dependency = 2162 (HTTP_STREAM_JOB_CONTROLLER) t=20003 [st=20003] HTTP_STREAM_REQUEST_BOUND_TO_JOB --> source_dependency = 2163 (HTTP_STREAM_JOB) t=20003 [st=20003] -HTTP_STREAM_REQUEST t=20003 [st=20003] +HTTP_TRANSACTION_SEND_REQUEST [dt=0] t=20003 [st=20003] HTTP_TRANSACTION_SEND_REQUEST_HEADERS日志第一列为时间线，自请求发起时算。 第二列为每步操作所逝去的时间，时间差的概念，与第三列里面的dt不同，它会积累前面的耗时。 第三列为具体的事件，以及相应事件的耗时dt，此耗时为绝对耗时。
发现 net_error = -409 (ERR_CACHE_LOCK_TIMEOUT)
同参考文章一样，系统已经设置了
1.no-cache：是把资源进行了本地缓存，在浏览器使用缓存之前，会使用last-Modified和Etag往返浏览器进行对比，判断时间和唯一标识符和服务器的是否一致，一致的话304使用缓存，不一致的话请求服务器。
2.no-store：才是真正的完完全全的禁止本地缓存。
只有chrome有这个问题，换个浏览器就好了，暂时也找不到解决办法
