[讨论]性能怎么样,功能方面和实现方面如何设计的。

[qeatzy]

请问，性能怎样? 1 延时低吗，尤其是打开多个浏览器窗口时。（比如用Vimium，谷歌搜索后一次打开10来个后台窗口，然后一一查看。） 2 连接数多时，服务器端性能如何？ 3 对墙的动作有什么防范吗？假如被针对的话会如何？ 4 后续维护的动力如何？ 5 高级功能方面有考虑过吗？ 6 是自用或小范围使用，还是想做大推广？预想的用户群体是什么，开发者，还是一般用户？ 7 如果别人要入坑的话，理由是什么，什么地方有吸引力？

[gaukas]

aspect do you want to talk about

Can't really name one. My first priority in foreseeable future will be to keep utls and tlsfingerprint.io up-to-date. Also, I have proposed the idea of uquic and quicfingerprint.io to my PI. I hope we can get it rolling asap. If you had any thoughts on design or features for a tunable quic library in terms of anti-censorship, it would be much appreciated.

efficient & simple & flexible

🤔 Man it almost sounded like an impossible trinity! But you are right, it is too easy for censoring parties to act specifically against one popular approach.

Emerging on one approach & one implementation is dangerous.

That's basically why I am so eager to hear more about censorship-proof approaches instead of another IT WORKED YESTERDAY. Tbh I'm fed up with this cat-and-mouse game... sigh (even tho I know it will always be a cat-and-mouse game lol)

[qeatzy]

efficient & simple & flexible

This the the tradeoff part.

• instead of decoupling, tighten core structure to avoid allocation/locking etc.
• carefully design core, make api simple without sacrifice performance,
• keep internals simple by utilizing proper language constructions
• be prepared for custom front end instead of a fixed one (flexibility). code more expressive that json.

Basically it's removal of flexibility from core, leave it to users with proficiency & passionate, with a decent default one for regular use. It's splitting responsibility into two categories, core developers focus on efficiency & simplicity & stability, power user innovate on front end. If you look around the issues, there are too many focused on front end, only minimal touch on the core if any. Provide a front end 小而美 , leave front end 大而全 to power uses and client writers. Communicate through contract, instead of a large façade. linux kenel & distro/desktop might be a good example here.

this cat-and-mouse game

You can search below words.

本来不应该这么左支右绌的。

the second premise

And for those who are interested with persistent tunnel & handshake & forward secrecy & low delay. Search below

mutiplexing proxy

My design

[qeatzy]

As for udp implementation and quic.

我决定采取后者，放弃kcp，实现类似quic的multiplexing方案。(1 魔改quic 2 自研)

I'd like to see both survived, ...

I'm implementing a lightweight udp multiplexing protocol. Adapting from current persistent tcp tunnel approach. Also open to contribute to other QUIC versions.

[qeatzy]

net4people/bbs/issues/9

[gaukas]

net4people/bbs

Thanks for mentioning this one. I have come across that paper published on FOCI'20 years ago but had never gave it a detailed look. And it does make a point on high-availability censorship circumvention designs.

[qeatzy]

l mention this one because it echoes my current tcp persistent tunnel implementation. Same goes for mention of chrome's connection management and SPDY at https://github.com/enfein/mieru/issues/8#issuecomment-1156197906

[qeatzy]

https://github.com/v2ray/v2ray-core/issues?q=is%3Aissue+comments%3A%3E20

https://github.com/v2ray/discussion/issues?q=is%3Aissue+comments%3A%3E19

Edit, add more. State of QUIC proxy support · Issue #77 · klzgrad/naiveproxy CDN support? · Issue #74 · klzgrad/naiveproxy

https://github.com/EAimTY/tuic

https://github.com/v2ray/v2ray-core/issues/2889

https://github.com/XTLS/Xray-core/issues/625#issuecomment-955949568

[bash99]

Just my 2 cents.

1. I've experienced protocol whitelist in my local ISP (a small ISP but the only one in my company's office building),only 80/433 is open. at that time, ssr/http_simple is ok but other protocol (ss/vmess/brook...) is failed. I think it's in 2018 or 2019, CCP's 19big ?
2. trojan-go use SMUX for multiplex, someone said it's much better than v2ray's mux design (which I found unreliable in bad network, perhaps tcp HOL problem). I'm not sure SMUX can solve tcp HOL problem.

[qeatzy]

@bash99 Yeah, that's nothing new.

https://github.com/net4people/bbs/issues?q=is%3Aissuen+block

and these ones https://github.com/enfein/mieru/issues/8#issuecomment-1168275840 , years ago.

The sad thing is development stagnate for too long, and everyone is believe what he/she want believe & just repeat bold assertions & spread suspicions & .

Everyone can and should say words he/she want to say. But the world will not become any better with 2cents & is there any difference with xxx & xxx is meaningless & xxx is not needed since i don't need that you can open pr & I got a idea & my finding are xxx & non-tls is dead end .

Please, do read, research, and work towards it.

[moranno]

@enfein 后续发现，上述性能的提升跟multiplexing关系不大，目前看来主要是程序优化的结果。

针对单个client connection对接多个tunnel multiplexing意义不大，反而代价明显。只对运营商只针对ip/port[TCP/IP的四元组限速才有意义，这种场景应该是越来越少。而代价很明显，需要synchroniztion，只要有一个tunnel慢/丢包就会极大的影响。食之无味，弃之可惜。

真正有用的multiplexing是针对多个连接的multiplexing，类似HTTP 2的那种长连接，但这就要引入packet的概念，类比tls record，像ss一样无脑socks stream肯定是不行的。

关于multiplexing（多路复用），实际使用中发现中网络状况不太好的情况下，速度损失巨大：

https://github.com/e1732a364fed/v2ray_simple/issues/128 quic+bbr相比trojan tcp+bbr在网络质量不佳的环境下提升巨大： https://github.com/XTLS/Xray-core/issues/975#issuecomment-1182579967

另外请问下，你的项目进展如何？希望能看到后续更新。

[moranno]

自己写的协议，稳的很，3楼里5.3的情况下都稳的很。思路见 shadowsocks/shadowsocks-org/issues/196#issuecomment-1130808838 shadowsocks/shadowsocks-org/issues/183#issuecomment-1130801232 长期来看，加域名可不是什么好点子，SNI阻断安排的明明白白的，cf之类迟早被玩坏，不信，看泉州就是。

能否分享下你自己写的协议？或者购买私有使用也行。如果可以的话，我的tg：@missmoranno

[qeatzy]

@moranno

能否分享下你自己写的协议？

It's already told. Basically it's ecdh handshake + multiplexing. Please refer to previous comments, eg, https://github.com/enfein/mieru/issues/8#issuecomment-1159453773

[moranno]

@moranno

能否分享下你自己写的协议？

It's already told. Basically it's ecdh handshake + multiplexing. Please refer to previous comments, eg, #8 (comment)

感谢回复，我说的是可以编译使用的代码（我可以在你的基础上做一些开发完善）或者开箱即用的解决方案。不是设计思路。

[qeatzy]

@moranno No open source plan. Reason already stated. eg, https://github.com/enfein/mieru/issues/8#issuecomment-1153060183

Edit Also no social media contact. Remember lessons guys.

[moranno]

@moranno No open source plan. Reason already stated. eg, #8 (comment)

明白，所以我之前说私有购买使用（可usdt，我也不会公开）