Linux多线程服务端编程:使用muduo C++网络库

1.11.2 弱回调24
1.12 替代方案26
1.13 心得与小结26
1.14 Observer 之谬28
第2 章线程同步精要31
2.1 互斥器（mutex） 32
2.1.1 只使用非递归的mutex 33
2.1.2 死锁35
2.2 条件变量（condition variable） 40
2.3 不要用读写锁和信号量43
2.4 封装MutexLock、MutexLockGuard、Condition 44
2.5 线程安全的Singleton 实现48
2.6 sleep(3) 不是同步原语50
2.7 归纳与总结51
2.8 借shared_ptr 实现copy-on-write 52
第3 章多线程服务器的适用场合与常用编程模型59
3.1 进程与线程59
3.2 单线程服务器的常用编程模型61
3.3 多线程服务器的常用编程模型62
3.3.1 one loop per thread 62
3.3.2 线程池63
3.3.3 推荐模式64
3.4 进程间通信只用TCP 65
3.5 多线程服务器的适用场合67
3.5.1 必须用单线程的场合69
3.5.2 单线程程序的优缺点70
3.5.3 适用多线程程序的场景71
3.6 “多线程服务器的适用场合”例释与答疑74
第4 章C++ 多线程系统编程精要83
4.1 基本线程原语的选用84
4.2 C/C++ 系统库的线程安全性85
4.3 Linux 上的线程标识89
4.4 线程的创建与销毁的守则91
4.4.1 pthread_cancel 与C++ 94
4.4.2 exit(3) 在C++ 中不是线程安全的94
4.5 善用__thread 关键字96
4.6 多线程与IO 98
4.7 用RAII 包装文件描述符99
4.8 RAII 与fork() 101
4.9 多线程与fork() 102
4.10 多线程与signal 103
4.11 Linux 新增系统调用的启示105
第5 章高效的多线程日志107
5.1 功能需求109
5.2 性能需求112
5.3 多线程异步日志114
5.4 其他方案120
第2 部分muduo 网络库123
第6 章muduo 网络库简介125
6.1 由来125
6.2 安装127
6.3 目录结构129
6.3.1 代码结构131
6.3.2 例子134
6.3.3 线程模型135
6.4 使用教程136
6.4.1 TCP 网络编程本质论136
6.4.2 echo 服务的实现138
6.4.3 七步实现finger 服务140
6.5 性能评测144
6.5.1 muduo 与Boost.Asio、libevent2 的吞吐量对比145
6.5.2 击鼓传花：对比muduo 与libevent2 的事件处理效率148
6.5.3 muduo 与Nginx 的吞吐量对比153
6.5.4 muduo 与ZeroMQ 的延迟对比156
6.6 详解muduo 多线程模型157
6.6.1 数独求解服务器157
6.6.2 常见的并发网络服务程序设计方案160
第7 章muduo 编程示例177
7.1 五个简单TCP 示例178
7.2 文件传输185
7.3 Boost.Asio 的聊天服务器194
7.3.1 TCP 分包194
7.3.2 消息格式195
7.3.3 编解码器LengthHeaderCodec 197
7.3.4 服务端的实现198
7.3.5 客户端的实现200
7.4 muduo Buffer 类的设计与使用204
7.4.1 muduo 的IO 模型204
7.4.2 为什么non-blocking 网络编程中应用层buffer 是必需的205
7.4.3 Buffer 的功能需求207
7.4.4 Buffer 的数据结构209
7.4.5 Buffer 的操作211
7.4.6 其他设计方案217
7.4.7 性能是不是问题218
7.5 一种自动反射消息类型的Google Protobuf 网络传输方案220
7.5.1 网络编程中使用Protobuf 的两个先决条件220
7.5.2 根据type name 反射自动创建Message 对象221
7.5.3 Protobuf 传输格式226
7.6 在muduo 中实现Protobuf 编解码器与消息分发器228
7.6.1 什么是编解码器（codec） 229
7.6.2 实现ProtobufCodec 232
7.6.3 消息分发器（dispatcher）有什么用232
7.6.4 ProtobufCodec 与ProtobufDispatcher 的综合运用233
7.6.5 ProtobufDispatcher 的两种实现234
7.6.6 ProtobufCodec 和ProtobufDispatcher 有何意义236
7.7 限制服务器的最大并发连接数237
7.7.1 为什么要限制并发连接数237
7.7.2 在muduo 中限制并发连接数238
7.8 定时器240
7.8.1 程序中的时间240
7.8.2 Linux 时间函数241
7.8.3 muduo 的定时器接口242
7.8.4 Boost.Asio Timer 示例243
7.8.5 Java Netty 示例245
7.9 测量两台机器的网络延迟和时间差248
7.10 用timing wheel 踢掉空闲连接250
7.10.1 timing wheel 原理251
7.10.2 代码实现与改进254
7.11 简单的消息广播服务257
7.12 “串并转换”连接服务器及其自动化测试260
7.13 socks4a 代理服务器264
7.13.1 TCP 中继器264
7.13.2 socks4a 代理服务器267
7.13.3 N : 1 与1 : N 连接转发267
7.14 短址服务267
7.15 与其他库集成268
7.15.1 UDNS 270
7.15.2 c-ares DNS 272
7.15.3 curl 273
7.15.4 更多275
第8 章muduo 网络库设计与实现277
8.0 什么都不做的EventLoop 277
8.1 Reactor 的关键结构280
8.1.1 Channel class 280
8.1.2 Poller class 283
8.1.3 EventLoop 的改动287
8.2 TimerQueue 定时器290
8.2.1 TimerQueue class 290
8.2.2 EventLoop 的改动292
8.3 EventLoop::runInLoop() 函数293
8.3.1 提高TimerQueue 的线程安全性296
8.3.2 EventLoopThread class 297
8.4 实现TCP 网络库299
8.5 TcpServer 接受新连接303
8.5.1 TcpServer class 304
8.5.2 TcpConnection class 305
8.6 TcpConnection 断开连接308
8.7 Buffer 读取数据313
8.7.1 TcpConnection 使用Buffer 作为输入缓冲314
8.7.2 Buffer::readFd() 315
8.8 TcpConnection 发送数据316
8.9 完善TcpConnection 320
8.9.1 SIGPIPE 321
8.9.2 TCP No Delay 和TCP keepalive 321
8.9.3 WriteCompleteCallback 和HighWaterMarkCallback 322
8.10 多线程TcpServer 324
8.11 Connector 327
8.12 TcpClient 332
8.13 epoll 333
8.14 测试程序一览336
第3 部分工程实践经验谈337
第9 章分布式系统工程实践339
9.1 我们在技术浪潮中的位置341
9.1.1 分布式系统的本质困难343
9.1.2 分布式系统是个险恶的问题344
9.2 分布式系统的可靠性浅说349
9.2.1 分布式系统的软件不要求7 24 可靠352
9.2.2 “能随时重启进程”作为程序设计目标354
9.3 分布式系统中心跳协议的设计356
9.4 分布式系统中的进程标识360
9.4.1 错误做法361
9.4.2 正确做法362
9.4.3 TCP 协议的启示363
9.5 构建易于维护的分布式程序364
9.6 为系统演化做准备367
9.6.1 可扩展的消息格式368
9.6.2 反面教材：ICE 的消息打包格式369
9.7 分布式程序的自动化回归测试370
9.7.1 单元测试的能与不能370
9.7.2 分布式系统测试的要点373
9.7.3 分布式系统的抽象观点374
9.7.4 一种自动化的回归测试方案375
9.7.5 其他用处379
9.8 分布式系统部署、监控与进程管理的几重境界380
9.8.1 境界1：全手工操作382
9.8.2 境界2：使用零散的自动化脚本和第三方组件383
9.8.3 境界3：自制机群管理系统，集中化配置386
9.8.4 境界4：机群管理与naming service 结合389
第10 章C++ 编译链接模型精要391
10.1 C 语言的编译模型及其成因394
10.1.1 为什么C 语言需要预处理395
10.1.2 C 语言的编译模型398
10.2 C++ 的编译模型399
10.2.1 单遍编译399
10.2.2 前向声明402
10.3 C++ 链接（linking） 404
10.3.1 函数重载406
10.3.2 inline 函数407
10.3.3 模板409
10.3.4 虚函数414
10.4 工程项目中头文件的使用规则415
10.4.1 头文件的害处416
10.4.2 头文件的使用规则417
10.5 工程项目中库文件的组织原则418
10.5.1 动态库是有害的423
10.5.2 静态库也好不到哪儿去424
10.5.3 源码编译是王道428
第11 章反思C++ 面向对象与虚函数429
11.1 朴实的C++ 设计429
11.2 程序库的二进制兼容性431
11.2.1 什么是二进制兼容性432
11.2.2 有哪些情况会破坏库的ABI 433
11.2.3 哪些做法多半是安全的435
11.2.4 反面教材：COM 435
11.2.5 解决办法436
11.3 避免使用虚函数作为库的接口436
11.3.1 C++ 程序库的作者的生存环境437
11.3.2 虚函数作为库的接口的两大用途438
11.3.3 虚函数作为接口的弊端439
11.3.4 假如Linux 系统调用以COM 接口方式实现442
11.3.5 Java 是如何应对的443
11.4 动态库接口的推荐做法443
11.5 以boost::function 和boost::bind 取代虚函数447
11.5.1 基本用途450
11.5.2 对程序库的影响451
11.5.3 对面向对象程序设计的影响453
11.6 iostream 的用途与局限457
11.6.1 stdio 格式化输入输出的缺点457
11.6.2 iostream 的设计初衷461
11.6.3 iostream 与标准库其他组件的交互463
11.6.4 iostream 在使用方面的缺点464
11.6.5 iostream 在设计方面的缺点468
11.6.6 一个300 行的memory buffer output stream 476
11.6.7 现实的C++ 程序如何做文件IO 480
11.7 值语义与数据抽象482
11.7.1 什么是值语义482
11.7.2 值语义与生命期483
11.7.3 值语义与标准库488
11.7.4 值语义与C++ 语言488
11.7.5 什么是数据抽象490
11.7.6 数据抽象所需的语言设施493
11.7.7 数据抽象的例子495
第12 章C++ 经验谈501
12.1 用异或来交换变量是错误的501
12.1.1 编译器会分别生成什么代码503
12.1.2 为什么短的代码不一定快505
12.2 不要重载全局::operator new() 507
12.2.1 内存管理的基本要求507
12.2.2 重载::operator new() 的理由508
12.2.3 ::operator new() 的两种重载方式508
12.2.4 现实的开发环境509
12.2.5 重载::operator new() 的困境510
12.2.6 解决办法：替换malloc() 512
12.2.7 为单独的class 重载::operator new() 有问题吗513
12.2.8 有必要自行定制内存分配器吗513
12.3 带符号整数的除法与余数514
12.3.1 语言标准怎么说515
12.3.2 C/C++ 编译器的表现516
12.3.3 其他语言的规定516
12.3.4 脚本语言解释器代码517
12.3.5 硬件实现521
12.4 在单元测试中mock 系统调用522
12.4.1 系统函数的依赖注入522
12.4.2 链接期垫片（link seam） 524
12.5 慎用匿名namespace 526
12.5.1 C 语言的static 关键字的两种用法526
12.5.2 C++ 语言的static 关键字的四种用法526
12.5.3 匿名namespace 的不利之处527
12.5.4 替代办法529
12.6 采用有利于版本管理的代码格式529
12.6.1 对diff 友好的代码格式530
12.6.2 对grep 友好的代码风格537
12.6.3 一切为了效率538
12.7 再探std::string 539
12.7.1 直接拷贝（eager copy） 540
12.7.2 写时复制（copy-on-write） 542
12.7.3 短字符串优化（SSO） 543
12.8 用STL algorithm 轻松解决几道算法面试题546
12.8.1 用next_permutation() 生成排列与组合546
12.8.2 用unique() 去除连续重复空白548
12.8.3 用{make,push,pop}_heap() 实现多路归并549
12.8.4 用partition() 实现“重排数组，让奇数位于偶数前面” 553
12.8.5 用lower_bound() 查找IP 地址所属的城市554
第4 部分附录559
附录A 谈一谈网络编程学习经验561
附录B 从《C++ Primer（第4 版）》入手学习C++ 579
附录C 关于Boost 的看法591
附录D 关于TCP 并发连接的几个思考题与试验593
参考文献599

