专栏名称: 嵌入式微处理器

关注这个时代最火的嵌入式微处理器，你想知道的都在这里。

go的net/http有哪些值得关注的细节？

嵌入式微处理器 · 公众号 · · 2024-03-26 15:42

正文

golang的 net/http 库是我们平时写代码中，非常常用的标准库。由于go语言拥有goroutine，goroutine的 上下文切换成本 比普通线程低很多，net/http库充分利用了这个优势，因此，它的内部实现跟其他语言会有一些区别。

其中最大的区别在于，其他语言中，一般是多个网络句柄共用一个或多个线程，以此来减少线程之间的切换成本。而golang则会为每个网络句柄 创建两个goroutine ，一个用于读数据，一个用于写数据。

下图是net/http源码中创建这两个goroutine的地方。

了解它的内部实现原理，可以帮助我们写出更高性能的代码，以及避免协程泄露造成的内存泄漏问题。

这篇文章是希望通过几个例子让大家对net/http的内部实现有更直观的理解。

连接与协程数量的关系

首先我们来看一个例子。

func main() {
    tr := &http.Transport{
        MaxIdleConns:    100,
        IdleConnTimeout: 3 * time.Second,
    }

    n := 5
    for i := 0; i         req, _ := http.NewRequest("POST", "https://www.baidu.com", nil)
        req.Header.Add("content-type", "application/json")
        client := &http.Client{
            Transport: tr,
            Timeout:   3 * time.Second,
        }
        resp, _ := client.Do(req)
        _, _ = ioutil.ReadAll(resp.Body)
        _ = resp.Body.Close()
    }
    time.Sleep(time.Second * 5)
    fmt.Printf("goroutine num is %d\n", runtime.NumGoroutine())
}

上面的代码做的事情很简单，执行5次循环http请求，最终通过runtime.NumGoroutine()方法打印当前的goroutine数量。

代码里只有三个地方需要注意：

1. Transport设置了一个3s的空闲连接超时
2. for循环执行了5次http请求
3. 程序退出前执行了5s sleep

答案输出 1 。也就是说当程序退出的时候，当前的goroutine数量为1，毫无疑问它指的是正在运行main方法的goroutine，后面我们都叫它 main goroutine 。

再来看个例子。

func main() {
    tr := &http.Transport{
        MaxIdleConns:    100,
        IdleConnTimeout: 3 * time.Second,
    }

    n := 5
    for i := 0; i         req, _ := http.NewRequest("POST", "https://www.baidu.com", nil)
        req.Header.Add("content-type", "application/json")
        client := &http.Client{
            Transport: tr,
            Timeout:   3 * time.Second,
        }
        resp, _ := client.Do(req)
        _, _ = ioutil.ReadAll(resp.Body)
        _ = resp.Body.Close()
    }
    time.Sleep(time.Second * 1)
    fmt.Printf("goroutine num is %d\n", runtime.NumGoroutine())
}

在原来的基础上，我们程序退出前的睡眠时间， 从5s改成1s ，此时输出 3 。也就是说除了main方法所在的goroutine，还多了两个goroutine，我们大概也能猜到，这就是 文章开头 提到的读goroutine和写goroutine。也就是说程序在退出时，还有一个网络连接没有断开。

这是一个TCP长连接。

网络五层模型中，HTTP处于应用层，它的底层依赖了传输层的TCP协议。

当我们发起http请求时，如果每次都要建立新的TCP协议，那就需要每次都经历三次握手，这会影响性能，因此更好的方式就是在http请求结束后，不立马断开TCP连接，将它放到一个 空闲连接池 中，后续有新的http请求时就复用该连接。

像这种长时间存活，被多个http请求复用的TCP连接，就是所谓的 长连接 。反过来，如果每次HTTP请求结束就将TCP连接进行四次挥手断开，下次有需要执行HTTP调用时就再建立，这样的TCP连接就是所谓的 短连接 。

HTTP1.1之后默认使用长连接。

那为什么这跟5s和1s有关系？

这是因为长连接在空闲连接池也不能一直存放着，如果一直没被使用放着也是浪费资源，因此会有个空闲回收时间，也就是上面代码中的 IdleConnTimeout ，我们设置的是 3s ，当代码在结束前sleep了 5s 后，长连接就已经被释放了，因此输出结果是只剩一个main goroutine。当sleep 1s 时，长连接还在空闲连接池里，因此程序结束时，就还剩3个goroutine（main goroutine+网络读goroutine+网络写goroutine）。

