golang http server 源码解析

http 包怎么用

使用 golang 的 http 包可以很简易的实现一个 web 服务，如下

main.go

package main

import (
    "log"
    "net/http"
    "runtime"
    "fmt"
)

func foo(w http.ResponseWriter, r *http.Request) {
    w.Write([]byte("hi! babe~"))
}

func echo(w http.ResponseWriter, r *http.Request) {
    s := fmt.Sprintf("gorotines count: %d", runtime.NumGoroutine())
    w.Write([]byte(s))
}

func main() {
    mux := http.NewServeMux()

    mux.HandleFunc("/foo", foo)plainplainplainplainplainplainplainplainplainplainplainplainplainplainplainplainplainplainplainplain
    mux.HandleFunc("/echo/goroutines", echo)

    log.Println("Listening...")
    http.ListenAndServe(":3000", mux)
}

那如果我想看看整个服务是怎么实现的，该怎么办呢？
ListenAndServe()接收一个地址和处理程序的参数，此函数的定义如下

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

然后调用了

func (srv *Server) ListenAndServe() error {
    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)})
  }

然后上述函数又调用了 Serve 函数

func (srv *Server) Serve(l net.Listener) error {
    defer l.Close()
    ...
    srv.trackListener(l, true)
    defer srv.trackListener(l, false)

    baseCtx := context.Background() // base is always background, per Issue 16220
    ctx := context.WithValue(baseCtx, ServerContextKey, srv)
    ctx = context.WithValue(ctx, LocalAddrContextKey, l.Addr())
    for {
        // Accept等待并返回listener的下一个连接
        rw, e := l.Accept()
        if e != nil { ... } // 省略一些代码
        tempDelay = 0
        // 使用rw创建一个新连接
        c := srv.newConn(rw)
        // 将链接置为激活状态，同时可指定在客户端连接更改状态时调用可选的回调函数
        c.setState(c.rwc, StateNew) // before Serve can return
        go c.serve(ctx)
    }
}

从上面的go c.serve(ctx)可以看出，http 包在 ctx 上下文组装好之后交给了 gorotine 来处理这个请求。在继续下一步之前，我们先看看这个 ctx 上下文，Context 被定义为一个接口，它在 golang 中被运用的非常广泛。

type Context interface {
    // Deadline 设置了两个参数deadline, ok
    // deadline 表示上下文被取消的截止时间
    // 如果没有设置deadline，Deadline的ok参数会返回false。
    // 连续调用返回结果相同
    Deadline() (deadline time.Time, ok bool) 
 
    // 如果上下文被取消，Done会返回一个被关闭的chan
    // 如果上下文从没被取消过，Done将返回nil
    // 连续调用返回结果相同
    Done() <-chan struct{}

    // Done 的 chan被关闭后，也就是上下文被取消时，Err会返回非零的错误值。
   // 当 Done 的 chan被关闭后，连续调用返回结果相同
    Err() error

    // 也就是通过key去获取该key上下文中的值，如果没有则为nil，可见ctx是一个键值对。该值是线程安全的
    Value(key interface{}) interface{} 
}

好了介绍完 context 之后，我们再来看看 Serve 函数中的baseCtx := context.Background()是干什么的。

// Background返回一个非零的空Context。它没有值也没有deadline，所以也不会被取消，
// 它通常在main函数被用来初始化，测试，以及作为请求传入的顶级Context
func Background() Context {
    return background
}

嗯，他其实就是初始化的一个作用。

接下来又碰到了 WithValue 函数，我们继续看看 WithValue 的定义。

// 生成一个绑定了一个键值对数据的Context，可以通过parent访问到上一层的context，这个绑定的数据可以通过Context.Value方法访问到
func WithValue(parent Context, key, val interface{}) Context {
    if key == nil {
        panic("nil key")
    }
    if !reflect.TypeOf(key).Comparable() {
        panic("key is not comparable")
    }
    return &valueCtx{parent, key, val}
}

// 一个valueCtx结构带有一个键值对。然后用来嵌套其他的Context。
type valueCtx struct {
    Context
    key, val interface{}
}

