能主動(dòng)的推送數(shù)據(jù)給客戶端。
[0049]若客戶端需要獲取服務(wù)器的實(shí)時(shí)數(shù)據(jù)，就需要客戶端與服務(wù)器之間反復(fù)進(jìn)行HTTP通信。即，客戶端不斷發(fā)送資源請(qǐng)求，以實(shí)現(xiàn)服務(wù)器向客戶端實(shí)時(shí)地進(jìn)行消息推送。常用的消息推送方法如下:
[0050]輪詢(Polling):
[0051]輪詢方式的過(guò)程為:客戶端定時(shí)地向服務(wù)器發(fā)送資源請(qǐng)求；服務(wù)器接收到資源請(qǐng)求后，把待推送的數(shù)據(jù)推送給客戶端；客戶端接收該待推送的數(shù)據(jù)。定期重復(fù)上述過(guò)程。
[0052]雖然輪詢的方式實(shí)現(xiàn)了客戶端與服務(wù)器之間的實(shí)時(shí)通訊，但是當(dāng)服務(wù)器中沒(méi)有待推送的數(shù)據(jù)推送給客戶端時(shí)，該輪詢的過(guò)程仍然進(jìn)行，服務(wù)器會(huì)把推送過(guò)的數(shù)據(jù)再次進(jìn)行推送，既浪費(fèi)網(wǎng)絡(luò)帶寬，又浪費(fèi)了服務(wù)器中CPU的利用率。
[0053]請(qǐng)參考圖1，其示出了本發(fā)明一個(gè)實(shí)施例提供的消息推送方法的流程圖，本實(shí)施例以該消息推送方法應(yīng)用于服務(wù)器中來(lái)舉例說(shuō)明。該消息推送方法可以包括但不限于以下步驟:
[0054]步驟101，檢測(cè)客戶端是否兼容Websocket協(xié)議。
[0055]步驟102，若客戶端兼容Websocket協(xié)議，則基于Websocket協(xié)議進(jìn)行消息推送。
[0056]步驟103，若客戶端不兼容Websocket協(xié)議，則基于長(zhǎng)輪詢方式進(jìn)行消息推送。
[0057]綜上所述，本發(fā)明實(shí)施例提供的消息推送方法，通過(guò)檢測(cè)客戶端是否兼容Websocket協(xié)議；若客戶端兼容Websocket協(xié)議，則基于Websocket協(xié)議進(jìn)行消息推送；若客戶端不兼容Websocket協(xié)議，則基于長(zhǎng)輪詢方式進(jìn)行消息推送，使得客戶端不必頻繁地向服務(wù)器發(fā)出資源請(qǐng)求，就可以保持客戶端和服務(wù)器之間的同步，解決了當(dāng)服務(wù)器基于輪詢方式進(jìn)行消息推送時(shí)，占用大量服務(wù)器資源的問(wèn)題，達(dá)到了根據(jù)客戶端的實(shí)際情況選擇使用更為合理的消息推送方式，降低服務(wù)器端CPU的利用率的效果。
[0058]可選的，基于Websocket協(xié)議進(jìn)行消息推送時(shí)，網(wǎng)絡(luò)連接的建立至少需要一對(duì)網(wǎng)絡(luò)套接字，其中一個(gè)運(yùn)行于客戶端，稱為WS Client (Websocket Client，網(wǎng)絡(luò)套接字客戶端)，另一個(gè)運(yùn)行于服務(wù)器端，稱為WS Server (Websocket Server，網(wǎng)絡(luò)套接字服務(wù)器)。
[0059]基于Websocket協(xié)議進(jìn)行消息推送時(shí)，除了要進(jìn)行基于TCP協(xié)議的握手過(guò)程之外，還要進(jìn)行WS Client與WS Server之間的握手過(guò)程。
[0060]請(qǐng)參考圖2，其示出了本發(fā)明一個(gè)實(shí)施例提供的基于Websocket協(xié)議進(jìn)行消息推送時(shí)網(wǎng)絡(luò)連接建立過(guò)程的交互圖，其中，客戶端中包括基于Websocket協(xié)議的WS Client和基于TCP協(xié)議的TCP Client ;服務(wù)器端中包括基于Websocket協(xié)議的Websocket Server和基于TCP協(xié)議的TCP Server ο該基于Websocket協(xié)議進(jìn)行消息推送的網(wǎng)絡(luò)連接建立步驟如下:
[0061]1)WS Client向TCP Client發(fā)送網(wǎng)絡(luò)連接請(qǐng)求；
[0062]2)第一次握手:TCP Client收到該網(wǎng)絡(luò)連接請(qǐng)求后，將SYN(synchronous，同步信號(hào))包發(fā)送給TCP Server,并進(jìn)入SYN_SEND狀態(tài)，等待TCP Server確認(rèn)；
[0063]3)第二次握手:TCP Server接收到SYN包后，將SYN包和ACK包(Acknowledgement，確認(rèn)字符)返回給 TCP Client，此時(shí) TCP Server 進(jìn)入 SYN_RECV 狀態(tài)；
[0064]4)第三次握手:若TCP Client成功接收到該SYN和ACK包，則TCP Client將ACK確認(rèn)包發(fā)送給TCP Server ；
[0065]ACK確認(rèn)包發(fā)送完畢，TCP Client和TCP Server進(jìn)入ESTABLISHED狀態(tài)，完成三次握手。
[0066]如果基于TCP協(xié)議的網(wǎng)絡(luò)連接過(guò)程成功，那么客戶端與服務(wù)器之間的網(wǎng)絡(luò)連接建立。
[0067]如果基于TCP協(xié)議的網(wǎng)絡(luò)連接過(guò)程失敗，那么后面的過(guò)程就不會(huì)執(zhí)行，客戶端會(huì)收到錯(cuò)誤消息的通知。
[0068]以下為客戶端和服務(wù)器基于TCP協(xié)議成功建立連接后，WS Client與WS Server之間的握手過(guò)程:
[0069]5)ffS Client通過(guò)HTTP協(xié)議向WS Server發(fā)送連接請(qǐng)求，該連接請(qǐng)求中包含WSServer中WebSocket協(xié)議的字版本號(hào)，原始地址，主機(jī)地址等；
[0070]本次連接請(qǐng)求，用于服務(wù)器端判斷消息推送方法是基于WebSocket協(xié)議還是基于HTTP協(xié)議。
[0071]6)ffS Server收到WS Client發(fā)來(lái)的連接請(qǐng)求后，若檢測(cè)到數(shù)據(jù)包數(shù)據(jù)和格式正確、客戶端和服務(wù)器端的協(xié)議版本號(hào)匹配，則WS Server接收本次連接請(qǐng)求，并將相應(yīng)的數(shù)據(jù)包回復(fù)給WS Client ；
[0072]其中，回復(fù)的數(shù)據(jù)包也是采用HTTP協(xié)議傳輸。
[0073]7)ffS Client接收到WS Server回復(fù)的數(shù)據(jù)包后，如果數(shù)據(jù)包的內(nèi)容和格式都正確，表示本次握手成功。
[0074]此后，服務(wù)器就可以基于WebSocket協(xié)議向客戶端實(shí)時(shí)地進(jìn)行消息推送。
[0075]可選的，基于長(zhǎng)輪詢方式進(jìn)行消息推送的過(guò)程為:
[0076]1)基于TCP協(xié)議進(jìn)行握手過(guò)程，建立客戶端與服務(wù)器之間的網(wǎng)絡(luò)連接；
[0077]具體的，該握手過(guò)程與上述基于Websocket協(xié)議進(jìn)行消息推送時(shí)，基于TCP協(xié)議進(jìn)行的握手過(guò)程一致，此處不再贅述。
[0078]2)客戶端向服務(wù)器發(fā)送資源請(qǐng)求；
[0079]3)服務(wù)器中如果存在待推送數(shù)據(jù)，就把該數(shù)據(jù)推送給客戶端，客戶端收到該數(shù)據(jù)后，斷開(kāi)本次網(wǎng)絡(luò)連接，并再次向服務(wù)器發(fā)送網(wǎng)絡(luò)連接請(qǐng)求；
[0080]4)如果服務(wù)器不存在待推送數(shù)據(jù)，服務(wù)器保持連接，直到服務(wù)器接收到新的待推送數(shù)據(jù)時(shí)，再將該新的待推送數(shù)據(jù)發(fā)送給客戶端；
[0081]5)如果服務(wù)器中的待推送數(shù)據(jù)長(zhǎng)時(shí)間沒(méi)有更新，客戶端與服務(wù)器端的網(wǎng)絡(luò)連接就會(huì)超時(shí)，網(wǎng)絡(luò)連接斷開(kāi)，則客戶端再次向服務(wù)器發(fā)送網(wǎng)絡(luò)連接請(qǐng)求。也即，步驟1中建立網(wǎng)絡(luò)連接時(shí)的網(wǎng)絡(luò)連接請(qǐng)求。
[0082]循環(huán)上述過(guò)程。
[0083]請(qǐng)參考圖3，其示出了本發(fā)明一個(gè)實(shí)施例提供的消息推送方法的流程圖，本實(shí)施例以該消息推送方法應(yīng)用于服務(wù)器中來(lái)舉例說(shuō)明，該消息推送方法可以包括但不限于以下步驟:
[0084]步驟301，檢測(cè)客戶端是否兼容Websocket協(xié)議。
[0085]由于Websocket協(xié)議是一種新型協(xié)議，并非所有客戶端都兼容Websocket協(xié)議。因此，在客戶端與服務(wù)器之間建立網(wǎng)絡(luò)連接后，若客戶端向服務(wù)器發(fā)送了資源請(qǐng)求，服務(wù)器接收到該資源請(qǐng)求后，需要對(duì)該客戶端是否兼容Websocket協(xié)議進(jìn)行檢測(cè)。
[0086]服務(wù)器檢測(cè)客戶端是否兼容Websocket協(xié)議的方法為:通過(guò)預(yù)定函數(shù)檢測(cè)客戶端是否兼容Websocket協(xié)議。
[0087]其中，預(yù)定函數(shù)是Websocket協(xié)議所提供的函數(shù)。
[0088]在Websocket協(xié)議中，包含一個(gè)預(yù)定函數(shù)，該預(yù)定函數(shù)用于檢測(cè)當(dāng)前發(fā)出資源請(qǐng)求的客戶端，是否兼容Websocket協(xié)議。
[0089]在客戶端與服務(wù)器之間的網(wǎng)絡(luò)連接建立后，客戶端向服務(wù)器發(fā)送的資源請(qǐng)求中包含一個(gè)頭信息，若服務(wù)器通過(guò)預(yù)設(shè)函數(shù)檢測(cè)到該頭信息中包含預(yù)定字段，則服務(wù)器判斷為當(dāng)前客戶端兼容Websocket協(xié)議。此后，服務(wù)器基于Websocket協(xié)議向客戶端進(jìn)行消息推送，執(zhí)行步驟302。
[0090]若服務(wù)器在頭文件中沒(méi)有檢測(cè)到該預(yù)定字段，則服務(wù)器判斷為當(dāng)前客戶端不兼容Websocket協(xié)議。由于所有類型的瀏覽器都對(duì)HTTP協(xié)議兼容，而長(zhǎng)輪詢方式是服務(wù)器基于HTTP協(xié)議向客戶端推送消息，且相對(duì)于傳統(tǒng)的輪詢方式占用的服務(wù)器資源較少，因此，服務(wù)器基于長(zhǎng)輪詢方式進(jìn)行消息推送，來(lái)保證客戶端的瀏覽功能正常使用，執(zhí)行步驟304。
[0091]步驟302，基于Websocket協(xié)議向客戶端進(jìn)行消息推送。
[0092]步驟303，檢測(cè)與客戶端之間的網(wǎng)絡(luò)連接在預(yù)設(shè)時(shí)間內(nèi)的中斷次數(shù)是否超過(guò)預(yù)設(shè)閾值。
[0093]服務(wù)器每隔預(yù)定時(shí)間間隔，檢測(cè)與客戶端之間的網(wǎng)絡(luò)連接在預(yù)設(shè)時(shí)間內(nèi)的終端次數(shù)是否超過(guò)預(yù)設(shè)閾值。
[0094]若服務(wù)器在每