性能文章>超极速优化:网络开发中的请求合并!>

超极速优化:网络开发中的请求合并!原创

262823

导语

今天,xjjdog来分享网络开发中的一个超级技巧。它可以把两个请求合并为一个请求,使得服务在弱网环境中性能得到极大的改善。说开了很容易,但却很难想到。

 

正文

需求

如果我有大量的物联网设备,比如说100万台。如果这些设备平均每10秒产生一个请求,那么QPS就是10W,这对于任何公司来说都是一个不小的规模了。

涉及到交易等有变更的需求,为了实现幂等操作,通常会提前申请一个交易号(或者说token),来进行唯一的交易请求。

这样,完成一个交易,需要至少发起两个请求。一个是申请token,一个是拿着token做交易。

虽然说生成token很快,但它是从网络上传输的。且不说现在都是异步模型,就拿网络延迟来说,就是一个大的问题。它可能硬生生的把服务质量给降了下去,增加了不确定性,也增加了编码的复杂性。

有什么办法来加快这个过程吗?

从HTTP中学习经验

大多数人都知道,TCP有三次握手和四次挥手的机制。这种冗长的对话虽然保证了连接的可靠性,但却损失了不少性能。HTTP从一到三各个版本,都是在尽量减少HTTP连接的个数,也在减少交互的次数。

在比较早的HTTP1.0实现中,如果需要从服务端获取大量资源,会开启N条TCP短链接,并行的获取信息。但由于TCP的三次握手和四次挥手机制,在连接数量增加的时候,整体的代价就变得比较大

在HTTP/1.1中,通过复用长连接,来改善这个情况,但问题是,由于TCP的消息确认机制和顺序机制以及流量控制策略的原因,资源获取必须要排队使用。一个请求,需要等待另外一个请求传输完毕,才能开始

HTTP/2采用多路复用,多个资源可以共用一个连接。但它解决的只是应用层的复用,在TCP的传输上依然是阻塞的,后面的资源需要等待前面的传输完毕才能继续。这就是队头阻塞现象(Head-of-line blocking)

QUIC,也就是HTTP3,抽象出了一个stream(流)的概念,多个流,可以复用一条连接,那么滑动窗口这些概念就不用作用在连接上了,而是作用在stream上。由于UDP只管发送不管成功与否的特性,这些数据包的传输就能够并发执行。协议的server端,会解析并缓存这些数据包,进行组装和整理等。由于抽象出了stream的概念,就使得某个数据包传输失败,只会影响单个stream的准确性,而不是整个连接的准确性。

请求黏贴

其实,我们参考TCP的三次握手就可以了。TCP的握手和挥手流程都差不多,但为什么握手是三次,但挥手是四次呢?

原因就是TCP把SYN和ACK两个报文,合并成一个返回了。

563F3A06-DB6F-4682-9548-1DFF163329AC.png


我们可以把token看作是序列号,然后把它黏贴在正常的请求里返回就可以了。

比如,原来的请求是。

一、获取token

request: /getToken
response: 
{
    "token": "12345"
}


二、提交请求

request: /postOrder
{
    "token": "12345",
    "other": {}
}

response:
{
    "status": 200
}


合并后的请求是。

request: /postOrder
{
    "token": "12345",
    "other": {}
}

response:
{
    "status": 200,
    "token": "12346"
}


只需要在每次请求返回的时候,不论成功还是失败,都附加一个新的token到客户端。客户端缓存这个token,然后发起下个请求。

通过这个方法,就可以把两个请求合并为1个请求,完成我们的优化目标。

End

在网络编程中,减少网络交互是一个非常重要的优化,尤其是在弱网环境中。虽然这个技巧很简单,但它很难被想到。优化效果也是巨大的,毕竟减少了一次网络交互。

5411AADF-407A-4DD6-8CA8-07E32270F1E4.png


它有一个响亮的名字,那就是三连环。意味着前后请求的衔接,永不断环。

 

💥看到这里的你,如果对于我写的内容很感兴趣,有任何疑问,欢迎在下面留言📥,会第一次时间给大家解答,谢谢!

 

作者简介:小姐姐味道  (xjjdog),一个不允许程序员走弯路的公众号。聚焦基础架构和Linux。十年架构,日百亿流量,与你探讨高并发世界,给你不一样的味道。我的个人微信xjjdog0,欢迎添加好友,进一步交流。

请先登录,查看2条精彩评论吧
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

使用虚线程进行同步网络 IO 的不阻塞原理
使用虚线程进行网络 IOProject Loom 主要目标是在 Java 平台上提供一种易于使用、高吞吐量的轻量级并发性和新的编程模型的 JVM 特性和API。这带来了许多有趣和令人兴奋的前景,其中之
分享一次排查CLOSE_WAIT过多的经验
作者:踩刀诗人原文链接:https://www.cnblogs.com/chopper-poet/p/14618391.html 问题背景某日下午有测试人员急匆匆的跑来跟我反馈:“有客户反馈供应商附件
面试官问我:什么是高并发下的请求合并?
我重新给个我觉得合理的场景,告诉大家我理解的请求合并和高并发下的请求合并是什么玩意。
一次 HTTP/2 通信失败的问题分析
背景某业务上线 HTTP/2 以后,通过 curl 访问某接口一直失败。开发人员怀疑可能是运维的 HTTP/2 配置不当导致访问失败,但是同样是配置 HTTP/2 的其它域名却是正常的,于是来一起看了一下这个问题。
Redis 突然变慢了如何排查并解决?
Redis 通常是我们业务系统中一个重要的组件,比如:缓存、账号登录信息、排行榜等。一旦 Redis 请求延迟增加,可能就会导致业务系统“雪崩”。我在单身红娘婚恋类型互联网公司工作,在双十一推出下单就送女朋友的活动。谁曾想,凌晨 12 点之后,用户量暴增,出现了
一次 Redis Unexpected end of stream 的除错分析记录
搬运一篇早期的文章这几天线上出现了偶发性jedis的异常,堆栈如下redis.clients.jedis.exceptions.JedisConnectionException: Unexpected end of stream. at redis.clients.util
Kube-OVN:容器网络性能的自我救赎
本文围绕着打造Kube-OVN的过程中的网络性能问题展开,详细阐述了Kube-OVN怎样进行性能瓶颈分析、怎样设置性能优化测试思路,测试过程,以及令人较为满意的测试结果。在性能“自救”的同时,
WebSocket 原理和可能遇到的性能问题
 📢 大家好,我是法医,不是验尸的法医,而是写代码的法医,哈哈😅相信大家都听到过`HTTP协议`、`TCP协议`、`UDP协议`,还有那啥`离婚协议`等等很多协议,这都是一些既熟悉又陌生的词,很多小伙伴不理解这些协议到底是干嘛的?不用这协议行不行?其它协议还好说,这离婚协议我还是希