web - http client 连接池不复用的问题 - 《golang生态》

当 http client 返回值为不为空，只读取 response header，但不读 body 内容就执行 response.Body.Close()，那么连接会被主动关闭，得不到复用。

测试代码如下

func main() {
    var t = &http.Transport{
        Proxy: func(req *http.Request) (*url.URL, error) { return &url.URL{Host: "127.0.0.1:9999"}, nil },
        DialContext: (&net.Dialer{
            Timeout:   30 * time.Second,
            KeepAlive: 30 * time.Second,
            DualStack: true,
        }).DialContext,
        ForceAttemptHTTP2:     true,
        MaxIdleConns:          100,
        IdleConnTimeout:       90 * time.Second,
        TLSHandshakeTimeout:   10 * time.Second,
        ExpectContinueTimeout: 1 * time.Second,
    }
    http.DefaultTransport = t
    for {
        time.Sleep(1 * time.Second)
        fmt.Println("new")
        resp, err := http.Get("http://www.baidu.com")
        if err != nil {
            fmt.Println(err)
            continue
        }
        if resp.StatusCode == http.StatusOK {
            //io.Copy(ioutil.Discard, resp.Body)
        }
        resp.Body.Close()
    }
}

第一次：

第二次：

多观察几个抓包数据，会发现连接没复用，每次请求都会新建一个tcp连接

接下来把io.Copy(ioutil.Discard, resp.Body) 注释取消，继续观察抓包
第一次：

第二次及之后：

很明显，复用了连接

话说，golang httpclient 需要注意的地方着实不少。

如没有 response.Body.Close()，有些小场景造成 persistConn 的 writeLoop 泄露。
如 header 和 body 都不管，那么会造成泄露的连接干满连接池，后面的请求只能是短连接。

通过 lsof 找到进程关联的 TCP 连接，然后使用 ss 或 netstat 查看读写缓冲区。信息如下，recv-q 读缓冲区确实是存在数据。这个缓冲区字节一直未读，直到连接关闭引发了 rst。

 lsof -p 54330
COMMAND   PID USER   FD      TYPE    DEVICE SIZE/OFF       NODE NAME
...
aaa     54330 root    1u      CHR     136,0      0t0          3 /dev/pts/0
aaa     54330 root    2u      CHR     136,0      0t0          3 /dev/pts/0
aaa     54330 root    3u  a_inode      0,10        0       8838 [eventpoll]
aaa     54330 root    4r     FIFO       0,9      0t0  223586913 pipe
aaa     54330 root    5w     FIFO       0,9      0t0  223586913 pipe
aaa     54330 root    6u     IPv4 223596521      0t0        TCP host-46:60626->110.242.68.3:http (ESTABLISHED)
$ ss -an|egrep "68.3:80"
State      Recv-Q      Send-Q       Local Address:Port        Peer Address:Port 
ESTAB      72480       0            172.16.0.46:60626         110.242.68.3:80

strace 跟踪系统调用
通过系统调用可分析出，貌似只是读取了 header 部分了，还未读到 body 的数据。

