golang对http进行了很好的封装， 使我们在开发基于http服务的时候， 十分的方便， 但是良好的封装， 很容易是的我们忽略掉它们底层的实现细节。
如下是我踩过的一些坑， 以及相应的解决方法。
调用http服务
通常的实践如下：
|
1
2
3
4
5
6
7
|
resp, err := http.Get("http://example.com/")
if err != nil {
// handle error
}
defer resp.Body.Close()
body, err := ioutil.ReadAll(resp.Body)
// ...
|
陷阱一： Response body没有及时关闭
网络程序运行中， 过了一段时间， 比较常见的问题就是爆出错误：“socket: too many open files”， 这通常是由于打开的文件句柄没有关闭造成的。
在http使用中， 最容易让人忽视的， 就是http返回的response的body必须close,否则就会有内存泄露。
更不容易发现的问题是， 如果response.body的内容没有被读出来， 会造成socket链接泄露， 后续的服务无法使用。
这里， response.body是一个io.ReadCloser类型的接口， 包含了read和close接口。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
type Response struct {
// Body represents the response body.
//
// The response body is streamed on demand as the Body field
// is read. If the network connection fails or the server
// terminates the response, Body.Read calls return an error.
//
// The http Client and Transport guarantee that Body is always
// non-nil, even on responses without a body or responses with
// a zero-length body. It is the caller's responsibility to
// close Body. The default HTTP client's Transport may not
// reuse HTTP/1.x "keep-alive" TCP connections if the Body is
// not read to completion and closed.
//
// The Body is automatically dechunked if the server replied
// with a "chunked" Transfer-Encoding.
Body io.ReadCloser
}
|
如果没有通过ioutil.ReadAll或者其他的接口读取response.body的内容， 此次socket链接就无法被后续的连接复用， 造成的结果就是该连接一直存在。
尽管调用了ioutil.ReadAll就可以避免该连接的泄露， 我们还是建议在获取response后， 就调用Close, 因为在response返回的地方与ReadAll之间， 万一有条件判断造成接口提前返回， 还是会造成泄露的。
|
1
|
defer resp.Body.Close()
|
另外， http.Request是不需要主动关闭的。
陷阱二： 默认的http的transport的设定不合适
在简单的应用下， 采用默认的http client就可以满足需要， 在稍微复杂一点的场景， 有其实想要保持长链接以及提高链接复用的效率等方面的控制， 这个时候就需要对client比较清楚的了解。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
type Client struct {
// Transport specifies the mechanism by which individual
// HTTP requests are made.
// If nil, DefaultTransport is used.
Transport RoundTripper
// Timeout specifies a time limit for requests made by this
// Client. The timeout includes connection time, any
// redirects, and reading the response body. The timer remains
// running after Get, Head, Post, or Do return and will
// interrupt reading of the Response.Body.
//
// A Timeout of zero means no timeout.
//
// The Client cancels requests to the underlying Transport
// as if the Request's Context ended.
//
// For compatibility, the Client will also use the deprecated
// CancelRequest method on Transport if found. New
// RoundTripper implementations should use the Request's Context
// for cancelation instead of implementing CancelRequest.
Timeout time.Duration
}
|
这里， 我们重点关注Transport与Timeout两个字段， Transport记录了本次请求的事务信息， 以及连接复用相关的信息。
Timeout记录此次调用的超时时间以避免异常发生的时候的长时间等待。
通常我们使用的默认的Transport定义如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
|
var DefaultTransport RoundTripper = &Transport{
Proxy: ProxyFromEnvironment,
DialContext: (&net.Dialer{
Timeout: 30 * time.Second,
KeepAlive: 30 * time.Second,
DualStack: true,
}).DialContext,
MaxIdleConns: 100,
IdleConnTimeout: 90 * time.Second,
TLSHandshakeTimeout: 10 * time.Second,
ExpectContinueTimeout: 1 * time.Second,
}
|
默认情况下， 它会保留打开的连接以备未来复用， 如果服务要连接很多的主机， 就会保存很多的空闲连接， IdleConnTimeout用来将超过一定时间的空闲连接回收；实际上， Defaulttransport 的MaxIdleConns是100， 在很多的场景下还是偏小的， 尤其是对于需要管理大的系统并且模块之间交互频繁的情况。
另外， 如果该连接需要定期 访问很多的资源节点， 并列我们知道每个资源节点上面需要的连接数大于2， 那么就会出现很多的短连接， 因为对于每一台资源机， DefaultTransport默认的最大连接数是2， 最大空闲连接是1.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
type Transport struct {
// MaxIdleConnsPerHost, if non-zero, controls the maximum idle
// (keep-alive) connections to keep per-host. If zero,
// DefaultMaxIdleConnsPerHost is used.
MaxIdleConnsPerHost int
// MaxConnsPerHost optionally limits the total number of
// connections per host, including connections in the dialing,
// active, and idle states. On limit violation, dials will block.
//
// Zero means no limit.
//
// For HTTP/2, this currently only controls the number of new
// connections being created at a time, instead of the total
// number. In practice, hosts using HTTP/2 only have about one
// idle connection, though.
MaxConnsPerHost int
}
|
HTTP的长连接与TCP的长连接
在http1.1中， http默认保持长连接， 以备将来复用， 但是这个长连接通常是有时间限制的， 并且向我们上面开到的Transport里面的设定， 空闲的连接数是有最大限制的， 超过了该限制，其余新的连接就变成了短连接。
TCP协议本身是长连接， 它超过一定时间没有数据传送， 就会发送心跳来检测该连接是否存活， 如果是， 该连接继续有效。
补充：golang 设置 http response 响应头的内容与坑
用 golang 写 http server 时，可以很方便可通过 w.Header.Set(k, v) 来设置 http response 中 header 的内容。
例如：w.Header().Set("Access-Control-Allow-Origin", "*") 。
但是需要特别注意的是某些时候不仅要修改 http header ，还要修改 http status code。
修改 http status code 可以通过：w.WriteHeader(code) 来实现，例如：w.WriteHeader(404) 。
如果这两种修改一起做，就必须让 w.WriteHeader 在所有的 w.Header.Set 之后，也就是 w.WriteHeader 后 Set Header 是无效的。
今天就遇到了这个问题，在一段代码中调用 w.Header.Set，怎么折腾都无效，最后才发现其它代码段中先调用了 w.WriteHeader。
以上为个人经验，希望能给大家一个参考，也希望大家多多支持服务器之家。如有错误或未考虑完全的地方，望不吝赐教。
原文链接：https://blog.csdn.net/baijiwei/article/details/84924605