传说中的性能测试

一直都有人问 V2Ray 的性能问题，一直都很无奈因为没有人测过。被问得烦了，现在给一个比较科学，比较准确的结论。

本次测试的目的

测试 VMess 和 Shadowsocks 各种加密方式，在传输过程中的极限速度。

测试方法

在同一台主机上同时启动 V2Ray 客户端和服务器端，使用环回网络（Loopback）进行网络传输。客户端会接受到预设数量的数据，然后验证服务器端发出同样数量的数据。

测试环境

一台云主机，内存 2GB，CPU 信息如下。显然这台机器本身的性能不怎么样，如果用一台更好的机器，会得到更好的绝对数值，但本次实验结果的数值比例有参考价值。

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                2
On-line CPU(s) list:   0,1
Thread(s) per core:    1
Core(s) per socket:    2
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 61
Model name:            Virtual CPU a7769a6388d5
Stepping:              2
CPU MHz:               2399.996
BogoMIPS:              4799.99
Hypervisor vendor:     KVM
Virtualization type:   full
L1d cache:             32K
L1i cache:             32K
L2 cache:              4096K
NUMA node0 CPU(s):     0,1

测试工具

特地写了两个小工具：loadgen 和 receiver。

loadgen 用于发送数据，它可以对某个端口建立连接，支持直连和 Socks 协议。可配置并发一定数量的连接，发送指定数量的数据后，验证 receiver 的反馈。如果 receiver 收到了同样数量的数据，则表明传输结束。

receiver 用于接收数据，对于每个连接，每次收到数据后，把总共收到的数据字节数发回，并等待连接发起方关闭连接。

由于 VMess 的正确性已被其它的测试验证，这里只需要验证连接畅通，即收到数据量等于发出数据量即可。

基本信息

我们用 loadgen 和 receiver 直接对接，可以得出环回网络的大致性能。实验结果如下：

数据量：50 GB / 连接

并发连接数	1	2	4
速度（MB/s）	4266	4654	4551

对比下面实验中的速度，可以认为环回网络的基本速度不会成为瓶颈。

进一步的基础信息，我们又测了一下使用 V2Ray 直连的速度。实验中只启动一个 V2Ray 进程，配置 Dokodemo-door <-> Freedom。实验结果如下：

数据量：10 GB / 连接

并发连接数	1	2	4
速度（MB/s）	640	819	787

VMess 测试

测试场景的差别是 VMess 的加密方式，其它都一样。传入依然是 Dokodemo-door，传出是 Freedom。

• VMess CFB: AES-128-CFB 加密方式
• VMess GCM: AES-128-GCM 加密方式
• VMess Chacha: Chacha20-poly1305 加密方式
• VMess None: 不加密

结果如下（数据量：10 GB / 连接）：

解读如下：

• 速度 GCM > Chacha > None > CFB；
• VMess 可以同时处理多个连接。由于 CPU 是双核，所以 2 个连接的速度比单个连接快，而 4 个连接对比 2 个连接则没有明显提升；

很有趣的一点是 None 居然比 GCM 慢。不加密反而比加密慢，有一点违反常识。原因是这样的：VMess 不管加不加密，都会进行数据校验，None 中使用的校验算法是 FNV，而 GCM 是一个 AEAD 算法，自带校验。于是带 CPU 加成的校验比软件实现的校验快了不小。这一点也超出了开发人员的预期，之后会考虑提升校验的性能。

与 Shadowsocks 对比

V2Ray 和 Shadowsocks 的比较也是一个常见问题。既然我们有了一个性能测试的工具，那就一起测一下吧。

• V2Ray SS CFB: V2Ray 中的 Shadowsocks 实现，AES-128-CFB 加密方式；
• SS-Libev CFB: Shadowsocks libev 2.5.6，AES-128-CFB 加密方式，客户端 ss-tunnel，服务器端 ss-server；
• SSR-PY CFB: ShadowsocksR 最新的代码（2017-01-20），AES-128-CFB 加密方式。其它的参数都是默认的：auth_aes128_md5、tls1.2_ticket_auth_compatible。

OTA 在所有 Shadowsocks 中都启用了。

实验结果（数据量：10 GB / 连接）：

解读如下：

• VMess 的速度优于 Shadowsocks；
• 比起 ss-libev 和 ssr-python，V2Ray 在多并发连接的场景中更有优势；

结论

• 在一台双核 2.4 GHz 的主机上，V2Ray 的极限传输速度超过 400 MB/s。
• 如果你对速度有需求，请使用 VMess + AES-128-GCM。

