小白教程：V2Ray搭建服务器之拓展资料

介绍

• 本文介绍一些搭建 V2ray 服务器时的一些拓展内容
• 主要是针对于搭建服务器的进阶教程的讲解
• 原文大部分内容搬运自 无主界
• 注意：请不要进行任何商业行为，产生任何后果都与本人无关

一、传输协议

• V2Ray 的传输协议非常之多，由于 V2Ray 本质就是一种网络传输数据的应用。因此它可以使用的工具自然也不会少，比如用于网站的 HTTP/HTTPS 协议、更底层的 TCP/UDP 协议等等。这些协议既然存在并且依然在使用，说明它们各有千秋。因此，想要知道你应该使用哪个协议，便需要你对协议本身有一定的了解

1.WebSocket+TLS

• 此协议使用的人并不多，但是笔者是推荐使用此协议的。使用不多的原因是 WebSocket+TLS 协议存在一定的应用难度：你需要知道如何注册、解析域名。但是如果你能搞定域名的问题，搭配现在甚多的一键部署脚本，WebSocket+TLS 是较为简单、可靠的

(1).WebSocket (ws)

• WebSocket 是一种在单个 TCP 连接上进行全双工通信的协议；WebSocket 通信协议于2011年被 IETF 定为标准 RFC 6455，并由 RFC 7936补充规范；WebSocket API 也被 W3C 定为标准。

• WebSocket 使得客户端和服务器之间的数据交换变得更加简单，允许服务端主动向客户端推送数据。在WebSocket API中，浏览器和服务器只需要完成一次握手，两者之间就直接可以创建持久性的连接，并进行双向数据传输。

• 简单说，WebSocket 解决了 HTTP 协议的部分问题，比如每次请求都携带状态信息（如身份认证等）、请求每次都要携带完整的头部等等。再加上由于 WebSocket 全双工通信，因此能够很好的进行实时通信。用在V2Ray 上时，请求与应答的效率要远高于 HTTP，而 V2Ray 的请求要远高于普通的请求，所以 WebSocket 可以说是一种不错的选择。同时由于 WebSocket 本身已经成熟，因此有 Cloudflare 这类云服务商支持基于 WebSocket 流量的 CDN 服务，这进一步增进了原本的服务器的安全性。

• 但是，由于 WebSocket 本身是基于 TCP 协议。既然使用了 TCP，那么自然少不了一些 TCP 的缺点，由于 TCP 协议占据了大多数的网络链接，再者有着复杂的握手机制。虽然保证了链接的可靠性，但也牺牲了效率和带宽，因此在拥堵的网络环境，WebSocket 便不在那么好用了。

• 这类的网络拥堵并不仅仅在于客户端，对于 V2Ray 的服务器端更为明显，所以使用这类协议的服务器，最好安装诸如 BBR、锐速等拥塞控制算法，减少拥堵。

• 同时，由于 WebSocket 是明文传输，这意味着与服务器的通信内容均可以被第三者探测甚至攻击。因此，这对传输安全带来了隐患。如果仅仅开启 WebSocket ，建议开启伪装，伪装的域名建议为 WebSocket 流量相对较大的网站。

(2).TLS

• 传输层安全性协议（英语：Transport Layer Security，缩写作TLS），及其前身安全套接层（Secure Sockets Layer，缩写作SSL）是一种安全协议，目的是为互联网通信提供安全及数据完整性保障。网景公司（Netscape）在1994年推出首版网页浏览器——网景导航者时，推出 HTTPS 协议，以 SSL 进行加密，这是 SSL 的起源。IETF 将 SSL 进行标准化，1999年公布第一版 TLS 标准文件。随后又公布 RFC 5246 （2008年8月）与 RFC 6176（2011年3月）。在浏览器、邮箱、即时通信、VoIP、网络传真等应用程序中，广泛支持这个协议。主要的网站，如 Google、Facebook 等也以这个协议来创建安全连线，发送数据。目前已成为互联网上保密通信的工业标准。

