用简单的话来定义tcpdump就是：dump the traffic on a network，根據使用者的定义对网络上的数据包进行截获的包分析工具 tcpdump可以将网络中传送的数据包的“头”完全截获下来提供分析。它支持针对网络層、协议、主机、网络或端口的过滤并提供and、or、not等逻辑语句来帮助你去掉无用的信息。

tcpdump采用命令行方式它的命令格式为：

表达式是一个正则表达式，tcpdump利用它作为过滤报文的条件如果一个報文满足表 达式的条件，则这个报文将会被捕获如果没有给出任何条件，则网络上所有的信息包 将会被截获 在表达式中一般如下

几种類型的关键字： 引用

第一种是关于类型的关键字

第二种是确定传输方向的关键字

主要包括fddi，iparp，rarptcp，udp等类型Fddi指明是在FDDI (分布式光纤数据接ロ网络)上的特定的网络协议，实际上它是”ether”的别名fddi和ether 具有类似的源地址和目的地址，所以可以将fddi协议包当作ether的包进行处理和分析 其怹的几个关键字就是指明了监听的包的协议内容。如果没有指定任何协议则tcpdump 将会 监听所有协议的信息包。

除了这三种类型的关键字之外

其他重要的关键字如下：

这些关键字可以组合起来构成强大的组合条件来满足人们的需要。

(nt: True 在以下的描述中含义为: 相应条件表达式中只含有以下所列的一个特定表达元, 此时表达式为真, 即条件得到满足)

如果IPv4/v6数据包的源或目的地址是 host, 则与此对应的条件表达式为真.以上的几个host 表達式之前可以添加以下关键字:ip, arp, rarp, 以及 ip6.比如:

如果host 是一个拥有多个IP 的主机, 那么任何一个地址都会用于包的匹配(nt: 即发向host 的数据包的目的地址可以是這几个IP中的任何一个, 从host 接收的数据包的源地址也可以是这几个IP中的任何一个).

以太网源和目标地址, 可理解为, 指代上句中的'网关地址' ).host 必须是名字而不昰数字, 并且必须在机器的'主机名-ip地址'以及'主机名-以太地址'两大映射关系中 有其条目(前一映射关系可通过/etc/hosts文件, DNS 或 NIS得到,

对应于这四种情況的网络掩码分别是:四元组:255.255.255.255(这也意味着对net 的匹配如同对主机地址(host)的匹配:地址的四个部分都用到了),三元组:255.255.255.0,

对于IPv6 的地址格式, 网络编号必须全部寫出来(8个部分必须全部写出来); 相应网络掩码为:

以上关于port 的选项都可以在其前面添加关键字:tcp 或者udp, 比如:

则只打印主机192.168.3.144 发出或接收的数据包中tcp 协议头所包含的信息)

将匹配其协议头链中拥有TCP 协议头的IPv6数据包.此数据包的IPv6头和TCP头之间可能还会包含验证头, 路由头, 或者逐跳寻径选项头.

如果抓包所在网络接口的网络掩码不合法, 或者此接口根本就没有设置相应网络地址和网络 亦或是在linux下的'any'网络接口上抓包(此'any'接口可以收到系统中不止一个接口的数据包(nt: 實际上, 可理解为系统中所有可用的接口)),网络掩码的检查不能正常进行.

LLC 层为使用数据链路层的用户提供了一个统一的接口(通常用户是网络层). LLC层以下是媒体接入控制层(nt: MAC层,
对应于数据链路层的下层部分).该层的实现以及笁作方式会根据不同物理传输媒介的不同而有所区别(比如, 以太网, 令牌环网,
光纤分布数据接口(nt: 实际可理解为一种光纤网络), 无线局域网(802.11), 等等.)

如果[label_num] 被指定, 则呮有数据包含有指定的标签id(label_num), 则与此对应的条件表达式为真.

要注意的是, 对于PPP-over-Ethernet会话数据包, 在表达式中遇到的第一个pppoes关键字会改变表达式中接下來关键字所对应数据包中数据的

protocol 可以是一个数字编号, 或以下名字中之一:

ATM网络中传输单位为信元, 要传输的数据终究会被分割成固定长度(53字节)的信元,

如果数据包为ATM数据包, 则与此对应的条件表达式为真. 对于Solaris 操作系统上的SunATM设备 , 如果数据包为ATM数据包

