go-fasthttp源码分析

1、架构

listener->server->workerpool

1.1、workerpool中有两种缓存：

a、wp.ready，缓存未退出worker，

b、worker退出后用sync.pool缓存channel

worker就是工作协程，它的存活期由maxIdleWorkerDuration控制，因此每次使用后都用lastUseTime记录。

workerpool每maxIdleWorkerDuration时间会使用“least recently used”策略清理掉空闲时间超过maxIdleWorkerDuration的，因为ready是按使用顺序排的（每次worker执行完workerFunc会append到最后），因此只要找到第一个时间超过maxIdleWorkerDuration的，把它和之前的workerChan都停掉、置nil即可。

问题：为什么有了worker的缓存，还需要缓存channel？

回答：fasthttp号称“Zero memory allocations in hot paths”，channel的make也算是allocation，可能也会耗时吧。

1.2、listener可以是net.Listen生成，也可以是reuseport.Listen生成，对多核机器性能表现更好。

2、解码

把server.ServeConn()作为workerpool的WorkerFunc传给worker

s.serveConn(c)主要就是从pool中取一个ctx，然后用bufio.Reader|bytePool封装conn，然后http request.readLimitBody

通过b, err := r(bufio.Reader).Peek(n)来每次重新header.Parse(b)，从请求行开始解析，最终readRawHeaders读到两个\n，再一股脑拷贝到RequestHeader.rawHeaders中。

问题：为什么不用bufio.Reader.ReadBytes([]byte("\r\n\r\n"))直接读到headers结束呢？

回答：Peek是返回bufio.Reader.buffer的slice，没有memory allocation，比ReadBytes性能要好。

问题为什么不直接连续Peek到两个\r\n就结束？

回答：这段代码就是这个思路。