网络系统

Droplet写过一些Network应用实现的模式，鉴于网络设备的复杂性，还有不少D还没有囊括进去，我这里补充一种累积下发模式：

其实很简单，如果发送方有很多小的消息需要发送，延迟一会儿累积一些消息一并发送。这里一般有两个条件会触发发送：

1.在消息积累到一定数量的时候，超过Threshold的时候发送累积消息。

2.在消息没有达到threshold，但是经过一定超时时间的时候，也发送。

这个模式很常用，其实熟悉TCP协议的人会想到Nagle算法就是完全使用这种模式，当时解决的问题是Telnet协议中的大量小报文造成的协议损耗以及低速链路的拥塞。Nagle算法是84年采纳的，当时网络还很不发达，行家更少，以至于这样简单的设计也会成为著名算法，恨不早生20年，也发明一下":-)

在看讲网络处理器或者是路由器芯片的书里面，一定会把网络包的处理分为ingress和egress。如果从做软件的

角度来看，比如linux网络协议栈，好像完全没有必要这么来划分。因为一般来说，linux协议栈看到都是网卡设备，

而不会有从switch fabric来的包，这就是最大的不同。

一般来说，ingress processing包括：

■ Error checking.
■ Security checking and decoding.
■ Classifi cation (or demultiplexing).
■ Traffi c management (measurement and policing).
■ Searching (usually address lookup).
■ Header manipulations.
■ Packet reassembly.
■ Packet prioritization and queueing.
■ Packet forwarding.

而egress processing包括：

■ Calculating and adding checksum (or any error detection and correcting codes).
■ Address lookup.
■ Packet forwarding.
■ Segmentation and fragmentation.
■ Traffic management (shaping, timing, and scheduling).
■ Packet prioritization and queueing.
■ Security processing (e.g., encoding).

如果没有switch fabric接口，就不需要egress processing了吗？当然也不是。在有些设计里面会提到，

一个包从同一个芯片进出，还是需要到switch fabric过一下；而有些则不需要。如果每个包的逻辑是一样

的，很显然可以简化设计；但是如果能在发出去判断一下这个包去哪里，节省去switch fabric的时间，性能

可能会好一点，但相信不会有太大的提高。有懂行的人能说说吗？

参考资料：

1）Network Processors: Architecture, Programming,and Implementation

2)  http://www.tektalk.org/2010/02/07/alu-fp2%e8%8a%af%e7%89%87%e7%bb%84-%e3%80%82-100ge%e7%ba%bf%e5%8d%a1-%e3%80%8277507450/

http://www.tektalk.org/2011/06/18/%e5%af%b9%e5%a4%a7%e9%80%81%e7%b3%bb%e7%bb%9f%e8%bd%af%e4%bb%b6%e6%9e%b6%e6%9e%84%e5%b8%88%e7%...

有诗云：人之老，其言真；人之去；其行善。

系统软件设计是软件系统的皇冠中的宝石。绚烂美丽。令无数男女痴迷。

在系统软件，特别是通信系统软件的设计上，有没有一些可以提炼的方法论？

今身处幽州（北平），心在大宋。聊聊数语。谈谈我对大宋年轻一代的系统软件工程师的期望。

1。 The Thinner vs. The Thicker
年轻人都以为有些事情需要粗，有些事情需要厚。其实，合适就好。。。

系统软件一定要越细越好；越薄越好。

我在华为做speech的时候，也提到过：能把系统软件做薄，才是一代高手。

最可怕的就是为了做而做。

最高境界是：能不做就不做。

每一行代码，都会成为历史（Legacy）；每一份恋情都会成为过去。

工程的事情，就是要简简单单。

内在算法的复杂不代表外在的臃肿。

一个女人，要的是清澈美丽；而非妖娆迷人。

智慧者应该做的是cut；而非单纯的add。

2。 Re－Create vs Re－Search

ReCreate是工程之大忌。任何一个问题，必须首先养成良好的科研习惯：
－－是否陈首席已经解答过类似的问题。
－－是否友商（敌商）解决过类似的问题。
－－是否Open Source领域已经解决过类似的问题。
－－是否Google和Baidu已经解答过类似的问题。

如果有，拿来主义基础上的改良主义就是最好的。重复发明已经发明了的算法，模型是兵家之大忌。
学术界的Research的意思是：伊人已经在阑珊处；要的是反复寻找，找到你的爱人。
工业界的Recreate是：瞎折腾。利己但害公司。

3。 Qualitative vs Quantitative
大宋文化博大精深，但似乎更多的是在形而上，在君臣父子，为相为官上做文章。

自然科学在中国的错失是我们大宋百年之痛之根本之一

