要在Linux下写TCP客户端连接服务器，核心就是socket、connect、收发数据三步，代码量不大，但细节决定成败。很多初学者卡在连接不上、超时、粘包这些问题上，其实都是对TCP底层机制理解不够，这篇文章从基础API讲起，逐步深入到错误排查和性能优化，帮你把客户端代码写扎实。
Linux TCP客户端编程的核心思路
TCP客户端编程的流程非常固定,理解了这个流程，代码就是填空题，客户端不需要bind，也不需要listen，那是服务器的事，客户端要做的是发起连接、交换数据、关闭连接。
标准连接流程
第一步,创建socket。socket(AF_INET, SOCK_STREAM, 0)，AF_INET表示IPv4，SOCK_STREAM表示TCP流式套接字，这一步失败的情况很少，基本就是文件描述符耗尽。
第二步,设置服务器地址结构体，需要填服务器的IP和端口，注意IP要用inet_pton()把点分十进制字符串转换成二进制格式，端口要用htons()转成网络字节序，这里有个特别容易踩的坑：端口号写反了，或者忘了转字节序，导致连接到一个完全不对的端口。
第三步,调用connect()发起连接，这是阻塞调用，TCP会执行三次握手，如果对端不可达，这里会卡住一段时间然后返回错误，超时时间通常比较长，生产环境代码一般要设置非阻塞模式配合select或poll来控制超时。
第四步,连接建立后，用send()和recv()收发数据。
第五步,通信完毕，调用close()关闭连接。
一个最小可运行的客户端代码
#include <stdio.h>
#include <string.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <unistd.h>
int main() {
int sockfd = socket(AF_INET, SOCK_STREAM, 0);
if (sockfd < 0) {
perror("socket");
return 1;
}
struct sockaddr_in server_addr;
memset(&server_addr, 0, sizeof(server_addr));
server_addr.sin_family = AF_INET;
server_addr.sin_port = htons(8080);
inet_pton(AF_INET, "127.0.0.1", &server_addr.sin_addr);
if (connect(sockfd, (struct sockaddr )&server_addr, sizeof(server_addr)) < 0) {
perror("connect");
close(sockfd);
return 1;
}
const char msg = "Hello, Server!";
send(sockfd, msg, strlen(msg), 0);
char buf[1024] = {0};
recv(sockfd, buf, sizeof(buf) - 1, 0);
printf("Received: %s\n", buf);
close(sockfd);
return 0;
}
编译命令：gcc client.c -o client，这段代码能跑通，但只适合学习，到了真实环境，还得处理很多边界情况。
Linux socket编程实例：连接超时控制
默认的connect()是阻塞式的，如果服务器IP不可达，可能要等一两分钟才返回错误，这在生产环境不可接受，行业共识认为，客户端连接超时应该控制在3到5秒以内，否则用户会直接认为服务挂了。
非阻塞connect的正确写法
把socket设为非阻塞,调用connect()后立即返回，再用select()或poll()等待结果，具体步骤：
- 用
fcntl()把socket设置为非阻塞模式 - 调用
connect()，此时通常会返回-1，错误码是EINPROGRESS，表示连接正在建立 - 调用
select()，设置超时时间，监听socket的可写事件 - 如果
select()返回可写，再用getsockopt()检查SO_ERROR选项，0表示连接成功，其他值表示失败原因
int connect_with_timeout(int fd, struct sockaddr addr, socklen_t len, int timeout_sec) {
int flags = fcntl(fd, F_GETFL, 0);
fcntl(fd, F_SETFL, flags | O_NONBLOCK);
int ret = connect(fd, addr, len);
if (ret == 0) {
fcntl(fd, F_SETFL, flags);
return 0;
}
if (errno != EINPROGRESS) {
return -1;
}
fd_set wset;
FD_ZERO(&wset);
FD_SET(fd, &wset);
struct timeval tv = {timeout_sec, 0};
ret = select(fd + 1, NULL, &wset, NULL, &tv);
if (ret <= 0) {
return -1;
}
int err = 0;
socklen_t elen = sizeof(err);
getsockopt(fd, SOL_SOCKET, SO_ERROR, &err, &elen);
if (err != 0) {
return -1;
}
fcntl(fd, F_SETFL, flags);
return 0;
}
这里有个细节：getsockopt()读SO_ERROR后，错误码会被清除，所以一定要在拿到值之后再判断。
常见的TCP客户端连接不上原因排查
连接不上服务器,错误提示五花八门，根据经验，绝大多数情况集中在这几个方面。
从错误码看问题本质
| 错误码 | 含义 | 常见场景 |
|---|---|---|
| ECONNREFUSED (111) | 连接被拒绝 | 端口没监听、防火墙拦截、进程没启动 |
| ETIMEDOUT (110) | 连接超时 | IP不可达、路由不通、防火墙丢弃包 |
| EHOSTUNREACH (113) | 主机不可达 | 网络配置错误、对端不在同一网络 |
| EADDRNOTAVAIL (99) | 地址不可用 | 本机没有配置对应IP地址 |
从Windows交叉测试定位问题
Windows下能用,Linux下连不上，这种情况相当常见，排查方向：
- 防火墙：Windows防火墙默认允许特定端口，Linux的iptables/firewalld默认规则可能不同，用
iptables -L -n查看当前规则。 - SELinux：在一些CentOS发行版上，SELinux会拦截网络访问，可以在
/var/log/audit/audit.log里看到AVC拒绝记录。 - 字节序：
htons()和ntohs()在Windows和Linux下行为一致，但要看代码里是否在某一端多转了一次字节序。
可以用tcpdump看协议栈实际情况：tcpdump -i any tcp port 8080 -nn，观察SYN包是否发出，是否有SYN-ACK回复，如果只有SYN发出而没有回复，大概率是防火墙丢包或网络不可达；如果收到RST，说明对端端口没有监听。
客户端数据收发：处理粘包和半包
TCP是字节流协议,没有消息边界。send()发送的数据，对端recv()不一定按相同切割方式收到，这也是行业内说的粘包和半包问题。
常用的定界方案
- 固定长度消息：每条消息都按固定字节数发送，不足补0，解析简单，但浪费空间，适合消息格式统一的场景。
- 长度字段+数据体：消息头用2字节或4字节存数据体长度，接收方先收头，再收体，这是应用最广泛的方案。
- 特殊分隔符：如HTTP的
\r\n\r\n、Redis的\r\n，简单直接，但数据内容里不能出现分隔符序列。
// 发送消息头+数据体 uint32_t len = htonl(strlen(payload)); send(fd, &len, 4, 0); send(fd, payload, strlen(payload), 0); // 接收端先收4字节长度 uint32_t len; recv(fd, &len, 4, MSG_WAITALL); len = ntohl(len); char data = malloc(len + 1); recv(fd, data, len, MSG_WAITALL); data[len] = '\0';
使用MSG_WAITALL标志可以确保一次性收满指定字节数，否则recv()返回的字节数可能小于请求值，配合非阻塞IO和多路复用，才能写出高并发客户端。
短连接还是长连接：如何选择
客户端与服务端的连接模式,直接决定代码架构。
各自适用的场景
短连接的典型场景是HTTP请求,每次请求都建立新TCP连接，请求完就关闭，好处是服务端资源释放干净，坏处是三次握手+四次挥手带来额外延迟，在延迟敏感的场景，新增的RTT开销可能占整个请求时间的40%以上。
长连接适用于请求频繁、消息密集的场景，比如消息推送、实时游戏同步、数据库连接，连接建立后复用，省去握手开销，但需要处理心跳保活和断线重连逻辑。
对于长连接,操作系统层面的SO_KEEPALIVE探活间隔默认是2小时，太长了，生产环境通常要设短一些：
int keepalive = 1; setsockopt(fd, SOL_SOCKET, SO_KEEPALIVE, &keepalive, sizeof(keepalive)); int idle = 30; // 30秒无数据时开始探测 setsockopt(fd, IPPROTO_TCP, TCP_KEEPIDLE, &idle, sizeof(idle));
这里要注意,TCP保活只能检测连接是否失效，不能判断对端应用是否卡死，业务层面的心跳包（应用层ping/pong）才是更可靠的方案。
TCP客户端相关常见问题解答
问：connect返回ECONNREFUSED，一定是服务器没启动吗？
不完全是,多数情况下是服务器没有监听对应端口，但防火墙手段也可能产生这个错误，例如iptables的REJECT策略默认返回RST包，客户端看到的就是ECONNREFUSED，用tcpdump观察对端是否有回应，判断是主动拒绝还是被丢弃，还有一种情况是服务器监听了0.0.1而客户端连的是外网IP，内核也会直接返回ECONNREFUSED。
问：connect超时时间怎么设置比较合理？
没有绝对标准,取决于业务容忍度，内部服务建议3秒，公网服务建议5到10秒，如果再细分，移动网络下用10秒，因为弱网环境握手时间偏长，实际调优逻辑是：统计线上P99耗时的1.5到2倍，加上500毫秒冗余，这种方法比随手填一个数字可靠得多。
问：客户端大量出现TIME_WAIT状态的连接该如何处理？
客户端主动关闭连接后,进入TIME_WAIT状态，持续约60秒，大量TIME_WAIT意味着短连接释放过快，这不一定需要处理，但客户端频繁创建连接又关闭，容易触发端口耗尽，这时有两个方向：一是改用长连接，重复利用已有TCP连接；二是调整net.ipv4.ip_local_port_range扩大可用端口范围，配合net.ipv4.tcp_tw_reuse在内核层面复用TIME_WAIT连接。
从Linux TCP客户端编程的完整链路来看，核心就三件事：把连接建起来、把数据传明白、把资源管干净，很多人把注意力放在send和recv上，忽略了connect超时和错误处理，结果生产环境遇到网络抖动就暴露问题，建议先写出一个支持超时控制和错误分类的客户端框架，再逐步补充重连、心跳、并发管理能力，这样无论是做后台服务还是嵌入式设备，都能稳定跑很久。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/794957.html
