我们有一个服务于静态资产的网络服务器。我们遇到了一个问题,在您浏览一些 http 请求后,它会卡在“待处理”状态。在 chrome 检查器中,响应标头确实会返回,但请求不会超时,并且看起来像是在下载。在时间线视图中,“等待 (ttfb)”是最后填写的项目(例如 400 毫秒),然后有一个注释“注意:请求尚未完成!”
这个问题似乎仅限于 chrome,并且当网站运行 https 时。我们无法在 safari、ff、ie 上重现,如果 https 关闭,我们也无法重现。
奇怪的注释:
nginx 版本 1.9.3
# some variables we've tweaked
worker_processes 4;
worker_connections 4000;
keepalive_timeout 15;
client_body_timeout 12;
gzip on
Run Code Online (Sandbox Code Playgroud)nginx 日志不会抱怨任何事情
基于这些问题,该错误感觉像是某种类型的服务器配置问题,我们认为它与证书无关,但它仅影响 chrome 的事实确实很奇怪。
有关此问题或类似问题的大量信息,但没有一个解决方案对我有用。所以在挖掘之后 - 这是添加到服务器的响应标头['Connection'] ='close'
考虑wireshark
使用 Chrome 开发人员工具来分析网络流量。
在 Chrome 中打开网络调试器并尝试重现卡住的请求。它将向您显示准确的时间表:请求标头完全发送后,请求内容已发送,等待回复,响应标头完全接收,收到内容的第一个字节,内容的最后一个字节(如果完成)。
确定问题处于哪个阶段很重要?
如果一开始,Web 服务器从未收到请求,则可能一开始就无法建立连接。
如果它卡在等待内容结束,这意味着Web服务器完全接收并处理了请求,您应该能够在Web服务器日志中看到该请求,带有状态代码可能是错误?
我遇到过许多现实世界中的事情,这些事情会破坏响应或减慢传输速度。
积极的流量整形。必须在伦敦的一间办公室与亚洲服务器进行通信。第一个 MB 的响应正常,然后传输速度上限为 20 KB/s。它没有坏,只是速度慢得令人难以置信。
代理问题,尤其是 MITM 代理。它们可以无特殊原因地断开或保持连接。当我在银行工作时,曾经有一个完整的 MITM 代理,有时会无缘无故地花 5 分钟才能打开 Google.com,太烦人了,但在其他 99% 的时间里工作得很好。
HTTP/2(以前的 SPDY)和 TLS 1.3 问题。不管你是否相信我,但这些产品在刚推出的头几年就充满了 bug(截至 2020 年仍然存在一些边缘情况)。任何开发人员都应该意识到,没有任何代码在第一次尝试时是完美的,需要一段时间才能消除错误和边缘情况。不幸的是,这些东西确实需要跨系统完美工作,否则哎呀(浏览器、负载平衡器、Web 服务器等)。相信我,当您在组织中需要管理数十或数百个应用程序(在几个不同的堆栈上)时,您不会想成为新协议的早期采用者。
Chrome 错误。像所有复杂的软件一样,Chrome 也有缺陷,更重要的是因为它运行速度很快,而且经常故意把事情强加给你。我可以重复 HTTP/2 作为例子,Chrome 是第一个实现的,当然第一次尝试并不完美,所以这里出现了一些错误。Chrome 也是第一个默认启用它的浏览器,当然这会导致弹出窗口不兼容,并且您无法逃脱它。当您遇到奇怪的问题时,请考虑尝试上一个/下一个版本的 Chrome 或其他浏览器。
防毒软件。防病毒软件会过滤进出计算机的所有连接和所有流量。如果您不知道 Windows 防病毒软件的工作原理,它们会拦截所有网络系统调用。它们并非完美无缺,并且可能会严重破坏连接。我可以告诉你,我花了很多时间调试一个影响少数员工的问题,一个软件通过 HTTP 下载配置,这应该需要 1 秒,但对他们来说需要 10 分钟到 2 小时。我们追踪到这个问题是由于赛门铁克防病毒软件导致连接停止(1 KB/s),尝试分析流量或确定是否允许连接时一定是有问题的。然后与支持人员来回尝试修复它或找到不会发生这种情况的设置。
归档时间: |
|
查看次数: |
33708 次 |
最近记录: |