Zephyr网络协议栈：嵌入式物联网设备网络连接的核心解决方案-平芜编程栈

1. 从“嵌入式”到“万物互联”：Zephyr网络协议栈的定位与价值

如果你和我一样，在嵌入式领域摸爬滚打多年，从8位单片机玩到32位MCU，再到如今各种带网络功能的SoC，那你一定对“网络协议栈”这四个字又爱又恨。爱的是，它让我们的设备不再是信息孤岛，可以轻松接入互联网，实现远程控制、数据上报；恨的是，在资源捉襟见肘的嵌入式环境中，移植一个完整的、稳定的网络协议栈，往往意味着无尽的调试、裁剪和适配，其工作量有时甚至超过了应用逻辑本身。而Zephyr的出现，特别是其内置的、深度集成的网络协议栈，正在从根本上改变这个局面。它不是一个简单的“库”或“组件”，而是一个为资源受限设备量身定制的、从物理层到应用层的完整网络解决方案。

简单来说，Zephyr的网络协议栈是Zephyr RTOS（实时操作系统）的核心子系统之一。它的目标非常明确：在保证实时性、低功耗和极小内存占用的前提下，为物联网设备提供可靠、安全、标准的网络连接能力。这听起来像是所有RTOS的梦想，但Zephyr真正做到了“开箱即用”。你不再需要费尽心思去移植LwIP、Contiki或者自己写驱动适配，Zephyr已经将IP、TCP、UDP、ICMP、DHCP、DNS、HTTP、MQTT、CoAP等主流协议，以及以太网、Wi-Fi、蓝牙、LoRa、NB-IoT等多种网络接口，深度整合进了其统一的内核架构中。这意味着，当你选择Zephyr作为项目的基础时，网络连接能力是“自带”的，你只需要通过Kconfig菜单像点菜一样选择你需要的协议和驱动，然后调用一套统一的、线程安全的Socket API进行开发即可。

这种设计带来的价值是巨大的。首先，它极大地降低了开发门槛和周期。开发者可以将精力集中在业务逻辑和创新上，而不是底层网络驱动的调试上。其次，它保证了代码的一致性和可维护性。无论你的设备使用哪种网络硬件（比如从ESP32的Wi-Fi切换到STM32的以太网），上层的应用代码几乎无需改动。最后，也是最重要的，Zephyr背后有Linux基金会和庞大的社区支持，其网络协议栈持续演进，紧跟最新的物联网安全标准（如DTLS、TLS）和协议（如MQTT 5.0、HTTP/2），这对于需要产品长期维护和升级的团队来说，是至关重要的保障。接下来，我们就深入这个协议栈的内部，看看它是如何被“设计”出来的。

2. 架构深潜：Zephyr网络协议栈的分层设计与核心模块

理解Zephyr网络协议栈，不能把它看成一个黑盒。它的架构清晰反映了经典网络分层思想，同时又针对嵌入式场景做了大量优化。我们可以把它自上而下分为几个关键层次：应用层/套接字接口层、网络协议层、网络设备驱动层以及数据缓冲区管理。每一层都有其独特的职责和设计哲学。

2.1 统一的套接字抽象层：屏蔽底层的复杂性

对于应用开发者而言，最直接的接口就是BSD风格的套接字API。Zephyr提供了<sys/socket.h>中定义的标准函数，如socket(),bind(),connect(),send(),recv(),close()等。这套API与你在Linux或Windows上使用的非常相似，这极大地降低了学习成本。但关键在于，Zephyr在底层实现上做了大量工作来保证这套API在单线程、多线程以及协作式、抢占式内核下的线程安全性和确定性。

例如，当你调用一个阻塞式的recv()时，Zephyr内核会挂起当前线程，并把它放入该套接字对应的等待队列。当网络底层有数据包到达并处理完毕后，会触发一个内核事件，唤醒等待的线程。这个过程完全由内核调度器管理，应用开发者无需关心底层的信号量或互斥锁。这种设计使得编写网络应用和编写普通的、事件驱动的嵌入式程序一样直观。