[pid  8311] connect(6, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("110.242.68.3")}, 16 <unfinished ...>
[pid 195519] epoll_pwait(3,  <unfinished ...>
[pid  8311] <... connect resumed>)      = -1 EINPROGRESS (操作现在正在进行)
[pid  8311] epoll_ctl(3, EPOLL_CTL_ADD, 6, {EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, {u32=2350546712, u64=140370471714584}} <unfinished ...>
[pid 195519] getsockopt(6, SOL_SOCKET, SO_ERROR,  <unfinished ...>
[pid 192592] nanosleep({tv_sec=0, tv_nsec=20000},  <unfinished ...>
[pid 195519] getpeername(6, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("110.242.68.3")}, [112->16]) = 0
[pid 195519] getsockname(6,  <unfinished ...>
[pid 195519] <... getsockname resumed>{sa_family=AF_INET, sin_port=htons(47746), sin_addr=inet_addr("172.16.0.46")}, [112->16]) = 0
[pid 195519] setsockopt(6, SOL_TCP, TCP_KEEPINTVL, [15], 4) = 0
[pid 195519] setsockopt(6, SOL_TCP, TCP_KEEPIDLE, [15], 4 <unfinished ...>
[pid  8311] write(6, "GET / HTTP/1.1\r\nHost: www.baidu.com\r\nUser-Agent: Go-http-client/1.1\r\nAccept-Encoding: gzip\r\n\r\n", 94 <unfinished ...>
[pid 192595] read(6,  <unfinished ...>
[pid 192595] <... read resumed>"HTTP/1.1 200 OK\r\nBdpagetype: 1\r\nBdqid: 0xc43c9f460008101b\r\nCache-Control: private\r\nConnection: keep-alive\r\nContent-Encoding: gzip\r\nContent-Type: text/html;charset=utf-8\r\nDate: Wed, 09 Dec 2020 13:46:30 GMT\r\nExpires: Wed, 09 Dec 2020 13:45:33 GMT\r\nP3p: CP=\" OTI DSP COR IVA OUR IND COM \"\r\nP3p: CP=\" OTI DSP COR IVA OUR IND COM \"\r\nServer: BWS/1.1\r\nSet-Cookie: BAIDUID=996EE645C83622DF7343923BF96EA1A1:FG=1; expires=Thu, 31-Dec-37 23:55:55 GMT; max-age=2147483647; path=/; domain=.baidu.com\r\nSet-Cookie: BIDUPSID=99"..., 4096) = 4096
[pid 192595] close(6 <unfinished ...>

分析问题
分析下为何出现短连接，连接不能复用的问题。
为什么不读取 body 就出问题？其实 http.Response 字段描述中已经有说明了。当 Body 未读完时，连接可能不能复用。

众所周知，golang httpclient 要注意 response Body 关闭问题，但上面的 case 确实有关了 body，只是非常规地没去读取 reponse body 数据。这样会造成连接异常关闭，继而引起连接池不能复用。

一般 http 协议解释器是要先解析 header，再解析 body，结合当前的问题开始是这么推测的，连接的 readLoop 收到一个新请求，然后尝试解析 header 后，返回给调用方等待读取 body，但调用方没去读取，而选择了直接关闭 body。那么后面当一个新请求被 transport roundTrip 再调度请求时，readLoop 的 header 读取和解析会失败，因为他的读缓冲区里有前面未读的数据，必然无法解析 header。按照常见的网络编程原则，协议解析失败，直接关闭连接。
想是这么想的，但还是看了 golang net/http 的代码，结果不是这样的。😅

分析源码
httpclient 每个连接会创建读写协程两个协程，分别使用 reqch 和 writech 来跟 roundTrip 通信。上层使用的response.Body 其实是经过多次封装的，一次封装的 body 是直接跟 net.conn 进行交互读取，二次封装的 body 则是加强了 close 和 eof 处理的 bodyEOFSignal。

当未读取 body 就进行 close 时，会触发 earlyCloseFn() 回调，看 earlyCloseFn 的函数定义，在 close 未见 io.EOF 时才调用。自定义的 earlyCloseFn 方法会给 readLoop 监听的 waitForBodyRead 传入 false, 这样引发 alive 为 false 不能继续循环的接收新请求，只能是退出调用注册过的 defer 方法，关闭连接和清理连接池。

func (pc *persistConn) readLoop() {
 closeErr := errReadLoopExiting // default value, if not changed below
 defer func() {
  pc.close(closeErr)      // 关闭连接
  pc.t.removeIdleConn(pc) // 从连接池中删除
 }()
  ...
 alive := true
 for alive {
     ...
  rc := <-pc.reqch  // 从管道中拿到请求，roundTrip 对该管道进行输入
  trace := httptrace.ContextClientTrace(rc.req.Context())
  var resp *Response
  if err == nil {
   resp, err = pc.readResponse(rc, trace) // 更多的是解析 header
  } else {
   err = transportReadFromServerError{err}
   closeErr = err
  }
    ...
  waitForBodyRead := make(chan bool, 2)
  body := &bodyEOFSignal{
   body: resp.Body,
   // 提前关闭 !!! 输出false
   earlyCloseFn: func() error {
    waitForBodyRead <- false
    ...
   },
   // 正常收尾 !!!
   fn: func(err error) error {
    isEOF := err == io.EOF
    waitForBodyRead <- isEOF
    ...
   },
  }
  resp.Body = body
  select {
  case rc.ch <- responseAndError{res: resp}:
  case <-rc.callerGone:
   return
  }
  select {
  case bodyEOF := <-waitForBodyRead:
   replaced := pc.t.replaceReqCanceler(rc.cancelKey, nil) // before pc might return to idle pool
   // alive 为 false, 不能继续 continue
   alive = alive &&
    bodyEOF &&
    !pc.sawEOF &&
    pc.wroteRequest() &&
    replaced && tryPutIdleConn(trace)
    ...
  case <-rc.req.Cancel:
   alive = false
   pc.t.CancelRequest(rc.req)
  case <-rc.req.Context().Done():
   alive = false
   pc.t.cancelRequest(rc.cancelKey, rc.req.Context().Err())
  case <-pc.closech:
   alive = false
  }
 }
}

bodyEOFSignal 的 Close()：

func (es *bodyEOFSignal) Close() error {
 es.mu.Lock()
 defer es.mu.Unlock()
 if es.closed {
  return nil
 }
 es.closed = true
 if es.earlyCloseFn != nil && es.rerr != io.EOF {
  return es.earlyCloseFn()
 }
 err := es.body.Close()
 return es.condfn(err)
}

最终会调用 persistConn 的 close(), 连接关闭并关闭closech：

func (pc *persistConn) close(err error) {
 pc.mu.Lock()
 defer pc.mu.Unlock()
 pc.closeLocked(err)
}
func (pc *persistConn) closeLocked(err error) {
 if err == nil {
  panic("nil error")
 }
 pc.broken = true
 if pc.closed == nil {
  pc.closed = err
  pc.t.decConnsPerHost(pc.cacheKey)
  if pc.alt == nil {
   if err != errCallerOwnsConn {
    pc.conn.Close() // 关闭连接
   }
   close(pc.closech) // 通知读写协程
  }
 }
}

如果单纯实现http client，可以用resty，易用性较好

参考：https://mp.weixin.qq.com/s?__biz=MjM5MDUwNTQwMQ==&mid=2257484657&idx=1&sn=8d61d625af3aafd9697f4d0139b632a9&chksm=a5391ba7924e92b1293458939d41db92e38a497e66b2dcf7cd5cfb517710a50481d52cd711a5&mpshare=1&scene=1&srcid=12236NuAVmSETqd8Dn0EX9xc&sharer_sharetime=1608719416036&sharer_shareid=4317d953c0b80e400bcd56fdb955a3af&key=acbfa0a404122fa5afb91b88149c71df50af93115f127cc02d0eda21b970e3d3727d99460a0a69175d1d0aa2b04d609b93b2e39869dd9a9a4869d9bb14a0e2fa83f067566c42e0ee7ebc09f9935cb3a652c0ed9e32f75753ee6f7eb2fb4419ee42cf99cbb73f9f512607681156bc5a248b12c25926d202321dd715eed19f1975&ascene=1&uin=MjA4ODYwNjgxOA%3D%3D&devicetype=Windows+10+x64&version=6300002f&lang=zh_CN&exportkey=AwHakHWmgrgEaaqRncJY604%3D&pass_ticket=ovTG9SiYf%2B9cW8fa%2B2fdf7YjFn1Q8MMiRoco0QfAToWU4UiW1Sl1JWP877MIAaCU&wx_header=0