深入分析Golang 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 Server源码实现过程的文章就介绍到这了,更多相关Go Server内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • 一文详解Go Http Server原理

    目录 从一个 Demo 入手 Http Server 如何处理连接? Http Server 如何处理请求的? 一些前置工作 serve 方法到底干了什么 请求如何路由? 总结 从一个 Demo 入手 俗话说万事开头难,但用 Go 实现一个 Http Server 真不难,简单到什么程度?起一个 Server,并且能响应请求,算上包名.导入的依赖,甚至空行,也就只要 15 行代码: package main import ( "io" "net/http" ) fu

  • Golang实现http server提供压缩文件下载功能

    最近遇到了一个下载静态html报表的需求,需要以提供压缩包的形式完成下载功能,实现的过程中发现相关文档非常杂,故总结一下自己的实现. 开发环境: 系统环境:MacOS + Chrome 框架:beego 压缩功能:tar + gzip 目标压缩文件:自带数据和全部包的静态html文件 首先先提一下http server文件下载的实现,其实就是在后端返回前端的数据包中,将数据头设置为下载文件的格式,这样前端收到返回的响应时,会直接触发下载功能(就像时平时我们在chrome中点击下载那样) 数据头设

  • 使用Go语言写一个Http Server的实现

    目录 调试 功能1 功能2 功能3 功能4 Http Server 代码 go.mod: module goStudy1 go 1.17 main.go: package main import ( "fmt" "os" "strconv" //"github.com/thinkeridea/go-extend/exnet" "io" "log" "net/http"

  • Golang简单实现http的server端和client端

    介绍 HTTPS (Secure Hypertext Transfer Protocol)安全超文本传输协议,是一个安全通信通道,它基于HTTP开发用于在客户计算机和服务器之间交换信息.它使用安全套接字层(SSL)进行信息交换,简单来说它是HTTP的安全版,是使用TLS/SSL加密的HTTP协议. HTTP和HTTPS的区别 HTTPS是加密传输协议,HTTP是名文传输协议 HTTPS需要用到SSL证书,而HTTP不用 HTTPS比HTTP更加安全,对搜索引擎更友好,利于SEO HTTPS标准端

  • 深入分析Golang 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 { te

  • mysql5.6.8源码安装过程

    内核: [root@opop ~]# cat /etc/centos-release CentOS release 6.8 (Final) [root@opop ~]# uname -a Linux opop 2.6.32-642.el6.x86_64 #1 SMP Tue May 10 17:27:01 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux 开始安装: [root@opop ~]# for i in `rpm -qa | grep mysql`;do

  • CentOs7 64位 mysql 5.6.40源码安装过程

    1.首先安装依赖包,避免在安装过程中出现问题 [root@chufeng yusen]# yum -y install wget vim bash-completion [root@chufeng yusen]# yum -y install gcc gcc-c++ cmake ncurses-devel autoconf perl perl-devel 2.下载mysql-5.6.40.tar.gz MySQLxxx下载地址: https://dev.mysql.com/downloads/m

  • 开源数据库postgreSQL13在麒麟v10sp1源码安装过程详解

    一.中标麒麟v10sp1在飞腾2000+系统安装略 二.系统依赖包安装 [root@ft2000db opt]# yum install bzip* [root@ft2000db opt]# nkvers ############## Kylin Linux Version ################# Release: Kylin Linux Advanced Server release V10 (Tercel) Kernel: 4.19.90-17.ky10.aarch64 Buil

  • Python Django源码运行过程解析

    目录 一.Django运行顺序 1.启动 1.1 命令行启动(测试服务器) 2.监听 2.1 runserver(测试服务器) 3.中间件的执行 本文只算是本人片面之言(当然也会借鉴网络上公开资料),而且技术含量比较低,内容质量也一般,大家仅限参考即可 如果对本文看不太懂,请先阅读后面文章,等都差不多看完再回顾来看 一.Django运行顺序 WSGI会不断监听客户端发送来的请求 先经过中间件进行分析验证处理 然后经过url分发与验证 视图层进行处理 再经过中间件进行分析验证处理 返回响应内容 1

  • mysql-5.5.28源码安装过程中错误总结

    介绍一下关于mysql-5.5.28源码安装过程中几大错误总结,希望此文章对各位同学有所帮助.系统centOS 6.3 mini (没有任何编译环境)预编译环境首先装了众所周知的 cmake(yum install cmake -y) 复制代码 代码如下: ../bootstrap Error when bootstrapping CMake: Cannot find appropriate C compiler on this system. Please specify one using

  • Spring Bean的实例化之属性注入源码剖析过程

    前言 这一章节我们来讨论创建Bean过程中的属性注入,在Spring的IOC容器启动过程中,会把定义的Bean封装成BeanDefinition注册到一个ConcurrentHashMap中,Bean注册完成后,就会对单利的且lazy-init=false 的Bean进行实例化.创建Bean的代码在 AbstractAutowireCapableBeanFactory#doCreateBean 中,当Bean创建成功之后,会调用AbstractAutowireCapableBeanFactory

  • Idea导入eureka源码实现过程解析

    通过GitHub获取Eureka源码 进入git bash命令行,自己找个目录,用来存放eureka源码,然后在目录里面,执行git clone  https://github.com/Netflix/eureka.git,就可以了,这个是需要点时间的,稍微有点慢,你等一会儿好了. git clone https://github.com/Netflix/eureka.git 获取eureka项目依赖 然后在eureka目录中,直接双击gradlew.bat就可以,这个是人家给你提供的命令,直接

  • 分享CentOS下MySQL最新版本5.6.13源码安装过程

    2个月前公司给DBA的测试服务器被收回去了,一直跟开发用一组DB,有些需要测试的小功能,需要不断重启db,为了不影响开发同事,自己又申请了一个虚拟机,准备安装最新的5.6.13版本的MySQL社区版. 1 download the tar.gzwget http://dev.mysql.com/get/Downloads/MySQL-5.6/mysql-5.6.13.tar.gz/from/http://cdn.mysql.com/ 2 安装cmake软件包yum install cmake 3

  • 修改并编译golang源码的操作步骤

    最近为了做Hyperledger Fabric国密改造,涉及到了golang源码的改动.特将操作过程整理如下,以供参考: golang的源码安装其实比较简单,只需运行源码包中的脚本src/all.bash,等到出现类似以下字样就安装好了: Installed Go for linux/amd64 in xxx(目录地址) Installed commands in xxx(目录地址) 但是在源码安装1.5版本以上的go时会报以下的错误 : ##### Building Go bootstrap

随机推荐