静水潜流 – 第 3 页 – 记录一点生活

parseInt

2022/11/21 YI

云通信系统的用户偶尔向我们反馈，分机的状态显示总是离线状态。我们从后台检查状态是正确的，检查其他用户的分机状态也都很正常，但是这位用户查询的结果确实总是离线状态。这事颇有些蹊跷，引起了我很大的兴趣去研究发生了什么。

检查之后的结果也很简单。后台返回的状态数据是字符串形式，而前端 javascript 脚本是按照整数进行判断，自然无法正常显示状态。但是为什么有些又能正确显示呢？

进一步检查后发现这与 MySQL 数据库的版本有关。我们的云系统有很多服务器，都是采用 Debian 的系统，同时也是采用 Debian 默认自带的数据库。旧 Debian 系统中的 MySQL 数据库版本比较陈旧，返回查询结果时都是采用字符串格式，哪怕字段是整数类型，返回的结果也是转换成字符串。而新的 Debian 系统已经将默认的数据库替换成 MariaDB，返回结果时严格遵循字段的类型，不会进行这类转换。

用户的虚拟通信系统部署在不同的 Debian 节点上，返回查询结果时就存在上述转换方面的差异。

解决方式自然也不复杂。可以从服务器端解决，也可以从前端解决。服务器端升级 Debian 系统就会同时将数据库升级到 MariaDB，自然就能返回整数类型的结果。当然也可以从 PHP （包括 pdo层）解决，由 PHP 对查询结果强制进行转换，将字符串又转换成整数即可。但是出于稳定性方面的考虑，我们一般不太愿意直接升级服务器系统（包括 PHP 等中间层），各节点的升级总是按年制定计划，不太可能为了这样一个小问题兴师动众地升级系统。

因此最后的解决方案就是对前端 JavaScript 脚本做一点修改。JS 提供了 parseInt 函数进行转换（如果是浮点数就是 parseFloat），无论服务器返回的是字符串还是整数，经转换后都可以按照整数进行判断。

此事反映出（1）我们对web、数据库等方面的技术技能比较欠缺，缺乏足够理解；（2）测试范围不够广泛，没有涵盖所有的用户类型；（3）系统配置不够一致，存在新旧并存的现象。我个人觉得后续工作要着力解决第（3）点的情况，尽量做到（包括开发、测试、线上）只有一个版本、只有一种系统。

Windows 10 启动慢

2022/11/13 YI

小孩用一台 ThinkPad 笔记本上网课，最近发现启动很慢，启动阶段往往耗时将近 3 分钟。这台笔记本是我以前开发工作的笔记本，已经升级了 SSD 硬盘、加装了 16G 内存，似乎不应该这么慢。

孩子反映以前也很快，只是最近才变慢，因此怀疑是某次 windows 升级后（当然也不排除小孩误操作）改动了设置。在网络上搜索了一下，检查启动配置后发现被设置为“正常启动”，修改为“有选择地启动”后，启动时间缩短到十几秒。

修改方式很简单，如下：（1）按键 Win+R 后，输入 msconfig，启动管理界面。（2）设置为“有选择的启动”。

酱汁焖鱼

2022/11/07 YI

材料：

（1）鱼用草鱼就可以，当然用无骨、少刺的鱼更好。

（2）料酒、葱、姜、蒜、胡椒粉；

（3）鸡蛋、生粉；

（4）喜欢吃辣就加点干辣椒、生抽、蚝油、豆瓣酱（这个是灵魂）。

步骤：

鱼清洗干净（注意要拔掉鱼腥线，内部黑色的膜、红色的血块等都应洗净）后切块，加少许盐、一勺料酒、葱姜（切块、切丝随意）、以及少许胡椒粉，腌制15分钟。

腌制好后，挑出葱姜，然后鸡蛋液、一勺生粉，抓拌均匀（这样挂浆，煎的时候不容易散）。

平底锅加热，加底油以及少许盐（防止粘锅）。油热后转小火，将鱼块放入锅中，慢慢煎，一面发白变色后，再轻轻给鱼翻面，各个面都煎到。

煎完鱼后，加入姜（切块）、葱蒜（都切粒即可）、干辣椒，再加入一勺蚝油、一勺豆瓣酱、两勺生抽。

加开水，水量没过鱼块即可，开大火烧开，然后转小火，加盖焖煮 5 分钟。

最后开锅盖，大火收汁，装盘。

程序员做饭指南

2022/10/10 YI

国庆期间（其实也包括前段时间静态管理期间）无所事事，考虑到孩子上学就没有出去玩的想法、甚至都没有跨区，只是去前海逛了逛，坐了摩天轮，基本上属于在家葛优躺几天的状态。