结合源码，那么这个 context 定义结构就可以了解了

    // 下面定义了两个context key，一个存储了type *Server，另一个存储了type net.Addr
    ServerContextKey = &contextKey{"http-server"}
    LocalAddrContextKey = &contextKey{"local-addr"}
   
    // 顶层context
    ctx := context.WithValue(baseCtx, ServerContextKey, srv)
   // parent 为 顶层的context
    ctx = context.WithValue(ctx, LocalAddrContextKey, l.Addr())

那么为什么这么定义呢？ 思考思考，对 context 的作用和细节还没系统了解过，context 是一个很重要的功能 TODO

继续往下看 go serve(ctx)，可以看到这里用 gorotine 来处理每个链接来支撑并发，这也是支持并发的关键。

// 处理一个新链接
func (c *conn) serve(ctx context.Context) {
    c.remoteAddr = c.rwc.RemoteAddr().String()

    ...

    // HTTP/1.x from here on.
    // 这里又碰到WithCancel函数，WithCancel返回带有父context 的Done通道副本和一个cancelCtx函数。
    // 返回的上下文的Done通道在调用了返回的cancelCtx函数或父context的Done通道关闭时关闭，以先发生者为准。
    // 取消此上下文会释放与其关联的资源，因此代码应在此上下文中运行的操作完成后立即调用cancelCtx。所以可以看到使用了defer去调用cancelCtx释放资源
    ctx, cancelCtx := context.WithCancel(ctx)
    c.cancelCtx = cancelCtx
    defer cancelCtx()

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

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

        ...
        // 核心点，该处就是处理请求的hanler
        serverHandler{c.server}.ServeHTTP(w, w.req)
        w.cancelCtx()
        
        ...

        c.rwc.SetReadDeadline(time.Time{})
    }
}

好了到这我们知道是用serverHandler{c.server}.ServeHTTP(w, w.req)来处理请求的。我们回过头去看看，路由和 handler 是怎么绑定到一起的

    // ServeMux是一个HTTP请求多路复用器，说白了就承担了路由功能呗
    // 在ServeMux 的注释中，我们可以了解到整个路由的一些机制。
    // 模式名称固定，带根的路径，如"/favicon.ico"，或带根的子树，如"/images/"（请注意尾部斜杠）。
    // 较长的模式优先于较短的模式，因此如果存在"/images/"和"/images/thumbnails/"注册的handler，则"/images/thumbnails/"开头的路径将调用后者的handler，然后前者将接收"/images/"子树中任何其他路径的请求，比方说"/images/xxxx"等等。

    mux := http.NewServeMux()

    // 往mux上绑定了两个handler
    mux.HandleFunc("/foo", foo)
    mux.HandleFunc("/echo/goroutines", echo)

我们看到 mux 调用了 HandleFunc，来看看他们的定义

// HandleFunc为给定pattern注册handler
func (mux *ServeMux) HandleFunc(pattern string, handler func(ResponseWriter, *Request)) {
    mux.Handle(pattern, HandlerFunc(handler))
}

// 如果pattern已经存在handler了，将会panic
func (mux *ServeMux) Handle(pattern string, handler Handler) {
    mux.mu.Lock()
    
    ...

    if mux.m == nil {
        mux.m = make(map[string]muxEntry)
    }
    mux.m[pattern] = muxEntry{explicit: true, h: handler, pattern: pattern}

    if pattern[0] != '/' {
        mux.hosts = true
    }

    // 如果pattern是/tree/，则为/tree插入隐式永久重定向
    // 通过显式注册可以覆盖
    n := len(pattern)
    if n > 0 && pattern[n-1] == '/' && !mux.m[pattern[0:n-1]].explicit {
        // 如果pattern包含host name，将其删除并使用剩余的路径进行重定向。
        path := pattern
        if pattern[0] != '/' {
            // strings.Index 返回子串 sep "/" 在字符串 pattern 中第一次出现的位置
            // 如果找不到，则返回 -1，如果 sep 为空，则返回 0。
            path = pattern[strings.Index(pattern, "/"):]
        }
        url := &url.URL{Path: path}
        // 在我们的例子中pattern为"/echo/gorotine/"，则会为"/echo/gorotine" 添加一个重定向
        mux.m[pattern[0:n-1]] = muxEntry{h: RedirectHandler(url.String(), StatusMovedPermanently), pattern: pattern}
    }
}

