問題背景
在go語言的http服務中，我們常常會使用到Context來取消一個請求，或者取消資料的讀取，偶然的一次嘗試，讓我對Context有了一定的興趣，接下來本文圍繞下面的例子，分析http如何利用Context來控制請求的取消和影響資料讀取，
例子
我們開啟一個http服務，發送大量資料給每個請求，代碼如下：
srv.go：http服務
package main
import (
"fmt"
"net/http"
)
func hello(w http.ResponseWriter, r *http.Request) {
for i := 0; i < 100*10000; i++ {
w.Write([]byte("hello world"))
}
}
func main() {
fmt.Println("listening 8888:")
http.HandleFunc("/hello", hello)
_ = http.ListenAndServe(":8888", nil)
}
client.go: 發送請求的客戶端
package main
import (
"context"
"fmt"
"io"
"log"
"net/http"
"time"
)
func main() {
client := http.Client{}
request, err := http.NewRequest(http.MethodPost, "http://127.0.0.1:8888/hello", nil)
ctx, cancelFunc := context.WithCancel(request.Context())
request = request.WithContext(ctx)
if err != nil {
return
}
response, err := client.Do(request)
if err != nil {
log.Fatal(err)
}
cache := make([]byte, 128)
timer := time.NewTimer(time.Millisecond)
go func() {
select {
case <-timer.C:
cancelFunc()
}
}()
for {
read, err := response.Body.Read(cache)
if err == nil {
fmt.Println(string(cache[:read]))
continue
}
if err == io.EOF {
fmt.Println(string(cache[:read]))
break
}
log.Fatal(err)
}
}
代碼很簡單，就不做注釋啦，分別啟動服務和client，我們將得到如下結果：
我們看到這句話Process finished with the exit code 1，程式非正常退出，那么首先是追蹤這個錯誤，下面我們追蹤這個錯誤，
錯誤追蹤
首先清楚這個“context canceled” 是客戶端列印出來的：
log.Fatal(err)
// 這個錯誤來源于讀取Response中的資料時得到錯誤，而且這個錯誤非io.EOF錯誤
斷點入口：
read, err := response.Body.Read(cache)
我們會進入transport.go檔案中：
func (es *bodyEOFSignal) Read(p []byte) (n int, err error) { // 這里表明我們讀取的body是bodyEOFSignal型別
es.mu.Lock()
closed, rerr := es.closed, es.rerr
es.mu.Unlock()
if closed {
return 0, errReadOnClosedResBody
}
if rerr != nil {
return 0, rerr
}
n, err = es.body.Read(p)// 我們在這里讀到了錯誤，這里是什么錯誤，在后面將會介紹
if err != nil {
es.mu.Lock()
defer es.mu.Unlock()
if es.rerr == nil {
es.rerr = err
}
err = es.condfn(err) // 通過這個方法對錯誤進行判別，得到上層傳下來的錯誤資訊
}
return
}
然后我們繼續進入到bodyEOFSignal的condfn(error)函式中：
func (es *bodyEOFSignal) condfn(err error) error {
if es.fn == nil {
return err //1
}
err = es.fn(err) // 如果fn不為空，這里會繼續到bodyEOFSignal去得到上層的錯誤資訊；fn為空，顯然錯誤和上層就沒有關系，就在上面1處就回傳了，除此，因為client從這個body讀的資料，這里的錯誤是通過fn從上層獲取，
es.fn = nil
return err
}
那我們繼續到es.fn(err)中一探究竟：
body := &bodyEOFSignal{
body: resp.Body,
earlyCloseFn: func() error {
waitForBodyRead <- false
<-eofc // will be closed by deferred call at the end of the function
return nil
},
fn: func(err error) error {// 就到了這里，這一段代碼源自transport.go中的封裝內部類persistConn的方法readLoop，顧名思義：回圈讀取
// 這里會簡單的皮判斷錯誤是不是io.EOF,然后作進一步處理
isEOF := err == io.EOF
waitForBodyRead <- isEOF
if isEOF {
<-eofc // see comment above eofc declaration
} else if err != nil {
if cerr := pc.canceled(); cerr != nil {// 繼續除錯我們就到了這里，顯然不是io.EOF錯誤
return cerr // 回傳的是pc.canceled()
}
}
return err
},
}
繼續到pc.canceled()中：
func (pc *persistConn) canceled() error {
pc.mu.Lock()
defer pc.mu.Unlock()
return pc.canceledErr // 回傳的這個錯誤，那么下一步便需要知道這個canceledErr是什么？如何被賦值？
}
1. 是什么？
canceledErr error // set non-nil if conn is canceled
//是一種錯誤，且如果非空，則連接被取消，那么這個錯誤是一個連接狀態的標志或者連接斷開的原因
2. 如何被賦值？
根據canceledErr，我們找被賦值的函式如下：
func (pc *persistConn) cancelRequest(err error) {
pc.mu.Lock()
defer pc.mu.Unlock()
pc.canceledErr = err // 在這里被賦值
pc.closeLocked(errRequestCanceled)
}
錯誤追蹤先到這里，接下來我們換一個角度，我們從Context的角度來看，
Context
這里就不講context了，有興趣的伙伴去官網獲取吧！！！回到客戶端代碼，給request傳入了一個WithCancel context，看看這個函式做了什么：
func WithCancel(parent Context) (ctx Context, cancel CancelFunc) {
if parent == nil {
panic("cannot create context from nil parent")
}
c := newCancelCtx(parent) // 包裝父類Context
propagateCancel(parent, &c)
return &c, func() {
c.cancel(true, Canceled) // 回傳一個取消函式
}
}
進入到c.cancel(),會發現Canceled作為一個錯誤型別，定義如下：
// Canceled is the error returned by Context.Err when the context is canceled.
var Canceled = errors.New("context canceled")// 這個不是客戶端列印的嗎？是不是很激動，找到了錯誤資訊的祖宗
...
//而cancel函式定義如下：
// cancel closes c.done, cancels each of c's children, and, if
// removeFromParent is true, removes c from its parent's children.
func (c *cancelCtx) cancel(removeFromParent bool, err error) {
...
c.err = err //這里做了一個賦值，即把這個錯誤傳給cancelCtx了，它是Context的一個內部類
...
// 做一些子context的通知以及錯誤的傳遞，說取消了，不用干了
}
context先到這里，在context里找到了錯誤資訊的來源，接下來看看錯誤是如何傳給前面我們談到的canceledErr，
似憾訓有一個入口沒有看，就是http.client.Do的方法:
我們打斷點進入到RoundTrip方法的呼叫入口，看看下面是如何感知context被取消：
resp, err = rt.RoundTrip(req) //這個在send()方法內部呼叫
...
// send issues an HTTP request.
// Caller should close resp.Body when done reading from it.
func send(ireq *Request, rt RoundTripper, deadline time.Time) (resp *Response, didTimeout func() bool, err error) {
...
resp, err = rt.RoundTrip(req)
...
}
然后跟著RoundTrip(…)， 進入到：
func (t *Transport) roundTrip(req *Request) (*Response, error) {
...
var resp *Response
if pconn.alt != nil {
// HTTP/2 path.
t.setReqCanceler(cancelKey, nil) // not cancelable with CancelRequest
resp, err = pconn.alt.RoundTrip(req)
} else {
resp, err = pconn.roundTrip(treq) // 繼續可到這里，我們看看這個pconn,剛好就是前面提到的persistConn，它里面包含了canceledErr，似乎我們離真相更近了
}
}
進入到persistConn的實作方法roundTrip（），我們看看這個for回圈：
var respHeaderTimer <-chan time.Time
cancelChan := req.Request.Cancel
ctxDoneChan := req.Context().Done() //這個request是setRequestCancel(req *Request, rt RoundTripper, deadline time.Time)中重新定義的request，里實作了超時取消的機制,這里的監聽便是超時的監聽，并不是我們取消的監聽
pcClosed := pc.closech
canceled := false
for {
testHookWaitResLoop()
select { // select開啟對channel的輪詢
case err := <-writeErrCh:
if debugRoundTrip {
req.logf("writeErrCh resv: %T/%#v", err, err)
}
if err != nil {
pc.close(fmt.Errorf("write error: %v", err))
return nil, pc.mapRoundTripError(req, startBytesWritten, err)
}
if d := pc.t.ResponseHeaderTimeout; d > 0 {
if debugRoundTrip {
req.logf("starting timer for %v", d)
}
timer := time.NewTimer(d)
defer timer.Stop() // prevent leaks
respHeaderTimer = timer.C
}
case <-pcClosed:
pcClosed = nil
if canceled || pc.t.replaceReqCanceler(req.cancelKey, nil) {
if debugRoundTrip {
req.logf("closech recv: %T %#v", pc.closed, pc.closed)
}
return nil, pc.mapRoundTripError(req, startBytesWritten, pc.closed)
}
case <-respHeaderTimer:
if debugRoundTrip {
req.logf("timeout waiting for response headers.")
}
pc.close(errTimeout)
return nil, errTimeout
case re := <-resc:
if (re.res == nil) == (re.err == nil) {
panic(fmt.Sprintf("internal error: exactly one of res or err should be set; nil=%v", re.res == nil))
}
if debugRoundTrip {
req.logf("resc recv: %p, %T/%#v", re.res, re.err, re.err)
}
if re.err != nil {
return nil, pc.mapRoundTripError(req, startBytesWritten, re.err)
}
return re.res, nil
case <-cancelChan:
canceled = pc.t.cancelRequest(req.cancelKey, errRequestCanceled)
cancelChan = nil
case <-ctxDoneChan:
canceled = pc.t.cancelRequest(req.cancelKey, req.Context().Err())
cancelChan = nil
ctxDoneChan = nil
}
}
因而這里的監聽不是在客戶端取消的context的監聽，根據客戶端的輸出顯示，表明請求已經發送到服務端，請求并未超時，response也回傳了，那么這里的函式監聽是與我們讀取資料沒有聯系，小編最開始也以為是在這里監聽回傳，然而這里打斷點，怎么進不來，在前面提到，連接是型別為persistConn，其次是讀取資料程序中，context的取消會產生影響，那么表明錯誤發生在tcp連接中的讀取資料，接下來，根據連接建立程序，看看http做了什么？其次是真正的資料讀取來自哪里？
pconn, err := t.getConn(treq, cm)
...
func (t *Transport) getConn(treq *transportRequest, cm connectMethod) (pc *persistConn, err error) {
req := treq.Request
trace := treq.trace
ctx := req.Context() //這里去了request的context
w := &wantConn{
cm: cm,
key: cm.key(),
ctx: ctx, //傳給w
ready: make(chan struct{}, 1),
beforeDial: testHookPrePendingDial,
afterDial: testHookPostPendingDial,
}
...
select{
case <-w.ready:
if w.err != nil {
// If the request has been canceled, that's probably
// what caused w.err; if so, prefer to return the
// cancellation error (see golang.org/issue/16049).
//如果建立連接前，請求被取消，這里會監聽到取消的err
select {
case <-req.Cancel:
return nil, errRequestCanceledConn
case <-req.Context().Done():
return nil, req.Context().Err()
case err := <-cancelc:
if err == errRequestCanceled {
err = errRequestCanceledConn
}
return nil, err
default:
// return below
}
}
return w.pc, w.err//這里回傳的是persistConn
...
通過這個w建立連接，進入到dialConn(ctx context.Context, cm connectMethod) (pconn *persistConn, err error)， 在這里面開啟了一個協程pconn.readLoop()，讀取連接里面的資料，
(t *Transport) dialConn(ctx context.Context, cm connectMethod) (pconn *persistConn, err error) {
...
go pconn.readLoop()
}
因為錯誤與資料讀取有直接聯系，至少錯誤發生readloop中的某一個地方：
for alive {
...
var resp *Response
if err == nil {
resp, err = pc.readResponse(rc, trace) // 得到response
} else {
err = transportReadFromServerError{err}
closeErr = err
}
...
waitForBodyRead := make(chan bool, 2)
body := &bodyEOFSignal{ //對上面讀取的resp.Body進行封裝，這里封裝主要是傳遞請求取消的錯誤
body: resp.Body,
earlyCloseFn: func() error {
waitForBodyRead <- false
<-eofc // will be closed by deferred call at the end of the function
return nil
},
fn: func(err error) error {//
isEOF := err == io.EOF
waitForBodyRead <- isEOF
if isEOF {
<-eofc // see comment above eofc declaration
} else if err != nil {
if cerr := pc.canceled(); cerr != nil {
return cerr
}
}
return err
},
}
resp.Body = body
...
// Before looping back to the top of this function and peeking on
// the bufio.Reader, wait for the caller goroutine to finish
// reading the response body. (or for cancellation or death)
// 這里有開啟監聽，顯然是監聽讀的程序中發生的取消和超時等
select {
case bodyEOF := <-waitForBodyRead:
replaced := pc.t.replaceReqCanceler(rc.cancelKey, nil) // before pc might return to idle pool
alive = alive &&
bodyEOF &&
!pc.sawEOF &&
pc.wroteRequest() &&
replaced && tryPutIdleConn(trace)
if bodyEOF {
eofc <- struct{}{}
}
case <-rc.req.Cancel:
alive = false
pc.t.CancelRequest(rc.req)
case <-rc.req.Context().Done(): //這里便監聽了客戶頓context的取消
alive = false //結束回圈
pc.t.cancelRequest(rc.cancelKey, rc.req.Context().Err())//傳遞err
case <-pc.closech:
alive = false
}
testHookReadLoopBeforeNextRead()
}
熟悉context的便知道，當我們呼叫context的cancel方法時，在前面的context的cancel()方法中有如下代碼：
d, _ := c.done.Load().(chan struct{}) // 拿到Done方法的回傳值channel
if d == nil {
c.done.Store(closedchan)
} else {
close(d)// 關閉channel，而關閉時會向channel寫入值
}
再回到：
ccase <-rc.req.Context().Done():// 當contex取消，便進入這個代碼塊
alive = false
pc.t.cancelRequest(rc.cancelKey, rc.req.Context().Err())
進入到cancelRequest(…)的rc.req.Context().Err()
func (c *cancelCtx) Err() error {
c.mu.Lock()
err := c.err//這里似曾相識，前面我們說到context呼叫取消函式時，會給c.err賦值為cancelErr
c.mu.Unlock()
return err
}
因而傳入cancelRequest的err便是cancelErr，我們進入cancelRequest：
func (t *Transport) cancelRequest(key cancelKey, err error) bool {
// This function must not return until the cancel func has completed.
// See: https://golang.org/issue/34658
t.reqMu.Lock()
defer t.reqMu.Unlock()
cancel := t.reqCanceler[key]// 這里的key正是我們傳入的請求的cancelkey,拿到reqCanceler中的func(error)
delete(t.reqCanceler, key)
if cancel != nil {
cancel(err) // 進入cancel
}
return cancel != nil
}
進入cancel（err）:
func (pc *persistConn) cancelRequest(err error) {//這個函式不正是我們前面追蹤錯誤所看見的，這也表明我們追蹤是正確的
pc.mu.Lock()
defer pc.mu.Unlock()
pc.canceledErr = err
pc.closeLocked(errRequestCanceled)
}
到這里我們的err就傳給了body bodyEOFSignal，整個錯誤傳遞流程便走通了，
還剩最后一個問題，bodyEOFSignal的read函式中n, err = es.body.Read§ 所遇到的錯誤是什么？
n, err = es.body.Read(p)// 除錯發現是網路連接關閉錯誤，這里表明我們執行完err的傳遞根本原因在于連接被關閉
if err != nil {
es.mu.Lock()
defer es.mu.Unlock()
if es.rerr == nil {
es.rerr = err
}
err = es.condfn(err)
}
return
那么關閉連接又是在哪里呢？
我們回到cancelRequest函式：
pc.closeLocked(errRequestCanceled) //這里便關閉了連接
這樣err整個傳遞邏輯和原因便都走同通了！
總結
經過上面的分析，將整個Context取消程序總結如下：
- 當創建一個帶有取消的Context，會把Context的內部類中的err變數賦值為CancelErr；
- 客戶端的呼叫cancelFunc，會向context的Done所系結的channel寫入值；
- 當channel寫入值后，transport.go中的readLoop方法會監聽這個channel的寫入，從而把context取消的err傳給persistConn，并關閉連接；
- 關閉連接后，資料讀取便會遇到連接關閉的網路錯誤錯誤，當遇到這個錯誤，在bodySignal中進行錯誤處理，這里并不感知連接的關閉，只利用fn分別錯誤型別，當錯誤為io.EOF，直接將這個錯誤置為nil，若不是，便通過bodySignal獲取到連接中的錯誤，再回傳這個錯誤；
- 最后通過body.read()方法將錯誤列印出來，
- 這里復雜在于，每個角色只做自己的作業，遇到錯誤不是直接回傳，而是等待其他角色來讀取錯誤；具體表現為：context負責生成錯誤訊息、傳遞取消指令給persistConn；persistConn基于bodySignal建立讀取資料和連接的關聯，回應Context的取消并關閉連接，拿到context的錯誤資訊；client讀取資料和錯誤；bodySignal：分析錯誤，并傳遞資料和persistConn的錯誤訊息給client，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/317867.html
標籤：其他
上一篇：位元組面試真題：如何設計出一個能抗住很大并發量的系統
下一篇：實作一個網頁直播功能超級簡單(EasyRTMP.apk + nginx-http-flv + vue + flv.js) 不使用 Flash