簡(jiǎn)介面向C網(wǎng)絡(luò)編程開發(fā)者此壓縮包演示了基于libevent構(gòu)建WebSocket服務(wù)器的完整實(shí)現(xiàn)涵蓋HTTP升級(jí)握手、幀的編解碼、事件循環(huán)集成以及連接超時(shí)管理等環(huán)節(jié)適合需要為系統(tǒng)增加低延遲雙向通信能力的工程技術(shù)人員。包內(nèi)共20個(gè)文件其中8個(gè)頭文件與7個(gè)C源文件構(gòu)成核心代碼另附Makefile構(gòu)建腳本、README說明文檔和可直接運(yùn)行的聊天示例整體大小僅16KB結(jié)構(gòu)干凈便于快速定位關(guān)鍵模塊。已有616人下載學(xué)習(xí)代碼框架簡(jiǎn)潔示例可直接編譯運(yùn)行適合作為課堂項(xiàng)目或面試準(zhǔn)備材料。通過研讀源碼可以掌握Sec-WebSocket-Accept的生成原理、base64與MD5工具的使用方法以及如何利用libevent的非阻塞I/O管理大量并發(fā)連接是一份能直接借鑒甚至作為自研服務(wù)器起點(diǎn)的實(shí)用參考也為進(jìn)一步加入多線程或TLS加密留出了清晰的擴(kuò)展思路。1. websocket 服務(wù)器項(xiàng)目解析當(dāng) C 遇上 libevent單線程如何扛住萬人長(zhǎng)連接做過即時(shí)通訊或?qū)崟r(shí)推送的后端開發(fā)者大概率都經(jīng)歷過這種場(chǎng)景用阻塞 socket 加多線程處理 WebSocket連接數(shù)一漲線程爆炸內(nèi)存飆升最后連 CPU 都耗在線程切換上。而用 C 配合 libevent 實(shí)現(xiàn) WebSocket 服務(wù)器走的是另一條路——事件驅(qū)動(dòng)、單線程撐起上萬并發(fā)連接既不靠多線程也不靠異步框架而是把每個(gè)連接的讀寫事件交給 libevent 的事件循環(huán)統(tǒng)一調(diào)度。這套方案特別適合對(duì)延遲敏感、連接數(shù)大但單連接吞吐不高的場(chǎng)景比如消息推送、在線狀態(tài)同步、行情分發(fā)。本篇文章就把這份源碼包里 C 與 libevent 結(jié)合實(shí)現(xiàn)的 WebSocket 服務(wù)器完整拆開從事件模型到幀解析再到心跳?；詈投伍_發(fā) 每一步都給你講透。2. 架構(gòu)設(shè)計(jì)與事件驅(qū)動(dòng)libevent 如何撐起 WebSocket 服務(wù)器2.1 事件循環(huán)為什么單線程反而更高效傳統(tǒng)阻塞式 socket 服務(wù)器每個(gè)連接分配一個(gè)線程線程在 read 上阻塞等待數(shù)據(jù)。連接數(shù)一多上下文切換開銷和內(nèi)存占用就成了瓶頸。而這份源碼里的 WebSocket 服務(wù)器基于 libevent 的事件循環(huán)把所有 socket 文件描述符注冊(cè)到 event_base 上由 libevent 內(nèi)部統(tǒng)一監(jiān)聽讀寫事件事件觸發(fā)時(shí)回調(diào)對(duì)應(yīng)處理函數(shù)單個(gè)線程就能驅(qū)動(dòng)成千上萬個(gè)連接。核心初始化代碼如下struct event_base* base event_base_new(); struct evhttp* http_server evhttp_new(base); evhttp_bind_socket(http_server, 0.0.0.0, 8080);這里evhttp_bind_socket把 HTTP 服務(wù)綁定到 8080 端口這是 WebSocket 握手的前置步驟——WebSocket 協(xié)議規(guī)定連接必須通過 HTTP Upgrade 請(qǐng)求完成握手升級(jí)。libevent 自帶的 evhttp 模塊幫你處理了 HTTP 層面的解析省去了手寫 HTTP 請(qǐng)求解析的重復(fù)勞動(dòng)。event_base_new創(chuàng)建事件循環(huán)的根基后續(xù)所有 socket、定時(shí)器、信號(hào)事件都會(huì)掛在這個(gè) base 上。事件循環(huán)的啟動(dòng)代碼是event_base_dispatch(base)它會(huì)陷入一個(gè)無限循環(huán)內(nèi)部調(diào)用epoll或kqueue等系統(tǒng)多路復(fù)用接口等待事件到來。整個(gè)過程不阻塞在任何一個(gè) socket 上所以單線程可以同時(shí)服務(wù)大量連接這就是事件驅(qū)動(dòng)模型的核心優(yōu)勢(shì)。2.2 線程模型與連接管理每個(gè)連接綁定一個(gè)緩沖區(qū)結(jié)構(gòu)源碼里為每個(gè) WebSocket 連接維護(hù)了一個(gè)獨(dú)立的結(jié)構(gòu)體包含緩沖區(qū)、連接狀態(tài)、心跳計(jì)時(shí)器等字段。libevent 通過bufferevent對(duì)這個(gè)結(jié)構(gòu)體進(jìn)行封裝bufferevent幫你管理了讀寫緩沖區(qū)的自動(dòng)擴(kuò)容和數(shù)據(jù)的按需讀取。struct websocket_client { struct bufferevent* bev; char recv_buffer[8192]; size_t recv_len; int handshake_done; time_t last_ping_time; void* user_data; };每個(gè)連接的handshake_done標(biāo)記是否完成握手last_ping_time記錄最后一次收到心跳包的時(shí)間user_data留給業(yè)務(wù)層掛載自定義數(shù)據(jù)。一個(gè)連接從建立到銷毀生命周期里的讀事件、寫事件、超時(shí)事件全部由 libevent 分發(fā)到對(duì)應(yīng)回調(diào)函數(shù)不需要為每個(gè)連接創(chuàng)建線程。3. 核心模塊拆解從握手到幀解析的完整鏈路3.1 HTTP 握手升級(jí)WebSocket 的第一道關(guān)卡當(dāng)一個(gè)客戶端發(fā)起 WebSocket 連接時(shí)首先發(fā)送的是標(biāo)準(zhǔn)的 HTTP 請(qǐng)求帶Upgrade: websocket頭。服務(wù)器需要識(shí)別這個(gè)頭返回101 Switching Protocols狀態(tài)碼完成協(xié)議切換。源碼中在 evhttp 的回調(diào)里判斷請(qǐng)求頭核心邏輯如下static void https_cb(struct evhttp_request* req, void* arg) { const char* upgrade evhttp_find_header(req-input_headers, Upgrade); if (upgrade ! NULL strcasecmp(upgrade, websocket) 0) { handle_websocket_handshake(req); } else { evhttp_send_reply(req, HTTP_OK, OK, NULL); } }evhttp_find_header從 HTTP 請(qǐng)求頭里查找 Upgrade 字段如果匹配 websocket就進(jìn)入握手處理否則當(dāng)成普通 HTTP 請(qǐng)求返回。這段代碼是對(duì)Sec-WebSocket-Key的驗(yàn)證與響應(yīng)static void handle_websocket_handshake(struct evhttp_request* req) { const char* key evhttp_find_header(req-input_headers, Sec-WebSocket-Key); char accept_key[64]; compute_accept_key(key, accept_key); struct evbuffer* evb evbuffer_new(); evbuffer_add_printf(evb, HTTP/1.1 101 Switching Protocols\r\n Upgrade: websocket\r\n Connection: Upgrade\r\n Sec-WebSocket-Accept: %s\r\n\r\n, accept_key); evhttp_send_reply_start(req, 101, Switching Protocols); evhttp_send_reply_chunk(req, evb); evhttp_send_reply_end(req); }compute_accept_key將客戶端傳來的Sec-WebSocket-Key拼接固定 GUID再做 SHA-1 哈希和 Base64 編碼得到Sec-WebSocket-Accept響應(yīng)頭。這個(gè)流程是 RFC 6455 協(xié)議規(guī)定的標(biāo)準(zhǔn)握手過程缺了哪一步瀏覽器都會(huì)拒絕建立連接。3.2 幀解析掩碼處理與數(shù)據(jù)分片WebSocket 數(shù)據(jù)幀格式是二進(jìn)制結(jié)構(gòu)第一個(gè)字節(jié)的高四位表示操作碼低四位表示是否分片第二個(gè)字節(jié)包含掩碼位和長(zhǎng)度信息。源碼中最核心的函數(shù)是websocket_parse_frame每次從緩沖區(qū)讀取數(shù)據(jù)時(shí)都會(huì)調(diào)用int websocket_parse_frame(struct websocket_client* client) { unsigned char* data (unsigned char*)client-recv_buffer; unsigned char opcode data[0] 0x0F; int masked (data[1] 0x80) 7; uint64_t payload_len data[1] 0x7F; int offset 2; if (payload_len 126) { payload_len (data[2] 8) | data[3]; offset 2; } else if (payload_len 127) { payload_len 0; for (int i 0; i 8; i) { payload_len (payload_len 8) | data[offset i]; } offset 8; } if (masked) { unsigned char mask_key[4]; memcpy(mask_key, data offset, 4); offset 4; for (uint64_t i 0; i payload_len; i) { data[offset i] ^ mask_key[i % 4]; } } // 此時(shí) data offset 就是解密后的業(yè)務(wù)數(shù)據(jù) }代碼里先讀操作碼判斷消息類型再讀長(zhǎng)度字段。當(dāng)長(zhǎng)度小于 126 時(shí)直接使用等于 126 時(shí)按 16 位長(zhǎng)度讀等于 127 時(shí)按 64 位長(zhǎng)度讀。掩碼處理是 WebSocket 協(xié)議里客戶端發(fā)送數(shù)據(jù)時(shí)必須做的操作服務(wù)器收到的數(shù)據(jù)是掩碼異或后的必須用密鑰逐字節(jié)還原。源碼里用mask_key[i % 4]對(duì) payload 逐字節(jié)異或還原出原始數(shù)據(jù)。3.3 分片消息重組TCP 粘包與半包處理的破解思路WebSocket 協(xié)議允許大消息分成多個(gè)幀傳輸?shù)谝粋€(gè)幀的 FIN 位為 0最后一個(gè)幀的 FIN 位為 1中間的數(shù)據(jù)需要攢起來拼接。源碼里用一個(gè)動(dòng)態(tài)緩沖區(qū)暫存分片數(shù)據(jù)struct fragment_buffer { char* data; size_t len; size_t capacity; int opcode; };每次收到新的分片時(shí)把 payload 追加到這個(gè)緩沖區(qū)尾部檢查 FIN 位決定是否結(jié)束拼接。這個(gè)機(jī)制的處理邏輯在handle_websocket_data中實(shí)現(xiàn)static void handle_websocket_data(struct websocket_client* client, unsigned char opcode, char* payload, size_t len) { if (opcode 0x00) { // 續(xù)幀追加到 fragment_buffer append_fragment(client-frag, payload, len); } else if (opcode 0x01) { // 文本幀可能是起始幀也可能是完整消息 if (client-frag-len 0) { client-frag-opcode opcode; append_fragment(client-frag, payload, len); } else { process_complete_message(client, payload, len); } } else if (opcode 0x08) { // 關(guān)閉幀 handle_close_frame(client); } else if (opcode 0x09) { // ping 幀 send_pong_frame(client); } }TCP 是流式協(xié)議收到的數(shù)據(jù)可能一次包含多個(gè)幀也可能一個(gè)幀被拆成多次到達(dá)。源碼里通過bufferevent的回調(diào)機(jī)制每次把可讀數(shù)據(jù)全部取出循環(huán)解析幀頭和數(shù)據(jù)直到緩沖區(qū)數(shù)據(jù)處理完。這就是粘包拆包問題的根本解法——不依賴一次 recv 拿全而是按幀邊界循環(huán)消費(fèi)緩沖區(qū)。3.4 心跳?；頦ebSocket 層級(jí)的 ping 與 pong 互搏網(wǎng)絡(luò)不穩(wěn)定或客戶端掉線服務(wù)器可能無法立即感知。源碼實(shí)現(xiàn)了 ping/pong 心跳機(jī)制服務(wù)器定期向客戶端發(fā)送 ping 幀客戶端收到后必須回復(fù) pong 幀服務(wù)器根據(jù) pong 響應(yīng)判斷連接是否存活。這個(gè)定時(shí)邏輯掛在 libevent 的定時(shí)器事件上static void heartbeat_cb(evutil_socket_t fd, short events, void* arg) { struct websocket_client* client (struct websocket_client*)arg; time_t now time(NULL); if (now - client-last_ping_time HEARTBEAT_INTERVAL) { send_ping_frame(client); client-last_ping_time now; } if (now - client-last_ping_time HEARTBEAT_TIMEOUT) { // 超過超時(shí)時(shí)間未收到 pong判定連接死亡 websocket_close_connection(client); } struct timeval tv {HEARTBEAT_INTERVAL, 0}; event_add(client-heartbeat_ev, tv); }每次定時(shí)器觸發(fā)時(shí)檢查上次收到 pong 的時(shí)間超時(shí)則直接關(guān)閉連接。使用event_add重新注冊(cè)定時(shí)器實(shí)現(xiàn)周期性調(diào)用這種模式比event_persist更靈活因?yàn)槟憧梢愿鶕?jù)業(yè)務(wù)動(dòng)態(tài)調(diào)整下一次檢查的間隔。3.5 消息回調(diào)分發(fā)業(yè)務(wù)代碼如何接入服務(wù)器核心功能是消息路由與分發(fā)。源碼里維護(hù)一個(gè)連接池struct websocket_server { struct event_base* base; struct evhttp* http; std::mapint, struct websocket_client* clients; int next_client_id; };每個(gè)新連接加入時(shí)分配一個(gè)客戶端 ID通過clients映射管理。當(dāng)收到完整消息時(shí)服務(wù)器查找消息中攜帶的目標(biāo) ID 或房間號(hào)將消息轉(zhuǎn)發(fā)給對(duì)應(yīng)連接void websocket_server_broadcast(struct websocket_server* server, const char* message) { for (auto pair : server-clients) { struct websocket_client* client pair.second; if (client-handshake_done) { websocket_send_text(client, message); } } }廣播的實(shí)現(xiàn)簡(jiǎn)單粗暴遍歷連接池逐個(gè)發(fā)送單播則需要業(yè)務(wù)層傳入目標(biāo) ID從clients里查詢對(duì)應(yīng)連接再發(fā)送。實(shí)際生產(chǎn)場(chǎng)景里這種全遍歷的模式在連接數(shù)突破萬級(jí)時(shí)會(huì)帶來不小的延遲源碼中為覆蓋高頻場(chǎng)景預(yù)留了 ID 路由接口讓使用者自行擴(kuò)展哈希索引與房間分組。4. 編譯運(yùn)行與避坑指南從源碼包到可用的 WebSocket 服務(wù)器4.1 環(huán)境準(zhǔn)備與編譯參數(shù)源碼包基于 CMake 構(gòu)建依賴系統(tǒng)安裝 libevent 開發(fā)庫。在 Ubuntu 系系統(tǒng)上安裝依賴sudo apt-get install libevent-dev cmake g然后進(jìn)入源碼根目錄執(zhí)行編譯流程mkdir build cd build cmake .. -DCMAKE_BUILD_TYPERelease make -j4CMake 會(huì)自動(dòng)查找 libevent 頭文件和動(dòng)態(tài)庫如果找不到就去/usr/local/include和/usr/local/lib路徑下面翻。源碼包里附帶一個(gè)CMakeLists.txt其中關(guān)鍵配置是鏈接event和event_extra兩個(gè)庫evhttp相關(guān)接口在event_extra中編譯時(shí)漏鏈接會(huì)出現(xiàn)undefined reference to evhttp_new。運(yùn)行服務(wù)端./websocket_server 8080啟動(dòng)后沒有任何輸出這是正常的libevent 的事件循環(huán)一旦啟動(dòng)就阻塞在event_base_dispatch上。想確認(rèn)是否正常工作下一個(gè)請(qǐng)求測(cè)試握手curl -i -H Connection: Upgrade -H Upgrade: websocket -H Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ http://127.0.0.1:8080/返回101 Switching Protocols表示握手成功。4.2 避坑這個(gè)項(xiàng)目里最常見的五個(gè)深坑坑一掩碼處理遺漏客戶端直接斷開連接現(xiàn)象服務(wù)器能完成握手但收到的文本消息解析出來全是亂碼或者瀏覽器直接報(bào)WebSocket connection failed。原因客戶端發(fā)送的幀數(shù)據(jù)全部經(jīng)過掩碼異或處理如果服務(wù)器不按 mask key 還原解析出的數(shù)據(jù)就是混淆后的。解決確認(rèn)幀解析代碼中masked位判斷是否完整掩碼還原必須用payload_len循環(huán)異或mask_key[i % 4]遺漏一個(gè)字節(jié)都不行。這個(gè)坑在初學(xué)階段幾乎必踩最直接的排查方式是在解幀后打印 raw data 和還原后數(shù)據(jù)的對(duì)比結(jié)果一眼就能發(fā)現(xiàn)問題。坑二TCP 粘包導(dǎo)致消息粘連現(xiàn)象連續(xù)快速發(fā)送多條消息服務(wù)器收到時(shí)幾條消息拼接在同一個(gè)緩沖區(qū)里解析出第一條后剩余數(shù)據(jù)留在緩沖區(qū)但被忽略或錯(cuò)位解析。原因TCP 是流協(xié)議多條 WebSocket 幀可能同時(shí)被內(nèi)核送達(dá)bufferevent_read一口氣讀出來。如果只解析一幀就返回剩余數(shù)據(jù)會(huì)在下一次觸發(fā) read 時(shí)才處理但此時(shí)緩沖區(qū)狀態(tài)已經(jīng)亂了。解決解析函數(shù)必須循環(huán)處理判斷當(dāng)前緩沖區(qū)消費(fèi)了多長(zhǎng)剩下的繼續(xù)按幀邊界解析。我給這個(gè)函數(shù)加了一個(gè)while (client-recv_len FRAME_HEADER_LEN)循環(huán)直到緩沖區(qū)剩余長(zhǎng)度不足一個(gè)幀頭才退出?？尤?4 位長(zhǎng)度字段解析錯(cuò)誤現(xiàn)象發(fā)送超過 2GB 的大文件時(shí)消息截?cái)嗷蛘呓馕龀鲥e(cuò)誤長(zhǎng)度。原因當(dāng) payload length 標(biāo)記為 127 時(shí)協(xié)議規(guī)定后續(xù) 8 字節(jié)是 64 位無符號(hào)整數(shù)。如果代碼里用一個(gè)int類型去存高位截?cái)嗪箝L(zhǎng)度變成負(fù)數(shù)或完全錯(cuò)亂后續(xù)緩沖區(qū)的 memcpy 必然越界。解決用uint64_t存儲(chǔ)長(zhǎng)度循環(huán)移位 8 次拼接完整值。這個(gè)問題在常規(guī)場(chǎng)景不一定觸發(fā)但一旦做大文件傳輸就是致命的。反正我改完以后都會(huì)用偽造的 8GB 超大幀做過一次壓力測(cè)試驗(yàn)穩(wěn)?？铀男奶瑫r(shí)誤殺正常連接現(xiàn)象連接在不聯(lián)網(wǎng)的辦公區(qū)或移動(dòng)網(wǎng)絡(luò)環(huán)境頻繁掉線服務(wù)器日志里大量連接被超時(shí)關(guān)閉。原因心跳間隔和超時(shí)閾值設(shè)置不合理ping 和 pong 的往返時(shí)間在弱網(wǎng)環(huán)境可能超過超時(shí)閾值服務(wù)器誤以為客戶端失活。源碼里HEARTBEAT_TIMEOUT默認(rèn)設(shè)成 10 秒在公共 WiFi 下經(jīng)常誤殺。解決把超時(shí)閾值放寬到心跳間隔的三倍以上比如每 30 秒發(fā)一次 ping90 秒未收到 pong 才關(guān)閉連接。這參數(shù)屬于生產(chǎn)環(huán)境必須調(diào)的那種本地調(diào)試看不出問題上真實(shí)公網(wǎng)環(huán)境才暴露?？游宸?wù)器主動(dòng)關(guān)閉連接時(shí)沒發(fā)關(guān)閉幀現(xiàn)象客戶端收到 TCP FIN 包但沒有收到協(xié)議層的關(guān)閉幀前端 WebSocket 的close事件不觸發(fā)表現(xiàn)為頁面卡在連接中。原因服務(wù)器調(diào)用close(socket)直接斷開 TCP 連接沒有先發(fā)送0x08關(guān)閉幀走完協(xié)議握手式的關(guān)閉流程。解決關(guān)閉連接前先發(fā)關(guān)閉幀然后等客戶端回關(guān)閉幀或超時(shí)才真正關(guān)閉 socket。WebSocket 協(xié)議跟 HTTP 一樣關(guān)閉也要講究一個(gè)善始善終不然前端的網(wǎng)絡(luò)狀態(tài)判斷機(jī)制會(huì)混亂。4.3 性能調(diào)優(yōu)參數(shù)怎么改才能吃滿事件循環(huán)影響 WebSocket 服務(wù)器吞吐量的核心參數(shù)其實(shí)不在 libevent 里而在系統(tǒng)層面。源碼包根目錄提供了一個(gè)sysctl.conf參數(shù)參考直接寫入系統(tǒng)的/etc/sysctl.conf后生效net.core.somaxconn 1024 net.ipv4.tcp_max_syn_backlog 1024 net.ipv4.ip_local_port_range 1024 65000 net.ipv4.tcp_tw_reuse 1somaxconn和tcp_max_syn_backlog決定 TCP 連接的 accept 隊(duì)列長(zhǎng)度連接數(shù)上來以后隊(duì)列滿了新連接會(huì)被直接丟棄表現(xiàn)為握手超時(shí)。tcp_tw_reuse讓 TIME_WAIT 狀態(tài)的端口快速回收短連接頻繁建立的場(chǎng)景下能明顯減少端口耗盡的問題。5. 二次開發(fā)實(shí)戰(zhàn)給這個(gè) WebSocket 服務(wù)器加上認(rèn)證與轉(zhuǎn)發(fā)能力5.1 加一個(gè)協(xié)議層的握手鑒權(quán)原版握手過程不校驗(yàn)任何身份信息任何客戶端只要能建立 TCP 連接就能完成 WebSocket 升級(jí)。在實(shí)際項(xiàng)目中這個(gè)裸奔狀態(tài)幾乎是不可接受的。我們可以在handle_websocket_handshake里加一個(gè) token 校驗(yàn)步驟const char* token evhttp_find_header(req-input_headers, Authorization); if (token NULL || strcmp(token, Bearer my-secret-token) ! 0) { evhttp_send_reply(req, HTTP_UNAUTHORIZED, Unauthorized, NULL); return; }這里直接從請(qǐng)求頭取 Authorization 字段跟預(yù)設(shè) token 做比對(duì)。你也可以在這個(gè)位置把 token 丟給后端的 Redis 做一次查詢校驗(yàn)用戶會(huì)話是否有效。需要注意的是token 放在查詢參數(shù)里時(shí)會(huì)被 WebSocket 連接串在 URL 里需要在服務(wù)端單獨(dú)拆出來處理邏輯會(huì)多出幾步。5.2 擴(kuò)展一個(gè) JSON 格式的業(yè)務(wù)消息分發(fā)原版的廣播接口是純文本透?jìng)鞲某?JSON 協(xié)議只需要在消息入口做一個(gè)簡(jiǎn)單序列化和反序列化。引入一個(gè)輕量的 json 解析庫把收到的消息體解析成結(jié)構(gòu)體typedef struct { char type[16]; char target[64]; char payload[4096]; } ws_message_t; static int parse_json_message(const char* data, size_t len, ws_message_t* msg) { // 解析 JSON提取 type、target、payload 字段 // 校驗(yàn)必填字段缺一不可 return 0; }拿到解析后的ws_message_t按type字段分發(fā)到不同的業(yè)務(wù)處理函數(shù)send類型查target對(duì)應(yīng)的連接做單播room類型查房間成員列表做群發(fā)broadcast類型走全量廣播。這就是從 echo 服務(wù)器變成一個(gè)真正業(yè)務(wù)服務(wù)端的最小改造路徑。5.3 多線程改造思路原版是單線程事件循環(huán)CPU 密集型的消息處理任務(wù)會(huì)阻塞整個(gè)事件循環(huán)。簡(jiǎn)單粗暴的解法是開多個(gè)event_base每個(gè)線程跑一個(gè)事件循環(huán)用accept鎖或SO_REUSEPORT把新連接分散到不同線程。libevent 本身不提供連接分配機(jī)制常見做法是主線程負(fù)責(zé) accept然后把bufferevent通過event_base_add掛到工作線程的事件循環(huán)上。這個(gè)改造的關(guān)鍵是注意線程安全問題所有客戶端對(duì)象的讀寫都要加鎖或者用無鎖隊(duì)列把消息傳遞到對(duì)應(yīng)線程處理。5.4 驗(yàn)證改造效果改完以后拿瀏覽器控制臺(tái)跑一段 WebSocket 壓力測(cè)試腳本先驗(yàn)證功能再驗(yàn)證性能const ws new WebSocket(ws://127.0.0.1:8080/); ws.onopen () { ws.send(JSON.stringify({type: send, target: user-1, payload: hello})); };功能驗(yàn)證通過后再連接多個(gè)客戶端測(cè)群發(fā)和心跳最后用 ab 或者 iperf 壓一把看吞吐和延遲曲線。整個(gè)過程跑完你會(huì)發(fā)現(xiàn)這套架構(gòu)的伸縮性邊界基本都在事件循環(huán)的阻塞點(diǎn)上動(dòng)畫和確認(rèn)日志打得太狠對(duì)性能影響特別大。從那以后我每次給這個(gè)服務(wù)端加新功能都強(qiáng)制走一遍先壓測(cè)再上日志最后調(diào)心跳參數(shù)。不然改完的功能可能在低并發(fā)下看不出問題一到真實(shí)環(huán)境就翻車。希望這些踩坑經(jīng)驗(yàn)對(duì)你上手這個(gè)項(xiàng)目能有點(diǎn)幫助。本文還有配套的精品資源點(diǎn)擊獲取