Golang Go语言中 http.Get 的耗时比 curl 耗时大很多是什么原因？

发布于 1周前 作者 vueper 来自 Go语言

Golang Go语言中 http.Get 的耗时比 curl 耗时大很多是什么原因？

可能这个问题比较小白，大家轻喷。

我用 Golang 中http库的Get函数写个简单的下载网页的工具，发现下载网页时间很长，比 curl 长很多：

截图

Golang 代码：


// Fetch prints the content found at a URL.
package main

import (
“time”
“fmt”
“io”
“net/http”
“os”
“strings”
)


func main() {


for _, url := range os.Args[1:] {
	start := time.Now()
	if !(strings.HasPrefix(url, "https://") || strings.HasPrefix(url, "http://")) {
		url = "http://" + url
	}

	resp, err := http.Get(url)
	if err != nil {
		fmt.Fprintf(os.Stderr, "fetch: %v\n", err)
		os.Exit(1)
	}
	fmt.Printf("[\033[0;31m%d\033[0m] %v\n", resp.StatusCode, resp.Request.URL)

	// Test download cost.
	//fmt.Println("Download cost:", time.Since(start))

	if _, err := io.Copy(os.Stdout, resp.Body); err != nil {
		fmt.Fprintf(os.Stderr, "\033[0;31mERROR\033[0m %v\n", err)
		os.Exit(1)
	}
	fmt.Println("Total cost:", time.Since(start))
}

}

看到这么大的差距，我以为是io.Copy可能出了点问题，就在io.Copy前添了一个时间测试，结果：

Download cost: 21.651425s
Total cost: 21.656501s

可以看到时间主要是花在http.Get这里了。

我多次测试后都可以复现（包含测试不同网站），Google 也没有什么结果，搜索关键词都不知道怎么设置。。

这究竟是啥原因啊？


更多关于Golang Go语言中 http.Get 的耗时比 curl 耗时大很多是什么原因？的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html

Harmonyos Next教程
26 回复

帮你试了下，我这儿无法复现。
go version go1.11.2

更多关于Golang Go语言中 http.Get 的耗时比 curl 耗时大很多是什么原因？的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html


可以抓包看是建立连接之前的处理太长还是数据传输的花费时间长，我这里测试没问题。

<br>➜ testing-ground go run httpget.go <a target="_blank" href="http://httpbin.org/get" rel="nofollow noopener">http://httpbin.org/get</a><br>Get cost:496.770582ms<br>[200] <a target="_blank" href="http://httpbin.org/get" rel="nofollow noopener">http://httpbin.org/get</a><br>{<br> "args": {}, <br> "headers": {<br> "Accept-Encoding": "gzip", <br> "Connection": "close", <br> "Host": "<a target="_blank" href="http://httpbin.org" rel="nofollow noopener">httpbin.org</a>", <br> "User-Agent": "Go-http-client/1.1"<br> }, <br> "origin": "124.79.234.173", <br> "url": "<a target="_blank" href="http://httpbin.org/get" rel="nofollow noopener">http://httpbin.org/get</a>"<br>}<br>Total cost: 497.479966ms<br>

啊谢谢！我还能复现。我感觉肯定不是 golang 的原因，想不通哪出问题了。连个测试的方向我都想不出来(总不能是学校路由器针对 golang 的 user-agent 吧)。
补充一下：
我的版本是 go version go1.11 linux/amd64
curl 测试的那行代码是
start=$(date +’%s’) && curl httpbin.org/get && echo “It took $(($(date +’%s’) - $start)) seconds”

strace 和抓包看看

用 httptrace 包看一下在哪里耗时了 https://godoc.org/net/http/httptrace#WithClientTrace


curl 好像只获取连接的第一个界面的文本。
你的保存网页是不是，图片、CSS JS 之类的也下载下来了？

没复现，go 1.11 Total cost: 501.175936ms
用 http.Client 自己包装一个测试下看那个步骤耗时比较多。

可能和 resolver 有关

或者不想手写 httptrace 的话，试一下 github.com/davecheney/httpstat，这个是用 net/http 加 net/http/httptrace 做的工具，可以详细展示各个阶段的耗时。

➜ httpstat http://httpbin.org/get

Connected to 52.86.186.182:80

HTTP/1.1 200 OK
Server: gunicorn/19.9.0
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
Content-Length: 231
Content-Type: application/json
Date: Wed, 05 Dec 2018 09:49:00 GMT
Via: 1.1 vegur
Connection: keep-alive

Body discarded

DNS Lookup TCP Connection Server Processing Content Transfer
[ 612ms | 375ms | 237ms | 0ms ]
| | | |
namelookup:612ms | | |
connect:988ms | |
starttransfer:1225ms |
total:1225ms




谢谢！我测试一下，看看是哪里的问题







又用 提到的工具httpstat测试了下，发现时间主要花在 DNS Lookup 阶段：
https://s1.ax1x.com/2018/12/05/FlsTEj.png
可以看到 windows 下执行就是正常时间, wsl 下执行时间 DNS Lookup 阶段就花了很多时间。我分别用 Get-NetIPConfiguration 和 cat /etc/resolv.conf 看了下，wsl 和 windows 的 DNS 服务器都是 223.5.5.5 223.6.6.6
用的是同一个 DNS。

还是没有解决问题，同在 wsl 下，curl 和 go 的 http.Get 差别还是很大，理论上它俩是一个 DNS 服务器啊。
https://imgchr.com/i/FlsIbQ

忘记说环境了，我是 windows10，出现差异的是 wsl(Linux 4.4.0-17134-Microsoft )环境，在 windows 下 powershell 里是没问题的。

可能是 dns cache 的问题，看下 net 下的文档 https://godoc.org/net#hdr-Name_Resolution
类 unix 系统默认是纯 go 的实现走 dns 协议 Lookup，windows 默认是走系统调用，可能有 cache 加速。
你在 wsl 下加上 export GODEBUG=netdns=cgo 强制走系统查询试试

The method for resolving domain names, whether indirectly with functions like Dial or directly with functions like LookupHost and LookupAddr, varies by operating system.

On Unix systems, the resolver has two options for resolving names. It can use a pure Go resolver that sends DNS requests directly to the servers listed in /etc/resolv.conf, or it can use a cgo-based resolver that calls C library routines such as getaddrinfo and getnameinfo.

By default the pure Go resolver is used, because a blocked DNS request consumes only a goroutine, while a blocked C call consumes an operating system thread. When cgo is available, the cgo-based resolver is used instead under a variety of conditions: on systems that do not let programs make direct DNS requests (OS X), when the LOCALDOMAIN environment variable is present (even if empty), when the RES_OPTIONS or HOSTALIASES environment variable is non-empty, when the ASR_CONFIG environment variable is non-empty (OpenBSD only), when /etc/resolv.conf or /etc/nsswitch.conf specify the use of features that the Go resolver does not implement, and when the name being looked up ends in .local or is an mDNS name.

The resolver decision can be overridden by setting the netdns value of the GODEBUG environment variable (see package runtime) to go or cgo, as in:

export GODEBUG=netdns=go # force pure Go resolver
export GODEBUG=netdns=cgo # force cgo resolver
The decision can also be forced while building the Go source tree by setting the netgo or netcgo build tag.

A numeric netdns setting, as in GODEBUG=netdns=1, causes the resolver to print debugging information about its decisions. To force a particular resolver while also printing debugging information, join the two settings by a plus sign, as in GODEBUG=netdns=go+1.

On Plan 9, the resolver always accesses /net/cs and /net/dns.

On Windows, the resolver always uses C library functions, such as GetAddrInfo and DnsQuery.

在 wsl 里分别执行了 3 条命令，截取了部分结果：

$dig .6.6.6
> ;; Query time: 287 msec

$ ./httpstat
> Connected to 34.196.224.14:80
> namelookup:15450ms

$ curl -v
> * Connected to httpbin.org (52.3.53.115) port 80 (#0)
> It took 1 seconds


仿佛有些头绪了。。。。

感谢！完全解决！
export GODEBUG=netdns=cgo
> namelookup:154ms
export GODEBUG=netdns=go
> namelookup:15484ms
看来 curl 和 go 区别应该就在这。 在#8 已经提到了，刚看我还没搞懂，现在才明白 说的是啥。

#13 又给我普及知识了^_^

长知识了，我要收藏起来

#13 学习了

涨姿势了。这才是论坛的意义呀


厉害了，，膜拜

涨知识

大概猜到 dns 解析的问题，不过细节却是不知道，涨知识了

歪个楼，查看程序运行时间用 time 命令就好了，不需要取开始时间结束时间相减

，谢谢，又发现了一个新命令。我试了一下，/usr/bin/time -p更适合我这个情况。

又开了个帖子解释了下为啥 go dns 查询这么慢
https://www.v2ex.com/t/515096#reply1

在比较 Golang 中 http.Get 和 curl 的请求耗时时，如果发现 http.Get 明显更慢，可能的原因包括以下几个方面：

  1. DNS 解析时间：http.Get 默认使用 Go 的 DNS 解析器，而 curl 可能使用系统级的 DNS 解析器，后者有时因为缓存等原因会更快。可以通过在 http.Client 中设置自定义的 Transport，并配置 DialContext 使用快速 DNS 解析来优化。

  2. TCP 连接建立：http.Get 可能是首次请求，需要完整的 TCP 三次握手过程，而 curl 可能已经建立了持久连接（Keep-Alive）。确保 http.Client 的 Transport 启用了 KeepAlivesEnabled。

  3. HTTP/2 vs HTTP/1.1：默认情况下，curl 可能使用 HTTP/1.1，而 http.Client 在 Go 1.6 及以后默认启用了 HTTP/2。HTTP/2 的开销可能因服务器实现而异，有时可能导致初始连接较慢。

  4. 客户端和服务器的交互：服务器可能对 curl 和 Go 客户端有不同的处理逻辑，比如连接复用、请求处理优先级等。

  5. 代码和环境差异：检查是否有其他代码逻辑（如日志记录、错误处理等）影响了 http.Get 的性能。此外，运行环境（如操作系统、网络配置）也可能导致差异。

优化 http.Get 的性能通常涉及调整 http.Client 的配置，确保 DNS 解析、TCP 连接复用等高效运行。

回到顶部