这是一个创建于 1101 天前的主题，其中的信息可能已经有所发展或是发生改变。
内网的 https api 接口，用 golang 自带的 https 包写的。
接口本身很快就是返回一个字符串，类似客户端发 ping ，服务器发 pong 这样的接口，但是好像 https 握手有点问题：90%的情况下握手时间在 100ms 以内，但是偶尔会跑到 12s 。
为什么我觉得是 https 握手的问题呢，因为如果再这 12s 内关闭浏览器的话，服务端会出现一个 http: TLS handshake error from 172.30.30.0:58182: EOF 日志，所以我判断还在 https 握手阶段。
证书使用了 let's encrypt 的证书，开始以为是被墙的原因，于是做了 OCSP ，但是没有改观。
也考虑是 dns 服务器的问题，于是干脆在内网布上 dns 服务器，也没有改观。
另外出现这个问题的时候，此时用同一个浏览器窗口去访问其他域名的 https 接口（同样 golang ，内网），大概率也会要等 12s 。
但是出现问题的时候，如果用另外的电脑去访问这个接口，返回就很快。所以我判断不是服务器的负载太高。
大概率觉得是 https 握手的问题。各位可以指导下吗？
第 1 条附言 · 2021-11-08 16:42:20 +08:00
一个下午抓到2次这个现象，卡住的时候，浏览器在不停的访问一个IP地址114.80.30.43，但是似乎被公司防火墙挡住了。这个IP好像也没什么特殊的，查到是电信的一个IP。可是这个IP似乎和我们跑的应用没有关系。
第 2 条附言 · 2021-11-08 16:53:48 +08:00
看上去，这些 IP 都是微软的
 |
1
starsky007 2021-11-08 15:36:25 +08:00
“另外的电脑”也像出现问题的那台电脑那样“持续访问”，会怎么样呢？
这样有助于确定是服务端还是客户端的问题。 |
 |
2
misaka19000 2021-11-08 15:57:49 +08:00
tcpdump 抓包看
|
 |
3
msmmbl OP @starsky007 它也会出现偶尔 12s 的握手时间
|
|
4
msmmbl OP @misaka19000 嗯，正抓着呢，希望能发现点什么。
|
 |
5
jatsz 2021-11-08 16:16:27 +08:00
一个思路是使用 curl -v 来访问你的接口，纪录这些日志，查看时间真正花在哪里。
|
|
7
msmmbl OP @misaka19000 用 tcpdump 貌似发现了一点规律
|
|
8
starsky007 2021-11-09 11:48:07 +08:00 via Android
我想学习一下，希望楼主在问题解决之后分享一下。
|
|
9
msmmbl OP @starsky007 我也是在试。因为卡住的时候，tcpdump 正好都能在网关上抓到附言中提到的 IP 访问，并且那家公司貌似在防火墙上限制了它的访问，于是开始怀疑这几个 IP 了。通过 IP 反查，看出来应该是微软的 CDN 地址，结合公司内网的 DNS 查询记录，大体确认是访问几个 microsoft.com 后缀地址。于是干脆先在 DNS 服务器上加了一些规则，把 microsoft.com 后缀的 dns 查询直接返回 127.0.0.1 。先这样跑着，看看客户的反馈。
|
 |
10
alvinbone88 2021-11-09 18:36:06 +08:00
|
|
11
msmmbl OP @alvinbone88 厉害啊，应该就是这个问题了。屏蔽 microsoft.com 后客户反馈 ok 了。但是长久来看，还是应该解除这样的访问屏蔽，让系统可以更新到根证书。
|
Select Language