注意：虽然API是标准的，但在资源受限系统中，你需要特别注意套接字选项和缓冲区大小。默认的发送/接收缓冲区可能很小，对于大数据量传输，你可能需要通过setsockopt()来调整SO_SNDBUF和SO_RCVBUF。同时，非阻塞模式（O_NONBLOCK）结合poll()或select()（Zephyr也支持）是构建高效事件驱动网络应用的推荐方式，可以避免线程长时间阻塞。

2.2 网络协议层：从IP到应用协议的完整拼图

这是协议栈的核心。Zephyr实现了从网络层到应用层的一系列协议：

网络层：完整支持IPv4和IPv6（包括双栈）。实现了IP数据包的分片与重组、路由表管理。这是设备能够接入互联网的基础。
传输层：可靠传输的TCP和轻量级无连接的UDP是标配。Zephyr的TCP实现经过了优化，在内存使用和连接管理上比传统的LwIP更为精简，同时保持了良好的互操作性。
应用层协议：这是物联网场景的焦点。Zephyr原生集成了：
- HTTP/HTTPS：用于RESTful API交互或简单的网页服务。
- MQTT：物联网消息协议的事实标准，支持MQTT 3.1.1和5.0，内置了重连、遗嘱消息、QoS等级等特性。
- CoAP：专为受限设备设计的RESTful协议，基于UDP，比HTTP更轻量。
- DNS：域名解析客户端。
- DHCP：动态获取IP地址。
安全层：安全不是可选项。Zephyr集成了mbed TLS（现为PSA Crypto）作为其加密后端，为TCP（TLS）和UDP（DTLS）提供传输层安全，也为应用层协议如HTTPS、MQTT over TLS/SSL提供支持。密钥和证书的管理也有一套完整的机制。

这些协议并非全部强制链接，而是通过Zephyr强大的Kconfig配置系统进行模块化选择。你可以在prj.conf文件中用类似CONFIG_NET_TCP=y、CONFIG_MQTT=y这样的语句来启用或禁用特定协议，从而精确控制最终固件的大小。

2.3 网络设备驱动与L2层：硬件多样性的统一接口

Zephyr支持的网络接口（NIC）类型非常丰富：以太网（ETH）、Wi-Fi（如ESP32、Infineon、Intel等）、蓝牙（BLE IPSP）、IEEE 802.15.4（用于Thread、Zigbee）、蜂窝网络（如NB-IoT、LTE-M的调制解调器驱动）、以及CAN总线等。每种硬件都有对应的驱动。

这些驱动通过一个统一的网络设备接口与上层协议栈通信。这个接口定义了一套标准的操作函数集（struct net_if_api），包括发送、接收、打开、关闭等。任何网络驱动只要实现了这套接口，就能被协议栈识别和使用。当驱动从硬件收到一个原始数据帧（如以太网帧）后，它会将其放入一个网络数据包缓冲区，然后递交给协议栈的L2层进行处理（如以太网解包、MAC地址过滤等），再根据协议类型（如IPv4、IPv6、ARP）传递给相应的网络层处理程序。

这种设计使得添加一个新的网络硬件支持变得相对规范。驱动开发者只需关注硬件特定的初始化、发送和接收逻辑，而不需要理解整个协议栈的运作。

2.4 数据包缓冲区（Net Buffer）管理：性能与效率的关键

在内存稀缺的嵌入式系统中，如何高效地管理网络数据包是协议栈设计的重中之重。Zephyr设计了其独有的网络数据包缓冲区架构。一个数据包（struct net_pkt）并不是一整块连续的内存，而是由多个数据缓冲区（struct net_buf）通过链表连接而成。

这种“碎片化”存储有几个巨大优势：

零拷贝：当数据从应用层传递到驱动层，或在不同协议层间传递时，可以只传递net_pkt和net_buf的指针和描述信息，而无需复制实际数据内容，极大提升了效率。
高效的内存利用：可以充分利用内存池中预先分配好的、固定大小的net_buf块来组装不同长度的数据包，避免了为最大传输单元（MTU）分配大块内存造成的浪费。
易于分片与重组：对于IP分片或TCP流式数据，这种链表结构天然适合数据的添加和截取。

理解net_buf和net_pkt的关系，是进行高级网络编程（如自定义协议解析、高效数据搬运）的基础。通常，应用开发者使用标准的Socket API无需直接操作它们，但当你需要深度优化或调试底层数据流时，它们就至关重要了。

3. 实战配置与构建：从零开始让一个设备“上网”

