主要讲解了服务器推送的发展历程

1. 前端那点事系列分享 实时信息推送

2. 应用场景 微博状态更新 地图中公交实时路况信息 Question: 1、client端要向server端不停的请求 2、client端要在人工不干预的情况下发起请求

3. 古老的方式诞生了 那时候传说中的Ajax还没出生 不能让用户手动F5，但也要让浏览器发起请求 HTML的原生支持，meta refresh Question: 1、如此糟糕的体验，还可以更差点吗？ 2、整页的刷新，低效，可耻的浪费！！

4. 来自微软的福音—AJAX 异步请求，非阻塞 XHR ——same origin policy，不能跨域，双刃剑 局部刷新页面，体验较好 Question: 1、但是要满足信息实时性，client端会定时的发起http请求，请求可不可以少一点？打开关闭如此多依然是可耻的浪费！ 2、如何确保每个链接都有数据返回，没有数据返回的链接木有意义 3、新的数据在server端，可不可以让server端主动推送？

5. AJAX可看作是一种中间件

6. HTTP长链接-Comet 基于AJAX 长轮询（long-polling） 流（streaming）方式

7. long-polling Server端阻塞请求直到有数据返回或者超时 XHR的readyState为4时，js执行回调函数，执行完毕后，再次发送请求 优劣： 确保了每个链接都是有数据返回的，但是如果实时数据更新频繁，仍然会有很多打开关闭的过程。 Tips: 0 (未初始化)： XHR对象已经创建，但还没有调用open()方法。1 (载入)：已经调用open() 方法，但尚未发送请求。2 (载入完成)： 请求已经发送完成。3 (交互)：可以接收到部分响应数据。4 (完成)：已经接收到了全部数据，并且连接已经关闭

8. Streaming 最初的作法是在XHR的readyState为3时读取数据，从而保证链接不会被关闭 非理想状态下，长连接会被防火墙或者服务器干掉，client端要支持自动重连 蛋疼的IE不支持readyState==3时读取数据，使用Iframe，一统天下！ 优劣： 理想状态打开一次关闭一次； readyState==3模式支持不完全； Iframe方式浏览器（IE、FF）会有进度条（Google大婶使用ActiveX技术解决） 有些response会没有更新数据返回

9. 非comet comet Long-polling Streaming client server client server open open open New data New data close close close 没有新的数据，则阻塞请求 open New data close 连接超时重连 open New data Re-open close Client处理时server端有数据到达 New data close close data0+data1 data0 open data1 close

10. 崭新的世界 再怎么模拟，http也不是擅长做实时通信的 HTML5 websocket脱离http的束缚！没有了http那些对我们来说无用的header，传输更加快捷 专为server与client实时通信打造 demo

11. 有关注意事项 Nginx的反向代理一般会自动bufferServer的response，会导致client木有实时更新的效果 proxy_buffering off； //关闭 W3c的规范是client端不能持有2个以上的同源长连接，多出的会被阻塞 对于tomcat这种多线程服务器，服务器端会持有大量并发的长连接，可不可以再优化？（NIO?） 让server和client都知道大家都还活着，维持“心跳”，单向关闭后及时通知对方，及时释放资源

12. 与Isearch通信都是使用HTTP，这个使用场景是否更适合用长连接 地图的图片加载可否考虑使用websocket

13. THE END 下期预告：让浏览器歇一会儿吧！服务端渲染DOM？客户端流水加载？服务端并行渲染？