当年今日

• 2025 : 黑屏之后
• 2024 : 感冒假期
• 2023 : WHAT???
• 2022 : 思维导图，你好
• 2021 : 越来越高和越来越少
• 2020 : 指纹解锁无能
• 2019 : RUN NOTE
• 2019 : 乐在翻拍
• 2018 : 寻访石围塘
• 2017 : 不喜欢摩天大楼
• 2016 : 苏醒
• 2015 : 电饭煲戚风蛋糕
• 2014 : 为Dos Caras老爹做橡皮章庆生
• 2013 : BE BETTER
• 2012 : 买新洗衣机了
• 2011 : 不是故意的押韵
• 2010 : 红果Alex @ GAS06
• 2010 : Where they came from
• 2009 : 人的问题
• 2008 : 黄
• 2007 : 可爱狗狗
• 2006 : 感觉不一
• 2005 : 可恶的进口税费
• 2005 : C语言之运算符号和表达式(3)

在小米Civi 1S又出现了在解锁的时候黑屏，必须插上充电头才能重启之后，我又去研究了一番之前我已经研究过，但是隔了好长一段时间都没有结果的事情。那时我觉得已经等不到结果了，或许有一天，我希望HyperOS那边会说，已经修复的那个指纹解锁不知道为什么就会出现黑屏的问题。但实际上，我感觉这个东西从来都没有出现过，因为谁都没办法重现那个黑屏，当你拿着手机去检查，最后出来的结果就是什么问题都查不到，但就是会随机黑屏。通常情况下，维修的人会给你刷一个系统，然后完事，但说不准那个系统什么时候又挂了。我遇到的情况是根本就没有等到HyperOS那边说有修复的补丁。出现指纹解锁的时候出现黑屏，这个状态不仅仅是小米Civi 1S的专属 ，红米K系列或者小米数字系列也有很多同样的遭遇。

这一次当我又去查找黑屏这个问题的时候。发现不久前在小米社区上。小米13Ultra的用户很多都遇到了这个问题，最后都必须重启才能解决。有些人已经把这个重启当作家常便饭，不仅仅是小米13Ultra，小米15，刚刚出的新机也有这种问题。一开始我以为那只是大家在抖音上抹黑小米15所以才这么说的，后来发现，在小米社区上也有很多，如果他们觉得这是抹黑的话，估计管理员会主动删帖，实际上没有。小米15的黑屏更加无语，那是任何场景都可能触发。小米13Ultra可能不插充电线也能长按电源键重启，但小米15就只能先插上充电线，然后才能重启。我不确定小米Civi 1S是不是长按电源键时间足够长了就能重启。以前当我的指纹解锁导致黑屏以后，一开始我是用插充电线重启的，后来某一次我发现，只要长按时间足够长，也可以不插充电线重启。所以这些黑屏到底是什么情况呢？为什么手机的某个核心部件突然就挂掉了？怎么那么脆弱呢？我自己用过7台小米或者红米的手机或平板。除了小米Civi 1S出现黑屏这个状况以外，其它从开始使用到寿终正寝都不会出现在解锁的时候突然黑屏，又或者用着用着就黑屏。红米Note7的确在最后的时候会用着用着就自动关机了，那是因为电池跟主板都已经不行了，不是现在我所遇到的黑屏问题，现在遇到的黑屏问题是手机重启之后发现电池是正常的，手机也没有问题，但你就说不准那个黑屏什么时候会来。

再次遇到黑屏这个问题的时候。我的考虑要不要把我的备用手机跟主用主力手机换一下，把红米Note11 5G换成我的主力手机，那个机子跟小米Civi 1S相比，的确性能不足，但稳定，而且电池的续航也比较好，因为它的CPU很一般，因为它的天线很阉割。慢是会慢一点，但起码不用我每天都为这个黑屏问题担惊受怕。但我真的要放弃小米Civi 1S作为主力手机吗？其实除了这个以外，我还有第二个选择，就是直接换一台新机，然后用换机的方式把所有资料都从小米Civi 1S上挪到新机。小米Civi 1S一旦屏幕点亮，就不会有黑屏的问题，所以哪怕给他们去检查，也不可能检查得出有毛病，所以那台机子理论上如果以旧换新，能换个好价钱，但是我真的要以这种方式告别小米Civi 1S吗？最重要的是，现在的小米手机里，我还没有一款特别心仪的。

说起黑屏问题，是不是都做过小米换机这个操作呢？所以是不是在换机的时候带进了某些信息导致跟系统本身不匹配，所以出现黑屏呢？

小米15黑屏的用户有的说可能是自动光亮度导致的bug，所以我直接关掉了小米Civi 1S的自动光亮度调节。我不知道这个能挺多久，我不知道下一次黑屏会什么时候袭来。