定性和定量分析的有机结合，是成为一个优秀的系统软件架构师的基本素养。

只有定性分析的胶片，是研发之大忌。

一定要养成能case study，算法分析的良好工作习惯。

要的是数据说话；不要的是框架忽悠。
4。 Feature Parity vs Disruptive Innovation

大宋某公司特别喜欢玩一个词汇：技术断裂点。还有一些：领先世界产品的优势点。

这基本上是胡扯。或者从大样本的角度，是胡扯。是文革作风。是党八股。

作为一个工程设计人员，不要羞于Feature Parity。学习和模仿美军，伪军的东西，是提高自己的最佳方法。不要上来就是什么断裂点。

邓公稼先都说：我们这几代人要做的是使得国家不要差距加大。

我们这2，3代人能做的是：Follow。领先基本上不存在现实。

这其中，最大的问题不是工程，而是教育的落后。教育的落后使得我们不存在成为一个高科技大国的基础yet。

所以，不要有强迫症，没事玩断裂点。跟上并略微有改良就好。

这就好比，明明不是AV明星，非要玩AV明星的动作。。。受罪。

请把创新留给90后和00后吧。。。

5。 Semi－Optimal Optimization vs Full－Optimal Optimization

工程上，没有最好的算法；只有最好的折衷。
爱情上，没有最好的恋人；只有心中的情人。

不要过分追求最佳算法。要能把握算法带来的时间和空间上代价的折衷。更为重要的是，在工程上，如果出了问题，调试，调优和定位带来的代价。否则，能解决问题的算法，就是好算法。

6。 Application vs System

系统是为应用服务的。

http://www.tektalk.org/2011/06/14/%e5%af%b9%e4%b8%8b%e4%b8%80%e4%bb%a3%e9%ab%98%e7%ab%af%e9%80%9a%e4%bf%a1%e7%b3%bb%e7%bb%9f%e8%...

高端通信系统设计从来就是一个困难的话题。一个优秀的系统设计往往决定了其竞争力和相应的生命周期。

本文试图阐述笔者对下一代高端通信系统设计的一些展望。抛豆腐引砖块，其目的是通过读者的评论，使得美军，共军，国军，伪军等的知识和经验可以共享。使得Open Source的精神发扬光大。

1。 LDF Rule（Legacy Decides Future）
系统都是演变的，而非设计的。一个好的系统设计必须首先满足对历史系统，历史代码的演进路标。否则，就是在做Science，而非Engineering。这方面最大的挑战就是在哪个release去掉哪些历史遗留问题。改良的代价一定是小于革命。

在这个第一重要的法则里，要求的是系统设计师必须了解细节。需要能进能出［想歪了的同学请自己惩罚一下自己邪恶的心灵］。要的是能bottom up。然后在bottom up的基础上，进行top down的设计。缺一不可。只能bottom inside，是一个单纯的工程师；只能top through就是一个玩胶片的大忽悠。

2。 CDMD Convergence Rule
（Control Plane，Data Plane，Management Plane and Debug Plane Convergence）
这个rule类似与我大宋气功中的一句经典法则：人身无处不丹田。啥意思呢？
控制平面，数据平面，管理平面，调试平面都将是一个逻辑的概念，而非一个物理的实体，例如控制平面卡，数据平面卡。。。

上述的各个Plane都是你中有我，我中有你。［想歪了的同学请自己惩罚一下自己邪恶的心灵］。

在任何一个环节都需要有相应的逻辑部分。整体系统的任何一个平面是通过分布在系统各个环节中的子平面来共同构成的。

这方面最大的挑战是：系统架构师必须对分布式系统的设计非常过敏，sorry，敏感。

在分布式系统设计中，一个最重要的理论悖论是： 在分布式系统中，在任何时刻，在任何一个节点上，是无法知道当时的全局状态的。

这是啥意思呢？

就是，除了上帝，你在一个时刻点Ti，是不可能知道Ti时刻系统其他信息的。你能知道的信息只能是T（i＋Delta）。这个Delta就是通信开销所带来的。

大白话就是，杨小姐（杨贵妃），从理论上，Y从来就没有吃过新鲜的荔枝，no matter驿道上的马儿跑的有多快。

在这个分布式天生的死穴问题上，带来的问题是最多的。

作为系统架构师，必须对时序逻辑（Temporal Logic）有所掌握。Otherwise, 系统设计一定是漏洞十出。

另外，分布式系统的nature决定了任何全局算法的优化一定不是最优的，而是次优的。
在CDMD Convergence的设计基础上，一个很大的演变就是：C，D，M，D的计算资源的自适应（Adaptive）的调配。而非静态的划分。

