TCP/IP, WebSocket 和 MQTT

转自：  http://www.cnblogs.com/shanyou/p/4085802.html

 

 

按照OSI网络分层模型，IP是网络层协议，TCP是传输层协议，而HTTP和MQTT是应用层的协议。在这三者之间， TCP是HTTP和MQTT底层的协议。你们对HTTP很熟悉，这里简要介绍下MQTT。MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是IBM开发的一个即时通信协议，有可能成为物联网的重要组成部分。该协议支持全部平台，几乎能够把全部联网物品 和外部链接起来，被用来当作传感器的通讯协议。

1. HTTP的不足

   HTTP协议通过多年的使用，发现了一些不足，主要是性能方面的，包括：

   HTTP的链接问题，HTTP客户端和服务器之间的交互是采用请求/应答模式，在客户端请求时，会创建一个HTTP链接，而后发送请求消息，服务端给出应答消息，而后链接就关闭了。（后来的HTTP1.1支持持久链接）
   由于TCP链接的创建过程是有开销的，若是使用了SSL/TLS开销就更大。

   在浏览器里，一个网页包含许多资源，包括HTML，CSS，JavaScript，图片等等，这样在加载一个网页时要同时打开链接到同一服务器的多个链接。

   HTTP消息头问题，如今的客户端会发送大量的HTTP消息头，因为一个网页可能须要50-100个请求，就会有至关大的消息头的数据量。

   HTTP通讯方式问题，HTTP的请求/应答方式的会话都是客户端发起的，缺少服务器通知客户端的机制，在须要通知的场景，如聊天室，游戏，客户端应用须要不断地轮询服务器。

   而 WebSocket是从不一样的角度来解决这些不足中的一部分。还有其余技术也在针对这些不足提出改进。

2. WebSocket
   WebSocket则提供使用一个TCP链接进行双向通信的机制，包括网络协议和API，以取代网页和服务器采用HTTP轮询进行双向通信的机制。

   本质上来讲，WebSocket是不限于 HTTP协议的，可是因为现存大量的HTTP基础设施，代理，过滤，身份认证等等，WebSocket借用HTTP和HTTPS的端口。因为使用HTTP 的端口，所以TCP链接创建后的握手消息是基于HTTP的，由服务器判断这是一个HTTP协议，仍是WebSocket协议。 WebSocket链接除了创建和关闭时的握手，数据传输和HTTP没丁点关系了。

历时11年，WebSocket终于被批准成为IETF的建议标准：RFC6455.其前身是WHATWG （Web Hypertext Application Technology Working Group）的工做。而Web Socket的API,是W3C的工做。

WebSocket能够只打开一个到服务器的连接，而且在此连接上交换信息。其优点在于减小了传统方法的复杂性，提升了可靠性和下降了浏览器和客户端之间的负载。这样作的一个重要缘由是，不少防火墙屏蔽80之外的端口，迫使愈来愈多的应用迁移到HTTP上来了。

11年的websocket草案的变迁中，有的浏览器支持的是旧版本的websocket，好比iPhone4上的safari使用的WebSocket是旧版的握手协议,那么就要使用就的握手协议来制作服务器端。现在只有Safari支持旧版本的协议，Chrome和Firefox最新版都已升级至Hybi-10（协议地址）。所以，咱们再来看一下WebSocket新版协议Hybi-10。此次协议变动很是大，主要集中在握手协议和数据传输的格式上。

握手协议

咱们先来看一下大体的区别：

1. 最老的websocket草案标准中是没有安全key，草案7.5、7.6中有两个安全key，而如今的草案10中只有一个安全key，即将 7.5、7.6中http头中的"Sec-WebSocket-Key1″与"Sec-WebSocket-Key2″合并为了一个"Sec- WebSocket-Key"
2. 把http头中Upgrade的值由"WebSocket"修改成了"websocket"；http头中的"-Origin"修改成了"Sec-WebSocket-Origin";
3. 增长了http头"Sec-WebSocket-Accept"，用来返回原来草案7.5、7.6服务器返回给客户端的握手验证，原来是之内容的形式返回，如今是放到了http头中；另外服务器返回客户端的验证方式也有变化。

服务器生成验证的方式变化较大，咱们来作一介绍。

旧版：