很多小伙伴的电脑系统都是源于购买时自带的Windows家庭版，或者是卖家直接批量用Ghost方式安装的。存在系统文件被精简、家庭版缺少高级特性、安全性下降之类的问题。本文旨在提供一种绝对原版的重装方式，WinPE快速安装原版镜像的方式之后再另开文章 你可以在微软官网渠道获取，也可以通过一些比较靠谱的整合站，例如ITELLYOU。无论哪种方式，确保自己获取的镜像是原版未经修改的即可 你可能会问：官方不是都有安装小帮手了？ 但是本文列出的方法通用于大部分系统，不仅包括旧版Windows，Linux发行版都可以这样装（只是写引导和选择系统的时候有所差别） 如果你选择上述的ITELLYOU渠道，你会发现下载链接只有ED2K和BT。这个时候就可以选一个靠谱的下载工具了，喜欢用迅雷的倒也可以直接使用，

来源

很早前就想写一篇关于eBPF的文章，但是迟迟没有动手，这两天有点时间，所以就来写一篇，这文章主要还是简单的介绍eBPF 是用来干什么的，并通过几个示例来介绍是怎么玩的，这个技术非常非常之强，Linux 操作系统的观测性实在是太强大了，并在 BCC 加持下变得一览无余。这个技术不是一般的运维人员或是系统管理员可以驾驭的，这个还是要有底层系统知识并有一定开发能力的技术人员才能驾驭的了的。我在这篇文章的最后给了个彩蛋。

介绍

eBPF（extened Berkeley Packet Filter）是一种内核技术，它允许开发人员在不修改内核代码的情况下运行特定的功能。eBPF 的概念源自于 Berkeley Packet Filter（BPF），后者是由贝尔实验室开发的一种网络过滤器，可以捕获和过滤网络数据包。

出于对更好的 Linux 跟踪工具的需求，eBPF 从 dtrace中汲取灵感，dtrace 是一种主要用于 Solaris 和 BSD 操作系统的动态跟踪工具。与 dtrace 不同，Linux 无法全面了解正在运行的系统，因为它仅限于系统调用、库调用和函数的特定框架。在Berkeley Packet Filter  (BPF)（一种使用内核 VM 编写打包过滤代码的工具）的基础上，一小群工程师开始扩展 BPF 后端以提供与 dtrace 类似的功能集。 eBPF 诞生了。2014 年随 Linux 3.18 首次限量发布，充分利用 eBPF 至少需要 Linux 4.4 以上版本。

eBPF 比起传统的 BPF 来说，传统的 BPF 只能用于网络过滤，而 eBPF 则可以用于更多的应用场景，包括网络监控、安全过滤和性能分析等。另外，eBPF 允许常规用户空间应用程序将要在 Linux 内核中执行的逻辑打包为字节码，当某些事件（称为挂钩）发生时，内核会调用 eBPF 程序。此类挂钩的示例包括系统调用、网络事件等。用于编写和调试 eBPF 程序的最流行的工具链称为 BPF 编译器集合 (BCC)，它基于 LLVM 和 CLang。

eBPF 有一些类似的工具。例如，SystemTap 是一种开源工具，可以帮助用户收集 Linux 内核的运行时数据。它通过动态加载内核模块来实现这一功能，类似于 eBPF。另外，DTrace 是一种动态跟踪和分析工具，可以用于收集系统的运行时数据，类似于 eBPF 和 SystemTap。[1]

以下是一个简单的比较表格，可以帮助您更好地了解 eBPF、SystemTap 和 DTrace 这三种工具的不同之处：[1]

工具	eBPF	SystemTap	DTrace
定位	内核技术，可用于多种应用场景	内核模块	动态跟踪和分析工具
工作原理	动态加载和执行无损编译过的代码	动态加载内核模块	动态插接分析器，通过 probe 获取数据并进行分析
常见用途	网络监控、安全过滤、性能分析等	系统性能分析、故障诊断等	系统性能分析、故障诊断等
优点	灵活、安全、可用于多种应用场景	功能强大、可视化界面	功能强大、高性能、支持多种编程语言
缺点	学习曲线高，安全性依赖于编译器的正确性	学习曲线高，安全性依赖于内核模块的正确性	配置复杂，对系统性能影响较大

对比表格[1]

从上表可以看出，eBPF、SystemTap 和 DTrace 都是非常强大的工具，可以用于收集和分析系统的运行情况。[1]

用途

eBPF 是一种非常灵活和强大的内核技术，可以用于多种应用场景。下面是 eBPF 的一些常见用途：[1]

