购买地址：http://e.jd.com/30149978.html

阅读效果：

PC

iPad

目前京东的阅读器没有切白边功能，值得改进。

这不是 memcached 的替代品（它没有实现LRU和超时功能，也没有实现二进制协议，更没有自己管理内存），而是一个网络编程的示例（代码只有 1000 行，比 memcached 小很多），展示 muduo 风格的事件驱动编程，以及将来性能优化的试验品（换句话说，现在这个版本完全没有在性能上做出任何努力）。读过 memcached 代码的人可以对比这两种编程风格的区别，memcached 的 read/write 操作穿插于正常逻辑处理，而 muduo 的网络数据读写是由库完成，应用程序只关心消息收发，目前二者的基本 get/set 操作的性能相当。

现在 muduo 的 inspector 内置了 gperftools 的远程 profiling 功能，memcached-debug 展示了其用法。

为什么不必优化 set 操作（含 set/add/update/append/prepend/cas 等）的性能？

1. 比例。既然是 memcache，那么 get:set 的比例很高，10:1 甚至更高，因此优化的重心应该是 get 而非 set。

假设 memcached 能处理 100k QPS，再假设这些操作都是 set（其实应该不到 10% 是 set），再假设所有的 set 都是串行执行的（没有并发），那么每次 set 的 CPU 时间不应该超过 10 us（含服务器本地的网络代码运行时间，但不含网络延迟）。而实际上一次 set 的 CPU 时间最多是 2~3 us （用 memcached-footprint 程序测得），根本不值得优化。

2. 网络带宽。假设一次 set 操作的 key + value 的长度是 1k bytes，TCP 的有效载荷带宽按110MB/s估算，那么1kB数据在千兆网上的惯性延迟是 9us（传输延迟是几十上百微秒，与此无关），也就是说服务器的网卡收到这 1kB 数据需要花 9us 时间（从第一个字节到达到服务器到收完最后一个字节），那么在 set 耗时 2~3 us 的情况下再去优化它是做无用功。

3. 产生“需要更新的数据”的成本远大于 memcached set 的开销。memcached 需要更新，往往是将已写入数据库的新数据放到 memcached 中，那么写数据库的开销远远大于 memcached set 的开销，优化 set 对提升系统整体性能没意义。

今天先讲第一个，单词计数及排序。单词计数（word count），顾名思义就是统计一个文本文件里边每个词出现了多少次。排序指的是按出现次数从多到少排序，也可以把问题改为“找出出现次数最多的1000个单词”。

这个问题有三个层次，第一是输入文件比较小，能完全放入内存；第二是输入文件比较大，不能一次性都放入内存；第三是输入文件分布在多台机器上，这需要用到网络编程。

第一个层次很好解决，几十行代码就搞定了。https://gist.github.com/4519962

第二个层次不难解决，基本思路是分而治之，先hash分块统计单词出现次数，将每一块按出现次数排序，最后归并。代码见 https://github.com/chenshuo/recipes/blob/master/puzzle/query_freq.cc ，分析见 http://www.cnblogs.com/baiyanhuang/archive/2012/11/11/2764914.html 。

第三个层次也不难，可以当做网络编程的练习来做。如果有合适的框架，可以轻松解决，因为单词计数是map reduce的经典范例，对出现次数排序也可以再用一步map reduce搞定（估计需要一个好的 shuffle 函数，简单hash是不行的）。

如果用普通网络编程，一种设计思路如下图，其中方框代表机器，椭圆代表输入输出文件，圆角矩形代表进程。思路跟第二个层次一样，先hash到多个shard文件（由hasher和receiver负责），再对每个shard文件排序（由sender负责），最后归并（merger）。

注意这种思路适合求top K元素，不适合按出现次数排序全部单词，因为最终结果收集在一台机器上。目前这个sender实现的一个限制是，每个shard必须能全部放入内存，因为sender对shard排序是在内存中进行的。如果数据更大，还需要实现单机外部排序。

图中hasher和receiver的代码见muduo示例中的 muduo/examples/wordcount ；sender和merger的代码见 https://github.com/chenshuo/recipes/tree/master/topk 。注意merger没有使用muduo，而是采用阻塞网络编程。有兴趣的读者可以思考其背后的原因。要想发挥 merger 正常的性能，需要修改 /usr/include/boost/asio/basic_socket_streambuf.hpp ，增大缓冲区，即 enum { buffer_size = 8192 };

这可以看作是map reduce的原始实现，或者说用map reduce的思想手写了一些原始工具。如果把map reduce比作C语言，这里的几个程序相当于汇编写的函数。

以后我再写一个按出现次数全排序的例子吧，需要替换这里的sender和merger。

(.完.)

本书主要讲述采用现代 C++ 在 x86-64 Linux 上编写多线程 TCP 网络服务程序的主流常规技术，重点讲解一种适应性较强的多线程服务器的编程模型，即 one loop per thread。这是在 Linux 下以 native 语言编写用户态高性能网络程序最成熟的模式，掌握之后可顺利地开发各类常见的服务端网络应用程序。本书以 muduo 网络库为例，讲解这种编程模型的使用方法及注意事项。

本书的宗旨是贵精不贵多。掌握两种基本的同步原语就可以满足各种多线程同步的功能需求，还能写出更易用的同步设施。掌握一种进程间通信方式和一种多线程网络编程模型就足以应对日常开发任务，编写运行于公司内网环境的分布式服务统。

基本信息

出版社：电子工业出版社

页数：xvi+600

定价：人民币89元

ISBN：9787121192821

豆瓣及网上书店预订

豆瓣：http://book.douban.com/subject/20471211/
互动：http://product.china-pub.com/3021861
亚马逊：http://www.amazon.cn/dp/B00AYS2KL0
当当：http://product.dangdang.com/product.aspx?product_id=23162953
京东：http://book.360buy.com/11163782.html

试读样章

前言与目录：https://chenshuo-public.s3.amazonaws.com/pdf/preamble.pdf
第1章：线程安全的对象生命期管理：https://chenshuo-public.s3.amazonaws.com/pdf/chap1.pdf
第6章：muduo网络库简介：https://chenshuo-public.s3.amazonaws.com/pdf/chap6.pdf
附录：https://chenshuo-public.s3.amazonaws.com/pdf/appendix.pdf
样章合集下载：http://vdisk.weibo.com/s/mtupb 共150页，包括第 11.5 节。

前言（节选）

本书主要讲述采用现代 C++ 在 x86-64 Linux 上编写多线程 TCP 网络服务程序的主流常规技术，这也是我对过去 5 年编写生产环境下的多线程服务端程序的经验总结。本书重点讲解多线程网络服务器的一种 IO 模型，即 one loop per thread。这是一种适应性较强的模型，也是 Linux 下以 native 语言编写用户态高性能网络程序最成熟的模式， 掌握之后可顺利地开发各类常见的服务端网络应用程序。本书以 muduo 网络库为例，讲解这种编程模型的使用方法及注意事项。

muduo 是一个基于非阻塞 IO 和事件驱动的现代 C++ 网络库，原生支持 one loop 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）的数目。用诸如§11.5 表示本书第 11.5 节，L42 表示上下文中出现的第 42 行代码。[JCP]、[CC2e] 等是参考文献，见书末清单。

代码

本书的示例代码以开源项目的形式发布在 GitHub 上，
地址是 http://github.com/chenshuo/recipes/ 和 http://github.com/chenshuo/muduo/ 。本书配套页面提供全部源代码打包下载，正文中出现的类似 recipes/thread 的路径是压缩包内的相对路径，读者不难找到其对应的 GitHub URL。

本书假定读者熟悉 diff -u 命令的输出格式，用于表示代码的改动。

本书正文中出现的代码有时为了照顾排版而略有改写，例如改变缩进规则，去掉单行条件语句前后的花括号等。就编程风格而论，应以电子版代码为准。

联系方式

邮箱：giantchen_at_gmail.com

主页：http://chenshuo.com/book （正文和脚注中出现的 URL 可从这里找到。 ）

微博：http://weibo.com/giantchen

博客：http://blog.csdn.net/Solstice

代码：http://github.com/chenshuo

陈硕

中国•香港

• 程序在本机测试正常，放到网络运行上就经常出现数据收不全的情况？
• TCP 协议真的有所谓的“粘包问题”吗？该如何设计打包拆包的协议？又该如何编码实现才不会掉到陷阱里？
• 带外数据（OOB）、信号驱动IO这些高级特性到底有没有用？
• 网络协议格式该怎么设计？发送 C struct 会有对齐方面的问题吗？对方不用 C/C++ 怎么通信？ 将来服务端软件升级，需要在协议中增加一个字段，现有的客户端就必须强制升级？
• 要处理几千上万的并发连接，似乎书上讲的传统 fork() 模型应付不过来，该用哪种并发模型呢？ 试试 select、poll、epoll 这种 IO 复用模型吧，又感觉非阻塞IO陷阱重重，怎么程序的 CPU 使用率一直是100%？
• 要不改用现成的 libevent 网络库吧，怎么查询一下数据库就把其他连接上的请求给耽误了？ 再用个线程池吧。万一发回响应的时候对方已经断开连接了怎么办？会不会串话？
• 读过《UNIX 环境高级编程》，想用多线程来发挥多核 CPU 的效率， 但对程序该用哪种多线程模型感到一头雾水？ 有没有值得推荐的适用面广的多线程 IO 模型？ 互斥器、条件变量、读写锁、信号量这些底层同步原语哪些该用哪些不该用？ 有没有更高级的同步设施能简化开发？ 《UNIX 网络编程（第二卷）》介绍的那些琳琅满目的IPC机制到底用哪个才能兼顾开发效率与可伸缩性？

• 网上听人说服务端开发要做到 7x24 运行，为了防止内存碎片连动态内存分配都不能用， 那岂不是连 C++ STL 也一并禁用了？硬件的可靠性高到值得去这么做吗？
• 传闻服务端开发主要通过日志来查错，那么日志里该写些什么？日志是写给谁看的？怎样写日志才不会影响性能？
• 分布式系统跟单机多进程到底有什么本质区别？心跳协议为什么是必须的，该如何实现？
• C++ 的大型工程该如何管理？库的接口如何设计才能保证升级的时候不破坏二进制兼容性？

这本《Linux 多线程服务端编程》中，作者凭借多年的工程实践经验试图解答以上疑问。当然，内容还远不止这些……

本书配套页面： http://chenshuo.com/book ，将不定期更新。

这是PPT：

http://www.slideshare.net/chenshuo/muduo-network-library

演讲视频：

http://v.youku.com/v_show/id_XNDIyNDc5MDMy.html

http://youtu.be/YDnCAs894Bg 

活动介绍：

http://ouropensource.51qiangzuo.com/

2012年6月30日在深圳的简短演讲：

http://v.youku.com/v_show/id_XNDIyMjUwMDYw.html

http://www.youtube.com/watch?v=KM_eQ6uRYdU

代码位于 muduo 网络库中的 muduo/base

https://github.com/chenshuo/muduo

muduo 0.5.0 也包含了这个日志库 http://code.google.com/p/muduo/

blog.csdn.net/Solstice

前几天我在新浪微博上出了两道有关 TCP 的思考题，引发了一场讨论 http://weibo.com/1701018393/eCuxDrta0Nn 。

第一道初级题目是：

有一台机器，它有一个 IP，上面运行了一个 TCP 服务程序，程序只侦听一个端口，问：从理论上讲（只考虑 TCP/IP 这一层面，不考虑IPv6）这个服务程序可以支持多少并发 TCP 连接？答 65536 上下的直接刷掉。

具体来说，这个问题等价于：有一个 TCP 服务程序的地址是 1.2.3.4:8765，问它从理论上能接受多少个并发连接？

第二道进阶题目是：

一台被测机器 A，功能同上，同一交换机上还接有一台机器 B，如果允许 B 的程序直接收发以太网 frame，问：让 A 承担 10 万个并发 TCP 连接需要用多少 B 的资源？100万个呢？

从讨论的结果看，很多人做出了第一道题，而第二道题几乎无人问津。

这里先不公布答案（第一题答案见文末），让我们继续思考一个本质的问题：一个 TCP 连接要占用多少系统资源。

在现在的 Linux 操作系统上，如果用 socket()/connect() 或 accept() 来创建 TCP 连接，那么每个连接至少要占用一个文件描述符(file descriptor)。为什么说“至少”？因为文件描述符可以复制，比如 dup()；也可以被继承，比如 fork()；这样可能出现系统里边同一个 TCP 连接有多个文件描述符与之对应。据此，很多人给出的第一题答案是：并发连接数受限于系统能同时打开的文件数目的最大值。这个答案在实践中是正确的，却不符合原题意。

如果抛开操作系统层面，只考虑 TCP/IP 层面，建立一个 TCP 连接有哪些开销？理论上最小的开销是多少？考虑两个场景：

1. 假设有一个 TCP 服务程序，向这个程序成功发起连接需要做哪些事情？换句话说，如何才能让这个 TCP 服务程序认为有客户连接到了它（让它的 accept() 调用正常返回）？

2. 假设有一个 TCP 客户端程序，让这个程序成功建立到服务器的连接需要做哪些事情？换句话说，如何才能让这个 TCP 客户端程序认为它自己已经连接到服务器了（让它的 connect() 调用正常返回）？

以上这两个问题问的不是如何编程，如何调用 Sockets API，而是问如何让操作系统的 TCP/IP 协议栈认为任务已经成功完成，连接已经成功建立。

学过 TCP/IP 协议，理解三路握手的同学明白，TCP 连接是虚拟的连接，不是电路连接，维持 TCP 连接理论上不占用网络资源（会占用两头程序的系统资源）。只要连接的双方认为 TCP 连接存在，并且可以互相发送 IP packet，那么 TCP 连接就一直存在。

对于问题 1，向一个 TCP 服务程序发起一个连接，客户端（为明白起见，以下称为 faketcp 客户端）只需要做三件事情（三路握手）：

1a. 向 TCP 服务程序发一个 IP packet，包含 SYN 的 TCP segment

1b. 等待对方返回一个包含 SYN 和 ACK 的 TCP segment

1c. 向对方发送一个包含 ACK 的 segment

在做完这三件事情之后，TCP 服务器程序会认为连接已建立。而做这三件事情并不占用客户端的资源（？），如果faketcp 客户端程序可以绕开操作系统的 TCP/IP 协议栈，自己直接发送并接收 IP packet 或 Ethernet frame 的话。换句话说，faketcp 客户端可以一直重复做这三件事件，每次用一个不同的 IP:PORT，在服务端创建不计其数的 TCP 连接，而 faketcp 客户端自己毫发无损。很快我们将看到如何用程序来实现这一点。

对于问题 2，为了让一个 TCP 客户端程序认为连接已建立，faketcp 服务端只需要做两件事情：

2a. 等待客户端发来的 SYN TCP segment

2b. 发送一个包含 SYN 和 ACK 的 TCP segment

2c. 忽视对方发来的包含 ACK 的 segment

在做完这两件事情（收一个 SYN、发一个 SYN+ACK）之后，TCP 客户端程序会认为连接已建立。而做这三件事情并不占用 faketcp 服务端的资源（？）换句话说，faketcp 服务端可以一直重复做这两件事件，接受不计其数的 TCP 连接，而 faketcp 服务端自己毫发无损。很快我们将看到如何用程序来实现这一点。

基于对以上两个问题的分析，说明单独谈论“TCP 并发连接数”是没有意义的，因为连接数基本上是要多少有多少。更有意义的性能指标或许是：“每秒钟收发多少条消息”、“每秒钟收发多少字节的数据”、“支持多少个活动的并发客户”等等。

faketcp 的程序实现

代码见： https://github.com/chenshuo/recipes/tree/master/faketcp 可以直接用 make 编译

为了验证我上面的说法，我写了几个小程序来实现 faketcp，这几个程序可以发起或接受不计其数的 TCP 并发连接，并且不消耗操作系统资源，连动态内存分配都不会用到。

我家里有一台运行 Ubuntu Linux 10.04 的 PC 机，hostname 是 atom，所有的试验都在这上面进行。

家里试验环境的网络配置是：

陈硕在《谈一谈网络编程学习经验》中曾提到“可以用 TUN/TAP 设备在用户态实现一个能与本机点对点通信的 TCP/IP 协议栈”，这次的试验正好可以用上这个办法。

试验的网络配置是：

具体做法是：在 atom 上通过打开 /dev/net/tun 设备来创建一个 tun0 虚拟网卡，然后把这个网卡的地址设为 192.168.0.1/24，这样 faketcp 程序就扮演了 192.168.0.0/24 这个网段上的所有机器。atom 发给 192.168.0.2~192.168.0.254 的 IP packet 都会发给 faketcp 程序，faketcp 程序可以模拟其中任何一个 IP 给 atom 发 IP packet。

程序分成几步来实现。

第一步：实现 icmp echo 协议，这样就能 ping 通 faketcp 了。

代码见 https://github.com/chenshuo/recipes/blob/master/faketcp/icmpecho.cc

其中响应 icmp echo request 的函数在 https://github.com/chenshuo/recipes/blob/master/faketcp/faketcp.cc#L57 这个函数在后面的程序中也会用到。

运行方法，打开 3 个命令行窗口：

1. 在第 1 个窗口运行 sudo ./icmpecho ，程序显示

allocted tunnel interface tun0

2. 在第 2 个窗口运行

$ sudo ifconfig tun0 192.168.0.1/24

$ sudo tcpdump -i tun0

3. 在第 3 个窗口运行

$ ping 192.168.0.2

$ ping 192.168.0.3

$ ping 192.168.0.234

发现每个 192.168.0.X 的 IP 都能 ping 通。

第二步：实现拒绝 TCP 连接的功能，即在收到 SYN TCP segment 的时候发送 RST segment。

代码见 https://github.com/chenshuo/recipes/blob/master/faketcp/rejectall.cc

运行方法，打开 3 个命令行窗口，头两个窗口的操作与前面相同，运行的 faketcp 程序是 ./rejectall

3. 在第 3 个窗口运行

$ nc 192.168.0.2 2000

$ nc 192.168.0.2 3333

$ nc 192.168.0.7 5555

发现向其中任意一个 IP 发起的 TCP 连接都被拒接了。

第三步：实现接受 TCP 连接的功能，即在收到SYN TCP segment 的时候发回 SYN+ACK。这个程序同时处理了连接断开的情况，即在收到 FIN segment 的时候发回 FIN+ACK。

代码见 https://github.com/chenshuo/recipes/blob/master/faketcp/acceptall.cc

运行方法，打开 3 个命令行窗口，步骤与前面相同，运行的 faketcp 程序是 ./acceptall。这次会发现 nc 能和 192.168.0.X 中的每一个 IP 每一个 PORT 都能连通。还可以在第 4 个窗口中运行 netstat –tpn ，以确认连接确实建立起来了。如果在 nc 中输入数据，数据会堆积在操作系统中，表现为 netstat 显示的发送队列（Send-Q）的长度增加。

第四步：在第三步接受 TCP 连接的基础上，实现接收数据，即在收到包含 payload 数据 的 TCP segment 时发回 ACK。

代码见 https://github.com/chenshuo/recipes/blob/master/faketcp/discardall.cc

运行方法，打开 3 个命令行窗口，步骤与前面相同，运行的 faketcp 程序是 ./acceptall。这次会发现 nc 能和 192.168.0.X 中的每一个 IP 每一个 PORT 都能连通，数据也能发出去。还可以在第 4 个窗口中运行 netstat –tpn ，以确认连接确实建立起来了，并且发送队列的长度为 0。

这一步已经解决了前面的问题 2，扮演任意 TCP 服务端。

第五步：解决前面的问题 1，扮演客户端向 atom 发起任意多的连接。

代码见 https://github.com/chenshuo/recipes/blob/master/faketcp/connectmany.cc

这一步的运行方法与前面不同，打开 4 个命令行窗口。

1. 在第 1 个窗口运行 sudo ./connectmany 192.168.0.1 2007 1000 ，表示将向 192.168.0.1:2007 发起 1000 个并发连接。

程序显示

allocted tunnel interface tun0
press enter key to start connecting 192.168.0.1:2007

2. 在第 2 个窗口运行

$ sudo ifconfig tun0 192.168.0.1/24

$ sudo tcpdump -i tun0

3. 在第 3 个窗口运行一个能接收并发 TCP 连接的服务程序，可以是 httpd，也可以是 muduo 的 echo 或 discard 示例，程序应 listen 2007 端口。

4. 回到第 1 个窗口中敲回车，然后在第 4 个窗口中用 netstat -tpn 来观察并发连接。

有兴趣的话，还可以继续扩展，做更多的有关 TCP 的试验，以进一步加深理解，验证操作系统 TCP/IP 协议栈面对不同输入的行为。甚至可以按我在《谈一谈网络编程学习经验》中提议的那样，实现完整的 TCP 状态机，做出一个简单的 mini tcp stack。

第一道题的答案：

在只考虑 IPv4 的情况下，并发数的理论上限是 2**48。考虑某些 IP 段被保留了，这个上界可适当缩小，但数量级不变。实际的限制是操作系统全局文件描述符的数量，以及内存大小。

一个 TCP 连接有两个 end points，每个 end point 是 {ip, port}，题目说其中一个 end point 已经固定，那么留下一个 end point 的自由度，即 2 ** 48。客户端 IP 的上限是 2**32 个，每个客户端IP发起连接的上限是 2**16，乘到一起得理论上限。

即便客户端使用 NAT，也不影响这个理论上限。（为什么？）

在真实的 Linux 系统中，可以通过调整内核参数来支持上百万并发连接，具体做法见：

http://urbanairship.com/blog/2010/09/29/linux-kernel-tuning-for-c500k/

http://www.metabrew.com/article/a-million-user-comet-application-with-mochiweb-part-3

(.完.)

blog.csdn.net/Solstice

Muduo 全系列文章列表： http://blog.csdn.net/Solstice/category/779646.aspx

本文以一个 Sudoku Solver 为例，回顾了并发网络服务程序的多种设计方案，并介绍了使用 muduo 网络库编写多线程服务器的两种最常用手法。以往的例子展现了 Muduo 在编写单线程并发网络服务程序方面的能力与便捷性，今天我们看一看它在多线程方面的表现。

