服务器和客户端之间的TCP通讯，本质上就是两台设备通过三次握手建立可靠连接、按序传输数据、四次挥手断开连接的过程，socket编程是落地的核心手段。
接下来按权重拆解。
服务器和客户端tcp通讯原理是什么
TCP（Transmission Control Protocol）是传输层协议，它在IP协议之上增加了可靠性保障，服务器和客户端各自维护一个socket对象，通过端口号唯一标识通信端点。
三次握手建立连接
客户端主动调用connect()，服务端listen()监听端口，内核完成三次报文交换，第一次客户端发SYN，第二次服务端回SYN+ACK，第三次客户端再发ACK，为什么需要第三步？因为服务端需要确认客户端的接收能力正常，这三步缺一不可，少了任何一步，连接状态都不完整。
四次挥手断开连接
断开时客户端或服务端任一方调用close()，流程是主动方发FIN、被动方回ACK、被动方发FIN、主动方回ACK，中间多出的第二步，是为了让被动方把剩余数据发送完毕，常见的时间等待状态TIME_WAIT就出现在主动关闭方，它要等2MSL（最长报文段寿命）才能彻底释放端口，这是防止旧连接的数据包干扰新连接。
数据在连接中如何流动
连接建立后,数据以字节流形式传输，内核为socket分配了发送缓冲区和接收缓冲区，send()只是把数据拷贝到内核缓冲区，真正发送由内核控制，接收方收到数据后放进接收缓冲区，recv()从缓冲区取数据，这个机制解释了为什么TCP没有消息边界，粘包问题由此而来。
tcp通讯长连接和短连接区别
这是服务器开发选型时绕不开的问题,短连接是每次请求都建立新连接，请求完就断开；长连接是连接建立后保持不断，多次请求复用同一条连接。
| 对比维度 | 短连接 | 长连接 |
|---|---|---|
| 连接开销 | 每次都要三次握手 | 只握手一次 |
| 适用场景 | 低频请求、简单查询 | 高频交互、实时推送 |
| 资源占用 | 服务端负载低 | 需维护心跳和连接状态 |
| 典型端口 | HTTP/1.0传统接口 | WebSocket、即时通讯 |
行业共识认为,物联网设备和服务器之间的数据上报，绝大多数采用长连接，因为设备频繁建立连接会消耗大量电量和网络资源，而普通的API接口，比如客户端查询天气，用短连接就足够。
长连接的心跳机制
长连接最怕的是”假死”状态连接看似存在，实际已经断掉，解决方法是心跳包，客户端每隔30秒到60秒发送一个心跳报文，服务端如果在超时时间内没收到，就判定连接失效并清理资源，心跳间隔的设定要结合业务：太频繁浪费流量，太稀疏无法及时发现断线。
长连接和短连接怎么选
选型依据有三个：请求频率、数据实时性要求、服务端并发能力，请求间隔超过30秒，用短连接更划算；需要服务端主动推送，必须用长连接，还有折中方案连接池，比如数据库连接池，本质是复用手工维护的长连接集合。
服务器客户端tcp通讯延迟高怎么办
延迟高是线上排查最常见的问题,先区分是网络延迟还是应用延迟，再对症下药。
第一步：用ping和traceroute定位网络瓶颈
在客户端执行ping命令,看往返时延（RTT），如果RTT稳定但业务延迟高，问题大概率在应用层，如果RTT波动大，用traceroute看每一跳的耗时，定位到具体运营商节点。
ping -c 10 服务器IP
traceroute 服务器IP第二步：检查Nagle算法和延迟确认
Nagle算法会把小包合并发送,但对实时性要求高的场景反而增加延迟，在socket上设置TCP_NODELAY可以关闭这个算法，接收方的延迟确认（Delayed ACK）可能与Nagle算法产生交互，导致40毫秒级别的额外延迟，客户端和服务端都开启TCP_NODELAY，是即时通讯类应用的常见做法。
第三步：抓包分析重传
用tcpdump在服务端抓包,看有没有大量TCP重传，重传意味着网络丢包，这是延迟高的直接元凶，丢包率在局域网内应该接近零，公网环境允许极少量丢包，但超过一定比例就必须联系运营商处理。
tcpdump -i eth0 tcp port 8080 -w tcp.pcap抓包后用Wireshark打开,重点看TCP的Retransmission标记。
第四步：优化应用层读取逻辑
如果网络层面一切正常,延迟来自应用处理，检查服务端是否用了阻塞式I/O，一个慢请求会拖累整个线程，改成非阻塞I/O或异步I/O，配合多路复用（epoll或select），单机并发能力能提升一个量级。
tcp socket编程步骤
新手学TCP通讯,直接看这七步就够了，服务端和客户端各有固定套路。
服务端socket编程流程
- socket()创建套接字
- bind()绑定IP和端口
- listen()把套接字转为监听状态
- accept()阻塞等待客户端连接，返回新的socket
- recv()接收数据
- send()发送数据
- close()关闭连接
每一步都有对应的错误处理,bind()失败最常见的原因是端口被占用，可以用netstat工具查询端口状态。
客户端socket编程流程
- socket()创建套接字
- connect()向服务端发起连接请求
- send()发送数据
- recv()接收数据
- close()关闭连接
客户端的步骤比服务端简单,核心是connect()的返回值，connect()返回0表示连接成功，返回-1需要用errno判断失败原因。
一个最小可运行的服务端示例
用Python演示最直观,因为语法简洁且库封装完整：
import socket
server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server.bind(('0.0.0.0', 8080))
server.listen(5)
while True:
client, addr = server.accept()
data = client.recv(1024)
client.send(b'Hello, client!')
client.close()
这段代码可以跑在云服务器上,用手机的TCP调试工具连接测试，注意bind的IP用了0.0.0.0，表示监听所有网卡接口，这样公网IP和内网IP都能访问。
服务器tcp通讯工具推荐
生产环境调试TCP通讯,推荐三个工具组合。tcpdump用于命令行抓包，Wireshark用于可视化分析，nc（netcat）用于快速测试端口连通性，Windows用户可以用Network Analyzer或TCP调试助手，这些工具都能在官网免费下载，如果服务器在简米云或酷番云上，控制台自带的安全组规则，本质就是TCP端口层面的访问控制。
Q&A：服务器tcp通讯常见问题
为什么我连接服务器老是超时？
先确认服务器端口是否监听,执行netstat -tlnp查看监听状态，再检查云厂商安全组是否放行了对应端口，很多新手在本地能连，但公网连不上，就是安全组规则没配置，最后ping一下服务器IP，排除网络不通的情况。
TCP通讯中的数据粘包怎么处理？
粘包是TCP字节流特性导致的,应用层需要自己定义消息边界，常用方案是固定长度报文、长度字段前置、分隔符分割，长度字段前置是最稳妥的做法：消息头固定4字节存长度，消息体存实际数据，接收端先读4字节解析长度，再读对应长度的数据，业内专家指出，这个方案在绝大多数业务场景下都是首选。
单台服务器能支持多少并发连接？
理论上限是65535个端口,但实际受文件描述符数量、内存大小、内核参数限制，Linux系统默认文件描述符上限是1024，需要修改ulimit和/etc/sysctl.conf中的网络参数，配合epoll模型，一台4核8G的云服务器支撑数万个长连接是可行的，据工信部公开信息，国内主流云厂商的负载均衡产品，后端单实例单机并发能力普遍在十万级别。
TCP通讯的核心价值在于可靠,它用三次握手和重传机制换来了数据传输的确定性，无论业务怎么变，socket编程的基本流程和长连接的心跳维护，都是每个后端工程师绕不开的基本功。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/554920.html
