西安一码通到底是通过后端下发图片的吗？新笑话：CPU转速过高导致内存溢出？

关注DD，前沿技术早知道，弯道超车有希望

昨天分享的《难道这就是“西安一码通”再次崩溃的真实原因？》收到了很多留言，群里也是各种吐槽。怎么会通过服务端生成图片下发呢？Low的不行！

今天小编也收到群友说这个事情辟谣了。这个怎么说呢，其实昨天文章中小编也说了这个只是猜测嘛。同时，在发布了一段时间之后，知乎上的这个帖子也是很热，马上就有其他答主通过截包等方式对此一探究竟，我们也是第一时间在前文的留言中放了相关链接，感兴趣的小伙伴可以点击查看。

今天小编看到有另一位网友的分析更加到位，所以拿出来分享一下，一起看看深度分析的结果是怎么样的。

知友“卢兴民”的回答中提供了刷新二维码接口的返回数据（下图），确实很正常，并没有太大的问题。

答主也表示：确实没有low到服务器生成图片进行下发这么蠢。虽然这个接口没有问题，但是分析过程中，答主发现，对于静态资源的访问还是存在较大的隐患。

问题主要问题集中在所有的js/css/img这些静态资源全都从从一个出口进行提供，没上CDN

粗略估算了一下，js/css/img数据总共约500kB，按照从某个群里得到的数据，暂且认为是准的，健康码的请求量峰值达到了3.3w qps

那按照这个量估计 33000 x 500 x 8 bps ≈ 125Gbps 这个出口量级很难用单机房承载，峰值一来，出口网卡打满，直接gg。

到写这个回答时（ 2022-01-05 20:17），西安健康码还是没有将静态资源上CDN，之后看看访问量再起飞的时候，能不能扛得住吧。

深度分析的分享就到这里，最后分享几个今天把小编笑哭的图：

tinypng是指的这个网站：https://tinypng.com/，小编也是这个网站的用户。因为他提供了极强的图片压缩能力。太狠了，没几个字，却秒杀了昨天这段美文：

中午的时候，群里有小伙伴发了下面这个图：

看样子是说：CPU转速过快，导致内存溢出...这个就不用解释了...相信你已经开始笑了。不过这个消息据网友留言反馈是电视剧输赢的片段。不然的，那真的应了下面这位网友的评论：

好了，吃瓜归吃瓜，开头的分析还是很到位的，希望大家也能学习答主探究事情本源的精神。

也希望西安的疫情可以快速好起来，马上春节了，疫情以来，不少小伙伴没回家过年了吧，今年一定要安安心心过个好年啊！