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