Bojie Li (李博杰)

（本文首发于 知乎）

中国科大 LUG 的 @高一凡 在 LUG HTTP 代理服务器上部署了 Linux 4.9 的 TCP BBR 拥塞控制算法。从科大的移动出口到新加坡 DigitalOcean 的实测下载速度从 647 KB/s 提高到了 22.1 MB/s（截屏如下）。

（应评论区各位 dalao 要求，补充测试环境说明：是在新加坡的服务器上设置了 BBR，新加坡的服务器是数据的发送方。这个服务器是访问墙外资源的 HTTP 代理。科大移动出口到 DigitalOcean 之间不是 dedicated 的专线，是走的公网，科大移动出口这边是 1 Gbps 无限速（但是要跟其他人 share），DigitalOcean 实测是限速 200 Mbps。RTT 是 66 ms。实测结果这么好，也是因为大多数人用的是 TCP Cubic (Linux) / Compound TCP (Windows)，在有一定丢包率的情况下，TCP BBR 更加激进，抢占了更多的公网带宽。因此也是有些不道德的感觉。）

此次 Google 提交到 Linux 主线并发表在 ACM queue 期刊上的 TCP BBR 拥塞控制算法，继承了 Google “先在生产环境部署，再开源和发论文” 的研究传统。TCP BBR 已经在 Youtube 服务器和 Google 跨数据中心的内部广域网（B4）上部署。

TCP BBR 致力于解决两个问题：

1. 在有一定丢包率的网络链路上充分利用带宽。
2. 降低网络链路上的 buffer 占用率，从而降低延迟。

TCP 拥塞控制的目标是最大化利用网络上瓶颈链路的带宽。一条网络链路就像一条水管，要想用满这条水管，最好的办法就是给这根水管灌满水，也就是：
水管内的水的数量 = 水管的容积 = 水管粗细 × 水管长度
换成网络的名词，也就是：
网络内尚未被确认收到的数据包数量 = 网络链路上能容纳的数据包数量 = 链路带宽 × 往返延迟

TCP 维护一个发送窗口，估计当前网络链路上能容纳的数据包数量，希望在有数据可发的情况下，回来一个确认包就发出一个数据包，总是保持发送窗口那么多个包在网络中流动。

TCP 与水管的类比示意（图片来源：Van Jacobson，Congestion Avoidance and Control，1988）
如何估计水管的容积呢？一种大家都能想到的方法是不断往里灌水，直到溢出来为止。标准 TCP 中的拥塞控制算法也类似：不断增加发送窗口，直到发现开始丢包。这就是所谓的 ”加性增，乘性减”，也就是当收到一个确认消息的时候慢慢增加发送窗口，当确认一个包丢掉的时候较快地减小发送窗口。

标准 TCP 的这种做法有两个问题：

首先，假定网络中的丢包都是由于拥塞导致（网络设备的缓冲区放不下了，只好丢掉一些数据包）。事实上网络中有可能存在传输错误导致的丢包，基于丢包的拥塞控制算法并不能区分拥塞丢包和错误丢包。在数据中心内部，错误丢包率在十万分之一（1e-5）的量级；在广域网上，错误丢包率一般要高得多。

更重要的是，“加性增，乘性减” 的拥塞控制算法要能正常工作，错误丢包率需要与发送窗口的平方成反比。数据中心内的延迟一般是 10-100 微秒，带宽 10-40 Gbps，乘起来得到稳定的发送窗口为 12.5 KB 到 500 KB。而广域网上的带宽可能是 100 Mbps，延迟 100 毫秒，乘起来得到稳定的发送窗口为 10 MB。广域网上的发送窗口比数据中心网络高 1-2 个数量级，错误丢包率就需要低 2-4 个数量级才能正常工作。因此标准 TCP 在有一定错误丢包率的长肥管道（long-fat pipe，即延迟高、带宽大的链路）上只会收敛到一个很小的发送窗口。这就是很多时候客户端和服务器都有很大带宽，运营商核心网络也没占满，但下载速度很慢，甚至下载到一半就没速度了的一个原因。

