晚高峰实测香港服务器CN2与CMIN2，如何比较回程延迟与丢包？

平均延迟只有40毫秒，不代表香港服务器在晚高峰就能稳定响应。更值得关注的是：延迟的P95、P99是否明显抬升，丢包是否集中成串，单连接吞吐是否下降，以及这些变化有没有传导到页面加载、API响应和文件下载。比较CN2与CMIN2，如果只各执行一次Ping，再按平均值选线路，很容易把“空闲时延迟低”误认为“高峰时回程质量好”。

有效的比较应让两台香港服务器在相近配置、相同带宽和相同测试时段下，分别面向大陆电信、联通、移动探测点测试，并把香港到大陆的回程路径、双向往返延迟、目的端丢包和实际业务表现放在一起解释。CN2与CMIN2没有脱离用户运营商、地区和交付配置的固定胜负。下文给出可复测的方法，并用一组示例数据说明判断方式；示例数值用于解释机制，不代表A5IDC在售产品的实测结果。

一、测试目标：比较交付线路，而不是比较名称

香港服务器的网络体验由去程、回程和服务器处理能力共同决定。大陆用户访问香港服务器时，大陆到香港是去程，香港返回大陆是回程。两条路径可能不对称，去程经过某个网络，不代表回程也经过同一网络。

因此，测试目标需要分为两个层面：

• 网络层面：香港向目标用户运营商回传数据时，路径是否合理，高峰期是否出现排队、丢包和吞吐下降。
• 业务层面：在预期并发下，网络差异是否造成请求超时、下载降速或响应长尾，并排除CPU、内存、磁盘等因素。

CN2与CMIN2分别核对什么

CN2属于中国电信的网络体系，CMIN2属于中国移动的网络体系。但产品使用这些名称，不等于对三家运营商、所有地区和所有方向都采用同一种路径。

CN2 GT与CN2 GIA不能只凭“都叫CN2”视为相同交付。类似地，CMI与CMIN2也不能仅凭名称接近就混为一谈。询问线路时，应要求说明目标运营商、路由方向和测试IP，而不是只确认产品标签。

识别路由可结合IP归属与ASN。AS4809通常用于识别中国电信CN2网络，AS58807用于识别CMIN2相关网络；AS58453属于CMI相关网络，不能仅凭出现它就认定整条回程为CMIN2。CN2路由中常见的59.43地址同样只是识别线索，不能单独证明某个产品符合特定等级的交付。

线路名称用于建立候选，实际路径用于核对交付，业务指标用于判断是否适合。三者不能相互替代。

测试对象应贴近用户分布

如果业务主要面向广东移动用户，仅用北京电信探测点比较，结果很难支持采购决定。建议按实际用户来源配置探测点：

• 覆盖电信、联通、移动，不用一台大陆云服务器代表全部运营商。
• 覆盖主要用户地区，至少包含流量集中的省份或城市。
• 固定探测点的接入方式，避免一条线路用有线宽带、另一条用无线网络。
• 优先使用可控探测点；公共测试节点可补充观察，但要记录其出口与负载情况。

家用宽带的接入网络更接近终端用户，但可能受本地无线网络、家庭设备抢占和运营商NAT影响。云服务器探测点更容易持续监测，却不一定代表住宅宽带路径。两者可以互补，不能不加区分地合并。

二、指标含义：回程路由、RTT与单向延迟不是一回事

Ping与MTR测到的是往返时间

从香港服务器向大陆探测点执行Ping，可以观察响应往返时间；执行MTR或Traceroute，可以观察探测报文在香港到大陆方向经过的节点。

但每一跳的RTT都包含探测报文发出去、响应报文返回来的时间。即使命令是在香港执行，也不能把结果直接称为“香港到大陆的单向延迟”。

更准确的记录方式是：

香港发起的回程方向路径探测，以及该探测对应的往返RTT。

如需严格测量单向延迟，需要两端具备足够精确的时钟同步，并记录报文发送、接收时间。普通采购验收通常不必做到这个层级，但必须避免把RTT除以二，当作已确认的回程单向延迟。

平均值看基本水平，分位数看长尾

例如，两条线路的P50分别为35毫秒和42毫秒，但前者晚高峰P99达到220毫秒，后者只有85毫秒。对于频繁交互的API，后者可能提供更平稳的体验；对于少量低频请求，7毫秒的基础差异则未必值得额外投入。