看完上面的定义，我们知道路由和 handler 是怎么存储的了。

再看看 ServeMux 结构，m 是一个字典形式的，当我们调用 HandlerFunc 会把 pattern 即"/echo/goroutines"作为 key，muxEntry 作为 value，muxEntry 为一个包含 pattern，handler 和 explicit 的结构。

type ServeMux struct {
    mu    sync.RWMutex // 读写锁
    m     map[string]muxEntry // 存储结构
    hosts bool // whether any patterns contain hostnames
}

type muxEntry struct {
    explicit bool  // 该pattern是否完全匹配handler
    h        Handler
    pattern  string
}

好了，上述把 handler 绑定到了 server 上。那么是如何通过 url 查找 handler 的呢？先看看 ServeHTTP

// ServeHTTP将请求分派给handler，该handler的pattern与请求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
    }
    // 通过Handler找到最匹配的handler来处理该请求
    h, _ := mux.Handler(r)
    // 调用处理请求
    h.ServeHTTP(w, r)
}

从上面代码可以看到，使用 handler 的 ServeHTTP 方法去处理请求，这里又有一个疑问了，为什么 ServeHTTP 的 w 是值传递，而 r 是引用传递呢？
先看看 w，r 的定义，通过观察 ResponseWriter，和 Request 的定义就知道为什么这么做了。

// HTTP处理程序使用ResponseWriter接口来构造HTTP响应。
// Handler.ServeHTTP方法返回后，可能就无法使用ResponseWriter了。
type ResponseWriter interface {
    Header() Header
    Write([]byte) (int, error)
    WriteHeader(int)
}

// 请求表示由服务器接收或由客户端发送的HTTP请求。
type Request struct {
    ...
}

可以看到，ResponseWriter 是一个接口，Request 是一个结构。我们往回拨一下，看看这个接口是什么。

w, err := c.readRequest(ctx)
...
// 正是readRequest返回的
serverHandler{c.server}.ServeHTTP(w, w.req)

// 再看看 readRequest的函数签名，其实也是一个指针来的。
func (c *conn) readRequest(ctx context.Context) (w *response, err error)
{
    ...
    w = &response{
        conn:          c,
        cancelCtx:     cancelCtx,
        req:           req,
        reqBody:       req.Body,
        handlerHeader: make(Header),
        contentLength: -1,
        closeNotifyCh: make(chan bool, 1),

        // We populate these ahead of time so we're not
        // reading from req.Header after their Handler starts
        // and maybe mutates it (Issue 14940)
        wants10KeepAlive: req.wantsHttp10KeepAlive(),
        wantsClose:       req.wantsClose(),
    }
    if isH2Upgrade {
        w.closeAfterReply = true
    }
    // 这里有个令人窒息的操作，对于vegetable的我来说有点难以理解。w.cw.res的res其实也是一个response，w.w的第一个w是response结构，第二个w是一个*bufio.Writer结构。
    w.cw.res = w
    // newBufioWriterSize返回一个Writer结构的指针，而w的Writer是一个方法，注意区分
    w.w = newBufioWriterSize(&w.cw, bufferBeforeChunkingSize)
    return w, nil
}

// response的Write方法正是掉用了第二个w结构的Write方法，把数据写入了缓冲区
// 在main.go中向response里写数据的方法 w.Write([]byte("hi! babe~"))
func (w *response) Write(data []byte) (n int, err error) {
    return w.write(len(data), data, "")
}

// Write的具体实现
func (w *response) write(lenData int, dataB []byte, dataS string) (n int, err error) {
    ...
    if dataB != nil {
        return w.w.Write(dataB)
    } else {
        return w.w.WriteString(dataS)
    }
}

