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

简介: go的net/http有哪些值得关注的细节?

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

func main() {
   n := 5
   for i := 0; i < n; 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 < n; 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 < n; 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 < n; 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 < n; 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.Clienttimeout的时候,就会导致协程泄露

比如下面这样。

func main() {
    tr := &http.Transport{
        MaxIdleConns:    100,
        IdleConnTimeout: 3 * time.Second,
    }
    n := 5
    for i := 0; i < n; 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{}
目录
相关文章
|
4月前
|
JSON 安全 前端开发
类型安全的 Go HTTP 请求
类型安全的 Go HTTP 请求
|
1月前
|
网络协议 安全 Go
Go语言进行网络编程可以通过**使用TCP/IP协议栈、并发模型、HTTP协议等**方式
【10月更文挑战第28天】Go语言进行网络编程可以通过**使用TCP/IP协议栈、并发模型、HTTP协议等**方式
51 13
|
2月前
|
API
使用`System.Net.WebClient`类发送HTTP请求来调用阿里云短信API
使用`System.Net.WebClient`类发送HTTP请求来调用阿里云短信API
39 0
|
4月前
|
数据采集 缓存 IDE
Go中遇到http code 206和302的获取数据的解决方案
文章提供了解决Go语言中处理HTTP状态码206(部分内容)和302(重定向)的方案,包括如何获取部分数据和真实请求地址的方法,以便程序员能快速完成工作,享受七夕时光。
212 0
Go中遇到http code 206和302的获取数据的解决方案
|
4月前
|
数据采集 API 开发者
.NET 8新特性:使用ConfigurePrimaryHttpMessageHandler定制HTTP请求
在.NET 8中,通过`ConfigurePrimaryHttpMessageHandler`方法,开发者能更精细地控制HTTP请求,这对于构建高效爬虫尤为重要。此特性支持定制代理IP、管理Cookie与User-Agent,结合多线程技术,有效应对网络限制及提高数据采集效率。示例代码展示了如何设置代理服务器、模拟用户行为及并发请求,从而在遵守网站规则的同时,实现快速稳定的数据抓取。
.NET 8新特性:使用ConfigurePrimaryHttpMessageHandler定制HTTP请求
|
4月前
|
数据采集 开发框架 .NET
HttpClient在ASP.NET Core中的最佳实践:实现高效的HTTP请求
在现代Web开发中,高效可靠的HTTP请求对应用性能至关重要。ASP.NET Core提供的`HttpClient`是进行这类请求的强大工具。本文探讨其最佳实践,包括全局复用`HttpClient`实例以避免性能问题,通过依赖注入配置预设头部信息;使用代理IP以防IP被限制;设置合理的`User-Agent`和`Cookie`来模拟真实用户行为,提高请求成功率。通过这些策略,可显著增强爬虫或应用的稳定性和效率。
114 0
HttpClient在ASP.NET Core中的最佳实践:实现高效的HTTP请求
|
4月前
|
JSON 测试技术 Go
Go Kit中读取原始HTTP请求体的方法
Go Kit中读取原始HTTP请求体的方法
|
4月前
|
网络协议 Go
go的net/http有哪些值得关注的细节?
go的net/http有哪些值得关注的细节?
|
Web App开发 前端开发 关系型数据库
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html><head><meta http-equiv="Cont
fuser可用于查询文件、目录、socket端口和文件系统的使用进程 1.查询文件和目录使用者 fuser最基本的用法是查询某个文件或目录被哪个进程使用: # fuser -v .
884 0
|
Web App开发 前端开发 Android开发
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html><head><meta http-equiv="Cont
使用MAT分析内存泄露 对于大型服务端应用程序来说,有些内存泄露问题很难在测试阶段发现,此时就需要分析JVM Heap Dump文件来找出问题。
788 0