• 网络监控：eBPF 可以用于捕获网络数据包，并执行特定的逻辑来分析网络流量。例如，可以使用 eBPF 程序来监控网络流量，并在发现异常流量时进行警报。[1]
• 安全过滤：eBPF 可以用于对网络数据包进行安全过滤。例如，可以使用 eBPF 程序来阻止恶意流量的传播，或者在发现恶意流量时对其进行拦截。[1]
• 性能分析：eBPF 可以用于对内核的性能进行分析。例如，可以使用 eBPF 程序来收集内核的性能指标，并通过特定的接口将其可视化。这样，可以更好地了解内核的性能瓶颈，并进行优化。[1]
• 虚拟化：eBPF 可以用于虚拟化技术。例如，可以使用 eBPF 程序来收集虚拟机的性能指标，并进行负载均衡。这样，可以更好地利用虚拟化环境的资源，提高系统的性能和稳定性。[1]

总之，eBPF 的常见用途非常广泛，可以用于网络监控、安全过滤、性能分析和虚拟化等多种应用场景。[1]

工作原理

eBPF 的工作原理主要分为三个步骤：加载、编译和执行。

eBPF 需要在内核中运行。这通常是由用户态的应用程序完成的，它会通过系统调用来加载 eBPF 程序。在加载过程中，内核会将 eBPF 程序的代码复制到内核空间。

eBPF 程序需要经过编译和执行。这通常是由Clang/LLVM的编译器完成，然后形成字节码后，将用户态的字节码装载进内核，Verifier会对要注入内核的程序进行一些内核安全机制的检查,这是为了确保 eBPF 程序不会破坏内核的稳定性和安全性。在检查过程中，内核会对 eBPF 程序的代码进行分析，以确保它不会进行恶意操作，如系统调用、内存访问等。如果 eBPF 程序通过了内核安全机制的检查，它就可以在内核中正常运行了，其会通过通过一个JIT编译步骤将程序的通用字节码转换为机器特定指令集，以优化程序的执行速度。

下图是其架构图。

（图片来自：https://www.infoq.com/articles/gentle-linux-ebpf-introduction/）

在内核中运行时，eBPF 程序通常会挂载到一个内核钩子（hook）上，以便在特定的事件发生时被执行。例如，

• 系统调用——当用户空间函数将执行转移到内核时插入
• 函数进入和退出——拦截对预先存在的函数的调用
• 网络事件 – 在收到数据包时执行
• Kprobes 和 uprobes – 附加到内核或用户函数的探测器

最后 eBPF Maps，允许eBPF程序在调用之间保持状态，以便进行相关的数据统计，并与用户空间的应用程序共享数据。一个eBPF映射基本上是一个键值存储，其中的值通常被视为任意数据的二进制块。它们是通过带有BPF_MAP_CREATE参数的bpf_cmd系统调用来创建的，和Linux世界中的其他东西一样，它们是通过文件描述符来寻址。与地图的交互是通过查找/更新/删除系统调用进行的

总之，eBPF 的工作原理是通过动态加载、执行和检查无损编译过的代码来实现的。[1]

示例

eBPF 可以用于对内核的性能进行分析。下面是一个基于 eBPF 的性能分析的 step-by-step 示例：

第一步：准备工作：首先，需要确保内核已经支持 eBPF 功能。这通常需要在内核配置文件中启用 eBPF 相关的选项，并重新编译内核。检查是否支持 eBPF，你可以用这两个命令查看 ls /sys/fs/bpf 和 lsmod | grep bpf

第二步：写 eBPF 程序：接下来，需要编写 eBPF 程序，用于收集内核的性能指标。eBPF 程序的语言可以选择 C 或者 Python，它需要通过特定的接口访问内核的数据结构，并将收集到的数据保存到指定的位置。

下面是一个Python 示例（其实还是C语言，用python来加载一段C程序到Linux内核）

#!/usr/bin/python3

from bcc import BPF
from time import sleep

# 定义 eBPF 程序
bpf_text = """
#include <uapi/linux/ptrace.h>

BPF_HASH(stats, u32);

int count(struct pt_regs *ctx) {
    u32 key = 0;
    u64 *val, zero=0;
    val = stats.lookup_or_init(&key, &zero);
    (*val)++;
    return 0;
}
"""

# 编译 eBPF 程序
b = BPF(text=bpf_text, cflags=["-Wno-macro-redefined"])

# 加载 eBPF 程序
b.attach_kprobe(event="tcp_sendmsg", fn_name="count")

name = {
  0: "tcp_sendmsg"
}
# 输出统计结果
while True:
    try:
        #print("Total packets: %d" % b["stats"][0].value)
        for k, v in b["stats"].items():
           print("{}: {}".format(name[k.value], v.value))
        sleep(1)
    except KeyboardInterrupt:
        exit()

这个 eBPF 程序的功能是统计网络中传输的数据包数量。它通过定义一个 BPF_HASH 数据结构来保存统计结果（eBPF Maps），并通过捕获 tcp_sendmsg 事件来实现实时统计。最后，它通过每秒输出一次统计结果来展示数据。这个 eBPF 程序只是一个简单的示例，实际应用中可能需要进行更复杂的统计和分析。

