查看“︁上海｜中国移动｜家庭宽带｜Ultra Singapore｜含晚高峰与非晚高峰数据”︁的源代码

'''Welcome to ''md5.pw''!''' We hope you will contribute much and well. You will probably want to read the [[mediawikiwiki:Special:MyLanguage/Help:Contents|help pages]]. Again, welcome and have fun! [[User:Liam|Liam]]（[[User talk:Liam|留言]]） 2026年11月5日 (四) 07:57 (PST)

== 上海｜中国移动｜家庭宽带｜Ultra Singapore｜含晚高峰与非晚高峰数据 ==
本次使用上海中国移动宽带。

本轮单 TCP 连接下载平均吞吐为 '''191.29 Mbps'''，4 条并行 TCP 连接下载为 '''376.62 Mbps'''；独立 Ping 共 60 次，全部收到回复，平均往返延迟 '''102.10 ms'''。随后补测的去程 MTR 在第 20 跳到达测试机，目标地址 100 次探测均收到回复，平均 RTT 为 '''96.1 ms'''。5 分钟 SSH 心跳正常完成。

本轮四连接下载的吞吐高于单连接，但发送端同时记录到较多 TCP 重传。回程探测没有取得客户端出口的终点响应。下文保留了逐项结果、补测记录和测试条件，供相近接入环境的用户参考。

== 一、测试环境 ==
{| class="wikitable"
!项目
!本次环境
|-
|地区与运营商
|上海，中国移动
|-
|网络与接入方式
|宽带 Wi-Fi，无代理直连；未记录 Wi-Fi 频段与协商速率
|-
|宽带套餐
|下行 500 Mbps，上行未知；套餐速率由测试者提供
|-
|测试机来源与机房
|活动提供的 BandwagonHost Ultra Singapore 测试机
|-
|本地电脑与系统
|Apple Silicon，macOS 15.8.2
|-
|VPS 系统
|AlmaLinux 9.8，x86_64
|-
|VPS 基础配置
|2 vCPU，系统可见内存 2024 MiB；CPU 型号显示为 AMD EPYC-Genoa Processor
|-
|VPS TCP 拥塞控制
|环境日志记录为 BBR
|-
|Mac 工具版本
|iPerf3 3.22，MTR 0.96，Python 3.15.2
|-
|VPS 工具版本
|iPerf3 3.9，MTR 0.94，Python 3.9.25
|-
|测试工具包版本
|Mac 1.1.1，VPS 1.1.0
|-
|地址协议
|IPv4
|}
Mac 环境日志记录到系统 HTTP、HTTPS、SOCKS 代理均关闭，到 VPS 的路由接口为 <code>en0</code>。本次接入方式为测试者确认的移动宽带 Wi-Fi 直连。

== 二、测量时间与参数 ==
下表所列晚高峰测量时间均为 '''2026 年 11 月 13 日，UTC+8'''。不同项目分阶段采样，并非整个时间范围内的连续监控。非晚高峰 NQ / TQ 的准确采样时间留在第八节另行填写。
{| class="wikitable"
!项目
!实际采样时间
!参数
|-
|VPS 对客户端出口 Ping
|20:07:42～20:08:52
|60 次，约每秒一次
|-
|VPS 回程 MTR
|20:08:52～20:10:39
|IPv4 ICMP，100 周期
|-
|Mac 对 VPS Ping
|20:30:45～20:31:44
|60 次，约每秒一次
|-
|Mac 双向吞吐
|20:31:44～20:35:19
|单/4 连接分别上传、下载，每项 30 秒，各测 1 次，测试间休息 30 秒
|-
|SSH 心跳
|20:35:19～20:40:21
|60 条心跳，间隔约 5 秒，持续约 5 分钟
|-
|独立补测去程 MTR
|20:53:49～20:55:41
|IPv4 ICMP，100 周期
|}
单连接与 4 连接的'''合计目标速率上限均为 500 Mbps'''，其中 4 连接按每条 125 Mbps 设置。下载使用 iPerf3 反向模式；下文最终吞吐统一采用接收端合计平均速率。该上限是测试参数，不是实测得到的链路容量。

