Go net/http 逾時指導

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

當在編寫一個Go語言的HTTP服務端或者是用戶端時，逾時是最容易同時也是最敏感的錯誤，有很多選擇，一個錯誤可以導致很長時間沒有結果，知道網路出現故障，或者進程宕掉。 HTTP是一個複雜的多階段的協議，所以逾時沒有一刀切的解決方案。想想一個流的端點與JSON API端點和comet端點。事實上，預設值往往不是你想要的。 在這篇文章中，我將採取不同的階段，你可能需要申請一個逾時，並在伺服器和用戶端不同的方式來實現。	山野痞夫 翻譯於 7天前 1人頂 頂 翻譯的不錯哦!
	其它翻譯版本(1)

正在載入...

設定期限(逾時) 首先，你需要理解Go提供的最初級的網路逾時實現：Deadlines（期限）。 在Go標準庫net.Conn中實現了Deadlines，通過 set[Read|Write]Deadline(time.Time)方法進行設定。Deadlines是一個絕對時間，一旦到時，將停止所有I/O操作，併產生一個逾時錯誤。（譯註：time.Time的精度是納秒） Deadlines本身是不會逾時的。一旦被設定，將一直生效（直到再一次調SetDeadline），它並不關心在此期間連結是否存在以及如何使用。因此，你需要在每次進行讀/寫操作前，使用SetDeadline設定一個逾時時間長度。 實際開發中，你並不需要直接調用SetDeadline，而是在標準庫net/http中使用更高層次的逾時設定。但需要注意的是，所有基於Deadlines的逾時都會被執行，所以不需要在每次收/發操作前，重設逾時。(譯註：tcp、udp、unix-socket也是如此，參見標準庫net)。 伺服器逾時 對於一個部署在Internet上的HTTP伺服器來說，設定用戶端連結逾時，是至關重要的。否則，一個超慢或已消失的用戶端，可能會泄漏檔案描述符，並最終導致異常。如下所示： http: Accept error: accept tcp [::]:80: accept4: too many open files; retrying in 5ms

caotj72 翻譯於 7天前 1人頂 頂 翻譯的不錯哦!

