共计 1731 个字符,预计需要花费 5 分钟才能阅读完成。
导读 | 如果我有大量的物联网设备,比如说 100 万台。如果这些设备平均每 10 秒产生一个请求,那么 QPS 就是 10W,这对于任何公司来说都是一个不小的规模了。 |
今天,xjjdog 来分享网络开发中的一个超级技巧。它可以把两个请求合并为一个请求,使得服务在弱网环境中性能得到极大的改善。
说开了很容易,但却很难想到。
如果我有大量的物联网设备,比如说 100 万台。如果这些设备平均每 10 秒产生一个请求,那么 QPS 就是 10W,这对于任何公司来说都是一个不小的规模了。
涉及到交易等有变更的需求,为了实现幂等操作,通常会提前申请一个交易号 (或者说 token),来进行唯一的交易请求。
这样,完成一个交易,需要至少发起两个请求。一个是申请 token,一个是拿着 token 做交易。
虽然说生成 token 很快,但它是从网络上传输的。且不说现在都是异步模型,就拿网络延迟来说,就是一个大的问题。它可能硬生生的把服务质量给降了下去,增加了不确定性,也增加了编码的复杂性。
有什么办法来加快这个过程吗?
大多数人都知道,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 两个报文,合并成一个返回了。
我们可以把 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 个请求,完成我们的优化目标。
在网络编程中,减少网络交互是一个非常重要的优化,尤其是在弱网环境中。虽然这个技巧很简单,但它很难被想到。优化效果也是巨大的,毕竟减少了一次网络交互。
它有一个响亮的名字,那就是三连环。意味着前后请求的衔接,永不断环。
作者简介:小姐姐味道 (xjjdog),一个不允许程序员走弯路的公众号。聚焦基础架构和 Linux。十年架构,日百亿流量,与你探讨高并发世界,给你不一样的味道。
![post-qrcode](https://www.xgss.net/wp-content/uploads/2023/07/二维码-微信公众号256x256.jpg)