第三步：运行 eBPF 程序：接下来，需要使用 eBPF 编译器将 eBPF 程序编译成内核可执行的格式（这个在上面的Python程序里你可以看到——Python引入了一个bcc的包，然后用这个包，把那段 C语言的程序编译成字节码加载在内核中并把某个函数 attach 到某个事件上）。这个过程可以使用 BPF Compiler Collection（BCC）工具来完成。BCC 工具可以通过命令行的方式将 eBPF 程序编译成内核可执行的格式，并将其加载到内核中。

下面是运行上面的 Python3 程序的步骤：

sudo apt install python3-bpfcc

注：在Python3下请不要使用 pip3 install bcc （参看：这里）

如果你是 Ubuntu 20.10 以上的版本，最好通过源码安装（否则程序会有编译问题），参看：这里：

apt purge bpfcc-tools libbpfcc python3-bpfcc
wget https://github.com/iovisor/bcc/releases/download/v0.25.0/bcc-src-with-submodule.tar.gz
tar xf bcc-src-with-submodule.tar.gz
cd bcc/
apt install -y python-is-python3
apt install -y bison build-essential cmake flex git libedit-dev   libllvm11 llvm-11-dev libclang-11-dev zlib1g-dev libelf-dev libfl-dev python3-distutils
apt install -y checkinstall
mkdir build
cd build/
cmake -DCMAKE_INSTALL_PREFIX=/usr -DPYTHON_CMD=python3 ..
make
checkinstall

接下来，需要将上面的 Python 程序保存到本地，例如保存到文件 netstat.py。运行程序：最后，可以通过执行以下命令来运行 Python 程序：

$ chmod +x ./netstat.py
$ sudo ./netstat.py
tcp_sendmsg: 29
tcp_sendmsg: 216
tcp_sendmsg: 277
tcp_sendmsg: 379
tcp_sendmsg: 419
tcp_sendmsg: 468
tcp_sendmsg: 574
tcp_sendmsg: 645
tcp_sendmsg: 29

程序开始运行后，会在控制台输出网络数据包的统计信息。可以通过按 Ctrl+C 组合键来结束程序的运行。

下面我们再看一个比较复杂的示例，这个示例会计算TCP的发包时间（示例参考于Github上 这个issue里的程序）：

#!/usr/bin/python3

from bcc import BPF
import time

# 定义 eBPF 程序
bpf_text = """
#include <uapi/linux/ptrace.h>
#include <net/sock.h>
#include <net/inet_sock.h>
#include <bcc/proto.h>

struct packet_t {
    u64 ts, size;
    u32 pid;
    u32 saddr, daddr;
    u16 sport, dport;
};

BPF_HASH(packets, u64, struct packet_t);

int on_send(struct pt_regs *ctx, struct sock *sk, struct msghdr *msg, size_t size)
{
    u64 id = bpf_get_current_pid_tgid();
    u32 pid = id;

    // 记录数据包的时间戳和信息
    struct packet_t pkt = {}; // 结构体一定要初始化，可以使用下面的方法
                              //__builtin_memset(&pkt, 0, sizeof(pkt)); 
    pkt.ts = bpf_ktime_get_ns();
    pkt.size = size;
    pkt.pid = pid;
    pkt.saddr = sk->__sk_common.skc_rcv_saddr;
    pkt.daddr = sk->__sk_common.skc_daddr;
    struct inet_sock *sockp = (struct inet_sock *)sk;
    pkt.sport = sockp->inet_sport;
    pkt.dport = sk->__sk_common.skc_dport;

    packets.update(&id, &pkt);
    return 0;
}

int on_recv(struct pt_regs *ctx, struct sock *sk)
{
    u64 id = bpf_get_current_pid_tgid();
    u32 pid = id;

    // 获取数据包的时间戳和编号
    struct packet_t *pkt = packets.lookup(&id);
    if (!pkt) {
        return 0;
    }

    // 计算传输时间
    u64 delta = bpf_ktime_get_ns() - pkt->ts;

    // 统计结果
    bpf_trace_printk("tcp_time: %llu.%llums, size: %llu\\n", 
       delta/1000, delta%1000%100, pkt->size);

    // 删除统计结果
    packets.delete(&id);

    return 0;
}
"""

# 编译 eBPF 程序
b = BPF(text=bpf_text, cflags=["-Wno-macro-redefined"])

# 注册 eBPF 程序
b.attach_kprobe(event="tcp_sendmsg", fn_name="on_send")
b.attach_kprobe(event="tcp_v4_do_rcv", fn_name="on_recv")

# 输出统计信息
print("Tracing TCP latency... Hit Ctrl-C to end.")
while True:
    try:
        (task, pid, cpu, flags, ts, msg) = b.trace_fields()
        print("%-18.9f %-16s %-6d %s" % (ts, task, pid, msg))
    except KeyboardInterrupt:
        exit()

