说到协议，我们第一反应都会想到http，既然这样，那就对Http协议再简单的BB一番，没有对比就没有伤害，我们来见证一下最终是谁会是受伤的一方，当然结果还是你说了算，不要问小编为什么，因为你牛逼啊。
Http协议：
众所周知的超文本传输协议，所有的万维网都遵循此协议，这家伙出道早（1945年传说中RFC-http1.0），加上又没有竞争对手可称之为在协议界的一大霸主。
建立在TCP协议之上，称之为http，但是建立在SSL和TLS协议层之上，又变成了人们常说的https。总之不管怎样，他们只是所承载的协议层不同罢了，不要太介怀。如果你很是介怀，没办法，小编只能说你先去熟悉网络的7层协议，一层层分析，慢慢介怀去。
再来简单说下，http请求响应模式：
宏观上看是不是超级简单？一个Request 对应一个 Response。建立连接后，客户端发送一次请求，服务端确认收到了，就被动反应一下。看起来很不友好的样子，在1.0时更可怜，默认的是短连接，客户端和服务端之间频繁的建立连接，频繁的断开连接，在1.1起开始引入keep-alive（长连接）即是在http请求的header中加了一个识别：connetion:keep-alive(代表告诉服务器，我要的是长连接)。
但依旧解决不了服务端的‘高冷’和‘惰性’。因此引发了下一个问题：http协议是有很大缺陷的。
Http协议的缺点：
通过上面简单的介绍，我们明显感觉到，客户端和服务端之间的交互有点生硬，服务端有点被动，客户端问一句，服务端答一句，客户端没命的啰嗦就会导致浪费时间和带宽（针对于短连接来说）。
如果是长连接的话，那可能更惨，客户端发一个请求，服务端没有及时返回，链接就一直建立着，上面也说了，http的相应模式无论是多少台客户端发出请求，服务端的标配是一个request对应一个response，如此说来，如果很多的这样的链接的话，那么服务端就有扛不住的时候，所以有的时候就会碰到server is too busy，这时你又该骂娘了。
说到这，我们再来说说，这种不友好的相应模式最终的根源是啥。
哦，原来是有两种机制导致的，Ajax轮询long poll的轮询机制，分别对应短连接和长连接的实现形式。
ajax轮询是，孜孜不倦，乐在其中啊，那我就隔几秒请求一次，服务端和客户端来回的断开建立，就这样一问一答直到客户端拿到了自己想要的东西，所以这种沟通贼浪费时间和宽带。
long poll呢也是采用了轮询机制，但是他轮询的时间比较长，如果把ajax看成是发短信，那他就是打电话了（可以称之为阻塞模型），客户端就和服务端杠上了，高冷是吗？没关系，我会一直等，等你有数据反馈给我，就这样一直占线轮询。
综上所述，http的一大‘亮点’就是，客户端不请求，服务端绝对不会主动。凸显了http数据传输的一个被动性。
WebSocket协议：
这个社会是发展的，所有风靡一时的荣耀最终都会被崛起的新事物给慢慢取代，当然说的有点严重，反正就是那意思了。鉴于http的缺点，伴随着http的发展，直到h5出现，Websocket应运而生。
不过，新事物的单身往往都是踩在巨人的肩膀上的，WebSocket也是基于http协议的一种持久化的协议，并不是跟http毫无关系，可以说是http协议的一种进化。
那么Websocket是怎样建立连接的呢？
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13 Origin: http://example.com
以上是请求的头，Websocket很是高调啊，生怕对方不知道是自己的协议，整了这么多关键字眼，废话不多说，抽几个关键的说说吧。
Upgrade && Connection：告诉服务端我采取的是什么协议。
Sec-WebSocket-Key：别乱来，我是有身份证的。
剩下的就不说了，很显然，客户端是比较仔细的，定制的很是详细。
服务器接到请求后，就回应了下：
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat
看起来服务端也是很守规矩，告诉客户端，你看看信息对不对。
细心的同学会发现，不对啊，那个发送的key和请求的key怎么不一样呢？孩子别太单纯那是服务端加过密的，小编没搞错的话应该是SHA-1的加密方式。
好了，以上就是客户端和服务端建立连接的过程。
Websocket特点：
回归到http协议的被动性和一些缺点，那么Websocket协议就凸显的很好了，请求只需要成功建立一次，这次咸鱼翻身了，服务端会屁颠屁颠的主动把信息反馈给客户端，完美解决了之前的被动性，提高沟通效率，减少了沟通成本，真正建立了久连接。
但是，人无完人，websockt需要浏览器的支持，如果有些浏览器不支持，也没什么卵用了。另外假如设置的有代理，需要代理也支持。更要命的是需要服务器支持，如果服务器不支持，那对不起，发了一堆什么破乱玩意，本座不认识，打回！
另外，websocket实现的是双向通道，对网络的链接要求很高，这是其优点也是缺点，一旦一方网络有问题，那就直接game-over了。
小编有话说：
以上是本人看了些资料，加以消化和总结的，有什么不对的地方希望给出改正，另外，两种协议终究哪个更好，你们说了算。