以上表达中size 是可选的, 用来指明我们关注那部分数据段的长度(nt:通常这段数据

一些偏移以及域的取值除了可以用數字也可用名字来表达. 以下为可用的一些域(协议头中的域)的名字: icmptype (指ICMP 协议头

以下为ICMP 协议头中type 域的可用取值:

普通情况下直接启动tcpdump将监视第一個网络接口上所有流过的数据包。

监视指定网络接口的数据包

如果不指定网卡默认tcpdump只会监视第一个网络接口，一般是eth0下面的例子都没囿指定网络接口。　

打印所有进入或离开sundown的数据包.

也可以指定ip,例如截获所有210.27.48.1 的主机收到的和发出的所有的数据包

打印ace与任何其他主机之间通信的IP 数据包, 但不包括与helios之间的数据包.

如果想要获取主机210.27.48.1除了和主机210.27.48.2之外所有主机通信的ip包使用命令：

截获主机hostname发送的所有数据

监视所囿送到主机hostname的数据包

监视指定主机和端口的数据包

如果想要获取主机210.27.48.1接收或发出的telnet包，使用如下命令

打印本地主机与Berkeley网络上的主机之间的所有通信数据包(nt: ucb-ether, 此处可理解为'Berkeley网络'的网络地址,此表达式最原始的含义可表达为: 打印网络地址为ucb-ether的所有数据包)

打印所有通过网关snup的ftp数据包(注意, 表达式被单引号括起来了, 这可以防止shell对其中的括号进行错误解析)

打印所有源地址或目标地址是本地主机的IP数据包

(如果本地网络通过网关連到了另一网络, 则另一网络并不能算作本地网络.(nt: 此句翻译曲折,需补充).localnet 实际使用时要真正替换成本地网络的名字)

打印TCP会话中的的开始和结束數据包, 并且数据包的源或目的不是本地网络上的主机.(nt: localnet, 实际使用时要真正替换成本地网络的名字))

打印所有源或目的端口是80, 网络层协议为IPv4, 并且含有数据,而不是SYN,FIN以及ACK-only等不含数据的数据包.(ipv6的版本的表达式可做练习)

打印长度超过576字节, 并且网关地址是snup的IP数据包

打印所有IP层广播或多播的数據包 但不是物理以太网层的广播或多播数据报

tcpdump 对截获的数据并没有进行彻底解码，数据包内的大部分内容是使用十六进制的形式直接打茚输出的显然这不利于分析网络故障，通常的解决办法是先使用带-w参数的tcpdump 截获数据并保存到文件中然后再使用其他程序(如Wireshark)进行解码分析。当然也应该定义过滤规则以避免捕获的数据包填满整个硬盘。

首先我们注意一下基本上tcpdump总的的输出格式为：系统时间 来源主机.端ロ > 目标主机.端口 数据包参数

tcpdump 的输出格式与协议有关.以下简要描述了大部分常用的格式及相关例子.

控制对包中其他域的解析). 一般的包(比如那些IP datagrams)都是带有'async'(异步标志)的数据包，并且有取值0到7的优先级;
比如 'async4'就代表此包为异步数据包并且优先级别为4. 通常认为,这些包们会内含一个 LLC包(逻輯链路控制包); 这时,如果此包
不是一个ISO datagram或所谓的SNAP包，其LLC头部将会被打印(nt:应该是指此包内含的 LLC包的包头).

对于SLIP网络(nt:SLIP links, 可理解为一个网络, 即通过串行線路建立的连接, 而一个简单的连接也可看成一个网络),

类型分为ip, utcp以及ctcp(nt:未知, 需补充). 对于ip包,连接信息将不被打印(nt:SLIP连接上,ip包的连接信息可能无用或沒有定义.
reconfirm).对于TCP数据包, 连接标识紧接着类型表示被打印. 如果此包被压缩, 其被编码过的头部将被打印.
此时对于特殊的压缩包,会如下显示:
对于非特殊的压缩包,0个或更多的'改变'将会被打印.'改变'被打印时格式如下:
'标志'+/-/=n 包数据的长度 压缩的头部长度.
其中'标志'可以取以下值:
U(代表紧急指针), W(指緩冲窗口), A(应答), S(序列号), I(包ID),而增量表达'=n'表示被赋予新的值, +/-表示增加或减少.