我们可以改下代码下验证这个说法。我们知道，HTTP可以通过 connection 的 header头 来控制这次的HTTP请求是用的长连接还是短连接。 connection:keep-alive 表示http请求结束后，tcp连接保持存活，也就是长连接， connection:close 则是短连接。

req.Header.Add("connection", "close")

就像下面这样。

func main() {
    tr := &http.Transport{
        MaxIdleConns:    100,
        IdleConnTimeout: 3 * time.Second,
    }

    n := 5




    

    for i := 0; i         req, _ := http.NewRequest("POST", "https://www.baidu.com", nil)
        req.Header.Add("content-type", "application/json")
        req.Header.Add("connection", "close")
        client := &http.Client{
            Transport: tr,
            Timeout:   3 * time.Second,
        }
        resp, _ := client.Do(req)
        _, _ = ioutil.ReadAll(resp.Body)
        _ = resp.Body.Close()
    }
    time.Sleep(time.Second * 1)
    fmt.Printf("goroutine num is %d\n", runtime.NumGoroutine())
}

此时，会发现，程序重新输出 1 。完全符合我们预期。

resp.body是否读取对连接复用的影响

func main() {
   n := 5
   for i := 0; i       resp, _ := http.Get("https://www.baidu.com")
      _ = resp.Body.Close()
   }
   fmt.Printf("goroutine num is %d\n", runtime.NumGoroutine())
}

注意这里没有执行 ioutil.ReadAll(resp.Body) 。也就是说http请求 响应的结果并没有被读取 的情况下，net/http库会怎么处理。

上面的代码最终输出 3 ，分别是main goroutine，read goroutine 以及write goroutine。也就是说长连接没有断开，那 长连接是会在下一次http请求中被复用吗？ 先说答案， 不会复用 。

我们可以看代码。 resp.Body.Close() 会执行到 func (es * bodyEOFSignal) Close() error 中，并执行到 es.earlyCloseFn() 中。

earlyCloseFn 的逻辑也非常简单，就是将一个 false 传入到 waitForBodyRead 的channel中。那写入通道后的数据会在另外一个地方被读取，我们来看下读取的地方。

bodyEOF 为false, 也就不需要执行 tryPutIdleConn() 方法。

tryPutIdleConn会将连接放到长连接池中备用）。

最终就是 alive=bodyEOF ，也就是 false ，字面意思就是该连接不再存活。因此该长连接并不会复用，而是会释放。

那为什么output输出为 3 ？这是因为长连接释放需要时间。

我们可以在结束前加一个休眠，比如再执行休眠 1毫秒 。

func main() {
    n := 5
    for i := 0; i         resp, _ := http.Get("https://www.baidu.com")
        _ = resp.Body.Close()
    }
    time.Sleep(time.Millisecond * 1)
    fmt.Printf("goroutine num is %d\n", runtime.NumGoroutine())
}

此时就会输出 1 。说明协程是退出中的， 只是没来得及完全退出 ，休眠1ms后彻底退出了。

如果我们，将在代码中重新加入 ioutil.ReadAll(resp.Body) ，就像下面这样。

func main() {
    n := 5
    for i := 0; i         resp, _ := http.Get("https://www.baidu.com")
        _, _ = ioutil.ReadAll(resp.Body)
        _ = resp.Body.Close()
    }
    fmt.Printf("goroutine num is %d\n", runtime.NumGoroutine())
}

此时，output还是输出 3 ，但这个3跟上面的3不太一样， 休眠5s 后还是输出3。这是因为长连接被推入到连接池了，连接会重新复用。

下面是源码的解释。

body.close()不执行会怎么样

网上都说不执行 body.close() 会协程泄漏（导致内存泄露）， 真的会出现协程泄漏吗 ，如果泄漏，会泄漏多少？

func main() {
    tr := &http.Transport{
        MaxIdleConns:    100,
        IdleConnTimeout: 3 * time.Second,
    }

    n := 5
    for i := 0; i         req, _ := http.NewRequest("POST", "https://www.baidu.com", nil)
        req.Header.Add("content-type", "application/json")
        client := &http.Client{
            Transport: tr,
        }
        resp, _ := client.Do(req)
        _, _ = ioutil.ReadAll(resp.Body)
        //_ = resp.Body.Close()




    

    }
    time.Sleep(time.Second * 1)
    fmt.Printf("goroutine num is %d\n", runtime.NumGoroutine())
}

