深入 Linux 内核理解 TCP 状态机与性能调优

1. 前言 (Introduction)

1.1 破除“Socket API”的幻觉

在计算机网络的基础教学中，TCP/IP 往往被简化为一组标准的 Socket API：socket、bind、listen、connect、accept。许多初级开发者认为，只要熟练掌握这几个函数的调用顺序，就学会了网络编程。

然而，在C++ 游戏服务端开发（特别是 MOBA、FPS 或 MMORPG 等对延迟极度敏感的品类）的战场上，这种认知是危险的。

对于高性能服务器而言，Socket API 仅仅是冰山一角。真正的博弈发生在Linux 内核网络栈的深处。当你调用listen()时，你是否知道内核为你维护了几个队列？当你调用send()返回成功时，数据真的离网卡发出去了吗？还是仅仅被拷贝到了内核的sk_buff缓冲区里睡大觉？当你的服务器遭受 SYN Flood 攻击时，你的代码能做什么，还是只能眼睁睁看着accept阻塞？

“会用 API”只是 CRUD 程序员的基准线，而“理解 API 背后的内核行为”才是服务端工程师需要具备的。

1.2 游戏业务的核心痛点

在实际的生产环境中，对 TCP 协议机制理解的缺失，往往直接导致各类“无法复现”的诡异故障，这些问题是游戏运营的噩梦：

• 延迟抖动 (Lag Spike)：玩家反馈操作有明显的“顿挫感”，Ping 值忽高忽低。这往往不是网络卡顿，而是Nagle 算法与Delayed ACK在内核中发生的死锁。
• 假死与掉线 (Zombie Connections)：玩家明明还在通过 4G 网络疯狂释放技能，服务器却判定其断开连接；或者玩家已经断电下线，服务器却还保留着连接直到内存耗尽。这是TCP Keep-Alive（默认2小时）与运营商 NAT 超时（往往仅60秒）之间不对等的博弈。
• 高并发瓶颈 (Concurrency Limit)：线上活动开启瞬间，数万玩家同时登录，服务器 CPU 负载不高，但大量玩家连接超时。这是SYN Queue或Accept Queue溢出导致的灾难。
• 资源泄漏 (Resource Leak)：服务器运行几天后崩溃，报错Too many open files，排查发现是代码逻辑导致了大量的CLOSE_WAIT残留。

1.3 本文目标：穿透内核的迷雾

本文将不会重复教科书式的“三次握手、四次挥手”流程图背诵。我们的目标是穿透 API 表层，深入 Linux 内核，从以下三个维度重构对 TCP 状态机的认知：

1. 队列管理：剖析 SYN_RCVD 与 ESTABLISHED 状态背后的半连接/全连接队列机制及溢出处理。
2. 异常控制：探讨 RST 强踢、僵尸连接检测以及 TIME_WAIT/CLOSE_WAIT 的资源治理。
3. 算法博弈：揭示滑动窗口、流控与 BBR 拥塞控制算法如何决定数据的吞吐与延迟。

作为 C++ 服务端开发学习者，我们不仅要写出跑得通的代码，更要具备通过内核参数调优 (sysctl)和Socket 选项优化 (setsockopt)来驾驭千万级连接的能力。

2. 连接建立：三次握手与其背后的两个队列 (Connection Establishment)

核心知识点：request_sockvstcp_sock| SYN Flood | Syncookies 隐性代价 | backlog 陷阱

在 Linux 内核（v4.x/v5.x）的视角下，三次握手不仅仅是状态机的流转，更是内存对象从轻量级到重量级的“升级”过程。理解这一过程，是解决高并发下“连接超时”问题的关键。

2.1 握手流程再审视：内核对象的蜕变

当我们在 C++ 代码中调用accept()时，其实连接早已建立好了。真正的“战斗”发生在内核的软中断（SoftIRQ）处理中。

1. SYN 到达 (SYN_RCVD 状态) —— 轻量级存储：
   当 Server 收到 SYN 包，内核不会直接分配一个完整的struct tcp_sock（约 2KB+）。这太浪费内存，且容易被攻击。
   内核分配一个迷你的struct request_sock（只记录 IP、Port、ISN 等必要元数据），并将其挂入SYN Queue (半连接队列)。

