导语：Go 让网络编程回归"业务本身"
在网络编程的江湖里，C 语言教你把 epoll 事件循环、非阻塞 socket、缓冲区管理亲手写一遍；Java 有 Netty 这样的重型框架。而 Go 给出的答案是：goroutine + net 标准库，让每个连接占一个 goroutine，把 IO 阻塞交给 runtime 统一调度，开发者只需要写"顺序化"的业务代码。
这不代表你可以忽略底层：理解 Go 的 netpoller 如何用 epoll/kqueue 做事件驱动，才能解释"为什么 Go 能同时扛住十万连接"以及"为什么高并发下仍要小心连接数、缓冲与超时"。
一句话总结：Go 网络编程的核心是"每连接一 goroutine + netpoller 事件驱动"，你写的代码像同步阻塞，底层却是 epoll/kqueue 在高效轮转。
1. Socket 抽象与 net 包核心
1.1 net.Conn：一切连接的统一接口
type Conn interface {
Read(b []byte) (n int, err error)
Write(b []byte) (n int, err error)
Close() error
LocalAddr() Addr
RemoteAddr() Addr
SetDeadline(t time.Time) error
SetReadDeadline(t time.Time) error
SetWriteDeadline(t time.Time) error
}
无论底层是 TCP、UDP、Unix Socket 还是 TLS，net.Conn 都提供同一套读写与超时接口。这意味着你的协议编解码代码可以完全无视底层传输差异——这正是 Go 标准库最优雅的设计之一。
1.2 地址族与 Dial
// Dial 建立到任意地址的连接，自动根据 scheme 选择协议
conn, err := net.Dial("tcp", "example.com:443")
// 自定义超时与本地绑定
d := net.Dialer{
Timeout: 3 * time.Second,
KeepAlive: 30 * time.Second,
LocalAddr: &net.TCPAddr{IP: net.ParseIP("0.0.0.0")},
}
conn, err := d.Dial("tcp", "10.0.0.1:8080")
1.3 Listen：服务端入口
ln, err := net.Listen("tcp", ":8080")
if err != nil {
log.Fatal(err)
}
defer ln.Close()
for {
conn, err := ln.Accept() // 阻塞等待新连接
if err != nil {
if ne, ok := err.(net.Error); ok && ne.Timeout() {
continue // 临时错误，继续接受
}
log.Fatal(err)
}
go handleConn(conn) // 每个连接一个 goroutine
}
一句话总结：
net.Conn是传输无关的统一读写接口，Dial负责建连、Listen+Accept负责收连接——这是 Go 网络程序的地基。
2. TCP 服务端与客户端实战
2.1 可优雅关停的服务端骨架
func main() {
ln, err := net.Listen("tcp", ":8080")
if err != nil { log.Fatal(err) }
var wg sync.WaitGroup
// 优雅关停：收到 SIGTERM 后关闭 listener，等待存量连接结束
ctx, stop := signal.NotifyContext(context.Background(), os.Interrupt, syscall.SIGTERM)
defer stop()
go func() {
<-ctx.Done()
ln.Close() // 停止 Accept，已建立的连接仍可继续
}()
for {
conn, err := ln.Accept()
if err != nil {
if ctx.Err() != nil {
break // 收到退出信号
}
continue
}
wg.Add(1)
go func(c net.Conn) {
defer wg.Done()
defer c.Close()
handleConn(c)
}(conn)
}
wg.Wait() // 等待所有连接处理完毕
}
func handleConn(conn net.Conn) {
// 设置读写超时，防止连接长期占用
conn.SetReadDeadline(time.Now().Add(60 * time.Second))
buf := make([]byte, 4096)
for {
n, err := conn.Read(buf)
if err != nil {
if err == io.EOF {
return // 对端关闭
}
if ne, ok := err.(net.Error); ok && ne.Timeout() {
return // 读超时，主动断开
}
return
}
// 处理请求后回写
if _, err := conn.Write([]byte("pong\n")); err != nil {
return
}
_ = n
}
}
2.2 客户端：带超时的读写
func fetch(addr string, payload []byte) ([]byte, error) {
conn, err := net.DialTimeout("tcp", addr, 3*time.Second)
if err != nil {
return nil, err
}
defer conn.Close()
// 整体 deadline：连接建立后所有读写都受此约束
conn.SetDeadline(time.Now().Add(5 * time.Second))
if _, err := conn.Write(payload); err != nil {
return nil, err
}
// 使用 bufio 读取响应
reader := bufio.NewReader(conn)
line, err := reader.ReadString('\n')
if err != nil {
return nil, err
}
return []byte(line), nil
}
2.3 TCP 编程的三个默认陷阱
□ Read 不保证一次读完整条消息 —— 必须自行处理粘包/拆包
□ Write 返回 n < len(b) 且 err == nil 是允许的 —— 需循环写完
□ 连接是双向的：只读不写也要及时关闭，否则两端互相等待
一句话总结：TCP 服务端要关注"优雅关停 + 超时 + 循环读写"，客户端要设置整体 deadline，且永远把 TCP 当字节流而不是消息流处理。
3. UDP 数据报编程
3.1 无连接的服务端
func main() {
// UDP 不需要 Accept，直接用同一个 conn 收发任意客户端的数据报
conn, err := net.ListenPacket("udp", ":9000")
if err != nil { log.Fatal(err) }
defer conn.Close()
buf := make([]byte, 65535) // UDP 最大数据报 65507 字节
for {
n, addr, err := conn.ReadFrom(buf)
if err != nil {
if ne, ok := err.(net.Error); ok && ne.Timeout() {
continue
}
return
}
go func(n int, addr net.Addr) {
// 用 WriteTo 回包到指定地址
reply := []byte("ack:" + string(buf[:n]))
conn.WriteTo(reply, addr)
}(n, addr)
}
}
3.2 客户端：连接式 UDP
// 连接式 UDP：connect 后可以像流一样 Write/Read，但仍是数据报语义
conn, err := net.Dial("udp", "127.0.0.1:9000")
defer conn.Close()
conn.SetDeadline(time.Now().Add(2 * time.Second))
_, err = conn.Write([]byte("hello"))
if err != nil { /* UDP 写不报错不代表送达 */ }
// 收不到回包不一定是对方没回，也可能是网络丢包
n, err := conn.Read(buf)
if err != nil {
if ne, ok := err.(net.Error); ok && ne.Timeout() {
log.Println("udp read timeout, retry...")
}
}
3.3 UDP 应用层必须自建可靠性
□ UDP 不保证送达、不保证顺序、不保证不重复 —— 应用层自己重试与去重
□ 数据报有长度上限，超过 65507 字节要分片或改用 TCP
□ 大量小数据报场景下，连接式 UDP 比每包一次 SendTo 更高效
□ 心跳/探测/日志上报这类"可丢但要及时"的业务天然适合 UDP
一句话总结：UDP 是"无连接的数据报"，服务端用 ListenPacket 收发、客户端用连接式 Dial，可靠性（重试/去重/顺序）必须由应用层补齐。
4. 自定义协议与编解码
4.1 二进制协议：长度前缀 + 消息体
// 帧格式：4 字节大端长度 + 1 字节类型 + 消息体
const (
msgTypeRequest byte = 0x01
msgTypeResponse byte = 0x02
)
func writeFrame(w io.Writer, mtype byte, body []byte) error {
header := make([]byte, 5)
binary.BigEndian.PutUint32(header[:4], uint32(len(body)))
header[4] = mtype
if _, err := w.Write(header); err != nil {
return err
}
_, err := w.Write(body)
return err
}
func readFrame(r *bufio.Reader) (byte, []byte, error) {
header := make([]byte, 5)
if _, err := io.ReadFull(r, header); err != nil {
return 0, nil, err
}
length := binary.BigEndian.Uint32(header[:4])
mtype := header[4]
body := make([]byte, length)
if _, err := io.ReadFull(r, body); err != nil {
return 0, nil, err
}
return mtype, body, nil
}
长度前缀是解决 TCP 粘包/拆包的最可靠方案：先读固定长度的头拿到消息长度，再用 io.ReadFull 精确读满 body，任何一次 Read 返回都只是"进度"，框架保证拼接。
4.2 文本协议：行分隔 + bufio
func handleLineConn(conn net.Conn) {
defer conn.Close()
reader := bufio.NewReader(conn)
for {
line, err := reader.ReadString('\n')
if err != nil {
return
}
line = strings.TrimSpace(line)
fields := strings.Split(line, " ")
switch fields[0] {
case "PING":
fmt.Fprintln(conn, "PONG")
case "QUIT":
fmt.Fprintln(conn, "BYE")
return
default:
fmt.Fprintf(conn, "ERR unknown cmd %s\n", fields[0])
}
}
}
文本协议（如 Redis 的 RESP、HTTP 的请求行）可读性好、调试方便，但性能上限低于二进制协议——高吞吐场景要谨慎。
4.3 协议设计的六个原则
1. 帧边界必须明确：长度前缀或定界符，二者必居其一
2. 大小端与长度字段宽度全局统一（推荐大端）
3. 协议号/版本号字段留给演进，避免上线后无法升级
4. 长度字段设上限，防止恶意超大包打爆内存
5. 区分心跳帧与数据帧，长连接靠心跳保活
6. 序列化选型：JSON 简单、protobuf 高效、自研紧凑
一句话总结：自定义协议的精髓是"先定帧边界、再定字段布局、最后定序列化"，长度前缀 + 大端 + 版本字段是二进制协议的标准组合。
5. 事件驱动：Go runtime 的 epoll / kqueue 之谜
5.1 netpoller：io 多路复用藏在 runtime 里
Go 的 net 包底层并不做阻塞系统调用。每个文件描述符在首次 IO 时会被注册进 runtime 的 netpoller：
Linux → epoll_create + epoll_ctl + epoll_wait
macOS → kqueue + kevent
Windows → IOCP
当一个 goroutine 执行 conn.Read() 而暂时无数据时，netpoller 把它挂起并把 fd 注册进 epoll；当内核报告该 fd 可读，runtime 再把对应的 goroutine 唤醒——这就是"同步写、异步执行"的真相。
5.2 为什么每连接一个 goroutine 不爆炸
// 一个 goroutine 阻塞在 Read 上时，占用的只是栈内存（初始 2KB）
// 10 万个连接 ≈ 10 万 goroutine，每个暂停的 goroutine 不占 CPU
// 事件到达时只有就绪的 goroutine 被调度执行
for {
conn, err := ln.Accept()
go handleConn(conn) // 看似随意，实则是 O(1) 的事件回调
}
对比 C 语言手写 epoll：你要维护 fd → 回调函数 的映射表。Go 里这个映射由"goroutine 暂停位置"天然代替了——goroutine 就是事件回调，只是它写起来像线性代码。
5.3 GOMAXPROCS 与网络吞吐的相互作用
□ 网络 IO 不占用 GOMAXPROCS 的 P：阻塞在网络上的 goroutine 会主动让出 P
□ 所以"网络密集型"服务即使 GOMAXPROCS=8 也能并发处理海量连接
□ 瓶颈通常在 CPU 密集处理段：解析、加解密、业务计算
□ 观察手段：runtime 统计的 goroutine 数 vs 活跃 CPU 时间
一句话总结：Go 把 epoll/kqueue 内化进 runtime 的 netpoller，goroutine 取代了手写事件回调，这就是"每连接一 goroutine"能扛十万连接的底层原因。
6. 生产级网络服务的避坑清单
| 坑 | 现象 | 对策 |
|---|---|---|
| 忘记设置读写 Deadline | 死连接长期占资源 | SetDeadline / SetReadDeadline |
| Read 循环不处理粘包 | 协议解析错乱 | 长度前缀 + io.ReadFull |
| 一个连接一个 goroutine 且不控制上限 | 慢客户端拖垮服务 | 引入连接数限流、读写超时、backlog 控制 |
| TCP Keep-Alive 默认关闭 | 半开连接长期不释放 | Dialer.KeepAlive 设置探测间隔 |
| 忽略临时错误 | Accept 热循环空转 | net.Error 的 Temporary() 判断后 sleep |
| UDP 不做超时重试 | 丢包导致业务失败 | 应用层重试 + 序列号去重 |
| Write 未循环处理短写 | 数据丢失 | io.WriteString 或循环直到写完 |
| 监听的端口被占用未处理 | 启动即 panic | Listen 前探测或捕获 EADDRINUSE |
7. 总结
| 维度 | 方案 | 一句话要义 |
|---|---|---|
| 连接抽象 | net.Conn | 传输无关的统一读写与超时接口 |
| 服务端 | Listen + Accept + goroutine | 每连接一 goroutine，事件驱动由 runtime 承担 |
| 客户端 | net.Dial | 设置 Timeout 与 KeepAlive |
| TCP 协议 | 字节流 + 粘包处理 | 帧边界必须自定，长度前缀最可靠 |
| UDP 协议 | 数据报 + 应用层可靠性 | 重试/去重/顺序由业务层保证 |
| 事件驱动 | netpoller（epoll/kqueue/IOCP） | goroutine 即事件回调，同步写异步执行 |
| 可靠性 | Deadline + 心跳 + 限流 | 死连接、慢客户端、半开连接全部兜住 |
落地记住五件事：每个连接设置读写 Deadline、TCP 按帧解析不做流假设、UDP 应用层自建重试、限制连接数与 goroutine 总量、区分临时错误与致命错误。把"协议先行、超时兜底、事件驱动"想明白，Go 网络服务就能同时兼顾性能与健壮性。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。