Bojie Li (李博杰)

Highly flexible software network functions (NFs) are crucial components to enable multi-tenancy in the clouds. However, software packet processing on a commodity server has limited capacity and induces high latency. While software NFs could scale out using more servers, doing so adds significant cost. This paper focuses on accelerating NFs with programmable hardware, i.e., FPGA, which is now a mature technology and inexpensive for datacenters. However, FPGA is predominately programmed using low-level hardware description languages (HDLs), which are hard to code and difficult to debug. More importantly, HDLs are almost inaccessible for most software programmers.

This paper presents ClickNP, an FPGA-accelerated platform for highly flexible and high-performance NFs with commodity servers. ClickNP is highly flexible as it is completely programmable using high-level C-like languages, and exposes a modular programming abstraction that resembles Click Modular Router. ClickNP is also high performance. Our prototype NFs show that they can process traffic at up to 200 million packets per second with ultra-low latency (< 2µs). Compared to existing software counterparts, with FPGA, ClickNP improves throughput by 10x, while reducing latency by 10x. To the best of our knowledge, ClickNP is the first FPGA-accelerated platform for NFs, written completely in high-level language and achieving 40 Gbps line rate at any packet size.

Joint project with Tianyi Cui for Microsoft Hackathon 2016.

To achieve low TCP flow completion time (FCT) in data center networks (DCNs), it is critical and challenging to rapidly recover loss without adding extra congestion. Therefore, in this paper we propose a novel loss recovery approach FUSO that exploits multi-path diversity in DCN for transport loss recovery. In FUSO, when a multi-path transport sender suspects loss on one subflow, recovery packets are immediately sent over another sub-flow that is not or less lossy and has spare congestion window slots. FUSO is fast in that it does not need to wait for timeout on the lossy sub-flow, and it is cautious in that it does not violate congestion control algorithm. Testbed experiments and simulations show that FUSO decreases the latency-sensitive flows’ 99th percentile FCT by up to ~82.3% in a 1Gbps testbed, and up to ~87.9% in a 10Gpbs large-scale simulated network.

昨天（9月25日）晚上吵架，搞到分手和删 QQ 好友，是我们吵架最严重的一次。都是因为我被指出一些毛病之后，自尊心受到打击，怒了，一下子丧失逻辑，说了很多伤人的话。我们分手了，好友删了加了几次，不过双方想通了之后和好了，我答应诚恳地道歉。静宁还去我寝室拿被套回她寝室洗、晒，我要感动哭了！在此公开发布道歉文一篇，也是给自己敲响个警钟。

教训

1. 静宁心情难过的时候，要用心安慰，这时一定不能对她所做的事情横加指责。
2. 当静宁指出我的缺点、对我提出意见的时候，不要急于给自己找台阶下，而是应当记在心里，慢慢思考，并不急于回应。只有最亲密的人才肯指出这些性格上的缺点，这些是很宝贵的建议。不能自尊心太重，要勇于承认自己的问题。
3. 不论何种情况，要避免情绪不稳定，冲动行事，出语伤人，说话不考虑后果。吵架不仅浪费时间，更是破坏感情。
4. 吵架的时候我们都不理性，完全忘了平时对方的好、一起相处的欢乐，以及分手的深远影响。尤其是我，经常说一些没有逻辑的话或者越扯越远。
5. 做人、生活、家庭和技术同等重要，应当摒弃技术至上的偏见，不能只顾着搞技术不顾感情。

事件回顾

发端

1. 昨天（9月25日）晚上张静宁并不开心，在 QQ 里跟我倾诉了很多。
2. 而我早上刚刚赶完一篇 NSDI paper，回到家没聊几句，就呼呼大睡。
3. 凌晨 00:37 醒来了，刚好这时候她也想找我。她说已经无聊的开始看网络小说了，跟我发了几段，我却说这些网络小说好无聊，建议她去看明朝那些事儿。
4. 她觉得我们无法沟通，说我完全不会哄女生。
5. 然后我就开始发飙了，说我应该专心去搞技术，让她去找愿意跟她一起玩的男生，“你说心情不好的时候，我不是想把你的心情弄好，而是想你一个人呆着去吧”。她说我不负责任。
6. 她试图缓解局面，聊起小说里泡妞的经验，然后我说不但不会这样做，反而对这种做法很反感，静宁说我可以看了提高一下情商，太直男癌了。

高潮