• SSL 包含记录层（Record Layer）和传输层，记录层协议确定传输层数据的封装格式。传输层安全协议使用X.509认证，之后利用非对称加密演算来对通信方做身份认证，之后交换对称密钥作为会谈密钥（Session key）。这个会谈密钥是用来将通信两方交换的数据做加密，保证两个应用间通信的保密性和可靠性，使客户与服务器应用之间的通信不被攻击者窃听。

• TLS 作用于 HTTP 便诞生出了现今最为常用的协议 HTTPS，那么作用于 WebSocket，自然便成了 WSS，也就是 WebSocket+TLS。

• 对于 V2Ray 来说，虽然经过了协议的加密，但是这类流量本身就并不“正常”。试想，你手机连接了 V2ray，大量数据通过协议向一个固定 IP 请求，而数据内容与普通的数据格格不入。这自然会引起部分人的警觉。如果嵌套一个保险箱(TLS)，让数据显得和其他请求的数据没什么两样，这样一方面减少了审查者的怀疑，另一方面又加强了数据的安全性。

• 当然由于 TLS 本身存在一个加密解密的过程，因此势必会对传输的效率带来影响。不过影响是微乎其微的，想要追求安全，自然也需要一定的牺牲。笔者是推荐这种协议的，如果条件允许，主要推荐 WebSocket+TLS 这个协议。

2.mKCP伪装

• 这一类协议细分有多种，由于 KCP 拥有控制头，因此可以通过修饰头部进行数据伪装。这类伪装常见的有 SRTP、UTP、DTLS、wechat-video 等。这类伪装并不能决定这类协议本质，因此便不再详细阐述。对于 mKCP 伪装最为重要的影响是 KCP 协议本身。

• KCP 协议是传输层的一个具有可靠性的传输层 ARQ协议。它的设计是为了解决在网络拥堵情况下 TCP 协议的网络速度慢的问题。KCP 力求在保证可靠性的情况下提高传输速度。KCP 协议的关注点主要在控制数据的可靠性和提高传输速度上面，因此 KCP 没有规定下层传输协议，一般用 UDP 作为下层传输协议，KCP 层协议的数据包在 UDP 数据报文的基础上增加控制头。当用户数据很大，大于一个 UDP 包能承担的范围时（大于MSS），KCP 会将用户数据分片存储在多个 KCP 包中。

• KCP 协议与上述的 WebSocket 协议便大大的不同了。由于本身的下层传输协议不同，KCP 通常使用 UDP 而 WebSocket 使用 TCP，因此特性也十分不同。

• WebSocket 在拥堵的网络情况下显得效果不佳，而 KCP 则可以在拥堵的网络下依旧达到一定的速度。所以，在 3G、4G 这类用户多、网络堵的情况下，KCP 甚至可以起到加速的作用。

• 但是，这类协议虽然速度快，其本身是基于 UDP 的，UDP 协议本身并不稳定。即便有一定的可靠性，由于使用了 UDP，容易导致产生拥塞。注意，这里的拥塞并不是由于其他的连接引起的，而是协议自身引起的。如果出现拥塞，反而会导致传输效率大打折扣。因此最好启用拥塞控制。同时，由于 UDP 自身容易出现拥塞影响其他连接，又难以进行很好的管控，我们运营商可能会对这类连接阻断，也即是 QoS 。遇到这种情况， KCP 也成了牺牲品，进一步影响了连接的稳定。

• 当然由于 KCP 自身容易拥塞的特性，相应的 V2Ray 客户端有 Mux 技术来一定程度解决这类问题。Mux 是推荐开启的，它可以使 KCP 数据更为有条理的整合在一起，提高效率。

3.TCP

• TCP（Transmission Control Protocol 传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议，由 IETF 的 RFC 793定义。在简化的计算机网络 OSI 模型中，它完成第四层传输层所指定的功能，用户数据报协议（UDP）是同一层内另一个重要的传输协议。在因特网协议族（Internet protocol suite）中，TCP 层是位于 IP 层之上，应用层之下的中间层。不同主机的应用层之间经常需要可靠的、像管道一样的连接，但是 IP 层不提供这样的流机制，而是提供不可靠的包交换。

• 这类协议本身较之其他的 V2Ray 协议更加底层和原始。这对于 V2Ray 的安全性带来了问题。由于本身就是TCP 协议，因此，看到这里大家应该知道了它的缺点在哪里。

