云存储揭秘｜http ，怎么优雅的拒绝你

坚持思考，就会很酷

典型问题：服务端优雅的拒绝

今天分享一个后端编程的实际经验。这个问题来源于对象 S3 后端协议实现的技巧思考。场景：服务端不想接收 http 的 body 的时候，该怎么优雅的拒绝呢？

什么意思？对上面的场景，首先解释几个前置的事情。

1 第一，为什么会出现服务端不想接收客户端的 body ？

这个太正常了。S3 服务的鉴权可以放在 header 里，数据放在 body 里。如果客户端的参数鉴权不过，或者参数非法。这种的请求服务端根本不想多看 body 一眼。

2 第二，什么叫做优雅的拒绝？

优雅指的是，客户端发请求数据的过程不会有任何异常，服务端回响应的过程也不会有任何异常。

最常见的异常：

• 客户端发数据的时候，发现连接已经不在，那么就会导致服务端发送 Reset 包给客户端。客户端的感知就会出现 write broken，connection close by peer 等等异常。
• 服务端收数据的时候，还没收够呢，就读到 EOF，这种体现的就是 Unexpected EOF ；

第一种一般是服务端提前关闭连接导致，第二种一般是客户端提前关闭导致。我们今天聊第一种。

简单复习 HTTP

http 是基于 TCP 之上的应用层协议。客户端发个 request ，然后服务端回个 response 。request 和 response 由 header + body 组成，一来一回的响应，必须是串行的，要有严格的时序关系，才能保证优雅。

• 客户端发完之后，服务端才能响应。
• 服务端响应发完之后，客户端才能走开。

否则就会在 TCP 层出现 Reset 包，应用层就会看到 write broken，connection reset by peer 等等等报错。

简单复习 S3 协议

S3 的协议是对象存储协议，上传的时候数据在 body 里，鉴权在 url、header、 body 里。http 协议发包的时候，正常情况 header 和 body 可能是同一批发过去的。也就是说，服务端网络栈收到 reqeust 的 header 的时候，body 已经收到部分数据（或者全部）。这个时候客户端可能是处在一个 write 数据的过程，此时服务端如果直接断开，那么就会导致客户端 write 异常。那怎么处理才能优雅的度过呢？

怎么解决呢？

服务端确实是不能再接收数据了，鉴权都不过，说明是非法请求。这种情况下，如果服务端还要接收完 body 的数据，这不是纯粹的给自己压力嘛。但是服务端直接断开连接却是和客户端理解不一致的，因为客户端的 body 已经在路上了。这种情况下 100% 是会收到 Reset 报错的。

怎么办才好呢？

按照不同的层次，有三种解决方案：

1. TCP 层（ socket ）能解决 ：使用 linger close 的特性
2. http 协议层解决：使用 100 continue 特性
3. 业务层自己解决：比如 S3 服务端，自己掏空 body ，再断开连接

1 linger close

Linux 操作系统就提供了一个叫做延迟关闭的特性。当调用 close() 来关闭一个 TCP 连接的时候，如果 socket fd 设置了 linger close 的特性，那么这条 TCP 连接并不会立即关闭连接，内核会延迟一段时间。会继续读 TCP 连接里的数据，直到读完或者超时时间到了之后。

这样保证客户端传完数据， socket 再 close 就能优雅退出了。

struct linger st_linger；

setsockopt(fd, SOL_SOCKET, SO_LINGER, (void *)&st_linger, &sizeof(st_linger));

2 100 continue

http 协议为什么会出现不协调的根因在于：服务端可能不需要 body，但是客户端发的 body 已经在路上了。

所以 http 解决这个问题也很简单，就是在发送 body 之前，再加一个协商的确认，服务端确认会处理这个 body，客户端才发送。这样就不存在 body 发送了又被拒绝的问题了。

这个是在 http 协议层来解决这个问题。

但， 100-continue 有两个局限性：

1. 小请求会带来很大的开销，之前只需要交互 1 次即可。加入了 100-continue 机制，那么一定会放大成 2 次。开销翻倍。
2. 并不是所有的 server 支持 100-continue 协议，这个对服务端来说是非强制的。

3 业务自己解决

如果不考虑 socket 层和 http 层的解决方案，需要业务自己解决的话（比如 S3 服务端），该怎么办呢？

原理很简单：数据你可以不存，但是不能不读。

客户端只要有在发送数据，那么服务端就读，读完为止，然后再回复响应。这样就不会有任何问题。

服务端自己实现，就算要关闭连接，那也要把 TCP 的数据读完，读干净之后，再把连接关闭掉。这读来的数据，服务端不需要就 discard 掉即可。这样就不会有任何异常发生了。

_, err := io.CopyN(ioutil.Discard, w.reqBody, maxPostHandlerReadBytes+1)

这个其实才是最通用的解决方案，但要考量几个因素：

1. 难道客户端发 10G 的数据在路上，我也要读完？
2. 难道客户端发 24 个小时都发不完的数据，我也要读完？

这两个是服务端必须要考量的因素，消耗的网络资源能否抗住？长时间占用的无效资源能否抗住？

一般情况下，服务端是不能允许这种不确定的因素发生的。所以会加入两个约束：

1. 读的数据量有约束，比如不超过 1M ；
2. 读的时间有约束，比如不超过 30 秒 ；

超过的话，我建议就不管优雅不优雅了，服务端保命要紧。

来看看 nginx 的实现

最后以 nginx 的实现来做一个对比参考。nginx 是现在功能最强大的 http 的代理实现，它对各种异常场景其实都有考量。针对这种服务端优雅关闭连接它有一个 linger close 的特性。

注意：这个并不是使用操作系统 socket 的 linger close ，而是 nginx 自己实现的，nginx 自己掏的数据。lingering_close 有三个选项。

// 默认行为。试着读完剩余的数据。
lingering_close on

// 不管三七二十一，总是要掏空连接的数据
lingering_close always

// 关闭延迟关闭的特性
lingering_close off

还有另外两个跟时间相关的开关：

• lingering_time ：请求关闭的时间超过一个阈值，那么无论还有没有数据，都要关闭；
• lingering_timeout ：一段时间内，一点数据都没有？那关闭连接；

以上就是 nginx 处理这种服务端关闭连接的姿势。通过开关 lingering 的配置让客户端感知友好，通过配置 timeout 时间让 nginx 自己不至于太大的压力。

总结

1. 当服务端并不想接收客户端的 body （浪费资源和时间），如果直接回复 response 并且关闭连接会导致客户端收到 reset 错误。这不优雅；
2. 优雅的方式有三种，可以通过 socket linger close，http 100-continue ，业务自己读完 这三种办法来处理；
3. socket 依赖于操作系统的特性，http 100-continue 有利有弊（多了一次交互并且依赖于服务端的实现），业务自己处理才是最通用的做法；
4. 业务读数据虽然通用，但是处理的时间和处理的数据量必须要慎重考量，保命要紧，防止服务端被打爆；