企业官网建设流程全解析

Socket网络编程这个题目，几乎每个做后端、做客户端、做嵌入式、做游戏服务端的人都绕不开。我刚入行那会儿，觉得Socket就是几个函数：创建、绑定、监听、收发，背下来就能用。真正在项目里跑起来才发现，能跑通和能扛住是两码事——本地两个进程聊得好好的，一放到真实网络里就开始丢数据、卡死、连接数涨上去下不来。所以这篇不谈教科书式的名词解释，我想把自己这些年写Socket代码的顺序捋一遍：先讲清楚它到底是什么、为什么长这样，再给一份能直接跑的最小示例，然后把粘包、超时、端口复用这些"文档里一笔带过、实际会要命"的点掰开揉碎，最后整理一份排查问题的速查表。不管你是刚接触网络编程的新手，还是写过几年代码但总在细节上翻车的同行，应该都能从里面拿到点能直接抄的东西。

1. 先搞清楚Socket到底是个什么东西

1.1 从一通电话说起：Socket在通信链路里的位置

很多人第一次听到Socket，脑子里是抽象的"套接字"三个字，其实用打电话类比是最贴切的。你家里的电话机相当于一台主机，电话号码相当于IP地址，分机号相当于端口号。光有电话号码打不通，因为对方可能有几十部分机；光有分机号也没用，因为你不知道往哪儿打。IP加端口合在一起，才能唯一定位到某个进程。而Socket，就是你手里那部"已经拨通的电话"——它不是一个物理设备，而是操作系统给进程提供的一个句柄，背后挂着发送缓冲区、接收缓冲区、连接状态机这一整套东西。

我在给新人讲这块时会强调一个事实：Socket本质上是文件描述符。在类Unix系统里，你调用socket()拿到的返回值就是一个整数，和打开一个文件拿到的fd没有本质区别，一样可以用read/write去操作，一样受文件描述符上限约束。理解这一点很关键，后面讲select的1024限制、讲fd泄漏、讲epoll为什么高效，全都建立在这个前提上。很多人写代码时把Socket当成一个特殊对象供着，反而不敢用统一的方式去管理它的生命周期，最后就是连接泄漏。

再往下一层，Socket是应用层和传输层之间的接口。应用层往下走，是TCP/UDP，再往下是IP，再往下是链路层。Socket API做的事情，是把"我要发一段数据给对面某个端口"这个意图，翻译成内核能执行的协议栈动作。你调用send()返回的时候，数据只是被拷进了内核的发送缓冲区，并不代表对面收到了。这个认知差异，是后面一大堆"为什么我发成功了但对面没收到"问题的根源。

1.2 TCP与UDP两套性格迥异的"插座"

创建Socket时的第二个参数决定了协议类型，最常见的就是SOCK_STREAM和SOCK_DGRAM。前者对应TCP，后者对应UDP。这两个不是"高级版"和"低级版"的关系，而是两种设计哲学，选错了后面怎么优化都别扭。

TCP是面向连接的字节流协议，它自己负责重传、排序、流控、拥塞控制。你往里写100个字节，对面可能分3次读到，也可能一次读到200个字节里包含你前后两次写的内容。它保证的是"字节按序不丢不重到达"，不保证"消息边界"。这就是粘包的由来，后面会专门讲。TCP适合什么场景？文件传输、HTTP接口、数据库连接、需要可靠有序的业务数据，这些场景下丢一个字节整个语义就废了，必须TCP。

UDP是无连接的数据报协议，你发一个包就是一个包，内核不保证到达、不保证顺序、不保证不重复。听起来很糟糕，但它的优势是快和简单：没有握手挥手，没有连接状态维护，没有重传等待，头部开销只有8字节。实时音视频、游戏里的位置同步、DNS查询、日志采集这类场景，丢一两个包用户几乎无感，但如果为了等一个过期包重传而卡住200毫秒，体验反而崩了，这时候UDP才是对的选择。

我个人的经验是：拿不准的时候先选TCP，除非你能明确说出"这个场景允许丢包且延迟比完整性更重要"。见过太多项目一开始图省事用UDP传业务指令，结果自己在外层实现了一套重传加序号，做得比TCP还差。

1.3 为什么大多数业务场景我优先选TCP

