最大四倍加速:开启Shadowsocks客户端的混淆协议

20160405102739

2016年4月,站长对所有服务器进行了升级,本次升级主要完成两项改进和提升,本次服务端升级有哪些改变?

1、所有线路开启UDP转发支持,游戏玩家、一些对UDP有需求的用户有福了。

2、升级服务端版本,可以完美的匹配ShadowsocksR(简称SSR)客户端的各项功能,其中最大的变化就是可以使用SSR客户端的混淆协议,彻底防干扰,有的用户甚至达到4倍的加速效果。

如何使用混淆协议?

如果你是个懒人,大部分用户只看下面第1项傻瓜式教程就可以了。

如果你想更详细的了解混淆协议的方方面面,以达到更好的优化,请继续看第2项进阶教程。

傻瓜式教程

默认是上图,可以把每个节点都修改为下图这样:

QQ图片20160405114833

Merlin固件:

在Merlin SS设置界面将使用SSR打钩,混淆模式填入即可:

SS全新协议模式-SSR 说明及客户端下载 2016.1.5更新

没有什么是完美的,一千个用户就有一千个环境,如果你设置后出现翻不出去的情况,请切换回原来的选项即可。

进阶教程

选择何种TCP协议和混淆模式因各地区和服务器线路属性而定,这里面的变量太大,就是原作者也无法提供一种准确的恒定参数,那么首先看看各参数的解释(来自作者Wiki)

最大四倍加速:开启SS客户端的混淆协议

其实从上面就可以看出各种协议及插件的使用用途,TCP协议中有不同的抗攻击办法,而混淆插件可以伪装的方式也有几种,通过我这几天详细测试,在现有国内电信宽带的情况下,测试了如下数据:

最大四倍加速:开启SS客户端的混淆协议

说明:本地带宽是50M光纤,机器已经经过自己优化。错误率统计是根据SSR客户端内统计得出。

YouTube 4K HTML5使用前后对比:(上是使用前)

最大四倍加速:开启SS客户端的混淆协议

最大四倍加速:开启SS客户端的混淆协议

 

综上所述,如果在选择插件方式的时候,还是建议auth_sha1+tls1.0_session_auth的组合,特别是对Linode这种线路有较好的提升。

附官方插件介绍:

1、原始协议插件:origin或plain:表示不混淆,使用原协议

2、混淆插件:

  • http_simple: 并非完全按照http1.1标准实现,仅仅做了一个头部的GET请求和一个简单的回应,之后依然为原协议流。使用这个混淆后,已在部分地区观察到似乎欺骗 了QOS的结果。对于这种混淆,它并非为了减少特征,相反的是提供一种强特征,试图欺骗G-F-W的协议检测。要注意的是应用范围变大以后因特征明显有可 能会被封锁。此插件可以兼容原协议(需要在服务端配置为http_simple_compatible),延迟与原协议几乎无异(在存在QOS的地区甚至 可能更快),除了头部数据包外没有冗余数据包,支持自定义参数,参数为http请求的host,例如设置为cloudfront.com伪装为云服务器请 求,可以使用逗号分割多个host如a.com,b.net,c.org,这时会随机使用。注意,错误设置此参数可能导致连接被断开甚至IP被封锁,如不 清楚如何设置那么请留空。

  • tls_simple(不建议使用):模拟https/TLS1.2的握 手过程,目前未完成,server hello的应答数据不完整,但亦可使用。对于防火墙针对TLS握手协议篡改会无视,但结果是会导致此连接超时断开,浏览器响应缓慢。此插件可以兼容原协 议(需要在服务端配置为tls_simple_compatible),比原协议多一次握手导致连接时间会长一些,除了握手过程之后没有冗余数据包,不支 持自定义参数。

  • random_head:开始通讯前发送一个几乎为随机的数据包(目前末尾4字节为CRC32,会成为 特征,以后会改进),之后为原协议流。目标是让首个数据包根本不存在任何有效信息,让统计学习机制见鬼去吧。此插件可以兼容原协议(需要在服务端配置为 random_head_compatible),比原协议多一次握手导致连接时间会长一些,除了握手过程之后没有冗余数据包,不支持自定义参数。

  • tls1.0_session_auth: 模拟TLS1.0在客户端有session ID的情况下的握手连接。目前为完整模拟实现,因为有session ID所以没有发送证书等复杂步骤,因而防火墙无法根据证书做判断。同时自带一定的抗重放攻击的能力。如遇到重放攻击则会在服务端log里搜索到,可以通过 grep “replay attack”搜索,可以用此插件发现你所在地区线路有没有针对TLS的干扰。防火墙对TLS比较无能为力,抗封锁能力应该会较其它插件强,但遇到的干扰 也可能不少,不过协议本身会检查出任何干扰,遇到干扰便断开连接,避免长时间等待,让客户端或浏览器自行重连。在支持本插件的情况下建议不要使用 tls_simple。此插件可以兼容原协议(需要在服务端配置为tls1.0_session_auth_compatible),比原协议多一次握手 导致连接时间会长一些,除了握手过程之后没有冗余数据包,不支持自定义参数,使用C#客户端开启自动重连时比其它插件表现更好。

 

