[golang]為什麼Response Body需要被關閉

一桶冷水發表於2017-12-20
Golang
Body io.ReadCloser

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 does not attempt to 
reuse HTTP/1.0 or HTTP/1.1 TCP connections ("keep-alive") unless the Body is read to 
completion and is closed.

http客戶端(Client)和傳輸(Transport)保證響應體總是非空的，即使響應沒有響應體或0長響應
體。關閉響應體是呼叫者的責任。預設http客戶端傳輸(Transport)不會嘗試複用keep-alive的
http/1.0、http/1.1連線，除非請求體已被完全讀出而且被關閉了。
複製程式碼

以上是http包文件說明。但是為什麼body需要被關閉呢，不關閉會如何？那就讀原始碼唄。

要了解body，首先要了解http事務是如何處理的。http事務是交由底層的Transport處理的。

第一步是從連線池獲取一個連線，這個連線的功能由3個goroutine協同實現，一個主goroutine，一個readLoop，一個writeLoop，後兩個goroutine生命週期和連線一致。雖說readLoop和writeLoop名字叫迴圈（也確實是for迴圈），但實際上一次迴圈就完整處理一個http事務，迴圈本身僅僅是為了連線複用，所以為了便於理解其邏輯可以忽略它的迴圈結構。

接下來三個goroutine協同完成http事務：

  1. 主goroutine將request同時發給readLoop和writeLoop。
  2. writeLoop傳送request，然後將狀態（error）傳送給主goroutine和readLoop。
  3. readLoop解析頭部response，然後將狀態（error）和response傳送給主goroutine。
  4. 主goroutine返回使用者程式碼，readLoop等待body讀取完成。
  5. readLoop回收連線。

瞭解http事務的處理流程，然後我們回過頭來看看神祕的body到底是什麼

//原始碼版本1.8.3
// src/net/http/transfer.go:405 body解析方法
func readTransfer(msg interface{}, r *bufio.Reader) (err error)

// src/net/http/transfer.go:485 解析chunked
t.Body = &body{src: internal.NewChunkedReader(r), hdr: msg, r: r, closing: t.Close}

// src/net/http/transfer.go:490 產生eof
t.Body = &body{src: io.LimitReader(r, realLength), closing: t.Close}

// src/net/http/transport.go:1560 傳送eof訊號
body := &bodyEOFSignal{

// src/net/http/transport.go:1583 gzip解碼
resp.Body = &gzipReader{body: body}
複製程式碼

body實際上是一個巢狀了多層的net.TCPConn：

  1. bufio.Reader，這層嘗試將多次小的讀操作替換為一次大的讀操作，減少系統呼叫的次數，提高效能；
  2. io.LimitedReader，tcp連線在讀取完body後不會關閉，繼續讀會導致阻塞，所以需要LimitedReader在body讀完後發出eof終止讀取；
  3. chunkedReader，解析chunked格式編碼（如果不是chunked略過）；
  4. bodyEOFSignal，在讀到eof，或者是提前關閉body時會對readLoop發出回收連線的通知；
  5. gzipReader，解析gzip壓縮（如果不是gizp壓縮略過）；

從上面可以看出如果body既沒有被完全讀取，也沒有被關閉，那麼這次http事務就沒有完成，除非連線因超時終止了，否則相關資源無法被回收。

如果請求頭或響應頭指明Connection: close呢？還是無法回收，因為close表示在http事務完成後斷開連線，而事務尚未完成自然不會斷開，更不會回收。

從實現上看只要body被讀完，連線就能被回收，只有需要拋棄body時才需要close，似乎不關閉也可以。但那些正常情況能讀完的body，即第一種情況，在出現錯誤時就不會被讀完，即轉為第二種情況。而分情況處理則增加了維護者的心智負擔，所以始終close body是最佳選擇。

相關文章