How to strengthen or improve the work of GoQuiet
rdbox opened this issue · comments
I have a question, to the developer
Advise how to improve the performance of your GoQuiet plugin
How long should I put a password of 10 or 30 characters and how often do I need to change my password?
Because the Chinese GWF with its big eye watches and checks all traffic and I want to be sure that tomorrow I will have access to the Internet
You shouldn't be too concerned with password strength. 10 characters is fine
mean if I miss http traffic through
shadowsocks + plugin GoQuiet when analyzing the traffic wireshark all packages must be SSL or TLS right?
I did a simple-obfs plugin comparison and your GoQuiet
a difference in the spine.
Immediately I feel the speed and ping became lower and it began to open faster.
To mean, apparently, traffic can not pass the analysis and its system sees as simply https surprisingly.
I'm right ?
Sorry I couldn't quite understand what you mean, but I think you are asking about TLS encryption and the latency caused by the plugin, in comparason to simple-obfs.
For the first question: this plugin does not encrypt the data. Encryption is done by Shadowsocks itself and everything is encrypted, regardless of whether HTTPS is used by your browser and the webserver. This plugin imitates TLS taffic pattern by doing handshakes and adding headers.
As for the extra latency, there could be two reasons. One being that this plugin does a TLS handshake everytime a TCP connection is established, which costs some roundtrip time, as experienced by "open slower". However once the handshake is done, the latency is negligible. The other reason could be that my code is less optimised comparied to that of simple-obfs, which adds extra time overhead.
your plugin works faster.
Now I understand, thanks for the clarification
I did a test with shadowsocks + GoQuiet enabled and that's what I saw, out of 200,000 packets that I analyzed through wireshark losses were 10%
it's a lot?
You mean the uncaptured packets in Wireshark? That is normally just due to Wireshark not being able to capture packets so quickly. No actual packet is lost.
The packages were marked in black and red.
Red color was not much 50-100 pcs.
and black more than 9 thousand
my screenshot
this collected traffic of more than 250 thousand packets
I had that with my wireshark as well. The reason that happens is that, TCP is a stream protocol with a maximum packet size of 64kb. However due to protocols lower down into the layers (the link layer), there is a much smaller maximum trasmission unit (MTU, normally ~1450b). Any IP packet exceeding the MTU will be fragmented, and hence the TCP packet built on top of the Internet Protocol is also fragmented. Since the capturing unit of Wireshark is a link layer packet (a frame), multiple frames containing fragmented data of the same IP and TCP packet needs to be grouped together by Wireshark according to the data in the IP and TCP headers, which exists only in the first of the fragmented frames.
This will cause problem when a fragmented packet that does not contain any IP and TCP header is the very first packet Wireshark captures - because Wireshark cannot find the header, it cannot group multiple fragmented TCP packets together. It also doesn't know the length of the current TCP packet and therefore cannot figure out where the next header is. So everything is out of order and Wireshark gives a lot of error.
To prevent this, you need to make sure that your internet traffic is relatively "silent" at the moment you click "start capture", so that Wireshark does not step midway into a series of fragmented packets and gets confused.