先看一段代码：

func main() {
    ln, _ := net.Listen("tcp", ":8080")
    for {
        conn, _ := ln.Accept()
        go func(c net.Conn) {
            defer c.Close()
            io.Copy(c, c) // echo
        }(conn)
    }
}

8 行。一个能跑的 TCP echo server。

Go 的 net 包让网络编程简单到有点不真实。你甚至不需要理解 epoll 是什么，不需要手动管理线程池。net.Listen + Accept + goroutine，完事了。

但这个 echo server 离生产可用有多远？

从 echo server 到生产可用，要补的东西比你以为的多。从"能跑"到"能扛"，中间藏着三层进阶——连接管理、协议设计、性能调优。不少人卡在第一层就停了，以为自己已经"会"网络编程了。

这篇文章就沿着这三层往下走。每一层，我都会尽可能用实测数据和踩坑经历来支撑。

一个提醒：三层不是严格递进——你可以交错进行，但建议按这个优先级排查。连接管不好就去设计协议，是本末倒置。

1. 第一层：连接管理

1.1 goroutine 的真实成本

“goroutine 很轻量”——这话说了十年了。但轻量到底是多轻？

我写了一个测试程序：启动一个 TCP 服务，逐步建立 100 到 10000 个连接，每个连接分配一个 goroutine 和 4KB 的读缓冲区（这是最常见的配置）。然后用 runtime.ReadMemStats 测内存。

结果：

每个连接大约 5 KB。这个数字包含了 goroutine 栈（初始 2KB，但会按需增长）和 4KB 的读缓冲区。一万个连接，50 MB 内存。

50 MB 多吗？对一台 8GB 内存的服务器来说，不多。goroutine-per-conn 模型在万级连接以内，内存开销可控。

那什么时候会出问题？不是连接数太多，而是连接没被正确关闭。

1.2 CLOSE_WAIT 排查：一次不太愉快的经历

我在一个网关项目里遇到过一次。线上服务跑了两天后，监控报连接数异常。我上去一看 netstat：

$ netstat -ant | grep CLOSE_WAIT | wc -l
3847

快四千个 CLOSE_WAIT。

CLOSE_WAIT 的意思是：对端已经发了 FIN（我要断开了），但你这边还没调 Close()。换句话说，对端想走，你没放人。

我排查了半天，最后发现问题出在一个处理函数里：

func handleConn(conn net.Conn) {
    // 问题：如果 readHeader 报错，直接 return
    // 此时 conn.Close() 永远不会被调用
    header, err := readHeader(conn)
    if err != nil {
        log.Printf("读取头部失败: %v", err)
        return // conn 泄漏了
    }
    defer conn.Close()
    // ... 后续处理
}

defer conn.Close() 写在了 readHeader 之后。如果 readHeader 报错直接 return，defer 根本没注册上，连接就泄漏了。

修复很简单——把 defer conn.Close() 提到函数第一行。但这个 bug 在测试环境完全没暴露，因为测试时连接少、报错少。线上跑两天，积攒了几千个泄漏连接。

教训：defer conn.Close() 永远写在获取 conn 之后的第一行。没有例外。

还有一个更隐蔽的坑：即使 defer conn.Close() 位置正确，如果 goroutine 阻塞在 conn.Read() 上迟迟不返回，连接同样无法关闭。这在对端异常断开（没发 FIN，比如拔网线）时很常见——你的 goroutine 会永远卡在 Read 上，连接进入 CLOSE_WAIT 却无人处理。

防范手段是给每个连接设 SetReadDeadline：

func handleConn(conn net.Conn) {
    defer conn.Close()
    for {
        conn.SetReadDeadline(time.Now().Add(30 * time.Second))
        n, err := conn.Read(buf)
        if err != nil {
            return // 超时或对端关闭，goroutine 退出
        }
        // 处理数据...
    }
}

30 秒内没收到数据，Read 返回超时错误，goroutine 正常退出，连接正常关闭。具体超时值根据你的心跳间隔来定。

1.3 TIME_WAIT：短连接的隐形杀手

