-
Notifications
You must be signed in to change notification settings - Fork 126
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[讨论]性能怎么样,功能方面和实现方面如何设计的。 #8
Comments
qeatzy 谢谢你对本项目的关注!
抱歉,我们目前做测试主要关注能不能翻墙,没有单独做过延时的测试。
当带宽足够时,连接数对服务器端性能影响不大。服务端的 CPU 和内存使用量都很小,带宽是决定因素。
对墙的防范主要是防止基于重放攻击的主动探测。我们的流量是完整加密的,而且添加随机填充字符,很难通过特征识别的方式发现。我们在设计协议时,参考了历史上 GFW 进行主动探测的案例,制定了针对性的防御措施。我们认为,TCP 协议有很小的概率遭到针对性攻击,UDP 协议被攻击几乎不可能。
被抓之前都会一直维护的,即便我离开天朝。最近在自学移动开发,后续可能会做安卓客户端。
请列举。
希望社区成员因为喜欢这个项目而自愿推广。不打算靠这个挣钱,所以不需要商业推广。做这个主要是为有一定技术实力的人提供一个持续可用的翻墙工具。
这句话需要时间来检验:在天朝完全变成局域网之前,我们打算做一个一直可以稳定使用的翻墙工具,不需要担心六四或者其他敏感时期梯子失灵。 |
5.1 one port multiple user |
这两个已支持。
可以尝试 UDP 协议。
已支持。
我们的期望是,socks5 传给我们域名,DNS 解析交给服务器端进行。服务器端在墙外,GFW 无法进行污染。
这个打算交给浏览器来实现。我们这里就不引入复杂的逻辑了。
支持同时连接多个服务器端。自动选择线路这件事,写出一个好的实现可能会比较难。暂时在酝酿阶段,没有具体的时间表。 |
更正一下,我先前的理解有误,这个是不支持的。如果浏览器只发起了一个连接,代理也只用一个连接。大多数站点和浏览器针对连接的使用会做优化,代理不了解用户的意图,盲目做 multiplexing 不一定能取得好的效果。 |
最近封的很厉害,大佬你这个有被封吗 |
自己写的协议,稳的很,3楼里5.3的情况下都稳的很。思路见 shadowsocks/shadowsocks-org/issues/196#issuecomment-1130808838 shadowsocks/shadowsocks-org/issues/183#issuecomment-1130801232 长期来看,加域名可不是什么好点子,SNI阻断安排的明明白白的,cf之类迟早被玩坏,不信,看泉州就是。 |
仔细看了一下你这个的设计思路,如果全密文感觉是很稳啊,没有任何特征 |
@huyi51462 我不是本项目作者。(好像造成误解了,[逃])。 我是自己写的协议,长连接实现的,仅tcp,有握手,非对称加密握手,ecdh,类似ssh。思路见上述链接。我的本意是,这事本来不应该这么左支右绌的。你仔细看下5.3是什么。 不同于本项目,我的优先级是 【多余的话,权当胡言】 |
@enfein 最近实现了multiplexing,效果挺好,当然链路状况差的时候可能会增加延时和失败率。 // https://www.speedtest.net/result/13266865xxx I agree with you that it's probably not worth to even think about multiplexing unless long running tunnel is used, but in that case it will incur a lot more challenges and require protocol overhauls rather than monkey-patching. == Edit == Edit Edit |
qeatzy 你好, 能看出来你对各类翻墙协议有深入的研究。我这个 mieru 项目倒是没有针对低延迟和网络性能做过多的优化。最早设计协议的时候,更多考虑到的是安全可靠,如果加 multiplexing 要推出下一版协议才可以。如果你有成型的项目,可以开源出来让大家一同受益。 |
huyi51462 你好, 我六四期间用 mieru 没有感觉到任何差别。mieru 的 TCP 和 UDP 协议都是不传输任何明文数据的,包括报文的长度也被加密,另外所有的加密都有 AEAD 防篡改验证,就从数据包本身来说 GFW 是没有什么办法的。GFW 可以选择使用白名单,把所有看不懂的协议都封掉,不过加速到那一步还需要一些日子。 |
成型的项目倒没有,尚在prototype阶段,也没有开源的打算。能在开源项目的项目中贡献微薄之力就很满足了(比如本项目enfein/mieru,e1732a364fed/v2ray_simple, ShadowsocksR-Live/shadowsocksr-native, txthinking/brook, geph-official/geph4,p4gefau1t/trojan-go, v2ray, ss/ssr。 比起大大+小白的模式。我更乐见百花齐放,授人以鱼,不如授人以渔。我眼中最好的社区是思维的碰撞,各种实现层出不穷,并且能相互支持,而不是圈地自萌+相互攻诘。相关的开源项目,我的看法是,共同的道+有能力有意愿的一群人+大众的收益和知识眼界的提升,这种模式,远好于几个独裁者+路人+粉丝+黑子的模式。 至于效果(稳定性,cpu & mem utilization,network delay & throughput)这个使用起来差异很大,很多时候往往是如人饮水,冷暖自知(很多时候人们无法共情别人的遭遇和困难,尤其是这里)。而我能做到的只不过是,知道自己要什么(绝对的低延时+no fuss+no headache),而不满于ss/v2ray,自己造了个趁手的轮子而已。 至于加速主义,站队等相关的话题,我是不参与讨论的,我觉得,一个人知道自己要什么,愿意放弃什么。 你如果在技术/协议方面感兴趣的话,后续可以互相实现验证。 Edit |
@enfein 后续发现,上述性能的提升跟multiplexing关系不大,目前看来主要是程序优化的结果。 针对单个client connection对接多个tunnel multiplexing意义不大,反而代价明显。只对运营商只针对ip/port[TCP/IP的四元组限速才有意义,这种场景应该是越来越少。而代价很明显,需要synchroniztion,只要有一个tunnel慢/丢包就会极大的影响。食之无味,弃之可惜。 真正有用的multiplexing是针对多个连接的multiplexing,类似HTTP 2的那种长连接,但这就要引入packet的概念,类比tls record,像ss一样无脑socks stream肯定是不行的。 Edit |
我想仔细讨论一下网络性能和反封锁两个话题。 网络性能如果用 TCP 协议,我的意见是,一个用户连接在代理中对应多个连接意义不大。以我有限的实际体验,还没有察觉到运营商对 TCP 单个连接有限速。 反过来,如果把多个连接在代理里面对应一个连接,能带来什么好处呢?减少握手的一次 RTT,另外跳过 slow start 过程,这些对降低延迟提升性能是有价值的。但是这种做法真的没有问题么?TCP 里面的数据是有序传输的,如果遇到了比较慢的请求,或者单纯的网络丢包,后面的应答就算准备好了也要等待,这是会降低性能的。想一想浏览器发起 HTTP 的时候为什么要用多个 TCP 连接。你想在 TCP 里面实现 UDP?没用啊,只要你的应用必须消费有序的的字节流,卡顿是无法在 TCP 协议内部解决的。我不认为 shadowsocks 那样 TCP 连接 1:1 对应有什么根本的性能问题。这种 1:1 对应倒是会暴露一些流量特征,mieru 尝试用 padding 来减少这种特征,但是做不到根本性消除。 反封锁我不喜欢用域名,TLS 不是为了反封锁设计的。 我和你的想法不同,我认为面向连接的 TCP 协议是有利于封锁的,加速到后期还是要依靠 UDP 协议。事实上 mieru 最早推出的就是 UDP 协议,无奈运营商的 UDP 限速对用户体验伤害太大,所以后来出了 TCP。但是 TCP 能用几年,这件事不好说。 |
这正是我上条回复说的。
My current approach. If described more accurately, it's more than thant, N local <-> M tunnel <-> N remote, as said at shadowsocks/shadowsocks-org/issues/183#issuecomment-1130801232. Even under extreme conditions like 5.3 above, I can ssh to vps through my own tunnel, demonstrating high availability per se.
senerio 5.3, already stated above.
me too. 🍺
Yes, as non-connection based protocol, it is indeed harder to targeted at, but it's already targeted by other ways (eg, qos). Yeah, if tcp way is not even possible, I will choose to use udp too, just like you choice. But who will choose worse approach if better way do exist. Though udp adoption do grow with quic deployment etc.
This is my main stance. I just proved tcp works exceptionally well, unlike many stated. Similarly, as for ip/domain, I goes for ip, not domain, contrary to some's belief I think ip approach will outlast domain ones, and incur larger cost, which is another gain.
Think about this, which probability is higher, a) tens of tunnel, already proved to work, periodically check state and re-instantiate b) tens or even hundreds of new connections. Which is more likely impacted by slow link or timeout or drop packet. Which one is more likely be affected by inspection if inspection do happen. Which one is more easily fingerprinted. Whose attack surface is larger. If you are force/required to drop packet, which one will you choose, active ones or new ones. Not to mention other security/performance gains. Yeah, they all said this is too hard, that is not needed, those are no good, but let's admit it, they are not the authors who design & implement most of it. Some may be just pretending as big lao and enjoy the feeling, some are not affected since his/her link is good or drinking coffee in San Francisco, some do want to help but cannot afford the time/proficiency or daunted by sheer complexity, v2ray, cough,cough. Even under 5.3 senerio it must not sacrifice any aspect of delay/speed, and any weaker version is unacceptable by my view, this is how I work/test it. Treat seriously about the risk/gain, the v2 author Victoria Raymond disappear years and seems no one cares. Whose treatment IMO is still worser than breakwa11. The blogger mentioned in you docs about securely surfing is gone too. Implentation detail You can wrapper around connection read/write, set time before & after syscall, maintain a persistent thread to check periodically, if now - t_succcess is too large, it suggest something might go wrong, and some action could be taken. Sidenote, as micro-optimization, do not naively get time by each op, only get time in the persistent thread since fine grained time not needed, unnecessary syscalls do affect performance. You said right, it's a lot more muddy approach and playing bad with those unprepared. It's a tradeoff of pain & gain. There is no such thing as accelerationism, it's always cost/benefit. If handshake do adopted, remember it's a different security model from tls, no certificate needed. it's more like 2 gpg holder verify each other. And please do not make mistake as v2ray to mix identification & authentication as one, which greatly hinder transparent support multiple client with same authentication, which might works with socks like approach 1:1 mapping, but a big no-no with multiplexing. Seems like you have some minor mis-understanding of multiplexing, you don't need to simultaneously tuck multiple local active connections into one tunnel, you can re-assign connection to a tunnel only if it's being not occupied. Though, in practice, too many/few tunnels is both not good. And if connection number goes high, each tunnel will be used by multiple connections. I just stick to round-robin before better way exists. In summary it's like http2, but M tunnel instead of one. |
Implementation details
with multiplexing, each tunnel reader need to get connection id for each packet. what if 100+ tunnel's simultaneously getting id interleaved with serveral newConn operations, with the total upload link speed reachs 100Mbps. There are ways to exclude connection id from packet, but then each tunnel become stateful and the burden shift to synchronization client & server side, and also reduce the utilization rate of each tunnel.
to reach for maximal speed, you need to separate read from write, which incurs transfer ownership of memory, and default gc/malloc way is far from efficient when network speed utilization is high, you need to implement arena/allocator somewhere.
similar to what you already said. |
As for high availability. Though implemented differently, they actually share same premise, -- hoping being recognized as something and do not block. ss & plain vmess hopes to being recognized as random/unknown protocol. trojan hopes to being recognized as normal web traffic. Sadly both is intrinsically flawed. The trojan family (eg, v2ray+tls etc) pretend to be normal traffic, but their users do not hold prominent domains and highly prioritized certs. With the adoption of ESNI seems gloomy. The pretending is just illusion. I pointed out elephant in the room and introduce the unexplored approach of multiplexing at here. But the reaction is all but negative. Actually it's inaccurate to say multiplexing being unexplored, since the good old ssh tunnel is precisely multiplexing, though the result is far from ideal due to single point of failure. However with M tunnel, you can get all the benefit of ssh and http2. But sadly, no one has agreed with me yet. As stated early, even if your 99 of 100 handshake failed due to drop packet or timeout, the successful one will serve you for at least minutes. Even in the most extreme accelerationists' view, it's hard to envision all tcp connection to a blacklisted ip set will never succeed. That's what I recalled the second premise. A truely yang mou. |
Similar to my choice of tunnel binding, the chrome guys adopt "late binding" since early binding is apparently sub-optimal, the final SPDY solution interleave mutliple http stream with one active socket, which is the same as my current approach, proabably with a more fine-grained session manager. Connection Management in Chromium source from gfwrev |
感谢你的长篇回复。看过之后,我意识到这个 M:N:M 的 TCP mesh 的确有可取之处。 关于之前你在 shadowsocks 社区的遭遇,我是完全可以理解的。shadowsocks 作为一个千万用户级别的产品,关于兼容性方面一定要小心谨慎。仅仅是为了应对主动探测把 infinite read 改成 one time read 这件小事,都会导致一大批 shadowsocks 实现无法与新版本一起工作。像你这种翻天覆地的架构变化,在社区看来一定是来砸场子的。 由于你这种想法与已有的各类翻墙软件的实现均大为不同,已有的软件要么出于兼容性的考虑不能改协议,要么会因为加入新协议变得更加臃肿(参考 v2ray),要么有兴趣但是出于理解水平和技术实力做不到期望的效果(比如本项目,另外,我真的很缺时间)。所以,最好的办法依旧是另起炉灶创立新的开源项目,用实际的用户体验赢得声望。事实上我作为近几年长期使用 shadowsocks / v2ray / trojan 的用户,清楚知道他们各自有哪里做得不好。做出一个我自己理想中的翻墙软件,是我维持这个项目的根本动力。 做开源翻墙软件最大的阻碍自然是安全。你之前也提到过几位先烈的结局,我这里不再重复。如果安全是一个核心的考量,那么我完全同意你开发出来自用,毕竟没有任何人有义务把自己通晓的牛逼翻墙姿势传播给其他人。但是在开源社区里面,talk is cheap,只有真正拿得出项目和代码的人才有发言权。 言归正传,我已经许诺了 mieru 这个项目会继续开发下去,无论我个人今后是否用得到。我在谨慎地衡量 M:N:M TCP mesh 的可行性,或许在将来,它会成为 mieru 支持的第三种协议。如果有那么一天,还望仁兄赐教。 |
One core reason yet unmentioned for the choice of multiplexing approach is, new protocol without authentication is not reliable and not recommended at all, as already suggested by third party anticensorship organization like xxxreport years ago. Non-handshake authentication is flawed, whereas without multiplexing asymmetric handshake is too heavy. I can provide some core module implementation that are performance related as reference, if there will be someone that's determined to work on it and prepared for all kind of obstacles. Hope you make a good fortune and still has the determination. Let's hope for good and not expect the community being stagnant or go down. As for the authority in this area of open source project and community, contrary to what you said, it's rather more complex, it's not more code more power of disclosure. Let's raise two kind of samples.
|
还有一点想请教,为什么客户端和服务器之间一定需要 DH key exchange。 这里面涉及两个问题。 第一,为什么没有 DH KEX 的情况下通信的安全性或者隐匿性得不到保证?能否给出详细的论证或者参考资料? 第二,加入 DH KEX 会让翻墙协议更容易被识别。你之前提及,shadowsocks 的原理是模仿一种未知的协议,trojan 的原理是模仿 TLS 协议。这种模仿和混淆能成功,是因为未知协议的集合太大,GFW 无法进行有效的判别,另外 GFW 不容易分辨浏览器产生的 TLS 流量和 trojan 产生的 TLS 流量。如果用了 DH KEX 情况就不一样了。我假设 DH KEX 过程数据包是明文传输,那么你具体的实现一定会有具体的数据包的特征,这种特征和正常的 TLS 流量是容易分辨开的,导致你的翻墙协议被识别封锁。如果 DH KEX 是密文传输,相当于退回到了 shadowsocks 的模式,那么 KEX 的意义是什么? |
My design, e: ephemeral, l: long term, s: server, c: client
My implementation detail
The key point is
|
I do not known much detail about trojan or trojan-go, but for v2's tls, it's easily detectable, just see the many relevant issues. What's worse, it's even different from other go program fingerprint, before a fix being applied, due to fixed setting of cipher suite. That's why naiveproxy ever being created, to re-use chrome network stack to avoid that. And there seems no strong interest in improve on this fingerprint part. Their premise seems it's too damaging to ban all go programs, thus current setting is good enough. Unless some standard library provide the needed functionality out of box, seems unlikely to improve upon or provide custom choices. It's tls handshake being detected for v2's tls, since tls handshake has plain cleartext content which in predictable position, thus easily detectable. Sidenotes, that's where tor failed. -- If you do found design in previous post has some point said, please do make backup, I might delete it after some time, to avoid unnecessary debates. sha256sum doc/design-orig.txt 7565728d36ca7e9d002e612601c0af7e49313535133fdfb39b2229b31e442a09 doc/design-orig.txt wc design-orig.txt 24 292 2030 doc/design-orig.txt As for the faking as other protocol, ss did succeeded, but that's history years ago and broken afterwards, similar story with v2's tls. newer version may improve on replay part, but suspect the motivation contain anything with detectability (fixed value at fixed position with predictable length). Also tls in tls do leak characteristics, due to predictable length of tls handshake. |
@qeatzy 是的,搞错了,不过你的发言和回复对我来说也很有价值。 |
@enfein 感谢解答我的疑问,就是比较担心GFW会不会直接封锁看不懂的大流量密文(google youtube),大概每月100G,如果会的话,自己写也没多大意义。 |
精彩,受教 |
@huyi51462 对于全加密流量,如果是 TCP 协议,理论上讲 GFW 可以做深度包检测并且掐掉看不懂的连接。不过这种白名单方法很容易误杀,一时应该不会启用。如果是 UDP 协议,没头没尾,GFW 除了丢弃所有 UDP 包没有什么很好的办法。 |
@enfein 大概思路明确了,这两天我的使用可能验证了你说的GWF的行为: |
最近想尝试udp的起因是换了机房后,速度骤降,从原来的40-200Mbps降到0.5-2Mbps(极少数空闲时能达到40-50Mbps,但上升非常缓慢,之前上升非常快,很快就达到峰值),用WinMTR查看路由,丢包率达到8-13%。 初步实现的过程中,用udp传输一个64KB的文件,上行丢包率小于1%,最大不超过2%,下行丢包率始终在10以上,42K-57KB,以49-52KB最为常见。实现为echo server。
从响应速度来看,去掉 为排除其他原因,切换为一个hk服务器测试,本地1-2秒打印完成,服务器端也几乎同时完成。 参数 从上述分析,我认为在这种情况下udp大有作为,可大幅度提高性能。
而KCP实际上并不是为上述场景优化的,从它的设计思路看,以及从我之前的使用体验看(1-2年前搭配ss使用过,效果一般),好像从你的回复来看也是如此(你应该一直是KCP实现udp的吧,我记得你好像说udp不太好用)。 而且,随着网民数量的增多和外网需求增大,而国际带宽有限,至少从运营商的角度来看,丢包是几乎无代价但有奇效的手段。所以,上述场景应该是会越来越多的。 我的看法是,降速的源头是高丢包率+TCP本身的性质。那么只有通过udp来自己实现,针对性的应对。两种方案,一种直接使用成熟方案,一种自研。前一种,quic是可行的方案,目前hysteria据说效果不错HyNetwork/hysteria/issues/321,但我不认为这是普适或长久的,尤其是大规模的用户使用后。那时候就需要使用quic,但需要魔改或调参,或者自研。前者的好处在于起点高,实现难度低,缺点在于复杂度高,想调优事实上很难,也很难孤立某一部分做单独的尝试或测试。自研的缺点在于,起点低,实现难度很高,达到跟成熟方案开箱用的同等效果需要很大功夫,但优点在于灵活性高、方案复杂度可以降到相对很低,后续调优和改进能非常容易实现。我决定采取后者,放弃kcp,实现类似quic的multiplexing方案。 |
What could be the cost of having a whitelist allowing only popular protocols to a well-known IP (owned by a mainstream CDN provider?) with a good |
The ever-changing nature & the bureaucracy. |
It's never easy to minimize the collateral damage I'd say. Unfortunately. And IMO, from the very beginning, the reason for mimicking a popular protocol is always to introduce heavier collateral damage as a cost to censoring parties. |
If works, yes. It's akin to threaten someone, if it will not listen, it's futile or you are saying the wrong thing.
But https/domain name is by its nature very biased toward giants, thus the average cost of remove long tail is actually minimal. That's why whitelist is actually simpler than old blacklist for domain name. |
Closing. If you guys want to debates. Go to another issue. Just some quote.
Last word. Why I insist write in English at first, to increase the cost and prevent unnecessary debates. But futile. You big lao. 😆 Farewell. |
Come on... I feel sad if you closed the issue feeling offended. Open source is like democracy. There's no wrong idea, only good ideas or better ideas. However, all people tend to stick to what they want to hear. I'd really like to proceed with my sincere debates/discussions but if you no longer feel comfortable with it... so long.
What's a big lao btw? |
No, It's not being offensed, actually already expected many reactions, negative & positive, and the form. It's being deeply disappointed. Make me recall Lu Xun, RPRX, breakwa11, clowwindy. If you guys want to discuss, then discuss, and do the real work. Instead of good old 党同伐异/拉帮结派. The history just repeat.
so long.
guys of this kind [renyidong] at shadowsocks-rss/issues/38 |
I closed the issue, because what I want to say is already fully discussed. Though mostly of them will deemed ignored & just laughed at. Now since the job done. Let's finish it & move on. |
|
Me too. But
If you do want to talk about the design of protocol & performance tuning, new project/new issue might be a better place. Since different project might take different approach. I'm looking forward to see more open source projects (though probably will never happen, but let's just hope for good, and being prepared for the goodness). |
@gaukas Btw which aspect do you want to talk about, I'm kind of reluctant to participate some topics that inherently opinionated, but interested in real implementation that are efficient & simple & flexible so that everyone can and should own his/her own one. Bureaucracy is no good, complexity incurs bureaucracy & totalitarianism. Emerging on one approach & one implementation is dangerous. Just name a few, udp vs tcp, non-characteristics vs faking/being popular protocol, persistent tunnel vs 1:1 mapping, UoT or pure udp, detect based on header/first packets or dpi on all, detect server or detect client or detect traffic or other ways. It's too easy to stick to one. |
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
🤔 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.
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) |
This the the tradeoff part.
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 小而美
You can search below words.
And for those who are interested with persistent tunnel & handshake & forward secrecy & low delay.
|
As for udp implementation and quic.
I'm implementing a lightweight udp multiplexing protocol. Adapting from current persistent tcp tunnel approach. |
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. |
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 #8 (comment) |
Just my 2 cents.
|
@bash99 Yeah, that's nothing new. https://github.com/net4people/bbs/issues?q=is%3Aissuen+block and these ones #8 (comment) , 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. |
关于multiplexing(多路复用),实际使用中发现中网络状况不太好的情况下,速度损失巨大: e1732a364fed/v2ray_simple#128 另外请问下,你的项目进展如何?希望能看到后续更新。 |
能否分享下你自己写的协议?或者购买私有使用也行。如果可以的话,我的tg:@missmoranno |
It's already told. Basically it's ecdh handshake + multiplexing. Please refer to previous comments, eg, #8 (comment) |
感谢回复,我说的是可以编译使用的代码(我可以在你的基础上做一些开发完善)或者开箱即用的解决方案。不是设计思路。 |
@moranno No open source plan. Reason already stated. eg, #8 (comment) Edit |
明白,所以我之前说私有购买使用(可usdt,我也不会公开) |
请问,性能怎样?
1 延时低吗,尤其是打开多个浏览器窗口时。(比如用Vimium,谷歌搜索后一次打开10来个后台窗口,然后一一查看。)
2 连接数多时,服务器端性能如何?
3 对墙的动作有什么防范吗?假如被针对的话会如何?
4 后续维护的动力如何?
5 高级功能方面有考虑过吗?
6 是自用或小范围使用,还是想做大推广?预想的用户群体是什么,开发者,还是一般用户?
7 如果别人要入坑的话,理由是什么,什么地方有吸引力?
The text was updated successfully, but these errors were encountered: