应用层协议那些事

应用层协议那些事

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

1. 大家在说同一种语言

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

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

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

  • 说话的停顿
    • “Hey,你在干啥呢?”、“写作业呢”、“吃饭了没”、”一会儿去吃煎饼“,理解没有问题
  • 对于语言内容的理解
    • “Hey你在干啥呢吃饭了没”、”写作业呢一会儿去吃煎饼“。也能费劲理解(NLP)

3. 对于计算机网络

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

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

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

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

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

4. ”断句“的方式

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

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

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

这里有个有意思的插曲,大家可能发现GFW有封SSH协议的能力,按理说SSH是加密的,不应该能被识别出来啊,看下图大家就应该明白了:

SSH协议在client连接成功后,server端会主动明文发送ssh的版本信息。

5. 复杂度和效率的平衡

首先我们介绍一种叫Netstring Netstring 的协议:开头用ASCII明文标记后面数据的大小,然后紧跟一个“:”,然后是数据,最后以一个“,”结尾。

12:hello world!,

空消息:

0:,

我们在之前几家公司做项目的时候为了平衡“工程实现复杂度”和“运行效率”,往往采用类似Netstring的协议,并进一步简化,固定10bytes的ASCII头表示消息长度,后面紧跟数据。

0000000002hi

这样做的优势有:

  • ASCII头方便debug
  • 10bytes固定头长度,易于算法实现,消息长度上限大约是10GB,基本够用
  • 头后面紧跟数据,不需要其它逻辑

应朋友请求打个广告

欢迎加入Reboot运维&开发技术交流群:365534424

编辑于 2016-07-28

文章被以下专栏收录