【Flask】 flask-socketio實現WebSocket

【flask-socektio】

　　以前不知道在哪一個場合下提到過如何從web後臺向前臺推送消息。聽聞了反向ajax技術這種模式以後，大呼神奇，試了一下以後發現也確實能夠用。不過，反向ajax的代價也很明顯，只要客戶端還和服務端要有信息交互，服務端就必須還維持客戶端的這個請求，而後在合適的時候返回。當客戶端一多，這麼作的成本會比較大。

　　其餘的後端推前端的技術還有相似於隱藏frame，Comet、長輪詢等等，沒有詳細瞭解過，總之也是各有千秋但也各有利弊。

　　前不久在開發中碰到了這樣一個場景，就是在後臺執行一些代碼，而後會根據執行的最新狀況推送一些提示信息到前臺讓用戶能夠知道目前執行到哪一步了。典型就是一個後臺向前端推送消息的，並且是比較簡單的一個場景。用反向ajax的話好像略顯累贅，由於消息的頻度仍是蠻高的，應該會消費很多網絡資源，並且ajax請求的url後執行的程序確定和後臺的工做程序是並行的，若是要得到工做程序的進度信息可能還會涉及到進程間通訊問題，總之各類麻煩。最好能找到一種解決方案，能夠在後臺隨時推送數據後在前臺實時展現而且容許後臺程序繼續跑的。

　　而後找了下就找到了websocket這種html5以後纔有的技術。另外再找了下發現了flask-socketio這個拓展模塊添加了flask對websocket的支持。

■　　概述

　　websocket是html5中實現了服務端和客戶端進行雙向文本或二進制數據通訊的一種新協議，其實已經低於HTTP協議自己和HTTP本質上沒有什麼關係了。不過形式上二者仍是有想象之處。所以websocket的鏈接地址是長這樣的：ws://localhost:8080。能夠看到，協議修飾符不是http了。

　　另外，websocket在鏈接創建階段是經過HTTP的握手方式進行的，這能夠看作是爲了兼容瀏覽器或者使用一些現成的功能來實現，這樣一種捷徑。當鏈接創建以後，客戶端和服務端之間就再也不進行HTTP通訊了，全部信息交互都由websocket接管。

　　從資源佔用的角度上來講，其實websocket比ajax佔用的資源更多，但它真正實現了全雙工通訊這一點仍是很理想的，意味着不管是前端仍是後臺的信息交互程序編寫都會變得更加方便。因爲採用了新的協議，因此咱們也須要適當地改造下先後臺的程序。

 

■　　前端ws編寫以及socket.io.js

　　因爲是比較新的東西，並不必定全部的瀏覽器都支持，全部能夠用:

if ('WebSocket' in window){
  websocket = new WebSocket('ws://localhost:8080');
}

 

　　這樣的方式來判斷是否支持，只有支持的狀況下才開始websocket處理

　　其實光實現雙向通訊是並無什麼用的，主要仍是在通訊過程當中，讓先後端發生一些動做，這就須要添加監聽事件。在前端這裏，咱們能夠給websocket這個對象的一些監聽回調接口賦值，來規定在不一樣的場合下前端作些不一樣的事情。好比：

wesocket.onopen = function(){
    alert('創建websocket鏈接');
}

websocket.onerror = function(){
    alert('WebSocket鏈接發生錯誤');
}

/****
等等，因爲有封裝程度更高的js模塊，就不擴展寫從較底層構建websocket的方法了
****/

 

 

　　●  socket.io.js

　　若是以爲略顯麻煩，那麼能夠用一些已經封裝好的websocket的js庫，好比socket.io.js。這個庫彷佛是專門爲了node.js設計的，（主要由於網上隨便一搜都是把它和node.js結合使用相關的信息。。）不過單獨拿出來也能用。引用若是使用cdn方式，那麼能夠寫

<script src="//cdnjs.cloudflare.com/ajax/libs/socket.io/1.3.6/socket.io.min.js"></script>

　　應用了socket.io.js的一個簡單socket對象的建立能夠這麼寫：

var websocket_url = 'http"//' + document.domain + ':' + location.port + '/testnamespace';

//沒錯是用http開頭的url了，由於這個庫會自動解析並幫咱們建立websocket對象的
//最後的namespace是websocket中的命名空間，後面再講