然而让我颇有动力去做的就是学习怎么炒菜。基本上就是上午买材料、中午做饭吃一天，下午接着上网查资料看看第二天做点啥。

这中间找到一个非常适合家常菜的指南，更离谱的是作者居然也是一位程序员，他写的做饭指南就叫《程序员做饭指南》。这篇指南解决了很多做饭新手的痛点，内容也非常丰富，我觉得照着这个指南做可以做一整年。

咖喱鸡

2022/09/24 YI

原材料很简单：（1）用超市买的“百梦多”咖喱一盒；（2）鸡肉（也可以是鸡腿肉）；（3）洋葱；（4）土豆；以及（5）红萝卜。

鸡肉用葱、姜、料酒腌制大约20分钟。

洋葱切丝（稍大一些）；鸡肉、土豆切块；红萝卜切片（薄一点）。

热油（稍多一些）下锅，先炒洋葱；

炒香后下鸡肉块；

鸡肉块变色后下土豆；

土豆炒得略带金黄色后，下红萝卜片翻炒；

然后加入清水（热开水），超过食材即可。一盒咖喱有四小片，此时先放入两小片，然后中小火继续煮20分钟；

然后放入另外两小片咖喱块（再加入一小包椰子粉，味道会更好），转大火，融化后搅拌均匀，装盘结束。

华为 AX3 pro

2022/09/10 YI

去年双十一买的华为 AX3 pro（WS7206）路由器，用了不到一年的时间，今天替换为华硕 TUF GAMING AX3000V2（又称为“小旋风”，以下简称TUF）。前者大概是399元，后者原价799，在京东优惠、又用了京豆后大约是580元。

AX3 pro（以下简称“AX3P”）的使用过程整体上不太令人满意。使用初期就有断流、网络突然停滞、路由器过热、突然重启等问题，升级后有所改善；另外我平时上网无非也就是看新闻、看资讯，实际影响不太大，也就不太在意。

然而从前两个月开始，天气逐渐变热、有时特别酷热（以深圳的天气标准衡量），AX3P 热得发烫，上述问题也变得越来越严重，停滞、断流非常频繁，已经到了无法忽略的地步。在网上搜索了网友提供的一些解决方案，例如底下垫散热块、用小风扇吹、关闭某些特性等，基本没什么作用。

由于疫情原因，开学后小孩都只能在家上网课。两个小孩上网课（一个用腾讯会议、一个用zoom）频繁出现停滞、断流问题，常常会同时中断几秒、十几秒、甚至几十秒不等，一堂课下来中断好几次，严重影响上课的质量。这实在是无法容忍。

我毫无根据地怀疑 AX3P 存在以下问题：

（1）发热量很大。这是所有 WiFi6 路由器都客观存在的问题，毕竟有那么多射频、同时处理能力要求也比旧的路由器要大得多。

（2）机型设计没有考虑好散热，尤其是和 TUF 相比，散热差距极为明显。

（3）过热导致元器件更容易老化，从而进一步恶化路由器的表现。最近几月极为频繁地出现问题。

（4）内存严重不足。这是我作为一名通信软件开发人员根据经验做出的一点推测。从 AX3P 表现的“停滞”问题现象看，似乎是 CPU 由于过热（或者过载）降频降速，但如果仅仅是这样，网速应该只是变慢而不是“停滞”，因此我判断很可能还存在内存不足问题，此时监控模块可能要求停止各项工作任务，清理、回收资源后，再继续工作，期间就导致“停滞”甚至断流，严重情况下就是重启。由于 AX3P 没有提供系统的运行状态，因此无法证实这个推测。相比之下 TUF 提供了比较详细的系统状态，如下图所示，非常清晰：

看了一下华为后来出的 AX6 路由器，采用了几乎一模一样的外观设计，当然尺寸有所放大。我怀疑这不能从根本上解决散热问题。在华为官网查到 AX3P 和 AX6 都只有 256M 内存，我觉得这严重不足。在资源如此受限的情况下，软件设计、实现必然穷工极巧，再加上一些华而不实的功能（比如 NFC 之类的），内存可能捉襟见肘，实在没有必要。即使是家用路由器，也应该以稳定为第一优先级。

另外，在华为官网还罗列了 AX3P 的工作温度，如下图所示：

我可以肯定前段时间的温度超过了 40 度，除了天气确实很炎热，AX3P 路由器自身发热的温度也很高。

目前 TUF 工作很稳定，没有出现类似的问题。当然，不能草率地轻言 TUF 表现更好；另外价格也客观存在差距。然而在选择路由器时（尤其是 WiFi6 及以上的路由器），除了常规的频段、无线标准、传输速率、CPU 等参数之外，确实应多考虑散热、内存等以往容易被忽视的信息。