1. 我说“我所了解的男生基本对女生都是说假话的，不准说妹子不好，妹子说什么都得是对的，人性如此，你不愿意承认这一点罢了”。
2. 静宁非常生气，说“你自己爱说假话还黑其他人，我的朋友都很诚实”，指出我只是在给自己找借口，拉别人下水，让你自己觉得面子上好过一些。
3. 然后我就认为静宁不相信我的人品，开始赶她走了……
4. 我又扯到另一件无关的事上：“我觉得每天跟其他同学在一起讨论问题都很有趣，而跟你经常是扯一些无聊的话题，偶尔还会搞得不开心，为什么要跟一个没什么共同话题的人整天在一起，做事的时候还要时不时响应你的中断”
5. 这时候双方开始谈分手了，静宁说明天不来合肥就分手吧。我想都没想就同意了分手，以为分手是件很容易的事情，以后不联系了正好不用烦我了，全然忘了在一起一年的欢乐和双方之间的深爱。
6. 静宁提出要我道歉。我却说我需要一些主动权，不然以后就是受气包了。
7. 我给她导出了聊天记录，静宁删了我好友，并拉黑了通讯录（每次吵架都爱干这些）。这是我们加好友的第 383 天。
8. 这时候是凌晨 2 点 25 分。我们分别在人人网上发了状态。

发展

1. 我们都睡不着。40 分钟后，静宁发了加好友请求。
2. 我这时候开始从情绪中清醒过来，意识到前面是冲动说的胡话，试图挽回。
3. 静宁回顾了聊天记录里我说的伤人的话。她说 “你很自私，你吵架的时候觉得自己没有需求，觉得我浪费你时间，你不懂的珍惜和爱护女生，你不配拥有”
4. 我承认了错误，静宁要求我写一篇文章发到网上，并且明天来合肥正式道歉。然后又把好友删了。

缓和

1. 半个小时后（凌晨四点半），静宁发了一个知乎问题《男票情商低，吵架无逻辑各种伤人，要分手吗？》发完感觉，明明我吵架的时候思维混乱、逻辑不清，就不应该跟我提分手激化矛盾，所以应该包容我，哪怕是说伤人的话。
2. 静宁觉得这只是突然吵架拌嘴，要我诚恳道歉并且保证以后不再犯。气氛顿时缓和了。
3. 静宁让我把知乎问题标题中的 “情商低” 改成了 “容易冲动”。我们开始理性思考吵架中暴露出的问题。
4. 我回顾了小时候跟妈妈吵架的事，认识到自己的问题是长期做优秀学生做惯了，自尊心太强，听不进别人的不肯定。静宁说，我和别人争论的时候，或者自己做错了什么的时，总是快速同意或者随便扯一个结论，都似乎是想给自己找一个台阶下。
5. 静宁指出了另一个很好的点，说我还有一种技术至上的偏见，而对做人、生活、家庭并不关心。
6. 我很后悔把静宁赶走，轻易同意分手。

尾声

1. 早上7点买了周日去合肥的票（周六除了一等座和商务座的票，实在买不到啊，从南京或者天津转车也不行。一等座太贵了……）
2. 其实早上可以买周六高铁到最近一个车站的票，就四个多小时，后半段站着，出站补票就行了。
3. 中午发现 LUG 讨论组里都在议论我们发生了什么……把内部矛盾捅出去让大家担心，真是惊扰诸位了。
4. 今天下午醒来，去公司整理了实验代码和数据，抱果神大腿去清华品尝了美食节，晚上回来开始阅读聊天记录、总结教训。

避免伤害爱你的人

上次严重到要分手的吵架，是大概三个月以前了。也是让讨论组都知道了。我们当时想吵架后分开几天长长教训，不过还是第二天和好了。静宁说，应该考验一下我该怎么做，不过每次都做不到坚持不理我。看起来是一个悖论，早些和好就教训不深刻，晚些和好就给双方更大的伤害。现在异地，要是长时间不联系，就感情越来越淡，最后就真的分手了。我觉得，吵架还是不能冷处理，拖得越久伤害越大，要及时道歉。

今天（9月26日）静宁去我寝室把被套拿回寝室洗了，我说不用麻烦你了，但她还是去做了。我感动得要哭了！昨天晚上我对她这么不好，说了这么多伤人的话，还是她半夜主动找我和好，今天还对我这么好，实在是太感动了。

找到真爱不容易，一定要珍惜。下次想要冲动吵架之前，看看我们在 tower 上的吵架总结和这篇文章，想想平日相处里对方的好，也许就不会这么轻易伤害爱你的人了。

