Websocket不是拯救世界的未来战士，那socket.io呢？

今天在微博上看到朋友们在讨论关于各种web推送技术的话题，心里一阵唏嘘，触景生情，想想觉得自己还真是与这个叫做“web推送”的技术渊源颇深，有必要就这个话题唠叨两句，来回顾自己的青春，若是这篇乱弹，能对刚接触这个东西的年轻朋友有些启示，也算哥肚皮上累积了7年的脂肪没有白长。

Web项目里，其实有好几个场景都非常需要这个技术，比如：实时在线用户列表，聊天，文件上传的进度条，在页面上实时显示系统日志，web页面同步。哥几乎经历和使用过这个领域常用的所有技术，从早期自己实现轮询，长轮询，piggyback, IFRAME，到后来的flex插件, DWR。以及现在websocket和封装的相对成熟的socket.io等等，虽说软件技术更新快速，但说实话，对这个领域的发展让人真的很不爽，这么多年过去了，直到今天还有没有那一种，让人在这个问题上真正省心。写到这里，基本上是进入一个吐槽的情绪，在正式吐槽之前，先撤点温情的话题吧，毕竟开头都说了这个文章主要是回顾自己的青春。

开始之所以说自己与“推送”颇有渊源，一是因为在过去的几年，在多个项目中，自己多次用不同的方式都用过相关的技术。二来，自己有两个有趣的经历与此相关。

先说有趣的经历吧：

第一段经历是，当年加入京东商城研究院面试的时候，面试官让我介绍了自己了解的web推送技术，刚好这些技术，我全部都用过，把自己从长轮询，iframe 到flex插件的各种使用经历都告诉了他，最后又展望了一下那时候还没有出来的websocket，面试官相当满意，我相信最后能拿到offer，这个问题起了很大的作用。

第二段是，在09年的一天，DWR的创始人，竟然出现在我的办公室，没错，就是他-DWR的创始人，来到了我在成都的办公室，原因是他是我老板朋友，所以来中国的时候，就过来玩玩，令当时还比较年轻的我，不可思议，一是自己无论如何没想到竟然能接触到那个时代最有影响力的团队，二来这个传说中的大牛其实是一个只有20多岁，有点腼腆的小伙子，真是没想到啊。有朋友要问，DWR是啥? 让哥告诉你把，08年前后全世界java社区最流行的ajax框架之一， 所谓的”反向ajax”，英文叫“Reverse Ajax”应该就是这个团队发明出的一个唬人的名词。虽然DWR看着很光鲜，其实BUG也是蛮多的，尤其是反向AJAX这一块，我们团队就帮他打了不少的patch。

OK，咸淡扯完进入正题。 网上关于实现轮询，长轮询，iframe stream、如何使用flex插件进行通信，以及如何使用DWR, websocket如何使用，socket.io+ node.js 如何使用的文章多如牛毛，中间也不乏优秀程序员的精品文章，因此关于具体使用方面的问题，这里就不再赘述，需要的朋友google一下，就很容易找到满意的方案。

今天这里主要使用吐槽方式，将自己过去几年里，在各种推送技术的使用中遇到的问题，和大家一起分享，以示对这个领域技术发展缓慢的不爽！！！！

一说到吐槽web推送技术，大家肯定就会说各种浏览器对 websocket的支持越来越好了，这个问题早就不是问题了，但真的就不是问题了吗？

那咱们就从这个该死的websocket开刀，曾几何时，websocket是每个程序员心目中的共产主义，想着有了websocket的一天，我们就可以很轻松的实现进度条，聊天等等功能。今天,从IE10， firefox, safari，chrom几乎所有浏览器的最新版本已经支持了websocket，可是，美好的一天真的到来了吗？ 哥不是这方面的专家，只说说哥在使用websocket中遇到的各种血泪史：

• 哥要实现一个在线用户列表，但如果直接使用websocket，服务器端却没有一个API准确的告诉哥，客户端的在线状态，哥不得不像傻逼的一样每隔几秒钟发一个PING，去检测一个客户端的是否在线，并通过超时的方式来维护整个在线用户列表。至少从程序员的工作量上，这并没有比轮询或长轮询节约任何时间。
• 从后台发送一条消息到客户端，服务器端并无法知晓消息是否到达客户端，为了确保每一条消息到达，你就不得不在客户端做一些该死的额外工作：发送一个确认消息回去，让服务器知道，这条消息到达。如果你的功能要求每条消息必须到达，你的活儿就更多了，你还需要实现消息在服务器端的缓存，以备客户端网络不好时，需要重发，这些活儿可都不少啊。

