tcpdump常用命令及wireshark异常分析
首选介绍一下tcpdump的常用参数 tcpdump采用命令行方式,它的命令格式为: tcpdump [ -adeflnNOpqStvx ] [ -c 数量 ] [ -F 文件名 ] [ -i 网络接口 ] [ -r 文件名] [ -s snaplen ] [ -T 类型 ] [ -w 文件名 ] [表达式 ] 1. tcpdump的选项介绍 -a 将网络地址和广播地址转变成名字; -d 将匹配信息包的代码以人们能够理解的汇编格式给出; -dd 将匹配信息包的代码以c语言程序段的格式给出; -ddd 将匹配信息包的代码以十进制的形式给出; -e 在输出行打印出数据链路层的头部信息; -f 将外部的Internet地址以数字的形式打印出来; -l 使标准输出变为缓冲行形式; -n 不把网络地址转换成名字; -t 在输出的每一行不打印时间戳; -v 输出一个稍微详细的信息,例如在ip包中可以包括ttl和服务类型的信息; -vv 输出详细的报文信息; -c 在收到指定的包的数目后,tcpdump就会停止; -F 从指定的文件中读取表达式,忽略其它的表达式; -i 指定监听的网络接口; -r 从指定的文件中读取包(这些包一般通过-w选项产生); -w 直接将包写入文件中,并不分析和打印出来; -T 将监听到的包直接解释为指定的类型的报文,常见的类型有rpc(远程过程 调用)和snmp(简单网络管理协议;) 当网络出现故障时,由于直接用tcpdump抓包分析有点困难,而且当网络中数据比较多时更不容易分析,使用tcpdump的-w参数+ethereal分析会很好的解决这个问题,具体参数如下: tcpdump -i eth1 -c 2000 -w eth1.cap -i eth1 只抓eth1口的数据 -c 2000代表数据包的个数,也就是只抓2000个数据包 -w eth1.cap 保存成cap文件,方便用ethereal分析 抓完数据包后ftp到你的FTP服务器,put一下,然后用ethereal软件打开就可以很直观的分析了 注:有时将.cap文件上传到FTP服务器后,发现用ethreal打开时提示数据包大于65535个,这是你在ftp上传或者下载的时候没有用bin的模式上传的原因。 另:有的网站提示在tcpdump中用-s 0命令,例如 tcpdump -i eth1 -c 2000 -s0 -w eth1.cap,可实际运行该命令时系统却提示无效的参数,去掉-s 0参数即可 例子: [root@localhost cdr]#tcpdump -i eth0 -t tcp -s 60000 -w diaoxian.cap [root@localhost cdr]# tcpdump host 58.240.72.195 -s 60000 -w x.cap
wireshark异常数据,wireshark异常数据
[TCP Spurious Retransmission]
- TCP虚假重传
发送端认为发送的package已经丢失了,所以重传了,尽管此时接收端已经发送了对这些包的确认。
指实际上并没有超时,但看起来超时了,导致虚假超时重传的原因有很多种:
(1)对于部分移动网络,当网络发生切换时会导致网络延时突增
(2)当网络的可用带宽突然变小时,网络rtt会出现突增的情况,这会导致虚假超时重传
(3)网络丢包(原始和重传的包都有可能丢包)会导致虚假重传超时。
[Reassembly error, protocol TCP: New fragment overlaps old data (retransmission?)]
-重新组装错误,协议TCP:新片段与旧数据重叠(重新传输?)
[TCP Retransmission]
- 超时引发的数据重传。
我的另一篇文章《tcp retransmission原因解析》
[TCP Dup ACK xxx#y]
- 重复应答seq=xxx的表示报文到哪个序号丢失,y表示第几次丢失。
当package发生乱序或者丢失时,接收端会收到一些seq比期望值更大的package。
每收到一次这种package就ack一次期望值,用以提醒发送方。
[TCP Out-Of-Order]
- 次序颠倒
出现这个信息的原因就是因为数据在传输过程中顺序乱了,也就是后一个package的seq会小于前一个package的seq+len。
[TCP Fast Retransmission]
- 快速重传
当发送发接收到3个或以上的[TCP Dup ACK],就意识到之前发的包可能丢了,于是快速重传package。
[TCP Previous segment not captured]
- 未捕获TCP先前的段,意思就是出现报文的丢失,报文没有捕捉到。
tcp连接建立后,针对同一台主机的发包情况进行叙述。正常情况下,后一个package的seq等于前一个package的seq+len。而在实际传输过程中经常会产生数据丢失的问题,这种情况下,后一个Package的seq会大于前一个package的seq+len,实际的网络包的显示效果就是”TCP Previous segment not captured”。
重点:later package’s seq > previous package’s seq + data len
[TCP segment of a reassembled PDU]
在用Wireshark抓包的时候,经常会看到TCP segment of a reassembled PDU,字面意思是要重组的协议数据单元(PDU:Protocol Data Unit)的TCP段。比如由多个数据包组成的HTTP协议的应答包,如下
这里的分段是指:上层协议HTTP的应答由多个分段组成,每个分段都是TCP协议的。TCP本身没有分段的概念,它的sequence number和acknowledge number 是使TCP是基于流的协议的支撑,TCP segment of a reassembled PDU的出现是因为Wireshark分析了其上层的HTTP协议而给出的摘要,如果配置Wireshark不支持HTTP协议解析
那么,同样的数据包就会变成下面的样子
每个TCP数据包都是这条流中的自身完整的一部分,TCP segment应该表述为分段是TCP协议,而不应该是TCP分段。
https://www.cnblogs.com/yinghao1991/p/7532889.html
[TCP Keep-Alive]
- 保持连接特性 socket 发起方发包
[TCP Keep-Alive ACK]
- 保持连接特性 socket 应答方发包
微信
支付宝