1. 项目概述：为什么我们需要一个自己的Network类？

在C++的世界里，搞网络编程，尤其是TCP/UDP通信，很多人的第一反应就是直接抄起Berkeley Socket API（也就是我们常说的socket、bind、listen、accept那一套）开干。这没错，Socket是基石，但用过的都知道，原生的C接口用起来有多“酸爽”：错误处理靠返回值加errno，资源管理要手动close，多线程下还得小心处理竞态条件，更别提那堆令人眼花缭乱的struct sockaddr转换了。写一个小demo还行，一旦项目规模上来，到处散落着重复的socket创建、连接、读写代码，维护起来简直就是一场灾难。

所以，封装一个自己的Network通信类，几乎成了每一个有追求的C++后端开发者的“必修课”。这不仅仅是为了代码复用，更是为了构建一套清晰、健壮、易于调试的网络抽象层。一个好的Network类，应该像一把趁手的瑞士军刀，把Socket的复杂性隐藏起来，对外暴露简洁、安全的接口。想象一下，当你需要建立一个TCP服务器时，你只需要server.listen(port)；客户端连接就是client.connect(ip, port)；发送数据就是send(buffer)，并且能优雅地处理连接断开、超时和各类网络异常。这能极大提升开发效率和代码质量。

最近在社区里，关于C++网络编程的讨论热度一直不减，无论是“C++八股文”里常问的IO多路复用，还是实际项目中遇到的“stream disconnected before completion: transport error: network error”这类令人头疼的问题，都指向了一个核心需求：我们需要更可靠、更易用的网络编程工具。自己动手实现一个Network类，正是深入理解这些问题的绝佳途径。本文将带你从零开始，详解一个生产级可用的C++Network类的设计与实现，涵盖从Socket封装、IO模型选择到错误处理和性能优化的方方面面。

2. 核心设计思路与架构选型

在动手写代码之前，我们必须先回答几个关键的设计问题。这决定了我们的Network类是玩具还是能真正用于项目的工具。

2.1 跨平台兼容性：WinSock2 vs. POSIX Sockets

网络编程的第一个拦路虎就是平台差异。在Linux/macOS上，我们使用POSIX标准的Socket API，头文件是<sys/socket.h>、<netinet/in.h>等。而在Windows上，则是WinSock2，头文件是<winsock2.h>。

一个健壮的Network类必须处理好这个差异。我们的策略是使用预编译指令进行条件编译。

// Network_Common.h #pragma once #ifdef _WIN32 #define WIN32_LEAN_AND_MEAN #include <winsock2.h> #include <ws2tcpip.h> #pragma comment(lib, "Ws2_32.lib") using socklen_t = int; #define SHUT_RDWR SD_BOTH #define close closesocket #else #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #include <unistd.h> #include <fcntl.h> #define SOCKET int #define INVALID_SOCKET (-1) #define SOCKET_ERROR (-1) #endif #include <string> #include <system_error> #include <memory>

这里有几个关键点：

1. WIN32_LEAN_AND_MEAN：在Windows上定义这个宏，可以避免引入一些不常用的Windows头文件，加快编译速度。
2. #pragma comment(lib, ...)：这是MSVC编译器特有的指令，用于自动链接Ws2_32.lib库，省去了在项目设置里手动配置的麻烦。对于其他编译器（如MinGW），可能需要在构建系统（如CMake）中显式链接。
3. 类型别名：我们将Windows的SOCKET类型（本质是unsigned int）和Linux的int统一用SOCKET表示，并定义了INVALID_SOCKET和SOCKET_ERROR的跨平台值。
4. 函数别名：将Windows的closesocket映射为close，使得我们在代码中可以统一使用close(fd)。

注意：Windows的Socket库需要显式初始化和清理。我们必须在程序开始时调用WSAStartup，结束时调用WSACleanup。这通常可以通过一个全局的RAII（Resource Acquisition Is Initialization）管理器类来完成，确保在任何Network对象被使用前初始化，在程序退出后清理。

2.2 核心抽象：Connection 与 Listener

一个清晰的架构比一堆混杂的函数更重要。我们将网络实体抽象为两个核心类：Connection和Listener（或Server）。

