抓包破案录：序章

Hi，我是信涛，喜欢抓包。

我打算写一个以现实应用的网络技术为主题的系列文章，姑且将其称之为「书」吧。（还从没有写过系列长篇，所以这对我来说也是一个挑战。）

这本书面向的读者

大学的网络课程，和很多计算机网络的教材，普遍存在一个问题：内容比较抽象。大部分教材都是适合对网络有所了解的人，去学习新的网络来阅读。如果是刚刚学习网络，会觉得这些抽象的内容比较难理解，会产生多问题，而这些问题大部分来自于不正确的理解。

由于内容抽象，导致阅读枯燥。我经历过这一段时间，比较喜欢学习编程，因为编程学习了就可以实践，能够看到效果；而网络的学习通常不好实践，没有实践的话，学习效果就大打折扣。所以一度认为自己与计算机网络八字不合。

但是当我在工作中遇到网络问题，没有人能够解决（或者愿意花时间去解决），然后我去抓包，分析，最后精准找到问题原因的时候，我发现网络是如此有趣！

之后的工作中，我积累了很多网络问题排查的案例，有一些记录在之前的博客中了，有一些还只存在我的笔记中。

这些案例都和网络协议等基础知识有关，又需要动手，结合实际来分析。我发现去解决实际问题很大程度上加深了我对原来学习的内容的理解。我也发现，有很多人工作多年，竟然从没用过 Wireshark 来分析网络问题（即使他们的工作和网络相关！）。我认为原因就是，第一次太难，当你从没有用 Wireshark 来解决问题，那么遇到问题的时候，你也不会想到去分析。即使打开，面对五花八门的字段，也会感觉无从下手。我也经过这种时候。但是如果用过几次，就不一样了，在用 Wireshark 解决过一次问题之后，信心会大增，甚至遇到问题会感到兴奋——我倒要看看还能是哪里出了问题！

所以本书以让实际动手分析为主，章节大部分成对出现，第一节抛出问题，描述问题，读者可以进行自己的分析。之后发布第二节，揭晓答案，结合网络协议知识，分析相关的网络设计。

另一个问题是，教科书普遍都在介绍过时的技术。比如谈到数据链路层，必开始介绍 CDMA 如何解决冲突的，这部分内容比较枯燥，也让人困惑：为什么 Frame 要发给不需要它的机器，然后再处理冲突？事实上，这都已经是几十年前的网络了，现代的网络 Ethernet 是全双工的，交换机是只发给指定目的端口的，完全不会遇到冲突然后避让。当然学习这些技术是有用的，但是不建议一上来就讲这么枯燥、现代网络又几乎用不上的内容。

比如谈到 IP 地址，必介绍 IP 分类。然后出个问题考考你：「这个 IP 是 A 类还是 B 类？」后来，工作这么多年从没遇到一个问题需要我判断一个 IP 是几类 IP 的（倒是需要经常判断一个 IP 是不是 Private IP）。因为如今的网络掩码都是可变长度了，Classful network 那是上个世纪的东西了，没有人用这种 IP 分类划分网络了。

网络的世界中存在很多这种「过时」的设计，根本原因是，在设计之初，没有意识到今后的世界会如何发展，比如 IPv4 耗尽问题，近几年的区块链趋势，AI，等等，所以不合时宜的设计是必然会存在的。我们需要学习的是这些设计当初的考虑是什么，为什么这么设计，存在的问题有哪一些，如今的替代方案是什么。这样，才不会让自己都「学了一些没用的东西」。即使学习「过时」的技术，我们也可以从中吸取经验。

所以本书会结合现代的网络技术，介绍网络知识的同时，也介绍一下当前流行的解决方案。

本书适合阅读过一些网络教材但是感觉一身武功无处施展的读者，也适合在工作中没有思路解决实际的网络问题的读者，如果你是网络高手的话，可以拿本书来消遣，看本书抛出的问题是否能够应付自如。

如何阅读？

在问题章节，会描述问题的场景，给出一个抓包文件。读者可以根据对问题的描述，下载抓包文件进行分析，得出自己的答案。推荐重新阅读一遍问题的描述，看一下自己的答案是否能够完全解释的通场景中的问题。（就像做 leetcode 一样，有趣吧？）

读者可以在评论区发布自己的想法，和其他读者交流。我会在文末留白来和评论隔离开，避免剧透。

答案发布之后，如果读者的想法和答案一致，说明我们英雄所见略同。如果不一致，也可以将您的想法贴在评论中，说不定答案并不止一种。

问题的设计会尽量让读者有「哦！原来是这样」的感觉，而不是感觉被耍了。不然我又写成枯燥的计算机网络教材了。欢迎读者在评论中对文章质量作出反馈。

投稿？

如果您也有有意思的网络问题，欢迎通过博客右侧的邮箱联系我。说不定可以设计成一个题目。

由于是一个完整系列，需要耗费很多心血，本想做订阅制，还是觉得不合适，有人读这些东西已经很荣幸了，而且订阅制也会让自己压力变大。我还是觉得自己想写什么就写什么，才会写出让自己满意的东西来。

这里放一个赞赏码吧，如果读者感到本系列内容有所帮助，欢迎打赏。

我会坚持分享自己学到的知识。