要充分利用计算池的模型，Processing on Demand。

3。CTP（Close To Port, Close To Packet， Close To Payload） Rule
计算或者存储能力一定要离端口（Port）近，离数据（Packet Descriptor和Payload）近。越远，越歇火。 当官是要离党中央近。做系统是要离Traffic近。

这里的一个设计Case study 是：要充分利用系统中线卡，处理卡，I/O卡上的计算能力。这些计算能力是离端口最近的，对Traffic而言，是Local Bus的距离，而非Interconnect的长途跋涉。

计算是分布的。分布计算的集合就是系统的总体计算和（或）处理能力。

4。 CCNUMA Adoption Rule
CCNUMA一定会被广泛的用在将来的高端通信系统中。

自从internet引入NAT以后，围绕NAT的问题就是层出不穷。想当年，把NAT介绍进来，是为了解决

ipv4地址不够用（或者public ip太贵）的问题，顺带还增加了内网的安全性（隐藏网络拓扑）。但是

NAT本身是违背网络端到端的设计的，因为它需要在网关上做一些手脚。以至于很多应用由于NAT，会

出现问题，最突出的就是voip, p2p and p2p gaming。

先看个图：

为了解决应用穿越NAT的问题，IETF又发明了很多solution（从这一点上来看，IETF很体谅工程师，

总是能够搞出来点事，让ip工程师不至于失业，而且还能活得很滋润）。闲话不说，我们来看看两个

常见的方法：STUN和ALG。

说STUN，就需要谈谈nat cone，那么，什么是nat cone哪？看图

• Full cone

这是一个full cone, nat binding是 {z, 3001, xxx, xxx}，也就是不限制从外面来的ip地址和端口，

匹配这个binding后，会把目的地址和端口映射成内部地址和端口。

• ip restricted cone

ip restricted cone, binding是{z, 3001, b, xxx}，也就是限制从外面来的源地址

前几天听说用哈希算法查找路由的，说是linux就是这样实现的。没想明白是如何实现的。从原理上来说，路由匹配

是最长匹配，它需要匹配掩码，这一点与session 匹配以及mac地址查找不同。session或者mac查找过程里面，往

表里面填的数据是确定值的，但是在路由查找里面，需要比较掩码。所以路由查找一般都是采用树型算法。如果采用

哈希算法，不知道这个哈希表如何构造。按掩码，从1~32构造32个哈希表。匹配的时候，从最长的32位掩码开始，

直到0位掩码匹配缺省路由？不知道这样做是否可行，或者效果如何。

ip classify或者policy match的思路与此相同。当然，policy match通常有多个dimensions，也就是说有多个匹配项，

这些项之间是与的关系。所以可以把这些项加起来，比如5-tuple，可以构造出一个8+32*3=104 bits的匹配树，有掩码

的部分填成0就可以了。

ip classify算法是网络里面的核心算法，不过大多数人都没太仔细考虑过其中的细节。

没有陈首席的整理，评论，我写的文字就太单薄了。这是对自己十多年工作的一个总结，也是为自己所做

工作的一个纪念。

先贴一个思维导图

花了一天时间画的。对路由器，交换机市场和产品不太了解，画的有些简单，当然也不排除路由器，交换机市场和产品本来就简单，产品形态

比较少，所以这个市场上的厂商比较少，竞争态势比较清晰。

安全产品是主要关注的部分，这主要是笔者的工作与此相关，对这个行业多少有点理解。

安全市场和产品非常丰富，厂商也很多。安全市场上的产品很难有一个清晰的分类，因为单一功能的产品很少，大多都具有多种功能。按下面

的思路分可能比较简单一些：

• 客户端安全：包括防病毒，补丁管理，安全浏览器，文档保护，访问控制，安全证书等等，安全功能在客户端上实现。由于用户群庞大，市场也很大，但是

                         从个人用户那里赚钱比较困难，所以能赚钱的还是企业用户。但是支付宝，网络银行之类的如何划分？电子商务是最关注安全的业务，

                         但是这里的安全不是指某个产品，而是整个业务流程的安全，电子商务，电子银行有很多安全规范和流程，也有很多实践。产品是为

                         业务服务的，如果产品不能增加用户业务的价值，那么产品就没有存在的必要。

• 网关安全：包括防火墙，入侵检测，UTM，WAF，VPN之类的。主要部署在客户端和服务器之间，以网关的形式存在。这类产品的形态很多，各有不同的关注点。

                        厂商创造出很多新名词，但大多都只是包装而已。真正能有效工作的，可能是设备的网络功能，而非安全功能。个人认为在网关上做安全，

                        特别是内容安全，有点勉为其难，把网络当做管道就足够了，不要加太多智能。