我们可以运行这段代码，代码中将 resp.body.close() 注释掉，结果输出 3 。debug源码，会发现连接其实复用了。代码执行到 tryPutIdleConn 函数中，会将连接归还到空闲连接池中。

休眠5s ，结果输出 1 ，这说明达到 idleConnTimeout ，空闲连接断开。看起来一切正常。

将 resp.Body.Close() 那一行代码重新加回来，也就是下面这样，会发现代码结果依然输出 3 。 我们是否删除这行代码，对结果没有任何影响。

func main() {
    tr := &http.Transport{
        MaxIdleConns:    100,
        IdleConnTimeout: 3 * time.Second,
    }

    n := 5
    for i := 0; i         req, _ := http.NewRequest("POST", "https://www.baidu.com", nil)
        req.Header.Add("content-type", "application/json")
        client := &http.Client{
            Transport: tr,
        }
        resp, _ := client.Do(req)
        _, _ = ioutil.ReadAll(resp.Body)
        _ = resp.Body.Close()
    }
    time.Sleep(time.Second * 1)
    fmt.Printf("goroutine num is %d\n", runtime.NumGoroutine())
}

既然执不执行body.close()都没啥区别，那body.close()的作用是什么呢？

它是为了标记当前连接请求中， response.body 是否使用完毕，如果不执行 body.close() ，则 resp.Body 中的数据是可以不断重复读且不报错的（但不一定能读到数据），执行了 body.close() ，再次去 读取resp.Body则会报错 ，如果resp.body数据读一半，处理代码逻辑就报错了，此时你不希望其他地方继续去读，那就需要使用body.close()去关闭它。这更像是一种 规范约束 ，它可以更好的保证数据正确。

也就是说 不执行body.close()，并不一定会内存泄露 。那么 什么情况下会协程泄露呢？

直接说答案，既不执行 ioutil.ReadAll(resp.Body) 也不执行 resp.Body.Close() ，并且不设置 http.Client 内 timeout 的时候，就 会导致协程泄露 。

比如下面这样。

func main() {
    tr := &http.Transport{
        MaxIdleConns:    100,
        IdleConnTimeout: 3 * time.Second,
    }

    n := 5
    for i := 0; i         req, _ := http.NewRequest("POST", "https://www.baidu.com", nil)
        req.Header.Add("content-type", "application/json")
        client := &http.Client{
            Transport: tr,
        }
        resp, _ := client.Do(req)
        _ = resp
    }
    time.Sleep(time.Second * 5)
    fmt.Printf("goroutine num is %d\n", runtime.NumGoroutine())
}

最终结果会输出 11 ，也就是1个main goroutine + （1个read goroutine + 1个read goroutine）* 5次http请求。

前面提到， 不执行ioutil.ReadAll(resp.Body)，网络连接无法归还到连接池 。 不执行resp.Body.Close()，网络连接就无法为标记为关闭 ，也就无法正常断开。因此能导致协程泄露，非常好理解。

但http.Client内timeout有什么关系？这是因为timeout是指，从发起请求到从resp.body中读完响应数据的总时间，如果超过了，网络库会自动断开网络连接，并释放read+write goroutine。 因此如果设置了timeout，则不会出现协程泄露的问题。

另外值得一提的是，我看到有不少代码都是直接用下面的方式去做网络请求的。

resp, _ := http.Get("https://www.baidu.com")

这种方式用的是 DefaultClient ，是没有设置超时的，生产环境中使用不当，很容易出现问题。

func Get(url string) (resp *Response, err error) {
    return DefaultClient.Get(url)
}

var DefaultClient = &Client{}

连接池的结构

我们了解到连接池可以复用网络连接，接下来我们通过一个例子来看看网络连接池的结构。


func main() {
    tr := &http.Transport{
        MaxIdleConns:    100,
        IdleConnTimeout: 3 * time.Second,
    }

    n := 5
    for i := 0; i         req, _ := http.NewRequest("POST", "http://www.baidu.com", nil)
        req.Header.Add("content-type", "application/json")
        client := &http.Client{
            Transport: tr,
            Timeout:   3 * time.Second,
        }
        resp, _ := client.Do(req)
        _, _ = ioutil.ReadAll(resp.Body)
        _ = resp.Body.Close()
    }
    time.Sleep(time.Second * 1)
    fmt.Printf("goroutine num is %d\n", runtime.NumGoroutine())
}

