当前位置： 首页 > news >正文

计算机网络——协议

news 2025/8/14 14:12:11

1. 计算机网络分层

1.1 OSI 7层模型

  • 应用层
  • 表示层
  • 会话层
  • 传输层
  • 网络层
  • 数据链路层
  • 物理层

1.2 TCP/IP 4 层模型

  • 应用层
  • 运输层
  • 网际层
  • 网络接口层

1.3 5层体系机构

  • 应用层
  • 传输层
  • 网络层
  • 数据链路层
  • 物理层

2. 应用层协议

2.1 HTTP协议

2.1.1 基本介绍

HTTP（HyperText Transfer Protocol，超文本传输协议）是应用层的一种协议，用于客户端（如浏览器）与服务器之间传输超文本（如 HTML 页面、图片、视频等）。它是 Web 的基础，建立在 TCP 协议之上，确保数据的可靠传输。HTTP协议的默认端口是80。

特点说明
无状态（Stateless）每个请求之间相互独立，服务器不会记住前一个请求的状态。
基于请求-响应模型客户端发送请求，服务器返回响应。
可扩展性强支持多种数据类型（通过 Content-Type 指定）。
支持持久连接HTTP/1.1 默认启用 keep-alive，可复用 TCP 连接。
明文传输默认不加密（HTTP），安全性差；HTTPS 使用 SSL/TLS 加密。

2.1.2 工作流程

HTTP 的典型工作流程如下：

  1. 建立 TCP 连接
    客户端与服务器通过 三次握手 建立 TCP 连接（默认端口 80）。

  2. 客户端发送 HTTP 请求
    客户端构造请求报文，包含：请求行、请求头、空行、请求体（可选）。

  3. 服务器处理请求并返回响应
    服务器解析请求，处理业务逻辑，生成响应报文（状态行、响应头、响应体）。

  4. 客户端接收并解析响应
    浏览器渲染页面或应用程序处理数据。

  5. 关闭连接（可选）

    • 若使用 Connection: close，则立即四次挥手断开。
    • 若使用 Connection: keep-alive，连接保持，可复用。

✅ 现代浏览器通常使用连接池和持久连接，避免频繁建立/断开 TCP 连接。

HTTP 协议是应用层协议，它依赖于传输层的 TCP 协议 来保证可靠传输。而：

  • 三次握手：是 TCP 建立连接的过程。
  • 四次挥手：是 TCP 断开连接的过程。

从 HTTP/1.1 开始，默认使用持久连接（也叫长连接），这意味着：

一个 TCP 连接可以被复用来发送多个 HTTP 请求和响应，而不是每次请求都重新建立和关闭连接。

举个例子：

假设你访问一个网页，页面包含：

  • 1 个 HTML 文件
  • 2 个 CSS 文件
  • 3 个 JavaScript 文件
  • 4 张图片

在持久连接下：

  1. 客户端与服务器进行一次 三次握手，建立 TCP 连接。
  2. 复用这个连接，连续发送 10 个 HTTP 请求（获取资源）。
  3. 所有请求完成后，才通过 四次挥手 断开 TCP 连接。

2.1.3 HTTP请求

一个完整的 HTTP 请求由以下三部分组成：

1. 请求行（Request Line）

格式：方法 资源路径 协议版本

GET /index.html HTTP/1.1
  • 常见方法：
    • GET：获取资源
    • POST：提交数据
    • PUT：更新资源
    • DELETE：删除资源
    • HEAD：获取响应头（不返回体）
    • OPTIONS：预检请求（CORS）

2. 请求头（Request Headers）

键值对形式，提供客户端信息和请求元数据。

常见请求头：

头部作用
Host指定服务器域名（必需）
User-Agent客户端类型（如浏览器、操作系统）
Accept客户端可接受的响应类型（如 application/json）
Content-Type请求体的数据格式（如 application/json）
Authorization认证信息（如 Bearer Token）
Cookie发送存储在本地的 Cookie

3. 请求体（Request Body）

  • 仅用于 POST、PUT 等方法。
  • 数据格式由 Content-Type 决定：
    • application/json：JSON 数据
    • application/x-www-form-urlencoded：表单数据
    • multipart/form-data：文件上传

⚠️ 请求头与请求体之间必须有一个 空行（\r\n\r\n）。

2.1.4 HTTP响应

服务器返回的响应也由三部分组成：

1. 状态行（Status Line）

格式：协议版本 状态码 状态描述

