wireshark时序图怎么打开

Posted 2023-04-20

Wireshark 可以用时序图的方式显示数据包交互的过程，从菜单栏中，点击 统计 (Statistics) -> 流量图 (Flow Graph)，然后，在弹出的界面中的「流量类型」选择 「TCP Flows」，你可以更清晰的看到，整个过程中 TCP 流的执行过程：

TCP 流量图

你可能会好奇，为什么三次握手连接过程的 Seq 是 0 ？
实际上是因为 Wireshark 工具帮我们做了优化，它默认显示的是序列号 seq 是相对值，而不是真实值。

如果你想看到实际的序列号的值，可以右键菜单， 然后找到「协议首选项」，接着找到「Relative Seq」后，把它给取消，操作如下：

取消序列号相对值显示

取消后，Seq 显示的就是真实值了：

TCP 流量图

可见，客户端和服务端的序列号实际上是不同的，序列号是一个随机值。

这其实跟我们书上看到的 TCP 三次握手和四次挥手很类似，作为对比，你通常看到的 TCP 三次握手和四次挥手的流程，基本是这样的：

TCP 三次握手和四次挥手的流程

为什么抓到的 TCP 挥手是三次，而不是书上说的四次？
因为服务器端收到客户端的 FIN 后，服务器端同时也要关闭连接，这样就可以把 ACK 和 FIN 合并到一起发送，节省了一个包，变成了“三次挥手”。

而通常情况下，服务器端收到客户端的 FIN 后，很可能还没发送完数据，所以就会先回复客户端一个 ACK 包，稍等一会儿，完成所有数据包的发送后，才会发送 FIN 包，这也就是四次挥手了。

如下图，就是四次挥手的过程：

四次挥手

2. TCP三次握手异常

TCP 三次握手的过程相信大家都背的滚瓜烂熟，那么你有没有想过这三个异常情况：

TCP 第一次握手的 SYN 丢包了，会发生了什么？
TCP 第二次握手的 SYN、ACK 丢包了，会发生什么？
TCP 第三次握手的 ACK 包丢了，会发生什么？
有的小伙伴可能说：“很简单呀，包丢了就会重传嘛。”

那我在继续问你：

那会重传几次？
超时重传的时间 RTO 会如何变化？
在 Linux 下如何设置重传次数？
…
是不是哑口无言，无法回答？

不知道没关系，接下里我用三个实验案例，带大家一起探究探究这三种异常。

实验场景

本次实验用了两台虚拟机，一台作为服务端，一台作为客户端，它们的关系如下：

实验环境

客户端和服务端都是 CentOs 6.5 Linux，Linux 内核版本 2.6.32
服务端 192.168.12.36，apache web 服务
客户端 192.168.12.37
实验一：TCP 第一次握手 SYN 丢包

为了模拟 TCP 第一次握手 SYN 丢包的情况，我是在拔掉服务器的网线后，立刻在客户端执行 curl 命令：

其间 tcpdump 抓包的命令如下：

过了一会， curl 返回了超时连接的错误：

从 date 返回的时间，可以发现在超时接近 1 分钟的时间后，curl 返回了错误。

接着，把 tcp_sys_timeout.pcap 文件用 Wireshark 打开分析，显示如下图：

SYN 超时重传五次

从上图可以发现， 客户端发起了 SYN 包后，一直没有收到服务端的 ACK ，所以一直超时重传了 5 次，并且每次 RTO 超时时间是不同的：

第一次是在 1 秒超时重传
第二次是在 3 秒超时重传
第三次是在 7 秒超时重传
第四次是在 15 秒超时重传
第五次是在 31 秒超时重传
可以发现，每次超时时间 RTO 是指数（翻倍）上涨的，当超过最大重传次数后，客户端不再发送 SYN 包。

在 Linux 中，第一次握手的 SYN 超时重传次数，是如下内核参数指定的（我自己的服务器是6次，与作者实验中的略有差异）：

