看到源码就觉得恐惧，这是一种病，得治！

大家好，我是飞哥！

咱们的《深入理解Linux网络》是 5 月 31 号首发的，现在有 5 个多月的时间了。目前已经印刷了 1.9万册，而且预计很快就会再继续加印了。在技术书籍里这实属已经是一个非常不错的成绩了。但最近豆瓣上的几条书的差评让我陷入了进一步的思考。

目前豆瓣上的总评价人数是 65 人。其中打四星五星好评的同学占比 78.5%，占比不低。

但是仍然有一些打出了普通评价，甚至还有一位打出了一星，两位打出了二星的差评。打低星的同学主要都围绕一个点，都在嫌弃咱们书中提供了内核源码。

虽然打低星的同学比例很低，但是由于豆瓣的积分机制，一下子就把平均分给拉下来了，导致总评分从 9 分多跌破了 8。

首先先感谢上面能认真阅读书中的内容，并还抽空到豆瓣上给出积极评价的同学。你们的积极评价不光是对飞哥两年工作成果的认可，也还给业内打算在网络上学习东西的同学给了很好的参考。

接下来我再说说为什么在写作中要坚持在创作中展示内核关键源码，有这么几个原因：

第一，只有理解源码才能更接近真相

在我刚工作的前几年，和绝大部分同学一样，对内核源码有着深深的恐惧感。遇到线上问题基本都是靠猜，或者 Google 几篇隔靴挠痒的原理技术文。对底层运行原理，和线上问题的处理一直都处于似懂非懂的状态。

在破除源码恐惧后，我对底层的工作原理有了质的飞跃。举个例子，比如 listen 中的 backlog，只有看完源码以后才恍然大悟领会了它的真正含义。很多线上问题，或者性能瓶颈的时候能更快地接近最核心的点。

现在我遇到线上问题后，部分时候都不是先 Google，而是先去当前使用的版本的内核源码里翻翻看能不能找到答案。因为 Google 出来的内容质量参差不齐，而且还有可能早已过时了的。源码虽然难，但是它是最准的。

第二、内核实现是不断地在演进的

Linux 实现是不断地在演进的，如果只是写理论结论，那今天看起来正确的结论，没准儿将来哪一天就变成错的了。

在书中写源码核心逻辑，目的也是把我自己理解 Linux 网络的思路过程提供给大家。不光是授人以鱼，更想是授人以渔。帮助大家理解网络源码的核心逻辑，而不是单纯只记我说的结论。

我在每一段源码的开头都会把这段源码所在的文件路径给标出来了。这样未来大家再遇到内核实现有变更的地方，顺着这些去源码中再翻一翻就能摸索到答案了。

第三、源码展示只保留了骨干逻辑

亲自看过内核源码的同学都知道内核源码无比的庞大和复杂。为了让大家能更快地理解 Linux 网络全貌，我书中都只保留的是核心骨干逻辑，都是非常关键的地方。

比如 tcp_v4_do_rcv，这个函数在内核中实际有 73 行，而我是这样展示的。

另外，抽取完骨干逻辑还比较复杂的逻辑，我基本都配了图帮助大家更容易理解。靠图来把骨干逻辑进行进一步的抽取。

第四、想在未来用好 eBPF 等工具不理解源码是不行的

现在在各家大公司，eBPF 都已经开始逐渐流行起来了。而使用 eBPF 的话，无论是做最基础的跟踪观测也好，还是进阶的网络行为修改，都有要求使用者理解内核的源码主体逻辑。

如果不具备起码的内核源码掌控能力，那么对于这种强有力的技术基本无法驾驭。例如 bpftrace 打出来的跟踪点，都是和内核源码相关的。

有的同学建议只讲原理，辅以各种工具剖析。

就看 bcc 工具集吧，每一款也都是工作在特定内核层的。不理解特定内核层在干啥的话，直接用这种工具根本用不明白。

出于以上的几个原因，所以我认为在书中展示源码核心逻辑是很有价值的。如果不写源码，只讲原理的话，我们就退变成了一本理论上的教科书了。那不是我的目的，至少不是现阶段的目的。而且这种理论上的教科书已经很多了，不缺这一本。

现在我还是更想把网络上的理论知识，和 Linux 上的工程实现结合起来。让大家更好地在排查工作中遇到的网络问题，更多地挖掘手头项目的性能优化空间。这是我更想达成的目标。

虽然我们绝大部分时候学习一种技术的时候都不需要去看它的源码，但是如果你想真的理解它的工作原理的话，源码是绕不开的。

所以虽然在豆瓣中有少量的读者嫌弃咱们书中提供了内核源码，但出于以上的原因，在未来的创作中我仍然还会坚持核心源码的展示，至少短期内仍然会保持这个风格。

在将来的继续创作中，我可能会考虑升级一下我所看的内核的版本。因为我发现这两年越来越多的公司都把自己的发行版升级到了 4 甚至是 5 的内核。