原文（含大量监控界面截图）： 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
1
Select Language