第一种类型,二进制格式的网络数据包,通常要首先接收包头,在包头中有校验数据校验获取的数据是否正确,同时包头中还有数据域存放接下来的内容域的大小,得到该大小之后开始接收内容包,然后对内容包进行解析,包头的大小是固定的,否则无法知道何时接收包头完毕进行解析.
第二种类型,XML格式组织的数据包,通常以连续几个\r\n之类的字符表示结束,在接收包的时候无法知道所要获取数据包的大小,只有每次判断时候已经接收到了表示结束的字符.
两种传送数据包优缺点比较:
1)网络传送效率比较:第一种的优点是接收数据包的效率高,首先按照包头的数据大小接收包头可以获知内容包的大小,再按照此大小获取数据包;而第二种数据包无法在接收的时候获取该数据包的大小,只能在每次接收的时候判断时候已经到达包的结尾,因此相比较而言第一种格式的数据包在网络传送效率上高一些.同时,由于第一种格式可以在包头中加入一些校验字段判断包是否合法,在数据校验这一块也具有优势.
2)解析数据包:第一种数据包没有固定的格式,或者准确的说没有固定的解析器用于解析这种格式的数据,因为每个人定出的协议都不尽相同;而第二种数据包有完备的解析XML格式数据的第三方库可用(libxml2,tinyxml,expat等),但是并不见得有了第三方的库解析起数据起来效率就一定高(这里指的是程序的效率,而不是编码的效率),因为XML解析比普通的数据解析要复杂的多,效率也就更加慢一些.
3)可扩展性:第一种数据包的格式不同,可扩展性也不尽相同,具体与每种格式的包有区别.第二种格式的数据包由于采用了XML格式,天正的具备很好的可扩展性.
4)数据安全性:第一种格式的数据包可以方便的实现数据的加密,而XML格式的数据实现加密不容易,基本上抓包就能看到数据.
综上，个人认为XML格式的数据包仅在可扩展性上有较大的优势，但是对于安全性，性能要求不太高而扩展性要求较大的协议还是建议使用XML格式的协议，毕竟如果协议制定的不好造成扩展性差也是麻烦的事情，因为客户端一旦放出去就收不回来的。目前jabber的通讯协议就是采用的XML格式的协议。
来自：http://www.cppblog.com/converse/archive/2008/03/26/45472.html
JSON(JavaScript Object Notation) 是一种轻量级的数据交换格式。易于人阅读和编写。同时也易于机器解析和生成。它基于JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999的一个子集。 JSON采用完全独立于语言的文本格式，但是也使用了类似于C语言家族的习惯（包括C, C++, C#, Java, JavaScript, Perl, Python等）。这些特性使JSON成为理想的数据交换语言。
JSON建构于两种结构：
- “名称/值”对的集合（A collection of name/value pairs）。不同的语言中，它被理解为对象（object），纪录（record），结构（struct），字典（dictionary），哈希表（hash table），有键列表（keyed list），或者关联数组 （associative array）。
- 值的有序列表（An ordered list of values）。在大部分语言中，它被理解为数组（array）。
这些都是常见的数据结构。事实上大部分现代计算机语言都以某种形式支持它们。这使得一种数据格式在同样基于这些结构的编程语言之间交换成为可能。
JSON具有以下这些形式：
对象是一个无序的“‘名称/值’对”集合。一个对象以“{”（左括号）开始，“}”（右括号）结束。每个“名称”后跟一个“:”（冒号）；“‘名称/值’ 对”之间使用“,”（逗号）分隔。
数组是值（value）的有序集合。一个数组以“[”（左中括号）开始，“]”（右中括号）结束。值之间使用“,”（逗号）分隔。
值（value）可以是双引号括起来的字符串（string）、数值(number)、true、false、 null、对象（object）或者数组（array）。这些结构可以嵌套。
字符串（string）是由双引号包围的任意数量Unicode字符的集合，使用反斜线转义。一个字符（character）即一个单独的字符串（character string）。
字符串（string）与C或者Java的字符串非常相似。
数值（number）也与C或者Java的数值非常相似。除去未曾使用的八进制与十六进制格式。除去一些编码细节。
空白可以加入到任何符号之间。
参考：
1、 http://www.json.org/
2、 http://www.json.org/json-zh.html
本文选择一个第三方库 jsoncpp 来解析 JSON。jsoncpp 是比较出名的 C++ JSON 解析库。下载地址为：http://sourceforge.net/projects/jsoncpp。本文使用的 jsoncpp 版本为：0.5.0。License: Public Domain。
Jsoncpp是Json数据格式的编码解码器，使用c++编写，提供reader和writer来进行解码和编码。
jsconcpp 进行 JSON 解析的源码文件分布在 include/json、src/lib_json 下。
jsoncpp 主要包含三种类型的 class：Value、Reader、Writer。jsoncpp 中所有对象、类名都在 namespace Json 中，包含 json.h 即可。
Json::Value 只能处理 ANSI 类型的字符串，如果 C++ 程序是用 Unicode 编码的，最好加一个 Adapt 类来适配。
1、Reader
该库中的Reader类用来将字串或者流载入解析器。是的后期可以用Reader里面的解析方法来解码Json字串为C++认识的数据。可以用Json::Reader来声明一个Reader实例。Reader中最常用的就是一个parse方法，该方法用来将载入的json字串解析为C++格式的数据。
2、Value
这是该库中的核心类，用于存储各样格式的数据，可以包括int,double,short,char*,string,bool,object,array等几乎所有格式的数据。该库的编码和解码的核心功能都是用Value类实现的。就用以上的Reader的parse方法来说，需要传入一个Value类别的引用值，就是用来存储Json数据的根值，并且可以用这个根值来存取其他的所有值。
3、Writer
这是该库的一个虚类，没有真正的实现encode的功能。需要重载里头的方法来实现真正的encode功能。
4.FastWriter
这是该库中真正实现encode功能的类，用来实现将Value编码称为Json串。
参考：
1、 http://sourceforge.net/projects/jsoncpp/
2、 http://jsoncpp.sourceforge.net/index.html
3、 http://blog.csdn.net/xt_xiaotian/archive/2010/06/04/5648388.aspx
4、 http://adebugger.cn/2009/11/cpp-json-data-communication/
ProtoBuf，全称是Protocol Buffers, 它是谷歌内部用的一种高效的、可扩展的对结构化数据进行编码的格式规范。谷歌自己内部很多程序之间的通信协议都用了ProtoBuf。
ProtoBuf可以支持多种编程语言，目前已经C++, Java和Python，本文中所前的内容用到例子的话，会以C++为例。
ProtoBuf在Google Code上的主页是：http://code.google.com/p/protobuf/， 感兴趣的可以在这里下载ProtoBuf的源码，也可以在这里阅读ProtoBuf的详细的文档。
在开始本部分的内容之前，首先有必要介绍两个基本概念，一个是序列化，一个是反序列化。这两个概念的定义在网上搜一下都很多的，但大多都讲得比较晦涩，不太好理解，在这里我会用比较通俗的文字来解释，尽可能让读都朋友们一读就明白是怎么回事：
序列化：是指将结构化的数据按一定的编码规范转成指定格式的过程。
反序列化：是指将转成指定格式的数据解析成原始的结构化数据的过程。
举个例子，Person是一个表示人的对象类型，person是一个Person类型的对象，将person存到一个对应的XML文档中的过程就是一种序列化，而解析XML生成对应Person类型对象person的过程，就是一个反序列化的过程。在这里结构化数据指的就是Person类型的数据，一定的编码规范指的就是XML文档的规范。XML是一种简单的序列化方式，用XML序列化的好处是，XML的通用性比较好，另外，XML是一种文本格式，对人阅读比较友好，但是XML方式比较占空间，效率也不是很高。通常，比较高效的序列化都是采用二进制方式的，将要序列化的结构化数据，按一定的编码规范，转成为一串二进制的字节流存储下来，需要用的时候再从这串二进制的字节流中反序列化出对应的结构化的数据。
通过上面的介绍，我们给protobuf下一个比较正式的定义了：Google ProtoBuf是Google制定的一种用来序列化结构化数据的程序库。
1) ProtoBuf编码基础——Varints, varints是一种将一个整数序列化为一个或者多个Bytes的方法，越小的整数，使用的Bytes越少。
Varints的基本规则是：
（a） 每个Byte的最高位(msb)是标志位，如果该位为1，表示该Byte后面还有其它Byte，如果该位为0，表示该Byte是最后一个Byte。
（b）每个Byte的低7位是用来存数值的位
（c）Varints方法用Litte-Endian(小端）字节序
举个例子：300用Varints序列化的结果是1010 1100 0000 0010，运算过程如下 所示：
1010 1100 0000 0010->010 1100 000 0010（去标志位）->
000 0010 010 1100（调整字节序）-> 1 0010 1100 ->256+32+8+4=300（计算值）
300用Varints序列化的过程：-> (二进制)0000 0001 0010 1100 -> (7位一组)000 0010 010 1100 -> (调整字节序)010 1100 000 0010 -> (增加标志位)1010 1100 0000 0010。
2)ProtoBuf中消息的编码规则：
（a）每条消息(message)都是有一系列的key-value对组成的, key和value分别采用不同的编码方式。
（b）对某一条件消息(message)进行编码的时候，是把该消息中所有的key-value对序列化成二进制字节流；而解码的时候，解码程序读入二进制的字节流，解析出每一个key-value对，如果解码过程中遇到识别不出来的类型，直接跳过。这样的机制，保证了即使该消息添加了新的字段，也不会影响旧的编/解码程序正常工作。
（c）key由两部分组成，一部分是在定义消息时对字段的编号（field_num），另一部分是字段类型（wire_type）。字段类型定义如下表所示。
|
Type
|
Meaning
|
Used For
|
|
0
|
Varint
|
int32, int64, uint32, uint64, sint32, sint64, bool, enum
|
|
1
|
64-bit
|
fixed64, sfixed64, double
|
|
2
|
Length-delimited
|
string, bytes, embedded messages, packed repeated fields
|
|
3
|
Start group
|
groups (deprecated)
|
|
4
|
End group
|
groups (deprecated)
|
|
5
|
32-bit
|
fixed32, sfixed32, float
|
（d）key的编码方式：field_num << 3 | wire_type
（e）varint类型(wire_type=0)的编码，与第(1)部分中介绍的方法基本一致，但是int32, int64和sint32,sint64有些特别之处：int32和int64就是简单的按varints方法来编码，所以像-1、-2这样负数也会占比较多的Bytes。于是sint32和sint64采用了一种改进的方法：先采用Zigzag方法将所有的整数（正数、0和负数）一一映射到所有的无符号数上，然后再采用varints编码方法进行编码。Zigzag映射函数为：
Zigzag(n) = (n << 1) ^ (n >> 31), n为sint32时
Zigzag(n) = (n << 1) ^ (n >> 63), n为sint64时
下表是一个比较直观的映射表，这样映射后再进行编码的好处就是绝对值比较小的负数序列化后的结果占的Bytes数也会比较少。
|
Signed Original
|
Encoded As
|
|
0
|
0
|
|
-1
|
1
|
|
1
|
2
|
|
-2
|
3
|
|
2
|
4
|
|
-3
|
5
|
|
…
|
…
|
|
2147483647
|
4294967294
|
|
-2147483648
|
4294967295
|
（f）64-bit(wire_type=1)和32-bit(wire_type=5)的编码方式就比较简单了，直接在key后面跟上64bits或32bits，采用Little-Endian(小端)字节序。
（g）length-delimited(wire_type=2)的编码方式：key+length+content, key的编码方式是统一的，length采用varints编码方式，content就是由length指定的长度的Bytes。
（h）wire_type=3和4的现在已经不推荐使用了，因此这里也不再做介绍。
3）ProtoBuf编解码中字段顺序(Field order)的问题：
(a) 编码/解码与字段顺序无关，这一点由key-value机制就能保证
(b)对于未知的字段，编码的时候会把它写在序列化完的已知字段后面。
首先需要在一个 .proto 文件中定义你需要做串行化的数据结构信息。每个ProtocolBuffer信息是一小段逻辑记录，包含一系列的键值对。这里有个非常简单的 .proto 文件定义了个人信息:
message Person {
required string name=1;
required int32 id=2;
optional string email=3;
enum PhoneType {
MOBILE=0;
HOME=1;
WORK=2;
}
message PhoneNumber {
required string number=1;
optional PhoneType type=2 [default=HOME];
}
repeated PhoneNumber phone=4;
}
有如你所见，消息格式很简单，每个消息类型拥有一个或多个特定的数字字段，每个字段拥有一个名字和一个值类型。值类型可以是数字(整数或浮点)、布尔型、字符串、原始字节或者其他ProtocolBuffer类型，还允许数据结构的分级。你可以指定可选字段，必选字段和重复字段。你可以在( http://code.google.com/apis/protocolbuffers/docs/proto.html )找到更多关于如何编写 .proto 文件的信息。
一旦你定义了自己的报文格式(message)，你就可以运行ProtocolBuffer编译器，将你的 .proto 文件编译成特定语言的类。这些类提供了简单的方法访问每个字段(像是 query() 和 set_query() )，像是访问类的方法一样将结构串行化或反串行化。例如你可以选择C++语言，运行编译如上的协议文件生成类叫做 Person 。随后你就可以在应用中使用这个类来串行化的读取报文信息。你可以这么写代码:
Person person;
person.set_name("John Doe");
person.set_id(1234);
person.set_email("jdoe@example.com");
fstream.output("myfile",ios:out | ios::binary);
person.SerializeToOstream(&output);
然后，你可以读取报文中的数据:
fstream input("myfile",ios::in | ios:binary);
Person person;
person.ParseFromIstream(&input);
cout << "Name: " << person.name() << endl;
cout << "E-mail: " << person.email() << endl;
你可以在不影响向后兼容的情况下随意给数据结构增加字段，旧有的数据会忽略新的字段。所以如果使用ProtocolBuffer作为通信协议，你可以无须担心破坏现有代码的情况下扩展协议。
你可以在API参考( http://code.google.com/apis/prot ... rence/overview.html )中找到完整的参考，而关于ProtocolBuffer的报文格式编码则可以在( http://code.google.com/apis/protocolbuffers/docs/encoding.html )中找到。
参考：
1、http://code.google.com/p/protobuf/
2、http://code.google.com/intl/zh-CN/apis/protocolbuffers/docs/tutorials.html
3、http://www.wuzesheng.com/?p=1258
json一种文本格式，带有字符串标签，对人阅读比较友好，但是json方式比较占空间。
protobuf的每条消息(message)都是有一系列的key-value对组成的，key和value分别采用不同的编码方式，编码后占用的空间比较小。
测试程序是定义Person消息，先序列化到一个string里，然后又从string里反序列化出来，如此重复100000，计算总共花费的时间。
测试结果：使用protobuf大概需要10秒，使用json大概需要58秒。
从结果可以看出，protobuf的序列化、反序列化是比json更快的。