1. 这不是API列表，而是一张网络通信的“操作地图”

刚入行那会儿，我翻过不下十本网络编程教材，每本都把socket()、bind()、listen()、accept()、connect()、send()、recv()这几个函数列成表格，配上参数说明和返回值定义。看得头大，写出来的代码却总在connect()卡住、recv()返回0就懵、send()发一半数据就断连——不是函数不会用，是根本没搞懂它们在干啥，更不知道它们之间怎么咬合运转。

“socket常用API函数”这八个字，表面看是C语言里的一组函数名，实际是一套完整的、分阶段的网络连接与数据交互协议栈的用户态接口映射。它们不是孤立的工具，而是一条流水线：从申请通信身份（socket），到绑定本地地址（bind），到准备接待访客（listen），再到真正握手（accept/connect），最后才是传话（send/recv）。漏掉任一环，整条链就断。

如果你正在调试一个卡在connect()的客户端，或者服务端accept()后收不到数据，又或者recv()总是返回0却不确定是对方关闭还是网络异常——那你不是缺函数原型，而是缺对这套API背后状态机的理解。这篇内容不罗列手册，不贴头文件，只讲我在某实验室做跨平台图像传输系统、在某公司重构高并发日志网关、以及带新人排查生产环境TCP粘包问题时，反复验证、踩坑、再验证出来的实操逻辑。它适合三类人：刚学完《计算机网络》但写不出稳定socket程序的在校生；能写但总被线上偶发连接失败困扰的初级开发；以及想给团队写一份真正能落地的socket规范文档的技术负责人。

核心关键词已经嵌进来了：socket常用API函数——这不是泛泛而谈，而是聚焦在真实项目中95%以上场景都会用到的那7个核心函数，每一个都对应一个不可跳过的通信生命周期阶段。下面拆解的不是语法，是动作背后的意图、约束条件、失败信号的真实含义，以及——最关键的——你该在哪个环节加日志、在哪种返回值下该重试、为什么send()成功不代表对方已收到。

2. API设计逻辑：为什么是这7个函数？它们如何构成一张状态流转图

2.1 不是“函数集合”，而是一套“连接生命周期管理协议”

很多初学者把 socket API 当成普通函数库，看到socket()就以为“创建了连接”，看到connect()就觉得“连上了”。这是最危险的认知偏差。socket API 的本质，是操作系统内核为用户程序提供的、对TCP/IP协议栈状态机的一套有限控制接口。它不让你直接操作SYN包，但给你一个connect()函数去触发整个三次握手流程；它不让你手动组装ACK，但通过recv()的返回值告诉你对方是否已关闭连接。

我们先画出这张状态流转图（文字版）：

[未初始化] ↓ socket() → [已创建，未绑定] ↓ bind() → [已绑定地址，未监听] ↓ listen() → [已进入监听队列，等待连接] ↓ accept() → [新连接建立，进入ESTABLISHED] [另一条路] [未初始化] ↓ socket() → [已创建，未绑定] ↓ connect()→ [发起连接请求，经历SYN→SYN-ACK→ACK] ↓ 成功 → [进入ESTABLISHED]

注意两个关键点：

1. socket()是起点，不是终点：它只是向内核申请一个“通信句柄”，就像去银行领了一个空白存折本。此时它没有IP、没有端口、没指定是服务端还是客户端，甚至还没决定用TCP还是UDP。它只是一个空壳，后续所有操作都在往这个壳里填信息。

2. bind()和connect()是两条平行路径的分水岭：

   • 服务端必须走bind()→listen()→accept()路径。bind()把这个空壳“钉”在某个IP+端口上，告诉内核：“以后发给这个地址的包，都交给我处理。”
   • 客户端通常跳过bind()，直接connect()。因为客户端不需要固定端口，内核会自动分配一个临时端口（ephemeral port）。但如果你要做源地址绑定（比如多网卡服务器指定从某张网卡发包），bind()就成了客户端的必选项。

提示：bind()对客户端非强制，但对服务端是强制的。很多新手服务端程序启动失败，报错Address already in use，就是忘了bind()前没设置SO_REUSEADDR选项，导致上次异常退出的socket还占着端口。

2.2 为什么没有“close()”？因为它太简单，也太容易错

