# 32、实时信息传递的方式对比
ajax轮询，长轮询(long polling)，websocket都可以实现实时信息传递
# 轮询
# ajax轮询（短轮询）
短轮询
让浏览器隔个几秒钟就发送一次请求，询问服务器是否有新的信息，服务器收到后无论是否有数据都立即返回。
- 客户端：啦啦啦，有没有新信息(
Request) - 服务端：没有（
Response） - 客户端：啦啦啦，有没有新信息(
Request) - 服务端：没有。。（
Response） - 客户端：啦啦啦，有没有新信息(
Request) - 服务端：你好烦啊，没有啊。。（
Response） - 客户端：啦啦啦，有没有新消息（
Request） - 服务端：好啦好啦，有啦给你。（
Response） - 客户端：啦啦啦，有没有新消息（
Request） - 服务端：。。。。。没。。。。没。。。没有（
Response） ---- loop
# long polling（长轮询）
长轮询
和ajax轮询原理差不多，都是采用轮询的方式，不过采取的是阻塞模型（一直打电话，没收到就不挂电话），也就是说，浏览器发起链接，服务器收到请求后，若有数据，则立即返回。若无数据则保持到有数据或超时后返回。浏览器收到响应后立即重新发送相同的请求。
- 客户端：啦啦啦，有没有新信息，没有的话就等有了才返回给我吧（
Request） - 服务端：额。。 等待到有消息的时候。。来 给你（
Response） - 客户端：啦啦啦，有没有新信息，没有的话就等有了才返回给我吧（
Request） -loop
# 小结
总结
所以，其实这两种方式都是在不断的建立HTTP链接，然后等待服务器端处理，可以体现HTTP协议的另外一个特性：被动性
什么是被动性：服务器端不能主动联系客户端，只有等客户端发起；
缺陷：
以上两种方式不管怎么样，都是非常消耗资源的；
ajax轮询 ：需要服务器有很快的处理速度和 资源（速度）
long polling： 需要有很高的并发，也就是说同时接待客户的能力（场地大小）
所以以上两种方式都有可能出现如下的情况：
- 客户端：啦啦啦啦，有新信息么？
- 服务端：月线正忙，请稍后再试（
503 Server Unavailable） - 客户端：。。。。好吧，啦啦啦，有新信息么？
- 服务端：月线正忙，请稍后再试（
503 Server Unavailable） - 客户端：
- 然后服务端在一旁忙的要死：冰箱，我要更多的冰箱！更多。。更多。。（我错了。。这又是梗。。）
# 长连接和短连接
TIP
本质上是TCP的长连接与短连接，HTTP1.0默认短连接，HTTP1.1起默认长连接;
- 短连接：在一次
HTTP请求响应后，本次TCP连接关闭。下次请求响应重新建立一个TCP链接。 - 长连接：在请求响应后，
TCP链接在到达超时时间之前不会关闭，下次请求响应继续使用该TCP链接。
HTTP1.0通过在请求头设置Connection:keep-alive开启长连接，后端通过Keep-Alive:timeout=20来设置长连接的超时时间（秒），并且服务端也要具备Keep-Alive: true
# websocket
websocket
通过上面的例子，我们可以看出，这两种都不是最好的方式，需要很多的资源，一种需要更快的速度，一种需要更多的'场地'，这两种都会导致'场地'的需求会越来越高；
还有HTTP是一个无状态的协议，通俗的来说就是，服务器因为每天要接待很多个客户，是个健忘的人，你一断了请求，他就把你的东西全忘光了，你第二次还得再告诉服务器一遍；
所以在这种情况下，websocket出现了。它解决了HTTP的几个难题
1、被动性，当服务器完成协议升级后（HTTP->Websocket），服务端就可以主动推送信息给客户端，场景可以做如下修改
- 客户端：啦啦啦，我要建立
Websocket协议，需要的服务：chat，Websocket协议版本：17（HTTP Request） - 服务端：ok，确认，已升级为
Websocket协议（HTTP Protocols Switched） - 客户端：麻烦你有信息的时候推送给我噢。。
- 服务端：ok，有的时候会告诉你的。
- 服务端：balabalabalabala
- 服务端：哈哈哈哈哈啊哈哈哈哈
- 服务端：笑死我了哈哈哈哈哈哈哈
这样的话只需要经过一次HTTP请求，就可以做到源源不断的信息传送了，这样的协议解决了同步有延迟，而且还非常消耗资源的情况
那websocket是怎么解决服务器上消耗资源的问题呢？
其实我们所用的程序是要经过两层代理的，即HTTP协议在Nginx等服务器的解析下，然后再传送给响应的handler（PHP等）来处理。简单的说，我们有一个非常快速的接线员（Nginx），他负责把问题转交给响应的客服（Handler）。
本身接线员基本上速度是足够的，但是每次都卡在客服（handler）了，老师有客服处理速度太慢。导致客服不够，websocket就解决了这样一个难题，建立后，可以直接跟接线员建立持久链接，有信息的时候客服想办法通知接线员，然后接线员再统一交给客户。这样就解决了客服处理速度过慢的问题了。