开启 Keep-Alive 可能会导致http 请求偶发失败

大家好，我是蓝胖子，说起提高http的传输效率，很多人会开启http的Keep-Alive选项，这会http请求能够复用tcp连接，节省了握手的开销。但开启Keep-Alive真的没有问题吗？我们来细细分析下。

最大空闲时间造成请求失败

通常我们开启Keep-Alive后 ，服务端还会设置连接的最大空闲时间，这样能保证在没有请求发生时，及时释放连接，不会让过多的tcp连接白白占用机器资源。

问题就出现在服务端主动关闭空闲连接这个地方，试想一下这个场景，客户端复用了一个空闲连接发送http请求，但此时服务端正好检测到这个连接超过了配置的连接最大空闲时间，在请求到达前，提前关闭了空闲连接，这样就会导致客户端此次的请求失败。

过程如下图所示，

如何避免此类问题

上述问题在理论上的确是一直存在的，但是我们可以针对发送http请求的代码做一些加强，来尽量避免此类问题。来看看在Golang中，http client客户端是如何尽量做到安全的http重试的。

go http client 是如何做到安全重试请求的？

在golang中，在发送一次http请求后，如果发现请求失败，会通过shouldRetryRequest 函数判断此次请求是否应该被重试，代码如下，

func (pc *persistConn) shouldRetryRequest(req *Request, err error) bool {  if http2isNoCachedConnError(err) {  // Issue 16582: if the user started a bunch of  // requests at once, they can all pick the same conn       // and violate the server's max concurrent streams.       // Instead, match the HTTP/1 behavior for now and dial       // again to get a new TCP connection, rather than failing       // this request.      return true  }  if err == errMissingHost {  // User error.  return false  }  if !pc.isReused() {  // This was a fresh connection. There's no reason the server  // should've hung up on us.       //       // Also, if we retried now, we could loop forever       // creating new connections and retrying if the server       // is just hanging up on us because it doesn't like       // our request (as opposed to sending an error).       return false  }  if _, ok := err.(nothingWrittenError); ok {  // We never wrote anything, so it's safe to retry, if there's no body or we  // can "rewind" the body with GetBody.      return req.outgoingLength() == 0 || req.GetBody != nil  }  if !req.isReplayable() {  // Don't retry non-idempotent requests.  return false  }  if _, ok := err.(transportReadFromServerError); ok {  // We got some non-EOF net.Conn.Read failure reading  // the 1st response byte from the server.       return true  }  if err == errServerClosedIdle {  // The server replied with io.EOF while we were trying to  // read the response. Probably an unfortunately keep-alive       // timeout, just as the client was writing a request.       return true  }  return false // conservatively  
}

我们来挨个看看每个判断逻辑，

http2isNoCachedConnError 是关于http2的判断逻辑，这部分逻辑我们先不管。

err == errMissingHost 这是由于请求路径中缺少请求的域名或ip信息，这种情况不需要重试。

pc.isReused() 这个是在判断此次请求的连接是不是属于连接复用情况，因为如果是新创建的连接，服务器正常情况下是没有理由拒绝我们的请求，此时如果请求失败了，则新建连接就好，不需要重试。

if _, ok := err.(nothingWrittenError); ok 这是在判断此次的请求失败的时候是不是还没有向对端服务器写入任何字节，如果没有写入任何字节，并且请求的body是空的，或者有body但是能通过req.GetBody 恢复body就能进行重试。

📢📢注意，因为在真正向连接写入请求头和body时，golang其实是构建了一个bufio.Writer 去封装了连接对象，数据是先写到了bufio.Writer 缓冲区中，所以有可能出现请求体Request已经读取了部分body，写入到缓冲区中，但实际真正向连接写入数据时失败的场景，这种情况重试就需要恢复原先的body，重试请求时，从头读取body数据。

req.isReplayable() 则是从请求体中判断这个请求是否能够被重试，如果不满足重试要求，则直接不重试，满足重试要求则会继续进行下面的重试判断。 其代码如下，如果http的请求body为空，或者有GetBody 方法能为其恢复body，并且是"GET", “HEAD”, “OPTIONS”, “TRACE” 方法之一则认为该请求重试是安全的。

还有种情况是如果http请求头中有Idempotency-Key 或者X-Idempotency-Key 也认为重试是安全的。

X-Idempotency-Key 和 Idempotency-Key 其实是为了给post请求的重试给了一个后门，对应的key是由业务方自己定义的具有幂等性质的key，服务端可以拿到它做幂等性校验，所以重试是安全的。

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  }  // The Idempotency-Key, while non-standard, is widely used to  // mean a POST or other request is idempotent. See       // https://golang.org/issue/19943#issuecomment-421092421       if r.Header.has("Idempotency-Key") || r.Header.has("X-Idempotency-Key") {  return true  }  }  return false  
}

只有认为请求重试是安全后，才会进一步判断请求失败 是不是由于服务端关闭空闲连接造成的 _, ok := err.(transportReadFromServerError) 和 errServerClosedIdle都是由于服务端关闭空闲连接造成的错误码，如果产生的错误码是其中之一，则都是允许被重试的。

🍉🍉🍉所以，综上你可以看出，如果你发的请求是一个不带有Idempotency-Key或者X-Idempotency-Keypost请求头的post请求，那么即使是由于服务器关闭空闲连接造成请求失败，该post请求是不会被重试的。不过在其他请求方法比如GET方法下，由服务器关闭空闲连接造成的请求错误，Golang 能自动重试。

最佳实践

针对上述场景，我们应该如何设计我们的请求发送来保证安全可靠的发送http请求呢？针对于Golang开发环境，我总结几点经验，

1，GET请求可以自动重试，如果你的接口没有完全准寻restful 风格，GET请求的处理方法仍然有修改数据的操作，那么你应该保证你的接口是幂等的。

2，POST请求不会自动重试，但是如果你需要让你的操作百分百的成功，请添加失败重试逻辑，同样，服务端最好做好幂等操作。

3，如果对性能要求不是那么高，那么直接关闭掉http的长链接，将请求头的Connection 字段设置为close 这样每次发送发送http请求时都是用的新的连接，不会存在潜在的服务端关闭空闲连接造成请求失败的问题。

4，第四点，其实你可以发现，网络请求，不管你的网络情况是否好坏，都是存在失败的可能，即使将http长连接关掉，在网络坏的情况下，请求还是会失败，失败了要想保证成功，就得重试，重试就一定得保证服务端接口幂等了，所以，你的接口如果是幂等的，你的请求如果具有重试逻辑，那么恭喜你，你的系统十分可靠。

5，最后一点，千万不要抱着侥幸心理去看待网络请求，正如第四点说的那样，不管你的网络情况是否好坏，都是存在失败的可能。嗯，面对异常编程。