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中遇到的各類血淚史：

1. 哥要實現一個在線用戶列表，但若是直接使用websocket，服務器端卻沒有一個API準確的告訴哥，客戶端的在線狀態，哥不得不像傻逼的同樣每隔幾秒鐘發一個PING，去檢測一個客戶端的是否在線，並經過超時的方式來維護整個在線用戶列表。至少從程序員的工做量上，這並無比輪詢或長輪詢節約任什麼時候間。

2. 從後臺發送一條消息到客戶端，服務器端並沒有法知曉消息是否到達客戶端，爲了確保每一條消息到達，你就不得不在客戶端作一些該死的額外工做：發送一個確認消息回去，讓服務器知道，這條消息到達。若是你的功能要求每條消息必須到達，你的活兒就更多了，你還須要實現消息在服務器端的緩存，以備客戶端網絡很差時，須要重發，這些活兒可都很多啊。

這裏只是講了最多見的兩個噁心的問題，其實在具體實踐中還有更多更噁心的問題，好比客戶端要定時檢測網絡，網絡斷開的時候還要本身重連； 要確保消息到達但還不容許重複發送，就須要更多的握手來確保，等等等各類噁心的問題，這實際上是有不少活兒要乾的。

至少從程序員的工做量上來講，相比其餘的技術，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年早日與你們見面，歡迎你們關注個人博客，敬請期待。