package net/http是Go語言的主要應用場景之一web應用的基礎，從中可以學習到大量前文提到的io,以及沒有提到的sync包等一系列基礎包的知識，代碼量也相對較多，是一個源碼學習的寶庫。本文主要從一個http server開始，講解Go是如何實現一個http協議服務器的。

主要涉及以下源碼文件：
net/net.go
net/server.go
net/http.go
net/transfer.go
sync/pool.go
sync/mutex.go

0.引子：從最簡單的http server說起

func main() {
    http.HandleFunc("/hi", hi)
    http.ListenAndServe(":9999", nil)
    fmt.Printf("hello, world\n")
}

func hi(res http.ResponseWriter, req *http.Request) {
    fmt.Fprintf(res, "hi")
}

以上就是最簡單的服務器代碼，運行后監聽本機的9999端口，在瀏覽器中打開http://localhost:9999可以看到返回的hi，接下來就從此入手，開始分析net/http模塊。

1.Handler： 從路由開始上路

先來分析http.HandleFunc("/hi", hi) 這一句，查看源碼發現：

func HandleFunc(pattern string, handler func(ResponseWriter, *Request)) {
    DefaultServeMux.HandleFunc(pattern, handler)
}

首先我們了解到handler的定義是這樣的func(ResponseWriter, *Request)。這個定義很關鍵，先提一下。
然后看到了DefaultServeMux，這個類是來自于ServeMux結構的一個實例，而后者是一個『路由器』的角色，在后面講到的請求處理過程中，ServeMux用來匹配請求的地址，分配適合的handler來完成業務邏輯。
完整的來講，我們應該先定義一個自己的ServeMux，并向他分配路由，像這樣：

mux := http.NewServeMux()
mux.HandleFunc("/", func(w http.ResponseWriter, req *http.Request) {
    fmt.Fprintf(w, "Welcome to the home page!")
})
http.ListenAndServe(":9999", mux)

1.生成一個路由器
2.向路由器注冊路由
3.由路由器以及服務地址建立底層連接并提供服務

而之前的簡寫方式只是省略了建立路由的過程，實際上用了系統自帶的DefaultServeMux作為路由器而已。

2.向net包匆匆一瞥：一切的基礎在net.Conn

接下來看到http.ListenAndServe(":9999", nil)這句代碼的源碼。

func ListenAndServe(addr string, handler Handler) error {
    server := &Server{Addr: addr, Handler: handler}
    return server.ListenAndServe()
}

首先生成了一個server對象，并調用了它的ListenAndServe方法。Server對象顧名思義，封裝了有關提供web服務相關的所有信息，是一個比較重要的類。

// A Server defines parameters for running an HTTP server.
// The zero value for Server is a valid configuration.
type Server struct {
    Addr         string        // TCP address to listen on, ":http" if empty
    Handler      Handler       // handler to invoke, http.DefaultServeMux if nil
    ReadTimeout  time.Duration // maximum duration before timing out read of the request
    WriteTimeout time.Duration // maximum duration before timing out write of the response
    TLSConfig    *tls.Config   // optional TLS config, used by ListenAndServeTLS

    MaxHeaderBytes int

    TLSNextProto map[string]func(*Server, *tls.Conn, Handler)

    ConnState func(net.Conn, ConnState)

    ErrorLog *log.Logger

    disableKeepAlives int32     // accessed atomically.
    nextProtoOnce     sync.Once // guards setupHTTP2_* init
    nextProtoErr      error     // result of http2.ConfigureServer if used
}

1.handler即路由器（實際上路由器本身作為handler，其中有注冊了很多handler），見Handler定義：

type Handler interface {
    ServeHTTP(ResponseWriter, *Request)
}

和之前注冊的函數幾乎一樣。
2.ErrorLog默認以stdErr作為輸出，也可以提供其他的logger形式。
3.其他的是一些配置以及https,http2的相關支持，暫擱一邊。

初始化一個Server必須要的是地址（端口）以及路由，其他都可以按照默認值。生成好Server之后，進入ListenAndServe,源碼主要有：

ln, err := net.Listen("tcp", addr)
return srv.Serve(tcpKeepAliveListener{ln.(*net.TCPListener)})

