Golang http response 解压缩分析

Golang自带的 http 标准库一直是自己的首选http library,最主要的原因是对标准的细节支持非常到位,兼容性优秀。

前几天遇到一个问题一直没时间处理,晚上花了挺多时间排查,落实到代码上其实也就一行的修改量,但是对于有段时间没有读标准库代码的自己来说倒是值得记录一下。

问题

使用标准库进行 http 请求时,如果在请求 header 中手动设置了 Accept-Encoding, 那么返回的响应内容看起来是乱码(其实是二进制)。

原因

定位的过程其实挺曲折的,分析抓包的时候对比了多个请求数据,最终才确认是header 中的 Accept-Encoding 导致。而这个细节之前在 http.Transport 的 DisableCompression 字段是有文档说明的:

也就是说:

  • 如果设置 DisableCompressiontrue 并且请求中没有设置 Accept-Encoding 的情况下,那么将发送要求服务器返回非压缩的请求;如果 DisableCompressionfalse (默认值), 则会发送允许服务器返回压缩内容的请求,并且会在 transport 层自动把 response 内容解压返回到业务层。这一点很容易理解,屏蔽了解压读取压缩内容细节,使用起来也非常方便。这也是我对golang http 标准库的理解,很多东西都自动处理了。我遇到的问题在于下面说的第二点。
  • 如果用户手动在请求中设置了 Accept-Encoding, 那么标准库会认为业务层是想自己接管 response 内容的处理,因此会返回原始的未解压的内容。也就是上面问题里面提到的乱码数据。

这段话看起来比较绕,我们直接看一下 transport.go 相关代码。

发起请求时,DisableCompressionfalse 且业务层没有设置 Accept-Encoding 的情况下,自动设置header:

读取 response 时,解压内容:

小结

很多问题其实都是魔鬼在细节中,本质上还是基础文档没有仔细阅读。不过找问题的晚上其实也挺开心的,因为通过配置好的 github Copilot 来写代码,整个过程真的非常愉悦。最开始自己还会写几个关键字,引导 Copilot 给出提示代码,后面索性回车就开始等待 Copilot 帮我写代码,跟自己编写代码匹配度能到 80% 以上。目前已知的不足是在 string 的内容推导上有时候不太准确(事实上,人工编码的时候,这部分也容易出现typo或者其他错误),因此要注意这部分代码的review.

这些年参加过的双11

今年双11在波澜不惊上落下帷幕,这个周末是难得的一个修整机会。百无聊赖之中,对自己参加过的几次双11简单总结。

加上今年双十一,已经参加了三次现场双11。对于普通用户来说,每年的基本盘都是 买买买 ,但对于自己来说,每年的感受却不尽相同。

第一次参加双十一技术支撑保障是2018年。作为还没有转正的新同学,第一次进入作战室的时候更多是新鲜感和第一次亲临现场的兴奋。然而,没想到等待自己的却是各种万丈深渊旁的如履薄冰,如同那年成都伸手不见五指的雾霾,一路战战兢兢,磕磕绊绊完成了任务。好在当时一起搭档的同学非常给力,把现场的问题都快速解决。

事后复盘,数据链路年久失修+系统架构设计太多trck和临时方案是症结。我们不能将这种必然的问题还诉诸于来年的好运。于是,我们花了半年的时间来解决以上问题。在大公司做这样的事情往往是不太被认可的,放在我身上也不例外。更为甚者,还会受到很多业务上的挑战。当时,我选择了接受阶段性不被认可的结果,坚持一条道走到黑。如今想来,有许多更加圆滑的做法,但是如果把我重新放在当时那个位置,我应该还是会选择当时的做法,而这种选择不是认知和经验问题,仅仅是内心自我的坚持吧。

带着第一年复盘的调整结果,信心满满的走进了2019双十一的作战室。是年丈母娘装了新房,当晚的一级保障计划就是给丈母娘 买买买。然而,还没等第一瓶可乐喝完,业务反馈大屏上面一个实时数据的结果不正确,找到当时业务接口同学,她倒也是诚(hou)实(yan)直(wu)接(chi):之前让验收数据的时候,回答是验收通过,其实并没有看数据。得嘞,这时手刃之祭天是没有任何作用的,而大屏数据又是部门万众瞩目的,那只能想办法现场把这个数据开发出来发布上线。抬头看了看时间,不要20点。

然而,因为双11封网一级保障的原因,实时任务开发平台无法新任务开发,沟通了将近1个小时也没有结论。好在想起之前作为集团实时任务计算平台的典型用户,与平台的owner有过一次还算愉快的内外论坛交流,于是直接联系他们解决了平台问题,只是受限于当时的关联系统管控原因,开发的计算任务无法调试,只是发布上线后结果。抬头有看了看时间,22点过了。

为了加快开发速度同时确保开发质量,我和当时搭档的同学每人负责一部分代码的编写,然后合并代码交叉review. 其实代码本身的复杂度不是太高,但是当时的高压环境和氛围让编写任何一个简单的逻辑似乎都变得不再简单。22:30 我们完成了代码编写,code review时候,我发现了一个代码的问题,跟搭档确认时,他也意识到了这是一个问题,不得不说,有时候高压真的会让动作变形。代码很快发布上线,没有调试的情况下,一次性上线成功,数据口径也符合预期。到此,问题解决了一半:由于需要追溯历史数据,因此,计算任务需要调回到今日凌晨开始计算,接下来的一个小时,我们就是盯着任务的追赶进度,终于在 23:45,成功追上了当前时刻的流式数据!

