分类目录归档：Golang

温故而知新之 https proxy

发表于由
回复

周六昏昏欲睡的下午，顺手用 goproxy 写了个小工具。功能部分不到两个小时就搞定了，但是在处理 https proxy 部分，希望实现一个自定义feature时，调试了挺长时间。这大大打击了自诩可以手撕 https/tls 的自我信心😝。于是顺手看了一下这块的实现部分。

原理上，https proxy 的处理，都是以客户端 CONNECT 请求开始，后续的请求都是通过这次建立的连接进行 req-rsp 交互。一句话就能讲完，很简单，对吧？对也不对。正确的部分在于，原理的确就是这样的，但是如何使用这个连接，以及如何处理其中的安全问题让这一块有很多细节需要考虑。所谓魔鬼在细节中，这也是这块最有意思的地方。

以 goproxy 这块的实现为例，通过 CONNECT 建立连接以后，请求的的交互主要支持4种方式：

  • ConnectAccept
  • ConnectHijack
  • ConnectHTTPMitm
  • ConnectMitm

ConnectAccept 是最基本的方式，只负责在 tcp 层建立远端和客户端的连接，这个连接具体怎么用，由客户端自己与远端交互决定。各个平台、各个客户端都支持这种方式，基本上没有兼容性问题。

ConnectHijack 与后面的两种方式本质上同一种类型，都可以认为是 Hijack 类型。这里涉及一个很重要的概念 Hijack, 这个在 golang 标准库中有非常准确详细的解释，搬运如下：

也就是相较于 ConnectAccept, proxy 不再是中间的小透明，而是可以接管连接，在中间实现一些自定义有意思的功能，这也是 MITM 的基石。所不同的是：

  • ConnectHijack 要求在业务自己在应用层实现这块逻辑，优点就是一切尽在掌握，可以实现很多有意思的功能。
  • ConnectHTTPMitm 是一种 https 降级为 http 的一种实现。也就是 https 通过这个 proxy 后，都被降级为 http 请求与远端交互。优点是可以 offload TLS 这层的加解密和签名开销，但是完全没有安全性。因此，这种一种古老的方式已经不被绝大部分 client 支持了。
  • ConnectMitm 则是一种经典实现，把客户端的 https 请求在中间做中转，然后还是以 https 的方式发送到远端。这是被client广泛支持的方式，因此兼容性较好。

需要说明的是：

  • Hijack 类型都依赖CA证书，这也是为什么你手机、电脑设备里面的CA根证书很重要，不要随便信任和安装来路不明证书的原因。
  • goproxy 在 ConnectHTTPMitm 和 ConnectMitm 的实现中，都会再次调用 filterRequest 执行 OnRequest 的 handler, 因此要在你的 request handler 中识别和处理这种经过转换的请求，否则会出现 loop 以及请求失败的情况。

从原理到实现，基本就拆解完了。其实也没有什么高深的部分，正如很多东西，不过是温故而知新，进一寸有一寸的欢喜。

Golang http response 解压缩分析

发表于由
回复

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

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

问题

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

原因

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

也就是说：

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

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

发起请求时，DisableCompression 为 false 且业务层没有设置 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的人。
  • 技术人要学会通过技术做表达，从技术的力量视角去理解商业的本质。