本报告按实际运行参数统计：独立 Ping 为 '''60 次'''，补测 MTR 为 '''100 周期'''，两组样本分别呈现。四项吞吐各测一次，因此表中数值是各自一次传输的平均吞吐，没有多轮中位数。

== 三、Ping 延迟与丢包 ==
Mac 到 VPS 的独立 Ping 结果如下：
{| class="wikitable"
!指标
!结果
|-
|发送 / 接收
|60 / 60
|-
|本次样本丢包率
|'''0%'''
|-
|最低 RTT
|80.65 ms
|-
|平均 RTT
|'''102.10 ms'''
|-
|最高 RTT
|147.88 ms
|-
|RTT 标准差
|13.39 ms
|-
|RTT P95
|126.30 ms
|}
P95 根据成功回复的逐包 RTT，以 nearest-rank 方法计算。本次约一分钟的采样未观察到 Ping 丢包，但 RTT 存在波动，最高值约 148 ms。这里的 0% 仅对应这 60 次 ICMP 探测，不代表整个晚高峰或 TCP 传输均无丢包。

VPS 对客户端公网出口的另一次 Ping 发送 60 次、收到 0 次回复。该现象可能与出口设备、NAT 或 ICMP 过滤有关，本轮无法确定原因，也不能将其直接等同于 Mac 到 VPS 的业务连接不可用。

== 四、单连接与多连接吞吐 ==
上传指 '''Mac → VPS'''，下载指 '''VPS → Mac'''。四项测试均正常结束。
{| class="wikitable"
!项目
!数据方向
!TCP 连接数
!测量时间，UTC+8
!接收端平均吞吐
!发送端 Retr
|-
|单连接上传
|Mac → VPS
|1
|20:31:44～20:32:15
|'''20.56 Mbps'''
|3,820
|-
|单连接下载
|VPS → Mac
|1
|20:32:45～20:33:16
|'''191.29 Mbps'''
|2
|-
|4 连接上传
|Mac → VPS
|4
|20:33:46～20:34:18
|'''25.68 Mbps'''
|2,179
|-
|4 连接下载
|VPS → Mac
|4
|20:34:48～20:35:19
|'''376.62 Mbps'''
|93,983
|}
本次 4 连接下载平均吞吐约为单连接的 '''1.97 倍'''。为查看传输后段的波动，另取开始 5 秒后的逐秒接收端记录：单连接下载约为 '''123.87～207.74 Mbps'''，4 连接约为 '''327.37～437.69 Mbps'''。这些区间描述一次传输内部的逐秒变化；上表平均吞吐仍采用完整测试时段，未剔除前 5 秒。

4 连接下载的发送端记录到 '''93,983 次 Retr'''。本文按 iPerf3 输出原样保留该计数，不将其换算为丢包率。不同项目的传输量、连接数和发送端也不同，不能仅按 Retr 总数直接比较链路优劣。这项结果值得在相同条件下复测，以确认较多重传是否重复出现。

上传平均吞吐约为 '''20～26 Mbps'''。套餐上行速率未知，本地又使用 Wi-Fi，暂时无法区分套餐限制、无线接入和跨境链路各自的影响。本轮也没有有线对照或国内测速基线，因此不直接用 500 Mbps 套餐下行与跨境应用层吞吐的差额来判断机房性能。

== 五、去程路由补测 ==
Mac 自动流程中的去程 MTR 因 sudo 认证失败而未取得数据，之后于 '''20:53:49～20:55:41''' 在终端前台独立补测。补测期间使用同一台 Mac、同一测试机，按原接入条件进行直连测试；原失败日志保留。

