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

作者: 我不是隔壁老王我是老王他爹
来源: 51数据库
2021-06-25

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

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

调用http服务

通常的实践如下：

resp, err := http.get("http://www.51sjk.com/Upload/Articles/1/0/248/248334_20210624000158962.jpg")
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协议本身是长连接，它超过一定时间没有数据传送，就会发送心跳来检测该连接是否存活，如果是，该连接继续有效。

补充：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。

以上为个人经验，希望能给大家一个参考，也希望大家多多支持。如有错误或未考虑完全的地方，望不吝赐教。

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

调用http服务

陷阱一： response body没有及时关闭

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

http的长连接与tcp的长连接

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