理论说得再多，不如动手一试。让我们以一个典型的场景为例：在一块支持Wi-Fi的开发板（比如常见的ESP32或nRF52840 DK配合外置Wi-Fi模块）上，配置Zephyr使其能够通过Wi-Fi连接到路由器，并作为一个TCP客户端发送“Hello World”。

3.1 项目环境准备与基础配置

首先，确保你已经安装了Zephyr的开发环境（SDK、工具链等）。我们创建一个新的应用程序目录，例如hello_wifi。在项目根目录下，最重要的就是prj.conf配置文件。这个文件决定了你的固件包含哪些功能。

一个最基础的、使能Wi-Fi和TCP的配置可能如下所示：

# 启用网络支持 CONFIG_NETWORKING=y # 启用网络日志，便于调试（生产环境可关闭） CONFIG_NET_LOG=y # 启用IP层支持（IPv4） CONFIG_NET_IPV4=y CONFIG_NET_IPV6=n # 本例先禁用IPv6以简化 # 启用TCP支持 CONFIG_NET_TCP=y # 启用Wi-Fi支持 CONFIG_WIFI=y # 选择你使用的Wi-Fi驱动，例如对于ESP32 AT命令模式 CONFIG_WIFI_ESP_AT=y # 启用套接字API CONFIG_NET_SOCKETS=y CONFIG_NET_SOCKETS_POSIX_NAMES=y # 使用标准的POSIX socket函数名 # 启用必要的网络服务 CONFIG_DNS_RESOLVER=y CONFIG_NET_DHCPV4=y # 通过DHCP自动获取IP # 堆栈大小调整（网络任务需要一定栈空间） CONFIG_MAIN_STACK_SIZE=4096 CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096

这份配置就像一个功能清单，告诉构建系统：“我需要网络、Wi-Fi、TCP、DHCP和Socket功能。”

3.2 Wi-Fi连接管理的代码实现

接下来是主程序。Zephyr提供了一套网络管理连接管理库来简化Wi-Fi/蜂窝等需要凭证的连接过程。你需要定义一个struct wifi_connect_req_params结构体来存储SSID和密码，然后调用net_mgmtAPI来触发连接。

#include <zephyr/net/wifi_mgmt.h> #include <zephyr/net/net_mgmt.h> #include <zephyr/net/net_if.h> #include <zephyr/net/socket.h> #include <zephyr/logging/log.h> LOG_MODULE_REGISTER(hello_wifi, LOG_LEVEL_DBG); static struct net_mgmt_event_callback wifi_cb; void handle_wifi_events(struct net_mgmt_event_callback *cb, uint32_t mgmt_event, struct net_if *iface) { if (mgmt_event == NET_EVENT_WIFI_CONNECT_RESULT) { int status = *((int *)cb->info); if (status) { LOG_ERR("Wi-Fi连接失败: %d", status); } else { LOG_INF("Wi-Fi连接成功！"); // 连接成功后，可以在这里触发TCP连接 } } else if (mgmt_event == NET_EVENT_IPV4_ADDR_ADD) { LOG_INF("已获取到IP地址"); // 此时可以安全地进行网络通信了 } } void wifi_connect(void) { struct net_if *iface = net_if_get_default(); struct wifi_connect_req_params params = {0}; params.ssid = "你的Wi-Fi SSID"; params.ssid_length = strlen(params.ssid); params.psk = "你的Wi-Fi密码"; params.psk_length = strlen(params.psk); params.channel = WIFI_CHANNEL_ANY; params.security = WIFI_SECURITY_TYPE_PSK; net_mgmt_init_event_callback(&wifi_cb, handle_wifi_events, NET_EVENT_WIFI_CONNECT_RESULT | NET_EVENT_IPV4_ADDR_ADD); net_mgmt_add_event_callback(&wifi_cb); int err = net_mgmt(NET_REQUEST_WIFI_CONNECT, iface, &params, sizeof(params)); if (err) { LOG_ERR("无法发起Wi-Fi连接请求: %d", err); } }

这段代码的核心是事件驱动。你发起连接请求后，不必忙等待，系统会在后台处理。连接结果（成功或失败）以及IP地址获取成功都会通过你注册的回调函数异步通知。这是一种非常“嵌入式”、节省资源的做法。

