为何我的tcpdump在linux下运行不了？
tcpdump是通过libpcap来抓取报文的，libpcap在不同平台有不同的实现，下面仅以Linux平台来作说明。首先Linux平台在用户态获取报文的Mac地址等链路层信息并不是什么特殊的事情，通过AF_PACK套接字就可以实现，而tcpdump或libpcap也正是用这种方式抓取报文的(可以strace tcpdump的系统调用来验证)。关于AF_PACK的细节，可查看man 7 packet。其次，上面已经提到tcpdumap使用的是AF_PACK套接字，不是Netfilter。使用Netfilter至少有2点不合理的地方：
1. 数据包进入Netfilter时其实已经在协议栈做过一些处理了，数据包可能已经发生一些改变了。比较明显的一个例子，进入Netfilter前需要重组分片，所以Netfilter中无法抓取到原始的报文分片。而在发送方向，报文离开Netfilter时也未完全结束协议栈的处理，所以抓取到的报文也会有不完整的可能。
2. 在Netfilter抓取的报文，向用户态递送时也会较为复杂。Netfilter的代码处在中断上下文和进程上下文两种运行环境，无法使用传统系统调用，简单的做法就是使用Netlink。而这还不如直接用AF_PACKET抓取报文来得简单（对内核和用户态程序都是如此）。
linuxtcp连接状态有哪些？
TCP连接状态详解 LISTEN： 侦听来自远方的TCP端口的连接请求SYN-SENT： 再发送连接请求后等待匹配的连接请求SYN-RECEIVED：再收到和发送一个连接请求后等待对方对连接请求的确认ESTABLISHED： 代表一个打开的连接FIN-WAIT-1： 等待远程TCP连接中断请求，或先前的连接中断请求的确认FIN-WAIT-2： 从远程TCP等待连接中断请求CLOSE-WAIT： 等待从本地用户发来的连接中断请求CLOSING： 等待远程TCP对连接中断的确认LAST-ACK： 等待原来的发向远程TCP的连接中断请求的确认TIME-WAIT： 等待足够的时间以确保远程TCP接收到连接中断请求的确认CLOSED： 没有任何连接状态