netstat实现原理

由于最近接手的项目是基于嵌入式Linux openwrt的，一开始觉得会跟以前的服务器开发没什么大的区别，可是遇到问题去分析的时候才发现，工具链仍是有些差异的，openwrt的netstat是属于一个叫作busybox的工具集的，这个工具集是专门提供给嵌入式Linux，它的参数很简单，竟然没有Linux下netstat的-p选项，所以当我想查看是哪些进程在监听哪些端口时，发现只能查看有哪些监听端口，没法得知是属于哪一个进程的，lsof也没有-i选项。

可是有时候排查问题又必须知道哪一个进程监听了某个端口，所以就想搞清楚Linux下的netstat是怎么实现能够查看监听端口属于哪一个进程呢。

首先想法就是去下载busybox的源代码，可是感受代码太多了，费时费力，因而灵机一动想到Linux下的另外一个工具strace（追踪程序调用的系统调用），经过strace来查看netstat执行时都作了什么操做。

截取了strace输出的某一段，能够看到，调用open以及readlink遍历了/proc/3055/fd/目录下的全部文件，你们都知道这个目录是进程打开文件的目录。

在strace输出的最后，能够看到调用了open打开/proc/net/udp文件，并读取里面的内容将其解析输出，这里面就记录了全部udp链接的信息，同时/proc/net/tcp对应tcp链接、/proc/net/unix对应Unix socket链接。

根据这个文件的标头能够知道，第二列是local address，可是因为是16进制编码，因此须要咱们手动转换成10进制。

这里其实能够发现，/proc/net/udp这个文件中的信息是不包含进程信息的，因此这也是为何netstat在开始的时候会先遍历全部/proc/xx/fd目录，由于netstat能够经过inode将/proc/net/udp中的行和/proc/xx/fd中的文件关联起来，这样就能够获得某一行udp链接的进程信息（由于inode是惟一的）。

因此，分析到这里，我猜想busybox中的netstat应该是没有遍历全部/proc/xx/fd这一步，仅仅是读取了/proc/net/udp文件并解析输出。

明白了netstat的原理，那么即便遇到不提供netstat -p选项的嵌入式Linux，咱们也能手动分析出本身想要的信息，进而解决问题。