chrome Stalled时间过长

心跳请求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有这个问题，换个浏览器就好了，暂时也找不到解决办法