如果让我们自己来实现一个http server,大部分同学都可以写出以下实现:

import ( 
"fmt"
"net"
"os" 
)
func main() {
  tcpAddr, err := net.ResolveTcpAddr("tcp", "localhost:6666")
  checkError(err)
  fd, err := net.ListenTcp("tcp", tcpAddr)
  checkError(err)
  for {
    conn, err := fd.Accept()
    if err != nil {
      continue
    }
    go Handle(conn) 
  }
}

主要步骤就是:

  • 监听一个端口
  • 一个大循环不断地Accept连接
  • 每个连接开一个goroutine去处理业务逻辑

以上的步骤也很直观,非常好理解。如果你粗略地扫一眼标准库httpServer的实现,也能看到大致是一个路子。以下是标准库的关键部分:

    for {
        rw, e := l.Accept()
        if e != nil {
            //处理错误 ...
        }
        tempDelay = 0
        c := srv.newConn(rw)
        c.setState(c.rwc, StateNew) // before Serve can return
        go c.serve(ctx)
    }

看起来几乎差不多也是一个套路,accept一个连接,然后起一个goroutine去处理。不过最近在做流量录制时遇到一个奇怪的现象。

我起了一个非常简单的echo server,然后使用strace查看它的系统调用。同时我有一个client每隔10s curl一次。奇怪的事情来了,client发了无数次请求,一直到我关闭了server,strace都显示server只进行过两次accept,而且这两次accept都是在第一个请求到来之前。

这里就比较困惑了,前面httpserver的源码我们也看了,确实是accept一个连接,再go 一个handler,怎么会出现没有accept依然能走到handler呢?

寻找问题

我第一时间想到的是,会不会是Go把Accept包了一层,在内部复用了连接,因此我尝试去读这块的源码实现。这里还是要吐槽一下这块儿Go的代码实现得还是不怎么好,看着比较乱。同时vscode的代码跳转也问题很多,经常跳到错误的地方去了,很多platform related的代码实现都跳不对。

这里总结的第一条经验就是,看标准库的源码,一定要用delve进行单步,用IDE跳转就废了。当然你也应该要理解IDE,毕竟很多代码都是compiler自动生成的,或者有些函数需要ld的帮助才能找到对应实现。所以一定要用dlv!

同步与异步

要理解这个现象的根本原因,我们需要先理解Go提供给我们的同步调用的抽象。首先,Go标准库中所有API都是“同步”的,并不是异步的。那么问题就来了,如果都是同步调用,那么和多线程还有啥区别,syscall始终要有一个线程阻塞在那里等待返回,实现一个N*M的goroutine还有啥意义?
上面的“同步”我是打了引号的,如果真的完全是同步的,那么goroutine确实就废了,这说明它并没有表面上那么简单。我们在进行网络IO操作时,代码都是这样的:

err := conn.Write(buffer)
data,err := conn.ReadAll()

然而实际上内部实现做了很多事情,最关键的一点是,最底层的IO操作其实是异步的。异步就需要等待event fire,但是我的代码并没有这么做啊?——这便是Go提供的抽象所在。
底层其实把每个socket都加入到了一个全局的epollfd中进行监听,当我们在socket上发生读写操作时,标准库都会进行异步操作,也就是说底层其实立刻就返回了。但是如果事件并没有完成,那么它会配合runtime park当前的goroutine,也就是说会把当前这个goroutine挂起。这里要注意,由于是异步操作,因此真正的线程是不阻塞而是立刻返回的,因此scheduler可以调度当前线程执行其它goroutine。当epoll收到event fire时,scheduler再把该goroutine唤醒,然后让对应线程去执行那个goroutine。这样,我们编写代码时就可以以同步的方式,写出基于异步回调的高性能的代码了。
这里的关键是,IO相关的系统调用是异步的,操作系统线程不会阻塞。因此配合scheduler正确的调度,才能实现这种抽象。同步的代码,异步的性能。如果系统调用会阻塞,那scheduler也没辙。