TIME_WAIT 的坑就不一样了。

场景是一个短连接高频的服务——每次请求建立 TCP 连接，处理完就断开。QPS 大约 3000。跑了一阵后，新连接开始失败，报 bind: address already in use。

$ netstat -ant | grep TIME_WAIT | wc -l
28547

两万多个 TIME_WAIT。

TIME_WAIT 是 TCP 四次挥手后主动关闭方进入的状态，默认持续 2MSL（Linux 上固定 60 秒；MSL = 报文最大生存时间）。这是协议设计，不是 bug——它防止旧连接的延迟包被新连接误收。

但在短连接高频场景下，60 秒内积攒的 TIME_WAIT 连接会占满本地端口（默认 32768-60999，约 28000 个）。端口耗尽，新连接就建不起来了。

解法有几条：

• 优先改成长连接 + 连接池。能复用连接就别每次都新建
• 如果是服务端主动关闭导致的 TIME_WAIT 影响重启，SO_REUSEADDR（Go 对 listen socket 默认已开启）可以解决 bind 问题
• 调大 net.ipv4.ip_local_port_range（治标不治本）
• 让服务端被动关闭（让客户端先断），避免服务端积攒 TIME_WAIT。通常通过协议层关闭握手实现——服务端发送"处理完毕"信号，客户端收到后主动断开

当你的消息开始变复杂——有心跳包，有业务数据，有 1KB 的也有 100KB 的——你怎么分辨它们？

这就是第二层的事了。

2. 第二层：协议设计

2.1 粘包不是 TCP 的 bug

你写过 TCP 服务的话，大概率遇到过一个诡异的问题——明明发了好几条消息，收的时候它们粘在一起了。

我写了一个实验来复现。客户端连续发送 5 条消息，每条 9-11 字节。看看服务端怎么收：

发送第 1 条: 11 字节 → "msg-1:hello"
发送第 2 条: 11 字节 → "msg-2:world"
第 1 次 Read: 收到 22 字节 → "msg-1:hellomsg-2:world"

发送第 3 条: 9 字节 → "msg-3:foo"
第 2 次 Read: 收到 9 字节 → "msg-3:foo"

发了 5 条消息，Read 调用只有 4 次。第一次 Read 把前两条消息粘在一起收了。

这不是 bug。TCP 是字节流协议——它承诺按序交付你的字节，但不承诺保留消息边界。你往一根水管里倒了五杯水，对面接的时候当然不知道哪杯到哪杯。

TCP 没有"粘包"，只有你没有协议。

有个容易误判的陷阱：你在本地测试时消息可能总是一条一条完整到达——因为本地回环快到没有攒包机会。然后上线后，跨机器网络延迟一来，Nagle 算法开始合并小包，粘包问题瞬间爆发。不少人以为自己的代码"没有粘包问题"，其实只是本地环境帮你藏了而已。

2.2 三种分帧策略

解决粘包的核心就是"分帧"——在字节流里标记每条消息的边界。

先说最通用的方案：Length-Prefix（长度前缀）。消息前面加 4 字节表示长度。收到后先读 4 字节拿到长度，再读对应字节数。大多数二进制协议都用这个方案——简单、高效、无歧义。

与之对应的是 Delimiter（分隔符）：用特定字符（比如换行符 \n）标记消息结尾。Redis 的 RESP 协议就用 \r\n。优点是人类可读，缺点是消息体里不能包含分隔符（除非加转义机制，会增加复杂度）。适合文本协议，不适合二进制数据。

还有 Fixed-Length（固定长度）：每条消息固定 N 字节，不够的补零。最简单粗暴，但浪费带宽。

哪个快？我跑了 benchmark（Go 1.26.2, Apple M4 Pro, 57 字节测试消息，加 sink 变量防止编译器 DCE）：

length-prefix 解码最快——0.62 ns/op，因为直接按偏移量切片，不需要扫描。delimiter 需要逐字节找分隔符，慢了近 4 倍。fixed-length 解码最慢——要处理填充字节的截断。编码方面 delimiter 最快（11.9 ns），length-prefix 紧随其后（12.3 ns），fixed-length 反而最慢（16.1 ns），因为需要分配更大的缓冲区来容纳填充。