http.Server有兩個設定逾時的方法: ReadTimeout 和 andWriteTimeout`。你可以顯式地設定它們： srv := &http.Server{      ReadTimeout: 5 * time.Second,    WriteTimeout: 10 * time.Second,}log.Println(srv.ListenAndServe()) ReadTimeout的時間計算是從串連被接受(accept)到request body完全被讀取(如果你不讀取body，那麼時間截止到讀完header為止)。它的內部實現是在Accept立即調用SetReadDeadline方法-代碼。 WriteTimeout的時間計算正常是從request header的讀取結束開始，到 response write結束為止 (也就是 ServeHTTP 方法的聲明周期), 它是通過在readRequest方法結束的時候調用SetWriteDeadline實現的-代碼。 但是，當串連是HTTPS的時候，SetWriteDeadline會在Accept之後立即調用-代碼，所以它的時間計算也包括 TLS握手時的寫的時間。 討厭的是， 這就意味著(也只有這種情況) WriteTimeout設定的時間也包含讀取Headerd到讀取body第一個位元組這段時間。 當你處理不可信的用戶端和網路的時候，你應該同時設定讀寫逾時，這樣用戶端就不會因為讀慢或者寫慢長久的持有這個串連了。 最後，還有一個http.TimeoutHandler方法。 它並不是Server參數，而是一個Handler封裝函數，可以限制ServeHTTP調用。它緩衝response, 如果deadline超過了則發送 504 Gateway Timeout 錯誤。 注意這個功能在1.6 中有問題，在1.6.2中改正了。

sheepbao 翻譯於 7天前 0人頂 頂 翻譯的不錯哦!

其它翻譯版本(1)

正在載入...

http.ListenAndServe的問題 不幸的是, http.ListenAndServe, http.ListenAndServeTLS及http.Serveare等經由http.Server的便利函數不太適合用於對外發布網路服務。 因為這些函數預設關閉了逾時設定，也無法手動設定。使用這些函數，將很快泄露串連，然後耗盡檔案描述符。對於這點，我至少犯了6次以上這樣的錯誤。 對此，你應該使用http.server！在建立http.server執行個體的時候，調用相應的方法指定ReadTimeout（讀取逾時時間）和WriteTimeout（寫逾時時間），在以下會有一些案例。 關於流 比較惱火的是沒法從ServerHttp訪問net.Conn包下的對象，所以一個伺服器想要響應一個流就必須解除WriteTimeout設定(這就是為什麼預設值是0的原因）。因為訪問不到net.Conn包，就無法在每個Write操作之前調用SetWriteDeadline設定一個合理的閑置逾時時間。

imqipan 翻譯於 7天前 0人頂 頂 翻譯的不錯哦!

同理，由於無法確認ResponseWriter.Close支援並發寫操作，所以ResponseWriter.Write可能產生的阻塞，並且是無法被取消的。 （譯者註：Go 1.6.2版本中 ，介面ResponseWriter定義中是沒有Close方法的，需要在介面實現中自行實現。揣測是作者在開發中實現過該方法） 令人遺憾的是，這意味著流媒體伺服器面對一個低速用戶端時，將無法有效保障自身的效率、穩定。 我已經提交了一些建議，並期待有所反饋。 用戶端逾時 用戶端逾時，取決於你的決策，可以很簡單，也可以很複雜。但同樣重要的是：要防止資源泄漏和阻塞。 最簡單的使用逾時的方式是http.Client。它涵蓋整個互動過程，從發起串連到接收響應報文結束。 c := &http.Client{      Timeout: 15 * time.Second,}resp, err := c.Get("https://blog.filippo.io/") 與服務端情況類似，使用http.Get等包級易用函數建立用戶端時，也無法設定逾時。應用在開放網路環境中，存在很大的風險。

caotj72 翻譯於 6天前 0人頂 頂 翻譯的不錯哦!

還有其它一些方法，可以讓你進行更精細的逾時控制： net.Dialer.Timeout 限制建立一個TCP串連使用的時間（如果需要一個新的連結） http.Transport.TLSHandshakeTimeout 限制TLS握手使用的時間 http.Transport.ResponseHeaderTimeout 限制讀取響應報文頭使用的時間 http.Transport.ExpectContinueTimeout 限制用戶端在發送一個包含：100-continue的http報文頭後，等待收到一個go-ahead響應報文所用的時間。在1.6中，此設定對HTTP/2無效。（在1.6.2中提供了一個特定的封裝DefaultTransport） c := &http.Client{      Transport: &Transport{        Dial: (&net.Dialer{                Timeout:   30 * time.Second,                KeepAlive: 30 * time.Second,        }).Dial,        TLSHandshakeTimeout:   10 * time.Second,        ResponseHeaderTimeout: 10 * time.Second,        ExpectContinueTimeout: 1 * time.Second,    }} 據我瞭解，尚沒有限制發送請求使用時間的機制。目前的解決方案是，在用戶端方法返回後，通過time.Timer來個手工控制讀取請求資訊的時間（參見下面的“如何取消請求”）。 最後，在新的1.7版本中，提供了http.Transport.IdleConnTimeout。它用於控制一個閑置串連在串連池中的保留時間，而不考慮一個用戶端請求被阻塞在哪個階段。 注意，用戶端將使用預設的重新導向機制。由於http.Transport是一個底層的系統機制，沒有重新導向概念，因此http.Client.Timeout涵蓋了用於重新導向花費的時間，而更精細的逾時控，可以根據請求的不同，進行定製。

caotj72 翻譯於 6天前 0人頂 頂 翻譯的不錯哦!

Cancel 和 Context net/http提供了兩種用於撤銷用戶端請求的方法：Request.Cancel以及新的1.7版本中提供的Context。 Request.Cancel是一個可選channel。在Request.Timeout被觸發時，Request.Cancel將被設定並關閉，進而促使請求中斷（基本上“撤銷”都採用相同的機制，在寫此文時，我發現一個1.7中的bug，所有的撤銷操作，都會當作一個逾時錯誤返回）。 我們可以使用Request.Cancel和time.Timer，來構建一個逾時更可控的，可用於流媒體的用戶端。它可以在成功獲響應報文體(Body)的部分資料後，重設deadline。 package mainimport (      "io"    "io/ioutil"    "log"    "net/http"    "time")func main() {      c := make(chan struct{})    timer := time.AfterFunc(5*time.Second, func() {        close(c)    })        // Serve 256 bytes every second.    req, err := http.NewRequest("GET", "http://httpbin.org/range/2048?duration=8&chunk_size=256", nil)    if err != nil {        log.Fatal(err)    }    req.Cancel = c    log.Println("Sending request...")    resp, err := http.DefaultClient.Do(req)    if err != nil {        log.Fatal(err)    }    defer resp.Body.Close()    log.Println("Reading body...")    for {        timer.Reset(2 * time.Second)                // Try instead: timer.Reset(50 * time.Millisecond)        _, err = io.CopyN(ioutil.Discard, resp.Body, 256)        if err == io.EOF {            break        } else if err != nil {            log.Fatal(err)        }    }} 在上面這個例子中，我們在要求階段，設定了一個5秒鐘的逾時。但讀取響應報文階段，我們需要讀8次，至少8秒鐘的時間。每次讀操作，設定2秒鐘的逾時。採用這樣的機制，我們可以無限制的擷取流媒體，而不用擔心阻塞的風險。如果我們沒有在2秒鐘內讀取到任何資料，io.CopyN將返回錯誤資訊： net/http: request canceled。 在1.7版本標準庫中的新增了context包。關於Contexts，我們有大量需要學習的東西。基於本文的主旨，你首先應該知道的是：Contexts將替代Request.Cancel，不再建議(反對)使用Request.Cancel。

caotj72 翻譯於 6天前 0人頂 頂 翻譯的不錯哦!

為了使用Contexts來撤銷一個請求，我們需要建立一個新的Context以及它的基於context.WithCancel的cancel()函數，同時還有建立一個基於Request.WithContext的Request。當我們要撤銷一個請求時，我們其實際是通過cancel()函數撤銷相應的Context（取代原有的關閉Cancel channel的方式）： ctx, cancel := context.WithCancel(context.TODO())  timer := time.AfterFunc(5*time.Second, func() {      cancel()})req, err := http.NewRequest("GET", "http://httpbin.org/range/2048?duration=8&chunk_size=256", nil)  if err != nil {      log.Fatal(err)}req = req.WithContext(ctx) 在上下文（我們提供給context.WithCancel的）已經被撤銷的情況下，Contexts更具有優勢。我們可以向整個管道發送命令。 就這些了。希望你對ReadDeadline理解比我更深刻。

caotj72 翻譯於 6天前 0人頂 頂 翻譯的不錯哦!

本文中的所有譯文僅用於學習和交流目的，轉載請務必註明文章譯者、出處、和本文連結
我們的翻譯工作遵照 CC 協議，如果我們的工作有侵犯到您的權益，請及時聯絡我們