Https 握手时间过长的问题如何解决

2018-02-12 00:55:04 +08:00
 night98

RT,偶然间发现博客的第一次访问时间非常的久,大约需要 3-4 秒的时间才能打开,但是第一次访问之后速度就非常快了,基本上是秒开,看了一下,发现是第一次 tls 建立时间导致的访问缓慢,大约需要 2000-3000 毫秒才能建立,但是朋友的博客只需要 300-700 毫秒即可建立完成,排查了许久没有找到原因,服务器用的 Nginx,证书是腾讯云的免费证书。

顺便加个外链增加点人气 博客地址:noesblog.com

查看延时请用火狐浏览器,先打开开发者工具然后输入网址,然后点 / 文件,点耗时查看。

想问下各位大佬是啥原因,讲道理我机器配置比朋友的要稍微好一点,应该不会这么慢才对。

14363 次点击
所在节点    程序员
36 条回复
singer
2018-02-12 09:27:53 +08:00
同为杭州程序员,握爪
cloudzhou
2018-02-12 10:01:57 +08:00
你网站 https 握手时间确实很长,原因不明:
> curl -w "TCP handshake: %{time_connect}, SSL handshake: %{time_appconnect}\n" -so /dev/null 'https://noesblog.com/'
TCP handshake: 0.556682, SSL handshake: 1.683999

1.683999 的握手时间
Cat73
2018-02-12 10:02:57 +08:00
我猜是 OCSP ?
cloudzhou
2018-02-12 10:05:01 +08:00
MeteorCat
2018-02-12 10:13:42 +08:00
Docker 中转的?实际没必要,速度并不是太明显的慢
fe619742721
2018-02-12 10:21:38 +08:00
PC 打开接近秒开,期待楼主醒来总结一下调试经验
night98
2018-02-12 19:53:02 +08:00
@javaluo
@superluckykoo
@yaerda
感谢各位的测试


@mengdisheng 应该是服务器带宽问题,1M 小水管,看了一下腾讯云后台,显示各地延迟均为 100ms+,设置里面大概看了一下没有什么问题,ping 的话和源站速度差不多,但是延时太高,估计可能是回源速度慢的问题。


@cloudzhou 是的,握手时间确实太长了,感觉很奇怪,看了一下你发的那个网站,还是没有找到问题的原因。
@MeteorCat 没有,直接在母机上部署的,LNMP 组合,或许是阿里云的磁盘问题?

总结一下调试经验,在没有调试之前,几乎所有的 js,css 文件都是从 cdn 上面加载的,请求数在 25 到 30 之间,有时候可能 cdn 加载问题会导致页面重新渲染,因此将小的 js,css 文件使用源站加载,用了 Autoptimize 合并了这些文件,目前请求数在 7 个左右,减少了页面发送请求的数量,也避免了某个文件没有加载完成导致的页面加载过慢的问题。

然后是删除了评论部分的 emoji 图标,这些图标数量在 20 个左右,都是单独加载的,因此若有个别图标没有加载完成的话页面速度会慢一些,这里直接砍掉。

调整了一下页面的字体,删除了 font-aweasome 这个字体,因为这个字体大小在 75kb 左右,而且仅有返回顶部与菜单这部分引用了该字体,感觉没有必要,删除了这个字体的引用,以及将返回顶部的文字修改为文字类型。

php-fpm 方面,调整了性能参数,最大进程数设置为 30,初始进程数为 5,并且增加了定时任务,每两小时清理一次内存。

wordpress 方面,调整了 Autoptimize 插件的参数,具体参数这里就不截图了,根据自己站点的需求调整即可。删除了 W3 Total Cache,新增了 WP Super Cache 插件缓存所有页面,实测使用 W3 Total Cache 缓存页面,页面加载时间在 100-200ms,也就是那个 / 文件,如果使用 WP Super Cache 缓存页面的话,除了首次缓存的时候页面加载时间在 150ms 左右,其他的时间均在 30ms 内即可加载完成 html 页面,相比来说 WP Super Cache 速度提升比 W3 Total Cache 要好一些。

