高级Socket编程技术

去年帮一个朋友排查线上事故，高级他的编程服务在高峰期每隔几小时就出现一批连接超时。代码翻了个底朝天，技术逻辑没问题，高级连接池也配了，编程但就是技术扛不住。最后抓包一看，高级问题出在TIME_WAIT状态堆积——服务器主动关闭连接太多，编程本地端口被耗尽。技术这事让我意识到，高级很多人写Socket代码只停留在“能通就行”的编程阶段，对内核层面的技术行为几乎没概念。

Socket编程真正的高级门槛不在API调用。bind、编程listen、技术accept、send、recv这几个函数，看文档半小时就能上手。难的是理解背后那套状态机和缓冲区机制。比如listen的backlog参数，Linux下它控制的是已完成三次握手但还没被accept的队列长度。如果你设成5，而accept循环处理得慢，新连接就会被内核直接丢掉，客户端看到的是超时，服务端连日志都不会有。这种问题在测试环境根本复现不了，因为并发量不够。

非阻塞和I/O多路复用不是可选项

阻塞式Socket写起来舒服，accept等连接，recv等数据，代码读起来像流水账。但一个线程只能盯一个连接，C10K问题就是这么来的。有人用线程池扛，连接数一上来，上下文切换的开销比干活还大。

非阻塞Socket配合epoll才是正经做法。把fd设成O_NONBLOCK，用epoll_wait统一等事件，哪个fd可读就处理哪个。这里有个细节：accept返回的new_fd也要记得设非阻塞，否则一个慢连接就能卡住整个事件循环。我见过不止一个项目栽在这上面。

epoll有两种触发模式，水平触发（LT）和边缘触发（ET）。LT是默认的，只要缓冲区有数据就一直通知你，写起来不容易出错。ET只在状态变化时通知一次，必须一次把数据读干净，否则不会再收到事件。ET效率高，但代码写错的代价是连接假死——数据到了，epoll不通知，你的回调永远不被调用。选哪个取决于团队对这套机制的熟悉程度，不是性能数字上的那点差距。

TCP_NODELAY和缓冲区那些事

Nagle算法默认开启，它会把小包攒起来一起发，减少网络上的小包数量。听起来挺好，但对延迟敏感的场景是灾难。比如游戏服务器发状态同步包，每个包就几十字节，Nagle一攒，延迟直接从1ms飙到40ms。setsockopt设TCP_NODELAY关掉它，这是低延迟场景的标准操作。

SO_SNDBUF和SO_RCVBUF也值得关注。内核给每个Socket分配的发送和接收缓冲区是有默认值的，高带宽高延迟的网络里，默认缓冲区可能不够用，导致吞吐上不去。BDP（带宽延迟积）算一下，比如100Mbps带宽、50ms RTT，需要的缓冲区大约是625KB，而Linux默认的wmem_max可能只有200KB左右。调大需要改系统参数，不是setsockopt就能突破上限的。

心跳和断线检测

TCP本身没有应用层心跳。如果网线被拔，或者中间路由器重启，两端可能都以为连接还在。Keepalive机制默认两小时才探测一次，基本没用。自己实现心跳是必须的：定时发一个小包，连续几次没收到回应就判定断线，主动关闭重连。

心跳间隔的选取有个经验值：内网5到10秒，公网15到30秒。太短浪费带宽，太长断线感知迟钝。另外心跳包不要走业务逻辑，单独一个类型字段，收到直接回，不排队不处理，否则业务线程一卡，心跳也跟着超时，误判断线。

Socket编程写到后面，拼的不是API熟练度，是对TCP状态机、内核缓冲区和网络实际行为的理解。调优参数只是表象，搞清楚数据从网卡到应用层到底经过了什么，才是解决问题的关键。