比较日本云服务器与香港主机的海外站点延迟，应看RTT还是首字节时间？

海外站点的首页、商品查询和文件下载，对“延迟”的要求并不相同：打开首页要经历连接建立和页面渲染，商品查询可能等待数据库返回，下载文件则更受可用带宽影响。比较日本云服务器与香港主机，应该先测RTT判断网络往返成本，再用首字节时间（TTFB）判断网站响应；真正用于选型的，应是目标用户、代表页面和预期负载下的TTFB分布、错误率及完整业务耗时，而不是某一次Ping的数值。

日本与香港哪一边更低，没有脱离线路和应用的固定答案。面向香港及周边用户，香港主机值得优先纳入测试；面向日本本地用户，日本云服务器值得优先纳入测试。面向中国内地、东南亚、欧美或混合用户时，运营商互联、国际出口、CDN、服务器资源和数据库位置都可能改变结果。地理位置只能帮助确定候选，不能代替同口径验证。

一、测试目标：比较网络距离，还是比较站点体验

先把业务请求分成三类

产品评测不能只测试服务器地址，还要选择能代表站点负载的请求。

三类请求应该分别保留结果，不能把它们混成一个“平均延迟”。

小文件先返回首字节，并不代表大型图片加载快；动态页面TTFB较低，也不代表浏览器能更早完成渲染。对于以页面体验为目标的站点，还应补充浏览器侧的主要内容呈现时间，例如LCP。对于接口型业务，则应关注请求完成时间和成功率。

日本云服务器与香港主机要先统一产品口径

“云服务器”和“主机”不一定是同一种交付形态。日本云服务器通常可由用户管理操作系统和应用环境；香港主机可能是云主机，也可能是共享虚拟主机或托管环境。

如果一边可以调节进程、缓存和数据库，另一边受到固定PHP进程数、CPU配额或并发连接数限制，那么结果包含的是网络位置与产品资源共同造成的差异，不能全部归因于日本或香港。

评测应区分两个问题：

• 位置与线路比较：尽量保持应用、资源规格、缓存策略、响应内容和依赖布局一致。
• 实际购买方案比较：按相近预算或业务需求比较完整方案，允许资源不同，但必须列明差异。

前一种适合回答“哪条访问路径更快”；后一种适合回答“哪套产品更适合这个站点”。两者都有价值，但不能互相冒充。

二、指标含义：RTT解释网络，TTFB解释一次请求

RTT不是完整页面延迟

RTT是数据从测试端到目标端再返回所需的往返时间。常见Ping结果测量的是ICMP往返时间，它可以提示基础网络距离、抖动和部分丢包现象，但并不直接等于HTTPS访问耗时。

原因在于，网页请求还要经过域名解析、连接建立、TLS握手、请求发送和服务端处理。某些设备还会限制ICMP响应，使Ping的丢包或延迟与实际业务连接不一致。遇到ICMP结果异常，应结合TCP连接建立耗时、HTTPS请求和终点响应验证，不要只凭中间路由节点的丢包百分比判断线路故障。

RTT适合回答“网络一次往返要多久”，TTFB适合回答“用户多久能收到响应的第一个字节”。它们不是替代关系，而是定位问题时的不同层次。

TTFB包含哪些时间，要看测量边界

从请求开始计时的客户端TTFB，通常可以拆成：

域名解析 + 连接建立 + TLS握手 + 请求发送 + 网络传输 + 服务端排队与处理 + 首字节返回

这是一种分析框架，不是要求每一项都通过单独探测后相加。各工具的计时边界可能不同，现代协议也可能复用连接，因此比较前必须确认口径。

尤其要区分冷连接与复用连接：

• 冷连接TTFB：包含新建连接和握手成本，更接近部分首次访问场景。
• 复用连接TTFB：省去已完成的连接建立，更适合观察连续接口请求和同一会话中的页面请求。

同一站点可能冷连接TTFB差距较大，复用连接后差距缩小。这样的结果意味着网络握手成本比较突出，不等于服务器计算能力较差。

如果用户主要首次进入站点，冷连接结果更重要；如果业务是连续查询、操作后台或长会话，复用连接结果也必须纳入。

用一次HTTPS请求记录分阶段耗时

下面的示例适合在已授权的测试端执行。perf.example.com是占位域名，应替换为已经同时部署到两个候选环境、且证书有效的测试域名。203.0.113.10是文档示例地址，应替换为其中一个候选源站地址。

curl --http1.1 \
  --resolve perf.example.com:443:203.0.113.10 \
  --connect-timeout 5 \
  --max-time 15 \
  --silent --show-error \
  --output /dev/null \
  --write-out 'ip=%{remote_ip} code=%{http_code} dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total} bytes=%{size_download}\n' \
  'https://perf.example.com/test/static-small.txt'

