Closed caizixian closed 9 years ago
请尽可能提供信息以便我能重现这个问题,如服务器端版本,加密方式,超时时间等等。如果还是无法重现,建议把服务器配置发我邮箱,我连接试试。
还有操作系统版本。
已经重现 图片在 #22 加密方式aes-256-cfb timeout:600ms 服务端 ss-python:2.4 服务器 Ubuntu 12.04 x86 14.04 x86 CentOS 6.4 x64 6.5 x64均有问题 客户端 Windows 7 SP1 x86 socks5直接,不经过pac
客户端操作系统是什么?另外出现问题的时候都是直接连 socks5 代理吗?
我是Windows 7 x64,浏览器使用的是SOCKS5,未使用PAC(PAC文件手动清空)。
服务端情况未知(租用的服务器),加密方式为AES-256-CFB。
我也是 7 x64,重现不了这个问题。把服务器配置发我邮箱吧。
还是重现不了,不过想到了一个可能的原因,明天改一下试试。
辛苦了~
可以试试这个版本有没有解决:
https://dl.dropboxusercontent.com/u/21440890/Shadowsocks.zip
@caizixian 我跑了一天没遇到这个问题,这种情况可以像 @chenshaoju 做的测试一样看一下是数据被截断还是数据损坏吗?
@clowwindy 刚才刷知乎,重现了一下
Bad
Normal
能否把有问题的资源文件导出出来,和正确的文件对比一下看看是截断还是内容错误?
@clowwindy 抱歉,非开发机,没有diff
comp good.jpg bad.jpg 比较 1 (2).jpg 和 1.jpg... 在 OFFSET 2C80 比较错误 file1= EF file2 = C9 在 OFFSET 2C81 比较错误 file1= 20 file2 = 45 在 OFFSET 2C82 比较错误 file1= 18 file2 = 4D 在 OFFSET 2C83 比较错误 file1= 24 file2 = 6B 在 OFFSET 2C84 比较错误 file1= 73 file2 = FD 在 OFFSET 2C85 比较错误 file1= 4C file2 = 77 在 OFFSET 2C86 比较错误 file1= 43 file2 = 3A 在 OFFSET 2C87 比较错误 file1= C file2 = 70 在 OFFSET 2C88 比较错误 file1= 91 file2 = AE 在 OFFSET 2C89 比较错误 file1= 26 file2 = 96 10 个不匹配之处 - 退出比较
试试这个版本(只需要试对应你的 .net 版本的那一个文件):
2.0 https://dl.dropboxusercontent.com/u/21440890/Shadowsocks-win-2.0.6-dev1.zip
4.0 https://dl.dropboxusercontent.com/u/21440890/Shadowsocks-win-dotnet4.0-2.0.6-dev1.zip
另外能否提供 CPU 型号和内存大小。
2.0.6 是哪些网站有问题呢。我昨天终于找到了一个网站有这个问题,2.0.6 修复后问题很少出现了。换 gui 出现的频率是一样的。
最好是打开 chrome 的网络把载入过程中的错误截个图。这样可以看到具体是什么错误。光知道有问题是没用帮助的。
刚测试了一下2.0.6,仍然有问题:(网址是糟糕站,要登录……)
此现象不一定能复现,似乎是随机的,相同服务器用node.js版本没有此现象。
出现的频率是怎样的呢? 另外有没有其它不需要登陆又能很容易重现这个问题的网站?昨天刷了一晚上但是太难遇到了。
不高,但是10分钟内可能会出现一次。
可以用这个地址测试: http://www.pixiv.net/search.php?s_mode=s_tag&word=Fate
另外,我注意到有轻微的内存泄漏(?)问题,从开始测试的26MB左右,逐渐上升到36MB。
EDIT:连续运行5小时后,内存消耗维持在33MB左右,不是内存泄漏。
@caizixian 具体频率大概多少呢。另外能否多给一些具体的 URL,我观测到有的网站容易出现,有的难出现。这和网站是不是 Connection: Close 以及具体的 TCP 行为有一些关系。我昨天刷了一晚上也很难重现,如果你能多提供一些具体的 URL 和对应的 Network 截图我这边会容易许多。如果发现有些网站就是不出现,跟有些网站就是会出现,那问题就好办了。 现在有几个可能的原因,但因为每次修改后都要用很长时间来尝试重现,太花费时间。
@clowwindy GitHub(头像全没了) GMail(左侧的Hangout加载不出来) 都经常出现
@caizixian 这是一个做了一些粗暴处理的特殊测试版本,如果还是有问题就说明问题可能比较复杂,只能等周末再看看了: https://dl.dropboxusercontent.com/u/21440890/Shadowsocks-win-noclose-2.0.6-2.zip
我找到问题了maybe....另外开个坑吧
@mengskysama 什么问题呢
极有可能是跨线程调用DLL产生的!
刚刚测试用idm多线程挂下载发现重现几率100%存在下载数据错误,回退到了改版前我提交的那个OPENSSL版本,问题解决。
SERVER端我用我的,CLI用你的最新分支,IDM下载QQ速度较快,基本上维持6M/S,下完提示数据有问题。然后会用单线程重现下一遍,这个过程是100%重现的。 用libev或者py,或者0.12没有这个问题。
然后还发现windows平台下效率差距很大。。。。
@mengskysama
用libev或者py,或者0.12没有这个问题。
是指客户端么?加密方式是什么呢?
AES-128-CFB
效率差距很大是指什么和什么之间的什么效率?
先不说效率吧,先把数据错误解决,我测试来看WINDOWS下面 .NET这个比其他都要快很多。
libev 和 py 在 windows 上都是 select,很烂 nodejs 也是 iocp,应该很快
效率问题感兴趣看着几个截图,不用怀疑我这个网络波动,很稳定的,下载源是CDN。
http://blog.mengsky.net/test/images/ss/ss.rar
LIBEV利用率始终上不去(buff2048) 估计是跨平台原因,CPU反而比,NET要2倍多,你可以看看我那几张图。.NET的服务器客户端CPU占用基本持平的。
0.1.2你给的是1500我改到了buff4096能跑满7M/S(因为我的CPU到瓶颈了不能确定)
nodejs很吃CPU,在我这也不行
HEAD版本这个速度跑的话下载必然错误。你有TEAMVIEWER的话我可以给你看
openssl 太大了,即使精简也只能弄到 500KB,polarssl 代码很简单,就几个函数……尽量用 polarssl 吧 我之前把 encryptor 所有函数都 lock 了一个全局的对象,问题依旧……而且我用 table 偶尔也能重现出错误。但是如果我把所有的 close 全去掉,似乎就好了。
之前的排查记录在下面。下面每次尝试都是刷了十几次网页的结果,问题就是能否重现比较随机,有时不出错不代表这样就修好了,只是偶然。
推测 1 和 close 有关系
尝试 使用 nodelay
结果 现象没有变
推测 2 和加密的锁有关系
尝试 把 encrypt decrypt dispose 加上几个全局大锁
结果 现象没有变
推测 3 和 aes 加密方式有关系
尝试 把加密方式改为 rc4-md5,注意此时服务器换成了一个网速较快的
结果 有所好转,错误重现不出来,换回 aes 之后错误又频繁出现
aes 和 rc4-md5 有什么区别?
1. 速度
2. 是否需要 iv buffer
3. context 大小不一样
推测 4 context 大小不够
尝试 aes context 增加 10240
结果 现象没有变
推测 5 和 Dispose 有关
尝试 不 dispose
结果 现象没有变
推测 6 和 加密有关
尝试 同服务器换成 table 加密
结果 可以重现很少的 length mistmach,别的暂时重现不出来
尝试 同服务器换 rc4
结果
推测 7 网站本身有问题
尝试 直连网站
结果 无法重现
推测 8 有可能有多个问题,先修 length mismatch
尝试 把 StartPipe 以后的 this.Close() 全部换成另一个方向 Shutdown(send)
结果 没有变
尝试 把 Shutdown(send) 删掉
结果 似乎不能重现了,但是很慢,说明和 Close 有关
你也蛮拼的
跨线程访问非托管资源有时候有坑,我以前遇到的一般都是直接崩```明天我看看吧
思路就是换 table 对比排查是加密模块的错误(table 是纯 C# 而且完全线程安全) 各种地方加锁排查线程原因 排查 close 的原因,windows 上 tcp shutdown 好像和 unix 行为有些出入?
另外如果下载出来一个错误的文件,可以和正确文件对比,看看是数据错误,还是结尾被截断(长度不够)。
你先试试openssl,我这下载大文件尝试过几次都没有错,md5都比过了。
我确定,我来回切换试了2变,TABLE能够正确下载完,MD5也能对上。 AES不行。必错。要不还是openssl吧。
不玩了,其实.NET提供了一个AesCryptoServiceProvider,干脆把库都给丢了,原生自带纯天然无公害。
2.0 没有……
IDM 下 QQ 这方法好,我现在也能 100% 重现了,这下简单多了。
更新 2.0.7 改成 OpenSSL,这样体积大了不少,暂时先这么用着吧。PolarSSL 再慢慢改。
@clowwindy @mengskysama 貌似没问题了,为什么不试试LibreSSL呢?
@clowwindy 好像openssl也得加锁来着,我在写服务端的时候不加有些网站请求回来头4字节8字节正确,后面都不对,或者直接在chrome里面变下载了,晚上我回去再看看。
@mengskysama 现在 Local 的 Close 不会发生 race condition 了,不需要再对 encryption 模块加锁 你需要在 Server 里合适的地方加锁
改用 OpenSSL 之后就好了只能算是碰巧绕过了这个问题,但是这个 bug 还是得找出来,因为可能有其它隐藏的问题。
@clowwindy 没错
@clowwindy 其实我倒是觉得可以直接使用AesCryptoServiceProvider,从3.5开始就有这个Class了,为什么一定要强求使用2.0呢。。。我记得Win7好像是自带了3.5,这样一来大家还是都不需要安装额外的库。如果担心XP的话,反正XP也没自带2.0,都是要装一遍,为何不装自带了2.0的3.5呢。。。
@wzxjohn 如果这个 bug 不是加密库导致的,而是别的原因导致的,只是正好绕过了这个 bug 也不行啊。bug 还是要找出原因的。
情况1 400 Bad Request等 Your browser sent a request that this server could not understand. Sorry for the inconvenience. Please report this message and include the following information to us. Thank you very much!
各种网站都有可能提示request header错误
情况2 偶尔还会弹出选择文件保存路径的窗口,即浏览器试图另存为网页
情况3 如图![default](https://cloud.githubusercontent.com/assets/2891235/4964530/80bc6554-679d-11e4-9851-1fa7d539778e.PNG)
通常刷新后解决 环境:没有使用PAC,直接手动配置为使用SOCKS5