本文原创:中国科学技术大学 张焕杰
修改时间:2019.05.25
2018年建设了 http://ipv6.ustc.edu.cn ,测试跟踪各站点对 IPv6/v4 的 HTTP/HTTPS/HTTP2支持情况。
学校的网站,自己校内访问总觉得很满意。但是从其他地方访问,速度、稳定性满意吗?特别是跟兄弟单位网站的对比情况,总是值得探究的话题。
近期做了个分布式网站访问测试系统,运行了半个月,发现了一些有趣的现象,分享给大家。
分布式测试系统分两部分:
- 中心端
中心端主要是存放测试结果的influxdb和web展示的grafana。
- 测试点(SITE)
测试点定期对制定的URL访问测试,记录dns查询时间、tcp连接建立时间、获得第一个响应的时间、传输字节数、传输时间、传输速度等信息。 并将这些信息提交给中心端,存放到influxdb中。
测试点上使用 https://github.com/bg6cq/httptest 完成具体的测试,提交给中心端使用 curl。
测试点可参考 https://github.com/bg6cq/ahstatus 建设。
为了简化测试点的部署,使用docker方式部署,可以实现完全的自动更新。
测试时,为了让结果更有代表性,选择每个网站上大约500KB大小的文件进行测试。
向提供测试点运行的学校相关老师表示诚挚感谢!
下面是测试结果中一些比较有趣的现象。
上图是从科大测试点通过IPv6线路访问PKU和THU的下载速度,THU一直稳定4MB/s,而PKU一直稳定2MB/s,每个点是原始数据。
科大到PKU/THU间IPv6通信延迟约26ms,带宽很宽也不应该有设备限制带宽,为何测试结果很像是带宽被限制呢?
经过抓包分析,发现是TCP窗口大小引起的。
抓包发现,PKU的服务器不支持tcp window scale选项,因此服务器端发送的最大窗口是64KB,链路延迟26ms左右。 也就是每26ms,服务器最多发送64KB,折合速度大约是64/0.026=2.4MB/s(实测2.2MB/s)。按照每ms统计数据包,是下面的图:
而THU服务器,一上来发送tcp window scale选项7,也就是可以支持>64KB的窗口。实际传输时,窗口大小在130KB左右变化,因此速度比pku高了近一倍。 下午是每ms统计数据包对比,左边是PKU下载的数据包,右边是THU下载的数据包:
THU自己的每ms统计是下图:
从图里看,由于TCP窗口不够大,带宽远没有被占满。
初步估计测试点到服务器端有1G的带宽,26ms延迟,填满整个链路需要2.6MB,因此需要有2.6MB的窗口大小,才会完全用满链路带宽。
下图是从多个测试点访问THU和PKU的速度:
从中可以看到PKU的访问速度抖动很厉害。
经对比测试,如果用docker常用的alpine linux中的OpenSSL 1.1.1b 26 Feb 2019库,访问PKU时,https传输过程中会偶尔中断,其他高校未发现该现象,原因未知。
下图是从多个测试点访问ZJU的速度和返回码。正常的返回码是10,返回码6的含义是非200应答。
从中可以看到ZJU的访问比较慢,而且有大量非200返回码。
经详细测试,发现www.zju.edu.cn访问确实不快。它似乎是通过某个CDN服务的,速度慢,而且访问IPv6地址时,还经常给出302重定向到某个IPv4地址的响应。
下图是从多个测试点访问NJU的速度和返回码。正常的返回码是10,返回码7的含义是未读取到正确的HTTP应答:
从中可以看到NJU的访问有大量非200返回码。
经详细测试,发现www.nju.edu.cn访问不稳定,表现在tls协商后,发送HTTP GET请求后,服务器不响应的情况。
欢迎 加入我们整理资料