下一步计划

[e1732a364fed]

添加 给 advLayer 的调用 代码 添加 connid 参数。

主要是便于log日志输出时跟踪单个链接的状态，避免混乱。

我观察了，proxy中，只有 vless 用到了Log。 其他地方 主要是 advLayer中用到 Log的比较多。

所以proxy的函数暂时不需要该参数。也可以研究一下 把 vless 里 的 Log 输入给拿掉。

据说 v2ray 有一个 domainMatcher

mph：使用最小完美散列（minimal perfect hash）算法（v4.36.1+）。

• 测试数据约 17 万条，匹配速度提升约 30%，内存占用减少约 15%

这么好的东西，我也要。

参考
v2fly/v2ray-core#743

quic的嗅探。

这个涉及到 udpConn 读取 firstPayload 的问题。 目前的代码 根本就没有针对 udp 流量读取 firstPayload， 所以实际上这还涉及到 架构问题。

[ctermiii]

没有考虑直接支持 v2的geosite.dat吗？

[e1732a364fed]

没有考虑直接支持 v2的geosite.dat吗？

支持 geosite.dat 需要引用 protobuf 包，而这个包很大，有4MB（包含grpc的代码；我没测过protobuf包单独有多大，但是估计肯定也要2Mb左右吧），之前 的 grpcSimple包的实现刚刚解决了 protobuf包的引用，就不要再 给 引回来了吧。

geosite.dat 使用 protobuf 包实在是很差的决定，不是一个好格式。就算支持，也要其他人提交PR支持，我是不写的。

[ctermiii]

没有考虑直接支持 v2的geosite.dat吗？

支持 geosite.dat 需要引用 protobuf 包，而这个包很大，有4MB，之前 的 grpcSimple包的实现刚刚解决了 protobuf包的引用，就不要再 给 引回来了吧。

geosite.dat 使用 protobuf 包实在是很差的决定，不是一个好格式。就算支持，也要其他人提交PR支持，我是不写的。

收到。

[ctermiii]

多服务器选择策略？ leastping？

[e1732a364fed]

多服务器选择策略？ leastping？

可以考虑。 毕竟最近 大流量封杀很严重，如果能 分散服务器 肯定更好。

除了 多服务器 通过 延迟 选择一个 这个情况之外，还可以隔三差五 自动 轮换一个服务器，达到减少每个服务器的负担，减小单个服务器被审查的风险。

[e1732a364fed]

目前经过比对，认为mph算法应该使用 https://github.com/cespare/mph/blob/main/mph.go

而 v2ray 的 https://github.com/v2fly/v2ray-core/blob/master/common/strmatcher/matchergroup_mph.go

应该是借鉴了 上面 cespare 的包。

给v2ray提该PR的 作者 没有 鸣谢一下 cespare 也是不可取的，我们会加个鸣谢。

[bash99]

多服务器选择策略？ leastping？

可以考虑。 毕竟最近 大流量封杀很严重，如果能 分散服务器 肯定更好。

除了 多服务器 通过 延迟 选择一个 这个情况之外，还可以隔三差五 自动 轮换一个服务器，达到减少每个服务器的负担，减小单个服务器被审查的风险。

比较好的策略是 设定一个ping的阈值，低于这个的服务器进入轮换列表，过段时间随机换一个，但是保留老链接30分钟。

[bash99]

多服务器选择策略？ leastping？

可以考虑。 毕竟最近 大流量封杀很严重，如果能 分散服务器 肯定更好。

这个大流量封杀和 “然而，最近墙的 sni 阻断行为再一次打我脸了。看来 vmess/ssr 这种完全随机的协议还是有必要继续使用” 有关吗？好奇，哪儿有讨论？

[e1732a364fed]

刚出的ShadowTLS很骚气啊，向中间人表演一次 TLS 握手，作为 server 不再自己处理握手，而是将握手流量转发至一个可信的域名上。当握手结束则立刻跳车开始向自己的服务器中转流量。这样中间人看到的就是和 [www.gov.xx]的合法握手（观测到的证书也是合法的），而这显然是个白名单域名，这时中间人就会标记这个连接为合法连接。 就是不防主动探测，访问这个网站是不能显示实际的内容的，能不能加入ShadowTLS并实现回落，非法访问代理到可信服务上，但是限制到一个很低的网速和很高的丢包。

看起来很厉害，mark一下先。

[e1732a364fed]

shadowTLS 以后是一定要支持的，不过首先要先移植到golang上。

[e1732a364fed]

再加一个计划，protocol = "shadowsocks" 太长了，在1.3.x版本中我们应该 改一下配置定义，把它变成 proxy = "ss" 是最好的状态。

[e1732a364fed]

在1.3.x 版本中，应该重构 tlsLayer代码，添加子包支持，像 advLayer 和 proxy 包一样。

这样shadowTls等自定义tls层的代码就可以在自己的逻辑区域实现，不需要总改动总代码。

[e1732a364fed]

在未来主要版本，还将探索下面几个重要改变：

1. 链式代理，恐怕要在2.x.x 中实现，需要大量重构
2. 在Server的Handshake后，不仅返回Conn, 而且还返回一个 firstPayload。目前client的Handshake可以传入firstpayload，那么作为对应，server的handshake应该能得到一个 firstpayload

目前没有返回firstpayload，而是在Conn内部储存，不仅不优雅而且浪费很多代码，难以进一步优化

3. ConnSwitcher, 主要针对 vless/trojan/shadowTls, 有一定的握手，但是握手后，会降级为普通 tcp连接，此时目前我们总是通过嵌套的方式，不够优雅，如果能够配合上级，告知 降级的时机，就可以摆脱嵌套的烦恼了

4. server的handshake不仅返回一个Conn, 而且还返回一个 User, 可以方便分流。目前依然通过Conn内部储存，并通过接口转换方式实现，不够优雅。

结合2和4，server应该返回一个metadata。