接着上面说。自己实现可靠传输这件事，听起来很酷，实际是个无底洞。你要处理超时重传的退避策略、要处理乱序重组、要处理接收窗口和发送窗口、要处理拥塞时的降速，任何一环做不好，弱网环境下表现就不如内核那套打磨了几十年的实现。内核的TCP栈还做了路径MTU发现、快速重传、SACK选择确认这些细节优化，业务层很难复制。

还有一个容易忽略的点：TCP的连接状态本身就是一种资源管理和限流手段。服务端能通过连接数直观看到当前有多少客户端在线，能通过accept队列长度感知压力，能在对端异常时收到FIN或者RST。UDP没有这些信号，你得自己在应用层造一套会话管理，工作量并不小。

当然，TCP也有它烦人的地方。队头阻塞是硬伤：一个包丢了，后面所有数据都得等着，哪怕它们已经到了。所以在丢包率高的移动网络下，单条TCP连接做多路复用会有明显延迟抖动。这也是为什么有些场景会在应用层做多连接或者干脆换QUIC。但这是进阶话题，先把TCP用扎实，比一上来就追求新协议实在得多。

2. 开发环境准备与最小可跑通示例

2.1 环境与语言选型：为什么用Python起步

讲原理时用什么语言其实不重要，因为Socket API在各语言里长得几乎一样，都是那几个调用的排列组合。但我还是建议第一步用Python，原因很实际：它没有编译步骤，改一行跑一次，能把注意力全放在"连接是怎么建立的、数据是怎么流动的"上面，而不是被构建工具和类型系统分散精力。等服务端骨架跑通了，再换C、Go、Java去实现，你会发现只是换了语法糖。

环境上要注意两点。一是防火墙和本机回环，本地测试尽量用127.0.0.1，避免被系统防火墙拦掉，也避免因为网卡选择错误连不上。二是端口占用，测试时别用80、443、22这些常见端口，容易撞上系统服务或者权限问题。我一般从8000以上开始挑，跑完随手换一个，省得反复处理"Address already in use"。

需要提醒的是，Python的GIL会让你在写多线程服务端时观察到一些反直觉的现象：多个线程同时阻塞在recv上没问题，但CPU密集的处理会互相抢。这不是Socket的问题，是运行时的问题。做原型无所谓，真要压测并发能力，建议换语言或者至少用多进程。

2.2 服务端骨架：bind/listen/accept三段式

服务端的流程可以概括成一句话：创建插座、把插座钉在某个地址上、开始接待、逐个握手。对应到代码就是socket、bind、listen、accept。这里面每个调用的参数都有讲究，我一个个说。

import socket HOST = "127.0.0.1" PORT = 9001 server = socket.socket(socket.AF_INET, socket.SOCK_STREAM) server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) server.bind((HOST, PORT)) server.listen(128) while True: conn, addr = server.accept() print("new client:", addr) while True: data = conn.recv(4096) if not data: break conn.sendall(data) conn.close()

bind的参数是一个二元组，IP加端口。这里有个细节：绑0.0.0.0表示监听所有网卡，绑127.0.0.1只监听本机回环。开发阶段绑回环更安全，上线时再改成0.0.0.0或者具体的内网地址。绑错了会出现"本地能连、别的机器连不上"这种经典问题。

listen的参数是backlog，语义是"已完成三次握手但还没被accept取走的连接队列长度上限"。它不是并发连接总数的上限，很多人误解这一点。设太小，高并发瞬间会有客户端连上来就被拒；设太大，内核里堆着一堆没处理的连接也没意义。我的习惯是设128到1024之间，配合及时accept。有些系统会用somaxconn截断这个值，所以压测时如果发现实际队列比设定小，去查一下系统参数。

setsockopt那行SO_REUSEADDR，是本地开发必加的一行。它允许服务重启时立刻复用处于TIME_WAIT状态的端口，否则你改完代码重启，会看到一个让人抓狂的报错。这个参数线上也建议加，因为它还能防止端口被意外占用时的启动失败。

accept返回的是一个新的socket对象和客户端地址。这一点初学者容易懵：为什么有两个socket？因为监听的那个socket只负责"接待"，真正通信的是accept返回的新连接。原始监听socket继续守着端口等下一个客户端。理解了这个分工，后面理解多路复用就顺了。