重要的有兩句，首先調用底層的net模塊對地址實現監聽，返回的ln是一個Listener類型，這個類型有三個方法：

• Accept() (Conn, error)
• Close() error
• Addr() Addr

我們先不碰net模塊，只要知道ln可以通過accept()返回一個net.Conn就夠了，獲取一個連接的上下文意味著和客戶端建立了通道，可以獲取數據，并把處理的結果返回給客戶端了。接下來srv.Serve()方法接受了ln，在這里程序被分為了兩層：ln負責連接的底層建立，讀寫，關閉；Server負責數據的處理。

補充說明一下net.Conn，這個Conn區別于后文要講的server.conn，是比較底層的，有

• Read(b []byte) (n int, err error)
• Write(b []byte) (n int, err error)

兩個方法，也意味著實現了io.Reader, io.Writer接口。

3.回到server：建立一個服務器，用goroutine 優雅處理并發

接著前面說，建立好ln之后，用tcpKeepAliveListener類型簡單包裝，作為參數傳給srv.Serve()方法，該方法十分重要，值得放出全部代碼：

// Serve accepts incoming connections on the Listener l, creating a
// new service goroutine for each. The service goroutines read requests and
// then call srv.Handler to reply to them.
//
// For HTTP/2 support, srv.TLSConfig should be initialized to the
// provided listener's TLS Config before calling Serve. If
// srv.TLSConfig is non-nil and doesn't include the string "h2" in
// Config.NextProtos, HTTP/2 support is not enabled.
//
// Serve always returns a non-nil error.
func (srv *Server) Serve(l net.Listener) error {
    defer l.Close()
    if fn := testHookServerServe; fn != nil {
        fn(srv, l)
    }
    var tempDelay time.Duration // how long to sleep on accept failure

    if err := srv.setupHTTP2_Serve(); err != nil {
        return err
    }

    // TODO: allow changing base context? can't imagine concrete
    // use cases yet.
    baseCtx := context.Background()
    ctx := context.WithValue(baseCtx, ServerContextKey, srv)
    ctx = context.WithValue(ctx, LocalAddrContextKey, l.Addr())
    for {
        rw, e := l.Accept()
        if e != nil {
            if ne, ok := e.(net.Error); ok && ne.Temporary() {
                if tempDelay == 0 {
                    tempDelay = 5 * time.Millisecond
                } else {
                    tempDelay *= 2
                }
                if max := 1 * time.Second; tempDelay > max {
                    tempDelay = max
                }
                srv.logf("http: Accept error: %v; retrying in %v", e, tempDelay)
                time.Sleep(tempDelay)
                continue
            }
            return e
        }
        tempDelay = 0
        c := srv.newConn(rw)
        c.setState(c.rwc, StateNew) // before Serve can return
        go c.serve(ctx)
    }
}

分析一下：

a) 首先是context這個類型

這個類型比較奇葩，其作用就是一個map，以key,value的形式設置一些背景變量,使用方法是context.WithValue(parentCtx,key,value)

b) 然后進入一個for無限循環，

l.Accept()阻塞直到獲取到一個net.Conn，之后通過srv.newConn(rw)建立一個server.conn(屬于私有變量，不對外暴露)，并設置狀態為StateNew

c) 啟動一個goroutine來處理這個連接

調用go c.serve(ctx)。從這里可以看出，go語言的并發模型不同于nodejs的單線程回調模型，也不同于Java的多線程方案，采用原生的goroutine來處理既有隔離性，又兼顧了性能。因為這樣不會發生nodejs中因為異常處理問題經常讓服務器掛掉的現象。同時，goroutine的創建代價遠遠低于創建線程，當然能在同一臺機器比Java服務器達到更大的并發量了。

4. 從server到conn：一次請求所有的精華都在conn

前面提到了server.conn，來看一下源碼：