上面这个程序通过捕获每个数据包的时间戳来统计传输时间。在捕获 tcp_sendmsg 事件时，记录数据包的发送时间；在捕获 tcp_v4_do_rcv 事件时，记录数据包的接收时间；最后，通过比较两个时间戳来计算传输时间。

从上面的两个程序我们可以看到，eBPF 的一个编程的基本方法，这样的在Python里向内核的某些事件挂载一段 “C语言” 的方式就是 eBPF 的编程方式。实话实说，这样的代码很不好写，而且有很多非常诡异的东西，一般人是很难驾驭的（上面的代码我也不是很容易都能写通的，把 Google 都用了个底儿掉，读了很多晦涩的文档……）好在这样的代码已经有人写了，我们不必再写了，在 Github 上的 bcc 库下的 tools 目录有很多……

BCC（BPF Compiler Collection）是一套开源的工具集，可以在 Linux 系统中使用 BPF（Berkeley Packet Filter）程序进行系统级性能分析和监测。BCC 包含了许多实用工具，如：

1. bcc-tools：一个包含许多常用的 BCC 工具的软件包。
2. bpftrace：一个高级语言，用于编写和执行 BPF 程序。
3. tcptop：一个实时监控和分析 TCP 流量的工具。
4. execsnoop：一个用于监控进程执行情况的工具。
5. filetop：一个实时监控和分析文件系统流量的工具。
6. trace：一个用于跟踪和分析函数调用的工具。
7. funccount：一个用于统计函数调用次数的工具。
8. opensnoop：一个用于监控文件打开操作的工具。
9. pidstat：一个用于监控进程性能的工具。
10. profile：一个用于分析系统 CPU 使用情况的工具。

下面这张图你可能见过多次了，你可以看看他可以干多少事，内核里发生什么事一览无余。

延伸阅读

一些经典的文章和书籍关于 eBPF 包括：

• Brendan Gregg 的《BPF Performance Tools: Linux System and Application Observability》一书是一个全面的指南，涵盖了 eBPF 的基础知识和实践应用。
• eBPF 的官网：https://ebpf.io/ 由 Cilium 建立
• Cilium’s BPF and XDP Reference Guide
• BPF Documentation
• BPF Design Q&A
• 还有 Github 上的 Awesome eBPF

彩蛋

最后来到彩蛋环节。因为最近 ChatGPT 很火，于是，我想通过 ChatGPT 来帮助我书写这篇文章，一开始我让ChatGPT 帮我列提纲，并根据提纲生成文章内容，并查找相关的资料，非常之顺利，包括生成的代码，我以为我们以很快地完成这篇文章。

但是，到了代码生成的时候，我发现，ChatGPT 生成的代码的思路和方法都是对的，但是是比较老的，而且是跑不起来的，出现了好些低级错误，如：使用了未声明的变量，没有引用完整的C语言的头文件，没有正确地初始化变量，错误地获取数据，类型没有匹配……等等，在程序调试上，挖了很多的坑，C语言本来就不好搞，挖的很多运行时的坑很难察觉，所以，耗费了我大量的时间来排除各种各样的问题，其中有环境上的问题，还有代码上的问题，这些问题即便是通过 Google 也不容易找到解决方案，我找到的解决方案都放在文章中了，尤其是第二个示例，让我调试了3个多小时，读了很多 bcc 上的issue和相关的晦涩的手册和文档，才让程序跑通。

到了文章收关的阶段，我让ChatGPT 给我几个延伸阅读，也是很好的，但是没有给出链接，于是我只得人肉 Google 了一下，然后让我吃惊的是，好多ChatGPT给出来的文章是根本不存在的，完全是它伪造的。我连让它干了两次都是这样，这个让我惊掉大牙。这让我开始怀疑它之前生成的内容，于是，我不得我返回仔细Review我的文章，尤其是“介绍”、“用途”和“工作原理”这三个章节，基本都是ChatGPT生成的，在Review完后，我发现了ChatGPT 给我生造了一个叫 “无损编译器”的术语，这个术语简直了，于是我开始重写我的文章。我把一些段落重写了，有一些没有，保留下来的我都标记上了 [1]，大家读的时候要小心阅读。

最后，我的结论是，ChatGPT只是一个不成熟的玩具，只能回答一些没有价值的日常聊天的问题，要说能取代Google，我觉得不可能，因为Google会基于基本的事实，而ChatGPT会基于内容生成的算法，在造假方面称得上是高手，可以列为电信诈骗的范畴了，我以后不会再使用ChatGPT生成文章内容或是作我的帮手了。StackOverflow把其ban了真是不能太赞了！

附件一：ChatGPT的造假载图和样本

ChatGPT 生成的样本一

