golang http使用踩過的坑與應(yīng)對(duì)方式
golang對(duì)http進(jìn)行了很好的封裝, 使我們?cè)陂_發(fā)基于http服務(wù)的時(shí)候, 十分的方便, 但是良好的封裝, 很容易是的我們忽略掉它們底層的實(shí)現(xiàn)細(xì)節(jié)。
如下是我踩過的一些坑, 以及相應(yīng)的解決方法。
調(diào)用http服務(wù)
通常的實(shí)踐如下:
resp, err := http.Get("http://example.com/") if err != nil { // handle error } defer resp.Body.Close() body, err := ioutil.ReadAll(resp.Body) // ...
陷阱一: Response body沒有及時(shí)關(guān)閉
網(wǎng)絡(luò)程序運(yùn)行中, 過了一段時(shí)間, 比較常見的問題就是爆出錯(cuò)誤:“socket: too many open files”, 這通常是由于打開的文件句柄沒有關(guān)閉造成的。
在http使用中, 最容易讓人忽視的, 就是http返回的response的body必須close,否則就會(huì)有內(nèi)存泄露。
更不容易發(fā)現(xiàn)的問題是, 如果response.body的內(nèi)容沒有被讀出來, 會(huì)造成socket鏈接泄露, 后續(xù)的服務(wù)無法使用。
這里, response.body是一個(gè)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, 因?yàn)樵趓esponse返回的地方與ReadAll之間, 萬一有條件判斷造成接口提前返回, 還是會(huì)造成泄露的。
defer resp.Body.Close()
另外, http.Request是不需要主動(dòng)關(guān)閉的。
陷阱二: 默認(rèn)的http的transport的設(shè)定不合適
在簡單的應(yīng)用下, 采用默認(rèn)的http client就可以滿足需要, 在稍微復(fù)雜一點(diǎn)的場景, 有其實(shí)想要保持長鏈接以及提高鏈接復(fù)用的效率等方面的控制, 這個(gè)時(shí)候就需要對(duì)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 }
這里, 我們重點(diǎn)關(guān)注Transport與Timeout兩個(gè)字段, Transport記錄了本次請(qǐng)求的事務(wù)信息, 以及連接復(fù)用相關(guān)的信息。
Timeout記錄此次調(diào)用的超時(shí)時(shí)間以避免異常發(fā)生的時(shí)候的長時(shí)間等待。
通常我們使用的默認(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)情況下, 它會(huì)保留打開的連接以備未來復(fù)用, 如果服務(wù)要連接很多的主機(jī), 就會(huì)保存很多的空閑連接, IdleConnTimeout用來將超過一定時(shí)間的空閑連接回收;
實(shí)際上, Defaulttransport 的MaxIdleConns是100, 在很多的場景下還是偏小的, 尤其是對(duì)于需要管理大的系統(tǒng)并且模塊之間交互頻繁的情況。
另外, 如果該連接需要定期 訪問很多的資源節(jié)點(diǎn), 并列我們知道每個(gè)資源節(jié)點(diǎn)上面需要的連接數(shù)大于2, 那么就會(huì)出現(xiàn)很多的短連接, 因?yàn)閷?duì)于每一臺(tái)資源機(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ù)用, 但是這個(gè)長連接通常是有時(shí)間限制的, 并且向我們上面開到的Transport里面的設(shè)定, 空閑的連接數(shù)是有最大限制的, 超過了該限制,其余新的連接就變成了短連接。
TCP協(xié)議本身是長連接, 它超過一定時(shí)間沒有數(shù)據(jù)傳送, 就會(huì)發(fā)送心跳來檢測該連接是否存活, 如果是, 該連接繼續(xù)有效。
總結(jié)
以上為個(gè)人經(jīng)驗(yàn),希望能給大家一個(gè)參考,也希望大家多多支持腳本之家。
相關(guān)文章
在Golang中正確的修改HTTPRequest的Host的操作方法
我們工作中經(jīng)常需要通過HTTP請(qǐng)求Server的服務(wù),比如腳本批量請(qǐng)求接口跑數(shù)據(jù),由于一些網(wǎng)關(guān)策略,部分Server會(huì)要求請(qǐng)求中Header里面附帶Host參數(shù),所以本文給大家介紹了如何在Golang中正確的修改HTTPRequest的Host,需要的朋友可以參考下2023-12-12jenkins構(gòu)建go及java項(xiàng)目的方法
這篇文章主要介紹了jenkins構(gòu)建go及java項(xiàng)目,本文通過圖文實(shí)例相結(jié)合給大家介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值了,需要的朋友可以參考下2021-04-04Go?iota關(guān)鍵字與枚舉類型實(shí)現(xiàn)原理
這篇文章主要介紹了Go?iota關(guān)鍵字與枚舉類型實(shí)現(xiàn)原理,iota是go語言的常量計(jì)數(shù)器,只能在常量的表達(dá)式中使用,更多相關(guān)內(nèi)容需要的小伙伴可以參考一下2022-07-07Go語言中的匿名結(jié)構(gòu)體用法實(shí)例
這篇文章主要介紹了Go語言中的匿名結(jié)構(gòu)體用法,實(shí)例分析了匿名結(jié)構(gòu)體的使用技巧,具有一定參考借鑒價(jià)值,需要的朋友可以參考下2015-02-02