var socket = io.connect(wesocket_url);

 

　　獲得了這個socket對象以後，咱們能夠用這個對象進行消息的收發。簡答的消息收發以下：

//發送消息
socket.emit('request_for_response',{'param':'value'});


//監聽回覆的消息
socket.on('response',function(data){
    if (data.code == '200'){
        alert(data.msg);
    }
    else{
        alert('ERROR:' + data.msg);
    }
});

 

　　其中request_for_response和response兩個名字都是我本身取的，這兩個名字應該和後端相關的名字協同一致才能保證通訊的成功。另外剛纔提到了namespace這個東西，由於namespace是在socket建立的時候就決定的，也就是說這些消息的收發都是在'testnamespace'這個空間中進行的。因此在後端上這個空間也要和前端一致。

 

■　　後端socket編寫（flask-socketio）

　　這裏用python的後端來講明。python有socketio這個模塊，不過和前端時同樣，直接從較爲底層的開始編寫比較僵硬。各種web框架應該都對websocket有了較好的支持，這裏選用了flask這個框架的flask-socketio的擴展。

　　flask-socketio的建立和運行方式以下：

from flask import Flask 
from flask_socketio import SocketIO,emit

app = Flask(__name__)

socketio = SocketIO()
socketio.init_app(app)

"""
對app進行一些路由設置
"""

"""
對socketio進行一些監聽設置
"""

if __name__ == '__main__':
    socketio.run(app,debug=True,host='0.0.0.0',port=5000)
    #這裏就再也不用app.run而用socketio.run了。socketio.run的參數和app.run也都差很少

 

　　上面的，對app的路由設置就再也不說了，想說的是對socketio的監聽設置，這纔是真正關係到先後端websocket通訊過程的。結合前面的前端代碼，socketio的監聽設置能夠這樣作：

@socketio.on('request_for_response',namespace='/testnamespace')
def give_response(data):
    value = data.get('param')

    #進行一些對value的處理或者其餘操做,在此期間能夠隨時會調用emit方法向前臺發送消息
    emit('response',{'code':'200','msg':'start to process...'})

    time.sleep(5)
    emit('response',{'code':'200','msg':'processed'})

 

　　socketio也用了和app.route相似的裝飾器的形式進行監聽設置。主要參數中有namespace這一項，也就是這項指定了這個監聽的範圍。在前端，只有註冊在testnamespace上的socket，emit向request_for_response的消息纔會被這個函數接受並處理。處理函數自帶一個參數用來接收前端emit來消息中的那個object，在處理函數中能夠對其解析處理。隨後後端向前端發送了start to process的消息。也使用了emit這個方法，而後指明瞭監聽是response。也就是說前端on在response上的監聽處理函數會處理這個消息（固然仍是在testnamespace的框架內）。發出消息後後端不會被阻塞而是繼續向下執行，在處理了5秒鐘以後發出告終束處理的消息，前端天然隔了五秒以後就獲得了這個消息了。
　　socket監聽響應函數自己不須要返回什麼值，只須要在處理過程當中適當的位置emit出消息便可。

 

　　網上其餘一些教程中會提到send方法來取代emit方法的位置（不管是前端仍是後端），其實send方法就是把上文中的'request_for_response','response'這兩個標識都默認成'message'。如此在寫的時候就不用寫事件名，直接寫要傳遞的參數便可。反過來看，用emit方法其實是作了一個自定義事件的工做，能夠說更加靈活多變一點。

　　●  略大項目中Manager的支持

　　通常而言，上面那樣的socketio.run總給人感受是個玩具項目。若是要作一個大型的項目那確定得用一些更加高端的啓動方式才行，另外配置也應該有獨立的config.py，經過app.config.form_object的方法來填充配置。

　　可是通過個人實驗，雖然用manager.run可讓socketio工做，可是彷佛會存在相似於緩存同樣的一種機制。也就是說後臺emit出來的信息並不直接發送到前端，而是在整個響應函數執行結束以後一古腦兒的爆出來。不知道是後端發送時進行了緩存仍是前端接收時進行了緩存。

　　因此若是要用websocket的話儘可能仍是用socketio.run這種方法啓動把。至於配置能夠在socketio.run中添加相似於debug=current_app.config['DEBUG'],host=current_app.config['HOST']這樣的方法。