• Brendan Gregg 的《BPF Performance Tools: Linux System and Application Observability》一书是一个全面的指南，涵盖了 eBPF 的基础知识和实践应用。
• Alexei Starovoitov 在 2015 年的 LPC 大会上发表的《eBPF and XDP: fast programmable datapath in the Linux kernel》一文，是一个介绍 eBPF 和 XDP（eXpress Data Path）的综述。
• 谷歌的《BPF: The Future of Linux Monitoring and Observability》一文介绍了 eBPF 的基本概念，并探讨了它对于 Linux 监控和可观察性的影响。
• 微软的《A Survey of Techniques for Hardware Acceleration of BPF》一文，介绍了 eBPF 在硬件加速方面的研究现状。
• Daniel Borkmann 的《Linux kernel networking: implementation and theory》一书涵盖了 eBPF 的实现和理论。
• Martin KaFai Lau 在 2015 年的 SOSP 大会上发表的《eBPF: a new execution environment for the Linux kernel》一文，介绍了 eBPF 在 Linux 内核中的新执行环境。
• 来自两名谷歌工程师的《eBPF: A New Frontier in Performance Analysis》一文，探讨了 eBPF 对性能分析的影响。
• 《BPF Performance Tools: Linux System and Application Observability》一书中的第三章，讨论了 eBPF 的编译器和运行时系统。
• 来自三名谷歌工程师的《eBPF: The New Solaris DTrace》一文，比较了 eBPF 和 Solaris DTrace 系统的区别。

ChatGPT 生成的样本二

1. eBPF 程序开发指南（https://cilium.io/doc/ebpf/ebpf-guide/）
2. eBPF 官方文档（https://www.kernel.org/doc/Documentation/networking/filter.txt）
3. Linux 内核 eBPF 介绍（https://www.ibm.com/developerworks/cn/linux/kernel/ebpf/index.html）
4. eBPF 性能优化技巧（https://www.infoq.com/cn/news/2018/08/ebpf-performance-tips/）
5. eBPF 实战经验分享（https://blog.cloudflare.com/ebpf-in-practice/）
6. eBPF 在网络安全中的应用（https://www.zdnet.com/article/ebpf-how-to-use-it-for-network-security/）
7. eBPF 实现 Linux 系统性能监控（https://www.percona.com/blog/2017/08/15/how-to-use-ebpf-to-monitor-linux-system-performance/）
8. eBPF 入门教程（https://sysdig.com/blog/ebpf-getting-started/）
9. eBPF 与 BPF 比较（https://lwn.net/Articles/724647/）
10. eBPF 提高课程（https://www.pluralsight.com/courses/ebpf-advanced）

附件二：发明的术语：无损编译器

（全文完）

The post eBPF 介绍 first appeared on 酷 壳 - CoolShell.

今天来讲一讲TCP 的 TIME_WAIT 的问题。这个问题尽人皆知，不过，这次遇到的是不太一样的场景，前两天也解决了，正好写篇文章，顺便把 TIME_WAIT 的那些事都说一说。对了，这个场景，跟我开源的探活小工具 EaseProbe 有关，我先说说这个场景里的问题，然后，顺着这个场景跟大家好好说一下这个事。

问题背景

先说一下背景，EaseProbe 是一个轻量独立的用来探活服务健康状况的小工具，支持http/tcp/shell/ssh/tls/host以及各种中间件的探活，然后，直接发送通知到主流的IM上，如：Slack/Telegram/Discrod/Email/Team，包括国内的企业微信/钉钉/飞书， 非常好用，用过的人都说好 。

这个探活工具在每次探活的时候，必须要从头开始建立整个网络链接，也就是说，需要从头开始进行DNS查询，建立TCP链接，然后进行通信，再关闭链接。这里，我们不会设置 TCP 的 KeepAlive 重用链接，因为探活工具除了要探活所远端的服务，还要探活整个网络的情况，所以，每次探活都需要从新来过，这样才能捕捉得到整个链路的情况。

但是，这样不断的新建链接和关闭链接，根据TCP的状态机，我们知道这会导致在探测端这边出现的 TIME_WAIT 的 TCP 链接，根据 TCP 协议的定义，这个 TIME_WAIT 需要等待 2倍的MSL 时间，TCP 链接都会被系统回收，在回收之前，这个链接会占用系统的资源，主要是两个资源，一个是文件描述符，这个还好，可以调整，另一个则是端口号，这个是没法调整的，因为作为发起请求的client来说，在对同一个IP上理论上你只有64K的端口号号可用（实际上系统默认只有近30K，从32,768 到 60,999 一共 60999+1-32768=28,232，你可以通过 sysctl net.ipv4.ip_local_port_range 查看  ），如果 TIME_WAIT 过多，会导致TCP无法建立链接，还会因为资源消耗太多导致整个程序甚至整个系统异常。