HTTP/1.1 200 OK
  • 常见状态码分类：
范围类型示例
1xx信息响应100 Continue
2xx成功200 OK, 201 Created
3xx重定向301 Moved Permanently, 302 Found
4xx客户端错误400 Bad Request, 404 Not Found, 403 Forbidden
5xx服务器错误500 Internal Server Error, 502 Bad Gateway

2. 响应头（Response Headers）

提供服务器信息和响应元数据。

常见响应头：

头部作用
Content-Type响应体的数据类型（如 text/html）
Content-Length响应体长度
Set-Cookie设置 Cookie
Location重定向目标地址（配合 3xx 状态码）
Cache-Control缓存策略
Server服务器类型（如 Nginx、Apache）

3. 响应体（Response Body）

服务器返回的实际数据，如：

  • HTML 页面
  • JSON 数据
  • 图片、文件等二进制流

2.1.5 总结

HTTP 请求：
┌─────────────────────────────┐
│ GET /api/users HTTP/1.1     │ ← 请求行
│ Host: example.com           │
│ User-Agent: Chrome          │ ← 请求头
│ Content-Type: application/json │
│                             │ ← 空行
│ {"name": "Tom"}             │ ← 请求体（POST 时存在）
└─────────────────────────────┘HTTP 响应：
┌─────────────────────────────┐
│ HTTP/1.1 200 OK             │ ← 状态行
│ Content-Type: application/json │
│ Content-Length: 15          │ ← 响应头
│ Set-Cookie: session=abc     │
│                             │ ← 空行
│ {"id":1,"name":"Tom"}       │ ← 响应体
└─────────────────────────────┘

✅ 一句话总结：
HTTP 是一种基于 请求-响应模型 的应用层协议，通过 请求行、请求头、请求体 构成请求，通过 状态行、响应头、响应体 构成响应，是 Web 通信的核心。

2.2 HTTPS协议

2.2.1 基本介绍

HTTPS（超文本传输安全协议）是 HTTP 的安全版本，通过在 HTTP 和 TCP 之间加入 SSL/TLS 协议 来实现数据加密，确保通信过程中的 机密性、完整性、身份认证。

  • 默认端口：443（HTTP 是 80）
  • 协议基础：HTTP + SSL/TLS
  • 目标：防止数据被窃听、篡改或冒充

✅ 简单理解：HTTPS = HTTP + 加密 + 认证 + 完整性保护

2.2.2 为什么需要 HTTPS

HTTP 的三大安全问题：

问题说明
窃听风险数据明文传输，第三方可监听内容（如密码、银行卡号）
篡改风险中间人可修改传输内容（如插入广告）
冒充风险无法确认对方是否是真正的服务器（钓鱼网站）

HTTPS 通过加密和数字证书解决这些问题。

2.2.3 SSL/TLS 协议

SSL（Secure Sockets Layer）和其升级版 TLS（Transport Layer Security）是用于加密通信的安全协议。

  • 现代 HTTPS 使用的是 TLS（如 TLS 1.2、TLS 1.3）
  • 加密过程发生在 TCP 连接建立之后、HTTP 通信之前

2.2.4 工作过程

HTTPS 的安全通信建立在 TLS 握手 的基础上，主要步骤如下：

1. 客户端发起请求（Client Hello）

  • 客户端发送支持的 TLS 版本、加密套件（Cipher Suites）、随机数 Client Random

2. 服务器响应（Server Hello）

  • 服务器选择 TLS 版本和加密套件
  • 返回自己的 数字证书（包含公钥）
  • 生成并发送随机数 Server Random

3. 客户端验证证书

  • 客户端验证证书是否由可信 CA（证书颁发机构） 签发
  • 验证域名是否匹配
  • 验证证书是否过期
  • ✅ 验证通过后，提取服务器公钥

4. 生成会话密钥（Pre-Master Secret）

  • 客户端生成一个随机的 预主密钥（Pre-Master Secret）
  • 使用服务器的 公钥加密 后发送给服务器

5. 服务器解密预主密钥

  • 服务器使用自己的 私钥 解密，得到预主密钥

6. 双方生成会话密钥

  • 客户端和服务器使用 Client Random、Server Random、Pre-Master Secret 通过算法生成相同的 会话密钥（Session Key）

7. 切换到加密通信

  • 双方通知“握手完成”
  • 后续所有通信（包括 HTTP 请求和响应）都使用 对称加密（会话密钥）进行加密

2.2.5 加密技术详解