1 GET / HTTP/1.1
2 Upgrade: WebSocket
3 Connection: Upgrade
4 Host: 127.0.0.1:1337
5 Origin: http://127.0.0.1:8000
6 Cookie: sessionid=xxxx; calView=day; dayCurrentDate=1314288000000
7 Sec-WebSocket-Key1: cV`p1* 42#7  ^9}_ 647  08{
8 Sec-WebSocket-Key2: O8 415 8x37R A8   4
9 ;"######

旧版生成Token的方法以下：

取出Sec-WebSocket-Key1中的全部数字字符造成一个数值，这里是1427964708，而后除以Key1中的空格数目，获得一个数值，保留该数值整数位，获得数值N1；对Sec-WebSocket-Key2采起一样的算法，获得第二个整数N2；把N1和N2按照Big- Endian字符序列链接起来，而后再与另一个Key3链接，获得一个原始序列ser_key。Key3是指在握手请求最后，有一个8字节的奇怪的字符串";"######"，这个就是Key3。而后对ser_key进行一次md5运算得出一个16字节长的digest，这就是老版本协议须要的 token，而后将这个token附在握手消息的最后发送回Client，便可完成握手。

新版：

1 GET / HTTP/1.1
2 Upgrade: websocket
3 Connection: Upgrade
4 Host: 127.0.0.1:1337
5 Sec-WebSocket-Origin: http://127.0.0.1:8000
6 Sec-WebSocket-Key: erWJbDVAlYnHvHNulgrW8Q==
7 Sec-WebSocket-Version: 8
8 Cookie: csrftoken=xxxxxx; sessionid=xxxxx

新版生成Token的方法以下：

首先服务器将key（长度24）截取出来，如4tAjitqO9So2Wu8lkrsq3w==，用它和自定义的一个字符串（长度 36）258EAFA5-E914-47DA-95CA-C5AB0DC85B11链接起来，而后把这一字符串进行SHA-1算法加密，获得长度为20字节的二进制数据，再将这些数据通过Base64编码，最终获得服务端的密钥，也就是ser_key。服务器将ser_key附在返回值Sec- WebSocket-Accept后，至此握手成功。

WebSocket也有本身一套帧协议。数据报文格式以下：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

0                   1                   2                   3       01234567890123456789012345678901      +-+-+-+-+-------+-+-------------+-------------------------------+      |F|R|R|R|opcode|M|Payload len|    Extended payload length    |      |I|S|S|S|  (4)  |A|     (7)     |             (16/63)           |      |N|V|V|V|       |S|             |   (ifpayload len==126/127)   |      ||1|2|3|       |K|             |                               |      +-+-+-+-+-------+-+-------------+---------------+      |     Extended payload length continued,ifpayload len==127  |      +---------------+-------------------------------+      |                               |Masking-key,ifMASK set to1  |      +-------------------------------+-------------------------------+      |Masking-key(continued)       |          Payload Data         |      +-----------------------------------------------+      :                     Payload Data continued...                :      +-------------------------------+      |                     Payload Data continued...                |      +---------------------------------------------------------------+

FIN：1位，用来代表这是一个消息的最后的消息片段，固然第一个消息片段也多是最后的一个消息片段；

RSV1, RSV2, RSV3: 分别都是1位，若是双方之间没有约定自定义协议，那么这几位的值都必须为0,不然必须断掉WebSocket链接；

Opcode:4位操做码，定义有效负载数据，若是收到了一个未知的操做码，链接也必须断掉，如下是定义的操做码：

• %x0 表示连续消息片段
• %x1 表示文本消息片段
• %x2 表未二进制消息片段
• %x3-7 为未来的非控制消息片段保留的操做码
• %x8 表示链接关闭
• %x9 表示心跳检查的ping
• %xA 表示心跳检查的pong
• %xB-F 为未来的控制消息片段的保留操做码

Mask:1位，定义传输的数据是否有加掩码,若是设置为1,掩码键必须放在masking-key区域，客户端发送给服务端的全部消息，此位的值都是1；

Payload length: 传输数据的长度，以字节的形式表示：7位、7+16位、或者7+64位。若是这个值以字节表示是0-125这个范围，那这个值就表示传输数据的长度；若是这个值是126，则随后的两个字节表示的是一个16进制无符号数，用来表示传输数据的长度；若是这个值是127,则随后的是8个字节表示的一个64位无符合数，这个数用来表示传输数据的长度。多字节长度的数量是以网络字节的顺序表示。负载数据的长度为扩展数据及应用数据之和，扩展数据的长度可能为0,于是此时负载数据的长度就为应用数据的长度。

Masking-key:0或4个字节，客户端发送给服务端的数据，都是经过内嵌的一个32位值做为掩码的；掩码键只有在掩码位设置为1的时候存在。
Payload data:  (x+y)位，负载数据为扩展数据及应用数据长度之和。
Extension data:x位，若是客户端与服务端之间没有特殊约定，那么扩展数据的长度始终为0，任何的扩展都必须指定扩展数据的长度，或者长度的计算方式，以及在握手时如何肯定正确的握手方式。若是存在扩展数据，则扩展数据就会包括在负载数据的长度以内。
Application data:y位，任意的应用数据，放在扩展数据以后，应用数据的长度=负载数据的长度-扩展数据的长度。

3、 MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是轻量级基于代理的发布/订阅的消息传输协议，设计思想是开放、简单、轻量、易于实现。这些特色使它适用于受限环境。例如，但不只限于此：

• 网络代价昂贵，带宽低、不可靠。
• 在嵌入设备中运行，处理器和内存资源有限。

该协议的特色有：

• 使用发布/订阅消息模式，提供一对多的消息发布，解除应用程序耦合。
• 对负载内容屏蔽的消息传输。
• 使用 TCP/IP 提供网络链接。
• 有三种消息发布服务质量：
• "至多一次"，消息发布彻底依赖底层 TCP/IP 网络。会发生消息丢失或重复。这一级别可用于以下状况，环境传感器数据，丢失一次读记录无所谓，由于不久后还会有第二次发送。
• "至少一次"，确保消息到达，但消息重复可能会发生。
• "只有一次"，确保消息到达一次。这一级别可用于以下状况，在计费系统中，消息重复或丢失会致使不正确的结果。
• 小型传输，开销很小（固定长度的头部是 2 字节），协议交换最小化，以下降网络流量。
• 使用 Last Will 和 Testament 特性通知有关各方客户端异常中断的机制。

早在1999年，IBM的Andy Stanford-Clark博士以及Arcom公司ArlenNipper博士发明了MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）技术。BM和St. Jude医疗中心经过MQTT开发了一套Merlin系统，该系统使用了用于家庭保健的传感器。St. Jude医疗中心设计了一个叫作Merlin@home的心脏装置，这种无限发射器能够用来监控那些已经植入复律-除颤器和起搏器（二者都是基本的传感 器）的心脏病人。

该产品利用MQTT把病人的即时更新信息传给医生/医院，而后医院进行保存。这样的话，病人就不用亲自去医院检查心脏仪器了，医生能够随时查看病人的数据，给出建议，病人在家里就能够自行检查。

IBM称该发射器包括一个大型触摸屏，一个嵌入式键盘平台，以及一个Linux操做系统。

在将来几年，MQTT的应用会愈来愈广，值得关注。

经过MQTT协议，目前已经扩展出了数十个MQTT服务器端程序，能够经过PHP，JAVA，Python，C，C#等系统语言来向MQTT发送相关消息。

此外，国内不少企业都普遍使用MQTT做为 Android手机客户端与服务器端推送消息的协议。其中Sohu，Cmstop手机客户端中均有使用到MQTT做为消息推送消息。据Cmstop主要负 责消息推送的高级研发工程师李文凯称，随着移动互联网的发展，MQTT因为开放源代码，耗电量小等特色，将会在移动消息推送领域会有更多的贡献，在物联网 领域，传感器与服务器的通讯，信息的收集，MQTT均可以做为考虑的方案之一。在将来MQTT会进入到咱们生活的各各方面。

若是须要下载MQTT服务器端，能够直接去MQTT官方网站点击software进行下载MQTT协议衍生出来的各个不一样版本。

MQTT和TCP、WebSocket的关系能够用下图一目了然:

MQTT协议专一于网络、资源受限环境，创建 之初未曾考虑WEB环境。HTML5 Websocket是创建在TCP基础上的双通道通讯，和TCP通讯方式很相似，适用于WEB浏览器环境。虽然MQTT基因层面选择了TCP做为通讯通 道，但咱们添加个编解码方式，MQTT over Websocket也能够的。这样作的好处，MQTT的使用范畴被扩展到HTML五、桌面端浏览器、移动端WebApp、Hybrid等，多了一些想像空 间。这样看来，不管是移动端，仍是WEB端，MQTT都会有本身的使用空间。