3.3 建立TCP Socket并进行通信

假设我们要连接到一个在192.168.1.100:8080上运行的TCP服务器。在Wi-Fi连接成功并获取到IP后（例如在NET_EVENT_IPV4_ADDR_ADD事件回调中），我们可以建立Socket连接。

int setup_tcp_client(void) { int sock; struct sockaddr_in server_addr; // 创建TCP Socket sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); if (sock < 0) { LOG_ERR("无法创建Socket: %d", errno); return -1; } // 配置服务器地址 server_addr.sin_family = AF_INET; server_addr.sin_port = htons(8080); // 端口号 inet_pton(AF_INET, "192.168.1.100", &server_addr.sin_addr); // 连接服务器 if (connect(sock, (struct sockaddr *)&server_addr, sizeof(server_addr)) < 0) { LOG_ERR("连接失败: %d", errno); close(sock); return -1; } LOG_INF("已连接到TCP服务器"); // 发送数据 const char *send_buf = "Hello from Zephyr!\n"; int sent = send(sock, send_buf, strlen(send_buf), 0); if (sent < 0) { LOG_ERR("发送失败: %d", errno); } else { LOG_INF("已发送 %d 字节", sent); } // 这里可以添加接收数据的逻辑... // char recv_buf[128]; // int received = recv(sock, recv_buf, sizeof(recv_buf)-1, 0); close(sock); return 0; }

这段代码和你在任何Unix-like系统上写的TCP客户端代码几乎一模一样。Zephyr的Socket API兼容性在这里得到了充分体现。构建这个项目（使用west build），烧录到设备，如果一切配置正确，你就能在服务器的终端上看到来自嵌入式设备的问候了。

实操心得：在第一次调试网络应用时，强烈建议先使用CONFIG_NET_LOG=y并设置较高的日志级别（如LOG_LEVEL_DBG）。Zephyr的网络子系统会打印出非常详细的流程信息，比如Socket创建、绑定、连接、数据发送接收的每个步骤，以及错误码。这比盲目猜测问题所在要高效得多。同时，确保你的设备能正确连接到Wi-Fi并获取IP（可以通过net ifaceshell命令查看），这是所有上层通信的基础。

4. 高级主题与性能调优：超越“Hello World”

当基础通信跑通后，我们会面临更实际的挑战：如何保证稳定性？如何提升性能？如何适应复杂的网络环境？Zephyr网络协议栈提供了一系列高级特性和调优点。

4.1 连接管理与重连策略

物联网设备运行环境复杂，网络中断是常态。一个健壮的应用必须能处理断线重连。对于MQTT这样的协议，Zephyr的客户端库通常内置了重连机制。但对于自定义的TCP长连接，你需要自己实现。

一个简单的策略是使用一个工作队列或专用线程来管理连接状态机：

连接状态：初始化 -> 连接中 -> 已连接 -> 断开/错误。
断线检测：可以通过send()或recv()返回错误（如-1且errno为ECONNRESET、ETIMEDOUT），或者设置Socket选项SO_KEEPALIVE让TCP层自动探测。
指数退避重连：一旦检测到断开，不要立即重连，而是等待一个时间间隔（如1秒、2秒、4秒、8秒...直到一个最大值），然后尝试重连。这可以避免在服务器临时故障时对其造成洪泛攻击。

// 伪代码示例 static int reconnect_delay = 1; while (1) { if (setup_tcp_client() == 0) { reconnect_delay = 1; // 连接成功，重置延迟 // ... 进行数据通信 ... while (is_connection_ok()) { // 正常业务循环 } LOG_WRN("连接断开"); } else { LOG_ERR("连接失败，%d秒后重试...", reconnect_delay); k_sleep(K_SECONDS(reconnect_delay)); reconnect_delay = MIN(reconnect_delay * 2, 64); // 指数退避，上限64秒 } }

4.2 内存与线程栈的精细调优

网络协议栈是内存消耗大户。你需要根据实际使用的协议和并发连接数来调整相关配置。关键配置项通常在Kconfig中：

CONFIG_NET_BUF_RX_COUNT和CONFIG_NET_BUF_TX_COUNT：分别控制接收和发送方向的网络缓冲区数量。如果频繁出现发送失败或丢包，可能需要增加这些值。
CONFIG_NET_PKT_RX_COUNT和CONFIG_NET_PKT_TX_COUNT：网络数据包结构的数量。
CONFIG_NET_TC_TX_COUNT和CONFIG_NET_TC_RX_COUNT：流量控制的线程数量。
线程栈大小：网络处理运行在系统工作队列或专用的网络线程中。如果栈溢出，会导致各种诡异崩溃。如果启用了很多协议或处理复杂数据，可能需要增加CONFIG_NET_RX_STACK_SIZE和CONFIG_NET_TX_STACK_SIZE，以及你应用线程的栈大小（CONFIG_MAIN_STACK_SIZE）。

调试内存不足的一个有效方法是使用Zephyr的堆和栈分析工具。在配置中启用CONFIG_INIT_STACKS=y和CONFIG_THREAD_STACK_INFO=y，然后在运行时通过shell命令或代码查询栈的使用情况。

4.3 安全通信：TLS/DTLS集成实践

在物联网中，传输安全是底线。Zephyr通过mbed TLS（PSA）集成提供了TLS/DTLS支持。要使用安全Socket，你需要：

启用安全配置：

CONFIG_NET_SOCKETS_SOCKOPT_TLS=y CONFIG_MBEDTLS=y CONFIG_MBEDTLS_BUILTIN=y # 使用内置的mbedtls库 CONFIG_MBEDTLS_ENABLE_HEAP=y # 如果证书较大可能需要堆支持

准备证书：你需要服务器的CA证书（用于验证服务器），有时还需要客户端证书和私钥（用于双向认证）。这些通常以PEM或DER格式存储为文件，并在编译时通过CONFIG_MBEDTLS_PEM_CERTIFICATE_FORMAT等选项嵌入固件，或存储在文件系统、安全元件中。

创建安全Socket：创建Socket的步骤与普通TCP类似，但在连接前后需要设置TLS参数。

int sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TLS_1_2); // 注意协议类型 // ... 设置服务器地址 ... // 设置TLS选项：加载CA证书 sec_tag_t sec_tag_list[] = { MY_CA_CERT_TAG }; setsockopt(sock, SOL_TLS, TLS_SEC_TAG_LIST, sec_tag_list, sizeof(sec_tag_list)); setsockopt(sock, SOL_TLS, TLS_HOSTNAME, "my.server.com", strlen("my.server.com")); // 然后调用 connect()

