|
關(guān)于超時(shí)，可以把開發(fā)者分為兩類：一類是了解超時(shí)多么難以捉摸的人，另一類是正在感受超時(shí)如何難以捉摸的人。 超時(shí)既難以捉摸，卻又真實(shí)地存在于我們生活的由網(wǎng)絡(luò)連接的世界中。在我寫這篇文章的同時(shí)，隔壁兩個(gè)同事正在用他們的智能手機(jī)打字，也許是在跟與他們相距萬里的人聊天。網(wǎng)絡(luò)使這一切變?yōu)榭赡堋?/span> 這里要說的是網(wǎng)絡(luò)及其復(fù)雜性，作為寫網(wǎng)絡(luò)服務(wù)的我們，必須掌握如何高效地駕馭它們，并規(guī)避它們的缺陷。 閑話少說，來看看超時(shí)和它們是如何影響我們的 net/http 服務(wù)的。 服務(wù)超時(shí) — 基本原理web 編程中，超時(shí)通常分為客戶端和服務(wù)端超時(shí)兩種。我之所以要研究這個(gè)主題，是因?yàn)槲易约河龅搅艘粋€(gè)有意思的服務(wù)端超時(shí)的問題。這也是本文我們將要重點(diǎn)討論服務(wù)側(cè)超時(shí)的原因。 先解釋下基本術(shù)語：超時(shí)是一個(gè)時(shí)間間隔（或邊界），用來標(biāo)識(shí)在這個(gè)時(shí)間段內(nèi)要完成特定的行為。如果在給定的時(shí)間范圍內(nèi)沒有完成操作，就產(chǎn)生了超時(shí)，這個(gè)操作會(huì)被取消。 從一個(gè) net/http 的服務(wù)的初始化中，能看出一些超時(shí)的基礎(chǔ)配置： srv := &http.Server{ ReadTimeout: 1 * time.Second, WriteTimeout: 1 * time.Second, IdleTimeout: 30 * time.Second, ReadHeaderTimeout: 2 * time.Second, TLSConfig: tlsConfig, Handler: srvMux,}http.Server 類型的服務(wù)可以用四個(gè)不同的 timeout 來初始化：
對(duì)上述超時(shí)的圖表展示：  服務(wù)生命周期和超時(shí) 當(dāng)心！不要以為這些就是你所需要的所有的超時(shí)了。除此之外還有很多超時(shí)，這些超時(shí)提供了更小的粒度控制，對(duì)于我們的持續(xù)運(yùn)行的 HTTP 處理器不會(huì)生效。 請(qǐng)聽我解釋。 timeout 和 deadline如果我們查看 net/http 的源碼，尤其是看到 `conn` 類型[1] 時(shí)，我們會(huì)發(fā)現(xiàn) conn 實(shí)際上使用了 net.Conn 連接，net.Conn 表示底層的網(wǎng)絡(luò)連接： 換句話說，我們的 HTTP 請(qǐng)求實(shí)際上是基于 TCP 連接的。從類型上看，TLS 連接是 *net.TCPConn 或 *tls.Conn 。 serve 函數(shù)[2]處理每一個(gè)請(qǐng)求[3]時(shí)調(diào)用 readRequest 函數(shù)。readRequest 使用我們?cè)O(shè)置的 timeout 值[4]來設(shè)置 TCP 連接的 deadline： // Taken from: https://github.com/golang/go/blob/bbbc658/src/net/http/server.go#L936// Read next request from connection.func (c *conn) readRequest(ctx context.Context) (w *response, err error) { // *Snipped* t0 := time.Now() if d := c.server.readHeaderTimeout(); d != 0 { hdrDeadline = t0.Add(d) } if d := c.server.ReadTimeout; d != 0 { wholeReqDeadline = t0.Add(d) } c.rwc.SetReadDeadline(hdrDeadline) if d := c.server.WriteTimeout; d != 0 { defer func() { c.rwc.SetWriteDeadline(time.Now().Add(d)) }() } // *Snipped*}從上面的摘要中，我們可以知道：我們對(duì)服務(wù)設(shè)置的 timeout 值最終表現(xiàn)為 TCP 連接的 deadline 而不是 HTTP 超時(shí)。 所以，deadline 是什么？工作機(jī)制是什么？如果我們的請(qǐng)求耗時(shí)過長，它們會(huì)取消我們的連接嗎？ 一種簡單地理解 deadline 的思路是，把它理解為對(duì)作用于連接上的特定的行為的發(fā)生限制的一個(gè)時(shí)間點(diǎn)。例如，如果我們?cè)O(shè)置了一個(gè)寫的 deadline，當(dāng)過了這個(gè) deadline 后，所有對(duì)這個(gè)連接的寫操作都會(huì)被拒絕。 盡管我們可以使用 deadline 來模擬超時(shí)操作，但我們還是不能控制處理器完成操作所需的耗時(shí)。deadline 作用于連接，因此我們的服務(wù)僅在處理器嘗試訪問連接的屬性（如對(duì) http.ResponseWriter 進(jìn)行寫操作）之后才會(huì)返回（錯(cuò)誤）結(jié)果。 為了實(shí)際驗(yàn)證上面的論述，我們來創(chuàng)建一個(gè)小的 handler，這個(gè) handler 完成操作所需的耗時(shí)相對(duì)于我們?yōu)榉?wù)設(shè)置的超時(shí)更長： 上面的服務(wù)有一個(gè) handler，這個(gè) handler 完成操作需要兩秒。另一方面，http.Server 的 WriteTimeout 屬性設(shè)為 1 秒?；诜?wù)的這些配置，我們猜測 handler 不能把響應(yīng)寫到連接。 我們可以用 go run server.go 來啟動(dòng)服務(wù)。使用 curl localhost:8888 來發(fā)送一個(gè)請(qǐng)求： $ time curl localhost:8888curl: (52) Empty reply from servercurl localhost:8888 0.01s user 0.01s system 0% CPU 2.021 total這個(gè)請(qǐng)求需要兩秒來完成處理，服務(wù)返回的響應(yīng)是空的。雖然我們的服務(wù)知道在 1 秒之后我們寫不了響應(yīng)了，但 handler 還是多耗了 100% 的時(shí)間（2 秒）來完成處理。 雖然這是個(gè)類似超時(shí)的處理，但它更大的作用是在到達(dá)超時(shí)時(shí)間時(shí)，阻止服務(wù)進(jìn)行更多的操作，結(jié)束請(qǐng)求。在我們上面的例子中，handler 在完成之前一直在處理請(qǐng)求，即使已經(jīng)超出響應(yīng)寫超時(shí)時(shí)間（1 秒）100%（耗時(shí) 2 秒）。 最根本的問題是，對(duì)于處理器來說，我們應(yīng)該怎么設(shè)置超時(shí)時(shí)間才更有效？ 處理超時(shí)我們的目標(biāo)是確保我們的 slowHandler 在 1s 內(nèi)完成處理。如果超過了 1s，我們的服務(wù)會(huì)停止運(yùn)行并返回對(duì)應(yīng)的超時(shí)錯(cuò)誤。 在 Go 和一些其它編程語言中，組合往往是設(shè)計(jì)和開發(fā)中最好的方式。標(biāo)準(zhǔn)庫的 `net/http` 包[5]有很多相互兼容的元素，開發(fā)者可以不需經(jīng)過復(fù)雜的設(shè)計(jì)考慮就可以輕易將它們組合在一起。 基于此，net/http 包提供了`TimeoutHandler`[6] — 返回了一個(gè)在給定的時(shí)間限制內(nèi)運(yùn)行的 handler。 函數(shù)簽名： 第一個(gè)參數(shù)是 Handler，第二個(gè)參數(shù)是 time.Duration （超時(shí)時(shí)間），第三個(gè)參數(shù)是 string 類型，當(dāng)?shù)竭_(dá)超時(shí)時(shí)間后返回的信息。 用 TimeoutHandler 來封裝我們的 slowHandler，我們只需要： package mainimport ( 'fmt' 'io' 'net/http' 'time')func slowHandler(w http.ResponseWriter, req *http.Request) { time.Sleep(2 * time.Second) io.WriteString(w, 'I am slow!\n')}func main() { srv := http.Server{ Addr: ':8888', WriteTimeout: 5 * time.Second, Handler: http.TimeoutHandler(http.HandlerFunc(slowHandler), 1*time.Second, 'Timeout!\n'), } if err := srv.ListenAndServe(); err != nil { fmt.Printf('Server failed: %s\n', err) }}兩個(gè)需要留意的地方是：
如果我們?cè)賳?dòng)服務(wù)，當(dāng)程序運(yùn)行到 slow handler 時(shí)，會(huì)有如下輸出： 1s 后，我們的 TimeoutHandler 開始執(zhí)行，阻止運(yùn)行 slowHandler，返回文本信息 ”Timeout!“。如果我們?cè)O(shè)置信息為空，handler 會(huì)返回默認(rèn)的超時(shí)響應(yīng)信息，如下： <html> <head> <title>Timeout</title> </head> <body> <h1>Timeout</h1> </body></html>如果忽略掉輸出，這還算是整潔，不是嗎？現(xiàn)在我們的程序不會(huì)有過長耗時(shí)的處理；也避免了有人惡意發(fā)送導(dǎo)致長耗時(shí)處理的請(qǐng)求時(shí)，導(dǎo)致的潛在的 DoS 攻擊。 盡管我們?cè)O(shè)置超時(shí)時(shí)間是一個(gè)偉大的開始，但它仍然只是初級(jí)的保護(hù)。如果你可能會(huì)面臨 DoS 攻擊，你應(yīng)該采用更高級(jí)的保護(hù)工具和技術(shù)。（可以試試 Cloudflare[7] ） 我們的 slowHandler 僅僅是個(gè)簡單的 demo。但是，如果我們的程序復(fù)雜些，能向其他服務(wù)和資源發(fā)出請(qǐng)求會(huì)發(fā)生什么呢？如果我們的程序在超時(shí)時(shí)向諸如 S3 的服務(wù)發(fā)出了請(qǐng)求會(huì)怎么樣？ 會(huì)發(fā)生什么？ 未處理的超時(shí)和請(qǐng)求取消我們稍微展開下我們的例子： 我們假設(shè)最初我們不知道 slowHandler 由于通過 slowAPICall 函數(shù)向 API 發(fā)請(qǐng)求導(dǎo)致需要耗費(fèi)這么長時(shí)間才能處理完成， slowAPICall 函數(shù)很簡單：使用 select 和一個(gè)能阻塞 0 到 5 秒的 time.After 。當(dāng)經(jīng)過了阻塞的時(shí)間后，time.After 方法通過它的 channel 發(fā)送一個(gè)值，返回 'foobar' 。 （另一種方法是，使用 sleep(time.Duration(rand.Intn(5)) * time.Second)，但我們?nèi)匀皇褂?select，因?yàn)樗鼤?huì)使我們下面的例子更簡單。） 如果我們運(yùn)行起服務(wù)，我們預(yù)期超時(shí) handler 會(huì)在 1 秒之后中斷請(qǐng)求處理。來發(fā)送一個(gè)請(qǐng)求驗(yàn)證一下： $ time curl localhost:8888Timeout!curl localhost:8888 0.01s user 0.01s system 1% CPU 1.021 total通過觀察服務(wù)的輸出，我們會(huì)發(fā)現(xiàn)，它是在幾秒之后打出日志的，而不是在超時(shí) handler 生效時(shí)打出： 這個(gè)現(xiàn)象表明：雖然 1 秒之后請(qǐng)求超時(shí)了，但是服務(wù)仍然完整地處理了請(qǐng)求。這就是在 4 秒之后才打出日志的原因。 雖然在這個(gè)例子里問題很簡單，但是類似的現(xiàn)象在生產(chǎn)中可能變成一個(gè)嚴(yán)重的問題。例如，當(dāng) slowAPICall 函數(shù)開啟了幾個(gè)百個(gè)協(xié)程，每個(gè)協(xié)程都處理一些數(shù)據(jù)時(shí)。或者當(dāng)它向不同系統(tǒng)發(fā)出多個(gè)不同的 API 發(fā)出請(qǐng)求時(shí)。這種耗時(shí)長的的進(jìn)程，它們的請(qǐng)求方/客戶端并不會(huì)使用服務(wù)端的返回結(jié)果，會(huì)耗盡你系統(tǒng)的資源。 所以，我們?cè)趺幢Ｗo(hù)系統(tǒng)，使之不會(huì)出現(xiàn)類似的未優(yōu)化的超時(shí)或取消請(qǐng)求呢？ 上下文超時(shí)和取消Go 有一個(gè)包名為 `context`[8] 專門處理類似的場景。 context 包在 Go 1.7 版本中提升為標(biāo)準(zhǔn)庫，在之前的版本中，以/x/net/context[9] 的路徑作為 Go Sub-repository Packages[10] 出現(xiàn)。 這個(gè)包定義了 Context 類型。它最初的目的是保存不同 API 和不同處理的截止時(shí)間、取消信號(hào)和其他請(qǐng)求相關(guān)的值。如果你想了解關(guān)于 context 包的其他信息，可以閱讀 Golang's blog[11] 中的 “Go 并發(fā)模式：Context”（譯注：Go Concurrency Patterns: Context） . net/http 包中的的 Request 類型已經(jīng)有 context 與之綁定。從 Go 1.7 開始，Request 新增了一個(gè)返回請(qǐng)求的上下文的 `Context` 方法[12]。對(duì)于進(jìn)來的請(qǐng)求，在客戶端關(guān)閉連接、請(qǐng)求被取消（HTTP/2 中）或 ServeHTTP 方法返回后，服務(wù)端會(huì)取消上下文。 我們期望的現(xiàn)象是，當(dāng)客戶端取消請(qǐng)求（輸入了 CTRL + C）或一段時(shí)間后 TimeoutHandler 繼續(xù)執(zhí)行然后終止請(qǐng)求時(shí)，服務(wù)端會(huì)停止后續(xù)的處理。進(jìn)而關(guān)閉所有的連接，釋放所有被運(yùn)行中的處理進(jìn)程（及它的所有子協(xié)程）占用的資源。 我們把 Context 作為參數(shù)傳給 slowAPICall 函數(shù)： func slowAPICall(ctx context.Context) string { d := rand.Intn(5) select { case <-time.After(time.Duration(d) * time.Second): log.Printf('Slow API call done after %d seconds.\n', d) return 'foobar' }}func slowHandler(w http.ResponseWriter, r *http.Request) { result := slowAPICall(r.Context()) io.WriteString(w, result+'\n')}在例子中我們利用了請(qǐng)求上下文，實(shí)際中怎么用呢？`Context` 類型[13]有個(gè) Done 屬性，類型為 <-chan struct{}。當(dāng)進(jìn)程處理完成時(shí)，Done 關(guān)閉，此時(shí)表示上下文應(yīng)該被取消，而這正是例子中我們需要的。 我們?cè)?slowAPICall 函數(shù)中用 select 處理 ctx.Done 通道。當(dāng)我們通過 Done 通道接收一個(gè)空的 struct 時(shí)，意味著上下文取消，我們需要讓 slowAPICall 函數(shù)返回一個(gè)空字符串。 （這就是使用 select 而不是 time.Sleep -- 這里我們只能用select 處理 Done 通道。） 在這個(gè)簡單的例子中，我們成功得到了結(jié)果 -- 當(dāng)我們從 Done 通道接收值時(shí)，我們打印了一行日志到 STDOUT 并返回了一個(gè)空字符串。在更復(fù)雜的情況下，如發(fā)送真實(shí)的 API 請(qǐng)求，你可能需要關(guān)閉連接或清理文件描述符。 我們?cè)賳?dòng)服務(wù)，發(fā)送一個(gè) cRUL 請(qǐng)求： # The cURL command:$ curl localhost:8888Timeout!# The server output:$ Go run server.go2019/12/30 00:07:15 slowAPICall was supposed to take 2 seconds, but was canceled.檢查輸出：我們發(fā)送了 cRUL 請(qǐng)求到服務(wù)，它耗時(shí)超過 1 秒，服務(wù)取消了 slowAPICall 函數(shù)。我們幾乎不需要寫任何代碼。TimeoutHandler 為我們代勞了 -- 當(dāng)處理耗時(shí)超過預(yù)期時(shí)，TimeoutHandler 終止了處理進(jìn)程并取消請(qǐng)求上下文。 TimeoutHandler 是在 `timeoutHandler.ServeHTTP` 方法[14] 中取消上下文的： 上面例子中，我們通過調(diào)用 context.WithTimeout 來使用請(qǐng)求上下文。超時(shí)值 h.dt （TimeoutHandler 的第二個(gè)參數(shù)）設(shè)置給了上下文。返回的上下文是請(qǐng)求上下文設(shè)置了超時(shí)值后的一份拷貝。隨后，它作為請(qǐng)求上下文傳給 r.WithContext(ctx)。 context.WithTimeout 方法執(zhí)行了上下文取消。它返回了 Context 設(shè)置了一個(gè)超時(shí)值之后的副本。當(dāng)?shù)竭_(dá)超時(shí)時(shí)間后，就取消上下文。 這里是執(zhí)行的代碼： // Taken from: https://github.com/golang/go/blob/bbbc6589/src/context/context.go#L486-L498func WithTimeout(parent Context, timeout time.Duration) (Context, CancelFunc) { return WithDeadline(parent, time.Now().Add(timeout))}// Taken from: https://github.com/golang/go/blob/bbbc6589/src/context/context.go#L418-L450func WithDeadline(parent Context, d time.Time) (Context, CancelFunc) { // *Snipped* c := &timerCtx{ cancelCtx: newCancelCtx(parent), deadline: d, } // *Snipped* if c.err == nil { c.timer = time.AfterFunc(dur, func() { c.cancel(true, DeadlineExceeded) }) } return c, func() { c.cancel(true, Canceled) }}這里我們又看到了截止時(shí)間。WithDeadline 函數(shù)設(shè)置了一個(gè) d 到達(dá)之后執(zhí)行的函數(shù)。當(dāng)?shù)竭_(dá)截止時(shí)間后，它調(diào)用 cancel 方法處理上下文，此方法會(huì)關(guān)閉上下文的 done 通道并設(shè)置上下文的 timer 屬性為nil。 Done 通道的關(guān)閉有效地取消了上下文，使我們的 slowAPICall 函數(shù)終止了它的執(zhí)行。這就是 TimeoutHandler 終止耗時(shí)長的處理進(jìn)程的原理。 （如果你想閱讀上面提到的源碼，你可以去看 `cancelCtx` 類型[15]和 `timerCtx` 類型[16]） 有彈性的 net/http 服務(wù)連接截止時(shí)間提供了低級(jí)的細(xì)粒度控制。雖然它們的名字中含有“超時(shí)”，但它們并沒有表現(xiàn)出人們通常期望的“超時(shí)”。實(shí)際上它們非常強(qiáng)大，但是使用它們有一定的門檻。 另一個(gè)角度講，當(dāng)處理 HTTP 時(shí)，我們?nèi)匀粦?yīng)該考慮使用 TimeoutHandler。Go 的作者們也選擇使用它，它有多種處理，提供了如此有彈性的處理以至于我們甚至可以對(duì)每一個(gè)處理使用不同的超時(shí)。TimeoutHandler 可以根據(jù)我們期望的表現(xiàn)來控制執(zhí)行進(jìn)程。 除此之外，TimeoutHandler 完美兼容 context 包。context 包很簡單，包含了取消信號(hào)和請(qǐng)求相關(guān)的數(shù)據(jù)，我們可以使用這些數(shù)據(jù)來使我們的應(yīng)用更好地處理錯(cuò)綜復(fù)雜的網(wǎng)絡(luò)問題。 結(jié)束之前，有三個(gè)建議。寫 HTTP 服務(wù)時(shí)，怎么設(shè)計(jì)超時(shí)：
更多關(guān)于此主題的文章：
via: https:///post/make-resilient-golang-net-http-servers-using-timeouts-deadlines-context-cancellation/ 作者：Ilija Eftimov[21]譯者：lxbwolf[22]校對(duì)：polaris1119[23] 本文由 GCTT[24] 原創(chuàng)編譯，Go 中文網(wǎng)[25] 榮譽(yù)推出 參考資料[1] conn 類型: [2] 函數(shù): [3] 處理每一個(gè)請(qǐng)求: [4] timeout 值: [5] net/http 包: [6] TimeoutHandler: https:///pkg/net/http/#TimeoutHandler [7] Cloudflare: https://www./ddos/ [8] context: https:///pkg/context/ [9] /x/net/context: https:////x/net/context [10] Go Sub-repository Packages: https:///-/subrepo [11] Golang's blog: https://blog./context [12] Context 方法: [13] Context 類型: [14] timeoutHandler.ServeHTTP 方法: [15] cancelCtx 類型: [16] timerCtx 類型: [17] Cloudflare's blog: https://blog./the-complete-guide-to-golang-net-http-timeouts/ [18] Cloudflare's blog: https://blog./exposing-go-on-the-internet/ [19] Stackoverflow: https:///questions/51258952/use-http-timeouthandler-or-readtimeout-writetimeout [20] Simon Frey's blog: https://blog./go-as-in-golang-standard-net-http-config-will-break-your-production [21] Ilija Eftimov: https:/// [22] lxbwolf: https://github.com/lxbwolf [23] polaris1119: https://github.com/polaris1119 [24] GCTT: https://github.com/studygolang/GCTT [25] Go 中文網(wǎng): https:/// |
|
|