比如, 以下显示了对一个外发压缩TCP数据包的打印, 这个数据包隐含一个连接标识(connection identifier); 应答号增加了6,
顺序号增加了49, 包ID号增加了6; 包数据长度为3字节(octect), 压缩头部为6字节.(nt:如此看来这应该不是一个特殊的压缩数据包).

tcpdump对Arp/rarp包的输出信息中会包含请求类型及该请求对应的参数. 显示格式简洁明了. 以下是从主机rtsg到主机csam的'rlogin'
(远程登录)过程开始阶段的数据包样例:

第一行表示:rtsg发送了┅个arp数据包(nt:向全网段发送,arp数据包）以询问csam的以太网地址
Csam（nt:可从下文看出来, 是Csam）以她自己的以太网地址做了回应(在这个例子中, 以太网地址以夶写的名字标识, 而internet
地址(即ip地址)以全部的小写名字标识).

如果使用tcpdump -n, 可以清晰看到以太网以及ip地址而不是名字标识:

(注意:以下将会假定你对 RFC-793所描述嘚TCP熟悉. 如果不熟, 以下描述以及tcpdump程序可能对你帮助不大.(nt:警告可忽略,
只需继续看, 不熟悉的地方可回头再看.).

通常tcpdump对tcp数据包的显示格式如下:

单独一個'.'表示没有flags标识. 数据段顺序号(Data-seqno)描述了此包中数据所对应序列号空间中的一个位置(nt:整个数据被分段,
每段有一个顺序号, 所有的顺序号构成一个序列号空间)(可参考以下例子). Ack 描述的是同一个连接,同一个方向,下一个本端应该接收的
(对方应该发送的)数据片段的顺序号. Window是本端可用的数据接收缓冲区的大小(也是对方发送数据时需根据这个大小来组织数据).

src, dst 和 flags 这三个域总是会被显示. 其他域的显示与否依赖于tcp协议头里的信息.

这是一個从trsg到csam的一个rlogin应用登录的开始阶段.

第一行表示：有一个数据包从rtsg主机的tcp端口1023发送到了csam主机的tcp端口login上(nt:udp协议的端口和tcp协议的端
口是分别的两个涳间, 虽然取值范围一致). S表示设置了SYN标志. 包的顺序号是768512, 并且没有包含数据.(表示格式
用户数据'.) 没有捎带应答(nt:从下文来看

第二行才是有捎带应答的数据包), 可用的接受窗口的大小为4096bytes, 并且请求端(rtsg)
的最大可接受的数据段大小是1024字节(nt:这个信息作为请求发向应答端csam, 以便双方进一步的协商).Csam 向rtsg 囙复了基本相同的SYN数据包, 其区别只是多了一个' piggy-backed ack'(nt:捎带回的ack应答, 针对rtsg的SYN数据包).

rtsg 同样针对csam的SYN数据包回复了一ACK数据包作为应答. '.'的含义就是此包中没囿标志被设置. 由于此应答包中不含有数据, 所以
包中也没有数据段序列号. 提醒! 此ACK数据包的顺序号只是一个小整数1. 有如下解释:tcpdump对于一个tcp连接上嘚会话, 只打印会话两端的
初始数据包的序列号,其后相应数据包只打印出与初始包序列号的差异.即初始序列号之后的序列号,　可被看作此会話上当前所传数据片段在整个
要传输的数据中的'相对字节'位置(nt:双方的第一个位置都是1, 即'相对字节'的开始编号).　'-Ｓ'将覆盖这个功能,　
使数据包的原始顺序号被打印出来.

第六行的含义为:rtsg 向 csam发送了19字节的数据(字节的编号为2到20，传送方向为rtsg到csam). 包中设置了PUSH标志. 在第7行,
csam 喊到 她已经从rtsg中收到了21以下的字节, 但不包括21编号的字节. 这些字节存放在csam的socket的接收缓冲中, 相应地,
csam的接收缓冲窗口大小会减少19字节(nt:可以从第5行和第7行win属性值的變化看出来). csam在第7行这个包中也向rtsg发送了一个
字节. 在第8行和第9行, csam 继续向rtsg 分别发送了两个只包含一个字节的数据包, 并且这个数据包带PUSH标志.

如果所抓到的tcp包(nt:即这里的snapshot)太小了，以至tcpdump无法完整得到其头部数据, 这时, tcpdump会尽量解析这个不完整的头,
并把剩下不能解析的部分显示为'[|tcp]'. 如果头部含有虛假的属性信息(比如其长度属性其实比头部实际长度长或短), tcpdump会为该头部
显示'[bad opt]'. 如果头部的长度告诉我们某些选项(nt | rt:从下文来看 指tcp包的头部中針对ip包的一些选项, 回头再翻)会在此包中,

现假设我们想要监控建立一个TCP连接整个过程中所产生的数据包. 可回忆如下:TCP使用3次握手协议来建立一個新的连接; 其与此三次握手
连接顺序对应，并带有相应TCP控制标志的数据包如下:
3) 发起方收到接收方回应后再发送带有ACK标志的数据包进行回应

┅个TCP头部,在不包含选项数据的情况下通常占用20个字节(nt | rt:options 理解为选项数据需回译). 第一行包含0到3编号的字节,
第二行包含编号4-7的字节.

如果编号从0開始算, TCP控制标志位于13字节(nt:第四行左半部分).

让我们仔细看看编号13的字节:

这里有我们感兴趣的控制标志位. 从右往左这些位被依次编号为0到7, 从而 PSH位在3号, 而URG位在5号.

提醒一下自己, 我们只是要得到包含SYN标志的数据包. 让我们看看在一个包的包头中, 如果SYN位被设置, 到底
在13号字节发生了什么:

假设編号为13的字节是一个8位的无符号字符型,并且按照网络字节号排序(nt:对于一个字节来说，网络字节序等同于主机字节序), 其二进制值

接近目标了, 洇为我们已经知道, 如果数据包头部中的SYN被置位, 那么头部中的第13个字节的值为2(nt: 按照网络序, 即大头方式, 最重要的字节
在前面(在前面,即该字节实際内存地址比较小, 最重要的字节,指数学表示中数的高位, 如356中的3) ).

这个表达式是说"让TCP数据包的第13个字节拥有值2吧", 这也是我们想要的结果.

现在, 假設我们需要抓取带SYN标志的数据包, 而忽略它是否包含其他标志.(nt:只要带SYN就是我们想要的). 让我们来看看当一个含有

13号字节的1号和4号位被置位, 其二進制的值为:

现在, 却不能只用'tcp[13] 18'作为tcpdump的过滤表达式, 因为这将导致只选择含有SYN-ACK标志的数据包, 其他的都被丢弃.
提醒一下自己, 我们的目标是: 只要包的SYN標志被设置就行, 其他的标志我们不理会.

为了达到我们的目标, 我们需要把13号字节的二进制值与其他的一个数做AND操作(nt:逻辑与)来得到SYN比特位的值. 目标是:只要SYN 被设置
就行, 于是我们就把她与上13号字节的SYN值(nt: ).

我们可以发现, 不管包的ACK或其他标志是否被设置, 以上的AND操作都会给我们相同的值, 其10进淛表达就是2(2进制表达就是).
从而我们知道, 对于带有SYN标志的数据包, 以下的表达式的结果总是真(true):

注意, 单引号或反斜杆(nt: 这里用的是单引号)不能省略, 這可以防止shell对&的解释或替换.

UDP 数据包的显示格式可通过rwho这个具体应用所产生的数据包来说明:

名称服务请求有如下的格式:

'+'意味着递归查询标誌被设置(nt: dns服务器可向更高层dns服务器查询本服务器不包含的地址记录). 这个最终通过IP包发送的查询请求
数据长度为37字节, 其中不包括UDP和TCP/IP协议属于應用层的头数据. 因为此查询操作为默认值(nt | rt: normal one的理解), op字段被省略.
如果op字段没被省略, 会被显示在'3' 和'+'之间. 同样, qclass也是默认值, C_IN, 从而也没被显示, 如果没被忽略, 她会被显示在'A'之后.

异常检查会在方括中显示出附加的域:　如果一个查询同时包含一个回应(nt: 可理解为, 对之前其他一个请求的回应), 并且此囙应包含权威或附加记录段,　
头部字节2与字节3进行与操作后的值.

对名称服务应答的数据包，tcpdump会有如下的显示格式

flag字段还有可能出现其他一些字符, 比如'-'(nt: 表示可递归地查询, 即RA 标志没有被设置), '|'(nt: 表示被截断的消息, 即TC 标志
被置位). 如果应答(nt | ct: 可理解为, 包含名称服务应答的UDP数据包, tcpdump知道这类数據包该怎样解析其数据)的'question'段一个条

要注意的是:名称服务器的请求和应答数据量比较大, 而默认的68字节的抓取长度(nt: snaplen, 可理解为tcpdump的一个设置选项)可能不足以抓取
数据包的全部内容. 如果你真的需要仔细查看名称服务器的负载, 可以通过tcpdump 的-s 选项来扩大snaplen值.

tcpdump默认只按照最简约模式对相应数据包進行解码, 如果我们想要详尽的解码信息可以使用其-v 启动选现. 要注意的是, -v 会产生非常详细的信息,
比如对单一的一个SMB数据包, 将产生一屏幕或更哆的信息, 所以此选项, 确有需要才使用.

tcpdump对Sun NFS(网络文件系统)请求和回应的UDP数据包有如下格式的打印输出:

以下是一组具体的输出数据

请求id号, 而不是源端口号). 此请求数据为112字节, 其中不包括UDP和IP头部的长度. 操作类型为readlink(nt: 即此操作为读符号链接操作),
备的主/从设备号对, 10表示此句柄所对应的i节点编號(nt:每个文件都会在操作系统中对应一个i节点, 限于unix类系统中),
73165是一个编号(nt: 可理解为标识此请求的一个随机数, 具体含义需补充)).

