推技術

一 輪詢：

polling：client按設置好的時間間隔主動訪問server，有可能server返回有用數據，有可能server無有用數據返回，但都是一個創建鏈接－request－response－關閉鏈接的過程。

二 web的推：

1 comet

1）long polling

client訪問server，若server有數據返回，則返回，關閉鏈接，client繼續發請求；若server沒有數據返回，鏈接保持，等待直到server有數據返回，關閉鏈接，client繼續發請求。創建鏈接－request－（wait）－response－關閉鏈接。

2） Iframe

iframe 是很早就存在的一種 HTML 標記， 經過在 HTML 頁面裏嵌入一個隱蔵幀，而後將這個隱蔵幀的 SRC 屬性設爲對一個長鏈接的請求，服務器端就能源源不斷地往客戶端輸入數據

2 websocket

websocket是一種協議，本質上和http，tcp同樣。協議是用來講明數據是如何傳輸的。它的url前綴是ws:// 或者wss://，後者是加密的websocket。它的url諸如這樣：ws://10.16.15.64:3201/

客戶端和服務端進行websocket交互的方式也有人理解爲「HTTP握手+TCP數據傳輸」的方式。

HTTP握手+TCP數據傳輸

握手和傳輸的整個流程是這樣的：

瀏覽器（支持Websocket的瀏覽器）像HTTP同樣，發起一個請求，而後等待服務端的響應

服務器返回握手響應，告訴瀏覽器請將後續的數據按照websocket制定的數據格式傳過來

瀏覽器和服務器的socket鏈接不中斷，此時這個鏈接和http不一樣的是它是雙工的了

瀏覽器和服務器有任何須要傳遞的數據的時候使用這個長鏈接進行數據傳遞

這裏說它是HTTP握手，是由於瀏覽器和服務器在創建長鏈接的握手過程是按照HTTP1.1的協議發送的，有Request，Request Header， Response， Response Header。可是不一樣的是Header裏面的字段是有特定含義的。

說它是TCP傳輸，主要體如今創建長鏈接後，瀏覽器是能夠給服務器發送數據，服務器也能夠給瀏覽器發送請求的。固然它的數據格式並非本身定義的，是在要傳輸的數據外層有ws協議規定的外層包的。

握手過程

這是一個握手過程的例子。

Upgrade頭表示的意思是「客戶端除了http以外也支持websocket協議，並且更傾向使用websocket，服務端若是支持的話，我們就換websocket協議吧」

sec-websocket-version：是指出瀏覽器支持的websocket號。這裏是支持hybi-13。這裏是不會出現9-12的版本號的。websocket協議規定9-12是保留字段。

sec-websocket-key：算是一種驗證返回回來的服務端是不是支持websocket的驗證算法。與Response中的sec-websocket-accept是對應的。

sec-websocket-accept與sec-websocket-key的對應算法是：

sec-websocket-accept = base64(hsa1(sec-websocket-key + 258EAFA5-E914-47DA-95CA-C5AB0DC85B11))

若是返回的sec-websocket-accept不對，在chrome下會出現Sec-WebSocket-Accept dismatch的錯誤。

Response返回的HTTP Staus是101，表明服務端說「咱們雙方後面就按照websocket協議來進行數據傳輸吧」

小程序裏對ws的支持好於h5。

ws的實現：

1）javax＋tomcat（7.0.47+）

2）spring