应用层的协议简单来说就是程序之间网络通信的方式，相当于就是我们说话的方式，两个人能成功的进行沟通需要有两个先决条件：
1、大家在说同一种语言
一个只会说汉语的人和一个只会说德语的人注定是无法在一起的；一个胡建人和一个河北人虽然会有较高的误码率，但基本还是可以谈恋爱的。
2、需要有“断句”方式的约定
人类的沟通无一例外是通过“说话的停顿”和“对于语言内容的理解”来进行断句的：
说话的停顿
“Hey，你在干啥呢？”、“写作业呢”、“吃饭了没”、”一会儿去吃
煎饼“，理解没有问题
对于语言内容的理解
“Hey你在干啥呢吃饭了没”、”写作业呢一会儿去吃煎饼“。也能费劲理解（NLP）
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进行编码，把所有字符都转化成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是否闭合，从而完成“断句”。但这种方式有一个较为严重的问题就是，“断句”逻辑依赖编码方式，这样在工程上的实现难度就会变大。
这里有个有意思的插曲，大家可能发现GFW有封SSH协议的能力，按理说SSH是加密的，不应该能被识别出来啊，看下图大家就应该明白了：
SSH协议在client连接成功后，server端会主动明文发送ssh的版本信息。
5、复杂度和效率的平衡
首先我们介绍一种叫Netstring 的协议：开头用ASCII明文标记后面数据的大小，然后紧跟一个“:”，然后是数据，最后以一个“,”结尾。
12:hello world!,
空消息：
0:,
我们在之前几家公司做项目的时候为了平衡“工程实现复杂度”和“运行效率”，往往采用类似Netstring的协议，并进一步简化，固定10bytes的ASCII头表示消息长度，后面紧跟数据。
0000000002hi
这样做的优势有：
- ASCII头方便debug
- 10bytes固定头长度，易于算法实现，消息长度上限大约是10GB，基本够用
- 头后面紧跟数据，不需要其它逻辑
