标签：
Original:http://blog.csdn.net/phunxm/article/details/5086080
在OSI开放互联参考模型中，对等实体（peer）之间数据单元在发送方逐层封装（encapsulation），在接收方的逐层解析（decapsulation）。发送方N层实体从N+1层实体得到的数据包称为服务数据单元（Service Data Unit，SDU）。N层实体只将其视为需要本实体提供服务的数据，将服务数据单元进行封装，使其成为一个对方能够理解的数据单元（Protocol Data Unit，PDU），封装过程实际上是为SDU增加对等实体间约定的控制信息（Protocol Control Information，PCI）的过程。
为了保证网络的各个功能的相对独立性，以及便于实现和维护，通常将协议划分为多个子协议，并且让这些协议保持一种层次结构，子协议的集合通常称为协议簇（Protocol Family）。
网络协议的分层有利于将复杂的问题分解成多个简单的问题，从而分而治之。各层的协议由各层的实体（entity）实现，通信双方对等层中完成相同协议功能的实体称为对等实体。对等实体按协议进行通信，所以协议反映的是对等层的对等实体之间的一种横向关系，严格地说，协议是对等实体共同遵守的规则和约定的集合。
通信协议精确地定义了双方通信控制信息和解释信息：发送方能将特定信息（文本、图片、音频、视频）按协议封装成指定格式的数据包，最终以串行化比特流在网络上传输；接收方接收到数据包后，根据协议将比特流解析为本地化数据，从而获取对方发送过来的原始信息。
通信协议包括三个要素：
（1）语法：规定了信息的结构和格式；
（2）语义：表明信息要表达的内容；
（3）同步：规则涉及双方的交互关系和事件顺序。
整个计算机网络的实现体现为协议的实现，TCP/IP协议是Internet互联网的核心协议。
（1） 协议的开发主要包括协议设计、协议形式描述、协议实现和协议一致性测试。协议的开发过程与步骤如图1所示。
图1 协议开发过程与步骤
（2） 协议设计过程中的分组发送接收模型如图2所示。
图2协议设计过程中的分组发送接收模型
（3）协议的一致性测试
协议的一致性测试是指测试协议能否按照预想的控制策略实现正确的通信，主要体现在数据包通过信道从信源传送到信宿后，信宿能够根据协议正确的解析出原始信息。
协议的一致性测试如图3所示。
图3 协议一致性测试环境
根据测试环境的可以分为局部测试和分布式测试，如图4所示。
图4局部测试法、分布式测试法
为方便描述自定义协议，还是借用数据包和数据报来描述封装数据单元和传输数据单元，但这里的数据包和数据报完全不同于TCP/IP架构中的Packet和Datagram概念。
下文所述的数据包指封装的基本单位，以TLV（Type-Length-Value）格式封装基本消息单位；数据报Package是传输的基本单位，头部包含序列号和命令信息。接收端根据命令信息分辨事件类型，做出不同的解析。报文实体是多个TLV数据包组成的链表。
从应用层HTTP协议，到超文本置标语言HTML（HyperText Mark-up Language），再到可扩展置标语言XML（Extensible Markup Language），它们提供了数据的格式化存储、传输和格式化显示的规范，是网络通信的基石。然而HTTP协议以及HTML/XML置标语言的本质就是定义一堆标签（Tag）对数据进行串行化序列化，然后接收方再根据标签解析、还原数据。
自定义通信协议的关键是对数据包的合理构造（construct）和正确解析（parse），即制定编解码规则。
抽象语法标记ASN（Abstract Syntax Notation） BER的长度确定的编码方式，由3部分组成Identifier octets、Length octets和Contents octets，实际上这就是一种TLV（Type-Length-Value）模型：类型字段（Type或Tag）是关于标签和编码格式的信息；长度字段（Length）定义数值的长度； 内容字段（Value）表示实际的数值。
因此，一个编码值又称TLV三元组。编码可以是基本型或结构型，如果它表示一个简单类型的、完整的显式值，那么编码就是基本型（primitive）；如果它表示的值具有嵌套结构，那么编码就是结构型 （constructed）。
TLV编码就是指对Type（Tag）、Length和Value进行编码，形成比特流；解码是编码的逆过程，是从比特流缓冲区中解析还原出原始数据。
采用C++编程语言设计TLV协议类，其类视图如图5所示。
图5 CTLV类视图
目前只提供设置整形值（int型）的setValue_Int和设置字符串值（C_String型）的SetValue_Cstring两个接口。
TLV将数据封装成包的格式如表1所示。
|
TLV包 |
||
|
头部 |
包实体 |
|
|
m_dwTag |
m_nLen |
m_pValue |
表1 TLV包格式
TLV的接口说明：
（1）值类型标签m_vtTag是内部辅助枚举变量，它根据构造TLV时传递的服务类型标签m_dwTag来确定。
（2）TLV::m_nLen在为TLV设置具体值时确定。
（3）TLV包的封装：
（4）TLV包的解析：创建一个TLV对象后，调用TLV::fromBuffer方法从缓冲区streamBuffer解析出TLV。
（5）封装和解析涉及到本机字节顺序和网络字节顺序的转换问题。
（6）调用TLV::setValue_*方法填充TLV时，统一字节边界数为4。
不同于底层的数据包/数据报只是对数据层次的封装解析，实际应用程序是以事件驱动的，因此必须注册不同的信令（事件类型标签），然后填充到数据报中。接收端根据信令做出相应的事件处理。
例如在C/S通信系统中，客户端往往要先登录，通过服务器端的校验才能进行后续通信。因此客户端运行后，需要构造并向服务器端发送含有LOGIN信令的包含用户名字符串strUserName和密码字符串strPassWord的数据报；服务器端解析LOGIN信令后做校验处理，然后发送含有LOGIN_RESPONSE信令和校验结果的回执数据报给客户端。
采用C++编程语言设计Package类，其类视图如图6所示。
图6 CPackage类视图
Package类将TLV封装成包的格式如表2所示。
|
Package包 |
||||
|
头部 |
序列号 |
包实体 |
||
|
m_nCmdLen |
m_dwCmdID |
m_dwCmdState |
m_nSeqNo |
Count*TLV |
表2 Package包格式
Package的接口说明：
（1）Package::m_nCmdLen是整个Package包的长度，将其作为首个字段的好处在于当传送大数据包时，接收方可以根据数据长度来控制读状态，从而将一个大数据包分批接收。
（2）Package::m_nCmdLen在构造函数中初始化为16，在调用Package::addTLV方法填充包实体时增长。
（3）Package包的封装：
（4）Package包的解析：
（5）Package::toBuffer方法和Package::fromBuffer方法主要遍历Package::m_TLV_List列表，然后调用TLV::toBuffer方法和TLV::fromBuffer方法解析出TLV数据单元。
TLV数据包的功能测试（主要是本地测试）
鉴于实际通信数据最后都要转换成比特流，故只测试发送字符串类型的变量，仅测试协议能否正确打包、解析。其他类型的普通数据都可以转换成字符串传输，最后，接收方根据m_dwTag确定值类型m_vtTag，解析出具体值。
对TLV::setValue_C_String方法填充TLV的测试，需要考虑字节对齐问题。对于长度为4字节倍数的C状态字符串，打包时省去末尾的‘/0’结束标志符。需要测试长度非4倍数的字符串和长度为4倍数的字符串。
经本地测试，调用TLV::setValue_Int方法和TLV::setValue_C_String方法构造整形和字符串时，能够正确封装、正确解析。
Package数据报的功能测试，主要是将TLV组合成包，然后添加信令，完成特定的通信。对登陆LOGIN和发送消息SUBMIT_SM的测试表明Package协议能正确封装、正确解析。
在实际项目中使用Package通信协议，对于稍大一点的数据块需要控制好读的步骤，以便能接收整包完整的信息。
本文示例代码下载：《TLV应用层协议开发示例》
参考：
《计算机网络协议和实现技术》 鲁士文
标签：
原文地址：http://www.cnblogs.com/ganrui/p/4567958.html
