打开/关闭搜索
打开/关闭菜单
164
2.2K
144
5.5K
md5.pw
打开/关闭外观设置菜单
打开/关闭个人菜单
未登录
未登录用户的IP地址会在进行任意编辑后公开展示。

上海｜中国移动｜家庭宽带｜Ultra Singapore｜含晚高峰与非晚高峰数据：修订间差异

来自md5.pw
更多语言
更多操作
←上一编辑
可视化wikitext
Starlight​（留言 | 贡献）
4次编辑
无编辑摘要
Starlight​（留言 | 贡献）
4次编辑
无编辑摘要
 
第1行： 第1行：
'''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)
本次使用上海中国移动 500 Mbps 下行家庭宽带，通过 Wi-Fi 连接同一台 Mac，直连活动提供的同一台 BandwagonHost Ultra Singapore 测试机，分别记录 11 月 13 日晚高峰和 11 月 14 日白天的表现。报告由 Codex 辅助撰写。


== 上海｜中国移动｜家庭宽带｜Ultra Singapore｜含晚高峰与非晚高峰数据 ==
两轮单 TCP 连接下载平均吞吐分别为 '''191.29 Mbps''' 和 '''198.08 Mbps'''；四连接下载分别为 '''376.62 Mbps''' 和 '''472.73 Mbps'''，本次白天四连接下载高约 '''25.52%'''。两轮独立 Ping 的平均 RTT 均约 '''102 ms'''，各自样本内没有观察到 ICMP 丢包；两次约 5 分钟的 SSH 心跳也均正常完成。
本次使用上海中国移动宽带。


本轮单 TCP 连接下载平均吞吐为 '''191.29 Mbps'''，4 条并行 TCP 连接下载为 '''376.62 Mbps'''；独立 Ping 共 60 次，全部收到回复，平均往返延迟 '''102.10 ms'''。随后补测的去程 MTR 在第 20 跳到达测试机，目标地址 100 次探测均收到回复，平均 RTT 为 '''96.1 ms'''。5 分钟 SSH 心跳正常完成。
这次较大的差异出现在四连接下载，单连接下载和平均延迟接近。两轮各项吞吐各测一次、分属不同日期，Wi-Fi 状态等条件未严格控制，结论限于这两个测量窗口。原帖已附的 NQ / TQ 完整报告链接在第八节单独保留，不并入本地昼夜统计。


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


== 一、测试环境 ==
{| class="wikitable"
{| class="wikitable"
!项目
! 项目 !! 两轮本地测试环境
!本次环境
|-
|-
|地区与运营商
| 地区与运营商 || 上海，中国移动
|上海，中国移动
|-
|-
|网络与接入方式
| 网络与接入方式 || 同一条家庭宽带、同一台 Mac，经 Wi-Fi 无代理直连；未记录频段、协商速率与无线干扰
|宽带 Wi-Fi，无代理直连；未记录 Wi-Fi 频段与协商速率
|-
|-
|宽带套餐
| 宽带套餐 || 下行 500 Mbps，上行未知；套餐速率由测试者提供
|下行 500 Mbps，上行未知；套餐速率由测试者提供
|-
|-
|测试机来源与机房
| 测试机来源与机房 || 活动提供的 BandwagonHost Ultra Singapore 测试机，两轮为同一台 VPS
|活动提供的 BandwagonHost Ultra Singapore 测试机
|-
|-
|本地电脑与系统
| 本地电脑与系统 || Apple Silicon，macOS 15.8.2
|Apple Silicon，macOS 15.8.2
|-
|-
|VPS 系统
| VPS 系统 || AlmaLinux 9.8，x86_64
|AlmaLinux 9.8，x86_64
|-
|-
|VPS 基础配置
| VPS 基础配置 || 2 vCPU，系统可见内存 2024 MiB；CPU 型号显示为 AMD EPYC-Genoa Processor
|2 vCPU，系统可见内存 2024 MiB；CPU 型号显示为 AMD EPYC-Genoa Processor
|-
|-
|VPS TCP 拥塞控制
| VPS TCP 拥塞控制 || 两轮环境日志均记录为 BBR
|环境日志记录为 BBR
|-
|-
|Mac 工具版本
| Mac 工具版本 || iPerf3 3.22，MTR 0.96，Python 3.15.2
|iPerf3 3.22，MTR 0.96，Python 3.15.2
|-
|-
|VPS 工具版本
| VPS 工具版本 || iPerf3 3.9，MTR 0.94，Python 3.9.25
|iPerf3 3.9，MTR 0.94，Python 3.9.25
|-
|-
|测试工具包版本
| 测试工具包版本 || Mac 1.1.1，VPS 1.1.0
|Mac 1.1.1，VPS 1.1.0
|-
|-
|地址协议
| 地址协议 || IPv4
|IPv4
|}
|}
Mac 环境日志记录到系统 HTTP、HTTPS、SOCKS 代理均关闭，到 VPS 的路由接口为 <code>en0</code>。本次接入方式为测试者确认的移动宽带 Wi-Fi 直连。
 
两轮 Mac 环境记录到系统 HTTP、HTTPS、SOCKS 代理均关闭，到 VPS 的路由接口为 <code>en0</code>。家庭宽带 Wi-Fi 接入由测试者确认。白天 VPS 日志中的“移动网络”为备注误填，实际仍为同一条家庭宽带接入；本文说明该差异，保留原始日志。
 
宽带上行套餐速率未知。本次没有有线对照、国内测速基线，也未严格控制 Wi-Fi 瞬时状态、局域网其他流量和主机负载。


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


本报告按实际运行参数统计：独立 Ping 为 '''60 次'''，补测 MTR 为 '''100 周期'''，两组样本分别呈现。四项吞吐各测一次，因此表中数值是各自一次传输的平均吞吐，没有多轮中位数。
两轮 iPerf3 使用相同参数：单连接和四连接分别上传、下载，每项 30 秒，各测一次，测试之间休息约 30 秒。'''单连接与四连接的合计目标速率均为 500 Mbps'''，其中四连接按每条 125 Mbps 设置。下载使用反向模式，最终吞吐统一采用完整测试时段的接收端合计平均值。
 
500 Mbps 是测试目标速率参数，不是测得的链路容量。四项吞吐每轮都只有一次观测，本文不将其表述为多轮中位数。
 
两轮独立 Ping 的样本量分别为晚高峰 '''60 次'''、白天 '''100 次'''，均约每秒一次。去程 MTR 均在自动流程认证失败后独立补测，各为 '''100 周期'''；它们与独立 Ping 分别统计，不互相替代。两轮回程 MTR 也各为 100 周期，VPS 对客户端出口 Ping 各为 60 次。


== 三、Ping 延迟与丢包 ==
== 三、Ping 延迟与丢包 ==
Mac 到 VPS 的独立 Ping 结果如下：
 
{| class="wikitable"
! 指标 !! 晚高峰，11 月 13 日 !! 白天，11 月 14 日
|-
| 发送 / 接收 || 60 / 60 || 100 / 100
|-
| 本次样本丢包率 || 0% || 0%
|-
| 最低 RTT || 80.65 ms || 79.31 ms
|-
| 平均 RTT || 102.10 ms || 101.99 ms
|-
| 最高 RTT || 147.88 ms || 146.18 ms
|-
| RTT 标准差 || 13.39 ms || 13.70 ms
|-
| RTT P95 || 126.30 ms || 130.99 ms
|}
 
两轮平均 RTT 相差约 0.11 ms，所测窗口的平均延迟接近。白天 RTT 标准差为 13.70 ms、P95 为 130.99 ms，均略高于晚高峰的 13.39 ms 和 126.30 ms，没有呈现延迟各项指标一致改善的情况。
 
P95 沿用各轮逐包 RTT 的 nearest-rank 统计结果。两轮采样日期、时长和样本量不同，P95 与最大值只作描述性对照。这里的 0% 丢包分别对应 60 次、100 次本地 ICMP 探测，不代表整个白天或晚高峰，也不能扩展为 TCP 业务零丢包。
 
VPS 对客户端公网出口的另两次 Ping 均发送 60 次、收到 0 次回复。该方向的 ICMP 探测与本地 Ping 分开记录；NAT、出口设备或 ICMP 过滤都可能影响响应，具体原因未确定。双向 TCP 传输在两轮均可完成，不能据出口 Ping 不回复直接认定业务不可用。
 
== 四、单连接、多连接吞吐与昼夜对比 ==
 
上传指 '''Mac → VPS'''，下载指 '''VPS → Mac'''。两轮共八项传输均正常结束。以下时间均为对应日期的 UTC+8。
 
=== 4.1 晚高峰：2026 年 11 月 13 日 ===
 
{| class="wikitable"
{| 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
|60 / 60
|-
|-
|本次样本丢包率
| 4 连接上传 || Mac → VPS || 4 || 20:33:46～20:34:18 || '''25.68 Mbps''' || 2,179
|'''0%'''
|-
|-
|最低 RTT
| 4 连接下载 || VPS → Mac || 4 || 20:34:48～20:35:19 || '''376.62 Mbps''' || 93,983
|80.65 ms
|}
 
=== 4.2 白天：2026 年 11 月 14 日 ===
 
{| class="wikitable"
! 项目 !! 数据方向 !! TCP 连接数 !! 白天测量时间，UTC+8 !! 接收端平均吞吐 !! 发送端 Retr
|-
|-
|平均 RTT
| 单连接上传 || Mac → VPS || 1 || 13:56:32～13:57:04 || '''22.34 Mbps''' || 1,688
|'''102.10 ms'''
|-
|-
|最高 RTT
| 单连接下载 || VPS → Mac || 1 || 13:57:34～13:58:04 || '''198.08 Mbps''' || 4
|147.88 ms
|-
|-
|RTT 标准差
| 4 连接上传 || Mac → VPS || 4 || 13:58:34～13:59:06 || '''23.53 Mbps''' || 2,083
|13.39 ms
|-
|-
|RTT P95
| 4 连接下载 || VPS → Mac || 4 || 13:59:36～14:00:07 || '''472.73 Mbps''' || 2,202
|126.30 ms
|}
|}
P95 根据成功回复的逐包 RTT，以 nearest-rank 方法计算。本次约一分钟的采样未观察到 Ping 丢包，但 RTT 存在波动，最高值约 148 ms。这里的 0% 仅对应这 60 次 ICMP 探测，不代表整个晚高峰或 TCP 传输均无丢包。


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


== 四、单连接与多连接吞吐 ==
上传指 '''Mac → VPS'''，下载指 '''VPS → Mac'''。四项测试均正常结束。
{| class="wikitable"
{| class="wikitable"
!项目
! 项目 !! 晚高峰平均吞吐 !! 白天平均吞吐 !! 白天较晚高峰差值 !! 白天相对晚高峰变化
!数据方向
!TCP 连接数
!测量时间，UTC+8
!接收端平均吞吐
!发送端 Retr
|-
|-
|单连接上传
| 单连接上传 || 20.56 Mbps || 22.34 Mbps || +1.78 Mbps || +8.66%
|Mac → VPS
|1
|20:31:44～20:32:15
|'''20.56 Mbps'''
|3,820
|-
|-
|单连接下载
| 单连接下载 || 191.29 Mbps || 198.08 Mbps || +6.79 Mbps || +3.55%
|VPS → Mac
|1
|20:32:45～20:33:16
|'''191.29 Mbps'''
|2
|-
|-
|4 连接上传
| 四连接上传 || 25.68 Mbps || 23.53 Mbps || -2.15 Mbps || -8.37%
|Mac → VPS
|4
|20:33:46～20:34:18
|'''25.68 Mbps'''
|2,179
|-
|-
|4 连接下载
| 四连接下载 || 376.62 Mbps || 472.73 Mbps || +96.11 Mbps || +25.52%
|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 总数直接比较链路优劣。这项结果值得在相同条件下复测，以确认较多重传是否重复出现。
相对变化按表内保留两位小数的数值计算：<code>（白天 ÷ 晚高峰 - 1）× 100%</code>。若采用未舍入原始值，末位可能略有差别。
 
本次最明显的变化是四连接下载，由 376.62 提高到 472.73 Mbps，增加约 96.11 Mbps，白天相对晚高峰高约 25.52%。单连接下载只增加约 6.79 Mbps，即 3.55%。两轮四连接与单连接下载的比值分别约为 '''1.97 倍'''、'''2.39 倍'''。


上传平均吞吐约为 '''20～26 Mbps'''。套餐上行速率未知，本地又使用 Wi-Fi，暂时无法区分套餐限制、无线接入和跨境链路各自的影响。本轮也没有有线对照或国内测速基线，因此不直接用 500 Mbps 套餐下行与跨境应用层吞吐的差额来判断机房性能。
白天四连接下载已接近设置的 500 Mbps 合计目标速率，说明该参数下取得了较高吞吐。由于目标速率本身有限制，且缺少有线或国内测速基线，本轮没有测出更高目标速率下的链路容量，也不直接以跨境应用层吞吐判定套餐下行是否“跑满”。
 
上传没有呈现一致的昼夜变化：单连接白天略高，四连接白天略低，两轮约为 '''20～26 Mbps'''。上行套餐速率未知，现有数据无法区分套餐限制、无线接入和跨境链路各自的影响。
 
白天四项接收端记录的有效净荷合计约 '''2.69 GB'''。该数值不等同于网卡总流量或 VPS 计费流量，协议与重传开销另计。
 
=== 4.4 发送端重传 ===
 
{| class="wikitable"
! 项目 !! 晚高峰发送端 Retr !! 白天发送端 Retr
|-
| 单连接上传 || 3,820 || 1,688
|-
| 单连接下载 || 2 || 4
|-
| 四连接上传 || 2,179 || 2,083
|-
| 四连接下载 || 93,983 || 2,202
|}
 
两次四连接下载的发送端分别记录到 '''93,983''' 和 '''2,202''' 次 Retr。白天在取得更高平均吞吐的同时，记录到的重传总数较少，这个组合值得在相同条件下继续复测。
 
表中是 iPerf3 输出的原始计数，没有换算为重传率或丢包率。实际传输量、连接数及运行状态都会影响总计数，不能仅凭 Retr 总数确定重传位置或认定晚高峰拥堵。
 
=== 4.5 一次传输内部的逐秒波动 ===
 
为查看传输后段，另列开始 5 秒后的逐秒接收端速率范围：
 
{| class="wikitable"
! 下载项目 !! 晚高峰逐秒范围 !! 白天逐秒范围
|-
| 单连接 || 123.87～207.74 Mbps || 127.92～221.38 Mbps
|-
| 四连接 || 327.37～437.69 Mbps || 330.89～559.84 Mbps
|}
 
这些区间是单次传输内部的逐秒变化，不是多轮测速结果范围。上面的平均吞吐仍采用完整测试时段，没有剔除前 5 秒。白天四连接的 559.84 Mbps 接收端逐秒峰值不代表持续容量；目标发送速率也不保证每个接收端统计窗口均不超过该值。


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


本次 MTR 在 '''第 20 跳到达目标 VPS'''，目标地址发送 100 次、收到 100 次回复：
两轮自动去程 MTR 均因 sudo 认证失败而未取得结果，之后在终端前台独立补测。原失败日志保留，补测数据按自己的时间记录，不写回自动流程的失败时段。
 
两轮补测都在第 20 跳到达同一台目标 VPS，终点各 100 次探测均收到回复。
 
{| class="wikitable"
{| class="wikitable"
!终点指标
! 去程 MTR 终点指标 !! 晚高峰补测 !! 白天补测
!结果
|-
| 到达目标的跳数 || 第 20 跳 || 第 20 跳
|-
| 终点发送 / 接收 || 100 / 100 || 100 / 100
|-
|-
|终点丢包率
| 终点样本丢包率 || 0% || 0%
|'''0%'''
|-
|-
|平均 RTT
| 平均 RTT || 96.1 ms || 95.4 ms
|'''96.1 ms'''
|-
|-
|最低 / 最高 RTT
| 最低 / 最高 RTT || 79.0 / 117.5 ms || 78.6 / 119.6 ms
|79.0 / 117.5 ms
|-
|-
|RTT 标准差
| RTT 标准差 || 10.3 ms || 11.5 ms
|10.3 ms
|}
|}
逐跳记录如下，IP 已打码：
 
=== 5.1 晚高峰逐跳记录 ===
 
采样时间：11 月 13 日 '''20:53:49～20:55:41'''。IP 后两段已隐藏。
 
{| class="wikitable"
{| class="wikitable"
!跳数
! 跳数 !! 节点地址 !! ICMP 未响应比例 !! 平均 RTT
!节点地址
!ICMP 未响应比例
!平均 RTT
|-
|-
|1
| 1 || <code>172.20.*.*</code> || 0% || 4.3 ms
|<code>172.20.*.*</code>
|0%
|4.3 ms
|-
|-
|2
| 2 || 未响应 || 100% || 无数据
|未响应
|100%
|无数据
|-
|-
|3
| 3 || <code>172.21.*.*</code> || 0% || 32.7 ms
|<code>172.21.*.*</code>
|0%
|32.7 ms
|-
|-
|4
| 4 || <code>10.11.*.*</code> || 0% || 28.9 ms
|<code>10.11.*.*</code>
|0%
|28.9 ms
|-
|-
|5
| 5 || 未响应 || 100% || 无数据
|未响应
|100%
|无数据
|-
|-
|6
| 6 || <code>211.136.*.*</code> || 71% || 29.2 ms
|<code>211.136.*.*</code>
|71%
|29.2 ms
|-
|-
|7
| 7 || <code>183.194.*.*</code> || 20% || 33.1 ms
|<code>183.194.*.*</code>
|20%
|33.1 ms
|-
|-
|8
| 8 || <code>221.183.*.*</code> || 99% || 18.5 ms
|<code>221.183.*.*</code>
|99%
|18.5 ms
|-
|-
|9
| 9 || 未响应 || 100% || 无数据
|未响应
|100%
|无数据
|-
|-
|10
| 10 || <code>221.183.*.*</code> || 0% || 57.9 ms
|<code>221.183.*.*</code>
|0%
|57.9 ms
|-
|-
|11
| 11 || <code>221.183.*.*</code> || 0% || 57.3 ms
|<code>221.183.*.*</code>
|0%
|57.3 ms
|-
|-
|12
| 12 || <code>221.183.*.*</code> || 0% || 56.9 ms
|<code>221.183.*.*</code>
|0%
|56.9 ms
|-
|-
|13
| 13 || <code>221.183.*.*</code> || 0% || 59.3 ms
|<code>221.183.*.*</code>
|0%
|59.3 ms
|-
|-
|14
| 14 || <code>223.120.*.*</code> || 0% || 95.1 ms
|<code>223.120.*.*</code>
|0%
|95.1 ms
|-
|-
|15
| 15 || <code>223.120.*.*</code> || 0% || 95.5 ms
|<code>223.120.*.*</code>
|0%
|95.5 ms
|-
|-
|16
| 16 || <code>223.120.*.*</code> || 0% || 93.7 ms
|<code>223.120.*.*</code>
|0%
|93.7 ms
|-
|-
|17
| 17 || 未响应 || 100% || 无数据
|未响应
|100%
|无数据
|-
|-
|18
| 18 || 未响应 || 100% || 无数据
|未响应
|100%
|无数据
|-
|-
|19
| 19 || <code>142.0.*.*</code> || 0% || 90.2 ms
|<code>142.0.*.*</code>
|0%
|90.2 ms
|-
|-
|20
| 20 || <code>185.180.*.*</code> || 0% || 96.1 ms
|<code>185.180.*.*</code>
|0%
|96.1 ms
|}
|}
部分中间节点显示较高未响应比例或完全不回应，但后续节点与目标地址均能正常回复。因此，第 6 跳的 71%、第 8 跳的 99% 不能解释为整条链路同等比例的业务丢包；这些现象可能与路由器的 ICMP 响应策略或限速有关。


这次补测在目标端未观察到 ICMP 探测丢包。MTR 的 96.1 ms 与此前独立 Ping 的 102.10 ms 来自不同采样窗口，差异不足以说明线路变快。本文也不依据 IP 地址或地理标签认定物理绕行及具体线路产品。
=== 5.2 白天逐跳记录 ===
 
采样命令窗口：11 月 14 日 '''14:06:04～14:08:00'''；MTR 实际开始于 '''14:06:08'''。IP 后两段已隐藏。
 
{| class="wikitable"
! 跳数 !! 节点地址 !! ICMP 未响应比例 !! 平均 RTT
|-
| 1 || <code>172.20.*.*</code> || 0% || 4.0 ms
|-
| 2 || 未响应 || 100% || 无数据
|-
| 3 || <code>172.21.*.*</code> || 0% || 30.1 ms
|-
| 4 || <code>10.11.*.*</code> || 0% || 29.2 ms
|-
| 5 || 未响应 || 100% || 无数据
|-
| 6 || <code>211.136.*.*</code> || 39% || 27.3 ms
|-
| 7 || <code>183.194.*.*</code> || 21% || 32.0 ms
|-
| 8 || 未响应 || 100% || 无数据
|-
| 9 || 未响应 || 100% || 无数据
|-
| 10 || <code>221.183.*.*</code> || 1% || 60.4 ms
|-
| 11 || <code>221.183.*.*</code> || 0% || 61.7 ms
|-
| 12 || <code>221.183.*.*</code> || 0% || 57.8 ms
|-
| 13 || <code>221.183.*.*</code> || 0% || 59.7 ms
|-
| 14 || <code>223.120.*.*</code> || 0% || 96.0 ms
|-
| 15 || <code>223.120.*.*</code> || 0% || 95.5 ms
|-
| 16 || <code>223.120.*.*</code> || 0% || 95.1 ms
|-
| 17 || 未响应 || 100% || 无数据
|-
| 18 || 未响应 || 100% || 无数据
|-
| 19 || <code>142.0.*.*</code> || 0% || 91.9 ms
|-
| 20 || <code>185.180.*.*</code> || 0% || 95.4 ms
|}
 
两轮部分中间跳出现高未响应比例或完全不回复，但后续节点和目标仍能完整回应。因此，晚高峰第 6 跳的 71%、第 8 跳的 99%，以及白天相应中间跳的未响应比例，都不能直接解释为整条业务链路同等比例的丢包。这些现象可能与路由器的 ICMP 响应策略或限速有关。
 
两次终点平均 RTT 分别为 96.1 和 95.4 ms，数值接近；白天 MTR 标准差略高。独立 Ping 与 MTR 来自不同采样窗口，分别列示，不以两者均值之差判断线路变快或变慢。相同跳数、相近的打码地址前缀也不足以证明完整物理路径相同，本文不据此认定具体线路产品。


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


逐跳记录如下，IP 已打码：
两轮回程均从 VPS 发起，目标为客户端公网出口，早于各自的本地吞吐和去程补测，因此去回程不是同步观测。
 
=== 6.1 晚高峰回程 ===
 
采样时间：11 月 13 日 '''20:08:52～20:10:39'''，100 周期。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% || 无数据
|}
 
=== 6.2 白天回程 ===
 
采样时间：11 月 14 日 '''13:49:41～13:51:28'''，100 周期。日志中的 <code>05:49:41+0000</code> 对应 UTC+8 的 <code>13:49:41</code>。IP 后两段已隐藏。
 
{| class="wikitable"
{| class="wikitable"
!跳数
! 跳数 !! 节点地址 !! ICMP 未响应比例 !! 平均 RTT
!节点地址
!ICMP 未响应比例
!平均 RTT
|-
|-
|1
| 1 || <code>10.39.*.*</code> || 0% || 17.8 ms
|<code>10.39.*.*</code>
|0%
|19.3 ms
|-
|-
|2
| 2 || <code>10.39.*.*</code> || 0% || 0.6 ms
|<code>10.39.*.*</code>
|0%
|0.6 ms
|-
|-
|3
| 3 || <code>142.0.*.*</code> || 0% || 1.2 ms
|<code>142.0.*.*</code>
|0%
|1.0 ms
|-
|-
|4
| 4 || <code>203.144.*.*</code> || 0% || 1.5 ms
|<code>203.144.*.*</code>
|0%
|1.9 ms
|-
|-
|5
| 5 || <code>69.194.*.*</code> || 0% || 1.0 ms
|<code>69.194.*.*</code>
|0%
|1.1 ms
|-
|-
|6
| 6 || <code>69.194.*.*</code> || 3% || 3.2 ms
|<code>69.194.*.*</code>
|0%
|4.2 ms
|-
|-
|7
| 7 || <code>203.22.*.*</code> || 4% || 39.2 ms
|<code>203.22.*.*</code>
|56%
|39.1 ms
|-
|-
|8
| 8 || <code>59.43.*.*</code> || 49% || 40.7 ms
|<code>59.43.*.*</code>
|56%
|40.6 ms
|-
|-
|9
| 9 || <code>59.43.*.*</code> || 90% || 42.6 ms
|<code>59.43.*.*</code>
|83%
|43.2 ms
|-
|-
|10
| 10 || <code>202.97.*.*</code> || 88% || 44.1 ms
|<code>202.97.*.*</code>
|95%
|44.1 ms
|-
|-
|11
| 11 || <code>202.97.*.*</code> || 87% || 68.7 ms
|<code>202.97.*.*</code>
|87%
|68.4 ms
|-
|-
|12
| 12 || <code>202.97.*.*</code> || 99% || 69.7 ms
|<code>202.97.*.*</code>
|97%
|69.9 ms
|-
|-
|13
| 13 || <code>221.183.*.*</code> || 91% || 67.7 ms
|<code>221.183.*.*</code>
|96%
|67.8 ms
|-
|-
|14
| 14 || <code>221.183.*.*</code> || 94% || 63.6 ms
|<code>221.183.*.*</code>
|93%
|63.6 ms
|-
|-
|15
| 15 || 未响应 || 100% || 无数据
|<code>221.183.*.*</code>
|96%
|63.5 ms
|-
|-
|16
| 16 || <code>183.194.*.*</code> || 4% || 68.3 ms
|<code>183.194.*.*</code>
|99%
|68.3 ms
|-
|-
|17
| 17 || 未响应 || 100% || 无数据
|未响应
|100%
|无数据
|}
|}
回程探测可见上述响应节点，但'''没有得到客户端出口的终点响应'''，因此不作为完整的端到端回程验证。中间跳的高未响应比例不能直接当成业务丢包率；部分节点只有少量回复，其 RTT 也不宜用于精细比较。本报告不据此认定完整回程线路产品。
 
两次回程 MTR 都只获得部分响应路径，'''没有取得客户端公网出口的终点响应'''；VPS 对出口的独立 Ping 也均为 60 次发出、0 次回复。因此，这些记录不能作为完整的端到端回程验证。
 
NAT、出口防火墙或 ICMP 过滤都可能影响终点响应，具体原因未确定。中间跳只有少量回复时，其 RTT 也不适合精细比较；这些 RTT 是探测往返时间，不是逐段单向时延。两轮双向 iPerf3 均正常完成，但这不能补全缺失的回程探测数据。


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


本次约 5 分钟的流式 SSH 会话正常完成。心跳记录没有测量按键往返时延，也无法排除心跳之间的短暂延迟。本轮未另行记录人工 SSH 交互、SFTP、网页浏览或视频播放体验，这些项目留待实际使用后补充。
{| class="wikitable"
! SSH 心跳 !! 晚高峰 !! 白天
|-
| 预期 / 实收 || 60 / 60 || 60 / 60
|-
| 观察时长 || 约 5 分钟 || 约 5 分钟
|-
| 会话结果 || 正常结束 || 正常结束
|}
 
晚高峰 SSH 心跳于 '''20:35:19～20:40:21''' 执行，白天于 '''14:00:07～14:05:09''' 执行。两轮分别预期 60 条、实际收到 60 条，SSH 进程正常结束，各自约 5 分钟的观察窗口内没有出现会话中断。


== 八、非晚高峰 NQ / TQ 补充 ==
这些是短时流式 SSH 会话记录，没有测量按键响应时间，也不能排除心跳之间的短暂延迟。两轮均未另行记录人工 SSH 交互、SFTP、网页浏览或视频播放体验，因此不追加这些场景的性能评价。
以下预留非晚高峰 NodeQuality 与 TcpQuality 报告的填写位置。两项报告的采样时间、测试节点和方法分别以对应报告为准，与前文上海移动本地晚高峰结果分开呈现。
 
== 八、NQ / TQ 补充报告 ==
 
以下保留原帖的非晚高峰 NodeQuality 与 TcpQuality 完整报告链接，作为另行采样的脚本测试材料。各报告的准确时间、节点和方法以对应页面为准，与 11 月 13 日晚高峰、14 日白天的本地 Mac 对测分开，不合并计算本地昼夜吞吐、Ping 或重传指标。


=== 8.1 NodeQuality（NQ） ===
=== 8.1 NodeQuality（NQ） ===
第406行： 第422行：


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


# 吞吐每项仅测一次，没有重复样本评估轮间波动。
两轮独立本地 Ping、各四项 iPerf3、SSH 心跳及独立补测去程 MTR 均取得结果。自动去程 MTR 的认证失败记录保留；VPS 对客户端出口 Ping 未取得回复，回程 MTR 也没有终点响应。整轮状态与每一项实际结果分别理解，不以单个失败状态否定已经完成的测量，也不将补测伪装成原流程成功。
# 本地使用 Wi-Fi，未记录频段、协商速率及有线对照；上行套餐速率未知。
 
# 各项目采样时间不同，去程与回程不是同步测量。
本次比较需结合以下条件阅读：
# 回程终点未响应，具体原因未确定。
 
# 本地直连 Ping、单 / 多连接吞吐和 SSH 仅有晚高峰数据。非晚高峰 NQ / TQ 作为补充材料，不能替代相同端点、接入方式和参数下的白天对照。
# 两轮分属不同日期，各项吞吐各测一次，没有重复样本评估轮间波动，不作统计显著性结论。
# 上述晚高峰本地测试流程未进行 IPv6、流媒体解锁、硬盘或 CPU 性能测试。若非晚高峰 NQ / TQ 包含这些项目，应在对应段落单独注明采样时间和方法。
# 使用 Wi-Fi，未记录频段、协商速率及无线干扰，局域网其他流量与主机负载未严格控制；缺少有线和国内测速基线，套餐上行未知。
# 独立 Ping 的样本量不同：晚高峰 60 次、白天 100 次。MTR、Ping、吞吐与 SSH 也分别在各自时间窗口采样。
# 两轮回程均没有客户端公网出口的终点响应，具体原因未确认。
# 500 Mbps 为合计目标速率，白天四连接下载已接近该目标，不能据此确定更高目标速率下的容量。
# NQ / TQ 属于另行采样的脚本材料。上述两轮本地网络流程未测量 IPv6、流媒体解锁、CPU 或磁盘性能，也未进行长期可用性监控；第八节脚本中的相应输出按其自身时间与方法理解。


== 十、晚高峰结论 ==
== 十、综合结论 ==
在本次'''上海中国移动、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 接入、单次测速及不完整的回程探测，也限制了对稳定性和瓶颈的判断。现有数据尚不能支持“跑满宽带”“晚高峰无拥堵”或“长期稳定”等结论。
在这两次'''上海移动、500 Mbps 下行家庭宽带、Wi-Fi、IPv4 直连'''测试中，Ultra Singapore 晚高峰与白天的单连接下载平均吞吐分别约为 '''191 Mbps'''、'''198 Mbps'''，四连接下载分别约为 '''377 Mbps'''、'''473 Mbps'''。白天四连接下载高约 '''25.5%'''，单连接下载差异较小；上传两轮均约为 '''20～26 Mbps'''，没有一致的昼夜变化趋势。
 