你可能注意到，标题里没提close()。不是它不重要，恰恰相反，它是整个生命周期的终结者，但它的“常用性”体现在错误用法上。close()看似简单，实则暗藏玄机：

• 在Linux下，close()只是减少文件描述符引用计数。只有当计数降为0时，内核才真正发送FIN包，开始四次挥手。
• 如果你在多线程中共享一个socket fd，一个线程close()了，另一个线程还在send()，就会触发SIGPIPE信号（默认终止进程）或返回EPIPE错误。
• 更隐蔽的是：close()并不保证数据已送达对方。它只是告诉内核“我不再用了”，内核会尽力把发送缓冲区里的数据发完，但不等对方ACK。所以，真正的“安全关闭”必须是shutdown(SHUT_WR)+ 循环recv()直到返回0（对方也关闭了读端），最后再close()。

这就是为什么“socket常用API函数”聚焦在前7个——它们构建连接、维持通信；而close()的正确用法，是建立在深刻理解这7个函数所维护的状态之上的。

2.3send()和recv()：数据搬运工，但绝不“即送即达”

这是最容易产生幻觉的两个函数。send()成功，只代表数据拷贝进了内核的发送缓冲区，不代表网络已发出，更不代表对方已收到。recv()返回正数，只代表从内核接收缓冲区拷贝出了这么多字节，不代表这是一个完整业务包。

举个真实案例：某公司做设备远程固件升级，协议规定每个包头4字节（表示包体长度），然后是N字节数据。他们用recv()一次读4字节，再根据长度recv()N字节。结果在弱网环境下，第一次recv()成功读到4字节，第二次recv()却只读到部分数据，甚至阻塞超时。问题不在recv()，而在他们没理解TCP是字节流，不是消息队列。recv()没有“按包读取”的语义，它只管从缓冲区里拿数据，拿多少算多少。

解决方案不是换函数，而是补逻辑：必须自己实现“粘包/拆包”处理。要么用定长包，要么用分隔符，要么用长度前缀——而这一切的前提，是你得知道send()和recv()只负责搬运，不负责分界。

3. 核心函数逐个深挖：参数、返回值、典型错误码与真实世界应对策略

3.1socket()：申请通信身份证，但别急着填信息

int socket(int domain, int type, int protocol);

• domain（协议族）：最常用AF_INET（IPv4）和AF_INET6（IPv6）。别用PF_INET，虽然历史原因它和AF_INET值相同，但POSIX标准明确推荐用AF_前缀，PF_是旧的“protocol family”叫法，已过时。
• type（套接字类型）：SOCK_STREAM（TCP，可靠、有序、字节流）、SOCK_DGRAM（UDP，无连接、不可靠、数据报）。千万别混淆：TCP不能用SOCK_DGRAM，UDP不能用SOCK_STREAM，否则socket()直接返回-1。
• protocol（具体协议）：绝大多数情况填0。内核会根据domain和type自动选择（如AF_INET + SOCK_STREAM→ TCP）。只有当你需要IPPROTO_RAW这种底层协议时才指定。

实操心得：

• 我在某跨平台项目中遇到过socket()失败，错误码EAFNOSUPPORT。查了半天，发现是Android NDK版本太低，不支持AF_INET6。解决方案不是硬编码AF_INET，而是先getaddrinfo()获取可用地址族，再动态调用socket()。
• socket()返回的fd，务必检查是否-1。我见过太多代码直接int sockfd = socket(...);然后就bind()，结果bind()因fd无效而失败，错误日志里却只显示bind: Bad file descriptor，让人误以为是地址问题。

3.2bind()：给通信句柄“落户”，服务端的成人礼

int bind(int sockfd, const struct sockaddr *addr, socklen_t addrlen);

• addr：指向sockaddr_in（IPv4）或sockaddr_in6（IPv6）结构体。关键字段：
  • sin_family：必须和socket()的domain一致（如AF_INET）。
  • sin_port：端口号，必须用htons()转换为网络字节序！写sin_port = 8080是致命错误，因为8080在小端机器上是0x1F90，网络字节序要求高位在前，正确写法是sin_port = htons(8080)。
  • sin_addr.s_addr：IP地址，INADDR_ANY（0x00000000）表示监听本机所有网卡，inet_addr("127.0.0.1")表示只监听回环。

典型错误与避坑：