HTTPS 结合了两种加密方式，发挥各自优势：

加密方式用途特点
非对称加密（如 RSA、ECC）用于传输“预主密钥”安全但慢，公钥加密，私钥解密
对称加密（如 AES）用于加密实际数据（HTTP 报文）快速高效，加密解密用同一密钥

✅ 优势：既保证了密钥传输的安全性，又提升了通信效率。

2.2.6 数字证书与 CA

  • 数字证书：由可信第三方（CA）签发，包含：
    • 域名
    • 公钥
    • 有效期
    • CA 签名
  • CA（Certificate Authority）：如 Let's Encrypt、DigiCert、Symantec
  • 浏览器内置了受信任的 CA 根证书列表，用于验证服务器证书

🔐 如果证书无效（如自签名、过期、域名不匹配），浏览器会显示“不安全”警告。

2.2.7 HTTPS 与 HTTP 的对比

对比项HTTPHTTPS
安全性明文传输，不安全加密传输，安全
端口80443
协议应用层应用层 + SSL/TLS
性能快（无加密开销）略慢（握手有开销，但可优化）
SEO不利于搜索引擎排名更受搜索引擎青睐
证书不需要需要 SSL 证书（可免费获取）

2.3.8 总结

HTTPS 通过 SSL/TLS 对 HTTP 进行加密和身份认证，是保障 Web 安全的基石，已成为现代互联网的标准配置。

2.3 WebSocket

2.3.1 基本介绍

WebSocket 是一种基于 TCP 的应用层协议（RFC 6455），它在客户端和服务器之间提供 全双工（full-duplex）、持久化、双向通信 的通道。与传统的 HTTP 请求-响应模式不同，WebSocket 允许服务器主动向客户端推送数据。

  • 协议标识：
    • ws://：非加密 WebSocket（对应 HTTP）
    • wss://：加密 WebSocket（对应 HTTPS，基于 TLS）
  • 默认端口：与 HTTP/HTTPS 一致（80 / 443）
  • 设计目标：解决 HTTP 在实时通信场景下的性能瓶颈

✅ 简单理解：
WebSocket = 一次连接，双向通信，服务器可“主动说话”

2.3.2 为什么需要 WebSocket

HTTP 协议的局限性：

问题说明
单向通信只能客户端发起请求，服务器被动响应
频繁轮询开销大实时应用（如聊天、股票）需不断发请求，浪费资源
延迟高轮询间隔决定延迟，无法做到“即时”
头部开销大每次请求都携带完整 HTTP 头部

WebSocket 通过持久连接 + 消息帧机制，解决了这些问题。

2.3.3 WebSocket 的工作过程

WebSocket 的建立过程依赖 HTTP，分为两个阶段：

阶段 1：HTTP 握手升级（Upgrade Handshake）

客户端发送一个特殊的 HTTP 请求：

GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

服务器如果支持 WebSocket，返回 101 Switching Protocols：

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

✅ 此时，TCP 连接从 HTTP 协议“升级”为 WebSocket 协议。

阶段 2：双向通信

握手成功后，客户端和服务器可以随时互相发送数据帧（Frame），直到任意一方关闭连接。

  • 数据可以是文本（UTF-8）或二进制
  • 通信是全双工的，无需请求-响应模式

2.3.4 WebSocket 通信模型

特性说明
连接建立基于 HTTP 升级，仅一次
通信模式全双工、双向、持久化
数据单位消息（Message），由一个或多个帧（Frame）组成
消息类型文本消息（String）、二进制消息（ArrayBuffer/Buffer）
连接保持连接长期存活，可通过 ping/pong 心跳保活

2.3.5 WebSocket API（前端示例）

在浏览器中使用原生 WebSocket API：

// 1. 创建 WebSocket 连接
const socket = new WebSocket('ws://localhost:8080/chat');// 2. 监听连接打开
socket.onopen = function(event) {console.log('连接已建立');socket.send('Hello Server!');
};// 3. 监听消息
socket.onmessage = function(event) {console.log('收到消息:', event.data);
};// 4. 监听错误
socket.onerror = function(error) {console.log('发生错误:', error);
};// 5. 监听连接关闭
socket.onclose = function(event) {console.log('连接已关闭');
};// 发送消息
socket.send('这是一条客户端消息');

2.3.6 适用场景

WebSocket 特别适合需要低延迟、高频、双向通信的场景：

应用场景示例
💬 实时聊天微信网页版、在线客服
📈 实时数据推送股票行情、天气更新、监控系统
🎮 在线游戏多人互动、实时操作同步
🔔 通知系统消息提醒、订单状态更新
🖥️ 远程控制Web SSH、远程桌面

2.3.7 与 HTTP 的对比

对比项HTTPWebSocket
通信模式请求-响应（单向）全双工（双向）
连接状态短连接或持久连接持久化长连接
实时性差（依赖轮询）强（服务器可主动推送）
开销每次请求带完整头部帧头部小，效率高
建立方式直接发送请求先 HTTP 握手，再升级协议
安全性HTTP / HTTPSws:// / wss://（加密）

2.3.8 总结

项目说明
WebSocket 是什么一种支持全双工通信的 Web 应用层协议
核心机制基于 HTTP 升级，建立持久化双向连接
主要用途实时通信、消息推送、在线互动
关键优势低延迟、高效、服务器主动推送
发展趋势已成为现代 Web 实时应用的标准技术

🌐 一句话总结：
WebSocket 通过一次连接实现客户端与服务器的双向实时通信，是构建现代实时 Web 应用的核心技术。

3. 传输层协议

3.1 TCP协议

3.1.1 基本介绍

TCP（Transmission Control Protocol，传输控制协议）是一种面向连接、可靠、基于字节流的传输层协议（RFC 793），广泛用于对数据完整性要求高的应用，如网页浏览、文件传输、电子邮件等。

  • 协议特点：可靠传输、流量控制、拥塞控制、全双工通信
  • 默认端口示例：
    • HTTP: 80
    • HTTPS: 443
    • FTP: 21
    • SMTP: 25
  • 设计目标：确保数据在不可靠网络中准确、有序、不丢失地送达
3.1.2 为什么需要 TCP

IP 协议本身不保证可靠性，存在以下问题：

问题说明
数据丢失网络拥堵可能导致数据包丢失
数据乱序数据包可能通过不同路径到达，顺序错乱
数据重复重传机制可能导致接收端收到重复数据
无连接状态无法确认对方是否准备好接收数据

TCP 通过连接管理、确认机制、重传、排序、流量控制等机制解决这些问题。

3.1.3 TCP 的工作过程

TCP 通信分为三个阶段：连接建立、数据传输、连接释放。

阶段 1：三次握手（Three-way Handshake）

建立连接过程：

  1. SYN：客户端发送 SYN=1, seq=x，进入 SYN-SENT 状态
  2. SYN-ACK：服务器回复 SYN=1, ACK=1, seq=y, ack=x+1
  3. ACK：客户端发送 ACK=1, ack=y+1，连接建立

✅ 目的：双方确认彼此具有发送和接收能力

阶段 2：数据传输

  • 双方通过序列号（seq）和确认号（ack） 实现可靠传输
  • 使用滑动窗口实现流量控制
  • 通过慢启动、拥塞避免等机制进行拥塞控制

阶段 3：四次挥手（Four-way Wave）

断开连接过程：

  1. FIN：主动方发送 FIN=1, seq=u
  2. ACK：被动方确认 ACK=1, ack=u+1
  3. FIN：被动方发送自己的 FIN=1, seq=v
  4. ACK：主动方确认 ACK=1, ack=v+1，进入 TIME_WAIT 状态

✅ 为什么四次？因为 TCP 是全双工，两个方向需独立关闭。

3.1.4 TCP 通信模型
特性说明
连接模式面向连接（需先建立连接）
可靠性高（通过确认、重传、校验和）
传输单位字节流（无消息边界）
流量控制滑动窗口机制
拥塞控制慢启动、拥塞避免、快速重传、快速恢复
适用场景文件传输、网页访问、邮件等要求可靠的应用
3.1.5 TCP 报文结构
字段说明
源端口 / 目的端口标识应用进程
序列号（seq）当前数据第一个字节的编号
确认号（ack）期望收到的下一个字节序号
数据偏移TCP 头部长度（通常 20 字节）
控制位SYN, ACK, FIN, RST, PSH 等
窗口大小接收方当前可接收的字节数
校验和用于检测数据错误
3.1.6 适用场景
应用场景示例
🌐 网页浏览HTTP/HTTPS 基于 TCP
📧 电子邮件SMTP、POP3、IMAP
📂 文件传输FTP、SFTP
💬 远程登录SSH、Telnet
🗄️ 数据库访问MySQL、Redis（默认）
3.1.7 与 UDP 的对比
对比项TCPUDP
连接性面向连接无连接
可靠性可靠（确认、重传）不可靠（尽最大努力交付）
传输方式字节流数据报（有边界）
速度较慢（握手、确认开销）快（无连接、无确认）
拥塞控制有无
适用场景要求数据完整要求低延迟
3.1.8 总结
项目说明
TCP 是什么一种面向连接、可靠的传输层协议
核心机制三次握手、确认重传、滑动窗口、拥塞控制
主要用途可靠数据传输（如网页、文件、邮件）
关键优势可靠、有序、不重复、流量控制
发展趋势仍是互联网最主流的传输协议，持续优化（如 TCP BBR）

