[ 本文轉(zhuǎn)載自http://blog.csdn.net/yl02520/article/ ]
Browser已經(jīng)支持http協(xié)議辆布，為什么還要開發(fā)一種新的WebSocket協(xié)議呢嗜愈？我們知道http協(xié)議是一種單向的網(wǎng)絡(luò)協(xié)議联四，在建立連接后认罩，它只允許Browser/UA（UserAgent）向WebServer發(fā)出請(qǐng)求資源后翰守，WebServer才能返回相應(yīng)的數(shù)據(jù)薄翅。而WebServer不能主動(dòng)的推送數(shù)據(jù)給Browser/UA，當(dāng)初這么設(shè)計(jì)http協(xié)議也是有原因的剥纷，假設(shè)WebServer能主動(dòng)的推送數(shù)據(jù)給Browser/UA，那Browser/UA就太容易受到攻擊呢铆，一些廣告商也會(huì)主動(dòng)的把一些廣告信息在不經(jīng)意間強(qiáng)行的傳輸給客戶端晦鞋，這不能不說是一個(gè)災(zāi)難。那么單向的http協(xié)議給現(xiàn)在的網(wǎng)站或Web應(yīng)用程序開發(fā)帶來了哪些問題呢棺克？
讓我們來看一個(gè)案例悠垛，現(xiàn)在假設(shè)我們想開發(fā)一個(gè)基于Web的應(yīng)用程序去獲取當(dāng)前Web服務(wù)器的實(shí)時(shí)數(shù)據(jù)，例如股票的實(shí)時(shí)行情逆航，火車票的剩余票數(shù)等等鼎文，這就需要Browser/UA與WebServer端之間反復(fù)的進(jìn)行http通信，Browser不斷的發(fā)送Get請(qǐng)求因俐，去獲取當(dāng)前的實(shí)時(shí)數(shù)據(jù)拇惋。下面介紹幾種常見的方式：
Polling
這種方式就是通過Browser/UA定時(shí)的向Web服務(wù)器發(fā)送http的Get請(qǐng)求，服務(wù)器收到請(qǐng)求后抹剩，就把最新的數(shù)據(jù)發(fā)回給客戶端（Browser/UA）撑帖，Browser/UA得到數(shù)據(jù)后，就將其顯示出來澳眷，然后再定期的重復(fù)這一過程胡嘿。雖然這樣可以滿足需求，但是也仍然存在一些問題钳踊，例如在某段時(shí)間內(nèi)Web服務(wù)器端沒有更新的數(shù)據(jù)衷敌，但是Browser/UA仍然需要定時(shí)的發(fā)送Get請(qǐng)求過來詢問，那么Web服務(wù)器就把以前的老數(shù)據(jù)再傳送過來拓瞪，Browser/UA把這些沒有變化的數(shù)據(jù)再顯示出來缴罗，這樣顯然既浪費(fèi)了網(wǎng)絡(luò)帶寬，又浪費(fèi)了CPU的利用率祭埂。如果說把Browser發(fā)送Get請(qǐng)求的周期調(diào)大一些面氓，就可以緩解這一問題，但是如果在Web服務(wù)器端的數(shù)據(jù)更新很快時(shí)蛆橡，這樣又不能保證Web應(yīng)用程序獲取數(shù)據(jù)的實(shí)時(shí)性舌界。
上面介紹了Polling遇到的問題，現(xiàn)在介紹一下LongPolling泰演，它是對(duì)Polling的一種改進(jìn)呻拌。
2.Long Polling
Browser/UA發(fā)送Get請(qǐng)求到Web服務(wù)器，這時(shí)Web服務(wù)器可以做兩件事情睦焕，第一柏锄，如果服務(wù)器端有新的數(shù)據(jù)需要傳送酿箭，就立即把數(shù)據(jù)發(fā)回給Browser/UA，Browser/UA收到數(shù)據(jù)后趾娃，立即再發(fā)送Get請(qǐng)求給Web Server缭嫡；第二，如果服務(wù)器端沒有新的數(shù)據(jù)需要發(fā)送抬闷，這里與Polling方法不同的是妇蛀，服務(wù)器不是立即發(fā)送回應(yīng)給Browser/UA，而是把這個(gè)請(qǐng)求保持住笤成，等待有新的數(shù)據(jù)到來時(shí)评架，再來響應(yīng)這個(gè)請(qǐng)求；當(dāng)然了炕泳，如果服務(wù)器的數(shù)據(jù)長(zhǎng)期沒有更新纵诞，一段時(shí)間后，這個(gè)Get請(qǐng)求就會(huì)超時(shí)培遵，Browser/UA收到超時(shí)消息后浙芙，再立即發(fā)送一個(gè)新的Get請(qǐng)求給服務(wù)器。然后依次循環(huán)這個(gè)過程籽腕。
這種方式雖然在某種程度上減小了網(wǎng)絡(luò)帶寬和CPU利用率等問題嗡呼，但是仍然存在缺陷，例如假設(shè)服務(wù)器端的數(shù)據(jù)更新速率較快皇耗，服務(wù)器在傳送一個(gè)數(shù)據(jù)包給Browser后必須等待Browser的下一個(gè)Get請(qǐng)求到來南窗，才能傳遞第二個(gè)更新的數(shù)據(jù)包給Browser，那么這樣的話郎楼，Browser顯示實(shí)時(shí)數(shù)據(jù)最快的時(shí)間為2×RTT（往返時(shí)間）万伤，另外在網(wǎng)絡(luò)擁塞的情況下，這個(gè)應(yīng)該是不能讓用戶接受的呜袁。另外敌买，由于http數(shù)據(jù)包的頭部數(shù)據(jù)量往往很大（通常有400多個(gè)字節(jié)），但是真正被服務(wù)器需要的數(shù)據(jù)卻很少（有時(shí)只有10個(gè)字節(jié)左右）傅寡，這樣的數(shù)據(jù)包在網(wǎng)絡(luò)上周期性的傳輸放妈，難免對(duì)網(wǎng)絡(luò)帶寬是一種浪費(fèi)北救。
通過上面的分析可知荐操，要是在Browser能有一種新的網(wǎng)絡(luò)協(xié)議，能支持客戶端和服務(wù)器端的雙向通信珍策，而且協(xié)議的頭部又不那么龐大就好了托启。WebSocket就是肩負(fù)這樣一個(gè)使命登上舞臺(tái)的。