.　　本书假定读者熟悉diff -u 命令的输出格式，用于表示代码的改动。
　　本书正文中出现的代码有时为了照顾排版而略有改写，例如改变缩进规则，去掉单行条件语句前后的花括号等。就编程风格而论，应以电子版代码为准。
　　联系方式
　　邮箱：giantchen@gmail.com
　　主页：http://chenshuo.com/book （正文和脚注中出现的URL 可从这里找到。）
　　微博：http://weibo.com/giantchen
　　博客：http://blog.csdn.net/Solstice
　　代码：http://github.com/chenshuo
　　陈硕
　　中国香港
　　

.　　两次Sockets API，其他时候都是使用封装好的网络库。
　　第一次是2005 年在学校做一个羽毛球赛场计分系统：我用C# 编写运行在PC上的软件，负责比分的显示；再用C# 写了运行在PDA 上的计分界面，记分员拿着PDA 记录比分；这两部分程序通过TCP 协议相互通信。这其实是个简单的分布式系统，体育馆有几片场地，每个场地都有一名拿PDA 的记分员，每个场地都有两台显示比分的PC （显示器是42 寸平板电视，放在场地的对角，这样两边看台的观众都能看到比分）。这两台PC 的功能不完全一样，一台只负责显示当前比分，另一台还要负责与PDA 通信，并更新数据库里的比分信息。此外，还有一台PC 负责周期性地从数据库读出全部7 片场地的比分，显示在体育馆墙上的大屏幕上。这台PC 上还运行着一个程序，负责生成比分数据的静态页面，通过FTP 上传发布到某门户网站的体育频道。系统中还有一个录入赛程（参赛队、运动员、出场顺序等）数据库的程序，运行在数据库服务器上。算下来整个系统有十来个程序，运行在二十多台设备（PC 和PDA）上，还要考虑可靠性，避免single point of failure。
　　这是我第一次写实际项目中的网络程序，当时写下来的感觉是像写命令行与用户交互的程序：程序在命令行输出一句提示语，等待客户输入一句话，然后处理客户输入，再输出下一句提示语，如此循环。只不过这里的“客户”不是人，而是另一个程序。在建立好TCP 连接之后，双方的程序都是read/write 循环（为求简单，我用的是blocking 读写），直到有一方断开连接。
　　第二次是2010 年编写mudu网络库，我再次拿起了Sockets API，写了一个基于Reactor 模式的C++ 网络库。写这个库的目的之一就是想让日常的网络编程从Sockets API 的琐碎细节中解脱出来，让程序员专注于业务逻辑，把时间用在刀刃上。mudu网络库的示例代码包含了几十个网络程序，这些示例程序都没有直接使用Sockets API。
　　在此之外，无论是实习还是工作，虽然我写的程序都会通过TCP 协议与其他程序打交道，但我没有直接使用过Sockets API。对于TCP 网络编程，我认为核心是处理“三个半事件”，见§6.4.1 “TCP 网络编程本质论”。程序员的主要工作是在事件处理函数中实现业务逻辑，而不是和Sockets API“较劲”。
　　这里还是没有说清楚“网络编程”是什么，请继续阅读后文§A.1.5“网络编程的各种任务角色”。
　　A.1.2 学习网络编程有用吗
　　以上说的是比较底层的网络编程，程序代码直接面对从TCP 或UDP 收到的数据以及构造数据包发出去。在实际工作中，另一种常见的情况是通过各种client library来与服务端打交道，或者在现成的框架中填空来实现server，或者采用更上层的通信方式。比如用libmemcached 与memcached 打交道，使用libpq 来与PostgreSQL 打交道，编写Servlet 来响应HTTP 请求，使用某种RPC 与其他进程通信，等等。这些情况都会发生网络通信，但不一定算作“网络编程”。如果你的工作是前面列举的这些，学习TCP/IP 网络编程还有用吗？
　　我认为还是有必要学一学，至少在troubleshooting 的时候有用。无论如何，这些library 或framework 都会调用底层的Sockets API 来实现网络功能。当你的程序遇到一个线上问题时，如果你熟悉Sockets API，那么从strace 不难发现程序卡在哪里，尽管可能你没有直接调用这些Sockets API。另外，熟悉TCP/IP 协议、会用tcpdump 也非常有助于分析解决线上网络服务问题。
　　A.1.3 在什么平台上学习网络编程
　　对于服务端网络编程，我建议在Linux 上学习。
　　如果在10 年前，这个问题的答案或许是FreeBSD，因为FreeBSD“根正苗红”，在2000 年那一次互联网浪潮中扮演了重要角色，是很多公司首选的免费服务器操作系统。2000 年那会儿Linux 还远未成熟，连epoll 都还没有实现。（FreeBSD 在2001年发布4.1 版，加入了kqueue，从此C10k 不是问题。）
　　10 年后的今天，事情起了一些变化，Linux 成为市场份额最大的服务器操作系统。在Linux 这种大众系统上学网络编程，遇到什么问题会比较容易解决。因为用的人多，你遇到的问题别人多半也遇到过；同样因为用的人多，如果真的有什么内核bug，很快就会得到修复，至少有work around 的办法。如果用别的系统，可能一个问题发到论坛上半个月都不会有人理。从内核源码的风格看，FreeBSD 更干净整洁，注释到位，但是无奈它的市场份额远不如Linux，学习Linux 是更好的技术投资。
　　A.1.4 可移植性重要吗
　　写网络程序要不要考虑移植性？要不要跨平台？这取决于项目需要，如果贵公司做的程序要卖给其他公司，而对方可能使用Windows、Linux、FreeBSD、Solaris、AIX、HP-UX 等等操作系统，这时候当然要考虑移植性。如果编写公司内部的服务器上用的网络程序，那么大可只关注一个平台，比如Linux。因为编写和维护可移植的网络程序的代价相当高，平台间的差异可能远比想象中大，即便是POSIX 系统之间也有不小的差异（比如Linux 没有SO_NOSIGPIPE 选项，Linux 的pipe（2） 是单向的，而FreeBSD 是双向的），错误的返回码也大不一样。
　　我就不打算把mudu往Windows 或其他操作系统移植。如果需要编写可移植的网络程序，我宁愿用libevent、libuv、Java Netty 这样现成的库，把“脏活、累活”留给别人。
　　A.1.5 网络编程的各种任务角色
　　计算机网络是个big topic，涉及很多人物和角色，既有开发人员，也有运维人员。比方说：公司内部两台机器之间ping 不通，通常由网络运维人员解决，看看是布线有问题还是路由器设置不对；两台机器能ping 通，但是程序连不上，经检查是本机防火墙设置有问题，通常由系统管理员解决；两台机器能连上，但是丢包很严重，发现是网卡或者交换机的网口故障，由硬件维修人员解决；两台机器的程序能连上，但是偶尔发过去的请求得不到响应，通常是程序bug，应该由开发人员解决。
　　本文主要关心开发人员这一角色。下面简单列出一些我能想到的跟网络打交道的编程任务，其中前三项是面向网络本身，后面几项是在计算机网络之上构建信息系统。
　　1. 开发网络设备，编写防火墙、交换机、路由器的固件（firmware）。
　　2. 开发或移植网卡的驱动。
　　3. 移植或维护TCP/IP 协议栈（特别是在嵌入式系统上）。
　　4. 开发或维护标准的网络协议程序，HTTP、FTP、DNS、SMTP、POP3、NFS。
　　5. 开发标准网络协议的“附加品”，比如HAProxy、squid、varnish 等Web loadbalancer。
　　6. 开发标准或非标准网络服务的客户端库，比如ZooKeeper 客户端库、memcached客户端库。
　　7. 开发与公司业务直接相关的网络服务程序，比如即时聊天软件的后台服务器、网游服务器、金融交易系统、互联网企业用的分布式海量存储、微博发帖的内部广播通知等等。
　　8. 客户端程序中涉及网络的部分，比如邮件客户端中与POP3、SMTP 通信的部分，以及网游的客户端程序中与服务器通信的部分。
　　本文所指的“网络编程”专指第7 项，即在TCP/IP 协议之上开发业务软件。换句话说，不是用Sockets API 开发mudu这样的网络库，而是用libevent、muduo、Netty、gevent 这样现成的库开发业务软件，mudu自带的十几个示例程序是业务软件的代表。
　　A.1.6 面向业务的网络编程的特点
　　与通用的网络服务器不同，面向公司业务的专用网络程序有其自身的特点。
　　业务逻辑比较复杂，而且时常变化 如果写一个HTTP 服务器，在大致实现HTTP 1.1 标准之后，程序的主体功能一般不会有太大的变化，程序员会把时间放在性能调优和bug 修复上。而开发针对公司业务的专用程序时，功能说明书（spec）很可能不如HTTP 1.1 标准那么细致明确。更重要的是，程序是快速演化的。以即时聊天工具的后台服务器为例，可能第一版只支持在线聊天；几个月之后发布第二版，支持离线消息；又过了几个月，第三版支持隐身聊天；随后，第四版支持上传头像；如此等等。这要求程序员能快速响应新的业务需求，公司才能保持竞争力。由于业务时常变化（假设每月一次版本升级），也会降低服务程序连续运行时间的要求。相反，我们要设计一套流程，通过轮流重启服务器来完成平滑升级（§9.2.2）。
　　不一定需要遵循公认的通信协议标准 比方说网游服务器就没什么协议标准，反正客户端和服务端都是本公司开发的，如果发现目前的协议设计有问题，两边一起改就行了。由于可以自己设计协议，因此我们可以绕开一些性能难点，简化程序结构。比方说，对于多线程的服务程序，如果用短连接TCP 协议，为了优化性能通常要精心设计accept 新连接的机制2，避免惊群并减少上下文切换。但是如果改用长连接，用最简单的单线程accept 就行了。
　　程序结构没有定论 对于高并发大吞吐的标准网络服务，一般采用单线程事件驱动的方式开发，比如HAProxy、lighttpd 等都是这个模式。但是对于专用的业务系统，其业务逻辑比较复杂，占用较多的CPU 资源，这种单线程事件驱动方式不见得能发挥现在多核处理器的优势。这留给程序员比较大的自由发挥空间，做好了“横扫千军”，做烂了一败涂地。我认为目前one loop per thread 是通用性较高的一种程序结构，能发挥多核的优势，见§3.3 和§6.6。
　　性能评判的标准不同 如果开发httpd 这样的通用服务，必然会和开源的Nginx、lighttpd 等高性能服务器比较，程序员要投入相当的精力去优化程序，才能在市场上占有一席之地。而面向业务的专用网络程序不一定是Ibound，也不一定有开源的实现以供对比性能，优化方向也可能不同。程序员通常更加注重功能的稳定性与开发的便捷性。性能只要一代比一代强即可。
　　网络编程起到支撑作用，但不处于主导地位 程序员的主要工作是实现业务逻辑，而不只是实现网络通信协议。这要求程序员深入理解业务。程序的性能瓶颈不一定在网络上，瓶颈有可能是CPU、Disk IO、数据库等，这时优化网络方面的代码并不能提高整体性能。只有对所在的领域有深入的了解，明白各种因素的权衡（trade-off），才能做出一些有针对性的优化。现在的机器上，简单的并发长连接echo服务程序不用特别优化就做到十多万qps，但是如果每个业务请求需要1ms 密集计算，在8 核机器上充其量能达到8 000 qps，优化I不如去优化业务计算（如果投入产出合算的话）。
　　A.1.7 几个术语
　　互联网上的很多“口水战”是由对同一术语的不同理解引起的，比如我写的《多线程服务器的适用场合》3，就曾经被人说是“挂羊头卖狗肉”，因为这篇文章中举的master 例子“根本就算不上是个网络服务器。因为它的瓶颈根本就跟网络无关。”
　　网络服务器 “网络服务器”这个术语确实含义模糊，到底指硬件还是软件？到底是服务于网络本身的机器（交换机、路由器、防火墙、NAT），还是利用网络为其他人或程序提供服务的机器（打印服务器、文件服务器、邮件服务器）？每个人根据自己熟悉的领域，可能会有不同的解读。比方说，或许有人认为只有支持高并发、高吞吐量的才算是网络服务器。
　　为了避免无谓的争执，我只用“网络服务程序”或者“网络应用程序”这种含义明确的术语。“开发网络服务程序”通常不会造成误解。
　　客户端？服务端？ 在TCP 网络编程中，客户端和服务端很容易区分，主动发起连接的是客户端，被动接受连接的是服务端。当然，这个“客户端”本身也可能是个后台服务程序，HTTP proxy 对HTTP server 来说就是个客户端。
　　客户端编程？服务端编程？ 但是“服务端编程”和“客户端编程”就不那么好区分了。比如Web crawler，它会主动发起大量连接，扮演的是HTTP 客户端的角色，但似乎应该归入“服务端编程”。又比如写一个HTTP proxy，它既会扮演服务端--被动接受Web browser 发起的连接，也会扮演客户端--主动向HTTP server 发起连接，它究竟算服务端还是客户端？我猜大多数人会把它归入服务端编程。
　　那么究竟如何定义“服务端编程”？
　　服务端编程需要处理大量并发连接？也许是，也许不是。比如云风在一篇介绍网游服务器的博客4 中就谈到，网游中用到的“连接服务器”需要处理大量连接，而“逻辑服务器”只有一个外部连接。那么开发这种网游“逻辑服务器”算服务端编程还是客户端编程呢？又比如机房的服务进程监控软件，并发数跟机器数成正比，至多也就是两三千的并发连接。（再大规模就超出本书的范围了。）
　　我认为，“服务端网络编程”指的是编写没有用户界面的长期运行的网络程序，程序默默地运行在一台服务器上，通过网络与其他程序打交道，而不必和人打交道。与之对应的是客户端网络程序，要么是短时间运行，比如wget；要么是有用户界面（无论是字符界面还是图形界面）。本文主要谈服务端网络编程。
　　……
　　
　　

.　　两次Sockets API，其他时候都是使用封装好的网络库。
　　第一次是2005 年在学校做一个羽毛球赛场计分系统：我用C# 编写运行在PC上的软件，负责比分的显示；再用C# 写了运行在PDA 上的计分界面，记分员拿着PDA 记录比分；这两部分程序通过TCP 协议相互通信。这其实是个简单的分布式系统，体育馆有几片场地，每个场地都有一名拿PDA 的记分员，每个场地都有两台显示比分的PC （显示器是42 寸平板电视，放在场地的对角，这样两边看台的观众都能看到比分）。这两台PC 的功能不完全一样，一台只负责显示当前比分，另一台还要负责与PDA 通信，并更新数据库里的比分信息。此外，还有一台PC 负责周期性地从数据库读出全部7 片场地的比分，显示在体育馆墙上的大屏幕上。这台PC 上还运行着一个程序，负责生成比分数据的静态页面，通过FTP 上传发布到某门户网站的体育频道。系统中还有一个录入赛程（参赛队、运动员、出场顺序等）数据库的程序，运行在数据库服务器上。算下来整个系统有十来个程序，运行在二十多台设备（PC 和PDA）上，还要考虑可靠性，避免single point of failure。
　　这是我第一次写实际项目中的网络程序，当时写下来的感觉是像写命令行与用户交互的程序：程序在命令行输出一句提示语，等待客户输入一句话，然后处理客户输入，再输出下一句提示语，如此循环。只不过这里的“客户”不是人，而是另一个程序。在建立好TCP 连接之后，双方的程序都是read/write 循环（为求简单，我用的是blocking 读写），直到有一方断开连接。
　　第二次是2010 年编写muduo 网络库，我再次拿起了Sockets API，写了一个基于Reactor 模式的C++ 网络库。写这个库的目的之一就是想让日常的网络编程从Sockets API 的琐碎细节中解脱出来，让程序员专注于业务逻辑，把时间用在刀刃上。muduo 网络库的示例代码包含了几十个网络程序，这些示例程序都没有直接使用Sockets API。
　　在此之外，无论是实习还是工作，虽然我写的程序都会通过TCP 协议与其他程序打交道，但我没有直接使用过Sockets API。对于TCP 网络编程，我认为核心是处理“三个半事件”，见§6.4.1 “TCP 网络编程本质论”。程序员的主要工作是在事件处理函数中实现业务逻辑，而不是和Sockets API“较劲”。
　　这里还是没有说清楚“网络编程”是什么，请继续阅读后文§A.1.5“网络编程的各种任务角色”。
　　A.1.2 学习网络编程有用吗
　　以上说的是比较底层的网络编程，程序代码直接面对从TCP 或UDP 收到的数据以及构造数据包发出去。在实际工作中，另一种常见的情况是通过各种client library来与服务端打交道，或者在现成的框架中填空来实现server，或者采用更上层的通信方式。比如用libmemcached 与memcached 打交道，使用libpq 来与PostgreSQL 打交道，编写Servlet 来响应HTTP 请求，使用某种RPC 与其他进程通信，等等。这些情况都会发生网络通信，但不一定算作“网络编程”。如果你的工作是前面列举的这些，学习TCP/IP 网络编程还有用吗？
　　我认为还是有必要学一学，至少在troubleshooting 的时候有用。无论如何，这些library 或framework 都会调用底层的Sockets API 来实现网络功能。当你的程序遇到一个线上问题时，如果你熟悉Sockets API，那么从strace 不难发现程序卡在哪里，尽管可能你没有直接调用这些Sockets API。另外，熟悉TCP/IP 协议、会用tcpdump 也非常有助于分析解决线上网络服务问题。
　　A.1.3 在什么平台上学习网络编程
　　对于服务端网络编程，我建议在Linux 上学习。
　　如果在10 年前，这个问题的答案或许是FreeBSD，因为FreeBSD“根正苗红”，在2000 年那一次互联网浪潮中扮演了重要角色，是很多公司首选的免费服务器操作系统。2000 年那会儿Linux 还远未成熟，连epoll 都还没有实现。（FreeBSD 在2001年发布4.1 版，加入了kqueue，从此C10k 不是问题。）
　　10 年后的今天，事情起了一些变化，Linux 成为市场份额最大的服务器操作系统。在Linux 这种大众系统上学网络编程，遇到什么问题会比较容易解决。因为用的人多，你遇到的问题别人多半也遇到过；同样因为用的人多，如果真的有什么内核bug，很快就会得到修复，至少有work around 的办法。如果用别的系统，可能一个问题发到论坛上半个月都不会有人理。从内核源码的风格看，FreeBSD 更干净整洁，注释到位，但是无奈它的市场份额远不如Linux，学习Linux 是更好的技术投资。
　　A.1.4 可移植性重要吗
　　写网络程序要不要考虑移植性？要不要跨平台？这取决于项目需要，如果贵公司做的程序要卖给其他公司，而对方可能使用Windows、Linux、FreeBSD、Solaris、AIX、HP-UX 等等操作系统，这时候当然要考虑移植性。如果编写公司内部的服务器上用的网络程序，那么大可只关注一个平台，比如Linux。因为编写和维护可移植的网络程序的代价相当高，平台间的差异可能远比想象中大，即便是POSIX 系统之间也有不小的差异（比如Linux 没有SO_NOSIGPIPE 选项，Linux 的pipe(2) 是单向的，而FreeBSD 是双向的），错误的返回码也大不一样。
　　我就不打算把muduo 往Windows 或其他操作系统移植。如果需要编写可移植的网络程序，我宁愿用libevent、libuv、Java Netty 这样现成的库，把“脏活、累活”留给别人。
　　A.1.5 网络编程的各种任务角色
　　计算机网络是个big topic，涉及很多人物和角色，既有开发人员，也有运维人员。比方说：公司内部两台机器之间ping 不通，通常由网络运维人员解决，看看是布线有问题还是路由器设置不对；两台机器能ping 通，但是程序连不上，经检查是本机防火墙设置有问题，通常由系统管理员解决；两台机器能连上，但是丢包很严重，发现是网卡或者交换机的网口故障，由硬件维修人员解决；两台机器的程序能连上，但是偶尔发过去的请求得不到响应，通常是程序bug，应该由开发人员解决。
　　本文主要关心开发人员这一角色。下面简单列出一些我能想到的跟网络打交道的编程任务，其中前三项是面向网络本身，后面几项是在计算机网络之上构建信息系统。
　　1. 开发网络设备，编写防火墙、交换机、路由器的固件（firmware）。
　　2. 开发或移植网卡的驱动。
　　3. 移植或维护TCP/IP 协议栈（特别是在嵌入式系统上）。
　　4. 开发或维护标准的网络协议程序，HTTP、FTP、DNS、SMTP、POP3、NFS。
　　5. 开发标准网络协议的“附加品”，比如HAProxy、squid、varnish 等Web loadbalancer。
　　6. 开发标准或非标准网络服务的客户端库，比如ZooKeeper 客户端库、memcached客户端库。
　　7. 开发与公司业务直接相关的网络服务程序，比如即时聊天软件的后台服务器、网游服务器、金融交易系统、互联网企业用的分布式海量存储、微博发帖的内部广播通知等等。
　　8. 客户端程序中涉及网络的部分，比如邮件客户端中与POP3、SMTP 通信的部分，以及网游的客户端程序中与服务器通信的部分。
　　本文所指的“网络编程”专指第7 项，即在TCP/IP 协议之上开发业务软件。换句话说，不是用Sockets API 开发muduo 这样的网络库，而是用libevent、muduo、Netty、gevent 这样现成的库开发业务软件，muduo 自带的十几个示例程序是业务软件的代表。
　　A.1.6 面向业务的网络编程的特点
　　与通用的网络服务器不同，面向公司业务的专用网络程序有其自身的特点。
　　业务逻辑比较复杂，而且时常变化 如果写一个HTTP 服务器，在大致实现HTTP 1.1 标准之后，程序的主体功能一般不会有太大的变化，程序员会把时间放在性能调优和bug 修复上。而开发针对公司业务的专用程序时，功能说明书（spec）很可能不如HTTP 1.1 标准那么细致明确。更重要的是，程序是快速演化的。以即时聊天工具的后台服务器为例，可能第一版只支持在线聊天；几个月之后发布第二版，支持离线消息；又过了几个月，第三版支持隐身聊天；随后，第四版支持上传头像；如此等等。这要求程序员能快速响应新的业务需求，公司才能保持竞争力。由于业务时常变化（假设每月一次版本升级），也会降低服务程序连续运行时间的要求。相反，我们要设计一套流程，通过轮流重启服务器来完成平滑升级（§9.2.2）。
　　不一定需要遵循公认的通信协议标准 比方说网游服务器就没什么协议标准，反正客户端和服务端都是本公司开发的，如果发现目前的协议设计有问题，两边一起改就行了。由于可以自己设计协议，因此我们可以绕开一些性能难点，简化程序结构。比方说，对于多线程的服务程序，如果用短连接TCP 协议，为了优化性能通常要精心设计accept 新连接的机制2，避免惊群并减少上下文切换。但是如果改用长连接，用最简单的单线程accept 就行了。
　　程序结构没有定论 对于高并发大吞吐的标准网络服务，一般采用单线程事件驱动的方式开发，比如HAProxy、lighttpd 等都是这个模式。但是对于专用的业务系统，其业务逻辑比较复杂，占用较多的CPU 资源，这种单线程事件驱动方式不见得能发挥现在多核处理器的优势。这留给程序员比较大的自由发挥空间，做好了“横扫千军”，做烂了一败涂地。我认为目前one loop per thread 是通用性较高的一种程序结构，能发挥多核的优势，见§3.3 和§6.6。
　　性能评判的标准不同 如果开发httpd 这样的通用服务，必然会和开源的Nginx、lighttpd 等高性能服务器比较，程序员要投入相当的精力去优化程序，才能在市场上占有一席之地。而面向业务的专用网络程序不一定是IO bound，也不一定有开源的实现以供对比性能，优化方向也可能不同。程序员通常更加注重功能的稳定性与开发的便捷性。性能只要一代比一代强即可。
　　网络编程起到支撑作用，但不处于主导地位 程序员的主要工作是实现业务逻辑，而不只是实现网络通信协议。这要求程序员深入理解业务。程序的性能瓶颈不一定在网络上，瓶颈有可能是CPU、Disk IO、数据库等，这时优化网络方面的代码并不能提高整体性能。只有对所在的领域有深入的了解，明白各种因素的权衡（trade-off），才能做出一些有针对性的优化。现在的机器上，简单的并发长连接echo服务程序不用特别优化就做到十多万qps，但是如果每个业务请求需要1ms 密集计算，在8 核机器上充其量能达到8 000 qps，优化IO 不如去优化业务计算（如果投入产出合算的话）。
　　A.1.7 几个术语
　　互联网上的很多“口水战”是由对同一术语的不同理解引起的，比如我写的《多线程服务器的适用场合》3，就曾经被人说是“挂羊头卖狗肉”，因为这篇文章中举的master 例子“根本就算不上是个网络服务器。因为它的瓶颈根本就跟网络无关。”
　　网络服务器 “网络服务器”这个术语确实含义模糊，到底指硬件还是软件？到底是服务于网络本身的机器（交换机、路由器、防火墙、NAT），还是利用网络为其他人或程序提供服务的机器（打印服务器、文件服务器、邮件服务器）？每个人根据自己熟悉的领域，可能会有不同的解读。比方说，或许有人认为只有支持高并发、高吞吐量的才算是网络服务器。
　　为了避免无谓的争执，我只用“网络服务程序”或者“网络应用程序”这种含义明确的术语。“开发网络服务程序”通常不会造成误解。
　　客户端？服务端？ 在TCP 网络编程中，客户端和服务端很容易区分，主动发起连接的是客户端，被动接受连接的是服务端。当然，这个“客户端”本身也可能是个后台服务程序，HTTP proxy 对HTTP server 来说就是个客户端。
　　客户端编程？服务端编程？ 但是“服务端编程”和“客户端编程”就不那么好区分了。比如Web crawler，它会主动发起大量连接，扮演的是HTTP 客户端的角色，但似乎应该归入“服务端编程”。又比如写一个HTTP proxy，它既会扮演服务端——被动接受Web browser 发起的连接，也会扮演客户端——主动向HTTP server 发起连接，它究竟算服务端还是客户端？我猜大多数人会把它归入服务端编程。
　　那么究竟如何定义“服务端编程”？
　　服务端编程需要处理大量并发连接？也许是，也许不是。比如云风在一篇介绍网游服务器的博客4 中就谈到，网游中用到的“连接服务器”需要处理大量连接，而“逻辑服务器”只有一个外部连接。那么开发这种网游“逻辑服务器”算服务端编程还是客户端编程呢？又比如机房的服务进程监控软件，并发数跟机器数成正比，至多也就是两三千的并发连接。（再大规模就超出本书的范围了。）
　　我认为，“服务端网络编程”指的是编写没有用户界面的长期运行的网络程序，程序默默地运行在一台服务器上，通过网络与其他程序打交道，而不必和人打交道。与之对应的是客户端网络程序，要么是短时间运行，比如wget；要么是有用户界面（无论是字符界面还是图形界面）。本文主要谈服务端网络编程。
　　作者简介
　　陈硕，北京师范大学硕士，擅长C++ 多线程网络编程和实时分布式系统架构。曾在摩根士丹利IT 部门工作5 年，从事实时外汇交易系统开发。现在在美国加州硅谷某互联网大公司工作，从事大规模分布式系统的可靠性工程。编写了开源C++ 网络库muduo，参与翻译了《代码大全（第2 版）》和《C++ 编程规范（繁体版）》，整理了《C++ Primer （第4 版）（评注版）》，并曾多次在各地技术大会演讲。
　　前言
　　本书主要讲述采用现代C++ 在x86-64 Linux 上编写多线程TCP 网络服务程序的主流常规技术，这也是我对过去5 年编写生产环境下的多线程服务端程序的经验总结。本书重点讲解多线程网络服务器的一种IO 模型，即one loop per thread。这是一种适应性较强的模型，也是Linux 下以native 语言编写用户态高性能网络程序最成熟的模式，掌握之后可顺利地开发各类常见的服务端网络应用程序。本书以muduo网络库为例，讲解这种编程模型的使用方法及注意事项。
　　muduo 是一个基于非阻塞IO 和事件驱动的现代C++ 网络库，原生支持oneloop per thread 这种IO 模型。muduo 适合开发Linux 下的面向业务的多线程服务端网络应用程序，其中“面向业务的网络编程”的定义见附录A。“现代C++”指的不是C++11 新标准，而是2005 年TR1 发布之后的C++ 语言和库。与传统C++ 相比，现代C++ 的变化主要有两方面：资源管理（见第1 章）与事件回调（见第449 页）。
　　本书不是多线程编程教程，也不是网络编程教程，更不是C++ 教程。读者应该已经大致读过《UNIX 环境高级编程》、《UNIX 网络编程》、《C++ Primer》或与之内容相近的书籍。本书不谈C++11，因为目前（2012 年）主流的Linux 服务端发行版的g++ 版本都还停留在4.4，C++11 进入实用尚需一段时日。
　　本书适用的硬件环境是主流x86-64 服务器，多路多核CPU、几十GB 内存、千兆以太网互联。除了第5 章讲诊断日志之外，本书不涉及文件IO。
　　本书分为四大部分，第1 部分“C++ 多线程系统编程”考察多线程下的对象生命期管理、线程同步方法、多线程与C++ 的结合、高效的多线程日志等。第2 部分“muduo 网络库”介绍使用现成的非阻塞网络库编写网络应用程序的方法，以及muduo 的设计与实现。第3 部分“工程实践经验谈”介绍分布式系统的工程化开发方法和C++ 在工程实践中的功能特性取舍。第4 部分“附录”分享网络编程和C++语言的学习经验。
　　本书的宗旨是贵精不贵多。掌握两种基本的同步原语就可以满足各种多线程同步的功能需求，还能写出更易用的同步设施。掌握一种进程间通信方式和一种多线程网络编程模型就足以应对日常开发任务，编写运行于公司内网环境的分布式服务系统。（本书不涉及分布式存储系统，也不涉及UDP。）
　　
　　术语与排版范例
　　本书大量使用英文术语，甚至有少量英文引文。设计模式的名字一律用英文，例如Observer、Reactor、Singleton。在中文术语不够突出时，也会使用英文，例如class、heap、event loop、STL algorithm 等。注意几个中文C++ 术语： 对象实体（instance）、函数重载决议（resolution）、模板具现化（instantiation）、覆写（override）虚函数、提领（dereference）指针。本书中的英语可数名词一般不用复数形式，例如两个class，6 个syscall；但有时会用(s) 强调中文名词是复数。fd 是文件描述符（file descriptor）的缩写。“CPU 数目”一般指的是核（core）的数目。容量单位kB、MB、GB 表示的字节数分别为103、106、109，在特别强调准确数值时，会分别用KiB、MiB、GiB 表示210、220、230 字节。用诸如§11.5 表示本书第11.5 节，L42 表示上下文中出现的第42 行代码。[JCP]、[CC2e] 等是参考文献，见书末清单。
　　一般术语用普通罗马字体，如mutex、socket；C++ 关键字用无衬线字体，如class、this、mutable；函数名和class 名用等宽字体，如fork(2)、muduo::EventLoop，其中fork(2) 表示系统函数fork() 的文档位于manpage 第2 节，可以通过man 2 fork命令查看。如果函数名或类名过长，可能会折行，行末有连字号“-”，如EventLoop-ThreadPool。文件路径和URL 采用窄字体，例如muduo/base/Date.h、http://chenshuo.com。用中文楷体表示引述别人的话。
　　代码
　　本书的示例代码以开源项目的形式发布在GitHub 上，地址是
　　http://github.com/chenshuo/recipes/ 和http://github.com/chenshuo/muduo/。本书配套页面提供全部源代码打包下载，正文中出现的类似recipes/thread 的路径是压缩包内的相对路径，读者不难找到其对应的GitHub URL。本书引用代码的形式如下，左侧数字是文件的行号，右侧的“muduo/base/Types.h”是文件路径1。例如下面这几行代码是muduo::string 的typedef。
　　muduo/base/Types.h
　　15 namespace muduo
　　16 {
　　17
　　18 #ifdef MUDUO_STD_STRING
　　19 using std::string;
　　20 #else // !MUDUO_STD_STRING
　　21 typedef __gnu_cxx::__sso_string string;
　　22 #endif
　　muduo/base/Types.h
　　在第6、7 两章的muduo 示例代码中，路径muduo/examples/XXX 会简写为examples/XXX。此外，第8 章会把recipes/reactor/XXX 简写为reactor/XXX。
　　本书假定读者熟悉diff -u 命令的输出格式，用于表示代码的改动。
　　本书正文中出现的代码有时为了照顾排版而略有改写，例如改变缩进规则，去掉单行条件语句前后的花括号等。就编程风格而论，应以电子版代码为准。
　　联系方式
　　邮箱：giantchen@gmail.com
　　主页：http://chenshuo.com/book （正文和脚注中出现的URL 可从这里找到。）
　　微博：http://weibo.com/giantchen
　　博客：http://blog.csdn.net/Solstice
　　代码：http://github.com/chenshuo
　　陈硕
　　中国·香港