本次 MTR 在 '''第 20 跳到达目标 VPS'''，目标地址发送 100 次、收到 100 次回复：
{| class="wikitable"
!终点指标
!结果
|-
|终点丢包率
|'''0%'''
|-
|平均 RTT
|'''96.1 ms'''
|-
|最低 / 最高 RTT
|79.0 / 117.5 ms
|-
|RTT 标准差
|10.3 ms
|}
逐跳记录如下，IP 已打码：
{| class="wikitable"
!跳数
!节点地址
!ICMP 未响应比例
!平均 RTT
|-
|1
|<code>172.20.*.*</code>
|0%
|4.3 ms
|-
|2
|未响应
|100%
|无数据
|-
|3
|<code>172.21.*.*</code>
|0%
|32.7 ms
|-
|4
|<code>10.11.*.*</code>
|0%
|28.9 ms
|-
|5
|未响应
|100%
|无数据
|-
|6
|<code>211.136.*.*</code>
|71%
|29.2 ms
|-
|7
|<code>183.194.*.*</code>
|20%
|33.1 ms
|-
|8
|<code>221.183.*.*</code>
|99%
|18.5 ms
|-
|9
|未响应
|100%
|无数据
|-
|10
|<code>221.183.*.*</code>
|0%
|57.9 ms
|-
|11
|<code>221.183.*.*</code>
|0%
|57.3 ms
|-
|12
|<code>221.183.*.*</code>
|0%
|56.9 ms
|-
|13
|<code>221.183.*.*</code>
|0%
|59.3 ms
|-
|14
|<code>223.120.*.*</code>
|0%
|95.1 ms
|-
|15
|<code>223.120.*.*</code>
|0%
|95.5 ms
|-
|16
|<code>223.120.*.*</code>
|0%
|93.7 ms
|-
|17
|未响应
|100%
|无数据
|-
|18
|未响应
|100%
|无数据
|-
|19
|<code>142.0.*.*</code>
|0%
|90.2 ms
|-
|20
|<code>185.180.*.*</code>
|0%
|96.1 ms
|}
部分中间节点显示较高未响应比例或完全不回应，但后续节点与目标地址均能正常回复。因此，第 6 跳的 71%、第 8 跳的 99% 不能解释为整条链路同等比例的业务丢包；这些现象可能与路由器的 ICMP 响应策略或限速有关。

这次补测在目标端未观察到 ICMP 探测丢包。MTR 的 96.1 ms 与此前独立 Ping 的 102.10 ms 来自不同采样窗口，差异不足以说明线路变快。本文也不依据 IP 地址或地理标签认定物理绕行及具体线路产品。

== 六、回程路由 ==
VPS 回程 MTR 于 '''20:08:52～20:10:39''' 采集，共 100 周期。它比 Mac 吞吐测试早约 20 分钟，也早于去程补测，两端路径并非同步观测。

逐跳记录如下，IP 已打码：
{| class="wikitable"
!跳数
!节点地址
!ICMP 未响应比例
!平均 RTT
|-
|1
|<code>10.39.*.*</code>
|0%
|19.3 ms
|-
|2
|<code>10.39.*.*</code>
|0%
|0.6 ms
|-
|3
|<code>142.0.*.*</code>
|0%
|1.0 ms
|-
|4
|<code>203.144.*.*</code>
|0%
|1.9 ms
|-
|5
|<code>69.194.*.*</code>
|0%
|1.1 ms
|-
|6
|<code>69.194.*.*</code>
|0%
|4.2 ms
|-
|7
|<code>203.22.*.*</code>
|56%
|39.1 ms
|-
|8
|<code>59.43.*.*</code>
|56%
|40.6 ms
|-
|9
|<code>59.43.*.*</code>
|83%
|43.2 ms
|-
|10
|<code>202.97.*.*</code>
|95%
|44.1 ms
|-
|11
|<code>202.97.*.*</code>
|87%
|68.4 ms
|-
|12
|<code>202.97.*.*</code>
|97%
|69.9 ms
|-
|13
|<code>221.183.*.*</code>
|96%
|67.8 ms
|-
|14
|<code>221.183.*.*</code>
|93%
|63.6 ms
|-
|15
|<code>221.183.*.*</code>
|96%
|63.5 ms
|-
|16
|<code>183.194.*.*</code>
|99%
|68.3 ms
|-
|17
|未响应
|100%
|无数据
|}
回程探测可见上述响应节点，但'''没有得到客户端出口的终点响应'''，因此不作为完整的端到端回程验证。中间跳的高未响应比例不能直接当成业务丢包率；部分节点只有少量回复，其 RTT 也不宜用于精细比较。本报告不据此认定完整回程线路产品。

