网络协议实践（下）-应用层网络协议栈的典型架构

架构分层

上一篇，我们分析了协议构成之后，其实协议栈的典型架构已经呼之欲出了。
当然，架构肯定不是唯一的。千人千面，每个程序员都会有自己的理念。这里只是个人的一些想法，抛砖引玉供大家参考了。

设计思路

设计的整体思路是：

1. 从应用接口(服务原语)入手；
2. 通过实体管理对多个协议实体进行管理；
3. 根据协议实体的运用方式，将实体分割为服务端节点和客户端节点以控制；
4. 通过控制连接流程，引用流程中调用的各种PDU帧；
5. 通过PDU帧的打包和解包，并调用协议的实体各种功能来对PDU的各域进行生成和分析操作，这样整个的业务主流程就完成了；
6. 最后则是网络协议中的诊断和分析相关的OAM功能，大致会分为故障管理和性能监测两部分。
   通过上述的设计流程，我们就基本能够完成一个网络协议栈的开发了。

服务原语

个人习惯上，设计时，首先是从接口入手，因此，我选择的入口是服务原语。
服务原语在协议中会较为清晰地定义，包括所需的相关参数。
当然，注意很多参数在实际使用时并不一定会通过应用传入，因此我们可能在服务原语之上再进行一层封装以提高协议的易用性。
应注意indication和confirm原语是从协议实体调用应用实体的，所以需要由应用端进行实现，通过类似反射或者服务注册的方式告诉本协议栈的实体。

实体管理

收到服务原语后，实体管理类判定原语所归属的协议实体，并将原语分发给相应服务端或客户端节点进行处理。
之前也说过，协议是在同层对等实体之间交换信息的，一组同层对等实体组成了一个本协议的通信网络。
对于一台主机来说，可能加入一个本协议通信网络，也可能加入多个本协议的通信网络。
通常来说，在每个通信网络中，我们需要创建一个独立的协议实体，因此我们就需要对本主机上本层的协议实体进行管理，从而了解本主机中存在多少通信网络和相应的连接情况。

服务端/客户端实体节点

一般来说，服务端负责打开端口监听，属于被动式提供服务的协议实体；客户端则负责进行连接，属于主动请求服务的协议实体。
这块比较容易理解，就不再赘述。

协议连接管理

服务端/客户端实体节点通过协议管理来完成协议组的顺序组织和调用。
典型的协议连接相关的功能有：

• 建立连接
• 断开连接
• 数据传输
• 信道检测/保活
• 连接重建
  当然，这部分功能很多时候根据服务端/客户端的节点性质会有不同。

帧处理

与同层对等实体的协议连接是通过不同的协议帧（主要是帧头）来实现的。
因此，需要根据不同的协议连接功能对各种类型的协议帧进行一一实现。
需要注意的是，帧一般分为管理型和数据型，管理型的帧一般不包含用户数据，数据型的帧则需要在用户数据之上再进行打包操作。
其中帧中所涉及的本层的协议消息类型域依赖于本层的实体功能。

协议实体功能

协议实体功能可以通过其接口（PDU中的消息类型域）来进行逐一实现，能够按照功能模块对消息类型域的生成和校验进行处理。

OAM

完成了上述功能，协议本身就可以工作了。
但是作为网络协议必不可少的部分，我们希望能够对其进行监控和出错时进行排查，这时就涉及到相关的OAM功能了。这一块有的协议是不写的。
当协议本身没有对这部分功能进行描述的时候，我们可以参考ITU-T 的OAM标准进行设计。

• G.8013标准中按照故障管理和性能监测两部分对OAM的关联功能进行描述；
• G.8013中的描述是基于以太网管理的，我们需要将其迁移到本层来；
• G.8013的标准是基于用户层通过PDU进行的信息管理，我们在设计接口时可以无需基于PDU，常常可以基于交互式命令行来进行这部分的功能设计。

小结

协议栈的架构设计风格不是唯一的，这篇文章只是个人的一些理解。希望能够做一些个人记录，如果能够帮助到大家当然也是极好的。

参考

网络协议实践（上）-应用层网络协议栈的基础构成