为什么叫“哥哥科技”？因为我爱着我的哥哥和弟弟。就这么简单。
English | 简体中文
BroTech（哥哥科技） 是我的个人技术品牌。
我喜欢做技术，也愿意把一些真正喜欢、真正花时间打磨过的东西留在互联网上，所以最后选择了 哥哥科技 / BroTech 这个名字。
哥哥科技 目前主要围绕消费级品牌硬路由、家庭网络以及原厂 Web 后台做一些东西。这里会涉及单设备实时网速、流量统计、网络遥测、浏览器用户脚本、原厂 API、XHR 和 Fetch 数据接口，也会碰到 NPU、硬件加速、Mesh、设备状态判断、数据采样和可视化：我讨厌把一台品牌硬路由刷机另一套固件，相反更愿意先看看厂商原本已经做好的系统到底能不能继续利用。
我的世界里没有『刷机』，不去Flash那可怜的ROM；不如物理上拿毛刷清清灰；我的字典里只有“系统安装”“系统部署”。所谓固件就是固化的 BIOS/UEFI。 理想的网关
我当然知道这不是严格的定义，严格的来讲，系统安装和系统部署类似，是系统封装的逆过程。镜像本身只是类似于打包盒，Wim/ESD和内部使用了哪种封装体系半毛钱关系都没有；固件/韧体也并非只有 BIOS。我想表达的意思是：针对一个设备或者说计算机，他更倾向于是一个软硬件一体的设备，并且刷写后的镜像会直接启动，是已经固化好的、也不一定必须是烧录进去的，还是需要一个完整的展开设备树，对当前系统环境做优化之类的过程。或者更简单的说，除非玩固件，否则这套底层运行的 OS 或者基于某操作系统深度定制的 UI，其主要功能的升级可以通过常规的系统升级来完成，且升级过程中通常不可以移除安装介质。
更直接地说：当你去升级系统时，排除可能导致 CPU 频率升高、温度上升之类的物理影响以外，在逻辑上，升级系统和这台设备变砖之间有无直接的影响因果性或者概率可能性。常见于 ARM 平台。即：在日常使用习惯里，能作为操作系统正常安装、部署和维护的部分，我就把它当 OS；固件这个词留给boot firmware等真正位于OS以下的平台层。
原厂固件继续负责它擅长的数据面，我在 Web 管理层上把数据调校好；完全保留原厂 NPU 和硬件加速，然后把后台重新做得更适合真正想看数据的人。
在很多玩家语境里，只要一说到“路由器插件”，话题很快就会滑向 OpenWrt、软漏油邪教、DPI、多 WAN、策略路由之类的东西。
问题是手上就是一台中兴、华为、小米、华硕、TP-Link 或者 H3C 的品牌硬路由，我并不打算把它改造成一台通用主机！
那能不能在完全不破坏原厂系统的情况下，把这些数据重新组织出来？ 能不能直接看到所有设备的实时上下行，而不是一个个点进去？ 能不能把瞬时速率、累计流量、在线状态、Wi-Fi 信号、WAN 状态放到真正需要看的地方？ 能不能让一台原厂硬路由继续走自己的 NPU 和硬件卸载，同时又拥有一个更像样的观测界面？
哥哥科技 的很多代码就是围绕这些问题慢慢长出来的。
Bro-Stat 是面向多个品牌硬路由的 Web UI 增强和网络监控项目。
它现在会处理不同厂商完全不同的后台。有些设备给的是瞬时速率，有些只能拿到累计计数器；有些后台是 XML，有些是 JSON，有些还保留着 Lua 页面；有些固件可以直接 Fetch，有些需要从 XHR 里截数据；H3C 一类设备甚至还会碰到 GBK 页面和比较重的设备信息解析。
所以 Bro-Stat 并不是先写一个统一模板，再把不同厂商的 API 地址替换进去。
如果华硕给我的只是累计字节，我就按真实时间差做差分；如果中兴能够直接给设备瞬时速率，就使用它自己的数据；如果某一代中兴固件同时存在新 Vue API 和老 Lua 接口，就根据实际环境探测；如果 H3C 的完整设备解析开销比较重，那就把高频变化的数据和低频变化的数据拆开，只有设备集合发生变化时才重新走重路径。 无论厂商后台底下是 XML、JSON 还是别的东西，用户真正想知道的其实一直很简单：谁在线，谁正在上传，谁正在下载，每台设备现在多快，用了多少流量，Wi-Fi 信号怎么样，WAN 总速度是多少，刚才是谁接入，又是谁掉线了。 底下那些乱七八糟的差异，本来就应该由程序解决。
ZTE-Stat_Max 是 BroTech 重要的一条起点。 SourceForge 也保留了一份发布入口：ZTE Router Web Plugin。
这个项目最早就是围绕中兴原厂路由器 Web 后台做的。中兴后台本身已经能提供不少有价值的数据，只是很多东西放得比较深，设备实时网速可能需要进入详情页才能看到，设备累计量、WAN 数据和客户端数据又分散在不同地方。 于是最开始的问题其实很朴素：数据已经在那里，为什么不直接把它们拿出来放到设备列表里？但后来事情就越来越复杂了。
一旦真正开始统计流量，就会遇到采样间隔并不完全准确、设备从零速率突然开始传输、计数器归零、浏览器后台节流、设备掉线、重新接入、Mesh 漫游以及不同数据源互相对不上的问题。
查看详细
中兴官方是有 bug 的，它在那个发生漫游的时候会把流量算作两遍。 比如说你漫游之前有 20G 流量，然后漫游到另外一个 AP，就会被算两遍，被算成 40G。
官方不仅会归零，还会漫游、继承、诈尸，有几大问题。
所谓清零，指的是在离线以后重新接入，流量统计会归零。
所谓诈尸，指的是当星云 Max 作为主路由，也就是有些路由它不清楚设备的无线状态，因此设备需要离线 10 分钟才会报告离线； 其中无线 AP 在设备离线以后会在 10 秒左右迅速报告离线，然后维护 ARP 表 5 分钟； 然后 5 分钟之内有风吹草动就会重试；然后 5 分钟之后再维护一轮 5 分钟，从而 10 分钟之后停止维护 ARP 表，从而主路由有线端得知离线。
因此，掉线 5 分钟以内重新接入，星云 Max 不会有 bug。 5~10 分钟之内有概率立即继承，不会有 bug，有概率清零。清零我的插件能防御。
最恶心的是归零以后马上继承，也就是诈尸。 由于清零是一个递减过程，很容易识别，但是诈尸是一个合法的单调递增过程，所以非常恶心。
它逐渐从一个“把后台改好看一点”的脚本，变成了一套更偏向原厂硬路由网络遥测的数据处理方案。开发过程中，我也曾经就后台轮询间隔之类的问题和中兴相关人员做过技术交流，并得到过一些帮助。
UI 以后可以随便改。颜色不好看，布局过时了，可以改。哪天有人想把整个前端重新用另一套框架写一遍，也没有什么问题。
真正麻烦的是另外一些东西：
一个设备上一秒还是 0 Mbps，下一次采样突然变成了 100 Mbps，那么两个采样点中间那段流量到底怎么算？如果定时器设成 1000 ms，但浏览器实际过了 1087 ms 才执行下一轮，又应该按 1000 ms 还是 1087 ms 算？ 原厂累计量、设备侧积分量和 WAN 总量彼此对不上时，哪一个才更值得相信？Mesh 漫游以后接口发生了变化，这算掉线重连还是同一个设备继续在线？ 计数器突然归零，是设备真的没流量了，还是统计基线被重置了？采样间隔并不严格等于定时器设定值时，是否应该仍然假设固定时间？ 一个极小但持续存在的变化，为什么不能永远被滞回门限吃掉，而一个极大的变化，为什么还需要傻等固定防抖时间？
这些问题在 UI 上看不出来，但最后所有数字准不准，都取决于这些细节。
如果我不做，可能再也没有一个人完整的作出这些有执念的代码了。
普通情况下，可以用相邻两个采样点之间的梯形面积：
Traffic ≈ (Speed_old + Speed_new) × Δt / 2
真正重要的是 Δt：如果程序每秒轮询一次，不代表每一次真实间隔都刚好是 1000 ms。误差就是这样一点一点积起来的。
还有一种情况很容易被忽略：上一轮采样是 0，下一轮突然出现了明显流量。
真实网络当然不会在第二个采样点到来的那一瞬间才凭空开始传输，更可能是在两个采样点之间的某个时刻启动 ➡️ 如果整段都按照 0 算，就会漏流量；如果整段全部按照新的速率算，又会高估。
所以部分实现会对这种 0 → 非 0 的区间做额外估算，例如按照一个三角形面积补偿中间缺失的部分。 如果某一块数据只能估算，那就把它当估算处理。把这部分估算量和触发次数单独记下来，让用户知道最终累计值里有多少来自确定积分+采样空隙的补偿。
同一台路由器里，有时候可以同时拿到 WAN 侧统计、客户端侧统计、原厂累计量和自己根据实时速率积分出来的数据。
如果几个数据源一直十分接近，可以互相证明统计路径大体正常；如果某一刻突然有一个来源掉到 0，而其他两个还在增长，那就值得怀疑是计数器重置或者接口异常；如果设备累计量和 WAN 总量长期存在稳定差值，也可能反过来帮助判断哪些流量没有被当前设备统计覆盖。
所以多个数据源并不是简单重复显示几个数字，而可以互相校验，甚至参与最终判断。 厂商给了一个数字，并不意味着程序就必须无条件把它当作唯一真值。
RSSI 这种数据很容易在某个阈值 附近来回跳。
最简单的办法是规定“变化以后持续几秒才更新”，但这样会有一个很明显的问题：从 50 变成 51 要等，从 0 突然变成 100 居然也要等。 另一种传统办法是给 50 设置一个 45 到 55 的死区。这样确实不抖了，但如果真实值变成 51，然后在那里稳定一辈子，显示值理论上也可以一辈子停在 50。
所以我更喜欢把“变化有多大”和“变化持续了多久”放到同一个判断里。
变化特别大时，幅度本身就能快速提供足够证据；变化只有一点点也没关系，只要它一直存在，就可以一点一点累积到需要更新的程度；如果只是 51、49、51、49 这样来回抖，正负变化又会互相抵消。
简单说就是： 大变化用幅度换时间，小变化用时间换幅度。这样既不会让巨大的状态变化傻等固定防抖时间，也不会产生一个永远吞掉微小真实变化的死区。
我称之为 双向奔赴防抖算法，把一个二元数组转换为一维加法。就如： NAT类型加和，6为分界，和传统 RFC 3489 经典打洞对照表完全等价。
我不太喜欢为了“过程看起来完整”而制造只使用一次的中间变量，或者：废物变量，Wasteful Let。通常声明完马上就用，并且再也用不上、没有可复用性，例如比特转MiB非要先来个字节，算比例非要先 let 一个 total。反之，能节约一半以上或者两三次运算的变量缓存则值得。
关于废话：我并不讨厌废话，甚至可以说：正是所谓的“废话”才组成了我们。
况且，很多 LLM 对「废话」的判定有极高的假阳性率和伪阴性率：后者通常是AI不自知的、真正令人讨厌的「车轱辘话」。
比如最终只是算某个设备占总量的比例，如果总量在这一轮里不会变，可以提前把倒数算好，后面直接乘；某个单位转换如果最终本来就是乘一个固定常数，也没必要先除一次、再除一次、最后再乘回来。
同样的想法也会用在 DOM 上。如果一个节点已经在第一次渲染时拿到了引用，后续刷新就没有必要每一轮重新 querySelector；如果实时图只需要最近 32、64 或 128 个采样点，就直接使用固定大小的环形缓冲，而不是不停 push()、shift()，把数组里所有东西来回搬。 这些优化单独拿出来都很小，但脚本是长期、高频运行的东西。我更喜欢让高频路径里留下的每一步都有理由。
实时曲线并不需要保存无限历史。
如果界面只展示最近 64 个采样点，那么第 65 个点到来时，最老的那个自然就已经没有继续留在实时缓冲区里的必要。
固定大小的 TypedArray 加一个循环索引就足够了。
缓冲区大小如果正好是 2 的幂，索引甚至可以直接通过位运算循环回来。这样数据本身一直待在原来的内存块里，只修改当前位置，不需要为了新增一个采样点反复移动整个数组。
这类东西写起来并不复杂，只是我觉得既然可以这样做，就没有必要故意绕远路。
我不太喜欢为了所谓“架构统一”把不同厂商强行磨成同一种实现。
中兴、华为、华硕、小米、TP-Link、H3C 的后台差别本来就非常大，它们拿实时数据的方法不同，设备状态模型不同，接口更新频率不同，甚至连字符编码都可能不一样。
所以某一个品牌最适合用的办法，不应该因为另一个品牌做不到就被放弃。
Bro-Stat 真正想统一的是最后呈现给用户的概念。比如无论下面的数据到底来自 XML 还是 JSON，页面上最终还是应该告诉用户这台设备现在上传多少、下载多少、连接在哪个频段、信号怎么样、在线了多久。
这其实就是 ZTE-Stat_Max 最早解决的问题之一。
部分中兴原厂后台本身能够获得设备实时网速，只是信息位置比较分散，有时需要进入设备详情才能看。ZTE-Stat_Max 会把这些数据重新整理，尽量直接放回接入设备列表，让所有在线设备的上传、下载和其他状态能够放在同一个页面比较。
对于设备很多的家庭网络来说，一个个点进去查看没有太大意义。
这件事要看具体固件到底能提供什么数据。
如果原厂已经有可靠的设备累计量，可以直接拿来使用；如果只能获得实时速率，也可以通过积分得到本次在线流量；如果几个来源同时存在，还可以互相比较，判断某个统计源是不是发生了归零、遗漏或者异常。
因此 ZTE-Stat_Max 里并不只有“一个流量数字”。
我更在意的是这个数字从哪里来，以及它在什么情况下可能不准。
如果路由器本身运行正常，只是原厂后台查看数据太麻烦，那么没有必要因为这一件事就先去换固件。
有些用户真正不满意的其实只是这些小问题：实时网速藏得太深，接入设备列表信息太少，WAN 状态分散在别的页面，设备多了以后必须不断点来点去。
ZTE-Stat_Max 本来就是针对这类问题做的。
Bro-Stat 是 BroTech / 哥哥科技开发的中兴原厂路由器 Web 后台增强项目，主要通过浏览器用户脚本运行，不需要替换路由器固件。
如果你只是想在保留原厂固件和硬件加速的前提下，把设备实时网速、流量统计、接入设备列表和 WAN 状态做得更直观，那么可以看看 ZTE-Stat_Max。
如果想把类似的思路用到其他品牌硬路由，则可以看 Bro-Stat。
可以。这也是我一直喜欢这条路线的原因。
浏览器用户脚本运行在管理页面这一侧，所以路由器自己的系统、驱动、NPU 和硬件加速路径都不需要因此改变。
最直接的办法就是把所有设备的实时上传和下载同时显示出来。 如果设备列表本身就能看到每一台客户端的瞬时速度，那么谁正在下载、谁突然开始上传大量数据，基本一眼就能看出来，没有必要再进入每一个设备详情。
容易走入一条不归路，好好的硬路由 NPU 不弄，让网管当上帝，根本不知道终端自己的需求，800年不进一次的后台，还不如终端直接更改分流方便。甚至到时候还要给各种小主机、工控机、树莓派、香橙各种派，螺丝壳里做道场的，热功率密度大于 18 瓦特每升的小设备增加散热风扇。几百万买的房子不是用来听噪音的。
当然，PC、甚至游戏手机、如果为了静音会有很多妥协，所以不一定有必要。但是网络设备本就不应该这么复杂。
但问题是，作为一个有线原教旨主义者，甚至我觉得电线也是线，也比单 5G 频段且空间流小于 2×2 的无线回程要好，详细可查看：
无线不能超二经验定则
不要让老头乐上高速，在家里修个双层立交桥，新手机上5.2G高速8车道160频宽，老手机小爱音箱上5.8G四车道80频宽，分流共存。
“在常规消费级无线局域网的物理层约束下，能量与数据的有效载荷不可能在不借助有线介质的情况下，通过单一射频接口在同一信道内实现无损的中继转发”
“不可能构建一个仅通过单一无线射频界面作为中转，而不向周围信道排放大量 无效占空比 并导致有效带宽腰斩的网络循环”
只要房屋不超过150平、长边小于15米、单层，宁可直连原5G信号,也不要用2.4G或者拓展出虚假的5G强信号。忘掉三频和无线回程，10cm短跳线连两个普通路由器，分体式双路由器三频，物理法则比什么都有效，或者直接有线回城，有线才是原教旨路由器。
一般地，忽略掉6G（中国不可用）和支持双高频并发的高端设备，或无线网桥、专有设备、私有协议设备等的情况下，有以下规律：
1.无线传输应该仅限于终端和终端之间的传输，或终端和AP之间的传输。 2.路由器的OFDMA和MU-MIMO之类的技术，可以适用于多用户的接入。但是，不要使用一个无线设备作为数据包的中转站。也就是让一个无线设备同时收和同时发，并且还要占用其缓冲区的部署形式。
即：零次无线传输最好，一次无线传输是无线发明的最初用途，也是正确用途，两次及以上的无线传输是不合理的。 由于无线超过两次及以上的传输会造成严重的问题，因此又被称之为无线单跳定则。
路由器厂商一般不是宣称双频吗？就是2.4和5。我的字典里没有模糊的5GHz，这是薛定谔的，要么工作在5.2，要么工作在5.8，一次只能在一个频段。
这就像一个人既会开小轿车，也会开大货车，开小轿车的时候，时速更快，可以开58，表现为就是延迟可能只有2.5ms，但是车身宽度只有80cm，一次能运货（数据包）比较少。
大货车限速低一点，只能开52，但是车身宽度最高可达160cm，一次运的数据多，表现为下载速率（如1100→2300Mbps）更大，延迟也不高，例如3ms
一个普通司机，一次要么只能开小轿车，要么只能开大货车，但是他的岗位可以调换。
至于2.4G，那只是你买路由器的时候，顺便附赠了一个只会骑自行车的小孩，只不过让他们住在了同一个白盒子里面而已。但是有驾照的司机只有一个。
为什么要分5.2G和5.8G？
就像收音机一样，如果所有人挤在一个频道说话，谁都听不清。即使WiFi 6有BSS着色机制，但是这也只是让大家时分复用排队。
要把5.2G（36-48，52-64）和5.8G（149-161）当成两个完全不同的独立频段来部署。
这比买三频路由器性价比要高得多，家里的三个频段就是不同的名字，同频同名同密码漫游，异频不同名不漫游。
为什么不要无线回程？
这是没有办法的办法。如果必须要的话，就搞两个廉价路由器吧。一个工作在5.2G，这个可能要贵一点，最好支持160频宽。另外一个工作在5.8G。然后中间用短跳线连接。这就相当于普通的人需要的双手端盘子，与其找一个高手，可以左手送盘右手接盘单手端盘，或者说他一个手可以端两个盘子，还不如找两个普通人在指定的地方用Overkill的性能来交接。
无线的环境是充满复杂的，很多时候我也没有一个量化的标准，还得借助生成式AI去讨论。我没有充分的把握把这些结论发到公网上，甚至我还需要求助网友；相反，其他网络层的东西反而所谓的大模型经常跟我抬杠，最后道理还说不赢我。
这些项目里有大量代码是在 AI 辅助下完成的，这对我来说很正常。 以后软件开发只会越来越依赖 AI，我也不觉得“每一行必须由人手敲”是什么值得坚持的原则。
真正麻烦的是：AI 第一次给出来的方案经常只是看起来正确。 比如防抖，如果需求只写一句“RSSI 不要跳”，模型很容易给一个固定时间 debounce；告诉它时间法有问题，它可能又给一个固定上下门限；继续追问 50 长期变成 51 怎么办，才会暴露第二种方案也有死区。
很多最后留下来的代码，实际上是这种来回返工以后逐渐磨出来的。 所以我更关心的是能不能发现问题，能不能构造一个让错误暴露出来的例子，能不能在真实路由器上验证结果。至于最后那几行 JavaScript 到底是人敲的还是模型生成的，我没有什么执念。
BroTech 不是商业项目，我也不靠这些东西赚钱。
所以能继续修代码的时候，我通常更愿意修代码；能再适配一个品牌的时候，我也更愿意把时间花在真实设备上。 文档当然需要有，不然搜索引擎和后来的人不知道项目在干什么，但我不想为了显得完整，给每一个决定都配一篇长篇设计说明。
以后真的有人想换 UI、重做前端、重新生成一套文档，AI 会越来越擅长这些工作。 一段已经在真实设备上跑过很久、处理过各种奇怪边界情况的代码，反而更难凭空重造。
AI 现在几秒钟就能生成一张非常整齐的架构图。
但我还是喜欢留一些开发过程中的手写东西。
因为人在真正想问题的时候，脑子里并不会先出现“Presentation Layer、Business Layer、Data Layer”这种整齐结构。更常见的是突然记一个 XHR，旁边写一个“差值”，又想到 LAN/WAN，然后再补一句“0 → 有”。
这些东西可能不好看，却很容易留下当时到底在想什么。
文字适合检索，源码适合验证，手写图则会留下开发者自己的痕迹。
如果一定要概括 哥哥科技 代码里比较长期的倾向：
原厂已经做好的东西也没有必要为了“极客感”故意推倒重来。
最后还是那句话：代码是跑在真实设备上的，设备最后表现怎么样，比纸面上看起来是不是很学院派重要。
我没有给它设什么商业目标。
真正希望的是很多年以后，当有人搜索“中兴路由器增强”“ZTE plugin”“中兴路由器怎么看每台设备实时网速”时，还能偶然看到这些东西。
也许那时候现在这些具体型号早就没人用了，UI 也已经完全过时，甚至代码早就被后来的 AI 和开发者改得认不出来。
但某些处理问题的方法还在，某些后来的人看到代码以后，会觉得“原来当时有人这样想过”。
那就够了。至于 BroTech / 哥哥科技这个名字，我也希望一直留在那里。
很多人提到路由器，脑子里首先出现的是一个放在墙角、会发 Wi-Fi 的白盒子。但我一直觉得，这其实把“路由器”理解得太窄了。Wi-Fi 只是它的一项功能，严格一点说，那部分更接近 AP 和 802.11。真正让我着迷的，反而是“路由”这两个字本身。
“路由”说白了就是路怎么走，是一个数据包到了网络里以后，它下一步该去哪里、最后又该从哪个出口离开的过程。要是让我用一个不那么教科书的说法来形容，我更愿意把它叫作一种赛博导航。现实里的导航是在岔路口告诉人下一步往哪里走，网络里的路由则是在一跳又一跳之间，把一个原本不知道前路的数据包送向它应该到达的地方。
我最早真正对家庭网络产生这么大兴趣，其实也是从校园网开始的。那时候为了折腾校园网，会碰到 NAT、NAPT、代理检测、出口这些东西。原来课本上很抽象的名词，一旦真的落到宿舍里，就一下子有了具体的意义：为什么几台设备可以共用一个公网出口，一个数据包出去的时候究竟带着什么身份，网关又是怎样决定它接下来应该往哪里走。
也就是从那个时候开始，我越来越喜欢研究的是数据包本身，越来越反感插件。 这可能也解释了为什么我对主网关的用途一直有一点近乎固执的看法。
主网关在一个家庭网络里的位置非常特殊。这些东西都和“一个包应该怎么走”直接相关。哪怕是我自己极端厌恶 vBRAS、家里搞 QoS 和各种流控，至少我还能理解它为什么会出现在网关上，因为它处理的仍然是经过这里的数据包。 但如果只是一个普通 Docker 应用，我就很难理解为什么一定要把它塞进主网关。
一个下载器、一个网页服务或者其他普通应用，本来放在局域网里的任何一台计算机上都能运行。它甚至可能有自己独立的容器地址，在网络意义上和另一台接入 LAN 的主机没有多大区别。既然它根本不需要“默认网关”这个特殊位置，那为什么一定要占着这个位置做？
这就像把手机带进高考考场，然后坐在那里打游戏。 不是违不违法的问题，是马上要往六角亭送了
所以我一直很喜欢 NPU、硬件 NAT 以及厂商自己做好的转发路径。它们就像网络设备自己的“显卡”，存在的目的很纯粹：让数据包更快、更直接地完成它应该完成的事情。与其把主网关变成一台什么都干的通用服务器，我更愿意让它把有限的算力、硬件和拓扑位置都花在网络本身。
这也是为什么 BroTech 很多项目最终选择了“不刷机增强原厂 Web”这条路线。
如果一台品牌硬路由的 NPU、硬件卸载、Wi-Fi 驱动和 Mesh 本来已经工作得很好，而真正让我不满意的只是后台，那么我更愿意保留这些东西，再从 Web 层把设备列表、实时网速、流量统计和网络遥测重新做好。 我没有必要为了证明自己会折腾，先把已经工作正常的数据面推倒一次。 如果一定要给这种偏执取一个名字，我有时候会开玩笑说自己是个路由原教旨主义者。 我喜欢的从来不是那个白盒子。
我喜欢的是“路由”这个过程：一个数据包进入网络，经过一次次判断，找到下一跳，穿过不同的链路，最后抵达它应该去的地方。 让路由器认真做路由。 对我来说，这件事本身就已经足够有意思了。
如果你已经一路看到这里，最后还是想问：
为什么叫哥哥科技？
答案没有第二个版本。
因为我爱着我的家，我们三兄弟。
❤️
BroTech 的 GitHub 主页是 github.com/ucxn，多品牌硬路由项目可以看 Bro-Stat，中兴原厂后台增强项目是 ZTE-Stat_Max，SourceForge 发布页则保留在 sourceforge.net/projects/zte/。
各子项目的许可证以对应仓库中的 License 文件为准。
BroTech / 哥哥科技
Code what matters.
因为有个为哥哥而生，服务于弟弟的：哥哥科技。