如何看待 Baidu Cloud CDN 回源 TTFB 高达 2.1 秒？

简述

这是一个技术讨论主题，与大家分享和探讨业务中遇到的问题。其中包含工程团队的一部分调查过程和结论，希望听一听大家的观点，指出调查结论中可能存在的错误或忽略的问题。

值得注意的是，请不要在该主题内添加任何与主题无关或违反社区指导原则的回复内容，包括但不限于：云计算服务提供商代理商销售广告、优惠活动和垃圾内容等。谢谢！

定义

CDN: Content Delivery Network 的缩写，指提供静态资源缓存和交付功能的一组地理上分散的服务器。
Baidu Cloud: 指公有云计算服务提供商百度智能云，与百度云加速和百度网盘无关。
TTFB: Time To First Byte 的缩写，指等待初始 HTTP 响应（不包括内容下载）所花费的时间。
回源: 指当 HTTP 请求的静态资源未命中内容分发网络所有缓存层时向源服务器发起 HTTP 请求并拉取资源的行为。

其他未明确定义的词汇和术语，请参阅 Internet 上的定义。

调查

技术细节

根据 Baidu Cloud 提供的信息，Baidu Cloud CDN 采用三层缓存架构。其中第一层为边缘服务器，第二层和第三层为中心源服务器。如果客户端请求的资源未命中第一层、第二层和第三层缓存，则由第三层中心源服务器向源服务器发起回源请求并拉取资源，后由第三层、第二层和第一层缓存，缓存策略和缓存驱逐策略是未明确定义的。

由于网络和成本优势，源服务器由 Tencent COS （ Tencent Cloud 提供的对象存储服务）提供。如果第三层中心源服务器请求的资源未命中 Tencent COS，则由 Tencent COS 向上游源服务器发起回源请求并拉取资源，后遵循对象生命周期策略进行存储。通常情况下，新的静态资源会主动推送到 Tencent COS 进行存储。

边缘服务器和中心源服务器之间通过公网建立连接，中心源服务器和源服务器通过公网建立连接，中心源服务器和源服务器均接入 BGP （ Border Gateway Protocol 的缩写）多线网络。

客户端和边缘服务器之间通过公网建立连接，采用基于 TCP/IP 的 TLS 1.3 和 HTTP/2 协议通信。中心源服务器（第三层）和源服务器之间采用基于 TCP/IP 的 TLS 1.2 和 HTTP/1.1 协议通信。

在调查过程中涉及的边缘服务器位于中国-河南省-洛阳市，ISP （ Internet Service Provider 的缩写）为中国电信。中心源服务器（第三层）位于中国-山东省-青岛市，回源路由选择 ISP 为中国电信。源服务器位于中国-北京。

更多相关细节由于 Baidu Cloud 认为涉及商业机密（根据商业保密协议和公司内部安全规定），故而没有提供。

发生了什么

在下文中我们将按照事情发生的先后次序讲述，时区均为 Asia/Shanghai 。

2020/8/30

工程团队发现现网某外部静态资源请求的 TTFB 增大至 1.2 秒左右，通过检查响应该请求的服务器 IP 地址和响应头部确定边缘服务器由 Baidu Cloud CDN 提供。进一步分析发现，当一个分段请求未命中缓存时可复现该问题。如果一个请求未命中缓存，那么流量将回到缓存服务器背后（上游）的源服务器，因此初步怀疑回源过程中可能存在问题。为快速排除源服务器可能存在的问题，工程团队即刻检查了监控台相关指标数据，但没有迹象表明源服务器工作异常。为进一步验证这些数据的正确性，工程团队使用内部 Analysis & Diagnosis 平台手动诊断源服务器的工作状况，其诊断过程包括从内部和外部向源服务器直接发送数个分段请求、等待响应和下载数据，诊断结果显示 TTFB 浮动于 88 ~ 110 毫秒之间，没有发现问题。

由于我们无法确定问题究竟发生在回源过程中的哪一个阶段，所以便通过 Baidu Cloud 工单系统向 Baidu Cloud CDN 团队提单询问回源流程、边缘服务器和中心源服务器的网络接入情况，以便于进一步定位问题原因。

2020/8/31

次日，我们收到 Baidu Cloud 工作人员在工单内提供的一些基本信息，并表示对于该问题乐意提供分析协助。为便于双方沟通和分析问题原因，工程团队在 Baidu Cloud CDN 发布了一个测试域名，并将其源服务器配置为在 Tencent COS 发布的测试 Bucket （对象存储桶），其中包含一个大小约 4.7 MB 的测试音频文件。为便于分析定位回源过程中潜在的问题，测试域名被配置为不缓存任何静态资源。