2023-01-07 更新：22年9月份买的 TUF，今天突然不停重启，有线、无线全都接不上去了 …… 想要一个稳定干活的路由器怎么就这么难？

办理身份证

2022/07/15 YI

老大的身份证月初过期了，上月由于初二生地会考，不敢随便动证件，就一直拖着。流程其实比较简单，不过由于小儿未满16岁，必须到现场办理，办理苗的居住证时就顺便一起预约了办理老大的身份证。

主要注意以下几点：

（1）预约民政服务中心点以及时间；

（2）提供证件原件：（a）户口本；（b）家长和小童的身份证；以及（c）照片回执。

无需提供证件复印件，但小童必须到现场办理，现场需要录入指纹。

现场无需支付费用，证件邮寄到家后再支付即可。

办理居住证

2022/07/15 YI

苗是双非孩子，虽然居住在深圳，但却一直没有办理居住证。最近办理一些手续，需要用到居住证，因此正式着手办理。深圳对港澳籍居民办理居住证的流程非常简单（小童无需到现场），主要是以下几点：

（1）需要在“深圳公安”公众号或者网站（点击此处）预约服务中心和时间；

（2）提供以下证件的原件和复印件：（a）家长身份证；（b）小童回乡证（也就是港澳居民往来大陆通行证）；以及（c）小童的香港出生纸。

（3）提供房产证（或者租房证）的复印件，无需原件；

（4）提供照片回执（现场附近一般都有照相馆，也可以到市内任意一家照相馆照相，声明是照居住证照片即可）。

事先可以致电咨询以免政策出现变化，联系电话：84466140。

预约时要选择办理的地点，南山这边有两个民政服务中心点：（1）南山公安局服务点；以及（2）深圳湾服务点。

由于我们家住南油附近，地铁9号线可以直接通到深圳湾服务点所在的“高新南”站，因此预约了这个服务点。路程也很简单：

南油（F1入口）坐9号线（文锦方向）、“高新南”站（B1出口）下、沿着出口上到9栋B座（一层）即是。

办完之后大约10个工作日证件邮寄到家，收件时再支付费用，服务点大厅不收取任何费用。

攀升电脑

2022/05/12 YI

去年年中的时候，考虑到孩子上网课用 iPad 太伤眼睛，就将自己平时用的笔记本给孩子，自己上网搜了一圈，买了一台攀升小电脑，如下图中所示：

本来可以自己攒一台电脑，这也不是什么难事，不过看到攀升这台小电脑，觉得外观不错、金属外壳估计散热也可以，另外觉得有品牌的电脑大概品控会比自己攒的要好一些。

最初一段时间还是不错，然而后续有些问题让人极度不愉快。主要体现在以下几点：

（1）Windows 10 家庭版系统可能是盗版。使用一段时间后，系统竟然提示过期、需要重新激活。联系了客服，发了一个注册码过来重新激活。我不知道攀升和微软是达成什么类型的协议，我第一次遇到 windows 提示这种信息，感觉不太正常。也不知道若干时间后，是不是还要再次激活。

（2）SSD硬盘降速、提示文件损坏等。使用了大约半年时间，很明显就降速了，甚至提示某些文件损坏。不到一年时间，任务管理器里提示磁盘活动时间100%，几乎无法使用。再次联系客服，可以保修换硬盘，但数据无法保证。于是自己想努力一下，用各种设备、软件先备份数据、备份系统，期间拆开电脑检查，SSD 是从来没听说过的”Flash War”品牌，上网查了一下，果然被评价为“垃圾中的垃圾”。

我对客服提示的换硬盘没有信心，鬼知道会换个什么牌子的硬盘，难道过半年我又重新再折腾一遍？于是自己买了张金士顿的 M.2 SSD、复制硬盘。很遗憾，由于错误太多，尝试很多次后都失败了，所幸原盘自带一个 OEM 分区，里面有初始安装的备份，在新盘上重新还原出来系统。数据部分没有损坏，只是系统相当于重置了，花了两天时间重新安装、备份系统。

我相信攀升选择这种野鸡 SSD 的主要原因是图便宜，但这实在得不偿失，严重损害品牌的形象。这台电脑的工作负荷并不高，平时只是我自己的一些开发工作（对硬盘读写几乎没有要求），然后就是上网看新闻、QQ 听点音乐而已。就这点负荷，这块 SSD 只能支撑大半年时间，可见品质有多烂。这样能省几个钱呢？哪怕换块国产长江存储的 SSD 肯定也比这好得多。

