技术论文

凌晨三点，技术论文实验室的技术论文荧光灯嗡嗡作响，我盯着屏幕上那条折线图——它终于不再是技术论文一条平直的死亡线了。数据在第七十二小时出现了陡峭的技术论文上升，像心电图上的技术论文一次起搏。这感觉比中彩票还爽，技术论文虽然我从不买彩票。技术论文

这里说的技术论文技术论文，不是技术论文那种发表在期刊上、被引用几百次的技术论文学术巨作。我说的技术论文是另一种东西——每个技术人电脑里都躺着几篇的那种。它们没有DOI编号，技术论文没有同行评议，技术论文甚至没有完整的技术论文参考文献。但它们记录着最真实的技术论文技术演进。我手头这篇，题目叫《关于在老旧服务器上强制开启BBR拥塞控制算法的可行性研究》，实际上就是我在一堆报废硬件上折腾了三个周末的流水账。

第一篇这样的“野论文”诞生于2019年冬天。那会儿公司机房有台戴尔R730，配置不差，但跑起数据库来总是卡顿。我检查了CPU、内存、磁盘IO，全都在合理范围内。最后用ss -s一看，发送队列里堆满了数据包。问题出在TCP拥塞控制上——默认的Cubic算法在丢包率稍高的网络环境里表现得太保守了。我查了一圈资料，发现Google早把BBR算法开源了，但Linux内核版本太低，得手动编译模块。

编译过程本身没什么好说的，就是标准的./configure && make && make install。真正的坑在配置阶段。BBR需要开启fq队列规则，但老内核里的fq模块有bug，会随机丢包。我花了一个晚上读内核源码，最后在net/sched/sch_fq.c里发现一个变量初始化顺序的问题——这bug在2016年就被修复了，但CentOS 7.4的内核还带着它。当时我写了篇两千字的分析，配了三个patch方案，发在内部wiki上。没人看，除了后来接手那台服务器的同事——他说那篇东西救了他一命，省了至少两周排查时间。

这种论文的写法跟正式学术论文完全不同。不需要“本研究旨在探索”，直接写“跑个iperf3测试，发现吞吐量只有200Mbps，但带宽明明是1G的”。不需要“实验结果表明”，直接贴wireshark截图，标注哪个包触发了重传。我最近一篇是关于用eBPF跟踪Nginx连接队列溢出的，开头第一句就是“nginx -s reload之后，连接数掉了一半”。

这些东西有个共同特点：它们记录的是“当时不知道答案”的过程。学术论文是结果导向的，把探索过程都剪掉了，只留结论。但技术野论文恰恰相反，最有价值的部分就是那些错误的尝试和碰壁的经历。比如我写BBR那篇，中间有个结论是错的——我以为tcp_notsent_lowat调小能改善延迟，后来发现对BBR根本没用。但那个错误尝试本身有记录价值，因为后来有人在其他场景里用到了这个参数。

写这种文章有个窍门：把每个操作步骤都写清楚，包括输入的命令、输出的报错、当时的网络环境。这不是流水账，而是给未来的自己留线索。三个月后你再看自己的代码，完全不记得当时为什么这么写。但如果你有篇野论文记录了当时的思考过程，哪怕只是“因为试了sysctl不管用，所以怀疑是驱动问题”，都能省下大量回溯时间。

我电脑里现在有三十多篇这样的文档。有些只有几百字，记录一个临时解决方案；有些长达上万字，包含完整的性能对比数据。它们从未被正式发表，但比那些发表在顶级会议上的论文更常被翻阅。技术这东西，本质就是经验的积累和传递。正式论文是技术的骨架，这些野论文才是血肉——带着调试时的汗味和半夜三更的咖啡因气息。

回到开头那条折线图。那是我在测试一个自定义的TCP拥塞控制算法，用了强化学习来动态调整窗口大小。七十二小时的数据终于显示出比BBR更好的吞吐量表现——虽然只在特定网络条件下。这事够写一篇正经论文了，但我打算先写成野论文存在本地。等哪天有人遇到同样的问题，说不定就能搜到它，省下三个周末。