六、使用高级统计工具
在本章中,我们将学习以下主题:
- 使用过滤器配置 I/O 图形以测量网络性能问题
- 使用 I/O 图测量吞吐量
- 具有高级 y 轴参数的高级 I/O 图形配置
- 通过 TCP 流图获取信息–时间/顺序(Steven 的)窗口
- 通过 TCP 流图获取信息–时间/序列(TCP-trace)窗口
- 通过 TCP 流图获取信息–吞吐量窗口
- 通过 TCP 流图获取信息–往返时间窗口
- 通过 TCP 流图获取信息–窗口缩放窗口
介绍
在第 5 章、*使用基本统计工具、*中,我们讨论了基本统计工具,即终端用户列表、对话列表、捕获摘要等。在本章中,我们将了解高级统计工具——I/O 图、TCP 流图,简而言之,还有 UDP 组播流。
我们将在这里讨论的工具使我们能够更好地了解网络。这里,我们有两个主要工具:
- I/O 图形,使我们能够查看任何预定义过滤器的统计图形,例如,单个 IP 地址上的吞吐量、两台或多台主机之间的负载、应用吞吐量、TCP 现象分布、帧之间的时间、TCP 序列号和确认之间的时间等。
- TCP 流图。在检查这些问题时,我们将更深入地研究单个 TCP 连接,并了解如何隔离 TCP 问题以及导致这些问题的原因。
Wireshark v2 显著改进了 I/O 图和 TCP 流图。在本章中,我们将学习如何使用这些工具;在处理协议的章节中,我们将需要它们来进行更深入的协议分析。
使用过滤器配置 I/O 图形以测量网络性能问题
在本菜谱中,我们将学习如何使用 I/O 图形工具,以及如何配置它来进行网络故障排除。
做好准备
在统计菜单下,打开 I/O 图。您可以在联机文件捕获过程中或在之前捕获的文件上执行此操作。在实时捕获中使用 I/O 图时,您将获得捕获数据的实时统计信息。
怎么做…
运行 I/O 图,您将得到以下窗口:
在窗口的上部,您可以看到图形区域。在左下方,您可以看到 filters 区域,该区域允许您配置将启用特定图形的显示过滤器。正如您在前面的截图中看到的,默认值是在 y 轴上的每秒包数和在 x 轴上的以秒为单位的时间。
您可以为窗口显示配置以下参数:
- 窗口左下角的+/-和复制按钮用于添加/删除和复制图表。
- 使用“鼠标用法”复选框来拖动或缩放。您可以将图形拖过窗口,并使用缩放功能来放大或缩小。使用窗口右下角的重置按钮返回到初始窗口状态。
在 x 轴上,可以通过以下方式配置参数:
- 选择间隔。范围可以在 1 毫秒到 10 分钟之间
例如,如果当 x 轴被配置为 1 秒的间隔时,我们获得每秒 1000 个包的峰值,这意味着在最后一秒,我们已经接收了 1000 个包。当我们将 x 轴更改为 0.1 秒间隔时,峰值会有所不同,因为现在我们可以看到在过去的 0.1 秒内捕获了多少个数据包。
- 选中“一天中的时间”复选框,以选择“一天中的时间”格式,而不是从捕获开始的时间
在 y 轴配置上,可以进行如下更改:
- 选中对数标度复选框,以对数标度查看图表
图形配置:
- 在图形窗口中,您可以添加/删除/复制和更改图形。只需完成以下步骤:
- 当您启动 I/O 图形时,默认情况下会显示所有数据包图形。
- 要添加带有过滤器的附加图形,请单击 I/O 图形窗口左下角的+号。将添加一个新行。
- 在“名称”列中为图表命名。
- 在显示过滤器列中配置所需的过滤器。顾名思义,该过滤器采用带有自动完成功能的显示过滤器语法。
- 配置(或保留默认值)颜色和样式列。
- 在样式栏中,您可以配置线条、脉冲、条形图、堆积条形图、点、正方形和菱形参数。例如,Line 适用于流量图,而 Dot 适用于 TCP 分析、重新传输、重复 ACK 等事件图。
- 如果您想要查看运行平均值,即在每个分笔成交点间隔中查看过去分笔成交点的平均值,请选取平滑。您可以选择 4 到 1024 之间的值来平滑图形。
在下面的示例中,CAP_1674_06_02
,您会看到一个包含所有数据包、tcp.analysis.duplicate_ack
和tcp.analysis.fast_retransmission
过滤器的流量图:
在示例中,您可以看到 x 轴刻度以 10 ms(毫秒)为单位, y 轴刻度以数据包/10 ms 为单位。在第一个图表中,所有数据包是没有任何过滤器的总流量,以线条样式呈现;使用过滤器tcp.analysis.
duplicate_ack
的第二个图形使用点样式呈现,使用过滤器tcp.analysis.
fast_retransmission
的第三个图形使用正方形样式呈现。该图以放大的焦点呈现在从捕获开始起 52.5 到 52.86 秒之间的时间上。
流量从 52.53 到 52.54 的每 10 毫秒 6 个包( 1 )的峰值开始,接下来的两个峰值是每 10 毫秒 12 个包( 4 和 9 )。
对于重复确认,我们在 52.61 秒看到一个事件( 2 ,在 52.62 秒看到六个事件( 3 ,在 52.68 秒看到两个事件( 5 ,在 52.69 秒看到两个事件( 6 ,在 52.60 秒,我们看到五个重复确认( 8 事件)和一个快速重传事件( 7 )。
正如我们从下面的截图中看到的,特定时间的事件意味着在指定时间发生的事件—例如,在时间 52.62 发生的六个事件意味着在时间 52.62 发生了六个事件:
稍后,在处理协议的章节中,我们将看到我们在这里谈到的准确性的重要性,以及何时何地使用它。
它是如何工作的…
I/O 图形功能是重要的 Wireshark 工具之一,使我们能够监控在线性能以及离线捕获文件分析。
当你使用这个工具时,重要的是要记住用正确的 x 轴和 y 轴参数配置正确的滤波器。
我们可以在 y 轴上测量两种类型的参数。第一种类型是数字参数——数据包、字节和位,相对于 x 轴中的时间刻度进行测量。如下面的屏幕截图所示,第二种类型的参数是 SUM、COUNT FRAMES、COUNT FIELDS、MAX、MIN、AVG 和 LOAD,它们用于 y 轴不一定显示数字的计数,如本章后面的“使用高级 y 轴参数的高级 I/O 图形配置”一节所述:
另一个需要记住的重要特性是窗口左侧的平滑栏,如下图所示。术语平滑意味着它不会绘制每个样本的值,但会累积最近的 10、20、50、100 和 200 个样本,构建这些读数的平均值,并绘制该平均值(10、20、50、100 等等):
正如我们将在后面看到的,这可以用于带宽/吞吐量测量。
还有更多…
要查看 I/O 图形窗口的快捷方式列表,请将鼠标放在图形窗口和过滤器窗口之间的空间:
在这个窗口中,你可以以任何你认为合适的方式改变这个显示——例如,你可以放大/缩小 x 或 y 刻度,移动光标,在选项之间切换,等等。
使用 I/O 图测量吞吐量
I/O 图形功能是一种测量网络吞吐量的便捷工具。我们可以用它来测量任何预定义过滤器的流量和吞吐量。在这个配方中,我们将看到一些如何使用它来测量网络吞吐量的例子。
做好准备
使用 Wireshark 将您的笔记本电脑连接到网络,将端口镜像到您想要测量的链路,正如您在第 1 章、Wireshark v2中所学。启动新的捕获或打开现有文件,然后从统计菜单中打开 I/O 图形。
测量吞吐量时,我们可以在终端设备(PC 到服务器、电话到电话、PC 到互联网)或特定应用之间的通信线路上进行测量:
隔离网络问题的过程始于测量链路上、终端设备之间或单个连接上的流量,以了解流量的来源。
一些典型的测量是主机到主机的流量、到特定服务器的所有流量、到特定服务器上的特定应用的所有流量、特定服务器上的所有 TCP 性能现象等等。
怎么做…
在本菜谱中,我们将提供一些基本的过滤器来测量整个网络的流量。
测量下载/上传流量
让我们来看看接下来的两幅图,其中一台 IP 地址为10.0.0.10
的电脑正在浏览互联网,在 http://www.youtube.com 的上看电影。图表在文件CAP_1674_06_03
中配置。
在这两个 I/O 图中,我们配置了两个过滤器:
- 第一张图显示了所有流向 IP 地址
10.0.0.10
的流量——这是ip.dst==10.0.0.10
过滤器,以红色显示(上面一行)。这是下载(下行)流量的图表。 - 第二张图显示了来自 IP 地址
10.0.0.10
的所有流量——这是ip.src==10.0.0.10
过滤器,用绿色表示(下面一行)。这是上传(上行)流量的图表。
在第一张图中,我们可以看到,当 x 轴被配置为 1 秒的时间间隔,并且 y 轴刻度被配置为包/秒时,我们已经测量了流量。我们得到的结果显示,当用户观看电影时,上传的内容约占总下载量的一半:
在第二张图中,我们可以看到以比特/秒为单位观看质量合理的电影的流量。在这个例子中,正在通过http://www.youtube.com观看电影。正如你所看到的,最初下载的流量是 10 兆比特/秒(这是当你打开电影窗口时看到的小圆箭头),从那时起连续观看电影的流量是 6 兆比特/秒。
我们还可以看到,流量是强烈不对称的,大部分流量来自下载。在下面的截图中,你可以看到为什么:
在这里,我们可以看到从googlevideo.com
到10.0.0.10
的每两个下行分组有一个上行确认,这就是为什么我们看到 1:2 的比率。另一方面,当我们查看数据包长度时,我们可以看到下载流量中的两个数据包的长度为 1,506 字节,而上行确认数据包是一个短的 54 字节长的数据包。
测量两个终端设备之间的几个流
要测量端点设备之间的吞吐量,只需在它们的 IP 地址之间配置一个显示过滤器。
让我们看看统计|对话中的CAP_1674_06_04
文件。在该文件中,我们可以看到三个最繁忙的连接如下:
- 从终端服务器客户端
192.168.1.192
到终端服务器172.30.0.10
的一个连接 - 从终端服务器
172.30.0.10
到数据库服务器172.30.0.22
的两个连接
在下面的屏幕截图中,我们可以看到对话窗口:
过滤器字段中设置的参数如下:
ip.addr==172.30.0.22 && tcp.port==57604 && ip.addr==172.30.0.10 && tcp.port==445
ip.addr==172.30.0.22 && tcp.port==58479 && ip.addr==172.30.0.10 && tcp.port==445
ip.addr==192.168.1.192 && tcp.port==45214 && ip.addr==172.30.0.10 && tcp.port==3389
正如我们在下面的截图中看到的,当我们查看 I/O 图时,我们可以看到从终端服务器172.30.0.10
到数据库服务器172.30.0.22
的两个峰值。棕色的客户端-服务器流量 1 出现在右侧,绿色的客户端-服务器流量 2 出现在左侧:
由于从终端服务器到数据库服务器的两个比特流的带宽远高于终端服务器流的带宽,因此我们在此窗口中看不到最后一个比特流(屏幕截图中添加了虚线)。为了查看它,我们禁用了两个较高的位流复选框,我们得到的结果如下:
在这里,我们可以看到终端服务器流量的最高峰值大约是每秒 400,000 位(在前面的屏幕截图中添加了一条虚线)。
测量应用吞吐量
为了配置特定应用的性能测量,您可以配置包含特定端口号或特定连接的过滤器。
有几种方法可以隔离应用图:
- 在捕获的数据中,单击属于通信流的任何数据包。在 TCP 中,会是特定的连接;在 UDP 中,它只是一个 IP/端口对之间的流。
- 右键单击它并选择跟随 TCP 流或跟随 UDP 流。
- 你会得到
tcp.stream eq <number>or udp.stream eq <number>
。<number>
只是捕获文件中的流的编号。 - 将字符串复制到 I/O 图形中的过滤器窗口,您将获得特定流的图形:
使用 TCP 事件分析测量 TCP 流
要测量特定的流以找到干扰该流的事件,请使用如下 I/O 图:
-
打开捕获文件(或开始新的捕获)并启动 I/O 图形。在这个例子中,我们使用了
CAP_1674_06_06
文件。 -
在第一个过滤器中,配置流编号—在本例中,我们看到的是
tcp.stream eq 0
。这会给你这个流的流量。 -
在第一个过滤器中,配置流编号和
tcp.analysis.retransmissions: tcp.stream eq 0
,和tcp.analysis.retransmissions
。这将显示特定流上的所有 TCP 重新传输现象(指示慢速终端设备)。
在下面的屏幕截图中,我们在第一个线形图中看到 0 号流,在第二个点状图中看到该流的重新传输:
在第十章、网络层协议和操作中,我们将看到如何使用这些特性对 TCP 流量进行深入分析。
它是如何工作的…
I/O graph 工具的强大之处在于,您可以配置任何显示过滤器,并以各种形状和配置将其视为图形。数据包中的任何参数都可以通过这种方式进行过滤和监控。
还有更多…
您可以在任何可以通过显示过滤器字符串过滤的参数上配置 I/O 图形,这使它成为一个非常强大的工具。让我们看一些例子。
我们可以使用图表来查找特定用户发送的 SMS 消息(CAP_1674_06_07
):
- 要配置过滤器,使用
Submit_SM
命令选择短消息点对点 (SMPP)协议数据包。这是发送 SMS 的 SMPP 命令。 - 键入
smpp.source_addr == phone number
过滤器。在示例中应用了smpp.source_addr == 0529992525
过滤器:
我们还可以使用一个图表来显示一些 HTTP 请求(CAP_1674_06_08
):
- 打开 I/O 图。您可以在捕获期间执行此操作以查看在线统计数据,也可以打开保存的捕获文件。
- 在输入/输出图形窗口中配置
http.request
过滤器。 - 您将得到下图:
该图显示了每秒包含 HTTP 请求的数据包数量。
本配方的目的是展示 I/O 图形工具的功能。稍后,在处理协议的章节中,我们将使用它们进行更深入的协议分析。
具有 y 轴参数的高级 I/O 图形配置
在使用 I/O 图的标准测量中,当 y 轴以包/秒、字节/秒或比特/秒为单位显示时,我们测量网络的性能。有些类型的数据不能用这些参数来度量,例如,我们度量查询和响应之间的秒数、以太网帧之间的秒数、延迟,以及我们将在这个配方中看到的其他类似情况。下一节将介绍这些参数。这些功能在 Wireshark 版本 1 的 y 轴选项中被称为高级。
做好准备
打开 y 轴下的下拉菜单,如下截图所示:
您将获得以下 y 轴选项:
- SUM (Y 字段):绘制一个图表,其中包含刻度间隔内的参数摘要
- 计算帧数(Y 字段):绘制一个图形,计算时间间隔内过滤帧的出现次数
- 计数字段(Y 字段):绘制一个图表,对时间间隔内筛选字段的出现次数进行计数
- MAX (Y 字段):用时间间隔内参数的平均值绘制图形
- MIN (Y 字段):用时间间隔中参数的最小值绘制图形
- AVG (Y 字段):用时间间隔内参数的平均值绘制图形
- 负载(Y 字段):用于响应时间图表
在 Y 字段中,您可以设置想要查看的参数。
怎么做…
要开始使用带有 y 轴配置选项功能的 I/O 图形,请完成以下步骤:
- 从统计菜单启动 I/O 图
- 在 Y 轴下拉菜单中,选择您希望出现在 y 轴上的参数
- 您将看到一个带有字符串 SUM (Y 字段)的新下拉菜单
- 选择以下字段:总和(Y 字段)/计数帧(Y 字段)/计数字段(Y 字段)/最大值(Y 字段)/最小值(Y 字段)/ AVG (Y 字段)/负载(Y 字段)
- 在 Y 字段列中配置适当的过滤器
让我们看一些有用的例子。
监控帧间时间增量统计
帧之间的时间增量会影响 TCP 性能,并严重影响语音和视频等交互式应用。因此,您可以使用各种选项。其中之一是将frame.time_delta
用于所有帧之间的时间增量,或者将frame.time_delta
用于显示的分组之间的时间增量。
让我们看看下面的捕获文件(文件CAP_06_09
):
正如我们在前面的屏幕截图中看到的,配置了以下参数:
- 在显示过滤器栏中,过滤器 ip.src==212.143.195.13 。这是用来查看从这个网站传到我们电脑的帧。
- 在 Y 轴字段中,AVG (Y 轴)用于显示平均帧间时间。
- 在 Y 字段列中,
frame.time_delta_displayed
过滤器用于显示帧间时间。
本例中的时间间隔被配置为 1 毫秒,放大视图的中心是从捕获开始起的 176 秒。
y 轴中的时间值以微秒表示,例如第 9391 帧和前一帧之间的帧间时间显示为 6349 微秒。
要查看最小值、平均值和最大值,我们可以使用三个图表,如下图所示。
我们可以查看frame.time_delta
过滤器的最大值、平均值和最小值,正如我们在下一个截图中看到的。请记住以下几点:
- 对于第一个图表:
- 在显示过滤器栏中,
ip.src==212.143.195.13
过滤器描述了从该网站传到我们电脑的帧 - 在 Y 轴字段中,AVG (Y 轴)用于显示平均帧间时间
- 在显示过滤器栏中,
- 对于第二个图表:
- 在显示过滤器栏中,
ip.src==212.143.195.13
过滤器描述了从该网站传到我们电脑的帧 - 在 Y 轴字段中,MIN (Y 轴)用于显示平均帧间时间
- 在显示过滤器栏中,
- 对于第三个图表:
- 在显示过滤器栏中,
ip.src==212.143.195.13
过滤器描述了从该网站传到我们电脑的帧 - 在 Y 轴字段中,MAX (Y 轴)用于显示平均帧间时间
- 在显示过滤器栏中,
正如 Style 列中所配置的,我们可以看到最小值为正方形,最大值为菱形,平均值为直线。我们应该如何处理这些图,以及如何使用它们进行网络调试?这一点我们将在第 10 章、网络层协议和操作到第 19 章、安全和网络取证中学习,这些章节处理协议。
监控流中 TCP 事件的数量
TCP 事件可以有多种类型—重新传输、滑动窗口事件、ack 等等。要查看一段时间内 TCP 事件的数量,我们可以使用带有高级功能和计数(Y 轴)参数的 I/O 图。
在下面的示例CAP_1674_06_10
中,我们有两个 TCP 流:
要配置 I/O 图形,请执行以下步骤:
- 从统计菜单中打开 IO 图。
- 配置显示筛选器列;在本例中,这些内容如下:
- 第一图:
ip.addr==10.0.0.1 && tcp.port==57449 && ip.addr==92.122.12.174 && tcp.port==80
- 第二张图表:
ip.addr==10.0.0.1 && tcp.port==57627 && ip.addr==88.221.159.148 && tcp.port==80
- 第一图:
要配置过滤器,您可以右键单击对话窗口中的流行,准备一个将出现在显示过滤器窗口中的过滤器,并将其复制到 I/O 图形窗口。您也可以右键单击流中的一个数据包,并选择跟随 TCP 流。
- 配置 Y 轴参数:
- 配置帧数(Y 场)。
- 在 Y 字段上,配置过滤器——在本例中,这是所有 TCP 事件的
tcp.analysis
,但它可以是任何特定的过滤器,如tcp.analysis.retransmissions
、tcp.analysis.zero_window
或任何其他过滤器。
在最后一张截图中,我们可以看到两个时期的事件。我们可以放大其中的一个——例如,放大第一组事件——我们将获得下一个屏幕截图。
监控现场出现的次数
可变计数字段(Y 字段)对捕获文件中特定字段的出现次数进行计数,或对由“显示过滤器”列中配置的过滤器过滤的信息进行计数。
其原理如下:
- 在显示过滤器列中,您可以为应该检查的流量配置过滤器
- 在 Y 轴列中,您可以配置计数字段(Y 字段)
- 在 Y 字段列中,指定要对其外观进行计数的字段
在下面的截图(文件CAP_1674_06_11
)中,您可以看到一个如何使用它的示例:
在这里,我们可以看到我们检查了 A 记录和 AAAA 记录的出现次数:上图是 IPv4 A 记录,下图是 IPv6 AAAA 记录。
它是如何工作的…
I/O 图是 Wireshark 最强大、最有效的工具之一。虽然标准 I/O 图形统计可用于基本统计,但 y 轴配置可用于深入监控响应时间、单个流或多个流的 TCP 分析等。
当我们在左侧配置过滤器时,我们将过滤主机之间的流量、连接上的流量、服务器上的流量等等。 y 轴配置功能为我们提供了更多关于流量的详细信息。例如:
- 左边—TCP 流。右边—流中帧之间的时间增量
- 左侧—视频/RTP 流。右侧—出现一个标记位
还有更多…
您可以随时单击 I/O 图,它会将您带到数据包窗格中的参考数据包。
通过 TCP 流图获取信息–时间/顺序(Steven 的)窗口
Wireshark 中的一个工具是 TCP 流图,它使我们能够更深入地研究应用的行为。正如我们将在接下来的几个食谱中看到的,这些图表使我们能够获得应用行为的细节,这样做,为我们提供了定位问题的可能性。
做好准备
打开现有的捕获或开始新的捕获。单击捕获文件中的特定数据包。尽管您可以在正在运行的捕获上使用此功能,但它并不意味着用于在线统计,因此建议您启动一个捕获,停止它,然后使用此工具。
怎么做…
要查看 TCP 流图统计信息,请执行以下操作:
- 单击您想要监控的数据流上的数据包。
TCP 流显示了一个方向图,所以当你点击一个数据包时,它应该在你想要查看统计数据的方向。例如,如果您下载了一个文件,并且想要查看下载统计数据,请单击下载方向上的数据包。
- 从统计菜单中,选择 TCP 流图|时序图(Stevens)。
将会打开以下窗口:
该图显示了字节传输量随时间的变化过程。在本例中,我们可以看到一条连续的对角线,在传输中有一些平稳段。
图中的 Y 轴是序列号,而在图中我写的是数据包/秒图。实际上意思是一样的——图中的每个点指的是一个数据包,当它的值是 TCP 数据包中的第一个序列号时(参见*它是如何工作的…*本食谱后面的章节)。
在第 10 章、网络层协议和操作中,我们将了解该图表示什么,以及它有助于解决的一些案例。
- 对于文件传输,要测量其吞吐量,只需计算单位时间内传输的字节数,如下图所示:
-
我们可以看到,6 秒钟的传输速率为 350,000 字节,也就是大约 58,000 字节/秒,即 58 千位/秒。
-
默认情况下,“流图”菜单左下角的“拖动”复选框处于选中状态。在这种情况下,您可以上下拖动图形或者左右拉伸 x 轴- y 轴。例如,我们可以使用该功能将图表移动到更靠近 y 轴的位置,以查看特定的值。
当鼠标复选框设置为拖动时,您可以使用 Ctrl +鼠标滚轮来放大和缩小 TCP 流图。
- 当我们选中鼠标复选框右侧的缩放复选框时,我们会将设置更改为缩放。在下一个屏幕截图中,我们可以看到如何将图表放大两次,以获得特定时间段的更多详细信息,在本例中,我们看到的时间点大约在捕获开始后的 16 到 19 秒之间:
- 其他图形配置按钮如下:
- 图表类型(左下角,拖动/缩放复选框的正上方)。您可以在各种类型的 TCP 图之间进行选择(如下图所示):时间/序列(Stevens)、往返时间、吞吐量、时间/序列(tcptrace)、窗口缩放。
它是如何工作的…
时序图(Stevens)是一个简单的图表,它计算一段时间内的 TCP 序列号。由于 TCP 序列号计算 TCP 发送的字节数,所以这些实际上是从一端发送到另一端的应用字节(包括应用头)。
在图中,我们实际上看到了每个数据包的一个点,当该点位于 y 轴上时,在数据包的第一个字节的序列值上,如下图所示:
这个图表(我们将在 TCP 和应用的章节中学习)可以很好地显示应用的行为。例如,斜线表示文件传输良好,而有中断的斜线表示传输有问题。具有高梯度的对角线表示快速数据传输,而低梯度表示低传输速率(当然取决于规模)。
还有更多…
当鼠标被设置到窗口左下角的 drags 选项时,点击一个点会将您带到 capture 窗口中的匹配数据包。正如您在下面的屏幕截图中所看到的,在开始捕获后大约 15.24 秒,在数据包 8119 中传输了一个略高于 872,000 的序列号,然后在开始捕获后 15.35 秒,在数据包 8191 中再次传输:
在下面的截图中,我们可以看到在时序图中点击这两个点的结果。第一个数据包(数据包 8119)在捕获开始后的 15.248 秒时具有序列号 872674:
在下面的屏幕截图中,您可以看到第二个数据包,在开始捕获后的 15.25 秒,具有相同的序列号。当一个序列号自我重复时,这被称为 TCP 重传,将在第 10 章、网络层协议和操作中涉及。
查看图表时,重要的是了解应用是什么。指示一个应用中的问题的图可以是另一个应用的完美网络行为。
通过 TCP 流图-时间/序列(TCP-trace)窗口获取信息
基于 UNIX 的tcpdump
命令的 TCP 时间/序列图为我们提供了更多关于我们监控的连接的数据。除了时间序列(Stevens)中的标准序列/秒之外,通过 TCP 时间/序列图,我们还可以获得有关发送的 ack、重新传输、窗口大小和更多细节的信息,这些信息使我们能够分析连接问题。
做好准备
打开现有的捕获,或开始新的捕获。单击捕获文件中的特定数据包。尽管您可以在正在运行的捕获上使用此功能,但它并不意味着用于在线统计,因此建议您启动一个捕获,停止它,然后使用此工具。在这个菜谱中,我们使用示例文件CAP_1674_06_05
和CAP_1674_06_14
。
怎么做…
要查看 TCP 流图统计信息,请执行以下步骤:
- 单击您想要监控的数据流上的数据包。在本例中,我点击了捕获文件
CAP_1674_06_05
上的数据包 100。这就把我们带到了 0 号 TCP 流。
TCP 流显示一个方向图,所以当您单击一个数据包时,它应该在您想要查看统计数据的方向。例如,如果您下载了一个文件,并且想要查看下载统计数据,请单击下载方向上的一个数据包。
-
从“统计”菜单中,选择 TCP 流图时间序列(tcptrace)。
-
将会打开以下窗口。采集文件名称作为副标题列在图表顶部:
- 放大图表,我们会看到以下内容:
-
该图显示了字节传输随时间的进展。我们看到的是以下内容:
- 垂直的蓝色短线表示通过连接发送的数据包。
- 下方的棕色图表显示了为收到的数据包发送的确认。
- 上面的绿线显示了窗口大小。两条线之间的空间——即上面的绿色线和下面的棕色线——表示剩余的 TCP 缓冲区的大小,这使得 TCP 能够继续发送字节。当两条线越来越近并相互接触时,这是一种满窗现象,无法实现更大的数据传输。
-
当我们进一步放大图表时,我们会看到下面的屏幕截图:
在这里,我们可以看到:
- 自捕获开始 75 秒后,发送了几个数据包
- 这些数据包在 75.08 到 75.09 之间得到确认,这大约是它们发送后的 80-90 毫秒
- 我们还看到,空闲接收器窗口大约为 7000 字节,这是在 y 轴上的 271000-264000 个序列
要在数据包捕获窗格中查看这些信息,请单击鼠标|拖动,然后用鼠标单击其中一个点,相关的数据包将在数据包窗格中标记出来:
正如您在数据包窗格中看到的,我们有六个数据包从10.0.0.10
发送到172.217.22.80
。这些都是同一个 TCP 数据包的数据段,因此它们在很短的时间内被发送,从捕获开始不到 75 秒。紧接着,我们可以看到六个致谢。我们还可以在确认数据包中看到,接收方显示的窗口大小约为 7,000 字节,这是图中上方绿线和下方棕色线之间的距离。
它是如何工作的…
时序(tcptrace
)取自 UNIX 的tcpdump
命令,它也指接收方发布的窗口大小(这是接收方分配给进程的缓冲区大小),以及重新传输的数据包和 ack。
使用此图为我们提供了大量信息,我们将在以后的网络调试中使用这些信息。该图将使窗口比预期更快变满、过多的重新传输等现象变得明显,这将帮助我们解决这些问题。
还有更多…
在某些情况下,尤其是在高速数据传输中,图表可能看起来像一条完美的直线,但当你放大时,你会发现问题。
在下面的截图中,我们可以看到捕获文件CAP_1674_06_14
:
放大显示我们有时间间隙,重新传输和其他问题:
您还可以看到,在一秒钟内,大约传输了 14,000 个序列(字节)——与连接的其余部分相比,这是相当慢的。
bar 是对数据包的指示(它携带初始和最终序列号之间的数据)。不在常规图形中并且看起来好像已经逃离的条是重传,灰色条是重复的 ACK。我们将在下一章的 TCP 分析中了解这些现象。
通过 TCP 流图获取信息–吞吐量窗口
TCP 流图的吞吐量窗口使我们能够查看连接的吞吐量。根据该图,我们还可以根据应用检查不稳定性。
做好准备
打开现有的捕获,或开始新的捕获。单击捕获文件中的特定数据包。尽管您可以在正在运行的捕获上使用此功能,但它并不意味着用于在线统计,因此建议您启动一个捕获,停止它,然后使用此工具。
怎么做…
要查看 TCP 流图统计信息,请执行以下步骤:
-
单击您想要监控的数据流上的数据包。
-
从统计菜单中,选择 TCP 流图|吞吐量图。
-
将会打开以下窗口:
在这里,我们可以看到示例CAP_1674_06_14
,流 0。在图表中,我们可以看到以下内容:
- TCP 连接吞吐量。我们在这里看到它大约是 700-800 千比特/秒。
- TCP 数据段长度。这是 TCP 大小。
数据网络中数据单元的正式定义因其所属的 OSI 层而异——帧到第 2 层,例如以太网帧;包到第 3 层,例如 IP 包;段到第 4 层 TCP 数据报到第 4 层 UDP。协议数据单元(PDU)是所有此类单元的统称。在大多数情况下,这些术语是在适当的位置使用的,我在本书中已经尝试这样做了,但是在许多其他情况下,它们之间存在混淆。无论如何,重要的是理解我们正在谈论的是哪一层,不管正式的定义是什么。
这个图似乎没有 TRP 时间/序列图那么有用,但是它仍然可以向我们显示吞吐量的任何突然下降,这可以表明一个问题。
它是如何工作的…
吞吐量图简单地统计了一段时间内的 TCP 序列号,由于序列号实际上是应用数据,因此它给出了以每秒字节数为单位的应用吞吐量。
还有更多…
稳定的文件传输应该类似于中心值,如下图左侧所示。不稳定的文件传输可能看起来像右图,其中吞吐量图上下跳动:
您还可以在 I/O 图中看到吞吐量。需要注意的主要一点是,I/O 图显示了跟踪文件中所有流量在两个方向上的吞吐量,而 TCP 流吞吐量图只显示了一个 TCP 流在一个方向上的吞吐量(基于所选的数据包)。如果您过滤 I/O 图,使其与吞吐量图查看相同的流量,您将看到相同的字节/秒值。
通过 TCP 流图获取信息–往返时间窗口
TCP 流图的往返时间窗口使我们能够查看序列号和它们被确认的时间之间的往返时间。与其他图表一起,它让我们看到了连接的性能。
做好准备
打开现有的捕获,或开始新的捕获。单击捕获文件中的特定数据包。尽管您可以在正在运行的捕获上使用此功能,但它并不意味着用于在线统计,因此建议您启动一个捕获,停止它,然后使用此工具。
在下面的例子中,我们将CAP_1674_06_13
文件用于 TCP 流编号 8,它是从数据包 85 开始的 TCP 连接。
怎么做…
要查看 TCP 流图统计信息,请执行以下步骤:
-
单击您想要监控的数据流上的数据包。
-
从统计菜单中,选择 TCP 流图|往返时间图。
-
将会打开以下窗口:
- 在图中,我们可以看到大多数序列号在短时间内被确认,但有一些不稳定性,这将影响 TCP 性能。
- 如果您想在 I/O 图形中看到这个图形,请使用
tcp.analysis.ack_rtt
过滤器。 - 要查看序列,以便您可以看到确认较小时间单位的图形进度,请使用鼠标缩放功能。
它是如何工作的…
我们在图中看到的是 TCP 序列号和确认它们所用的时间。这是发送数据包和收到该数据包的 ACK 之间的时间。
还有更多…
您可以在 TCP 数据包下方的“数据包详细信息”窗格中看到tcp.analysis, ack_rtt
过滤器的值,如下图所示:
当你看到显示不稳定性的图表时,这不一定是个问题。这很可能就是应用的工作方式。可能需要时间来确认数据包,因为存在问题,或者因为服务器正在等待响应,或者因为客户端只是浏览 web 服务器,而用户正在单击几个新链接。
在 Wireshark v2 中,您可以在窗口左下角的下拉菜单中选择图形类型。
通过 TCP 流图获取信息–窗口缩放窗口
TCP 流图的窗口缩放图使我们能够查看接收方公布的窗口大小,这是接收方处理数据能力的指示。与其他图表一起,它让我们看到了连接的性能。
做好准备
打开现有的捕获,或开始新的捕获。单击捕获文件中的特定数据包。尽管您可以在正在运行的捕获上使用此功能,但它并不意味着用于在线统计,因此建议您启动一个捕获,停止它,然后使用此工具。
怎么做…
要查看 TCP 流图统计信息,请执行以下步骤:
- 单击您想要监控的数据流上的数据包。
- 从统计菜单中,选择 TCP 流图|窗口缩放图。
- 将会打开以下窗口:
在这个图中,我们可以看到不稳定性,是由一边引起的。这可能表示服务器或客户端速度较慢,无法处理收到的所有数据,因此,通过减小接收的窗口大小,它会告诉另一端发送较少的数据。
它是如何工作的…
这里的软件简单地观察连接上的窗口大小并画出它。在第 10 章、网络层协议和操作中,我们将更详细地探讨这一点。
还有更多…
当窗口大小减小时,应用吞吐量也应该减小。窗口大小完全由连接的两端控制,例如客户端和服务器,窗口大小的变化与网络性能没有任何关系。
七、使用专家系统
在这一章中,我们将学习专家系统,这是一个为我们提供更深入的网络现象分析的工具,包括事件和问题。我们将讨论:
- 专家系统窗口以及如何使用它进行网络故障排除
- 错误事件以及我们可以从中了解到什么
- 警告事件以及我们能从中了解到什么
- 记录事件以及我们能从中了解到什么
介绍
Wireshark 最强大的功能之一是能够分析网络现象并提出可能的原因。与其他工具一起,它为我们提供了关于网络性能和问题的详细信息。在本章中,我们将学习如何使用这个工具。在本书的后面,我们将提供使用专家系统和其他工具来查找和解决网络问题的详细方法。
当我们第一次检查网络、通信链路、主机服务器等时,可以使用专家信息选项,我们希望得到网络的第一次填充。在我们进行更深入的分析之前,我们将能够看到是否有可以表明问题的事件。我们应该寻找可以抓住的事件:像 TCP 重传、以太网校验和错误、DNS 问题、重复 IP 等等。
在第一个食谱中,我们将学习如何使用专家信息窗口。在下一个菜谱中,我们将了解您可能会想到的大多数事件的可能原因。
专家系统窗口以及如何使用它进行网络故障排除
专家窗口提供了 Wireshark 发现的事件和网络问题列表。在本食谱中,我们将学习如何启动专家系统,以及如何参考各种事件。
做好准备
启动 Wireshark,开始实时捕获或打开现有文件。
怎么做…
要启动专家窗口,请单击分析菜单;选择专家信息:
将会打开以下窗口:
所有有效的事件都按这个顺序显示(如果有的话):错误、警告、注释等等…
条形右侧的数字显示了该类别中事件的数量。
上方的条形图提供了以下信息:
- 错误:严重的问题可能是以太网校验和错误、格式错误的数据包或协议报头中缺少字段。这些可能是各种类型的格式错误的数据包,如格式错误的 SPOOLSS、GTP 等。它们也可能是错误的校验和错误,例如 IPv4 错误的校验和。在下面的屏幕截图中,您可以看到以太网校验和错误:
单击错误组左侧的小箭头,打开该类别下的错误列表。要在数据包窗格中查看特定数据包,请单击数据包行。
- 警告:警告表示应用或通信中的问题:如 TCP 零窗口、TCP 窗口满、前一个数据段未被捕获、无序数据段以及任何不符合协议行为的问题。你可以在下面的截图中看到这样的例子:
- 注意事项:当 Wireshark 指出某个事件可能会导致问题,但仍在协议的正常行为范围内时,就会出现注意事项。例如,TCP 重新传输将显示在这里,因为即使它是一个使网络变慢的关键问题,它仍然在 TCP 的正常行为下。这里的其他事件有重复 ACK、快速重传等等。在下面的截图中,您可以看到重新传输和重复确认;它们可能表示通信缓慢,但仍然是 TCP 协议的正常行为:
- 聊天:提供通常工作流程的信息,例如 TCP 连接建立请求(SYN)、TCP 连接建立确认(SYN + ACK)、连接重置(RST)、HTTP GET 和 HTTP POST:
- 数据包注释:您可以手动为每个数据包添加注释。这将出现在专家信息窗口的聊天中。
要给数据包添加注释,右键单击它并选择数据包注释…将打开一个窗口,您可以在其中添加或更改您的评论。你可以在下一张截图中看到这一点。
一般操作注意事项:
- 在“专家信息”窗口的底部,您可以选择限制显示过滤器和按摘要分组(默认情况下标记),您还可以搜索事件中的特定单词。
- 要转到 packet capture 窗格中的事件,只需在 expert 窗口中单击事件下的数据包,它就会引导您找到该事件。
值得注意的是,警告事件可能不重要,而记录事件可能会严重影响网络。总是深入问题的细节,看看它是从哪里来的,它的意义是什么。
- 表格右侧的三列表示事件的分组。在下面的截图中,可以看到第一行属于协议 TCP 中的组序列( 1 )。下一行属于组协议。协议是 RPC 浏览器( 2 )。最后标记的事件属于一个序列组;协议是 IPv4 ( 3 )。该组保存来自同一类别的事件,例如,涉及序列参数的序列事件,并且它指示事件发生在哪个协议上。
它是如何工作的…
专家信息窗口是一个专家系统,它为我们提供有关网络问题的信息,在某些情况下还提供可能的原因建议。虽然它给出了合理的结果,但总是要验证它的发现。
在有些情况下,Wireshark 发现的问题并不是真实的问题,反之亦然,在有些情况下,Wireshark 不会显示存在的真实问题。
不要忘记,最好的故障排除工具是你的大脑(和你的网络知识!).Wireshark 是一个非常智能的工具,但它仍然只是一个工具。
可能是您在数据传输期间开始了捕获,因此您会看到以前的数据段丢失消息或更复杂的问题。),您只捕获了部分数据。Wireshark 称它为完整的数据流,并向您显示许多错误。我们将在本书的后面看到这些问题的许多例子。
还有更多…
专家严重性也可以通过显示过滤器过滤并显示在数据包窗格中。要根据显示过滤器查看事件:
- 选择显示过滤器窗口右侧的表达式。
- 向下滚动以获得专家消息(您只需输入工作专家即可到达)。
- 如下图所示,您将获得以下过滤器—
expert.message
、expert.group
和expert.severity
:
前面的过滤器解释如下:
expert.group
指的是专家消息组,例如校验和错误组、序列组、格式错误组等。expert.message
是指特定的消息。例如,在这里,您可以配置一个过滤器来显示包含或匹配特定字符串的消息。expert.severity
是指具有特定严重性的消息,即错误、警告、注意等。
您也可以右键单击特定事件,如下图所示,您将看到以下菜单:
在这里,您可以:
- 选择引用此事件的显示过滤器并应用它
- 选择一个引用此事件的显示过滤器,并只准备它
- 在数据包窗格中找到特定的数据包
- 为事件配置着色规则
- 在互联网上查找事件信息
- 复制事件文本
请参见
- 第八章、以太网和局域网交换和协议章节
错误事件以及我们可以从中了解到什么
在这个菜谱中,我们将深入研究错误和事件类型、校验和错误、格式错误的数据包以及其他类型的错误。
做好准备
开始捕获,或打开现有文件并启动专家系统。
怎么做…
- 从分析菜单中,打开专家信息。窗口顶部列出了错误:
在前面作为示例提供的窗口中,您可以看到校验和错误;在这种情况下,可能是因为真正的错误或卸载。
- 单击特定错误会将我们带到数据包窗格,以查看数据包本身的错误。这在下面的截图中有所呈现:
您在此事件中看到的是校验和错误,并且校验和不正确。在这种情况下(文件CAP_07_05
),我们看到所有错误都来自单个器件,这是一个很好的起点,可以开始查看问题来自哪里。关于以太网和以太网错误的更多信息,请参见第 8 章、以太网和局域网交换。
它是如何工作的…
校验和是一种错误检查机制,它使用数据包中插入的一个字节或一系列字节来实现帧验证算法。错误检查算法的原理是计算整个消息(第 4 层)、数据包(第 3 层)或帧(第 2 层)的公式。他们将结果插入包内的字节中,当包到达目的地时,他们再次计算它。如果我们得到相同的结果,这是一个好的数据包,如果不是,有一个错误。可以在整个分组上或者仅仅在报头上计算误差校验机制;这取决于协议。
卸载机制是在将 IP、TCP 和 UDP 校验和传输到网络之前,在 NIC 上对其进行计算的机制。在 Wireshark 中,这些会显示为错误数据包,因为 Wireshark 会在数据包发送到网络适配器之前将其捕获;因此,它将看不到正确的校验和,因为它还没有被计算。
因此,尽管看起来像是严重的错误,但在许多情况下,校验和错误是 Wireshark 的错误配置。如果您在从您的 PC 发送的数据包上看到许多校验和错误,这可能是因为卸载。
要取消校验和验证:
- 对于 IPv4,当您看到许多校验和错误,并且您确定它们是由于卸载造成的,请转到编辑|首选项,然后在协议| IPv4 下,取消选中单选按钮:如果可能,验证 IPv4 校验和
- 对于 TCP,当您看到许多校验和错误,并且您确定它们是由于卸载造成的,请转到编辑|首选项,然后在协议| TCP 下,取消选中单选按钮:如果可能,验证 TCP 校验和
还有更多…
对于格式错误的数据包,这可能是 Wireshark 错误或真正的格式错误数据包。使用其他工具来隔离问题。可以在 Wireshark 网站上报告可疑的错误。
当您看到许多校验和错误的格式错误的数据包时,可能是因为卸载或解析器错误。任何种类的超过 1%-2%的错误的网络将导致许多其他事件(例如,重新传输),并且将变得比预期慢得多;因此,一个正常运行的网络不可能有高错误率!
请参见
- 第八章、以太网和局域网交换和协议章节
警告事件以及我们能从中了解到什么
如前所述,警告事件表明应用或通信中存在问题。在本食谱中,我们将描述这一类别中的主要事件。
做好准备
开始捕获,或打开现有文件并启动专家系统。
怎么做…
-
从分析菜单中,打开专家信息。
-
警告事件将从顶部第二个显示。如果没有错误事件,那么警告将排在第一位。你可以在下一张截图中看到一个例子(文件
CAP_07_04
):
您将在这里看到几个事件类别:
- 有关特定事件的详细信息,请右键单击该事件,然后选择查找。这将把你带到互联网上的相关页面。
它是如何工作的…
Wireshark 监视被监控数据包的参数:
- 它监视 TCP 窗口大小,并检查窗口大小是否减小到零
- 它会查找乱序的 TCP 数据包(数据段),即它们是在预期时间之前还是之后发送的
- 它查找未发送的 TCP 数据包的 ack
这些参数以及许多其他参数为您提供了查找网络问题的良好起点。我们将在第十一章、传输层协议分析中了解它的细节。
还有更多…
不要忘记,警告事件是 Wireshark 指的非关键事件,但不是协议的正常行为。在这里,你有这样的事件:
- TCP 重置:它们是 TCP 协议的一部分,但是连接应该以 TCP FIN 而不是 TCP 重置结束。因此,在这种情况下,这可能是由于一个问题,或者只是因为 TCP 开发人员选择了以这种方式关闭连接。
- TCP 零窗口:对连接上的慢端设备的指示;这里我们看到了协议的另一种行为,这可能是由于连接的一端出现了问题,但这仍然是 TCP 的工作方式。
像未知标题、BER 错误:标记类型中的错误标记等消息。这些消息表明数据包结构中存在问题。就像各种错误和事件一样,重要的是理解它,而不是类别或颜色。
请参见
- 第八章、以太网和局域网交换和协议章节
记录事件以及我们能从中了解到什么
如前所述,当 Wireshark 指出某个事件可能会导致问题,但仍在协议的正常行为范围内时,该事件将属于注释类别。例如,TCP 重新传输将显示在注释栏下,因为即使它是一个使网络变慢的关键问题,但它仍在 TCP 的正常行为下。
做好准备
开始捕获,或打开现有文件并启动专家系统。
怎么做…
- 从分析菜单中,打开专家信息。
- “注释”事件在“专家信息”窗口中从顶部数第三个出现:
您将在这里看到几个事件类别:
其他事件将在相关的 TCP 和应用章节中讨论。
发现广播和错误风暴
通信网络中最常见和最麻烦的问题之一是广播/多播和错误风暴。发生这些问题的原因可能是第 2 层环路、基于第 2 层的攻击、有问题的网络适配器或向网络发送数据包的应用或服务。在这一章中,我们将提供一些基本的方法来发现、隔离和解决这些类型的问题。
广播/组播风暴是指你每秒钟收到几千甚至几万个这样的数据包。在大多数情况下,它会耗尽带宽并完全锁定网络。
它是如何工作的…
Wireshark 监视被监控数据包的参数:
- 它监视 TCP 序列号和确认号。它检查重新传输以及其他排序问题。
- 它寻找来自远程网络的值为 1 的 IP 生存时间,并告诉你这是一个问题。
- 它寻找保活;这可能是正常情况,但也可能表示有问题。
这些参数以及许多其他参数为您提供了一个寻找网络性能问题的良好起点。
还有更多…
这里看到的许多症状可能是几种问题的征兆。例如,由于错误导致数据包丢失,或者由于恶劣的网络条件(低带宽或高延迟)导致数据包不能按时到达,数据包可能会被重新传输。也可能是因为服务器或客户端没有响应。专家信息系统会给你症状。怎么解决问题?我们将在本书的后面学习。
请参见
- 第八章、以太网和局域网交换和协议章节
八、以太网和局域网交换
在本章中,我们将讨论以下主题:
- 发现广播和错误风暴
- 分析生成树协议
- 分析 VLAN 和 VLAN 标记问题
介绍
在本章中,我们将重点讨论如何发现和解决基于第 2 层的问题,重点是基于以太网的问题,如广播/组播事件、错误以及如何找到问题的根源。我们还将关注 LAN 协议,如生成树和 VLAN。
这些问题需要在我们进入第 3 层、第 4 层和应用层之前解决,因为第 2 层的问题会反映在上层协议中。例如,第 2 层中的数据包丢失将导致 TCP(第 4 层协议)中的重新传输,并导致应用变慢。
做好准备
当出现这些问题时,您通常用来解决问题的网络会非常慢,或者已经停止工作。?
需要记住的一些重要事实:
- 路由器不会转发广播。
- 广播不在 VLAN 之间转发(这就是 VLAN 被称为广播域的原因),所以每个 VLAN 本身就是一个广播域。
- LAN 交换机不会转发错误数据包,例如 CRC 错误的数据包、小于最小 64 字节的数据包等等。
- 除非另行配置,否则组播通过交换机转发。
- 仅当路由器被配置为这样做时,组播才通过路由器转发。
- 每个网络都传输合理数量的广播。这就是网络的工作方式,但是高比率的广播/组播可能是一个问题。
- 广播/组播被转发到交换机或路由器的控制平面/CPU,如果它被配置为这样做或启用了第 3 层功能。这可能导致操纵面不稳定(例如,OSPF 邻接襟翼)。
广播太多和广播风暴是有区别的。太多的广播(例如,每秒几百次)会使网络负载过重,但在大多数情况下,用户不会注意到。广播风暴会完全封锁网络。确定网络中广播数据包百分比的基线非常重要,以便在故障排除过程中用作数据点。
怎么做…
要找出问题的来源,请执行以下步骤:
- 由于网速慢是用户感觉到的一个问题,所以先问以下问题:
- 这个问题是在总部还是在某个分支机构?
- 这是通过网络还是在特定的 VLAN?
- 这是在大楼上方还是在特定楼层?
当然,不要问用户关于 VLANs 的问题;用户不是网络专家。询问他们在他们的小组、部门等中运行的应用,以了解问题的范围。
在一个组织网络中,VLAN 通常将按部门(或几个部门)和按地理区域(或几个区域)甚至按组织功能来配置;例如,人力资源 VLAN、财务 VLAN、特定软件的用户 VLAN 等等。通过询问问题是否与这些角色之一有关,你将能够缩小到你需要寻找问题的区域。
- 下一个问题应该是一个微不足道的问题:网络还在工作吗?在广播/组播风暴中,网络会变得非常慢;在大多数情况下,应用将停止运行。在这种情况下,您会遇到以下典型问题:
- 生成树问题
- 产生广播的装置
- 路由环路(在第 10 章、网络层协议和操作中讨论)
我经常被问到的问题是:多少次广播才算多?
这个问题当然有几种答案。这取决于网络设备在做什么,以及在这些设备上运行的协议。
合理的广播次数应该是每分钟每台设备 1-2 次到 4-5 次。例如,如果您的网络是由一台 VLAN 上的 100 台设备构建而成,则每秒钟的广播次数不应超过 5-10 次(5 次广播 x 100 台设备每分钟可广播 500 次,即每秒大约 9-10 次)。只要它们不是成千上万、来源不明,超过这个数字也是合理的。
生成树问题
在生成树问题中,你会得到每秒数千甚至数万次广播(参考*它是如何工作的…*本食谱中的一节知道为什么)。在这种情况下,您的 Wireshark,可能还有您的笔记本电脑,将会冻结。关闭 Wireshark,开始断开冗余电缆以隔离问题(几乎使网络层 2 环路空闲),并检查交换机中的 STP 配置。
产生广播的装置
特定设备产生的典型广播风暴具有以下特征:
- 每秒大量的广播(数千甚至更多)
- 在大多数情况下,广播将来自单一来源;但是在攻击的情况下,它们可能来自多个来源
- 通常以恒定的包/秒速率,即帧之间的间隔几乎相等
让我们看看如何根据前面列表中提到的参数在接下来的三个截图中找到广播风暴。
在下面的屏幕截图中,我们看到大量广播数据包从源 MAC(惠普网络适配器)发送到ff:ff:ff:ff:ff:ff
:
图 8.1:广播泛滥
如前面的屏幕截图所示,time 列以秒为单位进行配置(这意味着两个连续数据包的时间戳之间的差值将以秒为单位进行报告)。您可以通过导航至视图|时间显示格式进行配置。
可以通过导航到统计| IO 图来查看数据包的速率。下面的屏幕截图显示广播数据包的速率为每秒 5,000 个数据包:
图 8.2:广播泛洪:I/O 图
通过导航到统计|对话选项,我们可以从以太网、IPv4、TCP/UDP 的角度查看设备之间的对话。在以下屏幕截图的上半部分,我们可以看到两个 MAC 地址之间的大量广播,而屏幕截图的下半部分报告了相同的转换,但从 IPv4 地址的角度来看。总之,在 18 秒的持续时间内捕获了 87,142 个广播数据包。
图 8.3:广播泛滥:对话
在前一个案例中,问题是由一个叫做 SMB 邮件槽协议的服务引起的。简单的试错法找出这项服务是什么,并在电台上禁用它,解决了广播风暴问题。
注意这一点很重要:当您禁用一个服务(尤其是属于操作系统的服务)时,请确保系统继续运行并保持稳定。在核实之前不要离开现场!
此外,我建议您再次运行 Wireshark,以确认没有看到广播泛滥。
固定模式广播
您还可以按固定模式进行广播,例如,每隔固定时间进行一次广播,如下图所示:
图 8.4:固定模式广播
该图针对 1 分钟的刻度间隔(在 X 轴下)和以下过滤器进行了配置:
- 网络中所有广播的红色过滤器(
eth.addr ==ff:ff:ff:ff:ff:ff
) - ARP 请求广播的绿色过滤器(
arp.opcode ==1
)
我们在这里看到的是,大约每 5 分钟就有一次 ARP 请求的爆发(绿点)。如果我们单击图中的一个点,它会将我们带到捕获窗格中的数据包。
在下面的屏幕截图中,我们看到了每 5 分钟发生一次的扫描模式:
图 8.5: ARP 扫描
我们可以看到,扫描内部网络的是 d-link 路由器(基于源 MAC 地址)。这可能是好的也可能是坏的,但是检查我们的网络中正在运行什么是好的。
它是如何工作的…
IPv4 网络中的广播非常常见,这些第 3 层广播将通过第 2 层广播发送。每当第 3 层设备向网络发送广播(目的地是子网的广播地址;参见第 10 章、网络层协议和操作,了解更多信息),它将被转换为所有 fs 目的 MAC 地址。
您将在基于 IP 的网络中看到几类广播。其中一些如下:
- 基于 TCP/IP 的网络协议,如 ARP 请求、DHCP 请求等
- 网络协议,如 NetBIOS 名称服务 ( NBNS )查询、 NetBIOS 服务器消息块 ( SMB )公告、网络时间协议 ( NTP )等
- 发送广播的应用,如 Dropbox、Microsoft 网络负载平衡等
在 IPv6 中,我们没有广播,但是我们有单播、多播和任播。由于该协议与发现机制、公告和其他机制的多播一起工作,我们将会看到很多这样的机制。
还有更多…
我在许多情况下遇到的一个问题是如何在局域网交换机中使用广播和多播风暴控制定义(Cisco 设备中的风暴控制广播级别**【高级】【低级】**命令)。问题是,在许多情况下,我看到的配置将广播次数限制在每秒 50、100 或 200 次,而这还不够。在网络中,您可以安装一个软件,向网络发送跨越这些值的广播或组播。然后,根据您在交换机中的配置,它将开始向管理系统发送陷阱,生成系统日志消息,甚至断开端口(Cisco devices 中的风暴控制操作 {shutdown | trap} 命令)。
解决这个问题的方法是简单地配置高等级的广播作为阈值。当一场广播风暴发生时,你会得到成千上万的广播;因此,配置每秒 1,000 到 2,000 次广播或多播的阈值水平,可以为您提供相同的保护级别,而不会对正常的网络操作造成任何干扰。
如果您对风暴控制的高阈值水平不满意,那么您应该审核网络流量,以确定终端站在高峰工作时间发送广播的速率,并使用该数据来设置适当的阈值。
请参见
- 有关 IPv4 的更多信息,请参见第 10 章、网络层协议和操作
分析生成树问题
我们都用过,或者至少听说过生成树协议 ( STP )。我之所以称这个方法为分析生成树问题是因为它有三个主要版本,如下所示:
- STP:这是 1998 年的 IEEE 802.1D 标准,称为 802.1D-1998
- 快速生成树协议(RSTP) :这是 2001 年的 IEEE 802.1W 标准,后来添加到 802.1D 中,称为 802.1D-2004
- 多生成树(MST) :这最初是在 IEEE 802.1S 中定义的,后来合并到 IEEE 802.1Q 中
还有一些思科和其他厂商的专有版本。在本菜谱中,我们将重点介绍标准版本,并学习如何解决在 STP/RSTP/MST 作业中可能出现的问题。
做好准备
发现 STP 问题的最佳方法是登录到 LAN 交换机,使用供应商的命令(例如,Cisco IOS 或 Juniper JUNOS CLI)来发现并修复问题。如果您在网络设备上正确配置了 SNMP,您将在管理控制台上获得所有消息,除非 STP 问题以某种方式导致交换机与管理系统通信出现问题。
本指南的目的是展示如何使用 Wireshark 来实现这一目的,尽管我们仍然建议将其作为实现这一目的的二线工具。因此,只需打开您的笔记本电脑,启动 Wireshark,并开始捕获局域网上的数据。
怎么做…
关于 STP,网络中有几点需要注意:
- 网络上运行的是哪个 STP 版本?
- 拓扑结构有变化吗?
网络上运行的是哪个 STP 版本?
Wireshark 将通过查看网桥协议数据单元(bpdu)为您提供网络上运行的 STP 类型(STP、RSTP 或 MST)的版本。BPDUs 是在交换机之间组播的更新帧。
协议版本有:
- 对于 STP,协议版本 ID 等于 0
- 对于 RSTP/MST,协议版本 ID 等于 3
在标准中,你不会发现开关这个词;它将永远是网桥或多端口网桥。在本书中,我们将使用术语网桥和交换机。
拓扑变化太多了吗?
当您监控 STP 运行时,您可能会担心许多拓扑变化。拓扑变化在 STP 中是正常的,但是过多的拓扑变化会对网络性能产生影响,因为它可能会导致 MAC 地址老化,从而导致未知的单播泛洪。
当新设备连接到网络或从网络断开时,就会发生拓扑变化。您可以在下面的屏幕截图中看到拓扑变化:
图 8.6: STP:拓扑变化
当您看到过多的拓扑变化时,连接到不支持 STP 的主机(通常是用户频繁开关电源的终端站)的 LAN 交换机端口应配置端口快速功能(适用于 Cisco 交换机;对于其他供应商,请查阅供应商手册)。
在旧的 STP (IEEE 802.1d)中,将设备连接到交换机端口后,交换机大约需要一分钟来启动和转发数据包。当客户端试图在这段时间内登录到网络服务器,或者通过 DHCP 请求 IP 地址时,这可能是一个问题。端口快速功能强制端口在几秒钟内(通常是 8 到 10 秒)开始转发,以防止这类问题。
如果拓扑结构继续变化,请检查问题可能是什么以及是谁造成的。请注意,尽管大多数拓扑变化源自连接到终端站的端口,但也可能是由于两台交换机之间的链路抖动造成的。
它是如何工作的…
STP 可以防止局域网中出现环路。如果您使用多种连接方式连接两台或更多交换机,可能会发生环路,如下图所示:
图 8.7:生成树:环路是如何形成的
让我们看看循环是如何创建的:
- 站 A 向网络发送广播。广播可以是 ARP、NetBIOS 或任何其它目的 MAC 地址中全是 fs 的数据包。
- 由于广播被转发到交换机的所有端口, SW1 从端口 1 接收广播,并将其转发到端口 2 和 3。
- SW2 和 SW3 将把数据包转发到它们的其他端口,这些端口将把它们送到 SW4 的端口 2 和 3 。
- SW4 将来自端口 2 的数据包转发到端口 3 ,来自端口 3 的数据包转发到端口 2 。
- 我们将得到两个无休止循环的数据包——一个已被转发到端口 3 (红色箭头)和一个已被转发到端口 2 (绿色箭头)的 SW1 。
- 根据交换机转发速度的不同,我们会得到多达数万个数据包,这些数据包会完全阻塞网络。
STP 通过简单地构建树形拓扑,即定义无环拓扑来防止这种情况发生。在出现故障的情况下,链路被断开并恢复服务。
在下图中,我们可以看到我们最初是如何通过多个连接来连接所有交换机的,以及 STP 是如何创建树的:
图 8.8:生成树:原始拓扑与树形拓扑
BPDUs 是使用第 2 层组播在 LAN 交换机之间交换的更新帧。首先,在以太网层,如下面的屏幕截图所示,数据包将从发送更新的交换机的源 MAC 进行组播:
图 8.9:生成树源和目的 MAC 地址
BPDU 由以太网 802.3 帧承载,其格式如下图所示:
图 8.10:生成树 BPDU 以太网帧格式
在下表中,您可以看到 STP 帧中的字段:
| 字段 | 字节 | 什么事? | 值 | 显示过滤器 |
| 协议 ID | Two | 协议标识符 | 总是 0 | stp.protocol
|
| 版本 | one | 协议版本 | 对于 STP = 0 对于 RSTP = 2 对于 MST = 3 | stp.version
|
| 消息类型 | one | BPDU 类型 | 对于 STP = 0 对于 RSTP = 2 对于 MST = 2 | stp.type
|
| 旗帜 | one | 协议标志 | 在上图中 | stp.flags
|
| 根 ID | eight | 根标识符(根 ID),即与网桥硬件地址(MAC)连接的网桥优先级 | 根桥的 MAC 地址 | stp.root.prio
、stp.root.ext
和stp.root.hw
|
| 根路径开销 | four | 到根交换机的路径开销 | 由生成树计算的路径开销。如果这是根,路径开销将为零。 | stp.root.cost
|
| 网桥 ID | eight | 网桥标识符(网桥 ID),即与网桥硬件地址(MAC)连接的网桥优先级 | 网桥 MAC 地址 | stp.bridge.prio
、stp.bridge.ext
和stp.bridge.hw
|
| 端口 ID 2 | Two | 端口标识符 | 发送更新的端口的标识符 | stp.port
|
| 信息时代 | Two | 消息年龄字段指示自从网桥发送当前配置消息所基于的配置消息以来已经过去的时间量 | 对于每个 BPDU,发送帧的网桥发送一个值 0,每个网桥增加 1 转发它 | stp.msg_age
|
| 最大值时间 | Two | 最大年龄,即帧可以在网络中停留的最长时间(实际上是网桥的数量) | 通常 20 秒 | stp.max_age
|
| 你好时间 | Two | BPDUs 之间的时间 | 通常是 2 秒 | stp.hello
|
| 向前延迟 | Two | 转发延迟字段指示拓扑变化后,网桥在转换到新状态之前应该等待的时间长度 | 通常 15 秒 | stp.forward
|
注意,在 MST 的情况下,将为 MST 参数添加一个额外的头。
港口国
在 STP 中,端口状态如下:
- Disabled :在这种状态下,没有帧被转发,也听不到 BPDUs
- 阻塞:在这种状态下,没有帧被转发,但是 BPDUs 被监听
- 监听:在这种状态下,没有帧被转发,但是端口监听帧
- 学习:在这种状态下,没有帧被转发,但是 MAC 地址被交换机学习
- 转发:在这种状态下,帧被转发,MAC 地址被交换机学习
当您将设备连接到 LAN 交换机时,端口会经历这些阶段,所需时间如下:
- 从屏蔽到监听需要 20 秒
- 从听到学需要 15 秒
- 从学习到转发需要 15 秒
在 RSTP 和 MST,港口州如下:
- 丢弃:在这种状态下,帧被丢弃
- 学习:在这个帧中,没有帧被转发,MAC 地址被捕获
- 转发:帧被转发,MAC 地址被捕获
根据网络拓扑和复杂性,从丢弃到转发的整个端口状态转换应该需要几秒钟。
还有更多…
对于生成树调试,最好的方法是从直接连接到 LAN 交换机的连接中获取数据。一个配置良好的管理系统 SNMP 陷阱也有助于完成这项任务。
STP 数据包的一些示例如下:
在下面的截图中,您可以看到一个 STP 帧。你可以看到源 MAC 地址是一个北电地址,在 BPDU 本身中,根和网桥标识符是相等的;这是因为发送数据包的网桥是根网桥。端口 ID 是8003
,在北电交换机中表示端口号 3。
图 8.11:从根交换机生成 BPDU 树
在下面的截图中,你可以看到一个快速的 STP BPDU。您可以看到,协议标识符等于 2,端口状态为指定状态。
图 8.12:生成树 BPDU 参数
在前面的截图中,您可以看到 MST 的示例。在这里,我们看到 MST 扩展紧跟在标准 STP 帧之后。
图 8.13: MST BPDU 和扩展
分析 VLAN 和 VLAN 标记问题
VLAN,即虚拟局域网,是一种将局域网划分为独立局域网的机制,即使它们共存于同一物理基础设施中,它们之间也没有任何直接通信,这就是虚拟这个名称的由来。在本节中,我们将了解监控 VLAN 流量的方法。
本指南的目的是向读者简要介绍如何使用 Wireshark 解决 VLAN 问题。解决相关问题的一个更简单的方法是使用供应商的 CLI (Cisco IOS、Juniper JUNOS 等)来实现此目的。
做好准备
在本食谱中,我们将讨论两个问题:
- 如何监控 VLAN 内的流量?
- 如何查看通过 VLAN 标记端口的标记帧?
在第一种情况下,需要简单的配置。在第二种情况下,有一些要点需要注意。
在 VLAN 上捕获时,您不一定会看到数据包中的 VLAN 标签。您是否会看到 VLAN 标签的问题实际上取决于您正在运行的操作系统,以及您的网络接口卡 ( NIC )和 NIC 驱动程序是否支持该功能。
您的操作系统和网卡是否支持 VLAN 标记完全取决于操作系统和网卡供应商。去供应商的手册或谷歌上找答案。
在下图中,您可以看到带有 VLANs 的典型拓扑。上层交换机通过两条中继(标记以太网帧的端口)连接到下层交换机。在此网络中,您有 VLANs 10、20 和 30,而连接到每个 VLAN 的 PC 将无法看到来自其它 VLAN 的 PC。
图 8.14: VLAN 标签
怎么做…
将 Wireshark 连接到您要监控的交换机。让我们看看前面的配置(如上图所示)。
监控 VLAN 内的流量
为了监控整个 VLAN 的流量:
- 将您的笔记本电脑连接到中央交换机和其中一个端口。
- 配置从受监控的 VLAN 到您所连接的端口的端口镜像。例如,如果您将笔记本电脑连接到 SW1 端口 4 ,并且您想要监控来自 VLAN10 的流量,命令将会是(在 Cisco 中):
Switch(config)#monitor session 1 source vlan 10
Switch(config)#monitor session 1 destination interface fastethernet0/4
这将显示从 VLAN10 通过中央交换机 SW1 转发的流量。
有关如何在各种供应商网站上配置端口镜像的更多信息,请搜索 SPAN(在 Cisco 中)、port mirror 或 mirroring (HP、Dell、Juniper 等)。在监控刀片中心的流量时,通常只能监控物理端口上的流量;但是,有些应用使您能够监控刀片式服务器上特定服务器的流量(例如,Cisco Nexus 1000V)。
查看通过 VLAN 标记端口的标记帧
监控标记的流量不是一项简单的任务。使用 Wireshark 捕获数据时是否会看到 VLAN 标签取决于您的网络适配器、运行该适配器的驱动程序以及它们对 VLAN 标签的处理。
验证您的笔记本电脑能否捕获标记帧的最简单方法如下:
- 开始用端口镜像捕获标记的端口。如果您看到标签,请继续工作。
- 如果您没有看到任何标签,请转到适配器配置。在 Windows 7 中,您可以通过单击开始,然后导航到控制面板|网络和互联网|查看网络状态和任务|更改适配器设置|本地连接。接下来,执行以下屏幕截图中所示的步骤:
图 8.15:启用优先级和 VLAN
配置适配器的优先级并禁用 VLAN。这将移动 WinPcap 驱动程序和 Wireshark 的标记
在前面的截图中,我们看到了一个带有 Realtek 网卡的联想笔记本电脑示例。该图给出了一个流行设备上的示例,但在其他笔记本电脑或服务器上可能会有所不同。原理应该是一样的:通过提取 VLAN 标签禁用适配器,以便它将被转发到 WinPcap 驱动程序并呈现在 Wireshark 上。
它是如何工作的…
标签是添加到数据包中的小段数据,目的是向数据包中添加 VLAN 信息。标签是一个 4 字节长的字符串(32 位),如下图所示。大多数网络适配器及其驱动程序会简单地将 VLAN 标签传递给上层来处理它们。在这些情况下,Wireshark 会看到 VLAN 标签并显示出来。在更复杂的适配器和驱动程序中,VLAN 标签将由适配器本身处理。这包括一些最常见的英特尔和 Broadcom 千兆位芯片组适配器。在这些情况下,您必须禁用 VLAN 功能。
图 8.16: VLAN 标记和网络适配器
在配置网卡驱动程序时,为了确保它不会处理 VLAN 标签,数据包将被简单地转发到 WinPcap 驱动程序并由 Wireshark 显示。
图 8.17: VLAN 标签
在下面的屏幕截图中,您可以看到一个标记帧的示例;该帧标有 VLAN ID = 20
:
图 8.18:带有 VLAN 标签的数据包
还有更多…
Wireshark 也将捕获双标签,就像 802.1ad 标准一样。这些标签被称为服务标签,添加在服务提供商边缘,以便区分提供商和客户标签。提供商标签称为 S 标签(802.1ad),客户标签称为 C 标签(802.1Q)。它也被称为 QinQ 机制。
请参见
- 有关 WinPcap 的更多信息,请访问 WinPcap 主页,网址为http://www.winpcap.org/
- 有关 UNIX/Linux 库的更多信息,请参考位于http://www.tcpdump.org/的 tcpdump 主页
九、无线局域网
在本章中,我们将了解:
- 无线网络和标准简介
- 无线电问题、分析和故障排除
- 捕获无线局域网流量
学到的技能
本章结束时,读者将能够分析无线局域网流量,并诊断用户报告的连接和性能问题。
无线网络和标准简介
无线网络在过去十年中变得非常流行,现在它是我们的小工具保持连接所需的最重要的连接之一。概括地说,无线网络可以有以下几种类型:
- 无线个人区域网(WPAN) :无线设备之间的距离在 5-10 米之内,可以临时搭建
- 无线局域网(WLAN) :无线设备之间的距离不超过 100 米
- 无线城域网(WMAN) :无线设备之间的距离不超过 100 米,距离不超过 5 公里(3.1 英里),通常覆盖郊区或城镇
图 9.1:无线网络的类型
让我们快速浏览一下各种 WLAN 标准。自 20 世纪 90 年代中期以来,IEEE 802.11 委员会一直在开发无线局域网标准,并已发布了从 802.11b 到 802.11ac 的若干标准,如下所示:
| 标准 | 802.11b | 802.11a | 802.11g | 802.11n | 802.11ac |
| 年 | One thousand nine hundred and ninety-nine | One thousand nine hundred and ninety-nine | Two thousand and three | Two thousand and nine | Two thousand and thirteen |
| 频率 | 2.4ghz | 5 千兆赫 | 2.4ghz | 2.4 / 5 千兆赫 | 5 千兆赫 |
| 通道数量 | three | <=24 | three | 动态的 | 动态的 |
| 传输技术 | DSSS | 正交频分多路复用技术(Orthogonal Frequency Division Multiplexing 的缩写) | DSSS /正交频分复用 | 正交频分多路复用技术(Orthogonal Frequency Division Multiplexing 的缩写) | 正交频分多路复用技术(Orthogonal Frequency Division Multiplexing 的缩写) |
| 数据速率(Mbps) | 1, 2, 5.5, 11 | 6, 9, 12, 18, 24, 36, 48, 54 | 6,9,12,18,24,36,48,54 - OFDM | <= 450 | 1300(第一波),6930(第二波) |
了解 WLAN 设备、协议和术语
了解无线电基础知识和各种 WLAN 设备非常重要,这样有助于了解用户报告的问题并排除故障。
接入点
无线 LAN 网络基于接入点(AP)——允许无线站/设备(称为 STA)连接到它并进而连接到有线网络的硬件。AP 通常连接到上游交换机/路由器。
无线局域网控制器(WLC)
一个无线局域网控制器 ( WLC )是一个硬件,它使用 IEEE CAPWAP(无线接入点的控制和供应)协议与大量轻量级接入点进行通信和管理,该协议基于思科的轻量级接入点协议 ( LWAPP )。CAPWAP 在接入点和控制器之间传输控制流量(DTLS 加密)和数据流量(DTLS 加密可选)。
AP 可以以独立模式或集中模式部署。
- 单机:顾名思义,这种模式下,AP 是单独部署和维护的。这是中小型企业中最常见的部署类型,只需要几个接入点。
图 9.3:独立模式下的无线接入点
- 集中式:在这种模式下,大量接入点由无线局域网控制器管理其设备配置、安全/策略设置、软件/固件更新等。AP 和控制器之间的连接可以通过第 2/3 层网络。如前所述,接入点由使用 CAPWAP 协议的无线控制器管理,该协议处理数据和控制流量。
图 9.4:集中模式下的无线接入点
对无线局域网设备有了基本的了解后,让我们再来看几个无线领域中使用的术语:
- STA: 使用服务的无线站或客户端
- AP :为客户端提供无线服务的设备
- DS:分布,连接接入点的局域网
- BSS : 基本服务集 ( BSS ),或者具有相同媒体特性(例如,射频和调制方案)的无线设备单元
- ESS : 扩展服务集 ( ESS ),或同一逻辑网段内基本服务集的逻辑单元(如 IP 子网和 VLAN)
为了更好地理解这些术语,请参考下图:
图 9.5:无线局域网分布和服务集
无线电问题、分析和故障排除
做好准备
当用户抱怨 Wi-Fi 网络没有连接或连接很差时,请带着您的笔记本电脑尽可能靠近用户的位置,并验证您是否有 Wi-Fi 网络。
怎么做…
要找出问题的来源,请执行以下步骤:
- 用户的无线连接很差还是完全没有连接?
- 无线连接性差的问题是出现在楼层/建筑的不同部分,还是只出现在楼层/建筑的特定部分?
零无线连接
如果用户的连接为零,则访问并检查覆盖受影响区域的接入点(以独立模式运行)的状态和运行状况。
如果 AP 由控制器集中管理,那么它们的用户界面(GUI)应该提供检查 AP 的状态、它们的健康状况,特别是它们提供服务的 SSIDs 的方法。从下面的屏幕截图中,我们可以看到 Cisco 无线控制器报告了 AP 的数量、它们的正常运行时间等等。
图 9.6:思科无线控制器接入点列表和状态
请注意,接入点发现控制器、加入无线域和下载配置/策略有一个过程。我建议参考特定供应商的故障排除文档来诊断和解决问题。
如果控制器的用户界面中缺少 AP,则它们之间可能存在连接问题。通过数据包捕获排除接入点和控制器之间的连接问题与排除网络中两台电脑之间的连接问题是一样的。
请注意,并非所有 SSIDs 都由 AP 广播。因此,如果用户抱怨看不到特定的 SSID,这可能是由于 AP 没有广播它们。如果是这样,那么尝试使用用户名/密码凭证手动加入特定的 SSID。
无线连接不良或断断续续
如果用户报告间歇性连接和性能不佳,请执行以下步骤。
基本工具就在笔记本电脑中(正如我们在下面的屏幕截图中所看到的),在那里您有第一个指示:
- 信号强度,也称为接收信号强度指标()
*** 接入点 ID,即服务集标识 ( SSID )* 使用的安全协议* 无线电类型(802.11n,如截图所示)**
**
图 9.7:电脑中的 Wi-Fi 网络和细节
一旦确认用户所在位置有合适的 Wi-Fi 网络,请使用专用软件(例如,免费版的 Acrylic Wi-Fi、Windows 版的 Homedale、Apple Mac 版的 NetSpot 或 macOS 无线诊断工具)。因此,您会发现可用的网络、信号强度、信道、链路质量以及更多细节。这将提供当地可用 Wi-Fi 网络的概况,以及可能的频率干扰、干扰和无线电问题。一些软件还提供了在特定时间内监控信号质量的选项。
RSSI 等级表明数字越高,强度越低:
- -60 dBm 及更好的:这表示良好的信号水平
- -80 dBm 到-60 dBm :表示合理的信号电平
- -80 dBm 到-90 dBm :这表示信号电平很弱
- -90 dBm 及以下:表示信号非常微弱
图 9.8:丙烯酸的 Wi-Fi 网络、RSSI 水平和速度
如果你有 RSSI 在合理的范围和以上,接收水平通常是足够的,你应该寻找频率干扰和其他无线电问题。信噪比 ( SNR )是重要参数之一;它提供了环境中信号功率和噪声功率之间的比率。
我通常应用于无线网络设计的一个经验法则是,对于标准的企业应用,我需要 75 dBm 或更好;对于也应该用于 VoIP 的无线网络,我要求-65 dBm 或更好。
如果你想检查是否有任何干扰,你可以使用软件,将发现 RSSI 随着时间的推移,它会给你一个更准确的图片你的网络。在下面的截图中,你可以看到一个叫做的软件。它让您更准确地了解哪些接入点正在工作及其详细信息。
图 9.9:来自 inSSIDer 的 RSSI 随时间的变化
试着找出以下问题:
- 不同的接入点在同一区域的同一信道上工作
- 低信噪比,出现在 RSSI 较低(通常低于-90 dBm)和/或噪声较高时
802.11 网络运行在 2.4 GHz ISM(工业、科学和医疗)频段,无需许可。因此,由于来自各种设备(如无线摄像机、微波炉、无绳电话/耳机、无线游戏控制台/控制器、运动检测器甚至荧光灯)的传输,它非常拥挤。
图 9.10: 802.11 干扰
机场、海港和军事区等区域可能会出现频率干扰。下一步是使用频谱分析仪来检查哪些频率在您的地区使用。频谱分析仪可从各种供应商处获得,如 Fluke Networks、Agilent 和 Anritsu。
Wireshark 可用于分析 Wi-Fi 控制帧。首先要寻找的是 AP 是否正在发送信标帧,并且它们也在无线站被接收。在下面的截图中,您可以看到这些帧:
图 9.11:接入点发送的信标帧
AP 周期性地发送信标帧来宣告其存在、SSID、使用的安全方法等等,以及时间戳。
无线站/设备持续扫描所有 802.11 无线电信号并监听信标,以确定要关联的最佳接入点和无线网络。这些站确认信标,以便注册到 AP 和特定的 SSID。
无线站还可以发送探测请求帧来发现附近的接入点,这些接入点将使用探测响应帧进行响应,以提供进一步的信息。
在识别出首选无线网络并确认信标帧后,将启动一个标准的 DHCP 过程,如第 10 章、网络层协议和操作中所述。** **# 捕获无线局域网流量
捕获选项
如果您试图捕获运行 Wireshark 的无线站与网络中其他有线/无线机器之间的流量,并且只对常规网络数据感兴趣,而对 802.11 控制数据包或无线电/链路层信息不感兴趣,那么您不必做任何特殊的事情。只需打开 Wireshark,选择您感兴趣的特定无线接口,应用必要的过滤器,并以混杂模式运行它。
使用 Wireshark,如果您想要捕获无线站内运行的不同进程之间的流量,则应该在环回接口上进行捕获。
如果您试图捕获不仅发送到运行 Wireshark 的无线站或从运行 Wireshark 的无线站发送的流量,而且还捕获网络中不同无线设备之间的流量,并且如果您对 802.11 控制数据包或无线电/链路层信息感兴趣,那么您必须通过启用监控模式来实现,如下所示(Wireshark 版本 10.6,运行在 Apple macOS Sierra 10.12.6 上)。这种类型的捕获通常被称为空中 ( OTA )数据包捕获。
图 9.12: Wireshark 接口捕获选项
请注意,Wireshark 提供有限的功能来执行 OTA 数据包捕获;一些商业工具和应用可用于提供更全面的监控和故障排除功能和特性。
在基于 Unix 的操作系统和 Apple macOS (10.6 或更高版本)中,有一些内置工具,如airportd
、airport 实用工具、无线诊断和 tcpdump,可以用来捕获和分析无线数据包。
做好准备
对捕获流量的可用选项有了基本的了解后,让我们来讨论基站成功关联到无线网络以及访问网络服务/数据的步骤:
- 无线站从 AP 接收信标帧和/或与 AP 交换探测请求和响应以获得关联。
- 关联成功后,工作站将通过身份验证过程并获得许可。
- 基于网络策略为无线客户端提供 IPv4/v6 地址。
- 在 web 身份验证过程中,用户同意无线服务提供商的条款和条件。根据提供商的不同,此步骤可能是可选的。
通过上述步骤,网络中会出现许多问题;它们可能会阻止站点成功地与无线网络关联并访问数据。在这里,我们将研究一些非常常见的问题:
- 没有加入特定 SSID 的无线站
- 成功关联到 SSID 后,用户将无法进行身份验证
怎么做…
请回顾上一节—无线电问题、分析和故障排除—并确保没有无线电/链路层问题。
没有加入特定 SSID 的无线站
在监控模式下运行 Wireshark,使用适用的过滤器过滤无线站(正在进行故障排除的设备)发送和接收的流量。
如前几章所述,在给定的框架中找到感兴趣的字段,右键单击它,并选择 Apply as Column 以将该字段添加为列。例如,您可以添加数据速率、强度等,这将在故障排除过程中非常有帮助。
考虑一个场景,一个苹果无线设备刚刚被激活,加入是一个 SSID。正如您接下来看到的,无线设备发送一个探测请求,并从 AP 获得探测响应。使用的过滤器:(wlan.fc == 0x4000) or (wlan.fc == 0x5008)
:
图 9.13:探测请求和响应
请注意,探测请求是一个广播,目的地是所有 Fs mac 地址。
图 9.14:探测响应报头详细信息:无线电、AP 和 BSS
正如您在这里看到的,有效的探测响应将在 802.11 无线电信息报头中包含无线电/链路层信息,如频率、信道、SNR 等,在 802.11 探测响应报头中包含发射机和 BSS 信息。
下图显示了 SSID、支持的 Mbps 速率以及 802.11 无线 LAN 报头中的其他功能。确保所有信息看起来有效,并且与无线适配器兼容。
图 9.15:探测响应标头详细信息:SSID 和速率
得到响应后,无线客户端与 AP 服务的特定 SSID 相关联。如下所示,在探测请求和响应之后,客户端和 AP 交换一些消息来完成关联过程。
图 9.16:无线客户端和 AP 关联过程
如果您查看 AP 发送的最终关联响应帧中的 802.11 无线 LAN 报头,您应该会看到状态代码字段为成功。这表明客户端与特定的 AP 和 SSID 成功关联。
图 9.17:无线客户端和 AP 关联:状态代码
成功关联后用户无法进行身份验证
成功关联后,如果您看到客户端和 AP 之间交换了用户数据,则很可能没有实施安全策略。这在百货商店或酒店中很常见,在这些地方,客人可以在没有设备级认证的情况下访问无线网络。请记住,当用户打开浏览器时,可能会发生应用级别的身份验证,此时会要求用户提供用户名/密码凭据和/或接受条款和条件,以便继续使用无线服务。
在排除身份验证问题之前,让我们了解一下身份验证框架和各种方法。
可扩展认证协议 ( EAP )是当今部署中最流行的认证框架之一,并得到了各种厂商和无线客户端的广泛支持。该框架本身不是一种身份验证机制,它提供了常见的身份验证功能和协商,称为 EAP 方法。目前有 40 多种方法用于保护设备之间的通信,例如 LEAP、EAP-TLS、EAP-MD5、EAP-FAST、EAP-IKEv2 等等。
注:
- RFC5274 中定义了 EAP。早先它在 RFC3748 中被定义。
- RFC4017 中描述了专用于无线局域网的方法要求。
- 有关 EAP 数据包中使用的类型和代码,请参考 IANA EAP 注册表,链接如下:https://www . iana . org/assignments/EAP-numbers/EAP-numbers . XHTML。
- IEEE 802.1X 定义了 EAP over LAN 的封装,也称为 EAPoL。
请参考下面的截图,跟踪关联成功后发生的事件。
使用的过滤器:(wlan.da == 78:88:6d:43:90:ad or wlan.sa == 78:88:6d:43:90:ad) && (eapol.type == 0)
。这里,78:88:6d:43:90:ad
是无线客户端的 MAC 地址:
- 帧#9: AP 向无线客户端发送请求以识别自身。
- 第 10 帧:苹果无线客户端识别自己。
- 帧# 12:AP 想要使用 e AP-TLS 方法建立一个安全隧道来保护所有的 EAP 通信(称为受保护的 EAP-PEAP)。
- 帧#13:客户端开始向 AP 发送 TLS ver1.2 帧。
- 帧# 15-46:AP 和无线设备再交换几个数据包,以完成身份验证过程和封装方法。
图 9.18: EAP 流程
- 第 48 帧:EAP 进程完成,在 EAP 报头中有代码 成功 。详情如下:
图 9.19:–EAP 流程-最终状态代码
在成功的 EAP 过程之后,无线客户端和 AP 必须完成四次握手,这是为 AP 和无线客户端设计的,以在不泄露先前共享的密钥的情况下独立地向彼此证明它们的合法性。这对于保护网络免受各种恶意接入点的攻击至关重要。确保四次握手完成,以便无线客户端可以访问数据。
图 9.20:四次握手
还有更多…
河床上的空气帽
在前面讨论的场景中,考虑了一种非常特殊的身份验证和封装方法,并在 Apple Mac 笔记本电脑上执行。您可以使用市场上提供的各种商业工具,如 Riverbed 的 AirPcap 无线适配器,它与 Wireshark 和 SteelCentral packet analyzer 完全集成。该产品包提供了全面的报告和可视化。详情请参考以下链接:https://www . riverbed . com/products/steel central/steel central-riverbed-aircap . html。
获取无线客户端、接入点和控制器之间流量的更多方式
在前面的章节中,我们只讨论了无线客户端和 AP 之间的交互,以及相关的数据包捕获。思科系统公司和阿鲁巴/HPE 公司等供应商提供了以嗅探模式运行 AP 和/或无线控制器的方法。在这种模式下,AP/WLC 向特定的 UDP 端口(例如,5555
)发送流量;它可以在无线客户端中使用带有 UDP 端口5555
过滤器的 Wireshark 捕获,并解码为 peekremote(在旧版本中为 airopeek)。此选项有助于确认从 AP 到客户端的流量没有丢失,也有助于验证各种无线电/链路层参数。
在正常情况下,无线客户端和接入点之间的所有控制/数据负载都是加密的,无法使用 Wireshark 解密。我建议您与特定的供应商联系,看看是否有可能在 AP/WLC 解密这些数据包。
此外,在集中式部署模式下,接入点和 WLC 之间的数据/控制流量采用 CAPWAP 隧道。可以使用 Wireshark 捕获 CAPWAP 流量(就像我们捕获网络中两台电脑之间的流量一样)并解码。
确保您检查了 Wireshark | Preferences | Protocols | CAPWAP 控制下的 Cisco 无线控制器支持选项,以便解码 CAPWAP 控制数据包。如果未选中,数据包可能会在 Wireshark 显示中被标记为格式错误的数据包。**
十、网络层协议和操作
在本章中,您将了解以下内容:
- IPv4 操作原则
- IPv4 地址解析协议操作和故障排除
- ICMP–协议操作、分析和故障排除
- 分析 IPv4 单播路由操作
- 分析 IP 碎片故障
- IPv4 多播路由操作
- IPv6 操作原则
- IPv6 扩展标头
- icmp V6–协议操作、分析和故障排除
- IPv6 自动配置
- 基于 DHCPv6 的地址配置
- IPv6 邻居发现协议的运行与分析
介绍
在本章中,我们将主要关注 OSI 参考模型的第 3 层,并学习如何分析第 3 层协议(IPv4/IPv6)的运行,以及单播和组播流量分析。我们还将了解地址解析协议 ( ARP )/ND、动态和无状态 IPv6 地址配置等等。我们将讨论您在排除这些协议故障时可能面临的基本问题。
我们将学习如何使用 Wireshark 分析单播和组播流量的端到端 IPv4 和 IPv6 连接故障。
虽然有各种结构化的故障排除方法,但自下而上的故障排除方法是最有效的方法。它从 OSI 参考模型的底层(物理层)开始。当端点之间出现端到端连接故障时,这种方法会从底层开始检查元素,然后向顶层移动,直到确定故障原因。方法如下:
ISO 自下而上故障排除模型
IPv4 操作原则
在 OSI 参考模型中,网络层负责使用网络层寻址来提供全球唯一的设备标识,并为不同网络中的终端系统之间的数据传输提供连接。网络层的基本功能是从上层(传输层)接收数据段,用携带源和目的标识符的网络层报头封装数据段,然后将数据包转发到远程终端系统。
IP 是网络层协议,并且是互联网和其他网络最常用的网络层协议。IPv4 报头的格式如下:
IPv4 数据包报头
以下是 Wireshark 捕获 IP 数据包的示例:
样本 IP 数据包
IP 寻址
IPv4 地址是分配给 IP 网络上每台设备的唯一逻辑网络层标识符。它是一个 32 位标识符,由网络部分和主机部分组成。地址格式如下:
IPv4 地址格式
网络 ID 用于识别主机所在的网络。同一网络中的所有节点将共享相同的网络 ID。主机 ID 用于识别网络中的主机。网络中的每个节点都有一个唯一的主机 ID。IP 地址总是分配有子网掩码,用于标识地址的网络 ID 部分。例如,子网掩码为255.255.255.0
的 IP 地址10.0.0.1
表示前三个二进制八位数是网络 ID,最后一个二进制八位数是主机 ID。
虽然 IPv4 地址的大小是 32 位,但用于表示地址的语法是基于点分十进制的。32 位分为四个二进制八位数,每个二进制八位数表示为一个十进制值,以点作为分界。
有三种类型的 IPv4 地址,概述如下:
- 单播地址:用于点对点通信,数据从一个节点发送到相同或不同网络中的一个接收方。单播的地址范围是从
1.0.0.0
到223.255.255.255
。 - 组播地址:用于点对多点通信,数据从一个节点发送到相同或不同网络中的多个接收者。组播的地址范围是从
224.0.0.0
到239.255.255.255
。 - 广播地址:用于点对多点通信,数据从一个节点发送到同一网络中的所有接收器。每个子网中的最后一个 IP 地址是广播地址。地址
255.255.255.255
被称为受限广播地址。
IPv4 地址解析协议操作和故障排除
以太网是流行且主要部署的局域网 ( LAN )技术,传输速率从 10 Mbps 到 400 Gbps。该数据链路层协议使用 48 位 MAC 地址作为数据链路层标识符。在本菜谱中,我们将讨论 IPv4 ARP 及其相关问题。
做好准备
在自下而上的故障排除方法中,任何连通性问题的第一步都是确保 ARP 解析对于相应的 IP 地址是成功的。
怎么做…
考虑以下 LAN 拓扑的屏幕截图:
局域网拓扑
在前面的场景中,假设 PC1 正试图联系 PC2 :
- 从 PC1 (
10.1.1.101
)到 PC2 (10.1.1.102
)触发 ping 探针。这将触发从 PC1 到 PC2 的 ARP 请求。 - 使用
arp-a
检查 PC1 上的 ARP 表,查看本地表中是否填充了10.1.1.102
的 MAC 地址。 - 如果你在 PC1 本地表中看到了
10.1.1.102
的 MAC 地址,那就证实了 PC1 发送了 ARP 请求并收到了来自 PC2 的 ARP 响应。 - 如果在 PC1 中没有看到
10.1.1.102
的 MAC 地址,将 Wireshark 连接到交换机上的一个空闲端口并捕获数据包(使用端口镜像)。在连接 PC1 和 PC2: 的端口的入口和出口方向上执行捕获将是有用的
ARP 数据包捕获
- 检查来自 PC1 的 ARP 请求是否出现在捕获中。前面的截图显示了来自 PC1 的 ARP 请求。您可能已经注意到,ARP 数据包的目的地是广播 MAC 地址
ff.ff.ff.ff.ff.ff
:- 如果在连接 PC1 (入口方向)的端口的捕获中发现 ARP 请求包,但在连接 PC2 (出口方向)的端口的捕获中没有发现,则交换机可能已经丢弃了 ARP 包。
- 如果在连接 PC1 的端口(入口方向)的捕获中没有看到 ARP 请求数据包,请检查连接 PC1 到交换机的物理电缆。
- 如果在连接 PC1 和 PC2 的两个端口上捕获到 ARP 请求包,但是没有 ARP 响应,检查 PC2:
ARP 回复捕获
- 检查 ARP 回复数据包是否出现在捕获中。前面的截图显示了从 PC2 到 PC1 的 ARP 回复。可以看出,ARP 回复是单播给 PC1 MAC 地址的:
- 如果在连接 PC2 的端口(入口方向)的捕获中发现 ARP 回复数据包,但在连接 PC1 的端口(出口方向)的捕获中没有发现,则交换机可能已经丢弃了 ARP 回复数据包。
- 如果在连接 PC2 (入口方向)的端口上的捕获中没有看到 ARP 应答包,检查连接 PC2 到交换机的物理电缆。
- 如果在连接 PC1 和 PC2 的两个端口的捕获中看到 ARP 应答包,但是在 PC1 ARP 表中没有条目,检查 PC1 。
以下是一些有用的显示过滤器:
Wireshark ARP 显示过滤器
ARP 攻击和缓解措施
ARP 是一个非常简单的协议,没有任何认证或其他内置的安全机制,因此很容易受到攻击。网络中的恶意用户可以使用 ARP 作为 ARP 中毒的手段进行窃听,或者可以使用 ARP 扫描进行拒绝服务 ( DoS )攻击。在本节中,我们将讨论不同的基于 ARP 的攻击,以及如何使用 Wireshark 来检测它们。
ARP 中毒和中间人攻击
中间人攻击的一种类型是,攻击者利用以太网网卡的 MAC 地址毒害他们想要监听的设备的 ARP 缓存。一旦 ARP 缓存中毒成功,每台受害设备在与另一台设备通信时,都会将其所有数据包发送给攻击者。当然,攻击者在读取数据后会重新发送给他们。
这被称为中间人攻击,因为它将攻击者置于受害设备之间的通信路径中间。它也被称为 ARP 中毒,因为攻击者实际上是用错误的信息毒害受害者的 ARP 缓存。
在下图中,我们看到了一个中间人攻击的示例:
ARP 中毒攻击
以下是 Wireshark 的截图:
ARP 欺骗捕获
应该注意的是,攻击者使用 MAC 地址f0:de:f1:ae:77:69
来响应对10.0.0.100
和10.0.0.101
的 ARP 请求。在生产网络中,您可能会在几秒钟内看到成千上万的数据包被捕获。Wireshark 显示过滤器将有助于缩小我们感兴趣的数据包的范围。
无偿 ARP
任何节点都可以使用免费的 ARP ( GARP )来通告自己的 MAC 地址,并以相应的 IP 地址作为 ARP 回复,即使没有 ARP 请求。这种提前通知的主要目的是确保邻居的 ARP 缓存随着本地 MAC 地址的任何变化而更新。GARP 总是注定要广播 MAC 地址:
GARP 包
虽然预计它会在生产环境中看到 GARP,但它也可能被任何恶意攻击者利用,通过向 GARP 发送其自己的 MAC 地址来窃听任何 IP 地址:
GARP 滤波器
arp.isgratuitous
是一个 Wireshark 显示过滤器,有助于从大量捕获的数据包中列出 GARP 数据包。
基于 ARP 扫描的 DoS 攻击
对于网络库存,通常的做法是使用管理系统,并向子网内的所有 IP 地址发送 ARP 请求扫描。在这种方法中,目标 IP 地址将不断变化,但发送方 IP 地址和发送方 MAC 地址将保持不变,并被设置为管理系统地址。为了实现高效通信,终端主机的默认行为是从 ARP 请求中获取发送方 IP 和 MAC 地址,并填充本地 ARP 缓存。任何恶意攻击者也可以利用 ARP 扫描和这种行为,通过更改发送者的 IP 和 MAC 地址来耗尽 LAN 网络中所有终端主机的 ARP 缓存。
ARP 请求和回复是常规网络操作的一部分。这里有一些经验法则来确保它们确实如此:
- 对于来自不同来源的 ARP 请求:
- 如果来源合法,这是一个正常的操作
- 如果来源是恶意的,这可能是一种攻击
- 对于来自单一来源的 ARP 请求:
- 如果源是管理系统,则是正常操作
- 如果来源是路由器,则可能是网络扫描
- 如果来源不合法,则可能是攻击
IP 统计
Wireshark 统计数据可用于识别是否有 ARP 扫描。这可以通过 Wireshark 报头字段中的统计信息|协议层次结构来查看。如前例所示,通过该选项可以查看 ARP 数据包的数量,这将有助于我们了解网络中是否存在 ARP 数据包的扫荡。
它是如何工作的…
对于端到端通信,任何节点都需要解析与第 3 层 IPv4 或 IPv6 网络地址相关联的 48 位以太网 MAC 地址。
当第 3 层网络为 IPv4 时,ARP 用于解析与 IPv4 地址相关的 MAC 地址。ARP 数据包格式如下:
ARP 数据包格式
解析节点将发送 ARP 请求(OpCode = 1
),该请求广播 MAC 地址(ff.ff.ff.ff.ff.ff
)。发送方硬件地址将被设置为发起节点的 MAC 地址,发送方协议地址将被设置为发起节点的 IP 地址。目标硬件地址将被设置为零值,并且目标协议地址将被设置为正在执行 MAC 解析的地址。
响应节点将用单播给解析节点的 ARP 回复(Opcode = 2
)进行回复。
ARP 操作只是本地的,这意味着 ARP 请求是一种广播,只在局域网上发送。当源地址 S 和目的地址 D 属于同一个局域网(相同的 IP 网络和掩码)时,ARP 会通过发送携带目标协议地址为 D 的 ARP 请求,尝试解析出 D 的 MAC 地址。但是当源地址 S 和目的地址 D 在不同的局域网(不同的 IP 网络和掩码)时,将对默认网关地址进行解析。
ICMP–协议操作、分析和故障排除
互联网控制消息协议 ( ICMP )是一种网络层协议,用于错误报告和网络路径诊断功能。Ping 和 Traceroute 实用工具利用 ICMP 消息进行故障检测和隔离。ICMP 消息使用基本 IP 报头发送。IP 报头中的协议字段将被设置为 ICMP,后跟 ICMP 有效负载。ICMP 数据包具有以下格式:
ICMP 报头格式
用于网络连接性验证的 ICMP 消息类型有回应请求(Type = 8
)和回应回复(Type = 0
)。
做好准备
当 web 服务或邮件服务等终端应用出现问题时,使用自下而上方法的第一个故障排除步骤是检验数据链路层。使用上一节中定义的步骤检验完数据链路层后,下一步是检验端点之间的网络连通性。端点之间的网络连通性可以通过常用的故障检测和隔离实用工具来验证,例如 Ping 和 Traceroute。
怎么做…
考虑以下 IPv4 拓扑的屏幕截图,并仔细观察 Ping 探针:
IPv4 拓扑
在上图中,当从 PC1 到 PC2 触发 Ping 探测时,从 PC1 到 PC2 的 IP 或以太网报头不会有任何变化,因为它们都在同一个局域网中:
- 触发 PC1 (
10.1.100.101
)到 PC2 (10.1.100.102
)的 Ping 探针。这将产生一个从 PC1 到 PC2 的 ICMP 回应请求消息。 - 如果没有来自 PC2 的回应回复,确保在本地 ARP 缓存表中填充了 PC2 的 MAC 地址。
- 将 Wireshark 连接到 SW1 上的一个空闲端口,并捕获数据包(端口镜像):
ICMP 数据包
- 检查在捕获中是否看到来自 PC1 的 ICMP 回应请求。前面的截图显示了从 PC1 到 PC2 的 ICMP 回应消息:
- 如果在连接 PC1 和 PC2 的端口看到 echo 消息,但是还没有响应,检查 PC2 上的防火墙和其他设置。
- 如果在连接 PC1 的端口看到回应消息,但在连接 PC2 的端口没有看到回应消息,请检查交换机是否正在丢弃数据包。
- 如果在连接 PC1 的端口没有看到 echo 消息,检查连接 PC1 到 SW1 的物理电缆:
- 检查在捕获中是否看到来自 PC2 的 ICMP 回复。上图显示了从 PC2 到 PC1 的 ICMP 回复:
- 如果在连接 PC1 和 PC2 的端口中看到回应回复,那么一切都工作正常。
- 如果在连接 PC2 的端口中看到回应应答,但在连接 PC1 的端口中没有看到回应应答,请检查交换机是否正在丢弃数据包。
- 如果连接 PC2 的端口看不到回应应答,检查连接 PC2 到 SW1 的物理线缆。
以下是一些有用的 ICMP 显示过滤器:
ICMP 攻击和缓解
虽然 ICMP 是一个极好的错误报告和诊断实用工具,但它也在许多网络中被用作 DoS 攻击的来源。
ICMP 洪水攻击
ICMP flood 攻击是常见的 DoS 攻击之一,网络中的恶意用户会向目标主机(如服务器)发送大量 ICMP 数据包:
Wireshark 统计数据可用于识别是否存在 ICMP 攻击。可以通过 Wireshark 头字段中的统计信息|协议层次结构来查看统计信息。如前面的截图所示,几秒钟内有 60,000 个 ICMP 数据包。
ICMP smurf 攻击
ICMP smurf 攻击是另一种分布式 DoS 攻击,在这种攻击中,恶意攻击者会向一个或多个目标发送大量 ICMP 回送消息,并将目标(受害者)主机的欺骗地址作为 ICMP 回送消息的源 IP 地址。这将导致受害主机收到大量回应回复消息,导致其缓冲区溢出和耗尽:
单一网络拓扑
在上图中,攻击者生成了一条 ICMP 回应消息,其中包含假冒地址 PC1 。这种攻击导致 PC1 收到来自非预期响应者的 ICMP 回应回复,导致缓冲区耗尽问题。
当启用第 2 层安全功能时,源 MAC 地址不能被欺骗。因此,捕获数据包并使用源 MAC 地址可能有助于识别攻击者以阻止攻击。
它是如何工作的…
为了验证 PC1 和 PC3 之间的可达性,Ping 实用工具将用于触发从 PC1 到 PC3 的 ICMP 消息,如下图所示:
将生成一个 ICMP 回应请求(类型 8 ),源地址为10.1.100.101
,目的地为10.1.200.101
,并转发到默认网关。路径上的每台路由器都会根据转发表转发它。 PC3 收到 ICMP 回应请求消息后,会回复一个 ICMP 回应回复(类型 0)给 figure。Ping 失败将指示 PC1 和 PC3 之间的连接问题。
分析 IPv4 单播路由操作
IPv4 单播路由是将单播数据包从一个网络中的主机转发到同一网络或另一个网络中的接收器的过程。数据分组可以沿着路径穿过一个或多个路由器,这些路由器将在 IP 报头中执行查找以做出转发决定。
做好准备
只需打开 Wireshark,将其连接到网络,配置您想要测试的设备的端口镜像,然后启动它。碎片化将主要影响交互式应用,如数据库,这些是我们应该寻找问题的地方。
它是如何工作的…
如果10.1.100.0/24
网络中的 PC1 想要与10.1.200.0/24
网络中的 PC4 通信,则执行以下操作:
- PC1 生成数据并将其封装到 IP 报头中。源 IP 地址被设置为
10.1.100.101
,目的 IP 地址被设置为10.1.200.102
。 - PC1 用以太网报头封装数据包。源 MAC 地址设置为 PC1 MAC 地址,目的 MAC 地址设置为 R1(默认网关)MAC 地址。该帧将被转发给 SW1。
- SW1 是一个简单的第 2 层交换机,因此它对以太网报头执行查找,然后转发到目的 MAC(本例中为 R1)。
- R1 收到数据包并解封以太网报头,因为目的 MAC 地址与它自己的地址匹配。它在本地路由表中查找 IP 报头中的目的 IP 地址,发现 R2 是到达
10.1.200.0/24
的下一跳。 - R1 递减 IP 报头中的 TTL,并将数据包封装到以太网报头中。源 MAC 地址设置为 R1,目的 MAC 地址设置为 R2。该帧将被转发到 R2。
- R2 执行相同的转发行为。它会解封以太网报头,减少 IP 报头的 TTL,并将其与封装的新以太网报头一起转发给 R3。
- R3 收到帧后,会解封以太网报头,递减 IP 报头的 TTL,并将其与以太网报头封装在一起。源 MAC 设置为 R3,目的 MAC 地址将设置为 PC4 的 MAC 地址。
- PC4 将接收帧,解封装以太网和 IP 报头,并将其用于适当的应用。
可以看到,沿着路径的路由器修改 IP 报头中的一些字段(例如 TTL ),并且以太网封装沿着路径改变。 PC1 和 PC4 之间的任何连接故障都可能是由于各种原因造成的,包括错误的以太网封装、TTL 处理以及数据包太大而无法处理。我们将看到如何使用 Wireshark 来分析此类数据包路由问题。
TCP 路径 MTU 发现
虽然与 IP 报头相关联的转发语义允许任何中转节点对分组进行分段,但是这可能会产生性能问题(如前一节所述),因为在处理之前要求接收方重新组装分组。我们可以强制传输节点不分割分组,而是发信号通知路径中较低 MTU 的存在,并让发起者调整 MSS。此过程称为路径 MTU 发现(PMTUD) ,是检测路径上最低 MTU 并使用该值调整 MSS 以实现高效数据传输的有效方式。
IP TTL 故障和攻击
正如我们在前面几节中看到的,每当中转路由器在 IP 报头中执行查找时,它都会将 IP TTL 减 1,然后再将数据包转发到下一跳路由器。如果路由器收到 TTL 为 1 的数据包,并且目的 IP 地址不是它自己的地址,则默认行为是丢弃该数据包并生成类型为 11(超过生存时间)的 ICMP 错误消息。此行为可确保路由环路中的数据包不会永远在节点之间跳跃,而是会在 255 次迭代后被丢弃(TTL 的最大值可设置为 255):
Wireshark 的专家信息选项提供了一个警告,提示收到了 TTL 小于 5 的数据包,并突出显示这些数据包,如前面的屏幕截图所示。这可以通过执行以下操作来查看:
- 转到分析并单击专家信息选项
- 单击警告或注释部分以查看更多详细信息
恶意攻击者可以利用 IP TTL 发送大量低 TTL 值(小于 5)的数据包来触发 DoS 攻击。传输节点将继续将数据包发送到 CPU,以生成 ICMP 错误消息,这可能会导致占用 CPU。有各种选项可用,如 CPU 保护机制或限制 CPU 的流量速率,可以帮助减轻此类攻击。
重复的 IP 地址
我们将从现象开始,例如对服务器或另一个设备的缓慢访问,对互联网的缓慢访问,以及所有没有得到回复的 pings。
- 当您缓慢访问网络设备时,其中一个问题可能是您的设备的 IP 地址与另一个地址冲突。要验证这一点,请 ping IP 地址。
在一些设备中,当它们的地址与相同的地址冲突时,驱动程序将被关闭(Windows 操作系统中屏幕左下角的小符号)。在其他设备中,您将不会收到任何冲突通知,而这正是会出现问题的地方。
- 在命令行界面 ( CLI )中输入
arp -a
。在 Windows 中使用命令cmd
(或者在 Linux 中使用任何 shell)。如果您使用不同的 MAC 地址 pinged 了两行 IP 地址,则存在重复。 - 谷歌一下这两款设备的 MAC 地址,地址的第一部分会告诉你厂商是谁。这会让你找到麻烦制造者。
- 如果您需要设备的位置,请登录到您的 LAN 交换机(当然,当您有被管理的交换机时),从交换机 MAC 地址表中,您将看到您所连接的交换机端口。有一个软件可以显示连接到每台交换机的设备列表,以及它们的 MAC 地址、IP 地址、DNS 名称等等。谷歌交换机端口映射或交换机端口映射工具,你会发现很多。
- 如果 Ping 和 ARP 没有任何效果,只需启动 Wireshark 并对网络 VLANs 进行端口镜像。Wireshark 将向您显示重复地址错误以及相关详细信息。
- 您将得到的错误消息如下面的屏幕截图所示:
当您 ping 一个在您的本地网络中出现两次的 IP 地址时,具有相同 IP 地址的两台(或更多)设备将响应您发送的 ARP 请求,并且您的 ARP 缓存将有两个相同 IP 地址的条目。
在许多情况下,您的设备会通过关闭其 IP 驱动程序来指示它,并通过弹出窗口或您知道的任何其他类型的通知来通知您。
在其他情况下,冲突的设备不会通知您冲突,然后您会发现只有 Ping 和 ARP 有问题,如前所述。
无论如何,当您将 Wireshark 连接到网络并看到重复的 IP 消息时,不要忽略它们。
分析 IP 碎片故障
分段是 IP 中的一种常见机制,它将一个大的 IP 数据包分成适合第 2 层以太网帧的较小数据包。当任何路由器接收到大于出接口最大传输单位 ( MTU )的数据包时,该数据包就会被分段。在大多数情况下,这种机制不应该有任何问题,但是这种机制可能会导致性能问题。IP 碎片也可能被用作 DoS 攻击的来源。
怎么做…
发生碎片化时,您会看到 UDP 或 TCP 数据包以及碎片化的 IP 协议数据包,如以下屏幕截图所示:
如果怀疑存在性能问题,例如,数据库客户机与服务器的连接速度很慢,请按照以下步骤查看问题是否是由碎片引起的:
- 测试客户端和服务器之间的连接,验证没有其他问题。
- 寻找客户端和服务器之间的碎片。片段将如之前的截图所示(IPv4 片段)。
- 如果您怀疑碎片是问题的原因,可以通过修复传输路径的 MTU 或调整应用发送不会导致网络碎片的较小数据包来解决问题。
- 以太网中推荐的数据包大小不超过 1460 字节减去 TCP 报头大小。因此,从接口出来的数据段应该有 1420-1440 字节的大小。
在我们需要更多字节作为报头的情况下,例如,当我们使用隧道机制和 TCP 选项时,DBA 将不得不进一步减小这个大小。最好的方法就是把它缩小到你看不到任何碎片的大小。
基于碎片的攻击
虽然在网络中看到 IP 碎片是正常的,但是恶意攻击者也可以利用碎片进行 DoS 攻击。这种攻击称为微小碎片攻击,攻击者将向目标主机发送大量微小碎片数据包。这种微小的碎片需要由目标主机重新组装,从而导致性能问题或其他缓冲区溢出问题:
在前面的截图中,可以看到捕获片段的大小为 100 字节;攻击者可以使用更小的规模在目标主机上触发 DoS 攻击。
默认情况下,Wireshark 会重组捕获中的任何碎片数据包,并将其显示为一个重组的数据包。这可能会给人一种网络不存在碎片化的印象。通过更改首选项设置,我们将能够在 Wireshark 中显示真正的碎片数据包。
这可以通过以下步骤完成:
- 转到编辑并单击首选项
- 单击协议,然后选择 IPv4
- 取消设置重组碎片 IPv4 数据报字段
它是如何工作的…
理解定义通过网络发送的数据单元大小的两个术语非常重要,如下图所示:
- 最大传输单位(MTU) :这是 IP 数据包的大小,包括报头和数据
- 最大数据段大小(MSS): 这是 TCP 数据段的最大大小:
IPv4 中使用的分段机制如下图所示:
一个原始的大数据包进入网卡或路由器,其数据包大小需要进行分段。根据原始大小,数据包被分成几个部分。
对于碎片,我们有以下字段:
ID
:与原始 IP 包的 ID 相同Bit 0
:始终0
Bit 1 (DF bit)
:0
=五月断片,1
=不断片Bit 2 (MF bit)
:0
=最后一个片段,1
=更多片段Fragment Offset
:表示从原始数据包开始的字节数
在 IPv4 中,网卡本身可以在数据包到达目的地的途中与每台路由器一起将数据包分段。
PMTUD 利用 IP 报头中的不分段 ( DF
)标志。当任何中转路由器接收到大于输出接口 IP MTU 大小的 IP 数据包时,如果数据包报头中的DF
标志设置为1
,路由器将丢弃该数据包并生成类型 3 ( Destination unreachable
)的 ICMP 错误消息,代码为 4(需要分段并设置 DF)。此消息将被发送给数据包的发起者,并将携带传出接口的 MTU 大小:
路径 MTU 发现拓扑
在上图中, R2 上出接口到达 R3 的 MTU 值为 100 。当 R2 接收到任何大小超过 100 的 IP 数据包时,它会丢弃该数据包并生成 ICMP 错误消息:
R2 丢弃数据包并生成 ICMP 错误消息,如前面的屏幕截图所示。发起主机将使用接收到的消息中的 MTU 值来调整会话的 MSS,以实现高效的数据传输。
以下是一些有用的 IP 碎片过滤器:
IPv4 多播路由操作
IPv4 多播路由是将数据包从源转发到位于相同或不同网络中的一个或多个接收者的过程。组播包的源地址将是单播地址,而目的地址将是组播地址(224.0.0.0
到239.255.255.255
)。使用组播接收流量的终端应用将使用带外机制解析组播地址,并使用 IGMP 等组播组成员协议加入相应的组播组。主机将向连接的路由器发送 IGMP 加入。
连接接收器的支持多播的路由器被称为最后一跳路由器(LHR) ,连接源的支持多播的路由器被称为第一跳路由器(FHR) 。LHR 将使用诸如 PIM 之类的多播路由协议,使用最短路径来建立到 FHR 的多播树。FHR 将通过多播树转发多播数据流量。多播可以部署在不同的模式中。下面是两种最常用的多播模式:
- 稀疏模式:在这种模式下,一个普通节点将被定位为集合点(RP) ,每个 LHR 将向 RP 建立组播树。这种树被称为共享树。FHR 在接收到来自连接源的多播流量时,会将数据包单播给 RP,RP 又会将其转发给共享树上的接收器。
- 特定于源的组播:在这种模式下,每个 LHR 将建立一个组播树,指向连接到源本身的 FHR。这种模式下不需要 RP。
它是如何工作的…
在下图中,假设接收方使用239.1.1.1
作为组播地址加入来自连接到 R1: 的源的流
在我们的例子中,10.1.8.8
作为 RP ,这个 RP 连接到 R2 :
- 接收者将向连接的多播路由器发送
239.1.1.1
的 IGMP 加入请求。LHR 路由器( R3 和 R4 )在接收到来自接收者的 IGMP 加入后,将建立一棵朝向 RP 的共享树。在我们的例子中, R3 和 R4 将使用 R2 作为上游路由器来构建朝向 RP 的树。 - 连接到源的 FHR 在接收到第一个多播流量时,将使用 PIM register 消息对其进行封装,并向 RP 单播该数据包:
- 如前面截图所示, R1 将组播数据包(源为
10.1.17.7
,目的为239.1.1.1
)封装成 PIM 注册封装头。它进一步使用 IP 单播报头对其进行封装,其中源作为 FHR 路由器(10.1.12.1
),目的地作为 RP (10.1.8.8
)。 - RP 将解封装报头,并将多播流量转发到共享树。
- 默认情况下,LHR 路由器在收到组播流量后,会建立另一个指向源的树。这棵树叫做最短路径树。
虽然多播流量的转发行为不同于单播流量,但是 IP 报头在路径上的处理方式并没有太大的区别。例如,任何路由器都会减少单播和组播流量的 TTL。因此,我们为 IPv4 单播定义的所有故障排除分析程序也适用于 IPv4 多播捕获。
还有更多…
使用多播流量的终端应用主要是音频或视频应用,接收多播流的流量速率是故障排除时要考虑的标准之一。Wireshark 允许我们列出所有 UDP 多播流,并根据 PPS、使用的平均带宽等进行简单分析。在排除多播流量故障时,此统计信息非常有用。可以按照以下步骤查看统计数据:
- 转到统计,然后单击 UDP 多播流
- 检查多播信息的可用字段
IPv6 工作原理
随着 20 世纪 90 年代初互联网泡沫的出现,更多的企业开始依赖 IP 网络,这意味着 IPv4 地址空间的急剧枯竭。很快,业界意识到需要一种新的网络层协议来适应和满足不断增长的网络需求。这使得该行业开始致力于下一代知识产权(IPng)。
虽然最初的努力是扩展流协议(ST2)作为网络地址耗尽的快速解决方案,但诸如网络地址转换 ( NAT )和动态地址分配(如 DHCP)等功能在一定程度上解决了耗尽问题,使业界有足够的时间来研究 IPng。开发 IPng 不仅是为了应对地址空间挑战,也是为了考虑 IPv4 面临的其他限制和挑战。ST2 被正式指定为 IPv5,IPng 被正式指定为 IPv6。
IPv6 的大小为 128 位,因此提供了非常大的地址空间。虽然 IPv6 地址的大小是 IPv4 的四倍,但为了高效处理数据包,报头的大小得到了简化。IPv6 报头的格式如下:
以下是 Wireshark 捕获 IPv6 数据包的示例:
IPv6 寻址
与 IPv4 一样,IPv6 地址是分配给连接到网络的每台设备的唯一逻辑网络层标识符。IPv6 地址的大小为 128 位,包括网络前缀和接口 ID。IPv4 表示为四个十进制八位数,而 IPv6 地址表示为八个 16 位十六进制值块,以冒号作为分界。IPv6 地址的格式如下:
网络前缀用于标识主机所在的网络,而接口 ID 用于标识网络中的主机。虽然 128 位表示通过以十六进制值引用地址而变得高效,但这里有一些进一步简化表示的良好实践:
- IPv6 地址中的所有前导零都可以省略
- 连续的零可以表示为::
- *在地址中只能出现一次
有许多不同类型的 IPv6 地址;以下是其中一些的细节:
- 链路本地地址:这是一个不可路由的单播地址,具有特定于链路的范围,用于链路本地通信,其中数据包不会被发送超过一跳。所有控制平面通信(如 OSPF hello 消息)都属于这一类。任何启用 IPv6 的接口都将被分配一个链路本地地址。地址范围是 fe80::/10。
- 全局单播地址:这是具有全局范围的公共可路由单播地址。大多数互联网设备将从此范围内分配。地址范围是 2000::/3。
- 唯一本地地址:这是一个私有范围单播地址,在公共互联网中不可路由。地址范围为 fc00::/8 和 fd00::/8。
- 组播地址:和 IPv4 一样,这个地址用于点到多点的通信。地址范围是 ff00::/8。
还有一些其他类型的地址,如 IPv4 嵌入式地址和请求节点组播地址,为简洁起见,此处不做解释。
可以注意到,IPv6 没有任何广播地址,因为所有类型的广播通信都可以通过 IPv6 多播地址来寻址。如前所述,多播的地址范围是 ff00::/8,第一个块的最后 4 位定义了多播地址的范围。例如,1 具有节点本地范围,2 具有链接本地范围,5 具有站点本地范围,而 E 具有全局范围。下表给出了不同地址和范围的明确信息:
IPv6 扩展标头
为 IPv4 报头定义的 IP 选项主要用于携带额外的网络层信息。但是 IPv4 中 IP 选项的存在将最终将数据包发送到 CPU,从而由于慢路径数据包转发而引入性能问题。在 IPv6 中,提出了扩展报头来将这种控制平面信息编码为单独的灵活报头,而不增加 IPv6 报头的大小。IPv6 扩展报头位于分组中的 IPv6 报头和传输层报头之间,并且通过将下一个报头设置为相关值来识别 IPv6 扩展报头的存在。
以下是一些常用的 IPv6 扩展头:
| 协议号**(IPv6 NH 值)** | 扩展头名称 | 描述 | 参考 |
| 0
| IPv6 逐跳选项 | 可选的扩展报头,用于携带路径上每个节点可能处理的附加信息。这可能需要将数据包发送到所有节点上的 CPU。 | RFC 8200 |
| 44
| IPv6 的片段头 | 由源用来发送大于路径 MTU 的数据包。 | RFC 8200 |
| 50
| 封装安全负载 | 用于携带安全信息,以提供机密性、身份验证、完整性等。 | RFC 4303 |
| 60
| 目标标题 | 源使用它来携带只给最终目的地的信息。 | RFC 8200 |
以下是带有扩展报头的 IPv6 数据包格式:
以下是一个示例捕获:
IPv6 扩展标头和攻击
尽管 IPv6 在设计时考虑到了安全性,但扩展报头仍可能被用作 DoS 攻击的来源。如前所述,逐跳扩展报头的存在将需要路径上的所有中转节点来处理报头,从而消耗大量 CPU。类似地,当大量具有 IPv6 目的地扩展报头的数据包被转发到特定主机或服务器时,它可能会消耗服务器上的大量资源。
做好准备
只需打开 Wireshark,将其连接到网络,配置设备的端口镜像,然后开始捕获。可以通过 Wireshark 捕获来验证 IPv6 扩展标头的存在。
怎么做…
下面的屏幕截图显示了带有 IPv6 扩展标头的 IPv6 数据包:
在前面的屏幕截图中,使用ipv6.dst_opt
过滤数据包将列出所有带有 IPv6 目的地选项扩展头的 IPv6 数据包。或者,我们可以使用一个ipv6.hop_opt
过滤器列出所有带有 IPv6 逐跳选项的 IPv6 数据包。
虽然上述任务有助于缩小收到的带有扩展报头的数据包或数据包数量,但可能需要额外的手动分析,以了解这是预期行为还是攻击。
IPv6 分段
如前所述,分段是指将数据包分成更小的片段,以适应路径上最低的 MTU 的过程。IPv6 处理数据包碎片的方式与 IPv4 完全不同。以下是 IPv6 在处理碎片方面的一些主要差异:
- 在 IPv4 中,允许任何路由器对数据包进行分段(假设未设置
DF bit
),而 IPv6 仅允许 IPv6 数据包的源进行分段,任何中转节点都不能对 IPv6 数据包进行分段。 - 在 IPv4 中,分段细节作为 IPv4 报头的一部分被携带,但是在 IPv6 中,定义了新的扩展报头,并且该报头将仅被包括在分段的分组中。
它是如何工作的…
下图中, R2 上出接口的 MTU 值设置为 1280 ,这是 IPv6 报文转发所需的最小 MTU :
如果路由器收到大于传出接口的 MTU 的 IPv6 数据包,默认行为是丢弃该数据包并生成 ICMPv6 错误消息:
在前面的屏幕截图中, R2 丢弃数据包并生成一个 ICMPv6 错误消息,其中传出的 MTU 接口指向数据包的实际来源(在我们的示例中为 R1 )。
R1 将缓存此信息,并根据收到的 MTU 大小对数据包进行分段,如前面的截图所示。
如前面的屏幕截图所示,IPv6 片段扩展标头将包含所有与碎片相关的详细信息。在 IPv4 中,所有这些信息都作为 IPv4 报头本身的一部分携带。但是在 IPv6 中,它被包含在扩展报头中。
恶意攻击者也可以利用 IPv6 碎片进行 DoS 攻击。攻击者可能会发送大量带有 IPv6 片段扩展标头的数据包,导致目标主机消耗资源来重组片段数据包。
以下是一些有用的过滤器:
icmp V6–协议操作、分析和故障排除
ICMPv6 是针对 IPv6 的 ICMP 的增强版本,它不仅执行错误报告和路径诊断功能,还进一步扩展了其他网络层功能。ICMPv6 在以下方面起着关键作用:
- IPv6 路由器和邻居发现
- IPv6 无状态自动配置
- 路径 MTU 发现
- 故障检测和隔离
ICMPv6 是 IPv6 的一个组成部分,IPv6 的下一个头字段将被设置为58
。ICMPv6 数据包具有以下格式:
有不同类型的 ICMPv6 消息可用于错误报告、信息或发现目的。在本节中,我们将了解如何使用 ICMPv6 进行故障检测和隔离,在接下来的几节中,我们将看到 ICMPv6 的更多应用。
做好准备
当使用 IPv6 的终端应用面临连接问题时,可以使用 Ping 和 Traceroute 等故障检测和隔离实用工具来检测或隔离故障。当 Ping 工具用于 IPv6 地址时,它使用 ICMPv6 消息进行路径诊断。沿途一台或多台设备上的 Wireshark 可用于捕获不同点的数据包进行分析。
IPv6 邻居发现协议的运行与分析
当第 3 层网络是 IPv6 寻址时,IPv6 邻居发现(ND) 协议用于解析与 IPv6 地址相关联的 MAC 地址。与 ARP 不同,IPv6 ND 通过定义不同的 ICMPv6 数据包类型,使用 ICMPv6 进行地址解析。
ICMPv6 邻居请求是一种 ICMPv6 消息类型,解析节点使用它来查询 IPv6 地址的链路层地址。这类似于 IPv4 的 ARP 请求。此消息将被指定给 IPv6 请求节点多播地址,因为 IPv6 中没有广播地址。邻居请求消息格式如下:
ICMPv6 邻居公告是一种 ICMPv6 消息类型,响应节点使用它来回复相关 IPv6 地址的链路层地址。此消息类似于 IPv4 的 ARP 回复。该消息将被单播给解析节点。
邻居通告消息格式如下:
怎么做…
- 下图中, R1 正在对 R3 的地址 2001::3 进行路径诊断。当在 R1 上触发 ping 时,它产生一个 ICMPv6 回应消息,并将其转发给 R2 :
- 如下截图所示, R1 向 R3 发送 ICMPv6 回应请求消息(ICMPv6 type = 128)。
- R3 在收到 ICMPv6 回应请求后,将回复 ICMPv6 回应回复。
如前面截图所示, R3 回复 ICMPv6 回应回复给 R1 。
在一些故障场景中,我们可能会注意到一些间歇性的数据包丢失。在一个大的pcap
文件中,可能很难缩小我们没有得到响应的 ICMPv6 消息的列表。专家信息选项在这里会很有帮助:
- 转到分析并点击专家信息
- 检查警告:
这将列出在捕获中没有 ICMPv6 响应的所有 ICMPv6 回显消息。
IPv6 自动配置
IPv6 的主要优势之一是能够自动配置接口地址。这种能力允许支持 IPv6 的设备以即插即用模式工作。
做好准备
当使用 IPv6 自动配置的终端主机无法正常工作时,首先要做的是确保正确自动配置链路本地地址。这可以通过检查接口地址配置来验证。在 Unix/Linux 设备中,ifconfig -a
将列出接口上配置的 IPv6 地址。如果您看不到任何东西,主机上的 IPv6 堆栈可能有问题。如果您看到 IPv6 链路本地地址,下一步是使用 Wireshark 捕获数据包,并查看路由器请求和广告消息是否交换。
怎么做…
- 当在终端主机上启用 IPv6 自动配置时,预计会向所有路由器多播地址发送路由器请求消息。
- 在 Wireshark 捕获中检查消息是否由主机发送:
- 如前面的屏幕截图所示,IPv6 主机发送一条 ICMPv6 路由器请求消息。可以观察到,ICMPv6 选项在路由器请求消息中携带终端主机的 MAC 地址。任何收到此消息的路由器都会缓存 MAC 地址以进行地址解析。
- 下一步是检查路由器是否正在发送路由器通告消息,其中包含终端主机可用于自动配置的相关详细信息:
- 如前面的屏幕截图所示,路由器向所有节点的组播地址
ff02::1
发送路由器广告消息。局域网中的所有节点都将监听这个多播,因此将处理消息中的信息。 - ICMPv6 路由器广告消息携带最小 64 位的 IPv6 前缀细节。在前面的截图中,前缀
2001:db8:1000::/64
被广告。这个前缀将用一个双定时器变量来通告。有效寿命是该前缀在链路上作为有效地址使用的时间长度。优选寿命是从接收到的前缀生成的地址优选的时间长度。
如果在捕获中没有看到前面的路由器通告,则需要验证路由器配置,以确保启用了相关的 IPv6 自动配置来通告前缀。
它是如何工作的…
自动配置 IPv6 地址的过程被称为无状态地址自动配置 ( SLAAC )。正如我们前面看到的,当 IPv6 在任何设备上启用时,默认情况下会分配一个来自fe80::/10
范围的链路本地地址。根据 IPv6 地址格式的要求,IPv6 地址的接口 ID(最后 64 位)对于网络中的每个主机来说必须是唯一的。那么,我们如何确保自动配置的 IPv6 地址对于网络中的每台主机都是唯一的呢?在 LAN 中,MAC 地址是分配给每台主机的数据链路层标识符,在网络中应该是唯一的。这是为了确保帧被传送到正确的主机。IPv6 自动配置利用了 IPv6 自动配置的 MAC 地址的唯一性。但是有一个挑战 MAC 地址是 48 位大小,而接口 ID 是 64 位大小。MAC 地址由 24 位组织唯一标识符(OUI)和 24 位供应商分配的标识符组成。使用以下步骤将此 MAC 地址转换为 64 位 EUI-64 寻址格式:
- 16 位十六进制值
FFFE
插入 OUI 和供应商分配的标识符之间 - OUI 中的 U/L 标志(位 7)被设置为
1
以下是前面步骤的说明:
产生的 64 位值连接到 64 位网络前缀{fe80::/10 + 54 bits all-zero value}
,以自动配置一个 128 位的唯一 IPv6 链路本地地址。顾名思义,该地址是本地链路范围的,因此不能用于与 LAN 网络外部的节点通信。
IPv6 SLAAC 从路由器发出全球唯一前缀信号,并利用终端主机生成 EUI-64 地址的能力来自动配置全球唯一的 IPv6 地址。ICMPv6 充当路由器向 LAN 网络中的终端主机通告全局唯一前缀的信令协议角色。以下是用于此目的的两种 ICMPv6 消息类型:
- 路由器请求消息
- 路由器广告消息
任何启用了 IPv6 自动配置的终端主机都将发送 ICMPv6 路由器请求消息。该 ICMPv6 消息的源地址通常设置为接口的本地链路地址,目的地址设置为所有路由器的本地链路组播地址(ff02::2)。该消息具有以下格式:
连接到 LAN 网络的路由器会定期发送 ICMPv6 路由器广告消息,其中包含前缀和其它相关详细信息,终端主机可以使用这些信息来自动配置地址。此 ICMPv6 消息的源地址将被设置为路由器接口的本地链路地址,目的地址将被设置为所有节点的本地链路多播地址(ff02::1)。该消息具有以下格式:
基于 DHCPv6 的地址分配
虽然 IPv6 SLAAC 更简单、更容易,因为它即插即用,但它不是自动配置 IPv6 地址的唯一选项。DHCPv6 是另一个集中式地址分配选项,可用于地址分配和管理。在这个菜谱中,我们将看到如何分析一些最常见的 DHCPv6 问题。
做好准备
确保您配置了 DHCPv6 服务器来为请求客户端分配 IPv6 地址。在 Unix/Linux 设备中,ifconfig -a
将列出接口上配置的 IPv6 地址。如果您没有看到 DHCPv6 分配的地址,请在局域网中使用 Wireshark 捕获数据包。
怎么做…
- 检查终端主机是否发送了 DHCPv6 请求消息。这是客户端发送的第一条消息,用于标识提供 IPv6 地址的可用 DHCPv6 服务器列表。该消息将以源地址作为链路本地地址发送,而目的地址将是链路本地范围的多播地址,称为全 DHCP 中继地址(
ff02::1:2
)。 - 如果您在捕获中没有看到请求消息,则终端主机可能没有正确配置或运行不正常:
- 检查相关接口是否启用了 IPv6。
- 检查是否为接口分配了链路本地地址。
- 检查接口是否能够从 DHCPv6 接收 IPv6 地址:
- 如果看到请求消息,请确保消息中包含客户端标识符。这是 DHCPv6 服务器用来唯一标识客户端的 ID,有助于客户端管理和为客户端重新分配相同的地址。任何没有客户端 ID 的请求消息都将被服务器忽略。因此,如果您看到此消息,但没有客户端 ID,则预计服务器不会为客户端分配 IPv6 地址。
- 接下来,检查在捕获中是否可以看到广告消息。如果服务器成功接收到带有客户端 ID 的请求消息,它将使用 DHCPv6 广告消息进行单播。如果网络中有多个服务器,所有的服务器都会回复一个广告消息。
- 如果您没有看到 DHCPv6 广告消息,可能是服务器配置不正确或运行不正常:
- 检查是否有服务器在监听
ff02::1:2
。这可以通过简单地触发从客户端到ff02::1:2
的 ICMPv6 ping 来验证。如果我们得到一个响应,它验证有一个服务器在监听请求消息。 - 检查服务器是否配置了 DHCPv6 池。
- 检查服务器端的 IPv6 或 DHCPv6 堆栈是否有任何问题。这可能因用于此目的的服务器类型而异:
- 检查是否有服务器在监听
- 前面的屏幕截图显示了来自服务器的 DHCPv6 广告消息。可以注意到,该消息将被单播给请求地址的客户端。广告消息携带服务器标识符,该标识符从网络中的其他可用服务器中唯一地标识该服务器…
- 下一步是检查客户端是否正在发送 DHCPv6 请求消息。如果广告消息没有携带客户端标识符(来自请求消息),客户端将忽略该消息:
-
如果您看到请求消息,请检查该消息是否携带相关的客户端和服务器标识符。该消息将被发送到全 DHCP 中继地址,因此它将被传送到网络中的所有服务器。
-
要检查的最后一条消息是 DHCPv6 回复消息。服务器从客户端收到 DHCPv6 请求消息后,将从本地地址池中分配一个 IPv6 地址。如果网络中有多台服务器,服务器标识符将用于标识哪个服务器将分配地址:
- 如前面的屏幕截图所示,DHCPv6 回复消息是携带 IPv6 地址的实际消息。此消息将从服务器单播到客户端。
它是如何工作的…
考虑下图,其中启用了从 DHCPv6 服务器接收 IPv6 地址的 DHCPv6 客户端将发送 DHCPv6 请求消息:
该消息是一个 UDP 数据包,目的端口为547
。DHCPv6 请求消息将被泛洪到 all-DHCPv6 组播地址ff02::1:2
。源地址将被设置为客户端的链路本地 IPv6 地址。
DHCPv6 服务器在收到请求消息后,将发送 DHCPv6 广告消息。此消息将被单播回 DHCPv6 客户端的链路本地地址。网络中可能存在一个或多个 DHCPv6 服务器,并且所有服务器都将发送 DHCPv6 广告消息。每个服务器都会在广告消息中包含自己的服务器 ID。
DHCPv6 客户端在接收到广告消息后将发送 DHCPv6 请求消息。该消息将携带一个服务器 ID,以识别请求地址分配的服务器。
DHCPv6 服务器将从本地地址池中分配一个 IPv6 地址,并发送带有前缀和相关详细信息(如前缀的生命周期)的 DHCPv6 回复消息。
以下是一些有用的过滤器:
怎么做…
- 在下图中,假设 PC1 (
2001:DB8::1
)正试图联系 PC2 (2001:DB8::2
):
IPv6 拓扑
-
从 PC1 到 PC2 触发 IPv6 ping 探针。这将触发从 PC1 到 PC2 的 IPv6 ND 邻居请求。
-
检查 PC1 上的本地 IPv6 邻居表,查看本地表中是否填充了
2001:DB8::2
的 MAC 地址。不同的供应商使用不同的 show 命令来查询本地表:- 在 macOS 中,使用
ndp -na
列出 IPv6 邻居的详细信息。 - 在 Windows 中,使用
netsh interface ipv6 show neighbor
。
- 在 macOS 中,使用
-
如果在 PC1 中看到
2001:DB8::2
的 MAC 地址,它确保 PC2 接收到来自 PC1 的 IPv6 邻居请求,并回复邻居广告
- 如果在 PC1 中没有看到
2001:DB8::2
的 MAC 地址,将 Wireshark 连接到交换机上的一个空闲端口并捕获数据包(使用端口镜像)。在连接 PC1 和 PC2: 的端口的入口和出口方向上执行捕获将是有用的
- 检查在捕获中是否看到来自 PC1 的 ICMPv6 邻居请求消息。前面的截图显示了来自 PC1 的消息。PC1 的 MAC 地址将包含在 IPv6 选项中:
- 如果在连接 PC1 (入口方向)的端口捕获中发现 ICMPv6 NS 数据包,但在连接 PC2 (出口方向)的端口捕获中没有发现,则交换机可能丢弃了该数据包。
- 如果在连接 PC1 的端口捕获上没有看到 ICMPv6 NS 数据包,检查连接 PC1 到交换机的物理电缆或者 PC1 的 NIC 端口。
- 如果在入口和出口捕获中都看到 ICMPv6 NS 数据包,但没有 ICMPv6 NA,请检查 PC2 。
- 同样,检查在从 PC2 的捕获中是否看到 ICMPv6 邻居广告数据包:
- 如果在连接 PC2 (入口方向)的端口捕获中发现 IPv6 NA 数据包,但在连接 PC1 (出口方向)的端口捕获中没有发现,则交换机可能丢弃了回复数据包。
- 如果在连接 PC2 (入口方向)的捕获端口上没有看到 IPv6 NA 数据包,请检查连接 PC2 到交换机的物理电缆。
- 如果在连接 PC1 和 PC2 的端口上的两个捕获中都看到 IPv6 NA 数据包,但是在 PC1 IPv6 邻居表中还没有条目,则检查 PC1 。
以下是一些有用的过滤器:
IPv6 重复地址检测
重复地址一直是 IPv4 网络中的一个难题。IPv4 没有内置的重复地址检测机制,这会导致生产网络出现问题。考虑到这些挑战,IPv6 设计了内置的重复地址检测(DAD) 机制。
它是如何工作的…
当主机使用静态或其他动态机制(如 SLAAC 或 DHCPv6)配置了 IPv6 地址时,主机会在将地址分配给接口之前向新的 IPv6 地址发送 ICMPv6 NS 消息。如果为 DAD 验证的地址是主机唯一可用的 IPv6 地址,则发送的 NS 消息将带有全零 IPv6 地址,如以下屏幕截图所示:
如 ND 部分所述,NS 消息将被发送到被请求的节点多播地址。如果它收到来自任何节点的响应,主机将检测到具有相同地址的另一台主机的存在,因此它不会分配这个重复的地址。如果它没有从任何主机收到任何 NA,则分配和使用 IPv6 地址是安全的。
十一、传输层协议分析
在本章中,您将了解:
- UDP 操作原理
- UDP 协议分析及故障排除
- TCP 操作原理
- TCP 连接问题故障排除
- TCP 重新传输问题疑难解答
- TCP 滑动窗口机制
- TCP 增强–选择性 ACK 和时间戳
- TCP 吞吐量故障排除
介绍
在本章中,我们将主要关注 OSI 参考模型的传输层,并学习如何分析各种第 4 层协议(TCP/UDP/SCTP)的运行。传输层协议是主机到主机的通信协议,负责不同主机上运行的终端应用之间的数据交换。用户数据报协议 ( UDP )是一种简单的无连接协议,它只是将数据报传递给预定的接收者,没有任何可靠性机制。另一方面,传输控制协议 ( TCP )是面向连接的协议,其主要目的是在终端应用之间提供可靠的、拥塞感知的数据传输。
超过 80%的互联网总流量利用 TCP 作为传输层协议。任何对丢包敏感的终端应用都需要可靠性,这类应用使用 TCP 作为传输层协议。例如,使用 HTTP 的 web 服务器使用 TCP 端口80
。虽然 TCP 提供了可靠性,但它需要重新传输丢失的数据;这可能会引入抖动和延迟。一些终端应用,如 IP 语音/视频,对丢包不太敏感,但对抖动/延迟更敏感。此类应用使用 UDP 而不是 TCP 作为传输层协议。
在本章中,我们将讨论不同传输层协议的基本原理、常见问题以及如何使用 Wireshark 来分析协议并排除故障。
UDP 操作原理
UDP 是一种轻量级传输层协议,它基于最大努力工作。对于可以容忍数据包丢失的终端应用,或者如果可以在应用层考虑可靠性,UDP 是传输层协议的一个很好的选择。例如,小文件传输协议 ( TFTP ),这是一个简单的文件传输协议,利用 UDP 作为传输层协议。TFTP 会对应用层收到的每个数据报块发送确认。因此,即使 UDP 没有内置的可靠性机制,这样的应用仍然可以使用 UDP 作为传输层协议。
对于 UDP,IP 报头的协议字段将被设置为17
。UDP 报头的格式如下:
图 11.1: UDP 报头格式
发起 UDP 流的主机将使用从范围1024
到65535
的任何本地未使用的端口。目的端口将用于识别目的主机中的终端应用。目的港通常是从众所周知的1
到1023
。
下表列出了一些众所周知的 UDP 应用端口:
表 11.2:众所周知的 UDP 应用
以下是 Wireshark 捕获 UDP 数据包的示例:
图 11.3: UDP 数据包 Wireshark 捕获
UDP 协议分析及故障排除
虽然大多数使用 UDP 的应用可以容忍数据包丢失,但是任何 UDP 流的大量数据包丢失都可能导致非常令人沮丧的最终用户体验。在本节中,我们将讨论 UDP 流故障的一些常见原因,以及如何使用 Wireshark 来分析和排除此类故障。
做好准备
当 UDP 流运行不正常时,第一步是确保到远程主机的网络连接工作正常。这可以通过使用实用工具(如 Ping 或 Traceroute)来验证。可以按照第 10 章、网络层协议和操作中的定义对网络连接中的任何故障进行故障排除。如果网络连接正常,我们执行以下步骤。
怎么做…
图 11.4: UDP 拓扑
在上图中,在 PC1 ( 10.1.100.101
)和 PC3 ( 10.1.200.101
)之间使用 UDP 流的终端应用运行不正常:
-
确保防火墙或其他安全设置允许 UDP 端口。传输路径中或端点上不允许 UDP 端口的防火墙可能会丢弃数据包。
-
获取 PC1 向其发送数据的 UDP 目的端口,并检查 PC3 上的相关 UDP 端口是否已打开以接收数据。这可以通过检查 PC3 上的进程或执行端口扫描来完成。
-
当可以访问 PC3 时,可以在主机上直接使用
netstat
,可以检查目的端口是否打开。 -
当无法访问 PC3 时,可以使用端口扫描机制进行检查。有各种端口扫描工具可用于此目的。如果端口没有在 PC3 上打开,它将丢弃数据包并发送 ICMP 错误消息(目的端口不可达)。
-
如果端口打开,下一步是执行 Wireshark 捕获和数据包分析。由于 UDP 是无连接的,因此建议在尽可能靠近两个端点的地方同时捕获数据包。
图 11.5 UDP 校验和
在前面的屏幕截图中,检查 UDP 校验和是否正确。如果校验和未通过验证,目的主机将会丢弃该数据包。由于 UDP 是无连接的,因此不会发送任何关于校验和错误的错误消息或确认。默认情况下,Wireshark 可能不会验证捕获中的校验和。这需要在工具中启用,如下所示:
-
转到编辑并点击首选项。
-
单击协议,然后选择 UDP。
-
如果可能,设置验证 UDP 校验和。
-
如果 UDP 校验和正常,比较两次捕获的 UDP 流,确保数据包到达目的地:
图 11.6: UDP 流索引
- Wireshark 允许我们跟踪特定的 UDP 流,该流可用于在捕获之间进行比较。每个捕获都有一个 UDP 流索引号,如前面的屏幕截图所示。这可以用作过滤器来跟踪 UDP 流。它基本上按接收顺序列出了具有相同源/目的 IP 和源/目的 UDP 端口的所有数据包。
- 如果在比较的捕获中没有观察到问题,则可能是主机堆栈中的问题。
以下是一些有用的 UDP 过滤器:
TCP 操作原理
TCP 是一种高度可靠的传输层协议,用于面向连接的主机到主机通信。对数据丢失非常敏感的终端应用可以利用 TCP 作为传输层协议。大多数互联网流量由 TCP 控制。它被许多应用广泛使用,包括电子邮件、对等文件共享和著名的 WWW 应用。TCP 从应用层接收数据,并将其分割成数据单元,这些数据单元将与 TCP 报头封装在一起。封装了 TCP 报头的协议数据单元称为段。如前所述,TCP 是面向连接的,因此将使用三次握手在端点之间建立连接。可靠性是通过确认每个数据段的接收方来实现的,任何丢失的数据段都将被重新传输。
对于 TCP,IP 报头的协议字段将被设置为6
。TCP 报头的格式如下:
图 11.7: TCP 报头格式
与固定 8 字节报头的 UDP 报头相比,TCP 的大小为 20 字节。根据 TCP 选项的存在,大小可能会有所不同。序列号和确认号在为终端应用数据传输提供可靠性方面起着关键作用。更多细节将在接下来的食谱章节中介绍。
下表列出了一些众所周知的 UDP 应用端口:
表 11.8:众所周知的 UDP 应用
以下是 Wireshark 捕获 TCP 数据包的示例:
图 11.9: TCP 数据包捕获
TCP 连接问题故障排除
当两个 TCP 进程希望通信时,它们打开连接,发送数据,然后关闭连接。当您打开浏览器连接到互联网,并从您的邮件客户端连接到邮件服务器,或者通过 Telnet 连接到您的路由器或任何其他通过 TCP 工作的应用时,就会发生这种情况。
当 TCP 打开连接时,它从源端口向目的端口发送一个打开连接的请求。在应用的建立或关闭过程中可能会出现一些问题。使用 Wireshark 来定位和解决这些问题是这个菜谱的目标。
做好准备
如果您遇到以下问题之一,请使用 Wireshark 找出原因。这些问题可能有多种类型,如下所示:
- 您尝试运行一个应用,但它不起作用。你试着浏览互联网,你没有得到任何回应。
- 您尝试使用您的邮件,但无法连接到邮件服务器。
- 问题可能是由简单的原因引起的,例如服务器关闭,应用没有在服务器上运行,或者网络在通往服务器的途中出现故障。
- 问题也可能是由更复杂的原因引起的,例如 DNS 问题、服务器上的内存不足使您无法连接(例如,由于应用的高内存消耗)、重复的 IP 以及许多其他原因。
在这个食谱中,我们关注这些去/不去的问题;它们通常很容易解决。
怎么做…
在这里,您将了解一些指标,以及使用 Wireshark 调试 TCP 连接问题时可以看到的情况。通常,这些问题会导致您尝试运行一个应用却没有任何结果。
当您尝试运行一个应用(例如,一个数据库客户端、一个邮件客户端、监视摄像机服务器等)而没有得到任何输出时,请按照下列步骤操作:
- 验证服务器和应用正在运行。
- 验证您的客户端正在运行,您已经配置了 IP 地址(手动或通过 DHCP),并且您已连接到网络。
- 对服务器执行 Ping 命令,并验证您已连接到该服务器。
- 在捕获文件中,查找以下模式之一:
- 没有响应的三次 SYN 消息
- 带有复位 ( RST )响应的 SYN 消息
在这两种情况下,可能是防火墙阻止了特定的应用,或者该应用没有运行。
在下面的截图中,我们看到了一个简单的例子,我们无法访问 web 服务器81.218.31.171
(数据包61
、62
和63
)。这可能是因为防火墙不允许,或者只是因为服务器有问题。我们也可以看到我们有一个到另一个网站的连接(108.160.163.43
;数据包65
、66
、67
),所以连接问题只出在81.218.31.171
上。
在下图中,我们看到了相同情况的一个稍微复杂一点的例子。在这种情况下,我们有一个摄像机服务器,客户希望登录并在远程站点上观看摄像机。摄像机的服务器有 IP 地址135.82.12.1
,问题是客户可以通过登录窗口获得服务器的主网页,但无法登录系统。在下面的截图中,我们可以看到我们打开了一个到 IP 地址135.82.12.1
的连接。我们可以看到一个到 HTTP 服务器的 TCP 连接已经打开,起初看起来没有连接问题:
当我们将所有流量过滤到 IP 地址135.82.12.1
,即摄像机服务器时,问题就出现了。
在这里,我们可以看到,当我们尝试连接到 TCP 端口6036
时,我们得到一个 RST/ACK 响应,这可能是由于以下原因:
- 阻止端口
6036
的防火墙(这里就是这种情况) - 当配置了端口地址转换 ( PAT )并且我们只转换端口
80
而不转换6036
时 - 用户名和密码的验证是在 TCP 端口
6036
上完成的,防火墙只允许端口80
,验证被阻止,应用无法工作
总而言之,当您无法连接到服务器时,请检查服务器和客户端,查看是否所有的 TCP/UDP 端口都在整个网络中转发,以及是否有您不知道的端口。
在某些情况下,当您在网络中安装新的应用时,最好连接客户端和服务器上的 Wireshark,并检查它们之间实际运行的内容。软件公司不会总是告诉你他们实际上在网络上传输什么(有时这是因为他们不知道!)和防火墙可以阻止你不知道的信息。
它是如何工作的…
启动 TCP 连接,如下图所示:
它分三步进行:
- 客户端的 TCP 进程发送一个 SYN 数据包。这是一个 SYN 标志设置为
1
的数据包。在此数据包中,客户端:- 指定其初始序列号。这是客户端发送给服务器的第一个字节的编号。
- 指定其窗口大小。这是客户端分配给进程的缓冲区(在客户端 RAM 中的位置)。
- 设置它将使用的选项:MSS、选择性 ACK 等。
- 当服务器接收到建立连接的请求时,服务器:
- 向客户端发送 SYN/ACK 数据包,确认接受 SYN 请求。
- 指定服务器的初始序列号。这是服务器发送给客户端的第一个字节的编号。
- 指定服务器的窗口大小。这是服务器分配给进程的缓冲区大小(在服务器 RAM 中的位置)。
- 响应请求的选项,并在服务器端设置选项。
- 当接收到服务器的 SYN/ACK 时,客户端:
- 向服务器发送 ACK 数据包,确认接受来自服务器的 SYN/ACK 数据包。
- 指定客户端的窗口大小。这是客户端分配给进程的缓冲区大小。虽然这个参数是在第一个数据包(SYN 数据包)中定义的,但是服务器将引用这个参数,因为它是服务器接收到的最新窗口大小。
在 TCP 报头的选项字段中,我们有以下主要选项:
- 最大段尺寸 ( MSS ):这是 TCP 数据报的最大尺寸,也就是从 TCP 头开始到整个包结束的字节数。
- 窗口大小 ( WSopt ):该因子与 TCP 报头中的窗口大小字段相乘,以通知接收方有更大的缓冲区。由于标头中的最大窗口大小是 64 KB,因此因子 4 等于 64 KB 乘以 4,即 256 KB 的窗口大小。
- SACK :选择性确认(Selective ACK)是一个选项,使连接双方能够确认特定的数据包,所以当单个数据包丢失时,只会再次发送这个数据包。连接双方必须就连接建立中的 SACK 达成一致。
- 时间戳选项 ( TSopt ):这个参数在本章前面已经解释过了,指的是客户端和服务器之间的延迟测量。
到了这个阶段,双方:
- 同意建立联系
- 知道对方的初始序列号
- 知道对方的窗口大小
在建立连接时,除了完全的三次握手之外的任何事情都应该被认为是一个问题。这包括没有响应的 SYN、SYN 然后 SYN/ACK 和没有最后 ACK、用复位(RST 标志等于 1)应答的 SYN 等等。
Wireshark 允许用户以图形方式查看 TCP 数据段交换的完整流程。示例如下:
要查看上述格式的 TCP 流,请单击属于该 TCP 流的一个数据包,并执行以下操作:
- 转到统计
- 点击流程图
还有更多…
一些经验法则如下:
- 如果一个 SYN 数据包被 RST 应答,查找阻止端口号的防火墙。
- 没有任何响应的三重 SYN 的出现,要么是由于应用没有响应,要么是防火墙阻止了特定端口上的请求。
- 始终验证您是否拥有网络地址转换 ( NAT )、端口转发以及使用 TCP 或 UDP 端口的机制。这些机制会干扰 TCP 的标准操作。
当 TCP 端点建立新的 TCP 连接时,SYN 数据包中的序列号将以任意数字开始,并且每 1 个字节递增 1。为了便于分析,Wireshark 将序列号替换为相对序列号,使得 SYN 数据包从序列号 0 开始,并按顺序递增。
在前面的截图中,可以观察到序列号被设置为 0,并标记为(相对序列号)。这不是 TCP 端点交换的真实序列号。通过禁用协议首选项中的相对序列号选项,可以保留原始序列号。
请按照下列步骤禁用该选项:
- 前往偏好设置
- 点击协议,然后选择 TCP
- 禁用相对序列号
TCP 重新传输问题疑难解答
当 TCP 发送一个包或一组包时(参考它是如何工作的…在这个配方的末尾,它等待一个确认来确认这些包的接受。重传显然是由于没有到达的分组或者没有按时到达的确认而发生的。这可能有各种各样的原因,找到正确的原因是这个食谱的目标。
做好准备
当您发现网络变慢时,原因之一可能是重新传输。将端口镜像中的 Wireshark 连接到可疑的客户端或服务器,并观察结果。
在本菜谱中,我们将看到 Wireshark 可能会遇到的一些常见问题以及这些问题的含义。
怎么做…
让我们开始吧:
- 开始在相关接口上捕获数据。
- 转到分析|专家信息菜单。
- 在“注释”下,查找重新传输。
- 您可以单击(+)号,将会打开一个重新传输列表。在每一行上单击鼠标,就会在数据包捕获窗格中显示重新传输。
- 现在重要的问题来了:如何定位问题?
当您通过通信线路、服务器接口、互联网链接或任何其他线路捕获数据包时,您可能会收到来自多个 IP 地址、多个应用甚至每个应用上特定程序的流量。例如,在数据库应用中访问特定的表。这里重要的是定位发生重新传输的 TCP 连接。
您可以通过以下方式查看重新传输的来源:
- 在专家信息窗口中逐个移动数据包,并在数据包捕获窗格中找出哪些数据包(适合有经验的用户)
- 在 packet 窗格中,您可以配置显示过滤器
expert.message == "Retransmission (suspected)"
,您将在捕获文件中获得所有的重新传输 - 应用过滤器,然后在“Statistics à Conversations”窗口的右下角选中“Limit to display filter”部分
案例 1–向多个目的地重新传输
在下面的屏幕截图中,您可以看到我们已经在许多服务器之间进行了多次重新传输,目的端口为80
(HTTP)。从这里我们还可以看到的是10.0.0.5
端口发送重传;因此,数据包在通往互联网的途中丢失了,或者网络服务器没有及时发回确认信息。
嗯,很明显网络线路出了问题。我们怎么知道它是什么?
- 从统计菜单中,打开 IO 图。
- 在这种情况下(情况 1),我们可以看到该行几乎是空的。这可能是一个错误或另一个加载到互联网上的线路。
- 您可以通过登录到通信设备或任何 SNMP 浏览器(当设备上配置了 SNMP 代理时)来检查丢包和导致丢包的错误。查看以下截图供参考:
情况 2–单个连接上的重新传输
如果所有的重新传输都在一个 IP 上,只有一个 TCP 端口号,这将是一个缓慢的应用。我们可以在下面的截图中看到这一点:
对于单个连接上的重新传输,请执行以下步骤:
- 我们也可以通过从“统计”菜单打开“对话”并选择“限制显示过滤器”复选框来验证这一点。我们将获得所有有重新传输的会话,在这种情况下,只有一个会话。
- 通过选择 IPv4:1 选项卡,如下面的屏幕截图所示,我们将看到我们从哪些 IP 地址获得重新传输:
- 通过选择 TCP:6 选项卡,如下图所示,我们将看到从哪个端口号(或应用)获得重新传输:
要找出问题,请执行以下步骤:
- 查看 IO 图,确保线路不忙。
繁忙通信线路的指示将是非常接近线路最大带宽的直线。例如,如果您有一条 10 Mbps 的通信线路,您可以对其进行端口镜像,并在 IO 图中看到一条接近 10 Mbps 的直线。这是负载线的良好指示。一条非繁忙的通信线路会有许多起伏、峰值和空白间隔。
- 如果线路不忙,这可能是 IP 地址
10.1.1.200
的服务器上的问题(10.90.30.12
正在发送大部分重新传输,因此可能是10.1.1.200
响应缓慢)。 - 从数据包窗格中,我们可以看到该应用是 FTP-DATA。FTP 服务器可能在活动模式下工作。因此,我们在一个端口(
2350
)上打开了一个连接,服务器将端口更改为1972
,因此它可能是一个缓慢的无响应 FTP 软件(这最终是这里的问题)。
案例 3–重传模式
在 TCP 重传中需要注意的一件重要事情是,重传是否有你可以看到的任何模式。
在下面的屏幕截图中,我们可以看到所有的重新传输都来自单个客户端和服务器上的 NetBIOS 会话服务(TCP 端口139
)之间的单个连接。
看起来像是一个简单的服务器/应用问题,但是当我们查看数据包捕获窗格时,我们可以看到一些有趣的东西(参考下面的截图):
有趣的是,当我们观察重新传输的模式时,我们可以看到它们每 30 毫秒循环发生一次。这里的时间格式是秒,因为之前显示的数据包和时间刻度都是以秒为单位的。
这个案例中的问题是,一个客户在软件中执行了一个财务程序,导致软件每 30-36 毫秒变慢一次。
案例 4–由于无响应的应用导致的重新传输
重新传输的另一个原因可能是客户端或服务器没有响应请求。在这种情况下,您将看到五次重新传输,时间差不断增加。在这五次连续的重新传输之后,发送方认为连接丢失(在某些情况下,将发送 reset 来关闭连接,这取决于软件实现)。断开连接后,可能会发生两件事:
- 客户端将发送一个 SYN 请求来打开一个新的连接。在这种情况下,用户将看到应用冻结,15-20 秒后,它将再次开始工作。
- 不会发送 SYN,用户将不得不再次运行应用(或它的特定部分)。
在下面的截图中,我们可以看到一个打开新连接的情况:
情况 5 -由于延迟变化导致的重传
TCP 是一种只要延迟不变就能容忍延迟的协议。当延迟发生变化时,您可以期待重新传输。确定这是否是问题所在的方法如下:
- 当然,首先要做的是 ping 目的地,并获得通信线路延迟的第一条信息。看看*它是如何工作的…*一节看看应该怎么做。
- 检查延迟变化,这可能是由于以下原因造成的:
- 不稳定或繁忙的通信线路。在这种情况下,您将使用
ping
命令看到延迟变化。它通常发生在带宽较窄的线路上,有时也发生在蜂窝线路上。 - 负载过重或效率低下的应用。在这种情况下,您将只看到这个特定应用的许多重新传输。
- 加载的通信设备(CPU 负载、缓冲器负载等)。您可以通过直接访问通信设备来检查这一点。
- 不稳定或繁忙的通信线路。在这种情况下,您将使用
- 使用 Wireshark 工具,如第 18 章、中所述,排除带宽和延迟问题。
TCP 重新传输的底线是,只要我们没有太多的重新传输,重新传输是 TCP 的自然行为。当重新传输约为 0.5%时,性能将开始下降,而断开连接将在约为 5%时开始。它还取决于应用及其对重传的敏感性。
找出它是什么
当您在通信链路(到互联网、服务器、站点之间或任何其他链路)上看到重新传输时,请执行以下步骤:
- 找到问题所在。是特定的 IP 地址,特定的连接,特定的应用,还是其他什么问题?
- 检查问题是由于通信链路、数据包丢失还是服务器或 PC 速度慢。检查应用是否缓慢。
- 如果不是由于上述原因,请检查延迟变化。
它是如何工作的…
我们来看看 TCP 的常规操作,以及可能出现的问题的原因。
TCP 序列/确认机制的常规操作
TCP 内置的机制之一是重新传输机制。这种机制支持恢复损坏、丢失、重复或无序交付的数据。
这是通过给每个传输的字节分配一个序列号,并期待来自接收方的确认 ( ACK )来实现的。如果在超时间隔内没有收到 ACK,数据将被重新传输。
在接收端,序列号用于验证信息是否按照发送的顺序到达。如果没有,请将其重新排列到之前的状态。
该机制的工作原理如下:
-
在连接建立时,双方告诉对方他们的初始序列号是多少。
-
发送数据时,每个数据包都有一个序列号。序列号表示 TCP 有效负载中第一个字节的编号。发送的下一个包将具有前一个包的序列号加上前一个包中的字节数加 1(在下一个屏幕截图中)。
-
当一个包被发送时,重传超时 ( RTO )计数器开始从它被发送的时刻开始计数时间。
重传超时计时器基于 Van Jacobson 拥塞避免和控制算法,该算法基本上认为 TCP 可以容忍高延迟,但不能容忍快速延迟变化。
- 当接收方收到数据包时,它会用 ACK 数据包进行应答,告知发送方发送下一个数据包。在下面的截图中,您将看到它是如何工作的:
从这里可以看到10.0.0.7
正在从62.219.24.171
下载一个文件。该文件通过 HTTP 下载(Wireshark 窗口被配置为显示编辑|首选项列配置中的tcp.seq
和tcp.ack
,如第 1 章、Wireshark v2 简介中所述)。
从这里,62.219.24.171
发送序列号以85101, 86557
结尾的数据包,之后10.0.0.7
发回一个 ACK,告诉发送者发送以88009
结尾的数据包。然后发送者发送它。诸如此类。
你可以在这里看到一个例子:
什么是 TCP 重新传输,它们会导致什么?
当数据包确认丢失或 ACK 没有按时到达时,发送方将执行两项操作:
- 再次发送数据包,如本菜谱前面所述
- 降低吞吐量
在下一个屏幕截图中,我们看到了一个降低发送方吞吐量的重新传输示例(为清晰起见,添加了红色细线):
还有更多…
TCP 可以容忍高延迟,只要它们相当稳定。定义 TCP 在延迟变化下的行为的算法被称为 Van Jacobson 算法,以其发明者的名字命名。Van Jacobson 算法允许高达平均延迟 3-4 倍的容差;因此,例如,如果您有 100 毫秒的延迟,那么 TCP 将容忍高达 300-400 毫秒的延迟,只要它们不经常改变。
请参见
- 你可以在 http://ee.lbl.gov/papers/congavoid.pdf 查看范·雅各布森算法
TCP 滑动窗口机制
当端点建立 TCP 会话时,TCP 报头中的窗口大小字段将用于通知接收缓冲区容量,并控制可以接收和处理的数据量。每个端点将维护一个本地接收窗口 ( RWND )。这是接收器可以接收用于缓冲和处理的最大数据量。端点会将此 RWND 值包含在 TCP 报头中。发送方使用 RWND 作为输入来决定滑动窗口的大小。它可以在等待确认之前向窗口大小中定义的对等体发送 TCP 数据段。
发送方端点通过管理等待确认的未完成 TCP 数据段的数量来维护滑动窗口。当发送方收到已发送数据段的 ACK 并等待确认时,它会向右滑动窗口。
如果没有滑动窗口机制,TCP 发送方将会一次发送一个数据段,并在发送下一个数据段之前等待确认,从而对整个 TCP 吞吐量产生重大影响。
做好准备
连接服务器上的 Wireshark 并捕获数据包。通过过滤特定的 TCP 流来分析滑动窗口行为要容易得多。为了跟踪特定的流,选择要分析的流的第一个 TCP 包(SYN 包),并执行以下操作:
- 去分析
- 选择关注
- 选择 TCP 流
怎么做…
在以下拓扑中,PC1 正在与 PC3 建立 TCP 会话以传输数据。
检查 TCP 端点是否正在用大于 0 的值交换 TCP 窗口大小。如果窗口大小设置为 0,接收器将无法接收任何流量,数据传输将会失败。
前面是 TCP 零窗口的一个例子。接收节点(10.0.0.9
)不能接受任何新的会话或数据,因此当它从任何对等方接收到新 TCP 会话的 SYN 段时,它用 SYN,ACK 段进行回复,并将窗口大小设置为 0。通常情况下,一旦接收器准备好接收额外数据,这种情况就会自行纠正。当接收方发送零窗口消息时,看到发送方发送 TCP 零窗口探测是正常的。这是发送方发送的消息,用于查看接收方的零窗口条件是否仍然为真。对于从 TCP 零窗口消息的接收器接收的每个响应,它在发送下一个探测消息之前指数地递增计时器。
如果数据包捕获持续显示接收方正在以窗口大小为 0 发送,则可能表明终端服务器运行不正常,或者传入端口缓冲区已满或被阻塞,可能需要在服务器端进行额外的分析来解决任何问题。
一旦服务器上的问题得到解决,它应该能够协商正确的窗口大小。在前面的示例中,10.0.0.1
在 SYN,ACK 段中使用非零窗口大小进行回复。可以注意到,服务器还包括一个 TCP 选项,它携带值为9
的窗口比例。TCP 对等体将使用窗口大小和窗口比例的组合来识别滑动窗口大小。关于窗口缩放的更多细节在*中…*一节。
在所有后续数据包中,每个对等体都将包括窗口大小,对等体将使用该窗口大小来放大或缩小滑动窗口大小。
它是如何工作的…
TCP 滑动窗口机制的工作原理如下:
- 连接建立后,发送方向接收方发送数据,填满接收方窗口。
- 几个数据包之后,接收方向发送方发送 ACK,确认接收到发送方发送的字节。发送 ACK 会清空接收器窗口。
- 当发送方填充窗口时,这个过程是连续的,接收方清空窗口并发送信息确认。
- 增大接收方窗口大小会告诉发送方增加吞吐量,而减小接收方窗口大小会告诉发送方减少吞吐量。它根据以下 WS/RTT 规则工作(根据 TCP 版本有一些变化):
TCP 报头中的窗口大小字段以字节表示,并且该字段是允许携带最大值 65,535 的 16 位字段。对于大多数硬件,可以处理超过 65,535 字节的 TCP 数据段。为了发出大于 65,535 的窗口大小的信号,在初始 TCP 三次握手期间包括 TCP 窗口比例。TCP 对等使用窗口大小值和比例值来导出窗口大小。
例如,当窗口大小设置为 457 并且比例值设置为 6 时,滑动窗口将被计算为 29,248 字节。
Wireshark 计算滑动窗口,并将其显示为前面示例中突出显示的内容。
TCP 增强–选择性 ACK 和时间戳
一段时间以来,已经引入了各种 TCP 增强来增强 TCP 性能。在本节中,我们将讨论这些重要的增强功能,并了解如何使用 Wireshark 进行分析。
做好准备
当您观察到 TCP 流性能下降并且不能按预期工作时,请连接 Wireshark 以捕获 TCP 流进行分析。
怎么做…
为了向后兼容,类似于选择性确认 ( SACK )或 TCP 时间戳的功能增强将在最初的三次握手期间进行协商。TCP 端点将在 SYN 和 SYN/ACK 数据包中包含相关的 TCP 选项。
TCP 选择性确认选项
TCP SACK 是一个 TCP 选项,将包含在 SYN 和 SYN/ACK 段中。当 TCP 端点启用了 TCP SACK 功能时,端点通过在 SYN 数据包中包含该功能来通知对等端的能力。
如前例所示,TCP SACK 选项将出现在 SYN 和 SYN/ACK 数据段中。如果在捕获中没有看到此 TCP 选项,请确保在 TCP 端点上启用了该功能。根据供应商和平台的不同,默认情况下可能会启用此功能。
当接收方想要选择性地确认某些数据段时,它会在 SACK 选项中包含相关的序列号。在前面的例子中,接收方确认它正在等待序列号为3321
的数据段。但也包括同一段中序号为3845
到4369
的 SACK。关于 SACK 如何工作的更多细节,请查看*它是如何工作的…*一节。
TCP 时间戳选项
与 TCP SACK 一样,TCP timestamp 是一个 TCP 选项,将包含在 SYN 和 SYN/ACK 数据段中。当 TCP 端点启用了 RTT 测量功能时,端点会向对等方发出在 SYN 数据包中包含 TCP 时间戳的信号。当两个端点都支持此功能时,发送方将在转发给对等方的所有数据段中包含 TCP 时间戳选项。
如前例所示,TCP 时间戳选项将出现在 SYN 和 SYN/ACK 数据段中。如果在捕获中没有看到此 TCP 选项,请确保在 TCP 端点上启用了该功能。根据供应商和平台的不同,默认情况下可能会启用此功能。
如前面的屏幕截图所示,发送方在发送数据段时会在 TSval 字段中包含当地时间。发送方将在时间戳回应回复 ( TSecr )中包含一个零值。
接收方应仅在 Ack 包中包含 TSecr。如前面的示例所示,接收方在回复时包含了 TSecr 和 TSval。发送方将使用这两者的组合来导出 RTT 值。关于该功能的更多细节,请参见*它是如何工作的…*一节。
它是如何工作的…
TCP 选择性确认
在前面几节中,我们讨论了 TCP 序列号和确认号如何帮助为最终应用提供可靠性。但是默认确认和重传行为不是吞吐量有效的,这是由于 TCP 要求从滑动窗口内的丢失段重传所有段的性质。下面的插图有助于我们更好地理解默认行为。
举例来说,我们使用一个窗口大小为五段的 TCP 会话。根据窗口大小,发送方在等待确认之前可以发送五个数据段。因此,它发送五个段,其中 seq=2,3,4,5,6 。接收器已经接收到具有序列=2,4,5,6 的段,但是它没有接收到具有序列=3 的段。发送 ACK 时,接收器发送 ack=3 。如前所述,ender 不仅会重新传输带有 seq=3 的段,还会重新传输窗口中的剩余段。
这会导致重复数据段的重新传输,从而导致吞吐量问题。
选择性确认通过允许接收器选择性地确认不连续的数据段来解决这个问题。TCP SACK 是一个 TCP 选项,将在初始 TCP 三次握手期间进行协商。
在同一个示例中,发送方和接收方都启用了 TCP SACK。请注意,TCP SACK 将包含在 SYN 数据段中,以向对等方发送信号。使用相同的例子,当接收器没有接收到具有 seq=3 的段时,它发送具有 ack=3 的 ack 段,但是它还包括针对 4、5、6 的选择性 ACK。这将指示发送方只发送丢失的数据段,而不重新传输其他接收到的数据段。这避免了重复,并有助于提供高效的吞吐量。
TCP 时间戳
某些终端应用受益于连续的往返时间()测量。RTT 测量通过利用 TCP 时间戳选项来执行。TCP 时间戳选项将包含在所有数据段中。该选项带有两个字段,即 TSval 和 TSecr。发送方将在 TSval 字段中包含发送数据段的本地时间,TSecr 将被设置为 0。接收方在确认数据段后,会在 TSval 中包含本地时间,并包含来自发送方的最后一个接收数据段的 TSval。
发送方将在 ACK 段中使用 TSval 和 TSecr 的组合来计算 RTT。为了效率,大多数实现将在每个窗口中一个或两个段中执行 RTT 测量,而不是在每个段的基础上执行。 **# 还有更多…
虽然上一节讨论了几个 TCP 选项,但是还有更多这样的选项用于不同的目的。以下是几个选项:
- TCP 认证
- 最大段尺寸
- TCP 压缩过滤器
- 多路径 TCP
TCP 吞吐量故障排除
行业中有各种工具可用于执行网络吞吐量测量,这些工具本质上更多是带外的。此类工具建立测试 TCP 会话,并由监视器执行。虽然这些工具很有用,但性能计算是在生产流量上进行的。使用 TCP 作为传输协议的 SLA 受限的终端应用需要一种机制来确保 TCP 流达到期望的吞吐量。为了证实这一点,我们需要一种简单有效的机制来测量每个 TCP 流的吞吐量。这可以用于各种目的,包括性能基准测试、基于 SLA 的服务保证等等。
有许多原因可能会影响 TCP 吞吐量的性能,其中一些原因已在前面的章节中讨论过,如重新传输、会话重置。在本节中,我们将讨论如何使用 Wireshark 来执行 TCP 吞吐量测量和分析。
做好准备
为了执行吞吐量测量,您必须做的第一件事是捕获流。您可以在终端服务器(如果支持的话)或传输路径上执行捕获。如前所述,使用相关过滤器仅显示要测量的 TCP 流。
怎么做…
- 检查正在测量的 TCP 流的吞吐量。这是通过过滤相应的 TCP 流,然后检查 IO 图的吞吐量来实现的。以下是查看吞吐量图表的步骤。
- 转到统计并选择 IO 图形**。**
- 现在用
tcp.stream == <stream number>
过滤器创建一个新图形。 - 示例如下所示:
-
如果输出中显示的吞吐量符合预期,我们可以得出结论,该流工作正常。如果吞吐量不如预期,我们需要如下的额外分析。
-
检查窗口大小是否协商为更大的大小。如果 RWND 较小,可能会导致吞吐量较低,因为发送方将在滑动窗口内等待数据段的确认。
-
获取 TCP 流的专家信息,并检查不同错误和警告的数量。这有助于理解吞吐量的可能原因。有关专家信息的更多详情,请阅读第 6 章、使用高级统计工具。
- 在上图中,可以注意到有 173 个缺失数据段的实例和多个重复数据段的实例。专家信息将帮助我们提供诸如无序段、连接重置、零窗口等错误。
- 如果有许多
[TCP Retransmission]
丢失数据段的实例,网络中可能会有一些数据包丢失。使用ping
等网络连接检查工具来验证底层网络的健康状况。或者,在网络中的多个捕获点上捕获流将有助于缩小丢弃节点的范围。
- 如果存在大量无序分组的情况,则属于同一流的分组可能采用具有不同延迟/抖动的不同路径。理想情况下,路径上的所有节点将在流级别执行负载平衡,以便属于同一流的所有数据包将始终遵循同一路径。在涉及链路抖动(间歇或连续)或任何传统节点的情况下,执行每分组负载平衡可能会导致这种无序分组。
- 如果有许多 TCP 窗口满错误的实例,接收节点就不能以发送方发送的速率处理数据包。如果问题持续存在,可能需要在接收端仔细调整 RWND。
- 可以在端点上启用一些 TCP 增强功能,如更高的 RWND 大小、选择性 ACK、快速重传,以提高整体吞吐量。
它是如何工作的…
TCP 吞吐量没有特定的工作机制。TCP 吞吐量是端点上启用的各种 TCP 功能的结果。这些不同的特性是如何工作的已经在不同的*工作原理中介绍过了…TCP 主题下的部分。*