  Go语言中，当我们需要访问第三方服务时，通常基于http.Client完成，顾名思义其代表HTTP客户端。http.Client的使用相对比较简单，不过底层有一些细节还是要多注意，包括长连接（连接池问题），可能偶现的reset情况等等。本篇文章主要介绍http.Client的基本使用方式，实现原理，以及一些注意事项。
## http.Client 概述
  Go语言中想发起一个HTTP请求真的是非常简单，net/http包封装了非常好用的函数，基本上一行代码就能搞定，如下面几个函数，用于发起GET请求或者POST请求：
```
func Post(url, contentType string, body io.Reader) (resp *Response, err error)
func PostForm(url string, data url.Values) (resp *Response, err error)
func Get(url string) (resp *Response, err error)
```
  这些函数其实都是基于http.Client实现的，其代表着HTTP客户端，如下所示：
```
//使用默认客户端DefaultClient
func PostForm(url string, data url.Values) (resp *Response, err error) {
return DefaultClient.PostForm(url, data)
}
func (c *Client) PostForm(url string, data url.Values) (resp *Response, err error) {
return c.Post(url, "application/x-www-form-urlencoded", strings.NewReader(data.Encode()))
}
```
  那么，http.Client是如何实现HTTP请求的发起过程呢？我们先看看http.Client结构的定义，非常简单，只有4个字段：
```
type Client struct {
//顾名思义传输层
Transport RoundTripper
//处理重定向方式（当301、302等之类重定向怎么办）
CheckRedirect func(req *Request, via []*Request) error
//存储预置cookie，向外发起请求时自动添加cookie
Jar CookieJar
//超时时间
Timeout time.Duration
}
type RoundTripper interface {
RoundTrip(*Request) (*Response, error)
}
```
  http.RoundTripper是一个接口，只自定义了一个方法，用于实现如何传输HTTP请求（长连接还是短连接等）；如果该字段为空，默认使用http.DefaultTransport，其类型为http.Transport结构（实现了RoundTripper接口）。
  CheckRedirect定义了请求重定向的处理方式，也就是当第三方服务返回301、302之类的重定向状态码时，如何处理，继续请求还是直接返回给上层业务；如果该字段为空，默认使用http.defaultCheckRedirect函数实现，该函数限制重定向次数不能超过10次。
  http.CookieJar是做什么的呢？存储预设置的cookie，而当我们使用http.Client发起请求时，会查找对应cookie，并自动添加；http.CookieJar也是一个接口，定义了两个方法，分别用于预设置cookie，以及发起请求时查找cookie，Go语言中cookiejar.Jar结构实现了接口http.CookieJar。
```
type CookieJar interface {
SetCookies(u *url.URL, cookies []*Cookie)
Cookies(u *url.URL) []*Cookie
}
```
  Timeout就比较简单了，就是请求的超时时间，超时返回错误"Client.Timeout exceeded while awaiting headers"。
  发起HTTP请求最终都会走到http.Client.do方法：这个方法的输入参数类型是http.Request，表示HTTP请求，包含有请求的method、Host、url、header、body等数据；方法的返回值类型是http.Response，表示HTTP响应，包含有响应状态码status、header、body等数据。http.Client.do方法的主要流程如下：
```
func (c *Client) do(req *Request) (retres *Response, reterr error) {
for {
//被重定向了
if len(reqs) > 0 {
loc := resp.Header.Get("Location")
//重新封装请求
req = &Request{
}
//重定向校验，默认使用ttp.defaultCheckRedirect函数，限制最多重定向10次
err = c.checkRedirect(req, reqs)
if err == ErrUseLastResponse {
return resp, nil
}
}
reqs = append(reqs, req)
if resp, didTimeout, err = c.send(req, deadline); err != nil {
//超时了
if !deadline.IsZero() && didTimeout() {
err = &httpError{
err: err.Error() + " (Client.Timeout exceeded while awaiting headers)",
timeout: true,
}
}
return nil, uerr(err)
}
//是否需要重定向（状态码301、302、307、308）
redirectMethod, shouldRedirect, includeBody = redirectBehavior(req.Method, resp, reqs[0])
if !shouldRedirect {
return resp, nil
}
}
```
  可以看到，http.Client.do方法整个流程还是比较简单的，那我们还研究什么呢？发起HTTP请求最复杂的逻辑应该是"HTTP请求的发送"，也就是http.RoundTripper，最明显的一个问题就是，采用的是短链接还是长连接呢？长连接的话如何维护连接池呢？