后记

• 在日常使用中，传输速度一般都不会超过 10 MB/s，上述测试的每种方式都可以满足需求。但如果你需要高性能传输，可以按测试结果选择合适的方式。
• 上述的测试结果都是运行多次的平均值。由于虚拟机的不稳定性，误差在 5% 以下。
• 其它方面的测试，如 CPU 和内存占用，会在后续的测试中进行。
• loadgen 和 receiver 可以由 iPerf 替代，唯一的问题是 iPerf 不支持 Socks 协议。
• 上述所有工具和测试脚本的源代码可以在这里找到。

来源：https://steemit.com/cn/@v2ray/3cjiux

适合自己的才是最好的

最近有很多关于 Shadowsocks 安全性以及各种解决方案的讨论，比如这个和这个，还有这个。实际上讨论的范围不仅限于 Shadowsocks，但不可否认它是目前最流行的翻墙工具，所以也是最大的目标。当然了，这类的讨论不会有什么明确的结论，谁都说服不了谁。重要的是大家表达了自己的观点和需求，让旁人也能更好的了解翻墙中可能碰到的各种问题。

于是我也来凑个热闹，说说 V2Ray 的设计理念。

首先，V2Ray 是什么？V2Ray 是一个网络代理工具。什么是代理？代理是当 A 和 B 想说话但不能直接对话时，要找 C 来传话，这时 C 就是代理。那么在这个过程中，C 有哪些职责？很简单，把话传到，把话传对，并且不泄露给除 A、B 之外的人。

看似这个描述很简单，把它应用到代理软件中，可以表述为下面的内容：

• 开放网络连接，使得 A 和 B 可以间接地进行正常通信；
• 通信内容不能被第三方知晓；
• 网络连接要稳定，不能间歇或永久地失效；

之所以没有写成一二三条，是因为上述三条的优先级，在不同的人看来是不一样的。

大多数人的选择应该会是“正常通信”。毕竟翻墙工具诞生的意义就是让用户访问被墙的网站，比如 Google 被墙了，我架设一个 Shadowsocks 服务器就又可以访问 Google 。至于我在 Google 上搜索了什么，都是一些人畜无害的内容，我想别人也没兴趣知道。只要这个工具能让我爽快地访问 Google，它就是一个好工具。这种情况我们称为“速度优先”。

另外一些人可能就比较注重私密性，不管我在搜索一些什么内容，可能也就是一些网红八卦，但我就是不想让别人知道，被别人知道了我就不爽。这种情况我们称为“隐私优先”。

还有一些人对服务器的稳定性有需求，平时我不怎么翻墙，而一旦需要的时候，就一定要可以及时翻出去。几百万的大单，谈不成这个月就要喝西北风了。这些人对翻墙服务（或服务器）的稳定性要求很高，服务不能断线。而断线的情况有很多种，比如翻墙协议被识别了，或者服务器被探测了，都可以造成翻墙服务失效。这种情况我们称为“稳定优先”。

上述的三种情况在翻墙工具中都有相应的功能，比如“速度优先”可能的问题是 ISP 的 QoS 限制，应对方式是流量混淆。又比如“隐私优先”可能需要工具提供完美的加密方式。而“稳定优先”需要翻墙服务器不被探测，翻墙协议需要减少特征。正是由于这些纷繁复杂的功能，引起了大量的讨论。观众不明就里，而开发人员则忙于推销自己的产品。有些问题呢，就越讨论越看不懂了。

从 V2Ray 的角度来看，这是一个不可调和的矛盾。每个人的需求不同，适合自己的才是最好的。不能因为开发人员觉得一项功能好，就强加给用户。用户用着没效果，也不会感谢开发者。

举个例子，Shadowsocks 最近的一次协议升级，使用 AEAD 算法取代了 OTA，提供了更好的加密特性。这个升级在“速度优先”的用户看来是完全没有意义的。因为 AEAD 只是加强了数据完整性，对于 QoS 和可被探测性没有任何改进。也就是说，在客观环境不变的情况下，升级到 AEAD 不会在翻墙速度上有任何提升。于是很多人就会问，到底要不要升级 AEAD，升完对我有什么好处。由于惰性，在没有明显优势的情况下，AEAD 的推广有着很大的阻力。

V2Ray 则尝试从另一个角度来解决这样的问题：提供很多功能，让用户根据自己的需求自由组合。虽然各种组合并不一定能满足所有人的需求，但总比只有一个选择来得好。