2.3 客户端骨架与第一次握手验证

客户端简单得多：创建、连接、收发。没有bind也没有listen，端口由内核自动分配一个临时端口。

import socket client = socket.socket(socket.AF_INET, socket.SOCK_STREAM) client.settimeout(3) client.connect(("127.0.0.1", 9001)) client.sendall(b"hello socket") resp = client.recv(4096) print(resp) client.close()

connect这一行背后发生了三次握手：客户端发SYN，服务端回SYN加ACK，客户端再回ACK。这三个包完成之后，connect才返回。所以connect的耗时能反映网络质量，如果本地测试都要几百毫秒，说明中间有代理或者配置有问题。给connect设超时非常重要，默认情况下它可能卡很久，业务线程就那么被占着。

验证连通性我有几个固定动作。第一，用ss或者netstat看端口有没有在监听，状态是不是LISTEN。第二，看连接建立后状态是不是ESTABLISHED。第三，如果是跨机器测试，先在对面用最简单的连通性检查确认链路可达，再跑程序。这几步能把"代码问题"和"网络问题"快速分开，省掉大量瞎猜。

提示：调Socket程序时，端口号、IP、协议类型这三者在客户端和服务端必须严格对齐。我见过太多"连不上"最后查出来是服务端改了端口客户端没改，或者一边用IPv4一边用IPv6。

还有个小技巧：写测试客户端时，别急着写复杂逻辑，先发一个固定字符串，服务端原样回显。这个回显通了，说明链路、权限、防火墙、协议选择都没问题，剩下的才是业务逻辑的事。

3. 核心细节拆解：那些文档里不写的坑

3.1 粘包与拆包：TCP是字节流不是消息流

这是Socket编程最高频的翻车点，没有之一。现象是：客户端连续发了三条消息，服务端一次recv读到了两条半，或者第一条消息的后半截跟第二条的前半截粘在一起。新手第一反应是"TCP丢数据了"或者"粘包了"，其实TCP一点问题都没有，它只是老老实实按字节流交付，是你自己把"字节流"当成了"消息流"。

根因有两层。发送侧，Nagle算法会把多个小包合并成一个大的TCP段发出去，减少网络上的小包数量；接收侧，内核收到数据先放进接收缓冲区，你的recv调用只是从缓冲区里拷数据，拷多少取决于你给的缓冲区大小和当前有多少数据，跟发送方写了几次毫无关系。两头一叠加，边界就没了。

解决办法是在应用层自己划边界，主流三种：

• 固定长度：每条消息长度固定，不足补位。实现最简单，但浪费带宽，适合定长指令。
• 分隔符：用换行符或者特殊字节分隔，HTTP的头部就是这么干的。问题是数据里如果出现分隔符就要转义。
• 长度前缀：先发一个固定长度的头，里面写明后续正文多少字节，接收方先读头再按长度读正文。这是最通用、最推荐的做法。

我基本上只用长度前缀。定义个简单协议：前4字节是正文长度（网络字节序），后面跟正文。接收方的处理逻辑必须放在循环里，因为一次recv可能只读到半个长度头。

import struct def recv_exact(conn, n): buf = b"" while len(buf) < n: chunk = conn.recv(n - len(buf)) if not chunk: raise ConnectionError("peer closed") buf += chunk return buf def recv_message(conn): header = recv_exact(conn, 4) (length,) = struct.unpack("!I", header) return recv_exact(conn, length) def send_message(conn, payload): conn.sendall(struct.pack("!I", len(payload)) + payload)

这段代码的关键在recv_exact那个循环。很多人写成"读一次，没读够就算了"，在本地回环上因为数据一次性到达，测试全过；一上线遇到网络分片，立刻出问题。所以只要涉及"必须读够N字节"，就必须循环。

注意：recv返回空字节串（b""）的含义是对端正常关闭了连接，不是"暂时没数据"。没数据在阻塞模式下表现为卡住，在非阻塞模式下表现为抛异常。把这两种情况搞混，会写出死循环。

3.2 阻塞与非阻塞：超时设置的正确姿势

默认创建的Socket是阻塞的。阻塞意味着recv没有数据时线程会挂起，connect连不上时会一直等。对简单程序来说这很方便，对服务端来说这是灾难——一个慢客户端就能占住一个线程。

