连接测速
排错时经常要先分清一件事：是名字解析慢，还是解析完之后的链路本身慢。这一页测的是后者。浏览器和本站服务器之间建立一条 WebSocket 连接，先用几次小消息量出往返时延，再各用 8 秒钟收、发随机数据，算出下行与上行速率。
开始测试#
测试会在两个方向各传输至多 8 秒、至多 256 MB 的随机字节。结果只显示在这个页面上，服务器不保存，也不记录是谁测的。同一地址两次测试之间要间隔一分钟。为节省带宽资源，测速仅开放给已注册用户使用，开始前会要求输入密码。
需要密码为节省带宽资源，测速仅开放给已注册用户使用。请输入密码后开始。
- 往返时延
- —
- 下行
- —
- 上行
- —
- 连接
- —
按“开始测试”并输入密码后约二十秒出结果。
怎么读这些数字#
- 往返时延取五次消息往返中最小的一次，接近 TCP 握手看到的 RTT，不含 DNS 解析时间。
- 下行按浏览器实际收到的字节数除以用时计算，上行按服务器实际收到的字节数计算。两者都只用一条连接，所以反映的是单条 TCP 流在这条路径上能跑到的速率，受 RTT、丢包和两端拥塞控制共同影响；多条并发连接的合计吞吐通常更高。
- 传输的是随机字节，中间设备压缩不了，数字不会被压缩美化。
- 浏览器自己也有开销：WebSocket 帧要掩码处理，大量小消息会先堆在页面线程上。数字比网卡速率低一些是正常的，差一个数量级就值得查查别的原因了。
- 服务器一次只服务几个测试。遇到“服务器忙”，过一会儿再试即可。密码输错几次后要等十分钟才能再试。
用命令行看同一件事#
如果想把解析和传输分开看，可以先单独计时解析，再单独计时传输：
dig +stats example.com # 末尾的 Query time 只是解析用时
curl -o /dev/null -s -w '%{time_namelookup} %{time_connect} %{time_appconnect} %{time_total}\n' https://example.com/time_namelookup 是解析，time_connect 减去它是 TCP 握手，time_appconnect 再减去前者是 TLS 握手。哪一段突然变长，问题就在哪一段。
这一页会发出什么#
只有到本站同一主机的一条 WebSocket 连接，不访问第三方服务，不写 Cookie，不保存结果。密码只在这条加密连接里发给服务器核对一次，不会存进浏览器。随机数据在服务器上由一块预先生成的缓冲区切出，内容没有意义。