应用层协议那些事

应用层的协议简单来说就是程序之间网络通信的方式，相当于就是我们说话的方式，两个人能成功的进行沟通需要有两个先决条件：

1. 大家在说同一种语言

一个只会说汉语的人和一个只会说德语的人注定是无法在一起的；一个胡建人和一个河北人虽然会有较高的误码率，但基本还是可以谈恋爱的。

2. 需要有“断句”方式的约定

人类的沟通无一例外是通过“说话的停顿”和“对于语言内容的理解”来进行断句的：

3. 对于计算机网络

当两台计算机需要沟通的时候，情况是十分类似的：

“大家在说同一种语言”很容易理解，我们不能用FTP协议去访问HTTP的服务器。

“断句方式“往往被初学者所忽略，校园招聘的时候经常遇到小朋友做了个“基于socket的文件传输工具”，但细问起传输协议是怎么判定文件传输结束的时候，有很多人就不明白这个问题的点在哪里，这时我就十分怀疑这个”传输工具“只是个Broken Toy。

由于现在广泛应用的TCP协议是基于流的传输协议（Stream）。也就是说，传输层协议本身没有“断句”的功能。参见：https://en.wikipedia.org/wiki/Transport_layer#COMPARISON1

这就要求我们在协议层实现”断句“：

4. ”断句“的方式

断句的方式也是随着计算机网络的发展一直在进化：

初，盘古开天辟地，有些类似于PING-PONG协议的非常简单的定长协议，限定消息长度是4个字节，协议的功能也十分之弱智，你发PING，我回PONG。
1968~1971年诞生的Telnet、FTP这类化石级的协议，一般采用的策略就是和我们写文章一样的方式：用回车和换行来标示一条命令的结束。这里细心的人就会想那遇到消息里本身有\r\n的情况怎么办呢？答案就是，转义！就是在消息本身带有\r\n的地方前面加一个”\”字符。stupid but work
1982年制定的SMTP协议的Header就沿用了上述的\r\n方式，但SMTP需要传输邮件内容，邮件附件。如果继续采用“转义”大法，恐怕有点吃不消。这时候就有大神提出了用Base64 Base64 进行编码，把所有字符都转化成a-z, A-Z, 0-9等字符。这样就就完美解决了这个问题。但副作用就是数据会膨胀1/3左右。

1991年制定HTTP协议Header继续沿用\r\n的方式，但由于HTTP将会传输更多的数据，用Base64就太浪费宝贵的带宽资源了。于是我们的前辈们就想出一个好办法，在Header里固定增加一个Content-length字段，用来标示，后续的数据大小。Haeder和content用\r\n\r\n分割。这样就解决了问题，有不会造成数据膨胀。（后续增加的trunk模式这里就不展开说了）
当然有朋友就会问了，有没有可能不增加额外的字节解决“断句”问题？答案是：Yes。1999年XMPP协议被制定出来的时候，就实现了这个设想。XMPP是基于XML的协议，XML的语法解析是有能力判断XML是否闭合，从而完成“断句”。但这种方式有一个较为严重的问题就是，“断句”逻辑依赖编码方式，这样在工程上的实现难度就会变大。