问题背景
该问题案例来自于公众号朋友分享，简单分析记录一下故障排查过程。
?
用户反馈网站打开慢，我们在不同的互联网访问源进行尝试打开网站，均会出现打开缓慢的现象，问题貌似出在服务器端，那么具体问题会是什么呢？
?
关于 http/https 方面的问题排查，浏览器开发者工具或是 Fiddler 工具同样也是分析利器，本文重点仍放在 Wireshark 分析上。
?
问题分析
由于网站打开缓慢的现象必现，所以排障环境较为容易实现。首先直接通过浏览器开发者工具简单看下，
其中部分 css 和 js 文件加载失败，时间长达 19s 多，和浏览器打开页面现象以及时间基本匹配，基本是在 19s 多之后才能打开网页。
?
继续转向 Wireshark 抓包结果，主要分析如下：
TCP Stream 0
在正常的 TCP 三次握手之后，客户端发起的 GET 请求 css 文件，并没有得到服务器响应，之后不断重传（分别为 NO.54、117、121、125、137、149），同时在一定时间之后服务器也进行了 SYN/ACK 的重传（分别为 NO.129、141），但仍未正常形成连接。之后从 No.153 开始客户端发送 TCP Keepalive 数据包（Wireshark 在此标识为疑似重传），在 10 次尝试无响应后，客户端 RST 连接，之后服务器也 RST 了连接。
通过进一步检查，
TCP Stream 1
在接近的时间上，TCP 流1能正常连接。
?
TCP Stream 2
与 TCP Stream 0 同样的现象，请求的文件类型为 js，这和浏览器开发者工具所看到的文件状态失败也匹配。
?
整体现象看下来，在服务器端未能正常建立连接，可能有两种原因：
- 服务器端未收到 TCP 握手第三次数据包，但实际上紧接之后客户端的数据请求也可以使得服务器端正常建立连接。客户端发送了 GET 数据请求，但服务器端未正常收到。
- 服务器端收到了 TCP 握手第三次数据包，但服务器端开启了 TCP 选项
TCP_DEFER_ACCEPT，因此并未正常建立连接。同样等待客户端发送 GET 数据请求，但服务器端未正常收到。
?结合 TCP 流 1 的正常结果，TCP 流 0 和 2 上的问题现象，更加匹配上述分析 2 中的原因。
TCP_DEFER_ACCEPT ，可以参考之前的一篇文章 《Wireshark TS | 服务器在三次握手后发送RST ？!》
?进一步分析，该网站在 19s 之后打开了基本页面
TCP Stream 6
其中 TCP 流 6 中所请求的 css 文件与 TCP 流 0 中的一致，而能正常连接请求到文件的时间，相差即为 19s 左右，与浏览器开发者工具所看到的文件请求消耗时间匹配。
问题总结
对于每次尝试打开网站，服务器端未能正常收到 css、js 等类型文件的请求数据包的问题，推断有可能是触发了服务器端的某些安全策略，阻拦了相关请求数据包，造成第一次请求文件失败。而由于部分页面文件的缺失，使得网站页面整体加载缓慢。