golang對http進(jìn)行了很好的封裝, 使我們在開發(fā)基于http服務(wù)的時候, 十分的方便, 但是良好的封裝, 很容易是的我們忽略掉它們底層的實現(xiàn)細(xì)節(jié)。
如下是我踩過的一些坑, 以及相應(yīng)的解決方法。
調(diào)用http服務(wù)
通常的實踐如下:
resp, err := http.Get("http://example.com/")
if err != nil {
// handle error
}
defer resp.Body.Close()
body, err := ioutil.ReadAll(resp.Body)
// ...
陷阱一: Response body沒有及時關(guān)閉
網(wǎng)絡(luò)程序運行中, 過了一段時間, 比較常見的問題就是爆出錯誤:“socket: too many open files”, 這通常是由于打開的文件句柄沒有關(guān)閉造成的。
在http使用中, 最容易讓人忽視的, 就是http返回的response的body必須close,否則就會有內(nèi)存泄露。
更不容易發(fā)現(xiàn)的問題是, 如果response.body的內(nèi)容沒有被讀出來, 會造成socket鏈接泄露, 后續(xù)的服務(wù)無法使用。
這里, 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的內(nèi)容, 此次socket鏈接就無法被后續(xù)的連接復(fù)用, 造成的結(jié)果就是該連接一直存在。
盡管調(diào)用了ioutil.ReadAll就可以避免該連接的泄露, 我們還是建議在獲取response后, 就調(diào)用Close, 因為在response返回的地方與ReadAll之間, 萬一有條件判斷造成接口提前返回, 還是會造成泄露的。
另外, http.Request是不需要主動關(guān)閉的。
陷阱二: 默認(rèn)的http的transport的設(shè)定不合適
在簡單的應(yīng)用下, 采用默認(rèn)的http client就可以滿足需要, 在稍微復(fù)雜一點的場景, 有其實想要保持長鏈接以及提高鏈接復(fù)用的效率等方面的控制, 這個時候就需要對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
}
這里, 我們重點關(guān)注Transport與Timeout兩個字段, Transport記錄了本次請求的事務(wù)信息, 以及連接復(fù)用相關(guān)的信息。
Timeout記錄此次調(diào)用的超時時間以避免異常發(fā)生的時候的長時間等待。
通常我們使用的默認(rèn)的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,
}
默認(rèn)情況下, 它會保留打開的連接以備未來復(fù)用, 如果服務(wù)要連接很多的主機(jī), 就會保存很多的空閑連接, IdleConnTimeout用來將超過一定時間的空閑連接回收;實際上, Defaulttransport 的MaxIdleConns是100, 在很多的場景下還是偏小的, 尤其是對于需要管理大的系統(tǒng)并且模塊之間交互頻繁的情況。
另外, 如果該連接需要定期 訪問很多的資源節(jié)點, 并列我們知道每個資源節(jié)點上面需要的連接數(shù)大于2, 那么就會出現(xiàn)很多的短連接, 因為對于每一臺資源機(jī), DefaultTransport默認(rèn)的最大連接數(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
}
HTTP的長連接與TCP的長連接
在http1.1中, http默認(rèn)保持長連接, 以備將來復(fù)用, 但是這個長連接通常是有時間限制的, 并且向我們上面開到的Transport里面的設(shè)定, 空閑的連接數(shù)是有最大限制的, 超過了該限制,其余新的連接就變成了短連接。
TCP協(xié)議本身是長連接, 它超過一定時間沒有數(shù)據(jù)傳送, 就會發(fā)送心跳來檢測該連接是否存活, 如果是, 該連接繼續(xù)有效。
補充:golang 設(shè)置 http response 響應(yīng)頭的內(nèi)容與坑
用 golang 寫 http server 時,可以很方便可通過 w.Header.Set(k, v) 來設(shè)置 http response 中 header 的內(nèi)容。
例如:w.Header().Set("Access-Control-Allow-Origin", "*") 。
但是需要特別注意的是某些時候不僅要修改 http header ,還要修改 http status code。
修改 http status code 可以通過:w.WriteHeader(code) 來實現(xiàn),例如:w.WriteHeader(404) 。
如果這兩種修改一起做,就必須讓 w.WriteHeader 在所有的 w.Header.Set 之后,也就是 w.WriteHeader 后 Set Header 是無效的。
今天就遇到了這個問題,在一段代碼中調(diào)用 w.Header.Set,怎么折騰都無效,最后才發(fā)現(xiàn)其它代碼段中先調(diào)用了 w.WriteHeader。
以上為個人經(jīng)驗,希望能給大家一個參考,也希望大家多多支持腳本之家。如有錯誤或未考慮完全的地方,望不吝賜教。
您可能感興趣的文章:- go 原生http web 服務(wù)跨域restful api的寫法介紹
- Go http client 連接池不復(fù)用的問題
- Golang實現(xiàn)http server提供壓縮文件下載功能
- golang語言http協(xié)議get拼接參數(shù)操作
- 在go文件服務(wù)器加入http.StripPrefix的用途介紹
- Golang 實現(xiàn)分片讀取http超大文件流和并發(fā)控制
- Go 實現(xiàn)HTTP中間人代理的操作