關(guān)于websocket和HTTP有很多博客和討論，許多開(kāi)發(fā)人員和網(wǎng)站都強(qiáng)烈支持websockets，但我仍然無(wú)法理解為什么。例如（websocket愛(ài)好者的參數(shù)）：HTML5 Web套接字代表了Web通信的下一個(gè)發(fā)展 - 一種全雙工雙向通信通道，通過(guò)Web上的單個(gè)套接字進(jìn)行操作。（http://www.websocket.org/quantum.html）HTTP支持流媒體：請(qǐng)求正文流（您在上傳大文件時(shí)使用它）和響應(yīng)正文流。在與WebSocket連接期間，客戶端和服務(wù)器每幀交換2個(gè)字節(jié)的數(shù)據(jù)，而連續(xù)輪詢時(shí)則為8千字節(jié)的http頭。為什么這2個(gè)字節(jié)不包括tcp和tcp協(xié)議開(kāi)銷？GET /about.html HTTP/1.1Host: example.org這是~48字節(jié)的http標(biāo)頭。http chunked編碼 - http://ru.wikipedia.org/wiki/Chunked_transfer_encoding：23This is the data in the first chunk1Aand this is the second one3con8sequence0因此，每個(gè)塊的開(kāi)銷并不大。這兩個(gè)協(xié)議都可以在TCP上運(yùn)行，因此所有與長(zhǎng)期連接的TCP問(wèn)題仍然存在。題：為什么websockets協(xié)議更好？為什么要實(shí)現(xiàn)而不是更新http協(xié)議？
3 回答
鴻蒙傳說(shuō)
TA貢獻(xiàn)1865條經(jīng)驗(yàn) 獲得超7個(gè)贊
您似乎假設(shè)WebSocket是HTTP的替代品。它不是。這是一個(gè)擴(kuò)展。
WebSockets的主要用例是Javascript應(yīng)用程序，它們?cè)赪eb瀏覽器中運(yùn)行并從服務(wù)器接收實(shí)時(shí)數(shù)據(jù)。游戲就是一個(gè)很好的例子。
在WebSockets之前，Javascript應(yīng)用程序與服務(wù)器交互的唯一方法是通過(guò)XmlHttpRequest。但這些都有一個(gè)主要的缺點(diǎn)：服務(wù)器無(wú)法發(fā)送數(shù)據(jù)，除非客戶端已明確請(qǐng)求它。
但新的WebSocket功能允許服務(wù)器隨時(shí)發(fā)送數(shù)據(jù)。這允許實(shí)現(xiàn)具有低得多的延遲的基于瀏覽器的游戲，而不必使用諸如AJAX長(zhǎng)輪詢或?yàn)g覽器插件之類的丑陋黑客。
那么為什么不使用普通的HTTP與流式請(qǐng)求和響應(yīng)
在對(duì)另一個(gè)答案的評(píng)論中，您建議只是異步地流式傳輸客戶端請(qǐng)求和響應(yīng)正文。
實(shí)際上，WebSockets基本上就是這樣。嘗試從客戶端打開(kāi)WebSocket連接首先看起來(lái)像HTTP請(qǐng)求，但標(biāo)題中的特殊指令（Upgrade：websocket）告訴服務(wù)器開(kāi)始以此異步模式進(jìn)行通信。WebSocket協(xié)議的初稿并不僅僅是那些以及確保服務(wù)器實(shí)際理解客戶端想要異步通信的一些握手。但后來(lái)人們意識(shí)到代理服務(wù)器會(huì)被它混淆，因?yàn)樗鼈兞?xí)慣于HTTP的通常請(qǐng)求/響應(yīng)模型。一個(gè)潛在的攻擊場(chǎng)景中對(duì)代理服務(wù)器被發(fā)現(xiàn)。為了防止這種情況，有必要使WebSocket流量看起來(lái)不像任何普通的HTTP流量。這就是為什么要引入屏蔽鍵的原因協(xié)議的最終版本。
添加回答
舉報(bào)
0/150
提交
取消