[root@192 ~]# cat /proc/sys/net/ipv4/tcp_syn_retries
6
[root@192 ~]#
tcp_syn_retries 默认值为 5，也就是 SYN 最大重传次数是 5 次。

接下来，我们继续做实验，把 tcp_syn_retries 设置为 2 次：

echo 2 > /proc/sys/net/ipv4/tcp_syn_retries
重传抓包后，用 Wireshark 打开分析，显示如下图：

SYN 超时重传两次

实验一的实验小结
通过实验一的实验结果，我们可以得知，当客户端发起的 TCP 第一次握手 SYN 包，在超时时间内没收到服务端的 ACK，就会在超时重传 SYN 数据包，每次超时重传的 RTO 是翻倍上涨的，直到 SYN 包的重传次数到达 tcp_syn_retries 值后，客户端不再发送 SYN 包。

实验二：TCP 第二次握手 SYN、ACK 丢包

为了模拟客户端收不到服务端第二次握手 SYN、ACK 包，我的做法是在客户端加上防火墙限制，直接粗暴的把来自服务端的数据都丢弃，防火墙的配置如下：

接着，在客户端执行 curl 命令：

从 date 返回的时间前后，可以算出大概 1 分钟后，curl 报错退出了。

客户端在这其间抓取的数据包，用 Wireshark 打开分析，显示的时序图如下：

从图中可以发现：

客户端发起 SYN 后，由于防火墙屏蔽了服务端的所有数据包，所以 curl 是无法收到服务端的 SYN、ACK 包，当发生超时后，就会重传 SYN 包
服务端收到客户的 SYN 包后，就会回 SYN、ACK 包，但是客户端一直没有回 ACK，服务端在超时后，重传了 SYN、ACK 包，接着一会，客户端超时重传的 SYN 包又抵达了服务端，服务端收到后，超时定时器就重新计时，然后回了 SYN、ACK 包，所以相当于服务端的超时定时器只触发了一次，又被重置了。
最后，客户端 SYN 超时重传次数达到了 5 次（tcp_syn_retries 默认值 5 次），就不再继续发送 SYN 包了。
所以，我们可以发现，当第二次握手的 SYN、ACK 丢包时，客户端会超时重发 SYN 包，服务端也会超时重传 SYN、ACK 包。

咦？客户端设置了防火墙，屏蔽了服务端的网络包，为什么 tcpdump 还能抓到服务端的网络包？
添加 iptables 限制后， tcpdump 是否能抓到包 ，这要看添加的 iptables 限制条件：

如果添加的是 INPUT 规则，则可以抓得到包
如果添加的是 OUTPUT 规则，则抓不到包
网络包进入主机后的顺序如下：

进来的顺序 Wire -> NIC -> tcpdump -> netfilter/iptables
出去的顺序 iptables -> tcpdump -> NIC -> Wire
tcp_syn_retries 是限制 SYN 重传次数，那第二次握手 SYN、ACK 限制最大重传次数是多少？
TCP 第二次握手 SYN、ACK 包的最大重传次数是通过 tcp_synack_retries 内核参数限制的，其默认值如下：

[root@192 ~]# cat /proc/sys/net/ipv4/tcp_synack_retries
5
[root@192 ~]#
是的，TCP 第二次握手 SYN、ACK 包的最大重传次数默认值是 5 次。

为了验证 SYN、ACK 包最大重传次数是 5 次，我们继续做下实验，我们先把客户端的 tcp_syn_retries 设置为 1，表示客户端 SYN 最大超时次数是 1 次，目的是为了防止多次重传 SYN，把服务端 SYN、ACK 超时定时器重置。

接着，还是如上面的步骤：

客户端配置防火墙屏蔽服务端的数据包
客户端 tcpdump 抓取 curl 执行时的数据包
把抓取的数据包，用 Wireshark 打开分析，显示的时序图如下：

从上图，我们可以分析出：