几次吵架，导火索都是我容不得静宁说我不好。尽管我自己知道存在这些缺点，还是容不得静宁说，一说就想要找各种借口。这不仅是双方感情的问题，更是个人心理的问题。整天被膜拜着不是好事，自尊心太强，导致我总是回避自己的短板。能有一个人耐心指出我的不足，是再好不过了。

题记：暑假我搞挂了 LUG 的开源软件镜像服务器，惩罚之一就是补交从 LUG 书库 所借书籍的读书笔记。距初读此书已两年有余，可以说是《浪潮之巅》为我打开了 IT 产业的大门，在此与诸位看官分享拙见。

《浪潮之巅》有两条主线：一是科技公司的起落沉浮；二是高科技行业的规律性。这本书有趣的地方在其前一条主线，把科技公司的历史写得像小说一样精彩。而这本书的价值则主要在其后一条主线，即透过现象看规律。本文将总结《浪潮之巅》中各个商业帝国的兴起、荣耀与衰落，以及公司和计算机工业的发展规律。

2015 年 7 月 28 日，世界上应用最广泛的 DNS 服务器 bind9 爆出了一个严重的拒绝服务漏洞（CVE-2015-5477）。

一点背景知识：DNS 是把域名映射到 IP 地址的服务。当你访问 google.com 时，计算机就会问你所在小区的 DNS 服务器，google.com 的 IP 地址是什么？如果你的邻居刚好也在访问 google.com，DNS 服务器就会直接返回其 IP；不然，这个 DNS 服务器就会去问 Google 官方的 DNS 服务器，得到 google.com 的 IP 地址，并返回给你。这个小区的 DNS 服务器叫做递归 DNS；递归 DNS 挂了，会导致它服务的区域无法上网。Google 官方的 DNS 服务器叫做权威 DNS；权威 DNS 挂了，会导致它所服务的网站从地球上消失。