准备就绪后，我们通过 Baidu Cloud 工单系统在工单内进一步提供了工程团队的初步调查结论、复现方式和测试数据。值得一提的是，从客户端向测试域名发起的一个分段请求的 TTFB 增大至 1.4 秒，这可能是由于网络波动所致。

大约 3 个小时后，我们收到 Baidu Cloud CDN 团队在工单内提供的分析回复，称 TLS 协议的性能损耗和未配置缓存导致回源链路较长是造成该问题的原因，对此我们并不认同。首先 Baidu Cloud CDN 团队应该了解测试域名没有配置缓存的原因，其次全链路 TLS 协议的性能损耗（包括但不限于：握手和加解密数据等）理论上不应该如此之大，很显然这不是一个负责任的回复。

Baidu Cloud 工作人员在工单内收到我们的反驳回复后，称会再次向 Baidu Cloud CDN 团队核实该问题是否符合预期。

2020/9/1

次日，我们收到 Baidu Cloud CDN 团队产品经理在工单内的回复，称该问题是符合预期的，并认为未配置缓存是造成该问题的原因，单个例子无法体现问题。很显然这依旧不是一个负责任的回复，甚至怀疑 Baidu Cloud CDN 团队是否有就该问题进行过分析，我们对此感到非常失望。

为了进一步体现在该问题上 Baidu Cloud CDN 产品与其他服务提供商的差距，工程团队在其他上游 CDN 服务提供商（包括但不限于：Tencent Cloud 、Alibaba Cloud 和 Upyun 等）上发布了相同的测试域名和配置，然后进行了数个对比测试。结果显示在相同的测试方式下，到其他上游 CDN 服务提供商的分段请求的 TTFB 常见浮动于 270 毫秒左右，最低为 161 毫秒，最高为 297 毫秒。值得注意的是，上游 CDN 服务提供商之间的架构不同，因此对比测试的结果仅用于反应在一个或多个场景限定下的差距。

值得一提的是，当我们通过 Baidu Cloud 工单系统在工单内向 Baidu Cloud CDN 团队请求获取更多有关该问题和证明其观点的关键数据（包括但不限于：边缘服务器、中心源服务器和源服务器之间通信链路的延时、路由、丢包率和各流程耗时等）时没有得到任何回复。为进一步推动调查，无奈之下我们于次日通过 Baidu Cloud 提供的投诉渠道提交了有关投诉。

2020/9/3

令人高兴的是，这一举动似乎正在改变我们与 Baidu Cloud CDN 团队的沟通效率。在提交有关投诉后，我们于次日（ 9 月 3 日）接到了 Baidu Cloud 客户经理的来电，并就相关问题进行沟通协调。

大约一个小时后，我们收到 Baidu Cloud CDN 团队在工单内提供的测试数据和观点，其中包括但不限于从 Baidu Cloud CDN 中心源服务器（第三层）到源服务器的网络连通情况、DNS 调度结果、链路延时（ ICMPv4 ）、链路路由和使用 CURL 直接请求源服务器的连接、响应和用时情况（用户态、内核态和子进程）等。

工程团队立即对 Baidu Cloud CDN 团队提供的数据进行检查。Baidu Cloud CDN 团队认为源服务器响应用时过长是造成该问题的原因，因为从用时情况来看 CURL 进程的生命周期约 1.39 秒（包括但不限于等待 I/O 操作完成等）。进一步检查后发现，Baidu Cloud CDN 团队使用 CURL 从中心源服务器（第三层）向源服务器发起的 HTTP 请求不是分段请求，这意味着还额外包括完整的内容下载用时。

值得注意的是，1.39 秒内包括但不限于：DNS 解析查询、建立 TCP/IP 连接、TLS 握手、发送 HTTP 请求、等待 HTTP 响应头和下载 HTTP 响应内容等流程的用时。我们不认可 Baidu Cloud CDN 团队的观点，因为这些数据不能排除源服务器存在问题，也无法证明源服务器没有问题，在数据不足的情况下将 CURL 进程生命周期时间当作源服务器的响应用时未免有些牵强。

为获取从中心源服务器（第三层）到源服务器的 HTTP 请求的各个流程用时情况，工程团队通过 Baidu Cloud 工单系统在工单内请求 Baidu Cloud CDN 团队协助在中心源服务器（第三层）上重新执行带有给定参数的 CURL 命令行。给定的 CURL 命令行将向源服务器发送一个 HTTP 分段请求并下载内容的前 10 个字节，以测量 HTTP 请求的各个流程的用时情况。从 Baidu Cloud CDN 团队提供的给定 CURL 命令行的运行结果来看，从中心源服务器（第三层）到源服务器的 HTTP 请求 TTFB 为 236 ~ 395 毫秒，结果符合预期。