本文代码见：http://code.google.com/p/muduo/source/browse/trunk/examples/sudoku/

Sudoku Solver

假设有这么一个网络编程任务：写一个求解数独的程序 (Sudoku Solver)，并把它做成一个网络服务。

Sudoku Solver 是我喜爱的网络编程例子，它曾经出现在《分布式系统部署、监控与进程管理的几重境界》、《Muduo 设计与实现之一：Buffer 类的设计》、《〈多线程服务器的适用场合〉例释与答疑》等文中，它也可以看成是 echo 服务的一个变种（《谈一谈网络编程学习经验》把 echo 列为三大 TCP 网络编程案例之一）。

写这么一个程序在网络编程方面的难度不高，跟写 echo 服务差不多（从网络连接读入一个 Sudoku 题目，算出答案，再发回给客户），挑战在于怎样做才能发挥现在多核硬件的能力？在谈这个问题之前，让我们先写一个基本的单线程版。

协议

一个简单的以 \r\n 分隔的文本行协议，使用 TCP 长连接，客户端在不需要服务时主动断开连接。

请求：[id:]〈81digits〉\r\n

响应：[id:]〈81digits〉\r\n 或者 [id:]NoSolution\r\n

其中[id:]表示可选的 id，用于区分先后的请求，以支持 Parallel Pipelining，响应中会回显请求中的 id。Parallel Pipelining 的意义见赖勇浩的《以小见大——那些基于 protobuf 的五花八门的 RPC（2） 》，或者见我写的《分布式系统的工程化开发方法》第 54 页关于 out-of-order RPC 的介绍。

〈81digits〉是 Sudoku 的棋盘，9x9 个数字，未知数字以 0 表示。

如果 Sudoku 有解，那么响应是填满数字的棋盘；如果无解，则返回 NoSolution。

例子1：

请求：000000010400000000020000000000050407008000300001090000300400200050100000000806000\r\n

响应：693784512487512936125963874932651487568247391741398625319475268856129743274836159\r\n

例子2：

请求：a:000000010400000000020000000000050407008000300001090000300400200050100000000806000\r\n

响应：a:693784512487512936125963874932651487568247391741398625319475268856129743274836159\r\n

例子3：

请求：b:000000010400000000020000000000050407008000300001090000300400200050100000000806005\r\n

响应：b:NoSolution\r\n

基于这个文本协议，我们可以用 telnet 模拟客户端来测试 sudoku solver，不需要单独编写 sudoku client。SudokuSolver 的默认端口号是 9981，因为它有 9x9=81 个格子。

基本实现

Sudoku 的求解算法见《谈谈数独(Sudoku)》一文，这不是本文的重点。假设我们已经有一个函数能求解 Sudoku，它的原型如下

string solveSudoku(const string& puzzle);

函数的输入是上文的"〈81digits〉"，输出是"〈81digits〉"或"NoSolution"。这个函数是个 pure function，同时也是线程安全的。

有了这个函数，我们以《Muduo 网络编程示例之零：前言》中的 EchoServer 为蓝本，稍作修改就能得到 SudokuServer。这里只列出最关键的 onMessage() 函数，完整的代码见 http://code.google.com/p/muduo/source/browse/trunk/examples/sudoku/server_basic.cc 。onMessage() 的主要功能是处理协议格式，并调用 solveSudoku() 求解问题。

 // muduo/examples/sudoku/server_basic.cc

  const int kCells = 81;

  void onMessage(const TcpConnectionPtr& conn, Buffer* buf, Timestamp)
  {
    LOG_DEBUG << conn->name();
    size_t len = buf->readableBytes();
    while (len >= kCells + 2)
    {
      const char* crlf = buf->findCRLF();
      if (crlf)
      {
        string request(buf->peek(), crlf);
        string id;
        buf->retrieveUntil(crlf + 2);
        string::iterator colon = find(request.begin(), request.end(), ':');
        if (colon != request.end())
        {
          id.assign(request.begin(), colon);
          request.erase(request.begin(), colon+1);
        }
        if (request.size() == implicit_cast<size_t>(kCells))
        {
          string result = solveSudoku(request);
          if (id.empty())
          {
            conn->send(result+"\r\n");
          }
          else
          {
            conn->send(id+":"+result+"\r\n");
          }
        }
        else
        {
          conn->send("Bad Request!\r\n");
          conn->shutdown();
        }
      }
      else
      {
        break;
      }
    }
  }

server_basic.cc 是一个并发服务器，可以同时服务多个客户连接。但是它是单线程的，无法发挥多核硬件的能力。

Sudoku 是一个计算密集型的任务（见《Muduo 设计与实现之一：Buffer 类的设计》中关于其性能的分析），其瓶颈在 CPU。为了让这个单线程 server_basic 程序充分利用 CPU 资源，一个简单的办法是在同一台机器上部署多个 server_basic 进程，让每个进程占用不同的端口，比如在一台 8 核机器上部署 8 个 server_basic 进程，分别占用 9981、9982、……、9988 端口。这样做其实是把难题推给了客户端，因为客户端(s)要自己做负载均衡。再想得远一点，在 8 个 server_basic 前面部署一个 load balancer？似乎小题大做了。

能不能在一个端口上提供服务，并且又能发挥多核处理器的计算能力呢？当然可以，办法不止一种。

常见的并发网络服务程序设计方案

W. Richard Stevens 的 UNP2e 第 27 章 Client-Server Design Alternatives 介绍了十来种当时（90 年代末）流行的编写并发网络程序的方案。UNP3e 第 30 章，内容未变，还是这几种。以下简称 UNP CSDA 方案。UNP 这本书主要讲解阻塞式网络编程，在非阻塞方面着墨不多，仅有一章。正确使用 non-blocking IO 需要考虑的问题很多，不适宜直接调用 Sockets API，而需要一个功能完善的网络库支撑。

随着 2000 年前后第一次互联网浪潮的兴起，业界对高并发 http 服务器的强烈需求大大推动了这一领域的研究，目前高性能 httpd 普遍采用的是单线程 reactor 方式。另外一个说法是 IBM Lotus 使用 TCP 长连接协议，而把 Lotus 服务端移植到 Linux 的过程中 IBM 的工程师们大大提高了 Linux 内核在处理并发连接方面的可伸缩性，因为一个公司可能有上万人同时上线，连接到同一台跑着 Lotus server 的 Linux 服务器。

可伸缩网络编程这个领域其实近十年来没什么新东西，POSA2 已经作了相当全面的总结，另外以下几篇文章也值得参考。

http://bulk.fefe.de/scalable-networking.pdf

http://www.kegel.com/c10k.html

http://gee.cs.oswego.edu/dl/cpjslides/nio.pdf

下表是陈硕总结的 10 种常见方案。其中“多连接互通”指的是如果开发 chat 服务，多个客户连接之间是否能方便地交换数据（chat 也是《谈一谈网络编程学习经验》中举的三大 TCP 网络编程案例之一）。对于 echo/http/sudoku 这类“连接相互独立”的服务程序，这个功能无足轻重，但是对于 chat 类服务至关重要。“顺序性”指的是在 http/sudoku 这类请求-响应服务中，如果客户连接顺序发送多个请求，那么计算得到的多个响应是否按相同的顺序发还给客户（这里指的是在自然条件下，不含刻意同步）。

UNP CSDA 方案归入 0~5。5 也是目前用得很多的单线程 reactor 方案，muduo 对此提供了很好的支持。6 和 7 其实不是实用的方案，只是作为过渡品。8 和 9 是本文重点介绍的方案，其实这两个方案已经在《多线程服务器的常用编程模型》一文中提到过，只不过当时我还没有写 muduo，无法用具体的代码示例来说明。

在对比各方案之前，我们先看看基本的 micro benchmark 数据（前三项由 lmbench 测得）：

• fork()+exit(): 160us
• pthread_create()+pthread_join(): 12us
• context switch : 1.5us
• sudoku resolve: 100us (根据题目难度不同，浮动范围 20~200us)

方案 0：这其实不是并发服务器，而是 iterative 服务器，因为它一次只能服务一个客户。代码见 UNP figure 1.9，UNP 以此为对比其他方案的基准点。这个方案不适合长连接，到是很适合 daytime 这种 write-only 服务。

方案 1：这是传统的 Unix 并发网络编程方案，UNP 称之为 child-per-client 或 fork()-per-client，另外也俗称 process-per-connection。这种方案适合并发连接数不大的情况。至今仍有一些网络服务程序用这种方式实现，比如 PostgreSQL 和 Perforce 的服务端。这种方案适合“计算响应的工作量远大于 fork() 的开销”这种情况，比如数据库服务器。这种方案适合长连接，但不太适合短连接，因为 fork() 开销大于求解 sudoku 的用时。

方案 2：这是传统的 Java 网络编程方案 thread-per-connection，在 Java 1.4 引入 NIO 之前，Java 网络服务程序多采用这种方案。它的初始化开销比方案 1 要小很多。这种方案的伸缩性受到线程数的限制，一两百个还行，几千个的话对操作系统的 scheduler 恐怕是个不小的负担。

方案 3：这是针对方案 1 的优化，UNP 详细分析了几种变化，包括对 accept 惊群问题的考虑。

方案 4：这是对方案 2 的优化，UNP 详细分析了它的几种变化。

以上几种方案都是阻塞式网络编程，程序（thread-of-control）通常阻塞在 read() 上，等待数据到达。但是 TCP 是个全双工协议，同时支持 read() 和 write() 操作，当一个线程/进程阻塞在 read() 上，但程序又想给这个 TCP 连接发数据，那该怎么办？比如说 echo client，既要从 stdin 读，又要从网络读，当程序正在阻塞地读网络的时候，如何处理键盘输入？又比如 proxy，既要把连接 a 收到的数据发给连接 b，又要把从连接 b 收到的数据发给连接 a，那么到底读哪个？（proxy 是《谈一谈网络编程学习经验》中举的三大 TCP 网络编程案例之一。）

一种方法是用两个线程/进程，一个负责读，一个负责写。UNP 也在实现 echo client 时介绍了这种方案。另外见 Python Pinhole 的代码：http://code.activestate.com/recipes/114642/

另一种方法是使用 IO multiplexing，也就是 select/poll/epoll/kqueue 这一系列的“多路选择器”，让一个 thread-of-control 能处理多个连接。“IO 复用”其实复用的不是 IO 连接，而是复用线程。使用 select/poll 几乎肯定要配合 non-blocking IO，而使用 non-blocking IO 肯定要使用应用层 buffer，原因见《Muduo 设计与实现之一：Buffer 类的设计》。这就不是一件轻松的事儿了，如果每个程序都去搞一套自己的 IO multiplexing 机制（本质是 event-driven 事件驱动），这是一种很大的浪费。感谢 Doug Schmidt 为我们总结出了 Reactor 模式，让 event-driven 网络编程有章可循。继而出现了一些通用的 reactor 框架/库，比如 libevent、muduo、Netty、twisted、POE 等等，有了这些库，我想基本不用去编写阻塞式的网络程序了（特殊情况除外，比如 proxy 流量限制）。

单线程 reactor 的程序结构是（图片取自 Doug Lea 的演讲）：

方案 5：基本的单线程 reactor 方案，即前面的 server_basic.cc 程序。本文以它作为对比其他方案的基准点。这种方案的优点是由网络库搞定数据收发，程序只关心业务逻辑；缺点在前面已经谈了：适合 IO 密集的应用，不太适合 CPU 密集的应用，因为较难发挥多核的威力。

方案 6：这是一个过渡方案，收到 Sudoku 请求之后，不在 reactor 线程计算，而是创建一个新线程去计算，以充分利用多核 CPU。这是非常初级的多线程应用，因为它为每个请求（而不是每个连接）创建了一个新线程。这个开销可以用线程池来避免，即方案 8。这个方案还有一个特点是 out-of-order，即同时创建多个线程去计算同一个连接上收到的多个请求，那么算出结果的次序是不确定的，可能第 2 个 Sudoku 比较简单，比第 1 个先算出结果。这也是为什么我们在一开始设计协议的时候使用了 id，以便客户端区分 response 对应的是哪个 request。

方案 7：为了让返回结果的顺序确定，我们可以为每个连接创建一个计算线程，每个连接上的请求固定发给同一个线程去算，先到先得。这也是一个过渡方案，因为并发连接数受限于线程数目，这个方案或许还不如直接使用阻塞 IO 的 thread-per-connection 方案2。方案 7 与方案 6 的另外一个区别是一个 client 的最大 CPU 占用率，在方案 6 中，一个 connection 上发来的一长串突发请求(burst requests) 可以占满全部 8 个 core；而在方案 7 中，由于每个连接上的请求固定由同一个线程处理，那么它最多占用 12.5% 的 CPU 资源。这两种方案各有优劣，取决于应用场景的需要，到底是公平性重要还是突发性能重要。这个区别在方案 8 和方案 9 中同样存在，需要根据应用来取舍。

方案 8：为了弥补方案 6 中为每个请求创建线程的缺陷，我们使用固定大小线程池，程序结构如下图。全部的 IO 工作都在一个 reactor 线程完成，而计算任务交给 thread pool。如果计算任务彼此独立，而且 IO 的压力不大，那么这种方案是非常适用的。Sudoku Solver 正好符合。代码见：http://code.google.com/p/muduo/source/browse/trunk/examples/sudoku/server_threadpool.cc 后文给出了它与方案 9 的区别。

如果 IO 的压力比较大，一个 reactor 忙不过来，可以试试 multiple reactors 的方案 9。

方案 9：这是 muduo 内置的多线程方案，也是 Netty 内置的多线程方案。这种方案的特点是 one loop per thread，有一个 main reactor 负责 accept 连接，然后把连接挂在某个 sub reactor 中（muduo 采用 round-robin 的方式来选择 sub reactor），这样该连接的所有操作都在那个 sub reactor 所处的线程中完成。多个连接可能被分派到多个线程中，以充分利用 CPU。Muduo 采用的是固定大小的 reactor pool，池子的大小通常根据 CPU 核数确定，也就是说线程数是固定的，这样程序的总体处理能力不会随连接数增加而下降。另外，由于一个连接完全由一个线程管理，那么请求的顺序性有保证，突发请求也不会占满全部 8 个核（如果需要优化突发请求，可以考虑方案 10）。这种方案把 IO 分派给多个线程，防止出现一个 reactor 的处理能力饱和。与方案 8 的线程池相比，方案 9 减少了进出 thread pool 的两次上下文切换。我认为这是一个适应性很强的多线程 IO 模型，因此把它作为 muduo 的默认线程模型。

代码见：http://code.google.com/p/muduo/source/browse/trunk/examples/sudoku/server_multiloop.cc

server_multiloop.cc 与 server_basic.cc 的区别很小，关键只有一行代码：server_.setThreadNum(numThreads);

$ diff server_basic.cc server_multiloop.cc -up
--- server_basic.cc     2011-06-15 13:40:59.000000000 +0800
+++ server_multiloop.cc 2011-06-15 13:39:53.000000000 +0800
@@ -21,19 +21,22 @@ using namespace muduo::net;
 class SudokuServer
 {
  public:
-  SudokuServer(EventLoop* loop, const InetAddress& listenAddr)
+  SudokuServer(EventLoop* loop, const InetAddress& listenAddr, int numThreads)
     : loop_(loop),
       server_(loop, listenAddr, "SudokuServer"),
+      numThreads_(numThreads),
       startTime_(Timestamp::now())
   {
     server_.setConnectionCallback(
         boost::bind(&SudokuServer::onConnection, this, _1));
     server_.setMessageCallback(
         boost::bind(&SudokuServer::onMessage, this, _1, _2, _3));
+    server_.setThreadNum(numThreads);
   }

方案 8 使用 thread pool 的代码与使用多 reactors 的方案 9 相比变化不大，只是把原来 onMessage() 中涉及计算和发回响应的部分抽出来做成一个函数，然后交给 ThreadPool 去计算。记住方案 8 有 out-of-order 的可能，客户端要根据 id 来匹配响应。

$ diff server_multiloop.cc server_threadpool.cc -up
--- server_multiloop.cc 2011-06-15 13:39:53.000000000 +0800
+++ server_threadpool.cc        2011-06-15 14:07:52.000000000 +0800
@@ -31,12 +32,12 @@ class SudokuServer
         boost::bind(&SudokuServer::onConnection, this, _1));
     server_.setMessageCallback(
         boost::bind(&SudokuServer::onMessage, this, _1, _2, _3));
-    server_.setThreadNum(numThreads);
   }

   void start()
   {
     LOG_INFO << "starting " << numThreads_ << " threads.";
+    threadPool_.start(numThreads_);
     server_.start();
   }

@@ -68,15 +69,7 @@ class SudokuServer
         }
         if (request.size() == implicit_cast<size_t>(kCells))
         {
-          string result = solveSudoku(request);
-          if (id.empty())
-          {
-            conn->send(result+"\r\n");
-          }
-          else
-          {
-            conn->send(id+":"+result+"\r\n");
-          }
+          threadPool_.run(boost::bind(solve, conn, request, id));
         }
         else
         {
@@ -91,8 +84,23 @@ class SudokuServer
     }
   }

+  static void solve(const TcpConnectionPtr& conn, const string& request, const string& id)
+  {
+    LOG_DEBUG << conn->name();
+    string result = solveSudoku(request);
+    if (id.empty())
+    {
+      conn->send(result+"\r\n");
+    }
+    else
+    {
+      conn->send(id+":"+result+"\r\n");
+    }
+  }
+
   EventLoop* loop_;
   TcpServer server_;
+  ThreadPool threadPool_;
   int numThreads_;
   Timestamp startTime_;
 };

完整代码见：http://code.google.com/p/muduo/source/browse/trunk/examples/sudoku/server_threadpool.cc

方案 10：把方案 8 和方案 9 混合，既使用多个 reactors 来处理 IO，又使用线程池来处理计算。这种方案适合既有突发 IO （利用多线程处理多个连接上的 IO），又有突发计算的应用（利用线程池把一个连接上的计算任务分配给多个线程去做）。

这种其实方案看起来复杂，其实写起来很简单，只要把方案 8 的代码加一行 server_.setThreadNum(numThreads); 就行，这里就不举例了。

结语

我在《多线程服务器的常用编程模型》一文中说

总结起来，我推荐的多线程服务端编程模式为：event loop per thread + thread pool。

• event loop 用作 non-blocking IO 和定时器。
• thread pool 用来做计算，具体可以是任务队列或消费者-生产者队列。

当时（2010年2月）我还说“以这种方式写服务器程序，需要一个优质的基于 Reactor 模式的网络库来支撑，我只用过in-house的产品，无从比较并推荐市面上常见的 C++ 网络库，抱歉。”

现在有了 muduo 网络库，我终于能够用具体的代码示例把思想完整地表达出来。

陈硕

giantchen@gmail.com

blog.csdn.net/Solstice

2011-06-08

PDF 版下载：https://github.com/downloads/chenshuo/documents/LearningNetworkProgramming.pdf

本文谈一谈我在学习网络编程方面的一些个人经验。“网络编程”这个术语的范围很广，本文指用Sockets API开发基于TCP/IP的网络应用程序，具体定义见“网络编程的各种任务角色”一节。

受限于本人的经历和经验，这篇文章的适应范围是：

· x86-64 Linux服务端网络编程，直接或间接使用 Sockets API

· 公司内网。不一定是局域网，但总体位于公司防火墙之内，环境可控

本文可能不适合：

· PC客户端网络编程，程序运行在客户的PC上，环境多变且不可控

· Windows网络编程

· 面向公网的服务程序

· 高性能网络服务器

本文分两个部分：

1. 网络编程的一些胡思乱想，谈谈我对这一领域的认识

2. 几本必看的书，基本上还是W. Richard Stevents那几本

另外，本文没有特别说明时均暗指TCP协议，“连接”是“TCP连接”，“服务端”是“TCP服务端”。

网络编程的一些胡思乱想

以下胡乱列出我对网络编程的一些想法，前后无关联。

网络编程是什么？

网络编程是什么？是熟练使用Sockets API吗？说实话，在实际项目里我只用过两次Sockets API，其他时候都是使用封装好的网络库。

第一次是2005年在学校做一个羽毛球赛场计分系统：我用C# 编写运行在PC机上的软件，负责比分的显示；再用C# 写了运行在PDA上的计分界面，记分员拿着PDA记录比分；这两部分程序通过 TCP协议相互通信。这其实是个简单的分布式系统，体育馆有不止一片场地，每个场地都有一名拿PDA的记分员，每个场地都有两台显示比分的PC机（显示器是42吋平板电视，放在场地的对角，这样两边看台的观众都能看到比分）。这两台PC机功能不完全一样，一台只负责显示当前比分，另一台还要负责与PDA通信，并更新数据库里的比分信息。此外，还有一台PC机负责周期性地从数据库读出全部7片场地的比分，显示在体育馆墙上的大屏幕上。这台PC上还运行着一个程序，负责生成比分数据的静态页面，通过FTP上传发布到某门户网站的体育频道。系统中还有一个录入赛程（参赛队，运动员，出场顺序等）数据库的程序，运行在数据库服务器上。算下来整个系统有十来个程序，运行在二十多台设备（PC和PDA）上，还要考虑可靠性。将来有机会把这个小系统仔细讲一讲，挺有意思的。

这是我第一次写实际项目中的网络程序，当时写下来的感觉是像写命令行与用户交互的程序：程序在命令行输出一句提示语，等待客户输入一句话，然后处理客户输入，再输出下一句提示语，如此循环。只不过这里的“客户”不是人，而是另一个程序。在建立好TCP连接之后，双方的程序都是read/write循环（为求简单，我用的是blocking读写），直到有一方断开连接。

第二次是2010年编写muduo网络库，我再次拿起了Sockets API，写了一个基于Reactor模式的C++ 网络库。写这个库的目的之一就是想让日常的网络编程从Sockets API的琐碎细节中解脱出来，让程序员专注于业务逻辑，把时间用在刀刃上。Muduo 网络库的示例代码包含了几十个网络程序，这些示例程序都没有直接使用Sockets API。

