Tornado 4.3文檔翻譯: web框架-websocket瀏覽器與服務器雙向通訊

譯者說

Tornado 4.3於2015年11月6日發佈,該版本正式支持Python3.5async/await關鍵字,而且用舊版本CPython編譯Tornado一樣可使用這兩個關鍵字,這無疑是一種進步。其次,這是最後一個支持Python2.6Python3.2的版本了,在後續的版本了會移除對它們的兼容。如今網絡上尚未Tornado4.3的中文文檔,因此爲了讓更多的朋友能接觸並學習到它,我開始了這個翻譯項目,但願感興趣的小夥伴能夠一塊兒參與翻譯,項目地址是tornado-zh on Github,翻譯好的文檔在Read the Docs上直接能夠看到。歡迎Issues or PR。本節感謝@thisisx7翻譯javascript

PS:本節最好直接在https://tornado-zh.readthedocs.org或者http://tornado.moelove.info/閱讀,以得到更好的閱讀體驗(格式支持)。原諒我沒排好版QAQ

tornado.websocket — 瀏覽器與服務器雙向通訊

WebSocket 協議的實現html

WebSockets 容許瀏覽器和服務器之間進行 雙向通訊html5

全部主流瀏覽器的現代版本都支持WebSockets(支持狀況詳見:http://caniuse.com/websockets)java

該模塊依照最新 WebSocket 協議 RFC 6455 實現.node

在 4.0 版更改: Removed support for the draft 76 protocol version.git

class tornado.websocket.WebSocketHandler(application, request, **kwargs)

經過繼承該類來建立一個基本的 WebSocket handler.github

重寫 on_message 來處理收到的消息, 使用 write_message 來發送消息到客戶端. 你也能夠重寫 open 和 on_close 來處理鏈接打開和關閉這兩個動做.web

有關JavaScript 接口的詳細信息: http://dev.w3.org/html5/websockets/ 具體的協議: http://tools.ietf.org/html/rfc6455正則表達式

一個簡單的 WebSocket handler 的實例: 服務端直接返回全部收到的消息給客戶端算法

class EchoWebSocket(tornado.websocket.WebSocketHandler):
    def open(self):
        print("WebSocket opened")

    def on_message(self, message):
        self.write_message(u"You said: " + message)

    def on_close(self):
        print("WebSocket closed")

WebSockets 並非標準的 HTTP 鏈接. 「握手」動做符合 HTTP 標準,可是在」握手」動做以後, 協議是基於消息的. 所以,Tornado 裏大多數的 HTTP 工具對於這類 handler 都是不可用的. 用來通信的方法只有 write_message() , ping() , 和 close() . 一樣的,你的 request handler 類裏應該使用 open() 而不是 get() 或者 post()

若是你在應用中將這個 handler 分配到 /websocket, 你能夠經過以下代碼實現:

var ws = new WebSocket("ws://localhost:8888/websocket");
ws.onopen = function() {
   ws.send("Hello, world");
};
ws.onmessage = function (evt) {
   alert(evt.data);
};

這個腳本將會彈出一個提示框 :」You said: Hello, world」

瀏覽器並無遵循同源策略(same-origin policy),相應的容許了任意站點使用 javascript 發起任意 WebSocket 鏈接來支配其餘網絡.這使人驚訝,而且是一個潛在的安全漏洞,因此 從 Tornado 4.0 開始 WebSocketHandler 須要對但願接受跨域請求的應用經過重寫.

check_origin (詳細信息請查看文檔中有關該方法的部分)來進行設置. 沒有正確配置這個屬性,在創建 WebSocket 鏈接時候極可能會致使 403 錯誤.

當使用安全的 websocket 鏈接(wss://) 時, 來自瀏覽器的鏈接可能會失敗,由於 websocket 沒有地方輸出 「認證成功」 的對話. 你在 websocket 鏈接創建成功以前,必須 使用相同的證書訪問一個常規的 HTML 頁面.

Event handlers

WebSocketHandler.open(args, *kwargs)

當打開一個新的 WebSocket 時調用

open 的參數是從 tornado.web.URLSpec 經過正則表達式獲取的, 就像獲取 tornado.web.RequestHandler.get 的參數同樣

WebSocketHandler.on_message(message)

處理在 WebSocket 中收到的消息

這個方法必須被重寫

WebSocketHandler.on_close()

當關閉該 WebSocket 時調用

當鏈接被完全關閉而且支持 status code 或 reason phtase 的時候, 能夠經過 self.close_code 和 self.close_reason 這兩個屬性來獲取它們

在 4.0 版更改: Added close_code and close_reason attributes. 添加 close_code 和 close_reason 這兩個屬性

WebSocketHandler.select_subprotocol(subprotocols)

當一個新的 WebSocket 請求特定子協議(subprotocols)時調用

subprotocols 是一個由一系列可以被客戶端正確識別出相應的子協議 (subprotocols)的字符串構成的 list . 這個方法可能會被重載,用來返回 list 中某 個匹配字符串, 沒有匹配到則返回 None. 若是沒有找到相應的子協議,雖然服務端並 不會自動關閉 WebSocket 鏈接,可是客戶端能夠選擇關閉鏈接.

Output

WebSocketHandler.write_message(message, binary=False)

將給出的 message 發送到客戶端

message 能夠是 string 或者 dict(將會被編碼成 json ) 若是 binary 爲 false, message 將會以 utf8 的編碼發送; 在 binary 模式下 message 能夠是 任何 byte string.

若是鏈接已經關閉, 則會觸發 WebSocketClosedError

在 3.2 版更改: 添加了 WebSocketClosedError (在以前版本會觸發 AttributeError)

在 4.3 版更改: 返回可以被用於 flow control 的 Future.

WebSocketHandler.close(code=None, reason=None)

關閉當前 WebSocket

一旦揮手動做成功,socket將會被關閉.

code 多是一個數字構成的狀態碼, 採用 RFC 6455 section 7.4.1. 定義的值.

reason 多是描述鏈接關閉的文本消息. 這個值被提給客戶端,可是不會被 WebSocket 協議單獨解釋.

在 4.0 版更改: Added the code and reason arguments.

Configuration

WebSocketHandler.check_origin(origin)

經過重寫這個方法來實現域的切換

參數 origin 的值來自 HTTP header 中的Origin,url 負責初始化這個請求. 這個方法並非要求客戶端不發送這樣的 heder;這樣的請求一直被容許(由於全部的瀏覽器 實現的 websockets 都支持這個 header ,而且非瀏覽器客戶端沒有一樣的跨域安全問題.

返回 True 表明接受,相應的返回 False 表明拒絕.默認拒絕除 host 外其餘域的請求.

這個是一個瀏覽器防止 XSS 攻擊的安全策略,由於 WebSocket 容許繞過一般的同源策略 以及不使用 CORS 頭.

要容許全部跨域通訊的話(這在 Tornado 4.0 以前是默認的),只要簡單的重寫這個方法 讓它一直返回 true 就能夠了:

def check_origin(self, origin):
    return True

要容許全部全部子域下的鏈接,能夠這樣實現:

def check_origin(self, origin):
    parsed_origin = urllib.parse.urlparse(origin)
    return parsed_origin.netloc.endswith(".mydomain.com")

4.0 新版功能.

WebSocketHandler.get_compression_options()

重寫該方法返回當前鏈接的 compression 選項

若是這個方法返回 None (默認), compression 將會被禁用. 若是它返回 dict (即便 是空的),compression 都會被開啓. dict 的內容將會被用來控制 compression 所 使用的內存和CPU.可是這類的設置如今尚未被實現.

4.1 新版功能.

WebSocketHandler.set_nodelay(value)

爲當前 stream 設置 no-delay

在默認狀況下, 小塊數據會被延遲和/或合併以減小發送包的數量. 這在有些時候會由於 Nagle’s 算法和 TCP ACKs 相互做用會形成 200-500ms 的延遲.在 WebSocket 鏈接 已經創建的狀況下,能夠經過設置 self.set_nodelay(True) 來下降延遲(這可能 會佔用更多帶寬)

更多詳細信息: BaseIOStream.set_nodelay.

在 BaseIOStream.set_nodelay 查看詳細信息.

3.1 新版功能.

Other

WebSocketHandler.ping(data)

發送 ping 包到遠端.

WebSocketHandler.on_pong(data)

當收到ping 包的響應時執行.

exception tornado.websocket.WebSocketClosedError

出現關閉鏈接錯誤觸發.

3.2 新版功能.

Client-side support

tornado.websocket.websocket_connect(url, io_loop=None, callback=None, connect_timeout=None, on_message_callback=None, compression_options=None)

客戶端 WebSocket 支持 須要指定 url, 返回一個結果爲 WebSocketClientConnection 的 Future 對象

compression_options 做爲 WebSocketHandler.get_compression_options 的 返回值, 將會以一樣的方式執行.

這個鏈接支持兩種類型的操做.在協程風格下,應用程序一般在一個循環裏調用~.WebSocket ClientConnection.read_message:

conn = yield websocket_connect(url)
while True:
    msg = yield conn.read_message()
    if msg is None: break
    # Do something with msg

在回調風格下,須要傳遞 on_message_callback 到 websocket_connect 裏. 在這兩種風格里,一個內容是 None 的 message 都標誌着 WebSocket 鏈接已經.

在 3.2 版更改: 容許使用 HTTPRequest 對象來代替 urls.

在 4.1 版更改: 添加 compression_options 和 on_message_callback .

不同意使用 compression_options .

class tornado.websocket.WebSocketClientConnection(io_loop, request, on_message_callback=None, compression_options=None)

WebSocket 客戶端鏈接

這個類不該當直接被實例化, 請使用 websocket_connect

close(code=None, reason=None)

關閉 websocket 鏈接

code 和 reason 的文檔在 WebSocketHandler.close 下已給出.

3.2 新版功能.

在 4.0 版更改: 添加 code 和 reason 這兩個參數

write_message(message, binary=False)

發送消息到 websocket 服務器.

read_message(callback=None)

讀取來自 WebSocket 服務器的消息.

若是在 WebSocket 初始化時指定了 on_message_callback ,那麼這個方法永遠不會返回消息

若是鏈接已經關閉,返回結果會是一個結果是 message 的 future 對象或者是 None. 若是 future 給出了回調參數, 這個參數將會在 future 完成時調用.

相關文章
相關標籤/搜索