gRPC+gRPC Gateway 能不能不用證書？

若是你之前有涉獵過 gRPC+gRPC Gateway 這兩個組件，你確定會遇到這個問題，就是 「爲何非得開 TLS，纔可以實現同端口雙流量，能不能不開？」 又或是 「我不想用證書就實現這些功能，行不行？」。我被無數的人問過無數次這些問題，也說服過不少人，但說服歸說服，不表明放棄。前年不行，不表明今年不行，在今天我但願分享前因後果和具體的實現方式給你。

原文地址：gRPC+gRPC Gateway 能不能不用證書？

過去

爲何 h2 不行

由於 net/http2 僅支持 "h2" 標識，而 "h2" 標識 HTTP/2 必須使用傳輸層安全性（TLS）的協議，此標識符用於 TLS 應用層協議協商字段以及識別 HTTP/2 over TLS。

簡單來說，也就 net/http2 必須使用 TLS 來交互。通俗來說就要用證書，那麼理所固然，也就沒法支持非 TLS 的狀況了。

尋找 h2c

那這條路不行，咱們再想一想別的路？那就是 HTTP/2 規範中的 "h2c" 標識了，"h2c" 標識容許經過明文 TCP 運行 HTTP/2 的協議，此標識符用於 HTTP/1.1 升級標頭字段以及標識 HTTP/2 over TCP。

可是這條路，早在 2015 年就已經有在 issue 中進行討論，當時 @bradfitz 明確表示 「不打算支持 h2c，對僅支持 TLS 的狀況很是滿意，一年後再問我一次」，原文回覆以下：

We do not plan to support h2c. I don't want to receive bug reports from users who get bitten by transparent proxies messing with h2c. Also, until there's widespread browser support, it's not interesting. I am also not interested in being the chicken or the egg to get browser support going. I'm very happy with the TLS-only situation, and things like https://LetsEncrypt.org/ will make TLS much easier (and automatic) soon.

Ask me again in one year.

琢磨其餘方式

使用 cmux

基於多路複用器 soheilhy/cmux 的另類實現 Stoakes/grpc-gateway-example。若對 cmux 的實現方式感興趣，還能夠看看 《Golang: Run multiple services on one port》。

使用第三方 h2

• veqryn/h2c

這種屬於本身實現了 h2c 的邏輯，以此達到效果。

如今

通過社區的不斷討論，最後在 2018 年 6 月，表明 "h2c" 標誌的 golang.org/x/net/http2/h2c 標準庫正式合併進來，自此咱們就可使用官方標準庫（h2c），這個標準庫實現了 HTTP/2 的未加密模式，所以咱們就能夠利用該標準庫在同個端口上既提供 HTTP/1.1 又提供 HTTP/2 的功能了。

使用標準庫 h2c

import (
    ...

    "golang.org/x/net/http2"
    "golang.org/x/net/http2/h2c"
    "google.golang.org/grpc"

    "github.com/grpc-ecosystem/grpc-gateway/runtime"

    pb "github.com/EDDYCJY/go-grpc-example/proto"
)

...

func grpcHandlerFunc(grpcServer *grpc.Server, otherHandler http.Handler) http.Handler {
    return h2c.NewHandler(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        if r.ProtoMajor == 2 && strings.Contains(r.Header.Get("Content-Type"), "application/grpc") {
            grpcServer.ServeHTTP(w, r)
        } else {
            otherHandler.ServeHTTP(w, r)
        }
    }), &http2.Server{})
}

func main() {
    server := grpc.NewServer()

    pb.RegisterSearchServiceServer(server, &SearchService{})

    mux := http.NewServeMux()
    gwmux := runtime.NewServeMux()
    dopts := []grpc.DialOption{grpc.WithInsecure()}

    err := pb.RegisterSearchServiceHandlerFromEndpoint(context.Background(), gwmux, "localhost:"+PORT, dopts)
    ...
    mux.Handle("/", gwmux)
    http.ListenAndServe(":"+PORT, grpcHandlerFunc(server, mux))
}

咱們能夠看到關鍵之處在於調用了 h2c.NewHandler 方法進行了特殊處理，h2c.NewHandler 會返回一個 http.handler，主要的內部邏輯是攔截了全部 h2c 流量，而後根據不一樣的請求流量類型將其劫持並重定向到相應的 Hander 中去處理。

驗證

HTTP/1.1

$ curl -X GET 'http://127.0.0.1:9005/search?request=EDDYCJY'
{"response":"EDDYCJY"}

HTTP/2(gRPC)

...
func main() {
    conn, err := grpc.Dial(":"+PORT, grpc.WithInsecure())
    ...
    client := pb.NewSearchServiceClient(conn)
    resp, err := client.Search(context.Background(), &pb.SearchRequest{
        Request: "gRPC",
    })
}

輸出結果：

$ go run main.go
2019/06/21 20:04:09 resp: gRPC h2c Server

總結

在本文中我介紹了大體的來龍去脈，且介紹了幾種解決方法，我建議你選擇官方的 h2c 標準庫去實現這個功能，也簡單。在最後，無論你是否曾經爲這個問題煩惱過許久，又或者正在糾結，都但願這篇文章可以幫到你。

參考

• https://github.com/golang/go/...
• https://github.com/golang/go/...
• https://github.com/golang/net...
• https://go-review.googlesourc...