免责声明：

笔记的只是方便各位师傅学习知识，以下代码、网站只涉及学习内容，其他的都与本人无关，切莫逾越法律红线，否则后果自负。

泷羽sec官网：https://longyusec.com/

泷羽sec B站地址：https://space.bilibili.com/350329294

泷羽sec帮会：https://wiki.freebuf.com/front/societyFront?invitation_code=5a2005d9&society_id=239&source_data=2

---

WireShark基础

wireshark简介

wireshark是一个网络封包分析软件。网络封包分析软件的功能是撷取网络封包，并尽可能显示出最为详细的网络封包资料。wireshark使用WinPCAP作为接口，直接与网卡进行数据报文交换

WinPcap（Windows Packet Capture）是Windows平台下一个免费、公共的网络访问系统。

一、主要功能

WinPcap的主要功能在于独立于主机协议（如TCP/IP）而发送和接收原始数据包。具体来说，它包括以下功能：

1. 捕获原始数据包：能够捕获在共享网络上各主机发送、接收的以及相互之间交换的数据包。
2. 数据包过滤：在数据包发往应用程序之前，可以按照自定义的规则将某些特殊的数据包过滤掉。
3. 统计信息收集：能够收集网络通信过程中的统计信息。

需要注意的是，WinPcap不能阻塞、过滤或控制其他应用程序数据包的发送和接收，它仅仅只是监听共享网络上传送的数据包。因此，它不能用于QoS调度程序或个人防火墙。

二、内部结构与组件

WinPcap是针对Win32平台上的抓包和网络分析的一个架构，它包括以下几个主要组件：

1. 网络数据包过滤器（NPF，Netgroup Packet Filter）：

• 是WinPcap的核心部分，处理网络上传输的数据包，并且对用户级提供可捕获（capture）、发送（injection）和分析性能（analysis capabilities）。
• 它是一个设备驱动，运行在操作系统核心内部，直接与网络接口驱动交互。

2. 底层的动态链接库（packet.dll）：

• 提供了一个底层API，伴随着一个独立于Microsoft操作系统的编程接口。
• 这些API可以直接用来访问驱动的函数。

3. 高级的独立于系统的动态链接库（wpcap.dll）：

• 导出了一组更强大的与libpcap一致的高层抓包函数库（capture primitives）。
• 这些函数使得数据包的捕获以一种与网络硬件和操作系统无关的方式进行。

三、应用领域

WinPcap特别适用于以下经典领域：

1. 网络及协议分析：可以捕获和分析网络上的数据包，了解网络协议的工作原理。
2. 网络监控：可以实时监控网络上的数据包流动情况，确保网络安全和稳定性。
3. 通信日志记录：可以记录网络通信过程中的数据包信息，用于后续的审计和分析。
4. Traffic Generators：可以生成网络流量，用于测试网络的性能和容量。
5. 用户级别的桥路和路由：可以在用户级别实现网络桥接和路由功能。
6. 网络入侵检测系统（NIDS）：可以捕获和分析网络上的数据包，检测潜在的入侵行为。
7. 网络扫描：可以扫描网络上的主机和服务，了解网络拓扑结构和资源配置。

四、使用限制

WinPcap不依靠主机的诸如TCP/IP协议去收发数据包，因此它不能阻塞、不能处理同一台主机中各程序之间的通信数据。它只能“嗅探”到物理线路上的数据包，因此不适用于traffic shapers、QoS调度以及个人防火墙等领域。

---

wireshark的功能

• 用来做故障排查
• 用来学习网络技术

wireshark的安装

官网在这

下载及安装步骤相对简单，一直next安装即可。

点击Download之后，会进入到下面这个界面

我下载的是红框里的版本，但由于这是老外的网站，下载速度慢的离谱，所以我附上度盘链接，师傅们自取

---

安装完成之后，进入就是这个界面了

这里会列举出电脑上所配置的网卡，想抓哪个网卡的包，就双击对应网卡的名字即可。

如果说不知道所对应的网卡名称是什么的话，可以通过win+s快捷键，调出搜索界面，搜索网络连接，

通过查看网络连接找到对应网卡的名称。

例如我这里，就连接上了WLAN，那么就抓通过了WLAN的包。双击进入之后，即会显示若干数据包

WireShark快速分析数据包技巧

