对于 netcat 程序，存在两种模式，即 服务端 和 客户端， 它们的区别在于连接建立的方式。 一旦连接建立，客户端/服务器 的行为都是一样的，使用两个并行的循环处理：
- 从标准输入，写到 TCP Socket
- 从 TCP Socket 读， 写到标准输出
主要有两种基本的并发模型：
- 多线程配合阻塞IO
- IO多路复用配合非阻塞
这里提供三种netcat的实现：
- recipes/tpc/netcat.cc thread-per-connection
- recipes/python/netcat.py IO-multiplexing
- recipes/python/netcat-nonblock.py IO-multiplexing
以及，为了测试以上 netcat 程序，这里还提供了对应的负载生成器：
- recipes/tpc/chargen.cc
- recipes/python/chargen.py
- muduo/examples/simple/chargen/*
对于 netcat 的实现这里提供了三个版本，多线程配合阻塞IO、IO多路复用配合阻塞IO、IO多路复用配合非阻塞IO。其中 IO多路复用配合非阻塞IO 实现的netcat使用不当会使整个程序阻塞。
测试- 右边窗口运行 chargen
- 左上运行 utop，可以看到每个程序的 CPU 使用率
左下运行 netcat
- 约为 1360MiB/s
- 约为 3200MiB/s
- 通过对比，我们可以发现自实现的 netcat 比系统实现的要快一些
分析 cpu 的使用率我们可以发现，在测试系统自带的 netcat 时，nc cpu 100%， 而chargen cpu 35%， 说明在测试结果11360 MiB/s 中， nc 程序是性能的瓶颈，拖慢了整个数据的传输速率。
而在测试自带的 nc 性能时，chargen cpu 100%，nc 接近 100%，测得性能为 3200 MiB/s 。
此时，如果我们再加上一个 pv 命令用于显示实时带宽，就会发现整体的测试结果会下降到 1130 MiB/s 左右。此时如果我们关注cpu的占用率，就会发现 pv 占用了一部分 cpu，导致 chargen 程序的cpu占用下降，从而拖慢了整个测试结果。
- 约为 940 MiB/s
- 约为 958 MiB/s
