网络协议编写的3层境界

免责声明
本文不会涉及到你该使用UDP还是TCP，是FTP还是HTTP，也就是跟P都没有关系。^^ 同时，也不涉及该使用私有协议还是标准协议，还是在标准协议下使用私有协议， 而是会谈及在具体的协议编写的时候，使用哪种编写的方式会更好。由于本人的知识有限，谈及利弊时，主要以使用C++编写服务端时的经验为主，至于同时适不适用于其他语言，就靠童鞋们自己分辨了。
第一层境界：新手入门
    因为我一开始工作的第一家公司就是精于服务端程序编写的公司（运营过百万级同时在线以上），所以实际上我以前都不太清楚真有公司处于此水平，直到真的碰到时，我才惊慌失措，感叹不已。
特点：信手拈来，直观质朴
也就是写一个结构，在任何需要使用的时候（典型环境就是打包解包，读写文件）一个变量一个变量的通过memcpy等方式处理。简单是简单，没有任何抽象。
但是，

1.非常的不符合DRY原则，在此情况下，服务器端的打包解包代码和客户端的打包解包代码都得两份。别说服务器只需要打包，客户端只需要解包，这是太理想的情况，太经常一个小结构会需要传来传去的。而无论这个结构用多少次，你都得多为其写一次代码。

2.扩展性差：任何底层协议的改动，你都得更改除了相关数据结构意外的地方，（这也算是不符合DRY原则带来的副作用）而且此更改你往往得通过搜索才能完成。甚至，同一个数据结构即使仅仅是打包解包都做不到DRY原则。需要进行版本控制时，相关代码也会散布在各打包解包各处，更何况，当你想要以其他方式（比如写入文件）保存此数据结构的时候，你又得重新来一次，简直就是不人道的。
3.容易出错：在上层打包解包代码，都需要关注于每个结构的每个字段的数据类型，任何一个类型错误，你能够预期到的最好结果就是crash。

第二层境界：序列化
    通过序列化的概念，通过函数抽象实现同一个数据结构打包解包的DRY。通过函数重载，减少不同类型的不同处理。

特点：统一接口，各司其职
    面向对象有的时候会代码对象层次过多等乱七八糟的问题，但是此处面向对象的使用，我感觉实在是太淋漓尽致的体现将面向对象的好处了。我记得以前有个关于对象设计的原则，那就是告诉对象要做什么，而不是去获取数据自己来做。在第一层境界中的做法就完全是自己获取结构中的数据，外部来完成工作，为什么不更面向对象一点，让这种工作由对象本身来完成呢？此时，因为序列化的本质是从接口到二进制之间的转换，对于网络打包解包，文件读写可以做到通过传入不同参数用同样的接口来完成，对于每个类/结构的数据只需要进行一次的编码，极大的减少了错误的发生概率。 能达到这个境界的工作已经算是比较有技术的公司了。
但是，
1.对于服务器客户端语言不同时的情况，再次的无法实现DRY，典型的应用就是以JAVA写服务器，而以C++写游戏时。
2.版本控制还是太过于手动化。
第三层境界： 代码生成代码
    《Unix编程艺术》中描述的至高境界....代码生成代码，元编程的本质。第一次领悟这种境界是通过Google Protobuf,后来还知道一个thrift。

特点：描述结构，自动生成
    以Google Protobuf为例，在写一个网络协议的时候，你不是直接的用一种语言编写协议，而是用特定的描述语言来描述这个协议的内容，然后通过工具自动的生成你需要的特定语言的结构。这样的好处是一次的描述，可以自动的为你生成多个语言的协议文件。（DRY，Protobuf官方支持C++,JAVA,Python，第三方支持的更多）更重要的是，这个接口的打包解包接口已经也生成好了，直接调用即可。当然，这个方法也不是完美的，简单的说，你需要学习怎么描述这个协议，你需要用工具生成代码，简单的说就是比直接写增加了复杂性。

小结：
  其实还有其他的协议编写方式，比如用XML,Json的纯文本协议，这个也是一种较佳的方式，调试非常方便，只是效率上比起二进制的还有差距，而在第三层境界中，为了调试方便，为生成的结构增加一个日志输出接口，也能较为方便的调试。