• 数据结构：SYN Queue 本质上是一个Hash Table，用于快速查找。

• ACK 到达 (ESTABLISHED 状态) —— 查找与升级：
  Client 回复 ACK 后，内核在 SYN Queue 的 Hash 表中找到对应的request_sock。
  验证无误后，内核执行tcp_v4_syn_recv_sock，将轻量级结构“克隆”并升级为完整的重量级struct tcp_sock。
  随后，新 Socket 被移动到Accept Queue (全连接队列)的链表尾部，唤醒阻塞在accept()上的应用层线程。

2.2 半连接队列 (SYN Queue) 与 Syncookies 的代价

核心痛点：SYN Flood 攻击通过发送大量伪造 IP 的 SYN 包，填满 Hash Table，导致正常玩家无法连接。

防御机制：Syncookies 的“有损”黑魔法

Linux 内核引入了net.ipv4.tcp_syncookies。当 SYN Queue 满时，内核不再分配request_sock，而是将连接信息编码进 ACK 包的 Sequence Number (Cookie) 中返回。

很多开发者只知道 Syncookies 能防攻击，却不知道它的代价。

• 丢失 TCP 选项：因为内核没有保存request_sock，它彻底忘记了 Client 在 SYN 包里携带的高级选项（如Window Scale,SACK,MSS）。
• 后果：虽然连接建立了，但窗口缩放 (Window Scale) 失效，导致接收窗口最大只能是 64KB。在 4G/5G 等高带宽长延迟（LFN）的网络下，游戏数据吞吐量可能会暴跌，玩家体验极差。

2.3 全连接队列 (Accept Queue) 与 溢出策略

核心痛点：游戏开服瞬间，数万玩家同时涌入，Accept Queue 瞬间爆满。

1. 队列长度由谁决定？

这是一个经典的面试坑。Accept Queue 的长度 =min(backlog, net.core.somaxconn)。

• backlog：你在 C++ 代码listen(fd, backlog)中传入的参数。
• somaxconn：系统级限制 (/proc/sys/net/core/somaxconn)。

结论：即使你代码里写了listen(fd, 2048)，如果系统默认somaxconn是 128，那队列长度依然只有 128！务必同步修改。

2. 溢出时的博弈：tcp_abort_on_overflow

当 Accept Queue 满了，内核怎么处理新的 ACK？

• 设置为 0 ：
  • 行为：扔掉 ACK，视作没收到。
  • 优势：Client 会触发 TCP 超时重传。如果 Server 只是暂时繁忙（如 GC 卡顿），重传时队列可能就有空位了，连接得以保留。这对玩家体验最友好。
• 设置为 1 ：
  • 行为：直接回 RST，Client 报错Connection reset by peer。
  • 场景：明确知道服务器已经彻底过载，希望快速拒绝服务。

3. 观测实战

不要瞎猜，用数据说话。如果以下计数器在增长，说明你的 listen 参数太小了，或者 Accept 处理太慢：

# 查看 Accept Queue 溢出次数 (累计值) $ netstat -s | grep "listen" 2048 times the listen queue of a socket overflowed

3. 连接断开：四次挥手与资源管理的博弈 (Connection Teardown)

核心知识点：SO_REUSEADDR | Epoll 处理 FIN | EPOLLRDHUP | 业务逻辑阻塞

相比于连接建立时的热烈，连接断开往往伴随着“资源残留”的阴影。对于 C++ 游戏服务端开发者而言，我们不关心运维视角的端口耗尽，我们只关心两件事：“服务挂了能不能立刻重启”以及“玩家下线时数据存好了没”。

3.1 主动关闭方：TIME_WAIT 与 重启自由

谁先调用close()，谁就要背负TIME_WAIT的重担（等待 2MSL，通常 60秒）。

1. 痛点：为什么重启会报 “Address already in use”？

• 场景：游戏服崩溃或维护，你杀掉进程（Server 主动关闭所有连接，产生大量 TIME_WAIT），然后立即尝试重启。
• 报错：bind: Address already in use。
• 原因：虽然进程没了，但内核里还残留着绑定在端口上的 TIME_WAIT Socket。默认情况下，Linux 不允许一个新的 Listener 绑定到一个还有活跃 Socket 的端口。
• 后果：你必须干等 60 秒才能启动服务器。这在紧急热修复（Hotfix）时是不可接受的。