• EADDRINUSE（地址已被使用）：最常见。原因有二：一是端口真被其他进程占了；二是上个socket没完全关闭，处于TIME_WAIT状态（默认2MSL，约4分钟）。解决方案是setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on))，让内核允许重用处于TIME_WAIT的地址。注意：SO_REUSEADDR不等于SO_REUSEPORT（后者允许多进程绑定同一端口，Linux 3.9+支持）。
• EACCES（权限不足）：尝试绑定1024以下端口（如80、443），普通用户无权操作。要么用root运行，要么用authbind工具，或改用高编号端口。

注意：bind()对客户端非必需，但若你调用了，且sin_port设为0，内核会自动分配一个可用端口（ephemeral port），并可通过getsockname()获取。这在需要记录客户端源端口的审计场景很有用。

3.3listen()：从“待业青年”变成“营业中”的临界点

int listen(int sockfd, int backlog);

• backlog：这个参数常被严重误解。它不是最大并发连接数，而是内核为该socket维护的“已完成连接队列”（completed connection queue）的最大长度。当客户端connect()完成三次握手后，内核就把这个连接放入此队列，等待你的accept()来取。如果队列满了，内核会丢弃后续的SYN包（表现为客户端connect()超时）。

backlog该设多大？

• 传统观点：设为128或1024。
• 现代实践：Linux 2.2+ 引入了somaxconn内核参数（默认128），backlog实际生效值是min(backlog, /proc/sys/net/core/somaxconn)。所以，如果你设backlog=1000，但somaxconn=128，那还是128。
• 我的经验：对于QPS上千的服务，somaxconn至少调到1024，并在listen()时传入同样值。否则，在秒级突发流量下，大量连接会因队列满而被丢弃，监控上看就是“连接成功率骤降”，但netstat -s | grep -i "listen"会显示listen overflows计数飙升。

3.4accept()：迎接客人，但要防“假客人”

int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen);

• addr和addrlen：用于获取客户端的IP和端口。addrlen必须初始化为sizeof(struct sockaddr_in)，否则accept()可能因缓冲区不足而失败。
• 阻塞 vs 非阻塞：默认阻塞。如果sockfd设为非阻塞（fcntl(sockfd, F_SETFL, O_NONBLOCK)），accept()会立即返回-1，错误码EAGAIN或EWOULDBLOCK，表示当前没有完成连接，需稍后重试。

关键认知：

• accept()返回的新fd，是专属于这个客户端连接的独立句柄。它继承了原sockfd的一些属性（如SO_RCVBUF），但有自己的发送/接收缓冲区。你可以对它单独setsockopt()，比如为不同客户端设置不同的超时。
• 永远检查返回值：accept()失败很常见。EMFILE（进程打开文件数超限）、ENFILE（系统总文件数超限）、ENOMEM（内存不足）都可能导致失败。我在线上见过因ulimit -n设置过低（默认1024），在连接洪峰时accept()大量失败，错误日志刷屏，但服务却没挂，只是拒绝所有新连接。

3.5connect()：主动发起握手，但别指望“一呼即应”

int connect(int sockfd, const struct sockaddr *addr, socklen_t addrlen);

• 同步 vs 异步：默认同步阻塞。connect()会一直等到三次握手完成（成功）或超时失败（如目标主机不可达、端口关闭）才返回。
• 异步连接：将sockfd设为非阻塞后，connect()会立即返回-1，错误码EINPROGRESS。此时你需要用select()/poll()/epoll()监听该fd的可写事件（writable）。当可写时，调用getsockopt(sockfd, SOL_SOCKET, SO_ERROR, &err, &len)检查err是否为0，0表示连接成功。

超时控制实战：

• 同步connect()的超时由内核决定（通常75秒），无法精确控制。必须用异步方式实现毫秒级超时。我在某金融行情推送系统中，要求连接超时严格控制在3秒内。做法是：socket()→fcntl(O_NONBLOCK)→connect()→epoll_wait()等待3秒 → 检查SO_ERROR。这样，即使对方防火墙静默丢弃SYN包，也能在3秒后果断放弃，避免线程长时间阻塞。

3.6send()：把数据交给内核，但别以为它“已送达”

ssize_t send(int sockfd, const void *buf, size_t len, int flags);

