[Chat]:直连为啥带宽跑不满 #2

New Issue

manbo · 2026-02-11T13:08:38+08:00

manbo commented

2026-02-11 13:08:38 +08:00

开个issue记录一下排查过程，顺便给你们补补相关知识。

背景

rn的小鸡:

<client>---<transoceanic fiber>---<vps>---<outbound target>

其中跨洋电缆部分的路由是没法控制的，全看bgp心情。

这毫无疑问属于LFN (long fat network) 详见。

理论上来说结合loss抖动是会影响实际带宽和tls交互。并且理论值和原先的speedtest结果相近。但是真的是这样吗？

先提出猜想:

1. 瓶颈在LFN
1. 协议本身的性能问题
1. GFW出口随机rst (即使伪装sni正常)

验证

实验编号和猜想一一对应

实验1(安全起见先在单机通过namespace + vnet模拟，原因详见章节1)

拓扑如下

ns_c : client app
ns_p1 : xray client side
ns_w : WAN emulator
ns_p2 : xray server side + target service

Links:

ns_c <-> ns_p1 <-> ns_w <-> ns_p2

结果:

暂时略过

猜想2:很难成立(明确context,只在tcp based之前比较，和quic那些比没意思)

这个PR有详细解释（对比机场常见的ss）。

不相信就自己拿iperf3或wrk测试一下

猜想3: 还没想好安全的实验设计，暂时略过

着急的话，可以拿wiresharkpassive观察一下rst(或者让ai给你写个脚本拿tcpdump监测)

为什么机场会快

其实还是跟LFN有关

一般来说拓扑是这样的:

<client>---<relay1>---<opt routing path (like cn2)>---<relay2>---<relayN>---<endpoint>---<outbound target>

一般userspace的转发是新建一条链接，这就把抖动隔离了（不懂就去问gpt）。物理延迟摆在那，但是稳定性上升了。

我不用机场，你们可以精心构造探针去验证一下

我最近回湖南后、这VPN的质量和速度直线下滑

正常，最近几大云不是在通报下线对等转发（对应上述拓扑中的relay1）吗？习惯就好（这个sources我没法cite）。

附加阅读（没耐心就直接看最后的ixp）

开个issue记录一下排查过程，顺便给你们补补相关知识。 ## 背景 rn的小鸡: ```text <client>---<transoceanic fiber>---<vps>---<outbound target> ``` 其中跨洋电缆部分的路由是没法控制的，全看bgp心情。这毫无疑问属于**LFN (long fat network)** [详见](https://paulgrevink.wordpress.com/2017/09/08/about-long-fat-networks-and-tcp-tuning/)。理论上来说结合loss抖动是会影响实际带宽和tls交互。并且理论值和原先的speedtest结果相近。但是真的是这样吗？先提出猜想: - 1) 瓶颈在LFN - 2) 协议本身的性能问题 - 3) GFW出口随机rst (即使伪装sni正常) ## 验证 > 实验编号和猜想一一对应实验1(安全起见先在单机通过namespace + vnet模拟，原因[详见](https://gitea.markyan04.cn/manbo/blog-post-backup/src/branch/main/drafts/2026-01-25-ace-profiling-attorney-the-case-of-the-missing-gbits.md)章节1) 拓扑如下 - ns_c : client app - ns_p1 : xray client side - ns_w : WAN emulator - ns_p2 : xray server side + target service Links: ```text ns_c <-> ns_p1 <-> ns_w <-> ns_p2 ``` **结果**: 暂时略过 --- 猜想2:很难成立(明确context,只在tcp based之前比较，和quic那些比没意思) 这个[PR](https://github.com/XTLS/Xray-core/pull/5067)有详细解释（对比机场常见的ss）。不相信就自己拿`iperf3`或`wrk`测试一下 --- 猜想3: 还没想好安全的实验设计，暂时略过 > 着急的话，可以拿`wireshark`passive观察一下rst(或者让ai给你写个脚本拿`tcpdump`监测) ## 为什么机场会快其实还是跟LFN有关一般来说拓扑是这样的: ```text <client>---<relay1>---<opt routing path (like cn2)>---<relay2>---<relayN>---<endpoint>---<outbound target> ``` 一般userspace的转发是新建一条链接，这就把抖动隔离了（不懂就去问gpt）。物理延迟摆在那，但是稳定性上升了。 --- 我不用机场，你们可以精心构造探针去验证一下 --- > 我最近回湖南后、这VPN的质量和速度直线下滑正常，最近几大云不是在通报下线**对等转发**（对应上述拓扑中的`relay1`）吗？习惯就好（这个sources我没法cite）。 [附加阅读](https://blog.mfwt.top/index.php/archives/912/)（没耐心就直接看最后的ixp）

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: manbo/internal-docs#2