第二章：网络编程基础——Socket编程原理、TCP与UDP在交易系统中的应用、非阻塞IO与事件驱动模型
各位同学，大家好。我是你们的老朋友，一个在量化交易系统里摸爬滚打了十几年的老兵。今天咱们聊点硬核的——网络编程基础。
你可能会问：“我一个做策略的，学这个干嘛？” 嗯，我当年也这么想。直到有一次，我写的策略因为网络延迟高了5毫秒，眼睁睁看着套利机会溜走。那一刻我才明白：交易系统的命脉，就是网络。
说白了，你的策略再牛，如果数据传不过来，或者指令发不出去，那就是一堆废纸。所以，这一章我们就把网络编程的底裤扒干净。
核心观点： 交易系统对网络的要求，就三个字——快、稳、准。Socket编程是实现这一切的基石。
2.1 Socket编程原理：你家的“快递员”
Socket，中文叫“套接字”。名字挺拗口，但你可以把它想象成一个快递员。你的程序（比如交易客户端）想跟另一个程序（比如交易所服务器）通信，就得找个快递员来跑腿。
这个快递员怎么工作？流程其实很简单：
- 创建快递员（socket()）：告诉系统，我要一个快递员，用IPv4还是IPv6？用TCP还是UDP？
- 绑定地址（bind()）：给快递员一个固定的工位（IP地址+端口号）。服务器端必须做这一步，客户端通常可以省略。
- 监听（listen()）：快递员开始上班，等着客户上门。这一步只有TCP需要，UDP不需要。
- 接受连接（accept()）：有客户来了，快递员接单，建立一条专属通道。同样，只有TCP需要。
- 收发数据（send()/recv()）：开始干活，把数据包发出去或收进来。
- 关闭（close()）：下班，释放资源。
我个人习惯把Socket比作“管道”。TCP是根铁管，数据流过去，顺序不乱；UDP是根塑料管，数据包可能乱序，甚至丢失。你想想看，交易系统里能用塑料管吗？
避坑指南： 我曾经在开发一个高频行情网关时，忘记在服务器端调用bind()之前设置SO_REUSEADDR选项。结果程序崩溃重启后，端口被占用，系统直接挂了。记住：setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt)) 这行代码，能救你的命。
2.2 TCP与UDP：交易系统的“左膀右臂”
TCP和UDP，就像交易系统的两条腿。一条稳健，一条轻快。但你不能瘸着走路。
| 特性 | TCP | UDP |
|---|---|---|
| 连接方式 | 面向连接（三次握手） | 无连接 |
| 可靠性 | 可靠传输，保证顺序 | 不可靠，可能丢包、乱序 |
| 延迟 | 较高（有确认重传机制） | 极低（只管发，不管到） |
| 适用场景 | 交易指令、订单状态 | 行情数据、心跳包 |
为什么交易指令要用TCP？因为指令丢了，可能造成几十万的损失。为什么行情数据可以用UDP？因为行情更新极快，丢一两个包无所谓，下一笔马上就到。说白了，TCP保命，UDP保速度。
我记得有一次，一个团队用UDP传交易指令，结果网络抖动丢了一个包，订单没成交，客户投诉到半夜。后来他们改回TCP，虽然慢了几微秒，但再也没出过事。
警告： 千万别在UDP上自己实现可靠传输协议！我见过太多人掉进这个坑。除非你是网络协议专家，否则直接用TCP。UDP的“不可靠”是设计哲学，不是bug。
2.3 非阻塞IO与事件驱动模型：让CPU不再“傻等”
传统的阻塞IO是什么？就像你打电话，对方不接，你就一直举着手机干等。CPU也是这样，调用recv()后，如果没有数据，它就傻傻地等着，啥也不干。
这在交易系统里是致命的。你想想看，行情数据每秒几十万笔，CPU如果花时间在“等待”上，那延迟就上去了。
解决方案就是非阻塞IO。设置socket为非阻塞模式后，调用recv()时，如果有数据就返回数据，没数据就立刻返回一个错误码（比如EAGAIN）。CPU不用等，可以继续干别的活。
但问题来了：你怎么知道什么时候有数据？总不能一直轮询吧？那更浪费CPU。
这时候就需要事件驱动模型。常见的实现有select、poll、epoll（Linux）和IOCP（Windows）。
我个人最常用的是epoll。它的原理很简单：你告诉内核，“我对这个socket的读事件感兴趣”。当socket上有数据到达时，内核主动通知你。你只需要处理那些“有事件”的socket，不用管那些空闲的。
来看一段伪代码，感受一下：
// 创建epoll实例
int epfd = epoll_create(1);
// 把行情socket加入epoll监听
struct epoll_event ev;
ev.events = EPOLLIN; // 监听读事件
ev.data.fd = market_sock;
epoll_ctl(epfd, EPOLL_CTL_ADD, market_sock, &ev);
// 事件循环
while (1) {
struct epoll_event events[1024];
int n = epoll_wait(epfd, events, 1024, -1); // 等待事件
for (int i = 0; i < n; i++) {
if (events[i].events & EPOLLIN) {
// 有行情数据来了，赶紧处理
handle_market_data(events[i].data.fd);
}
}
}你看，CPU不再傻等了。它只在有数据的时候才干活，其他时间可以处理别的任务，比如计算策略信号。
核心要点： 非阻塞IO + 事件驱动 = 高并发、低延迟。这是所有高性能交易系统的标配。我见过最快的行情网关，单机处理百万级消息/秒，用的就是epoll。
2.4 实战中的“坑”与“道”
理论讲完了，咱们聊聊实战。我踩过的坑，你们就别再踩了。
- 缓冲区大小：TCP有发送缓冲区和接收缓冲区。默认值通常只有几十KB。对于高频交易，建议调大。我一般设到1MB以上。用
setsockopt()设置SO_SNDBUF和SO_RCVBUF。 - Nagle算法：TCP默认开启Nagle算法，它会合并小数据包再发送。这对交易系统是灾难，因为延迟会增加。记得用
setsockopt()设置TCP_NODELAY，禁用Nagle。 - 惊群效应：多线程同时调用epoll_wait()时，一个事件会唤醒所有线程，但只有一个能处理。这就是惊群。解决方案是用EPOLLEXCLUSIVE标志（Linux 4.5+），或者用SO_REUSEPORT让内核做负载均衡。
我曾经在一个项目中，因为没禁用Nagle算法，导致交易指令延迟从100微秒飙升到5毫秒。排查了整整两天，最后发现是这么个小问题。嗯，从那以后，我写网络代码的第一件事就是关Nagle。
2.5 一张图看懂本章知识体系
说了这么多，咱们用一张图来总结一下。这张图展示了Socket编程、TCP/UDP、非阻塞IO和事件驱动模型之间的关系。
这张图把本章的核心内容串起来了。Socket是基础，TCP和UDP是两种传输方式，非阻塞IO和事件驱动是提升性能的关键。你想想看，没有这些，交易系统根本跑不起来。
个人建议： 初学者可以先从阻塞IO + 多线程开始，理解Socket的基本用法。然后逐步过渡到非阻塞IO + epoll。不要一上来就搞复杂模型，容易把自己绕晕。
好了，这一章就到这里。网络编程是交易系统的“血管”，必须扎实。下一章我们会深入协议解析，看看数据到了之后怎么处理。但今天的内容，够你消化一阵子了。
公众号:蓝海资料掘金营，微信deep3321