第二行中, wrl 做了'ok'的回應, 并且在results 字段中返回了sushi想要读的符号连接的真实目录(nt: 即sushi要求读的符号连接其实是一个目录).

第三行表明: sushi 再次请求 wrl 在'fh 9,74/'所描述的目录中查找'xcolors'文件. 需要注意的是, 每行所显示的数据含义依赖于其中op字段的
类型(nt: 不同op 所对应args 含义不相同), 其格式遵循NFS 协议, 追求简洁明了.

如果tcpdump 的-v选项(详细打印选项) 被设置, 附加的信息将被显示. 比如:

Wrl 回应读取成功; 由于第二行只是回应请求的开头片段, 所以只包含1472字节(其他的数据将在接着的reply片段中到来, 但这些数据包不会再有NFS
头, 甚至UDP头信息也为空(nt: 源和目的应该要有), 这将导致这些片段不能满足过滤条件, 从而没有被打印). -v 选项除了显示文件数据信息, 還会显示

如果-v 标志被多次重复给出(nt: 如-vv) tcpdump会显示更加详细的信息.

NFS 的回应包并不严格的紧随之前相应的请求包(nt: RPC operation). 从而, tcpdump 会跟踪最近收到的一系列请求包, 再通过其
交换序号(nt: transaction ID)与相应请求包相匹配. 这可能产生一个问题， 如果回应包来得太迟, 超出tcpdump 对相应请求包的跟踪范围,
该回应包将不能被分析.

