群里说可以用了

bd7503d 我把这个文件里的 LogInfo() 都改成 LogDebug() 了

另外默认参数中的判断小于 900 #5270 (comment) 是不是早就该改了

bd7503d 我把这个文件里的 LogInfo() 都改成 LogDebug() 了

另外默认参数中的判断小于 900 #5270 (comment) 是不是早就该改了

那些日志确实 debug 好点
padding 是这个意思 有一种无视原数据包长度 统一填充至 900-1400 我称之为longpadding（或许名字不太好）
对于原长900 以上当然不能这么用了 所以900 以上或者非longpadding 采用传统方法 随机 0-256

我的意思是随着 Chrome TLS 默认有了 X25519MLKEM768 和 ECH GRASE，可能不 padding 的话正好落到 1400 附近，而 padding 的话随机 0-256 又不太够，所以可能应该调整一下默认参数了？@yuhan6665

我的意思是随着 Chrome TLS 默认有了 X25519MLKEM768 和 ECH GRASE，可能不 padding 的话正好落到 1400 附近，而 padding 的话随机 0-256 又不太够，所以可能应该调整一下默认参数了？@yuhan6665

原 padding 是针对这几个包：
client hello 长度 28x 或者标志性的517
CCS+client handshake finished 长度 8x
第一个 application data 可能是 h2 settings 长度 6x
后面两个包短太显眼了 所以弄成（网络中）比较常见的长度 而 server hello 长包就是用的 0-256

我不太确定什么长度是比较合理的 但是如果合理当然可以改

我不太确定什么长度是比较合理的 但是如果合理当然可以改

这两天我观察一下 Chrome 的流量特征，针对性改一下默认参数然后发个 pre-release 让大家试一下 gfw 的反应吧

其实我觉得现在最大的问题就是一短去一长回再开始“传输数据”，应该顺便把这个流量特征给消除掉

最好的方案是 Switch，把 TLS 握手放另一个连接然后把 h2 的部分直接拼到新连接后面，对 Vision 来说的话插一两个包应该就行