http ,怎么优雅的拒绝你

f608dc4b8fcd14a852cc69615855db36.gif

作者 | 奇伢

来源 | 奇伢云存储

9a16ade5363469f133cdc64440a855e4.png

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

2ba08f96aeb6776d2b36cbafef8c683e.png

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

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

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

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

 2   第二,什么叫做优雅的拒绝?

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

最常见的异常

  • 客户端发数据的时候,发现连接已经不在,那么就会导致服务端发送 Reset 包给客户端。客户端的感知就会出现 write broken,connection close by peer 等等异常。

  • 服务端收数据的时候,还没收够呢,就读到 EOF,这种体现的就是 Unexpected EOF ;

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

988e7e70a1a2524706a39333409c536b.png

简单复习 HTTP

cedaeb90a04f1f80799db3c45de94b80.png

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

  • 客户端发完之后,服务端才能响应。

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

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

d04cb3e261c32305ee6328fb94ca8e10.png

简单复习 S3 协议

5efbef38bd96b48096e70867671651a6.png

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

68f602574cefcfe9f6d87b2e9d558ebb.png

怎么解决呢?

d1ee581bb97f8f0a2b072bd1a61912f4.png

服务端确实是不能再接收数据了,鉴权都不过,说明是非法请求。这种情况下,如果服务端还要接收完 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 协议层来解决这个问题。

ccd1a04f0118499b3317a47926038f4d.png

但, 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 秒 ;

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

5b049adf2a09a170dfc66b00ec6e7511.png

来看看 nginx 的实现

5ddb9ae604bb9a067b420519504efca2.png

最后以 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 自己不至于太大的压力。

91d60da878e4a39f024070a20c551470.png

总结

45ed452c18fd0c5ec2f0e86f248f5ace.png

  1. 当服务端并不想接收客户端的 body (浪费资源和时间),如果直接回复 response 并且关闭连接会导致客户端收到 reset 错误。这不优雅;

  2. 优雅的方式有三种,可以通过 socket linger close,http 100-continue ,业务自己读完 这三种办法来处理;

  3. socket 依赖于操作系统的特性,http 100-continue 有利有弊(多了一次交互并且依赖于服务端的实现),业务自己处理才是最通用的做法;

  4. 业务读数据虽然通用,但是处理的时间和处理的数据量必须要慎重考量,保命要紧,防止服务端被打爆;

c269bf85fadb102fef36c77c05d26b89.gif

往期推荐

read 文件一个字节实际会发生多大的磁盘IO?

如何优雅保护 Kubernetes 中的 Secrets

Redis 内存满了怎么办?这样置才正确!

云原生的本手、妙手和俗手

85eb052b2b7c6888a82870bafb351249.gif

点分享

ca0de338b2eeb73a63ad30367ccb3b93.gif

点收藏

65a952bcfc56cfb77fb6e352639159bd.gif

点点赞

82190c41065e6cda37005cfaaa191849.gif

点在看

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值