对于上述的三个需求，V2Ray 分别提供了不同的特性：

• 速度优先：VMess 协议、mKCP 协议、Mux.Cool 协议，内部路由分流
• 隐私优先：TLS (完整实现，非伪装)
• 稳定优先：HTTP 伪装、BT 伪装等，以及 Mux.Cool 协议。

V2Ray 在设计时已考虑到多个功能相互组合的使用，比如你可以使用 VMess + TLS 来达到隐私和速度的双重保证，或者使用 VMess + Mux 来提升速度和稳定性。也考虑到不同的用户的需求不同，V2Ray 的所有功能都可以选择打开或关闭，不会把任何一个功能强加给用户。不同的配置可以达到不同的效果，而在 V2Ray 中，你只需要一个配置文件就可以应对这些不同的需求。

当然 V2Ray 的功能远不止上述这些，如果你现在的翻墙工具已不能满足你的日常需求，何不试一下新的轮子呢？

来源：https://steemit.com/cn/@v2ray/47wumq

翻墙协议的三要素

上一篇文章介绍了从用户的角度如何理解翻墙工具，这次我们来讨论一下从工程的角度如何理解翻墙协议，每个翻墙协议有什么差别。

首先，我们来设定一个概念：一个代理（翻墙）协议可能具备的三要素。

一、传输：能在 A、B 两个主机之间建立一条安全可靠的通信通道，用于传输数据；
二、协议：对于将要传输的数据，能将这些数据的目的地告知代理服务器；
三、内容：可以对传输的数据进行优化，比如压缩、合并等。

任何一个翻墙协议都具备以上三要素中的几个或全部。

文字可能较难理解，我们来举一个简单的例子：Socks 协议。Socks 只具备协议要素，即告知代理服务器要把数据发送到哪里去，以达到代理的目的。但众所周知单纯的 Socks 不具备翻墙能力，因为它不能建立可靠的通道（即会被墙）。于是就有了 Shadowsocks。Shadowsocks 在 Socks 的基础上增加了传输要素，对数据加了密，使墙无法分析其内容。而 Shadowsocks 不具备内容要素，因为对于客户端的发来的内容，Shadowsocks 不进行任何修改，直接发送给了代理服务器。

在翻墙过程中，我们可能会使用几个协议的组合，比如 Shadowsocks + KcpTun。无论我们怎么组合，所产生的结果，必须包含传输要素和协议要素，才可以进行可靠的翻墙。

为什么不能单独使用 KcpTun 来翻墙，因为 KcpTun 只有传输+内容要素。KcpTun 只能建立连接，对内容进行一定的处理，比如加密以及其内置的 mux 模式。但它不能发送数据的实际目的地，导致了一定要再套一个其它协议才可以用于翻墙。

而在 Shadowsocks (传输+协议) + KcpTun (传输+内容) 的场景中，由于两者都有传输要素，重复了，以至于 Shadowsocks 的加密在这个场景中多余。因为 KcpTun 已经有加密了，Shadowsocks 再多加一层也没用。

这也就是 ShadowsocksR 最近的几个协议推荐使用不加密的原因。

ShadowsocksR 本质上是对 Shadowsocks 进行了一层封装，即 Shadowsocks + X。这个 X 包含了对协议要素的扩（单端口多用户多种加密方式），加强了传输要素（伪装和其它的加密方式）。和 Shadowsocks + KcpTun 同理，Shadowsocks 本身的传输要素就显得不那么重要了。

而 Shadowsocks 最近也加强了传输要素，即 obfs plugin。两者在要素这一层面相差无几，这也是为什么很多人不认为 ShadowsocksR 之于 Shadowsocks 有很大改进的原因。

顺便整理一下常用协议所具备的要素，仅供参考：

• HTTP/1.1: 协议
• HTTP/2 (不带 TLS): 协议+内容
• TLS: 传输
• Shadowsocks: 传输+协议。AEAD 只是强化了传输，并没有添加新的要素。
• ShadowsocksR: 传输+协议
• KcpTun: 传输+内容
• GoProxy: 等价于 HTTP/2 + TLS，即传输+协议+内容
• VMess (V2Ray): 传输+协议
• mKCP (V2Ray): 传输
• WebSocket (V2Ray): 传输
• Mux (V2Ray): 协议+内容

当然，一个翻墙协议的效率和它具备几个要素没有半点关系。以上这些内容只是帮助大家理解每个翻墙协议的侧重点，哪些组合是有意义的，哪些是没有意义的。一个协议组合首先要有意义，其次才能探讨它的效率。

