建站
咨詢
售后
建站咨詢
新聞中心
關(guān)于超時，可以把開發(fā)者分為兩類：一類是了解超時多么難以捉摸的人，另一類是正在感受超時如何難以捉摸的人。
創(chuàng)新互聯(lián)是專業(yè)的香河網(wǎng)站建設(shè)公司，香河接單;提供成都網(wǎng)站設(shè)計、成都網(wǎng)站建設(shè),網(wǎng)頁設(shè)計,網(wǎng)站設(shè)計,建網(wǎng)站,PHP網(wǎng)站建設(shè)等專業(yè)做網(wǎng)站服務(wù);采用PHP框架,可快速的進(jìn)行香河網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴(kuò)展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團(tuán)隊,希望更多企業(yè)前來合作!
超時既難以捉摸，卻又真實地存在于我們生活的由網(wǎng)絡(luò)連接的世界中。在我寫這篇文章的同時，隔壁兩個同事正在用他們的智能手機(jī)打字，也許是在跟與他們相距萬里的人聊天。網(wǎng)絡(luò)使這一切變?yōu)榭赡堋?/p>
這里要說的是網(wǎng)絡(luò)及其復(fù)雜性，作為寫網(wǎng)絡(luò)服務(wù)的我們，必須掌握如何高效地駕馭它們，并規(guī)避它們的缺陷。
閑話少說，來看看超時和它們是如何影響我們的 net/http 服務(wù)的。
服務(wù)超時 — 基本原理
web 編程中，超時通常分為客戶端和服務(wù)端超時兩種。我之所以要研究這個主題，是因為我自己遇到了一個有意思的服務(wù)端超時的問題。這也是本文我們將要重點討論服務(wù)側(cè)超時的原因。
先解釋下基本術(shù)語：超時是一個時間間隔(或邊界)，用來標(biāo)識在這個時間段內(nèi)要完成特定的行為。如果在給定的時間范圍內(nèi)沒有完成操作，就產(chǎn)生了超時，這個操作會被取消。
從一個 net/http 的服務(wù)的初始化中，能看出一些超時的基礎(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ù)可以用四個不同的 timeout 來初始化：
- ReadTimeout：讀取包括請求體的整個請求的最大時長
- WriteTimeout：寫響應(yīng)允許的最大時長
- IdleTimetout：當(dāng)開啟了保持活動狀態(tài)(keep-alive)時允許的最大空閑時間
- ReadHeaderTimeout：允許讀請求頭的最大時長
對上述超時的圖表展示：
服務(wù)生命周期和超時
當(dāng)心!不要以為這些就是你所需要的所有的超時了。除此之外還有很多超時，這些超時提供了更小的粒度控制，對于我們的持續(xù)運(yùn)行的 HTTP 處理器不會生效。
請聽我解釋。
timeout 和 deadline
如果我們查看 net/http 的源碼，尤其是看到 `conn` 類型[1] 時，我們會發(fā)現(xiàn)conn 實際上使用了 net.Conn 連接，net.Conn 表示底層的網(wǎng)絡(luò)連接：
- // Taken from: https://github.com/golang/go/blob/bbbc658/src/net/http/server.go#L247
- // A conn represents the server-side of an HTTP connection.
- type conn struct {
- // server is the server on which the connection arrived.
- // Immutable; never nil.
- server *Server
- // * Snipped *
- // rwc is the underlying network connection.
- // This is never wrapped by other types and is the value given out
- // to CloseNotifier callers. It is usually of type *net.TCPConn or
- // *tls.Conn.
- rwc net.Conn
- // * Snipped *
- }
換句話說，我們的 HTTP 請求實際上是基于 TCP 連接的。從類型上看，TLS 連接是 *net.TCPConn 或 *tls.Conn 。
serve 函數(shù)[2]處理每一個請求[3]時調(diào)用 readRequest 函數(shù)。readRequest使用我們設(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*
- }
從上面的摘要中，我們可以知道：我們對服務(wù)設(shè)置的 timeout 值最終表現(xiàn)為 TCP 連接的 deadline 而不是 HTTP 超時。
所以，deadline 是什么?工作機(jī)制是什么?如果我們的請求耗時過長，它們會取消我們的連接嗎?
一種簡單地理解 deadline 的思路是，把它理解為對作用于連接上的特定的行為的發(fā)生限制的一個時間點。例如，如果我們設(shè)置了一個寫的 deadline，當(dāng)過了這個 deadline 后，所有對這個連接的寫操作都會被拒絕。
盡管我們可以使用 deadline 來模擬超時操作，但我們還是不能控制處理器完成操作所需的耗時。deadline 作用于連接，因此我們的服務(wù)僅在處理器嘗試訪問連接的屬性(如對 http.ResponseWriter 進(jìn)行寫操作)之后才會返回(錯誤)結(jié)果。
為了實際驗證上面的論述，我們來創(chuàng)建一個小的 handler，這個 handler 完成操作所需的耗時相對于我們?yōu)榉?wù)設(shè)置的超時更長：
- package main
- import (
- "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: 1 * time.Second,
- Handler: http.HandlerFunc(slowHandler),
- }
- if err := srv.ListenAndServe(); err != nil {
- fmt.Printf("Server failed: %s\n", err)
- }
- }
上面的服務(wù)有一個 handler，這個 handler 完成操作需要兩秒。另一方面，http.Server 的 WriteTimeout 屬性設(shè)為 1 秒?；诜?wù)的這些配置，我們猜測 handler 不能把響應(yīng)寫到連接。
我們可以用 go run server.go 來啟動服務(wù)。使用 curl localhost:8888 來發(fā)送一個請求：
- $ time curl localhost:8888
- curl: (52) Empty reply from server
- curl localhost:8888 0.01s user 0.01s system 0% CPU 2.021 total
這個請求需要兩秒來完成處理，服務(wù)返回的響應(yīng)是空的。雖然我們的服務(wù)知道在 1 秒之后我們寫不了響應(yīng)了，但 handler 還是多耗了 100% 的時間(2 秒)來完成處理。
雖然這是個類似超時的處理，但它更大的作用是在到達(dá)超時時間時，阻止服務(wù)進(jìn)行更多的操作，結(jié)束請求。在我們上面的例子中，handler 在完成之前一直在處理請求，即使已經(jīng)超出響應(yīng)寫超時時間(1 秒)100%(耗時 2 秒)。
最根本的問題是，對于處理器來說，我們應(yīng)該怎么設(shè)置超時時間才更有效?
處理超時
我們的目標(biāo)是確保我們的 slowHandler 在 1s 內(nèi)完成處理。如果超過了 1s，我們的服務(wù)會停止運(yùn)行并返回對應(yīng)的超時錯誤。
在 Go 和一些其它編程語言中，組合往往是設(shè)計和開發(fā)中最好的方式。標(biāo)準(zhǔn)庫的 `net/http` 包[5]有很多相互兼容的元素，開發(fā)者可以不需經(jīng)過復(fù)雜的設(shè)計考慮就可以輕易將它們組合在一起。
基于此，net/http 包提供了`TimeoutHandler`[6] — 返回了一個在給定的時間限制內(nèi)運(yùn)行的 handler。
函數(shù)簽名：
- func TimeoutHandler(h Handler, dt time.Duration, msg string) Handler
第一個參數(shù)是 Handler，第二個參數(shù)是 time.Duration (超時時間)，第三個參數(shù)是 string 類型，當(dāng)?shù)竭_(dá)超時時間后返回的信息。
用 TimeoutHandler 來封裝我們的 slowHandler，我們只需要：
- package main
- import (
- "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)
- }
- }
兩個需要留意的地方是：
- 我們在 http.TimetoutHandler 里封裝 slowHanlder，超時時間設(shè)為 1s，超時信息為 “Timeout!”。
- 我們把 WriteTimeout 增加到 5s，以給予 http.TimeoutHandler 足夠的時間執(zhí)行。如果我們不這么做，當(dāng) TimeoutHandler 開始執(zhí)行時，已經(jīng)過了 deadline，不能再寫到響應(yīng)。
如果我們再啟動服務(wù)，當(dāng)程序運(yùn)行到 slow handler 時，會有如下輸出：
- $ time curl localhost:8888
- Timeout!
- curl localhost:8888 0.01s user 0.01s system 1% CPU 1.023 total
1s 后，我們的 TimeoutHandler 開始執(zhí)行，阻止運(yùn)行 slowHandler，返回文本信息 ”Timeout!“。如果我們設(shè)置信息為空，handler 會返回默認(rèn)的超時響應(yīng)信息，如下：
Timeout Timeout
如果忽略掉輸出，這還算是整潔，不是嗎?現(xiàn)在我們的程序不會有過長耗時的處理;也避免了有人惡意發(fā)送導(dǎo)致長耗時處理的請求時，導(dǎo)致的潛在的 DoS 攻擊。
盡管我們設(shè)置超時時間是一個偉大的開始，但它仍然只是初級的保護(hù)。如果你可能會面臨 DoS 攻擊，你應(yīng)該采用更高級的保護(hù)工具和技術(shù)。(可以試試Cloudflare[7] )
我們的 slowHandler 僅僅是個簡單的 demo。但是，如果我們的程序復(fù)雜些，能向其他服務(wù)和資源發(fā)出請求會發(fā)生什么呢?如果我們的程序在超時時向諸如 S3 的服務(wù)發(fā)出了請求會怎么樣?
會發(fā)生什么?
未處理的超時和請求取消
我們稍微展開下我們的例子：
- func slowAPICall() string {
- d := rand.Intn(5)
- select {
- case <-time.After(time.Duration(d) * time.Second):
- log.Printf("Slow API call done after %s seconds.\n", d)
- return "foobar"
- }
- }
- func slowHandler(w http.ResponseWriter, r *http.Request) {
- result := slowAPICall()
- io.WriteString(w, result+"\n")
- }
我們假設(shè)最初我們不知道 slowHandler 由于通過 slowAPICall 函數(shù)向 API 發(fā)請求導(dǎo)致需要耗費(fèi)這么長時間才能處理完成，
slowAPICall 函數(shù)很簡單：使用 select 和一個能阻塞 0 到 5 秒的 time.After 。當(dāng)經(jīng)過了阻塞的時間后，time.After 方法通過它的 channel 發(fā)送一個值，返回 "foobar" 。
(另一種方法是，使用 sleep(time.Duration(rand.Intn(5)) * time.Second)，但我們?nèi)匀皇褂?select，因為它會使我們下面的例子更簡單。)
如果我們運(yùn)行起服務(wù)，我們預(yù)期超時 handler 會在 1 秒之后中斷請求處理。來發(fā)送一個請求驗證一下：
- $ time curl localhost:8888
- Timeout!
- curl localhost:8888 0.01s user 0.01s system 1% CPU 1.021 total
通過觀察服務(wù)的輸出，我們會發(fā)現(xiàn)，它是在幾秒之后打出日志的，而不是在超時 handler 生效時打出：
- $ Go run server.go
- 2019/12/29 17:20:03 Slow API call done after 4 seconds.
這個現(xiàn)象表明：雖然 1 秒之后請求超時了，但是服務(wù)仍然完整地處理了請求。這就是在 4 秒之后才打出日志的原因。
雖然在這個例子里問題很簡單，但是類似的現(xiàn)象在生產(chǎn)中可能變成一個嚴(yán)重的問題。例如，當(dāng) slowAPICall 函數(shù)開啟了幾個百個協(xié)程，每個協(xié)程都處理一些數(shù)據(jù)時?；蛘弋?dāng)它向不同系統(tǒng)發(fā)出多個不同的 API 發(fā)出請求時。這種耗時長的的進(jìn)程，它們的請求方/客戶端并不會使用服務(wù)端的返回結(jié)果，會耗盡你系統(tǒng)的資源。
所以，我們怎么保護(hù)系統(tǒng)，使之不會出現(xiàn)類似的未優(yōu)化的超時或取消請求呢?
上下文超時和取消
Go 有一個包名為 `context`[8] 專門處理類似的場景。
context 包在 Go 1.7 版本中提升為標(biāo)準(zhǔn)庫，在之前的版本中，以`golang.org/x/net/context`[9] 的路徑作為 Go Sub-repository Packages[10]出現(xiàn)。
這個包定義了 Context 類型。它最初的目的是保存不同 API 和不同處理的截止時間、取消信號和其他請求相關(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 新增了一個返回請求的上下文的 `Context` 方法[12]。對于進(jìn)來的請求，在客戶端關(guān)閉連接、請求被取消(HTTP/2 中)或 ServeHTTP 方法返回后，服務(wù)端會取消上下文。
我們期望的現(xiàn)象是，當(dāng)客戶端取消請求(輸入了 CTRL + C)或一段時間后TimeoutHandler 繼續(xù)執(zhí)行然后終止請求時，服務(wù)端會停止后續(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")
- }
在例子中我們利用了請求上下文，實際中怎么用呢?`Context` 類型[13]有個 Done 屬性，類型為 <-chan struct{}。當(dāng)進(jìn)程處理完成時，Done 關(guān)閉，此時表示上下文應(yīng)該被取消，而這正是例子中我們需要的。
我們在 slowAPICall 函數(shù)中用 select 處理 ctx.Done 通道。當(dāng)我們通過 Done 通道接收一個空的 struct 時，意味著上下文取消，我們需要讓 slowAPICall 函數(shù)返回一個空字符串。
- func slowAPICall(ctx context.Context) string {
- d := rand.Intn(5)
- select {
- case <-ctx.Done():
- log.Printf("slowAPICall was supposed to take %s seconds, but was canceled.", d)
- return ""
- //time.After() 可能會導(dǎo)致內(nèi)存泄漏
- case <-time.After(time.Duration(d) * time.Second):
- log.Printf("Slow API call done after %d seconds.\n", d)
- return "foobar"
- }
- }
(這就是使用 select 而不是 time.Sleep -- 這里我們只能用 select 處理 Done 通道。)
在這個簡單的例子中，我們成功得到了結(jié)果 -- 當(dāng)我們從 Done 通道接收值時，我們打印了一行日志到 STDOUT 并返回了一個空字符串。在更復(fù)雜的情況下，如發(fā)送真實的 API 請求，你可能需要關(guān)閉連接或清理文件描述符。
我們再啟動服務(wù)，發(fā)送一個 cRUL 請求：
- # The cURL command:
- $ curl localhost:8888
- Timeout!
- # The server output:
- $ Go run server.go
- 2019/12/30 00:07:15 slowAPICall was supposed to take 2 seconds, but was canceled.
檢查輸出：我們發(fā)送了 cRUL 請求到服務(wù)，它耗時超過 1 秒，服務(wù)取消了 slowAPICall 函數(shù)。我們幾乎不需要寫任何代碼。TimeoutHandler 為我們代勞了 -- 當(dāng)處理耗時超過預(yù)期時，TimeoutHandler 終止了處理進(jìn)程并取消請求上下文。
TimeoutHandler 是在 `timeoutHandler.ServeHTTP` 方法[14] 中取消上下文的：
- // Taken from: https://github.com/golang/go/blob/bbbc658/src/net/http/server.go#L3217-L3263
- func (h *timeoutHandler) ServeHTTP(w ResponseWriter, r *Request) {
- ctx := h.testContext
- if ctx == nil {
- var cancelCtx context.CancelFunc
- ctx, cancelCtx = context.WithTimeout(r.Context(), h.dt)
- defer cancelCtx()
- }
- r = r.WithContext(ctx)
- // *Snipped*
- }
上面例子中，我們通過調(diào)用 context.WithTimeout 來使用請求上下文。超時值 h.dt (TimeoutHandler 的第二個參數(shù))設(shè)置給了上下文。返回的上下文是請求上下文設(shè)置了超時值后的一份拷貝。隨后，它作為請求上下文傳給r.WithContext(ctx)。
context.WithTimeout 方法執(zhí)行了上下文取消。它返回了 Context 設(shè)置了一個超時值之后的副本。當(dāng)?shù)竭_(dá)超時時間后，就取消上下文。
這里是執(zhí)行的代碼：
- // Taken from: https://github.com/golang/go/blob/bbbc6589/src/context/context.go#L486-L498
- func 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-L450
- func 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) }
- }
這里我們又看到了截止時間。WithDeadline 函數(shù)設(shè)置了一個 d 到達(dá)之后執(zhí)行的函數(shù)。當(dāng)?shù)竭_(dá)截止時間后，它調(diào)用 cancel 方法處理上下文，此方法會關(guān)閉上下文的 done 通道并設(shè)置上下文的 timer 屬性為 nil。
Done 通道的關(guān)閉有效地取消了上下文，使我們的 slowAPICall 函數(shù)終止了它的執(zhí)行。這就是 TimeoutHandler 終止耗時長的處理進(jìn)程的原理。
(如果你想閱讀上面提到的源碼，你可以去看 `cancelCtx` 類型[15] 和`timerCtx` 類型[16])
有彈性的 net/http 服務(wù)
連接截止時間提供了低級的細(xì)粒度控制。雖然它們的名字中含有“超時”，但它們并沒有表現(xiàn)出人們通常期望的“超時”。實際上它們非常強(qiáng)大，但是使用它們有一定的門檻。
另一個角度講，當(dāng)處理 HTTP 時，我們?nèi)匀粦?yīng)該考慮使用 TimeoutHandler。Go 的作者們也選擇使用它，它有多種處理，提供了如此有彈性的處理以至于我們甚至可以對每一個處理使用不同的超時。TimeoutHandler 可以根據(jù)我們期望的表現(xiàn)來控制執(zhí)行進(jìn)程。
除此之外，TimeoutHandler 完美兼容 context 包。context 包很簡單，包含了取消信號和請求相關(guān)的數(shù)據(jù)，我們可以使用這些數(shù)據(jù)來使我們的應(yīng)用更好地處理錯綜復(fù)雜的網(wǎng)絡(luò)問題。
結(jié)束之前，有三個建議。寫 HTTP 服務(wù)時，怎么設(shè)計超時：
- 最常用的，到達(dá) TimeoutHandler 時，怎么處理。它進(jìn)行我們通常期望的超時處理。
- 不要忘記上下文取消。context 包使用起來很簡單，并且可以節(jié)省你服務(wù)器上的很多處理資源。尤其是在處理異?；蚓W(wǎng)絡(luò)狀況不好時。
- 一定要用截止時間。確保做了完整的測試，驗證了能提供你期望的所有功能。
新聞名稱：實戰(zhàn)：用取消參數(shù)使Gonet/http服務(wù)更靈活
瀏覽路徑：http://m.5511xx.com/article/dpejepo.html