客户端的 SYN 只超时重传了 1 次，因为 tcp_syn_retries 值为 1
服务端应答了客户端超时重传的 SYN 包后，由于一直收不到客户端的 ACK 包，所以服务端一直在超时重传 SYN、ACK 包，每次的 RTO 也是指数上涨的，一共超时重传了 5 次，因为 tcp_synack_retries 值为 5
接着，我把 tcp_synack_retries 设置为 2，tcp_syn_retries 依然设置为 1:

$ echo 2 > /proc/sys/net/ipv4/tcp_synack_retries
$ echo 1 > /proc/sys/net/ipv4/tcp_syn_retries
依然保持一样的实验步骤进行操作，接着把抓取的数据包，用 Wireshark 打开分析，显示的时序图如下：

可见：

客户端的 SYN 包只超时重传了 1 次，符合 tcp_syn_retries 设置的值；
服务端的 SYN、ACK 超时重传了 2 次，符合 tcp_synack_retries 设置的值
实验二的实验小结
通过实验二的实验结果，我们可以得知，当 TCP 第二次握手 SYN、ACK 包丢了后，客户端 SYN 包会发生超时重传，服务端 SYN、ACK 也会发生超时重传。

客户端 SYN 包超时重传的最大次数，是由 tcp_syn_retries 决定的，默认值是 5 次；服务端 SYN、ACK 包时重传的最大次数，是由 tcp_synack_retries 决定的，默认值是 5 次。

实验三：TCP 第三次握手 ACK 丢包

为了模拟 TCP 第三次握手 ACK 包丢，我的实验方法是在服务端配置防火墙，屏蔽客户端 TCP 报文中标志位是 ACK 的包，也就是当服务端收到客户端的 TCP ACK 的报文时就会丢弃，iptables 配置命令如下：

接着，在客户端执行如下 tcpdump 命令：

然后，客户端向服务端发起 telnet，因为 telnet 命令是会发起 TCP 连接，所以用此命令做测试：

此时，由于服务端收不到第三次握手的 ACK 包，所以一直处于 SYN_RECV 状态：

而客户端是已完成 TCP 连接建立，处于 ESTABLISHED 状态：

过了 1 分钟后，观察发现服务端的 TCP 连接不见了：

过了 30 分钟，客户端依然还是处于 ESTABLISHED 状态：

接着，在刚才客户端建立的 telnet 会话，输入 123456 字符，进行发送：

持续「好长」一段时间，客户端的 telnet 才断开连接：

以上就是本次的实现三的现象，这里存在两个疑点：

为什么服务端原本处于 SYN_RECV 状态的连接，过 1 分钟后就消失了？
为什么客户端 telnet 输入 123456 字符后，过了好长一段时间，telnet 才断开连接？
不着急，我们把刚抓的数据包，用 Wireshark 打开分析，显示的时序图如下：

上图的流程：

客户端发送 SYN 包给服务端，服务端收到后，回了个 SYN、ACK 包给客户端，此时服务端的 TCP 连接处于 SYN_RECV 状态；
客户端收到服务端的 SYN、ACK 包后，给服务端回了个 ACK 包，此时客户端的 TCP 连接处于 ESTABLISHED 状态；
由于服务端配置了防火墙，屏蔽了客户端的 ACK 包，所以服务端一直处于 SYN_RECV 状态，没有进入 ESTABLISHED 状态，tcpdump 之所以能抓到客户端的 ACK 包，是因为数据包进入系统的顺序是先进入 tcpudmp，后经过 iptables；
接着，服务端超时重传了 SYN、ACK 包，重传了 5 次后，也就是超过 tcp_synack_retries 的值（默认值是 5），然后就没有继续重传了，此时服务端的 TCP 连接主动中止了，所以刚才处于 SYN_RECV 状态的 TCP 连接断开了，而客户端依然处于ESTABLISHED 状态；
虽然服务端 TCP 断开了，但过了一段时间，发现客户端依然处于ESTABLISHED 状态，于是就在客户端的 telnet 会话输入了 123456 字符；
此时由于服务端已经断开连接，客户端发送的数据报文，一直在超时重传，每一次重传，RTO 的值是指数增长的，所以持续了好长一段时间，客户端的 telnet 才报错退出了，此时共重传了 15 次。
通过这一波分析，刚才的两个疑点已经解除了：