问题所在

回到之前的问题,由于底层会把每个socket都加入到epoll中进行监听,因此主循环每accept到一个连接,就会加入到epoll中。如果你对网络编程的概念不是很熟悉,你可能会问,如果把某个socket加入epoll之后就无法accept了吗?如果你问出这个问题,至少说明你没有理解accept的语义。看一个accept的manpage,一开始是这么说的:

The accept() system call is used with connection-based socket types(SOCK_STREAM, SOCK_SEQPACKET). It extracts the first connection request on the queue of pending connections for the listening socket, sockfd, creates a new connected socket, and returns a new file descriptor referring to that socket. The newly created socket is not in the listening state. The original socket sockfd is unaffected by this call.

当client和server通过三次握手建立了连接之后(也就是实例化了一个socket结构体),它会被放到内核的一个缓存队列里。accept就是从这个队列的队首取出一个socket,然后返回一个fd指向该socket。换句话说,accept消费的是三次握手新建的连接!对于建立好的连接,后续发送的数据,只需要对该fd调用read方法即可。当然,这里也很复杂,因为你不知道这个fd对应的socket什么时候有数据,然后你要么轮询地试要么select要么就epoll,反正这里就有很多方法了。
因此你应该理解,accept是读取新连接,而epoll等各种方法实际上针对的是已建立的连接,对其后续的数据流入流出事件进行通知。
但是还是很奇怪啊,据说HTTP不是短连接吗?NoNoNo,这个观点已经过时了。在HTTP/1.0时代,确实是短连接。虽然TCP是长连接,但是基于TCP的HTTP/1.0协议要求:如果client没有明确告之keepalive,server在发送完response后就要主动关闭连接。那时keepalive还是一个试验特性,不过现在使用的http/1.1协议中,keepalive已经是默认行为了。因此大部分http请求也是长连接,也就是说socket并不会主动被server关掉。
一般来说,如果要复用连接,我们需要保存对应的数据结构,比如:

cli := newClient(host)
cli.Post()
cli.Get()
cli.Post()

但是,我们大多数时候直接使用了静态方法,并没有保存句柄:

http.Get()
http.Post()

不过go的http包底层帮我们做了连接池,我们的TCP连接都会被放到一个map中,后续建立连接前先检查map中有没有对应的连接,如果没有才会进行新建连接。

// getConn dials and creates a new persistConn to the target as
// specified in the connectMethod. This includes doing a proxy CONNECT
// and/or setting up TLS.  If this doesn't return an error, the persistConn
// is ready to write requests to.
func (t *Transport) getConn(treq *transportRequest, cm connectMethod) (*persistConn, error) {
    req := treq.Request
    trace := treq.trace
    ctx := req.Context()
    if trace != nil && trace.GetConn != nil {
        trace.GetConn(cm.addr())
    }
    if pc, idleSince := t.getIdleConn(cm); pc != nil {
        if trace != nil && trace.GotConn != nil {
            trace.GotConn(pc.gotIdleConnTrace(idleSince))
        }
        // set request canceler to some non-nil function so we
        // can detect whether it was cleared between now and when
        // we enter roundTrip
        t.setReqCanceler(req, func(error) {})
        return pc, nil
    }
    type dialRes struct {
        pc  *persistConn
        err error
    }
    dialc := make(chan dialRes)
//...后面省略

你可以看到,获取连接时会先getIdleConn,如果没有IdleConn再去dial。具体的代码就不细讲了,因为实现一个连接池简单,但是要实现一个高性能的连接池还是挺麻烦的,感兴趣可以具体学习下为什么有两个map。

而具体从conn中通过epoll或者kqueue读取数据然后执行ServeHTTP的逻辑,都在go c.serve(ctx)中感兴趣可以看看

文章来源于互联网:Go http.Server处理长连接

发表评论