最实用的折中是设置超时。settimeout之后，阻塞操作会在超时后抛出超时异常，你可以在异常处理里决定重试还是断开。这个模式我用了很多年，绝大多数业务服务够用。

conn.settimeout(5.0) try: data = conn.recv(4096) except socket.timeout: # 这里通常是心跳超时或者对端假死 conn.close()

超时值怎么定？我的原则是分场景。普通请求响应，取业务平均耗时的三到五倍；心跳检测，取心跳间隔的两倍左右；大批量数据传输，不要用整体超时，改成"两次收到数据之间的间隔超时"，否则大文件传到一半就被判死。最后这点很多人踩过：给一个要传10分钟的任务设了30秒超时，必然失败。

真正的高并发服务端要用非阻塞加多路复用，这个后面单独讲。这里先提醒一个容易忽略的点：settimeout会影响这个socket上的所有阻塞操作，包括connect、send、recv。如果只想给connect设超时，可以用setblocking(False)配合手动检查，或者用系统层面的连接超时参数，避免误伤后续的收发。

3.3 端口复用与地址占用：TIME_WAIT不是故障

"Address already in use"这个报错，几乎每个写Socket的人都见过。它通常出现在服务重启的时候，明明进程已经退出了，端口却还被占着。这时候用ss看，会看到一堆TIME_WAIT状态的连接。

TIME_WAIT是TCP的正常设计，主动关闭连接的一方会在这个状态停留一段时间（通常是2倍报文最大生存时间，Linux上大约60秒），目的是确保最后一个ACK能到达对端，以及让这条连接的残留报文在网络中消亡，避免影响后续复用相同四元组的新连接。它不是bug，是保护机制。

但开发阶段它确实烦人。解法就是前面提到的SO_REUSEADDR，让新socket可以绑定到处于TIME_WAIT的端口上。注意它只影响绑定，不会缩短TIME_WAIT时长，也不会让活跃连接被抢占，所以是安全的。

有一个坑要说清楚：SO_REUSEADDR和SO_REUSEPORT不是一回事。前者主要解决TIME_WAIT占用，后者允许多个进程或线程绑定完全相同的地址端口，由内核做负载均衡。后者在某些场景下很有用，但用错了会出现"同一个连接被不同进程处理"的诡异现象，排查起来极其痛苦。没有明确需求，不要随手加SO_REUSEPORT。

还有一种"端口占用"跟TIME_WAIT无关：上一个进程没退干净，还持有监听fd。这种情况下SO_REUSEADDR也救不了你，得先把进程找出来。用ss加进程参数一看就知道，养成习惯比瞎试强。

3.4 字节序与数据格式：跨平台通信的隐形地雷

本机测试全绿，一换机器就数据错乱，八成是字节序问题。不同CPU架构对多字节整数的存储顺序不同，小端机器把低位字节放前面，大端机器反过来。网络传输规定统一用大端，也就是所谓网络字节序。你在本地两台同架构机器上测试，永远发现不了这个问题。

Python里用struct的格式化字符控制：!表示网络字节序，<小端，>大端。前面长度前缀我用的!I就是无符号32位大端。如果是C语言，要用htonl、htons、ntohl、ntohs这一组函数做转换，发送前转成网络序，收到后转回主机序。这个转换只对多字节类型有意义，单字节的char不用管。

除了字节序，还有几个格式问题值得提前定好：字符串编码统一用UTF-8，不要一半GBK一半UTF-8；浮点数要不要传，能用定点整数就别传浮点，避免精度差异；变长字段一定带长度；结构体对齐在跨语言时不要依赖编译器默认行为，手动按字节拼装最稳。

我踩过最狠的一次是Java服务端和C客户端通信，服务端用DataOutputStream写int是大端，客户端读的时候没转换，数据全乱。查了大半天以为是协议解析写错了，最后发现就少了一个转换函数。从那以后我定规矩：协议字段表必须写清楚每个字段的类型、字节数、字节序，谁写谁签字。

4. 实操进阶：把Demo改成能扛住真实流量的服务

4.1 多路复用：select、poll、epoll的取舍