（3）无线信号极差，对，就是极差。由于是金属机身，信号差我是有预期的，但是差成这个鬼样子，绝对超出预期。上图中我不得不另外买了个外置的 EDUP 无线网卡才解决上网问题。这次拆机看了下无线模块，就牵了两条线粘在面板上，这样信号能好才见鬼了。千元电脑的杂牌机（比如占美）都知道外接天线（或者留下外接天线的接口），要不然就不应该采用金属机身。

（4）USB3供电不足。上面提到的无线网卡是USB3接口，经常因为供电不足而断开，后来不得不插到USB2口后才行。这个就很奇葩，以前只在笔记本上遇到过供电不足的问题，台式机居然搞成这样？！不知道是元器件的问题，还是主板设计的问题，对消费者而言就是个闹心的问题。

稍稍有点意外的是采用了英睿达的内存。既然如此，为什么不一套整下来，也采用英睿达的SSD呢？或者用好点的SSD、用差一点的内存？不知道攀升在供应链或者工业设计方面是怎么考虑的，我觉得整体严重低于预期，甚至不如之前使用了几年、换给孩子上网课的笔记本。

奇怪的 SIP 呼叫流程

2022/04/26 YI

最近几天帮助泰国的朋友检查一个呼叫业务流程，其中涉及很多细节和业务流程，不过让我觉得特别意外的是他使用的 VoIP 运营商的 SIP 呼叫流程。首次遇到这样的流程，请先参考下图的概要描述：

这个流程的奇怪之处在于：（1）VoIP 运营商发起呼叫时，INVITE 消息的媒体地址居然是“0.0.0.0”，这很明确告诉被叫：主叫只发送媒体流、甚至根本不处理媒体流；（2）被叫应答后，VoIP 运营商再次发起 reINVITE 流程，此时才真正指示出自己的真实媒体地址（当然也包括最终的媒体编码）。

通常的 SIP 呼叫流程在发起呼叫时就明确指示自己的真实媒体信息，因此在被叫应答后，没有必要再发起 reINVITE 流程。然而这家运营商为什么要放弃传统做法、采用这么奇怪的流程呢？

这家运营商是美国的一家运营商，而且规模很大，其设备供应商也是一家世界级的大软件公司（非常、非常大），因此这个流程肯定不是随意修改的结果，必定有其特殊的目的。仔细揣摩后，我认为它可能是为了节省媒体资源才这么做。

被叫方一般会振铃几秒、十几秒、甚至几十秒后，才可能应答。另外，呼叫量特别大时，统计上只有10%左右的呼叫最终才会应答。这家运营商采用这个流程，只需要在被叫真正应答之后才开始分配媒体资源，考虑到这是一家规模很大的运营商，这种流程确实可以节省很多的媒体资源。

VoIP 网络往往是主叫播放回铃音，因此这是个非常聪明、折中的呼叫流程，确实只有在被叫侧应答之后才处理真实媒体流。然而现实网络组网是非常复杂的，这个聪明到有些投机取巧的方法有固有的缺陷，请参考下图：

被叫侧如果对接了传统的 PSTN 网络，例如 VoIP 网关，很有可能直接返回 183 消息并携带被叫的媒体信息。传统的 PSTN 网络往往是被叫侧播放回铃音，并且也有一些被叫侧放音的业务（例如“彩铃”），此时这家 VoIP 运营商就有问题了。

由于它告诉给被叫的地址是“0.0.0.0”，因此被叫振铃音（或者业务音）就无法传达到主叫侧。VoIP 运营商可以向被叫发送 UPDATE 消息来传递自己的真实媒体信息，但被叫未必会支持 UPDATE 消息，这个是扩展消息，不是所有的 SIP 设备都必须支持。而且 PSTN 网络往往会要求对 18x 消息用 PRACK 流程确认，因此即便支持 UPDATE 消息，这个特殊流程实际也急剧放大了被叫侧振铃阶段流程的复杂度。

这也就是我们的泰国朋友遇到的问题。

解决方式是在 VoIP 运营商与 PSTN 网络之间架设 miniSIPServer：

（1）miniSIPServer 与 VoIP 之间建立完全应答的呼叫通道；

（2）miniSIPServer 与 PSTN 之间维持正常的呼叫流程；

（3）miniSIPServer 判断被叫侧是否自己放回铃音（或者业务音），如果（a）被叫没有放音，则 miniSIPServer 主动给 VoIP 运营商放回铃音（或者呼叫等待音），而如果（b）被叫有放音，miniSIPServer 则直接建立两边的通道，让主叫直接听被叫的放音。