• Connection类：代表一个已建立的网络连接（无论是TCP还是UDP）。它封装了一个Socket文件描述符（fd），并提供了send、receive、close等方法。它应该负责管理这个连接的生命周期，确保Socket被正确关闭（利用RAII在析构函数中close）。
• Listener类：代表一个监听特定端口、等待客户端连接的服务器。它封装了socket、bind、listen这一套流程，并提供一个accept方法来接收新的连接，返回一个Connection对象。

这种分离符合单一职责原则。Listener只管“接客”，Connection只管“对话”。后续如果我们想支持不同的协议（如TCP、UDP、甚至Unix Domain Socket），只需要让Connection和Listener继承自一个共同的基类接口，或者通过模板策略来实现。

2.3 IO模型：阻塞、非阻塞与事件驱动

这是设计中最核心的决策之一，直接影响到并发能力和编程复杂度。

1. 阻塞IO（Blocking IO）：最简单。调用accept、recv、send时，如果条件不满足（如没有数据可读），线程会一直挂起等待。这对于简单的客户端或低并发服务器来说足够，但一个连接一个线程的模式在连接数多时资源消耗巨大。
2. 非阻塞IO（Non-blocking IO）：将Socket设置为非阻塞模式后，这些IO调用会立即返回。如果没有数据，recv会返回一个错误（如EAGAIN或EWOULDBLOCK）。这要求程序不断轮询（polling）所有连接，效率低下，CPU占用高。
3. IO多路复用（I/O Multiplexing）：这是现代高性能网络服务器的基石。使用select、poll、epoll（Linux）或kqueue（BSD/macOS）等系统调用，一个线程可以同时监视多个Socket fd上的事件（可读、可写、错误）。当任何一个被监视的fd就绪时，系统调用返回，程序再对就绪的fd进行IO操作，避免了无意义的轮询和线程阻塞。

对于我们的Network类，如果目标是高并发服务器，那么将IO多路复用的逻辑集成到Listener和Connection的管理中是更优的选择。我们可以设计一个EventLoop或Poller类来封装epoll/kqueue的细节，Listener和Connection向这个事件循环注册自己感兴趣的事件（如Listener注册可读事件等待新连接，Connection注册可读事件等待数据）。

考虑到文章的篇幅和聚焦于Network类本身的封装，我们第一版的实现将采用阻塞IO模式，以保证代码的清晰和易于理解。但会在架构上为后续引入事件驱动留出扩展点，并详细讨论如何将其升级为非阻塞+IO多路复用的模式。

2.4 错误处理：异常 vs. 错误码

网络操作充满了不确定性。连接可能被拒绝、可能超时、可能被对端重置。一个健壮的网络库必须有清晰的错误处理策略。

• C风格错误码：Socket API本身使用返回值+errno（Windows上是WSAGetLastError()）。这种方式比较原始，错误信息需要手动转换。
• C++异常：利用RAII，在构造函数或连接操作失败时抛出异常（如std::system_error），可以让错误处理逻辑更清晰，资源管理更安全。例如，如果Connection构造函数中socket()调用失败，直接抛出异常，避免创建一个无效的连接对象。

我们将采用异常为主，辅以错误状态查询的方式。对于构造函数和可能失败的初始化操作（如connect、bind），我们抛出异常。对于一些非致命的、可预期的错误（如非阻塞IO下的EAGAIN），我们可以通过返回值或一个last_error()方法来提供信息。

class NetworkError : public std::system_error { public: NetworkError(int ev, const std::string& what_arg) : std::system_error(ev, std::system_category(), what_arg) {} NetworkError(const std::string& what_arg) : std::system_error(0, std::generic_category(), what_arg) {} };

3. 基础Socket封装与Connection类实现

有了清晰的设计蓝图，我们现在开始实现最基础的构建块：对原生Socket的RAII封装和Connection类。

3.1 Socket句柄的RAII封装

在C++中，管理资源（尤其是文件描述符、指针等）的最佳实践是RAII。我们创建一个Socket类，在其构造函数中创建Socket，在析构函数中自动关闭它。