来源：https://steemit.com/cn/@v2ray/unzev

各种加密代理协议的简单对比

目前我们常用的加密代理有协议有 HTTPS，SOCKS5-TLS 和 shadowsocks,此文从各个角度简单分析各个协议的优劣，以帮助各位选择合适的协议。

先简单说些背景知识，以上协议都是基于 TCP 的代理协议，代理协议（Proxy Procotol）与 VPN 不同，仅可被用于通过代理服务器转发 TCP 连接（shadowsocks 支持代理 UDP），而 VPN 可被用于 IP 层上的所有协议，如 TCP、UDP、ICMP 等。所以在使用代理时，ping 等 ICMP 应用是不可以被代理的。

然后简单解释一下什么是 TLS，TLS 又名 SSL，是针对数据流的安全传输协议。简单来说，一个 TCP 链接，把其中原本要传输的数据，按照 TLS 协议去进行加密传输，那么即可保证其中传输的数据安全。这个安全至少体现在以下几个方面：

1. 数据被加密，任何可以截取到 TCP 数据流的人，无法解密出原始数据；
2. 数据不可被篡改，一旦篡改会导致解密失败，连接断开；
3. 服务器身份验证，基于 X509 的证书体系去确认目标服务器是否为真实的服务器。

明文的 HTTP 套上一层 TLS，也就变成了 HTTPS，SOCKS5 套上 TLS，就变成了 SOCKS5-TLS。TLS 协议是整个互联网安全的基石，几乎所有需要安全传输的地方都使用了 TLS，如银行、政府等等。

当被用作代理协议时，HTTP 层和 SOCKS5 层去进行具体的代理连接控制，如进行身份验证、告知需要转发的目标主机名等。所以不需要 TLS 他们也可以用作代理，只不过所有数据都是明文传输，不具备安全性。加上 TLS 后，由 TLS 去保证安全。而 shadowsocks 协议则融合了代理控制和安全保证。所以后文的很多对比实际上是 shadowsocks 和 TLS 的对比。

性能

TLS 协议由于承担了一项额外的功能，需要验证目标服务器身份，导致其握手时会比较复杂。

ping 的时间表示，一个 IP 层数据包从本地发出，到服务器再返回的来回时间，即 RTT（round-trip time）。

在发起代理连接时，首先我们需要进行 TCP 3 次握手，耗时为 1 个 RTT。（此处把最后的 ACK 直接并入后续的数据传输部分）。

然后进行 TLS 握手，因为服务端和客户端需要进行身份验证并协商协议版本号、加密方式等细节，第一次连接时需要 2 个 RTT。当然 TLS 的制定者也发现这太慢了，于是引入了 TLS Session Resumption，当服务端和客户端服务器连接过一次后，之后的连接可以直接复用先前的协商结果，使得 RTT 降低到 1 个 RTT。但这需要服务器和客户端的支持。（这是为什么 Surge benchmark 时，对于 TLS 代理第一次的测试结果可能较慢的原因之一）

对于 HTTPS 协议，当 TLS 连接建立后，客户端通过 HTTP 层发起代理请求，服务端回应连接建立，此后进入正常的代理通讯环节，再耗费 1 个 RTT。

对于 SOCKS5-TLS 协议，当 TLS 连接建立后，如果没有验证的环节，那么需要再耗费 1 个 RTT，如果有验证（用户名密码），那么需要耗费 2 个 RTT。

而对于 shadowsocks，由于使用的是预共享密钥（pre-shared key, PSK），加密方式也是预先约定好的，所以不需要进行协商，只需要在 TCP 建立之后，再耗费一个 1 个 RTT 告知目标主机名。

总结如下：

HTTPS（TLS Session Resumption）：3 个 RTT

SOCKS5-TLS 无验证：3 个 RTT

SOCKS5-TLS 有验证：4 个 RTT

shadowsocks：2 个 RTT

（注：最后一个 RTT 并不严谨，因为客户端可以在最后一个 RTT 产生响应前，直接开始后续传输。另外如果使用了 TCP Fast Open，可以看作 TCP 阶段 RTT 为 0。）

对于日常使用，最影响性能的就是握手速度，后续传输过程中的加解密性能，对于现代 CPU 来说基本都不会构成瓶颈。 shadowsocks 由于有 PSK 的特点，在 TCP 协议基础上已经达到极限，不可能有协议能再低于 2 个 RTT。

