前面我们学过的top、vmstat、iostat、strace——它们能告诉你发生了什么，但很难回答为什么会发生。比如系统负载突然飙升，CPU使用率却不高——如果能看到内核函数级别的调用耗时，问题就一目了然了。SystemTap和eBPF正是为此而生的“内核显微镜”。本文介绍动态追踪技术的原理，对比SystemTap和eBPF两条技术路线，并通过BCC工具集中的execsnoop和opensnoo

内核是Linux系统的灵魂，所有我们前面学过的命令、服务、应用都运行在它之上。但绝大多数人用的是发行版预编译好的“通用内核”——它为了兼容各种硬件，塞进了大量你根本不需要的驱动和模块。本文带你走出舒适区，亲手从kernel.org获取源码，通过make menuconfig配置界面裁剪出一个适合自己系统的精简内核，然后编译、安装、配置Grub引导，并设置双内核启动的保底方案——新内核即使启动失败，

TCP流量控制通过接收方通告窗口来调节发送方速率，防止发送方淹没处理能力不足的接收方。然而，这一机制若不加精细控制，会陷入两种对称的失效模式：接收方通告小窗口导致发送方产生大量小数据段，或发送方自身主动发送小数据段浪费网络带宽——前者即糊涂窗口综合征，后者由Nagle算法抑制。本文分析这两种失效模式的成因与交互，论证Clark算法和Nagle算法如何在收、发两侧分别解决小段问题，并讨论二者在特定场

TCP性能瓶颈的定位不能依赖主观直觉，而应基于抓包数据的定量分析。本文区分超时重传与快速重传的判定准则和推断逻辑，前者意味着网络严重拥塞或连接中断，后者指示偶发丢包但链路仍然通畅。通过TCP Trace图的拥塞窗口、接收窗口与在途数据的叠加分析，可以直观诊断发送方被阻塞的原因——是拥塞控制窗口限制还是接收方通告窗口限制。在此基础上，分析Bufferbloat的成因——过大的路由器缓冲区将丢包信号延

TCP拥塞控制经历了从启发式丢包反馈到模型化带宽探测的范式转移。本文以AIMD原则为理论起点，分段推导慢启动、拥塞避免、快速重传与快速恢复四个阶段的算法细节，阐明Reno如何将丢包作为拥塞信号并据此调节窗口。在此基础上，分析CUBIC以三次函数替代Reno的线性窗口增长，解决高带宽长时延网络中的收敛效率问题。重点讨论BBR的范式转向——不再依赖丢包作为拥塞信号，而是通过持续测量瓶颈带宽与最小RTT

Linux内核网络栈是理解网络行为与诊断故障的基础。本文从数据包在物理链路上到达网卡开始，逐阶段描述数据包从网卡驱动到套接字接收缓冲区的完整路径：硬中断触发、NAPI软中断调度、数据包从网卡环形缓冲区DMA拷贝至内核、协议栈逐层处理、netfilter钩子点的规则遍历、路由决策、最终递交到应用层套接字。分析每一阶段的缓冲区管理策略及其在高负载下的瓶颈特征，阐明iptables规则顺序与netfil

并查集是一种树形的数据结构，用于处理不相交集合的合并与查询问题。它支持两种操作：查找（Find）元素属于哪个集合，合并（Union）两个集合。并查集代码极短但思想精巧，配合路径压缩和按秩合并后，时间复杂度接近O(1)。这一篇我们实现并查集，重点讲解路径压缩优化，并用它解决朋友圈问题。

前9篇我们学了顺序表、单链表、双向链表等线性结构。这一篇来做个实战项目：学生信息管理系统。我们会用单链表来存储学生信息，实现增删改查功能，并采用模块化设计，把代码拆分成.h和.c文件。这是一个完整的命令行小项目，你可以把它当作数据结构学习的第一个综合练习。

最短路径问题是图论中的核心问题之一。这一篇我们学习两种最经典的算法：Dijkstra算法解决单源最短路径（从一个顶点到其他所有顶点），Floyd算法解决多源最短路径（任意两点之间）。Dijkstra基于贪心思想，不能处理负权边；Floyd基于动态规划，代码简洁但时间复杂度较高。我们会用C语言实现两种算法，并分析它们的适用场景。

查找是在数据集合中寻找满足特定条件的数据元素。静态查找指查找过程中数据集合不变。这一篇我们学习两种最基本的静态查找算法：顺序查找和折半查找。顺序查找简单但效率低，折半查找效率高但要求数据有序。我们会实现哨兵优化的顺序查找，以及折半查找的递归和非递归版本，并介绍折半查找的判定树。