// A conn represents the server side of an HTTP connection.
type conn struct {
    // server is the server on which the connection arrived.
    // Immutable; never nil.
    server *Server

    // rwc is the underlying network connection.
    // This is never wrapped by other types and is the value given out
    // to CloseNotifier callers. It is usually of type *net.TCPConn or
    // *tls.Conn.
    rwc net.Conn

    // remoteAddr is rwc.RemoteAddr().String(). It is not populated synchronously
    // inside the Listener's Accept goroutine, as some implementations block.
    // It is populated immediately inside the (*conn).serve goroutine.
    // This is the value of a Handler's (*Request).RemoteAddr.
    remoteAddr string

    // tlsState is the TLS connection state when using TLS.
    // nil means not TLS.
    tlsState *tls.ConnectionState

    // werr is set to the first write error to rwc.
    // It is set via checkConnErrorWriter{w}, where bufw writes.
    werr error

    // r is bufr's read source. It's a wrapper around rwc that provides
    // io.LimitedReader-style limiting (while reading request headers)
    // and functionality to support CloseNotifier. See *connReader docs.
    r *connReader

    // bufr reads from r.
    // Users of bufr must hold mu.
    bufr *bufio.Reader

    // bufw writes to checkConnErrorWriter{c}, which populates werr on error.
    bufw *bufio.Writer

    // lastMethod is the method of the most recent request
    // on this connection, if any.
    lastMethod string

    // mu guards hijackedv, use of bufr, (*response).closeNotifyCh.
    mu sync.Mutex

    // hijackedv is whether this connection has been hijacked
    // by a Handler with the Hijacker interface.
    // It is guarded by mu.
    hijackedv bool
}

解釋一下：
首先，持有server的引用；持有對原始net.Conn引用；持有一個reader，封裝自底層讀取接口，可以從連接中讀取數據，以及一個bufr（還是前面的reader，加了緩沖）。以及一個對應的同步鎖，鎖定對本身的參數修改，防止同步更新出錯。
然后，這里的mu類型是sync.Mutex這個類型的作用有點像Java中的synchronized塊（有關于Java的Synchronized，可以參考本人另一篇拙作《Java多線程你只需要看著一篇就夠了》），mu就是持有對象鎖的那個實例。我們可以看到conn的hijackedv屬性就是通過mu來進行維護的，目的是防止同步更新問題。參考conn.hijackLocked()，不再展開。

繼續看serv.Serve()方法，接著前面的3點：

d) setState(state)

實際上state被維護在Server里，只不過通過conn來調用了。一共有StateNew, StateActive, StateIdle, StateHijacked, StateClosed五個狀態。從new開始，當讀取了一個字節之后進入active，讀取完了并發送response之后，進入idle。終結有兩種，主動終結closed以及被接管： Hijack讓調用者接管連接,在調用Hijack()后,http server庫將不再對該連接進行處理,對于該連接的管理和關閉責任將由調用者接管。參考interface Hijacker

e) c.serve(ctx)

讓我們先來看conn.serve()源碼：