所以，同等网络环境下，shadowsocks 是明显快于 HTTPS 的。（体现在延迟上，而不是带宽）

另外，最新的 TLS 1.3 协议正力图解决这个问题，由于目前还处于草案阶段，各种工具链不完善，现在不太好评估实际效果。

数据安全性

（此处说的数据安全性，指的是加密后的流量是否会被截取并破解的问题。）

对于 TLS，作为个人用户，丝毫不用担心，TLS 协议如果真的不安全了，世界早就乱套了…

对于 shadowsocks，使用的加密方法也都是工业上成熟的算法，从数据安全性角度考虑也基本不用担心。

抗识别

这个问题有两个角度需要考虑：

1. 观察一段数据流量，是否能判别这是一个代理协议的流量；
2. 对于一个仅暴露出 TCP 端口的黑箱，能否判断这个端口提供了代理服务。

对于 shadowsocks 协议，在第一点上，观察者只能判定这个数据流为未知的协议。而第二点，shadowsocks 的几次修改，都是因为在这出了问题，目前最新的 AEAD 加密方式，应该已经解决了这个问题，但还需要时间去检验。

对于 HTTPS 协议，在第一点上，观察者是无法去区分这是一个代理还是一个标准的 HTTPS 网页访问的（当访问 HTTP 页面时，如果访问 HTTPS 会使得流量模型出现特征）。而第二点，在妥善配置的情况下，也是完全无法判别。

但在实践中，大部分 HTTPS 代理服务器为了兼容浏览器行为，在直接被当做 HTTPS Web 服务器访问时，会返回代理错误页或者 407 Proxy authentication required，直接暴露了自己是一个代理，如果要抗击第二点，可以将服务端的行为修改为，如果请求的 Header 中，不包含一个有效的 Auth，那么就返回一个标准的 200 页面，这样从理论上杜绝了被嗅探的可能。

总结一下，最新的 shadowsocks 已经能满足抗识别的两个要求，但是观察者得到结论是“未知协议”。而使用 HTTPS，观察者无法判断这是一个 HTTPS 代理还是 HTTPS Web 服务器，这是更优的结果。

Hiding true identities inside a seemingly ordinary. — Person of Interest S03E23

部署难度

HTTPS 协议使用广泛，有众多成熟的工业级工具，如 squid，haproxy，nghttp2 等等，但是由于 HTTPS 协议本身比较复杂，配置起来参数众多，有很多性能相关参数需要自己调优，所以一般用户配置起来会有难度。

shadowsocks 经过多年发展，目前也已经有众多的软件支持，但是对于不同特性的支持度不一。由于参数简单，部署配置起来极其方便。

功能

shadowsocks 目前还存在一些功能上的缺陷：

1. shadowsocks 没有设计错误回报机制，对于以下错误，客户端看到的行为都是服务器主动断开 TCP 连接：

• 密钥或者加密方法错误
• 目标主机名 DNS 解析失败
• 目标主机不可达
• 目标主机拒绝连接

这使得客户端没办法根据不同的错误采取进一步的动作，只能简单的向用户返回 Socket closed by remote 错误。

2. shadowsocks 没有考虑用户鉴别，使得服务端 ACL 或者流量统计等功能无法实现，主流的 workaround 是通过不同的端口号去识别不同的用户，但这极其浪费资源且很不优雅。

3. 部分 ISP 对于非 HTTP 和 TLS 的未知流量，会进行降速限制，这个可以通过配置 obfs 解决。

来源：https://medium.com/@Blankwonder/%E5%90%84%E7%A7%8D%E5%8A%A0%E5%AF%86%E4%BB%A3%E7%90%86%E5%8D%8F%E8%AE%AE%E7%9A%84%E7%AE%80%E5%8D%95%E5%AF%B9%E6%AF%94-1ed52bf7a803

《Shadowsock翻墙流量检测算法》论文翻译

翻译前言

随着机器学习技术的火热，国内不少实验室一窝蜂的将机器学习纳入自己的科研课题研究之中，这样可以更好的找到发论文的结合点。我之前的所在实验室就曾将机器学习引入漏洞挖据的研究之中，取到了很好的效果。但是据我所知，有些研究课题将机器学习引入并没有带来多少收益。本文将机器学习引入Shadowsock翻墙流量的检测，旨在提高准确率节省人力，我认为准确率的提高主要在于：特征的抽象和训练数据的规模。论文中并没有详细的数据说明，我对于准确率部分的说明有保留意见。

原文标题

《The Random Forest based Detection of Shadowsock's Traffic》