工程团队认为 Baidu Cloud CDN 的 Range 回源功能可能存在问题，无法以正确或最佳方式处理 HTTP 分段请求。边缘服务器或中心源服务器（第二层或第三层）在接收到源服务器的响应和响应内容后并未立即发送到上一层，其中的一层或多层可能存在策略缓冲逻辑。我们通过 Baidu Cloud 工单系统在工单内将这一观点告知于 Baidu Cloud CDN 团队。

Baidu Cloud CDN 团队在工单内收到我们的观点后通过电话与我们取得联系，Baidu Cloud CDN 团队的软件开发工程师认为我们的观点有误，并坚持认为该问题是由源服务器造成的。通过向 Baidu Cloud CDN 软件开发工程师核实，确认 Range 回源功能不包含策略缓冲逻辑，边缘服务器和中心源服务器在接收到源服务器的响应和响应内容后会即刻发送到上一层。

为进一步排除现有源服务器可能存在的问题，工程团队将测试域名的源服务器配置为在 BOS （ Baidu Cloud 对象存储服务）发布的测试 Bucket，其中包含的对象与现有 Bucket 一致。工程团队向测试域名发送了数个 HTTP 分段请求，然后等待响应和下载响应内容。测试结果相比预期更为严重，其 HTTP 分段请求的 TTFB 高达 1.57 ~ 2.17 秒。

令人失望的是，Baidu Cloud CDN 软件开发工程师依然坚持认为该问题是由源服务器造成的，理由是从客户端直接向源服务器发送数个 HTTP 请求，然后等待响应和下载响应内容的总用时为 3.3 ~ 3.6 秒，对此我们无法认同。僵持过后，Baidu Cloud CDN 软件开发工程师认为边缘服务器和中心源服务器（第二层和第三层）之间的公网链路较长是造成该问题的原因，因为:

从客户端向 BOS 发送一个 HTTP 请求、等待响应和下载响应内容总用时 1.18 秒。
从客户端向测试域名发送一个 HTTP 请求、等待响应和下载响应内容的总用时约 2.29 秒。

则边缘服务器和中心源服务器（第二层和第三层）之间的通信用时约 2.29 秒 - 1.18 秒 = 1.11 秒。这的确是有可能的，但是我们无法认同链路用时的计算方式。由于工程团队没有边缘服务器和中心源服务器或相关跟踪工具的直接访问权限，因此无法分析边缘服务器和中心源服务器之间的通信用时情况。

工程团队通过向测试域名首页发送数个 HTTP 请求、等待响应和下载响应内容以评估边缘服务器和中心源服务器的通信用时情况，从测试结果来看 TTFB 为 122 ~ 504 毫秒（常见于 250 毫秒左右），Baidu Cloud CDN 软件开发工程师的观点不成立。

Baidu Cloud CDN 团队未提供更多有关回复。

2020/9/7

数天后，我们收到 Baidu Cloud 工作人员在工单内的回复，称该问题正在进一步处理中。值得一提的是，Baidu Cloud 工作人员在向工单添加新回复的同时，将工单状态一并更改为待反馈状态。如果我们在有限时间内没有回复，该工单将被 Baidu Cloud 工单系统自动确认并关闭。在我们的追问之下，Baidu Cloud CDN 团队仍然声称该问题是符合预期的，更多技术细节由于安全规定无法对外提供。

最后，该工单被 Baidu Cloud 工作人员主动关闭。

调查结论

工程团队认为 Baidu Cloud CDN 边缘服务器和中心源服务器（第二层和第三层）可能没有正确处理 HTTP 分段请求，一个或多个回源流程可能存在问题。边缘服务器或中心源服务器（第二层或第三层）从源服务器接收到响应和响应内容后可能没有立即将其发送到上一层，其中一层或多层可能存在策略缓冲逻辑，造成当一个或多个 HTTP 分段请求未命中边缘服务器和中心源服务器（第二层和第三层）缓存并回源时 TTFB 增大至秒级。

边缘服务器和中心源服务器（第二层和第三层）之间的公网链路情况可能是进一步减轻或恶化该问题的原因之一，没有迹象表明源服务器是影响或造成该问题的原因之一。

总结

我们对 Baidu Cloud 调查和解决问题时的工作态度非常失望，自 2020 年以来也越发感觉 Baidu Cloud 工作态度和产品质量在不断下降。不可否认的是，如果一个静态资源已经缓存于边缘服务器或中心源服务器，则该问题在缓存驱逐前发生的可能性较低，但并不意味着问题不存在。

大家如何看待呢？