SSR is faster

Question

SSR is faster

x0r2d2 opened this issue 6 years ago · comments

R2-D2 commented 6 years ago

@cbeuw
After several tests it seems that SSR is performing TLS shake faster.

SS+GQ = takes 3-4 seconds to open the page

The same page with SSR tls1.2_ticket_auth opens it in 1-2 seconds.

R2-D2 · Answer 1 · Thu Mar 15 2018 22:33:02 GMT+0800 (China Standard Time)

@cbeuw
SSR support UDP relay by default, so it also perform DNS requests through the tunnel.
I have set the nameserver in SS config file, I will try to check it with out that option.

Andy Wang · Answer 2 · Thu Mar 15 2018 22:37:29 GMT+0800 (China Standard Time)

There could be several reasons:

DNS lookups. SS tunnels all DNS requests by default, this adds a lot of overhead
Browser session resumptions. If you tested the websites first with SS+GQ, the browser needs to do full handshakes with the websites which adds RTT. If you then test the same websites with SSR, the browsers can do session resumptions with these websites and save handshake time.
TCP handshake overhead between SS and GQ. SS and GQ communicate using TCP connections on loopback, which still gives SYN SYN-ACK ACK overhead. The obfs modes in SSR are probably integrated and data are passed internally. However I doubt this will make a difference.

(WTB: prompt me after I click "Close and comment")

R2-D2 · Answer 3 · Fri Mar 16 2018 12:22:45 GMT+0800 (China Standard Time)

@cbeuw
In my network, SS+GQ with turned off fast_open works faster or same as SSR.

Andy Wang · Answer 4 · Sat Mar 17 2018 06:30:33 GMT+0800 (China Standard Time)

@hybtoy
Golang's native TCPConn doesn't seem to support TCP fast open. I will integerate https://github.com/bradleyfalzon/tcp-fast-open into this project.

Andy Wang · Answer 5 · Sun Mar 18 2018 05:24:55 GMT+0800 (China Standard Time)

I'm an idiot

There is a new release

R2-D2 · Answer 6 · Sun Mar 18 2018 15:30:55 GMT+0800 (China Standard Time)

@cbeuw Thanks! A lot better!
Waiting for Android release.

R2-D2 · Answer 7 · Mon Mar 19 2018 13:00:28 GMT+0800 (China Standard Time)

@cbeuw
After several tests, still seems slow against SSR. What do you need from my side to help you to understand what is the problem?
Thanks.

Andy Wang · Answer 8 · Tue Mar 20 2018 04:47:37 GMT+0800 (China Standard Time)

@hybtoy
If you are using linux, could you please tell me the time of
time ( curl https://www.youtube.com > /dev/null )
and
time ( proxychains curl https://www.youtube.com > /dev/null )
while using GQ and SSR?
Thanks

R2-D2 · Answer 9 · Tue Mar 20 2018 11:35:08 GMT+0800 (China Standard Time)

@cbeuw
I am on Win10

R2-D2 · Answer 10 · Mon Mar 26 2018 15:55:54 GMT+0800 (China Standard Time)

Now it seems OK.
Don't know why it was slower on earlier versions.
Will continue to test.

linusyang · Answer 11 · Mon Mar 26 2018 18:38:52 GMT+0800 (China Standard Time)

@hybtoy @cbeuw I think there is no fundamental difference of performance between SSR (using its own TLS obfuscation plugin) and GoQuiet as a separate process. I made an experiment that extends SSR with GoQuiet as both a native SSR plugin and a SIP003 plugin. The speed is almost identical for both plugin modes. The only benefit of using a native SSR plugin that I could imagine is to potentially save some memory or reduce latency (though not noticeable in my tests).