在此之外，无论是实习还是工作，虽然我写的程序都会通过TCP协议与其他程序打交道，但我没有直接使用过Sockets API。对于TCP网络编程，我认为核心是处理“三个半事件”，见《Muduo 网络编程示例之零：前言》中的“TCP 网络编程本质论”。程序员的主要工作是在事件处理函数中实现业务逻辑，而不是和Sockets API较劲。

这里还是没有说清楚“网络编程”是什么，请继续阅读后文“网络编程的各种任务角色”。

学习网络编程有用吗？

以上说的是比较底层的网络编程，程序代码直接面对从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也大大有助于分析解决线上网络服务问题。

在什么平台上学习网络编程？

对于服务端网络编程，我建议在Linux上学习。

如果在10年前，这个问题的答案或许是FreeBSD，因为FreeBSD根正苗红，在2000年那一次互联网浪潮中扮演了重要角色，是很多公司首选的免费服务器操作系统。2000年那会儿Linux还远未成熟，连epoll都还没有实现。（FreeBSD在2001年发布4.1版，加入了kqueue，从此C10k不是问题。）

10年后的今天，事情起了变化，Linux成为了市场份额最大的服务器操作系统(http://en.wikipedia.org/wiki/Usage_share_of_operating_systems)。在Linux这种大众系统上学网络编程，遇到什么问题会比较容易解决。因为用的人多，你遇到的问题别人多半也遇到过；同样因为用的人多，如果真的有什么内核bug，很快就会得到修复，至少有work around的办法。如果用别的系统，可能一个问题发到论坛上半个月都不会有人理。从内核源码的风格看，FreeBSD更干净整洁，注释到位，但是无奈它的市场份额远不如Linux，学习Linux是更好的技术投资。

可移植性重要吗？

写网络程序要不要考虑移植性？这取决于项目需要，如果贵公司做的程序要卖给其他公司，而对方可能使用Windows、Linux、FreeBSD、Solaris、AIX、HP-UX等等操作系统，这时候考虑移植性。如果编写公司内部的服务器上用的网络程序，那么大可只关注一个平台，比如Linux。因为编写和维护可移植的网络程序的代价相当高，平台间的差异可能远比想象中大，即便是POSIX系统之间也有不小的差异（比如Linux没有SO_NOSIGPIPE选项），错误的返回码也大不一样。

我就不打算把muduo往Windows或其他操作系统移植。如果需要编写可移植的网络程序，我宁愿用libevent或者Java Netty这样现成的库，把脏活累活留给别人。

网络编程的各种任务角色

计算机网络是个 big topic，涉及很多人物和角色，既有开发人员，也有运维人员。比方说：公司内部两台机器之间 ping 不通，通常由网络运维人员解决，看看是布线有问题还是路由器设置不对；两台机器能ping通，但是程序连不上，经检查是本机防火墙设置有问题，通常由系统管理员解决；两台机器能连上，但是丢包很严重，发现是网卡或者交换机的网口故障，由硬件维修人员解决；两台机器的程序能连上，但是偶尔发过去的请求得不到响应，通常是程序bug，应该由开发人员解决。

本文主要关心开发人员这一角色。下面简单列出一些我能想到的跟网络打交道的编程任务，其中前三项是面向网络本身，后面几项是在计算机网络之上构建信息系统。

1. 开发网络设备，编写防火墙、交换机、路由器的固件 firmware

2. 开发或移植网卡的驱动

3. 移植或维护TCP/IP协议栈（特别是在嵌入式系统上）

4. 开发或维护标准的网络协议程序，HTTP、FTP、DNS、SMTP、POP3、NFS

5. 开发标准网络协议的“附加品”，比如HAProxy、squid、varnish等web load balancer

6. 开发标准或非标准网络服务的客户端库，比如ZooKeeper客户端库，memcached客户端库

7. 开发与公司业务直接相关的网络服务程序，比如即时聊天软件的后台服务器，网游服务器，金融交易系统，互联网企业用的分布式海量存储，微博发帖的内部广播通知，等等

8. 客户端程序中涉及网络的部分，比如邮件客户端中与 POP3、SMTP通信的部分，以及网游的客户端程序中与服务器通信的部分

本文所指的“网络编程”专指第7项，即在TCP/IP协议之上开发业务软件。

面向业务的网络编程的特点

跟开发通用的网络程序不同，开发面向公司业务的专用网络程序有其特点：

· 业务逻辑比较复杂，而且时常变化

如果写一个HTTP服务器，在大致实现HTTP /1.1标准之后，程序的主体功能一般不会有太大的变化，程序员会把时间放在性能调优和bug修复上。而开发针对公司业务的专用程序时，功能说明书（spec）很可能不如HTTP/1.1标准那么细致明确。更重要的是，程序是快速演化的。以即时聊天工具的后台服务器为例，可能第一版只支持在线聊天；几个月之后发布第二版，支持离线消息；又过了几个月，第三版支持隐身聊天；随后，第四版支持上传头像；如此等等。这要求程序员能快速响应新的业务需求，公司才能保持竞争力。

· 不一定需要遵循公认的通信协议标准

比方说网游服务器就没什么协议标准，反正客户端和服务端都是本公司开发，如果发现目前的协议设计有问题，两边一起改了就是了。

· 程序结构没有定论

对于高并发大吞吐的标准网络服务，一般采用单线程事件驱动的方式开发，比如HAProxy、lighttpd等都是这个模式。但是对于专用的业务系统，其业务逻辑比较复杂，占用较多的CPU资源，这种单线程事件驱动方式不见得能发挥现在多核处理器的优势。这留给程序员比较大的自由发挥空间，做好了横扫千军，做烂了一败涂地。

· 性能评判的标准不同

如果开发httpd这样的通用服务，必然会和开源的Nginx、lighttpd等高性能服务器比较，程序员要投入相当的精力去优化程序，才能在市场上占有一席之地。而面向业务的专用网络程序不一定有开源的实现以供对比性能，程序员通常更加注重功能的稳定性与开发的便捷性。性能只要一代比一代强即可。

· 网络编程起到支撑作用，但不处于主导地位

程序员的主要工作是实现业务逻辑，而不只是实现网络通信协议。这要求程序员深入理解业务。程序的性能瓶颈不一定在网络上，瓶颈有可能是CPU、Disk IO、数据库等等，这时优化网络方面的代码并不能提高整体性能。只有对所在的领域有深入的了解，明白各种因素的权衡(trade-off)，才能做出一些有针对性的优化。

几个术语

互联网上的很多口水战是由对同一术语的不同理解引起的，比我写的《多线程服务器的适用场合》就曾经人被说是“挂羊头卖狗肉”，因为这篇文章中举的 master例子“根本就算不上是个网络服务器。因为它的瓶颈根本就跟网络无关。”

· 网络服务器

“网络服务器”这个术语确实含义模糊，到底指硬件还是软件？到底是服务于网络本身的机器（交换机、路由器、防火墙、NAT），还是利用网络为其他人或程序提供服务的机器（打印服务器、文件服务器、邮件服务器）。每个人根据自己熟悉的领域，可能会有不同的解读。比方说或许有人认为只有支持高并发高吞吐的才算是网络服务器。

为了避免无谓的争执，我只用“网络服务程序”或者“网络应用程序”这种含义明确的术语。“开发网络服务程序”通常不会造成误解。

· 客户端？服务端？

在TCP网络编程里边，客户端和服务端很容易区分，主动发起连接的是客户端，被动接受连接的是服务端。当然，这个“客户端”本身也可能是个后台服务程序，HTTP Proxy对HTTP Server来说就是个客户端。

· 客户端编程？服务端编程？

但是“服务端编程”和“客户端编程”就不那么好区分。比如 Web crawler，它会主动发起大量连接，扮演的是HTTP客户端的角色，但似乎应该归入“服务端编程”。又比如写一个 HTTP proxy，它既会扮演服务端——被动接受 web browser 发起的连接，也会扮演客户端——主动向 HTTP server 发起连接，它究竟算服务端还是客户端？我猜大多数人会把它归入服务端编程。

那么究竟如何定义“服务端编程”？

服务端编程需要处理大量并发连接？也许是，也许不是。比如云风在一篇介绍网游服务器的博客http://blog.codingnow.com/2006/04/iocp_kqueue_epoll.html中就谈到，网游中用到的“连接服务器”需要处理大量连接，而“逻辑服务器”只有一个外部连接。那么开发这种网游“逻辑服务器”算服务端编程还是客户端编程呢？

我认为，“服务端网络编程”指的是编写没有用户界面的长期运行的网络程序，程序默默地运行在一台服务器上，通过网络与其他程序打交道，而不必和人打交道。与之对应的是客户端网络程序，要么是短时间运行，比如wget；要么是有用户界面（无论是字符界面还是图形界面）。本文主要谈服务端网络编程。

7x24重要吗？内存碎片可怕吗？

一谈到服务端网络编程，有人立刻会提出7x24运行的要求。对于某些网络设备而言，这是合理的需求，比如交换机、路由器。对于开发商业系统，我认为要求程序7x24运行通常是系统设计上考虑不周。具体见《分布式系统的工程化开发方法》第20页起。重要的不是7x24，而是在程序不必做到7x24的情况下也能达到足够高的可用性。一个考虑周到的系统应该允许每个进程都能随时重启，这样才能在廉价的服务器硬件上做到高可用性。

既然不要求7x24，那么也不必害怕内存碎片，理由如下：

· 64-bit系统的地址空间足够大，不会出现没有足够的连续空间这种情况。

· 现在的内存分配器（malloc及其第三方实现）今非昔比，除了memcached这种纯以内存为卖点的程序需要自己设计分配器之外，其他网络程序大可使用系统自带的malloc或者某个第三方实现。

· Linux Kernel也大量用到了动态内存分配。既然操作系统内核都不怕动态分配内存造成碎片，应用程序为什么要害怕？

· 内存碎片如何度量？有没有什么工具能为当前进程的内存碎片状况评个分？如果不能比较两种方案的内存碎片程度，谈何优化？

有人为了避免内存碎片，不使用STL容器，也不敢new/delete，这算是premature optimization还是因噎废食呢？

协议设计是网络编程的核心

对于专用的业务系统，协议设计是核心任务，决定了系统的开发难度与可靠性，但是这个领域还没有形成大家公认的设计流程。

系统中哪个程序发起连接，哪个程序接受连接？如果写标准的网络服务，那么这不是问题，按RFC来就行了。自己设计业务系统，有没有章法可循？以网游为例，到底是连接服务器主动连接逻辑服务器，还是逻辑服务器主动连接“连接服务器”？似乎没有定论，两种做法都行。一般可以按照“依赖->被依赖”的关系来设计发起连接的方向。

比新建连接难的是关闭连接。在传统的网络服务中（特别是短连接服务），不少是服务端主动关闭连接，比如daytime、HTTP/1.0。也有少部分是客户端主动关闭连接，通常是些长连接服务，比如 echo、chargen等。我们自己的业务系统该如何设计连接关闭协议呢？

服务端主动关闭连接的缺点之一是会多占用服务器资源。服务端主动关闭连接之后会进入TIME_WAIT状态，在一段时间之内hold住一些内核资源。如果并发访问量很高，这会影响服务端的处理能力。这似乎暗示我们应该把协议设计为客户端主动关闭，让TIME_WAIT状态分散到多台客户机器上，化整为零。

这又有另外的问题：客户端赖着不走怎么办？会不会造成拒绝服务攻击？或许有一个二者结合的方案：客户端在收到响应之后就应该主动关闭，这样把 TIME_WAIT 留在客户端。服务端有一个定时器，如果客户端若干秒钟之内没有主动断开，就踢掉它。这样善意的客户端会把TIME_WAIT留给自己，buggy的客户端会把 TIME_WAIT留给服务端。或者干脆使用长连接协议，这样避免频繁创建销毁连接。

比连接的建立与断开更重要的是设计消息协议。消息格式很好办，XML、JSON、Protobuf都是很好的选择；难的是消息内容。一个消息应该包含哪些内容？多个程序相互通信如何避免race condition（见《分布式系统的工程化开发方法》p.16的例子）？系统的全局状态该如何跃迁？可惜这方面可供参考的例子不多，也没有太多通用的指导原则，我知道的只有30年前提出的end-to-end principle和happens-before relationship。只能从实践中慢慢积累了。

网络编程的三个层次

侯捷先生在《漫談程序員與編程》中讲到 STL 运用的三个档次：“會用STL，是一種檔次。對STL原理有所了解，又是一個檔次。追蹤過STL源碼，又是一個檔次。第三種檔次的人用起 STL 來，虎虎生風之勢絕非第一檔次的人能夠望其項背。”

我认为网络编程也可以分为三个层次：

1. 读过教程和文档

2. 熟悉本系统TCP/IP协议栈的脾气

3. 自己写过一个简单的TCP/IP stack

第一个层次是基本要求，读过《Unix网络编程》这样的编程教材，读过《TCP/IP详解》基本理解TCP/IP协议，读过本系统的manpage。这个层次可以编写一些基本的网络程序，完成常见的任务。但网络编程不是照猫画虎这么简单，若是按照manpage的功能描述就能编写产品级的网络程序，那人生就太幸福了。

第二个层次，熟悉本系统的TCP/IP协议栈参数设置与优化是开发高性能网络程序的必备条件。摸透协议栈的脾气还能解决工作中遇到的比较复杂的网络问题。拿Linux的TCP/IP协议栈来说：

· 有可能出现自连接（见《学之者生，用之者死——ACE历史与简评》举的三个硬伤），程序应该有所准备。

· Linux的内核会有bug，比如某种TCP拥塞控制算法曾经出现TCP window clamping（窗口箝位）bug，导致吞吐量暴跌，可以选用其他拥塞控制算法来绕开(work around)这个问题。

这些阴暗角落在manpage里没有描述，要通过其他渠道了解。

编写可靠的网络程序的关键是熟悉各种场景下的error code（文件描述符用完了如何？本地ephemeral port暂时用完，不能发起新连接怎么办？服务端新建并发连接太快，backlog用完了，客户端connect会返回什么错误？），有的在manpage里有描述，有的要通过实践或阅读源码获得。

第三个层次，通过自己写一个简单的TCP/IP协议栈，能大大加深对TCP/IP的理解，更能明白TCP为什么要这么设计，有哪些因素制约，每一步操作的代价是什么，写起网络程序来更是成竹在胸。

其实实现TCP/IP只需要操作系统提供三个接口函数：一个函数，两个回调函数。分别是：send_packet()、on_receive_packet()、on_timer()。多年前有一篇文章《使用libnet与libpcap构造TCP/IP协议软件》介绍了在用户态实现TCP/IP的方法。lwIP也是很好的借鉴对象。

如果有时间，我打算自己写一个Mini/Tiny/Toy/Trivial/Yet-Another TCP/IP。我准备换一个思路，用TUN/TAP设备在用户态实现一个能与本机点对点通信的TCP/IP协议栈，这样那三个接口函数就表现为我最熟悉的文件读写。在用户态实现的好处是便于调试，协议栈做成静态库，与应用程序链接到一起（库的接口不必是标准的Sockets API）。做完这一版，还可以继续发挥，用FTDI的USB-SPI接口芯片连接ENC28J60适配器，做一个真正独立于操作系统的TCP/IP stack。如果只实现最基本的IP、ICMP Echo、TCP的话，代码应能控制在3000行以内；也可以实现UDP，如果应用程序需要用到DNS的话。

最主要的三个例子

我认为TCP网络编程有三个例子最值得学习研究，分别是echo、chat、proxy，都是长连接协议。

Echo的作用：熟悉服务端被动接受新连接、收发数据、被动处理连接断开。每个连接是独立服务的，连接之间没有关联。在消息内容方面Echo有一些变种：比如做成一问一答的方式，收到的请求和发送响应的内容不一样，这时候要考虑打包与拆包格式的设计，进一步还可以写简单的HTTP服务。

Chat的作用：连接之间的数据有交流，从a收到的数据要发给b。这样对连接管理提出的更高的要求：如何用一个程序同时处理多个连接？fork() per connection似乎是不行的。如何防止串话？b有可能随时断开连接，而新建立的连接c可能恰好复用了b的文件描述符，那么a会不会错误地把消息发给c？

Proxy的作用：连接的管理更加复杂：既要被动接受连接，也要主动发起连接，既要主动关闭连接，也要被动关闭连接。还要考虑两边速度不匹配，见《Muduo 网络编程示例之十：socks4a 代理服务器》。

这三个例子功能简单，突出了TCP网络编程中的重点问题，挨着做一遍基本就能达到层次一的要求。

TCP的可靠性有多高？

TCP是“面向连接的、可靠的、字节流传输协议”，这里的“可靠”究竟是什么意思？《Effective TCP/IP Programming》第9条说：Realize That TCP Is a Reliable Protocol, Not an Infallible Protocol，那么TCP在哪种情况下会出错？这里说的“出错”指的是收到的数据与发送的数据不一致，而不是数据不可达。

我在《一种自动反射消息类型的 Google Protobuf 网络传输方案》中设计了带check sum的消息格式，很多人表示不理解，认为是多余的。IP header里边有check sum，TCP header也有check sum，链路层以太网还有CRC32校验，那么为什么还需要在应用层做校验？什么情况下TCP传送的数据会出错？

IP header和TCP header的check sum是一种非常弱的16-bit check sum算法，把数据当成反码表示的16-bit integers，再加到一起。这种checksum算法能检出一些简单的错误，而对某些错误无能为力，由于是简单的加法，遇到“和”不变的情况就无法检查出错误（比如交换两个16-bit整数，加法满足交换律，结果不变）。以太网的CRC32只能保证同一个网段上的通信不会出错（两台机器的网线插到同一个交换机上，这时候以太网的CRC是有用的）。但是，如果两台机器之间经过了多级路由器呢？

上图中Client向Server发了一个TCP segment，这个segment先被封装成一个IP packet，再被封装成ethernet frame，发送到路由器（图中消息a）。Router收到ethernet frame (b)，转发到另一个网段(c)，最后Server收到d，通知应用程序。Ethernet CRC能保证a和b相同，c和d相同；TCP header check sum的强度不足以保证收发payload的内容一样。另外，如果把Router换成NAT，那么NAT自己会构造c（替换掉源地址），这时候a和d的payload不能用tcp header checksum校验。

路由器可能出现硬件故障，比方说它的内存故障（或偶然错误）导致收发IP报文出现多bit的反转或双字节交换，这个反转如果发生在payload区，那么无法用链路层、网络层、传输层的check sum查出来，只能通过应用层的check sum来检测。这个现象在开发的时候不会遇到，因为开发用的几台机器很可能都连到同一个交换机，ethernet CRC能防止错误。开发和测试的时候数据量不大，错误很难发生。之后大规模部署到生产环境，网络环境复杂，这时候出个错就让人措手不及。有一篇论文《When the CRC and TCP checksum disagree》分析了这个问题。另外《The Limitations of the Ethernet CRC and TCP/IP checksums for error detection》(http://noahdavids.org/self_published/CRC_and_checksum.html)也值得一读。

这个情况真的会发生吗？会的，Amazon S3 在2008年7月就遇到过，单bit反转导致了一次严重线上事故，所以他们吸取教训加了 check sum。见http://status.aws.amazon.com/s3-20080720.html

另外一个例证：下载大文件的时候一般都会附上MD5，这除了有安全方面的考虑（防止篡改），也说明应用层应该自己设法校验数据的正确性。这是end-to-end principle的一个例证。

三本必看的书

谈到Unix编程和网络编程，W. Richard Stevens 是个绕不开的人物，他生前写了6本书，APUE、两卷UNP、三卷TCP/IP。有四本与网络编程直接相关。UNP第二卷其实跟网络编程关系不大，是APUE在多线程和进程间通信(IPC)方面的补充。很多人把TCP/IP一二三卷作为整体推荐，其实这三本书用处不同，应该区别对待。

这里谈到的几本书都没有超出孟岩在《TCP/IP 网络编程之四书五经》中的推荐，说明网络编程这一领域已经相对成熟稳定。

· 《TCP/IP Illustrated, Vol. 1: The Protocols》中文名《TCP/IP 详解》，以下简称 TCPv1。

TCPv1 是一本奇书。

这本书迄今至少被三百多篇学术论文引用过http://portal.acm.org/citation.cfm?id=161724。一本学术专著被论文引用算不上出奇，难得的是一本写给程序员看的技术书能被学术论文引用几百次，我不知道还有哪本技术书能做到这一点。

TCPv1 堪称 TCP/IP领域的圣经。作者 W. Richard Stevens 不是 TCP/IP 协议的发明人，他从使用者（程序员）的角度，以 tcpdump 为工具，对 TCP 协议抽丝剥茧娓娓道来（第17~24章），让人叹服。恐怕 TCP 协议的设计者也难以讲解得如此出色，至少不会像他这么耐心细致地画几百幅收发 package 的时序图。

TCP作为一个可靠的传输层协议，其核心有三点：

1. Positive acknowledgement with retransmission

2. Flow control using sliding window（包括Nagle 算法等）

3. Congestion control（包括slow start、congestion avoidance、fast retransmit等）

第一点已经足以满足“可靠性”要求（为什么？）；第二点是为了提高吞吐量，充分利用链路层带宽；第三点是防止过载造成丢包。换言之，第二点是避免发得太慢，第三点是避免发得太快，二者相互制约。从反馈控制的角度看，TCP像是一个自适应的节流阀，根据管道的拥堵情况自动调整阀门的流量。

TCP的 flow control 有一个问题，每个TCP connection是彼此独立的，保存有自己的状态变量；一个程序如果同时开启多个连接，或者操作系统中运行多个网络程序，这些连接似乎不知道他人的存在，缺少对网卡带宽的统筹安排。（或许现代的操作系统已经解决了这个问题？）

TCPv1 唯一的不足是它出版太早了，1993 年至今网络技术发展了几代。链路层方面，当年主流的 10Mbit 网卡和集线器早已经被淘汰；100Mbit 以太网也没什么企业在用了，交换机(switch)也已经全面取代了集线器(hub)；服务器机房以 1Gbit 网络为主，有些场合甚至用上了 10Gbit 以太网。另外，无线网的普及也让TCP flow control面临新挑战；原来设计TCP的时候，人们认为丢包通常是拥塞造成的，这时应该放慢发送速度，减轻拥塞；而在无线网中，丢包可能是信号太弱造成的，这时反而应该快速重试，以保证性能。网络层方面变化不大，IPv6 雷声大雨点小。传输层方面，由于链路层带宽大增，TCP window scale option 被普遍使用，另外 TCP timestamps option 和 TCP selective ack option 也很常用。由于这些因素，在现在的 Linux 机器上运行 tcpdump 观察 TCP 协议，程序输出会与原书有些不同。

一个好消息：TCPv1将于今年10月（2011年）推出第二版，Amazon 的预定页面是：http://www.amazon.com/gp/product/0321336313，让我们拭目以待。

· 《Unix Network Programming, Vol. 1: Networking API》第二版或第三版（这两版的副标题稍有不同，第三版去掉了 XTI），以下统称 UNP，如果需要会以 UNP2e、UNP3e 细分。

UNP是Sockets API的权威指南，但是网络编程远不是使用那十几个Sockets API那么简单，作者 W. Richard Stevens深刻地认识到这一点，他在UNP2e的前言中写到：http://www.kohala.com/start/preface.unpv12e.html

I have found when teaching network programming that about 80% of all network programming problems have nothing to do with network programming, per se. That is, the problems are not with the API functions such as accept and select, but the problems arise from a lack of understanding of the underlying network protocols. For example, I have found that once a student understands TCP's three-way handshake and four-packet connection termination, many network programming problems are immediately understood.

搞网络编程，一定要熟悉TCP/IP协议及其外在表现（比如打开和关闭Nagle算法对收发包的影响），不然出点意料之外的情况就摸不着头脑了。我不知道为什么UNP3e在前言中去掉了这段至关重要的话。

另外值得一提的是，UNP中文版翻译得相当好，译者杨继张先生是真懂网络编程的。

UNP很详细，面面俱到，UDP、TCP、IPv4、IPv6都讲到了。要说有什么缺点的话，就是太详细了，重点不够突出。我十分赞同孟岩说的

“（孟岩）我主张，在具备基础之后，学习任何新东西，都要抓住主线，突出重点。对于关键理论的学习，要集中精力，速战速决。而旁枝末节和非本质性的知识内容，完全可以留给实践去零敲碎打。

“原因是这样的，任何一个高级的知识内容，其中都只有一小部分是有思想创新、有重大影响的，而其它很多东西都是琐碎的、非本质的。因此，集中学习时必须把握住真正重要那部分，把其它东西留给实践。对于重点知识，只有集中学习其理论，才能确保体系性、连贯性、正确性，而对于那些旁枝末节，只有边干边学能够让你了解它们的真实价值是大是小，才能让你留下更生动的印象。如果你把精力用错了地方，比如用集中大块的时间来学习那些本来只需要查查手册就可以明白的小技巧，而对于真正重要的、思想性东西放在平时零敲碎打，那么肯定是事倍功半，甚至适得其反。

“因此我对于市面上绝大部分开发类图书都不满——它们基本上都是面向知识体系本身的，而不是面向读者的。总是把相关的所有知识细节都放在一堆，然后一堆一堆攒起来变成一本书。反映在内容上，就是毫无重点地平铺直叙，不分轻重地陈述细节，往往在第三章以前就用无聊的细节谋杀了读者的热情。为什么当年侯捷先生的《深入浅出MFC》和 Scott Meyers 的 Effective C++ 能够成为经典？就在于这两本书抓住了各自领域中的主干，提纲挈领，纲举目张，一下子打通读者的任督二脉。可惜这样的书太少，就算是已故 Richard Stevens 和当今 Jeffrey Richter 的书，也只是在体系性和深入性上高人一头，并不是面向读者的书。”

什么是旁枝末节呢？拿以太网来说，CRC32如何计算就是“旁枝末节”。网络程序员要明白check sum的作用，知道为什么需要check sum，至于具体怎么算CRC就不需要程序员操心。这部分通常是由网卡硬件完成的，在发包的时候由硬件填充CRC，在收包的时候网卡自动丢弃CRC不合格的包。如果代码里边确实要用到CRC计算，调用通用的zlib就行，也不用自己实现。

UNP就像给了你一堆做菜的原料（各种Sockets 函数的用法），常用和不常用的都给了（Out-of-Band Data、Signal-Driven IO 等等），要靠读者自己设法取舍组合，做出一盘大菜来。在第一遍读的时候，我建议只读那些基本且重要的章节；另外那些次要的内容可略作了解，即便跳过不读也无妨。UNP是一本操作性很强的书，读这本这本书一定要上机练习。

另外，UNP举的两个例子（菜谱）太简单，daytime和echo一个是短连接协议，一个是长连接无格式协议，不足以覆盖基本的网络开发场景（比如 TCP封包与拆包、多连接之间交换数据）。我估计 W. Richard Stevens 原打算在 UNP第三卷中讲解一些实际的例子，只可惜他英年早逝，我等无福阅读。

UNP是一本偏重Unix传统的书，这本书写作的时候服务端还不需要处理成千上万的连接，也没有现在那么多网络攻击。书中重点介绍的以accept()+fork()来处理并发连接的方式在现在看来已经有点吃力，这本书的代码也没有特别防范恶意攻击。如果工作涉及这些方面，需要再进一步学习专门的知识（C10k问题，安全编程）。

TCPv1和UNP应该先看哪本？我不知道。我自己是先看的TCPv1，花了大约半学期时间，然后再读UNP2e和APUE。

· 《Effective TCP/IP Programming》

第三本书我犹豫了很久，不知道该推荐哪本，还有哪本书能与 W. Richard Stevens 的这两本比肩吗？W. Richard Stevens 为技术书籍的写作树立了难以逾越的标杆，他是一位伟大的技术作家。没能看到他写完 UNP 第三卷实在是人生的遗憾。

《Effective TCP/IP Programming》这本书属于专家经验总结类，初看时觉得收获很大，工作一段时间再看也能有新的发现。比如第6 条“TCP是一个字节流协议”，看过这一条就不会去研究所谓的“TCP粘包问题”。我手头这本电力社2001年的中文版翻译尚可，但是很狗血的是把参考文献去掉了，正文中引用的文章资料根本查不到名字。人邮2011年重新翻译出版的版本有参考文献。

其他值得一看的书

以下两本都不易读，需要相当的基础。

· 《TCP/IP Illustrated, Vol. 2: The Implementation》以下简称 TCPv2

1200页的大部头，详细讲解了4.4BSD的完整TCP/IP协议栈，注释了15,000行C源码。这本书啃下来不容易，如果时间不充裕，我认为没必要啃完，应用层的网络程序员选其中与工作相关的部分来阅读即可。

这本书第一作者是Gary Wright，从叙述风格和内容组织上是典型的“面向知识体系本身”，先讲mbuf，再从链路层一路往上、以太网、IP网络层、ICMP、IP多播、IGMP、IP路由、多播路由、Sockets系统调用、ARP等等。到了正文内容3/4的地方才开始讲TCP。面面俱到、主次不明。

对于主要使用TCP的程序员，我认为TCPv2一大半内容可以跳过不看，比如路由表、IGMP等等（开发网络设备的人可能更关心这些内容）。在工作中大可以把IP视为host-to-host的协议，把“IP packet如何送达对方机器”的细节视为黑盒子，这不会影响对TCP的理解和运用，因为网络协议是分层的。这样精简下来，需要看的只有三四百页，四五千行代码，大大减轻了负担。

这本书直接呈现高质量的工业级操作系统源码，读起来有难度，读懂它甚至要有“不求甚解的能力”。其一，代码只能看，不能上机运行，也不能改动试验。其二，与操作系统其他部分紧密关联。比如TCP/IP stack下接网卡驱动、软中断；上承inode转发来的系统调用操作；中间还要与平级的进程文件描述符管理子系统打交道；如果要把每一部分都弄清楚，把持不住就迷失主题了。其三，一些历史包袱让代码变复杂晦涩。比如BSD在80年代初需要在只有4M内存的VAX上实现TCP/IP，内存方面捉襟见肘，这才发明了mbuf结构，代码也增加了不少偶发复杂度（buffer不连续的处理）。

读这套TCP/IP书切忌胶柱鼓瑟，这套书以4.4BSD为底，其描述的行为（特别是与timer相关的行为）与现在的Linux TCP/IP有不小的出入，用书本上的知识直接套用到生产环境的Linux系统可能会造成不小的误解和困扰。（TCPv3不重要，可以成套买来收藏，不读亦可。）

· 《Pattern-Oriented Software Architecture Volume 2: Patterns for Concurrent and Networked Objects》以下简称POSA2

这本书总结了开发并发网络服务程序的模式，是对UNP很好的补充。UNP中的代码往往把业务逻辑和Sockets API调用混在一起，代码固然短小精悍，但是这种编码风格恐怕不适合开发大型的网络程序。POSA2强调模块化，网络通信交给library/framework去做，程序员写代码只关注业务逻辑，这是非常重要的思想。阅读这本书对于深入理解常用的event-driven网络库（libevent、Java Netty、Java Mina、Perl POE、Python Twisted等等）也很有帮助，因为这些库都是依照这本书的思想编写的。

POSA2的代码是示意性的，思想很好，细节不佳。其C++ 代码没有充分考虑资源的自动化管理(RAII)，如果直接按照书中介绍的方式去实现网络库，那么会给使用者造成不小的负担与陷阱。换言之，照他说的做，而不是照他做的学。

不值一看的书

Douglas Comer 教授名气很大，著作等身，但是他写的网络方面的书不值一读，味同嚼蜡。网络编程与 TCP/IP 方面，有W. Richard Stevens 的书扛鼎；计算机网络原理方面，有Kurose的“自顶向下”和Peterson的“系统”打旗，没其他人什么事儿。顺便一提，Tanenbaum的操作系统教材是最好的之一（嗯，之二，因为他写了两本：“现代”和“设计与实现”），不过他的计算机网络和体系结构教材的地位比不上他的操作系统书的地位。体系结构方面，Patterson 和 Hennessy二人合作的两本书是最好的，近年来崭露头角的《深入理解计算机系统》也非常好；当然，侧重点不同。

(完)

陈硕 (giantchen_AT_gmail)

Blog.csdn.net/Solstice  t.sina.com.cn/giantchen

这是《Muduo 网络编程示例》系列的第十篇文章，本系列暂告一段落。

Muduo 全系列文章列表： http://blog.csdn.net/Solstice/category/779646.aspx

本文介绍用 muduo 实现一个简单的 socks4a 代理服务器，代码见 http://code.google.com/p/muduo/source/browse/trunk/examples/socks4a/ 。

TCP 中继器

在实现 socks4a proxy 之前，我们先写一个功能更简单的网络程序—— TCP 中继器 (TCP relay)，或者叫做穷人的 tcpdump (poor man's tcpdump)。

一般情况下，客户端程序直接连接服务端，如下图。有时候，我们想在 client 和 server 之间放一个中继器 (relay)，把 client 与 server 之间的通信内容记录下来。这时用 tcpdump 是最方便省事的，但是 tcpdump 需要 root 权限，万一没有 root 密码呢？穷人有穷人的办法，自己写一个 relay，让 client 连接 relay，再让 relay 连接 server，如下图中的 T 型结构，relay 扮演了类似 proxy 的角色。

TcpRelay 是我们自己写的，可以动动手脚。除了记录通信内容，还可以制造延时，或者故意翻转 1 bit 数据以模拟 router 硬件故障。

TcpRelay 的功能（业务逻辑）看上去很简单，无非是把连接 C 上收到的数据发给连接 S，同时把连接 S 上收到的数据发给连接 C。但仔细考虑起来，细节其实不那么简单：

• 建立连接。为了真实模拟 client，TcpRelay 在 accept 连接 C 之后才向 server 发起连接 S，那么在 S 建立起来之前，从 C 收到数据怎么办？要不要暂存起来？
• 并发连接的管理。上图中只画出了一个 client，实际上 TcpRelay 可以服务多个 clients，左右两边这些并发连接如何管理，如何防止串话(cross talk)？
• 连接断开。Client 和 Server 都可能主动断开连接。当 Client 主动断开连接 C 时，TcpRelay 应该立刻断开 S。当 Server 主动断开连接 S 时，TcpRelay 应立刻断开 C。这样才能比较精确地模拟 Client 和 Server 的行为。在关闭连接的刹那，又有新的 client 连接进来，复用了刚刚 close 的 fd 号码，会不会造成串话？ 万一 Client 和 Server 几乎同时主动断开连接，TcpRelay 如何应对？
• 速度不匹配。如果连接 C 的带宽是 100KB/s，而连接 S 的带宽是 10MB/s，不巧 Server 是个 chargen 服务，会全速发送数据，那么会不会撑爆 TcpRelay 的 buffer？如何限速？特别是在使用 non-blocking IO 和 level-trigger polling 的时候如何限制读取数据的速度？

在看 muduo 的实现之前，请读者思考：如果用 Sockets API 来实现 TcpRelay，如何解决以上这些问题。

TcpRelay 的实现很简单，只有几十行代码 http://code.google.com/p/muduo/source/browse/trunk/examples/socks4a/tcprelay.cc，主要逻辑都在 Tunnel class 里

http://code.google.com/p/muduo/source/browse/trunk/examples/socks4a/tunnel.h 。这个实现解决了前三个问题，第四个留给将来吧。

Socks4a 代理服务器

Socks4a 的功能与 TcpRelay 非常相似，也是把连接 C 上收到的数据发给连接 S，同时把连接 S 上收到的数据发给连接 C。它与 TcpRelay 的区别在于，TcpRelay 固定连到某个 server 地址，而 socks4a 允许 client 指定要连哪个 server。在 accept 连接 C 之后，Socks4a server 会读几个字节，以了解 server 的地址，再发起连接 S。

Socks4a 的协议非常简单，请参考维基百科 http://en.wikipedia.org/wiki/SOCKS#SOCKS_4a 。

muduo 的 socks4a 代理服务器的实现在 http://code.google.com/p/muduo/source/browse/trunk/examples/socks4a/socks4a.cc，它也使用了 Tunnel class。与 TcpRelay 相比，只多了解析 server 地址这一步骤。

muduo 这个 socks4a 是个标准的网络服务，可以供 Web 浏览器使用（我正是这么测试它的）。

n:1 与 1:n 连接转发

云风在《写了一个 proxy 用途你懂的》中写了一个 TCP 隧道 tunnel，程序由三部分组成：n:1 连接转发服务，1:n 连接转发服务，socks 代理服务。

我仿照他的思路，用 muduo 实现了这三个程序。不同的是，我没有做数据混淆，所以不能用来翻传说中的墙。

• n:1 连接转发服务就是《Muduo 网络编程示例之七：“串并转换”连接服务器及其自动化测试》中的 multiplexer (数据选择器)。
• 1:n 连接转发服务是该文提到的 backend，一个数据分配器(demultiplexer)，代码在 http://code.google.com/p/muduo/source/browse/trunk/examples/multiplexer/demux.cc
• socks 代理服务正是本文实现的 socks4a。

有兴趣的读者可以把这三个程序级联起来试一试。

Muduo 编程示例系列告一段落

《Muduo 网络编程示例》从今年2月初开始写，到今天正好是四个月，我写了十一篇博客，基本按计划完成了任务。这个系列暂告一段落。

这个系列基本涵盖了 muduo 为编写单线程服务端和客户端 TCP 网络程序提供的功能，muduo 的能力不止于此：

• 多线程，muduo::net::TcpServer 内置了一个简单但适应性很强的线程模型。目前博客上的例子涉及的业务逻辑很简单，没有复杂的运算，瓶颈通常在 IO 上，多线程的优势发挥不出来。
• 高级应用。比方说用 muduo::net::Channel 配合 signalfd 来处理信号；其他非阻塞网络客户端库（例如 ZooKeeper 的 C 客户端，PostgreSQL 的客户端 libpq）与 muduo EventLoop 的集成。

以上两点在以后的文章里会提及，不会明珠暗藏。

Muduo 在 2010 年 8 月底发布 0.1.0 版，随着这个编程示例系列文章的发表，迄今已发布了 14 次小升级，下载地址： http://code.google.com/p/muduo/downloads/list

接下来的计划

接下来，我还会写一系列博客，目前想到的有：

1. 谈一谈我的网络编程学习经验。文章已经完成大半，端午节之后可以发布。
2. muduo 设计与实现系列，介绍如何一步步实现一个非阻塞网络库。代码已经准备得差不多了，在 https://github.com/chenshuo/recipes/tree/master/reactor
3. 用 muduo 实现一些稍微复杂一些的网络程序，比如小规模的分布式系统。计划有：利用 Paxos 算法实现一个高可用的 in-memory key value 存储，在此基础上实现 naming service，然后实现我以前多次提到的简单机群管理系统等等。目前 muduo 的示例程序都是简单独立的网络程序，下半年我想多写一写由多个程序组成的系统，具体谈一谈分布式系统细节设计。

另外，我会逐步把已有的博客文章整理成 PDF 合集，方便下载保存，地址是： http://blog.csdn.net/Solstice/archive/2011/02/24/6206154.aspx

陈硕 (giantchen_AT_gmail)

Blog.csdn.net/Solstice  t.sina.com.cn/giantchen

这是《Muduo 网络编程示例》系列的第九篇文章，讲用 muduo 实现一个简单的 pub/sub 服务。

Muduo 全系列文章列表： http://blog.csdn.net/Solstice/category/779646.aspx

本文介绍用 muduo 实现一个简单的 topic-based 消息广播服务，这其实是“聊天室”的一个简单扩展，不过聊天的不是人，而是分布式系统中的程序。

本文的代码见 http://code.google.com/p/muduo/source/browse/trunk/examples/hub

在分布式系统中，除了常用的 end-to-end 通信，还有一对多的广播通信。一提到“广播”，或许会让人联想到 IP 多播或 IP 组播，这不是本文的主题。本文将要谈的是基于 TCP 协议的应用层广播。示意图如下：

上图中圆角矩形代表程序，"Hub"是一个服务程序，不是网络集线器，它起到类似集线器的作用，故而得名。Publisher 和 Subscriper 通过 TCP 协议与 Hub 程序通信。Publisher 把消息发到某个 topic 上，Subscribers 订阅该 topic，然后就能收到消息。即 publisher 借助 hub 把消息广播给了多个 subscribers。这种 pub/sub 结构的好处在于可以增加多个 Subscriber 而不用修改 Publisher，一定程度上实现了“解耦”（也可以看成分布式的 observer pattern）。 由于走的是 TCP 协议，广播是基本可靠的，这里的“可靠”指的是“比 UDP 可靠”，不是“完全可靠”。（思考：如何避免 Hub 成为 single point of failure？）

为了避免串扰（cross-talk），每个 topic 在同一时间只应该有一个 publisher，hub 不提供 compare-and-swap 操作。

（“可靠广播、原子广播”在分布式系统中有重大意义，是以 replicated state machine 方式实现可靠的分布式服务的基础，“可靠广播”涉及 consensus 算法，超出了本文的范围。）

应用层广播在分布式系统中用处很大，这里略举几例：

1. 体育比分转播。有 8 片比赛场地正在进行羽毛球比赛，每个场地的计分程序把当前比分发送到各自的 topic 上（第 1 号场地发送到 court1，第 2 号发送到 court2，以此类推）。需要用到比分的程序（赛场的大屏幕显示，网上比分转播等等）自己订阅感兴趣的 topic ，就能及时收到最新比分数据。由于本文实现的不是 100% 可靠广播，那么消息应该是 snapshot，而不是 incremental。（换句话说，消息的内容是“现在是几比几”，而不是“刚才谁得分”。）

2. 负载监控。每台机器上运行一个监控程序，周期性地把本机当前负载（CPU、网络、磁盘、温度）publish 到以 hostname 命名的 topic 上，这样需要用到这些数据的程序只要在 hub 订阅相应的 topic 就能获得数据，无需与多台机器直接打交道。（为了可靠起见，监控程序发送的消息里边应该包含时间戳，这样能防止 stale 数据，甚至一定程度上起到心跳的作用。）沿着这个思路，分布式系统中的服务程序也可以把自己的当前负载发布到 hub 上，供 load balancer 和 monitor 取用。

协议

为了简单起见，muduo 的 hub 示例采用以 '\r\n' 分界的文本协议，这样用 telnet 就能测试 hub。协议只有三个命令：

• sub <topic>\r\n
  • 该命令表示订阅 <topic>，以后该 topic 有任何跟新都会发给这个 tcp 连接。在 sub 的时候，hub 会把该 <topic> 上最近的消息发给此 subscriber。
• unsub <topic>\r\n
  • 该命令表示退订 <topic>
• pub <topic>\r\n<content>\r\n
  • 往 <topic> 发送消息，内容为 <content>。所有订阅了此 <topic> 的 subscribers 会收到同样的消息“pub <topic>\r\n<content>\r\n”

代码

muduo 示例中的 hub 分为几个部分：

• hub 服务程序，负责一对多的消息分发。它会记住每个 client 订阅了哪些 topic，只把消息发给特定的订阅者。代码见 http://code.google.com/p/muduo/source/browse/trunk/examples/hub/hub.cc
• pubsub 库，为了方便编写使用 hub 服务的应用程序，我写了一个简单的 client library，用来和 hub 打交道。这个 library 可以订阅 topic、退订 topic、往指定 topic 发布消息。代码见 http://code.google.com/p/muduo/source/browse/trunk/examples/hub/pubsub.h 和 http://code.google.com/p/muduo/source/browse/trunk/examples/hub/pubsub.cc
• sub 示例程序，这个命令行程序订阅一个或多个 topic，然后等待 hub 的数据。代码 http://code.google.com/p/muduo/source/browse/trunk/examples/hub/sub.cc
• pub 示例程序，这个命令行程序往某个 topic 发布一条消息，消息内容由命令行参数指定。代码 http://code.google.com/p/muduo/source/browse/trunk/examples/hub/pub.cc

一个程序可以既是 publisher 又是 subscriber，而且 pubsub 库只用一个 tcp 连接（这样 failover 比较简便）。

使用范例：

1. 开启 4 个命令行窗口
2. 在第一个窗口运行 $ hub 9999
3. 在第二个窗口运行 $ sub 127.0.0.1:9999 mytopic
4. 在第三个窗口运行 $ sub 127.0.0.1:9999 mytopic court
5. 在第四个窗口运行 $ pub 127.0.0.1:9999 mytopic "Hello world."  ，这时第二三号窗口都会打印 “mytopic: Hello world.”，表明收到了 mytopic 这个主题上的消息。
6. 在第四个窗口运行 $ pub 127.0.0.1:9999 court "13:11"  ，这时第三号窗口会打印 “court: 13:11”，表明收到了 court 这个主题上的消息。第二号窗口没有订阅此消息，故无输出。

借助这个简单的 pub/sub 机制，还可以做很多有意思的事情。比如把分布式系统中的程序的一部分 end-to-end 通信改为通过 pub/sub 来做（例如，原来是 A 向 B 发一个 SOAP request，B 通过同一个 tcp 连接发回 response (分析二者的通信只能通过查看 log 或用 tcpdump 截获）；现在是 A 往 topic_a_to_b 上发布 request，B 在 topic_b_to_a 上发 response），这样多挂一个 monitoring subscriber 就能轻易地查看通信双方的沟通情况，很容易做状态监控与 trouble shooting。

陈硕 (giantchen_AT_gmail)

Blog.csdn.net/Solstice  t.sina.com.cn/giantchen

这是《Muduo 网络编程示例》系列的第八篇文章，原计划讲文件传输，这里插入一点计划之外的内容。

Muduo 全系列文章列表： http://blog.csdn.net/Solstice/category/779646.aspx

本文介绍如何使用 timing wheel 来踢掉空闲的连接，一个连接如果若干秒没有收到数据，就认为是空闲连接。

本文的代码见 http://code.google.com/p/muduo/source/browse/trunk/examples/idleconnection

在严肃的网络程序中，应用层的心跳协议是必不可少的。应该用心跳消息来判断对方进程是否能正常工作，“踢掉空闲连接”只是一时权宜之计。我这里想顺便讲讲 shared_ptr 和 weak_ptr 的用法。

如果一个连接连续几秒钟（后文以 8s 为例）内没有收到数据，就把它断开，为此有两种简单粗暴的做法：

• 每个连接保存“最后收到数据的时间 lastReceiveTime”，然后用一个定时器，每秒钟遍历一遍所有连接，断开那些 (now - connection.lastReceiveTime) > 8s 的 connection。这种做法全局只有一个 repeated timer，不过每次 timeout 都要检查全部连接，如果连接数目比较大（几千上万），这一步可能会比较费时。
• 每个连接设置一个 one-shot timer，超时定为 8s，在超时的时候就断开本连接。当然，每次收到数据要去更新 timer。这种做法需要很多个 one-shot timer，会频繁地更新 timers。如果连接数目比较大，可能对 reactor 的 timer queue 造成压力。

使用 timing wheel 能避免上述两种做法的缺点。timing wheel 可以翻译为“时间轮盘”或“刻度盘”，本文保留英文。

连接超时不需要精确定时，只要大致 8 秒钟超时断开就行，多一秒少一秒关系不大。处理连接超时可以用一个简单的数据结构：8 个桶组成的循环队列。第一个桶放下一秒将要超时的连接，第二个放下 2 秒将要超时的连接。每个连接一收到数据就把自己放到第 8 个桶，然后在每秒钟的 callback 里把第一个桶里的连接断开，把这个空桶挪到队尾。这样大致可以做到 8 秒钟没有数据就超时断开连接。更重要的是，每次不用检查全部的 connection，只要检查第一个桶里的 connections，相当于把任务分散了。

Timing wheel 原理

《Hashed and hierarchical timing wheels: efficient data structures for implementing a timer facility》这篇论文详细比较了实现定时器的各种数据结构，并提出了层次化的 timing wheel 与 hash timing wheel 等新结构。针对本文要解决的问题的特点，我们不需要实现一个通用的定时器，只用实现 simple timing wheel 即可。

Simple timing wheel 的基本结构是一个循环队列，还有一个指向队尾的指针 (tail)，这个指针每秒钟移动一格，就像钟表上的时针，timing wheel 由此得名。

以下是某一时刻 timing wheel 的状态，格子里的数字是倒计时（与通常的 timing wheel 相反），表示这个格子（桶子）中的连接的剩余寿命。

一秒钟以后，tail 指针移动一格，原来四点钟方向的格子被清空，其中的连接已被断开。

连接超时被踢掉的过程

假设在某个时刻，conn 1 到达，把它放到当前格子中，它的剩余寿命是 7 秒。此后 conn 1 上没有收到数据。

1 秒钟之后，tail 指向下一个格子，conn 1 的剩余寿命是 6 秒。

又过了几秒钟，tail 指向 conn 1 之前的那个格子，conn 1 即将被断开。

下一秒，tail 重新指向 conn 1 原来所在的格子，清空其中的数据，断开 conn 1 连接。

连接刷新

如果在断开 conn 1 之前收到数据，就把它移到当前的格子里。

收到数据，conn 1 的寿命延长为 7 秒。

时间继续前进，conn 1 寿命递减，不过它已经比第一种情况长寿了。

多个连接

timing wheel 中的每个格子是个 hash set，可以容纳不止一个连接。

比如一开始，conn 1 到达。

随后，conn 2 到达，这时候 tail 还没有移动，两个连接位于同一个格子中，具有相同的剩余寿命。（下图中画成链表，代码中是哈希表。）

几秒钟之后，conn 1 收到数据，而 conn 2 一直没有收到数据，那么 conn 1 被移到当前的格子中。这时 conn 1 的寿命比 conn 2 长。

代码实现与改进

我们用以前多次出现的 EchoServer 来说明具体如何实现 timing wheel。代码见 http://code.google.com/p/muduo/source/browse/trunk/examples/idleconnection

在具体实现中，格子里放的不是连接，而是一个特制的 Entry struct，每个 Entry 包含 TcpConnection 的 weak_ptr。Entry 的析构函数会判断连接是否还存在（用 weak_ptr），如果还存在则断开连接。

数据结构：

  typedef boost::weak_ptr<muduo::net::TcpConnection> WeakTcpConnectionPtr;
struct Entry : public muduo::copyable
{
Entry(const WeakTcpConnectionPtr& weakConn)
: weakConn_(weakConn)
{
}
~Entry()
{
muduo::net::TcpConnectionPtr conn = weakConn_.lock();
if (conn)
{
conn->shutdown();
}
}
WeakTcpConnectionPtr weakConn_;
};
typedef boost::shared_ptr<Entry> EntryPtr;
typedef boost::weak_ptr<Entry> WeakEntryPtr;
typedef boost::unordered_set<EntryPtr> Bucket;
typedef boost::circular_buffer<Bucket> WeakConnectionList;

在实现中，为了简单起见，我们不会真的把一个连接从一个格子移到另一个格子，而是采用引用计数的办法，用 shared_ptr 来管理 Entry。如果从连接收到数据，就把对应的 EntryPtr 放到这个格子里，这样它的引用计数就递增了。当 Entry 的引用计数递减到零，说明它没有在任何一个格子里出现，那么连接超时，Entry 的析构函数会断开连接。

Timing wheel 用 boost::circular_buffer 实现，其中每个 Bucket 元素是个 hash set of EntryPtr。

在构造函数中，注册每秒钟的回调（EventLoop::runEvery() 注册 EchoServer::onTimer() ），然后把 timing wheel 设为适当的大小。

EchoServer::EchoServer(EventLoop* loop,
const InetAddress& listenAddr,
int idleSeconds)
: loop_(loop),
server_(loop, listenAddr, "EchoServer"),
connectionBuckets_(idleSeconds)
{
server_.setConnectionCallback(
boost::bind(&EchoServer::onConnection, this, _1));
server_.setMessageCallback(
boost::bind(&EchoServer::onMessage, this, _1, _2, _3));
loop->runEvery(1.0, boost::bind(&EchoServer::onTimer, this));
connectionBuckets_.resize(idleSeconds);
}

其中 EchoServer::onTimer() 的实现只有一行：往队尾添加一个空的 Bucket，这样 circular_buffer 会自动弹出队首的 Bucket，并析构之。在析构 Bucket 的时候，会依次析构其中的 EntryPtr 对象，这样 Entry 的引用计数就不用我们去操心，C++ 的值语意会帮我们搞定一切。

void EchoServer::onTimer()
{
connectionBuckets_.push_back(Bucket());
}

在连接建立时，创建一个 Entry 对象，把它放到 timing wheel 的队尾。另外，我们还需要把 Entry 的弱引用保存到 TcpConnection 的 context 里，因为在收到数据的时候还要用到 Entry。（思考题：如果 TcpConnection::setContext 保存的是强引用 EntryPtr，会出现什么情况？）

void EchoServer::onConnection(const TcpConnectionPtr& conn)
{
LOG_INFO << "EchoServer - " << conn->peerAddress().toHostPort() << " -> "
<< conn->localAddress().toHostPort() << " is "
<< (conn->connected() ? "UP" : "DOWN");
if (conn->connected())
{
EntryPtr entry(new Entry(conn));
connectionBuckets_.back().insert(entry);
WeakEntryPtr weakEntry(entry);
conn->setContext(weakEntry);
}
else
{
assert(!conn->getContext().empty());
WeakEntryPtr weakEntry(boost::any_cast<WeakEntryPtr>(conn->getContext()));
LOG_DEBUG << "Entry use_count = " << weakEntry.use_count();
}
}

在收到消息时，从 TcpConnection 的 context 中取出 Entry 的弱引用，把它提升为强引用 EntryPtr，然后放到当前的 timing wheel 队尾。（思考题，为什么要把 Entry 作为 TcpConnection 的 context 保存，如果这里再创建一个新的 Entry 会有什么后果？）

void EchoServer::onMessage(const TcpConnectionPtr& conn,
Buffer* buf,
Timestamp time)
{
string msg(buf->retrieveAsString());
LOG_INFO << conn->name() << " echo " << msg.size() << " bytes at " << time.toString();
conn->send(msg);
assert(!conn->getContext().empty());
WeakEntryPtr weakEntry(boost::any_cast<WeakEntryPtr>(conn->getContext()));
EntryPtr entry(weakEntry.lock());
if (entry)
{
connectionBuckets_.back().insert(entry);
}
}

然后呢？没有然后了，程序已经完成了我们想要的功能。（完整的代码会打印 circular_buffer 变化的情况，运行一下即可理解。）

希望本文有助于您理解 shared_ptr 和 weak_ptr。

改进

在现在的实现中，每次收到消息都会往队尾添加 EntryPtr （当然，hash set 会帮我们去重。）一个简单的改进措施是，在 TcpConnection 里保存“最后一次往队尾添加引用时的 tail 位置”，然后先检查 tail 是否变化，若无变化则不重复添加 EntryPtr。这样或许能提高效率。

以上改进留作练习。

陈硕 (giantchen_AT_gmail)

Blog.csdn.net/Solstice  t.sina.com.cn/giantchen

这是《Muduo 网络编程示例》系列的第七篇文章。

Muduo 全系列文章列表： http://blog.csdn.net/Solstice/category/779646.aspx

本文介绍如何使用 test harness 来测试一个具有内部逻辑的网络服务程序。

本文的代码见 http://code.google.com/p/muduo/source/browse/trunk/examples/multiplexer

下载地址：http://muduo.googlecode.com/files/muduo-0.2.0-alpha.tar.gz SHA1 checksum: 75a09a82f96b583004876e95105c679e64c95715

云风在他的博客中提到了网游连接服务器的功能需求（搜“练手项目”），我用 C++ 初步实现了这些需求，并为之编写了配套的自动化 test harness，作为 muduo 网络库的示例。

注意：本文呈现的代码仅仅实现了基本的功能需求，没有考虑安全性，也没有特别优化性能，不适合用作真正的放在公网上运行的网游连接服务器。

功能需求

这个连接服务器把多个客户连接汇聚为一个内部 TCP 连接，起到“数据串并转换”的作用，让 backend 的逻辑服务器专心处理业务，而无需顾及多连接的并发性。以下是系统的框图：

这个连接服务器的作用与数字电路中的数据选择器 (multiplexer) 类似，所以我把它命名为 multiplexer。（其实 IO-Multiplexing 也是取的这个意思，让一个 thread-of-control 能有选择地处理多个 IO 文件描述符。）

(上图取自 wikipedia，是 public domain 版权)

实现

Multiplexer 的功能需求不复杂，无非是在 backend connection 和 client connections 之间倒腾数据。具体来说，主要是处理四种事件：

• 对每个新 client connection 分配一个新的整数 id，如果 id 用完了，则断开新连接（这样通过控制 id 的数目就能控制最大连接数）。另外，为了避免 id 过快地被复用（有可能造成 backend 串话），multiplexer 采用 queue 来管理 free id，每次从队列的头部取 id，用完之后放回 queue 的尾部。
• 当 client connection 到达或断开时，向 backend 发出通知。onClientConnection() http://code.google.com/p/muduo/source/browse/tags/0.2.0/examples/multiplexer/multiplexer_simple.cc#54
• 当从 client connection 收到数据时，把数据连同 connection id 一同发给 backend。onClientMessage() http://code.google.com/p/muduo/source/browse/tags/0.2.0/examples/multiplexer/multiplexer_simple.cc#117
• 当从 backend connection 收到数据时，辨别数据是发给哪个 client connection，并执行相应的转发操作。onBackendMessage() http://code.google.com/p/muduo/source/browse/tags/0.2.0/examples/multiplexer/multiplexer_simple.cc#194
• 如果 backend connection 断开连接，则断开所有 client connections（假设 client 会自动重试）。 onBackendConnection() http://code.google.com/p/muduo/source/browse/tags/0.2.0/examples/multiplexer/multiplexer_simple.cc#162

由上可见，multiplexer 的功能与 proxy 颇为类似。multiplexer_simple.cc 是一个线程版的实现，借助 muduo 的 io-multiplexing 特性，可以方便地处理多个并发连接。

在实现的时候有两点值得注意：

• TcpConnection 的 id 如何存放？当从 backend 收到数据，如何根据 id 找到对应的 client connection？当从 client connection 收到数据，如何得知其 id ？

第一个问题比较好解决，用 std::map〈int, TcpConnectionPtr〉 clientConns_; 保存从 id 到 client connection 的映射就行。

第二个问题固然可以用类似的办法解决，但是我想借此介绍一下 muduo::net::TcpConnection 的 context 功能。每个 TcpConnection 都有一个 boost::any 成员，可由客户代码自由支配(get/set)，代码如下。这个 boost::any 是 TcpConnection 的 context，可以用于保存与 connection 绑定的任意数据（比方说 connection id、connection 的最后数据到达时间、connection 所代表的用户的名字等等）。这样客户代码不必继承 TcpConnection 就能 attach 自己的状态，而且也用不着 TcpConnectionFactory 了（如果允许继承，那么必然要向 TcpServer 注入此 factory）。

class TcpConnection : public boost::enable_shared_from_this<TcpConnection>,
                      boost::noncopyable
{
 public:

  void setContext(const boost::any& context)
  { context_ = context; }

  boost::any& getContext()
  { return context_; }

  const boost::any& getContext() const
  { return context_; }

  // ...

 private:
  // ...
  boost::any context_;
};

typedef boost::shared_ptr<TcpConnection> TcpConnectionPtr;

对于 Multiplexer，在 onClientConnection() 里调用 conn->setContext(id)，把 id 存到 TcpConnection 对象中。onClientMessage() 从 TcpConnection 对象中取得 id，连同数据一起发送给 backend，完整实现如下：

  void onClientMessage(const TcpConnectionPtr& conn, Buffer* buf, Timestamp)
  {
    if (!conn->getContext().empty())
    {
      int id = boost::any_cast<int>(conn->getContext());
      sendBackendBuffer(id, buf);
    }
    else
    {
      buf->retrieveAll();
    }
  }

• TcpConnection 的生命期如何管理？由于 Client Connection 是动态创建并销毁，其生与灭完全由客户决定，如何保证 backend 想向它发送数据的时候，这个 TcpConnection 对象还活着？解决思路是用 reference counting，当然，不用自己写，用 boost::shared_ptr 即可。TcpConnection 是 muduo 中唯一默认采用 shared_ptr 来管理生命期的对象，盖由其动态生命期的本质决定。更多内容请参考陈硕《当析构函数遇到多线程──C++ 中线程安全的对象回调》

multiplexer 是二进制协议，如何测试呢？

自动化测试

Multiplexer 是 muduo 网络编程示例中第一个具有 non-trivial 业务逻辑的网络程序，根据陈硕《分布式程序的自动化回归测试》一文的思想，我为它编写了 test harness。代码见 http://code.google.com/p/muduo/source/browse/trunk/examples/multiplexer/harness/src/com/chenshuo/muduo/example/multiplexer

这个 Test harness 采用 Java 编写，用的是 Netty 库。这个 test harness 要扮演 clients 和 backend，也就是既要主动发起连接，也要被动接受连接。结构如下：

Test harness 会把各种 event 汇聚到一个 blocking queue 里边，方便编写 test case。Test case 则操纵 test harness，发起连接、发送数据、检查收到的数据，例如以下是其中一个 test case

http://code.google.com/p/muduo/source/browse/trunk/examples/multiplexer/harness/src/com/chenshuo/muduo/example/multiplexer/testcase/TestOneClientSend.java

这里的几个 test cases 都以用 java 直接写的，如果有必要，也可以采用 Groovy 来编写，这样可以在不重启 test harness 的情况下随时修改添加 test cases。具体做法见陈硕《“过家家”版的移动离线计费系统实现》。

将来的改进

• 增加“backend 发送指令断开 client connection”的功能。有了自动化测试，这个新功能可以被单独测试（指开发者测试），而不需要真正的 backend 参与进来。
• 将 Multiplexer 改用多线程重写。有了自动化回归测试，我们不用担心破坏原有的功能，可以放心大胆地重写。而且由于 test harness 是从外部测试，不是单元测试，重写 multiplexer 的时候不用动 test cases，这样保证了测试的稳定性。另外，这个 test harness 稍作改进还可以进行 stress testing，既可用于验证多线程 multiplexer 的正确性，亦可对比其相对单线程版的效率提升。

陈硕 (giantchen_AT_gmail)

Blog.csdn.net/Solstice  t.sina.com.cn/giantchen

这是《Muduo 网络编程示例》系列的第六篇文章。

Muduo 全系列文章列表： http://blog.csdn.net/Solstice/category/779646.aspx

本文已以大家都熟悉的 EchoServer 介绍如何限制服务器的并发连接数。

本文的代码见 http://code.google.com/p/muduo/source/browse/trunk/examples/maxconnection/

《Muduo 网络编程示例 系列》计划中的第六篇文章原本是“用于测试两台机器的带宽的 pingpong 程序”，pingpong 协议的程序已经在《muduo 与 boost asio 吞吐量对比》和《muduo 与 libevent2 吞吐量对比》两篇文章中介绍过了，所以我改为写另外一个有点意思的主题。

这篇文章中的“并发连接数”是指一个 server program 能同时支持的客户端连接数，连接系由客户端主动发起，服务端被动接受(accept)连接。（如果要限制应用程序主动发起的连接，则问题要简单得多，毕竟主动权和决定权都在程序本身。）

为什么要限制并发连接数？

一方面，我们不希望服务程序超载，另一方面，更因为 file descriptor 是稀缺资源，如果出现 file descriptor 耗尽，很棘手（跟 “malloc 失败/new() 抛出 std::bad_alloc”差不多同样棘手）。

我在《分布式系统的工程化开发方法》一文中曾谈到 libev 作者建议的一种应对“accept()ing 时 file descriptor 耗尽”的办法。

Muduo 的 acceptor 正是这么实现的，但是，这个做法在多线程下不能保证正确，会有 race condition。（思考题：是什么 race condition？）

其实有另外一种比较简单的办法：file descriptor 是 hard limit，我们可以自己设一个稍低一点的 soft limit，如果超过 soft limit 就主动关闭新连接，这样就避免触及“file descriptor 耗尽”这种边界条件。比方说当前进程的 max file descriptor 是 1024，那么我们可以在连接数达到 1000 的时候进入“拒绝新连接”状态，这样留给我们足够的腾挪空间。

Muduo 中限制并发连接数

Muduo 中限制并发连接数的做法简单得出奇。以在《Muduo 网络编程示例之零：前言》中出场过的 EchoServer 为例，只需要为它增加一个 int 成员，表示当前的活动连接数。（如果是多线程程序，应该用 muduo::AtomicInt32。）

class EchoServer
{
 public:
  EchoServer(muduo::net::EventLoop* loop,
             const muduo::net::InetAddress& listenAddr,
             int maxConnections);

  void start();

 private:
  void onConnection(const muduo::net::TcpConnectionPtr& conn);

  void onMessage(const muduo::net::TcpConnectionPtr& conn,
                 muduo::net::Buffer* buf,
                 muduo::Timestamp time);

  muduo::net::EventLoop* loop_;
  muduo::net::TcpServer server_;
  int numConnected_; // should be atomic_int
  const int kMaxConnections;
};

然后，在 EchoServer::onConnection() 中判断当前活动连接数，如果超过最大允许数，则踢掉连接。

void EchoServer::onConnection(const TcpConnectionPtr& conn)
{
  LOG_INFO << "EchoServer - " << conn->peerAddress().toHostPort() << " -> "
    << conn->localAddress().toHostPort() << " is "
    << (conn->connected() ? "UP" : "DOWN");

  if (conn->connected())
  {
    ++numConnected_;
    if (numConnected_ > kMaxConnections)
    {
      conn->shutdown();
    }
  }
  else
  {
    --numConnected_;
  }
  LOG_INFO << "numConnected = " << numConnected_;
}

这种做法可以积极地防止耗尽 file descriptor。

另外，如果是有业务逻辑的服务，可以在 shutdown() 之前发送一个简单的响应，表明本服务程序的负载能力已经饱和，提示客户端尝试下一个可用的 server（当然，下一个可用的 server 地址不一定要在这个响应里给出，客户端可以自己去 name service 查询），这样方便客户端快速 failover。

后文将介绍如何处理空闲连接的超时：如果一个连接长时间（若干秒）没有输入数据，则踢掉此连接。办法有很多种，我用 Time Wheel 解决。

陈硕 (giantchen_AT_gmail)

Blog.csdn.net/Solstice  t.sina.com.cn/giantchen

这是《Muduo 网络编程示例》系列的第五篇文章。

Muduo 全系列文章列表： http://blog.csdn.net/Solstice/category/779646.aspx

本文介绍一个简单的网络程序 roundtrip，用于测量两台机器之间的网络延迟，即“往返时间 / round trip time / RTT”。这篇文章主要考察定长 TCP 消息的分包，TCP_NODELAY 的作用。

本文的代码见 http://code.google.com/p/muduo/source/browse/trunk/examples/roundtrip/roundtrip.cc

测量 RTT 的办法很简单：

• host A 发一条消息给 host B，其中包含 host A 发送消息的本地时间
• host B 收到之后立刻把消息 echo 回 host A
• host A 收到消息之后，用当前时间减去消息中的时间就得到了 RTT。

NTP 协议的工作原理与之类似，不过，除了测量 RTT，NTP 还需要知道两台机器之间的时间差 (clock offset)，这样才能校准时间。

以上是 NTP 协议收发消息的协议，RTT = (T4-T1) – (T3-T2)，时间差 = ((T4+T1)-(T2+T3))/2。NTP 的要求是往返路径上的单程延迟要尽量相等，这样才能减少系统误差。偶然误差由单程延迟的不确定性决定。

在我设计的 roundtrip 示例程序中，协议有所简化：

简化之后的协议少取一次时间，因为 server 收到消息之后立刻发送回 client，耗时很少（若干微秒），基本不影响最终结果。

我设计的消息格式是 16 字节定长消息：

T1 和 T2 都是 muduo::Timestamp，一个 int64_t，表示从 Epoch 到现在的微秒数。

为了让消息的单程往返时间接近，server 和 client 发送的消息都是 16 bytes，这样做到对称。

由于是定长消息，可以不必使用 codec，在 message callback 中直接用

while (buffer->readableBytes() >= frameLen) { ... } 就能 decode。

请读者思考，如果把 while 换成 if 会有什么后果？

client 程序以 200ms 为间隔发送消息，在收到消息之后打印 RTT 和 clock offset。一次运作实例如下：

这个例子中，client 和 server 的时钟不是完全对准的，server 的时间快了 850 us，用 roundtrip 程序能测量出这个时间差。有了这个时间差就能校正分布式系统中测量得到的消息延迟。

比方说以上图为例，server 在它本地 1.235000 时刻发送了一条消息，client 在它本地 1.234300 收到这条消息，直接计算的话延迟是 –700us。这个结果肯定是错的，因为 server 和 client 不在一个时钟域（这是数字电路中的概念），它们的时间直接相减无意义。如果我们已经测量得到 server 比 client 快 850us，那么做用这个数据一次校正： -700+850 = 150us，这个结果就比较符合实际了。当然，在实际应用中，clock offset 要经过一个低通滤波才能使用，不然偶然性太大。

请读者思考，为什么不能直接以 RTT/2 作为两天机器之间收发消息的单程延迟？

这个程序在局域网中使用没有问题，如果在广域网上使用，而且 RTT 大于 200ms，那么受 Nagle 算法影响，测量结果是错误的（具体分析留作练习，这能测试对 Nagle 的理解），这时候我们需要设置 TCP_NODELAY 参数，让程序在广域网上也能正常工作。

Blog.csdn.net/Solstice  t.sina.com.cn/giantchen

Muduo 全系列文章列表： http://blog.csdn.net/Solstice/category/779646.aspx

本文是《一种自动反射消息类型的 Google Protobuf 网络传输方案》的延续，介绍如何将前文介绍的打包方案与 muduo::net::Buffer 结合，实现了 protobuf codec 和 dispatcher。

Muduo 的下载地址： http://muduo.googlecode.com/files/muduo-0.1.9-alpha.tar.gz ，SHA1 dc0bb5f7becdfc0277fb35f6dfaafee8209213bc ，本文的完整代码可在线阅读 http://code.google.com/p/muduo/source/browse/trunk/examples/protobuf/codec/ 。

考虑到不是每个人都安装了 Google Protobuf，muduo 中的 protobuf 相关示例默认是不 build 的，如果你的机器上安装了 protobuf 2.3.0 或 2.4.0a，那么可以用 ./build.sh protobuf_all 来构建 protobuf 相关的 examples。

在介绍 codec 和 dispatcher 之前，先讲讲前文的一个未决问题。

为什么 Protobuf 的默认序列化格式没有包含消息的长度与类型？

Protobuf 是经过深思熟虑的消息打包方案，它的默认序列化格式没有包含消息的长度与类型，自然有其道理。哪些情况下不需要在 protobuf 序列化得到的字节流中包含消息的长度和（或）类型？我能想到的答案有：

• 如果把消息写入文件，一个文件存一个消息，那么序列化结果中不需要包含长度和类型，因为从文件名和文件长度中可以得知消息的类型与长度。
• 如果把消息写入文件，一个文件存多个消息，那么序列化结果中不需要包含类型，因为文件名就代表了消息的类型。
• 如果把消息存入数据库（或者 NoSQL），以 VARBINARY 字段保存，那么序列化结果中不需要包含长度和类型，因为从字段名和字段长度中可以得知消息的类型与长度。
• 如果把消息以 UDP 方式发生给对方，而且对方一个 UDP port 只接收一种消息类型，那么序列化结果中不需要包含长度和类型，因为从 port 和 UDP packet 长度中可以得知消息的类型与长度。
• 如果把消息以 TCP 短连接方式发给对方，而且对方一个 TCP port 只接收一种消息类型，那么序列化结果中不需要包含长度和类型，因为从 port 和 TCP 字节流长度中可以得知消息的类型与长度。
• 如果把消息以 TCP 长连接方式发给对方，但是对方一个 TCP port 只接收一种消息类型，那么序列化结果中不需要包含类型，因为 port 代表了消息的类型。
• 如果采用 RPC 方式通信，那么只需要告诉对方 method name，对方自然能推断出 Request 和 Response 的消息类型，这些可以由 protoc 生成的 RPC stubs 自动搞定。

对于最后一点，比方说 sudoku.proto 定义为：

service SudokuService {
  rpc Solve (SudokuRequest) returns (SudokuResponse);
}

那么 RPC method Sudoku.Solve 对应的请求和响应分别是 SudokuRequest 和 SudokuResponse。在发送 RPC 请求的时候，不需要包含 SudokuRequest 的类型，只需要发送 method name Sudoku.Solve，对方自知道应该按照 SudokuRequest 来解析(parse)请求。这个例子来自我的半成品项目 evproto，见 http://blog.csdn.net/Solstice/archive/2010/04/17/5497699.aspx 。

对于上述这些情况，如果 protobuf 无条件地把长度和类型放到序列化的字节串中，只会浪费网络带宽和存储。可见 protobuf 默认不发送长度和类型是正确的决定。Protobuf 为消息格式的设计树立了典范，哪些该自己搞定，哪些留给外部系统去解决，这些都考虑得很清楚。

只有在使用 TCP 长连接，且在一个连接上传递不止一种消息的情况下（比方同时发 Heartbeat 和 Request/Response），才需要我前文提到的那种打包方案。（为什么要在一个连接上同时发 Heartbeat 和业务消息？请见陈硕《分布式系统的工程化开发方法》 p.51 心跳协议的设计。）这时候我们需要一个分发器 dispatcher，把不同类型的消息分给各个消息处理函数，这正是本文的主题之一。

以下均只考虑 TCP 长连接这一应用场景。

先谈谈编解码器。

什么是编解码器 codec?

Codec 是 encoder 和 decoder 的缩写，这是一个到软硬件都在使用的术语，这里我借指“把网络数据和业务消息之间互相转换”的代码。

在最简单的网络编程中，没有消息 message 只有字节流数据，这时候是用不到 codec 的。比如我们前面讲过的 echo server，它只需要把收到的数据原封不动地发送回去，它不必关心消息的边界（也没有“消息”的概念），收多少就发多少，这种情况下它干脆直接使用 muduo::net::Buffer，取到数据再交给 TcpConnection 发送回去，见下图。

non-trivial 的网络服务程序通常会以消息为单位来通信，每条消息有明确的长度与界限。程序每次收到一个完整的消息的时候才开始处理，发送的时候也是把一个完整的消息交给网络库。比如我们前面讲过的 asio chat 服务，它的一条聊天记录就是一条消息，我们设计了一个简单的消息格式，即在聊天记录前面加上 4 字节的 length header，LengthHeaderCodec 代码及解说见《Muduo 网络编程示例之二：Boost.Asio 的聊天服务器》一文。

codec 的基本功能之一是做 TCP 分包：确定每条消息的长度，为消息划分界限。在 non-blocking 网络编程中，codec 几乎是必不可少的。如果只收到了半条消息，那么不会触发消息回调，数据会停留在 Buffer 里（数据已经读到 Buffer 中了），等待收到一个完整的消息再通知处理函数。既然这个任务太常见，我们干脆做一个 utility class，避免服务端和客户端程序都要自己处理分包，这就有了 LengthHeaderCodec。这个 codec 的使用有点奇怪，不需要继承，它也没有基类，只要把它当成普通 data member 来用，把 TcpConnection 的数据喂给它，然后向它注册 onXXXMessage() 回调，代码见 asio chat 示例。muduo 里的 codec 都是这样的风格，通过 boost::function 粘合到一起。

codec 是一层间接性，它位于 TcpConnection 和 ChatServer 之间，拦截处理收到的数据，在收到完整的消息之后再调用 CharServer 对应的处理函数，注意 CharServer::onStringMessage() 的参数是 std::string，不再是 muduo::net::Buffer，也就是说 LengthHeaderCodec 把 Buffer 解码成了 string。另外，在发送消息的时候，ChatServer 通过 LengthHeaderCodec::send() 来发送 string，LengthHeaderCodec 负责把它编码成 Buffer。这正是“编解码器”名字的由来。

Protobuf codec 与此非常类似，只不过消息类型从 std::string 变成了 protobuf::Message。对于只接收处理 Query 消息的 QueryServer 来说，用 ProtobufCodec 非常方便，收到 protobuf::Message 之后 down cast 成 Query 来用就行。如果要接收处理不止一种消息，ProtobufCodec 恐怕还不能单独完成工作，请继续阅读下文。

实现 ProtobufCodec

Protobuf 的打包方案我已经在《一种自动反射消息类型的 Google Protobuf 网络传输方案》中讲过，并以 string 为载体演示了 encode 和 decode 操作。在 muduo 里，我们有专门的 Buffer class，编码更轻松。

编码算法很直截了当，按照前文定义的消息格式一路打包下来，最后更新一下首部的长度即可。

解码算法有几个要点：

• protobuf::Message 是 new 出来的对象，它的生命期如何管理？muduo 采用 shared_ptr<Message> 来自动管理对象生命期，这与其他地方的做法是一致的。
• 出错如何处理？比方说长度超出范围、check sum 不正确、message type name 不能识别、message parse 出错等等。ProtobufCodec 定义了 ErrorCallback，用户代码可以注册这个回调。如果不注册，默认的处理是断开连接，让客户重连重试。codec 的单元测试里模拟了各种出错情况。
• 如何处理一次收到半条消息、一条消息、一条半消息、两条消息等等情况？这是每个 non-blocking 网络程序中的 codec 都要面对的问题。

ProtobufCodec 在实际使用中有明显的不足：它只负责把 muduo::net::Buffer 转换为具体类型的 protobuf::Message，应用程序拿到 Message 之后还有再根据其具体类型做一次分发。我们可以考虑做一个简单通用的分发器 dispatcher，以简化客户代码。

此外，目前 ProtobufCodec 的实现非常初级，它没有充分利用 ZeroCopyInputStream 和 ZeroCopyOutputStream，而是把收到的数据作为 byte array 交给 protobuf Message 去解析，这给性能优化留下了空间。protobuf Message 不要求数据连续(像 vector 那样)，只要求数据分段连续(像 deque 那样)，这给 buffer 管理带来性能上的好处（避免重新分配内存，减少内存碎片），当然也使得代码变复杂。muduo::net::Buffer 非常简单，它内部是 vector<char>，我目前不想让 protobuf 影响 muduo 本身的设计，毕竟 muduo 是个通用的网络库，不是为实现 protobuf RPC 而特制的。

消息分发器 dispatcher 有什么用？

前面提到，在使用 TCP 长连接，且在一个连接上传递不止一种 protobuf 消息的情况下，客户代码需要对收到的消息按类型做分发。比方说，收到 Logon 消息就交给 QueryServer::onLogon() 去处理，收到 Query 消息就交给 QueryServer::onQuery() 去处理。这个消息分派机制可以做得稍微有点通用性，让所有 muduo+protobuf 程序收益，而且不增加复杂性。

换句话说，又是一层间接性，ProtobufCodec 拦截了 TcpConnection 的数据，把它转换为 Message，ProtobufDispatcher 拦截了 ProtobufCodec 的 callback，按消息具体类型把它分派给多个 callbacks。

ProtobufCodec 与 ProtobufDispatcher 的综合运用

我写了两个示例代码，client 和 server，把 ProtobufCodec 和 ProtobufDispatcher 串联起来使用。server 响应 Query 消息，发生回 Answer 消息，如果收到未知消息类型，则断开连接。client 可以选择发送 Query 或 Empty 消息，由命令行控制。这样可以测试 unknown message callback。

为节省篇幅，这里就不列出代码了，请移步阅读

http://code.google.com/p/muduo/source/browse/trunk/examples/protobuf/codec/client.cc 

http://code.google.com/p/muduo/source/browse/trunk/examples/protobuf/codec/server.cc

在构造函数中，通过注册回调函数把四方 (TcpConnection、codec、dispatcher、QueryServer) 结合起来。

ProtobufDispatcher 的两种实现

要完成消息分发，那么就是对消息做 type-switch，这似乎是一个 bad smell，但是 protobuf Message 的 Descriptor 没有留下定制点（比如暴露一个 boost::any 成员），我们只好硬来了。

先定义

typedef boost::function<void (Message*)> ProtobufMessageCallback;

注意，本节出现的不是 muduo dispatcher 真实的代码，仅为示意，突出重点，便于画图。

ProtobufDispatcherLite 的结构非常简单，它有一个 map<Descriptor*, ProtobufMessageCallback> 成员，客户代码可以以 Descriptor* 为 key 注册回调（recall: 每个具体消息类型都有一个全局的 Descriptor 对象，其地址是不变的，可以用来当 key）。在收到 protobuf Message 之后，在 map 中找到对应的 ProtobufMessageCallback，然后调用之。如果找不到，就调用 defaultCallback。

当然，它的设计也有小小的缺陷，那就是 ProtobufMessageCallback 限制了客户代码只能接受基类 Message，客户代码需要自己做向下转型，比如：

如果我希望 QueryServer 这么设计：不想每个消息处理函数自己做 down casting，而是交给 dispatcher 去处理，客户代码拿到的就已经是想要的具体类型。如下：

那么该该如何实现 ProtobufDispatcher 呢？它如何与多个未知的消息类型合作？做 down cast 需要知道目标类型，难道我们要用一长串模板类型参数吗？

有一个办法，把多态与模板结合，利用 templated derived class 来提供类型上的灵活性。设计如下。

ProtobufDispatcher 有一个模板成员函数，可以接受注册任意消息类型 T 的回调，然后它创建一个模板化的派生类 CallbackT<T>，这样消息的类新信息就保存在了 CallbackT<T> 中，做 down casting 就简单了。

比方说，我们有两个具体消息类型 Query 和 Answer。

然后我们这样注册回调：

dispatcher_.registerMessageCallback<muduo::Query>(
    boost::bind(&QueryServer::onQuery, this, _1, _2, _3));
dispatcher_.registerMessageCallback<muduo::Answer>(
    boost::bind(&QueryServer::onAnswer, this, _1, _2, _3));

这样会具现化 (instantiation) 出两个 CallbackT 实体，如下：

以上设计参考了 shared_ptr 的 deleter，Scott Meyers 也谈到过。

ProtobufCodec 和 ProtobufDispatcher 有何意义？

ProtobufCodec 和 ProtobufDispatcher 把每个直接收发 protobuf Message 的网络程序都会用到的功能提炼出来做成了公用的 utility，这样以后新写 protobuf 网络程序就不必为打包分包和消息分发劳神了。它俩以库的形式存在，是两个可以拿来就当 data member 用的 class，它们没有基类，也没有用到虚函数或者别的什么面向对象特征，不侵入 muduo::net 或者你的代码。

下一篇文章讲《分布式程序的自动回归测试》会介绍利用 protobuf 的跨语言特性，采用 Java 为 C++ 服务程序编写 test harness。

Blog.csdn.net/Solstice

Muduo 全系列文章列表： http://blog.csdn.net/Solstice/category/779646.aspx

今天收到一位网友来信：

在 simple 中的 daytime 示例中，服务端主动关闭时调用的是如下函数序列，这不是只是关闭了连接上的写操作吗，怎么是关闭了整个连接？

   1: void DaytimeServer::onConnection(const muduo::net::TcpConnectionPtr& conn)

   2: {

   3:   if (conn->connected())

   4:   {

   5:     conn->send(Timestamp::now().toFormattedString() + "\n");

   6:     conn->shutdown();

   7:   }

   8: }

   9:  

  10: void TcpConnection::shutdown()

  11: {

  12:   if (state_ == kConnected)

  13:   {

  14:     setState(kDisconnecting);

  15:     loop_->runInLoop(boost::bind(&TcpConnection::shutdownInLoop, this));

  16:   }

  17: }

  18:  

  19: void TcpConnection::shutdownInLoop()

  20: {

  21:   loop_->assertInLoopThread();

  22:   if (!channel_->isWriting())

  23:   {

  24:     // we are not writing

  25:     socket_->shutdownWrite();

  26:   }

  27: }

  28:  

  29: void Socket::shutdownWrite()

  30: {

  31:   sockets::shutdownWrite(sockfd_);

  32: }

  33:  

  34: void sockets::shutdownWrite(int sockfd)

  35: {

  36:   if (::shutdown(sockfd, SHUT_WR) < 0)

  37:   {

  38:     LOG_SYSERR << "sockets::shutdownWrite";

  39:   }

  40: }

陈硕答复如下：

Muduo TcpConnection 没有提供 close，而只提供 shutdown ，这么做是为了收发数据的完整性。

TCP 是一个全双工协议，同一个文件描述符既可读又可写， shutdownWrite() 关闭了“写”方向的连接，保留了“读”方向，这称为 TCP half-close。如果直接 close(socket_fd)，那么 socket_fd 就不能读或写了。

用 shutdown 而不用 close 的效果是，如果对方已经发送了数据，这些数据还“在路上”，那么 muduo 不会漏收这些数据。换句话说，muduo 在 TCP 这一层面解决了“当你打算关闭网络连接的时候，如何得知对方有没有发了一些数据而你还没有收到？”这一问题。当然，这个问题也可以在上面的协议层解决，双方商量好不再互发数据，就可以直接断开连接。

等于说 muduo 把“主动关闭连接”这件事情分成两步来做，如果要主动关闭连接，它会先关本地“写”端，等对方关闭之后，再关本地“读”端。练习：阅读代码，回答“如果被动关闭连接，muduo 的行为如何？” 提示：muduo 在 read() 返回 0 的时候会回调 connection callback，这样客户代码就知道对方断开连接了。

Muduo 这种关闭连接的方式对对方也有要求，那就是对方 read() 到 0 字节之后会主动关闭连接（无论 shutdownWrite() 还是 close()），一般的网络程序都会这样，不是什么问题。当然，这么做有一个潜在的安全漏洞，万一对方故意不不关，那么 muduo 的连接就一直半开着，消耗系统资源。

完整的流程是：我们发完了数据，于是 shutdownWrite，发送 TCP FIN 分节，对方会读到 0 字节，然后对方通常会关闭连接，这样 muduo 会读到 0 字节，然后 muduo 关闭连接。（思考题：在 shutdown() 之后，muduo 回调 connection callback 的时间间隔大约是一个 round-trip time，为什么？）

另外，如果有必要，对方可以在 read() 返回 0 之后继续发送数据，这是直接利用了 half-close TCP 连接。muduo 会收到这些数据，通过 message callback 通知客户代码。

那么 muduo 什么时候真正 close socket 呢？在 TcpConnection 对象析构的时候。TcpConnection 持有一个 Socket 对象，Socket 是一个 RAII handler，它的析构函数会 close(sockfd_)。这样，如果发生 TcpConnection 对象泄漏，那么我们从 /proc/pid/fd/ 就能找到没有关闭的文件描述符，便于查错。

muduo 在 read() 返回 0 的时候会回调 connection callback，然后把 TcpConnection 的引用计数减一，如果 TcpConnection 的引用计数降到零，它就会析构了。

参考：

《TCP/IP 详解》第一卷第 18.5 节，TCP Half-Close。

《UNIX 网络编程》第一卷第三版第 6.6 节， shutdown() 函数。

Blog.csdn.net/Solstice

这是《Muduo 网络编程示例》系列的第二篇文章。

Muduo 全系列文章列表： http://blog.csdn.net/Solstice/category/779646.aspx

本文讲介绍一个与 Boost.Asio 的示例代码中的聊天服务器功能类似的网络服务程序，包括客户端与服务端的 muduo 实现。这个例子的主要目的是介绍如何处理分包，并初步涉及 Muduo 的多线程功能。Muduo 的下载地址： http://muduo.googlecode.com/files/muduo-0.1.7-alpha.tar.gz ，SHA1 873567e43b3c2cae592101ea809b30ba730f2ee6，本文的完整代码可在线阅读

http://code.google.com/p/muduo/source/browse/trunk/examples/asio/chat/ 。

TCP 分包

前面一篇《五个简单 TCP 协议》中处理的协议没有涉及分包，在 TCP 这种字节流协议上做应用层分包是网络编程的基本需求。分包指的是在发生一个消息(message)或一帧(frame)数据时，通过一定的处理，让接收方能从字节流中识别并截取（还原）出一个个消息。“粘包问题”是个伪问题。

对于短连接的 TCP 服务，分包不是一个问题，只要发送方主动关闭连接，就表示一条消息发送完毕，接收方 read() 返回 0，从而知道消息的结尾。例如前一篇文章里的 daytime 和 time 协议。

对于长连接的 TCP 服务，分包有四种方法：

1. 消息长度固定，比如 muduo 的 roundtrip 示例就采用了固定的 16 字节消息；
2. 使用特殊的字符或字符串作为消息的边界，例如 HTTP 协议的 headers 以 "\r\n" 为字段的分隔符；
3. 在每条消息的头部加一个长度字段，这恐怕是最常见的做法，本文的聊天协议也采用这一办法；
4. 利用消息本身的格式来分包，例如 XML 格式的消息中 <root>...</root> 的配对，或者 JSON 格式中的 { ... } 的配对。解析这种消息格式通常会用到状态机。

在后文的代码讲解中还会仔细讨论用长度字段分包的常见陷阱。

聊天服务

本文实现的聊天服务非常简单，由服务端程序和客户端程序组成，协议如下：

• 服务端程序中某个端口侦听 (listen) 新的连接；
• 客户端向服务端发起连接；
• 连接建立之后，客户端随时准备接收服务端的消息并在屏幕上显示出来；
• 客户端接受键盘输入，以回车为界，把消息发送给服务端；
• 服务端接收到消息之后，依次发送给每个连接到它的客户端；原来发送消息的客户端进程也会收到这条消息；
• 一个服务端进程可以同时服务多个客户端进程，当有消息到达服务端后，每个客户端进程都会收到同一条消息，服务端广播发送消息的顺序是任意的，不一定哪个客户端会先收到这条消息。
• （可选）如果消息 A 先于消息 B 到达服务端，那么每个客户端都会先收到 A 再收到 B。

这实际上是一个简单的基于 TCP 的应用层广播协议，由服务端负责把消息发送给每个连接到它的客户端。参与“聊天”的既可以是人，也可以是程序。在以后的文章中，我将介绍一个稍微复杂的一点的例子 hub，它有“聊天室”的功能，客户端可以注册特定的 topic(s)，并往某个 topic 发送消息，这样代码更有意思。

消息格式

本聊天服务的消息格式非常简单，“消息”本身是一个字符串，每条消息的有一个 4 字节的头部，以网络序存放字符串的长度。消息之间没有间隙，字符串也不一定以 '\0' 结尾。比方说有两条消息 "hello" 和 "chenshuo"，那么打包后的字节流是：

0x00, 0x00, 0x00, 0x05, 'h', 'e', 'l', 'l', 'o', 0x00, 0x00, 0x00, 0x08, 'c', 'h', 'e', 'n', 's', 'h', 'u', 'o'

共 21 字节。

打包的代码

这段代码把 const string& message 打包为 muduo::net::Buffer，并通过 conn 发送。

   1: void send(muduo::net::TcpConnection* conn, const string& message)

   2: {

   3:   muduo::net::Buffer buf;

   4:   buf.append(message.data(), message.size());

   5:   int32_t len = muduo::net::sockets::hostToNetwork32(static_cast<int32_t>(message.size()));

   6:   buf.prepend(&len, sizeof len);

   7:   conn->send(&buf);

   8: }

muduo::Buffer 有一个很好的功能，它在头部预留了 8 个字节的空间，这样第 6 行的 prepend() 操作就不需要移动已有的数据，效率较高。

分包的代码

解析数据往往比生成数据复杂，分包打包也不例外。

   1: void onMessage(const muduo::net::TcpConnectionPtr& conn,

   2:                muduo::net::Buffer* buf,

   3:                muduo::Timestamp receiveTime)

   4: {

   5:   while (buf->readableBytes() >= kHeaderLen)

   6:   {

   7:     const void* data = buf->peek();

   8:     int32_t tmp = *static_cast<const int32_t*>(data);

   9:     int32_t len = muduo::net::sockets::networkToHost32(tmp);

  10:     if (len > 65536 || len < 0)

  11:     {

  12:       LOG_ERROR << "Invalid length " << len;

  13:       conn->shutdown();

  14:     }

  15:     else if (buf->readableBytes() >= len + kHeaderLen)

  16:     {

  17:       buf->retrieve(kHeaderLen);

  18:       muduo::string message(buf->peek(), len);

  19:       buf->retrieve(len);

  20:       messageCallback_(conn, message, receiveTime);  // 收到完整的消息，通知用户

  21:     }

  22:     else

  23:     {

  24:       break;

  25:     }

  26:   }

  27: }

上面这段代码第 7 行用了 while 循环来反复读取数据，直到 Buffer 中的数据不够一条完整的消息。请读者思考，如果换成 if (buf->readableBytes() >= kHeaderLen) 会有什么后果。

以前面提到的两条消息的字节流为例：

0x00, 0x00, 0x00, 0x05, 'h', 'e', 'l', 'l', 'o', 0x00, 0x00, 0x00, 0x08, 'c', 'h', 'e', 'n', 's', 'h', 'u', 'o'

假设数据最终都全部到达，onMessage() 至少要能正确处理以下各种数据到达的次序，每种情况下 messageCallback_ 都应该被调用两次：

1. 每次收到一个字节的数据，onMessage() 被调用 21 次；
2. 数据分两次到达，第一次收到 2 个字节，不足消息的长度字段；
3. 数据分两次到达，第一次收到 4 个字节，刚好够长度字段，但是没有 body；
4. 数据分两次到达，第一次收到 8 个字节，长度完整，但 body 不完整；
5. 数据分两次到达，第一次收到 9 个字节，长度完整，body 也完整；
6. 数据分两次到达，第一次收到 10 个字节，第一条消息的长度完整、body 也完整，第二条消息长度不完整；
7. 请自行移动分割点，验证各种情况；
8. 数据一次就全部到达，这时必须用 while 循环来读出两条消息，否则消息会堆积。

请读者验证 onMessage() 是否做到了以上几点。这个例子充分说明了 non-blocking read 必须和 input buffer 一起使用。

编解码器 LengthHeaderCodec

有人评论 Muduo 的接收缓冲区不能设置回调函数的触发条件，确实如此。每当 socket 可读，Muduo 的 TcpConnection 会读取数据并存入 Input Buffer，然后回调用户的函数。不过，一个简单的间接层就能解决问题，让用户代码只关心“消息到达”而不是“数据到达”，如本例中的 LengthHeaderCodec 所展示的那一样。

   1: #ifndef MUDUO_EXAMPLES_ASIO_CHAT_CODEC_H

   2: #define MUDUO_EXAMPLES_ASIO_CHAT_CODEC_H

   3:  

   4: #include <muduo/base/Logging.h>

   5: #include <muduo/net/Buffer.h>

   6: #include <muduo/net/SocketsOps.h>

   7: #include <muduo/net/TcpConnection.h>

   8:  

   9: #include <boost/function.hpp>

  10: #include <boost/noncopyable.hpp>

  11:  

  12: using muduo::Logger;

  13:  

  14: class LengthHeaderCodec : boost::noncopyable

  15: {

  16:  public:

  17:   typedef boost::function<void (const muduo::net::TcpConnectionPtr&,

  18:                                 const muduo::string& message,

  19:                                 muduo::Timestamp)> StringMessageCallback;

  20:  

  21:   explicit LengthHeaderCodec(const StringMessageCallback& cb)

  22:     : messageCallback_(cb)

  23:   {

  24:   }

  25:  

  26:   void onMessage(const muduo::net::TcpConnectionPtr& conn,

  27:                  muduo::net::Buffer* buf,

  28:                  muduo::Timestamp receiveTime)

  29:   { 同上 }

  30:  

  31:   void send(muduo::net::TcpConnection* conn, const muduo::string& message)

  32:   { 同上 }

  33:  

  34:  private:

  35:   StringMessageCallback messageCallback_;

  36:   const static size_t kHeaderLen = sizeof(int32_t);

  37: };

  38:  

  39: #endif  // MUDUO_EXAMPLES_ASIO_CHAT_CODEC_H

这段代码把以 Buffer* 为参数的 MessageCallback 转换成了以 const string& 为参数的 StringMessageCallback，让用户代码不必关心分包操作。客户端和服务端都能从中受益。

服务端的实现

聊天服务器的服务端代码小于 100 行，不到 asio 的一半。

请先阅读第 68 行起的数据成员的定义。除了经常见到的 EventLoop 和 TcpServer，ChatServer 还定义了 codec_ 和 std::set<TcpConnectionPtr> connections_ 作为成员，connections_ 是目前已建立的客户连接，在收到消息之后，服务器会遍历整个容器，把消息广播给其中每一个 TCP 连接。

首先，在构造函数里注册回调：

   1: #include "codec.h"

   2:  

   3: #include <muduo/base/Logging.h>

   4: #include <muduo/base/Mutex.h>

   5: #include <muduo/net/EventLoop.h>

   6: #include <muduo/net/SocketsOps.h>

   7: #include <muduo/net/TcpServer.h>

   8:  

   9: #include <boost/bind.hpp>

  10:  

  11: #include <set>

  12: #include <stdio.h>

  13:  

  14: using namespace muduo;

  15: using namespace muduo::net;

  16:  

  17: class ChatServer : boost::noncopyable

  18: {

  19:  public:

  20:   ChatServer(EventLoop* loop,

  21:              const InetAddress& listenAddr)

  22:   : loop_(loop),

  23:     server_(loop, listenAddr, "ChatServer"),

  24:     codec_(boost::bind(&ChatServer::onStringMessage, this, _1, _2, _3))

  25:   {

  26:     server_.setConnectionCallback(

  27:         boost::bind(&ChatServer::onConnection, this, _1));

  28:     server_.setMessageCallback(

  29:         boost::bind(&LengthHeaderCodec::onMessage, &codec_, _1, _2, _3));

  30:   }

  31:  

  32:   void start()

  33:   {

  34:     server_.start();

  35:   }

  36:  

这里有几点值得注意，在以往的代码里是直接把本 class 的 onMessage() 注册给 server_；这里我们把 LengthHeaderCodec::onMessage() 注册给 server_，然后向 codec_ 注册了 ChatServer::onStringMessage()，等于说让 codec_ 负责解析消息，然后把完整的消息回调给 ChatServer。这正是我前面提到的“一个简单的间接层”，在不增加 Muduo 库的复杂度的前提下，提供了足够的灵活性让我们在用户代码里完成需要的工作。

另外，server_.start() 绝对不能在构造函数里调用，这么做将来会有线程安全的问题，见我在《当析构函数遇到多线程 ── C++ 中线程安全的对象回调》一文中的论述。

以下是处理连接的建立和断开的代码，注意它把新建的连接加入到 connections_ 容器中，把已断开的连接从容器中删除。这么做是为了避免内存和资源泄漏，TcpConnectionPtr 是 boost::shared_ptr<TcpConnection>，是 muduo 里唯一一个默认采用 shared_ptr 来管理生命期的对象。以后我们会谈到这么做的原因。

  37:  private:

  38:   void onConnection(const TcpConnectionPtr& conn)

  39:   {

  40:     LOG_INFO << conn->localAddress().toHostPort() << " -> "

  41:         << conn->peerAddress().toHostPort() << " is "

  42:         << (conn->connected() ? "UP" : "DOWN");

  43:  

  44:     MutexLockGuard lock(mutex_);

  45:     if (conn->connected())

  46:     {

  47:       connections_.insert(conn);

  48:     }

  49:     else

  50:     {

  51:       connections_.erase(conn);

  52:     }

  53:   }

  54:  

以下是服务端处理消息的代码，它遍历整个 connections_ 容器，把消息打包发送给各个客户连接。

  55:   void onStringMessage(const TcpConnectionPtr&,

  56:                        const string& message,

  57:                        Timestamp)

  58:   {

  59:     MutexLockGuard lock(mutex_);

  60:     for (ConnectionList::iterator it = connections_.begin();

  61:         it != connections_.end();

  62:         ++it)

  63:     {

  64:       codec_.send(get_pointer(*it), message);

  65:     }

  66:   }

  67:  

数据成员：

  68:   typedef std::set<TcpConnectionPtr> ConnectionList;

  69:   EventLoop* loop_;

  70:   TcpServer server_;

  71:   LengthHeaderCodec codec_;

  72:   MutexLock mutex_;

  73:   ConnectionList connections_;

  74: };

  75:  

main() 函数里边是例行公事的代码：

  76: int main(int argc, char* argv[])

  77: {

  78:   LOG_INFO << "pid = " << getpid();

  79:   if (argc > 1)

  80:   {

  81:     EventLoop loop;

  82:     uint16_t port = static_cast<uint16_t>(atoi(argv[1]));

  83:     InetAddress serverAddr(port);

  84:     ChatServer server(&loop, serverAddr);

  85:     server.start();

  86:     loop.loop();

  87:   }

  88:   else

  89:   {

  90:     printf("Usage: %s port\n", argv[0]);

  91:   }

  92: }

如果你读过 asio 的对应代码，会不会觉得 Reactor 往往比 Proactor 容易使用？

客户端的实现

我有时觉得服务端的程序常常比客户端的更容易写，聊天服务器再次验证了我的看法。客户端的复杂性来自于它要读取键盘输入，而 EventLoop 是独占线程的，所以我用了两个线程，main() 函数所在的线程负责读键盘，另外用一个 EventLoopThread 来处理网络 IO。我暂时没有把标准输入输出融入 Reactor 的想法，因为服务器程序的 stdin 和 stdout 往往是重定向了的。

来看代码，首先，在构造函数里注册回调，并使用了跟前面一样的 LengthHeaderCodec 作为中间层，负责打包分包。

   1: #include "codec.h"

   2:  

   3: #include <muduo/base/Logging.h>

   4: #include <muduo/base/Mutex.h>

   5: #include <muduo/net/EventLoopThread.h>

   6: #include <muduo/net/TcpClient.h>

   7:  

   8: #include <boost/bind.hpp>

   9: #include <boost/noncopyable.hpp>

  10:  

  11: #include <iostream>

  12: #include <stdio.h>

  13:  

  14: using namespace muduo;

  15: using namespace muduo::net;

  16:  

  17: class ChatClient : boost::noncopyable

  18: {

  19:  public:

  20:   ChatClient(EventLoop* loop, const InetAddress& listenAddr)

  21:     : loop_(loop),

  22:       client_(loop, listenAddr, "ChatClient"),

  23:       codec_(boost::bind(&ChatClient::onStringMessage, this, _1, _2, _3))

  24:   {

  25:     client_.setConnectionCallback(

  26:         boost::bind(&ChatClient::onConnection, this, _1));

  27:     client_.setMessageCallback(

  28:         boost::bind(&LengthHeaderCodec::onMessage, &codec_, _1, _2, _3));

  29:     client_.enableRetry();

  30:   }

  31:  

  32:   void connect()

  33:   {

  34:     client_.connect();

  35:   }

  36:  

disconnect() 目前为空，客户端的连接由操作系统在进程终止时关闭。

  37:   void disconnect()

  38:   {

  39:     // client_.disconnect();

  40:   }

  41:  

write() 会由 main 线程调用，所以要加锁，这个锁不是为了保护 TcpConnection，而是保护 shared_ptr。

  42:   void write(const string& message)

  43:   {

  44:     MutexLockGuard lock(mutex_);

  45:     if (connection_)

  46:     {

  47:       codec_.send(get_pointer(connection_), message);

  48:     }

  49:   }

  50:  

onConnection() 会由 EventLoop 线程调用，所以要加锁以保护 shared_ptr。

  51:  private:

  52:   void onConnection(const TcpConnectionPtr& conn)

  53:   {

  54:     LOG_INFO << conn->localAddress().toHostPort() << " -> "

  55:         << conn->peerAddress().toHostPort() << " is "

  56:         << (conn->connected() ? "UP" : "DOWN");

  57:  

  58:     MutexLockGuard lock(mutex_);

  59:     if (conn->connected())

  60:     {

  61:       connection_ = conn;

  62:     }

  63:     else

  64:     {

  65:       connection_.reset();

  66:     }

  67:   }

  68:  

把收到的消息打印到屏幕，这个函数由 EventLoop 线程调用，但是不用加锁，因为 printf() 是线程安全的。

注意这里不能用 cout，它不是线程安全的。

  69:   void onStringMessage(const TcpConnectionPtr&,

  70:                        const string& message,

  71:                        Timestamp)

  72:   {

  73:     printf("<<< %s\n", message.c_str());

  74:   }

  75:  

数据成员：

  76:   EventLoop* loop_;

  77:   TcpClient client_;

  78:   LengthHeaderCodec codec_;

  79:   MutexLock mutex_;

  80:   TcpConnectionPtr connection_;

  81: };

  82:  

main() 函数里除了例行公事，还要启动 EventLoop 线程和读取键盘输入。

  83: int main(int argc, char* argv[])

  84: {

  85:   LOG_INFO << "pid = " << getpid();

  86:   if (argc > 2)

  87:   {

  88:     EventLoopThread loopThread;

  89:     uint16_t port = static_cast<uint16_t>(atoi(argv[2]));

  90:     InetAddress serverAddr(argv[1], port);

  91:  

  92:     ChatClient client(loopThread.startLoop(), serverAddr); // 注册到 EventLoopThread 的 EventLoop 上。

  93:     client.connect();

  94:     std::string line;

  95:     while (std::getline(std::cin, line))

  96:     {

  97:       string message(line.c_str()); // 这里似乎多此一举，可直接发送 line。这里是

  98:       client.write(message);

  99:     }

 100:     client.disconnect();

 101:   }

 102:   else

 103:   {

 104:     printf("Usage: %s host_ip port\n", argv[0]);

 105:   }

 106: }

 107:  

简单测试

开三个命令行窗口，在第一个运行

$ ./asio_chat_server 3000

第二个运行

$ ./asio_chat_client 127.0.0.1 3000

第三个运行同样的命令

$ ./asio_chat_client 127.0.0.1 3000

这样就有两个客户端进程参与聊天。在第二个窗口里输入一些字符并回车，字符会出现在本窗口和第三个窗口中。

下一篇文章我会介绍 Muduo 中的定时器，并实现 Boost.Asio 教程中的 timer2~5 示例，以及带流量统计功能的 discard 和 echo 服务器（来自 Java Netty）。流量等于单位时间内发送或接受的字节数，这要用到定时器功能。

(待续)

Blog.csdn.net/Solstice

Muduo 全系列文章列表： http://blog.csdn.net/Solstice/category/779646.aspx

我将会写一系列文章，介绍用 muduo 网络库完成常见的 TCP 网络编程任务。目前计划如下：

1. UNP 中的简单协议，包括 echo、daytime、time、discard 等。 
2. Boost.Asio 中的示例，包括 timer2~6、chat 等。
3. Java Netty 中的示例，包括 discard、echo、uptime 等，其中的 discard 和 echo 带流量统计功能。
4. Python twisted 中的示例，包括 finger01~07
5. 云风的串并转换连接服务器 multiplexer，包括单线程和多线程两个版本。
6. 用于测试两台机器的往返延迟的 roundtrip
7. 用于测试两台机器的带宽的 pingpong
8. 文件传输
9. 一个基于 TCP 的应用层广播 hub
10. socks4a 代理服务器，包括简单的 TCP 中继(relay)。
11. 一个 Sudoku 服务器的演变，从单线程到多线程，从阻塞到 event-based。
12. 一个提供短址服务的 httpd 服务器

其中前面 7 个已经放到了 muduo 代码的 examples 目录中，下载地址是： http://muduo.googlecode.com/files/muduo-0.1.5-alpha.tar.gz 

这些例子都比较简单，逻辑不复杂，代码也很短，适合摘取关键部分放到博客上。其中一些有一定的代表性与针对性，比如“如何传输完整的文件”估计是网络编程的初学者经常遇到的问题。请注意，muduo 是设计来开发内网的网络程序，它没有做任何安全方面的加强措施，如果用在公网上可能会受到攻击，在后面的例子中我会谈到这一点。

本系列文章适用于 Linux 2.6.x (x > 25)，主要测试发行版为 Ubuntu 10.04 LTS 和 Debian 6.0 Squeeze，64-bit x86 硬件。

TCP 网络编程本质论

我认为，TCP 网络编程最本质的是处理三个半事件：

1. 连接的建立，包括服务端接受 (accept) 新连接和客户端成功发起 (connect) 连接。
2. 连接的断开，包括主动断开 (close 或 shutdown) 和被动断开 (read 返回 0)。
3. 消息到达，文件描述符可读。这是最为重要的一个事件，对它的处理方式决定了网络编程的风格（阻塞还是非阻塞，如何处理分包，应用层的缓冲如何设计等等）。
4. 消息发送完毕，这算半个。对于低流量的服务，可以不必关心这个事件；另外，这里“发送完毕”是指将数据写入操作系统的缓冲区，将由 TCP 协议栈负责数据的发送与重传，不代表对方已经收到数据。

这其中有很多难点，也有很多细节需要注意，比方说：

1. 如果要主动关闭连接，如何保证对方已经收到全部数据？如果应用层有缓冲（这在非阻塞网络编程中是必须的，见下文），那么如何保证先发送完缓冲区中的数据，然后再断开连接。直接调用 close(2) 恐怕是不行的。
2. 如果主动发起连接，但是对方主动拒绝，如何定期 (带 back-off) 重试？
3. 非阻塞网络编程该用边沿触发(edge trigger)还是电平触发(level trigger)？（这两个中文术语有其他译法，我选择了一个电子工程师熟悉的说法。）如果是电平触发，那么什么时候关注 EPOLLOUT 事件？会不会造成 busy-loop？如果是边沿触发，如何防止漏读造成的饥饿？epoll 一定比 poll 快吗？
4. 在非阻塞网络编程中，为什么要使用应用层缓冲区？假如一次读到的数据不够一个完整的数据包，那么这些已经读到的数据是不是应该先暂存在某个地方，等剩余的数据收到之后再一并处理？见 lighttpd 关于 \r\n\r\n 分包的 bug。假如数据是一个字节一个字节地到达，间隔 10ms，每个字节触发一次文件描述符可读 (readable) 事件，程序是否还能正常工作？lighttpd 在这个问题上出过安全漏洞。
5. 在非阻塞网络编程中，如何设计并使用缓冲区？一方面我们希望减少系统调用，一次读的数据越多越划算，那么似乎应该准备一个大的缓冲区。另一方面，我们系统减少内存占用。如果有 10k 个连接，每个连接一建立就分配 64k 的读缓冲的话，将占用 640M 内存，而大多数时候这些缓冲区的使用率很低。muduo 用 readv 结合栈上空间巧妙地解决了这个问题。
6. 如果使用发送缓冲区，万一接收方处理缓慢，数据会不会一直堆积在发送方，造成内存暴涨？如何做应用层的流量控制？
7. 如何设计并实现定时器？并使之与网络 IO 共用一个线程，以避免锁。

这些问题在 muduo 的代码中可以找到答案。

Muduo 简介

我编写 Muduo 网络库的目的之一就是简化日常的 TCP 网络编程，让程序员能把精力集中在业务逻辑的实现上，而不要天天和 Sockets API 较劲。借用 Brooks 的话说，我希望 Muduo 能减少网络编程中的偶发复杂性 (accidental complexity)。

Muduo 只支持 Linux 2.6.x 下的并发非阻塞 TCP 网络编程，它的安装方法见陈硕的 blog 文章。

Muduo 的使用非常简单，不需要从指定的类派生，也不用覆写虚函数，只需要注册几个回调函数去处理前面提到的三个半事件就行了。

以经典的 echo 回显服务为例：

1. 定义 EchoServer class，不需要派生自任何基类：

在构造函数里注册回调函数：

2. 实现 EchoServer::onConnection() 和 EchoServer::onMessage()：

3. 在 main() 里用 EventLoop 让整个程序跑起来：

完整的代码见 muduo/examples/simple/echo。
这个几十行的小程序实现了一个并发的 echo 服务程序，可以同时处理多个连接。
对这个程序的详细分析见下一篇博客《Muduo 网络编程示例之一：五个简单 TCP 协议》

(待续)

测试对象

• libevent 2.0.6-rc， 源代码包 http://monkey.org/~provos/libevent-2.0.6-rc.tar.gz 
• muduo 0.1.2-alpha，源码 http://muduo.googlecode.com/files/muduo-0.1.2-alpha.tar.gz SHA1 Checksum: 9e7da4b46ad87602dd206eaedf54e67c17dfe4e1 。须编译为 release 版。

测试环境

测试用的软硬件环境与《muduo 与 boost asio 吞吐量对比》和《muduo 与 libevent2 吞吐量对比》相同，另外我还在自己的笔记本上运行了测试，结果也附在后面。

测试内容

测试的场景是：有 1000 个人围成一圈，玩击鼓传花的游戏，一开始第 1 个人手里有花，他把花传给右手边的人，那个人再继续把花传给右手边的人，当花转手 100 次之后游戏停止，记录从开始到结束的时间。

用程序表达是，有 1000 个网络连接 (socketpairs 或 pipes)，数据在这些连接中顺次传递，一开始往第 1 个连接里写 1 个字节，然后从这个连接的另一头读出这 1 个字节，再写入第 2 个连接，然后读出来继续写到第 3 个连接，直到一共写了 100 次之后程序停止，记录所用的时间。

以上是只有一个活动连接的场景，我们实际测试的是 100 个或 1000 个活动连接（即 100 朵花或 1000 朵花，均匀分散在人群手中），而连接总数（即并发数）从 100 到 100,000 (十万)。注意每个连接是两个文件描述符，为了运行测试，需要调高每个进程能打开的文件数，比如设为 256000。

libevent2 的测试代码位于 test/bench.c，我修复了 2.0.6-rc 版里的一个小 bug，修正后的代码见 http://github.com/chenshuo/recipes/blob/master/pingpong/libevent/bench.c

muduo 的测试代码位于 examples/pingpong/bench.cc，见 http://gist.github.com/564985#file_pingpong_bench.cc

测试结果与讨论

第一轮，分别用 100 个活动连接和 1000 个活动连接，无超时，读写 100 次，测试一次游戏的总时间（包含初始化）和事件处理的时间（不包含注册 event watcher）随连接数（并发数）变化的情况。具体解释见 libev 的性能测试文档 http://libev.schmorp.de/bench.html ，不同之处在于我们不比较 timer event 的性能，只比较 IO event 的性能。对每个并发数，程序循环 25 次，刨去第一次的热身数据，后 24 次算平均值。测试用的脚本在 http://github.com/chenshuo/recipes/blob/master/pingpong/libevent/run_bench.sh 。这个脚本是 libev 的作者 Marc Lehmann 写的，我略作改用，用于测试 muduo 和 libevent2。

第一轮的结果，请先只看红线和绿线。红线是 libevent2 用的时间，绿线是 muduo 用的时间。数字越小越好。注意这个图的横坐标是对数的，每一个数量级的取值点为 1, 2, 3, 4, 5, 6, 7.5, 10。

从红绿线对比可以看出：

1. libevent2 在初始化 event watcher 上面比 muduo 快 20% （左边的两个图）

2. 在事件处理方面（右边的两个图）：a) 在 100 个活动连接的情况下，libevent2 和 muduo 分段领先。当总连接数（并发数）小于 1000 时，二者性能差不多；当总连接数大于 30000 时，muduo 略占优；当总连接数大于 1000 小于 30000 时，libevent2 明显领先。b) 在 1000 个活动连接的情况下，当并发数小于 10000 时，libevent2 和 muduo 得分接近；当并发数大于 10000 时，muduo 明显占优。

这里我们有两个问题：1. 为什么 muduo 花在初始化上的时间比较多？ 2. 为什么在一些情况下它比 libevent2 慢很多。

我仔细分析了其中的原因，并参考了 libev 的作者 Marc Lehmann 的观点 ( http://lists.schmorp.de/pipermail/libev/2010q2/001041.html )，结论是：在第一轮初始化时，libevent2 和 muduo 都是用 epoll_ctl(fd, EPOLL_CTL_ADD, …) 来添加 fd event watcher。不同之处在于，在后面 24 轮中，muduo 使用了 epoll_ctl(fd, EPOLL_CTL_MOD, …) 来更新已有的 event watcher；然而 libevent2 继续调用 epoll_ctl(fd, EPOLL_CTL_ADD, …) 来重复添加 fd，并忽略返回的错误码 EEXIST (File exists)。在这种重复添加的情况下，EPOLL_CTL_ADD 将会快速地返回错误，而 EPOLL_CTL_MOD 会做更多的工作，花的时间也更长。于是 libevent2 捡了个便宜。

为了验证这个结论，我改动了 muduo，让它每次都用 EPOLL_CTL_ADD 方式初始化和更新 event watcher，并忽略返回的错误。

第二轮测试结果见上图的蓝线，可见改动之后的 muduo 的初始化性能比 libevent2 更好，事件处理的耗时也有所降低（我推测是 kernel 内部的原因）。

这个改动只是为了验证想法，我并没有把它放到 muduo 最终的代码中去，这或许可以留作日后优化的余地。（具体的改动是 muduo/net/poller/EPollPoller.cc 第 115 行和 144 行，读者可自行验证。）

同样的测试在双核笔记本电脑上运行了一次，结果如下：（我的笔记本的 CPU 主频是 2.4GHz，高于台式机的 1.86GHz，所以用时较少。）

结论：在事件处理效率方面，muduo 与 libevent2 总体比较接近，各擅胜场。在并发量特别大的情况下（大于 10k），muduo 略微占优。

关于 muduo 的更多介绍请见《发布一个基于 Reactor 模式的 C++ 网络库》。muduo 的项目网站是 http://code.google.com/p/muduo ，上面有个 class diagram 可供参考。

本文用 ping pong 测试来对比 muduo 和 libevent2 的吞吐量，测试结果表明 muduo 吞吐量平均比 libevent2 高 18% 以上，个别情况达到 70%。

测试对象

• libevent 2.0.6-rc (http://monkey.org/~provos/libevent-2.0.6-rc.tar.gz)
• muduo 0.1.1 (http://muduo.googlecode.com/files/muduo-0.1.1-alpha.tar.gz) SHA1 Checksum: a446ea8a22915f439063d2bc52eb2dc4b9caf92d

测试环境与测试方法

测试环境与前文《muduo 与 boost asio 吞吐量对比》相同。

我自己编写了 libevent2 的 ping pong 测试代码，地址在 http://github.com/chenshuo/recipes/tree/master/pingpong/libevent/ 。由于这个测试代码没有使用多线程，所以本次测试只对比单线程下的性能。

测试内容为：客户端与服务器运行在同一台机器，均为单线程，测试并发连接数为 1/10/100/1000/10000 时的吞吐量。

在同一台机器测试吞吐量的原因：

• 现在的 CPU 很快，即便是单线程单 TCP 连接也能把 Gigabit 以太网的带宽跑满。如果用两台机器，所有的吞吐量测试结果都将是 100 MiB/s，失去了对比的意义。（或许可以对比哪个库占的 CPU 少。）
• 在同一台机器上测试，可以在 CPU 资源相同的情况下，单纯对比网络库的效率。也就是说单线程下，服务端和客户端各占满 1 个 CPU，比较哪个库的吞吐量高。

测试结果

单线程吞吐量测试，数字越大越好：

以上结果让人大跌眼镜，muduo 居然比 libevent 快 70%！跟踪 libevent2 的源代码发现，它每次最多从 socket 读取 4096 字节的数据 (证据在 buffer.c 的 evbuffer_read() 函数)，怪不得吞吐量比 muduo 小很多。因为在这一测试中，muduo 每次读取 16384 字节，系统调用的性价比较高。

buffer.c:#define EVBUFFER_MAX_READ      4096

为了公平起见，我再测了一次，这回两个库都发送 4096 字节的消息。

测试结果表明 muduo 吞吐量平均比 libevent2 高 18% 以上。

讨论

由于 libevent2 每次最多从网络读取 4096 字节，大大限制了它的吞吐量。

测试对象

• boost 1.40 中的 asio 1.4.3
• asio 1.4.5 (http://think-async.com/Asio/Download)
• muduo 0.1.1 (http://muduo.googlecode.com/files/muduo-0.1.1-alpha.tar.gz) SHA1 Checksum: a446ea8a22915f439063d2bc52eb2dc4b9caf92d

测试环境

硬件：DELL 490 工作站，双路 Intel quad core Xeon E5320 CPU，16G 内存

操作系统：Ubuntu Linux Server 10.04.1 LTS x86_64

编译器：g++ 4.4.3

测试方法

依据 asio 性能测试 http://think-async.com/Asio/LinuxPerformanceImprovements 的办法，用 ping pong 协议来测试吞吐量。

简单地说，ping pong 协议是客户端和服务器都实现 echo 协议。当 TCP 连接建立时，客户端向服务器发送一些数据，服务器会 echo 回这些数据，然后客户端再 echo 回服务器。这些数据就会像乒乓球一样在客户端和服务器之间来回传送，直到有一方断开连接为止。这是用来测试吞吐量的常用办法。

asio 的测试代码取自 http://asio.cvs.sourceforge.net/viewvc/asio/asio/src/tests/performance/ ，未作更改。

muduo 的测试代码在 0.1.1 软件包内，路径为 examples/pingpong/，代码如 http://gist.github.com/564985 所示。

muduo 和 asio 的优化编译参数均为 -O2 -finline-limit=1000

$ BUILD_TYPE=release ./build.sh  # 编译 muduo 的优化版本

我主要做了两项测试：

• 单线程测试，测试并发连接数为 1/10/100/1000/10000 时的吞吐量。
• 多线程测试，并发连接数为 100 或 1000，服务器和客户端的线程数同时设为 1/2/3/4。（由于我家里只有一台 8 核机器，而且服务器和客户端运行在同一台机器上，线程数大于 4 没有意义。）

所有测试中，ping pong 消息的大小均为 16k bytes。测试用的 shell 脚本可从 http://gist.github.com/564985 下载。

测试结果

单线程测试的结果，数字越大越好：

多线程测试的结果，数字越大越好：

测试结果表明 muduo 吞吐量平均比 asio 高 15% 以上。

讨论

muduo 出乎意料地比 asio 性能优越，我想主要得益于其简单的设计和简洁的代码。

asio 在多线程测试中表现不佳，我猜测其主要原因是测试代码只使用了一个 io_service，如果改用“io_service per CPU”的话，性能应该有所提高。我对 asio 的了解程度仅限于能读懂其代码，希望能有 asio 高手编写“io_service per CPU”的 ping pong 测试，以便与 muduo 做一个公平的比较。

ping pong 测试很容易实现，欢迎其他网络库（ACE、POCO、libevent 等）也能加入到对比中来，期待这些库的高手出马。

陈硕 (giantchen_AT_gmail)

Blog.csdn.net/Solstice

2010 Aug 30

本文主要介绍 muduo 网络库的使用。其设计与实现将有另文讲解。

目录

由来 1

下载与编译 2

例子 2

基本结构 3

公开接口 4

内部实现 4

线程模型 5

结语 5

由来

半年前我写了一篇《学之者生，用之者死——ACE历史与简评》，其中提到“我心目中理想的网络库”的样子：

• 线程安全，支持多核多线程
• 不考虑可移植性，不跨平台，只支持 Linux，不支持 Windows。
• 在不增加复杂度的前提下可以支持 FreeBSD/Darwin，方便将来用 Mac 作为开发用机，但不为它做性能优化。也就是说 IO multiplexing 使用 poll 和 epoll。
• 主要支持 x86-64，兼顾 IA32
• 不支持 UDP，只支持 TCP
• 不支持 IPv6，只支持 IPv4
• 不考虑广域网应用，只考虑局域网
• 只支持一种使用模式：non-blocking IO + one event loop per thread，不考虑阻塞 IO
• API 简单易用，只暴露具体类和标准库里的类，不使用 non-trivial templates，也不使用虚函数
• 只满足常用需求的 90%，不面面俱到，必要的时候以 app 来适应 lib
• 只做 library，不做成 framework
• 争取全部代码在 5000 行以内（不含测试）
• 以上条件都满足时，可以考虑搭配 Google Protocol Buffers RPC

在想清楚这些目标之后，我开始第三次尝试编写自己的 C++ 网络库。与前两次不同，这次我一开始就想好了库的名字，叫 muduo （木铎），并在 Google code 上创建了项目： http://code.google.com/p/muduo/ 。muduo 的主体内容在 5 月底已经基本完成，现在我把它开源。

本文主要介绍 muduo 网络库的使用，其设计与实现将有另文讲解。

下载与编译

下载地址： http://muduo.googlecode.com/files/muduo-0.1.0-alpha.tar.gz

SHA1 Checksum: 5d3642e311177ded89ed0d15c10921738f8c984c

Muduo 使用了 Linux 较新的系统调用，要求 Linux 的内核版本大于 2.6.28 （我自己用的是 2.6.32 ）。在 Debian Squeeze / Ubuntu 10.04 LTS 上编译测试通过，32 位和 64 位系统都能使用。

Muduo 采用 CMake 为 build system，安装方法：

$ sudo apt-get install cmake

Muduo 依赖 Boost，很容易安装：

$ sudo apt-get install libboost1.40-dev # 或 libboost1.42-dev

编译方法很简单：

$ tar zxf muduo-0.1.0-alpha.tar.gz

$ cd muduo/

$ ./build.sh

# 编译生成的可执行文件和静态库文件分别位于 ../build/debug/{bin,lib}

如果要编译 release 版，可执行

$ BUILD_TYPE=release ./build.sh

# 编译生成的可执行文件和静态库文件分别位于 ../build/release/{bin,lib}

编译完成之后请试运行其中的例子。比如 bin/inspector_test ，然后通过浏览器访问 http://10.0.0.10:12345/ 或 http://10.0.0.10:12345/proc/status，其中 10.0.0.10 替换为你的 Linux box 的 IP。

例子

Muduo 附带了几十个小例子，位于 examples 目录。其中包括从 Boost.Asio、JBoss Netty、Python Twisted 等处移植过来的例子。

examples

|-- simple # 简单网络协议的实现

|   |-- allinone  # 在一个程序里同时实现下面 5 个协议

|   |-- chargen   # RFC 864，可测试带宽

|   |-- daytime # RFC 867

|   |-- discard # RFC 863

|   |-- echo # RFC 862

|   |-- time # RFC 868

|   `-- timeclient # time 协议的客户端

|-- hub # 一个简单的 pub/sub/hub 服务，演示应用级的广播

|-- roundtrip # 测试两台机器的网络延时与时间差

|-- asio # 从 Boost.Asio 移植的例子

|   |-- chat # 聊天服务

|   `-- tutorial # 一系列 timers

|-- netty # 从 JBoss Netty 移植的例子

|   |-- discard # 可用于测试带宽，服务器可多线程运行

|   |-- echo # 可用于测试带宽，服务器可多线程运行

|   `-- uptime # TCP 长连接

`-- twisted # 从 Python Twisted 移植的例子

    `-- finger # finger01 ~ 07

基本结构

Muduo 的目录结构如下。

muduo

|-- base # 与网络无关的基础代码，已提前发布

`-- net # 网络库

    |-- http # 一个简单的可嵌入的 web 服务器

    |-- inspect # 基于以上 web 服务器的“窥探器”，用于报告进程的状态

    `-- poller # poll(2) 和 epoll(4) 两种 IO multiplexing 后端

Muduo 是基于 Reactor 模式的网络库，其核心是个事件循环 EventLoop，用于响应计时器和 IO 事件。Muduo 采用基于对象（object based）而非面向对象（object oriented）的设计风格，其接口多以 boost::function + boost::bind 表达。

Muduo 的头文件明确分为客户可见和客户不可见两类。客户可见的为白底，客户不可见的为灰底。

这里简单介绍各个头文件及 class 的作用，详细的介绍留给以后的博客。

公开接口

• Buffer 仿 Netty ChannelBuffer 的 buffer class，数据的读写透过 buffer 进行
• InetAddress 封装 IPv4 地址 (end point)，注意，muduo 目前不能解析域名，只认 IP
• EventLoop 反应器 Reactor，用户可以注册计时器回调
• EventLoopThread 启动一个线程，在其中运行 EventLoop::loop()
• TcpConnection 整个网络库的核心，封装一次 TCP 连接
• TcpClient 用于编写网络客户端，能发起连接，并且有重试功能
• TcpServer 用于编写网络服务器，接受客户的连接
• 在这些类中，TcpConnection 的生命期依靠 shared_ptr 控制（即用户和库共同控制）。Buffer 的生命期由 TcpConnection 控制。其余类的生命期由用户控制。
• HttpServer 和 Inspector，暴露出一个 http 界面，用于监控进程的状态，类似于 Java JMX。这么做的原因是，《程序员修炼之道》第 6 章第 34 条提到“对于更大、更复杂的服务器代码，提供其操作的内部试图的一种漂亮技术是使用内建的 Web 服务器”，Jeff Dean 也说“（每个 Google 的服务器进程）Export HTML-based status pages for easy diagnosis”。

内部实现

• Channel 是 selectable IO channel，负责注册与响应 IO 事件，它不拥有 file descriptor。它是 Acceptor、Connector、EventLoop、TimerQueue、TcpConnection 的成员，生命期由后者控制。
• Socket 封装一个 file descriptor，并在析构时关闭 fd。它是 Acceptor、TcpConnection 的成员，生命期由后者控制。EventLoop、TimerQueue 也拥有 fd，但是不封装为 Socket。
• SocketsOps 封装各种 sockets 系统调用。
• EventLoop 封装事件循环，也是事件分派的中心。它用 eventfd(2) 来异步唤醒，这有别于传统的用一对 pipe(2) 的办法。它用 TimerQueue 作为计时器管理，用 Poller 作为 IO Multiplexing。
• Poller 是 PollPoller 和 EPollPoller 的基类，采用“电平触发”的语意。它是 EventLoop 的成员，生命期由后者控制。
• PollPoller 和 EPollPoller 封装 poll(2) 和 epoll(4) 两种 IO Multiplexing 后端。Poll 的存在价值是便于调试，因为 poll(2) 调用是上下文无关的，用 strace 很容易知道库的行为是否正确。
• Connector 用于发起 TCP 连接，它是 TcpClient 的成员，生命期由后者控制。
• Acceptor 用于接受 TCP 连接，它是 TcpServer 的成员，生命期由后者控制。
• TimerQueue 用 timerfd 实现定时，这有别于传统的设置 poll/epoll_wait 的等待时长的办法。为了简单起见，目前用链表来管理 Timer，如果有必要可改为优先队列，这样复杂度可从 O(n) 降为 O(ln n) （某些操作甚至是 O(1)）。它是 EventLoop 的成员，生命期由后者控制。
• EventLoopThreadPool 用于创建 IO 线程池，也就是说把 TcpConnection 分派到一组运行 EventLoop 的线程上。它是 TcpServer 的成员，生命期由后者控制。

线程模型

Muduo 的线程模型符合我主张的 one loop per thread + thread pool 模型。每个线程最多有一个 EventLoop。每个 TcpConnection 必须归某个 EventLoop 管理，所有的 IO 会转移到这个线程，换句话说一个 file descriptor 只能由一个线程读写。TcpConnection 所在的线程由其所属的 EventLoop 决定，这样我们可以很方便地把不同的 TCP 连接放到不同的线程去，也可以把一些 TCP 连接放到一个线程里。TcpConnection 和 EventLoop 是线程安全的，可以跨线程调用。TcpServer 直接支持多线程，它有两种模式：

1. 单线程，accept 与 TcpConnection 用同一个线程做 IO。

2. 多线程，accept 与 EventLoop 在同一个线程，另外创建一个 EventLoopThreadPool，新到的连接会按 round-robin 方式分配到线程池中。

结语

Muduo 是我对常见网络编程任务的总结，用它我能很容易地编写多线程的 TCP 服务器和客户端。Muduo 是我业余时间的作品，代码估计还有很多 bug，功能也不完善（例如不支持 signal 处理），待日后慢慢改进吧。