golang http使用踩過的坑與填坑指南

更新時間：2021年04月27日 14:17:09 作者：baijiwei

這篇文章主要介紹了golang http使用踩過的坑與填坑指南，具有很好的參考價值，希望對大家有所幫助。一起跟隨小編過來看看吧

golang對http進行了很好的封裝，使我們在開發(fā)基于http服務的時候，十分的方便，但是良好的封裝，很容易是的我們忽略掉它們底層的實現(xiàn)細節(jié)。

如下是我踩過的一些坑，以及相應的解決方法。

調用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沒有及時關閉

網(wǎng)絡程序運行中，過了一段時間，比較常見的問題就是爆出錯誤：“socket: too many open files”，這通常是由于打開的文件句柄沒有關閉造成的。

在http使用中，最容易讓人忽視的，就是http返回的response的body必須close,否則就會有內存泄露。

更不容易發(fā)現(xiàn)的問題是，如果response.body的內容沒有被讀出來，會造成socket鏈接泄露，后續(xù)的服務無法使用。

這里， 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鏈接就無法被后續(xù)的連接復用，造成的結果就是該連接一直存在。

盡管調用了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記錄此次調用的超時時間以避免異常發(fā)生的時候的長時間等待。

通常我們使用的默認的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，在很多的場景下還是偏小的，尤其是對于需要管理大的系統(tǒng)并且模塊之間交互頻繁的情況。

另外，如果該連接需要定期訪問很多的資源節(jié)點，并列我們知道每個資源節(jié)點上面需要的連接數(shù)大于2，那么就會出現(xiàn)很多的短連接，因為對于每一臺資源機， DefaultTransport默認的最大連接數(shù)是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
}