1. 确定WireShark的物理位置。如果没有一个正确的位置，启动WireShark后会花费很长的事件捕获一些与自己无关的数据
2. 选择捕获接口。一般都是选择连接到Internet网络的接口，这样才可以捕获到与网络相关的数据。否则，捕获到的其他数据对自己也没有帮助。
3. 使用捕获过滤器。通过设置捕获过滤器，可以避免产生过大的捕获数据。这样用户在分析数据时，也不会受其他数据干扰。而且，还可以为用户节约大量的时间。
4. 使用显示过滤器。通常使用捕获过滤器过滤后的数据，往往还是很复杂。为了使过滤的数据包更细致，此时使用显示过滤器进行过滤。
5. 使用着色规则。通常使用显示过滤器过滤后的数据，都是有用的数据包。如果像更加突出的显示某个会话，可以使用着色规则高亮显示。
6. 构建图表。如果用户想要更明显的看出一个网络中数据的变化情况。使用图表的形式可以很方便的展现数据分布情况。
7. 重组数据。当传输较大的图片或文件时。需要将信息分布在多个数据包中。这时候就需要使用种族数据的方法来抓取完整的数据。WireShark的重组功能，可以重组一个会话中不同数据包的信息；或者重组一个完整的图片或文件。

---

WireShark模式

混杂模式

混杂模式概述

混杂模式是接受所有经过网卡的数据包，包括不是发给本机的包，即不验证MAC地址。普通模式下网卡只接收发给本机的包(包括广播包)传递给上层程序，其他的包一律丢弃。

一般来说，混杂模式不会影响网卡的正常工作，多在网络监听工具上使用。

开启或关闭混杂模式

---

WireShark过滤器使用

例1：过滤TCP数据包

在过滤器处输入tcp或TCP，虽然不计大小写，但通常不要大小写混合输入，这样WireShark是不识别的。

基于三次握手做进一步过滤

通过在过滤器处输入tcp.flags.syn == 1或者其他三次握手包里存在的ack、fin都是通用的

例2：过滤UDP数据包

拓展：客户端向DNS服务器查询域名，一般返回的内容都不超过512字节，用UDP传数即可。不用经过三次握手，这样DNS服务器负载更低，响应更快。理论上说，客户端也可以指定向DNS服务器查询时用TCP，但事实上，很多DNS服务器进行配置的时候，仅支持UDP查询包。

DTLS：

一、定义与用途

• 定义：DTLS协议是在用户数据报协议（UDP）上实现的一种安全协议，它基于传输层安全（TLS）协议，但针对UDP的特性进行了优化和改进。
• 用途：为基于UDP的应用程序提供安全连接，确保数据在传输过程中的机密性、完整性和真实性。

二、技术特点

• 基于TLS：DTLS协议复用了TLS协议的大部分代码，但在处理UDP报文的丢包及重排序等方面进行了特定的优化。
• 支持实时通信：由于UDP具有实时性强的特点，DTLS也相应地支持实时通信，适用于对延迟要求较高的应用场景。
• 包丢失重传机制：为了应对UDP无重传机制的问题，DTLS实现了包丢失重传机制，确保数据的可靠传输。
• 身份认证与密钥协商：DTLS在握手过程中验证双方的身份，并使用RSA或DH（Diffie-Hellman）等算法实现会话密钥的建立，以便在后续的数据传输中对数据加密。

三、应用场景

• 物联网：在物联网设备之间建立安全连接，保护设备间的通信数据不被窃取或篡改。
• 视频会议：为视频会议提供安全通信保障，防止会议内容被泄露或干扰。
• 嵌入式系统：由于DTLS具有轻量化、开销小的特点，因此适用于嵌入式系统中的安全通信。

四、版本与发展

• DTLS 1.0：基于TLS 1.1，提供了数据报文协议的加密功能，适用于UDP等不可靠的传输协议。
• DTLS 1.2：基于TLS 1.2，提供了更好的安全性和性能。

QUIC：

QUIC是一种由Google设计的传输层协议，旨在提高互联网通信的速度和可靠性。它建立在UDP协议之上，但集成了TLS（传输层安全性）加密、多路复用和流控制等特性，以提供类似于TCP的可靠性，同时减少连接建立的延迟。

技术特点

1. 基于UDP：QUIC使用UDP作为底层传输协议，这使其能够绕过TCP的三次握手过程，从而显著降低连接建立的延迟。

2. 加密：QUIC集成了TLS加密，确保数据传输的安全性。这意味着所有通过QUIC传输的数据都是加密的，可以防止中间人攻击和数据泄露。

3. 多路复用：QUIC允许在单个连接上并行传输多个逻辑数据流。这意味着多个请求可以在同一个连接上同时发送和接收，而不需要为每个请求建立单独的连接。这提高了网络资源的利用率，并减少了连接建立的开销。

4. 流控制：QUIC实现了流控制机制，以确保发送方不会发送过多的数据而导致接收方缓冲区溢出。这有助于保持网络的稳定性和可靠性。

5. 连接迁移：QUIC支持连接迁移，即当客户端的网络地址发生变化时（例如，从Wi-Fi切换到4G网络），连接可以无缝地迁移到新的网络地址上，而不需要重新建立连接。这提高了连接的持续性和稳定性。

6. 0-RTT连接建立：在特定条件下，QUIC可以实现0-RTT（零往返时间）连接建立，即客户端可以在不等待服务器响应的情况下立即发送数据。这进一步降低了连接建立的延迟。

应用场景

QUIC协议广泛应用于需要高性能和低延迟的互联网通信场景，包括但不限于：

• Web浏览：QUIC可以显著提高网页加载速度，提升用户体验。
• 实时通信：QUIC的低延迟特性使其成为视频会议、在线游戏等实时通信应用的理想选择。
• CDN（内容分发网络）：QUIC可以提高CDN的效率和性能，加速内容的分发和传输。

标准化与实现

QUIC最初由Google开发并作为其内部实验性协议使用。随着其优越性的逐渐显现，QUIC被提交给互联网工程任务组（IETF）进行标准化。经过多次讨论和修订，IETF最终发布了标准化的QUIC协议，并将其作为HTTP/3的基础传输协议。目前，许多主流的浏览器和服务器都已经支持或计划支持QUIC协议。

例3：筛选源地址是192.168.1.6或者目的地址是192.168.1.1

在过滤器处输入ip.src_host == 192.168.1.6 or ip.dst_host == 192.168.1.1

ICMP（Internet Control Message Protocol），即因特网控制报文协议，是TCP/IP协议簇的一个子协议。以下是对ICMP协议的详细介绍：

一、定义与功能

ICMP协议主要用于在IP主机、路由器之间传递控制消息，这些控制消息涉及网络通不通、主机是否可达、路由是否可用等网络本身的消息。虽然ICMP并不直接传输用户数据，但它对于用户数据的传递起着重要的作用。ICMP使用IP的基本支持，并作为IP的一个组成部分存在，必须由每个IP模块实现。

二、工作原理

ICMP协议是一种面向无连接的协议，它主要用于传输出错报告控制信息。当网络中数据包传输出现问题时，如IP数据无法访问目标、IP路由器无法按当前的传输速率转发数据包等情况，主机或设备就会使用ICMP向上层协议报告差错情况和提供有关异常情况的报告。这使得上层协议能够通过自己的差错控制程序来判断通信是否正确，从而进行流量控制和差错控制，保证服务质量。

三、报文格式与类型

ICMP报文包含在IP数据报中，属于IP的一个用户。一个ICMP报文包括IP头部、ICMP头部和ICMP报文数据部分。其中，IP头部就在ICMP报文的前面，ICMP头部中的类型（Type）域用于说明ICMP报文的作用及格式，此外还有一个代码（Code）域用于详细说明某种ICMP报文的类型。

ICMP有多种类型，每种类型有多个代码，用于表示不同的错误和控制信息。常见的ICMP类型包括：

1. 回显请求和回显应答：用于测试网络的连通性和性能。当主机收到一个回显请求时，会返回一个相同的回显应答，以确认网络的正常连通。
2. 目的不可达：用于指示主机无法到达目标地址，以及该地址的原因。这包括网络不可达、主机不可达、协议不可达和端口不可达等。
3. 重定向：用于指示主机将数据包发送到更合适的下一跳地址。这包括网络重定向和主机重定向等。
4. 超时：用于指示数据包在转发过程中超过了一定的生存时间或者最大跳数限制，导致无法到达目标地址。这包括TTL超时和分片重组超时等。
5. 时间戳请求和时间戳应答：用于在数据包中添加时间戳信息，以便在网络故障排除和性能分析中使用。

四、应用场景

ICMP协议在网络通信中扮演着重要的角色，常用于以下几个方面：

1. 网络连通性测试：通过发送回显请求并等待回显应答，可以确定网络的响应时间、丢包率和带宽等性能指标，以便优化网络配置和故障排除。
2. 错误检测与处理：当网络出现故障或者数据包转发异常时，ICMP可以快速地发现问题并生成错误报告，以便管理员及时采取措施。
3. 路由选择与管理：路由器通过使用ICMP协议中的重定向和路由请求等类型，可以动态地选择和管理路由路径，以便优化网络性能和减少数据包的延迟和丢失。
4. 安全检测与防御：通过检测和记录网络中的ICMP数据包，可以快速发现和防御各种攻击行为，如Ping洪水攻击等。

五、注意事项

1. ICMP差错报文只报告差错，但不负责纠正错误。纠错工作留给高层协议去处理。
2. 在某些情况下，如ICMP差错报文本身、广播或多播的IP数据报等，不会产生ICMP差错报文。
3. ICMP报文中的校验和字段用于检验ICMP数据报的正确性，包括ICMP头部和数据部分。

常用协议分析

ARP

通过nmap -sn 192.168.1.1产生arp数据包

请求包分析

1. ARP请求类型
   • 图片中明确标识了这是一个ARP请求（Address Resolution Protocol (request)）。
2. 硬件类型
   • 硬件类型被指定为以太网（Ethernet (1)），这是局域网中最常用的硬件类型。
3. 协议类型
   • 协议类型为IPv4（0x0800），表明这是基于IPv4地址的ARP请求。
4. 硬件和协议大小
   • 硬件大小为6字节，这对应于以太网MAC地址的标准长度。
   • 协议大小为4字节，这对应于IPv4地址的标准长度。
5. 操作码（Opcode）
   • 操作码为请求（request (1)），表明这是一个ARP请求操作，而不是ARP回复或其他类型的ARP消息。
6. 发送者信息
   • 发送者MAC地址为8a:4f:20:95:9f:ef。
   • 发送者IP地址为192.168.1.7，这是发送ARP请求的设备的IP地址。
7. 目标信息
   • 目标MAC地址被标记为00:00:00:00:00:00，这是一个广播地址，表明ARP请求是发送给局域网内的所有设备的。
   • 目标IP地址为192.168.1.1，这是需要解析MAC地址的目标设备的IP地址。

返回包分析

1. 硬件类型（Hardware type）：

   • 值为“Ethernet (1)”，表示这是一个以太网（Ethernet）环境。以太网是目前最广泛使用的局域网技术。

2. 协议类型（Protocol type）：

   • 值为“IPv4 (0x0800)”，表示ARP消息是为了解析IPv4地址而发送的。IPv4是互联网协议套件的核心，用于为互联网上的设备分配唯一地址。

3. 硬件大小（Hardware size）：

   • 值为6，表示MAC地址的长度为6个字节（48位）。MAC地址是链路层用于标识网络设备的唯一地址。

4. 协议大小（Protocol size）：

   • 值为4，表示IPv4地址的长度为4个字节（32位）。IPv4地址是分配给互联网上的每个设备的唯一数字标签。

5. 操作码（Opcode）：

   • 值为“reply (2)”，表示这是一个ARP回复消息。ARP操作码用于区分ARP请求和ARP回复消息。

6. 发送者MAC地址（Sender MAC address）：

   • 值为“zte 38:9d:59 （bc:f8:8b:38:9d:59）”，但这里似乎有一个格式错误或笔误。通常，MAC地址不会包含“zte”这样的字符串。正确的MAC地址应该是“bc:f8:8b:38:9d:59”。这个地址是发送ARP回复消息的设备的MAC地址。

7. 发送者IP地址（Sender IP address）：

   • 值为“192.168.1.1”，表示发送ARP回复消息的设备在局域网中的IPv4地址。

8. 目标MAC地址（Target MAC address）：

   • 值为“8a:4f:20:95:9f:ef”，这是ARP回复消息要解析的IPv4地址对应的MAC地址。换句话说，这个地址是ARP请求中请求解析的IPv4地址所对应的设备的MAC地址。

需要注意的一点是，返回包自动补全了自己的MAC地址，目的地址和源地址做了对调。

---

ICMP

通过ping baidu.com产生ICMP数据包

请求包分析

1. 协议名称：

   • “Internet Control Message Protocol”：这是协议的名称，表明这是一个ICMP消息。

2. 类型和代码：

   • “Type: 8 (Echo (ping) request)”：ICMP消息的类型为8，表示这是一个回显（ping）请求消息。
   • “Code: 0”：代码为0，通常用于表示ping请求或回复中的正常操作。

3. 校验和：

   • “Checksum: 0x4d54 [correct]”：校验和为0x4d54，且标记为正确。校验和用于确保ICMP消息的完整性，如果数据在传输过程中被篡改，则校验和将不匹配。
   • “[Checksum Status: Good]”：校验和状态良好，表示消息未被篡改。

4. 标识符和序列号：

   • “Identifier （BE): 1 （0x0001)”：在大端（BE）表示中，标识符为1。标识符通常用于区分不同的ping请求或回复。
   • “Identifier (LE): 256 (0x0100)”：在小端（LE）表示中，由于字节顺序的不同，标识符显示为256（0x0100）。
   • “Sequence Number（BE):7(0x0007)”：在大端表示中，序列号为7。序列号用于标识每个ping请求或回复的特定实例。
   • “Sequence Number (LE): 1792 (0x0700)”：在小端表示中，序列号为1792（0x0700）。

5. 响应帧：

   • “[Response frame: 5]”：此字段显示响应帧的编号为5，但请注意，由于这是一个ping请求，因此实际上还没有响应帧（此字段可能是工具或软件界面的一个部分，用于在收到响应时显示相关信息）。

6. 数据：

   • “Data (32 bytes)”：数据字段包含32个字节。
   • “Data: 6162636465666768696a6b6c6d6e6f7071727374757677616263646566676869”：这是数据的十六进制表示，对应于字母“abcdefghijklmnopqrstuvwxyzabcd”的ASCII码。
   • “[Length: 32]”：数据长度为32个字节，与前面的描述相符。

返回包分析

1. 协议名称：

   • “Internet Control Message Protocol”：这是协议的名称，表明这是一个ICMP消息。

2. 类型和代码：

   • “Type: 0 (Echo (ping) reply)”：ICMP消息的类型为0，表示这是一个回显（ping）回复消息。
   • “Code: 0”：代码为0，进一步确认了这是一个正常的ping回复。

3. 校验和：

   • “Checksum: 0x5554 [correct]”：校验和为0x5554，且标记为正确。校验和用于确保ICMP消息的完整性，如果数据在传输过程中被篡改，则校验和将不匹配。
   • “[Checksum Status: Good]”：校验和状态良好，表示消息未被篡改。

4. 标识符和序列号：

   • “Identifier (BE): 1 (0x0001)”和“Identifier（LE): 256 （0x0100)”：这里展示了标识符的两种表示方式，大端（BE）和小端（LE）。在大端表示中，标识符为1；在小端表示中，由于字节顺序的不同，标识符显示为256（0x0100）。
   • “Sequence Number (BE): 7 (0x0007)”和“Sequence Number (LE): 1792 (0x0700)”：同样地，这里展示了序列号的两种表示方式。在大端表示中，序列号为7；在小端表示中，序列号为1792（0x0700）。

5. 请求帧和响应时间：

   • “[Request frame: 4]”：这表示请求帧的编号为4。
   • “[Response time: 44.865 ms]”：响应时间为44.865毫秒，这是从发送ping请求到收到回复所需的时间。

6. 数据：

   • “Data (32 bytes)”：数据字段包含32个字节。
   • “Data: 6162636465666768696a6b6c6d6e6f7071727374757677616263646566676869”：这是数据的十六进制表示，对应于字母“abcdefghijklmnopqrstuvwxyzabcd”的ASCII码。
   • “[Length: 32]”：数据长度为32个字节，与前面的描述相符。

拓展

在正常情况下，使用Wireshark分析ping包时，响应帧（Reply Frame）应该在请求帧（Request Frame）之后出现，因为ping操作是一个请求-响应模型：先发送一个ICMP Echo请求（即ping请求），然后接收一个ICMP Echo回复（即ping响应）。

如果在Wireshark中观察到响应帧在请求帧前面，这可能是由于以下几个原因：

1. 捕获顺序问题：

   • 可能是Wireshark在捕获数据包时，由于网络延迟、捕获速度或其他因素，导致数据包的显示顺序与实际发送顺序不一致。这通常是一个偶发现象，不太可能是常态。

2. ARP缓存更新：

   • 在局域网中，ARP（Address Resolution Protocol）协议用于将IP地址解析为MAC地址。如果ARP缓存被更新或重新查询，可能会导致一些额外的ARP请求和应答数据包出现。这些ARP数据包可能会干扰ping请求和响应的显示顺序，但通常它们不会直接影响ICMP数据包的顺序。
   • 然而，如果ARP请求和应答恰好发生在ping请求和响应之间，并且Wireshark的捕获速度非常快，那么可能会给人一种响应帧在请求帧前面的错觉。实际上，这只是ARP数据包插入了ping请求和响应之间。

3. Wireshark界面显示问题：

   • 有时，Wireshark的界面可能会因为滚动、刷新或用户操作而导致数据包的显示顺序出现短暂的变化。这通常是一个界面问题，而不是数据包本身的顺序问题。

4. 数据包丢失或重排：

   • 在极少数情况下，网络问题或Wireshark的捕获问题可能导致数据包丢失或重排。这通常会导致数据包的顺序完全混乱，而不仅仅是响应帧在请求帧前面。

5. 时间戳问题：

   • Wireshark使用时间戳来记录每个数据包到达的时间。如果时间戳出现错误或不一致，可能会导致数据包的显示顺序与实际顺序不符。然而，这种情况非常罕见，通常与Wireshark本身的错误或网络设备的时钟问题有关。

为了准确分析ping包并确定数据包的顺序，可以采取以下措施：

• 确保Wireshark捕获的数据包是完整的，并且没有丢失任何数据包。
• 检查Wireshark的时间戳设置，确保时间戳是准确和一致的。
• 仔细分析数据包的序列号、标识符和其他相关信息，以确定它们的顺序和关系。
• 如果可能的话，使用其他网络分析工具或方法来验证Wireshark的结果。

---

TCP

1. 时间戳与IP地址：

   • 每行数据都以时间戳开始，如“135 7.687899”，表示数据包被捕获的时间。
   • “1–.2–.—.–”是源IP地址，而“192.168.1.6”是目的IP地址，这两个IP地址在多个数据包中保持不变，表明它们之间的通信是持续的。

2. TCP连接信息：

   • 端口号：源端口在多个数据包中变化（如66、54、1478等），而目的端口始终为80（HTTP服务的标准端口）。
   • TCP序列号与确认号：每个数据包都包含序列号（Seq）和确认号（Ack），用于确保数据的顺序和完整性。
   • 窗口大小（Win）：表示接收方能够接收的最大数据量，如“Win=64240”。
   • 数据长度（Len）：表示数据包中有效数据的长度，如“Len=0”表示没有数据，“Len=1424”表示有1424字节的数据。
   • MSS（Maximum Segment Size）：最大报文段长度，如“MSS=1424”。
   • SACK_PERM：表示支持选择性确认。
   • WS（Window Scaling）：窗口缩放选项，如“WS=128”。

3. TCP数据包类型：

   • [SYN, ACK]：TCP三次握手中的第一个和第二个步骤，用于建立连接。
   • [ACK]：确认数据包，用于确认接收到的数据。
   • [FIN, ACK]：TCP连接关闭过程中的数据包，表示一方希望关闭连接并确认对方的序列号。
   • [TCP Dup ACK]：重复的确认数据包，通常用于告诉发送方某个数据包可能丢失了。

4. TCP PDU重组：

   • [TCP PDU reassembled in 141]：表示TCP协议数据单元（PDU）在捕获过程中被重新组装，数字“141”可能是指重组的序列号或某种内部标识。

5. 网络连接过程：

   • 从“66 80 → 55307 [SYN, ACK]”开始，表示一个TCP连接请求被发送并得到了确认。
   • 随后是多个[ACK]数据包，表示数据正在被确认和传输。
   • 最后，以“[FIN, ACK]”和“[ACK]”数据包结束，表示TCP连接被正常关闭。

6. 网络性能分析：

   • 通过观察数据包的发送和接收时间，可以分析网络的延迟和吞吐量。
   • 通过观察数据包的长度和窗口大小，可以分析网络的带宽利用率和流量控制机制。

