网络协议的思考

   GT-R上市时间定在2007年底，以此推算，可以用于开发的时间只有3年半。水野一开始就已经决定把其中近一半的时间，也就是1年半用于培养人才。而开篇那句话便是这一方针的宣言。仲田的解读完全准确。水野接下来说了下面一番话。 “我们打算制造的是日产的技术人员都没有开过的汽车，所以并不是仅凭已有的知识经验就能制造出来的。从这个意义上来说，我们是一群“新手”。 必须要把新手转变为有效的战斗力。培养人才需要时间，后两年是才是实际制造汽车。”

                                                             --- 日经技术在线 《[开发故事]日产“GT-R”》

    最近，参与设计一个涉及跨区跨网络的复杂的视频支撑平台系统。在网络协议中，借用google的protobuf作为基本的协议。对于这个系统核心的网络协议，理所当然地需要深入的研究一番。

    什么样的协议时最佳的，CPU解析的速度快，传输的数据量小，可扩展性好，协议安全？个人认为，没有最佳的协议，适合自己系统的协议就是最好的。

    记得一个技术大牛的朋友就不齿HTTP，觉得http的协议就是解析字符串。效率太低，还是字节流的协议好。但是，http协议已经成为用的较多的协议,包括流媒体中的rtsp也是继承于http。以前的cpu的速度很慢，解析字符串，我工作做的第一个嵌入式项目，硬件主频不到200M，而现在呢，手机都快到2G,所以，这个已经不是大的问题。

    传输数据量小，目前网络的速度都是1mbps以上，相比流媒体数据，控制命令，无论采用字节流还是字符串流方式，对网络来说都不是问题。但是对于流媒体，压缩率却很重要。从mpeg2到mpeg4， 和目前用的最多的h264，到去年才敲定的h265协议，压缩率也在不断的扩大。相信就在这两到三年来，h265会成为实时流媒体的主流。到时又要研究h265罗。

    可扩展性，字符串性就比字节流方式好，如果新的功能，就直接增加不同的字符串就行了，但是字节流就不好扩展了。

    协议安全，当然字节流比字符串方式好，因为如果不知道协议的话，即使抓到网络包，也不好分析。

    protobuf，采用的是字节流的方式，但是，比一般的字节流要占用更多的数据，但是，采用option就可在原有协议上进行扩展。

    其基本思想就是，采用index的方式导入数据，而数据又使用几种标示来区分基本的数据类型。(网上有很多介绍，就不浪费CSDN的存储空间了)。通过添加新的index和option选项来扩展数据，通过类似于utf8的编码方式来压缩整型数据，但是，它并不压缩字符串类型数据。安全性也因为字节流得以保证。

    我坚信所有的协议和所有的事物都有两面性，protobuf也不例外。

    1. 在发起端和接受端，需要花费更多的内存和处理时间。以C++为例，首先，它需要必须定义每一种功能的协议命令为一个class，然后在处理时，先new一个这个对象，再往每个字段放上数据(其他协议也处理也是类似的)，然后需要使用另外一个比这个对象所占的内存少的（大多时候都是少很多的）新内存空间，序列化这个协议命令。然后，之前的对象就可以删除了。当然，比某些字节流协议的处理要节省一些空间（跟coding的水平有关的）。这几个过程当然花费的时间也一般的字节流协议要多，且由于每个协议命令都需要一个class，程序自然也就变大了。空间和时间都拉长了。

    2. 由于每条命令的序号都是从1开始，但是格式又不一样，所以，就导致外部必须再包一层协议名称的字段去区分每一条不同的协议。

    对于这个协议，我觉得其可扩展性是我们系统采用它的最主要的原因，因为我们的系统运行环境至少都是多核的x86系统，运算速度和内存都不是问题。另外，我们也在外包裹一层协议名称的字段去区分每一天协议。