== 七、SSH 与实际业务观察 ==
SSH 心跳测试于 '''20:35:19～20:40:21''' 执行，预期 60 条，实际收到 '''60 条'''，SSH 进程正常结束，未出现本轮会话中断。

本次约 5 分钟的流式 SSH 会话正常完成。心跳记录没有测量按键往返时延，也无法排除心跳之间的短暂延迟。本轮未另行记录人工 SSH 交互、SFTP、网页浏览或视频播放体验，这些项目留待实际使用后补充。

== 八、非晚高峰 NQ / TQ 补充 ==
以下预留非晚高峰 NodeQuality 与 TcpQuality 报告的填写位置。两项报告的采样时间、测试节点和方法分别以对应报告为准，与前文上海移动本地晚高峰结果分开呈现。

=== 8.1 NodeQuality（NQ） ===

* 完整报告：[https://nodequality.com/r/5F9QQBwrANkBN8UKfFUgQbSq4DKF55cC NodeQuality 非晚高峰报告]

=== 8.2 TcpQuality（TQ） ===

* 完整报告：[https://tcpquality.ibsgss.uk/r/hilqFx86mU TcpQuality 非晚高峰报告]

== 九、数据完整性与局限 ==
本轮需要结合以下条件理解：

# 吞吐每项仅测一次，没有重复样本评估轮间波动。
# 本地使用 Wi-Fi，未记录频段、协商速率及有线对照；上行套餐速率未知。
# 各项目采样时间不同，去程与回程不是同步测量。
# 回程终点未响应，具体原因未确定。
# 本地直连 Ping、单 / 多连接吞吐和 SSH 仅有晚高峰数据。非晚高峰 NQ / TQ 作为补充材料，不能替代相同端点、接入方式和参数下的白天对照。
# 上述晚高峰本地测试流程未进行 IPv6、流媒体解锁、硬盘或 CPU 性能测试。若非晚高峰 NQ / TQ 包含这些项目，应在对应段落单独注明采样时间和方法。

== 十、晚高峰结论 ==
在本次'''上海中国移动、500 Mbps 下行宽带、Wi-Fi、IPv4 直连'''条件下，Ultra Singapore 的单连接下载平均吞吐约为 '''191 Mbps'''，4 连接约为 '''377 Mbps'''；上传约为 '''20～26 Mbps'''。独立 Ping 60 次均收到回复，平均 RTT 约 '''102 ms'''；随后补测的去程 MTR 在第 20 跳到达目标，100 周期终点无丢包，平均 RTT 约 '''96 ms'''。5 分钟 SSH 心跳正常完成。

这轮测试中，上海移动 Wi-Fi 接入能够完成到 Singapore 的直连传输和短时 SSH 会话，四连接下载平均吞吐约为单连接的 1.97 倍。四连接下载的较多重传、Wi-Fi 接入、单次测速及不完整的回程探测，也限制了对稳定性和瓶颈的判断。现有数据尚不能支持“跑满宽带”“晚高峰无拥堵”或“长期稳定”等结论。

== 十一、数据记录与公开链接 ==
晚高峰部分依据本次 Mac 测试、VPS 测试及独立去程 MTR 的原始日志整理，包括 Ping 逐包记录、iPerf3 原始 JSON 与逐秒记录、SSH 心跳、双向 MTR 和各自时间记录。此前中断的测试和 smoke 短测未并入本轮结果。非晚高峰 NQ / TQ 单独列示，不并入晚高峰统计。

* 活动原帖：[https://www.nodeseek.com/post-1031874-1 搬瓦工全国各地区网络测试报告征集]
* NodeSeek 评测帖链接：[https://www.nodeseek.com/post-1052095-1 【搬瓦工月付49.99刀新加坡vps测试】上海｜中国移动｜家庭宽带｜Ultra Singapore｜含晚高峰与非晚高峰数据]