删除了一些页面的图片文件,其中首页上方背景图片之前是 90kb 左右,通常是在最后加载,时间大约为 300ms 才加载完,这里使用的是新浪的图床,初步预估可能是图片过大的原因,压缩图片质量到 30kb 左右,仍然需要 300ms 左右才可加载完成,这里就先砍掉这张图片了,有空的话再加。

目前有个比较奇怪的问题是页面会加载一个 favicon 文件,但是查找了磁盘和 wordpress 目录都没有找到该文件,预估可能是缓存的问题,这里暂不处理。

经过以上的优化,页面的首次加载时间压缩到了 200ms 内,但是仍然有几率出现握手时间过长的问题,这个问题有点迷,正好 https 证书要到期了就换了一个证书,握手时间过长的问题从之前的百分百降低到了偶发的程度,不过暂时不影响体验,就不做优化了。

经过上述的优化流程,目前页面的首次加载速度大幅提升,之前大约是 400-800ms 加载完毕,现在是 200ms 内加载完毕。继续打开页面其他的内容可以保持秒开状态,初步预估首次加载握手时间过长的问题可能是 http 重定向到 https 的设置问题,这里有待考究,另外我个人看到有些博客的秒开,他们的有些做法很不错。

小图片,图标,使用 base64 编码,直接放到页面,这样可以享受 gzip 压缩,而且不需要浏览器发送额外请求加载文件。
js,css 文件合并,大小在 20kb 以内的 js,css 文件压缩到一个文件中,大小超过这个范围的,例如 bootstrap 的 js,css 文件,可以使用 cdnjs,七牛云这些提供的前端公共库的地址来加载,避免从源站请求。
其他的页面静态化,页面压缩这些这里就不再概述了。
night98
2018-02-12 20:03:15 +08:00
@Cat73 有可能,正在看相关文章,看是不是这个的问题。
MeteorCat
2018-02-12 20:36:30 +08:00
@night98 过早优化是灾难开始,图片不要用 base64,直接图片访问,之后 nginx 将图片缓存射成一个月
night98
2018-02-12 20:40:07 +08:00
@MeteorCat nginx 设置了之后也是针对二次访问的,如果要求首次访问速度提升的话感觉 base64 这个方法会好一些。不过我这个是小水管站,1m 带宽的,大家参考即可。
MeteorCat
2018-02-13 00:08:51 +08:00
@night98 base64 之后的图片会导致比原图图片数据还大,而且 html 传输的数据开始膨胀,对于 http 传输来说,与其花费整张 base64 图片页面的加载,不如直接让他访问外链,html 的传输过程的膨胀,会导致日志系统和缓存系统越发臃肿,很多系统缓存都是用本地缓存,一个急剧膨胀的 html 对于空间和时间都没有好处
night98
2018-02-13 00:44:31 +08:00
@MeteorCat 哈哈,博客站点没有那么多讲究啦,头像这种我感觉 base64 还不错 ,背景图这种容易变动的还是图片外链,具体情况具体分析吧,你说的也没错,我看看再找找哪家的图床好一点的,最近找的几家图床速度都不怎么样😂
MeteorCat
2018-02-13 09:31:11 +08:00
@night98 没必要一上来就图床,本地服务器就行了,访问量就在那里,我们自己公司图片存储都还是直接服务开个 nginx 二级访问
night98
2018-02-13 18:37:33 +08:00
@MeteorCat 哈哈,我有强迫症,稍微慢一点都觉得不爽的那种,之前用的 hexo 就是因为发布文章不方便才又转回 wordpress。
woshinide300yuan
2018-08-20 22:11:19 +08:00
看来问题没有太完美解决,我刚首次访问文中的网址,依旧会卡住一会儿,之后就秒了~~

纳闷问题在哪,我也遇到了类似情况。
night98
2018-08-20 22:22:47 +08:00
@woshinide300yuan #35 之前优化好了,然后换了个主题。。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/430334

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX