Packets Frames 数据包和帧
官方链接 https://www.youtube.com/watch?v=vzcLrE0SfiQ
Task1 What are Packets and Frames 什么是包和帧
Packets and frames are small pieces of data that, when forming together, make a larger piece of information or message. However, they are two different things in the OSI model.
数据包和帧是小块数据，当它们组合在一起时，会形成一个更大的信息或消息。然而，在 OSI 模型中，它们是两个不同的事物。
A packet is a piece of data from Layer 3 (Network Layer) of the OSI model, containing information such as an IP header and payload. A frame, however, is used at Layer 2 (Data Link) of the OSI model, which, encapsulates the packet and adds additional information such as MAC addresses.
数据包是来自 OSI 模型第 3 层 (网络层) 的一段数据，包含 IP 报头和有效负载等信息。然而，在 OSI 模型第 2 层 (数据链路) 使用一个帧，该帧用于封装数据包并添加额外的信息，如 MAC 地址。
You can think of this process as similar to mailing a letter through the post. The envelope is a frame, which, is used to move the contents (in this analogy, the packet) of the envelope to another place. Once the recepient opens the envelop (frame), they will know how to forward the letter (packet) itself.
你可以将这个过程类比为通过邮局寄送信件。信封是一个框架，用于将信封中的内容 (在这个类比中是包裹) 移动到另一个地方。一旦收件人打开信封 (框架), 他们就会知道如何转发信件 (包裹) 本身。
This process is called encapsulation which we discussed in room 3: the OSI model. At this stage, it's safe to assume that when we are talking about anything IP addresses, we are talking about packets. When the encapsulating information is stripped away, we're talking about the frame itself.
这个过程被称为封装，我们在第 3 课中讨论过：OSI 模型。在这个阶段，可以安全地假设，当我们谈论任何 IP 地址时，我们谈论的是数据包。当封装信息被剥离时，我们谈论的是帧本身。
Packets are an efficient way of communicating data across networked devices such as those explained in Task 1. Because this data is exchanged in small pieces, there is less chance of bottlenecking occurring across a network than large messages being sent at once.
数据包是一种在网络化设备之间传输数据的高效方式，如任务 1 中所述。由于这些数据是以小块的形式交换的，因此与同时发送大型消息相比，在整个网络中发生瓶颈的可能性更小。
For example, when loading an image from a website, this image is not sent to your computer as a whole, but rather small pieces where it is reconstructed on your computer. Take the image below as an illustration of this process. The cat's picture is divided into three packets, where it is reconstructed when it reaches the computer to form the final image.
例如，当从网站上下载图片时，这张图片并不是作为一个整体发送到你的计算机，而是作为一个个小片段在你的计算机上重建。以下图片作为这个过程的示例。猫的图片被分成三个数据包，当它到达计算机时会被重建，形成最终的图片。
Packets have different structures that are dependant upon the type of packet that is being sent. As we'll come on to discuss, networking is full of standards and protocols that act as a set of rules for how the packet is handled on a device. With billions of devices connected on the internet, things can quickly break down if there is no standardisation.
数据包具有不同的结构，这取决于发送的数据包类型。正如我们将要讨论的，网络中充满了标准和协议，这些标准和协议充当了一套规则，用于指导设备如何处理数据包。由于互联网上连接着数十亿台设备，如果没有标准化，事情可能会迅速崩溃。
Let's continue with our example of the Internet Protocol. A packet using this protocol will have a set of headers that contain additional pieces of information to the data that is being sent across a network.
让我们继续我们的互联网协议示例。使用此协议的数据包将具有一组报头，其中包含正在通过网络发送的数据的额外信息片段
下面时常见字段的表格
| 字段 | 英文描述 | 中文描述 |
| 生存时间 (TTL) | Sets an expiry timer for packets to prevent network congestion when packets fail to reach destination or are undeliverable. | 为数据包设置生存周期定时器，防止无法到达目标或不可交付的数据包造成网络拥塞。 |
| 校验和 | Provides data integrity verification for protocols like TCP/IP. Any data alteration causes checksum mismatch, indicating corruption. | 为TCP/IP等协议提供数据完整性校验。任何数据篡改都会导致校验和不匹配，标识数据损坏。 |
| 源地址 | The source IP address of the sending device, enabling response routing back to origin. | 发送设备的源IP地址，确保响应数据能正确路由回原始发送方。 |
| 目的地址 | The destination IP address for packet delivery, determining the next hop in data transmission path. | 数据包传输的目标IP地址，决定数据传输路径中的下一跳节点。 |
Task2 TCP/IP (The Three-Way Handshake) TCP/IP (三次握手)
TCP (or Transmission Control Protocol for short) is another one of these rules used in networking.
TCP (简称传输控制协议) 是网络中使用的另一个规则。
This protocol is very similar to the OSI model that we have previously discussed in room three of this module so far. The TCP/IP protocol consists of four layers and is arguably just a summarised version of the OSI model. These layers are:
这个协议与我们之前在本模块第三部分中讨论过的 OSI 模型非常相似。TCP/IP 协议由四层组成，可以说只是 OSI 模型的一个总结版本。这些层是：
Application应用
Transport运输
Internet互联网
Network Interface网络接口
Very similar to how the OSI model works, information is added to each layer of the TCP model as the piece of data (or packet) traverses it. As you may recall, this process is known as encapsulation - where the reverse of this process is decapsulation.
与 OSI 模型的工作方式非常相似，当数据 (或数据包) 穿过 TCP 模型的每一层时，信息都会被添加到该模型的每一层中。你可能还记得，这个过程被称为封装 (encapsulation), 其反面是解封装 (decapsulation)。
One defining feature of TCP is that it is connection-based, which means that TCP must establish a connection between both a client and a device acting as a server before data is sent.
TCP 的一个有拥属性是它是基于连接的，这意味着在发送数据之前，TCP 必须在客户端和作为服务器的设备之间建立连接。
Because of this, TCP guarantees that any data sent will be received on the other end. This process is named the Three-way handshake, which is something we'll come on to discuss shortly. A table comparing the advantages and disadvantages of TCP is located below:
正因如此，TCP 确保任何发送的数据都会在另一端被接收。这个过程被称为三向握手，我们稍后会讨论。下面是一个比较 TCP 优缺点的表格：
| 类型 | 英文描述 | 中文描述 |
| 优势 | Guarantees end-to-end data integrity. | 确保端到端数据完整性。 |
| Implements flow control to prevent data flooding. | 实施流量控制防止数据洪泛。 | |
| Employs robust reliability mechanisms. | 采用健壮的可靠性机制。 | |
| 缺点 | Requires full data segment delivery; any loss triggers retransmission. | 要求完整数据段交付；任何丢失都会触发重传。 |
| Persistent connections cause resource bottlenecks. | 持久连接导致资源瓶颈。 | |
| Higher computational overhead than UDP. | 比UDP更高的计算开销。 |
TCP packets contain various sections of information known as headers that are added from encapsulation. Let's explain some of the crucial headers in the table below:
TCP 数据包包含各种被称为报头的信息部分，这些信息是从封装中添加的。让我们解释下表中的一些关键报头：
| 头部字段 | 英文描述 | 中文描述 |
| 源端口 | Randomly selected ephemeral port (0-65535) for outgoing connections. | 随机选择的临时端口(0-65535)，用于发起连接。 |
| 目的端口 | Specific port number of the receiving service (e.g., 80 for HTTP). | 接收服务的特定端口号（如HTTP服务为80）。 |
| 源IP地址 | IP address of the sending device. | 发送设备的IP地址。 |
| 目的IP地址 | IP address of the target device. | 目标设备的IP地址。 |
| 序列号 | Initial random value identifying first data segment in stream. | 标识数据流起始段的随机初始值。 |
| 确认号 | Next expected sequence number (current seq+1). | 下一个期望的序列号（当前序列号+1）。 |
| 校验和 | Mathematical value for data integrity verification. | 数据完整性验证的数学值。 |
| 数据载荷 | Actual application-layer data being transmitted. | 传输的应用层实际数据。 |
| 标志位 | Control bits determining packet handling behavior. | 决定数据包处理行为的控制位。 |
Next, we'll come on to discuss the Three-way handshake - the term given for the process used to establish a connection between two devices. The Three-way handshake communicates using a few special messages - the table below highlights the main ones:
接下来，我们将讨论三次握手 —— 这个术语用于在两个设备之间建立连接的过程。三次握手使用一些特殊的信息进行通信 —— 下表突出显示了其中的主要内容：
| 步骤 | 消息类型 | 英文描述 | 中文描述 |
| 1 | SYN | Initial packet sent by client to initiate connection synchronization. | 客户端发送的初始数据包，用于发起连接同步。 |
| 2 | SYN/ACK | Server response acknowledging synchronization request. | 服务器响应包，确认同步请求。 |
| 3 | ACK | Final acknowledgment confirming connection establishment. | 最终确认包，完成连接建立。 |
| 4 | DATA | Application data transmission after connection establishment. | 连接建立后的应用数据传输。 |
| 5 | FIN | Graceful connection termination request. | 正常连接终止请求。 |
| 6 | RST | Abrupt connection reset indicating critical errors. | 强制连接重置，表示发生严重错误。 |
这里补充一下 tcp关闭连接其实就是四次挥手 下面是整理的四次挥手的流程
| 步骤 | 消息类型 | 英文描述 | 中文描述 |
| 1 | FIN | The active closer sends a FIN segment to initiate connection termination. | 主动关闭方发送 FIN 报文段发起连接终止。 |
| 2 | ACK | The passive closer acknowledges the FIN with an ACK segment. | 被动关闭方发送 ACK 报文段确认 FIN。 |
| 3 | FIN | After completing data transmission, the passive closer sends its own FIN segment. | 完成数据传输后，被动关闭方发送自己的 FIN 报文段。 |
| 4 | ACK | The active closer sends a final ACK segment to confirm termination. | 主动关闭方发送最终 ACK 报文段确认终止。 |
| 状态变迁 | |||
| 1→2 | FIN_WAIT_1 → FIN_WAIT_2 | Active closer waits for passive's FIN after sending initial FIN. | 主动方发送初始 FIN 后进入 FIN_WAIT_2 状态，等待被动方 FIN。 |
| 2→3 | CLOSE_WAIT → LAST_ACK | Passive closer enters LAST_ACK state after sending FIN, waiting for final ACK. | 被动方发送 FIN 后进入 LAST_ACK 状态，等待最终 ACK。 |
| 4 | TIME_WAIT | Active closer waits for 2MSL (Maximum Segment Lifetime) to ensure reliable termination. | 主动方进入 TIME_WAIT 状态，等待 2MSL 时间确保可靠终止。 |
与三次握手的对比：
| 特性 | 三次握手 | 四次挥手 |
| 发起信号 | SYN (Synchronize) | FIN (Finish) |
| 确认机制 | SYN+ACK → ACK | ACK → FIN → ACK |
| 状态数量 | 3 states | 5 states (含TIME_WAIT) |
| 耗时 | 1.5 RTT | 2 RTT + 2MSL |
| 核心目的 | Connection synchronization | Graceful connection teardown |
Task3 Practical - Handshake 实战 - 握手
下面是这个网页的通过流程 基本上就是三次握手 四次挥手的过程
flag出来了
THM{TCP_CHATTER}
Task4 UDP/IP
The User Datagram Protocol (UDP) is another protocol that is used to communicate data between devices.
用户数据报协议 (UDP) 是另一种用于在设备之间通信数据的协议。
Unlike its brother TCP, UDP is a stateless protocol that doesn't require a constant connection between the two devices for data to be sent. For example, the Three-way handshake does not occur, nor is there any synchronisation between the two devices.
与 TCP 不同，UDP 是一种无状态协议，它不需要两个设备之间的恒定连接来发送数据。例如，三向握手不会发生，两个设备之间也不存在任何同步。
Recall some of the comparisons made about these two protocols in Room 3: "OSI Model". Namely, UDP is used in situations where applications can tolerate data being lost (such as video streaming or voice chat) or in scenarios where an unstable connection is not the end-all. A table comparing the advantages and disadvantages of UDP is located below:
回想一下在第 3 房间 “OSI 模型” 中对这两种协议的一些比较。也就是说，UDP 用于应用程序可以容忍数据丢失的情况 (如视频流或语音聊天), 或者在连接不稳定并非最终问题的情况下。下面是一个比较 UDP 优缺点的表格：
| 类型 | 英文描述 | 中文描述 |
| 优势 | Lower latency than TCP due to no connection establishment overhead. | 更低延迟：无连接建立开销，比TCP响应更快。 |
| Application-layer control over packet transmission rate and timing. | 应用层控制：由应用层决定数据包发送速率和时序。 | |
| No persistent connection state maintained, reducing resource usage. | 无持久连接：不维护连接状态，显著降低资源消耗。 | |
| 劣势 | No delivery guarantee - packets may be lost without retransmission. | 无交付保证：数据包可能丢失且不重传。 |
| No congestion control - requires custom implementation at app layer. | 无拥塞控制：需应用层自行实现流量控制机制。 | |
| Unreliable for unstable networks - causes poor user experience. | 不稳定网络体验差：在网络波动时用户体验急剧下降。 |
As mentioned, no process takes place in setting up a connection between two devices. Meaning that there is no regard for whether or not data is received, and there are no safeguards such as those offered by TCP, such as data integrity.
如前所述，在两个设备之间建立连接时没有任何过程。这意味着不考虑数据是否被接收，也没有 TCP 提供的那些保障措施，如数据完整性。
UDP packets are much simpler than TCP packets and have fewer headers. However, both protocols share some standard headers, which are what is annotated in the table below:
UDP 数据包比 TCP 数据包简单得多，头部也更少。然而，这两种协议都共享一些标准头部，如下表注释所示：
| 字段 | 英文描述 | 中文描述 |
| 源端口 | Ephemeral port (0-65535) randomly selected by sender for response routing. | 发送方随机选择的临时端口(0-65535)，用于响应路由。 |
| 目的端口 | Specific service port on destination host (e.g., 53 for DNS). | 目标主机上的特定服务端口（如DNS服务为53）。 |
| 报文长度 | Total datagram length including header and payload (in bytes). | 包含头部和负载的完整数据报长度（字节）。 |
| 校验和 | Optional integrity check for header and payload data. | 可选的头部与负载数据完整性校验。 |
| 源IP地址 | IP address of originating device. | 发送设备的IP地址。 |
| 目的IP地址 | IP address of target device. | 目标设备的IP地址。 |
| 生存时间(TTL) | Maximum router hops before packet discard (prevents network congestion). | 数据包被丢弃前可经过的最大路由跳数（防止网络拥塞）。 |
| 数据负载 | Application-layer payload (max 65,507 bytes for IPv4). | 应用层数据载荷（IPv4下最大65,507字节）。 |
Task5 Ports 101 (Practical)端口 101 (实战)
| 协议 | 端口号 | 英文描述 | 中文描述 |
| FTP | 21 | Enables file transfer between client and server over unsecured connections. | 支持客户端与服务端间不加密的文件传输协议。 |
| SSH | 22 | Provides encrypted command-line access for secure remote system administration. | 提供加密命令行访问，用于安全的远程系统管理。 |
| HTTP | 80 | Foundation protocol for web content delivery (HTML/CSS/JS/media). | Web内容传输基础协议（HTML/CSS/JS/多媒体）。 |
| HTTPS | 443 | HTTP with TLS/SSL encryption for secure data transmission. | 采用TLS/SSL加密的HTTP协议，保障传输安全。 |
| SMB | 445 | Network file and resource sharing protocol supporting printers/serial ports. | 支持打印机/串行端口的网络文件与资源共享协议。 |
| RDP | 3389 | Delivers graphical desktop interfaces over secure encrypted channels. | 通过安全加密通道传输图形化桌面界面。 |
挑战流程
总结和知识补充
TCP
全双工独立关闭机制 Full-Duplex Independent Closure
TCP 是全双工协议，要求双向通道独立关闭：
TCP is a full-duplex protocol requiring bidirectional channel independence:
- 第一组 FIN/ACK 关闭 主动方→被动方 通道
First FIN/ACK pair closes active → passive channel - 第二组 FIN/ACK 关闭 被动方→主动方 通道
Second FIN/ACK pair closes passive → active channel
- 确保最终 ACK 送达 | Guarantee Final ACK Delivery
-
- 若最终 ACK 丢失，被动方会重传 FIN
If final ACK is lost, passive closer retransmits FIN - 2MSL 时长 = 最大报文生存时间 × 2
2MSL duration = Maximum Segment Lifetime × 2
- 若最终 ACK 丢失，被动方会重传 FIN
- 消除旧连接干扰 | Eliminate Old Connection Interference
-
- 防止延迟报文被误认为新连接数据
Prevents delayed segments being mistaken for new connections - 清除网络路径中所有残留报文
Clears all residual packets in network path
- 防止延迟报文被误认为新连接数据
状态机变迁说明：
| 状态 | 英文 | 触发条件 | 持续时间 |
| FIN_WAIT_1 | Waiting for remote FIN | 主动方发送初始 FIN 后 | 直到收到 ACK |
| FIN_WAIT_2 | Waiting for remote FIN | 收到被动方 ACK 后 | 直到收到 FIN |
| CLOSE_WAIT | Waiting for local close | 被动方收到 FIN 后 | 应用决定时长 |
| LAST_ACK | Waiting for final ACK | 被动方发送 FIN 后 | 直到收到 ACK |
| TIME_WAIT | Connection lingering | 主动方发送最终 ACK 后 | 严格 2MSL |
| ::: |
异常处理机制：
RST 强制终止 | RST Forced Termination
- 当系统崩溃时发送 RST 报文立即重置连接
Send RST segment to forcibly reset connection on system crash - 跳过正常挥手流程，直接释放资源
Bypass normal handshake to directly release resources
半开连接检测 | Half-Open Connection Detection
- 通过 TCP Keepalive 探针（默认每 2 小时）
Via TCP Keepalive probes (default every 2 hours) - 连续失败后触发 RST 回收资源
Trigger RST to reclaim resources after consecutive failures
UDP
"Best Effort" Delivery Model
- 专注传输效率而非可靠性
- 将错误处理责任转移给应用层
- 适用于实时性优先场景：
• VoIP/视频会议 (容忍丢包)
• DNS查询 (短报文+快速响应)
• 广播/组播应用 (一对多传输)
端口
协议分层关系
| 层级 | 协议示例 |
| 应用层 | HTTP/HTTPS/FTP/SMB |
| 传输层 | TCP (SSH/RDP) |
| 网络层 | IP (路由寻址) |
端口特性对比：
| 特性 | 系统端口 (0-1023) | 用户端口 (1024-49151) |
| 使用权限 | 需root/admin特权 | 普通用户权限即可 |
| 协议示例 | HTTP(80)/SSH(22) | MySQL(3306)/RDP(3389) |
| 安全要求 | 必须严格访问控制 | 建议配置防火墙规则 |