最近心血来潮想要开发一个消息系统，观望一圈发现没有合适的现成的组件可以使用。
了解过xmpp协议，我认为xmpp协议的开放性太强，不利于消息服务的私密性保障，同时xml的消息格式浪费网络资源，这让我感到不满。
参考过http协议的格式，但我认为使用空格和换行分隔的固定的头信息格式不适合快速发展且业务容易变化的消息服务。虽然固定的消息头格式解析很方便，带宽占用小，但可扩展性较差，结构化不明显，对国际化字符编码例如utf8支持不好。
xmpp和http协议正好是两个极端，前者可扩展性好但冗余信息多，开放性太强，后者可扩展性差，开放性弱，冗余信息少。
最后不得不自己设计一套应用层通信协议。
通信协议主要的格式体现在头部，至少要包含主体内容的字节数。只有知道了主体长度才能够判断要读取多少内容之后结束。也要包含自己的通信协议的简单说明，例如http协议中包含http/1.1这样的协议名称的说明，以便于和其他协议区分。最好也能够体现内容的类型，是文字、图片、音频、视频还是下载文件，要标明，以便于正确处理。对于消息服务来讲，还要加上消息发送的时间戳。编码问题由于使用的是CS架构不需要额外注意，但加上推荐的文字编码格式更加，以便在不兼容的情况下作转码。与编码相协同的，把语言和地区也表示清楚，便于国际化。消息接收方和消息发送方也需要在头信息中标注，这样一来服务器才能转发消息。为了可扩展性，头部还要有一个标识标注是否有额外信息头，并标注额外信息头的编码。
有了基本的头信息，还要规定清楚头信息如何编码。一般来讲，头信息不会很复杂，通常都是英文字符，使用ascii码能够编码。然而，如果遇到传输文件这样的事情，文件名可能是中文的，这就不能用ascii码编码了。
一个好的想法是让头部之后包含一个扩展区域，扩展区域中的编码是可以另外指定的，建议采用utf8编码，这块扩展区域就是额外信息头。额外信息头应当也采用json格式，以便解析。
在头部和可能存在的额外信息头之后便是消息主体。消息主体可以是文本、图片文件或者其他任何内容，具体如何处理由转发和接收端决定。
