Skip to main content

shadowsocks

test 1​

SS全称是Shadowsocks，是一种基于Socks5代理方式的加密传输协议。 特点:

1.Shadowsocks使用自行设计的协议进行加密通信。加密算法有AES、Blowfish、IDEA、RC4等，除创建TCP连接外无需握手，每次请求只转发一个连接，无需保持“一直连线”的状态，因此在移动设备上相对较为省电。

2.所有的流量都经过算法加密，允许自行选择算法。

3.Shadowsocks通过异步I/O和事件驱动程序运行，响应速度快。

Shadowsocks由两部分组成，客户端和服务器端。 在使用之前，需要先将服务器端部署到服务器上面，然后通过客户端连接并创建本地代理。

客户端启动后会开启一个本地代理（一般用HTTP Proxy），通过修改操作系统配置或者浏览器配置把访问请求转发给本地代理。

当我们通过浏览器访问某个地址的时候:
    第一步：数据会被转发到本地代理.
    第二步：由本地代理加密后转发到服务器端.
    第三部：服务器端处理完请求后把数据加密后返回给客户端的本地代理.
    第四步：本地代理再次返回给浏览器。
1. SS协议和Http Proxy、Socks5没有关系，Http Proxy、Socks5这两个协议是浏览器或者操作系统所支持的标准代理协议，SS的架构中只是用这两种协议作为“获取用户请求”的手段而已。
2. SS协议中没有任何控制流，本地代理获取用户原始TCP/UDP数据包获取之后会直接取出Data部分，重新构造一个IP数据包（可能是TCP或者UDP，和用户原始请求是TCP还是UDP有关系。），目标地址和端口是服务器地址，数据包的Data部分是加密后的用户原始Data。

SS安全性与加密​

SS中本地代理和服务器通讯数据包都是经过加密的，DPI（深度数据包检测）只能检测到IP头部和TCP/UDP头部，无法对内容进行检测，而VPN之类的就特别容易被检测到了。想检测SS只能通过“流量特征”（数据包的结构）推测，但是使用SS一般选择带IV模式的AES加密算法作为加密方法（不了解AES的朋友请参考公众号的《深入浅出AES加密》），利用IV对数据做随机化，使每次请求的数据包都不一样，一般很难形成“流量特征”。如果SS无法使用那么一定是由于服务器端IP地址被限制了，被限制的原因也绝对不是由于SS被识别到了（除非谁有通天的能耐破解AES）。

Shadowsocks数据包分析​

前三条是TCP握手我们无视后面是162字节的请求数据包，接着是服务器端回复一个ACK确认（60）字节，接着是服务器返回651字节的回复数据包；紧接着服务器发送60字节的TCP控制数据包扩大数据窗口；客户端回复54字节的ACK确认数据包。后面4条是TCP的关闭动作。

我们关注的重点是162字节的请求和651字节的回复是什么内容：
SS请求数据包
关注IP头部和TCP头部，这两部分信息是源地址是本地代理的IP地址和端口；目标地址是服务器端的IP地址和端口，Data部分108字节是通过AES加密的原始请求。

SS回复数据包​

这是SS服务器回复给本地代理的数据包。IP和TCP头部没有什么特殊的，直接看Data部分，一共597字节。也是加密后的数据，我们把它解出来。
服务器端没有增加特殊头部，直接把原始数据返回。

SS改进​

SS的设计很low（好吧，其实也没啥设计），效率也很差，特别是HTTP之类的短连接简直是灾难。一个Web页面中可能包含40-50个请求那么相当于SS中转40-50次，所以并发压力很大。但是它实现起来特别简单，而且行之有效，这也许就是它美妙的地方。