如果让我们自己来实现一个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)中感兴趣可以看看