// Serve a new connection.
func (c *conn) serve(ctx context.Context) {
    c.remoteAddr = c.rwc.RemoteAddr().String()
    defer func() {
        if err := recover(); err != nil {
            const size = 64 << 10
            buf := make([]byte, size)
            buf = buf[:runtime.Stack(buf, false)]
            c.server.logf("http: panic serving %v: %v\n%s", c.remoteAddr, err, buf)
        }
        if !c.hijacked() {
            c.close()
            c.setState(c.rwc, StateClosed)
        }
    }()

    if tlsConn, ok := c.rwc.(*tls.Conn); ok {
        if d := c.server.ReadTimeout; d != 0 {
            c.rwc.SetReadDeadline(time.Now().Add(d))
        }
        if d := c.server.WriteTimeout; d != 0 {
            c.rwc.SetWriteDeadline(time.Now().Add(d))
        }
        if err := tlsConn.Handshake(); err != nil {
            c.server.logf("http: TLS handshake error from %s: %v", c.rwc.RemoteAddr(), err)
            return
        }
        c.tlsState = new(tls.ConnectionState)
        *c.tlsState = tlsConn.ConnectionState()
        if proto := c.tlsState.NegotiatedProtocol; validNPN(proto) {
            if fn := c.server.TLSNextProto[proto]; fn != nil {
                h := initNPNRequest{tlsConn, serverHandler{c.server}}
                fn(c.server, tlsConn, h)
            }
            return
        }
    }

    // HTTP/1.x from here on.

    c.r = &connReader{r: c.rwc}
    c.bufr = newBufioReader(c.r)
    c.bufw = newBufioWriterSize(checkConnErrorWriter{c}, 4<<10)

    ctx, cancelCtx := context.WithCancel(ctx)
    defer cancelCtx()

    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)
        }
        if err != nil {
            if err == errTooLarge {
                // Their HTTP client may or may not be
                // able to read this if we're
                // responding to them and hanging up
                // while they're still writing their
                // request. Undefined behavior.
                io.WriteString(c.rwc, "HTTP/1.1 431 Request Header Fields Too Large\r\nContent-Type: text/plain\r\nConnection: close\r\n\r\n431 Request Header Fields Too Large")
                c.closeWriteAndWait()
                return
            }
            if err == io.EOF {
                return // don't reply
            }
            if neterr, ok := err.(net.Error); ok && neterr.Timeout() {
                return // don't reply
            }
            var publicErr string
            if v, ok := err.(badRequestError); ok {
                publicErr = ": " + string(v)
            }
            io.WriteString(c.rwc, "HTTP/1.1 400 Bad Request\r\nContent-Type: text/plain\r\nConnection: close\r\n\r\n400 Bad Request"+publicErr)
            return
        }

        // Expect 100 Continue support
        req := w.req
        if req.expectsContinue() {
            if req.ProtoAtLeast(1, 1) && req.ContentLength != 0 {
                // Wrap the Body reader with one that replies on the connection
                req.Body = &expectContinueReader{readCloser: req.Body, resp: w}
            }
        } else if req.Header.get("Expect") != "" {
            w.sendExpectationFailed()
            return
        }

        // 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.
        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)
    }
}

5.從conn到conn.Serve：http協議的處理實現之處，conn變成Request和Response

上文的conn.Serve(),我們只關注主要邏輯：

1.初始化bufr和bufw。

...
c.bufr = newBufioReader(c.r)
c.bufw = newBufioWriterSize(checkConnErrorWriter{c}, 4<<10)
...

這兩個是讀寫的切入點，從效率考慮，是加了一層緩沖的。值得注意的是bufw和bufr還加了一層sync.Pool的封裝，這是來源于sync包的對象池，目的是為了重用，不需要每次都執行new分配內存。

2.接下來重要的是，從底層讀取客戶端發送的數據：

...
w, err := c.readRequest(ctx)
...

我們看到readRequest定義：

func readRequest(b *bufio.Reader, deleteHostHeader bool) (req *Request, err error)
返回的是 (w *response, err error)，而response又是server.go中的一個重要對象，它是conn的更高一層封裝，包括了req，conn，以及一個writer，當然這個write操作實際上還是由conn，進而由更底層的net.Conn來執行的。對于開發者而言，面對的基本上就是這個response，可以說是一個設計模式中的門面模式。

另外，注意到readRequest執行的時候也調用了mu.Lock()

3.最重要的，調用用戶的handler

...
serverHandler{c.server}.ServeHTTP(w, w.req)

首先serverHandler只是一個包裝，這句實際上調用的是c.server.Handler.ServeHTTP()。而在前面講到的server的初始化中，Handler就是DefaultServeMux或者用戶指定的ServeMux，我們稱之為路由器。在路由器中，根據用戶定義路由規則，來具體調用用戶的業務邏輯方法。

路由器可以看做一個Map，以路由規則(string)作為key，以業務方法(func類型)作為value。

ServeHttp傳入了最重要的兩個高層封裝response對象和Request對象（嚴格來講這里response是私有類型，暴露在外的是ResponseWriter，但從http的本質來理解，還是稱之為response）。

從層次來看，這兩個封裝對象中間封裝的是底層的conn,客戶端發送來的數據（req.body)，以及讀寫的接口reader,writer。

然后，用戶的業務邏輯就接受數據，進行處理，進而返回數據。返回數據一般直接寫入到這個w，即ResponseWriter中。這樣，一個http請求的完整流程就完成了。

4.最后做一些處理工作

主要包括：異常處理，資源回收，狀態更新。我們了解即可，重點還是放在主要流程上。