两轮独立 Ping 平均 RTT 均约 '''102 ms'''，各自样本内未观察到 ICMP 丢包。两次去程补测均在第 20 跳到达目标，终点各 100 次探测均回复，平均 RTT 分别为 '''96.1 ms'''、'''95.4 ms'''。两轮短时 SSH 心跳均正常完成，但回程终点未响应，不能作为完整回程验证。
 
白天四连接下载取得更高吞吐，同时发送端重传总数较少。现有数据可以描述两个窗口的表现，尚不足以确认差异全部由晚高峰造成，或支持“跑满宽带”“晚高峰无拥堵”“长期稳定”等结论。后续增加多日同参数重复测量或有线对照，有助于判断本次差异是否重复出现。


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


* 活动原帖：[https://www.nodeseek.com/post-1031874-1 搬瓦工全国各地区网络测试报告征集]
本报告依据两轮本地 Mac 测试、VPS 测试及独立去程补测记录整理，包括 Ping 逐包数据、iPerf3 JSON 与逐秒记录、SSH 心跳、双向 MTR 及各自时间。此前中断的测试和 smoke 短测未并入这两轮统计；NQ / TQ 单独列示。
* NodeSeek 评测帖链接：[https://www.nodeseek.com/post-1052095-1 【搬瓦工月付49.99刀新加坡vps测试】上海｜中国移动｜家庭宽带｜Ultra Singapore｜含晚高峰与非晚高峰数据]
 
本文路由表中的 IP 后两段已隐藏。原始 JSON、完整环境与连接日志留作私有核对材料；新增截图和外链报告的公开范围需单独核对，正文打码不会改变链接页面本身可见的信息。
 
* md5.pw：[https://md5.pw/index.php?title=%E4%B8%8A%E6%B5%B7%EF%BD%9C%E4%B8%AD%E5%9B%BD%E7%A7%BB%E5%8A%A8%EF%BD%9C%E5%AE%B6%E5%BA%AD%E5%AE%BD%E5%B8%A6%EF%BD%9CUltra_Singapore%EF%BD%9C%E5%90%AB%E6%99%9A%E9%AB%98%E5%B3%B0%E4%B8%8E%E9%9D%9E%E6%99%9A%E9%AB%98%E5%B3%B0%E6%95%B0%E6%8D%AE 上海移动家庭宽带 Ultra Singapore 评测]
* NodeSeek：[https://www.nodeseek.com/post-1052095-1 上海移动 Ultra Singapore 白天与晚高峰评测]

2026年11月13日 (五) 22:57的最新版本

本次使用上海中国移动 500 Mbps 下行家庭宽带，通过 Wi-Fi 连接同一台 Mac，直连活动提供的同一台 BandwagonHost Ultra Singapore 测试机，分别记录 11 月 13 日晚高峰和 11 月 14 日白天的表现。报告由 Codex 辅助撰写。

两轮单 TCP 连接下载平均吞吐分别为 191.29 Mbps 和 198.08 Mbps；四连接下载分别为 376.62 Mbps 和 472.73 Mbps，本次白天四连接下载高约 25.52%。两轮独立 Ping 的平均 RTT 均约 102 ms，各自样本内没有观察到 ICMP 丢包；两次约 5 分钟的 SSH 心跳也均正常完成。

这次较大的差异出现在四连接下载，单连接下载和平均延迟接近。两轮各项吞吐各测一次、分属不同日期，Wi-Fi 状态等条件未严格控制，结论限于这两个测量窗口。原帖已附的 NQ / TQ 完整报告链接在第八节单独保留，不并入本地昼夜统计。

一、测试环境

项目 两轮本地测试环境
地区与运营商 上海，中国移动
网络与接入方式 同一条家庭宽带、同一台 Mac，经 Wi-Fi 无代理直连；未记录频段、协商速率与无线干扰
宽带套餐 下行 500 Mbps，上行未知；套餐速率由测试者提供
测试机来源与机房 活动提供的 BandwagonHost Ultra Singapore 测试机，两轮为同一台 VPS
本地电脑与系统 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 的路由接口为 en0。家庭宽带 Wi-Fi 接入由测试者确认。白天 VPS 日志中的“移动网络”为备注误填，实际仍为同一条家庭宽带接入；本文说明该差异，保留原始日志。

宽带上行套餐速率未知。本次没有有线对照、国内测速基线，也未严格控制 Wi-Fi 瞬时状态、局域网其他流量和主机负载。

二、测量时间与参数

下表均为 UTC+8。各项目分阶段采样，整段时间不代表连续监控。

项目 11 月 13 日晚高峰 11 月 14 日白天
VPS 对客户端出口 Ping 20:07:42～20:08:52 13:48:30～13:49:41
VPS 回程 MTR 20:08:52～20:10:39 13:49:41～13:51:28
Mac 对 VPS 独立 Ping 20:30:45～20:31:44 13:52:22～13:54:01
Mac 双向吞吐 20:31:44～20:35:19 13:56:32～14:00:07
SSH 心跳 20:35:19～20:40:21 14:00:07～14:05:09
去程 MTR 补测 20:53:49～20:55:41 14:06:04～14:08:00 为命令窗口，实际开始于 14:06:08

两轮 iPerf3 使用相同参数：单连接和四连接分别上传、下载，每项 30 秒，各测一次，测试之间休息约 30 秒。单连接与四连接的合计目标速率均为 500 Mbps，其中四连接按每条 125 Mbps 设置。下载使用反向模式，最终吞吐统一采用完整测试时段的接收端合计平均值。

500 Mbps 是测试目标速率参数，不是测得的链路容量。四项吞吐每轮都只有一次观测，本文不将其表述为多轮中位数。

两轮独立 Ping 的样本量分别为晚高峰 60 次、白天 100 次，均约每秒一次。去程 MTR 均在自动流程认证失败后独立补测，各为 100 周期；它们与独立 Ping 分别统计，不互相替代。两轮回程 MTR 也各为 100 周期，VPS 对客户端出口 Ping 各为 60 次。

三、Ping 延迟与丢包

指标 晚高峰，11 月 13 日 白天，11 月 14 日
发送 / 接收 60 / 60 100 / 100
本次样本丢包率 0% 0%
最低 RTT 80.65 ms 79.31 ms
平均 RTT 102.10 ms 101.99 ms
最高 RTT 147.88 ms 146.18 ms
RTT 标准差 13.39 ms 13.70 ms
RTT P95 126.30 ms 130.99 ms

两轮平均 RTT 相差约 0.11 ms，所测窗口的平均延迟接近。白天 RTT 标准差为 13.70 ms、P95 为 130.99 ms，均略高于晚高峰的 13.39 ms 和 126.30 ms，没有呈现延迟各项指标一致改善的情况。

P95 沿用各轮逐包 RTT 的 nearest-rank 统计结果。两轮采样日期、时长和样本量不同，P95 与最大值只作描述性对照。这里的 0% 丢包分别对应 60 次、100 次本地 ICMP 探测，不代表整个白天或晚高峰，也不能扩展为 TCP 业务零丢包。

VPS 对客户端公网出口的另两次 Ping 均发送 60 次、收到 0 次回复。该方向的 ICMP 探测与本地 Ping 分开记录；NAT、出口设备或 ICMP 过滤都可能影响响应，具体原因未确定。双向 TCP 传输在两轮均可完成，不能据出口 Ping 不回复直接认定业务不可用。

四、单连接、多连接吞吐与昼夜对比

上传指 Mac → VPS，下载指 VPS → Mac。两轮共八项传输均正常结束。以下时间均为对应日期的 UTC+8。

4.1 晚高峰：2026 年 11 月 13 日

项目 数据方向 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.2 白天：2026 年 11 月 14 日

项目 数据方向 TCP 连接数 白天测量时间，UTC+8 接收端平均吞吐 发送端 Retr
单连接上传 Mac → VPS 1 13:56:32～13:57:04 22.34 Mbps 1,688
单连接下载 VPS → Mac 1 13:57:34～13:58:04 198.08 Mbps 4
4 连接上传 Mac → VPS 4 13:58:34～13:59:06 23.53 Mbps 2,083
4 连接下载 VPS → Mac 4 13:59:36～14:00:07 472.73 Mbps 2,202

4.3 吞吐对比

项目 晚高峰平均吞吐 白天平均吞吐 白天较晚高峰差值 白天相对晚高峰变化
单连接上传 20.56 Mbps 22.34 Mbps +1.78 Mbps +8.66%
单连接下载 191.29 Mbps 198.08 Mbps +6.79 Mbps +3.55%
四连接上传 25.68 Mbps 23.53 Mbps -2.15 Mbps -8.37%
四连接下载 376.62 Mbps 472.73 Mbps +96.11 Mbps +25.52%

相对变化按表内保留两位小数的数值计算：（白天 ÷ 晚高峰 - 1）× 100%。若采用未舍入原始值，末位可能略有差别。

本次最明显的变化是四连接下载，由 376.62 提高到 472.73 Mbps，增加约 96.11 Mbps，白天相对晚高峰高约 25.52%。单连接下载只增加约 6.79 Mbps，即 3.55%。两轮四连接与单连接下载的比值分别约为 1.97 倍、2.39 倍。

白天四连接下载已接近设置的 500 Mbps 合计目标速率，说明该参数下取得了较高吞吐。由于目标速率本身有限制，且缺少有线或国内测速基线，本轮没有测出更高目标速率下的链路容量，也不直接以跨境应用层吞吐判定套餐下行是否“跑满”。

上传没有呈现一致的昼夜变化：单连接白天略高，四连接白天略低，两轮约为 20～26 Mbps。上行套餐速率未知，现有数据无法区分套餐限制、无线接入和跨境链路各自的影响。

白天四项接收端记录的有效净荷合计约 2.69 GB。该数值不等同于网卡总流量或 VPS 计费流量，协议与重传开销另计。

4.4 发送端重传

项目 晚高峰发送端 Retr 白天发送端 Retr
单连接上传 3,820 1,688
单连接下载 2 4
四连接上传 2,179 2,083
四连接下载 93,983 2,202

两次四连接下载的发送端分别记录到 93,983 和 2,202 次 Retr。白天在取得更高平均吞吐的同时，记录到的重传总数较少，这个组合值得在相同条件下继续复测。

表中是 iPerf3 输出的原始计数，没有换算为重传率或丢包率。实际传输量、连接数及运行状态都会影响总计数，不能仅凭 Retr 总数确定重传位置或认定晚高峰拥堵。

4.5 一次传输内部的逐秒波动

为查看传输后段，另列开始 5 秒后的逐秒接收端速率范围：

下载项目 晚高峰逐秒范围 白天逐秒范围
单连接 123.87～207.74 Mbps 127.92～221.38 Mbps
四连接 327.37～437.69 Mbps 330.89～559.84 Mbps

这些区间是单次传输内部的逐秒变化，不是多轮测速结果范围。上面的平均吞吐仍采用完整测试时段，没有剔除前 5 秒。白天四连接的 559.84 Mbps 接收端逐秒峰值不代表持续容量；目标发送速率也不保证每个接收端统计窗口均不超过该值。

五、去程路由补测

两轮自动去程 MTR 均因 sudo 认证失败而未取得结果，之后在终端前台独立补测。原失败日志保留，补测数据按自己的时间记录，不写回自动流程的失败时段。

两轮补测都在第 20 跳到达同一台目标 VPS，终点各 100 次探测均收到回复。

去程 MTR 终点指标 晚高峰补测 白天补测
到达目标的跳数 第 20 跳 第 20 跳
终点发送 / 接收 100 / 100 100 / 100
终点样本丢包率 0% 0%
平均 RTT 96.1 ms 95.4 ms
最低 / 最高 RTT 79.0 / 117.5 ms 78.6 / 119.6 ms
RTT 标准差 10.3 ms 11.5 ms

5.1 晚高峰逐跳记录

采样时间：11 月 13 日 20:53:49～20:55:41。IP 后两段已隐藏。

跳数 节点地址 ICMP 未响应比例 平均 RTT
1 172.20.*.* 0% 4.3 ms
2 未响应 100% 无数据
3 172.21.*.* 0% 32.7 ms
4 10.11.*.* 0% 28.9 ms
5 未响应 100% 无数据
6 211.136.*.* 71% 29.2 ms
7 183.194.*.* 20% 33.1 ms
8 221.183.*.* 99% 18.5 ms
9 未响应 100% 无数据
10 221.183.*.* 0% 57.9 ms
11 221.183.*.* 0% 57.3 ms
12 221.183.*.* 0% 56.9 ms
13 221.183.*.* 0% 59.3 ms
14 223.120.*.* 0% 95.1 ms
15 223.120.*.* 0% 95.5 ms
16 223.120.*.* 0% 93.7 ms
17 未响应 100% 无数据
18 未响应 100% 无数据
19 142.0.*.* 0% 90.2 ms
20 185.180.*.* 0% 96.1 ms

5.2 白天逐跳记录

采样命令窗口：11 月 14 日 14:06:04～14:08:00；MTR 实际开始于 14:06:08。IP 后两段已隐藏。

跳数 节点地址 ICMP 未响应比例 平均 RTT
1 172.20.*.* 0% 4.0 ms
2 未响应 100% 无数据
3 172.21.*.* 0% 30.1 ms
4 10.11.*.* 0% 29.2 ms
5 未响应 100% 无数据
6 211.136.*.* 39% 27.3 ms
7 183.194.*.* 21% 32.0 ms
8 未响应 100% 无数据
9 未响应 100% 无数据
10 221.183.*.* 1% 60.4 ms
11 221.183.*.* 0% 61.7 ms
12 221.183.*.* 0% 57.8 ms
13 221.183.*.* 0% 59.7 ms
14 223.120.*.* 0% 96.0 ms
15 223.120.*.* 0% 95.5 ms
16 223.120.*.* 0% 95.1 ms
17 未响应 100% 无数据
18 未响应 100% 无数据
19 142.0.*.* 0% 91.9 ms
20 185.180.*.* 0% 95.4 ms

两轮部分中间跳出现高未响应比例或完全不回复，但后续节点和目标仍能完整回应。因此，晚高峰第 6 跳的 71%、第 8 跳的 99%，以及白天相应中间跳的未响应比例，都不能直接解释为整条业务链路同等比例的丢包。这些现象可能与路由器的 ICMP 响应策略或限速有关。

两次终点平均 RTT 分别为 96.1 和 95.4 ms，数值接近；白天 MTR 标准差略高。独立 Ping 与 MTR 来自不同采样窗口，分别列示，不以两者均值之差判断线路变快或变慢。相同跳数、相近的打码地址前缀也不足以证明完整物理路径相同，本文不据此认定具体线路产品。

六、回程路由

两轮回程均从 VPS 发起，目标为客户端公网出口，早于各自的本地吞吐和去程补测，因此去回程不是同步观测。

6.1 晚高峰回程

采样时间：11 月 13 日 20:08:52～20:10:39，100 周期。IP 后两段已隐藏。

跳数 节点地址 ICMP 未响应比例 平均 RTT
1 10.39.*.* 0% 19.3 ms
2 10.39.*.* 0% 0.6 ms
3 142.0.*.* 0% 1.0 ms
4 203.144.*.* 0% 1.9 ms
5 69.194.*.* 0% 1.1 ms
6 69.194.*.* 0% 4.2 ms
7 203.22.*.* 56% 39.1 ms
8 59.43.*.* 56% 40.6 ms
9 59.43.*.* 83% 43.2 ms
10 202.97.*.* 95% 44.1 ms
11 202.97.*.* 87% 68.4 ms
12 202.97.*.* 97% 69.9 ms
13 221.183.*.* 96% 67.8 ms
14 221.183.*.* 93% 63.6 ms
15 221.183.*.* 96% 63.5 ms
16 183.194.*.* 99% 68.3 ms
17 未响应 100% 无数据

6.2 白天回程

采样时间：11 月 14 日 13:49:41～13:51:28，100 周期。日志中的 05:49:41+0000 对应 UTC+8 的 13:49:41。IP 后两段已隐藏。

跳数 节点地址 ICMP 未响应比例 平均 RTT
1 10.39.*.* 0% 17.8 ms
2 10.39.*.* 0% 0.6 ms
3 142.0.*.* 0% 1.2 ms
4 203.144.*.* 0% 1.5 ms
5 69.194.*.* 0% 1.0 ms
6 69.194.*.* 3% 3.2 ms
7 203.22.*.* 4% 39.2 ms
8 59.43.*.* 49% 40.7 ms
9 59.43.*.* 90% 42.6 ms
10 202.97.*.* 88% 44.1 ms
11 202.97.*.* 87% 68.7 ms
12 202.97.*.* 99% 69.7 ms
13 221.183.*.* 91% 67.7 ms
14 221.183.*.* 94% 63.6 ms
15 未响应 100% 无数据
16 183.194.*.* 4% 68.3 ms
17 未响应 100% 无数据

两次回程 MTR 都只获得部分响应路径，没有取得客户端公网出口的终点响应；VPS 对出口的独立 Ping 也均为 60 次发出、0 次回复。因此，这些记录不能作为完整的端到端回程验证。

NAT、出口防火墙或 ICMP 过滤都可能影响终点响应，具体原因未确定。中间跳只有少量回复时，其 RTT 也不适合精细比较；这些 RTT 是探测往返时间，不是逐段单向时延。两轮双向 iPerf3 均正常完成，但这不能补全缺失的回程探测数据。

七、SSH 与实际业务观察

SSH 心跳 晚高峰 白天
预期 / 实收 60 / 60 60 / 60
观察时长 约 5 分钟 约 5 分钟
会话结果 正常结束 正常结束

晚高峰 SSH 心跳于 20:35:19～20:40:21 执行，白天于 14:00:07～14:05:09 执行。两轮分别预期 60 条、实际收到 60 条，SSH 进程正常结束，各自约 5 分钟的观察窗口内没有出现会话中断。

这些是短时流式 SSH 会话记录，没有测量按键响应时间，也不能排除心跳之间的短暂延迟。两轮均未另行记录人工 SSH 交互、SFTP、网页浏览或视频播放体验，因此不追加这些场景的性能评价。

八、NQ / TQ 补充报告

以下保留原帖的非晚高峰 NodeQuality 与 TcpQuality 完整报告链接，作为另行采样的脚本测试材料。各报告的准确时间、节点和方法以对应页面为准，与 11 月 13 日晚高峰、14 日白天的本地 Mac 对测分开，不合并计算本地昼夜吞吐、Ping 或重传指标。

8.1 NodeQuality（NQ）

8.2 TcpQuality（TQ）

九、数据完整性与局限

两轮独立本地 Ping、各四项 iPerf3、SSH 心跳及独立补测去程 MTR 均取得结果。自动去程 MTR 的认证失败记录保留；VPS 对客户端出口 Ping 未取得回复，回程 MTR 也没有终点响应。整轮状态与每一项实际结果分别理解，不以单个失败状态否定已经完成的测量，也不将补测伪装成原流程成功。

本次比较需结合以下条件阅读：

  1. 两轮分属不同日期，各项吞吐各测一次，没有重复样本评估轮间波动，不作统计显著性结论。
  2. 使用 Wi-Fi，未记录频段、协商速率及无线干扰，局域网其他流量与主机负载未严格控制；缺少有线和国内测速基线，套餐上行未知。
  3. 独立 Ping 的样本量不同：晚高峰 60 次、白天 100 次。MTR、Ping、吞吐与 SSH 也分别在各自时间窗口采样。
  4. 两轮回程均没有客户端公网出口的终点响应，具体原因未确认。
  5. 500 Mbps 为合计目标速率，白天四连接下载已接近该目标，不能据此确定更高目标速率下的容量。
  6. NQ / TQ 属于另行采样的脚本材料。上述两轮本地网络流程未测量 IPv6、流媒体解锁、CPU 或磁盘性能，也未进行长期可用性监控；第八节脚本中的相应输出按其自身时间与方法理解。

十、综合结论

在这两次上海移动、500 Mbps 下行家庭宽带、Wi-Fi、IPv4 直连测试中，Ultra Singapore 晚高峰与白天的单连接下载平均吞吐分别约为 191 Mbps、198 Mbps，四连接下载分别约为 377 Mbps、473 Mbps。白天四连接下载高约 25.5%，单连接下载差异较小；上传两轮均约为 20～26 Mbps，没有一致的昼夜变化趋势。

两轮独立 Ping 平均 RTT 均约 102 ms，各自样本内未观察到 ICMP 丢包。两次去程补测均在第 20 跳到达目标，终点各 100 次探测均回复，平均 RTT 分别为 96.1 ms、95.4 ms。两轮短时 SSH 心跳均正常完成，但回程终点未响应，不能作为完整回程验证。

白天四连接下载取得更高吞吐，同时发送端重传总数较少。现有数据可以描述两个窗口的表现，尚不足以确认差异全部由晚高峰造成，或支持“跑满宽带”“晚高峰无拥堵”“长期稳定”等结论。后续增加多日同参数重复测量或有线对照，有助于判断本次差异是否重复出现。

十一、数据记录与公开链接

本报告依据两轮本地 Mac 测试、VPS 测试及独立去程补测记录整理，包括 Ping 逐包数据、iPerf3 JSON 与逐秒记录、SSH 心跳、双向 MTR 及各自时间。此前中断的测试和 smoke 短测未并入这两轮统计；NQ / TQ 单独列示。

本文路由表中的 IP 后两段已隐藏。原始 JSON、完整环境与连接日志留作私有核对材料；新增截图和外链报告的公开范围需单独核对，正文打码不会改变链接页面本身可见的信息。

取自“https://md5.pw/index.php?title=上海｜中国移动｜家庭宽带｜Ultra_Singapore｜含晚高峰与非晚高峰数据&oldid=4348”
最后修改时间
此页面最后编辑于2026年11月13日 (星期五) 22:57。