统计时还有一个容易忽略的问题：超时的探测没有RTT数值。如果只计算成功响应，丢包严重的线路也可能显示出不错的平均延迟。因此，延迟分位数必须和丢包率、超时数一起看。

中间节点丢包不等于业务丢包

MTR中的中间路由器可能限制ICMP响应，或者降低对自身探测报文的处理优先级，但仍正常转发业务数据。

若某一跳显示30%丢包，后续节点和目的端没有对应丢包，通常不能认定这条链路丢失了30%的业务流量。更值得调查的是：从某处开始，后续可响应节点和目的端持续出现相近损失，并且TCP重传或应用超时同步增加。

目的端本身也可能限制ICMP响应。因此，不能只看一张MTR截图下结论。应使用TCP探测、真实HTTPS请求和接收端统计相互验证。相邻节点RTT突然增加，也不能直接当作两节点之间的链路延迟，因为各节点响应报文的返回路径可能不同。

吞吐是延迟、丢包与窗口共同作用的结果

相同的100Mbps端口，不保证单连接都能跑到相近速度。较高RTT意味着发送端需要维持更多在途数据；发生丢包后，拥塞控制又可能降低发送速率。

以100Mbps、50毫秒RTT为例，带宽时延积约为：

100,000,000 bit/s × 0.05 s ÷ 8 = 625,000字节，约625kB，采用十进制口径。

这表示要充分利用链路，需要大约这个量级的在途数据，而不是只关注端口标称值。实际吞吐还受TCP窗口、拥塞控制、重传、接收端能力和限速策略影响。

若单连接只有45Mbps，四连接合计达到90Mbps，说明增加连接可能提高带宽利用率，但单用户单连接体验仍然存在差异。把多线程测速的90Mbps直接写成“下载速度90Mbps”，会掩盖这个问题。

三、影响变量：怎样让晚高峰比较可以复现

控制服务器与带宽条件

两台候选服务器应尽量使用相同CPU、内存和存储配置，并核对带宽属性。如果一台是独享100Mbps，另一台是共享端口，那么结果比较的是“线路与带宽资源的组合”，不能全部归因于CN2或CMIN2。

测试期间同步记录CPU使用率、单核占用、内存可用量、交换活动、磁盘延迟和网络接口吞吐。例如：

• 吞吐低，但某个CPU核心已接近满载，可能是加密或单线程处理瓶颈。
• 下载变慢，同时磁盘读取延迟显著上升，可能是测试文件读取受到限制。
• 并发增加后出现交换活动，响应长尾可能主要来自内存压力。
• 业务延迟明显增加，但独立网络探测保持稳定，应先检查应用和后端服务。

测试大文件时，可使用两台服务器上相同的固定文件，并注明是否命中文件缓存。动态API则应使用相同程序、相同数据规模和相同后端条件。

固定时段，同时观察高峰前后

可将北京时间19:00—23:00设为晚高峰观察窗口，同时保留白天或凌晨的对照窗口。这个时间范围只是测试安排，具体拥塞起止仍以曲线为准。

建议连续观察至少三个普通工作日晚间，并补充周末或业务峰值日。每个探测点可以每秒采样一次，按5分钟或30分钟窗口统计。

每秒一次、连续30分钟，约有1800个样本。但丢包不一定相互独立：18次失败均匀分散，与连续18秒没有响应，虽然都约为1%，业务影响却不同。因此还应保存最长连续失败次数、短时丢包峰值和异常发生时间。

不要把多个城市的P95直接平均成“全国P95”。应先分别报告城市与运营商结果；确实需要总体指标时，应明确样本合并方式或业务权重。

用少量命令验证方向与应用表现

在香港服务器上，对可控的大陆探测点执行路径与连续采样：

# 在香港服务器执行，替换为允许测试的大陆探测点公网IP
MAINLAND_IP="替换为大陆探测点公网IP"

ping -n -c 1800 -i 1 "$MAINLAND_IP"
mtr -4 -n -r -w -c 100 -i 1 "$MAINLAND_IP"

大陆探测点需要允许对应响应。住宅宽带处于运营商NAT后方时，不能默认香港服务器能够直接探测到终端，应使用可达且获授权的探测点，并说明其代表范围。

若对端提供可用的HTTPS服务，可以补充TCP路径探测：