• 当然没有了上层协议的嵌套，简单的 TCP 协议对于传输效率来说是增加了不少。这也带来一个更为严重的问题，安全。由于实在简单，据了解，审查者已经开始拦截这类数据了。基于安全与网络顺畅考虑，笔者是不推荐的。

4.h2 (HTTP/2)

• h2 便是 HTTP/2 （原名HTTP/2.0）即超文本传输协议 2.0，是下一代 HTTP 协议。是由互联网工程任务组（IETF）的 Hypertext Transfer Protocol Bis (httpbis)工作小组进行开发。是自1999年 http1.1 发布后的首个更新。HTTP 2.0在2013年8月进行首次合作共事性测试。在开放互联网上 HTTP 2.0 将只用于 https:// 网址，而 http:// 网址将继续使用 HTTP/1 ，目的是在开放互联网上增加使用加密技术，以提供强有力的保护去遏制主动攻击。

• 对于 V2Ray，使用 h2 必须同时使用 TLS。h2 本质是 HTTP 协议，对于传统 http1.1 协议传输速度快了不少。h2 的下层协议是 TCP，因此大家应该知道这类协议的共同缺点了。较之类似的 WebSocket 协议，传输效率略逊于 WebSocket。但是它却有比 WebSocket 更加好的伪装，由于大部分网站使用 HTTP 协议，因此 h2+TLS 这种协议能使 V2Ray 流量伪装在正常流量中，并且难以察觉。

5.QUIC

• QUIC（Quick UDP Internet Connection）是谷歌制定的一种基于 UDP 的低时延的互联网传输层协议。我们知道，TCP/IP 协议族是互联网的基础。其中传输层协议包括 TCP 和 UDP 协议。与 TCP 协议相比，UDP 更为轻量，但是错误校验也要少得多。这意味着 UDP 往往效率更高（不经常跟服务器端通信查看数据包是否送达或者按序），但是可靠性比不上 TCP。通常游戏、流媒体以及 VoIP 等应用均采用 UDP，而网页、邮件、远程登录等大部分的应用均采用 TCP。

• QUIC 很好地解决了当今传输层和应用层面临的各种需求，包括处理更多的连接，安全性，和低延迟。QUIC 融合了包括 TCP，TLS，HTTP/2 等协议的特性，但基于 UDP 传输。QUIC 的一个主要目标就是减少连接延迟，当客户端第一次连接服务器时，QUIC 只需要 1RTT（Round-Trip Time）的延迟就可以建立可靠安全的连接，相对于 TCP+TLS 的1-3次 RTT 要更加快捷。之后客户端可以在本地缓存加密的认证信息，再次与服务器建立连接时可以实现 0-RTT 的连接建立延迟。QUIC 同时复用了 HTTP/2 协议的多路复用功能（Multiplexing），但由于 QUIC 基于 UDP 所以避免了 HTTP/2 的线头阻塞（Head-of-Line Blocking）问题。因为 QUIC 基于 UDP，运行在用户域而不是系统内核，使得 QUIC 协议可以快速的更新和部署，从而很好地解决了 TCP 协议部署及更新的困难。

• 此协议基于 UDP，但较之 KCP 更为可靠。从传输本身来说，笔者是推荐的。但是，由于协议本身太新，这类流量本身就不多，突然出现大量流量指向一个 IP 会如何？相信大家也知道风险。同时由于现今 V2Ray 的 QUIC 并不是真正意义上的 HTTP/3，因此存在一定的兼容问题，笔者并不是很推荐。

6.小结

• 对于大部分用户来说，如果有能力搞定域名购买、解析。那么是推荐使用 WebSocket+TLS，可以的话最好再增加 CDN 支持。如果没有办法搞定域名，那么推荐直接使用 WebSocket 伪装或者 mKCP 伪装。

• 对于处在拥堵网络，如经常使用 3G、4G 的用户，推荐使用 mKCP 伪装。并且推荐打开 Mux 多路复用。

• 对于不在乎服务器被墙的用户来说，推荐直接使用 WebSocket 伪装。