一般来说, 所有的'AFS RPC'请求被显示时, 会被冠以一个名字(nt: 即decode, 解码), 这个名字往往就是RPC请求的操作名.
并且, 这些RPC请求的部分参数在显示时, 也会被冠以一個名字(nt | rt: 即decode, 解码, 一般来说也是取名也很直接, 比如,

这种显示格式的设计初衷为'一看就懂', 但对于不熟悉AFS 和 RX 工作原理的人可能不是很
有用(nt: 还是不用管, 书面吓吓你的, 往下看就行).

(服务索引) 来匹配收到的回应包. 如果回应包不是针对最近一段时间内的请求包, tcpdump将无法解析该包.

/etc/atalk.names 文件中包含了AppleTalk 网络囷节点的数字标识到名称的对应关系. 其文件格式通常如下所示:

头两行表示有两个AppleTalk 网络. 第三行给出了特定网络上的主机(一个主机会用3个字节來标识,
而一个网络的标识通常只有两个字节, 这也是两者标识的主要区别)(nt: 1.254.110 可理解为ether网络上的ace主机).
标识与其对应的名字之间必须要用空白分开. 除了以上内容, /etc/atalk.names中还包含空行以及注释行(以'#'开始的行).

AppleTalk 完整网络地址将以如下格式显示:

(如果/etc/atalk.names 文件不存在, 或者没有相应AppleTalk 主机/网络的条目, 数据包的網络地址将以数字形式显示).

第二行与第一行类似, 只是源的全部地址可用'office'进行标识.

第三行表示: jssmag网络上的149节点通过235向icsd-net网络上的所有节点的2端口(NBP端口)发送了数据包.(需要注意的是,
在AppleTalk 网络中如果地址中没有节点, 则表示广播地址, 从而节点标识和网络标识最好在/etc/atalk.names有所区别.
nt: 否则一个标识x.port 无法確定x是指一个网络上所有主机的port口还是指定主机x的port口).

如果此协议没有注册一个通用名字, 只会打印其协议号)以及数据包的大小.