# 对端需监听TCP 443；部分系统需要相应网络探测权限
mtr -4 -n -r -w -c 100 -i 1 -T -P 443 "$MAINLAND_IP"

TCP探测与ICMP探测可能因策略或负载分担出现不同结果，仍需业务请求验证。在大陆探测点请求香港服务器上的固定HTTPS资源：

curl -sS -o /dev/null \
  --connect-timeout 5 \
  --max-time 15 \
  -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total} code=%{http_code}\n' \
  "https://替换为测试域名/固定测试资源"

这些时间是从请求开始累计的阶段时间。比较TCP建连耗时，可看connect减去dns；TLS阶段可看tls减去connect，不能将累计值全部相加。

持续采样时，要保存请求退出状态和HTTP状态码。返回200不一定代表业务成功，接口还需按自身业务字段判断。

吞吐测试不要污染延迟基线

在香港端运行获授权的iperf3服务后，大陆客户端可使用反向模式，让香港向大陆发送数据：

# 在大陆探测点执行；香港端需已提供获授权的iperf3服务
HONGKONG_IP="替换为香港服务器公网IP"

iperf3 -c "$HONGKONG_IP" -R -t 20 -P 1
iperf3 -c "$HONGKONG_IP" -R -t 20 -P 4

这里的-R反转数据发送方向，但TCP确认报文仍经过大陆到香港路径，所以吞吐依然受到双向网络影响。结果应以接收端有效吞吐为主要口径，分别记录单连接和四连接表现。

满速测试会占用带宽并消耗流量额度。应在获授权的测试实例或维护窗口执行，避免影响生产服务。延迟基线测试与满速吞吐测试最好分开；若要观察“带载时延迟”，则应明确负载大小，并让两条线路接受相同负载。

四、结果解释：把路由证据、网络数据与业务数据串起来

下面是一组用于说明判断方法的示例。两台香港服务器均配置100Mbps端口、2核CPU、4GB内存，使用相同测试文件；表中RTT和丢包来自香港发起的探测，吞吐为香港向大陆发送数据的单连接接收端结果。

示例延迟窗口为20:30—21:00，每个探测点发送1800次探测；吞吐在同一高峰时段另行测试，避免与延迟基线互相干扰。

这些数据不支持“CN2全面更好”或“CMIN2全面更好”，而是支持按目标用户条件判断。

电信方向：差距不只在8毫秒中位数

广州电信示例中，CN2的P50比CMIN2低8毫秒，但更值得注意的是P99、丢包和单连接吞吐同时更好。

如果HTTPS响应长尾也同步改善，服务器资源又有余量，就可以认为网络差异具有业务意义。反之，如果只有ICMP丢包差异，TCP请求和吞吐均无对应变化，则应继续检查探测限速，不能直接认定CMIN2业务回程较差。

路由记录在这里用于补充解释：异常期间是否改变了出口，是否增加互联节点，是否出现持续的目的端损失。它不应替代业务数据。

联通方向：小差异需要跨日复核

上海联通示例中，两种线路差距较小。0.33%与0.17%分别对应6次、3次未响应，单个半小时窗口很难据此形成稳定采购判断。

若多日相同时段持续出现同方向差异，且业务请求也有对应变化，结论才更有说服力。否则应将其视为接近，再比较费用、容量和交付条件，而不是给线路强行排出名次。

移动方向：关注长尾和连续失败

杭州移动示例中，CMIN2不仅中位数较低，P99和单连接吞吐也明显更好。如果业务用户主要来自该地区移动网络，这组差异更有决策价值。

但仍需区分21次未响应是分散发生，还是形成连续中断。少量分散损失可能被TCP重传吸收；连续失败更容易触发请求超时、重试放大和会话中断。

如果移动用户占70%、电信占20%、联通占10%，应优先改善主要用户群的高峰体验，但不能把三组P95按比例相加，称作整体P95。合理做法是按用户占比组织业务请求样本，再从合并样本计算总体响应分位数。

回程质量如何影响并发容量

网络延迟增加，会让请求和连接占用资源更久。用一个简化估算：业务每秒到达200个请求，平均完成时间为0.2秒时，平均在途请求约为40个；完成时间增加到0.5秒时，在途请求约为100个。

这不是工作进程数量的直接配置公式，但能说明为什么网络排队会增加连接数、缓冲区和内存占用。若连接池或并发上限接近边界，还可能进一步放大业务等待。