• 对于客户端、服务器性能孱弱的用户来说，直接使用 TCP 不使用加密并将 AlterId 值调低是最好的选择。

二、加密方式

• 对于加密方式/算法来说，一般安全性与性能呈负相关，越是安全越是对性能要求高，这应该是大家的常识。由于现在大部分给出的加密协议的安全性均能达到标准，因此这里主要讨论的最好便是加密性能的优良。

• 对于 V2Ray 而言，有三种加密方式：AES-128-CFB、AES-128-GCM、ChaCha20-Poly1305（当然还有不加密）。

1.AES加密方式

• AES（Advanced Encryption Standard）高级加密标准，这类加密标准是十分常见的对称加密算法。所谓的对称加密算法也就是加密和解密用相同的密钥，具体的加密流程如下图：
  

• 这里的 AES-128 就是密钥的长度为128位，加密轮数为10轮。

2.AES-128-CFB

• 对于 CFB 模式来说，其全称为 Cipher FeedBack模式（密文反馈模式）。在 CFB 模式中，前一个密文分组会被送回到密码算法的输入端。而所谓反馈，这里指的就是返回输入端的意思。以下是其示意图：
  

• 从上图中可以发现，对于 AES-128-CFB 而言其优点在于它隐藏了明文模式，同时它可以及时加密传送小于分组的数据。但它也有缺点，CFB 并不利于并行计算、一个明文单元损坏影响多个单元。

3.AES-128-GCM

• 对于 GCM 模式来说，其全称为 Galois/Counter Mode，也就是该对称加密采用 Counter 模式，并带有 GMAC 消息认证码。

• 其工作原理是相对较为复杂的，与CFB不同，它可以提供对消息的加密和完整性校验，另外，它还可以提供附加消息的完整性校验。以下是其粗略的示意图：
  

• 对于 GCM 而言其最大的优势便是有利于并行计算，并且有消息的完整性校验。缺点自然是要考虑运行加密时硬件的支持程度。

4.ChaCha20-Poly1305

• 对于 ChaCha20-Poly1305，其全称就是 ChaCha20-Poly1305，它是由 ChaCha20 流密码和 Poly1305 消息认证码（MAC）结合的一种加密算法。

• ChaCha20-Poly1305 是基于 RC4 流加密的一种加密方式，它与 AES 有本质的区别，对于 RC4 而言，已经被证实并不安全，那么为什么还要发展 ChaCha20-Poly1305 呢？原因很简单，兼容性。

• 对于精简指令集的 ARM 平台，由于没有 AES-NI 指令集，ChaCha20-Poly1305 在同等配置的手机中表现是 AES 的4倍（ARM v8之后加入了AES指令，所以在ARM v8平台上的设备，AES 方式反而比 chacha20-Poly1305 方式更快，性能更好），这样可减少加密解密所产生的数据量，使得性能更好。

5.小结

• 若 V2Ray 客户端运行在普通电脑上，很明显 AES 方式更加的高效。

• 若 V2Ray 客户端运行在手机或者软路由上，从上述描述中能很好的看到，AES 和 ChaCha20-Poly1305 的选择需要依据实际情况。一般在近几年的手机/软路由 CPU 中都内置了 AES-NI 指令集，因此使用 ChaCha20-Poly1305 是没有必要的。但对于老手机而言，ChaCha20-Poly1305 则快于 AES，是你的最佳选择。

• 所以，对于服务端，一般选择 Auto；对于使用老旧手机的用户而言，毫无疑问，你需要选择 ChaCha20-Poly1305 或者直接选择不加密获得最佳性能；对于使用电脑和近两年新手机的用户而言，选择 AES-128-GCM 效果最佳；对于在乎自己数据安全的用户来说，选择 AES-128-CFB 理论上能更加安全。

三、本系列文章

• 想要了解V2Ray的服务器购买教程请移步这里：[小白教程：V2Ray搭建服务器之服务器的购买]

• 想要了解V2Ray的基础搭建教程请移步这里：[小白教程：V2Ray搭建服务器之基础搭建教程]

• 想要了解V2Ray的进阶优化教程请移步这里：[小白教程：V2Ray搭建服务器之进阶优化教程]