1樓：馬克地圖
實際上，WebSocket 的出現，就是為了解決拆包，粘包的問題的。因為這些事情，本身就是應該由運用層去解決，而不是在TCP/IP層解決。
2樓：Whodsow
乙個Frame會被拆分成幾個資料報，或乙個資料報包含幾個Frame，乙個Frame的第乙個位元組在前乙個Frame的資料報最後，這些和WebSocket的協議沒關係，與瀏覽器沒關係，與伺服器也沒關係，TCP有，WebSocket就不能避免，也沒法避免，因為WebSocket是基於TCP的協議。
同乙個Message被拆分成幾個Frame來傳送的瀏覽器都是良心瀏覽器啊，都是幾M的Frame，伺服器快取受不了啊。
伺服器端把乙個Message分成多少個Frame你都不要管它，因為瀏覽器會自動處理成乙個個的message給你，那個事件介面是onmessage，不是onframe。
3樓：
測試的chrome瀏覽器，短字串，自動分包，連續發，包不會粘到一起。
對了服務端使用的是 golang，理論上，和伺服器以及客戶端實現都有關係。
在要求不嚴的場合（資料不大，不會長時間連續傳送），姑且認為是不用處理分包粘包的吧。
4樓：
經過一段時間的調研，題主來自問自答了。。
RFC規範指出，WebSocket是乙個message-based的協議，它可以自動將資料分片，並且自動將分片的資料組裝。
也就是說，WebSocket的RFC標準是不會產生粘包、半包問題的。無需應用層開發人員關心快取以及手工組裝message。
然而理想與現實的不一致：RFC規範與實現的不一致，現實當中有幾個問題：
1. 每個message可以是乙個或多個分片。message不記錄長度，分片才記錄長度。
2. message最大的長度可以達到 9,223,372,036,854,775,807 位元組，是由於Payload的資料長度有63bit的限制。
3. 很多WebSocket的實現其實並不按照標準的RFC實現完全，很多僅僅實現了50%就拿來用了。
這就導致了，在WebSocket實現上的最大長度很難達到這個大小，於是，很多API的實現上是會有限制的，可能會限制你的傳送的長度，也可能會把過長的資料直接以流式傳送。
結論
WebSocket的RFC標準是不會產生粘包、半包問題的，但是由於現實世界的WebSocket的實現者不同程度的偷懶，不同程度的會有這個問題，特別是當你的資料message特別大的時候（到底是多大是特別大，由具體實現決定）。
盡可能的選擇乙個符合自己專案的WebSocket實現，或者自己造乙個滿足需要的輪子。
也或者，把WebSocket看做乙個有特別大的長度限制「流」協議，然後自己處理buffering的問題。
參考文獻
WebSocket 相比普通的 TCP 長連線有什麼優勢？
WebSocket 是應用層協議，tcp 是傳輸層協議。websocket 本身是基於 tcp 實現的。tcp 本身無所謂長短連線，理想狀態下只要不 close，tcp 連線就一直存在 注意是理想 所謂的長連線本身是一條虛擬鏈路。所以這個問題沒法回答。 A yon 首先需要指出這個 WebSocke...
TCP協議關閉時為什麼需要TIME WAIT
l7dpi 1.協議沒有按你說的那有設計，如果按你這個思路設計，會有什麼弊端？前者在一定時間內time wait後進入close狀態，會話結束，後者會話結束時間不確定。2.本地埠會重複使用，如果有舊會話報文，收到亂序序列號，可能以為包丟了，會觸發快速重傳機制，造成一定干擾。 胡俊飛 如果是主機對主機...
為什麼UDP需要有長度字段，而TCP不需要長度欄位呢？
whoami TCP頭部大小是可變的，到TCP頭部有4bit用來表示資料偏移 單位是4位元組 其實也就是頭部的大小，這樣上層協議就知道TCP資料部分的開始位置，知道怎麼去重整資料。UDP頭部確實是多餘的，他是固定的八字節，很明顯8位元組後面的就是UDP資料部分，這樣上層應用就可以得到這些資料，後續由...