作者

Ziye Deng1, Zihan Liu1, Zhouguo Chen2, Yubin Guo2
网络安全中心
通信安全实验室
Email: mujinziye@163.com, hunandhan@sina.cn, czgexcel@163.com, ggyybb@hotmail.com

摘要

随着匿名通信技术的发展，网络监控越来越困难。 如果可以有效地识别匿名流量，则可以防止这种技术的滥用。 由于机器学习的研究正在迅速发展，本文将随机森林算法（一种半监督学习方法）应用于Shadowsocks的流量检测。 通过收集训练组，采集特征，训练模型和预测结果来应用随机森林算法，在实验中，我们可以获得超过85％的检测精度。 随着熟练数据设置和测试设置的规模增加，检测精度率逐渐增加，直到取向恒定。 下一步，我们将对训练数据，测试设置和功能集进行几个调整，以减少检测时的误报率。

关键词

随机森林算法; 机器学习

一.引言

随着近年来海外新闻的需求量不断增加，包含政治，经济，民主，金融，科技等方面的敏感信息。为了摆脱国家的防火墙获取更多的消息，越来越多的人已经学会了如何使用代理软件获取相关的敏感资料。然而，高速开发的代理软件通过翻越防火墙，已经成为广播大量敏感信息的非法工具。因此，隐蔽交易的发生频率很高。为了有效地防止这些事情发生，并立即发现和逮捕这些罪犯，我们不仅要对来自代理软件的流量进行检测和分类，而且要分别给具有某些特征的加密流量标记不同的可疑标签。这些工作可以为监督人员提供详细的信息和数据，进行解密工作和内容分析。
在本文中，我们简要介绍了Shadowsocks的运行原理1。下一步是从该代理软件中全面分析流量，并从该软件获取功能信息。指出特征数据和信息，我们使用Libpcap 2来解决协议，使用机器学习来训练特征数据的某些部分，并在构建模型之后识别。
本文的结构如下：第二部分介绍本文的准备工作和贡献。 我们将在第3节简单介绍该软件的运行原理。第4节将全面展示来自该代理软件的每个流量的检测原理。 相关的实验室结果将在第5节中声明。最后，第6节将是本文的总结。

二.相关工作

为了更好地了解Shadowsocks的流量特征，我们参考了许多论文和材料来了解其运行机制，以确定检测Shadowsocks流量的方法并提取所需的特征信息。众所周知，Shadowsocks的运行非常稳定-几乎是我国最稳定和流畅的代理软件，包括在翻墙的效率和速度（了不起！！！）。然而，目前的工作研究在检测Shadowsocks的流量方面并没有显着的结果。由于Shadowsocks的稳定性和效率，我们可以使用Shadowsocks连接Anony-mous network TOR 3，VPN 4等代理，这成为防火墙的严重威胁，给安全带来更严重的问题。在本文中，我们提出了一种基于随机森林算法的Shadowsocks检测方法5。我们通过使用机器学习处理Shadowsocks的流量[6]，之后我们可以通过使用半监督学习[7]算法来检测Shadowsocks流量，精度超过85％，这可以保护和处理敏感数据来源的潜在危险。
目前，将机器学习算法应用于流量检测方面没有太多的研究。流量检测方法主要取决于人为识别，如阻塞端口，IP等。如果我们可以使用半监督或无监督的机器学习算法，则可以通过机器简单地完成流量检测工作，这可以减少人员的工作量提高检测效率。结合机器学习算法和流量检测也是本文的贡献之一。

三.背景

A.为什么很难检测到Shadowsocks?

Shadowsocks难以被发现的主要原因是Shadowsocks的运行机制很简单。像代理软件的大多数原则一样，Shadowsocks首先建立一个基于SSH [8]的加密通道，其中包含防火墙外的服务器;其次，Shadowsocks通过使用已建立的通道进行代理，这意味着通过SSH服务器请求真正的服务器。最后，通过SSH服务器使用已建立的通道发回响应数据。由于SSH本身是基于RSA [9]加密技术，因此防火墙在传输过程中无法分析加密数据的关键字，从而防止重连接问题。 SSH存在有针对性的干扰问题，所以Shadowsocks将socks5 [10]协议分为服务器端和客户端两部分。详细过程如下：首先，客户端发送请求，根据sock5与本地Shadowsocks进行通信。由于本地的Shadowsocks通常是本地主机或路由器和任何其他机器，它们不会经过防火墙，因此它们不会受到防火墙的干扰。在Shadowsocks客户端和服务器之间，他们可以通过各种加密方式进行通信，因此，通过防火墙的数据包将显示为公共TCP数据包。这些数据包没有明显的功能，防火墙无法解密这些数据，导致防火墙无法检测和干扰这些数据。最后，Shadowsocks服务器解密接收到的加密数据，并向实际服务器发送真实请求，并将响应数据发送给Shadowsocks客户端。详细过程如图1所示。我们可以看到，Shadowsocks的每个运行步骤都绕过了防火墙的检测，并且不会被防火墙干扰。这就是为什么很难人为地检测到Shadowsocks的原因。