数据包详情(以SYN-ACK为例)

1. TCP Segment Len: 0，表示这个TCP段没有携带数据，仅包含TCP头部。

2. Sequence Number:

   • 相对序列号：0（这通常表示这是一个新的连接或重置后的序列号）
   • 原始序列号：1031148377（这是实际的序列号值，用于确保数据的顺序和完整性）

3. Next Sequence Number:

   • 相对序列号：1（表示下一个期待的序列号）

4. Acknowledgment Number:

   • 相对确认号：1（表示对之前收到的数据包的确认）
   • 原始确认号：1271186647（实际的确认号值）

5. Header Length: 32字节（8个32位字，即20字节的标准TCP头部加上12字节的选项字段）

6. Flags: 0x012（SYN, ACK），表示这是一个TCP三次握手中的SYN-ACK包，用于建立连接。

7. Window: 64240，表示接收窗口的大小，即接收方能够接收的最大数据量。

8. Checksum: 0x1b74（未验证），表示TCP头部的校验和，用于检测头部数据的完整性。

9. Urgent Pointer: 0，紧急指针，通常不用于常规数据传输。

10. Options:

    • 最大分节长度（MSS）：1424字节，表示TCP层每次能够传输的最大数据量（不包括TCP头部）。
    • 无操作（NOP）：用于对齐选项字段的边界。
    • SACK允许：表示支持选择性确认，用于提高传输效率。
    • 窗口缩放：7（乘以128），用于放大接收窗口的大小，以支持更大的数据传输。

11. 时间戳和RTT分析：

    • 自这个TCP流中的第一个帧以来的时间：0.044586000秒。
    • 自这个TCP流中的上一个帧以来的时间：0.044586000秒。
      -RTT（往返时间）：0.044586000秒，表示从发送数据包到收到确认包的时间。
    • iRTT：0.044936000秒，可能是另一个测量的RTT值。

12. SEQ/ACK分析：

    • 这是对帧134中数据包的确认。
    • 用于确认该数据包的RTT是0.044586000秒。

TCP-flags

1. TCP标志位（Flags）：

   • 0x012 (SYN, ACK)：这表明当前的数据包是一个SYN-ACK包，用于TCP连接的三次握手中。SYN表示同步序列编号，用于发起一个连接；ACK表示确认，用于确认接收到的数据包。这个组合通常出现在连接建立的响应阶段。

2. TCP选项：

   • Reserved: Not set：保留字段未设置。
   • Accurate ECN: Not set：准确的显式拥塞通知（ECN）未设置。ECN是一种网络拥塞控制机制，但在这个连接中未被使用。
   • Congestion Window Reduced: Not set：拥塞窗口减少选项未设置。这通常表示没有发生拥塞导致的窗口大小调整。
   • ECN-Echo: Not set：ECN回显未设置。这是与ECN相关的一个选项，用于确认接收方支持ECN。
   • Urgent: Not set：紧急指针未设置。紧急指针用于标记数据包中的紧急数据，但在这个连接中未被使用。
   • Acknowledgment: Set：确认字段已设置。这表明当前数据包是对之前接收到的数据包的确认。
   • Push: Not set：推送选项未设置。推送选项用于提示接收方立即将数据传递给上层应用，但在这个连接中未被使用。
   • Reset: Not set：重置选项未设置。重置选项用于关闭一个连接，但在这个数据包中未被使用。
   • Syn: Set：同步序列编号已设置。虽然这里写的是“Syn”，但根据上下文，它应该是指这个数据包是SYN-ACK包的一部分，即包含了SYN标志位。

3. 其他信息：

   • [Expert Info (Chat/Sequence): Connection establish acknowledge (SYN+ACK): server port 80]：这是一条专家信息，指出当前数据包是连接建立确认（SYN+ACK）的一部分，服务器端口为80。这进一步确认了这是一个HTTP服务的标准端口上的TCP连接建立过程。
   • Fin: Not set：结束标志未设置。这表明当前数据包不是用于关闭连接的FIN包。

HTTP

通过curl -I baidu,com抓取http数据包

curl -I表示仅返回头部信息

curl -I baidu.com

