tcp、ws、grpc、h2 这几种传输方式怎么选

一句话结论：不需要过 CDN 就用 tcp（最快、开销最小）；需要过 CDN 就在 ws 和 grpc 里挑——grpc 延迟通常更低，ws 兼容性更好。 配置里的 network（或 URI 参数 type）就是在选这个。

四种传输方式对比

tcp：默认且最快

裸 TCP 直传，没有任何额外协议层。延迟最低、CPU 开销最小。

代价是它没法借助 CDN，而且流量特征相对直白——不过配合 TLS 或 Reality 之后这一点会好很多。如果你的服务器直连质量好、不需要 CDN 中转，tcp 是最优选。

ws：为了过 CDN

WebSocket 建立在 HTTP 之上，所以它可以伪装成普通的网页长连接，穿过 CDN。这是它存在的主要理由：把流量套进 CDN，既能借 CDN 的线路优化，也让服务器真实 IP 不直接暴露。

需要配两个字段：

• path —— 请求路径，比如 /ray。它相当于一个弱口令：路径不对，服务端不会响应
• Host —— HTTP 头里的域名，通常是你的 CDN 域名

代价是每条连接都要多一次 HTTP 升级握手，所以建连稍慢。日常使用感知不明显，但在需要频繁建立新连接的场景（比如打开一个有几十个资源的网页）会有累积影响。

grpc：多路复用带来的优势

gRPC 跑在 HTTP/2 上，最大的特点是多路复用——多个请求共享同一条 TCP 连接，不需要为每个请求重新建连。

实际体感上，这意味着：

• 打开资源多的网页时更快（不用反复握手）
• 在延迟高的线路上优势更明显
• 弱网下有个反面：HTTP/2 的队头阻塞会让丢包影响所有复用的流，而 ws 每条连接独立

只需要配 serviceName，作用类似 ws 的 path。

h2：可以但通常没必要

HTTP/2 直传，同样能过 CDN。它和 grpc 都基于 HTTP/2，功能上大量重叠，而 grpc 在代理场景下的实现更成熟、支持的客户端更多。除非机场明确给的是 h2，否则一般不主动选它。

怎么选：三个问题

1. 服务器直连质量好吗？ 好 → tcp，别折腾。

2. 需要过 CDN 吗？ 需要的话继续往下。

3. 线路延迟高不高、你的使用场景连接多不多？

• 延迟高、网页浏览为主 → grpc（多路复用优势明显）
• 线路丢包多、或者客户端比较老 → ws（每条连接独立，兼容性最好）

实际上多数人不需要自己选——机场给什么用什么。这些知识的用处在于排查：当某个节点连不上，看清它用的是哪种传输、缺了哪个字段，比盲目换节点有效。

常见的配错

ws 缺 path：服务端不响应，表现为连接超时。path 必须和服务端配置完全一致，包括开头的斜杠。

grpc 缺 serviceName：同理。

Host 填错：走 CDN 时 CDN 不知道该回源到哪，返回 404 或 502。

用 ws 却没配 TLS：明文 WebSocket 特征非常明显，而且多数 CDN 不接受非 TLS 的回源。

这些字段用节点链接解析器一眼就能看清——它会把 path、Host、serviceName 这些参数单独列出来并翻成中文说明，缺失的也会提示。解析在你的浏览器里完成，链接不会上传。

小结

• 不过 CDN 就 tcp，最快最省
• 过 CDN 在 ws 和 grpc 里挑：grpc 延迟低、ws 兼容好
• h2 和 grpc 重叠，通常不用主动选
• 传输方式配错的表现多是「连接超时」，看清字段比换节点有效