图1 Shadowsocks的通信原理

B.随机森林算法

统计学中，随机森林算法是一种分类器算法。 分类器是确定给定样本数据应属于哪一类的算法。 随机森林包含许多决策树，训练样本并进行预测。 预测结果由随机森林中大多数决策树决定。 在我们的方法中，我们将使用随机森林算法将流量分类为两个分类，一个是“Shadowsocks流量”，一个是“无Shadowsocks流量”。

C.定义

1. 数据包：数据包是网络中用于传输和交换数据的单元。 数据包包含的传输数据长度不一致。 在传输过程中，数据包将被打包成帧。 其方法是以特定格式添加多个信息，如数据包头，数据包类型，消息长度，数据包版本等。
2. 数据流：IP网络通常可以将网络流量定义为五元组：源IP地址，目的IP地址，源IP端口，目的IP端口和协议号。 因此，具有相同五元组的网络分组可以被看作是一个相同的流。
3. Biflow：二进制流，具有相同的源IP地址，目的IP地址，源IP端口，目的IP端口和协议号数据集。
4. hostProfile：一组在一个主机中经过一段时间后被过滤的数据包（文件保存为.pcap格式）。

四.我们提出的方法

A.使用随机森林算法来检测Shadowsocks的流量。

随机森林由许多CART（分类和回归树）组成[11]。每组训练数据使用的决策树从总的训练数据集合中取出，取出的单组训练数据将被放回总训练集合。当训练每棵树的节点时，从训练组集合中取出用过的训练组，其中列出的训练组不会退回总训练集合中。假设训练数据总数为C，比例可以为C，sqrt（C），1 / 2sqrt（C），log2（C）。在我们的实验中，我们使用默认值sqrt（C）。
当使用随机森林算法时，有几个步骤可以检测到Shadowsocks的流量，如下所示：

1. 确定训练过程所需的所有数据集和参数，包括训练数据组P，测试集T，特征维度F，CART t的数量，每个CART的深度d，节点使用的功能数f，终止包括节点s中最小样本的条件，节点m中的信息增益最小。
2. 从总训练数据集合P去除训练数据，训练数据将返回，训练数据组数量等于训练组P（i）的数目，i表示数。将P（i）设置为根，并从根开始训练。
3. 如果当前节点没有达到终止条件，则从F维特征向量随机抽取f个特征，这些f特征将不会返回到F维特征向量。从这些f特征中选择具有最佳分类效果的特征k及其阈值th。并利用这些k特征进行判断。如果值小于阈值，样本将被分类为左侧节点，如果该值大于阈值，则样本将被分类为右侧节点。如果当前节点达到终止条件，则将当前节点设置为叶节点。这个叶节点的预测输出是当前节点样本集中最大的分类c（j），假设当前样本集中的c（j）的速率是概率。
4. 训练所有节点，直到所有节点被标记为叶节点或被训练。
5. 训练所有CART，直到所有CART被训练。
6. 预测训练数据组T，预测过程就像训练过程一样。 从当前CART根节点确定，如果小于当前节点的阈值，节点将进入左侧节点，如果大于当前节点的阈值，节点将进入右侧节点。 确定过程将维持直到叶节点输出预测结果。
7. 对CART输出的所有预测值进行确定和计算，所有树中预测概率的最大和是预测结果，这意味着c（j）的每个概率的总和。

B. Shadowsocks'biflow的特点

从上述随机森林算法的过程可知，我们需要确定训练数据组和特征尺寸。 根据网络数据包hostProfile和biflow的属性，我们提出几个功能。 然后，我们捕获一大堆Shadowsocks的流量，提取某些特征值，并将其保存为训练组。 具体功能部分如表1所示。 除此之外，我们还有一个3000维的向量，它记住在整个通信过程中是否出现上游和下游数据包的大小。

表1 部分特征

五.实验和结果

A.随机森林算法的过程，计算和价值

