WebSocket 簡介
當(dāng)前位置:點(diǎn)晴教程→知識管理交流
→『 技術(shù)文檔交流 』
你可以把 WebSocket 看成是 HTTP 協(xié)議為了支持長連接所打的一個大補(bǔ)丁,它和 HTTP 有一些共性,是為了解決 HTTP 本身無法解決的某些問題而做出的一個改良設(shè)計。在以前 HTTP 協(xié)議中所謂的 keep-alive connection 是指在一次 TCP 連接中完成多個 HTTP 請求,但是對每個請求仍然要單獨(dú)發(fā) header;所謂的 polling 是指從客戶端(一般就是瀏覽器)不斷主動的向服務(wù)器發(fā) HTTP 請求查詢是否有新數(shù)據(jù)。這兩種模式有一個共同的缺點(diǎn),就是除了真正的數(shù)據(jù)部分外,服務(wù)器和客戶端還要大量交換 HTTP header,信息交換效率很低。它們建立的“長連接”都是偽.長連接,只不過好處是不需要對現(xiàn)有的 HTTP server 和瀏覽器架構(gòu)做修改就能實(shí)現(xiàn)。
WebSocket 解決的第一個問題是,通過第一個 HTTP request 建立了 TCP 連接之后,之后的交換數(shù)據(jù)都不需要再發(fā) HTTP request了,使得這個長連接變成了一個真.長連接。但是不需要發(fā)送 HTTP header就能交換數(shù)據(jù)顯然和原有的 HTTP 協(xié)議是有區(qū)別的,所以它需要對服務(wù)器和客戶端都進(jìn)行升級才能實(shí)現(xiàn)。在此基礎(chǔ)上 WebSocket 還是一個雙通道的連接,在同一個 TCP 連接上既可以發(fā)也可以收信息。此外還有 multiplexing 功能,幾個不同的 URI 可以復(fù)用同一個 WebSocket 連接。這些都是原來的 HTTP 不能做到的。 另外說一點(diǎn)技術(shù)細(xì)節(jié),因?yàn)榭吹接腥颂釂?WebSocket 可能進(jìn)入某種半死不活的狀態(tài)。這實(shí)際上也是原有網(wǎng)絡(luò)世界的一些缺陷性設(shè)計。上面所說的 WebSocket 真.長連接雖然解決了服務(wù)器和客戶端兩邊的問題,但坑爹的是網(wǎng)絡(luò)應(yīng)用除了服務(wù)器和客戶端之外,另一個巨大的存在是中間的網(wǎng)絡(luò)鏈路。一個 HTTP/WebSocket 連接往往要經(jīng)過無數(shù)的路由,防火墻。你以為你的數(shù)據(jù)是在一個“連接”中發(fā)送的,實(shí)際上它要跨越千山萬水,經(jīng)過無數(shù)次轉(zhuǎn)發(fā),過濾,才能最終抵達(dá)終點(diǎn)。在這過程中,中間節(jié)點(diǎn)的處理方法很可能會讓你意想不到。 比如說,這些坑爹的中間節(jié)點(diǎn)可能會認(rèn)為一份連接在一段時間內(nèi)沒有數(shù)據(jù)發(fā)送就等于失效,它們會自作主張的切斷這些連接。在這種情況下,不論服務(wù)器還是客戶端都不會收到任何提示,它們只會一廂情愿的以為彼此間的紅線還在,徒勞地一邊又一邊地發(fā)送抵達(dá)不了彼岸的信息。而計算機(jī)網(wǎng)絡(luò)協(xié)議棧的實(shí)現(xiàn)中又會有一層套一層的緩存,除非填滿這些緩存,你的程序根本不會發(fā)現(xiàn)任何錯誤。這樣,本來一個美好的 WebSocket 長連接,就可能在毫不知情的情況下進(jìn)入了半死不活狀態(tài)。 而解決方案,WebSocket 的設(shè)計者們也早已想過。就是讓服務(wù)器和客戶端能夠發(fā)送 Ping/Pong Frame(RFC 6455 - The WebSocket Protocol)。這種 Frame 是一種特殊的數(shù)據(jù)包,它只包含一些元數(shù)據(jù)而不需要真正的 Data Payload,可以在不影響 Application 的情況下維持住中間網(wǎng)絡(luò)的連接狀態(tài)。 該文章在 2015/7/10 18:05:29 編輯過 |
關(guān)鍵字查詢
相關(guān)文章
正在查詢... |