## 连接池概述
  Go语言作为常驻进程，发起HTTP请求时，采用的是短链接还是长连接呢？短链接的话需要我们每次请求关闭关闭连接吗？长连接的话是不是需要维护一个连接池？也就是已建立的连接，请求返回之后，这些连接就空闲了，将其存储在连接池（而不是直接关闭），待下次发起HTTP请求时，继续复用这个连接（从连接池获取）。当然连接池并不止这么简单，比如池子中最多存储多少个空闲连接呢？如果某个连接长时间空闲会将其关闭吗？有没有心跳机制呢？发起HTTP请求获取空闲连接时，如果没有空闲连接怎么办？新建连接吗？可以无限制新建连接吗（突发流量）？这些所有的行为都定义在结构http.Transport，而且这个结构实现了接口http.RoundTripper：
```
type Transport struct {
//空闲连接池（key为协议目标地址等组合）
idleConn map[connectMethodKey][]*persistConn // most recently used at end
//等待空闲连接的队列
idleConnWait map[connectMethodKey]wantConnQueue // waiting getConns
//连接数（key为协议目标地址等组合）
connsPerHost map[connectMethodKey]int
//等待建立连接的队列
connsPerHostWait map[connectMethodKey]wantConnQueue // waiting getConns
//禁用HTTP长连接（请求完毕后完毕连接）
DisableKeepAlives bool
//最大空闲连接数，0无限制
MaxIdleConns int
//每host最大空闲连接数，默认为2（注意默认值）
MaxIdleConnsPerHost int
//每host最大连接数，0无限制
MaxConnsPerHost int
//空闲连接超时时间，该时间段没有请求则关闭该连接
IdleConnTimeout time.Duration
}
```
  可以看到，空闲连接池（idleConn）是一个map结构，而key为协议目标地址等组合，注意字段MaxIdleConnsPerHost定义了每host最大空闲连接数，即同一种协议与同一个目标host可建立的连接或者空闲连接是有限制的，如果你没有配置MaxIdleConnsPerHost，Go语言默认MaxIdleConnsPerHost等于2，即与目标主机最多只维护两个空闲连接。MaxIdleConns描述的也是最大空闲连接数，只不过其限制的是总数。想想如果这两个配置不合理（过少），会导致什么呢？如果遇到突发流量，由于空闲连接数较少，会瞬间建立大量连接，但是回收连接时，同样由于最大空闲连接数的限制，该连接不能进入空闲连接池，只能直接关闭。结果是，一直新建大量连接，又关闭大量连，业务机器的TIME_WAIT连接数随之突增。
  MaxConnsPerHost描述的是最大连接数，如果没有配置意味着无限制，注意不是空闲连接，也就是同一种协议与同一个目标host可建立的最大连接数。空闲连接数有限制，连接数也有限制，那如果超过限制怎么办？也就是获取空闲连接没有了，新建连接也不行，这时候怎么办？排队等待呗，idleConnWait维护等待空闲连接队列，connsPerHostWait维护等待连接的队列。想想如果MaxConnsPerHost配置的不合理呢？发送HTTP请求获取空闲连接发现没有排队等待，同时尝试新建连接发现超过限制，继续排队等待，如果遇到突发流量，可能请求都超时了，还没有获取到可用连接。
  最后，Transport也提供了配置DisableKeepAlives，禁用长连接，使用短连接访问第三方服务。
  Transport结构我们基本了解了，那么其发送HTTP请求的流程是怎样的呢？如下：
```
func (t *Transport) roundTrip(req *Request) (*Response, error) {
for {
//获取连接
pconn, err := t.getConn(treq, cm)
//发送请求
resp, err = pconn.roundTrip(treq)
if err == nil {
resp.Request = origReq
return resp, nil
}
//判断是否需要重试
if !pconn.shouldRetryRequest(req, err) {
return nil, err
}
}
}
```
  整个流程省略了很多细节，http.Transport.getConn方法用于从连接池获取可用连接，获取连接基本就是两个步骤：1）尝试获取空闲连接；2）常识新建连接。该过程涉及到的核心流程（方法）如下：
