关于SSR客户端

SS的作者停止了原有开发，但breakwa11?继续在原有SS基础上开发出了全新分支SS-SSR，很意外ssr的作者还是个上学的小孩子。twitter主页地址

1、关于SS-SSR

1-1、版本特点：

• 全能代理，同一端口支持socks4/socks4a/socks5/http
• 节点统计，包括延迟、连接数、当前下载速度、最高速度、出错率等等
• 连接管理，随时断开指定节点的连接，或修改节点后自动断开
• 协议转换，把UDP包封装于TCP里发送，或把TCP包封装于UDP里发送
• 多重代理，通过设置前置socks5/http代理，可达到任意重代理
• 协议插件，支持自定义协议和协议混淆

1-2、意义：

SSR版本的出现，改变了SS单纯的TCP发包模式，利用UDP和TCP转换，将协议流量特征降到最低，同时混淆及自定义协议接口，将流量变成隐性且不易察觉，特别是后期redirect参数，甚至可以将Twitter的流量伪装成bing的流量发包传输，整体来说SSR版本后期定制性不可小觑。

1-3、兼容性：

SS-SSR版本向下兼容原版SS，如果新客户端有SSR版本，则可使用新版特性。

1-4、客户端下载：（底部相关下载中）

• Windows客户端
• Merlin 固件
• Android客户端 （测试版，不推荐）

现有客户端完整支持的只有PC和Merlin上，iOS上的Surge等还不支持，不过因为向下兼容，就算使用不到新特性也可在原有模式下继续运行。

2、客户端使用

1、Windows客户端

下载后，和以前一样填入账号信息即可：

填入相关账号信息即可，关于TCP协议和obfs混淆插件下部分“进阶设置”会讲，不过无论选择哪种协议和混淆模式都必须服务器端支持。

TCP和UDP互换一般不建议使用，如果使用需要服务器端支持UDP转发（SS-Python都支持）

2、Merlin固件：

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

3、进阶设置

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

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

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

YouTube 4K HTML5使用前后对比：（上是使用前）

综上所述，如果在选择插件方式的时候，还是建议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进制整数，表示最大客户端同时使用数。