2. 必选项：SO_REUSEADDR

在 C++ 服务端代码中，必须在bind之前设置SO_REUSEADDR。

int opt = 1; // 允许重用处于 TIME_WAIT 状态的端口 if (setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt)) < 0) { perror("setsockopt"); exit(1); }

• 作用：告诉内核，“只要没有活动的（ESTABLISHED）连接占着这个端口，就算有一堆 TIME_WAIT 的僵尸，也允许我绑定成功”。
• 注意：不要混淆SO_REUSEPORT（端口复用，用于多进程监听同一端口），那是另一个话题。

3. 补充：连接下游的优化 (Gateway 场景)

当游戏服作为 Client 连接 Redis/DB 时，如果短连接频繁，本地端口确实可能不够用。此时应开启内核参数：

• net.ipv4.tcp_tw_reuse = 1：允许复用安全的 TIME_WAIT 连接。

3.2 被动关闭方：CLOSE_WAIT 与 逻辑层死锁

如果说 TIME_WAIT 是正常的生理代谢，那么CLOSE_WAIT 就是癌症。

线上出现大量 CLOSE_WAIT，意味着：内核收到了 FIN，但你的 C++ 代码（或逻辑库）没有调用close()。

1. Epoll 时代的陷阱 (Non-blocking I/O)

现在的游戏服大多使用 Epoll/Reactor 模型。很多 Bug 源于事件处理不当。

❌ 错误示范 (Epoll 漏处理)：

// 在 epoll_wait 返回的循环中... if (events[i].events & EPOLLIN) { int n = read(fd, buf, sizeof(buf)); if (n > 0) { handle_logic(buf, n); } // 💀 致命遗漏：没有处理 n == 0 的情况 // 当 n == 0 时，表示对端发了 FIN。 // 如果不在这里 close(fd) 并从 epoll_ctl 删除， // 这个 fd 就会一直处于 CLOSE_WAIT，且不断触发 EPOLLIN (Level Trigger)。 }

✅ 正确姿势 (关注 EPOLLRDHUP)：

推荐在注册事件时加上EPOLLRDHUP(Linux 2.6.17+)，专门检测对端关闭。

struct epoll_event ev; ev.events = EPOLLIN | EPOLLRDHUP | EPOLLET; // 边缘触发 + 对端关闭检测 epoll_ctl(epfd, EPOLL_CTL_ADD, fd, &ev); // ... 在循环中 ... if (events[i].events & (EPOLLRDHUP | EPOLLHUP)) { // 对端断开或异常 close_connection(fd); } else if (events[i].events & EPOLLIN) { int n = read(fd, ...); if (n == 0) { close_connection(fd); // 经典的 EOF 处理 } }

2. 真正的元凶：业务逻辑阻塞 (Graceful Shutdown)

在游戏开发中，CLOSE_WAIT堆积往往不是忘了写close()，而是代码执行不到close()。

• 场景：玩家下线 -> 收到 FIN -> 触发OnSessionClose()回调 ->执行存盘逻辑 (SavePlayer)-> 调用close(fd)。
• 坑点：
  • 如果SavePlayer是同步写入数据库，且数据库此时卡顿了，网络线程（或逻辑线程）就会阻塞在这里。
  • 如果逻辑线程发生了死锁 (Deadlock)。
  • 如果代码中有死循环。
• 结果：虽然网络层收到了 FIN，但应用层代码卡在存盘那一步，永远走不到close(fd)。
• 现象：netstat看到一堆 CLOSE_WAIT，同时日志里没有玩家下线的成功记录。

思考：如何设计一个“带状态断开”的异步流程，防止存盘卡死网络线程？

答案：收到 FIN 后，标记 Session 为“待关闭”，将存盘任务扔给专门的 DB 线程池。网络线程继续处理其他连接。当 DB 线程回调“存盘完成”后，再在网络线程中真正执行close(fd)。

4. 异常与控制：僵尸连接与强踢策略 (Abnormal & Control)

核心知识点：RST 强踢 | SO_LINGER | NAT 黑洞 | 应用层心跳