试想，如果我们以 10秒为周期探测10K的结点，如果TIME_WAIT的超时时间是120秒，那么在第60秒后，等着超时的 TIME_WAIT 我们就有可能把某个IP的端口基本用完了，就算还行，系统也有些问题。（注意：我们不仅仅只是TCP，还有HTTP协议，所以，大家不要觉得TCP的四元组只要目标地址不一样就好了，一方面，我们探的是域名，需要访问DNS服务，所以，DNS服务一般是一台服务器，还有，因为HTTPS一般是探API，而且会有网关代理API，所以链接会到同一个网关上。另外就算还可以建出站连接，但是本地程序会因为端口耗尽无法bind了。所以，现实情况并不会像理论情况那样只要四元组不冲突，端口就不会耗尽）

为什么要 TIME_WAIT

那么，为什么TCP在 TIME_WAIT 上要等待一个2MSL的时间？

以前写过篇比较宏观的《TCP的那些事》（上篇，下篇），这个访问在“上篇”里讲过，这里再说一次，TCP 断链接的时候，会有下面这个来来回回的过程。

我们来看主动断链接的最后一个状态 TIME_WAIT 后就不需要等待对端回 ack了，而是进入了超时状态。这主要是因为，在网络上，如果要知道我们发出的数据被对方收到了，那我们就需要对方发来一个确认的Ack信息，那问题来了，对方怎么知道自己发出去的ack，被收到了？难道还要再ack一下，这样ack来ack回的，那什么谁也不要玩了……是的，这就是比较著名的【两将军问题】——两个将军需要在一个不稳定的信道上达成对敌攻击时间的协商，A向B派出信鸽，我们明早8点进攻，A怎么知道B收到了信？那需要B向A派出信鸽，ack说我收到了，明早8点开干。但是，B怎么知道A会收到自己的确认信？是不是还要A再确认一下？这样无穷无尽的确认导致这个问题是没有完美解的（我们在《分布式事务》一文中说过这个问题，这里不再重述）

所以，我们只能等一个我们认为最大小时来解决两件个问题：

1） 为了 防止来自一个连接的延迟段被依赖于相同四元组（源地址、源端口、目标地址、目标端口）的稍后连接接受（被接受后，就会被马上断掉，TCP状态机紊乱）。虽然，可以通过指定 TCP 的 sequence number 一定范围内才能被接受。但这也只是让问题发生的概率低了一些，对于一个吞吐量大的的应用来说，依然能够出现问题，尤其是在具有大接收窗口的快速连接上。RFC 1337详细解释了当 TIME-WAIT状态不足时会发生什么。TIME-WAIT以下是如果不缩短状态可以避免的示例：

 

2）另一个目的是确保远端已经关闭了连接。当最后一个ACK​​ 丢失时，对端保持该LAST-ACK状态。在没有TIME-WAIT状态的情况下，可以重新打开连接，而远程端仍然认为先前的连接有效。当它收到一个SYN段（并且序列号匹配）时，它将以RST应答，因为它不期望这样的段。新连接将因错误而中止：

 

TIME_WAIT 的这个超时时间的值如下所示：

• 在 macOS 上是15秒， sysctl net.inet.tcp | grep net.inet.tcp.msl
• 在 Linux 上是 60秒 cat /proc/sys/net/ipv4/tcp_fin_timeout

解决方案

要解决这个问题，网上一般会有下面这些解法

• 把这个超时间调小一些，这样就可以把TCP 的端口号回收的快一些。但是也不能太小，如果流量很大的话，TIME_WAIT一样会被耗尽。
• 设置上 tcp_tw_reuse 。RFC 1323提出了一组 TCP 扩展来提高高带宽路径的性能。除其他外，它定义了一个新的 TCP 选项，带有两个四字节时间戳字段。第一个是发送选项的 TCP 时间戳的当前值，而第二个是从远程主机接收到的最新时间戳。如果新时间戳严格大于为前一个连接记录的最新时间戳。Linux 将重用该状态下的现有 TIME_WAIT 连接用于出站的链接。也就是说，这个参数对于入站连接是没有任何用图的。
• 设置上 tcp_tw_recycle 。 这个参数同样依赖于时间戳选项，但会影响进站和出站链接。这个参数会影响NAT环境，也就是一个公司里的所有员工用一个IP地址访问外网的情况。在这种情况下，时间戳条件将禁止在这个公网IP后面的所有设备在一分钟内连接，因为它们不共享相同的时间戳时钟。毫无疑问，禁用此选项要好得多，因为它会导致 难以检测和诊断问题。（注：从 Linux 4.10 (commit 95a22caee396 ) 开始，Linux 将为每个连接随机化时间戳偏移量，从而使该选项完全失效，无论有无NAT。它已从 Linux 4.12中完全删除）