一个连接一个线程的模型，在连接数上百之后就撑不住了。线程栈开销、上下文切换开销、锁竞争，都会把CPU吃干净。多路复用的思路是：用一个线程同时盯住成千上万个fd，哪个有事件就去处理哪个。这就是select、poll、epoll这一族系统调用的价值。

select是最老的，用位图表示fd集合，每次调用都要把整个集合从用户态拷到内核态，返回后还要遍历一遍找出哪个就绪。它有个硬限制：通常最多1024个fd，因为位图大小是编译期定死的。poll改进了数据结构，用数组加长度，去掉了1024限制，但拷贝和遍历的问题还在。epoll是Linux的方案，把fd注册到内核的一个实例里，事件就绪时由内核把就绪列表填好，用户态直接读，不用遍历全部。连接数越多，epoll的优势越明显。

epoll有两种触发模式，水平触发和边缘触发。水平触发是"只要缓冲区还有数据就一直通知你"，写起来简单，漏读了下次还会提醒。边缘触发是"只有状态变化时通知一次"，效率更高，但要求你必须一次把数据读干净，通常配合非阻塞socket和循环读到返回"暂时无数据"为止。新手用边缘触发最常见的错误是读了一次就完事，剩下的数据永远留在缓冲区里，表现为业务卡住但连接还在。

import selectors sel = selectors.DefaultSelector() # ... 注册监听socket和已建立连接的socket ... while True: for key, mask in sel.select(timeout=1.0): if mask & selectors.EVENT_READ: data = key.fileobj.recv(65536) if not data: sel.unregister(key.fileobj) key.fileobj.close() else: # 注意这里要做缓冲区拼接和消息拆解 handle(key.fileobj, data)

这段骨架看着简单，真正的复杂度全在handle里：半个消息要缓存、发送缓冲满了要挂起、写事件要动态注册。所以我一般建议，除非确实有性能需求，先用成熟框架，别自己撸事件循环。要学原理可以撸一个，要上生产慎重。

4.2 缓冲区大小与背压控制

缓冲区大小是个容易被忽略但影响很大的参数。内核层面有接收缓冲区和发送缓冲区，可以用setsockopt调整。调太小，高带宽高延迟链路上吞吐上不去，因为一个往返时间内能传输的数据量受限于窗口大小；调太大，内存占用上去了，延迟也可能变大，因为数据在缓冲区里排队。

经验值上，普通业务服务用系统默认就够，不需要动。做文件传输或者大流量转发时，可以按"带宽乘以往返时延"估算所需窗口，再反推缓冲区设置。比如一条100Mbps、往返时延40毫秒的链路，理论在途数据量是100Mbps乘0.04秒等于4Mbit，也就是500KB左右，缓冲区小于这个数就填不满管道。

比内核缓冲区更重要的是应用层背压。所谓背压，就是下游处理不过来时，要能把这个压力传导回上游，而不是无限攒在内存里。典型反例是：接收线程读得飞快，把消息全塞进一个无界队列，处理线程慢慢消费，跑一会儿内存就爆了。正确做法是队列设上限，满了就暂停读，让TCP的接收窗口自然收缩，上游发送方就会被内核限速。这套机制是TCP自带的，用好了非常省心，前提是你别在应用层把它架空。

发送侧同理。sendall看着是阻塞到发完，实际上如果对端接收窗口关闭，它会一直卡着。在非阻塞模式下，send可能只发出去一部分，返回实际发送字节数，剩下的要注册写事件等下次机会。这里必须维护一个发送缓冲区，把没发完的数据存着。忘记处理部分发送，是自研框架里最常见的bug之一。

4.3 心跳与超时重连设计

TCP连接建立之后，如果中间的网络设备静默丢掉了状态，两端可能都以为连接还活着，实际已经不通了。这种现象叫连接假死，表现为send不报错、recv永远没数据、业务请求石沉大海。仅靠TCP自身的保活机制不够用，系统默认的空闲探测时间通常是两小时，业务上完全不能接受。

所以长连接必须有应用层心跳。做法很简单：客户端每隔固定时间发一个轻量心跳包，服务端收到后回一个确认，同时服务端记录每个连接最后活跃时间，超过阈值没动静就主动断开释放资源。心跳间隔怎么定？太短浪费带宽和设备电量，太长发现故障慢。我的经验是15到30秒之间，配合两到三次未响应判定。