DNS 递归查询 (图片来源）

这个漏洞严重到什么程度呢？只要发一个 UDP 数据包，就能搞挂一台 DNS 服务器。不管是递归 DNS 还是权威 DNS，不管是 bind9 做了什么样的配置，只要这个数据包被 bind9 进程接收了，它就会立刻抛出异常，终止服务。

5 月中旬，LUG 举行了白帽子大赛，对校内网站进行白帽子漏洞测试，并按照漏洞来评奖。这次活动举行得还算顺利，几天时间里找到了校园网络系统的上百个漏洞。然而不知是什么原因引来了骇客。

5 月 31 日凌晨，监控系统接连发出的报警打破了深夜的宁静，LUG 的数十台服务器毫无预兆地接连出现故障，震惊中外的 LUG 服务器被黑事件拉开了帷幕。从 6 月 1 日服务器管理员 gyf 向网络信息中心第二次通报的邮件里，能够依稀感受到当年的紧张气氛。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

按照事件第一次发生时间排序：

【blog.ustc.edu.cn、freeshell.ustc.edu.cn】202.141.{160,176}.99（网络信息中心虚拟机）
31日 01:43，具体详情见上一封邮件（服务器失联），至今未修复。

【mirrors.ustc.edu.cn】202.38.95.110/25，202.141.{160,176}.110（网络信息中心实体机）
31日 01:51，黑客登陆后执行了 sudo /bin/sh；（P.S. 黑客登陆IP来自128.199.203.28（DigitalOcean），但该IP已被注销）
31日 01:58，系统崩溃， 由于我们设置了内核崩溃后60秒重启，因此该机器重启
31日 02:01，黑客再次登录
1日 19:42，管理员在排查问题时卸载了tun内核模块，随后，所有vlan配置消失。服务器失联。
1日 20:03，我和崔灏进入网络信息中心机房，物理接触服务器
1日 20:30，该服务器所有网络服务恢复正常

【lug.ustc.edu.cn】202.141.162.123（西区图书馆实体机）
31日11:54，服务器失联，无法ping通
31日13:47，我进入西区图书馆机房，发现服务器花屏，故障原因未知
31日14:07，强制重启服务器后，服务恢复
1日 19:58，服务器再次失联，至今未修复

【gitlab.lug.ustc.edu.cn】202.141.{162,176},93、202.38.93.93（东区图书馆机房虚拟机）
1日中午，接到用户反馈部分git仓库故障。
登录服务器发现btrfs文件系统损坏。
尝试通过vSphere Data Protection恢复失败，正在查找原因。。。

【vpn.lug.ustc.edu.cn】202.141.{160,176}.95（网络信息中心虚拟机）
1日20:35，该服务器失联
随后，我们通过vCenter查看，发现该机器正在循环重启。现象与blog服务器极为类似。
且该服务器故障前半小时的auth.log被删除，我们从硬盘中恢复出了部分入侵前后的日志。
服务至今未恢复。

我们正在全力抢修服务器，但由于事情发生得非常集中，服务全部恢复可能需要较长时间。

事后查明，服务器是用我的账号远程登录进去的。骇客 5 月中旬通过 U 盘传播的病毒入侵了我的笔记本，植入了键盘记录器，并通过未知方式远程控制我的浏览器访问一些与网络入侵有关的网页。由于我的个人账号没有访问记录，比特币钱包也没有被窃取，很有可能这是针对 LUG 而非我个人的一次高级持续性威胁（APT）。此后的半个月里，骇客没有打草惊蛇，估计是在通过各种渠道收集 LUG 服务器的信息。5 月 30 日夜，骇客通过键盘记录器窃取的服务器密码登录了大批服务器，并插入恶意内核模块。骇客还侵入 LDAP 数据库，篡改了一位已经离校的老会员的密码，登录进防守最严密的 mirrors 服务器。骇客还窃取了一位 VPN 用户的私钥，接入服务器内网，进一步入侵不允许从校外接入的服务器。

这个恶意内核模块所做的事情看起来很简单，就是在每次文件操作的时候随机修改硬盘上的一个字节。这个看起来像是恶作剧的内核模块，使得服务器在刚被入侵的时候运行一切正常，但当有关键数据被破坏后，发现系统异常，此时已经有大量用户数据和系统文件被破坏了。当管理员试图扫描和修复这些受损文件的时候，由于产生了大量文件操作，就导致更多的文件受损，总也修不好。甚至当我们 NFS 挂载备份服务器来拷贝备份数据的时候，拷出来的备份也是有错的，这让我们百思不得其解（幸亏备份服务器是 NFS 只读挂载，不然备份本身也可能被破坏）。

日访问量过千万的开源软件镜像（mirrors）服务中断，校内数千名用户依赖的 VPN 中断，freeshell 虚拟机内文件损坏，blog 无法访问，连 LUG 主页都打不开了，询问的邮件像雪片一样飞来，然而邮件服务器也挂了。这次被黑事件甚至惊动了多个 Linux 发行版和开源软件的上游，他们纷纷表示开源软件镜像被入侵是闻所未闻的事。Freeshell 服务由于没有备份而终止，VPN 服务则由于充当了帮凶而不再公开运行。此次事件暴露了 LUG 服务器基础架构的诸多问题，比如公共 VPN 服务和服务器使用同一内网，密码登录没有两步验证，服务器没有对插入内核模块的危险操作作报警和防御，离校管理员的账号没有禁用。当然，我的笔记本被骇客入侵是根本原因。事后，LUG 和 james 老师对我宽大处理，没有追究我的责任。我至今感到非常内疚。

背景：Windows 上的 Virtualbox 虚拟机。Ubuntu 14.04.1 LTS，3.13 内核。ext4 文件系统。

作死：前几天一直在该虚拟机上开发网站，做了 N 多 commit，以为 git push 了，但事实上 push 失败了。

悬疑：今天妹子 git pull 了一下，发现没有任何更新，然后说我这几天都没干活。

悲剧：登录到虚拟机里一看，项目目录里有几个刚写的文件变成了 0 字节的空文件。（ext4 这么稳定，一定是母机里万恶的 NTFS 和 Virtualbox 惹的祸）
.git 目录里好多文件也变成了 0 字节的空文件。git 提示仓库已损坏。

1
2
3
4

$ git status
error: object file .git/objects/71/cbcbbc9d06a74f2fd8ea9109b81b88086f1430 is empty
error: object file .git/objects/71/cbcbbc9d06a74f2fd8ea9109b81b88086f1430 is empty
fatal: loose object 71cbcbbc9d06a74f2fd8ea9109b81b88086f1430 (stored in .git/objects/71/cbcbbc9d06a74f2fd8ea9109b81b88086f1430) is corrupt

1
2
3
4

$ git fsck
error: object file .git/objects/00/837a7e1f8afb8da8609369f7acf95fe9b7fc5b is empty
error: object file .git/objects/00/837a7e1f8afb8da8609369f7acf95fe9b7fc5b is empty
fatal: loose object 00837a7e1f8afb8da8609369f7acf95fe9b7fc5b (stored in .git/objects/00/837a7e1f8afb8da8609369f7acf95fe9b7fc5b) is corrupt

几天来写的代码是不是这样就灰飞烟灭了呢？我们知道，当你删除一个东西的时候，你只是删除了这个东西在当前三维空间中的引用，而这个东西的本体仍然存在于四维时空之中。穿越大法，走起！

2015 年 1 月 30 日是 SIGCOMM 2015 论文投稿的 deadline，我却跑到黄山浪了。IMG_20150130_083809

临行准备

我们都是第一次去黄山，早在 12 月 15 日，我们期末考试的时间确定下来，就开始做准备了。

时间

我期末考试结束的第二天出发。查了一些攻略，黄山比较适合二日游，在山上住一晚上。加上往返合肥，一共四天。

交通

从合肥去黄山有两条路线可选：

1. 坐火车到黄山火车站（位于黄山市的屯溪），再坐一个小时的大巴到黄山脚下的汤口镇。
2. 在合肥长途汽车站坐大巴直接到黄山脚下的汤口镇。
   到达黄山脚下的汤口镇之后，要进入黄山景区，只能乘坐新国线大巴，19 元/人。大巴是 20 分钟的盘山公路，大约 10 公里。大巴有两个方向，一个到前山的慈光阁，一个到后山的云谷寺。慈光阁和云谷寺都有索道可以上山，当然也可以步行上山（大约 5 公里，需 3 小时）。现在前山的索道关闭整修，步行上山太累，因此游人都是从后山上山，在山上住一晚，从前山下山。

由于静宁晕车，不能长时间坐大巴，就选择了先火车后汽车的方案。目前从合肥到黄山只有 K 字头的火车，需要 6～7 个小时（今年就将有动车开通了）。尽管冬天这段时间合肥到黄山的火车票不紧张，我们还是提前一个月把火车票预订好了。

黄山市内和黄山风景区内的大巴基本都是半小时发一班车，不需要也无法预订。

住宿

在山下的两个晚上可以选择住在黄山市内，也可以选择住在黄山脚下。山上的住宿相对紧张，需要提前预订。这个上携程就行了。

装备

• 证件类：身份证、学生证
• 电器类：手机、iPad、移动电源、手电筒（从淘宝上买，事实上没用到）
• 保暖类：围巾、手套、帽子、坐垫（黄山冬天很冷）
• 登山辅助：
• 衣服类：每人带2双袜子，内衣内裤，擦澡的毛巾
• 洗漱类：牙刷、牙膏、牙杯、唇膏、护手霜、护肤系列产品…
  

1 月 28 日

2013 年 5 月 16 日，我的博客有了顶级域名 bojieli.com。2015 年 1 月 6 日，注册并启用了新域名 ring0.me（是数字 0 哦，字体看着像字母 O）。

Ring0 是 CPU 体系结构里特权级最高的保护级别，运行在 Ring0 级别的代码直接与物理硬件交互。特权级的概念可以追溯到 20 世纪 60 年代的 MULTICS。在 x86 体系结构中，ring0 代表操作系统内核和内核驱动，相对于通常运行在 ring 3 的用户态应用程序。我第一次听说 ring0 是在一篇关于 rootkits 的文章里，那时我初中，对 “黑客” 技术很好奇。惭愧的是，我至今都不会写 rootkit。

我的博客使用 ring0.me 这个域名，是为了展示我的兴趣主要在搭建起计算机系统和网络的基础研究和技术。

注册 ring0.me 是感觉姓名全拼的域名 bojieli.com 看起来不够 geek。我想过 rdma, ssh22, http80, tcp80, printk, reisub 等多个未被注册的域名，最后还是觉得 ring0 更好。

原来的 bojieli.com 已经 HTTP 301 跳转到 ring0.me 的相应页面。由于 StartSSL 的政策限制，SSL 证书需要在域名注册后三天才能申请。1 月 17 日部署了 SSL 证书。bojieli.com 将继续服务到 2016 年 5 月，之后不再续费。

博客标题由 “null != undefined” 改成了 “Ring0”，副标题由 “Seeking possibility for next-generation network” 改成了 “Fundamental research in networked systems”。希望读者喜欢 ^_^