💬 New comment on Xray-core#2635 Xray会支持歇斯底里2么？
by @RPRX

目前来说 Hysteria 等协议的目标是 **通过激进的发包策略来提升弱网环境的代理可用性**，但是有以下缺点：

1. 激进发包其实就是抢资源，会弱化其他人的体验，**如果大家都用，那只会更爆炸**
2. 它们的目标不是抗封锁，社区也没有 GFW 对 QUIC 动手的历史数据，尚不清楚 GFW 会如何针对性封锁这些协议

所以可以再观望一下，尤其是第一点要想清楚，这就跟补习一样，别人补，你看了也想补，最后大家都补了，就成了无意义内卷，而且既然它们成了主流，GFW 就会研究它们和普通 QUIC 的不同，最后大家只能回归普通 QUIC，~~反正预言是放这儿了~~

Reply to this message to post a comment on GitHub.

💬 New comment on Xray-core#2635 Xray会支持歇斯底里2么？
by @tobyxdd

1. Hysteria 发包是否 "激进" 仁者见仁，不过绝对不是多倍发包（这个我相信 RPRX 知道，只是为了和路人强调下），详细的解释可以看这里 https://v2.hysteria.network/zh/docs/misc/Hysteria-Brutal/ 。我的观点是用户使用运营商承诺的带宽发包，没有破解限速就是合理的。至于拥塞控制即使是 TCP 不同的操作系统和配置也不同，BBR 也是在 "弱化 Cubic 的体验"。而且互联网上天然就有很多流量没有拥塞控制，比如联机游戏可不会因为延迟和丢包率高而降低 tickrate。

2. Hysteria 还是特意注意没有魔改 QUIC 基本协议层的东西的，毕竟还要作为普通 HTTP/3 server 处理浏览器请求。行为上应该和其他用 quic-go 实现的 HTTP/3 web server (比如 caddy) 一致。当然往深了说目前各种 QUIC 实现都是有细微差异的，像 quic-go, quiche, quinn, ngtcp2, neqo 在默认参数和行为上都不完全相同，如果一定要把服务端用的是什么库本身作为特征的话应该是可以的。但是正如你所说 "尚不清楚 GFW 会如何针对性封锁这些协议"，我不想提前修改，偏离 quic-go 而 potentially 造成新的特征。如果 GFW 真的能够针对性封锁了，我相信只要不是白名单或者完全封锁了 UDP 流量都是能解决的。人固有一死但是今天的饭还得吃

另外 RPRX 发了这个回复以后我看到两边的用户群都开始有站队的现象，我想声明一下我十分清楚 RPRX 的目的只是技术讨论，没有任何 "攻击 Hysteria" 的意思。无论是否加入 Hysteria 我都会继续支持 RPRX 和 Xray 这个项目。no hard feelings

Reply to this message to post a comment on GitHub.

rprx:起猛了 xray装机量突然多了个把亿

关于近期在 USENIX 顶会发表的 TLS 特征检测论文
https://www.usenix.org/conference/usenixsecurity24/presentation/xue

这篇论文证明了重要的一点 即通过流量模型来识别 *任何* 加密代理协议中的内层 TLS 是可能的 且成本并不高

文章也提出了现有方法的一些弱点 比如
1. 当用户在代理内层使用 TLS v1.2 的时候 由于开头的5次握手包 特征明显超过3次的 TLS v1.3 握手 可以被针对性训练 达到非常高的阳性率
（好在 TLS v1.2 的使用越来越少的情况下 审查者想利用这个弱点的机会将逐渐减少）
2. 多路复用方法目前的一个缺点就是依赖用户的使用情况 假如一个代理连接的起始 刚好是用户发起的单连接 这会抵消多路复用的混肴作用
（要解决这个问题 一个方法是在每一个连接头插入一些伪造流量）

根据文章的数据 XTLS Vision 使得伪阳性率从 0.0544% 上升到 0.1989% 这意味着审查需要付出更大的代价 更为重要的 审查者必须使用重新训练的针对性模型 而且即使在这种情况下 阳性率还是从 0.748 下降到了 0.513
去年我们发布 XTLS Vision 的时候说 我们的设计目标是将“识别难度增加一个数量级”
可以说 这篇文章证明现有协议已经达到或者超过了我们的既定目标

自从 shadowsocks 以来 主流的学术圈和实用代理界出现了一些分野
UoT，VMESS+WS+TLS，Trojan 都没有引起学术界的重视 却是自建与机场的主流选择
这次文章作者 Diwen Xue 主动联系我们 我们也为文章提供了一些反馈 让我们的工作促进反审查科研圈与开发圈的交流 我们感到与有荣焉！

要解决 TLS-in-Any 特征 一个可行的方法是拆分连接 即把关键的内层握手包以某种方式拆分到多个代理连接中
今年早些时候 R佬已经发表了 switch 的构想并且在 [XUDP](https://github.com/XTLS/Xray-core/commit/be23d5d3b741268ef86f27dfcb06389e97447e87) 中实现了连接迁移的雏形
希望在不久的将来 反审查社区的合作越来越好 一起将这些构想化为现实

yuhan6665

快过年了，不要再讨论什么 CN2 、GIA ，什么 XTLS 、grpc 了，你的万兆过墙线路，回到家了并不会给你带来任何实质性作用，朋友们兜里掏出一大把钱吃喝玩乐，你默默在家里摆弄你的上网代理工具。亲戚朋友吃饭问你收获了什么，你说我撸了一个传家宝 vps ，延迟 20ms 以内，网速能上 10Gbps ，亲戚们懵逼了，你还在心里默默嘲笑他们，不懂你的线路的优质程度，也笑他们十有八九连上网代理都不知道是什么。

你父母的同事都在说自己的子女一年的收获，儿子买了个房，女儿购了台车，姑娘升职加薪了，你的父母默默无言，最后被人问到了，不说话不礼貌，才说我的儿子今年撸了好几个 vps ，里面有好几个传家宝级别的嘞。

Latest release: https://github.com/XTLS/Xray-core/releases/tag/v1.8.8

Latest release: https://github.com/XTLS/Xray-core/releases/tag/v1.8.9

不是我恶意揣测，我不相信不被封是因为 xray 技术牛逼，可能就是背后有人支持

请测试 HTTPUpgrade 0-RTT
现在起 WebSocket ed 建议填 2560 而不是 2048
https://github.com/XTLS/Xray-core/pull/3152

💬 New comment on Xray-core#3076 Add Authority to gRPC Transport
by @RPRX

> 这个有上面用？

技术是在进步的，别人造出了你能看懂的好东西不可怕，最可怕的是别人干了但你看不懂别人在干什么或者说为什么要这么干，就像以前我写的很多东西一样，~~不过这次我是真的不能细说，或许有一天除了我和 @yuhan6665 之外的人会发现它的真实用途~~

我一直催 @yuhan6665 发 1.8.9 就是为了它，~~就是为了这口醋才下了这盘饺子，结果 NG 新版没它我又去说 https://github.com/2dust/v2rayNG/issues/2924~~

Reply to this message to post a comment on GitHub.

Latest release: https://github.com/XTLS/Xray-core/releases/tag/v1.8.10

Latest release: https://github.com/XTLS/Xray-core/releases/tag/v1.8.11