该命令固定使用HTTP/1.1，不跟随重定向，也不跳过证书校验。替换目标IP后即可测试另一个环境；两端应返回相同内容和预期状态码。

这里的时间单位是秒，且多数时间字段是从请求开始计算的累计值：

• TCP建立阶段近似为time_connect - time_namelookup。
• TLS阶段近似为time_appconnect - time_connect。
• TLS完成到首字节到达的间隔为time_starttransfer - time_appconnect。
• 首字节之后的传输时间为time_total - time_starttransfer。

第三项仍包含请求发送、网络往返、服务器处理和首字节返回，不能直接标成“后端执行时间”。后端耗时需要应用日志或链路追踪确认。

使用--resolve绕过了正常DNS选址，因此这个结果主要用于源站对照。生产用户经过DNS和CDN的访问，还要另外测试真实域名路径。上述命令每次独立运行会建立新连接，也不能用于证明连接复用表现。

三、影响变量：地区之外，还要控制哪些条件

测试端的位置和运营商比测试平台名称更重要

一台海外测试机只能代表它所在网络，不能代表所有海外用户。同一城市的不同运营商，也可能采用不同跨境路径。

至少应覆盖主要用户地区，并在流量较大的地区加入不同运营商或不同接入网络。记录测试端城市、网络类型、运营商、IPv4或IPv6、测试时间及实际目标IP。移动网络与固定宽带最好分开统计，避免无线接入波动掩盖服务器差异。

对于面向中国内地用户的站点，还应按主要用户所在地区和运营商分层。某个探测点访问香港更快，只能支持该路径下的判断；不能直接外推为所有内地用户访问香港都更快。

IPv4与IPv6也应分别观察。若一端使用IPv4、另一端使用IPv6，测到的是地址族与线路共同造成的差异，而非纯粹的机房差异。

缓存、CDN和数据库必须进入测试记录

静态资源是否命中CDN，足以改变结果的含义。缓存命中时，用户主要访问边缘节点，源站位于日本还是香港对该次响应的影响可能很小；缓存未命中或动态请求回源时，源站位置才重新进入关键路径。

建议保留两套结果：

1. 真实用户路径：通过正式域名访问，保留实际DNS、CDN和缓存策略。
2. 源站对照路径：保持域名、证书和内容一致，直接比较两个源站。

不要把CDN命中与回源请求混在同一组TTFB中。响应大小、压缩方式、缓存命中状态、状态码和重定向次数都应一致或明确记录。

动态业务还要检查数据库、对象存储和外部接口的位置。如果应用迁到日本，数据库仍在香港，跨区域访问可能抵消前端网络收益。以一个解释性场景为例：关键路径上有8次无法并行的数据库往返，每次比同区域访问多45毫秒，那么新增等待约为：

8 × 45毫秒 = 360毫秒

这不是日本或香港的固有性能差异，而是应用依赖布局的结果。数据库连接池能减少建连开销，但不能消除每次查询的跨区域往返。

空载快，不代表业务高峰仍然快

CPU、内存和I/O通过服务端处理时间影响TTFB，而并发通过排队进一步放大差异。

云服务器中，整体CPU利用率不高也可能存在单核饱和；共享主机中，无法读取系统监控也不意味着没有资源限制。应向服务商确认可观察指标和产品配额，并在报告中保留不可见项，避免把资源限制造成的慢响应解释成线路绕行。

四、怎样采样与解释结果，才不会选错产品

采样要同时覆盖时间、用户网络和负载

短时测试适合排查明显异常，产品验收则需要覆盖正常时段与用户访问高峰。一个可执行的初步方案是连续观察3天，每天在主要用户的白天、晚间和业务高峰各设置测试窗口，按当地时间记录。

网络与轻量HTTP采样可以从每个探测点、每个窗口约200次请求起步。例如每5秒启动一次，窗口约17分钟；调度时不要让慢请求阻塞后续计划，也不要产生失控并发。两个候选环境应交替或配对测试，避免先测一边、过很久再测另一边。

每次请求至少记录时间、目标、响应码、TTFB、总耗时和成功或失败状态。超时不能作为零毫秒计入统计，也不能从报告里消失：成功请求的延迟与失败率应分别呈现。

空载探测与负载测试需要分开。持续的轻量探测用于观察线路，负载测试则应在授权范围内，按预期请求速率逐级增加，并明确停止条件，避免影响在线业务。

p50看常态，p95看尾部，还要看错误率

p50代表一半样本不慢于该值，适合观察常态体验；p95代表95%的样本不慢于该值，更适合发现高峰排队和网络抖动。

但样本数量必须与指标一起报告。只有几十次请求时，p95容易受到个别样本影响；几百次样本也不足以稳定描述极低概率故障。重要业务需要更多窗口和持续监测，而不是增加一个看似精确的小数位。

