UTM允许使用串口连接到物理终端，这使得用户界面非常像SSH登录后字符模式界面一样。只需要像下面这样操作：

1. 在运行虚拟机前，打开虚拟机设置；
2. 在“设备（Devices）”一栏右键删除原有的“Display”；
3. 然后增加一个“串口（Serial）”设备。

把增加的Serial串口设备的“Mode”改为“内置终端（Built-in Terminal）”即可。

保存配置后启动，就会发现鼠标可以操作了。

// CombinedOutput runs the command and returns its combined standard
// output and standard error.
func (c *Cmd) CombinedOutput() ([]byte, error) {
	// ...省略部分不相关代码...
	var b bytes.Buffer
	c.Stdout = &b
	c.Stderr = &b
	err := c.Run()
	return b.Bytes(), err
}

这段代码虽然看起来十分简单，但是实际上极其容易造成一种误解：把stdout和stderr设置成“同一个Writer”是安全的。

所以我也在我自己的代码中写出了类似下面这样看起来很像又不完全像的代码：

func main() {
	cmd := exec.Command(`echo`, `123`)
	b := bytes.Buffer{}
	cmd.Stdout = io.MultiWriter(os.Stdout, &b)
	cmd.Stderr = &b
	cmd.Run()
	output := b.String()
	fmt.Println("output:", output)
	if output == `` {
		panic(`should not be empty`)
	}
}

在一台全新的服务器上，给出了如下的运行结果：时而正常、时而崩溃。

root@iv-yeh9qbzz7kh2cbeuhzh4:~# ./go1.26.1/bin/go run a.go
123
output: 123

root@iv-yeh9qbzz7kh2cbeuhzh4:~# ./go1.26.1/bin/go run a.go
123
output:
panic: should not be empty

goroutine 1 [running]:
main.main()
	/root/a.go:20 +0x415
exit status 2

这让我很费解。按照正常理解，stdout和stderr在进程内是两个不同的描述符，对应到两个文件，也就意味着：它们可以被多线程同时写。所以，上述写法一定是线程不安全的，会造成数据竞态。但是Go语言本身就能把它们设置为同一个Write呢？而我，只是模仿Go的标准库写了差不多的代码。

如果再去看看Cmd.Stdout/Stderr的文档，有下面的说明：

type Cmd struct {
	// If Stdout and Stderr are the same writer, and have a type that can
	// be compared with ==, at most one goroutine at a time will call Write.
	Stdout io.Writer
	Stderr io.Writer
}

这里的文档正好解释了上面的问题：如果是同一个Writer且==，Write同一时刻只会被一个goroutine调用。这就保证了数据的安全。但这是如何保证的呢？

当Stdout和Stderr设置到同一个Writer时，下面的Go语言代码保证了只会创建唯一一个共享的os.File：

func (c *Cmd) childStdout() (*os.File, error) {
	return c.writerDescriptor(c.Stdout)
}

func (c *Cmd) childStderr(childStdout *os.File) (*os.File, error) {
	if c.Stderr != nil && interfaceEqual(c.Stderr, c.Stdout) {
		return childStdout, nil
	}
	return c.writerDescriptor(c.Stderr)
}

// interfaceEqual protects against panics from doing equality tests on
// two interfaces with non-comparable underlying types.
func interfaceEqual(a, b any) bool {
	defer func() {
		recover()
	}()
	return a == b
}

而os.File的Write方法又调用了poll.FD.Write方法：

// write writes len(b) bytes to the File.
// It returns the number of bytes written and an error, if any.
func (f *File) write(b []byte) (n int, err error) {
	n, err = f.pfd.Write(b)
	runtime.KeepAlive(f)
	return n, err
}

poll.FD内部一进来就对写操作进行了加锁：