当时的直接主管老阿里也坦诚这是他参加过历次双11颠覆他认知的紧急发布。坦率讲,这次问题处理是有运气成分的,因为我和搭档事后都觉得计算任务不经过调试,一次性发布成功在日常开发中基本是不存在的。但是,过程中我觉得很重要的一个点是:技术自信。日常开发中,有问题我们可以面向google编程,但是当你的开发周期被限制在很小的时间窗口的时候,你日常所有的积累和基本功,当然还有欠下的技术债都会在短时间内爆发并如数奉还,童叟无欺。比如,这次review出来的问题我之前是研究过的,并且计算平台的文档我也是每一页都读过多次的,这个问题在哪些版本会出现也是心中嘹亮的。这些东西可能都称不上知识,只能算是信息和经验,但是假设没有这些助力,我们当晚必然需要二次发布,而时间是肯定不够的,然后也就没有然后了……另外,我很推崇的技术sense是对基础的重视:我们日常99%的问题都可以用基础的80%去覆盖和解决。因此,在追求20%的高精尖的时候(程序员歧视链的必然)永远不要放松对基础的积累和完善。

今年双11保障基本面很早就进行了部署和实施,11.1的作战室现场也是波澜不惊。但是,因为11.3黑色事件与双11有重叠时间的原因,业务层面在10号早上提了新需求。而再过几个小时就是双十一了……而我选择了接下这个需求,除了所谓的 价值观,还有一个原因是我觉得这是一个与其他同学进行技术PK的好机会。中午放弃了午休开始编码,下午3点过完成了开发,业务验收通过,然后关联业务方得知以后似乎觉得我这里的开发是不要钱的,又追加了一个需求……当然,在迟到了几分钟进作战室,都毫无意外的完成开发,并发布上线。

其实很多老人都觉得这个时候接这种需求很容易搬石头砸自己脚,其实我也是这样认为的。只是我评估业务需求后,我没有走跟我PK同学相对比较笨重的java技术路线,而是选择了Golang,在编译和调试速度上都占尽了优势,同时凭借自己平时维护的标准扩展库,很多任务都是一行代码可以解决。典型的现场现状是:我比其他线的技术同学提前了好几个小时把任务开发完发布上线,反馈问题修改也是在分钟级搞定。另外,大家可能有个疑惑:为什么没有像去年那样交给下面的人一起合作去做?一方面是因为这条技术线路在短时间内只有自己最熟悉,跟合作同学简单沟通后发现其技术面还未覆盖这些领域,我这个时候只能选择跟我上的方式,功劳大家分;另一方面,这个事情除去价值观,我有私心,我就是要用技术的方式PK一些日常看不惯的技术同学。我深知,这其实也是某种不成熟, 只是,时间久了,有些东西只是变味了,未必是成熟了

总结下来,参加这几年双11的几点感悟:

  • 未雨绸缪,实践检验真理。
  • 不要把偶然的运气当做实力。偶然的好运学会感恩和感谢,必然的倒霉也不必气馁,区分好概率和实力。
  • 养兵千日,用兵一时。高压之下,要有自负的技术自信。
  • 日常学会辨别气味相投的人,并投资积累信用,而不是表面上nice的人。
  • 技术人要学会通过技术做表达,从技术的力量视角去理解商业的本质。

1024搬砖之IG密码加密方案分析

10.24本来是普通的日子,但却有机会让你很容易的区分的两种人:程序猿与其他。

正好周六,于是把之前 side project 中的一个临时方案修改一下。其中一个关键问题点是:用 go 生成 Instagram 登录时需要用到的加密密码。

C# 版本代码如下

扫了一下整体结构,发现IG的这段加密设计还是很好的体现了大厂典范:

  1. 密码加密使用到了 aes-256-gcm, 不是野生程序员上来就是base64或者来一个自欺欺人的哈希函数(MD5, SHA1等)。这两者本身不应该一起提,因为本身是用途完全不一样的东西,只是国内看过很多方案是后者,有时候还觉得自己加了salt更安全。AES结合GCM在解决数据加密问题的同时,也解决是数据完整性校验的问题。此外,加密操作中引入time作为附加数据,因此也可以校验数据的时效性,防止重放攻击。
  2. AES是一种对称加密,因此涉及的密钥分发的问题。上述方案中,使用了SealedPublicKeyBox 这种常用且规范的源于。即通过接收者的公钥来解密AES的对称密钥,得到密钥的密文。而这个密钥密文只有接收者使用自己的私钥才能解密。
  3. 从私钥密钥去中心化以及管理维护成本出发,应该是同时启用了多对公私钥对(可通过keyId识别)。
  4. 密文bytes构造上采用经典简洁的length.content设计。
  5. 最终构造的 enc_password 格式中包含了平台、版本、时间戳、密文。如果你也设计过密码加密的方案,你应该能看到这几个要素没有一点废话,基本就是教科书的标准格式示范。调研了一圈,发现的唯一业务上的槽点是版本为某个特定值时,其实是允许传输明文密码的。这从语义上来说是矛盾的,推测是从前向兼容的一种妥协。
  6. golang中可以通过 NewGCM 实现 aes-256-gcm, 但是认证标签(authentication tag) 没有单独输出,是append在密文之后的。因此可以通过 cipherText[len(cipherText)-16:] 获取。
  7. golang中没有 SealedPublicKeyBox 原语。可以用 package golang.org/x/crypto/nacl/box 中的 SealAnonymous 代替。

其实密码加密方案有很多基本的概念和原则,国外大厂也有很多规范的设计。只要不是一开始就想当然,其实是能找到或者设计出一个符合业务需求且安全高效的加密方案的。

特殊的一天,在老家楼上分析了一段有意思的代码,完整了方案的重构,还开着遥控车在农村撒欢越野。 What a beautiful day!