# 服务端侧的超时清理逻辑示意 now = time.time() for conn, last_active in list(connections.items()): if now - last_active > 90: conn.close() connections.pop(conn, None)

重连策略也有讲究。固定间隔重连在服务端故障恢复的瞬间会造成惊群，所有客户端同时涌上来。要用带随机抖动的指数退避：第一次1秒，第二次2秒，然后4秒、8秒，上限30秒，每次加一点随机偏移。这样能把请求摊开，服务端压力平滑很多。

还有个细节：重连之后，之前未完成的状态怎么办？我一般让重连成功后走一次全量同步，别指望增量能对上。协议上留一个会话标识字段，服务端发现标识对不上就要求客户端重新拉全量，比在增量逻辑里处理各种边界情况省事得多。

4.4 半关闭与优雅关闭的完整流程

关闭连接看着简单，其实有个完整的流程。直接close的问题在于，如果发送缓冲区里还有数据没发完，close可能会把它们丢掉；如果对端还在发数据，你close之后它收到的就是重置，之前发的全白费。所以严格来说，正常关闭应该分三步：先shutdown写方向，告诉对端我不再发了；然后继续读到对端也关闭；最后close释放fd。

shutdown的写方向关闭就是半关闭，对应TCP的FIN包。这时候连接还是可读的，对端能感知到你不会再发数据，但还能把剩下的数据发完。接收方读到空字节串就表示对端关闭了写方向，它处理完剩余数据后自己也shutdown，两边都关完，close才安全。

# 优雅关闭示意：先关写，再读干净，最后关fd conn.shutdown(socket.SHUT_WR) while True: leftover = conn.recv(4096) if not leftover: break conn.close()

用一个生活化的比喻：半关闭就像挂电话前说"我这边说完了，你还有什么要补充的"。直接close则是直接拔线，对方话没说完就被切断。

另外要说清close和shutdown的区别。close是释放fd，如果有多个进程共享同一个fd，close只减少引用计数，未必真的关闭连接。shutdown是直接作用于连接本身的，不涉及fd引用。在多进程或者fork出来的场景里，这个区别会造成"我明明关了为什么对端还收到数据"的困惑。

5. 常见问题与排查技巧实录

5.1 连不上：从哪一层开始查

连接失败是最常见的问题，但原因可能分布在好几层，瞎猜效率极低，按层往下查最快。第一步，确认目标端口有没有在监听，用ss看状态是否为LISTEN，绑的地址是0.0.0.0还是127.0.0.1。绑回环却从别的机器连，必然失败，这是新手第一坑。第二步，确认链路可达，同网段直接试，跨网段要考虑中间设备策略。第三步，确认客户端用的协议族和目标一致，IPv4连IPv6地址会直接报错。第四步，看服务端的accept队列是不是满了，backlog设太小在高并发下会拒连。第五步，看客户端有没有设超时，如果是超时而非拒绝，往往是中间环节静默丢包，需要抓包确认握手到了哪一步。

连接被拒绝和连接超时是两种完全不同的信号，别混为一谈。被拒绝说明包到了对端，但端口没在监听或者被策略拦掉并回了重置；超时说明包根本没到，或者回程丢了，问题在网络路径上。分清楚这两者，排查范围立刻缩小一半。

还有一类隐蔽情况：连上了，但立刻断开。这通常是服务端accept之后在业务逻辑里检查不通过主动关的，比如鉴权失败、连接数超限、白名单不匹配。这种情况要去翻服务端日志，别在客户端死磕。

5.2 数据收不全、收多了、收串了

收不全，九成是没做循环读取。一次recv读到的数据量取决于内核缓冲区当前有多少，而不是你期望多少。协议规定要读N字节，就必须循环读到N字节。收多了或者收串了，九成是把字节流当消息流，没做应用层拆包。这两种问题的解法前面已经给了，这里只说排查手段：在接收侧把每次recv的返回长度打出来，看一眼就能确认是不是分片到达。

另一个容易忽略的是编码问题。接收方按UTF-8解码，发送方按其他编码打包，中文字符就会出现乱码或者解码异常。这种情况在英文测试里永远正常，一上中文数据就炸。定协议时把编码写死在文档里，别依赖默认值。

