在這點擊的零點幾秒的時間內(nèi)，Internet網(wǎng)上的控制報文是如下傳輸?shù)摹?/div>
①客戶手機連接到云服務(wù)器發(fā)出熱水器的控制指令
②云服務(wù)器把控制指令轉(zhuǎn)發(fā)給家中智能家居網(wǎng)關(guān)，控制熱水器開關(guān)
③熱水器響應(yīng)控制指令，將結(jié)果反饋給云服務(wù)器
④云服務(wù)器再將結(jié)果反饋給客戶APP，APP顯示設(shè)置成功
大家可能會問一個問題，為什么客戶APP不直接控制智能家居網(wǎng)關(guān)，而使用云服務(wù)器做中轉(zhuǎn)？
答案：智能家居設(shè)備是躲在家用路由器的后面，它的ip地址并不是公網(wǎng)地址，因此用戶手機是無法訪問到智能家居設(shè)備。同理，云服務(wù)器也無法訪問到智能家居設(shè)備。
因此智能家居設(shè)備需要主動向云服務(wù)器發(fā)起連接，并建立好連接。這樣客戶APP就可以就隨時登錄到云端，通過云端對智能家居進行控制。
我們拿在internet世界常用的HTTP協(xié)議來實現(xiàn)智能家居網(wǎng)關(guān)和云服務(wù)器的交互控制。HTTP協(xié)議非常簡單，客戶端發(fā)起一個request，服務(wù)器回一個response。
大家注意，服務(wù)器是不能主動發(fā)起請求的，這是因為HTTP協(xié)議必須是客戶端發(fā)起的。因此如果要控制智能家居設(shè)備，智能家居設(shè)備需要不停的向服務(wù)器發(fā)起詢問，查看云服務(wù)器是否對它下控制命令。
設(shè)備不停地對服務(wù)器請求會造成以下問題：
1、無論設(shè)備還是云服務(wù)器，CPU很忙，設(shè)備性能下降
2、占用帶寬，特別是云服務(wù)器的帶寬資源是比較昂貴的
好，我們現(xiàn)在請出WebSocket協(xié)議來替換HTTP協(xié)議的實現(xiàn)，設(shè)備和服務(wù)器的請求變成下面的對話：
這樣就明顯合理多了，因此WebSocket協(xié)議有如下幾個優(yōu)點：
1、更小的控制開銷。建立連接后，用于協(xié)議控制的數(shù)據(jù)包頭部相對較小，在不擴展的情況下，只有2-10個字節(jié)。相對于HTTP請求每次都要帶完整的頭部，開銷要小很多
2、更強的實時性，協(xié)議是雙工的。客戶端和服務(wù)器端都可以隨時發(fā)起請求。
正因為WebSocket有這些優(yōu)點，它當(dāng)前被大量使用在如下領(lǐng)域：
1、社交聊天，如果WebSocket早一些出來，QQ和微*聊天的協(xié)議估計就是它了
2、彈幕
3、多玩家游戲
4、協(xié)同編輯，比如Google Docs，允許多人在線同時編輯相同一篇文檔
5、股票基金報價
6、基于位置的應(yīng)用
7、智能家居
可以看出來，需要實時性的場景都會使用WebSocket。
WebSocket vs HTTP
下圖是WebSocket和HTTP協(xié)議層次模型：
為什么客戶不直接控制智能家居網(wǎng)關(guān)，而要使用云服務(wù)器做中轉(zhuǎn)？
從圖上可以看出，HTTP和WebSocket有一些交集，我們通過下面一個典型的WebSocket握手請求來展示：
客戶端請求
GET/webfin/websocket/ HTTP/1.1Host： localhostUpgrade： websocket
Connection:UpgradeSec-WebSocket-Key： xqBt3ImNzJbYqRINxEFlkg==Origin： http://服務(wù)器地址Sec-WebSocket-Version： 13
服務(wù)器回應(yīng)
HTTP/1.1101 Switching ProtocolsUpgrade： websocketConnecTIon： UpgradeSec-WebSocket-Accept： K7DJLdLooIwIG/MOpvWFB3y3FE8=
可以看出來，WebSocket建立連接是使用HTTP協(xié)議進行握手的，握手完成之后，WebSocket就和HTTP沒有關(guān)系了，真正的數(shù)據(jù)傳輸階段是不需要http協(xié)議參與的。
WebSocket和HTTP是獨立的協(xié)議，那么為什么WebSocket協(xié)議借用了HTTP的協(xié)議來建立連接而不是自建一套獨立的協(xié)議呢？
在前幾年的時候，在大多數(shù)公司里，IT為了讓大家安心工作，在公司的防火墻上把QQ的端口號封了，這樣既解決了大家可以正常上網(wǎng)，但不能上網(wǎng)QQ聊天。如果QQ改用WebSocket來實現(xiàn)，WebSocket使用和HTTP相同的80端口，IT就沒法限制了，除非把Web瀏覽也禁掉。因此WebSocket協(xié)議借用了HTTP的協(xié)議來建立連接，使用HTTP的端口號，可以繞過大多數(shù)防火墻的限制。有Web的地方，WebSocket就可以通行無阻。
瀏覽器的兼容性
由于WebSocket協(xié)議是在2011年終定稿，因此一些舊款的瀏覽器還無法支持WebSocket，比如IE10以前的版本。下面是實現(xiàn)了WebSocket的瀏覽器(終版本RFC6455)：
Web世界日新月異，但IE的對新技術(shù)的支持總要慢一拍，所以現(xiàn)在IE的份額也在逐年下降。來自Net Market Share 2016年7月份的統(tǒng)計，Google的Chrome瀏覽器(48.65%)已經(jīng)超越 IE(31.65%)的*。這里提醒，還在用IE老版本的朋友們，趕快升級吧。
WebSocket之前
大家可能會有疑問，2011年WebSocket才終定稿，那么之前如何實現(xiàn)像聊天室之類的實時應(yīng)用呢？答案是：使用tcp編程。所以像QQ這樣的聊天程序，騰訊需要自己開發(fā)私有的SDK來實現(xiàn)。如果今天開發(fā)QQ聊天程序，直接拿WebSocket來用就好了，瀏覽器、客戶端程序、服務(wù)器程序、各種編程語言都已經(jīng)開發(fā)了現(xiàn)成的WebSocket庫函數(shù)，可以直接調(diào)用。底層的通信協(xié)議和實現(xiàn)細節(jié)不用再考慮了。
HTTP和WebSocket的編程對應(yīng)于OSI七層協(xié)議中的第七層，而tcp編程在第三層。從編程角度來說，層次越高，編碼越簡單。原理類似于，程序員用c語言編程還是python編程一樣，python寫幾句話，c可能需要寫幾頁的程序。
總結(jié)：在web開發(fā)之前是沒有保持長鏈接的協(xié)議，WebSocket的誕生使其從無到有，全雙工、實時、高效，WebSocket迎合了實時通訊的需求。
