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協議本身是長連接， 它超過一定時間沒有數據傳送， 就會發送心跳來檢測該連接是否存活， 如果是， 該連接繼續有效。