第一次写文章《中国大陆对象存储网络性能跟踪报告 04.01 ~ 04.08》华* 垫底好意外。

原文（含大量监控界面截图）： https://mp.weixin.qq.com/s/47nF1v4dS28cMFr3KIuPkQ

报告介绍

缤纷云 — www.bitiful.com
作为国内对象存储的新兴服务商，我们长期观察对象存储的性能与可靠性表现。想借此机会将我们的观察与大家分享，希望为大家的选择提供一点参考依据。

网络性能

数据结论

服务商	在线	TTFB(总)	TCP	SSL	Region
缤纷云 S4	100%	74 ms	25.4 ms	50.7 ms	江苏
阿 OSS	100%	146 ms	34.6 ms	101 ms	江苏
百 BOS	99.98%	207 ms	29.7 ms	152 ms	上海
京 OSS	99.97%	151 ms	27.0 ms	53.3 ms	上海
腾 COS	99.95%	181 ms	30.7 ms	87.2 ms	江苏
七 Koda	99.85%	175 ms	19.1 ms	48.8 ms	全局
华 OSS	99.75%	176 ms	32.0 ms	94.8 ms	上海

一些说明:

百度 BOS 创建的是“上海可用区”的桶，但实际 IP 探测似乎为“山东”；
七牛 Koda 默认套用 CDN ，所以：
- Region 为“全局”，由于跟用户都是就近连接，故 TCP 建连时间远低于其他；
- 也导致实际的 TTFB （首字节）延迟反而很大；
- 导致几乎垫底的在线率（ 99.85%），因为我们的测试方法排除了缓存的干扰。
只有缤纷云 S4 几乎没有多余的性能损耗（ TTFB 时间约等于 3 次 RTT ）。
华为 OBS 在线率的意外垫底，我们感到非常惭愧，未来会持续优化测试方法。

[ GPT 小课堂]

理想情况下首字节（ TTFB ）延迟应该是多少？

提问：假设网络物理延迟为 25ms 服务器响应的首字节的理论延迟是多少 ms ？

GPT4 回答： 如果客户端和服务器之间的物理延迟为 25 毫秒，我们可以将此值用作单个往返时间（ RTT ）。在最理想的情况下，如果使用的是 TLS 1.3 （它可以在一个 RTT 完成 TLS 握手），整个过程的延迟将是：加总起来，理论延迟将是：

DNS 解析 + TCP 握手 + TLS 握手 + HTTP 请求和响应
即：1 RTT + 1 RTT + 1 RTT + 1 RTT
全流程为 4 次 RTT
每次 RTT 为 25 ms

DNS 缓存前：
    首字节延迟 = 4 * 25 ms = 100 ms
DNS 缓存后（去掉 DNS 解析的 1 次 RTT ）：
    首字节延迟 = 3 * 25 ms = 75 ms

Greenm

36 天前

先说利益相关：

作为一个厂商，既当运动员又当裁判，这个测试从最开始的定位就站不住脚。

其次是测试方法：

你用阿里云作为拨测的出发点，然后测试其他云的单个 region ，得出仅有阿里云和你们的产品在线率是 100% 的结论。然后测试时间仅为一周。你哪怕多上几个节点，多测几个 region ，多用国内国外不同的云服务做做拨测，然后时间拉长到半年一年呢？

最后说你们的结论：

通篇再讲你们那个优势的 TTFB ，说实话我用对象存储根本不在意这个，最让人在意的稳定性和可靠性，你们就用了一周时间测试，然后吹自己是 100%，你们 SLA 可以承诺到 100%吗？阿里腾讯才出了事故大家都看见了吧。推广都不会推广，测试手段业余得不行，在这之前我并不认识你们，说实话看了你这个报告，我对你们印象直接为负，绝对草台班子。

nicoljiang