✅ 一句话总结：
TCP 通过连接管理和确认机制，确保数据在网络中可靠、有序地传输，是互联网通信的“基石协议”。

3.2 UDP协议

3.2.1 基本介绍

UDP（User Datagram Protocol，用户数据报协议）是一种无连接、不可靠、基于数据报的传输层协议（RFC 768），强调传输效率和低延迟。

  • 协议特点：无连接、尽最大努力交付、无重传、无拥塞控制
  • 默认端口示例：
    • DNS: 53
    • DHCP: 67/68
    • SNMP: 161
    • 视频/语音：动态端口
  • 设计目标：提供轻量级、低延迟的数据传输服务
3.2.2 为什么需要 UDP

TCP 的可靠性带来较大开销，不适合以下场景：

问题说明
延迟敏感实时音视频不能等待重传
高频小包如游戏状态更新，重传反而造成混乱
广播/多播TCP 不支持，UDP 支持
自定义可靠性应用层可自行实现轻量级重传机制

UDP 通过“简单直接”的设计满足这些需求。

3.2.3 UDP 的工作过程

UDP 通信极简，无需握手或挥手：

  1. 发送方：构造 UDP 数据报，直接发送
  2. 接收方：收到数据报后处理，不发送确认
  3. 无连接状态维护，每个数据报独立处理

⚠️ 数据可能丢失、乱序、重复，但速度极快。

3.2.4 UDP 通信模型
特性说明
连接模式无连接（发送即走）
可靠性不可靠（不保证送达）
传输单位数据报（有明确边界）
传输开销极小（仅 8 字节头部）
支持广播/多播✅ 支持
适用场景实时音视频、在线游戏、DNS 查询
3.2.5 UDP 报文结构
字段说明
源端口 / 目的端口标识应用进程（可选）
长度数据报总长度（头部 + 数据）
校验和可选，用于检测错误

✅ 头部仅 8 字节，非常轻量。

3.2.6 适用场景
应用场景示例
🎵 实时音视频视频会议（WebRTC）、直播
🎮 在线游戏多人游戏状态同步
🔍 域名查询DNS 查询响应
📡 广播/多播局域网发现、流媒体分发
🛰️ 物联网传感器数据上报
3.2.7 与 TCP 的对比
对比项TCPUDP
连接性面向连接无连接
可靠性可靠不可靠
传输方式字节流数据报
速度较慢快
拥塞控制有无
适用场景要求完整要求低延迟
3.2.8 总结
项目说明
UDP 是什么一种无连接、不可靠的传输层协议
核心机制简单数据报传输，无握手、无确认
主要用途实时通信、广播、轻量级传输
关键优势低延迟、高效率、支持广播
发展趋势在实时通信、物联网、QUIC（基于 UDP）中广泛应用

✅ 一句话总结：
UDP 以“简单高效”为核心，牺牲可靠性换取速度，是实时应用和轻量通信的理想选择。

4. 网络层协议

4.1 IP协议

4.1.1 基本介绍

IP（Internet Protocol，网际协议）是网络层的核心协议（IPv4: RFC 791，IPv6: RFC 2460），负责寻址和路由，将数据包从源地址传送到目的地址。

  • 协议版本：
    • IPv4：32 位地址（如 192.168.1.1），约 43 亿地址
    • IPv6：128 位地址（如 2001:db8::1），地址空间极大
  • 协议特点：无连接、不可靠、尽力而为（Best Effort）
  • 设计目标：实现跨网络的主机间数据包传输
4.1.2 为什么需要 IP

数据通信需跨越多个网络，面临问题：

问题说明
寻址混乱需统一地址格式标识全球主机
路由选择数据包需通过多跳路由器到达目标
分片与重组不同网络 MTU 不同，需分片传输
异构网络互联以太网、Wi-Fi、蜂窝网络需统一协议

