perf 是常用的性能分析工具，记录基本使用方法。
glibc 这个 c 库，封装了很多代码，可以通过 gdb 调试进去深入理解底层源码。
为了使用 linux 高版本内核功能，使用了 ubuntu 20.4，记录一下使用新系统时的相关软件安装配置。
文件描述符透传，它始终由一个进程（主进程）独占 listen socket，由它去获取资源，然后分派给其它的子进程。
SO_REUSEPORT (reuseport) 是网络的一个选项设置，它能开启内核功能：网络链接分配 内核负载均衡。
该功能允许多个进程/线程 bind/listen 相同的 IP/PORT，提升了新链接的分配性能。
nginx 开启 reuseport 功能后，性能有立竿见影的提升，我们结合 tcp 协议分析 nginx 的 reuseport 功能。
reuseport 也是内核解决 惊群问题 的优秀方案。
每个进程可以 bind/listen 相同的 IP/PORT，相当于每个进程拥有独立的 listen socket 的完全队列，避免了共享 listen socket 的资源争抢，提升了并发的吞吐。
内核通过哈希算法，将新链接相对均衡地分配到各个开启了 reuseport 属性的进程，所以资源的负载均衡得到解决。
EPOLLEXCLUSIVE 是 2016 年 4.5+ 内核新添加的一个 epoll 的标识（代码改动较小，详看：github）。
它降低了多个进程/线程通过 epoll_ctl 添加共享 fd 引发的惊群概率，使得一个事件发生时，只唤醒一个正在 epoll_wait 阻塞等待唤醒的进程/线程（而不是全部唤醒）。
而 Ngnix 在 1.11.3 之后相应添加了 NGX_EXCLUSIVE_EVENT 功能标识（代码改动较小，详看：github），它使用了 EPOLLEXCLUSIVE 特性。
对比 nginx 在应用层的解决方案：accept_mutex，NGX_EXCLUSIVE_EVENT 它从内核层面避免惊群问题，它更简洁高效。
该功能的工作原和使用相对简单：进程使用 epoll_ctl 添加 listen socket fd 时，把 EPOLLEXCLUSIVE 属性添加进去就可以了。多个进程通过 epoll_wait 等待 listen socket 事件，当有新链接到来时，内核只唤醒一个等待的进程。
我们从应用层（nginx）和内核去分析 epoll 的 EPOLLEXCLUSIVE 属性工作原理。
由主进程创建的 listen socket，是被 fork 出来的子进程共享的，但是为了避免多个子进程同时争抢共享资源，nginx 采用一种策略：使得多个子进程，同一时段，只有一个子进程能获取资源，就不存在共享资源的争抢问题。
但是这个策略是建立在多个子进程竞争锁的基础上的：
成功获取锁的，能获取一定数量的资源，而其它没有成功获取锁的子进程，不能获取资源，只能等待成功获取锁的进程释放锁后，nginx 多进程再重新进入锁竞争环节。
所以在应用层上，还是会存在一些锁竞争问题。
本文将通过测试，重现 nginx(1.20.1) 的惊群现象，并深入 Linux (5.0.1) 内核源码，剖析惊群原因。
早期的 accept 同步阻塞睡眠等待资源，当资源到来时，在多个进程或线程上睡眠的 accept 会同时被唤醒处理。后来 Linux 内核增加了 WQ_FLAG_EXCLUSIVE 排它唤醒属性，避免了惊群问题。
本文将深入 Linux 内核（5.0.1）源码，剖析在 TCP 多进程框架下，同步阻塞 accept 的惊群处理。
既然是 TCP 协议的 accept，那不得不了解三次握手和进程睡眠唤醒的原理。
惊群比较抽象，类似于抢红包 😁。它多出现在高性能的多进程/多线程服务中，例如：nginx。
探索惊群 系列文章将深入 Linux (5.0.1) 内核，透过 多进程模型 去剖析惊群现象、惊群原理、惊群的解决方案。
Linux 操作系统，为了避免用户程序非法操作设备资源，需要限制进程的操作权限，这样内核为用户程序提供了一组交互的接口，用户程序通过这组接口进行 系统调用。
本文将会通过调试方式，从用户程序到内核，理解一下系统调用的工作流程。
文章 Linux 内核源码基于 Linux 5.0.1。
走读网络协议栈 tcp 发送数据的内核源码（Linux - 5.0.1 下载）。
数据发送实现比较复杂，牵涉到 OSI 模型所有分层，所以需要对每个分层都要有所了解，才能理清工作流程和实现思路。
最好的两个参考资料：
书籍：《Linux 内核源码剖析 - TCP/IP 实现》 上下两册。
走读网络协议栈 tcp 的内核源码（Linux - 5.0.1 下载）。通过 Linux 内核源码理解 tcp 三次握手状态变化。
因为我走读的是 Linux 5.0.1 源码，与旧版的 Linux 3.x 系列比较，新版的三次握手的状态已经发生改变，这个需要注意一下。
rsync 比 scp 传输文件要好，因为它是差异化传输，效率极高，是跨平台工作的神兵利器；我经常在 mac 机器上写代码，然后通过 rsync 命令将源码同步到 linux 机器上运行。
编程中，需要经常处理信号，根据信号值查询对应的意思，为了方便查询记录一下。