对于服务器来说，上述的三个访问都不能解决服务器的 TIME_WAIT 过多的问题，真正解决问题的就是——不作死就不会死，也就是说，服务器不要主动断链接，而设置上KeepAlive后，让客户端主动断链接，这样服务端只会有CLOSE_WAIT。

但是对于用于建立出站连接的探活的 EaseProbe来说，设置上 tcp_tw_reuse 就可以重用 TIME_WAIT 了，但是这依然无法解决 TIME_WAIT 过多的问题。

然后，过了几天后，我忽然想起来以前在《UNIX 网络编程》上有看到过一个Socket的参数，叫 <code>SO_LINGER，我的编程生涯中从来没有使用过这个设置，这个参数主要是为了延尽关闭来用的，也就是说你应用调用 close()函数时，如果还有数据没有发送完成，则需要等一个延时时间来让数据发完，但是，如果你把延时设置为 0  时，Socket就丢弃数据，并向对方发送一个 RST 来终止连接，因为走的是 RST 包，所以就不会有 TIME_WAIT 了。

这个东西在服务器端永远不要设置，不然，你的客户端就总是看到 TCP 链接错误 “connnection reset by peer”，但是这个参数对于 EaseProbe 的客户来说，简直是太完美了，当EaseProbe 探测完后，直接 reset connection， 即不会有功能上的问题，也不会影响服务器，更不会有烦人的 TIME_WAIT 问题。

Go 实际操作

在 Golang的标准库代码里，net.TCPConn 有个方法 SetLinger()可以完成这个事，使用起来也比较简单：

conn, _ := net.DialTimeout("tcp", t.Host, t.Timeout())

if tcpCon, ok := conn.(*net.TCPConn); ok {
    tcpCon.SetLinger(0)
}

你需要把一个 net.Conn  转型成 net.TCPConn，然后就可以调用方法了。

但是对于Golang 的标准库中的 HTTP 对象来说，就有点麻烦了，Golang的 http 库把底层的这边连接对象全都包装成私有变量了，你在外面根本获取不到。这篇《How to Set Go net/http Socket Options – setsockopt() example 》中给出了下面的方法：

dialer := &net.Dialer{
    Control: func(network, address string, conn syscall.RawConn) error {
        var operr error
        if err := conn.Control(func(fd uintptr) {
            operr = syscall.SetsockoptInt(int(fd), unix.SOL_SOCKET, unix.TCP_QUICKACK, 1)
        }); err != nil {
            return err
        }
        return operr
    },
}

client := &http.Client{
    Transport: &http.Transport{
        DialContext: dialer.DialContext,
    },
}

上面这个方法非常的低层，需要直接使用setsocketopt这样的系统调用，我其实，还是想使用 TCPConn.SetLinger(0) 来完成这个事，即然都被封装好了，最好还是别破坏封闭性碰底层的东西。

经过Golang http包的源码阅读和摸索，我使用了下面的方法：

client := &http.Client{
    Timeout: h.Timeout(),
    Transport: &http.Transport{
      TLSClientConfig:   tls,
      DisableKeepAlives: true,
      DialContext: func(ctx context.Context, network, addr string) (net.Conn, error) {
        d := net.Dialer{Timeout: h.Timeout()}
        conn, err := d.DialContext(ctx, network, addr)
        if err != nil {
          return nil, err
        }
        tcpConn, ok := conn.(*net.TCPConn)
        if ok {
          tcpConn.SetLinger(0)
          return tcpConn, nil
        }
        return conn, nil
      },
    },
  }

然后，我找来了全球 T0p 100W的域名，然后在AWS上开了一台服务器，用脚本生成了 TOP 10K 和 20K 的网站来以5s, 10s, 30s, 60s的间隔进行探活，搞到Cloudflare 的 1.1.1.1 DNS 时不时就把我拉黑，最后的测试结果也非常不错，根本 没有 TIME_WAIT 的链接，相关的测试方法、测试数据和测试报告可以参看：Benchmark Report

总结

下面是几点总结

• TIME_WAIT 是一个TCP 协议完整性的手段，虽然会有一定的副作用，但是这个设计是非常关键的，最好不要妥协掉。
• 永远不要使用  tcp_tw_recycle ，这个参数是个巨龙，破坏力极大。
• 服务器端永远不要使用  SO_LINGER(0)，而且使用 tcp_tw_reuse 对服务端意义不大，因为它只对出站流量有用。
• 在服务端上最好不要主动断链接，设置好KeepAlive，重用链接，让客户端主动断链接。
• 在客户端上可以使用 tcp_tw_reuse  和 SO_LINGER(0)。

最后强烈推荐阅读这篇文章 – Coping with the TCP TIME-WAIT state on busy Linux servers

（全文完）

The post 从一次经历谈 TIME_WAIT 的那些事 first appeared on 酷 壳 - CoolShell.