不同用户地区的结果不能简单平均。业务覆盖多个地区时，可按用户占比构造整体样本分布，但不能把各地区p95按权重平均后称为整体p95。还应保留各地区的独立结果，防止少数重要市场的较差体验被整体指标掩盖。

一个RTT更低、TTFB却更高的对照场景

以下数据仅为解释指标关系的示例：两个环境运行相同测试应用，从同一用户网络访问，保持相同请求速率、响应内容和缓存状态。

在这组示例中，香港路径的网络往返更短，但动态响应更慢，尾部延迟和失败率也更高。合理的解释不是“日本距离更近”，而是香港环境可能存在较大的后端处理或排队成本，需要进一步查看应用耗时、进程配额和数据库等待。

如果香港环境的TTFB在低负载下较低、增加请求后才显著上升，则应优先检查资源和并发上限；如果静态小文件的连接耗时也同步恶化，而服务端处理稳定，则应重点检查网络路径、重传和出口拥塞。

定位时可以按以下顺序判断：

1. RTT与连接耗时是否随TTFB一起变化？
2. 静态请求和动态请求是否一起变慢？
3. 应用日志中的处理耗时是否上升？
4. 变化是否集中在高峰、某个用户网络或某一地址族？
5. 首字节之后的传输阶段是否异常拉长？

这比直接按RTT排序更能解释产品差异。还要注意，各阶段的p95通常来自不同请求，不能相加得出总TTFB的p95；应优先分析同一条请求的阶段记录。

下载业务不能用TTFB代替吞吐

一个5MB文件即使在100毫秒内开始返回，也可能需要数秒才能下载完成。

按十进制口径，1MB等于1,000,000字节，5MB等于40Mb。若实际可用吞吐为10Mbps，仅正文传输的理论时间约为：

40Mb ÷ 10Mbps = 4秒

若可用吞吐为100Mbps，则约为0.4秒。实际结果还受到协议开销、拥塞控制、丢包和共享带宽影响，因此这只是下限估算。

对于图片站、软件下载和大文件分发，应同时比较持续吞吐、完成时间及多用户并发时的带宽分配。首字节更快的方案，不一定更早完成下载。

五、决策边界：怎样把测试结果变成选购与验收条件

按业务目标选择，而不是按地区标签选择

日本云服务器与香港主机的选择，可以落到以下条件：

如果两个候选在主要用户网络下的TTFB接近，接下来应比较资源余量、维护能力、备份、扩容和费用，而不是为几毫秒差距付出明显更高的运维成本。

成本也不应只看月租。云服务器可能涉及系统维护、备份、监控和独立数据库费用；托管主机可能包含部分维护，但存在进程、站点数、数据库容量或并发限制。出口带宽、流量计费、CDN和跨区域数据传输费用，应与同一业务负载一起比较。

验收应写成可重复的门槛

“访问很快”无法作为交付验收标准。更可执行的写法是明确用户网络、页面、负载、时间窗口、协议、缓存状态及错误处理方式。

例如，一个动态站点可以把“指定页面在目标用户网络、每秒5次请求、规定高峰窗口内，TTFB p95不超过500毫秒，请求失败率低于0.5%”设为测试门槛。这里的数字是示例，应依据业务容忍度调整；同时还需约定超时上限、连续达标窗口数量和大响应完成时间。

如果实际流量经过CDN，验收应包含真实用户路径；如果需要判断源站质量，还应保留源站对照。无法提供底层监控的主机产品，则可通过固定请求集、重复采样和服务商配额说明建立验收依据。

用排队趋势判断容量，并规定复测触发条件

容量判断应逐级增加请求速率，而不是一开始就堆高并发。观察吞吐是否继续增长、p95是否出现明显拐点，以及错误率是否上升。

在稳定运行、统计边界一致的条件下，可以用“平均在途请求数约等于每秒请求数乘以平均请求耗时”作粗略校验。例如每秒20次请求、平均耗时0.18秒，对应约3.6个在途请求；若平均耗时升到0.75秒，则约为15个。相同到达速率下，在途请求增多，可能说明请求开始积压。这里应使用平均耗时，不能用p95直接代替。

可用容量应取在延迟和错误率仍满足门槛的范围内，并为突发流量、后台任务和依赖波动留出余量。CPU低于某个固定百分比并不能单独证明容量充足，数据库连接池、单核性能、I/O或带宽可能先成为瓶颈。

当用户地区比例变化、线路或机房调整、CDN策略变更、数据库迁移、应用版本更新，或请求量明显增长时，应按原测试口径复测。若问题只出现在高峰，就在相同高峰窗口复测，而不是用白天的低负载结果覆盖它。最终应保留的不是“日本还是香港更快”的永久排名，而是一组能说明当前用户路径、业务负载和容量边界的可重复结果。