这里的MY_CA_CERT_TAG是一个标识符，指向你之前通过tls_credential_add()函数添加的证书数据。

配置TLS是整个过程中最易出错的一环，常见问题包括证书格式不对、证书链不完整、主机名不匹配等。务必仔细阅读Zephyr文档中关于凭证管理的部分，并充分利用日志来排查问题。

4.4 多协议共存与网络接口管理

一个复杂的设备可能同时拥有多个网络接口，比如同时连接Wi-Fi和蓝牙，或者通过以太网备份。Zephyr支持多网络接口，每个接口（struct net_if）都有其索引和属性。你可以通过net_if_get_default()获取默认接口，也可以通过net_if_get_by_index()遍历所有接口。

协议栈会根据路由表自动选择出口接口。你也可以在创建Socket后，使用setsockopt()和SO_BINDTODEVICE选项（如果配置支持）将Socket绑定到特定接口。这对于实现诸如“数据优先通过蜂窝网络，Wi-Fi仅用于配置”的策略非常有用。

5. 调试技巧与常见问题排查指南

即使按照指南操作，在实际硬件上调试网络问题也常常令人头疼。以下是我在多个项目中总结出的Zephyr网络问题排查路径和工具箱。

5.1 分层排查法：从物理连接到应用逻辑

当设备无法联网时，不要一头扎进应用代码。应该自底向上，逐层确认：

