前言
對(duì)于Golang來(lái)說(shuō)，實(shí)現(xiàn)一個(gè)簡(jiǎn)單的 http server 非常容易，只需要短短幾行代碼。同時(shí)有了協(xié)程的加持，Go實(shí)現(xiàn)的 http server 能夠取得非常優(yōu)秀的性能。這篇文章將會(huì)對(duì)go標(biāo)準(zhǔn)庫(kù) net/http 實(shí)現(xiàn)http服務(wù)的原理進(jìn)行較為深入的探究，以此來(lái)學(xué)習(xí)了解網(wǎng)絡(luò)編程的常見(jiàn)范式以及設(shè)計(jì)思路。
HTTP服務(wù)
基于HTTP構(gòu)建的網(wǎng)絡(luò)應(yīng)用包括兩個(gè)端，即客戶端( Client )和服務(wù)端( Server )。兩個(gè)端的交互行為包括從客戶端發(fā)出 request 、服務(wù)端接受 request 進(jìn)行處理并返回 response 以及客戶端處理 response 。所以http服務(wù)器的工作就在于如何接受來(lái)自客戶端的 request ，并向客戶端返回 response 。
典型的http服務(wù)端的處理流程可以用下圖表示：
服務(wù)器在接收到請(qǐng)求時(shí)，首先會(huì)進(jìn)入路由( router )，這是一個(gè) Multiplexer ，路由的工作在于為這個(gè) request 找到對(duì)應(yīng)的處理器( handler )，處理器對(duì) request 進(jìn)行處理，并構(gòu)建 response 。Golang實(shí)現(xiàn)的 http server 同樣遵循這樣的處理流程。
我們先看看Golang如何實(shí)現(xiàn)一個(gè)簡(jiǎn)單的 http server ：
package main
import (
"fmt"
"net/http"
)
func indexHandler(w http.ResponseWriter, r *http.Request) {
fmt.Fprintf(w, "hello world")
}
func main() {
http.HandleFunc("/", indexHandler)
http.ListenAndServe(":8000", nil)
}
運(yùn)行代碼之后，在瀏覽器中打開(kāi) localhost:8000 就可以看到 hello world 。這段代碼先利用 http.HandleFunc 在根路由 / 上注冊(cè)了一個(gè) indexHandler , 然后利用 http.ListenAndServe 開(kāi)啟監(jiān)聽(tīng)。當(dāng)有請(qǐng)求過(guò)來(lái)時(shí)，則根據(jù)路由執(zhí)行對(duì)應(yīng)的 handler 函數(shù)。
我們?cè)賮?lái)看一下另外一種常見(jiàn)的 http server 實(shí)現(xiàn)方式：
package main
import (
"fmt"
"net/http"
)
type indexHandler struct {
content string
}
func (ih *indexHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
fmt.Fprintf(w, ih.content)
}
func main() {
http.Handle("/", indexHandler{content: "hello world!"})
http.ListenAndServe(":8001", nil)
}
Go實(shí)現(xiàn)的 http 服務(wù)步驟非常簡(jiǎn)單，首先注冊(cè)路由，然后創(chuàng)建服務(wù)并開(kāi)啟監(jiān)聽(tīng)即可。下文我們將從注冊(cè)路由、開(kāi)啟服務(wù)、處理請(qǐng)求這幾個(gè)步驟了解Golang如何實(shí)現(xiàn) http 服務(wù)。
注冊(cè)路由
http.HandleFunc 和 http.Handle 都是用于注冊(cè)路由，可以發(fā)現(xiàn)兩者的區(qū)別在于第二個(gè)參數(shù)，前者是一個(gè)具有 func(w http.ResponseWriter, r *http.Requests) 簽名的函數(shù)，而后者是一個(gè)結(jié)構(gòu)體，該結(jié)構(gòu)體實(shí)現(xiàn)了 func(w http.ResponseWriter, r *http.Requests) 簽名的方法。
http.HandleFunc 和 http.Handle 的源碼如下：
func HandleFunc(pattern string, handler func(ResponseWriter, *Request)) {
DefaultServeMux.HandleFunc(pattern, handler)
}
// HandleFunc registers the handler function for the given pattern.
func (mux *ServeMux) HandleFunc(pattern string, handler func(ResponseWriter, *Request)) {
if handler == nil {
panic("http: nil handler")
}
mux.Handle(pattern, HandlerFunc(handler))
}
func Handle(pattern string, handler Handler) {
DefaultServeMux.Handle(pattern, handler)
}
可以看到這兩個(gè)函數(shù)最終都由 DefaultServeMux 調(diào)用 Handle 方法來(lái)完成路由的注冊(cè)。
這里我們遇到兩種類(lèi)型的對(duì)象： ServeMux 和 Handler ，我們先說(shuō) Handler 。
Handler
Handler 是一個(gè)接口：
type Handler interface {
ServeHTTP(ResponseWriter, *Request)
}
Handler 接口中聲明了名為 ServeHTTP 的函數(shù)簽名，也就是說(shuō)任何結(jié)構(gòu)只要實(shí)現(xiàn)了這個(gè) ServeHTTP 方法，那么這個(gè)結(jié)構(gòu)體就是一個(gè) Handler 對(duì)象。其實(shí)go的 http 服務(wù)都是基于 Handler 進(jìn)行處理，而 Handler 對(duì)象的 ServeHTTP 方法也正是用以處理 request 并構(gòu)建 response 的核心邏輯所在。
回到上面的 HandleFunc 函數(shù)，注意一下這行代碼：
mux.Handle(pattern, HandlerFunc(handler))
可能有人認(rèn)為 HandlerFunc 是一個(gè)函數(shù)，包裝了傳入的 handler 函數(shù)，返回了一個(gè) Handler 對(duì)象。然而這里 HandlerFunc 實(shí)際上是將 handler 函數(shù)做了一個(gè) 類(lèi)型轉(zhuǎn)換 ，看一下 HandlerFunc 的定義：
type HandlerFunc func(ResponseWriter, *Request)
// ServeHTTP calls f(w, r).
func (f HandlerFunc) ServeHTTP(w ResponseWriter, r *Request) {
f(w, r)
}
HandlerFunc 是一個(gè)類(lèi)型，只不過(guò)表示的是一個(gè)具有 func(ResponseWriter, *Request) 簽名的函數(shù)類(lèi)型，并且這種類(lèi)型實(shí)現(xiàn)了 ServeHTTP 方法（在 ServeHTTP 方法中又調(diào)用了自身），也就是說(shuō)這個(gè)類(lèi)型的函數(shù)其實(shí)就是一個(gè) Handler 類(lèi)型的對(duì)象。利用這種類(lèi)型轉(zhuǎn)換，我們可以將一個(gè) handler 函數(shù)轉(zhuǎn)換為一個(gè)
Handler 對(duì)象，而不需要定義一個(gè)結(jié)構(gòu)體，再讓這個(gè)結(jié)構(gòu)實(shí)現(xiàn) ServeHTTP 方法。讀者可以體會(huì)一下這種技巧。
ServeMux
Golang中的路由（即 Multiplexer ）基于 ServeMux 結(jié)構(gòu)，先看一下 ServeMux 的定義：
type ServeMux struct {
mu sync.RWMutex
m map[string]muxEntry
es []muxEntry // slice of entries sorted from longest to shortest.
hosts bool // whether any patterns contain hostnames
}
type muxEntry struct {
h Handler
pattern string
}
這里重點(diǎn)關(guān)注 ServeMux 中的字段 m ，這是一個(gè) map ， key 是路由表達(dá)式， value 是一個(gè) muxEntry 結(jié)構(gòu)， muxEntry 結(jié)構(gòu)體存儲(chǔ)了對(duì)應(yīng)的路由表達(dá)式和 handler 。
值得注意的是， ServeMux 也實(shí)現(xiàn)了 ServeHTTP 方法：
func (mux *ServeMux) ServeHTTP(w ResponseWriter, r *Request) {
if r.RequestURI == "*" {
if r.ProtoAtLeast(1, 1) {
w.Header().Set("Connection", "close")
}
w.WriteHeader(StatusBadRequest)
return
}
h, _ := mux.Handler(r)
h.ServeHTTP(w, r)
}
也就是說(shuō) ServeMux 結(jié)構(gòu)體也是 Handler 對(duì)象，只不過(guò) ServeMux 的 ServeHTTP 方法不是用來(lái)處理具體的 request 和構(gòu)建 response ，而是用來(lái)確定路由注冊(cè)的 handler 。
注冊(cè)路由
搞明白 Handler 和 ServeMux 之后，我們?cè)倩氐街暗拇a：
DefaultServeMux.Handle(pattern, handler)
這里的 DefaultServeMux 表示一個(gè)默認(rèn)的 Multiplexer ，當(dāng)我們沒(méi)有創(chuàng)建自定義的 Multiplexer ，則會(huì)自動(dòng)使用一個(gè)默認(rèn)的 Multiplexer 。
然后再看一下 ServeMux 的 Handle 方法具體做了什么：
func (mux *ServeMux) Handle(pattern string, handler Handler) {
mux.mu.Lock()
defer mux.mu.Unlock()
if pattern == "" {
panic("http: invalid pattern")
}
if handler == nil {
panic("http: nil handler")
}
if _, exist := mux.m[pattern]; exist {
panic("http: multiple registrations for " + pattern)
}
if mux.m == nil {
mux.m = make(map[string]muxEntry)
}
// 利用當(dāng)前的路由和handler創(chuàng)建muxEntry對(duì)象
e := muxEntry{h: handler, pattern: pattern}
// 向ServeMux的map[string]muxEntry增加新的路由匹配規(guī)則
mux.m[pattern] = e
// 如果路由表達(dá)式以'/'結(jié)尾，則將對(duì)應(yīng)的muxEntry對(duì)象加入到[]muxEntry中，按照路由表達(dá)式長(zhǎng)度排序
if pattern[len(pattern)-1] == '/' {
mux.es = appendSorted(mux.es, e)
}
if pattern[0] != '/' {
mux.hosts = true
}
}
Handle 方法主要做了兩件事情：一個(gè)就是向 ServeMux 的 map[string]muxEntry 增加給定的路由匹配規(guī)則；然后如果路由表達(dá)式以 '/' 結(jié)尾，則將對(duì)應(yīng)的 muxEntry 對(duì)象加入到 []muxEntry 中，按照路由表達(dá)式長(zhǎng)度排序。前者很好理解，但后者可能不太容易看出來(lái)有什么作用，這個(gè)問(wèn)題后面再作分析。
自定義ServeMux
我們也可以創(chuàng)建自定義的 ServeMux 取代默認(rèn)的 DefaultServeMux ：
package main
import (
"fmt"
"net/http"
)
func indexHandler(w http.ResponseWriter, r *http.Request) {
fmt.Fprintf(w, "hello world")
}
func htmlHandler(w http.ResponseWriter, r *http.Request) {
w.Header().Set("Content-Type", "text/html")
html := `!doctype html>
META http-equiv="Content-Type" content="text/html" charset="utf-8">
html lang="zh-CN">
head>
title>Golang/title>
meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=0;" />
/head>
body>
div id="app">Welcome!/div>
/body>
/html>`
fmt.Fprintf(w, html)
}
func main() {
mux := http.NewServeMux()
mux.Handle("/", http.HandlerFunc(indexHandler))
mux.HandleFunc("/welcome", htmlHandler)
http.ListenAndServe(":8001", mux)
}
NewServeMux() 可以創(chuàng)建一個(gè) ServeMux 實(shí)例，之前提到 ServeMux 也實(shí)現(xiàn)了 ServeHTTP 方法，因此 mux 也是一個(gè) Handler 對(duì)象。對(duì)于 ListenAndServe() 方法，如果傳入的 handler 參數(shù)是自定義 ServeMux 實(shí)例 mux ，那么 Server 實(shí)例接收到的路由對(duì)象將不再是 DefaultServeMux 而是 mux 。
開(kāi)啟服務(wù)
首先從 http.ListenAndServe 這個(gè)方法開(kāi)始：
func ListenAndServe(addr string, handler Handler) error {
server := Server{Addr: addr, Handler: handler}
return server.ListenAndServe()
}
func (srv *Server) ListenAndServe() error {
if srv.shuttingDown() {
return ErrServerClosed
}
addr := srv.Addr
if addr == "" {
addr = ":http"
}
ln, err := net.Listen("tcp", addr)
if err != nil {
return err
}
return srv.Serve(tcpKeepAliveListener{ln.(*net.TCPListener)})
}
這里先創(chuàng)建了一個(gè) Server 對(duì)象，傳入了地址和 handler 參數(shù)，然后調(diào)用 Server 對(duì)象 ListenAndServe() 方法。
看一下 Server 這個(gè)結(jié)構(gòu)體， Server 結(jié)構(gòu)體中字段比較多，可以先大致了解一下：
type Server struct {
Addr string // TCP address to listen on, ":http" if empty
Handler Handler // handler to invoke, http.DefaultServeMux if nil
TLSConfig *tls.Config
ReadTimeout time.Duration
ReadHeaderTimeout time.Duration
WriteTimeout time.Duration
IdleTimeout time.Duration
MaxHeaderBytes int
TLSNextProto map[string]func(*Server, *tls.Conn, Handler)
ConnState func(net.Conn, ConnState)
ErrorLog *log.Logger
disableKeepAlives int32 // accessed atomically.
inShutdown int32 // accessed atomically (non-zero means we're in Shutdown)
nextProtoOnce sync.Once // guards setupHTTP2_* init
nextProtoErr error // result of http2.ConfigureServer if used
mu sync.Mutex
listeners map[*net.Listener]struct{}
activeConn map[*conn]struct{}
doneChan chan struct{}
onShutdown []func()
}
在 Server 的 ListenAndServe 方法中，會(huì)初始化監(jiān)聽(tīng)地址 Addr ，同時(shí)調(diào)用 Listen 方法設(shè)置監(jiān)聽(tīng)。最后將監(jiān)聽(tīng)的TCP對(duì)象傳入 Serve 方法：
func (srv *Server) Serve(l net.Listener) error {
...
baseCtx := context.Background() // base is always background, per Issue 16220
ctx := context.WithValue(baseCtx, ServerContextKey, srv)
for {
rw, e := l.Accept() // 等待新的連接建立
...
c := srv.newConn(rw)
c.setState(c.rwc, StateNew) // before Serve can return
go c.serve(ctx) // 創(chuàng)建新的協(xié)程處理請(qǐng)求
}
}
這里隱去了一些細(xì)節(jié)，以便了解 Serve 方法的主要邏輯。首先創(chuàng)建一個(gè)上下文對(duì)象，然后調(diào)用 Listener 的 Accept() 等待新的連接建立；一旦有新的連接建立，則調(diào)用 Server 的 newConn() 創(chuàng)建新的連接對(duì)象，并將連接的狀態(tài)標(biāo)志為 StateNew ，然后開(kāi)啟一個(gè)新的 goroutine 處理連接請(qǐng)求。
處理連接
我們繼續(xù)探索 conn 的 serve() 方法，這個(gè)方法同樣很長(zhǎng)，我們同樣只看關(guān)鍵邏輯。堅(jiān)持一下，馬上就要看見(jiàn)大海了。
func (c *conn) serve(ctx context.Context) {
...
for {
w, err := c.readRequest(ctx)
if c.r.remain != c.server.initialReadLimitSize() {
// If we read any bytes off the wire, we're active.
c.setState(c.rwc, StateActive)
}
...
// HTTP cannot have multiple simultaneous active requests.[*]
// Until the server replies to this request, it can't read another,
// so we might as well run the handler in this goroutine.
// [*] Not strictly true: HTTP pipelining. We could let them all process
// in parallel even if their responses need to be serialized.
// But we're not going to implement HTTP pipelining because it
// was never deployed in the wild and the answer is HTTP/2.
serverHandler{c.server}.ServeHTTP(w, w.req)
w.cancelCtx()
if c.hijacked() {
return
}
w.finishRequest()
if !w.shouldReuseConnection() {
if w.requestBodyLimitHit || w.closedRequestBodyEarly() {
c.closeWriteAndWait()
}
return
}
c.setState(c.rwc, StateIdle) // 請(qǐng)求處理結(jié)束后，將連接狀態(tài)置為空閑
c.curReq.Store((*response)(nil))// 將當(dāng)前請(qǐng)求置為空
...
}
}
當(dāng)一個(gè)連接建立之后，該連接中所有的請(qǐng)求都將在這個(gè)協(xié)程中進(jìn)行處理，直到連接被關(guān)閉。在 serve() 方法中會(huì)循環(huán)調(diào)用 readRequest() 方法讀取下一個(gè)請(qǐng)求進(jìn)行處理，其中最關(guān)鍵的邏輯就是一行代碼：
serverHandler{c.server}.ServeHTTP(w, w.req)
進(jìn)一步解釋 serverHandler ：
type serverHandler struct {
srv *Server
}
func (sh serverHandler) ServeHTTP(rw ResponseWriter, req *Request) {
handler := sh.srv.Handler
if handler == nil {
handler = DefaultServeMux
}
if req.RequestURI == "*" req.Method == "OPTIONS" {
handler = globalOptionsHandler{}
}
handler.ServeHTTP(rw, req)
}
在 serverHandler 的 ServeHTTP() 方法里的 sh.srv.Handler 其實(shí)就是我們最初在 http.ListenAndServe() 中傳入的 Handler 對(duì)象，也就是我們自定義的 ServeMux 對(duì)象。如果該 Handler 對(duì)象為 nil ，則會(huì)使用默認(rèn)的 DefaultServeMux 。最后調(diào)用 ServeMux 的 ServeHTTP() 方法匹配當(dāng)前路由對(duì)應(yīng)的 handler 方法。
后面的邏輯就相對(duì)簡(jiǎn)單清晰了，主要在于調(diào)用 ServeMux 的 match 方法匹配到對(duì)應(yīng)的已注冊(cè)的路由表達(dá)式和 handler 。
// ServeHTTP dispatches the request to the handler whose
// pattern most closely matches the request URL.
func (mux *ServeMux) ServeHTTP(w ResponseWriter, r *Request) {
if r.RequestURI == "*" {
if r.ProtoAtLeast(1, 1) {
w.Header().Set("Connection", "close")
}
w.WriteHeader(StatusBadRequest)
return
}
h, _ := mux.Handler(r)
h.ServeHTTP(w, r)
}
func (mux *ServeMux) handler(host, path string) (h Handler, pattern string) {
mux.mu.RLock()
defer mux.mu.RUnlock()
// Host-specific pattern takes precedence over generic ones
if mux.hosts {
h, pattern = mux.match(host + path)
}
if h == nil {
h, pattern = mux.match(path)
}
if h == nil {
h, pattern = NotFoundHandler(), ""
}
return
}
// Find a handler on a handler map given a path string.
// Most-specific (longest) pattern wins.
func (mux *ServeMux) match(path string) (h Handler, pattern string) {
// Check for exact match first.
v, ok := mux.m[path]
if ok {
return v.h, v.pattern
}
// Check for longest valid match. mux.es contains all patterns
// that end in / sorted from longest to shortest.
for _, e := range mux.es {
if strings.HasPrefix(path, e.pattern) {
return e.h, e.pattern
}
}
return nil, ""
}
在 match 方法里我們看到之前提到的 map[string]muxEntry 和 []muxEntry 。這個(gè)方法里首先會(huì)利用進(jìn)行精確匹配，在 map[string]muxEntry 中查找是否有對(duì)應(yīng)的路由規(guī)則存在；如果沒(méi)有匹配的路由規(guī)則，則會(huì)進(jìn)行近似匹配。
對(duì)于類(lèi)似 /path1/path2/path3 這樣的路由，如果不能找到精確匹配的路由規(guī)則，那么則會(huì)去匹配和當(dāng)前路由最接近的已注冊(cè)的父路由，所以如果路由 /path1/path2/ 已注冊(cè)，那么該路由會(huì)被匹配，否則繼續(xù)匹配父路由，知道根路由 / 。
由于 []muxEntry 中的 muxEntry 按照路由表達(dá)是從長(zhǎng)到短排序，所以進(jìn)行近似匹配時(shí)匹配到的路由一定是已注冊(cè)父路由中最接近的。
至此，Go實(shí)現(xiàn)的 http server 的大致原理介紹完畢！
總結(jié)
Golang通過(guò) ServeMux 定義了一個(gè)多路器來(lái)管理路由，并通過(guò) Handler 接口定義了路由處理函數(shù)的統(tǒng)一規(guī)范，即 Handler 都須實(shí)現(xiàn) ServeHTTP 方法；同時(shí) Handler 接口提供了強(qiáng)大的擴(kuò)展性，方便開(kāi)發(fā)者通過(guò) Handler 接口實(shí)現(xiàn)各種中間件。相信大家閱讀下來(lái)也能感受到 Handler 對(duì)象在 server 服務(wù)的實(shí)現(xiàn)中真的無(wú)處不在。理解了 server 實(shí)現(xiàn)的基本原理，大家就可以在此基礎(chǔ)上閱讀一些第三方的 http server 框架，以及編寫(xiě)特定功能的中間件。
以上。
參考資料
【Golang標(biāo)準(zhǔn)庫(kù)文檔--net/http】
以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。
您可能感興趣的文章:- golang 實(shí)現(xiàn)tcp server端和client端,并計(jì)算RTT時(shí)間操作
- golang實(shí)現(xiàn)微信小程序商城后臺(tái)系統(tǒng)（moshopserver）
- golang實(shí)現(xiàn)http server提供文件下載功能
- golang的httpserver優(yōu)雅重啟方法詳解
- Golang Socket Server自定義協(xié)議的簡(jiǎn)單實(shí)現(xiàn)方案
