即时通讯（Instant Messaging）大家应该都不陌生，平时使用的社交软件（微信、QQ等）基本都包含这种功能。想必看这偏文章的应该也都是同行，这里不做赘述。我们从协议的角度上来分析一下。
即时通讯协议有很多种，包括 WebSocket、MQTT、XMPP，都是应用层协议。应用层协议就有很多了，不仅包含上边列出的 WebSocket、MQTT、XMPP，还有大家熟知的 HTTP、POP、RTMP、SSH 等。下面我们还是聚焦到几种即时通讯协议上。先分别来说一下优缺点：
Http 轮询
Http 轮询严格意义上来讲算不上即时通讯协议，把它列上就是因为确实有不少开发者（或者公司）刚开始时就是使用 Http 轮询的方式来模拟即时通讯。因为这是最简单的，可以很快速的实现这个功能。Http 请求是单向性的，也就是只是在客户端发起请求，但 server 想推数据到 client 就无能为力了。最初 ajax 流行时，很多也都会用 http 轮询的方式来完成交互。优点就是简单、可控，缺点就是不实时，而且很多情况有冗余请求，而且 http 请求时也会包含过长的头部，其中的有效部分可能只有很少的内容。
WebSocket（与 Socket 可不是一个东西）
WebSocket(RCF) 就是为了解决上述问题而产生的。关于协议的概述可以去看一下 Protocol Overview，本质就是一开始会通过 HTTP 握手，然后建立 TCP 连接，在此连接上进行全双工的数据传输。
客户端的握手请求如下：
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
服务端返回的握手如下：
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat
优点就是不用轮询，直接建立全双工连接，可以实时的收发消息。
缺点就是各浏览器支持程度不一，而且服务端长期维护长连接需要一定的成本。
MQTT
MQTT 是一个基于代理的轻量级的 pub/sub 的消息传输协议。关于协议本身可以参考 协议规范。MQTT 设计之初就
是为了低带宽或者网络不可靠的情况下的通讯。
优点就是对带宽等硬件要求较低，适用于物联网场景。
缺点就是不支持点对点通信，以及 broker 等还不算很成熟，使用时坑可能比较多。
MQTT Broker 选型
XMPP
RFC RFC 中文 XSF
具体相关的历史可以去以上网站查询，这里不再赘述了。
XMPP 是 Extensible Messaging and Presence Protocol 的简拼，协议本身就体现了可扩展的特性，而且由于是基于 TCP 长链接的 XML 流，所以可扩展性也是由于 XML 本身可扩展的优点所提供的。而同样的 XML 的缺点当然也会体现于 XMPP 中，对于 Server 端来讲会数据负载过重，对于 Client 来讲，会有耗电、耗流量等问题。
优点是协议成熟，强大，可扩展性强，并且有成熟的开源方案
缺点是信息冗余量大（信息的格式是 XML），因而费流量，费电
GCM
看到有些人把 GCM 也归类到即时通讯协议里边，有点匪夷所思。GCM 实际是一个服务，而不是协议层的东西。