其次，网络中会有一些 buffer，就像输液管里中间膨大的部分，用于吸收网络中的流量波动。由于标准 TCP 是通过 “灌满水管” 的方式来估算发送窗口的，在连接的开始阶段，buffer 会被倾向于占满。后续 buffer 的占用会逐渐减少，但是并不会完全消失。客户端估计的水管容积（发送窗口大小）总是略大于水管中除去膨大部分的容积。这个问题被称为 bufferbloat（缓冲区膨胀）。

缓冲区膨胀现象图示

缓冲区膨胀有两个危害：

1. 增加网络延迟。buffer 里面的东西越多，要等的时间就越长嘛。
2. 共享网络瓶颈的连接较多时，可能导致缓冲区被填满而丢包。很多人把这种丢包认为是发生了网络拥塞，实则不然。

往返延迟随时间的变化。红线：标准 TCP（可见周期性的延迟变化，以及 buffer 几乎总是被填满）；绿线：TCP BBR （图片引自 Google 在 ACM queue 2016 年 9-10 月刊上的论文 [1]，下同）

有很多论文提出在网络设备上把当前缓冲区大小的信息反馈给终端，比如在数据中心广泛应用的 ECN（Explicit Congestion Notification）。然而广域网上网络设备众多，更新换代困难，需要网络设备介入的方案很难大范围部署。

TCP BBR 是怎样解决以上两个问题的呢？

1. 既然不容易区分拥塞丢包和错误丢包，TCP BBR 就干脆不考虑丢包。
2. 既然灌满水管的方式容易造成缓冲区膨胀，TCP BBR 就分别估计带宽和延迟，而不是直接估计水管的容积。

带宽和延迟的乘积就是发送窗口应有的大小。发明于 2002 年并已进入 Linux 内核的 TCP Westwood 拥塞控制算法，就是分别估计带宽和延迟，并计算其乘积作为发送窗口。然而带宽和延迟就像粒子的位置和动量，是没办法同时测准的：要测量最大带宽，就要把水管灌满，缓冲区中有一定量的数据包，此时延迟就是较高的；要测量最低延迟，就要保证缓冲区为空，网络里的流量越少越好，但此时带宽就是较低的。

TCP BBR 解决带宽和延迟无法同时测准的方法是：交替测量带宽和延迟；用一段时间内的带宽极大值和延迟极小值作为估计值。

在连接刚建立的时候，TCP BBR 采用类似标准 TCP 的慢启动，指数增长发送速率。然而标准 TCP 遇到任何一个丢包就会立即进入拥塞避免阶段，它的本意是填满水管之后进入拥塞避免，然而（1）如果链路的错误丢包率较高，没等到水管填满就放弃了；（2）如果网络里有 buffer，总要把缓冲区填满了才会放弃。

TCP BBR 则是根据收到的确认包，发现有效带宽不再增长时，就进入拥塞避免阶段。（1）链路的错误丢包率只要不太高，对 BBR 没有影响；（2）当发送速率增长到开始占用 buffer 的时候，有效带宽不再增长，BBR 就及时放弃了（事实上放弃的时候占的是 3 倍带宽 × 延迟，后面会把多出来的 2 倍 buffer 清掉），这样就不会把缓冲区填满。

发送窗口与往返延迟和有效带宽的关系。BBR 会在左右两侧的拐点之间停下，基于丢包的标准 TCP 会在右侧拐点停下（图片引自 TCP BBR 论文，下同）
在慢启动过程中，由于 buffer 在前期几乎没被占用，延迟的最小值就是延迟的初始估计；慢启动结束时的最大有效带宽就是带宽的初始估计。

慢启动结束后，为了把多占用的 2 倍带宽 × 延迟消耗掉，BBR 将进入排空（drain）阶段，指数降低发送速率，此时 buffer 里的包就被慢慢排空，直到往返延迟不再降低。如下图绿线所示。