综合来看，length-prefix 是最通用的选择。给一个最小可用的实现：

func encode(msg []byte) []byte {
    // 生产环境通常用 sync.Pool 复用 buffer，避免每次分配
    buf := make([]byte, 4+len(msg))
    binary.BigEndian.PutUint32(buf[:4], uint32(len(msg)))
    copy(buf[4:], msg)
    return buf
}

func decode(data []byte) (msg []byte, n int) {
    if len(data) < 4 {
        return nil, 0
    }
    msgLen := int(binary.BigEndian.Uint32(data[:4]))
    if len(data) < 4+msgLen {
        return nil, 0
    }
    // 注意：返回的 msg 引用了原始 data，复用 buffer 时需拷贝
    return data[4 : 4+msgLen], 4 + msgLen
}

encode 在消息前面加 4 字节长度头，decode 先读长度再切消息。如果数据不够（半包），返回零值让调用方继续读。

2.3 从帧到协议

分帧只解决了"一条消息从哪里开始到哪里结束"。但一个真正的协议还需要更多东西。

想象你的服务现在要处理三种消息：心跳包、普通请求、文件传输。你怎么区分它们？单靠 length-prefix 不够，你还需要：

• 消息类型标识：1 字节或 2 字节的 type 字段，区分心跳、请求、响应
• 版本号：协议会迭代，预留 1 字节让新旧版本共存
• 序列号：请求-响应配对用，不然并发场景下你分不清哪个响应对应哪个请求
• 错误码：响应里附带状态，调用方不需要解析 body 就知道成功还是失败

一个实用的最小帧头长这样：

8 字节帧头 + 变长 payload。够用了。

什么时候不需要自己设计？如果你的场景是标准的请求-响应模式，消息是结构化数据（JSON/Protobuf），而且需要跨语言——直接用 gRPC。gRPC 在 HTTP/2 上做了完整的分帧、多路复用、流控。自己造轮子没有意义。

但如果你在做游戏服务器、IoT 网关、高频交易——对帧头大小、编解码延迟有极端要求——自定义协议就是必要的。

3. 第三层：性能调优

协议设计解决了"怎么解析消息"。但当你的服务开始承受压力——延迟上升、吞吐量到顶——就该进第三层了。

3.1 TCP_NODELAY 不是万金油

TCP_NODELAY 是一个出镜率很高的 socket 选项。它关闭 Nagle 算法——Nagle 会把小包攒起来一起发，减少网络上的小包数量，但增加了延迟。

直觉上，关掉 Nagle、设 TCP_NODELAY = true 应该能降低延迟。但我的实测结果出乎意料。

测试环境：Go 1.26.2，本地回环（127.0.0.1），分别用 64B 小包、512B 中包、4KB 大包：

NoDelay=true 反而更慢？

以上数据仅在本地回环成立——本地回环没有真实的网络延迟，Nagle 合并小包减少了系统调用次数，每次 write 都是一次系统调用，合并后调用次数更少，总耗时更低。跨机器的真实网络中，Nagle 引入的等待延迟才是主要矛盾，情况会反转。

Nagle 算法在等什么？它等的是对端的 ACK。如果对端开启了 delayed ACK（大多数系统默认开启），ACK 会延迟发送。Nagle 等 ACK + delayed ACK 延迟回复，两者配合可以引入 40ms 量级的额外延迟。在游戏、实时通信这类场景下，40ms 的延迟是不可接受的。

结论：Go 默认对 TCP 连接开启 NoDelay，这是为跨机器场景优化的合理默认值。本地回环的数据不能反驳这一点。如果你不确定是否要改这个选项——先在真实网络环境测，而不是凭本地数据下结论。对延迟敏感的场景（游戏、实时通信），保持 NoDelay=true；对吞吐优先的批量传输场景，可以考虑关闭 NoDelay 让 Nagle 合并小包。

3.2 何时该换模型