实验步骤：

• 捕获纯粹的Shadowsocks流量，处理这些流量，提取和保存某些功能。
• 使用随机森林算法来模拟这些值。 在随机森林算法中，我们将CART的总值设置为100，将等级标准设置为“gini”，将提取要素的数量设置为sqrt（C），C是特征维度的总数。 树的最大深度设置为无，直到所有节点被识别为止。 分类结果标记为两个分类，“是”和“否”。 剩下的参数被设置为Python的默认参数RandomForestClassifer函数。
• 捕获检测流量，包括Shadowsocks流量和没有Shadowsocks的流量。 提取某些特征值并保存。 最后，使用随机森林算法构建模型并进行预测

B.数据采集

在本地主机上捕获1G Shadowsocks的流量，在C中使用Libpcap lib来解决这些流量。我们用提取的特征进行计算，得到所有的特征值，并将它们作为训练数据组保存到数据库中。捕获1G无Shadowsocks在本地主机的流量10次，使用libpcap处理这些数据。之后，随机捕获超过1G的Shadowsocks流量，并且在没有任何Shadowsocks的流量的26个主机中，以相同的方式处理这些数据，并以测试集的形式存储到数据库中。

C.如何计算。

根据随机森林算法的判断结果，我们人为地验证了他们对随机森林算法的训练集合和准确率的有效性。接下来，我们测试由不同尺寸的训练组构建的模型的检测精度。
从图2可以看出，本实验中特征集的选择效果良好。也可以证明，随机森林算法在Shadowsocks的流量检测中的应用具有显着的效果。我们也可以从图2得出结论，使用较大的测试集可以得到更准确的结果。

图2 检测精度

图3 不同训练集合大小的精度检测

图3说明越大的训练集构造的模型具有越高的检测率

六.结论

在我们的实验中，我们验证了将机器学习应用于流量检测是非常有效的。 我们也得出结论，随着训练数据规模的增加，模型更加完善，检测准确率也将提高。 另外，随着测试集的规模增加，检测的准确率也将增加。 将这种半监督机器学习算法应用于流量检测可以与人工方式相比，发现可以降低误报率和成本。
在我们的方法中，我们采用了许多功能，可以在一定程度上提高检测精度。 然而，它也增加了系统负担，这使得模型相对冗余。 在未来的工作中，我们将深入研究功能，找出最有效的特征属性，排除多个不必要的特征，优化和简化模型，提高整个系统的效率。

致谢

作者要感谢Zhuo ZhongLiu博士和Li Ruixing高工对这项工作的深刻的意见和讨论。 感谢网络安全中心为实验提供环境。 感谢通信安全实验室提供深入研究的机会。

参考文献

1 Xu, Weiai Wayne, and Miao Feng. "Networked creativity on the censored web 2.0: Chinese users’ Twitter-based activities on the issue of internet censorship." Journal of Contemporary Eastern Asia 14.1 (2015): 23-43.
2 Jacobson, Van, and S. McCanne. "libpcap: Packet capture library." Lawrence Berkeley Laboratory, Berkeley, CA(2009).
3 Fagoyinbo, Joseph Babatunde. The Armed Forces: Instrument of Peace, Strength, Development and Prosperity. AuthorHouse. 2013- 05-24 [29 August 2014]. ISBN 9781477226476.
4 Seid, Howard A., and Albert Lespagnol. "Virtual private network." U.S. Patent No. 5,768,271. 16 Jun. 1998.
5 Liaw, Andy, and Matthew Wiener. "Classification and regression by randomForest."R news 2.3 (2002): 18-22.
[6] Goldberg, David E., and John H. Holland. "Genetic algorithms and machine learning." Machine learning 3.2 (1988): 95-99.
[7] Zhu, Xiaojin. "Semi-supervised learning." Encyclopedia of Machine Learning. Springer US, 2011. 892-897.
[8] Ylonen, Tatu, and Chris Lonvick. "The secure shell (SSH) protocol architecture." (2006).
[9] Kaliski, Burt. "PKCS# 1: RSA encryption version 1.5." (1998).
[10] Krawetz, Neal. "Anti-honeypot technology." IEEE Security & Privacy 2.1 (2004): 76-79.
[11] Fonarow, Gregg C., et al. "Risk stratification for in-hospital mortality in acutely decompensated heart failure: classification and regression
tree analysis." Jama 293.5 (2005): 572-580.

翻译仓促，如有错误，欢迎指正~

来源：https://zhuanlan.zhihu.com/p/30072929