// Socket.h class Socket { public: // 创建一个指定类型和协议的Socket explicit Socket(int domain = AF_INET, int type = SOCK_STREAM, int protocol = 0); // 接管一个已存在的Socket文件描述符（用于accept返回的fd） explicit Socket(SOCKET fd); // 禁止拷贝 Socket(const Socket&) = delete; Socket& operator=(const Socket&) = delete; // 允许移动 Socket(Socket&& other) noexcept; Socket& operator=(Socket&& other) noexcept; ~Socket(); SOCKET fd() const noexcept { return fd_; } operator SOCKET() const noexcept { return fd_; } // 方便隐式转换 void setNonBlocking(bool nonBlocking = true); void setReuseAddr(bool reuse = true); void setTcpNoDelay(bool noDelay = true); // 禁用Nagle算法，降低延迟 private: SOCKET fd_ = INVALID_SOCKET; };

实现要点：

• 移动语义：允许Socket对象的所有权转移，这在将新接受的连接移出Listener时非常有用。
• 资源释放：析构函数中，如果fd_有效，则调用close(fd_)。
• 常用选项设置：提供了几个常用的Socket选项设置方法，如setReuseAddr（允许快速重启服务器绑定同一端口）、setTcpNoDelay（对于交互式应用，禁用Nagle算法合并小包，减少延迟）。

3.2 Connection类的核心功能

Connection类持有Socket对象，并实现数据收发。

// Connection.h class Connection { public: // 主动连接到远程地址 Connection(const std::string& ip, uint16_t port); // 从已有的Socket构造（用于服务器端accept后创建） explicit Connection(Socket&& socket); // 移动构造/赋值 Connection(Connection&&) = default; Connection& operator=(Connection&&) = default; ~Connection() = default; // Socket析构会自动关闭 // 发送数据，返回实际发送的字节数 size_t send(const void* data, size_t len); // 发送字符串（方便使用） size_t send(const std::string& str) { return send(str.data(), str.size()); } // 接收数据到缓冲区，返回实际接收的字节数 size_t receive(void* buffer, size_t bufferLen); // 接收指定长度的数据（可能循环调用recv直到收够） size_t receiveExact(void* buffer, size_t exactLen); // 接收数据直到遇到分隔符（如`\n`），适合文本协议 std::string receiveUntil(char delimiter = '\n'); // 关闭连接（发送端、接收端或双向） void shutdown(int how = SHUT_RDWR); void close() { socket_.~Socket(); } // 显式关闭，通常不需要手动调用 bool isConnected() const; std::string peerAddress() const; // 获取对端IP:Port private: Socket socket_; sockaddr_in peerAddr_{}; };

实现细节与避坑指南：