TCP BBR（绿线）与标准 TCP（红线）有效带宽和往返延迟的比较
排空阶段结束后，BBR 进入稳定运行状态，交替探测带宽和延迟。由于网络带宽的变化比延迟的变化更频繁，BBR 稳定状态的绝大多数时间处于带宽探测阶段。带宽探测阶段是一个正反馈系统：定期尝试增加发包速率，如果收到确认的速率也增加了，就进一步增加发包速率。

具体来说，以每 8 个往返延迟为周期，在第一个往返的时间里，BBR 尝试增加发包速率 1/4（即以估计带宽的 5/4 速度发送）。在第二个往返的时间里，为了把前一个往返多发出来的包排空，BBR 在估计带宽的基础上降低 1/4 作为发包速率。剩下 6 个往返的时间里，BBR 使用估计的带宽发包。

当网络带宽增长一倍的时候，每个周期估计带宽会增长 1/4，每个周期为 8 个往返延迟。其中向上的尖峰是尝试增加发包速率 1/4，向下的尖峰是降低发包速率 1/4（排空阶段），后面 6 个往返延迟，使用更新后的估计带宽。3 个周期，即 24 个往返延迟后，估计带宽达到增长后的网络带宽。

网络带宽增长一倍时的行为。绿线为网络中包的数量，蓝线为延迟
当网络带宽降低一半的时候，多出来的包占用了 buffer，导致网络中包的延迟显著增加（下图蓝线），有效带宽降低一半。延迟是使用极小值作为估计，增加的实际延迟不会反映到估计延迟（除非在延迟探测阶段，下面会讲）。带宽的估计则是使用一段滑动窗口时间内的极大值，当之前的估计值超时（移出滑动窗口）之后，降低一半后的有效带宽就会变成估计带宽。估计带宽减半后，发送窗口减半，发送端没有窗口无法发包，buffer 被逐渐排空。

网络带宽降低一半时的行为。绿线为网络中包的数量，蓝线为延迟
当带宽增加一倍时，BBR 仅用 1.5 秒就收敛了；而当带宽降低一半时，BBR 需要 4 秒才能收敛。前者由于带宽增长是指数级的；后者主要是由于带宽估计采用滑动窗口内的极大值，需要一定时间有效带宽的下降才能反馈到带宽估计中。

当网络带宽保持不变的时候，稳定状态下的 TCP BBR 是下图这样的：（我们前面看到过这张图）可见每 8 个往返延迟为周期的延迟细微变化。

往返延迟随时间的变化。红线：标准 TCP；绿线：TCP BBR
上面介绍了 BBR 稳定状态下的带宽探测阶段，那么什么时候探测延迟呢？在带宽探测阶段中，估计延迟始终是使用极小值，如果实际延迟真的增加了怎么办？TCP BBR 每过 10 秒，如果估计延迟没有改变（也就是没有发现一个更低的延迟），就进入延迟探测阶段。延迟探测阶段持续的时间仅为 200 毫秒（或一个往返延迟，如果后者更大），这段时间里发送窗口固定为 4 个包，也就是几乎不发包。这段时间内测得的最小延迟作为新的延迟估计。也就是说，大约有 2% 的时间 BBR 用极低的发包速率来测量延迟。

TCP BBR 还使用 pacing 的方法降低发包时的 burstiness，减少突然传输的一串包导致缓冲区膨胀。发包的 burstiness 可能由两个原因引起：

1. 数据接收方为了节约带宽，把多个确认（ACK）包累积成一个发出，这叫做 ACK Compression。数据发送方收到这个累积确认包后，如果没有 pacing，就会发出一连串的数据包。
2. 下面我们来看 TCP BBR 的效果如何。

首先看 BBR 试图解决的第一个问题：在有随机丢包情况下的吞吐量。如下图所示，只要有万分之一的丢包率，标准 TCP 的带宽就只剩 30%；千分之一丢包率时只剩 10%；有百分之一的丢包率时几乎就卡住了。而 TCP BBR 在丢包率 5% 以下几乎没有带宽损失，在丢包率 15% 的时候仍有 75% 带宽。数据发送方没有足够的数据可传输，积累了一定量的空闲发送窗口。当应用层突然需要传输较多的数据时，如果没有 pacing，就会把空闲发送窗口大小这么多数据一股脑发出去。

