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.最后做一些处理工作

主要包括：异常处理，资源回收，状态更新。我们了解即可，重点还是放在主要流程上。