3、协议定义插件:

此类型的插件实质上用于定义加密前的协议,部分插件能兼容原协议。

  • verify_simple: 对每一个包都进行CRC32验证和长度混淆,数据格式为:包长度(2字节)|随机数据长度+1(1字节)|随机数据|原数据包|CRC32,此混淆插件可 完全替代之前版本制作的协议。此插件与原协议握手延迟相同,整个通讯过程中存在验证及混淆用的冗余数据包,下载的情况下冗余数据平均占比1%,普通浏览时 占比略高一些,但平均也不会超过5%。

  • verify_deflate: 对每一个包都进行deflate压缩,数据格式为:包长度(2字节)|压缩数据流|原数据流Adler-32,此格式省略了0x78,0x9C两字节的头 部。另外,对于已经压缩过或加密过的数据将难以压缩(可能增加1~20字节),而对于未加密的html文本会有不错的压缩效果。因为压缩及解压缩较占 CPU,不建议较多用户同时使用此混淆插件。

  • verify_sha1:对每一个包都进行SHA-1校验,具体协议描述参阅One Time Auth,握手数据包增加10字节,其它数据包增加12字节。此插件能兼容原协议(需要在服务端配置为verify_sha1_compatible)。

  • auth_simple: 首个客户端数据包会发送由客户端生成的随机客户端id(4byte)、连接id(4byte)、unix时间戳(4byte)以及CRC32,服务端通过 验证后,之后的通讯与verify_simple相同。此插件提供了最基本的认证,能抵抗一般的重放攻击,默认同一端口最多支持16个客户端同时使用,可 通过修改此值限制客户端数量,缺点是使用此插件的服务器与客户机的UTC时间差不能超过5分钟,通常只需要客户机校对本地时间并正确设置时区就可以了。此 插件与原协议握手延迟相同,支持服务端自定义参数,参数为10进制整数,表示最大客户端同时使用数。

  • auth_sha1: 对首个包进行SHA-1校验,同时会发送由客户端生成的随机客户端id(4byte)、连接id(4byte)、unix时间戳(4byte),之后的通 讯使用Adler-32作为效验码。此插件提供了能抵抗CCA的认证,也能抵抗一般的重放攻击,默认同一端口最多支持64个客户端同时使用,可通过修改此 值限制客户端数量,使用此插件的服务器与客户机的UTC时间差不能超过1小时,通常只需要客户机校对本地时间并正确设置时区就可以了。此插件与原协议握手 延迟相同,能兼容原协议(需要在服务端配置为auth_sha1_compatible),支持服务端自定义参数,参数为10进制整数,表示最大客户端同 时使用数。

这 样以来,将来只要简单的换一个混淆插件,让大家的特征各不相同,G-F-W就极难下手统一封锁了。推荐使用auth_sha1插件,安全性在以上插件里最 高,同时如果要发布公开代理,两个auth插件可严格限制使用人数(要注意的是服务端若配置为auth_sha1_compatible则没有限制效 果)。
在现阶段,功夫网的重放攻击(Replay attack)十分常见,建议使用能抗重放攻击的协议。

我来说说

*

*

取消
...