Golang中的http.Server源码深入分析

 更新时间:2023年05月16日 10:34:33   作者:raoxiaoya  
这篇文章主要介绍了Golang中的http.Server源码,实现一个http.Server非常容易,只需要短短几行代码,同时有了协程的加持,Go实现的http.Server能够取得非常优秀的性能,下面我们来分析看看http.Server的源码
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 循环里面,是为了 HTTP Keep-Alive,可以复用TCP连接,并且是串行的,上一个请求处理完才会去读取下一个请求的数据,如果连接被客户端断开,那么c.readRequest(ctx)会因为读取报错而退出。

通过继续追踪源码,发现这里只是读取了 Header,并做一些判断,因此会有readHeaderDeadline这样的配置,然后设置Body的类型,Header和Body之间有一个空行,这个作为Header读完的标志,通过 Content-Length 可以知道是否有Body内容,以及有多少内容。

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在读取到指定的长度后就会返回EOF错误,表示读取完毕。

2、w.conn.r.startBackgroundRead

if requestBodyRemains(req.Body) {
    registerOnHitEOF(req.Body, w.conn.r.startBackgroundRead)
} else {
    w.conn.r.startBackgroundRead()
}

当Body读取完之后才会开启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
	}
}

其实startBackgroundRead就是为了监控客户端是否关闭了连接,它不能影响业务数据读取,因此需要等Body被读取完之后才开启,它象征性的读取一个字节,如果客户端关闭了,对应的 fd 是可读的,它会像一个通道写入数据,此协程的生命周期是当前请求,而不是当前连接,它的作用是为了中断当前请求的 Handler 处理阶段,它认为客户端已经放弃了这个请求,服务端也没必要做过多的业务处理,但是这个在实际业务中很难实现,或者说是多余的,在我们看来,只要请求到达了,服务端就有义务正确的给予处理,不应该将其中断。

当请求处理完毕,就会调用abortPendingRead,使得startBackgroundRead协程退出。为什么startBackgroundRead协程的生命周期不是跟着连接呢,因为 Keep-Alive 的连接会持续一段时间,即便没有请求到来,这会导致startBackgroundRead协程一直在运行。

那么服务端何时去关闭此连接呢,毕竟客户端是不可信的,它是通过设置SetReadDeadlineReadHeaderTimeout来修改定时器时间,当然如果没有设置ReadHeaderTimeout,那么会使用ReadTimeout代替,超时还没发来请求就可以认为客户端已经没有重用此连接了,for 循环退出,defer 中关闭此连接。

实际上客户端只会在一个短的时间内要发送多个请求的情况下才会重用连接,比如在页面初始化的时候,浏览器会视情况重用连接。

ReadDeadline是一个总的时间,一个截止时间,是读取Header和读取Body的总时间。

3、serverHandler{c.server}.ServeHTTP(w, w.req)

后面就开始调用Handler,如果需要用到Body的信息,则需要接着读取Body内容,可见Header和Body是分开来读的。第二次读取是不会阻塞的因为fd里面有内容,当然如果有人恶意攻击,只发请求头不填Body,那么也会阻塞。

到此这篇关于Golang中的http.Server源码深入分析的文章就介绍到这了,更多相关Golang http.Server内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!

相关文章

  • 浅谈go build后加文件和目录的区别

    浅谈go build后加文件和目录的区别

    这篇文章主要介绍了浅谈go build后加文件和目录的区别,具有很好的参考价值,希望对大家有所帮助。一起跟随小编过来看看吧
    2020-12-12
  • Golang设计模式工厂模式实战写法示例详解

    Golang设计模式工厂模式实战写法示例详解

    这篇文章主要为大家介绍了Golang 工厂模式实战写法示例详解,有需要的朋友可以借鉴参考下,希望能够有所帮助,祝大家多多进步,早日升职加薪
    2022-08-08
  • Go语言中defer语句的用法

    Go语言中defer语句的用法

    这篇文章介绍了Go语言中defer语句的用法,文中通过示例代码介绍的非常详细。对大家的学习或工作具有一定的参考借鉴价值,需要的朋友可以参考下
    2022-07-07
  • Windows下Goland的环境搭建过程详解

    Windows下Goland的环境搭建过程详解

    这篇文章主要介绍了Windows下Goland的环境搭建过程,本文通过图文并茂的形式给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,需要的朋友可以参考下
    2020-10-10
  • Go语言resty http包调用jenkins api实例

    Go语言resty http包调用jenkins api实例

    这篇文章主要为大家介绍了Go语言resty http包调用jenkins api实例,有需要的朋友可以借鉴参考下,希望能够有所帮助,祝大家多多进步,早日升职加薪
    2022-06-06
  • Go 中的空白标识符下划线

    Go 中的空白标识符下划线

    这篇文章主要介绍了Go 中的空白标识符下划线,空白标识符是未使用的值的占位符,由下划线(_)表示,下文对其相关介绍需要的小伙伴可以参考一下
    2022-03-03
  • Golang中的信号(Signal)机制详解

    Golang中的信号(Signal)机制详解

    Signal 是一种操作系统级别的事件通知机制,进程可以响应特定的系统信号,这些信号用于指示进程执行特定的操作,如程序终止、挂起、恢复等,Golang 的标准库 os/signal 提供了对信号处理的支持,本文将详细讲解 Golang 是如何处理和响应系统信号的,需要的朋友可以参考下
    2024-01-01
  • Go语言异常处理(Panic和recovering)用法详解

    Go语言异常处理(Panic和recovering)用法详解

    异常处理是程序健壮性的关键,往往开发人员的开发经验的多少从异常部分处理上就能得到体现。Go语言中没有Try Catch Exception机制,但是提供了panic-and-recover机制,本文就来详细讲讲他们的用法
    2022-07-07
  • 基于golang的轻量级工作流框架Fastflow

    基于golang的轻量级工作流框架Fastflow

    这篇文章主要介绍了基于golang的轻量级工作流框架Fastflow,fastflow 执行任务的过程会涉及到几个概念:Dag, Task, Action, DagInstance,本文给大家分享完整流程,需要的朋友可以参考下
    2022-05-05
  • 详解Go语言实现线性查找算法和二分查找算法

    详解Go语言实现线性查找算法和二分查找算法

    线性查找又称顺序查找,它是查找算法中最简单的一种。二分查找,也称折半查找,相比于线性查找,它是一种效率较高的算法。本文将用Go语言实现这两个查找算法,需要的可以了解一下
    2022-12-12

最新评论