```
func (t *Transport) getConn(treq *transportRequest, cm connectMethod) (pc *persistConn, err error) {
//获取到空闲连接，返回
if delivered := t.queueForIdleConn(w); delivered {
return pc, nil
}
//新建连接或者排队等待
t.queueForDial(w)
select {
//空闲连接放回连接池时，或者异步建立连接成功后，分配，同时关闭管道w.ready，这里select就会触发
case <-w.ready:
return w.pc, w.err
// 其他case，如超时等
}
}
//请求处理完毕，将空闲连接放回连接池
func (t *Transport) tryPutIdleConn(pconn *persistConn) error
```
  http.persistConn结构代表着一个连接，值得一提的是，HTTP请求的发送以及响应的读取也是异步协程完成的，主协程与之都是通过管道通信的（写请求，获取响应），这两个异步协程是在建立连接的时候启动的，分别是writeLoop以及readLoop（真正执行socket读写操作），如下所示：
```
type persistConn struct {
//协程间通信用的管道（请求与响应）
reqch chan requestAndChan // written by roundTrip; read by readLoop
writech chan writeRequest // written by roundTrip; read by writeLoop
}
func (pc *persistConn) roundTrip(req *transportRequest) (resp *Response, err error) {
//通知准备发起HTTP请求（写数据）
pc.writech <- writeRequest{req, writeErrCh, continueCh}
//通知准备读取响应
pc.reqch <- requestAndChan{
}
for {
select {
//获取到响应了
case re := <-resc:
return re.res, nil
//超时，出错等等case处理（可能直接关闭该连接）
}
}
}
```
  初学Go语言时，可能很难理解各种异步操作，但是要知道，协程是Go语言的精髓。这里在发起HTTP请求时，也是采用异步协程，这样socket的读写操作阻塞的也是异步协程，主协程只控制好主流程就行，很简单就实现了各种超时处理，错误处理等逻辑。
  最后提出一个问题，如何实现队列呢？你是不是想说，这也太简单了，基于切片不就行了，入队append切片结尾，出队即返回切片第一个元素。想想这样有什么问题吗？随着频繁的入队与出队操作，切片的底层数组，会有大量空间无法复用而造成浪费。或者是采用环形队列，可是环形队列也意味有长度限制（管道chan就是基于环形队列）。
  Go语言在实现队列时，使用了两个切片head和tail；head切片用于出队操作，tail切片用于入队操作；入队时，直接append到tail切片；出队优先从head切片获取，如果head切片为空，则交换head与tail。通过这种方式，实现了底层数组空间的复用。
```
//入队
func (q *wantConnQueue) pushBack(w *wantConn) {
q.tail = append(q.tail, w)
}
//出队
func (q *wantConnQueue) popFront() *wantConn {
// head为空
if q.headPos >= len(q.head) {
if len(q.tail) == 0 {
return nil
}
// 交换
q.head, q.headPos, q.tail = q.tail, 0, q.head[:0]
}
w := q.head[q.headPos]
q.head[q.headPos] = nil
q.headPos++
return w
}
```
## connection reset by peer
  没想到连接池需要注意这么多事情吧，别急，还有一个问题我们没有解决，我们直接少了IdleConnTimeout配置空闲长连接超时时间，Go语言HTTP连接池如何实现空闲连接的超时关闭逻辑呢？其实是在queueForIdleConn函数实现的，每次在获取到空闲连接时，都会检测是否已经超时，超时则关闭连接。
```
func (t *Transport) queueForIdleConn(w *wantConn) (delivered bool) {
//如果配置了空闲超时时间，获取到连接需要检测，超时则关闭连接
if t.IdleConnTimeout > 0 {
oldTime = time.Now().Add(-t.IdleConnTimeout)
}
if list, ok := t.idleConn[w.key]; ok {
for len(list) > 0 && !stop {
pconn := list[len(list)-1]
//pconn.idleAt记录该长连接空闲时间（什么时候添加到连接池）
tooOld := !oldTime.IsZero() && pconn.idleAt.Round(0).Before(oldTime)
//超时了，关闭连接
if tooOld {
go pconn.closeConnIfStillIdle()
}
//分发连接到wantConn
delivered = w.tryDeliver(pconn, nil)
}
}
}
```
  那如果没有业务请求到达，一直不需要获取连接，空闲连接就不会超时关闭吗？其实在将空闲连接添加到连接池时，Golang同时还设置了定时器，定时器到期后，自然会关闭该连接。