前一段时间写了一系列"Patterns in network system design”的文章，最近又继续思考这个话题，感觉还有一些

Pattern遗漏了。Pattern的发现，整理，是一个持续的过程。随着实践的深入和系统的发展，应该会有更多的pattern

被发现，而以前的pattern有可能在新系统里面失去了作用。所以要持续不断的优化，整理自己的知识，使之与现实的

系统能够匹配。

提出（发现）问题；分析问题；解决问题是一个完整的过程。很多时候，解决问题并不困难，难的是在分析问题和发现

问题。对我来说，提出（发现）问题，尤其重要，这代表了不断思考，不断拓展知识的兴趣。只有对一件事情有兴趣，

才能对分析和解决问题有持续的热情，这才是一个良性的循环。

35) Load balance

Pattern Name and Classification:  load balance
Intent: 把任务均衡分配给worker
Also Known As: No
Motivation (Forces):

(图来自http://www.kernelchina.org/?q=node/552，借来用一下，这个图是在描述distributed system里面

的load balance，但是也适用于网络系统，不同的系统，解决问题的思路有时是一样的）

如果系统里面有多个计算单元，如何把任务分配给每个计算单元，使得每个计算单元的负载是平衡的，这就是负载均衡

要考虑的问题，有很多不同的调度策略（这里要考虑机制（mechanism）和策略（policy）分离，策略是可以替换的，

但最好是一致的，换句话说，就是相同的策略才能产生一致的结果，否则就会引入新的不均衡）。如果计算单元的计算

能力是一样的，round-robin应该是首选；如果是不一样的，可以选择weighted round-robin。但是，有些时候，把session

分配到哪个计算单元上是由应用决定的（相当于另一种策略），比如ALG的control session需要和data session在一起；

又比如说http transaction stickness（一个transaction需要在同一个计算单元上，很多应用有这样的要求）。这样会导致

系统的负载难以预料。这时，需要在系统里面加一些探测机制（系统是否可用）和反馈机制（计算单元的负载情况），并

根据这些结果调整负载的分配。由于没有一个适用于所有情况的调度策略，所以做load balance很难。load balance不保证

100%正确的，比如把packet分配到某个计算单元，由于计算单元的负载太大而不能处理而导致的丢包，这种情况是很

难避免，而且这个packet也不能送回去重新调度，否则会带来更多的错误。
Known Uses: load balancer；packet scheduler
Related Patterns: centralized design；decentralized design
References:

1: http://zh.linuxvirtualserver.org/

Single CPU, Multi-core, Chassis based, Cluster, Distributed 的网络系统设计，是软件和硬件co-design的过程，硬件

方面，诸如ASIC, FPGA, Co-processor, Network processor, Switch fabric, Memory controller等问题，不在本文的

讨论范围之内，本文作者也不太了解这方面的知识。但从软件方面来说，首先要面对的是如何分配计算资源：SMP或者AMP，

这就涉及到操作系统选择（开源操作系统很多，但都不是为网络设备优化过的，网络设备也是一个嵌入式设备，但是协议栈

是通用协议栈，用来做网络设备可能稍差点），编程方式选择（在内核还是在用户空间），API（标准API，还是自己私有的

API），程序库等等。然后是任务分配，任务分配的难点在于如何让系统的资源使用达到平衡，避免有些CPU太忙，而有些CPU

太闲，在这里，Queue做为连接不同任务的节点就显得很重要。在接下来就是软件层次的划分，无状态包处理还是有状态包

处理的选择，最后就是多CPU（chassis based，cluster, Distributed）的通讯，有很多库可以参考，比如MPI或者OpenMP。

当然，做为一个完整的系统，肯定还有很多东西需要考虑，比如内存管理，timer, ager，链表，哈希表，树等等具体的问题，

这些都是细节，对系统的整体设计应该没有什么太大影响。

硬件设计需要考虑系列化，可扩展；软件设计需要考虑通用，可移植，可扩展。从单CPU到多CPU，从单板到多板，再到多机。

硬件可以scale out，软件同样可以scale out，这样的系统才是成功的系统。不管什么样的系统，从更高层次来看都是一样的，

所以google的high performance web和cisco的high performance network，上层结构可能是一样的，这个要慢慢体会。

References（只列出了看过的，翻过的，见过的，其他的没有了，读者可以自己补充）

1: Network Systems Design Using Network Processors: Intel 2XXX Version

2: Network Systems Design with Network Processors, Agere Version

3: Network Flows: Theory, Algorithms, and Applications