FabricPath

@biergaizi 传送网都基本都是 mpls 转发， 不看 ecn ，标记 ecn 要改报文，有代价，bras 不会浪费时间做 ecn 标记，只有双端支持的 ecn 就没有意义了。不过我现在双端 ecn 都是关的。
我最近改造成 mtls 入站分流了，并 fallback 到 nvr 的登录页面，同样比正向的 trojan-go 的性能会好很多（ 400Mbps vs 1100Mbps ），但会低于 ssh （ 1300Mbps ）。

在我这个环境下，vps->家宽这个方向，会少 7 跳，少的这 7 跳是少在 169 出口到 vps 侧的海外落地侧，那时我才怀疑是双向有不对称处理。虽然这也有可能是回程设备没做 ttl-1 ，但是从方向的性能测试上来看，也符合不同方向有不同的处理方式。
我也没有做对比测试，懒得开其他 vps 来测试，目标是本地跑得好就行了，包括正向和方向的协议也没对齐，也没评估不同协议的差异，并且 tcp 的 buffer size 、yamux 的 buffer size 都是对性能影响极大的参数，也没有做控制面变量测试，主要是我不是来做详细的技术分享或者 gfw 的研究，只是提供一个测试的例子，期待其他兄弟或者 gfw report 可以详细做一下定性测试。

现状是从 4 号开始切换到 mtls ，6 天多跑了 80 多 G 下行，20 多 G 上行的流量，目前连接没中断过，也没发现有主动扫描的流量。

这么好看的猫直接挂闲鱼 20 块钱自提就行了，很多人买。
我小区的流浪猫都被邻居挂闲鱼卖了，好看的 20 ，丑的 10 块。

@Foxkeh 区别不大，现在大部分协议在不开 mux 的情况下都是 per connection 创建一个远端 connection ，对于一个境外 IP ，在国内竟然只有单个 SrcIP 去访问，并且连接数和流量都很高。只是为了抓人的话，人肉筛一遍这些特征就行了。
不过我准备改成 fallback 到 nvr 的 https 试试，更符合正常业务流量，我这 nvr 开在公网上快 6 年了，运营商也没管过。

@yulon 那我流量是很大了，我现在 7.5 刀的 2TB （ 1TB ）每个月基本上都能用完，基本每个月都这么大流量，gpt 本身也会产生大量上行。在去年早期实现的时候，我一直在对比和正向 trojan 的性能，在任何观察过的时间点，正向直连 vps 的 trojan 性能都不如反向的 ssh 。

@zxbiao 时代变了，早期是靠流量大小识别的，你直接让 AI 分析 gfw 的代码和已知的规则，就能发现现在审查重点是出海方向的 tls 了。现在除 tls 外，海外主动回连的协议都不是审查重点。



我发现楼上好多人重点搞错了，重点不是 ssh 协议，而是从海外主动回连的公开协议。

https://geedge.report/assets/geedge-tsg-usenix26.pdf 附上今年的研究报告。

顺便补充一下为啥我会用反向的连接，因为去年粗略扫了一遍 tsg 的源码，发现他主要审查的方向是 tls 、quic ，并且从文档和已有的规则集来看，具备明显的境内->境外和境外->境内方向性，审查重点就是境外往境外主动发起的 tls 和 quic 。
但是并没有发现“长连接”，“二元组”等明显的规则，从过去几年只有特殊时期才封二元组来看，这应该是一个 adhoc 的规则集，平时不会启用。

至于为什么是 ssh ，纯粹是因为懒得做实验，ssh 比 frp 更像是正常流量，并且启用之后一直很稳定，也没动力去探索其他协议。
虽然从代码中也没找到明确豁免 ssh 的逻辑，但是从性能测试来看，使用反向的 ssh 会明显比正向的 ssh 隧道更快，且可以稳定复现，说明至少现在部署的 gfw 版本，大概率对两个方向的处理有差异。

@leaflxh 过去 5 、6 年一直用同一个 lightsail ，就今年流量大升了规格才换了 IP ，只有开大会的时候会短时间掐二元组。

@xeonforce 放到过去靠二元组流量特征去无脑掐的年代，这种模式容易被识别，放到现在，从泄露的 gfw 代码来看，中心都放到去扫描前 N 个报文的特征，而且 gfw 用的 dpdk ，dpdk 本身要做包缓存就需要消耗巨量的 hugepage ，不做包缓存又解决不了 SNI 分片。

从 gfw repo 的论文也能看出来，gfw 是对连接做了缓存的，并且在高峰期还会降级

@est 我关心对方 kpi 干嘛，被封了就继续用 cdn 接入就行了，本来家宽有公网就少，提供一个思路和测试结果而已，不知道你要杠啥。

@est 你自己实现协议不就是为了特征少吗，因为国内没多少人有公网 IP ，所以只是检测重点不在这里；如果要检测梯子流量，那太容易了，只要二元组流量过大、连接数过多，直接掐了就行了。
@nomansky 就是因为特征明显才猜测临时进了豁免通道，并且 ssh 建连接的频率极低，也比非 mux 情况下的新建连接数量少得多；非公开协议，那太明显了。
@yeyeye 就是因为国内有公网的少。相比伪装成正常的流量，之前最开始灰度接反向 ssh 的时候，和走 cloudfront 的正向连接做负载均衡，开会的时候会直接基于二元组封禁到 cloudfront 接入点 IP 的连接（不清楚非公网 IP 是否也会使用二元组封禁），但是 ssh 隧道还活着。

此外基于 gfwreport 过去几年的报告来看，gfw 审查模型多检测连接前 N 个报文，对于超长时间的长连接来说，没明显感知到会中途检测的情况。包括之前使用 mux 的时候，也观察到新建连接超时，存量连接能正常通信的情况，不过没定量评估正向长连接的稳定性，纯感觉。

@zizon 正向的 ssh tunnel 和其他协议一样，只能跑到 400Mbps ，速度明显会低一截。