HTTP/1.1 200 OK
Date: Wed, 27 Nov 2024 14:53:43 GMT
Server: Apache
Last-Modified: Tue, 12 Jan 2010 13:48:00 GMT
ETag: "51-47cf7e6ee8400"
Accept-Ranges: bytes
Content-Length: 81
Cache-Control: max-age=86400
Expires: Thu, 28 Nov 2024 14:53:43 GMT
Connection: Keep-Alive
Content-Type: text/html

请求包

1. 请求方法：

   • 请求方法是HEAD，这意味着请求仅获取资源的头部信息，而不获取资源本身的内容。这通常用于检查资源的元数据（如内容类型、最后修改时间等），而不实际下载资源。

2. 请求URI：

   • 请求URI是/，表示请求的是根目录的资源。在这个上下文中，它指的是baidu.com网站的根目录。

3. 请求版本：

   • 请求版本是HTTP/1.1，这是当前广泛使用的HTTP协议版本之一。

4. 头部信息：

   • Host: baidu.com：指定了请求的目标主机名。
   • User-Agent: cur1/8.4.0：表示发起请求的客户端软件的标识。这里的cur1/8.4.0可能是一个客户端程序的版本号，但需要注意的是，cur1并不是一个常见的用户代理字符串，可能是一个特定工具或自定义的标识。
   • Accept: */*：表示客户端可以接受任何类型的内容。

5. 响应帧：

   • 图片中标识了一个响应帧[Response in frame: 8]，这意味着响应数据位于捕获的数据包的第8帧中。

6. 完整请求URI：

   • 提供了完整请求URIhttp://baidu.com/，这是请求的完整网址。

响应包

1. HTTP协议版本与状态码：

   • Hypertext Transfer Protocol,HTTP/1.1 200 OK：这表示HTTP的版本是1.1，并且响应的状态码是200，意味着请求成功。状态码后的“OK”是对200状态码的文本描述。

2. 响应头部字段：

   • Response Version: HTTP/1.1：再次确认了HTTP响应的版本是1.1。
   • Status Code: 200 和 [Status Code Description: OK]：与前面的信息重复，表示请求成功。
   • Response Phrase: OK：这也是对状态码200的另一种描述方式。
   • Date: Wed, 27 Nov 2024 14:53:43 GMT：表示响应生成的日期和时间。
   • Server: Apache：表明服务器使用的是Apache。
   • Last-Modified: Tue, 12 Jan 2010 13:48:00 GMT：表示资源最后修改的日期和时间。
   • ETag: "51-47cf7e6ee8400"：一个特定于请求资源的实体标签，可以用于缓存验证。
   • Accept-Ranges: bytes：表明服务器接受字节范围请求。
   • Content-Length: 81 和 [Content length: 81]：表示响应主体的字节长度。
   • Cache-Control: max-age=86400：用于控制缓存的有效期，这里设置为86400秒（即一天）。
   • Expires: Thu, 28 Nov 2024 14:53:43 GMT：表示资源过期的日期和时间。
   • Connection: Keep-Alive：表示连接将保持活动状态，而不是在每次请求后关闭。
   • Content-Type: text/html：表示响应主体的媒体类型是HTML。

3. 附加信息：

   • [Request in frame: 6]：表示请求数据位于捕获的数据包的第6帧中。
   • [Time since request: 0.027961000 seconds]：表示从请求发送到接收到响应的时间。
   • [Request URI: /] 和 [Full request URI: http://baidu.com/]：分别表示请求的URI和完整的请求URI。

wireshark追踪http数据流

接受字节范围请求。

• Content-Length: 81 和 [Content length: 81]：表示响应主体的字节长度。
• Cache-Control: max-age=86400：用于控制缓存的有效期，这里设置为86400秒（即一天）。
• Expires: Thu, 28 Nov 2024 14:53:43 GMT：表示资源过期的日期和时间。
• Connection: Keep-Alive：表示连接将保持活动状态，而不是在每次请求后关闭。
• Content-Type: text/html：表示响应主体的媒体类型是HTML。

3. 附加信息：
   • [Request in frame: 6]：表示请求数据位于捕获的数据包的第6帧中。
   • [Time since request: 0.027961000 seconds]：表示从请求发送到接收到响应的时间。
   • [Request URI: /] 和 [Full request URI: http://baidu.com/]：分别表示请求的URI和完整的请求URI。

wireshark追踪http数据流

[外链图片转存中…(img-7QmFYXkC-1732721753258)]