100 Mbps，100ms 下的丢包率和有效带宽（红线：标准 TCP，绿线：TCP BBR）

异地数据中心间跨广域网的传输往往是高带宽、高延迟的，且有一定丢包率，TCP BBR 可以显著提高传输速度。这也是中国科大 LUG HTTP 代理服务器和 Google 广域网（B4）部署 TCP BBR 的主要原因。
再来看 BBR 试图解决的第二个问题：降低延迟，减少缓冲区膨胀。如下图所示，标准 TCP 倾向于把缓冲区填满，缓冲区越大，延迟就越高。当用户的网络接入速度很慢时，这个延迟可能超过操作系统连接建立的超时时间，导致连接建立失败。使用 TCP BBR 就可以避免这个问题。

缓冲区大小与延迟的关系（红线：标准 TCP，绿线：TCP BBR）
Youtube 部署了 TCP BBR 之后，全球范围的中位数延迟降低了 53%（也就是快了一倍），发展中国家的中位数延迟降低了 80%（也就是快了 4 倍）。从下图可见，延迟越高的用户，采用 TCP BBR 后的延迟下降比例越高，原来需要 10 秒的现在只要 2 秒了。如果您的网站需要让用 GPRS 或者慢速 WiFi 接入网络的用户也能流畅访问，不妨试试 TCP BBR。

标准 TCP 与 TCP BBR 的往返延迟中位数之比
综上，TCP BBR 不再使用丢包作为拥塞的信号，也不使用 “加性增，乘性减” 来维护发送窗口大小，而是分别估计极大带宽和极小延迟，把它们的乘积作为发送窗口大小。

BBR 的连接开始阶段由慢启动、排空两阶段构成。为了解决带宽和延迟不易同时测准的问题，BBR 在连接稳定后交替探测带宽和延迟，其中探测带宽阶段占绝大部分时间，通过正反馈和周期性的带宽增益尝试来快速响应可用带宽变化；偶尔的探测延迟阶段发包速率很慢，用于测准延迟。

BBR 解决了两个问题：

1. 在有一定丢包率的网络链路上充分利用带宽。非常适合高延迟、高带宽的网络链路。
2. 降低网络链路上的 buffer 占用率，从而降低延迟。非常适合慢速接入网络的用户。

看到评论区很多客户端和服务器哪个部署 TCP BBR 有效的问题，需要提醒：TCP 拥塞控制算法是数据的发送端决定发送窗口，因此在哪边部署，就对哪边发出的数据有效。如果是下载，就应在服务器部署；如果是上传，就应在客户端部署。

如果希望加速访问国外网站的速度，且下载流量远高于上传流量，在客户端上部署 TCP BBR（或者任何基于 TCP 拥塞控制的加速算法）是没什么效果的。需要在 VPN 的国外出口端部署 TCP BBR，并做 TCP Termination & TCP Proxy。也就是客户建立连接事实上是跟 VPN 的国外出口服务器建联，国外出口服务器再去跟目标服务器建联，使得丢包率高、延迟大的这一段（从客户端到国外出口）是部署了 BBR 的国外出口服务器在发送数据。或者在 VPN 的国外出口端部署 BBR 并做 HTTP(S) Proxy，原理相同。

大概是由于 ACM queue 的篇幅限制和目标读者，这篇论文并没有讨论（仅有拥塞丢包情况下）TCP BBR 与标准 TCP 的公平性。也没有讨论 BBR 与现有拥塞控制算法的比较，如基于往返延迟的（如 TCP Vegas）、综合丢包和延迟因素的（如 Compound TCP、TCP Westwood+）、基于网络设备提供拥塞信息的（如 ECN）、网络设备采用新调度策略的（如 CoDel）。期待 Google 发表更详细的论文，也期待各位同行报告 TCP BBR 在实验或生产环境中的性能。

