大家好,欢迎来到IT知识分享网。
官方网址:http://ss5.sourceforge.net/
场景描述
在支付项目的开发中,出于安全的考虑,App所部署的网段,不能直接访问公网,所以需要通过技术手段,让其可以访问公网。
尝试了几种方法,各有优缺点:
Nginx转发,缺点是证书传不到第三方,不可接受;
RINETD转发,缺点是只能转发到固定IP,不可接受;
配置路由规则,缺点是会对整个机器路由产生影响,不确定是否安全可靠;
Socket5代理,缺点是要改代码,但是可以代理Http/Https/Ftp等,可以满足要求。
SS5安装
关于SS5的安装过程,网上多有教程,不再赘述,比如,可以参考这个网址:http://lxsym.blog.51cto.com/1364623/769691 。
SS5压力测试
网络监控方法
dstat命令,所代表的receive/send,貌似receive是接收的字节数,*8是带宽,而send并不是机器对外网发送的字节数,故不用它判断收发流量;
iftop命令,在实验场景下(每秒大约4个baidu首页请求,接收流量大约138KB*4),显示的发送和接收的流量,和程序计算的每秒发送接收流量基本一致,故采用这个命令,判断网络流量。
SS5日志
1、STARTED和TERMINATED是配对出现的,代表一次连接的开始和结束
[08/Apr/2015:19:46:57 CST] [1035835136] 10.10.96.106 “” “CONNECT” STARTED 0 0 0 (10.10.96.106:55389 -> 220.181.112.244:80)
[08/Apr/2015:19:48:03 CST] [1035835136] 10.10.96.106 “” “CONNECT” TERMINATED 23189 352 66 (10.10.96.106:55389 -> 220.181.112.244:80)
2、不是每一次代理请求都会被记录下来
当我们访问公网时,由于一次Socket请求(Client:IP+Port和Server:IP+Port)会延续较长时间,所以基本不会在1秒内被复用,所以基本都能记录日志;
当我们测试访问一个内网URL时,1秒内完成几百次成功的Socket请求,很多被复用,对于1秒内“Client:IP+Port和Server:IP+Port”相同的Socket,SS5认为是一个,只有1行日志;
这样,可以解释,访问内网URL时,几千个成功的请求,只有几百行日志的场景。
以上两种日志场景,我们都认为是正常的。
3、Socks method unknown or bad request
telnet 1080端口,输入字符;或者F5心跳检测1080端口,都会导致这个日志不断报出。这个应该通过更好的配置过滤掉。
性能指标
大并发情况下,Socket连接没有正常及时释放,或者到达临界值,如下错误报出。
日志会报如下错误(刷屏):
[08/Apr/2015:16:06:23 CST] [0] [ERRO] $S5ServerAccept$: (Too many open files).
[08/Apr/2015:16:06:23 CST] [1916823296] [ERRO] $S5GetClientInfo$: (Bad file descriptor).
程序会报如下错误:
java.net.SocketException: SOCKS server general failure
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:526)
at java.net.Socket.connect(Socket.java:529)
at sun.net.NetworkClient.doConnect(NetworkClient.java:158)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:411)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:525)
at sun.net.www.http.HttpClient.<init>(HttpClient.java:208)
at sun.net.www.http.HttpClient.New(HttpClient.java:291)
at sun.net.www.http.HttpClient.New(HttpClient.java:310)
at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:987)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:966)
at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:841)
at cl.an.HttpConn.run(HttpSocketPressTest.java:188)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
性能测试结果:
Socket连接数-正常临界值(约值) | Socket连接数-异常临界值(约值) | 到达异常临界值后 | |
openfiles -1024 | 450 | 550 | 报上面的Bug,只保留200个线程,35秒后恢复正常 |
openfiles -4096 | 2000 | 2100-2500 | 第一种情况: ss5异常停止,不能恢复:service ss5 status,可以看到: ss5 已死,但是 subsys 被锁;有时还会报:*** glibc detected *** /usr/sbin/ss5: free(): invalid pointer: 0x00007f693c0207e0 *** 第二种情况: 报上面的Too many open files,只保留200个线程,10秒后恢复; |
openfiles -65536 | 结果和openfiles -4096类似 |
根据我们的测试结果,可以认为虚拟机10.100.140.85(4个CPU、6G内存),最大支持2000并发。
官网的性能指标是:IBM X360,支持2500并发数。
查看Socket连接数命令:netstat -napo | grep 1080 | wc -l
查看修改最大同时打开文件数命令:vim /etc/security/limits.conf ,需要新开一个终端,ulimit -n,确认生效了,service ss5 restart,才会在ss5中生生效。
关于这个值,很多公司这样设置:
* soft nofile 1000000
* hard nofile 1000000
* soft core 1048576
* hard core 1048576
参考网址:
http://www.codesky.net/article/201105/161796.html
http://www.justwinit.cn/post/6482/
http://blog.csdn.net/leili0806/article/details/7534985
压测结果
访问www.baidu.com(页面大小:135KB)
1、囿于带宽限制(实测、抢公网带宽,只能抢到1.5M-2M左右),所以,平均每秒,只可能有10-20个成功的Http请求返回。
2、会报java.net.SocketTimeoutException: Read timed out:这是因为网络带宽原因,Timeout时间内没有从流中读取完成数据所致的。这是正常的,网络原因,用不用Socket5代理都有这个问题。
3、会报java.net.ConnectException: Connection timed out: connect:也是网络原因,Timeout时间内,没有连接远程服务器成功。这是正常的,网络原因,用不用Socket5代理都有这个问题。
4、会报java.net.SocketException: Connection reset:怀疑是远程服务器的原因。
5、测试截图如下:
iftop:
dstat:
6、测试过程中,watch -n1 -d ‘netstat -an | grep 1080’,完全正常,SS5服务本身没有任何压力。
7、测试结果:
a、3个机器各开100个并发,成功率分别是:85%、65%、67%,失败的原因基本是Read timee out,即30秒不能完全从网络输入流中读取完成所有返回数据。
b、1个机器100个并发,成功率大约是98%。
访问内容URL
可以跑带宽大约50-60M,平均每秒250个成功返回,成功率100%,截图如下:
iftop:
dstat:
结论
- SS5服务本身能承受巨大压力,调优ulimit -n后,大约支撑2000并发。
- SS5服务,带宽足够,请求的文件越小,网络越好,就能支持更多的成功返回。
免责声明:本站所有文章内容,图片,视频等均是来源于用户投稿和互联网及文摘转载整编而成,不代表本站观点,不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益,请在线联系站长,一经查实,本站将立刻删除。 本文来自网络,若有侵权,请联系删除,如若转载,请注明出处:https://yundeesoft.com/22254.html