IP 协议通过统一地址、路由算法、分片机制实现全球互联。

4.1.3 IP 的工作过程
  1. 封装：传输层数据（TCP/UDP 报文）封装为 IP 数据报
  2. 路由：路由器根据目标 IP 地址查找路由表，转发数据包
  3. 分片（IPv4）：若数据包大于链路 MTU，则分片
  4. 重组：目标主机重新组装分片
  5. 交付：将数据交付给上层协议（通过协议号）

✅ IPv6 不推荐在中间路由器分片，由源端通过 PMTUD 探测路径 MTU。

4.1.4 IP 通信模型
特性说明
连接模式无连接（每个数据包独立处理）
可靠性不可靠（不保证送达、不重传）
传输单位IP 数据报（Datagram）
寻址方式IP 地址（IPv4/IPv6）
路由机制动态路由协议（如 OSPF、BGP）
分片支持IPv4 支持，IPv6 由源端处理
4.1.5 IP 报文结构
字段说明
版本4（IPv4）或 6（IPv6）
头部长度通常 20 字节
总长度数据报总长度
标识、标志、片偏移用于分片与重组
生存时间（TTL）防止无限循环，每经过一跳减 1
协议上层协议类型（6: TCP, 17: UDP）
首部校验和仅校验 IP 头部
源 IP 地址 / 目的 IP 地址32 位（IPv4）或 128 位（IPv6）
4.1.6 适用场景
应用场景说明
🌍 全球互联网通信所有跨网络通信的基础
🖥️ 局域网通信内网主机间通信（如 192.168.x.x）
📱 移动网络4G/5G 网络中数据传输
🌐 网站访问通过 IP 地址定位服务器
🔗 路由器转发核心路由协议依赖 IP
4.1.7 与 TCP/UDP 的对比
对比项IPTCPUDP
层级网络层传输层传输层
功能寻址与路由可靠传输高效传输
是否可靠否是否
是否面向连接否是否
传输单位数据报字节流 / 数据报数据报
4.1.8 总结
项目说明
IP 是什么网络层核心协议，负责寻址与路由
核心机制IP 地址、路由表、TTL、分片
主要用途实现全球主机间的数据包传输
关键优势统一寻址、支持异构网络互联
发展趋势IPv6 逐步取代 IPv4，解决地址枯竭问题

✅ 一句话总结：
IP 协议通过统一的地址体系和路由机制，实现了全球互联网的互联互通，是网络世界的“邮政系统”。

http://www.dtcms.com/a/330205.html

相关文章：

  • 基于SpringBoot+Vue的智能消费记账系统（AI问答、WebSocket即时通讯、Echarts图形化分析）
  • Python 类元编程(元类基础知识)
  • 推荐系统论文分享之多任务模型--PLE(二)
  • python与JavaScript的区别
  • MoviiGen1.1模型脚本调用
  • C语言队列的实现
  • AUTOSAR进阶图解==＞AUTOSAR_SWS_TTCANInterface
  • 开发避坑指南（25）：MySQL不支持带有limit语句的子查询的解决方案
  • 【学习嵌入式day23-Linux编程-文件IO】
  • imx6ull-驱动开发篇22——Linux 时间管理和内核定时器
  • 力扣top100(day02-04)--二叉树 01
  • 18.10 SQuAD数据集实战：5步高效获取与预处理，BERT微调避坑指南
  • 数据分析可视化学习总结（美妆2）
  • Python解包技巧全解析
  • Python 基础语法（一）
  • 多处理器技术：并行计算的基石与架构演进
  • 疯狂星期四文案网第38天运营日记
  • 继《念念有词》后又一作品《双刃》开播 马来西亚新人演员业文Kevin挑战多面角色引期待
  • CF每日3题(1600)
  • element-ui 时间线（timeLine）内容分成左右两侧
  • npm run dev 的作用
  • Unity_2D动画
  • 游戏盾的安全作用
  • RK3568嵌入式音视频硬件编解码4K 60帧 rkmpp FFmpeg7.1 音视频开发
  • Celery+RabbitMQ+Redis
  • Traceroute命令使用大全：从原理到实战技巧
  • IPC Inter-Process Communication（进程间通信）
  • 2小时构建生产级AI项目：基于ViT的图像分类流水线（含数据清洗→模型解释→云API）（第十七章）
  • 基于Supervision工具库与YOLOv8模型的高效计算机视觉任务处理与实践
  • 1.Cursor快速入门与配置