本人不是 TCP 拥塞控制领域的专家，如有错漏不当之处，恳请指正。

[1] Cardwell, Neal, et al. “BBR: Congestion-Based Congestion Control.” Queue14.5 (2016): 50.

Windows API 里面有一个 Beep 函数，作用是发出蜂鸣声。这个蜂鸣功能历史悠久，BIOS 的报警声就是从主板蜂鸣器里出来的，其原理是调用几乎每台机器都有的 Programmable Interval Timer (PIT)。可惜从 Windows Vista 开始，这个函数的行为变成了调用扬声器发声，而不再是使用主板蜂鸣器发声了。

如何在 Windows Vista 以上的系统里使用主板蜂鸣器发声呢？是不是必须写个 Windows 驱动呢？其实利用 WinDbg 内核调试器的功能，只需要一行代码就能搞定。下面一行代码以 800 Hz 的频率让主板蜂鸣器发声 1000 毫秒。

1

n 10; r $t0=800; r $t1=1000; ob 0x43 0xb6; ob 0x42 (1193180/$t0)&0xff; ob 0x42 (1193180/$t0)>>8; ob 0x61 3; .sleep $t1; ob 0x61 0

使用方法：

1. 下载安装 WinDbg
2. 打开内核调试。管理员权限运行

   1	bcdedit /debug on

   ，重启。
3. 管理员权限打开 WinDbg，File->Kernel Debug，选择 “Local” 选项卡，确定。不出意外的话，就会进入 kernel debug session。
4. 输入这段代码，如果你的主板蜂鸣器正常的话，应该就能听到蜂鸣声了。（可惜，截图里不带声音）
   

原理：

1
2
3
4
5
6
7
8
9

n 10;          设置十进制，默认 WinDbg 是 16 进制
r $t0=800;     设置 WinDbg 内部寄存器 t0 为 800，表示发声频率
r $t1=1000;    设置 WinDbg 内部寄存器 t1 为 1000，表示发声时长（毫秒）
ob 0x43 0xb6;  设置 PIT 输出到主板蜂鸣器的 PWM 波周期（这里的 ob 和 Linux 的 outb 相同）
ob 0x42 (1193180/$t0)&0xff;  PWM 波周期的低字节
ob 0x42 (1193180/$t0)>>8;    PWM 波周期的高字节
ob 0x61 3;     开始发声
.sleep $t1;    持续发声 $t1 这么长时间（毫秒）
ob 0x61 0;     发声结束

感谢 负一的平方根 (zzh1996) 出的题。

参考：http://wiki.osdev.org/PC_Speaker

（转载自 微软亚洲研究院）

作为计算机网络领域资历最老的顶级学术会议，ACM SIGCOMM自1977年起已经举办了37届。美国计算机学会（ACM）通信专业组（SIGCOMM）在其主页上无不自豪地将SIGCOMM称为其年度旗舰会议。40年来，从计算机网络教科书里的TCP拥塞控制协议到云数据中心里的软件定义网络（SDN）和网络功能虚拟化（NFV），SIGCOMM见证了众多计算机网络关键技术的诞生与发展。

SIGCOMM的论文以高质量著称，每年只录用40篇左右，录取率在15%左右。全世界的网络研究者都把在SIGCOMM上发表论文视为一种荣誉。每篇论文都经过严格的双盲评审，例如今年有三轮评审，第一轮从225篇选出99篇，第二轮选出66篇，第三轮选出60篇进入程序委员会（PC）讨论，在一天半的会议后决定最终被录用的39篇论文。每篇被录用的论文平均收到了8个评审意见，长达十几页。即使最终没有被录用，这些专家审稿人的意见对论文后续的改进也是很有帮助的。

FAQ for ClickNP: Highly Flexible and High-Performance Network Processing with Reconfigurable Hardware.

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 进程接收了，它就会立刻抛出异常，终止服务。