```
func (t *Transport) tryPutIdleConn(pconn *persistConn) error {
if t.IdleConnTimeout > 0 && pconn.alt == nil {
if pconn.idleTimer != nil {
pconn.idleTimer.Reset(t.IdleConnTimeout)
} else {
//设置定时器，超时后关闭连接
pconn.idleTimer = time.AfterFunc(t.IdleConnTimeout, pconn.closeConnIfStillIdle)
}
}
}
```
  所以说，连接池中的空闲长连接如果长时间没有被使用，是会被关闭的。其实Go服务主动关闭长连接是一件好事，如果是上游服务先关闭长连接，那就有可能导致"connection reset by peer"情况出现。为什么呢？想想某一时刻，上游服务关闭长连接，与此同时你的Go服务刚好需要发起HTTP请求，并且获取到该上连接（此时连接还正常），于是你的请求通过该长连接发送了，但是上游服务已经关闭该连接了，这时候怎么办？上游服务TCP层只能给你返回RST包了，于是就出现了上述错误。所以说，基于长连接传输HTTP请求时，最好是下游主动关闭长连接，不要等到上游服务关闭。
  我们以Nginx（常用来做接入层网关）为例（Go服务通过长连接向发起HTTP请求，请求先到达网关Nginx节点），讲解下为什么上游服务会关闭长连接。Nginx有两个配置描述长连接断开行为：
```
Syntax: keepalive_timeout timeout [header_timeout];
Default:
keepalive_timeout 75s;
Context: http, server, location
The first parameter sets a timeout during which a keep-alive client connection will stay open on the server side
Syntax: keepalive_requests number;
Default:
keepalive_requests 1000;
Context: http, server, location
Sets the maximum number of requests that can be served through one keep-alive connection. After the maximum number of requests are made, the connection is closed.
Syntax: http2_max_requests number;
Default:
http2_max_requests 1000;
Context: http, server
This directive appeared in version 1.11.6.
Sets the maximum number of requests (including push requests) that can be served through one HTTP/2 connection, after which the next client request will lead to connection closing and the need of establishing a new connection.
```
  当长连接超过keepalive_timeout时间段没有收到客户端请求，或者单个长连接最大收到keepalive_requests个请求，Nginx会关闭连接。http2_max_requests用于配置HTTP2协议下，每个长连接最大处理的请求数。
  Go语言只有IdleConnTimeout可以配置空闲长连接超时时间，没有类似Nginx配置keepalive_requests可以限制请求数。所以，我们生产环境就遇到了，无论怎么配置，总是会出现偶发的"connection reset by peer"。
  那怎么办？眼睁睁的看着HTTP请求异常？Go语言目前有这几个措施应对连接关闭情况：1）底层检测连接关闭事件，标记连接不可用；2）HTTP请求出现传输错误等情况时，对部分请求进行重试，注意重试请求是有条件的，比如：GET请求可以重试，或者请求头中出现{X-,}Idempotency-Key也可以重试。
```
+Transport.roundTrip
+persistConn.shouldRetryRequest
+RequestisReplayable
func (r *Request) isReplayable() bool {
if r.Body == nil || r.Body == NoBody || r.GetBody != nil {
switch valueOrDefault(r.Method, "GET") {
case "GET", "HEAD", "OPTIONS", "TRACE":
return true
}
if r.Header.has("Idempotency-Key") || r.Header.has("X-Idempotency-Key") {
return true
}
}
return false
}
```
  所以，如果你是GET请求，没问题Go语言底层在遇到RST情况，会自动帮你重试。但是如果是POST请求呢，如果你确信你的请求是幂等性的，或者可以接受重试导致提交两次的的风险，可以通过添加header使得Go语言帮你自动重试。或者，如果你的业务量较小，不考虑性能的话，使用短链接也能避免。
## 总结
  http.Client的使用相对比较简单，不过其底层连接池问题还是要多多注意，另外还有使用长连接可能出现的"connection reset by peer"情况。关于http.Client就介绍到这里，当然本篇文章只摘抄除了部分代码，整个流程的详细代码还需要你自己多研读学习。
有疑问加站长微信联系（非本文作者））