服务端在重传 SYN、ACK 包时，超过了最大重传次数 tcp_synack_retries，于是服务端的 TCP 连接主动断开了。
客户端向服务端发送数据包时，由于服务端的 TCP 连接已经退出了，所以数据包一直在超时重传，共重传了 15 次， telnet 就断开了连接。
TCP 第一次握手的 SYN 包超时重传最大次数是由 tcp_syn_retries 指定，TCP 第二次握手的 SYN、ACK 包超时重传最大次数是由 tcp_synack_retries 指定，那 TCP 建立连接后的数据包最大超时重传次数是由什么参数指定呢？
TCP 建立连接后的数据包传输，最大超时重传次数是由 tcp_retries2 指定，默认值是 15 次，如下：

[root@192 ~]# cat /proc/sys/net/ipv4/tcp_retries2
15
[root@192 ~]#
如果 15 次重传都做完了，TCP 就会告诉应用层说：“搞不定了，包怎么都传不过去！”

那如果客户端不发送数据，什么时候才会断开处于 ESTABLISHED 状态的连接？
这里就需要提到 TCP 的 保活机制。这个机制的原理是这样的：

定义一个时间段，在这个时间段内，如果没有任何连接相关的活动，TCP 保活机制会开始作用，每隔一个时间间隔，发送一个「探测报文」，该探测报文包含的数据非常少，如果连续几个探测报文都没有得到响应，则认为当前的 TCP 连接已经死亡，系统内核将错误信息通知给上层应用程序。 参考技术A 1、打开wireshark，主界面如下：

打开APP查看高清大图
2、选择菜单栏上 捕获 -> 选项，勾选WLAN网卡。这里需要根据各自电脑网卡使用情况选择，简单的办法可以看使用的IP对应的网卡。点击Start，启动抓包。

3、wireshark启动后，wireshark处于抓包状态中。

4、执行需要抓包的操作，如在cmd窗口下执行ping www.baidu.com。

5、操作完成后相关数据包就抓取到了，可以点击 停止捕获分组 按钮。

6、为避免其他无用的数据包影响分析，可以通过在过滤栏设置过滤条件进行数据包列表过滤，获取结果如下。说明：ip.addr == 183.232.231.172 and icmp 表示只显示ICPM协议且主机IP为183.232.231.172的数据包。说明：协议名称icmp要小写。

7、wireshark抓包完成，并把本次抓包或者分析的结果进行保存，就这么简单。关于wireshark显示过滤条件、抓包过滤条件、以及如何查看数据包中的详细内容

starUML怎么画时序图？

starUML怎么画时序图？或者给个教程的网址（中文版）

　　StarUml可以完美的支持ration rose 的uml图，而且是免费开源的。
　　画时序图、等图时，需要如下操作：
　　选择右上角的model expoloer
　　选中其中一个model
　　顶部菜单=>model=>add diagram
　　然后选择相应的图 参考技术A 右键你的那个总的model，add-》 actor。之后就会在model explorer里面出现那个小人图标。
1、首先建立一个空项目，如图所示：

2、然后在右面的Model Explorer窗口中新建立一个Model，如图所示：

3、在新建的Model1上，添加时序图，如图所示：

4、然后在Model1上选择Add下的Actor(角色)，如图所示：

5、然后按照下图的设置将小人添加到时序图中，如图所示：

6、如果想要重命名角色的话，不要在时序图中双击重命名，要在刚才添加小人那重命名，这样就把小人(角色)添加到了时序图中。 参考技术B http://zhidao.baidu.com/question/210085691.html