golang http使用踩过的坑与填坑指南_Golang

golang对http进行了很好的封装，使我们在开发基于http服务的时候，十分的方便，但是良好的封装，很容易是的我们忽略掉它们底层的实现细节。

如下是我踩过的一些坑，以及相应的解决方法。

调用http服务

通常的实践如下：

				?

									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接口。

				?

									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之间，万一有条件判断造成接口提前返回，还是会造成泄露的。

				?

									defer resp.Body.Close()

另外， http.Request是不需要主动关闭的。

陷阱二：默认的http的transport的设定不合适

在简单的应用下，采用默认的http client就可以满足需要，在稍微复杂一点的场景，有其实想要保持长链接以及提高链接复用的效率等方面的控制，这个时候就需要对client比较清楚的了解。

				?

									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定义如下：

				?

									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.

				?

									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

									}