-
Notifications
You must be signed in to change notification settings - Fork 2k
Long-term Shadowsocks Plan: ShadowsocksR versus Shadowsocks2 #501
Comments
This looks very promising from a cursory glance at the code and some machine translation. Are you aware of any English documentation?
|
@jlund |
@jlund I have shadowsocks R on a Openvz vs using this script. It works as a regular shadowsocks but when I tested the additional obfuscation features it didn't work. |
This one is better https://www.91yun.org/archives/2079
What does this mean? Which obfs feature did you use? |
@hybtoy sorry for not being clear. I have tested it long back. I remember testing this option tls1.2_ticket_auth when I tried it first time. Will spin a new server and will let you know how it goes. |
@atulsian89 what you have been testing actually? Do you know what is the purpose of the obfs in SSR? :) |
The internet was not getting connected after I selected tls1.2_ticket_auth option. I couldn't figure it out why it was not working, hence, I rolled back to shadowsocks libev version. |
It could be because of DPI, I had the same issue. After that I switched to http_simple and it works fine. Translated from Chinese to English with Google Translate and corrected by me:
Do not be surprised why one of the recommended obfuscation is plain, because the obfuscation is not always effective, depending on the strategy of the region, sometimes not obfuscated traffic looks better like random data than obfuscated |
@hybtoy I think you are correct. I never tested it again though. As you said the obfs depends on the strategy of the region, not sure which one will jlund will prefer using in the script? |
Any easy to follow guide about how to setup SSR on server and client side? I am facing problems with SS OTA and would like to try it out. A quick glimpse on SSR-libev README shows that it is not difficult to setup, however I would like to see some detailed info about how to setup the server and client side configs. Plus I wanted to ask: are there any differences with respect to performance and speed between these two protocols? Does SSR fare any better than SS? |
I'm still trying to find good documentation too. I'm not at all opposed to bringing this to Streisand if it's the right choice, but I feel like I'm missing important context when reading things via Google Translate.
The upcoming Shadowsocks protocol fork (Shadowsocks2?) also looks promising. Developments there are easier for me to follow because most of the discussions have taken place in English.
Exciting times on the SS* front!
|
For server side: use this script https://www.91yun.org/archives/2079
SSR is more secure but SS is faster. Try this setting of SSR: chacha20 (encryption) + auth_sha1_v4 (protocol) + plain (obfs) |
I was able to setup SSR successfully on the server and client side using the repo below: I used the wiki of
@hybtoy I use Linux. I was wondering if there is any GUI client for Ubuntu/Linux Mint. Do you know about it? I am still confused about the role of obfs and protocol fields in the configs 'json'. I am not sure how to set them up. But I used the default parameters "http_simple_compatible" and "auth_aes128_md5" and they worked fine. However, I couldn't see much difference between speeds of SS OTA and SSR. Perhaps there is some issue with my ISP. I would love to know, whether it is affected in other parts and ISPs of China though.
I set it up but couldn't see much difference. I will update my comment while I check it out for a longer amount of time. |
https://github.com/erguotou520/electron-ssr/releases
As I know, obfs is used to cheat/bypass QOS in China because international bandwidth is limited. |
@jlund I support that. Streisand users in China heavily rely on SS therefore it would be good to have more reliability in this area. As to the subject of this discussion, I think using SS and SSR concurrently with streisand might be possible. There is no need to replace one with the other. And since setting both of them up is almost same, therefore I think that adding SSR support would require less effort. One thing I particularly liked with SSR is the definition of multiple ports: each having their specific encryption, obfs, protocols and passwords defined in a single config file on server. It gives the client independence of using alternate ports. I am not aware if this can currently be done with SS or not.
@hybtoy Thank you for sharing this. |
I don't think that we want to run the forked and original Shadowsocks variants side-by-side. The level of duplicated functionality between the two is already high, and this is especially true with all of the recent protocol developments in the non-R variant. Now that we're no longer in a bad place with a missing Shadowsocks repo, I want to take the next couple of weeks and observe what happens. Progress on Shadowsocks2 (the protocol revamp from the non-forked version) is flying along. The new updates appear directly inspired by the work that was done in ShadowsocksR, and tickets like this one and the other SIP enhancement issues give me the impression that Shadowsocks2 (or whatever it ends up being called) has the potential to become the best of all worlds with the widest range of client support. For example, support for obfs transports in Shadowsocks is actively being worked on and there is already an Android client in the Play Store that supports it. The new Go implementation for Shadowsocks2 is looking good too. My hope is that it will provide native Ubuntu 16.04 packages, but compiling Go programs is really simple. Or we can stick to the libev variant and build it from source a la the commit I pushed tonight. Or we can switch to ShadowsocksR. These are all decent options, but I want to pick the best long-term path forward before devoting time to its implementation. |
@jlund Thanks for the kind words! I'm the author of the new Go port of Shadowsocks, and I initiated SIP007 which is also adopted by the libev port. As it stands now, latest version of Shadowsocks with AEAD ciphers using per-session subkey offers much better security and performance is excellent on modern hardwares. We at Shadowsocks.org are finalizing the protocol design and will start the difficult job of convincing client developers to adopt the new revision. It will take some time, but we're confident that it points us to a better way forward. Please let me know if you have any issues or concerns, and we can help to eliminate the pain for you to integrate into your project. Thanks! |
@riobard Thanks for the news regarding new SS ciphers.
As I understood, every new session will have it own key? It will be automatically generated or ...? Thanks. |
@hybtoy We have a detailed discussion about this in SIP007 shadowsocks/shadowsocks-org#42 |
@riobard Excellent. I really appreciate the offer to help, and keep up the great work! I think the biggest thing that I can think of outside of an official 16.04 package would be implementing backwards compatibility on the server in order to allow a mix of old and new clients to connect seamlessly. That should make the transition really straightforward. It looks like this layer already exists in your new Go implementation! The separation between shadowaead and shadowstream is exactly what I was hoping to see. I assume that it's possible to run both protocols simultaneously? |
@jlund Interesting. There have been quite a few people asking for a single Shadowsocks server simultaneously support more than one cipher/password combo. I'm not aware of any implementation currently being able to do so. Let me discuss this with other implementers and see what they think. It might make management complicated, though. On the other hand, it's always possible to run multiple instances of the server, each using different config parameters. Would you be fine with such setting? |
@riobard Yeah, that's what I meant. Sorry about the confusion. Ideally we can avoid running multiple different daemons (e.g. needing different binaries/packages installed for legacy and new protocols), but separate invocations of the same package would work just fine. The configuration and documentation for each OS/client can be modified to point to different ports/settings as clients are updated to speak the new protocol. |
@jlund This script https://teddysun.com/486.html allow to run multiple shadowsocks instances on 1 server. Give it a try. |
Sorry to ask about this again, but Shadosocks-NG dev just made latest release with OTA deprecated. Eager to know streisand can now use AEAD and if that will still be resiliant against GFW. https://github.com/shadowsocks/ShadowsocksX-NG/releases/tag/v1.5-alpha |
@hybtoy - sigh. I'm not getting into a fight with you. I don't want you to explain what the do. I said in comparison to... I'll say it again. If you want someone to buy in to a proposal, show how it's better than what's already out there. I'll make myself clearer and say again. Vanilla SS as I understand it:
That's it. There are additional things you can 'plug in'. As @riobard said:
ShadowsocksR as I understand it:
So, forgive me for wanting to be able to understand ShadowsocksR in terms of an apples to apples comparison:
I know where the cipher suites are from. But lets look at Shadowsocks.org spec: Vanilla SS: Now ShadowsocksR:
This is where I'm confused and there seems to be where you're making claims for, but not really giving information beyond, 'it's better'. I'm not trying to annoy you, I just want to help people here understand:
Then I have questions:
Why do the 'protocol' names look JUST LIKE CIPHER SUITE NAMES?!?!
Well, um, yes... but @riobard says:
But then @hybtoy says:
Why emphasise it can be turned off? If it's so important? Choice of obfuscation:
So finally, again:
This is the explanation I'm looking for @hybtoy - why is better than SS as implemented in Streisand. |
I think this thread has become rather heated & the discussion is rapidly becoming unproductive (and too much for me to follow!). As I said earlier I consider support for modular Streisand services that can be enabled/disabled the primary blocker for beginning to consider ShadowsoksR support in Streisand. I would say the same about adding any new services, Shadowsocks based or not. The other blocker is the actual development of ShadowsocksR support. There are a lot of strong advocates in this thread for Streisand adopting ShadowsocksR but no pull requests :-) For me this conversation has to be on hold until the two things above are resolved. If the discussion can be kept constructive I will keep following it, otherwise I'll have to lock the discussion. Thanks everyone, |
@nickolasclarke - What is your experience using a |
By the way, what is the protocol of SS?
Maybe because name of protocol describes which technology used to make it?
|
reinventing wheels? Are you kidding? If obfs already included (not as plugin) and using it by default is "reinventing wheels"? |
I will express my opinion as a user rather than a developer here. After following this discussion, I tried configuring the
The results might vary between locations and ISPs. In my particular case obfs helps. Though I think configuring the I haven't worked on Ansible, so I might have to pass a learning curve. But I am willing to work on this if it is considered a good idea. However, a downside is that it might complicate the generated instructions at users' end. |
@Denoza any pointer on documentation for enabling |
@nodje https://github.com/shadowsocks/simple-obfs is where the project is found and there is some documentation on how to use it. @cpu my experience matches those of many others here who have said that shadowsocks-libev is working for them just fine in China. Our installation has anywhere from 20-50 concurrent users at any given time during the day, and I get excellent performance. I often run everything through shadowsocks if I am not using domestic sites because I get significantly better performance for even for foreign sites that are not blocked. This emphasizes the very LARGE role that good routing and peering plays for your installation, both with your local ISP and the particular data center being used. In other parts of the country I've seen much much worse performance with an identical setup but using a different local ISP and/or remote datacenter. I think that trying out simple-obfs and or implementing some of the other plugins like KCP now supported by shadowsocks may help address some of the performance concerns people have. I think that sticking with the much better documented and still quite obviously active shadowsocks project makes the most sense for now. perhaps we could reach out to @riobard or others privately or publicly to help us understand what is considered "best practice" for optimum performance of SS these days. |
As I know, Shadowsocks for Windows doesn't support simple-obfs, does it? |
@Denoza That's really interesting! Thanks for adding this experience to the ticket. I've opened a separate issue to investigate using @nickolasclarke Thanks for adding your experience. Hearing your take makes me feel better about the path I think Streisand should be taking here with respect to waiting on modularity and focusing on the existing shadowsocks-libev infrastructure until there is an easier way to optionally add components to Streisand. We can't make everyone happy all of the time but I hope the folks that are left unhappy in the short term understand that this is a decision stemming from practicality and not xenophobia or ignorance :-) |
As @nickolasclarke mentioned, https://github.com/shadowsocks/simple-obfs is the place to begin with. After following the instructions, the easiest way is to add the relevant flags in JSON files. After that just restarting the services will do. I am not sure about the client side support for this feature. But as per my experience, shadowsocks-libev shows it as an experimental feature up until version 3.0.6, android client also supports it as I recall.
@hybtoy I am not sure about that, since I use shadowsocks-libev on both server and client sides.
@nickolasclarke After having a glance at shadowsocks/kcptun repo here: https://github.com/shadowsocks/kcptun, I am a little confused with the level of encryption available with it, although it looks promising, with the performance benchmarks mentioned. Further look into the README mentions following ciphers:
@cpu Yes, in comparison to replacing the whole component (SS with SSR), I think that this direction is simpler to pursue and easier to implement. |
The primary goal of kcptun is not to circumvent GFW but to combat high packet loss for some ISP during peak hours (e.g. China Telecom at night). It breaks a TCP stream into UDP packets and applies its own congestion control to send those UDP packets. TCP congestion control is implemented by the OS in kernel space. Users are discouraged to touch it for good reasons. Essentially kcptun moves congestion control from kernel space to user space (and switching from TCP packets to UDP packets), so that users can use a different congestion control algorithm than the one from the OS. Additionally, kcptun uses forward error correction to further combat packet loss (at the cost of reduced bandwidth). The effectiveness of kcptun depends heavily on how aggressive your ISP throttles UDP traffic. Again, the idea of sending more UDP packets when the network is already highly congested seems to be at odds with ISP's traffic engineering practices. At best high volume of encrypted UDP packets looks a lot like BitTorrenting which is usually the primary traffic load to be removed by many network administrators (e.g. corporate network with limited bandwidth to the Internet). |
Hi, Just wanted to know what you guys think of the shadowsocks traffic detection apps made available by shadowsocks and shadowsocksR developers. Do you think they point to possible weak points and areas of imporovement? Here are the links: |
Hi @OneHappyForever, I opened an issue for this discussion on the Streisand-Discussions repo: StreisandEffect/discussions#25 In the future please avoid adding new topics of conversation to existing threads & favour the discussions repo for non-code related topics. Thanks! |
Hi @cpu Sorry about that :) |
Guys, does anyone know why ShadowsocksR repo is not available anymore? There is no info. I am freaking out ... Sorry, but I didn't really know where to ask this question :( . |
The creator of SSR deleted all repositories |
She said it was because of the ss traffic detection tool and conflict with the ss development team. According to breakwa11, the développer of ssr, she received many complaints and even death threats. Edit: don't freak out completely, as there are backups. It just means it will no longer be maintained or updated. People may fork it and continue to work on it, kind of like what happened after cloudwindy deleted all ss repositories. |
@SquirrelCoder @OneHappyForever Hi 👋 This isn't a great place for general discussion on ShadowsocksR (or the overall Shadowsocks ecosystem). This is a ticket specifically about adopting ShadowsocksR in place of shadowsocks-libev for use with Streisand. It would be helpful to the Streisand maintainers if you could move discussion that isn't about that specific topic to a new venue. It's taxing to keep up with the open issues/pull requests that pertain to Streisand and discussions on the general Shadowsocks ecosystem are not actionable for us. Thanks for understanding. If this continues I'm going to have to lock the thread. |
Since the ShadowsocksR repo is now deleted I'm going to close the thread. I was opposed to Streisand adopting ShadowsocksR before and now that it appears to be further fragmenting into more forks I have an even harder time imagining that it would be a good replacement for Shadowsocks-libev at present. Thanks! |
I just thought that the info regarding shadowsocksR being deleted by developer is important to this issue regarding whether to choose shadowsocks or shadowsocksR. Edit: this will be my last post on this thread. |
@OneHappyForever I agree that was a relevant fact :-) Thank you for sharing. I'm hoping to curb too much follow-up discussion. I don't mean to be rude. |
I understand, no worries! Keep up the good work. :) Cheers |
Hey all,
It will be better to use ShadowsocksR instead of Shadowsocks, because with SSR traffic is obfuscating and SSR uses more secure encryption protocols.
https://github.com/breakwa11/shadowsocks-rss
https://github.com/breakwa11/shadowsocks-rss/wiki
The text was updated successfully, but these errors were encountered: