问题已经解决,感谢阿里云CA证书方面提供的技术支持。
现在留下造成问题的原因以供后面和我一样碰到该问题的同学查询。十分感谢阿里云的技术团队协助。阿里云好样的。
其实说来也简单,估计很少人会碰到这种问题,是域名解析造成的
已知我的主域名是 www.xxxxa.com
我签名的证书的域名是 m.xxxxa.com
然后当初我为了图变动web服务器IP方便,所有子域名全部以 cname 解析到 www.xxxxa.com ,这样一来,如果web服务器IP变更了的话,我修改 www.xxxxa.com的A记录指向后,即可变更所有子域cname指向的IP。而我当初签名的时候提交的域名是 m.xxxxa.com ,但是解析的时候却是 cname 解析到 www.xxxxa.com ,因此会有问题,为什么又是首次访问偶发性的呢,我猜应该是dns缓存导致的,dns解析成功一次后会缓存,一旦解析成功了,缓存建立了后面则很快速了。我猜是这样。。。。。总之问题算是解决了,修改m.xxxxa.com 的A记录指向为服务器IP后(注意修改解析的延迟,我当时修改完了一样会超时,放了好久才正常),现在访问没有出现过超时了。再次感谢阿里云技术支持,如果凭着我自己去找问题,我估计找死了也找不到这个问题。。。。。。
===================================================
我把网站从http升级到https后,发现pc端用chrome ,然后 https://m.xxx.com这样去访问网站的话,十次大概会 有一次连接超时,请求的时候迟迟无法展示结果,然后最后浏览器报超时,在它加载中的时候,我用手机设备去访问 https://m.xxx.com ,发现马上能打开,这说明不是服务器宕机,而是本次浏览中在传输数据中有故障了,我该怎么排查这个问题?
服务器环境是 windows server 2008 IIS+sql server数据库。
.net 4.0的项目。用的证书是阿里云的赛门铁克dv ssl 证书
这个和证书有没有关系?
现在我该如何去定位问题所在呢?求有经验的人支招
==========
我问题描述有误,不应该是偶尔,应该是首次加载(我确定以及肯定http的情况下首次加载不会超时,不存在加载资源慢等情况)
比如我电脑很久没访问 https://m.xxxx.com了,这个时候去浏览器输入https://m.xxxx.com的时候就很有可能超时,铁定是因为做证书验证这一块比较耗时我觉得,为什么会这样呢?
证书是部署在阿里云负载均衡还是IIS上?
证书是直接部署在IIS上,没有任何负载均衡。
@LoveCoder: 建设使用负载均衡,好处多多
@dudu: 上负载均衡得增加成本。没道理上个https一定要上负载均衡啊?
目前单台服务器可以支撑,不打算上负载均衡,求问题定位方案。
@LoveCoder: 20多元/月的成本,部署证书极其简单,后端服务器连http压缩的开销也省了
@dudu: 才20多元一个月?这个可以接受,是阿里云负载均衡吗?好像没这么便宜啊。
还有,我觉得我问题描述有误,不应该是偶尔,应该是首次加载。
比如我电脑很久没访问 https://m.xxxx.com了,这个时候去浏览器输入https://m.xxxx.com的时候就很有可能超时,铁定是因为做证书验证这一块比较耗时我觉得,为什么会这样呢?
@LoveCoder: 不到20元,¥0.02/小时(15元/月),我们用了很多阿里云负载均衡
@LoveCoder: 如果要排查IIS的问题,建议使用Wireshark抓包
@LoveCoder: 阿里云SSL证书控制台可以直接将证书推送到负载均衡,部署很方便
@dudu: 我试试看下加个负载均衡。
杜大大,你觉得这种第一次加载https会超时大概可能的问题是什么?和证书有没有关系?
https在加载的时候不会去请求其他第三方机构的服务验证真伪之类的吧?
@LoveCoder: 证书没问题,我们用的就是Symantec证书
@LoveCoder: 另外,我们之前遇到过一个在 windows 上部署 https 证书的问题,详见 https://www.cnblogs.com/cmt/p/aliyun-slb-https.html
@dudu: 关键是我用的是免费申请的,阿里云免费申请的 dv ssl ,按道理来说和证书应该是没有关系的。
能大致猜一猜原因,然后我去服务器操作操作验证一下吗。
这个又不是每次首次加载都超时,最怕遇到这种问题。
偶尔首次加载超时,我想复现一下都得看运气。
@LoveCoder: 看一下 TLS 1.2 Support added to Windows Server 2008
@LoveCoder: 猜不出来原因,我们都在负载均衡上部署https,Windows服务器用的是2016
@dudu: 好吧。谢谢回复。我再多试试,如果有结果我会及时更新到问题,帮助后面可能还会碰到这种问题的朋友
@LoveCoder: 建议的排查方法:用Wireshark进行tcp抓包
@dudu: 嗯嗯。好的。谢谢
现在又不会超时了,不知道它什么时候会超时,这种问题好头疼。
@dudu:
前段时间出差去了,临时改回了http,这次继续找问题。我用你说的winreshark抓包了。抓包结果我私你