// w.w 也就是 *bufio.Writer结构 的方法。可以看到通过copy把p写入了write结构。
func (b *Writer) Write(p []byte) (nn int, err error) {
    ...
    n := copy(b.buf[b.n:], p)
    b.n += n
    nn += n
    return nn, nil
}

从上面的代码可以看到 ResponseWriter 接口，其实也是传入了一个 response 结构的指针，又解决一个疑问，nice

// Handler返回用于给定请求的handler，返回依据参考r.Method，r.Host和r.URL.Path等参数。它总是返回一个非空的handler（如果没有则返回NotFound的handler）。
// 如果路径不规范，则处理程序将会走内部生成的handler，重定向到它的规范路径。
func (mux *ServeMux) Handler(r *Request) (h Handler, pattern string) {
    if r.Method != "CONNECT" {
        if p := cleanPath(r.URL.Path); p != r.URL.Path {
            _, pattern = mux.handler(r.Host, p)
            url := *r.URL
            url.Path = p
            return RedirectHandler(url.String(), StatusMovedPermanently), pattern
        }
    }

    return mux.handler(r.Host, r.URL.Path)
}

// handler函数是Handler的主要实现，host参数传入请求的r.Host, path参数传入r.URL.Path
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
}

上面的调用链handler.ServeHTTP -> func (mux *ServeMux) Handler(r *Request) -> func (mux *ServeMux) handler(r *Request)

当到达func (mux *ServeMux) handler的时候，一切逻辑就清晰了起来。先抛一个问题，"/echo/"和"/echo/goroutines/"这俩怎么区分 handler？从前面的注释，我们知道"/echo/"会处理它所有的子树，而"/echo/goroutines/"就是它的子树，匹配的时候会根据最长原则，也就是会先匹配"/echo/goroutines/"的 handler，那我们来看看这个具体实现。

// 上层调用match函数path传入r.URL.Path
func (mux *ServeMux) match(path string) (h Handler, pattern string) {
    var n = 0
    // m里的存储规则是 m['/echo/gorotines/'] = EntryMux{}
    for k, v := range mux.m {
        if !pathMatch(k, path) {
            continue
        }
        // 从pathMatch函数可以知道"/echo/"会匹配所有它的子树，也就是类似"/echo/xxx"这些，该函数都会返回true。
        // 所以下面这段逻辑就是上面问题的答案。即最长原则，如果满足len(k) > n 的情况，h会被替换成更长path的那个handler。
        // 这段代码的时间复杂度是O(n)，其他的更高效的web框架会不会实现一个O(lgn)的算法呢？我们知道trie树可以做的，下次看看其他的框架怎么实现的
        if h == nil || len(k) > n {
            n = len(k)
            h = v.h
            pattern = v.pattern
        }
    }
    return
}

// 可以看到这个pathMatch是拿pattern和path做比较，
func pathMatch(pattern, path string) bool {
    if len(pattern) == 0 {
        // should not happen
        return false
    }
    n := len(pattern)
    // 如果pattern不以'/'结尾 直接比较
    if pattern[n-1] != '/' {
        return pattern == path
    }
    // 关键部位，path比pattern要长
    // 截取path[0:n] 和 pattern匹配，也就是如果我们的path为"/echo/goroutines/" 我们注册的handler只有"/echo/"的话，那么"/echo/goroutines/" 会匹配到"/echo/"
    return len(path) >= n && path[0:n] == pattern
}

带着一些问题，阅读了整个 http 请求的一些源码，其中确实很复杂，通过了解代码能搞大概搞清楚怎么处理的，当然作者为什么这么写脑海里仍然有一个疑问，等姿势水平再高一点再来探究。整篇分析到此结束，怎么把这些条理化展示的水平还有待提高。

回顾一下提出的几个问题

• "/echo/"和"/echo/goroutines/"这怎么区分匹配 handler？
• 为什么 ServeHTTP 的 w 是值传递，而 r 是引用传递呢？
• http server 怎么处理并发请求？
• 了解 context 在golang中的应用？TODO

参考：

傅小黑的这篇文章框架很清晰
http://fuxiaohei.me/2016/9/20/go-and-http-server.html