• flags：最常用MSG_NOSIGNAL（防止SIGPIPE）和MSG_DONTWAIT（本次调用不阻塞，等同于对fd设了O_NONBLOCK）。
• 返回值：成功时返回实际拷贝到内核缓冲区的字节数，可能小于len！例如，发送缓冲区只剩100字节，而你send()1000字节，它可能只拷贝100字节并返回100。必须循环调用，直到len全部发送完毕。

循环发送的标准写法：

ssize_t sent = 0; while (sent < len) { ssize_t n = send(sockfd, buf + sent, len - sent, MSG_NOSIGNAL); if (n < 0) { if (errno == EINTR) continue; // 被信号中断，重试 if (errno == EAGAIN || errno == EWOULDBLOCK) { // 缓冲区满，需等待可写事件（epoll_ctl EPOLL_CTL_MOD） break; } return -1; // 真正错误 } sent += n; }

提示：send()的EAGAIN/EWOULDBLOCK是正常现象，尤其在非阻塞模式下。它不是错误，而是“请稍后再试”的信号。很多新手把它当错误处理，导致连接被意外关闭。

3.7recv()：从内核取数据，但别幻想“一锅端”

ssize_t recv(int sockfd, void *buf, size_t len, int flags);

• flags：MSG_PEEK（窥探数据，不移除缓冲区内容）、MSG_WAITALL（阻塞直到len字节全部收到，慎用！可能永久阻塞）。
• 返回值：
  • >0：成功读取的字节数。
  • ==0：对方已关闭连接（FIN包到达）。这是TCP优雅关闭的明确信号，不是错误！你的程序应该清理资源，退出循环。
  • <0：出错。EAGAIN/EWOULDBLOCK（非阻塞模式下缓冲区空）、ECONNRESET（对方RST强制关闭）、ECONNABORTED（连接被对方异常中止）。

处理“半包”的核心逻辑：

// 假设协议：4字节长度 + N字节数据 uint32_t header; ssize_t n = recv(sockfd, &header, sizeof(header), MSG_WAITALL); if (n != sizeof(header)) { if (n == 0) { /* 对方关闭 */ } else { /* 错误 */ } } uint32_t payload_len = ntohl(header); // 网络字节序转主机序 char *payload = malloc(payload_len); n = recv(sockfd, payload, payload_len, MSG_WAITALL); // 这里用MSG_WAITALL确保读完

为什么MSG_WAITALL在这里安全？因为recv()读取的是已确认到达的字节流，只要对方发了，内核缓冲区就有。MSG_WAITALL只是让recv()阻塞等待，直到payload_len字节全部进入缓冲区并被拷贝出来。它不会等“未来可能发来的包”，所以不会无限阻塞。

4. 实操全流程：从零搭建一个可调试的TCP回显服务端与客户端

4.1 服务端：不只是listen()和accept()，还要处理并发与异常

我们写一个健壮的服务端，它能：

• 处理多个客户端并发连接（用epoll）
• 每个连接超时30秒无活动则断开
• 收到数据后原样回显
• 所有错误都有清晰日志

核心步骤分解：

1. 创建socket并设置选项：

   int listenfd = socket(AF_INET, SOCK_STREAM, 0); if (listenfd == -1) { perror("socket"); exit(1); } // 设置SO_REUSEADDR，避免重启时"Address already in use" int on = 1; setsockopt(listenfd, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on)); struct sockaddr_in serv_addr; memset(&serv_addr, 0, sizeof(serv_addr)); serv_addr.sin_family = AF_INET; serv_addr.sin_addr.s_addr = htonl(INADDR_ANY); serv_addr.sin_port = htons(8080); if (bind(listenfd, (struct sockaddr*)&serv_addr, sizeof(serv_addr)) == -1) { perror("bind"); exit(1); } if (listen(listenfd, 1024) == -1) { // backlog设为1024 perror("listen"); exit(1); }

2. 初始化epoll：

   int epfd = epoll_create1(0); if (epfd == -1) { perror("epoll_create1"); exit(1); } struct epoll_event ev, events[64]; ev.events = EPOLLIN; // 关注可读事件 ev.data.fd = listenfd; if (epoll_ctl(epfd, EPOLL_CTL_ADD, listenfd, &ev) == -1) { perror("epoll_ctl: listenfd"); exit(1); }

3. 主事件循环：

   while (1) { int nfds = epoll_wait(epfd, events, 64, 1000); // 1秒超时，便于检查超时 if (nfds == -1) { if (errno == EINTR) continue; // 被信号中断，重试 perror("epoll_wait"); break; } for (int i = 0; i < nfds; i++) { if (events[i].data.fd == listenfd) { // 新连接到来 struct sockaddr_in cli_addr; socklen_t cli_len = sizeof(cli_addr); int connfd = accept(listenfd, (struct sockaddr*)&cli_addr, &cli_len); if (connfd == -1) { if (errno == EAGAIN || errno == EWOULDBLOCK) continue; perror("accept"); continue; } // 设置connfd为非阻塞 int flags = fcntl(connfd, F_GETFL, 0); fcntl(connfd, F_SETFL, flags | O_NONBLOCK); // 添加到epoll，关注可读和可写（可写用于检测连接关闭） ev.events = EPOLLIN | EPOLLET; // 边缘触发 ev.data.fd = connfd; if (epoll_ctl(epfd, EPOLL_CTL_ADD, connfd, &ev) == -1) { perror("epoll_ctl: connfd"); close(connfd); continue; } printf("New connection from %s:%d\n", inet_ntoa(cli_addr.sin_addr), ntohs(cli_addr.sin_port)); } else { // 已有连接的事件 handle_client_event(epfd, events[i].data.fd, events[i].events); } } // 检查所有活跃连接是否超时（简化版，实际用定时器fd） check_timeout_connections(); }

4. 处理客户端事件 (handle_client_event)：

   void handle_client_event(int epfd, int connfd, uint32_t events) { if (events & EPOLLIN) { char buf[1024]; ssize_t n = recv(connfd, buf, sizeof(buf)-1, 0); if (n > 0) { buf[n] = '\0'; printf("Received: %s", buf); // 回显 send(connfd, buf, n, MSG_NOSIGNAL); update_last_active_time(connfd); // 更新超时时间戳 } else if (n == 0) { // 对方关闭 printf("Client closed connection\n"); epoll_ctl(epfd, EPOLL_CTL_DEL, connfd, NULL); close(connfd); } else { if (errno == EAGAIN || errno == EWOULDBLOCK) return; perror("recv"); // 真正错误 epoll_ctl(epfd, EPOLL_CTL_DEL, connfd, NULL); close(connfd); } } if (events & EPOLLERR || events & EPOLLHUP) { // 连接异常 printf("Connection error/hup\n"); epoll_ctl(epfd, EPOLL_CTL_DEL, connfd, NULL); close(connfd); } }

关键细节说明：

• 使用EPOLLET（边缘触发）而非EPOLLONESHOT，是因为我们需要持续监听，但只在状态变化时通知。这要求每次recv()必须循环读到EAGAIN，否则会丢失事件。
• MSG_NOSIGNAL防止send()触发SIGPIPE，这是线上服务的必备选项。
• check_timeout_connections()函数需维护一个连接列表，记录每个connfd的最后活跃时间，每轮循环检查是否超30秒。实际项目中，用timerfd_create()配合epoll更高效。

4.2 客户端：模拟真实场景，包含重连、超时、错误恢复

客户端目标：连接服务端，发送一条消息，接收回显，断开。但要模拟真实世界的脆弱性。

int connect_with_timeout(const char *ip, int port, int timeout_ms) { int sockfd = socket(AF_INET, SOCK_STREAM, 0); if (sockfd == -1) return -1; // 设为非阻塞 int flags = fcntl(sockfd, F_GETFL, 0); fcntl(sockfd, F_SETFL, flags | O_NONBLOCK); struct sockaddr_in serv_addr; memset(&serv_addr, 0, sizeof(serv_addr)); serv_addr.sin_family = AF_INET; serv_addr.sin_port = htons(port); if (inet_pton(AF_INET, ip, &serv_addr.sin_addr) <= 0) { close(sockfd); return -1; } // 发起连接 int ret = connect(sockfd, (struct sockaddr*)&serv_addr, sizeof(serv_addr)); if (ret == 0) { // 立即成功（本地回环或快速响应） return sockfd; } if (errno != EINPROGRESS) { close(sockfd); return -1; } // 等待连接完成或超时 struct pollfd pfd = {sockfd, POLLOUT, 0}; ret = poll(&pfd, 1, timeout_ms); if (ret == 0) { // 超时 close(sockfd); return -1; } if (ret < 0 || !(pfd.revents & POLLOUT)) { close(sockfd); return -1; } // 检查连接结果 int err; socklen_t len = sizeof(err); if (getsockopt(sockfd, SOL_SOCKET, SO_ERROR, &err, &len) < 0 || err != 0) { close(sockfd); return -1; } // 连接成功，恢复为阻塞模式（方便后续recv/send） fcntl(sockfd, F_SETFL, flags); return sockfd; } int main() { int sockfd = -1; int retry = 0; const int MAX_RETRY = 3; while (retry < MAX_RETRY && sockfd == -1) { sockfd = connect_with_timeout("127.0.0.1", 8080, 3000); // 3秒超时 if (sockfd == -1) { printf("Connect failed, retry %d/%d...\n", ++retry, MAX_RETRY); sleep(1); // 退避 } } if (sockfd == -1) { fprintf(stderr, "All retries failed\n"); return 1; } const char *msg = "Hello, Echo Server!\n"; if (send(sockfd, msg, strlen(msg), 0) != strlen(msg)) { perror("send"); close(sockfd); return 1; } char buf[1024]; ssize_t n = recv(sockfd, buf, sizeof(buf)-1, 0); if (n > 0) { buf[n] = '\0'; printf("Echo: %s", buf); } else if (n == 0) { printf("Server closed connection\n"); } else { perror("recv"); } close(sockfd); return 0; }

这个客户端的价值在于：

• connect_with_timeout()封装了异步连接+超时的完整逻辑，可直接复用。
• 重试机制带退避（sleep(1)），避免雪崩式重连。
• send()和recv()都做了完整性检查，不假设一次调用就能完成。

5. 常见问题与排查技巧实录：那些手册里不会写的“血泪教训”

5.1 问题速查表：从现象反推根因

5.2 独家避坑技巧：来自生产环境的“灰度经验”

技巧1：用SO_LINGER控制close()行为，但要极度谨慎
SO_LINGER结构体可以强制close()等待所有数据发送完毕并收到对方ACK（l_onoff=1, l_linger=0是强制RST，l_linger>0是等待）。但在高并发服务中，绝对不要设置l_linger>0！因为这会让close()变成一个可能长达数秒的阻塞操作，瞬间拖垮整个线程池。正确的做法是：shutdown(SHUT_WR)后，用epoll监听该fd的可读事件，recv()返回0时再close()。

技巧2：getpeername()比accept()的addr参数更可靠
accept()的addr参数有时会返回0.0.0.0（尤其在SO_REUSEADDR场景下）。要获取真实的客户端IP，应在accept()成功后，立即对新connfd调用getpeername()。它总是返回对端的真实地址。

技巧3：send()的MSG_MORE标志，让内核“攒包”
在需要发送多个小块数据（如HTTP响应头+响应体）时，对前几块send()加MSG_MORE标志，告诉内核“后面还有数据”，内核会将它们合并成一个TCP段发送，减少包数量。这比关Nagle更精准，因为它只影响本次发送序列。

技巧4：诊断TIME_WAIT泛滥，看/proc/net/sockstat
当netstat -an \| grep TIME_WAIT \| wc -l数值巨大时，除了调net.ipv4.tcp_tw_reuse，更要检查/proc/net/sockstat：

sockets: used 1234 TCP: inuse 567 orphan 89 tw 456 alloc 789 mem 1024

其中tw就是TIME_WAIT数量。如果alloc（已分配socket总数）远大于inuse（当前使用中），说明连接创建销毁非常频繁，可能是客户端短连接滥用，需优化为长连接。

技巧5：strace是终极调试利器，但要用对
对一个卡死的进程strace -p pid -e trace=network，能看到它卡在哪个socket系统调用上。如果卡在recv()，说明在等数据；如果卡在connect()，说明网络不通；如果卡在epoll_wait()，说明没有事件。比看日志快十倍。

6. 性能与安全加固：让socket程序从“能跑”到“稳如磐石”

6.1 性能调优：缓冲区、队列与系统参数

• 发送/接收缓冲区 (SO_SNDBUF/SO_RCVBUF)：
  默认值（Linux）通常很小（约128KB）。对于高速网络（如万兆内网），应增大：

  int sndbuf = 4 * 1024 * 1024; // 4MB