A. 如何选择一个 linux Tracer
tracer 是一个高级的性能分析和诊断工具，但是不要让这名词唬住你，如果你使用过 strace 和tcpmp，其实你就已经使用过 tracer 了。系统 tracer 可以获取更多的系统调用和数据包。它们通常能跟踪任意的内核和应用程序。
有太多的 linux tracer 可以选择。每一种都有其官方的（或非官方的）的卡通的独角兽吉祥物，足够撑起一台"儿童剧"了。
那么我们应该使用哪个 tracer 呢？
我会为两类读者回答这个问题，大部分人和性能/内核工程师。过一段时间这些可能会发生变化，我会持续跟进并补充，大概会一年更新一次。
多数人
多数人 (开发者，系统管理员，开发管理者，运维人员，评测人员，等等) 不关心系统追踪器的细节。下面是对于追踪器你应该知道和做的：
1. 使用perf_events分析CPU性能
使用 perf_events 做 CPU 性能分析。性能指标可以使用flame graph 等工具做可视化。
git clone --depth 1 https://github.com/brendangregg/FlameGraph
perf record -F 99 -a -g -- sleep 30
perf script | ./FlameGraph/stackcollapse-perf.pl | ./FlameGraph/flamegraph.pl > perf.svg
Linux perf_events (又称 "perf"，同命令名) 是 Linux 用户的官方追踪器和性能分析器。内置于内核代码，有很好维护（近来获得快速增强），通常通过 linux 命令行工具包添加。
perf 有很多功能，如果只能推荐一个，我选择 CPU 性能分析。尽陵友管这只是采样，而不是从技术上追踪事件。最难的部分是获取完整的栈和信息，我为 java 和 node.js 做的一个演讲 Linux Profiling at Netflix中已经说过这个问题
2.了解其他的Tracer
正如我一个朋友说的：“你不需要知道如何操作 X 射线机器，但是一旦你吞了一枚硬币，你得知道这得去做 X 射线”，你应该了解各种 tracer 都能做什么，这样就能在你工作中真正需要 tracer 的时候，你既可以选择稍后学习使用，也可以雇相应的人来完成。
简短来说：几乎所有的东西都可以使用 tracer 来尺手槐进行分析和跟踪。如，文件系统，网络处理器，硬件驱动器，全部的应用程序。可以看一下我的个人网站上关于 ftrace的文章，还有我写的薯蚂关于perf_events 文档介绍，可以做为一个追踪(或者性能分析)的例子。
3. 寻求前端支持工具
如果你正想买一个能支持跟踪 Linux 的性能分析工具（有许多卖这类工具的公司）。想象一下，只需要直接点击一下界面就能“洞察”整个系统内核，包括隐藏的不同堆栈位置的热图，我在Monitorama talk 中介绍了一个这样带图形界面的工具。
我开源了一些我自己开发的前端工具，尽管只是 CLI （命令行界面）而不是（图形界面）。这些工具也会让人们更加快速容易的使用 tracer。比如下面的例子，用我的 perf_tool，跟踪一个新进程:
# ./execsnoopTracing exec()s. Ctrl-C to end.
PID PPID ARGS
22898 22004 man ls
22905 22898 preconv -e UTF-8
22908 22898 pager -s
22907 22898 nroff -mandoc -rLL=164n -rLT=164n -Tutf8
[...]
在 Netflix 上，我们创建了一个 Vector，一个分析工具的实例同时也是 Linux 上的 tracer 的最终前端。
致性能或内核工程师
我们的工作变的越来越困难，很多的人会问我们怎么样去追踪，哪种路径可以用！为了正确理解一个路径，你经常需要花上至少100个小时才能做到。理解所有的 linux 路径去做出理性的决定是一个浩大的工程。（我可能是唯一一个接近做到这件事情的人）
这里是我的建议，可以二选其一：
A) 选中一个全能的路径，并且使它标准化，这将涉及花费大量的时间去弄清楚它在测试环境中的细微差别和安全性。我现在推荐 SystemTap 的最新版本（ie，从源代码构建）。我知道有些公司已经选用 LTTng，而且他们用的很好，尽管它不是非常的强大（虽然它更安全）。Sysdig 可以成为另一个候选如果它可以增加追踪点或者 kprobes。
B) 遵循我上面提供的流程图，它将意味着尽可能更多的使用 ftrace 或者 perf_event， eBPF 会得到整合，之后其他的路径像 SystemTap/LTTng 会去填补这个空白。这就是我目前在 Netflix 做的工作。
tracer 的评论：
1. ftrace
我喜欢用 ftrace，它是内核 hacker 的首选，内置于系统内核，可以使用跟踪点(静态检查点)，能调用内核 kprobes 和 uprobes 调试工具。并且提供几个这样的功能：带可选过滤器和参数的事件追踪功能；在内核中进行统计的事件计数和定时功能；还有函数流程遍历的功能。可以看一下内核代码中 ftrace.txt 例子了解一下。ftrace 由 /sys 控制，仅支持单一的 root 用户使用（但是你可以通过缓冲区实例破解以支持多用户）。某些时候 Ftrace 的操作界面非常繁琐，但是的确非常“hack”，而且它有前端界面。Steven Rostedt，ftace 的主要作者，创建了 trace-cmd 命令工具，而我创建了 perf 的工具集。我对这个工具最大的不满就是它不可编程。举例来说，你不能保存和获取时间戳，不能计算延迟，不能把这些计算结果保存成直方图的形式。你需要转储事件至用户级别，并且花一些时间去处理结果。ftrace 可以通过 eBPF 变成可编程的。
2.perf_events
perf_events 是 Linux 用户的主要跟踪工具，它内置在内核源码中，通常通过 linux-tools-commom 加入。也称“perf”，同前端工具名称，通常用来跟踪和转储信息到一个叫做 perf.data 的文件中，perf.data 文件相当于一个动态的缓冲区，用来保存之后需要处理的结果。ftrace 能做到的，perf_events 大都也可以做到，perf-events 不能做函数流程遍历，少了一点儿“hack”劲儿（但是对于安全/错误检查有更好的支持）。它可以进行 CPU 分析和性能统计，用户级堆栈解析，也可以使用对于跟踪每行局部变量产生的调试信息。它也支持多用户并发操作。和 ftrace 一样也不支持可编程。如果要我只推荐一款 tracer，那一定是 perf 了。它能解决众多问题，并且它相对较安全。
3. eBPF
extended Berkeley Packet Filter（eBPF）是一个可以在事件上运行程序的高效内核虚拟机（JIT）。它可能最终会提供 ftrace 和 perf_events 的内核编程，并强化其他的 tracer。这是 Alexei Starovoitov 目前正在开发的，还没有完全集成，但是从4.1开始已经对一些优秀的工具有足够的内核支持了，如块设备I/O的延迟热图。可参考其主要作者 Alexei Starovoitov 的BPF slides和eBPF samples。
4. SystemTap
SystemTap 是最强大的tracer。它能做所有事情，如概要分析，跟踪点，探针，uprobes（来自SystemTap），USDT和内核编程等。它将程序编译为内核模块，然后加载，这是一种获取安全的巧妙做法。它也是从tree发展而来，在过去有很多问题（多的可怕）。很多不是 SystemTap 本身的错——它常常是第一个使用内核追踪功能，也是第一个碰到 bug 的。SystemTap 的最新版本好多了（必须由源代码编译），但是很多人仍然会被早期版本吓到。如果你想用它，可先在测试环境中使用，并与irc.freenode.net上 的 #systemtap 开发人员交流。（Netflix 有容错机制，我们已经使用了 SystemTap，但是可能我们考虑的安全方面的问题比你们少。）我最大的不满是，它似乎认为你有常常没有的内核 debug 信息。实际上没有它也能做很多事情，但是缺少文档和例子（我必须自己全靠自己开始学习）。
5. LTTng
LTTng 优化了事件采集，这比其他 tracers 做得好。它从 tree 发展而来，它的核心很简单：通过一组小规模的固定指令集将事件写入追踪缓冲区，这种方式使它安全、快速，缺点是它没有内核编码的简单途径。我一直听说这不是一个大问题，因为尽管需要后期处理，它也已经优化到可以充分的度量。此外，它还首创了一个不同的分析技术，更多对所有关注事件的黑盒记录将稍后以 GUI 的方式进行研究。我关心的是前期没有考虑到要录制的事件缺失问题如何解决，但我真正要做的是花更多时间来看它在实践中用的怎么样。这是我花的时间最少的一个 tracer（没有什么特殊原因）。
6. Ktap
ktap 在过去是一款前景很好的 tracer，它使用内核中的 lua 虚拟机处理，在没有调试信息的情况下在嵌入式设备上运行的很好。它分为几个步骤，并在有一段时间似乎超过了 Linux 上所有的追踪器。然后 eBPF 开始进行内核集成，而 ktap 的集成在它可以使用 eBPF 替代它自己的虚拟机后才开始。因为 eBPF 仍将持续集成几个月，ktap 开发者要继续等上一段时间。我希??今年晚些时候它能重新开发。
7. dtrace4linux
dtrace4linux 主要是 Paul Fox 一个人在业余时间完成的，它是 Sun DTrace 的 Linux 版本。它引入瞩目，还有一些 provider 可以运行，但是从某种程度上来说还不完整，更多的是一种实验性的工具（不安全）。我认为，顾忌到许可问题，人们会小心翼翼的为 dtrace4linux 贡献代码：由于当年 Sun 开源DTrace 使用的是 CDDL 协议，而 dtrace4linux 也不大可能最终进入 Linux kernel。Paul 的方法很可能会使其成为一个 add-on。我很乐意看到 Linux 平台上的 DTrace 和这个项目的完成，我认为当我加入 Netflix 后将会花些时间来协助完成这个项目。然而，我还是要继续使用内置的 tracers，如 ftrace 和 perf_events。
8.OL DTrace
Oracle Linux DTrace为了将 DTrace 引入 Linux，特别是 Oracle Linux，做出了很大的努力。这些年来发布的多个版本表明了它的稳定进展。开发者们以一种对这个项目的前景看好的态度谈论着改进 DTrace 测试套件。很多有用的 provider 已经完成了，如：syscall, profile, sdt, proc, sched 以及 USDT。我很期待 fbt（function boundary tracing, 用于内核动态跟踪）的完成，它是 Linux 内核上非常棒的 provider。OL DTrace 最终的成功将取决于人们对运行 Oracle Linux（为技术支持付费）有多大兴趣，另一方面取决于它是否完全开源：它的内核元件是开源的，而我没有看到它的用户级别代码。
9. sysdig
sysdig是一个使用类tcpmp语法来操作系统事件的新tracer，它使用lua提交进程。它很优秀，它见证了系统跟踪领域的变革。它的局限性在于它只在当前进行系统调用，在提交进行时将所有事件转储为用户级别。你可以使用系统调用做很多事情，然而我还是很希望它能支持跟踪点、kprobe和uprobe。我还期待它能支持eBPF做内核摘要。目前，sysdig开发者正在增加容器支持。留意这些内容。
延伸阅读
我关于 tracer 的工作包括：
ftrace：我的 perf-tools工具集（参考实例目录）；我在 lwn.net 上的 关于ftrace的文章；LISA14的发言；还有帖子：函数计数， iosnoop，opensnoop，execsnoop，TCP转发， uprobes 以及USDT。
perf_evenets：我的网页 perf_events实例；SCALE上的发言Netflix的Linux性能分析；还有帖子CPU采样，静态追踪点，热点图，计数，内核行追踪，off-CPU时间图。
eBPF：帖子eBPF：迈出一小步，和一些BPF工具（我需要发布更多）。
SystemTap：我很久以前写了一篇有点过期的帖子使用SystemTap。最近，我发布了一些工具systemtap-lwtools来演示如何在没有内核诊断信息的情况下使用SystemTap。
LTTng：我只花了一点时间，还不足以发表任何内容。
ktap：我的网页ktap实例包含一些早期版本的单行小程序和脚本。
dtrace4linux：我在系统性能一书中给出了一些实例，并曾经开发了一些小的修复程序，如timestamps。
OL DTrace：由于它直接由DTrace转变而来，很多我早期关于DTrace的工作都有相关性（如果在这里给出链接的话就太多了，可以在我的主页上搜索）。当它更完善时，我会开发一些特殊工具。
sysdig：我向 fileslower 和 subsecond offset spectrogram 贡献了代码。
其他：我写了关于strace 的注意事项。
请不要有更多的 tracer！如果你想知道为什么 Linux 不仅仅只有一个 tracer，或者只用本身的DTrace，你可以在我的演讲稿从DTrace到Linux中找到答案，从28张幻灯片开始。
感谢Deirdré Straughan的编辑，以及与 General Zoi 的小马宝莉创作者一起创作的 tracing 小马。
B. 如何选择一个 Linux Tracer
tracer 是一个高级的性能分析和诊断工具，但是不要让这名词唬住你，如果你使用过 strace 和tcpmp，其实你就已经使用过 tracer 了。系统 tracer 可以获取更多的系统调用和数据包。它们通常能跟踪任意的内核和应用程序。
有太多的 linux tracer 可以选择。每一种都有其官方的（或非官方的）的卡通的独角兽吉祥物，足够撑起一台"儿童剧"了。
那么我们应该使用哪个 tracer 呢？
我会为两类读者回答这个问题，大部分人和性能/内核工程师。过一段时间这些可能会发生变化，我会持续跟进并补充，大概会一年更新一次。
多数人
多数人 (开发者，系统管理员，开发管理者，运维人员，评测人员，等等) 不关心系统追踪器的细节。下面是对于追踪器你应该知道和做的：
1. 使用perf_events分析CPU性能
使用 perf_events 做 CPU 性能分析。性能指标可以使用flame graph 等工具做可视化。
git clone --depth 1 https://github.com/brendangregg/FlameGraph
perf record -F 99 -a -g -- sleep 30
perf script | ./FlameGraph/stackcollapse-perf.pl | ./FlameGraph/flamegraph.pl > perf.svg
Linux perf_events (又称 "perf"，同命令名) 是 Linux 用户的官方追踪器和性能分析器。内置于内核代码，有很好维护（近来获得快速增强），通常通过 linux 命令行工具包添加。
perf 有很多功能，如果只能推荐一个，我选择 CPU 性能分析。尽管这只是采样，而不是从技术上追踪事件。最难的部分是获取完整的栈和信息，我为 java 和 node.js 做的一个演讲 Linux Profiling at Netflix中已经说过这个问题
2.了解其他的Tracer
正如我一个朋友说的：“你不需要知道如何操作 X 射线机器，但是一旦你吞了一枚硬币，你得知道这得去做 X 射线”，你应该了解各种 tracer 都能做什么，这样就能在你工作中真正需要 tracer 的时候，你既可以选择稍后学习使用，也可以雇相应的人来完成。
简短来说：几乎所有的东西都可以使用 tracer 来进行分析和跟踪。如，文件系统，网络处理器，硬件驱动器，全部的应用程序。可以看一下我的个人网站上关于 ftrace的文章，还有我写的关于perf_events 文档介绍，可以做为一个追踪(或者性能分析)的例子。
3. 寻求前端支持工具
如果你正想买一个能支持跟踪 Linux 的性能分析工具（有许多卖这类工具的公司）。想象一下，只需要直接点击一下界面就能“洞察”整个系统内核，包括隐藏的不同堆栈位置的热图，我在Monitorama talk 中介绍了一个这样带图形界面的工具。
我开源了一些我自己开发的前端工具，尽管只是 CLI （命令行界面）而不是（图形界面）。这些工具也会让人们更加快速容易的使用 tracer。比如下面的例子，用我的 perf_tool，跟踪一个新进程:
# ./execsnoopTracing exec()s. Ctrl-C to end.
PID PPID ARGS
22898 22004 man ls
22905 22898 preconv -e UTF-8
22908 22898 pager -s
22907 22898 nroff -mandoc -rLL=164n -rLT=164n -Tutf8
[...]
在 Netflix 上，我们创建了一个 Vector，一个分析工具的实例同时也是 Linux 上的 tracer 的最终前端。
致性能或内核工程师
我们的工作变的越来越困难，很多的人会问我们怎么样去追踪，哪种路径可以用！为了正确理解一个路径，你经常需要花上至少100个小时才能做到。理解所有的 linux 路径去做出理性的决定是一个浩大的工程。（我可能是唯一一个接近做到这件事情的人）
这里是我的建议，可以二选其一：
A) 选中一个全能的路径，并且使它标准化，这将涉及花费大量的时间去弄清楚它在测试环境中的细微差别和安全性。我现在推荐 SystemTap 的最新版本（ie，从源代码构建）。我知道有些公司已经选用 LTTng，而且他们用的很好，尽管它不是非常的强大（虽然它更安全）。Sysdig 可以成为另一个候选如果它可以增加追踪点或者 kprobes。
B) 遵循我上面提供的流程图，它将意味着尽可能更多的使用 ftrace 或者 perf_event， eBPF 会得到整合，之后其他的路径像 SystemTap/LTTng 会去填补这个空白。这就是我目前在 Netflix 做的工作。
tracer 的评论：
1. ftrace
我喜欢用 ftrace，它是内核 hacker 的首选，内置于系统内核，可以使用跟踪点(静态检查点)，能调用内核 kprobes 和 uprobes 调试工具。并且提供几个这样的功能：带可选过滤器和参数的事件追踪功能；在内核中进行统计的事件计数和定时功能；还有函数流程遍历的功能。可以看一下内核代码中 ftrace.txt 例子了解一下。ftrace 由 /sys 控制，仅支持单一的 root 用户使用（但是你可以通过缓冲区实例破解以支持多用户）。某些时候 Ftrace 的操作界面非常繁琐，但是的确非常“hack”，而且它有前端界面。Steven Rostedt，ftace 的主要作者，创建了 trace-cmd 命令工具，而我创建了 perf 的工具集。我对这个工具最大的不满就是它不可编程。举例来说，你不能保存和获取时间戳，不能计算延迟，不能把这些计算结果保存成直方图的形式。你需要转储事件至用户级别，并且花一些时间去处理结果。ftrace 可以通过 eBPF 变成可编程的。
2.perf_events
perf_events 是 Linux 用户的主要跟踪工具，它内置在内核源码中，通常通过 linux-tools-commom 加入。也称“perf”，同前端工具名称，通常用来跟踪和转储信息到一个叫做 perf.data 的文件中，perf.data 文件相当于一个动态的缓冲区，用来保存之后需要处理的结果。ftrace 能做到的，perf_events 大都也可以做到，perf-events 不能做函数流程遍历，少了一点儿“hack”劲儿（但是对于安全/错误检查有更好的支持）。它可以进行 CPU 分析和性能统计，用户级堆栈解析，也可以使用对于跟踪每行局部变量产生的调试信息。它也支持多用户并发操作。和 ftrace 一样也不支持可编程。如果要我只推荐一款 tracer，那一定是 perf 了。它能解决众多问题，并且它相对较安全。
3. eBPF
extended Berkeley Packet Filter（eBPF）是一个可以在事件上运行程序的高效内核虚拟机（JIT）。它可能最终会提供 ftrace 和 perf_events 的内核编程，并强化其他的 tracer。这是 Alexei Starovoitov 目前正在开发的，还没有完全集成，但是从4.1开始已经对一些优秀的工具有足够的内核支持了，如块设备I/O的延迟热图。可参考其主要作者 Alexei Starovoitov 的BPF slides和eBPF samples。
4. SystemTap
SystemTap 是最强大的tracer。它能做所有事情，如概要分析，跟踪点，探针，uprobes（来自SystemTap），USDT和内核编程等。它将程序编译为内核模块，然后加载，这是一种获取安全的巧妙做法。它也是从tree发展而来，在过去有很多问题（多的可怕）。很多不是 SystemTap 本身的错——它常常是第一个使用内核追踪功能，也是第一个碰到 bug 的。SystemTap 的最新版本好多了（必须由源代码编译），但是很多人仍然会被早期版本吓到。如果你想用它，可先在测试环境中使用，并与irc.freenode.net上 的 #systemtap 开发人员交流。（Netflix 有容错机制，我们已经使用了 SystemTap，但是可能我们考虑的安全方面的问题比你们少。）我最大的不满是，它似乎认为你有常常没有的内核 debug 信息。实际上没有它也能做很多事情，但是缺少文档和例子（我必须自己全靠自己开始学习）。
5. LTTng
LTTng 优化了事件采集，这比其他 tracers 做得好。它从 tree 发展而来，它的核心很简单：通过一组小规模的固定指令集将事件写入追踪缓冲区，这种方式使它安全、快速，缺点是它没有内核编码的简单途径。我一直听说这不是一个大问题，因为尽管需要后期处理，它也已经优化到可以充分的度量。此外，它还首创了一个不同的分析技术，更多对所有关注事件的黑盒记录将稍后以 GUI 的方式进行研究。我关心的是前期没有考虑到要录制的事件缺失问题如何解决，但我真正要做的是花更多时间来看它在实践中用的怎么样。这是我花的时间最少的一个 tracer（没有什么特殊原因）。
6. Ktap
ktap 在过去是一款前景很好的 tracer，它使用内核中的 lua 虚拟机处理，在没有调试信息的情况下在嵌入式设备上运行的很好。它分为几个步骤，并在有一段时间似乎超过了 Linux 上所有的追踪器。然后 eBPF 开始进行内核集成，而 ktap 的集成在它可以使用 eBPF 替代它自己的虚拟机后才开始。因为 eBPF 仍将持续集成几个月，ktap 开发者要继续等上一段时间。我希??今年晚些时候它能重新开发。
7. dtrace4linux
dtrace4linux 主要是 Paul Fox 一个人在业余时间完成的，它是 Sun DTrace 的 Linux 版本。它引入瞩目，还有一些 provider 可以运行，但是从某种程度上来说还不完整，更多的是一种实验性的工具（不安全）。我认为，顾忌到许可问题，人们会小心翼翼的为 dtrace4linux 贡献代码：由于当年 Sun 开源DTrace 使用的是 CDDL 协议，而 dtrace4linux 也不大可能最终进入 Linux kernel。Paul 的方法很可能会使其成为一个 add-on。我很乐意看到 Linux 平台上的 DTrace 和这个项目的完成，我认为当我加入 Netflix 后将会花些时间来协助完成这个项目。然而，我还是要继续使用内置的 tracers，如 ftrace 和 perf_events。
8.OL DTrace
Oracle Linux DTrace为了将 DTrace 引入 Linux，特别是 Oracle Linux，做出了很大的努力。这些年来发布的多个版本表明了它的稳定进展。开发者们以一种对这个项目的前景看好的态度谈论着改进 DTrace 测试套件。很多有用的 provider 已经完成了，如：syscall, profile, sdt, proc, sched 以及 USDT。我很期待 fbt（function boundary tracing, 用于内核动态跟踪）的完成，它是 Linux 内核上非常棒的 provider。OL DTrace 最终的成功将取决于人们对运行 Oracle Linux（为技术支持付费）有多大兴趣，另一方面取决于它是否完全开源：它的内核元件是开源的，而我没有看到它的用户级别代码。
9. sysdig
sysdig是一个使用类tcpmp语法来操作系统事件的新tracer，它使用lua提交进程。它很优秀，它见证了系统跟踪领域的变革。它的局限性在于它只在当前进行系统调用，在提交进行时将所有事件转储为用户级别。你可以使用系统调用做很多事情，然而我还是很希望它能支持跟踪点、kprobe和uprobe。我还期待它能支持eBPF做内核摘要。目前，sysdig开发者正在增加容器支持。留意这些内容。
延伸阅读
我关于 tracer 的工作包括：
ftrace：我的 perf-tools工具集（参考实例目录）；我在 lwn.net 上的 关于ftrace的文章；LISA14的发言；还有帖子：函数计数， iosnoop，opensnoop，execsnoop，TCP转发， uprobes 以及USDT。
perf_evenets：我的网页 perf_events实例；SCALE上的发言Netflix的Linux性能分析；还有帖子CPU采样，静态追踪点，热点图，计数，内核行追踪，off-CPU时间图。
eBPF：帖子eBPF：迈出一小步，和一些BPF工具（我需要发布更多）。
SystemTap：我很久以前写了一篇有点过期的帖子使用SystemTap。最近，我发布了一些工具systemtap-lwtools来演示如何在没有内核诊断信息的情况下使用SystemTap。
LTTng：我只花了一点时间，还不足以发表任何内容。
ktap：我的网页ktap实例包含一些早期版本的单行小程序和脚本。
dtrace4linux：我在系统性能一书中给出了一些实例，并曾经开发了一些小的修复程序，如timestamps。
OL DTrace：由于它直接由DTrace转变而来，很多我早期关于DTrace的工作都有相关性（如果在这里给出链接的话就太多了，可以在我的主页上搜索）。当它更完善时，我会开发一些特殊工具。
sysdig：我向 fileslower 和 subsecond offset spectrogram 贡献了代码。
其他：我写了关于strace 的注意事项。
请不要有更多的 tracer！如果你想知道为什么 Linux 不仅仅只有一个 tracer，或者只用本身的DTrace，你可以在我的演讲稿从DTrace到Linux中找到答案，从28张幻灯片开始。
感谢Deirdré Straughan的编辑，以及与 General Zoi 的小马宝莉创作者一起创作的 tracing 小马。
C. 我的嗅探器程序无法分析数据包的类型
包
0. 前言
来源：《Computer Security》A Hands-on Approach — Wenliang Du
所有的代码/文档见github：https://github.com/da1234cao/computer_security
chapter 12 Packet sniffing and spoffing.
这一章有点硬核。知识点不难，但对socket编程有点要求。
我看过《unix网络编程》第一卷 前五章 ,背景知识还是相当欠缺。这章内容虽然看完，基本明白，但距离实际动手完成一个简单的有线/无线嗅探工具还挺远。本文，暂时仅仅看看书上的嗅探实现。
1. 摘要与总结
首先介绍了网卡的工作原理，嗅探需要网卡的工作模式（杂乱模式/监控模式）。
为了提数凯游早过滤过滤不需要的数据包，介绍了BPF。
接着用三种方式：普通套接字，原生套接字，pcap API，递进的讲述了包的嗅探过程。
2. 包(Packet)的接收
2.1 网卡
参考文章：网卡工作原理详解 、关于网络的混杂模式 、实战无线网络分析（篇一）无线监听
简单了解下：
网卡(Network Interface Card,NIC)是一块被设计用来允许计算机在计算机网络上进行通讯的计算机硬件。每块网卡有一个硬件地址，被称为MAC地址；网卡孙衫接入网络，使得用户可以通过电缆或无线相互连接；用户A要发送信息给B，通过电缆或者无线进行广播；每一块网卡都将广播的内容拷贝到自己的网卡内存中，检查头部信息中的MAC地址，判断是否是发送给自己的。如果是则将其拷贝进入内存，否则丢弃；因为MAC唯一，所以最后只有B接受了用户A的信息。
维基网络：混杂模式(promiscuous mode)。一般计算机网卡都工作在非混杂模式下，此时网卡只接受来自网络端口的目的地址指向自己的数据。当网卡工作在混杂模式下时，网卡将来自接口的所有数据都捕获并交给相应的驱动程序。网卡的混杂模式一般在网络管理员分析网络数据作为网络故障诊断手段时用到，同时这个模式也被网络黑客利用来作为网络数据窃听的入口。在Linux操作系统中设置网卡混杂模式时需要管理员权限。在Windows操作系统和Linux操作系统中都有使用混杂模式的抓包工具，比如着名的开源软件Wireshark。
监控模式(monitor mode)。 类似于有线网络的混杂模式。 无线网卡在监视模式下运行时支持嗅探。 与以太网不同，无线设备面临附近其他设备的干扰。 这将严重阻碍网络连接的性能。 为解决此问题，WIFI设备在不同的信道上传输数据。接入点将附近的设备连接到不同的信道，以减少它们之间的干扰影响。 Wifi网卡还设计为在整个可用带宽和通道的片上进行通信。 将这些卡置于监视模式时，它们将捕获802. 1I帧，这些帧在它们正在侦听的通道上传输。 这意味着，与以太网不同，无线网卡可能会丢失同一网络上的信息，因为它位于不同的信道上。 大多数无线网卡不支持监视器模式或制造商禁用了该模式。
2.2 (BSD Packet Filter)BPF
参考文章：BPF与eBPF
这个参考文章我没懂。目前大概知道怎么回事就好。后面使用pcap API会用到这里的概念。
嗅探网络流量时，嗅探器只对薯销某些类型的数据包感兴趣，例如TCP数据包或DNS查询数据包，这是很常见的。系统可以将所有捕获的数据包提供给嗅探器程序，后者可以丢弃不需要的数据包。这是非常低效的，因为处理这些不需要的数据包并将其从内核传送到嗅探器应用程序需要花费时间。当有很多不需要的数据包时，浪费的时间相当可观。最好尽早过滤这些不需要的数据包。
随着对数据包捕获的需求的增加，Unix操作系统定义了BSD数据包过滤器（BSD Packet Filter,BPF）以支持较低级别的过滤。 BPF允许用户空间程序将过滤器附加到套接字，这实际上是告诉内核尽早丢弃不需要的数据包。过滤器通常使用布尔运算符以人类可读的格式编写，并被编译为伪代码并传递给BPF驱动程序。然后由BPF伪机（一个专门为数据包过滤设计的内核级状态机）解释该低级代码。
3. 包的嗅探
3.1 通常套接字编程接收包
/**
* 作用：将进入服务器所有IP的9090端口的UDP内容，输出。
*
* 准备：
* 一个套接字描述符：scoket函数，指定期望的通信协议类型
* 一个监听套接字：指定协议族，ip，端口
* bind：将一个本地协议地址赋予一个套接字（描述符）
* recvfrom:接受经指定的socket 传来的数据，放入buf --》准备个buffer，一个客户端套接字，套接字长度
*
* 头文件：
* netinet/in.h 定义了ip地址结构 struct sockaddr_in （struct in_addr作为sockaddr_in 的成员)
* 还有函数 htons等，以及一些宏。
* sys/socket.h 定义了一些列的socket API函数 如
* socket()，bind() listen() ， send() ，sendmsg()，setsockopt()，等等。
* unistd.h close函数
*
* 验证：echo "Hello World\!" | nc -4u 127.0.0.1 9090
*/
#include <stdio.h>
#include <string.h>
#include <netinet/in.h>
#include <sys/socket.h>
#include <errno.h>
#include <unistd.h>
int main(void){
int sock;
struct sockaddr_in server;
int client_len;
struct sockaddr_in client;
char buf[1000];
// IPV4,数据包套接字，UDP传输协议
sock = socket(AF_INET,SOCK_DGRAM,IPPROTO_UDP);
if(sock <= 0){
perror("error in socket");
return -1;
}
// 用这个初始化为零，比memset函数少一个参数
// sockaddr_in结构体中sin_zero，还没用；整个结构体用之前，我们全部初始化为零
// IPv4协议族，监听该服务器上所有IP的9090端口
// 按照网络标准转化字节序
bzero(&server,sizeof(server));
server.sin_family = AF_INET;
server.sin_addr.s_addr = htonl(INADDR_ANY);
server.sin_port = htons(9090);
// 将一个本地协议地址赋予一个套接字（描述符）
if( bind(sock,(struct sockaddr *)&server,sizeof(server)) < 0){
perror("error in bind");
return -1;
}
while (1){
bzero(buf,sizeof(buf));
// 进入一个慢系统调用；
recvfrom(sock,buf,sizeof(buf)-1,0,(struct sockaddr *)&client,&client_len);
printf("%s",buf);
}
close(sock);
return 0;
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
3.2 使用原生套接字接收包