1. send和receive的循环处理：这是新手最容易出错的地方。send和recv系统调用并不保证发送或接收你请求的所有字节。它们可能因为内核发送缓冲区满或接收缓冲区空而只处理一部分。因此，我们必须循环调用，直到所有数据被处理完或发生错误。

   size_t Connection::send(const void* data, size_t len) { const char* buffer = static_cast<const char*>(data); size_t totalSent = 0; while (totalSent < len) { // MSG_NOSIGNAL 在Linux下防止send在连接断开时触发SIGPIPE信号 // Windows下该标志无效，但WinSock不会发信号 #ifdef _WIN32 int flags = 0; #else int flags = MSG_NOSIGNAL; #endif ssize_t sent = ::send(socket_.fd(), buffer + totalSent, len - totalSent, flags); if (sent < 0) { if (errno == EINTR) continue; // 被信号中断，重试 if (errno == EAGAIN || errno == EWOULDBLOCK) { // 在非阻塞模式下，缓冲区满，需要等待可写事件 // 这里我们先抛出异常，在事件驱动模型中会不同处理 throw NetworkError("Socket send buffer full"); } throw NetworkError(errno, "send failed"); } else if (sent == 0) { // 对端已关闭连接 throw NetworkError("Connection closed by peer"); } totalSent += sent; } return totalSent; }

2. receiveExact的实现：有些协议要求必须读取固定长度的报文头。receiveExact需要内部循环调用receive，直到收满指定字节数。这里需要注意超时和对端关闭连接的处理。

3. receiveUntil的实现：对于像HTTP这样的行式协议，按分隔符读取非常方便。但要注意缓冲区管理和可能的分隔符不在一个recv调用内的问题。一个简单的实现是使用一个内部的std::string作为缓存，每次recv数据追加到缓存，然后在缓存中查找分隔符。

4. 获取对端地址：在构造函数或accept后，我们可以使用getpeername系统调用填充peerAddr_，方便后续日志记录和调试。

实操心得：在实现send和receive时，务必考虑信号中断（EINTR）。在Linux/Unix系统上，慢速系统调用（如recv、send、accept）可能会被信号处理函数中断，此时errno会被设置为EINTR。正确的做法是检查到这个错误后，直接重试该调用，而不是将其视为失败。很多网络程序的隐蔽bug都源于忽略了EINTR。

4. Listener类与TCP服务器搭建

有了Connection，我们现在来构建服务器的另一部分：Listener。它的核心任务是监听端口并接受新连接。

4.1 Listener类的实现

// Listener.h class Listener { public: explicit Listener(uint16_t port, const std::string& bindIp = "0.0.0.0", int backlog = SOMAXCONN); ~Listener() = default; // 阻塞等待并接受一个新连接，返回一个Connection对象 Connection accept(); // 设置非阻塞模式后，可以尝试接受连接，如果没有新连接立即返回（可能返回一个无效的Connection） Connection tryAccept(); void setNonBlocking(bool nonBlocking = true); uint16_t port() const { return port_; } private: Socket socket_; uint16_t port_; };

构造函数流程详解：

1. 创建Socket：socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)。SOCK_STREAM代表TCP。
2. 设置SO_REUSEADDR：调用socket_.setReuseAddr(true)。这非常重要，它允许服务器在崩溃或关闭后快速重启，绑定到同一个端口，而不用等待之前的连接处于TIME_WAIT状态结束（通常2分钟）。
3. 绑定地址：准备一个sockaddr_in结构体，填充协议族（AF_INET）、端口（htons(port)）和IP地址（inet_pton或INADDR_ANY）。然后调用bind。
4. 开始监听：调用listen，并指定backlog参数。这个参数表示内核为此Socket排队的最大已完成连接数（ESTABLISHED且未被accept取走的连接）。不是指最大连接数。通常设为SOMAXCONN（系统允许的最大值）即可。

accept方法实现：

Connection Listener::accept() { sockaddr_in clientAddr{}; socklen_t addrLen = sizeof(clientAddr); SOCKET clientFd = ::accept(socket_.fd(), reinterpret_cast<sockaddr*>(&clientAddr), &addrLen); if (clientFd == INVALID_SOCKET) { if (errno == EINTR) { // 被信号中断，递归调用自己重试（或循环重试） return accept(); } throw NetworkError(errno, "accept failed"); } // 创建一个Socket对象接管clientFd Socket clientSocket(clientFd); // 使用移动语义返回一个Connection return Connection(std::move(clientSocket)); }

4.2 构建一个简单的Echo服务器

现在，我们可以用Listener和Connection组合出一个完整的、阻塞IO的Echo服务器。

// simple_echo_server.cpp #include "Listener.h" #include "Connection.h" #include <iostream> #include <thread> void handleClient(Connection conn) { try { std::cout << "New connection from: " << conn.peerAddress() << std::endl; while (true) { std::string msg = conn.receiveUntil('\n'); // 按行读取 if (msg.empty()) { // receiveUntil返回空字符串可能表示连接关闭 std::cout << "Connection closed by peer: " << conn.peerAddress() << std::endl; break; } std::cout << "Received: " << msg << std::endl; conn.send("Echo: " + msg + "\n"); // 回显并加换行 } } catch (const NetworkError& e) { std::cerr << "Error handling client " << conn.peerAddress() << ": " << e.what() << std::endl; } // conn离开作用域，析构函数会自动关闭Socket } int main() { try { Listener listener(8080); // 监听8080端口 std::cout << "Echo server listening on port 8080..." << std::endl; while (true) { Connection conn = listener.accept(); // 阻塞等待新连接 // 为每个新连接创建一个线程处理（简单示例，生产环境应用线程池） std::thread(handleClient, std::move(conn)).detach(); } } catch (const NetworkError& e) { std::cerr << "Server fatal error: " << e.what() << std::endl; return 1; } return 0; }

这个服务器虽然简单，但清晰地展示了我们Network类的用法：创建监听器、接受连接、处理数据。每个连接在一个独立的线程中处理，这是经典的“一个连接一个线程”模型。

重要警告：上述示例为每个连接创建新线程（std::thread(...).detach()），这在学习和小规模测试时没问题，但绝对不适合生产环境。线程创建和销毁开销巨大，且大量线程会导致系统调度性能急剧下降。生产级服务器必须使用线程池配合IO多路复用（如epoll）或异步IO模型。我们将在后续章节讨论如何升级我们的Network类来支持这种模式。

5. 错误处理、超时与连接管理

一个健壮的网络库，必须能妥善处理各种异常情况。

5.1 系统错误与自定义异常

我们之前定义了NetworkError异常。在实现中，所有系统调用（socket,bind,connect,send,recv,accept等）的失败，都应包装成NetworkError抛出。这包括检查errno（或WSAGetLastError()）并将其转换为人类可读的信息。

// 一个工具函数，用于抛出带错误信息的system_error inline void throwLastSocketError(const std::string& context) { #ifdef _WIN32 int err = WSAGetLastError(); #else int err = errno; #endif throw NetworkError(err, context); }

5.2 超时设置

网络操作可能永远阻塞。我们必须为关键操作设置超时，比如connect（连接超时）和recv（接收超时）。

可以通过setsockopt函数设置Socket选项SO_RCVTIMEO（接收超时）和SO_SNDTIMEO（发送超时）。需要注意的是，这个超时是对单个send/recv系统调用而言的，不是对整个发送或接收完整数据过程的超时。

void Connection::setReceiveTimeout(int milliseconds) { timeval tv{}; tv.tv_sec = milliseconds / 1000; tv.tv_usec = (milliseconds % 1000) * 1000; if (setsockopt(socket_.fd(), SOL_SOCKET, SO_RCVTIMEO, reinterpret_cast<const char*>(&tv), sizeof(tv)) < 0) { throwLastSocketError("setsockopt SO_RCVTIMEO failed"); } }

对于connect超时，在阻塞模式下，系统本身有一个默认的超时（通常很长，如75秒）。我们可以通过先设置Socket为非阻塞，然后connect，再使用select或poll在指定时间内等待连接完成的方式，来实现自定义的连接超时。这稍微复杂一些，但很多网络库都提供了这个功能。

5.3 连接状态检测与保活

如何判断一个TCP连接是否还活着？直接调用recv会阻塞，调用send如果对端已关闭，可能会触发SIGPIPE（Linux）或返回错误。

1. 心跳机制：这是应用层最可靠的方法。定期（如每30秒）通过连接发送一个小的心跳包，并期待回复。如果连续多次收不到回复，则认为连接已断开。
2. TCP Keepalive：操作系统提供的TCP保活机制。通过setsockopt设置SO_KEEPALIVE选项，并可以精细控制TCP_KEEPIDLE（空闲多久后开始探测）、TCP_KEEPINTVL（探测间隔）、TCP_KEEPCOUNT（探测次数）。但默认设置通常间隔太长（如2小时），不适合快速检测断连。需要根据业务调整。
3. 非阻塞探测：将Socket设为非阻塞，尝试recv一个字节（使用MSG_PEEK标志，不清除缓冲区数据）。如果返回0，说明对端已关闭连接；如果返回EAGAIN，说明连接正常但没有数据；如果返回错误，则连接异常。

在我们的Connection类中，可以提供一个isConnected()方法，它可能采用一种轻量级的探测方式（比如检查上次IO操作是否出错），但最准确的还是需要结合业务逻辑的心跳。

6. 从阻塞IO到事件驱动：引入Poller

“一个连接一个线程”的阻塞模型无法支撑高并发。接下来，我们探讨如何改造我们的Network类，引入事件驱动模型。核心是实现一个Poller类，它封装了底层的epoll（Linux）、kqueue（macOS/BSD）或select（跨平台但性能差）。

6.1 Poller抽象接口

我们先定义一个抽象的Poller接口，以便在不同平台下实现。

// Poller.h class Poller { public: virtual ~Poller() = default; // 添加或修改一个文件描述符到监听集合，关注其events事件 virtual void addOrModify(int fd, uint32_t events) = 0; // 移除一个文件描述符 virtual void remove(int fd) = 0; // 等待事件发生，超时时间timeoutMs，返回就绪的事件列表 virtual std::vector<Event> poll(int timeoutMs) = 0; static const uint32_t READ_EVENT = 0x01; static const uint32_t WRITE_EVENT = 0x02; static const uint32_t ERROR_EVENT = 0x04; }; struct Event { int fd; uint32_t events; // 就绪的事件类型（READ_EVENT, WRITE_EVENT等） void* userData; // 可携带的用户数据，通常指向对应的Connection或Listener对象 };

6.2 基于epoll的实现（Linux）

// EPollPoller.h (Linux专用) class EPollPoller : public Poller { public: EPollPoller(); ~EPollPoller() override; void addOrModify(int fd, uint32_t events) override; void remove(int fd) override; std::vector<Event> poll(int timeoutMs) override; private: int epollFd_; std::vector<struct epoll_event> events_; // 用于接收就绪事件的数组 };

实现中，addOrModify对应epoll_ctl的EPOLL_CTL_ADD或EPOLL_CTL_MOD，remove对应EPOLL_CTL_DEL。poll方法则调用epoll_wait。

6.3 改造Listener和Connection

在事件驱动模型中，Listener和Connection需要向Poller注册自己感兴趣的事件。

• Listener：只关注可读事件（EPOLLIN）。当epoll_wait返回表明监听Socket可读时，意味着有新的连接到达，此时调用accept不会阻塞。
• Connection：通常关注可读事件。当需要发送大量数据且发送缓冲区满时，可以注册可写事件，待缓冲区可写时再继续发送，避免阻塞。

我们需要修改Connection的send和receive方法，使其在非阻塞Socket上工作，并能够与Poller协作。

// 非阻塞模式下的send size_t Connection::sendNonBlocking(const void* data, size_t len) { // ... 类似之前的循环，但当send返回EAGAIN/EWOULDBLOCK时， // 不是抛出异常，而是返回已发送的字节数，并告知调用者需要等待可写事件。 // 调用者（如事件循环）会将该Connection的可写事件注册到Poller。 // 当Poller通知可写时，继续发送剩余数据。 }

6.4 构建事件驱动服务器

最终，我们可以构建一个单线程（或固定线程数）的事件驱动服务器框架：

class EventLoop { public: void run() { while (!quit_) { auto readyEvents = poller_.poll(100); // 等待100毫秒 for (const auto& event : readyEvents) { if (event.userData == &listener_) { // 监听Socket可读，接受新连接 Connection conn = listener_.acceptNonBlocking(); conn.setNonBlocking(true); // 将新连接的fd和可读事件注册到poller，userData指向该conn对象 poller_.addOrModify(conn.fd(), Poller::READ_EVENT, &conn); connections_.emplace(conn.fd(), std::move(conn)); } else { // 某个Connection的事件 Connection* conn = static_cast<Connection*>(event.userData); handleConnectionEvent(*conn, event.events); } } // 处理其他任务，如定时器、任务队列等 } } private: Poller poller_; Listener listener_; std::unordered_map<int, Connection> connections_; // fd -> Connection void handleConnectionEvent(Connection& conn, uint32_t events) { if (events & Poller::READ_EVENT) { // 可读，接收数据 std::string data = conn.receiveSome(); // 非阻塞接收 if (data.empty()) { // 对端关闭连接 poller_.remove(conn.fd()); connections_.erase(conn.fd()); return; } // ... 处理数据 ... } if (events & Poller::WRITE_EVENT) { // 可写，继续发送之前未发完的数据 // ... 发送逻辑 ... } if (events & Poller::ERROR_EVENT) { // 错误，关闭连接 poller_.remove(conn.fd()); connections_.erase(conn.fd()); } } };

这个框架就是Reactor模式的核心。通过一个事件循环（Event Loop）驱动所有连接的处理，能够轻松应对成千上万的并发连接，资源消耗远低于多线程阻塞模型。

7. 常见问题排查与性能优化

在实际使用自研的Network类时，你肯定会遇到各种问题。这里总结一些典型场景和排查思路。

7.1 连接失败与错误码解读

• connect返回ECONNREFUSED(Connection refused)：目标端口没有进程在监听。检查服务器是否启动，防火墙是否放行。
• bind返回EADDRINUSE(Address already in use)：端口被占用。确保设置了SO_REUSEADDR选项，并检查是否有其他程序（包括之前未正确退出的自己）占用了端口。Linux下可以用netstat -tlnp | grep <端口号>查看。
• send或recv返回ECONNRESET(Connection reset by peer)：对端异常关闭了连接（如进程崩溃）。这是正常的网络现象，你的程序应该能优雅处理，关闭本地的Socket并清理资源。
• recv返回 0：对端优雅地关闭了连接（调用了shutdown或close）。这表示没有更多数据会到来。
• send触发SIGPIPE信号（Linux）：向一个已关闭的Socket写数据。通过设置send的MSG_NOSIGNAL标志（如我们之前所做）或忽略SIGPIPE信号（signal(SIGPIPE, SIG_IGN)）来避免程序崩溃。

7.2 性能瓶颈与优化点

1. 缓冲区大小：send和recv使用的缓冲区大小会影响性能。太小会导致频繁的系统调用，太大会增加内存占用和延迟。通常设置为几KB到几十KB（如8K, 16K, 64K）是一个不错的起点，需要根据实际网络环境和报文大小测试调整。可以通过setsockopt设置SO_SNDBUF和SO_RCVBUF来调整内核缓冲区大小。
2. Nagle算法与TCP_NODELAY：Nagle算法会合并小数据包以减少网络报文数量，但会增加延迟。对于需要低延迟的交互式应用（如游戏、实时通信），在创建Connection后应立即调用setTcpNoDelay(true)来禁用它。
3. 避免内存拷贝：在高性能场景下，频繁的数据拷贝（如将数据从用户缓冲区复制到std::string再发送）会成为瓶颈。可以考虑使用writev/readv进行分散/聚集IO，或使用零拷贝技术（如splice、sendfile，但通常用于文件传输）。
4. 日志与调试输出：在事件循环的核心路径上，避免使用同步的std::cout或阻塞的日志库，这会严重拖慢事件处理速度。使用异步日志或仅在调试时开启详细日志。

7.3 多线程与线程安全

我们的事件驱动模型通常在一个主线程运行事件循环（Poller::poll和事件分发）。然而，耗时的业务逻辑（如数据库查询、复杂计算）不应该阻塞事件循环。

• 线程池：将接收到的数据包包装成任务，投递到一个工作线程池中去处理。处理完成后，如果需要回写数据，可以通过线程安全的队列通知事件循环线程，由它来执行send操作（因为Socket操作最好在同一个线程）。
• 线程间通信：可以使用无锁队列、管道（pipe）或eventfd（Linux）来通知事件循环线程有新的任务或数据需要发送。将管道或eventfd的读端也注册到Poller中，当工作线程写入数据时，事件循环线程就会被唤醒并处理。
• Connection对象的线程安全：Connection对象本身不是线程安全的。一个常见的模式是，每个Connection对象只由一个线程（通常是事件循环线程）操作其Socket。业务线程只处理数据，不直接调用conn.send()。

实现一个完整、高性能、易用的C++网络库是一个庞大的工程，本文详解的Network类实现，涵盖了从基础Socket封装到事件驱动模型的核心概念与关键实现细节。从阻塞IO到非阻塞IO+多路复用，是提升网络程序并发能力的必经之路。理解每一步背后的原理和取舍，远比单纯调用一个现成的网络库（如Boost.Asio、libevent）更有价值。当你自己踩过这些坑，再去看那些成熟库的源码和设计，会有更深刻的体会。在实际项目中，你可以基于这个框架，继续扩展支持SSL/TLS、协议编解码、连接池、负载均衡等高级特性，逐步构建出满足复杂业务需求的网络通信中间件。