注意这里请求的不是 https ，而是 http 。最终结果输出 5 ，为什么？

这是因为， http://www.baidu.com 会返回307，重定向到 https://www.baidu.com 。

在网络中，我们可以通过一个五元组来唯一确定一个TCP连接。

它们分别是源ip，源端口，协议，目的ip，目的端口。只有当多次请求的五元组一样的情况下，才有可能复用连接。

放在我们这个场景下，源ip、源端口、协议都是确定的，也就是两次http请求的目的ip或目的端口有区别的时候，就需要使用不同的TCP长连接。

而http用的是 80端口 ，https用的是 443端口 。于是连接池就为不同的网络目的地建立不同的长连接。

因此最终结果5个goroutine，其实2个goroutine来自http,2个goroutine来自https，1个main goroutine。

我们来看下源码的具体实现。net/http底层通过一个叫 idleConn 的 map 去存空闲连接，也就是空闲连接池。

idleConn 这个 map的key 是协议和地址，其实本质上就是ip和端口。 map的value 是长连接的数组（ []*persistConn ），说明net/http支持为同一个地址建立多个TCP连接，这样可以提升传输的吞吐。

Transport是什么？

Transport本质上是一个用来控制http调用行为的一个组件，里面包含超时控制，连接池等，其中最重要的是连接池相关的配置。

我们通过下面的例子感受下。

func main() {
    n := 5
    for i := 0; i         httpClient := &http.Client{}
        resp, _ := httpClient.Get("https://www.baidu.com")
        _, _ = ioutil.ReadAll(resp.Body)
        _ = resp.Body.Close()
    }
    time.Sleep(time.Second * 1)
    fmt.Printf("goroutine num is %d\n", runtime.NumGoroutine())
}

func main() {
    n := 5
    for i := 0; i         httpClient := &http.Client{
            Transport:  &http.Transport{},
        }
        resp, _ := httpClient.Get("https://www.baidu.com")
        _, _ = ioutil.ReadAll(resp.Body)
        _ = resp.Body.Close()
    }
    time.Sleep(time.Second * 1)
    fmt.Printf("goroutine num is %d\n", runtime.NumGoroutine())
}

上面的代码第一个例子的代码会输出 3 。分别是main goroutine + read goroutine + write goroutine，也就是有一个被不断复用的TCP连接。

在第二例子中，当我们在每次client中都创建一个新的 http.Transport ，此时就会输出 11 。

说明TCP连接没有复用，每次请求都会产生新的连接。这是因为 每个http.Transport内都会维护一个自己的空闲连接池 ，如果每个client都创建一个新的http.Transport，就会导致 底层的TCP连接无法复用 。如果网络请求过大，上面这种情况会导致 协程数量变得非常多 ，导致服务不稳定。

因此，最佳实践是 所有client都共用一个transport 。

func main() {
    tr := &http.Transport{
        MaxIdleConns:    100,
        IdleConnTimeout: 3 * time.Second,
    }

    n := 5
    for i := 0; i         req, _ := http.NewRequest("POST", "https://www.baidu.com", nil)
        req.Header.Add("content-type", "application/json")
        client := &http.Client{
            Transport: tr,
            Timeout:   3 * time.Second,
        }
        resp, _ := client.Do(req)
        _, _ = ioutil.ReadAll(resp.Body)
        _ = resp.Body.Close()
    }
    time.Sleep(time.Second * 1)
    fmt.Printf("goroutine num is %d\n", runtime.NumGoroutine())
}

如果创建客户端的时候不指定 http.Client ，会默认所有http.Client都共用同一个 DefaultTransport 。这一点可以从源码里看出。

因此当第二段代码中，每次都重新创建一个Transport的时候，每个Transport内都会各自维护一个空闲连接池。因此每次建立长连接后都会多两个协程（读+写），对应1个main goroutine+（read goroutine + write goroutine）* 5 =11。

别设置 Transport.Dail里的SetDeadline

http.Transport.Dial的配置里有个SetDeadline，它表示连接建立后发送接收数据的超时时间。听起来跟 client.Timeout 很像。