在理想的网络世界里，连接总是优雅地建立，优雅地断开。但在充满敌意的公网环境（DDoS 攻击、弱网波动、运营商 NAT 策略）下，游戏服务器必须具备“雷霆手段”。

4.1 RST (Reset) 的艺术：该出手时就出手

标准的close()会触发四次挥手，虽然优雅，但在某些场景下显得太“软弱”且昂贵。

1. 场景：为什么要用 RST？

• 踢人 (Kick)：当玩家 A 在设备 2 登录，服务器需要强制踢掉设备 1 的连接时。或者 GM 执行封号操作时。
• 防御攻击：当检测到某个 IP 发送非法协议包或进行爬虫扫描时，服务器不希望为这种恶意连接保留TIME_WAIT状态（占用内存）。
• 快速释放：在高负载下，RST 能立即释放 Socket 资源，不需要经过 2MSL 的等待。

2. 手段：SO_LINGER 的“零容忍”

在 C++ 中，通过设置SO_LINGER选项并将其超时设为 0，可以诱导内核在close()时发送 RST 报文，而不是 FIN。

struct linger sl; sl.l_onoff = 1; // 开启 Linger sl.l_linger = 0; // 超时设为 0 (强制复位) // 设置后，调用 close(fd) 将不再发送 FIN，而是直接发 RST setsockopt(fd, SOL_SOCKET, SO_LINGER, &sl, sizeof(sl)); close(fd);

3. 代价与风险

RST 是一种破坏性的关闭方式：

• 数据丢失：正常的 FIN 保证了“我发的数据你都收到了”。而 RST 会导致发送缓冲区（Send Buffer）里的残留数据被直接丢弃。
• 接收缓冲区清空：更危险的是，如果接收缓冲区（Recv Buffer）里还有数据没读（例如客户端发了最后一条聊天信息），此时触发 RST，内核会直接清空缓冲区，导致应用层读不到这部分数据。
• 客户端报错：客户端会收到ECONNRESET(Connection reset by peer) 错误，而不是正常的 EOF (read == 0)。

4.2 保活机制：对抗 NAT 黑洞与假死

1. TCP Keep-Alive 的致命缺陷

内核自带的保活机制 (SO_KEEPALIVE) 对游戏业务几乎不可用：

• 反应迟钝：默认配置是连接空闲7200秒（2小时）后才开始探测。这在手游里等于“永远不探测”。即使调优内核参数，也只能做到秒级，难以做到毫秒级控制。
• 无法检测进程死锁：TCP Keep-Alive 是内核层负责回复的。如果你的 C++ 游戏进程死锁了（主循环卡死），但内核网络栈依然健在，内核会帮你会回复 ACK。客户端会误以为“服务器还活着”，一直傻等，直到用户失去耐心杀进程。

2. 真正的杀手：运营商 NAT 黑洞 (The NAT Black Hole)

手游玩家通常处于 4G/5G 或 WiFi 内网中，与服务器之间隔着运营商的 NAT 网关。

• Session Table：NAT 网关维护着一张映射表。
• 超时剔除：为了节省性能，NAT 网关会迅速清理“不活跃”的映射记录。这个超时时间通常在60秒到 300秒之间（不同地区运营商策略不同）。
• 黑洞形成：如果玩家挂机（AFK）了 5 分钟没有发包，NAT 删除了映射。此时服务器再给玩家发消息（如被攻击掉血），数据包到达 NAT 网关后，因为找不到映射记录，会被直接丢弃（Drop）。
• 结果：连接在物理上虽没断，但在逻辑上已经断了。服务器发不出数据，客户端收不到数据，双方都以为对方还活着。这就是“半打开连接”。

3. 黄金法则：应用层心跳 (Application Heartbeat)

为了保活，必须在应用层实现心跳机制。

• 设计原则：
  • 双向检测：不仅 Client 要发 Ping，Server 也要回 Pong。
  • 频率：必须小于 NAT 超时时间（建议15秒 - 30秒一次）。
  • 逻辑检测：心跳包的处理必须在主逻辑线程中，证明“我的逻辑还活着”。
  • 无论 send 是否成功，如果now - last_read_time > timeout，必须强制断开。只有收到对端的数据（read > 0），才能证明链路是通的。

5. 速度与激情的权衡：滑动窗口与拥塞控制 (Flow & Congestion Control)

