-转自https://blog.csdn.net/liang_baikai/article/details/79626180
选出其中我需要的：
使用详解
（1）监视指定主机和端口的数据包
如果想要获取主机210.27.48.1接收或发出的telnet包，使用如下命令
tcpdump tcp port 23 and host 210.27.48.1
（2）截获主机hostname发送的所有数据
tcpdump -i eth0 src host hostname
（3）监视所有送到主机hostname的数据包
tcpdump -i eth0 dst host hostname
（4）监视指定主机的数据包
打印所有进入或离开sundown的数据包.tcpdump host sundown
（5）监视指定协议的数据包
打印TCP会话中的的开始和结束数据包, 并且数据包的源或目的不是本地网络上的主机.(nt: localnet, 实际使用时要真正替换成本地网络的名字))
tcpdump ‘tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and not src and dst net localnet’
打印所有源或目的端口是80, 网络层协议为IPv4, 并且含有数据,而不是SYN,FIN以及ACK-only等不含数据的数据包.(ipv6的版本的表达式可做练习)
tcpdump ‘tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)’
结果分析：
（1）UDP 数据包
UDP 数据包的显示格式，可通过rwho这个具体应用所产生的数据包来说明:
actinide.who > broadcast.who: udp 84
其含义为:actinide主机上的端口who向broadcast主机上的端口who发送了一个udp数据包(nt: actinide和broadcast都是指Internet地址).
这个数据包承载的用户数据为84个字节.
一些UDP服务可从数据包的源或目的端口来识别，也可从所显示的更高层协议信息来识别. 比如, Domain Name service requests(DNS 请求,
（2）CP 数据包
(注意:以下将会假定你对 RFC-793所描述的TCP熟悉. 如果不熟, 以下描述以及tcpdump程序可能对你帮助不大.(nt:警告可忽略,
只需继续看, 不熟悉的地方可回头再看.).
通常tcpdump对tcp数据包的显示格式如下:
src > dst: flags data-seqno ack window urgent options
src 和 dst 是源和目的IP地址以及相应的端口.
flags 标志由S(SYN), F(FIN), P(PUSH, R(RST),W(ECN CWT(nt | rep:未知, 需补充))或者 E(ECN-Echo(nt | rep:未知, 需补充))组成,
单独一个’.’表示没有flags标识.
数据段顺序号(Data-seqno)描述了此包中数据所对应序列号空间中的一个位置(nt:整个数据被分段,每段有一个顺序号,所有的顺序号构成一个序列号空间)
(可参考以下例子). Ack描述的是同一个连接,同一个方向,下一个本端应该接收的(对方应该发送的)数据片段的顺序号.
Window是本端可用的数据接收缓冲区的大小(也是对方发送数据时需根据这个大小来组织数据).
Urg(urgent) 表示数据包中有紧急的数据. options 描述了tcp的一些选项, 这些选项都用尖括号来表示(如 ).
src, dst 和 flags 这三个域总是会被显示.
其他域的显示与否依赖于tcp协议头里的信息.
这是一个从trsg到csam的一个rlogin应用登录的开始阶段.
rtsg.1023 > csam.login: S 768512:768512(0) win 4096 <mss 1024>
csam.login > rtsg.1023: S 947648:947648(0) ack 768513 win 4096 <mss 1024>
rtsg.1023 > csam.login: . ack 1 win 4096
rtsg.1023 > csam.login: P 1:2(1) ack 1 win 4096
csam.login > rtsg.1023: . ack 2 win 4096
rtsg.1023 > csam.login: P 2:21(19) ack 1 win 4096
csam.login > rtsg.1023: P 1:2(1) ack 21 win 4077
csam.login > rtsg.1023: P 2:3(1) ack 21 win 4077 urg 1
csam.login > rtsg.1023: P 3:4(1) ack 21 win 4077 urg 1
第一行表示有一个数据包从rtsg主机的tcp端口1023发送到了csam主机的tcp端口login上
(nt:udp协议的端口和tcp协议的端口是分别的两个空间,虽然取值范围一致).
S表示设置了SYN标志. 包的顺序号是768512, 并且没有包含数据.
(表示格式为:’first:last(nbytes)’,其含义是’此包中数据的顺序号从first开始直到last结束，不包括last.并且总共包含nbytes的用户数据’.) 没有捎带应答(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包的一些选项, 回头再翻)会在此包中,
而真正的IP(数据包的长度又不够容纳这些选项, tcpdump会显示’[bad hdr length]’.
抓取带有特殊标志的的TCP包(如SYN-ACK标志, URG-ACK标志等).
在TCP的头部中, 有8比特(bit)用作控制位区域, 其取值为:
CWR | ECE | URG | ACK | PSH | RST | SYN | FIN
(nt | rt:从表达方式上可推断:这8个位是用或的方式来组合的, 可回头再翻)
现假设我们想要监控建立一个TCP连接整个过程中所产生的数据包. 可回忆如下:TCP使用3次握手协议来建立一个新的连接; 其与此三次握手
连接顺序对应，并带有相应TCP控制标志的数据包如下:
- 连接发起方(nt:Caller)发送SYN标志的数据包
- 接收方(nt:Recipient)用带有SYN和ACK标志的数据包进行回应
- 发起方收到接收方回应后再发送带有ACK标志的数据包进行回应