小白教程: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)高级加密标准,这类加密标准是十分常见的对称加密算法。所谓的对称加密算法也就是加密和解密用相同的密钥,具体的加密流程如下图:
    V2ray拓展1.png

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

2.AES-128-CFB

  • 对于 CFB 模式来说,其全称为 Cipher FeedBack模式(密文反馈模式)。在 CFB 模式中,前一个密文分组会被送回到密码算法的输入端。而所谓反馈,这里指的就是返回输入端的意思。以下是其示意图:
    V2ray拓展2.png

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

3.AES-128-GCM

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

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

  • 对于 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 理论上能更加安全。

三、本系列文章