深入分析Golang Server源碼實(shí)現(xiàn)過(guò)程
func (srv *Server) Serve(l net.Listener) error { ...... for { rw, err := l.Accept() if err != nil { select { case <-srv.getDoneChan(): return ErrServerClosed default: } if ne, ok := err.(net.Error); ok && ne.Temporary() { if tempDelay == 0 { tempDelay = 5 * time.Millisecond } else { tempDelay *= 2 } if max := 1 * time.Second; tempDelay > max { tempDelay = max } srv.logf("http: Accept error: %v; retrying in %v", err, tempDelay) time.Sleep(tempDelay) continue } return err } connCtx := ctx if cc := srv.ConnContext; cc != nil { connCtx = cc(connCtx, rw) if connCtx == nil { panic("ConnContext returned nil") } } tempDelay = 0 c := srv.newConn(rw) c.setState(c.rwc, StateNew, runHooks) // before Serve can return go c.serve(connCtx) } }
func (c *conn) serve(ctx context.Context) { ...... // HTTP/1.x from here on. ctx, cancelCtx := context.WithCancel(ctx) c.cancelCtx = cancelCtx defer cancelCtx() c.r = &connReader{conn: c} c.bufr = newBufioReader(c.r) c.bufw = newBufioWriterSize(checkConnErrorWriter{c}, 4<<10) for { w, err := c.readRequest(ctx) if c.r.remain != c.server.initialReadLimitSize() { // If we read any bytes off the wire, we're active. c.setState(c.rwc, StateActive, runHooks) } if err != nil { const errorHeaders = "\r\nContent-Type: text/plain; charset=utf-8\r\nConnection: close\r\n\r\n" switch { case err == errTooLarge: // Their HTTP client may or may not be // able to read this if we're // responding to them and hanging up // while they're still writing their // request. Undefined behavior. const publicErr = "431 Request Header Fields Too Large" fmt.Fprintf(c.rwc, "HTTP/1.1 "+publicErr+errorHeaders+publicErr) c.closeWriteAndWait() return case isUnsupportedTEError(err): // Respond as per RFC 7230 Section 3.3.1 which says, // A server that receives a request message with a // transfer coding it does not understand SHOULD // respond with 501 (Unimplemented). code := StatusNotImplemented // We purposefully aren't echoing back the transfer-encoding's value, // so as to mitigate the risk of cross side scripting by an attacker. fmt.Fprintf(c.rwc, "HTTP/1.1 %d %s%sUnsupported transfer encoding", code, StatusText(code), errorHeaders) return case isCommonNetReadError(err): return // don't reply default: if v, ok := err.(statusError); ok { fmt.Fprintf(c.rwc, "HTTP/1.1 %d %s: %s%s%d %s: %s", v.code, StatusText(v.code), v.text, errorHeaders, v.code, StatusText(v.code), v.text) return } publicErr := "400 Bad Request" fmt.Fprintf(c.rwc, "HTTP/1.1 "+publicErr+errorHeaders+publicErr) return } } // Expect 100 Continue support req := w.req if req.expectsContinue() { if req.ProtoAtLeast(1, 1) && req.ContentLength != 0 { // Wrap the Body reader with one that replies on the connection req.Body = &expectContinueReader{readCloser: req.Body, resp: w} w.canWriteContinue.setTrue() } } else if req.Header.get("Expect") != "" { w.sendExpectationFailed() return } c.curReq.Store(w) if requestBodyRemains(req.Body) { registerOnHitEOF(req.Body, w.conn.r.startBackgroundRead) } else { w.conn.r.startBackgroundRead() } // HTTP cannot have multiple simultaneous active requests.[*] // Until the server replies to this request, it can't read another, // so we might as well run the handler in this goroutine. // [*] Not strictly true: HTTP pipelining. We could let them all process // in parallel even if their responses need to be serialized. // But we're not going to implement HTTP pipelining because it // was never deployed in the wild and the answer is HTTP/2. inFlightResponse = w serverHandler{c.server}.ServeHTTP(w, w.req) inFlightResponse = nil w.cancelCtx() if c.hijacked() { return } w.finishRequest() if !w.shouldReuseConnection() { if w.requestBodyLimitHit || w.closedRequestBodyEarly() { c.closeWriteAndWait() } return } c.setState(c.rwc, StateIdle, runHooks) c.curReq.Store((*response)(nil)) if !w.conn.server.doKeepAlives() { // We're in shutdown mode. We might've replied // to the user without "Connection: close" and // they might think they can send another // request, but such is life with HTTP/1.1. return } if d := c.server.idleTimeout(); d != 0 { c.rwc.SetReadDeadline(time.Now().Add(d)) if _, err := c.bufr.Peek(4); err != nil { return } } c.rwc.SetReadDeadline(time.Time{}) } }
1、c.readRequest(ctx)
放在 for 循環(huán)里面,是為了 HTTP Keep-Alive,可以復(fù)用TCP連接,并且是串行的,上一個(gè)請(qǐng)求處理完才會(huì)去讀取下一個(gè)請(qǐng)求的數(shù)據(jù),如果連接被客戶端斷開(kāi),那么c.readRequest(ctx)
會(huì)因?yàn)樽x取報(bào)錯(cuò)而退出。
通過(guò)繼續(xù)追蹤源碼,發(fā)現(xiàn)這里只是讀取了 Header,并做一些判斷,因此會(huì)有readHeaderDeadline
這樣的配置,然后設(shè)置Body的類型,Header和Body之間有一個(gè)空行,這個(gè)作為Header讀完的標(biāo)志,通過(guò) Content-Length 可以知道是否有Body內(nèi)容,以及有多少內(nèi)容。
switch { case t.Chunked: if noResponseBodyExpected(t.RequestMethod) || !bodyAllowedForStatus(t.StatusCode) { t.Body = NoBody } else { t.Body = &body{src: internal.NewChunkedReader(r), hdr: msg, r: r, closing: t.Close} } case realLength == 0: t.Body = NoBody case realLength > 0: t.Body = &body{src: io.LimitReader(r, realLength), closing: t.Close} default: // realLength < 0, i.e. "Content-Length" not mentioned in header if t.Close { // Close semantics (i.e. HTTP/1.0) t.Body = &body{src: r, closing: t.Close} } else { // Persistent connection (i.e. HTTP/1.1) t.Body = NoBody } }
func (l *LimitedReader) Read(p []byte) (n int, err error) { if l.N <= 0 { return 0, EOF } if int64(len(p)) > l.N { p = p[0:l.N] } n, err = l.R.Read(p) l.N -= int64(n) return }
io.LimitReader
在讀取到指定的長(zhǎng)度后就會(huì)返回EOF錯(cuò)誤,表示讀取完畢。
2、w.conn.r.startBackgroundRead
if requestBodyRemains(req.Body) { registerOnHitEOF(req.Body, w.conn.r.startBackgroundRead) } else { w.conn.r.startBackgroundRead() }
當(dāng)Body讀取完之后才會(huì)開(kāi)啟startBackgroundRead
。
func (cr *connReader) backgroundRead() { n, err := cr.conn.rwc.Read(cr.byteBuf[:]) cr.lock() if n == 1 { cr.hasByte = true ...... } if ne, ok := err.(net.Error); ok && cr.aborted && ne.Timeout() { // Ignore this error. It's the expected error from // another goroutine calling abortPendingRead. } else if err != nil { cr.handleReadError(err) } cr.aborted = false cr.inRead = false cr.unlock() cr.cond.Broadcast() } func (cr *connReader) handleReadError(_ error) { cr.conn.cancelCtx() cr.closeNotify() } // may be called from multiple goroutines. func (cr *connReader) closeNotify() { res, _ := cr.conn.curReq.Load().(*response) if res != nil && atomic.CompareAndSwapInt32(&res.didCloseNotify, 0, 1) { res.closeNotifyCh <- true } }
其實(shí)startBackgroundRead
就是為了監(jiān)控客戶端是否關(guān)閉了連接,它不能影響業(yè)務(wù)數(shù)據(jù)讀取,因此需要等Body被讀取完之后才開(kāi)啟,它象征性的讀取一個(gè)字節(jié),如果客戶端關(guān)閉了,對(duì)應(yīng)的 fd 是可讀的,它會(huì)像一個(gè)通道寫入數(shù)據(jù),此協(xié)程的生命周期是當(dāng)前請(qǐng)求,而不是當(dāng)前連接,它的作用是為了中斷當(dāng)前請(qǐng)求的 Handler 處理階段,它認(rèn)為客戶端已經(jīng)放棄了這個(gè)請(qǐng)求,服務(wù)端也沒(méi)必要做過(guò)多的業(yè)務(wù)處理,但是這個(gè)在實(shí)際業(yè)務(wù)中很難實(shí)現(xiàn),或者說(shuō)是多余的,在我們看來(lái),只要請(qǐng)求到達(dá)了,服務(wù)端就有義務(wù)正確的給予處理,不應(yīng)該將其中斷。
當(dāng)請(qǐng)求處理完畢,就會(huì)調(diào)用abortPendingRead
,使得startBackgroundRead
協(xié)程退出。為什么startBackgroundRead
協(xié)程的生命周期不是跟著連接呢,因?yàn)?Keep-Alive 的連接會(huì)持續(xù)一段時(shí)間,即便沒(méi)有請(qǐng)求到來(lái),這會(huì)導(dǎo)致startBackgroundRead
協(xié)程一直在運(yùn)行。
那么服務(wù)端何時(shí)去關(guān)閉此連接呢,畢竟客戶端是不可信的,它是通過(guò)設(shè)置SetReadDeadline
為ReadHeaderTimeout
來(lái)修改定時(shí)器時(shí)間,當(dāng)然如果沒(méi)有設(shè)置ReadHeaderTimeout
,那么會(huì)使用ReadTimeout
代替,超時(shí)還沒(méi)發(fā)來(lái)請(qǐng)求就可以認(rèn)為客戶端已經(jīng)沒(méi)有重用此連接了,for 循環(huán)退出,defer 中關(guān)閉此連接。
實(shí)際上客戶端只會(huì)在一個(gè)短的時(shí)間內(nèi)要發(fā)送多個(gè)請(qǐng)求的情況下才會(huì)重用連接,比如在頁(yè)面初始化的時(shí)候,瀏覽器會(huì)視情況重用連接。
ReadDeadline
是一個(gè)總的時(shí)間,一個(gè)截止時(shí)間,是讀取Header和讀取Body的總時(shí)間。
3、serverHandler{c.server}.ServeHTTP(w, w.req)
后面就開(kāi)始調(diào)用Handler,如果需要用到Body的信息,則需要接著讀取Body內(nèi)容,可見(jiàn)Header和Body是分開(kāi)來(lái)讀的。第二次讀取是不會(huì)阻塞的因?yàn)閒d里面有內(nèi)容,當(dāng)然如果有人惡意攻擊,只發(fā)請(qǐng)求頭不填Body,那么也會(huì)阻塞。
到此這篇關(guān)于深入分析Golang Server源碼實(shí)現(xiàn)過(guò)程的文章就介紹到這了,更多相關(guān)Go Server內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
golang 內(nèi)存對(duì)齊的實(shí)現(xiàn)
在代碼編譯階段,編譯器會(huì)對(duì)數(shù)據(jù)的存儲(chǔ)布局進(jìn)行對(duì)齊優(yōu)化,本文主要介紹了golang 內(nèi)存對(duì)齊的實(shí)現(xiàn),具有一定的參考價(jià)值,感興趣的可以了解一下2024-08-08go語(yǔ)言代碼生成器code?generator使用示例介紹
這篇文章主要為大家介紹了go語(yǔ)言代碼生成器code?generator的使用簡(jiǎn)單介紹,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2022-05-05Go語(yǔ)言reflect.TypeOf()和reflect.Type通過(guò)反射獲取類型信息
這篇文章主要介紹了Go語(yǔ)言reflect.TypeOf()和reflect.Type通過(guò)反射獲取類型信息,文中通過(guò)示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來(lái)一起學(xué)習(xí)學(xué)習(xí)吧2021-04-04Golang發(fā)送Get和Post請(qǐng)求的實(shí)現(xiàn)
做第三方接口有時(shí)需要用Get或者Post請(qǐng)求訪問(wèn),本文主要介紹了Golang發(fā)送Get和Post請(qǐng)求的實(shí)現(xiàn),文中通過(guò)示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來(lái)一起學(xué)習(xí)學(xué)習(xí)吧2024-05-05