标准库的 goroutine-per-conn 模型有天花板吗？有。但这个天花板比你以为的高。

gnet 是 Go 生态里最知名的高性能网络框架，它用 epoll/kqueue 事件驱动模型替代了 goroutine-per-conn。根据 gnet v2.x 官方 echo benchmark（引用 gnet 官方 benchmark，未自测），在百万级并发连接场景下，gnet 的吞吐量有显著性能优势。

但注意前提：百万级并发连接。

你的服务有百万并发连接吗？大概率没有。数万级连接规模下，标准库的性能通常可以接受——§1.1 的数据显示一万连接只占 50 MB 内存，而标准库真正的瓶颈不在内存，在于 GC 扫描大量 goroutine 时的停顿。实际项目中，根据我的经验，在连接数超过五万之前，GC 停顿通常还不足以影响 P99 延迟（具体阈值取决于对象分配模式和 GC 调优参数）。goroutine-per-conn 模型的优势是代码简单——每个连接一个 goroutine，用最直觉的阻塞式 I/O 写逻辑，可读性和可维护性远好于事件驱动模型。

那什么时候该考虑 gnet 这类框架？最明确的信号是连接数持续在十万以上，并且你已经通过 pprof 确认 GC 停顿在影响延迟 SLA。另一个信号是你已经排除了应用层的优化空间——连接池、协议优化、业务逻辑优化都做过了，瓶颈确实在网络层。最后一条很关键：在换模型之前，先确认瓶颈真的在网络层。比如某次优化中，pprof 显示热点其实在 JSON 序列化而不是网络 I/O，换了 gnet 性能纹丝不动。

3.3 TCP vs UDP：什么时候选哪个

什么时候用 TCP，什么时候用 UDP？看三个维度：

几个典型场景：API 网关用 TCP + 连接池，可靠性第一；游戏服务器用 UDP + 应用层可靠性，自己实现选择性重传；日志采集用 UDP fire-and-forget，丢包在可接受范围内（拥塞时可能批量丢失）；DNS 查询用 UDP，单次请求-响应不需要建连开销。

选了 UDP 不等于放弃可靠性。很多游戏引擎（比如 ENet，一个轻量的 C 语言网络库）在 UDP 上实现了自己的可靠传输层——比 TCP 更灵活，可以按消息类型决定要不要重传。

在 Go 里用 UDP 有个特点值得注意：net.UDPConn 的 ReadFromUDP 每次调用返回一个完整的 UDP 数据报——不存在 TCP 那样的粘包问题，消息边界天然保留。但 UDP 数据报大小受限于 MTU（通常 1472 字节 payload），超过就会被 IP 层分片，分片丢失等同整个数据报丢失。所以 UDP 场景下，你需要自己控制消息大小。

回到那个 echo server

回头看开头那 8 行代码。现在你知道它缺什么了：

• 没有连接管理——defer conn.Close() 的位置对吗？超时设了吗？连接泄漏怎么发现？
• 没有协议——io.Copy 只是把字节原样搬运。真实业务里，你需要分帧、需要消息类型、需要心跳
• 没有调优——socket 选项是默认值，也没考虑过什么时候该切连接池

三层进阶不是都要走完。关键是判断你的项目在哪一层。给你一个 checklist：

1. 连接有没有被正确关闭？（netstat 查 CLOSE_WAIT）
2. 有没有超时控制？（SetReadDeadline 或 context 超时）
3. 你的消息有分帧吗？（如果只是 Read 然后处理，你有粘包问题）
4. 协议有版本号吗？（没有的话，后面迭代会很痛）
5. 瓶颈真的在网络层吗？（先用 pprof（Go 内置性能分析工具）看热点，别急着换框架）

大多数 Go 项目，走完第一层、做好第二层，就够用了。第三层，等你真的遇到性能瓶颈再说。

别急着跑。先把连接管好。

附录：实验代码

本文涉及的实验代码（goroutine 内存压力测试、TCP 粘包复现、分帧策略 benchmark、TCP_NODELAY 对比）均已开源，可复现验证：

GitHub：zhiyulab-evidence/go-network-programming