还有个小概率但很恶心的情况：发送方用了send而不是sendall，非阻塞模式下只发出去一部分，剩下的被丢弃了。表现是对端收到的消息长度总是差一点。所以除非你自己在维护发送缓冲区，永远用sendall。

5.3 连接假死与CLOSE_WAIT堆积

连接数一路涨、内存一路涨、但CPU不高，这是典型的连接泄漏。去ss里看状态分布，如果CLOSE_WAIT特别多，说明对端已经关闭了连接，而你这边压根没调用close。CLOSE_WAIT是等待本端关闭的状态，它堆积只有一个原因：代码里漏了关闭逻辑，或者关闭逻辑在异常分支里被跳过了。

我的做法是把连接的关闭统一收口到一个地方，用try/finally或者上下文管理器包住，确保任何路径退出都会关。别在每个分支里手写close，漏一个是迟早的事。

连接假死则是另一种表现：连接是ESTABLISHED，但收发都没反应。这种只能靠心跳发现。没有心跳机制的系统，我建议至少配置TCP的保活参数，把默认的两小时缩短到分钟级，虽然它只能探测链路层存活，比没有强。要注意保活探测的间隔和次数在系统层面配置，不同平台参数名不一样，上线前确认清楚。

5.4 抓包与日志联合排查的方法

说到最后，最有效的排查手段是抓包加日志。抓包看事实，日志看上下文，两者对上，问题基本就定位了。抓包工具在命令行用tcpdump，过滤指定端口，抓下来存成文件再用图形化工具分析。要注意权限，普通用户抓不到，需要提权。

抓包看什么？先看握手是否完整，三次握手缺哪一次，问题就在哪一段。再看数据包的序号和确认号，有没有重传、有没有零窗口。零窗口说明接收方缓冲区满了，读得太慢，这时要去看应用层是不是处理阻塞了。再看FIN和RST是谁先发的，主动发RST通常意味着异常终止，比如进程崩了或者缓冲区里有未读数据就close了。

日志方面，建议在连接建立、收到数据、发送数据、连接关闭这四个点都打日志，带上连接标识、数据长度、时间戳。长度比内容更有用，因为日志里打全量数据既慢又有风险。有了这四个点的日志，任何连接问题都能还原出时间线。

5.5 几个我踩过之后才记住的细节

第一个是地址字符串的坑。用主机名代替IP时，解析可能返回多个地址，有的可达有的不可达，程序只试第一个就可能失败。生产环境建议直接配IP，或者实现多地址轮询尝试。

第二个是recv的缓冲区大小。设太小会导致频繁系统调用，设太大浪费内存，64KB左右是个不错的起点。真正影响吞吐的是内核缓冲区，别只盯着应用层这个参数调。

第三个是关于Nagle算法。它会把小包合并，降低网络开销，但对延迟敏感的场景（比如交互式指令）会有几十毫秒的额外等待。这种场景可以关掉它，同时关掉对端的延迟确认，两个一起调才有明显效果。只关一个往往看不到改善。

第四个是连接标识的管理。别用文件描述符当唯一标识，fd会被复用，旧连接的fd可能被新连接拿到，导致日志串线或者状态错乱。自己维护一个单调递增的连接ID，跟fd分开记。

第五个是多线程下的关闭。一个线程在recv阻塞，另一个线程去close，不同平台行为不一致，有的会让recv返回错误，有的会一直卡着。稳妥做法是先shutdown唤醒阻塞的调用，再close释放资源。

我自己这些年写下来的体会是，Socket编程的门槛不在于那几个函数调用，而在于对"字节流、连接状态、资源生命周期"这三件事的持续敬畏。每次我觉得这块已经很熟了，就会在一个新场景里被粘包或者假死教育一次。所以现在我写任何一段网络代码，都会先把协议格式写成一页纸，把连接的生命周期画成一条线，把异常路径一个个列出来，然后再动手敲。这多花的半小时，往往能省掉后面两天的排查。如果你刚开始写，建议从那个能跑通的最小示例开始，然后故意制造几种异常：拔网线、让对端卡住不读、发超长数据、中途杀进程，看看你的程序怎么反应。能把这些异常都处理明白，才算真正把Socket用起来了。