golang http使用踩过的坑与应对方式
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 }
HTTP的长连接与TCP的长连接
在http1.1中, http默认保持长连接, 以备将来复用, 但是这个长连接通常是有时间限制的, 并且向我们上面开到的Transport里面的设定, 空闲的连接数是有最大限制的, 超过了该限制,其余新的连接就变成了短连接。
TCP协议本身是长连接, 它超过一定时间没有数据传送, 就会发送心跳来检测该连接是否存活, 如果是, 该连接继续有效。
总结
以上为个人经验,希望能给大家一个参考,也希望大家多多支持脚本之家。
最新评论