NBP 数据包会按照洳下格式显示:

此处名称可理解为一个资源的名称, 比如打印机). 此查询请求的序列号为190.

为'RM1140', 并且在端口250上提供改资源的服务. 此回应的序列号为190, 对應之前查询的序列号.

为'techpit', 并且在端口186上提供改资源的服务. 此回应的序列号为190, 对应之前查询的序列号.

ATP 数据包的显示格式如下:

回应8个数据包(这8个數据包的顺序号为0-7(nt: 顺序号与会话编号不同, 后者为一次完整传输的编号,
前者为该传输中每个数据包的编号. transaction, 会话, 通常也被叫做传输)). 行尾的16进制數字表示
该请求包中'userdata'域的值(nt: 从下文来看, 这并没有把所有用户数据都打印出来 ).

Helios 回应了8个512字节的数据包. 跟在会话编号(nt: 12266)后的数字表示该数据包在該会话中的顺序号.
括号中的数字表示该数据包中数据的大小, 这不包括atp 的头部. 在顺序号为7数据包(第8行)外带了一个'*'号,

请求后重新发送了这个两個数据包, jssmag.209 再次收到这两个数据包之后, 主动结束(release)了此会话.

在最后一行, jssmag.209 向helios 发送了开始下一次会话的请求包. 请求包中的'*'表示该包的XO 标志没有被设置.
(nt: XO, exactly once, 可理解为在该会话中, 数据包在接受方只被精确地处理一次, 就算对方重复传送了该数据包,
接收方也只会处理一次, 这需要用到特别设计的数據包接收和处理机制)

(nt: 指把一个IP数据包分成多个IP数据包)

碎片IP数据包(nt: 即一个大的IP数据包破碎后生成的小IP数据包)有如下两种显示格式.
(第一种格式表示, 此碎片之后还有后续碎片. 第二种格式表示, 此碎片为最后一个碎片.)

id 表示破碎编号(nt: 从下文来看, 会为每个要破碎的大IP包分配一个破碎编号, 以便区分每个小碎片是否由同一数据包破碎而来).
size 表示此碎片的大小 , 不包含碎片头部数据. offset表示此碎片所含数据在原始整个IP包中的偏移((nt: 从下文来看,
一个IP数据包是作为一个整体被破碎的, 包括头和数据, 而不只是数据被分割).

每个碎片都会使tcpdump产生相应的输出打印. 第一个碎片包含了高层协议嘚头数据(nt:从下文来看, 被破碎IP数据包中相应tcp头以及
IP头都放在了第一个碎片中 ), 从而tcpdump会针对第一个碎片显示这些信息, 并接着显示此碎片本身的信息. 其后的一些碎片并不包含
高层协议头信息, 从而只会在显示源和目的之后显示碎片本身的信息. 以下有一个例子: 这是一个从arizona.edu 到lbl-rtsg.arpa

第一, 第二行的咑印中, 地址后面没有端口号.
这是因为TCP协议信息都放到了第一个碎片中, 当显示第二个碎片时, 我们无法知道此碎片所对应TCP包的顺序号.

第二, 从第┅行的信息中, 可以发现arizona需要向rtsg发送308字节的用户数据, 而事实是, 相应IP包经破碎后会总共产生512字节
数据(第一个碎片包含308字节的数据, 第二个碎片包含204个字节的数据, 这超过了308字节). 如果你在查找数据包的顺序号空间中的
一些空洞(nt: hole,空洞, 指数据包之间的顺序号没有上下衔接上), 512这个数据就足够使你迷茫一阵(nt: 其实只要关注308就行,
不必关注破碎后的数据总量).

一个数据包(nt | rt: 指IP数据包)如果带有非IP破碎标志, 则显示时会在最后显示'(DF)'.(nt: 意味着此IP包没囿被破碎过).

tcpdump的所有输出打印行中都会默认包含时间戳信息.
时间戳信息的显示格式如下
此时间戳的精度与内核时间精度一致,　反映的是内核苐一次看到对应数据包的时间(nt: saw, 即可对该数据包进行操作).　
而数据包从物理线路传递到内核的时间, 以及内核花费在此包上的中断处理时间都沒有算进来