v2ray传输协议哪个好/怎么选

推荐：V2ray 一键配装包

我们来探讨一下对于V2Ray究竟哪个传输协议更好。若读者你不是很想详细了解，也可以直接看最后总结。

有哪几种协议？

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

仅列出现在使用较多的几种协议：WebSocket+TLS、mKCP伪装、TCP、h2、QUIC。

WebSocket+TLS

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

===我在用的V2ray节点推荐给大家：点击注册===

WebSocket (ws)

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

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

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

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

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

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，其实大家不应该觉得陌生，TLS作用于HTTP便诞生出了现今最为常用的协议HTTPS，那么作用于WebSocket，自然便成了WSS，也就是WebSocket+TLS。

通过上述的描述，大家也许也就清楚TLS的作用是什么。它就好比是一个保险箱，不管在传输HTTP还是WebSocket的时候，传输中的内容均是以明文的方式传输的。也就是说，只要有人对传输数据拦截，是完全可以知道你在传输什么东西。而TLS就是用来交换最开始的“锁”的方式，保证传输的保密。

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

当然由于TLS本身存在一个加密解密的过程，因此势必会对传输的效率带来影响。不过影响是微乎其微的，想要追求安全，自然也需要一定的牺牲。笔者是推荐这种协议的，如果条件允许，主要推荐WebSocket+TLS这个协议。曾有小伙伴使用了这个协议一年之久，同一个IP地址至今仍能正常使用，非常隐蔽。

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叙述的那样，WebSocket在拥堵的网络情况下显得效果不佳，而KCP则可以在拥堵的网络下依旧达到一定的速度。所以，在3G、4G这类用户多、网络堵的情况下，KCP甚至可以起到加速的作用。

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

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

TCP

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

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

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

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的网站。h2的下层协议是TCP，因此大家应该知道这类协议的共同缺点了。较之类似的WebSocket协议，传输效率略逊于WebSocket。但是它却有比WebSocket更加好的伪装，由于大部分网站使用HTTP协议，因此h2+TLS这种协议能使V2Ray流量伪装在正常流量中，并且难以察觉。

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协议部署及更新的困难 。

2018年11月，国际互联网工程任务组（The Internet Engineering Task Force，简称 IETF ）将HTTP-over-QUIC 实验性协议将被重命名为 HTTP/3，并有望成为 HTTP 协议的第三个正式版本。

对没错，QUIC可能就是HTTP/3，这个协议代表了互联网的未来。不久之后，无主界也许也会支持这个协议。

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

总结

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

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

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

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

不值得或者是冗余的协议组合：

TLS+KCP

这是相当一部分人喜欢的组合。选用KCP的原因是为了在某些恶劣的网络环境下拥有比较好的上网体验。而使用 TLS 的原因大约有两种考虑：一是认为 TLS 拥有与 HTTPS 一样的特征不容易被墙；二是觉得TLS具有更好的加密效果不容易被墙。对于第一点，尽管 HTTPS 是基于 TLS，但并不等同与 TLS，因此 TLS 与 HTTPS 的特征一样的说法是错误的；对于第二点，使用更强的加密算法而被墙的几率更小这个观点并未得到论证。然而这并不是我不推荐的理由，真正的原因的是不使用 TLS 并没什么坏处，额外使用 TLS也没有足够的好处。

TLS+HTTP 伪装

我并没有测试过这个组合，不清楚最外层是 TLS 还是 HTTP 伪装。无论哪一种，处于内层的配置将会失去其意义。

单纯使用 Websocket

理论上，使用 Websocket 会比 TCP 性能差一些，单纯所以如果不是搭配 CDN、nginx 或者在 PaaS 上使用，那还是使用 TCP 吧。

点我即可安装ssr软件、获取ssr节点推荐