核心知识点：Nagle vs Delayed ACK | TCP_NODELAY | writev | CUBIC vs BBR

如果说前面的状态机决定了连接的“生死”，那么滑动窗口与拥塞控制算法就决定了数据的“快慢”。在 C++ 游戏服务端开发中，我们需要在低延迟 (Latency)和高吞吐 (Throughput)之间做出精准的权衡。

5.1 延迟杀手：Nagle 算法 vs Delayed ACK

这是网络编程中最经典的“死锁”组合，也是导致许多游戏莫名其妙出现 40ms 延迟的元凶。

1. 现象：神秘的 40ms 延迟

场景：客户端连续发送了两个很小的包（比如先发包头，再发包体），然后等待服务器响应。

故障：你会发现第二个包并没有立刻发出去，而是等了大约 40ms 后才发出。Ping 值瞬间飙升。

2. 原理：好心办坏事

这是 Nagle 算法（发送端）与 Delayed ACK（接收端）互相等待的结果：

• Nagle (Client):“为了节省带宽，如果上一个包的 ACK 还没回来，且当前数据不够一个 MSS，我就先攒着不发。”
• Delayed ACK (Server):“为了节省带宽，收到包后我不立刻回 ACK，我等 40ms 看看有没有数据要回传（Piggyback），或者攒够两个 ACK 一起回。”
• 死锁：Client 等 Server 的 ACK 才肯发第二个包；Server 等 Client 发更多数据（或者超时）才肯回 ACK。双方由于逻辑互锁，白白浪费了 40ms。

3. 实战：必须开启 TCP_NODELAY

对于 FPS/MOBA 等实时对战游戏，哪怕 1ms 的延迟都是致命的。我们必须禁用 Nagle 算法。

int opt = 1; // 禁用 Nagle 算法，有数据立刻发送 if (setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, &opt, sizeof(opt)) < 0) { perror("setsockopt"); }

4. 进阶：如何避免“小包满天飞”？

禁用 Nagle 后，如果你代码里写得烂（比如把一个逻辑包拆成 10 次send调用），会导致网络上充斥着只有几个字节负载的小包，严重浪费带宽和 CPU（系统调用开销）。

解决方案：既然不能用 Nagle 在内核层缓冲，就必须在应用层或系统调用层做聚合。

• 方案 A：应用层 Buffer (推荐)
  在用户态分配一个 buffer，把 Header + Body 拼好，调用一次send。这是最通用的做法。
• 方案 B：writev (Scatter/Gather I/O)
  如果不想产生内存拷贝，可以使用writev将多块不连续的内存一次性写入内核。

struct iovec iov[2]; iov[0].iov_base = header; iov[0].iov_len = header_len; iov[1].iov_base = body; iov[1].iov_len = body_len; // 原子性发送，内核自动组装成一个 TCP 包，既没拷贝也没延迟 writev(fd, iov, 2);

• 方案 C：MSG_MORE (Linux 特有)
  告诉内核：“我还没发完，先别推给网卡，等我下次调用无标记的 send 时一起发。”
  send(fd, header, len, MSG_MORE); send(fd, body, len, 0); // 此时才真正触发网络发送

5. 2 拥塞控制进化论：从 CUBIC 到 BBR

流量控制 (RWND) 保护的是接收方，而拥塞控制 (CWND) 保护的是整个互联网。

1. CUBIC (Loss-based)：

Linux 默认的拥塞控制算法是CUBIC。

• 核心逻辑：以“丢包”作为拥塞的信号。一旦发生丢包（超时或重复 ACK），CUBIC 就认为网络堵了，立刻大幅削减发送窗口（CWND）。
• 痛点：在跨国传输或无线网络 (4G/WiFi)中，物理距离长导致 RTT 大，且无线信号波动会导致随机丢包（并不是因为堵车）。
• 后果：CUBIC 会错误地“急刹车”，导致带宽利用率极低。明明有一条 100Mbps 的光缆，可能只能跑出 5Mbps 的速度。

2. BBR (Model-based)：

Google 提出的BBR (Bottleneck Bandwidth and Round-trip propagation time)彻底颠覆了 TCP 的发送逻辑。

• 核心逻辑：不再关注丢包。BBR 通过实时采样，建立网络模型，估算出两个核心指标：