// Write implements io.Writer.
func (fd *FD) Write(p []byte) (int, error) {
	if err := fd.writeLock(); err != nil {
		return 0, err
	}
	defer fd.writeUnlock()
	// ...

所以综合各种以上措施后，把stdout和stderr设置成完全相同的同一个Writer是安全的。否则，应该自行加锁。

活动监视器的网络一栏非常离谱：右下角的数据接收速度明明显示10MB/s，但是上面列表里面的“接收字节数”一直不变（已排序）。第一反应就是有些进程被系统隐藏了。

然后我就尝试安装各种工具看看是哪个进程在跑流量（因为是一台非开发机，什么开发工具都没有装），然后才发现， MacOS上的各种工具对网络的调试也太难受了：netstat、ss、lsof 居然要么不能查看端口对应的进程，要么直接查无此端口……而且和linux/ai给出的用法有非常大的冲突。

然后终于找到一个名叫“nettop”的自带工具（我错了，不该安装其它的），才终于找到罪魁祸首：

$ sudo nettop -m tcp -n

                                                                                    interface         state        bytes_in       bytes_out   rx_dupe    rx_ooo     re-tx   rtt_avg   rcvsize    tx_win  tc_class    tc_mgt   cc_algo P C R W
launchd.1                                                                                                             0 B             0 B       0 B       0 B       0 B
   tcp4 127.0.0.1:8021<->*:*                                                              lo0        Listen                                                                                                               -     cubic - - - -
   tcp6 ::1.8021<->*.*                                                                    lo0        Listen                                                                                                               -     cubic - - - -
   tcp4 *:22<->*:*                                                                                   Listen                                                                                                               -     cubic - - - -
   tcp6 *.22<->*.*                                                                                   Listen                                                                                                               -     cubic - - - -
apsd.603                                                                                                           1772 KiB        1128 KiB    10 KiB   150 KiB    20 KiB
   tcp4 192.168.10.230:59045<->17.57.145.152:443                                          en0   Established        1772 KiB        1128 KiB    10 KiB   150 KiB    20 KiB   3.50 ms   128 KiB    44 KiB        RD         -    prague - - - -
symptomsd.669                                                                                                         0 B             0 B       0 B       0 B       0 B
   tcp6 *.64301<->*.*                                                                                Listen                                                                                                              BG    prague - - - -
searchpartyd.773                                                                                                   9774 B          8585 B       0 B       0 B       0 B
rapportd.1092                                                                                                       174 KiB         150 KiB  2856 B       0 B    4845 B
   tcp6 *.64349<->*.*                                                                                Listen                                                                                                               -    prague - - - -
   tcp6 *.64348<->*.*                                                                                Listen                                                                                                               -    prague - - - -
   tcp6 fe80::1cde:a36f:4902:1e95%en0.57836<->fe80::84a:b198:e9cd:91d7%en0.50635          en0   Established          85 KiB         104 KiB     0 B       0 B    1702 B   239.00 ms   128 KiB   128 KiB        BE         -    prague - - - -
   tcp6 fe80::1cde:a36f:4902:1e95%en0.57836<->fe80::1897:c369:d7bb:aa07%en0.63315         en0   Established          88 KiB          46 KiB  2856 B       0 B    3143 B    60.56 ms   128 KiB   128 KiB        BE         -    prague - - - -
   tcp6 *.57836<->*.*                                                                                Listen                                                                                                               -    prague - - - -
   tcp4 *:57836<->*:*                                                                                Listen                                                                                                               -    prague - - - -
identityservice.1114                                                                                                 10 KiB        3946 B    1569 B       0 B     651 B
   tcp6 fe80::3f65:cae2:46a8:ff50%utun4.1025<->fe80::ec40:c110:5d9:6c75%utun4.1026      utun4   Established        9003 B          2697 B    1308 B       0 B     415 B    45.88 ms   128 KiB   127 KiB        RV         -    prague - - - -
   tcp6 fe80::3f65:cae2:46a8:ff50%utun4.1024<->fe80::ec40:c110:5d9:6c75%utun4.1024      utun4   Established        1282 B          1249 B     261 B       0 B     236 B     0.00 ms   128 KiB   128 KiB       CTL         -    prague - - - -
ControlCenter.1210                                                                                                    0 B             0 B       0 B       0 B       0 B
   tcp6 *.5000<->*.*                                                                                 Listen                                                                                                               -    prague - - - -
   tcp4 *:5000<->*:*                                                                                 Listen                                                                                                               -    prague - - - -
   tcp6 *.7000<->*.*                                                                                 Listen                                                                                                               -    prague - - - -
   tcp4 *:7000<->*:*                                                                                 Listen                                                                                                               -    prague - - - -
firefox.1451                                                                                                        238 KiB         582 KiB  3494 B    5032 B    1448 B
   tcp4 192.168.10.230:58250<->34.120.208.123:443                                         en0   Established        2404 B          9443 B       0 B       0 B       0 B     2.91 ms   128 KiB    72 KiB        BE         -    prague - - - -
   tcp4 192.168.10.230:58248<->151.101.129.91:443                                         en0   Established          30 KiB          24 KiB   815 B       0 B       0 B     3.59 ms   128 KiB    68 KiB        BE         -    prague - - - -
   tcp4 192.168.10.230:58247<->151.101.65.91:443                                          en0   Established        2203 B          3596 B      93 B       0 B       0 B     2.69 ms   128 KiB    67 KiB        BE         -    prague - - - -
   tcp4 192.168.10.230:58245<->23.217.118.24:443                                          en0   Established        1009 B          3454 B       0 B       0 B       0 B     4.81 ms   128 KiB    71 KiB        BE         -    prague - - - -
   tcp4 192.168.10.230:58231<->45.12.90.213:443                                           en0   Established         176 KiB         531 KiB  2493 B    5032 B    1448 B     6.91 ms   128 KiB   372 KiB        BE         -    prague - - - -
   tcp4 192.168.10.230:58225<->34.107.243.93:443                                          en0   Established        1290 B          3475 B       0 B       0 B       0 B     3.00 ms   128 KiB    72 KiB        BE         -    prague - - - -
   tcp4 192.168.10.230:58252<->151.101.129.91:443                                         en0   Established        5084 B          3030 B      93 B       0 B       0 B     3.12 ms   128 KiB    67 KiB        BE         -    prague - - - -
Code Helper.1609                                                                                                     14 KiB        7824 B     854 B       0 B       0 B
   tcp4 192.168.10.230:58243<->13.66.138.105:443                                          en0   Established        6949 B          3494 B     279 B       0 B       0 B     3.12 ms   128 KiB    60 KiB        BE         -    prague - - - -
ChatGPTHelper.1620                                                                                                 5961 B          4682 B     793 B       0 B       0 B
   tcp4 192.168.10.230:60744<->104.18.32.47:443                                           en0   Established        5961 B          4682 B     793 B       0 B       0 B     3.69 ms   128 KiB    60 KiB        BE         -    prague - - - -
Raycast.1635                                                                                                          0 B             0 B       0 B       0 B       0 B
   tcp6 *.7265<->*.*                                                                                 Listen                                                                                                               -    prague - - - -
maha-darwin-arm.1725                                                                                                  0 B             0 B       0 B       0 B       0 B
   tcp6 *.6242<->*.*                                                                                 Listen                                                                                                               -    prague - - - -
nginx.1765                                                                                                            0 B             0 B       0 B       0 B       0 B
   tcp4 *:443<->*:*                                                                                  Listen                                                                                                               -    prague - - - -
ChatGPT.3532                                                                                                       4919 B          5906 B       0 B       0 B       0 B
WeChat.55887                                                                                                        262 KiB          89 KiB   177 B      12 KiB  8489 B
   tcp4 127.0.0.1:14023<->*:*                                                             lo0        Listen                                                                                                               -    prague - - - -
   tcp4 127.0.0.1:14022<->*:*                                                             lo0        Listen                                                                                                               -    prague - - - -
   tcp4 127.0.0.1:14019<->*:*                                                             lo0        Listen                                                                                                               -    prague - - - -
   tcp4 127.0.0.1:14016<->*:*                                                             lo0        Listen                                                                                                               -    prague - - - -
   tcp4 127.0.0.1:14013<->*:*                                                             lo0        Listen                                                                                                               -    prague - - - -
   tcp4 192.168.10.230:57856<->157.255.191.88:80                                          en0   Established         262 KiB          89 KiB   177 B      12 KiB  8489 B    91.25 ms   256 KiB   324 KiB        BE         -    prague - - - -

这玩意儿的输出倒是非常的清晰明了，一眼就看出了哪个进程在跑流量：其中一个名为“idleassetsd”的进程（现场已破坏）。但是……搞笑的事情出现了：此进程在活动监视器里面不存在，是一个被系统隐藏了的进程！（无论是按名字搜、还是PID排序后人肉搜。）

网上说这是一个系统下载高清壁纸和动态壁纸的进程……啊？你是怎么敢偷偷跑我超过80G流量的？OnlyAppleCanDo。

另1：把Wi-Fi设置为低数据模式（low data rate）无效。
另2：我以为OpenWRT天生就很厉害，结果发现连个按设备查看网速的功能都没有，最终还是祭出了上古时代的iftop工具。

$ ssh cudy
** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.
** The server may need to be upgraded. See https://openssh.com/pq.html

大意是：当前服务器使用了非后量子安全的密钥交换算法，虽然现在能破解此算法的量子计算机还没有被发明出来，但是数据可以先被存储起来，等能破解此密钥的量子计算机发明出来以后再被解密。即：先窃取、后解密。

我以为我一直最喜欢的ED25519算法已经不能用了，其实不完全算是，看了上面的链接发现是又新出来了两个算法：

1. sntrup761x25519-sha512

   sntrup761   x   25519   -   sha512
   │                │          │
   │                │          └─ 哈希函数
   │                └─ 经典 ECDH
   └─ NTRU 家族后量子 KEM
   

2. mlkem768x25519-sha256

   mlkem768   x   25519   -   sha256
   │               │          │
   │               │          └─ 哈希函数
   │               └─ 经典椭圆曲线 DH
   └─ 后量子 KEM（NIST 标准）
   

ED25519没有被废除，只是又引入了两个长度超级超级长的组合算法。前者是固定的32字节，而后两者的长度竟然达到了≈1024字节。注意是字节，不是位。逆天。但是最终在交换时的密码是它们结合起来后再经SHA256/SHA512用KDF算法派生出来的新密钥。

太强大了。但是对我目前的内网主机来说用处应该不大，目前也没有必要升级使用，所以我决定关闭警告提示。

做法非常简单，只需要在“~/.ssh/config”的最最最前面加上以下配置就可以了：

Host *
	WarnWeakCrypto no

加在最前面的目的是为了对所有机器生效。

厌倦了Intel NUC的风扇狂转，突发奇想把32TB的硬盘柜插在了路由器屁股后面，一句话安装了USB存储模块²后，居然秒识别？？！那我就得想办法榨干它的性能价值了！然后就是如何把它分享给局域网，OpenWRT的包管理这么好用，应该有好用的UI？安装Samba的时候竟然让我选Samba还是Ksmbd³。前者让我不适；第一次听说后者，仔细研究了一下：

1. 太好了，内核模块，性能提升，没有历史包袱（旧协议支持）；
2. 能用 ksmbd.adduser <username> 一键添加用户；
3. 第一次让我明白Samba的用户系统是和Linux分开的；⁴

小而美的东西，依旧让我着迷：

然后用luci-app-ksmbd界面上操作分享，简直不要太简单：

虽然我很希望SFTP(ssh)能一统天下，但是为了跨平台兼容性考虑，我还是折服了。

起因是：最近些年一直旅居比较多，家里的宽带太贵被我停掉了，换成了随身WiFi➕️旅行/便携/迷你路由器的组合套装。没错，我选择了大家在推特上推荐得很多的一套组合：中兴F50随身WiFi➕️Cudy TR3000路由器，网速快时能跑到 150Mb+，差强人意。

我的套装中，除了这两个外，还有一个树莓派Zero 2W盒子，非常小巧，作用：旁路由网关。长期使用了一年左右，发现其在大流量时不稳定，容易死机。所以闲鱼卖掉了，这才准备折腾OpenWRT的，从此又可以少一个设备了。¹

准备内容

Cudy TR3000 一台

建议上256MB大闪存版，这样的话，安装完标准版本布局后还剩下大约200MB可自由使用。对于128MB的版本，安装完后仅剩下~40MB可使用。两者的差价仅20元左右。本文的内容目前只针对256MB大闪存版。

另外，Cudy从2025年第44周开始生产的设备使用了新的闪存芯片，OpenWRT从24.10.5(版本号虽然看似是去年的，实质是2025年12月发布的)才开始支持，以往的旧版本是刷不进去的，刷写时会被警告，强刷也没有效果。具体的生产批次可以从外壳背后的序列号(SN)看到，形如：SN: TR300025XX...，其中的25XX即是生产年份和周数。

固件：中间固件、OpenWRT固件

正常来说，固件更新只需要一次：从设备管理后台选择“固件升级”，选择新的固件，等待升级完成。但是Cudy有点儿不一样，它需要两次。为什么？因为：Cudy官方默认只允许固件升级到带RSA签名的官方固件。显然，社区没有Cudy的签名私钥是不可能给出正确签名的固件的，所以不能一步到位。但是官方比较良心，给出了一个所谓的“中间固件”，它是签过名的。并且，它的后台允许通过它升级到未签名的OpenWRT固件。

中间固件官方下载网盘：TR3000 256MB Flash V1 (not for TR3000 V1) - Google 云端硬盘。文件名：cudy_tr3000-256mb-v1-sysupgrade.bin。变更过，OpenWRT官方引用的名字已经不对了。

OpenWRT固件官方下载地址：OpenWrt Firmware Selector。搜索“Cudy TR3000 256mb v1”即可找到预编译好的固件。点击“SysUpgrade”即可下载到固件，名为：openwrt-24.10.5-mediatek-filogic-cudy_tr3000-256mb-v1-squashfs-sysupgrade.bin。从名字中的“squashfs”可以看到这是一个持久的文件系统，而不是另外一个“kernel”按钮下载到的“initramfs”。后者用于直接在内存中运行整个文件系统，用于系统维护，而不是长久使用。

第一次下载这个OpenWRT固件的时候太震惊我了，因为它仅仅只有9MB大小！其中：Linux Kernel 4.5MB，OpenWRT 根文件系统 4.5MB。要知道，我一个用Go写的几百上千行的小程序，已经11MB，辣鸡啊。

有线网络环境

中间固件、最终的OpenWRT默认均不开启WiFi网络，所以如果没有有线网络环境的话，升级过程是无法完成的。

如果是常规的台式机电脑，基本上都配有RJ45规格的网口。找一根网线把它和Cudy背后的LAN口连起来即可在没有WiFi的情况下直接访问管理后台。

我没有台式机，只有一台MacBook，它没有网口。所以我翻出了一个古老的TP-LINK迷你路由器，型号为TL-WR702N²。官方早已停产，但是在闲鱼上二手的价格不足¥10即可拿下，货源非常多买一个备用还是非常不错的。把此路由器的工作模式换成“AP(Access Point)”即可实现：有线网络↔️无线网络。只做数据接入转发，无DHCP、NAT等任何功能。它的出厂默认应该就是AP默认，如果不是的话，连上背后的WiFi后改一下即可；或者按一下重置按钮恢复出厂设置。

因为这台AP一直处于上电模式，所以WiFi一直存在。所以更建议在升级的过程中使用此WiFi访问Cudy路由器的后台，而不是直接连接Cudy的WiFi。

相关网页

• OpenWRT官方的Cudy产品硬件介绍页面：[OpenWrt Wiki] Cudy TR3000
• Cudy官方的TR3000固件下载页面：Downloads for TR3000 1.0 – Cudy

固件升级

前面介绍的准备工作内容准备好后就可以着手固件升级了。

首先是中间固件的刷写：

1. 进入Cudy的路由器后台 http://192.168.10.1/，依次找到“高级设置”➡️“系统”➡️“固件升级”。

2. 浏览并找到固件文件：cudy_tr3000-256mb-v1-sysupgrade.bin。

   

   然后点“继续”就可以开始刷写中间固件了。

3. 等待几分钟就可以刷写成功了。（建议尽量用有线网络环境（含AP）连接刷新，否则可能看不到图二刷写结束的画面时WiFi就被断掉了。但是没关系，盲等待几分钟也可以完成刷写过程。）

   

   

4. 中间固件是没有启动WiFi的，只能通过有线网络访问。新的管理后台地址：http://192.168.1.1/。用户名是root，没有密码。

   

   中间固件其实也是个OpenWRT变种，体验上和完整的标准版没有太大差异，可以把玩一下。但是它的文件体积比标准版本大了一半，我不太理解，明明它的唯一用途就是拿来升级到正式的OpenWRT系统？（有点想阴阳IE浏览器只是拿来下载Chrome的一样）

   

   注意其中的版本号，是23.05-SNAPSHOT。因为它和最终的版本长相几乎完全一样，所以好像以为没有升级成功。

然后就是通过中间固件升级到最终正式版本OpenWRT系统了：

1. 在新系统后台内依次找到“系统”➡️“备份与更新”➡️“更新固件”，并选择固件：openwrt-24.10.5-mediatek-filogic-cudy_tr3000-256mb-v1-squashfs-sysupgrade.bin。注意核对名字，然后确认上传。

   

2. 备份选项：无须备份现有配置

   

3. 等待刷写新系统。期间红灯会闪烁。

   

4. 等待几分钟后刷新一下浏览器，就可以进入新的后台，还是没有密码。

   

   看起来是不是长得一模一样？

5. 不过，版本号变了，现在是24.10.5。

   

初印象

主题不对？

默认的主题看起来可能不像OpenWRT？没错。更常见的应该是这个：jerrykuku/luci-theme-argon。

SSH访问

SSH应该是默认就打开的。如果不是：“系统”➡️“管理”➡️“SSH Access”启用即可。

Last login: Mon Dec 29 02:04:08 on ttys011
Downloads → ssh root@192.168.1.1


BusyBox v1.36.1 (2025-10-19 16:37:45 UTC) built-in shell (ash)

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 OpenWrt 24.10.4, r28959-29397011cc
 -----------------------------------------------------
root@cudy:~#

建立WiFi

在“Network”➡️“Wireless”处可以看到当前板子的硬件支持的无线硬件（长得像个信号塔、天线一样的东西）。在Cudy TR3000上，radio0是2.4GHz设备、radio1是5GHz设备。

点右边的“Add”，可以新建一个热点。可以想建多少个就建多少个！！！太神奇了。

另外，我的宽带接入是走的随身WiFi，所以我的radio1下面有一个Mode：Client的WiFi，这是用来做宽带接入的（即：WISP），其它两个才是家庭网络WiFi。

那……啥？

不行，我这个文章是用来安装非常标准的OpenWRT的，有需要的话，可以换其它的发行版，比如：ImmortalWRT、KWRT……

我不一样，我还是喜欢干净纯净的系统，我选择自己修改iptables，用自己写的隧道工具🤪。

在OpenWRT内开启之后，所有连接到WiFi的设备就自动翻🧱了。对象再也不会嫌弃每次都要手动改网关和DNS才能做到了。

恢复原厂固件（网络方式）

啊……不是刚刚才安装完成吗？这就要恢复了？

开机时，Bootloader会检测机身左侧的Reset键是否被按下，如果有被按下，则会尝试下载新固件并安装。过程如下：

1. 它会把路由器自身的IP地址设置成192.168.1.112；
2. 向固定目标为192.168.1.88:96端口处的TFTP服务器下载名为recovery.bin的固件；
3. 下载成功后便开始全新安装新的系统。

由于是通过网络下载固件，所以还是需要用网线把Cudy连接到电脑上：

1. 如果电脑有LAN口，则直接用网络连接即可；
2. 如果没有LAN口（大多数笔记本），则可以用AP把LAN转成WiFi后连接。

搭建一个TFTP服务器，把recovery.bin放在其工作目录内即可。记得把电脑的IP地址手动改成192.168.1.88哦。

由于我是在MacBook上使用的，很多教程推荐使用的Windows版tftp64.exe我无法使用。并且在试用过几个开源版本后我都不满意，所以我自己也写了一个，足够简单、小巧、易用。开源地址：

movsb/tts: A tiny/trivial² TFTP server that just works.

在右边的Release下载页面即可下载到主流各平台的预编译的二进制。随意找个空目录，放置好需要被下载的文件，然后运行即可。

值得注意的是，网络很多教程和视频说需要按下RESET键10秒。在我实践看来，这是完全没必要的，仅仅需要按下RESET并插上电源，直到TFTP服务器接收到下载请求了即可松开，这只需要大概2秒钟的时间。向TFTP请求下载时其使用的块大小选项只有1KB左右，而recovery文件大概有30MB，所以还是需要一定的时间来下载的。不过好在我前面写的TFTP服务器有实时进度显示，不用担心是卡住了。

等待几分钟便会下载完成，并且会继续花几分钟时间来重写系统。等待红灯闪烁完毕白灯(或红灯)常亮即代表系统重装完成。

没了

嗯。

但是由于它是基于UDP的，甚至可以直接构造IP包，所以可以离谱到裸机都可以跑，完全不需要操作系统或复杂的网络栈，实现也非常简单。所以，它能在嵌入式设备上“发光发热”就不足为奇了。

由于不知道具体的协议，硬是给我如何给我的Cudy TR3000路由器恢复原厂固件带来了麻烦。我甚至搞不懂为什么要给电脑设置手动IP地址。更好奇的是 U-Boot 如何能“塞”进去一个网络栈以下载固件？

看了4️⃣篇RFCs文档才知道了协议的具体细节。加上在一头雾水的情况了试用了几个别人写的，真是一言难尽。所以就决定自己写个最简能用的就行。我为什么不用系统的/自己安装？

1. MacOS上好像是自带的，但是要启动为一个后台服务，甚至还要launchctl来启动，太抽象了

2. Linux作为嵌入式开发主力设备，居然不自带，虽然前几天用过一次并成功了，还是觉得麻烦

3. Windows上有一个比较常见的，但是实在丑拒，另外，我没有 Windows 系统。

   

其实最大的问题是：不能跨平台使用。除了 Windows 开发，谁现在还用 Windows 开发啊？

我的项目地址在这里：movsb/tts: A tiny/trivial² TFTP server that just works.。

零依赖，零配置，开箱应用，用完即弃。

我的目的明明是为了救砖，你们为什么搞那么复杂？

服务器运行示例：

Downloads → sudo ~/code/tts/tts
2025/12/29 22:46:52 192.168.10.230:59750 ReadFile: 2.docx [{tsize 0} {blksize 1024} {rollover 0}]
2025/12/29 22:46:52 192.168.10.230:59750 Ignored unsupported option: {tsize 0}
2025/12/29 22:46:52 192.168.10.230:59750 Ignored unsupported option: {rollover 0}
2025/12/29 22:46:53 192.168.10.230:59750 Sent block: 1/14 (7%)
2025/12/29 22:46:53 192.168.10.230:59750 Sent block: 2/14 (14%)
2025/12/29 22:46:53 192.168.10.230:59750 Sent block: 3/14 (21%)
2025/12/29 22:46:53 192.168.10.230:59750 Sent block: 4/14 (28%)
2025/12/29 22:46:53 192.168.10.230:59750 Sent block: 5/14 (35%)
2025/12/29 22:46:53 192.168.10.230:59750 Sent block: 6/14 (42%)
2025/12/29 22:46:53 192.168.10.230:59750 Sent block: 7/14 (50%)
2025/12/29 22:46:53 192.168.10.230:59750 Sent block: 8/14 (57%)
2025/12/29 22:46:53 192.168.10.230:59750 Sent block: 9/14 (64%)
2025/12/29 22:46:53 192.168.10.230:59750 Sent block: 10/14 (71%)
2025/12/29 22:46:53 192.168.10.230:59750 Sent block: 11/14 (78%)
2025/12/29 22:46:53 192.168.10.230:59750 Sent block: 12/14 (85%)
2025/12/29 22:46:53 192.168.10.230:59750 Sent block: 13/14 (92%)
2025/12/29 22:46:53 192.168.10.230:59750 Sent block: 14/14 (100%)
2025/12/29 22:46:53 192.168.10.230:59750 Sent completed successfully.
2025/12/29 22:46:53 192.168.10.230:59750 Connection closed.

客户端运行示例：

tmp → tftp 192.168.10.230 69
tftp> options on
Support for RFC2347 style options are now enabled.
Support for non-RFC defined options are now enabled.

The following options are available:
	options on	: enable support for RFC2347 style options
	options off	: disable support for RFC2347 style options
	options extra	: toggle support for non-RFC defined options
tftp> blocksize 1024
Blocksize is now 1024 bytes.
tftp> get 2.docx
Received 14328 bytes during 1.0 seconds in 14 blocks
tftp>

root@cudy:~# cat /etc/config/system

config system
	option timezone 'CST-8'
	option zonename 'Asia/Shanghai'

中国的时区明明是UTC+8，这里的CST-8是个非常奇怪且少见的表示法（来自于 POSIX）¹：

• “CST”是个任意可能的名字，并不一定代表中国标准时间（China Standard Time）；
• “-8”才是用于准确计算的部分，表示本初子午线往东“+8”时区。

时区会同时被写入到/tmp/TZ这个文件中：

root@cudy:~# ls -lh /tmp/TZ
-rw-r--r--    1 root     root           6 Dec 21 00:29 /tmp/TZ
root@cudy:~# cat /tmp/TZ
CST-8

但是Go的时区处理函数并不会读取这个位置²³：

// Many systems use /usr/share/zoneinfo, Solaris 2 has
// /usr/share/lib/zoneinfo, IRIX 6 has /usr/lib/locale/TZ,
// NixOS has /etc/zoneinfo.
var platformZoneSources = []string{
	"/usr/share/zoneinfo/",
	"/usr/share/lib/zoneinfo/",
	"/usr/lib/locale/TZ/",
	"/etc/zoneinfo",
}

甚至也不在环境变量“TZ”中。虽然会fallback到 /etc/localtime 中，但是在OpenWRT上，这是一个无效的软连接。

尝试在现有的Linux系统中拷贝一个能用的时区数据库文件（shanghai）并软连接过去，发现是可以使用的：

root@cudy:~# ls -lh /etc/localtime
lrwxrwxrwx    1 root     root          14 Dec 21 00:29 /etc/localtime -> /root/shanghai

好了，把它加在启动脚本里面开机自动软连接即可：

或者，直接下载上述文件并覆盖/etc/localtime：

$ wget https://blog.twofei.com/2254/shanghai
$ mv shanghai /etc/localtime

用C或者Zig写的程序貌似都有此问题，以上的做法能够一次性全部解决。

但是也有一个问题：时区不会随着在System页面上的修改而自动修改。不经常出国的话完全没有问题。我也不想安装全量的zoneinfo包。

在不借助外部工具、服务的情况下，可以自己从 亚太互联网络信息中心（Asia-Pacific Network Information Centre，APNIC） 找到所有分配给中国的地址段，然后判断目标 IP 地址是否在范围内即可。（部分群体对这个数据库应该非常熟悉）

纯文本数据库地址：http://ftp.apnic.net/apnic/stats/apnic/delegated-apnic-latest。

这个数据库表格的数据始终是最新的。数据格式大概长这样：

apnic|AU|ipv4|1.0.0.0|256|20110811|assigned
apnic|CN|ipv4|1.0.1.0|256|20110414|allocated
apnic|CN|ipv4|1.0.2.0|512|20110414|allocated
apnic|AU|ipv4|1.0.4.0|1024|20110412|allocated
apnic|CN|ipv4|1.0.8.0|2048|20110412|allocated
apnic|JP|ipv4|1.0.16.0|4096|20110412|allocated
apnic|CN|ipv4|1.0.32.0|8192|20110412|allocated

过滤出包含“|CN|ipv4|”的行就能得到中国所有的 IPv4 地址网段（CIDR）。

CIDR（即 IPv4 ➕️ Prefix length）一共是 5️⃣ 个字节，为了节省空间，我把它们直接用二进制方式写到文件中了，而不是用 ASCII 一行一个的方式。

文件最终的大小是 40KB，足够小巧到可以无压力地直接嵌入到程序二进制内。远小于网上找到的各种什么 geoip 地址库（比如：GeoLite.mmdb）。当然，我这种做法仅限于判断 IP 所属国家是否是中国，更不含具体的省市等信息。但是对于我的需求来说，足够了，而且数据还是精确的。

判断 IP 地址是否在 CIDR 集合内有很多现成的高效的实现，比如最常用的：前缀树/基数树/Trie。

参考我的实现：taoblog/modules/geo/geoip at master · movsb/taoblog。

作为一个长期较稳定运行超过十年的网站，我会尽量少地依赖外部工具或服务。

前两天有朋友找到我说要部署一份我的博客系统，让我编译一个 Linux/AMD64 版本（实际上我一直是用的这个版本，只不过是 GitHub Actions 编译到容器里面的，但可以 cp 出来），我再次尝试在 MacOS 上直接 go build，再一次又被 CGO 气死了：没有看到任何 build tags 的 sqlite3.Error 竟然无法编译，找不到定义。

而恰好前几天又正好在群里和雨帆⛵️聊起 sqlite3 的问题，仔细看了前面的对比以及文档，发现 WASM 版本 CGO 版本竟然性能几乎无异，所以就动手切换了。实际上改动的代码只有几行¹，因为它俩都是兼容 database/sql 接口标准的。

$ wrk https://blog.mac.twofei.com/
Running 10s test @ https://blog.mac.twofei.com/
  2 threads and 10 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    49.88ms   14.55ms 110.15ms   70.69%
    Req/Sec   100.23     15.07   140.00     73.00%
  2008 requests in 10.06s, 18.91MB read
Requests/sec:    199.69
Transfer/sec:      1.88MB

$ wrk https://blog.mac.twofei.com/1/
Running 10s test @ https://blog.mac.twofei.com/1/
  2 threads and 10 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     7.50ms    2.57ms  37.84ms   71.15%
    Req/Sec   670.53     42.64   737.00     86.00%
  13358 requests in 10.01s, 81.92MB read
Requests/sec:   1334.46
Transfer/sec:      8.18MB

$ wrk https://blog.mac.twofei.com/
Running 10s test @ https://blog.mac.twofei.com/
  2 threads and 10 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    94.73ms   27.77ms 210.57ms   72.21%
    Req/Sec    52.77     12.82    90.00     70.71%
  1056 requests in 10.07s, 9.94MB read
Requests/sec:    104.88
Transfer/sec:      0.99MB

$ wrk https://blog.mac.twofei.com/1/
Running 10s test @ https://blog.mac.twofei.com/1/
  2 threads and 10 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    12.22ms    4.09ms  42.32ms   70.56%
    Req/Sec   411.22     27.02   474.00     74.00%
  8201 requests in 10.02s, 50.30MB read
Requests/sec:    818.50
Transfer/sec:      5.02MB

“首页”因为几乎没有缓存的原因，相比于“单篇文章”来说性能非常差，在我的预期内。但是从 CGO 换成 WASM 竟然整体性能掉了一半让我震惊。换还是不换呢❓

换，当然要换，对于我这样的小破站来说，即便是只有几百 QPS 的性能也完全没问题。最主要的是：编译速度/跨平台编译容易程度都极大地提高了。还有一点，几百 QPS 显然是另有隐情。

所以我就 profile 了一下 cpu：

好了，知道问题所在了：七年前（至少）写的查“相关文章”的接口没有缓存（大量 IN、OR、!= 语句），瓶颈全在这儿。

加了缓存后，效果改善就“很大”了：

$ wrk https://blog.mac.twofei.com/1/ 
Running 10s test @ https://blog.mac.twofei.com/1/
  2 threads and 10 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   447.34us    1.11ms  54.96ms   94.86%
    Req/Sec    20.70k    14.85k   36.16k    51.98%
  415804 requests in 10.10s, 320.85MB read
  Non-2xx or 3xx responses: 383097
Requests/sec:  41167.80
Transfer/sec:     31.77MB

直接起飞到了 4万 QPS。但是仔细观察，发现错误非常多，nginx 的 upstream 不够用了。我直接访问 localhost：

$ wrk http://localhost:2564/1/
Running 10s test @ http://localhost:2564/1/
  2 threads and 10 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.34ms    1.33ms  35.59ms   95.15%
    Req/Sec     4.03k   216.01     4.33k    94.06%
  80920 requests in 10.10s, 493.67MB read
Requests/sec:   8012.03
Transfer/sec:     48.88MB

这次就只有 8000+ 了（全部成功）。

好了，今天的优化至此结束。

测试机器：MacBook Pro 2023 14-inch, M2, 32GB.

再补一下（实时）堆内存占用，压测过后的数值。

完全可以接受的程度。

作者又把WASM版本的SQLite3用wasm2go直接翻译成了go代码，升级后重新跑了一遍，性能有所提升，内存有较大下降：

$ wrk http://localhost:2564/1/
Running 10s test @ http://localhost:2564/1/
  2 threads and 10 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.19ms  692.07us  11.88ms   79.97%
    Req/Sec     4.40k   236.63     4.73k    76.00%
  87512 requests in 10.00s, 549.08MB read
Requests/sec:   8748.33
Transfer/sec:     54.89MB

我才发现我这个测试是基于本地文件系统是真实数据的。我改成内存数据库库以及demo选项后，性能直接起飞：

$ ./taoblog server --demo

$ wrk http://localhost:2564/1/
Running 10s test @ http://localhost:2564/1/
  2 threads and 10 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   649.46us  335.92us   4.26ms   74.67%
    Req/Sec     7.92k   273.85     8.31k    79.50%
  157551 requests in 10.00s, 295.85MB read
Requests/sec:  15751.83
Transfer/sec:     29.58MB

直接翻了一倍。太强了。