我的家庭AC+AP分体组网高性价比满血方案

赶在成都降温前搬入了新居。以前的房子装修时因为还在帝都上学,网线布线和施工比较残废,这次从装修设计就计划使用AC+AP的方案,因此每个房间,包括厨房都预留了网线。剩下的就是买入网络设备塞进去。如果你的预算在5000以上,你可以直接看思科和UBNT的方案,稳定可靠,没有花钱的不是。如果你的预算跟我一样准备控制在3000以下,那么这篇文章应该可以解答你从设备选择到安装的绝大部分疑惑。

为什么选择AC+AP方案?

这次的网络方案目标是在预算有限(<3000)的情况下,有线网络千兆,全屋5G无线漫游、信号无死角。

这个目标下,一个路由全屋覆盖的方式首先被淘汰,因为卫生间死角怎么测试都无解。Mesh方案不考虑,太鸡肋,效果没有AC+AP好,价格整体也没便宜多少。

因此,AC+AP的方案成了唯一选择。按照房屋面积,规划AP数量为5个,两个吸顶AP,3个86面板AP。在预算范围内能选择的方案基本只有tp-link. 而对于这个品牌,网上能查到的信息也是褒贬不一。仔细研究了一下,希望以下信息对你有用。

实现无线漫游的先决条件

全屋无线漫游可以理解为AC+ACP设备都需要支持802.11 k/v/r 三个协议。这三个协议的具体作用这里不具体展开,也不要浪费时间相信很多设备不支持802.11 r,不支持这个协议也可以的论调。结论就是,真正的漫游需要这三个协议一个都不能少。在协议支持上,AC和AP的职能有所不同:AC负责控制是否开启801.22 k/v/r协议;AP负责在终端实际支持这三个协议。

选择什么样的AC?

组网方案中,AC主要进行AP的管理和控制。且AC与AP一般为厂家自有协议通信,因此AC与AP一般是需要配套的。对于tp家,现在性价比最该的就是AC100 V4.0, 可以管理100个AP,且支持802.11 k/v/r,且可以旁挂方式接入。现在在售的全新设备,基本都是V4.0版本。据说V3.0版本也可以,如果实在预算有限,可以考虑闲鱼收一个3.0版本。

需要说明的是,AC是旁挂方式接入,因此虽然AC100只是一个百兆AC,但是因为本身只负责AP管理,并不承载实际的上网流量,因此完全不会成为瓶颈,更没有购买AC300等千兆AC的必要。

选择什么样的AP?

不得不说,tp家AP真的是我见过最杂乱的产品线。型号众多,几乎覆盖千元一下各个价位,但是又没法从参数上看出产品线的分类和定位。而各个型号对漫游协议802.11 k/v/r的支持程度也是语焉不详。这就导致如果不做功课,买回来的东西期望和实际必然不匹配。这也是很多人觉得tp“垃圾”的根本原因。

总结来说,tp家AP只有高通硬件方案+支持802.11 k/v/r 值得选择。其他型号都不值得购买。高通方案是因为相对发热低,更加稳定;而满血漫游协议支持是全屋良好漫游体验的前提。截至2020年底,tp家满足这两个条件的型号有一下几款:

  • 支持KVR协议的86面板式AP,总共包括三款:
    1. AP1308GI,要求v2.0及以上 【9.71W】
    2. AP1750GI,要求v2.0及以上 【9.37W】
    3. AP1758GI,要求v2.0及以上 【10.73W】
  • 支持KVR协议的吸顶式AP,总共包括三款:
    1. AP1200GC,无版本要求 【9.4W】
    2. AP1750GC,要求v2.0及以上 【21.28W】
    3. AP1758GC,要求v2.0及以上 【15.31W】

价格由低到高,丰俭由人。从我的预算出发,选择的是3个AP1308GI,2个AP1200GC,实际到手以后发现版本都是V2.0。需要注意的是,面板式AP AP1308GI 已经停产,当前阶段更加推荐选择AP1758GI。

实际安装过程中的问题

  • 86面板式AP散热不太好,因此我选择在暗装盒上面对接一个明装盒,然后将AP面板安装在明装盒上。这种安装方式实际解决了两个问题:1、面板AP实际上并没有紧靠墙体,因此,散热更佳;在当前室内21度情况下,面板为温热;2、解决面板AP直接安装暗盒时空间不够的问题。理论和实际是有差距的,即使号称86面板AP,实际安装的时候也是很难安装进安装86线盒的,主要是因为上方的网线头以及AP背后的凸出严重挤占了空间。
  • 吸顶AP可以壁挂,如果家里不能接受吸顶,可以把AP壁挂在电视墙上。信号和覆盖基本不受影响。
  • AC控制器默认不会开启 802.11 r,需要手动登录开启。AC控制器每次修改配置以后,一定记得保存,否则不会生效。
  • 漫游效果以主观感受为准,软件信号强度仅做参考。
  • 安装完成以后,发现一个AP无法被AC识别。先检查AP LED是否闪烁判断供电是否存在问题,如果没有问题,可能是第一次组网未识别,可以重新插拔AP的网线重启尝试入网识别。
  • 六类网线铜线是比较粗壮的,手工打网线头手指比较疼,做好心理准别。
  • 大部分智能家居设备都不支持5G,因此2.4G网络还是需要保留。认证上,某些智能家居设备只支持不安全的TRIP算法,只开启AES可能导致无法认证入网。如果有安全洁癖,可以把2.4G的SSID隐藏。
  • 弱电箱相对空间有限,而设备又比较多,可以考虑把86面板操作扔掉,换上一个短小的多面插线板(各个面都有插孔),扩展更强,且安全、美观。

总结及使用感受

  • 整体预算控制在2500以下,主要是因为1688购买+运气好买到了库存的AP1308GI。
  • 全屋漫游苹果设备和安卓华为设备主观感受都超出预期。家里没人玩手机游戏,不太关注漫游延迟,多媒体和应用主观使用感受非常满意。考虑到实际价格,能打个接近满分的分数。

整个方案没有提到路由器,当前还是使用的光猫作为路由器使用。等后面又想折腾的时候,应该会入手一个 UBNT ER-X。

这些年参加过的双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!