这里只是讲了最常见的两个恶心的问题，其实在具体实践中还有更多更恶心的问题，比如客户端要定时检测网络，网络断开的时候还要自己重连； 要确保消息到达但还不允许重复发送，就需要更多的握手来确保，等等等各种恶心的问题，这其实是有很多活儿要干的。

至少从程序员的工作量上来说，相比其他的技术，websocket就没有带来任何的福利，此时此刻，真的很想说F开头的词语。更重要的是，至少在中国大部分系统还需要支持没有websocket的浏览器。

以上提到的这些问题websocket存在，long polling这些较早期的技术也同样存在。

Websocket根本不是未来战士，他拯救不了世界！

很多人可能觉得这家伙吹毛求疵，要求太高，但哥跟你的观点不同，别忘了现在是21世纪，各种推送技术已经发展了十几二十年，就这么简单一个东西，到今天为止，依然不能让大家省心，这真的令人费解，我相信很多程序员跟哥一样，不关心底层的实现，就需要一个像JDBC一样简单的东东，一两个小时让一个系统具备一套相对完整的推送功能，那么什么样的功能算是相对完整呢，哥认为，一个合理的推送技术，期望是这样（欢迎其他朋友补充）：

1.客户端在线的时候，每条消息确保到达。
2.客户端网络掉线，服务器要有API及时准确捕捉。
3.服务器挂掉时，客户端有API及时捕捉。
4.客户端掉线后，一旦网络恢复，客户端可以自动重连。
5.断线期间的消息，在重连后能立即自动补发，确保每条消息不丢失。
6.能兼容所有浏览器，不论这个浏览器是否支持websocket。
7.像JDBC一样简单，一年经验的程序员一两个小时就能用起来。

大家可能又要说了，socket.io就可以自动重连，又支持所有浏览器。但我想告诉你的是socket.io也同样不是一个省油的灯。

如果你要使用socket.io，那么你就要会用node.js，或者其他语言实现socket.io通信协议的后台程序。Node.js的工作量可不少，哪怕你是一个非常熟练的js程序员，想在一个月内开发一套非常稳定完善的系统都不是一件容易的事情。如果你刚好又是新手，你连NPM是什么都不知道，那恭喜你，不经历一番学习，你是不容易在短期内做出这样的功能。

更具体的是，socket.io团队的对项目的支持效率很低，在低版本浏览器的支持上还有不少的问题，而且修复的很慢，至少哥给他们报的BUG一直没人理睬，想想也是要哭了！

Fxxk，哥就是想在一个预算只有几万元，开发周期只有一两周的项目中加一个简单的文件上传的进度条，真的就有这么困难吗？ 没错，如果您要实现一个稳定的功能，他就真没办法这么简单的搞定，这个东西就是这么Fxxk!

想想这么多年过去了，各种技术更新换代，但就这么一个九十年代就存在的看起来不难的问题，20年过去了，依然没有能够是没能很好的解决，这难道不是一个巨大的悲剧吗！！！！

我是不是正在把你带向一个万劫不复的恶劣情绪？呵呵，请不要太入戏了，哥说的的是，目前没有一个成熟稳定的技术，能让程序员一两个小时就能将一个稳定完善的功能跑起来。哥强调的是：轻松、容易、短时间，稳定完善。

这个东西真的很难吗？当然不是，哥就曾经用DWR和socket.io都分别开发出来过很稳定的推送功能，当然时间也是花了不少，不论是自己开发，还是对社区中开源的项目进行二次开发，投入适当的人力和一定的时间，开发一个相对稳定的推送功能当然并非什么难事。

难的是如果你想快速的在一个低成本，开发周期短的项目中实现一个这样的功能，那就真的是个很烦人的事情！！！

每每想到这些，哥就夜不能寐，恨不得瞬间化身为未来战士，拿出一个大招，开发一个小插件从根本上解决这个问题，为社区贡献一点点力量，一直有这样一个想法，但因为各方面的原因，到现在还一直没能开始。

在我的大招出来之前，个人觉的一个稳定可靠的第三方推送服务可能是现阶段比较稳妥的一个选择，所以哥自己动手搞了一个web推送服务，放在亚马逊的云服务上，供大家免费使用，网址是https://goeasy.io 为了发扬国际共产主义精神，所以版面选择了英文版，国外也有许多蛋疼的朋友，需要帮助啊，当然咱也是撰写了完整的中文文档可供下载。希望大家多提建议，对大家也能有所帮助。

关于web推送的话题，欢迎大家热烈讨论！

开发一个插件从根本上解决这个问题，也已经列入计划，对这个新插件我的期望是：
1.不需要学习node.js类似的后台技术
2.使用简单，半小时跑起来

期望这个小插件能在2016年早日与大家见面，欢迎大家关注我的博客，敬请期待。