另一方面，CPU已经接近饱和时，即使更换线路，也可能无法改善服务端处理长尾。比较时应把请求时间拆为网络阶段和应用处理阶段，避免把全部收益或损失归到回程线路。

带宽容量也要独立计算。若每个响应平均传输200kB，持续每秒完成40个响应，则有效载荷约为：

200,000字节 × 40次/秒 × 8 = 64Mbps。

这里使用十进制kB，尚未计入协议开销、重传和其他业务流量。对100Mbps端口而言，已不能只按“还有36Mbps”判断峰值余量。若带载测试发现吞吐超过70Mbps后P95显著抬升，就应按实测拐点规划容量，而不是等待端口跑满。

面向大陆用户访问的企业网站和接口服务，A5数据提供香港物理服务器，产品涵盖CN2线路与国际带宽方案，并配有Xeon Gold、AMD EPYC等计算平台及SSD、NVMe存储。多档CPU、内存与带宽资源，为业务后台、数据库缓存和并发请求处理提供部署基础，也为不同业务规模下的计算、存储与网络容量配置提供更多组合空间。

五、决策边界：按目标用户验收，按负载拐点扩容

什么条件下倾向CN2或CMIN2

倾向CN2的条件：主要用户来自电信，交付明确覆盖相关回程，且连续晚高峰测试显示其目的端损失、延迟长尾和业务错误率更低。对于联通、移动用户，仍需独立验证，不能沿用电信方向的结论。

倾向CMIN2的条件：主要用户来自移动，目标地区测试显示其回程路径与晚高峰表现符合要求，同时电信、联通用户的体验没有越过业务可接受边界。

若用户分布混合，应优先比较业务请求成功率和长尾，而不是只比较全体平均Ping。对于文件下载服务，单连接持续吞吐更重要；对于API、登录和交互页面，响应P95/P99、超时与重试更重要。

如果两条线路在目标地区表现接近，费用差异应与可量化收益对应。升级减少了多少超时、能否推迟带宽扩容、是否降低高峰重试负载，都比“线路名称更高级”更有采购意义。低流量静态站点若主要通过CDN交付，源站直连指标与终端体验的关系也会减弱，应另测回源方向。

交付验收应写到具体方向

询价和验收时，建议把以下内容记录下来：

1. 资源与计费：CPU、内存、存储、带宽上限、独享或共享属性、限速方向、流量额度，以及超额或升级费用。
2. 覆盖与路径：哪些运营商、哪些地区、IPv4还是IPv6、去程还是回程属于交付范围。
3. 测试口径：指定探测点、时段、采样间隔、协议、目标端口，以及异常样本处理方式。
4. 业务门槛：目标请求成功率、响应分位数、单连接吞吐及预期并发下的资源余量。
5. 异常处理：是否支持排查出口、调整路由或更换IP，以及处理过程中是否需要迁移业务。

验收门槛应来自业务需求，不宜直接照搬某个示例中的毫秒数或丢包率。对于中间节点不响应、目的端限制探测和探测点自身异常，也应事先约定复核方法。

同一产品名称下，不同IP段、机房出口和交付批次也可能有差异。测试IP只能说明该测试入口的表现，正式交付后还应复测，不能把购买前的一次测速视为长期保证。

哪些变化需要复测，什么时候应该扩容

服务器迁移机房、更换IP、调整出口、升级带宽或改动限速策略后，应重新核对路径和指标。用户运营商占比变化、活动峰值增加，或出现“白天正常、晚间超时”的规律，也值得启动复测。

容量判断可以按三个负载档位进行：当前常态负载、预期高峰负载、略高于高峰的压力负载。每个档位同时记录吞吐、响应P95/P99、错误率、CPU、内存和磁盘延迟。

如果网络吞吐趋于平台，延迟持续上升，而CPU与I/O仍有余量，应重点评估带宽或路径拥塞；如果网络探测稳定，但应用响应随CPU、磁盘负载恶化，应先处理服务器或应用瓶颈。扩容依据应是可重复出现的性能拐点，而不是端口利用率达到某个孤立数字。

下一轮复测继续使用相同探测点、相同采样间隔和相同业务资源，并保留原始日志。只有差异能够在目标用户、相近负载和多个晚高峰中重复出现，CN2与CMIN2的比较才真正具备采购和容量规划价值。