Chrome Https访问Goahead服务器卡死问题

该问题没有从根本上定位解决，备忘：

问题描述：

Chrome Https访问Goahead服务器，Chrome只请求了一部分静态资源，然后只发心跳，无限期等待，不会继续发起请求；

点击浏览器的空白标签栏，或者缩放等方式重新聚焦动作，Chrome会继续请求剩余的静态网页资源；

（F12调试看chorme浏览器的network ，不发起剩余资源请求）

只要不把浏览器关掉，再次请求都相对比较流畅；

Goahead是单线程，卡死问题可能和这个相关；

wireshark抓网络数据包来看，并没有看到服务器出错；

在Chrome不再请求新的资源（如asp网页或者网页table中的 图片资源）时，依然保持和server的心跳；

交互帧为，三路握手后 互发https hello, 然后chrome发送FIN，四路挥手；

另外一个现象：

https方式第一次进页面比之后要慢很多；可能和ssl的握手有关系；因为这不是个主要的问题，不影响功能，没有持续关注；

目前的解决方式：

用屏蔽部分资源和功能的方式，来看看是否是请求少的时候就没有问题了；

如果是，那么尝试采用减少资源请求次数；

css文件的包含：@import url("./style/main.css");

script脚本的包含：<script language="javascript" type="text/javascript" src="./common.js"></script>

F12调试的时候，会看得到，都会单独发起一个请求；

查找规律发现，出现Chrome卡的问题和请求数量有一定的关系；

所以，尽量减少如上文件包含的方式；

将有些不需要马上开始的请求，使用window.setTimeout()的方式延迟，避免同一时间请求太多；

个人猜测：可能服务器的反馈速度没办法达到Chrome的一个性能要求，于是Chrome暂停了更多的请求，除非你再次聚焦到该网页；

这么猜测的原因是个人使用Chrome特意去访问国外网站，速度很慢，于是出现了和我们网页类似的问题；

具体的Chrome策略并没有进行核实；

但是作为一个嵌入式的网站，需求照着apache服务器来对比，却没有考量到我们使用的Goahead是一个单线程的简单服务器；

也有我们软件设计最初没有考虑性能，很多同事的WEB基础不过硬，边做边学；

后期的设计用Goahead3.1时，跨平台用JQuery，AJAX的请求数量和合理，运行应该是可以相对稳定和易维护的。