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