当前位置：首页 > 文章列表 > Golang > Go教程 > 深入分析GolangServer源码实现过程

深入分析GolangServer源码实现过程

来源：脚本之家 2023-02-25 08:59:43 0浏览收藏

golang学习网今天将给大家带来《深入分析GolangServer源码实现过程》，感兴趣的朋友请继续看下去吧！以下内容将会涉及到server等等知识点，如果你是正在学习Golang或者已经是大佬级别了，都非常欢迎也希望大家都能给我建议评论哈~希望能帮助到大家！

func (srv *Server) Serve(l net.Listener) error {
	......
	for {
		rw, err := l.Accept()
		if err != nil {
			select {
			case  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

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

func (l *LimitedReader) Read(p []byte) (n int, err error) {
	if l.N  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

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

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

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

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

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

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

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

到这里，我们也就讲完了《深入分析GolangServer源码实现过程》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于golang的知识点！

golang server

版本声明

本文转载于：脚本之家如有侵犯，请联系study_golang@163.com删除