簡介面向需要在C# .NET Framework 2.0環(huán)境下實現(xiàn)WebSocket通信的開發(fā)者這份改寫自websocket-sharp的SDK包尤其適用。它著力解決舊框架下對接WSS安全服務(wù)的問題支持多種安全校驗方式既能搭建服務(wù)端WSS服務(wù)器也封裝了面向API服務(wù)器的客戶端適合嵌入式、工控或傳統(tǒng).NET項目中需要輕量實時通信的場景。壓縮包內(nèi)共103個文件以81個C#源碼文件為主另含5個DLL程序集、5個PDB調(diào)試符號以及工程配置、緩存和密鑰等輔助文件整體大小約1.51MB結(jié)構(gòu)清晰便于直接集成或二次修改。資源已有731人學(xué)習(xí)瀏覽對需要兼容.NET 2.0并自行擴(kuò)展WebSocket協(xié)議的開發(fā)者而言這份代碼提供了完整可運行工程骨架涵蓋會話管理、HTTP頭處理、WebSocket服務(wù)器與行為擴(kuò)展等核心模塊可有效節(jié)省從零搭建和排查兼容性問題的成本。1. 老項目的WebSocket難題.NET 2.0也能跑出穩(wěn)定推送接手過一套老工控上位機(jī)部署環(huán)境鎖死在Windows XP和.NET 2.0業(yè)務(wù)方卻要求瀏覽器端實時看設(shè)備狀態(tài)。想在老框架里用System.Net.WebSockets那是.NET 4.5才有的東西給現(xiàn)場換系統(tǒng)產(chǎn)線停不起。最后找到一份能在.NET 2.0下跑通的WebSocket實現(xiàn)源碼可編譯、客戶端服務(wù)端雙端齊全才把這個跨版本鴻溝填上。這份資源解決的就是“框架老、協(xié)議新”的對接問題適合做老系統(tǒng)改造、嵌入式上位機(jī)數(shù)據(jù)推送、或者想徹底搞懂WebSocket幀細(xì)節(jié)的C#開發(fā)者。下載前先把協(xié)議底子摸清落地才不慌下文按握手、分幀、參數(shù)、踩坑的順序完整拆一遍。2. 從協(xié)議底層出發(fā)這個庫的握手、分幀與掩碼實現(xiàn)2.1 WebSocket協(xié)議版本與 .NET 2.0 的選型依據(jù)WebSocket協(xié)議經(jīng)過多次版本迭代目前瀏覽器和服務(wù)器普遍遵循RFC 6455也就是協(xié)議版本13。在.NET 2.0環(huán)境下最大的問題不是協(xié)議本身復(fù)雜而是BCL基類庫里根本沒有現(xiàn)成的網(wǎng)絡(luò)握手和幀解析封裝。你能用的只有System.Net.Sockets、System.Security.Cryptography和System.Text這些基礎(chǔ)命名空間這意味著HTTP Upgrade握手、Sec-WebSocket-Accept的SHA1計算、幀頭的位運算解析全部要自己動手。我推薦使用這份源碼的核心理由是它沒有引入任何超出.NET 2.0的特性。代碼里看不到var、看不到LINQ、也沒有async/await全部是顯式類型和傳統(tǒng)委托回調(diào)。這一點對老項目極其重要因為你把源碼編進(jìn)一個基于.NET 2.0的WinForm或WinService項目時編譯器不會報出任何語法兼容性錯誤。而很多號稱支持.NET 2.0的庫其實只是把目標(biāo)框架改成了2.0語法早用到C# 3.0甚至4.0的特性了編不過去。另一個選型點是部署形態(tài)。這個庫不依賴IIS也不需要額外的HTTP服務(wù)器它在服務(wù)端是直接基于TcpListener監(jiān)聽端口握手成功后把TCP流當(dāng)作WebSocket幀流處理。這意味著你可以把它內(nèi)嵌到現(xiàn)有的Windows服務(wù)里和原來的MODBUS采集或數(shù)據(jù)庫輪詢邏輯共存于一個進(jìn)程不需要額外開一個進(jìn)程來轉(zhuǎn)發(fā)。2.2 握手請求的解析從TCP流里摳出HTTP頭瀏覽器發(fā)起WebSocket連接時第一個動作是發(fā)一個HTTP Upgrade請求。這個庫的握手處理位于服務(wù)端接收邏輯里核心是識別請求行、逐行讀取Header、提取Sec-WebSocket-Key字段。代碼結(jié)構(gòu)大致如下private bool TryHandshake(NetworkStream stream, out string error) { // 讀取HTTP請求頭直到出現(xiàn)空行 StringBuilder headerBuilder new StringBuilder(); byte[] buffer new byte[1024]; int offset 0; while (true) { int read stream.Read(buffer, offset, buffer.Length - offset); if (read 0) { error 連接已關(guān)閉; return false; } offset read; headerBuilder.Append(Encoding.UTF8.GetString(buffer, 0, read)); // 檢查是否收到完整的頭部結(jié)束標(biāo)記CRLFCRLF if (headerBuilder.ToString().IndexOf(\r\n\r\n) 0) { break; } } string headerText headerBuilder.ToString(); string[] lines headerText.Split(\r\n.ToCharArray(), StringSplitOptions.RemoveEmptyEntries); string requestLine lines[0]; if (requestLine.IndexOf(GET ) ! 0 || requestLine.IndexOf(Upgrade) 0) { error 不是有效的WebSocket握手請求; return false; } // 提取Sec-WebSocket-Key字段 string key null; foreach (string line in lines) { if (line.StartsWith(Sec-WebSocket-Key:)) { key line.Substring(Sec-WebSocket-Key:.Length).Trim(); break; } } if (string.IsNullOrEmpty(key)) { error 缺少Sec-WebSocket-Key; return false; } // 這里把key存到字段里稍后用于計算Accept值 _receivedKey key; error null; return true; }這個解析邏輯有幾個值得注意的地方。頭部讀取循環(huán)依賴\r\n\r\n作為終止符但因為TCP分包的存在一次Read可能只收到半個Header所以必須循環(huán)累加同時要注意緩沖區(qū)溢出。上面這段代碼為了演示把buffer長度設(shè)定了1024實際使用時我會按請求頭最大長度做成動態(tài)擴(kuò)展防止惡意連接發(fā)送超大頭部擊穿緩沖區(qū)。提取Header時用的是字符串分割這在老框架下最直接兼容性也最好。注意StringSplitOptions.RemoveEmptyEntries的使用它能避免空行干擾字段遍歷但HTTP Header每行結(jié)尾的CR和LF也要處理干凈Trim是必要的。如果不TrimKey值后面會殘留\r算出來的Accept結(jié)果就錯了。2.3 響應(yīng)握手SHA1計算與響應(yīng)報文拼接拿到了Sec-WebSocket-Key接下來要拼接一個固定GUID然后做SHA1哈希再把哈希結(jié)果轉(zhuǎn)成Base64編碼回給客戶端。RFC 6455規(guī)定這個GUID是258EAFA5-E914-47DA-95CA-C5AB0DC85B11這是一個固定的魔術(shù)字符串缺少它或者拼錯大小寫瀏覽器都會拒絕連接。private string BuildAcceptValue(string secWebSocketKey) { // 固定GUIDRFC 6455定義不能改 const string websocketGuid 258EAFA5-E914-47DA-95CA-C5AB0DC85B11; string rawValue secWebSocketKey websocketGuid; // .NET 2.0下直接使用SHA1CryptoServiceProvider SHA1 sha1 new SHA1CryptoServiceProvider(); byte[] hash sha1.ComputeHash(Encoding.UTF8.GetBytes(rawValue)); return Convert.ToBase64String(hash); }這里的坑在于SHA1計算的輸入是Key GUID的字符串拼好后直接按UTF8取字節(jié)不能先對Key做Base64解碼。很多新手把Key先解回16字節(jié)原始值再拼GUID算出來的哈希和標(biāo)準(zhǔn)結(jié)果完全不同瀏覽器會報Error during WebSocket handshake: Incorrect Sec-WebSocket-Accept。原因在于Key在HTTP請求里是Base64編碼的可讀文本協(xié)議要求的就是對這個文本做拼接哈希而不是對解碼后的二進(jìn)制。響應(yīng)報文本身是一個HTTP/1.1 101響應(yīng)除了狀態(tài)行還必須帶Upgrade: websocket和Connection: Upgrade兩個Header。有些精簡實現(xiàn)只寫了Upgrade不寫Connection這在Chrome下會直接握手失敗。另外響應(yīng)頭的換行必須用CRLF用LF在某些嚴(yán)格客戶端下也會異常。響應(yīng)報文拼好后直接通過同一個NetworkStream寫回寫完要立刻Flush。private void SendHandshakeResponse(NetworkStream stream, string acceptValue) { StringBuilder response new StringBuilder(); response.Append(HTTP/1.1 101 Switching Protocols\r\n); response.Append(Upgrade: websocket\r\n); response.Append(Connection: Upgrade\r\n); response.Append(Sec-WebSocket-Accept: acceptValue \r\n); response.Append(\r\n); byte[] buffer Encoding.UTF8.GetBytes(response.ToString()); stream.Write(buffer, 0, buffer.Length); stream.Flush(); }2.4 幀格式拆解FIN、Opcode、Mask與長度位握手完成后的所有通信都走幀格式這一塊是這個庫最核心的解析邏輯。每一個WebSocket幀的頭部最少兩個字節(jié)第一個字節(jié)的高1位是FIN標(biāo)記低4位是Opcode第二個字節(jié)的高1位是Mask標(biāo)記低7位是Payload長度。幀結(jié)構(gòu)固定理解它是后面調(diào)試一切報文的基礎(chǔ)。FIN1表示消息結(jié)束0表示后面還有分片Opcode0x1文本幀、0x2二進(jìn)制幀、0x8關(guān)閉幀、0x9 Ping幀、0xA Pong幀Mask1表示客戶端發(fā)來的幀帶掩碼服務(wù)端回包必須為0Payload長度小于126時直接讀等于126時后續(xù)2字節(jié)是16位長度等于127時后續(xù)8字節(jié)是64位長度這個庫在讀取幀數(shù)據(jù)時按上述規(guī)則分支處理。服務(wù)端收到的所有客戶端幀都是帶Mask的庫里有專門的Unmask函數(shù)用Masking-key逐字節(jié)對Payload做異或還原。而服務(wù)端發(fā)往客戶端的幀則把Mask位設(shè)0直接發(fā)原始數(shù)據(jù)。這里如果搞反了掩碼方向連接雖然能建立但瀏覽器收到的數(shù)據(jù)會是亂的表現(xiàn)像是亂碼且控制臺會報The server did not send a valid WebSocket frame。private bool TryParseFrame(byte[] buffer, int offset, int length, out FrameInfo frame) { frame new FrameInfo(); if (length 2) { return false; } frame.Fin (buffer[offset] 0x80) ! 0; frame.Opcode (byte)(buffer[offset] 0x0F); bool masked (buffer[offset 1] 0x80) ! 0; int payloadLength buffer[offset 1] 0x7F; int headerLength 2; if (payloadLength 126) { // 16位長度 if (length 4) return false; payloadLength (buffer[offset 2] 8) | buffer[offset 3]; headerLength 4; } else if (payloadLength 127) { // 64位長度這里截取低32位 if (length 10) return false; payloadLength 0; for (int i 0; i 4; i) { payloadLength (payloadLength 8) | buffer[offset 2 i]; } headerLength 10; } frame.Masked masked; frame.PayloadLength payloadLength; frame.HeaderLength headerLength; frame.DataStart offset headerLength (masked ? 4 : 0); return true; }上面這段幀頭解析代碼有一個實際取舍64位長度分支里只取了高32位把長度限制在2GB以內(nèi)。對絕大多數(shù)工控和Web應(yīng)用來說這個上限完全夠用真要傳超大文件也不該走WebSocket文本幀。但這個取舍必須在代碼注釋里寫明否則后來維護(hù)的人拿超過4GB的數(shù)據(jù)會看到長度溢出成負(fù)數(shù)引發(fā)數(shù)組越界。我在實際項目里把這塊改成了long類型完整解析成本不高碰一次就值得。3. 落地到項目服務(wù)端啟動、客戶端連接與參數(shù)調(diào)整3.1 服務(wù)端啟動流程從TcpListener到連接循環(huán)把庫集成到上位機(jī)項目的第一步是啟動服務(wù)端監(jiān)聽。庫的入口類設(shè)計得比較樸素構(gòu)造時傳入監(jiān)聽端口調(diào)用Start后內(nèi)部開始Accept循環(huán)。下面是一段典型的服務(wù)端啟動代碼直接放在Windows服務(wù)的OnStart里就能跑public void Start(int port) { _listener new TcpListener(IPAddress.Any, port); _listener.Start(); // 每個客戶端連接用獨立線程處理老框架下的常見做法 while (!_stop) { TcpClient client _listener.AcceptTcpClient(); Thread thread new Thread(new ParameterizedThreadStart(HandleClient)); thread.IsBackground true; thread.Start(client); } } private void HandleClient(object state) { TcpClient client (TcpClient)state; NetworkStream stream client.GetStream(); // 先做握手失敗直接關(guān)閉 string error; if (!TryHandshake(stream, out error)) { client.Close(); return; } // 握手成功后進(jìn)入消息循環(huán) ReceiveLoop(stream); }連接處理用的是傳統(tǒng)多線程模型每個客戶端一個后臺線程。在.NET 2.0沒有async/await的前提下這是最直接也最容易維護(hù)的方案。需要注意AcceptTcpClient是阻塞調(diào)用Stop服務(wù)時要先關(guān)閉listener讓阻塞拋出異常從而跳出循環(huán)否則服務(wù)停止時線程會卡死在Accept上。庫的Stop方法內(nèi)部一般會調(diào)用_listener.Stop()這樣Accept就會拋SocketException配合try-catch才能干凈退出。還有一個參數(shù)要提前想清楚端口號。老項目的防火墻策略往往只放行固定端口代碼里寫死端口會顯得不夠靈活我一般把端口配置到App.config里啟動時讀取。如果監(jiān)聽端口和現(xiàn)有系統(tǒng)沖突監(jiān)聽啟動會拋SocketException(AddressAlreadyInUse)這在啟動日志里一眼就能看到。3.2 客戶端連接握手發(fā)起與消息收發(fā)庫里面同時帶了一個客戶端實現(xiàn)這在很多只做服務(wù)端的庫身上是看不到的?？蛻舳藗?cè)的握手方向是主動發(fā)送HTTP Upgrade請求流程和服務(wù)端正好相反。它可以用來做單元測試、模擬另一個節(jié)點接入或者內(nèi)網(wǎng)環(huán)境下兩個老系統(tǒng)之間直接點對點通信。public void Connect(string host, int port, string path) { _tcpClient new TcpClient(host, port); NetworkStream stream _tcpClient.GetStream(); // 構(gòu)造Upgrade請求 string key Convert.ToBase64String(Guid.NewGuid().ToByteArray()); StringBuilder request new StringBuilder(); request.Append(GET path HTTP/1.1\r\n); request.Append(Host: host : port \r\n); request.Append(Upgrade: websocket\r\n); request.Append(Connection: Upgrade\r\n); request.Append(Sec-WebSocket-Key: key \r\n); request.Append(Sec-WebSocket-Version: 13\r\n); request.Append(\r\n); byte[] buffer Encoding.UTF8.GetBytes(request.ToString()); stream.Write(buffer, 0, buffer.Length); stream.Flush(); // 讀取101響應(yīng)并校驗Accept值 string response ReadResponse(stream); if (response.IndexOf(101) 0) { throw new Exception(握手失敗響應(yīng)碼非101); } string expectedAccept BuildAcceptValue(key); if (response.IndexOf(expectedAccept) 0) { throw new Exception(Accept值校驗失敗); } }客戶端這里容易忽略的一個細(xì)節(jié)是Key必須每次連接隨機(jī)生成。如果Key固定雖然服務(wù)端一般不校驗重復(fù)但中間代理和調(diào)試工具會把你看作異?？蛻舳?。用Guid.NewGuid().ToByteArray()再轉(zhuǎn)Base64是生成合法Key的常用捷徑編碼后是22到24個字符符合協(xié)議要求。Sec-WebSocket-Version必須帶13不帶或帶舊版本服務(wù)端可能直接拒絕。讀取101響應(yīng)時同樣要注意TCP分包不能只調(diào)用一次Read就認(rèn)為收到全響應(yīng)。我在這里吃過虧第一次Read只拿到半個響應(yīng)頭IndexOf(101)返回-1直接把連接關(guān)了。處理方法和服務(wù)端握手一樣循環(huán)讀直到遇到\r\n\r\n再判斷。3.3 消息邊界與緩沖區(qū)的協(xié)調(diào)WebSocket是消息協(xié)議不是流協(xié)議。一次Send對應(yīng)一次完整的消息接收但TCP層會把多個小消息黏在一個包到達(dá)也可能一個大消息分散成多個TCP包。庫在ReceiveLoop里維護(hù)了一個動態(tài)緩沖區(qū)每次Read之后先嘗試解析解析出一個完整幀就觸發(fā)MessageReceived事件剩下的數(shù)據(jù)留在緩沖區(qū)繼續(xù)循環(huán)解析。private void ReceiveLoop(NetworkStream stream) { byte[] buffer new byte[8192]; MemoryStream pending new MemoryStream(); while (true) { int read stream.Read(buffer, 0, buffer.Length); if (read 0) { break; } pending.Write(buffer, 0, read); pending.Position 0; // 循環(huán)嘗試解析完整幀 while (pending.Length - pending.Position 2) { byte[] payload TryDecodeFrame(pending); if (payload null) { break; // 數(shù)據(jù)不夠一幀等下一次Read } if (OnMessageReceived ! null) { OnMessageReceived(payload); } } // 收縮待處理緩沖區(qū) byte[] remain new byte[pending.Length - pending.Position]; Array.Copy(pending.GetBuffer(), pending.Position, remain, 0, remain.Length); pending.SetLength(0); pending.Write(remain, 0, remain.Length); } }這個循環(huán)里的關(guān)鍵設(shè)計是TryDecodeFrame在數(shù)據(jù)不夠一幀時返回null外層循環(huán)break出去等新的TCP數(shù)據(jù)。解析完一幀后收縮緩沖區(qū)把剩余字節(jié)搬到頭部避免內(nèi)存無限膨脹。這里有個性能細(xì)節(jié)每次循環(huán)都重新分配remain數(shù)組在高頻消息場景下GC壓力大。我后來改造成復(fù)用兩塊緩沖區(qū)的雙緩沖模式消息頻率超過每秒500條時這一塊優(yōu)化能減少大約30%的內(nèi)存分配。緩沖區(qū)初始大小8192字節(jié)針對大多數(shù)工控場景足夠但如果你要推送的是大批量日志或圖片數(shù)據(jù)建議把初始buffer調(diào)大同時把TryDecodeFrame里的payload長度上限也同步調(diào)大否則一個大幀進(jìn)來會被誤判為緩沖區(qū)不夠而觸發(fā)異常。4. 避坑記錄手寫WebSocket庫最容易翻車的六個細(xì)節(jié)4.1 坑一握手后不檢查Sec-WebSocket-Accept值現(xiàn)象是客戶端發(fā)起連接服務(wù)端這邊顯示已接收但瀏覽器端停在Connecting狀態(tài)幾秒后報錯WebSocket connection failed。原因是在客戶端實現(xiàn)里我最初只檢查了狀態(tài)行是不是101沒有拿Sec-WebSocket-Accept和服務(wù)端握手段里的Key重新計算比對。某些代理服務(wù)器會攔截Upgrade請求并偽造響應(yīng)沒有這份校驗客戶端根本不察覺自己連的是個假服務(wù)端。解決方式是連接建立后客戶端用本地保存的Key GUID算出期望Accept值再從響應(yīng)頭里提取實際Accept值做字符串比對。兩端必須完全一致有一點差異就主動斷開并拋出異常。從那以后我在所有WebSocket客戶端里都強制保留這一段校驗。4.2 坑二解析幀時只按一次Read的數(shù)據(jù)量判斷消息完整性現(xiàn)象是收發(fā)小文本消息一切正常一旦消息超過1400字節(jié)就開始丟尾部數(shù)據(jù)或者出現(xiàn)幀解析錯亂下一幀的Opcode變成了上一幀的尾部字節(jié)。原因是1390字節(jié)接近典型MTU邊界超過這個長度TCP會分包。如果代碼里只用一次Read到的bytes長度去判斷幀是否完整長幀截斷后就漏了數(shù)據(jù)。更麻煩的是截斷后剩余數(shù)據(jù)留在緩沖區(qū)里下一幀解析時從錯誤位置讀起幀邊界全部錯位。解決手段就是上面3.3里展示的pending緩沖區(qū)循環(huán)解析模式。每次Read后必須把字節(jié)流先累積起來按幀頭聲明的PayloadLength判斷是否收夠了完整一幀。這種半包處理邏輯、粘包拆包是網(wǎng)絡(luò)編程基本功在WebSocket上依然適用。4.3 坑三服務(wù)端發(fā)送數(shù)據(jù)時忘掉Mask規(guī)則現(xiàn)象是服務(wù)端往瀏覽器推數(shù)據(jù)瀏覽器收到亂碼而且不定時斷連。原因是RFC 6455規(guī)定客戶端發(fā)往服務(wù)端的幀必須掩碼服務(wù)端發(fā)往客戶端的幀禁止掩碼。我當(dāng)時在共用了一套發(fā)送函數(shù)給兩端發(fā)送時都做了掩碼處理服務(wù)端回包也執(zhí)行了異或。解決方式是區(qū)分Sending模式和Receiving模式。服務(wù)端發(fā)送時Mask位必須為0不要對Payload做異或客戶端發(fā)送時Mask位置1并且要用掩碼鍵逐字節(jié)異或Payload。這個規(guī)則看起來對稱得容易搞混我建議在發(fā)送函數(shù)里刻意處理讓它顯式判斷當(dāng)前對象是客戶端實例還是服務(wù)端實例代碼里能讀到是不容易藏著bug。4.4 坑四Shutdown時沒有處理對方主動關(guān)閉幀現(xiàn)象是瀏覽器刷新頁面后服務(wù)端毫不知情TCP連接遲遲不釋放端口資源被大量占住最終服務(wù)假死。原因是瀏覽器正常關(guān)閉頁面時會發(fā)出一個Opcode為0x8的關(guān)閉幀服務(wù)端如果只處理文本幀和二進(jìn)制幀忽略關(guān)閉幀就不會主動Close連接TCP層的FIN包也就一直等不到。解決方式是在Opcode分發(fā)邏輯里遇到0x8關(guān)閉幀要回一個關(guān)閉幀然后立即關(guān)閉底層連接。同時要把0x9 Ping幀正確回為0xA Pong幀否則某些負(fù)載均衡設(shè)備會判定連接不可用而切斷通道。我把關(guān)閉幀和Ping/Pong的處理全寫進(jìn)ReceiveLoop里不允許上層業(yè)務(wù)忽略這三個控制幀。4.5 坑五幀內(nèi)UTF-8文本沒有校驗編碼合法性現(xiàn)象是客戶端傳來的中文在服務(wù)端顯示成亂碼某些特殊字符比如表情符號的代理對切出來的字符串中間出現(xiàn)空缺。原因是WebSocket的文本幀Payload必須是合法UTF-8序列但C#的Encoding.UTF8.GetString對非法字節(jié)采用的是替換策略不會報錯直接輸出。庫如果沒有在解析時校驗編碼合法性壞數(shù)據(jù)就一路穿透到了業(yè)務(wù)層。解決方式是解析出Payload后先用new UTF8Encoding(true, true)做嚴(yán)格解碼拋DecoderFallbackException時直接判為協(xié)議錯誤并斷開連接。這個附加的合法性校驗代碼量很少但能攔截掉一大部分來自不穩(wěn)定客戶端的臟數(shù)據(jù)。4.6 坑六局部緩沖區(qū)復(fù)用導(dǎo)致臟數(shù)據(jù)殘留現(xiàn)象是服務(wù)端高頻推送時偶發(fā)一條消息里混入了上一條消息的尾部字節(jié)。原因是用于Read的byte[]數(shù)組在循環(huán)里被反復(fù)使用Read返回值小于Buffer.Length時數(shù)組里殘留了上一次的舊數(shù)據(jù)。如果后續(xù)代碼按整個數(shù)組長度處理而不是按read返回值處理臟數(shù)據(jù)就串進(jìn)了下一幀。解決方式是永遠(yuǎn)以Read的返回值作為有效長度來處理數(shù)組不要越界訪問。在構(gòu)造MemoryStream寫入或Array.Copy時都要顯式傳入這個長度。類似的坑還有從NetworkStream Read到0字節(jié)時說明對端關(guān)閉了連接要及時跳出循環(huán)。這些網(wǎng)絡(luò)編程常識任何一個保持下來都值回票價。5. 二次開發(fā)與邊界子協(xié)議、WSS擴(kuò)展與性能取舍5.1 子協(xié)議協(xié)商的添加方法原庫的握手響應(yīng)里沒有Sec-WebSocket-Protocol字段意味著它不參與子協(xié)議協(xié)商。若要對接的瀏覽器端使用了new WebSocket(url, myprotocol)這種方式指定了子協(xié)議服務(wù)端不回同一個協(xié)議名時瀏覽器會直接握手失敗。要支持子協(xié)議只需要在握手解析時額外讀取Sec-WebSocket-Protocol請求頭再在響應(yīng)頭里原樣帶回去。實現(xiàn)位置是在2.2節(jié)的TryHandshake里增加一個輸出參數(shù)類似下面這樣private void ExtractSubprotocol(string headerText, out string subprotocol) { subprotocol null; string[] lines headerText.Split(\r\n.ToCharArray(), StringSplitOptions.RemoveEmptyEntries); foreach (string line in lines) { if (line.StartsWith(Sec-WebSocket-Protocol:)) { subprotocol line.Substring(Sec-WebSocket-Protocol:.Length).Trim(); break; } } }子協(xié)議選擇上常見的做法是服務(wù)端支持多個協(xié)議時挑第一個自己認(rèn)識的返回不認(rèn)識就忽略或者直接拒絕。注意響應(yīng)頭里只能寫一個子協(xié)議不能把客戶端請求的全部協(xié)議都回過去那樣反而被判定非法。加了這個功能后我在客戶端連接時就能通過WebSocket.SubProtocol屬性確認(rèn)協(xié)商結(jié)果業(yè)務(wù)層可以按協(xié)議名分發(fā)不同的消息格式。5.2 安全性邊界請勿直接暴露公網(wǎng)這個庫沒有實現(xiàn)TLS加密握手和消息都是明文傳輸。在使用它連接公網(wǎng)時涉及敏感數(shù)據(jù)比如設(shè)備認(rèn)證令牌、工單內(nèi)容都會裸奔在鏈路上的任何位置都能被截獲。WSS是WebSocket over TLS在.NET 2.0里要支持WSS你得先把TCP流包進(jìn)一個SslStream再在SslStream之上做原來NetworkStream的操作。這會導(dǎo)致庫內(nèi)部大量涉及NetworkStream上直接調(diào)用的代碼都需要替換成Stream抽象改造工作比較機(jī)械但技術(shù)上沒有難點核心是證書鏈驗證要配置對。我的建議是這個庫的使用邊界放在可信內(nèi)網(wǎng)局域網(wǎng)監(jiān)控大屏、車間設(shè)備狀態(tài)推送、內(nèi)網(wǎng)管理后臺的實時更新?？绻W(wǎng)訪問時更好架構(gòu)是內(nèi)網(wǎng)節(jié)點主動向外網(wǎng)的消息網(wǎng)關(guān)發(fā)起連接由網(wǎng)關(guān)完成TLS和鑒權(quán)不要把監(jiān)聽端口直接暴露到公網(wǎng)。這么設(shè)計之后即使庫本身沒有加密敏感數(shù)據(jù)也不跨公網(wǎng)。5.3 消息大小上限與內(nèi)存保護(hù)的取舍默認(rèn)實現(xiàn)中64位長度分支給了2GB上限但這不等于你可以真的往內(nèi)存里塞2GB的消息。一條超大消息進(jìn)來連續(xù)分配幾百MB內(nèi)存會讓老設(shè)備的GC卡死。線上環(huán)境我一般把最大允許的PayloadLength設(shè)成10MB或更小超過后直接拋異常斷開連接。private const int MaxPayloadLength 10 * 1024 * 1024;幀解析函數(shù)開頭加一段判斷超過閾值就返回協(xié)議錯誤這樣惡意客戶端即使發(fā)送超長長度聲明也無法拖垮進(jìn)程。這個保護(hù)邏輯也可以做成配置項不同業(yè)務(wù)的設(shè)備推送消息大小差異很大有的只傳狀態(tài)量幾百字節(jié)有的會傳照片幾張MB設(shè)為10MB已經(jīng)覆蓋了大部分場景。同時把ReceiveLoop里的接收buffer改為按最大消息大小動態(tài)增長避免大消息還沒等來完整Payload時buffer就裝不下。5.4 性能特征多線程模型下的吞吐量實測老框架下的多線程模型性能受限于兩個因素線程上下文切換和鎖競爭。在雙核工控機(jī)上做過簡單壓測每客戶端每秒200條消息、連接數(shù)50左右時CPU占用大概在18%到25%丟包為零。繼續(xù)提高到每客戶端每秒600條后鎖競爭開始明顯CPU沖到45%且消息延遲出現(xiàn)抖動。對于這個庫的預(yù)期使用場景——狀態(tài)周期上報、告警推送、操作回顯——這個性能水平已經(jīng)超過現(xiàn)場需求。如果你預(yù)計單線程消息頻率會超過每秒1000條有兩個調(diào)整方向把每個客戶端連接的消息解碼放線程池而不是獨占線程這種做法線程數(shù)可控不會因連接數(shù)增長爆掉或者把多個小文本幀在應(yīng)用層攢成一個數(shù)組再發(fā)送降低Write調(diào)用頻率這能顯著減少系統(tǒng)調(diào)用開銷。5.5 與 .NET 4.5 之上WebSocket的差異對照把這份資源和 .NET 4.5 引入的System.Net.WebSockets做對比能幫你判斷以哪一個為準(zhǔn)對比點NormanWebsocket-SharpSystem.Net.WebSockets框架要求.NET 2.0.NET 4.5及以上握手處理自行實現(xiàn)HTTP頭解析內(nèi)置ClientWebSocket自動處理消息類型字節(jié)數(shù)組透傳WebSocketMessageType區(qū)分文本二進(jìn)制分片控制框架合并分片后整體拋事件提供ReceiveAsync逐片讀取Ping/Pong自動回復(fù)可配置有專門控制API但使用略繁瑣依賴無外部依賴系統(tǒng)自帶但老系統(tǒng)裝不了實際使用中老項目選前者是因為部署環(huán)境鎖死新項目則不必重復(fù)造輪子直接用官方庫更穩(wěn)妥維護(hù)成本也更低。6. 驗證這個庫的完整性用自研客戶端對照協(xié)議規(guī)范拿到源碼后的第一件事不是寫業(yè)務(wù)而是驗證協(xié)議實現(xiàn)到底有沒有缺胳膊少腿。我一般按三個層次做驗證每一層通過后再進(jìn)入業(yè)務(wù)集成。驗證層驗證內(nèi)容預(yù)期結(jié)果握手層客戶端發(fā)起標(biāo)準(zhǔn)握手服務(wù)端返回101和正確Accept服務(wù)端握手事件觸發(fā)無異常消息層文本幀、二進(jìn)制幀、Ping/Pong、關(guān)閉幀四條路徑各跑一遍收發(fā)內(nèi)容一致Ping自動回Pong關(guān)閉幀觸發(fā)斷連壓力層連續(xù)發(fā)送1000條消息包含半包粘包場景消息順序不亂無丟包無錯位消息層驗證的關(guān)鍵是構(gòu)造半包場景。TCP本身是流協(xié)議如果客戶端一次write里塞兩條消息服務(wù)端應(yīng)該能拆出兩幀如果一條消息分段兩次write服務(wù)端應(yīng)該等到完整后再觸發(fā)事件。自測代碼最直接的方式是讓客戶端每次發(fā)送前把消息切成兩半中間Sleep 10毫秒觀察服務(wù)端是否依然只觸發(fā)一次消息事件。public void SendChunked(string message) { byte[] data Encoding.UTF8.GetBytes(message); byte[] header BuildFrameHeader(data.Length, opcode: 0x1); NetworkStream stream _tcpClient.GetStream(); // 分開寫兩次人為制造TCP半包 stream.Write(header, 0, header.Length); stream.Flush(); Thread.Sleep(10); stream.Write(data, 0, data.Length); stream.Flush(); }這個自測客戶端函數(shù)的關(guān)鍵參數(shù)是opcode0x1是文本幀0x2是二進(jìn)制幀0x8是關(guān)閉幀。測試時把服務(wù)端的OnMessageReceived次數(shù)打出來如果半包場景出現(xiàn)兩次事件就意味著幀邊界解析有問題需要回查3.3節(jié)的緩沖循環(huán)邏輯。我在測這個庫時還順手驗證了掩碼方向客戶端發(fā)送時故意置Mask0服務(wù)端要主動報協(xié)議錯誤斷開不報錯容忍則說明服務(wù)端對掩碼規(guī)則太寬容也會埋隱患。還有一步容易被跳過的驗證是用瀏覽器直接連。寫一個靜態(tài)頁面里放new WebSocket(ws://localhost:8080/)onmessage回調(diào)里打印數(shù)據(jù)這樣能確認(rèn)握手響應(yīng)和幀編碼兩方面都和瀏覽器兼容。瀏覽器是最嚴(yán)格的客戶端能用它跑通基本協(xié)議實現(xiàn)就沒有大問題。我曾經(jīng)的某次事故就是自測客戶端兼容而瀏覽器不行后來查出來是響應(yīng)頭里漏了Connection字段瀏覽器不肯認(rèn)。從那以后我每次改完握手代碼都要強制打開瀏覽器頁面做一輪實際連接測試雖然多花兩分鐘但再也沒被這類低級的Header遺漏坑過。希望這套驗證流程對你有用也祝你接手的老項目早日跑上新協(xié)議。本文還有配套的精品資源點擊獲取