不能用 net/http.Handler 做多协议切换,因其强制解析 HTTP 头、消费 r.Body 并缓冲请求流,导致 gRPC、WebSocket、MQTT 等协议无法获取原始帧头而报错;必须通过自定义 net.Listener 在 Accept 后仅读前 16 字节探测协议,并零消耗分发至对应服务。

为什么不能用 net/http.Handler 做多协议切换
因为 net/http.Handler 的契约强制消费 r.Body、校验 HTTP 头、缓冲请求流,而 gRPC、WebSocket、MQTT 等协议依赖原始字节流或连接生命周期。一旦调用 r.ParseForm() 或 io.ReadAll(r.Body),下游协议解析器就收不到帧头,直接报错:rpc error: code = Internal desc = transport: received the unexpected content-type "text/plain" 或 WebSocket 连接瞬间 400。
- HTTP/2 流量(如 gRPC)必须由
grpc.Server.ServeConn()直接接管底层net.Conn,不能走http.HandlerFunc - WebSocket 升级请求必须在
http.ResponseWriter上调用Hijack()拿到原始连接,否则Upgrade头会被丢弃 - MQTT/CoAP 根本不在 HTTP 协议栈里,
http.Server连解析机会都不给
如何用 net.Listener 实现协议识别与分流
核心是自己包装 net.Listener,在 Accept() 后只读前 16 字节做协议探测,再把连接“塞回”对应协议服务实例中处理——这个过程必须快、轻、零消费 Body。
- 读取后立即调用
conn.SetReadDeadline(),防止 TLS 握手卡住整个 accept 循环 - 用
switch判断特征字节:buf[0] == 0x16(TLS record)、bytes.HasPrefix(buf, []byte("GET "))(HTTP)、buf[0]&0xf0 == 0x10(MQTT CONNECT) - HTTP 流量交给改造过的
http.Server(禁用自动 body 解析);gRPC 流量交给grpc.Server.Serve(&oneConnListener{conn});MQTT 交给hmq或mochi-mqtt/server - 切忌在识别逻辑里调用
io.ReadAll(conn)——这会破坏所有后续协议的帧边界
如何让 gRPC 和 WebSocket 在单端口共存不互相劫持
HTTP/2 帧和 WebSocket Upgrade 请求在 TLS 握手后共享同一连接,ALPN 无法可靠区分 gRPC(本质是 h2)和 WebSocket(本质是 h1 + upgrade)。物理隔离仍是首选,但若必须单端口,靠路径前缀硬隔离最稳妥。
Go 配置库,使用 spf13/viper — 分层优先级(flag > env >file > KV > default),提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 对路径以
/grpc/开头的请求,交由 gRPC codec 处理;对/ws/开头的,立即Hijack()并用websocket.Upgrader.Upgrade()接管 - 所有非标准路径(如
/mqtt/、/coap/)不注册进http.ServeMux,改用独立http.HandlerFunc拦截并启动专用协程监听 - 禁止在任何中间件里调用
r.Body.Read()或修改r.Header,否则Connection: upgrade可能被篡改 - gRPC-Web 请求要缓存前 1024 字节供
grpc.ServeConn()重放,不能直接读空r.Body
协议适配器层怎么写才不耦合业务逻辑
关键不是“支持多少协议”,而是让业务逻辑完全不感知传输层。所有协议最终都调用同一套 service 接口,参数和返回值用纯 Go struct,不含 HTTP header、gRPC metadata 等协议字段。
立即学习“go语言免费学习笔记(深入)”;
- HTTP adapter:从
*http.Request提取 body/query/header → 构造 domain struct → 调用UserService.CreateUser(ctx, req)→ 把 resp 写成 JSON - gRPC adapter:实现 .proto 生成的 server interface,把 pb struct 转成 domain struct;错误统一用
status.Errorf()包装 - WebSocket adapter:用
gorilla/websocket读消息后根据type字段路由到 service 方法,结果以 JSON 消息推回 client - adapter 层不做业务判断,只做“翻译”,且可单独启停(比如临时关闭 gRPC 端点)
r.Body 的逻辑之前——哪怕是一行日志中间件、一个 JWT 解析器,只要提前读了 body,后续 gRPC 或 WebSocket 就必然失败。这不是配置问题,是数据流顺序问题。

















