找兼职h5网站开发人员,怎样推广自己的视频号,海阳市城建设局网站,下列关于网站开发网页上传作者 | 奇伢来源 | 奇伢云存储典型问题#xff1a;服务端优雅的拒绝今天分享一个后端编程的实际经验。这个问题来源于对象 S3 后端协议实现的技巧思考。场景#xff1a;服务端不想接收 http 的 body 的时候#xff0c;该怎么优雅的拒绝呢#xff1f;什么意思#xff1f;对… 作者 | 奇伢来源 | 奇伢云存储典型问题服务端优雅的拒绝今天分享一个后端编程的实际经验。这个问题来源于对象 S3 后端协议实现的技巧思考。场景服务端不想接收 http 的 body 的时候该怎么优雅的拒绝呢什么意思对上面的场景首先解释几个前置的事情。 1   第一为什么会出现服务端不想接收客户端的 body 这个太正常了。S3 服务的鉴权可以放在 header 里数据放在 body 里。如果客户端的参数鉴权不过或者参数非法。这种的请求服务端根本不想多看 body 一眼。 2   第二什么叫做优雅的拒绝优雅指的是客户端发请求数据的过程不会有任何异常服务端回响应的过程也不会有任何异常。最常见的异常客户端发数据的时候发现连接已经不在那么就会导致服务端发送 Reset 包给客户端。客户端的感知就会出现 write brokenconnection close by peer 等等异常。服务端收数据的时候还没收够呢就读到 EOF这种体现的就是 Unexpected EOF 第一种一般是服务端提前关闭连接导致第二种一般是客户端提前关闭导致。我们今天聊第一种。简单复习 HTTPhttp 是基于 TCP 之上的应用层协议。客户端发个 request 然后服务端回个 response 。request 和 response 由 header body 组成一来一回的响应必须是串行的要有严格的时序关系才能保证优雅。客户端发完之后服务端才能响应。服务端响应发完之后客户端才能走开。否则就会在 TCP 层出现 Reset 包应用层就会看到 write brokenconnection reset by peer 等等等报错。简单复习 S3 协议S3 的协议是对象存储协议上传的时候数据在 body 里鉴权在 url、header、 body 里。http 协议发包的时候正常情况 header 和 body 可能是同一批发过去的。也就是说服务端网络栈收到 reqeust 的 header 的时候body 已经收到部分数据或者全部。这个时候客户端可能是处在一个 write 数据的过程此时服务端如果直接断开那么就会导致客户端 write 异常。那怎么处理才能优雅的度过呢怎么解决呢服务端确实是不能再接收数据了鉴权都不过说明是非法请求。这种情况下如果服务端还要接收完 body 的数据这不是纯粹的给自己压力嘛。但是服务端直接断开连接却是和客户端理解不一致的因为客户端的 body 已经在路上了。这种情况下 100% 是会收到 Reset 报错的。怎么办才好呢按照不同的层次有三种解决方案TCP 层 socket 能解决 使用 linger close 的特性http 协议层解决使用 100 continue 特性业务层自己解决比如 S3 服务端自己掏空 body 再断开连接 1   linger closeLinux 操作系统就提供了一个叫做延迟关闭的特性。当调用 close() 来关闭一个 TCP 连接的时候如果 socket fd 设置了 linger close 的特性那么这条 TCP 连接并不会立即关闭连接内核会延迟一段时间。会继续读 TCP 连接里的数据直到读完或者超时时间到了之后。这样保证客户端传完数据 socket 再 close 就能优雅退出了。struct linger st_lingersetsockopt(fd, SOL_SOCKET, SO_LINGER, (void *)st_linger, sizeof(st_linger)); 2   100 continuehttp 协议为什么会出现不协调的根因在于服务端可能不需要 body但是客户端发的 body 已经在路上了。所以 http 解决这个问题也很简单就是在发送 body 之前再加一个协商的确认服务端确认会处理这个 body客户端才发送。这样就不存在 body 发送了又被拒绝的问题了。这个是在 http 协议层来解决这个问题。但 100-continue 有两个局限性小请求会带来很大的开销之前只需要交互 1 次即可。加入了 100-continue 机制那么一定会放大成 2 次。开销翻倍。并不是所有的 server 支持 100-continue 协议这个对服务端来说是非强制的。 3   业务自己解决如果不考虑 socket 层和 http 层的解决方案需要业务自己解决的话比如 S3 服务端该怎么办呢原理很简单数据你可以不存但是不能不读。客户端只要有在发送数据那么服务端就读读完为止然后再回复响应。这样就不会有任何问题。服务端自己实现就算要关闭连接那也要把 TCP 的数据读完读干净之后再把连接关闭掉。这读来的数据服务端不需要就 discard 掉即可。这样就不会有任何异常发生了。_, err : io.CopyN(ioutil.Discard, w.reqBody, maxPostHandlerReadBytes1)这个其实才是最通用的解决方案但要考量几个因素难道客户端发 10G 的数据在路上我也要读完难道客户端发 24 个小时都发不完的数据我也要读完这两个是服务端必须要考量的因素消耗的网络资源能否抗住长时间占用的无效资源能否抗住一般情况下服务端是不能允许这种不确定的因素发生的。所以会加入两个约束读的数据量有约束比如不超过 1M  读的时间有约束比如不超过 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 自己不至于太大的压力。总结当服务端并不想接收客户端的 body 浪费资源和时间如果直接回复 response 并且关闭连接会导致客户端收到 reset 错误。这不优雅优雅的方式有三种可以通过 socket linger closehttp 100-continue 业务自己读完 这三种办法来处理socket 依赖于操作系统的特性http 100-continue 有利有弊多了一次交互并且依赖于服务端的实现业务自己处理才是最通用的做法业务读数据虽然通用但是处理的时间和处理的数据量必须要慎重考量保命要紧防止服务端被打爆往期推荐read 文件一个字节实际会发生多大的磁盘IO如何优雅保护 Kubernetes 中的 SecretsRedis 内存满了怎么办这样置才正确云原生的本手、妙手和俗手点分享点收藏点点赞点在看