物理层与驱动层：
- 检查硬件连接：网线是否插好？Wi-Fi天线是否连接？模块供电是否稳定？
- 检查驱动初始化：查看启动日志，确认你的网络驱动（如wifi_esp_at或eth_stm32）是否成功初始化，有无报错（如初始化超时、通信失败）。
- 使用Shell命令：Zephyr提供了强大的网络Shell。通过串口连接，输入net iface可以列出所有网络接口及其状态（UP/DOWN）、IP地址、MAC地址等。输入net stats可以查看各层的统计数据（收发包数、错误数），这对判断丢包发生在哪一层非常有用。
网络层与连接层：
- IP地址获取：如果使用DHCP，设备是否成功获取到了IP（net iface查看）？如果没有，检查路由器DHCP服务是否开启，或者尝试配置静态IP测试。
- 路由与连通性：获取IP后，尝试用net ping <网关IP>测试是否能ping通网关。这是检验L3层是否通畅的关键。如果ping不通网关，问题可能出在驱动或网络配置（子网掩码错误）。
- 防火墙与服务器：确保你要连接的服务器的端口是开放的，并且没有防火墙阻拦。
传输层与应用层：
- Socket创建与选项：检查socket()调用的返回值。检查setsockopt()设置是否正确（特别是TLS相关选项）。
- 连接错误：connect()或send()/recv()失败后，立即打印errno。常见的错误码如：
  - EHOSTUNREACH/ENETUNREACH: 网络不可达，检查路由。
  - ECONNREFUSED: 连接被拒绝，服务器端口未监听。
  - ETIMEDOUT: 连接超时，网络延迟大或服务器无响应。
  - EAGAIN/EWOULDBLOCK: 在非阻塞模式下资源暂时不可用。
- 协议逻辑：对于MQTT、HTTP等高级协议，使用Wireshark在服务器侧或网关侧抓包，对比客户端发出的数据包是否符合协议规范（如MQTT Connect报文格式是否正确）。Zephyr的协议实现通常很标准，问题常出在应用层填充的参数上。

5.2 核心调试工具：网络Shell与日志

Zephyr的网络Shell是你最好的朋友。除了上述命令，还有：

net dns：管理DNS服务器和进行域名解析测试。
net tcp：查看当前的TCP连接状态。
net conn：查看所有网络连接。
net route：查看和修改路由表。
net ping：执行ICMP ping测试。

将CONFIG_NET_SHELL=y和CONFIG_NET_LOG=y加入你的调试版本，这些工具能提供无可替代的实时状态信息。

5.3 典型问题场景与解决方案

问题：Wi-Fi能连接，但获取不到IP（DHCP失败）。
- 排查：使用net iface查看接口状态。打开CONFIG_NET_DHCPV4_LOG_LEVEL_DBG查看DHCP交互日志。常见原因：路由器DHCP服务器已满；设备与路由器安全模式不兼容（如WPA3与旧驱动）；信号太弱。
- 解决：尝试静态IP测试，确认硬件链路正常。简化Wi-Fi安全设置（如先改用开放网络测试）。检查驱动是否支持当前路由器的认证方式。
问题：TCP连接成功，但发送数据后对方收不到，或send()阻塞/返回错误。
- 排查：首先检查send()的返回值。如果是正数，表示数据已被协议栈接受，但不一定已发送到网络。使用net stats查看send和send_err计数。如果send_err增加，可能是网络缓冲区不足。
- 解决：增加CONFIG_NET_BUF_TX_COUNT。检查对端是否及时recv()，如果对端接收窗口满，本端的发送也会被阻塞。考虑使用非阻塞Socket并配合poll()管理。
问题：启用TLS后，connect()失败。
- 排查：检查errno。启用mbedTLS的调试日志CONFIG_MBEDTLS_DEBUG=y并设置CONFIG_MBEDTLS_LOG_LEVEL_DBG。日志会详细显示TLS握手过程，在哪一步失败（如证书验证失败、协商套件不匹配）。
- 解决：确保证书格式正确且已通过tls_credential_add()添加。检查服务器主机名是否与证书中的Common Name或Subject Alternative Name匹配。对于自签名证书，可能需要禁用对端验证（仅用于测试，生产环境禁用）。
问题：设备运行一段时间后死机或重启。
- 排查：这很可能是栈溢出或内存耗尽。启用CONFIG_INIT_STACKS=y和CONFIG_THREAD_STACK_INFO=y，在死机前通过shell命令kernel stacks查看各线程栈使用水位。同时，监控堆内存使用情况。
- 解决：增加相关线程的栈大小。检查是否有内存泄漏，例如创建了Socket或分配了缓冲区但没有释放。确保网络事件回调函数执行时间尽可能短，不要在其中进行复杂操作。