1. BtlBw：瓶颈带宽（最细的那根水管有多粗）。
2. RTprop：物理往返延迟（光跑一圈要多久）。

• 行为：只要 RTT 没有明显升高，即使有随机丢包，BBR 也认为网络没堵，继续保持高吞吐发送。
• 价值：

• 高吞吐：在 1% 丢包率的弱网环境下，BBR 的吞吐量能比 CUBIC 高出10 倍以上。
• 低延迟：BBR 致力于不填满路由器的 Buffer（Bufferbloat），从而降低了排队延迟。

# 开启 BBR echo "net.core.default_qdisc = fq" >> /etc/sysctl.conf echo "net.ipv4.tcp_congestion_control = bbr" >> /etc/sysctl.conf sysctl -p

6. C++ 服务端Socket设置模板

#include <sys/types.h> #include <sys/socket.h> #include <netinet/tcp.h> #include <fcntl.h> #include <unistd.h> #include <errno.h> /** * 针对游戏服务器的高性能 Socket 调优 * 兼容性：Epoll (Yes), io_uring (Yes) * @param fd: 刚刚 accept 出来或创建的 socket fd * @param is_server: 是监听 socket 还是普通连接 socket */ void OptimizeSocket(int fd, bool is_listener) { int opt = 1; // ------------------------------------------------- // 1. 协议栈调优 (Protocol Stack) - 100% 通用 // 无论 IO 模型怎么变，TCP 协议的行为必须在这里配置 // ------------------------------------------------- // [Part 3.1] 允许重用处于 TIME_WAIT 的地址 // 解决 "Address already in use" 报错，让服务器崩溃后能立即重启 if (setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt)) < 0) { // LogError("Failed to set SO_REUSEADDR"); } // [Part 5.1] 禁用 Nagle 算法 (低延迟关键) // io_uring 只是改变了发包的方式，没有改变 TCP 攒包的逻辑 // 所以 io_uring 下依然必须开启 TCP_NODELAY if (!is_listener) { if (setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, &opt, sizeof(opt)) < 0) { // LogError("Failed to set TCP_NODELAY"); } } // ------------------------------------------------- // 2. I/O 模式设置 (IO Model) // ------------------------------------------------- // 获取当前 flag int flags = fcntl(fd, F_GETFL, 0); if (flags == -1) { /* Handle error */ } // [关键点] 设置 O_NONBLOCK // Epoll: 必须设置，否则会阻塞工作线程。 // io_uring: // 虽然 io_uring 支持对阻塞 fd 的异步操作，但最佳实践依然推荐设置为 O_NONBLOCK。 // 原因：防止某些非核心路径（或 io_uring Submission 队列满时）意外回退到同步阻塞行为， // 导致 Submission 线程卡死。 if (fcntl(fd, F_SETFL, flags | O_NONBLOCK) == -1) { // Handle error } // ------------------------------------------------- // 3. 进阶防御与保活 (Advanced) // ------------------------------------------------- // [Part 4.2] 开启内核层 Keep-Alive (作为最后一道防线) // 注意：应用层心跳仍然是必须的 if (setsockopt(fd, SOL_SOCKET, SO_KEEPALIVE, &opt, sizeof(opt)) < 0) { // LogError } // Keep-Alive 细粒度调优 int idle = 60; int intvl = 10; int cnt = 3; setsockopt(fd, IPPROTO_TCP, TCP_KEEPIDLE, &idle, sizeof(idle)); setsockopt(fd, IPPROTO_TCP, TCP_KEEPINTVL, &intvl, sizeof(intvl)); setsockopt(fd, IPPROTO_TCP, TCP_KEEPCNT, &cnt, sizeof(cnt)); if (is_listener) { // [注意] 仅适用于 "Client 先说话" 的协议 (如 HTTP 或 常见游戏登录)。 // 如果你的协议是 Server accept 后主动向 Client 发 Banner (Server先说话)，千万别开这个！ // 否则 accept 会一直阻塞，直到 Client 发数据。 int defer_timeout = 30; setsockopt(fd, IPPROTO_TCP, TCP_DEFER_ACCEPT, &defer_timeout, sizeof(defer_timeout)); } }

以上为自己的学习笔记，如果有误还望指正。