新观点超极速化：网络开发中的请求合并！

2022-7-13 15:40| 发布者: msmkmm2012| 查看: 63| 评论: 0

摘要: 今天，来分享络开发中的一个超级技巧。它可以把两个请求合并为一个请求，使得服务在弱环境中性能得到极大的改善。加速器的相关问题可以到网站了解下，我们是业内领域专业的平台，您如果有需要可以咨询，相信可以帮到 ...

今天，来分享络开发中的一个超级技巧。它可以把两个请求合并为一个请求，使得服务在弱环境中性能得到极大的改善。加速器的相关问题可以到网站了解下，我们是业内领域专业的平台，您如果有需要可以咨询，相信可以帮到您，值得您的信赖！https://www.tiandiapp.com/

说开了很容易，但却很难想到。

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

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

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

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

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

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

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

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

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

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

请求黏贴其，我们参考TCP的次握手就可以了。TCP的握手和挥手流程都差不多，但为什么握手是次，但挥手是四次呢?

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

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

比如，原来的请求是。

一、获取: T: { "": "12345"}二、提交请求: O{ "": "12345", "": {}}:{ "": 200}合并后的请求是。

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

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

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

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

作者简介：小姐姐味道
()，一个不允许程序员走弯路的。聚焦基础架构和L。十年架构，日百亿流量，与你探讨高并发世界，给你不一样的味道。