議同端口實戰(zhàn)：HTTP與WebSocket共存機(jī)制解析)
libwebsockets我習(xí)慣直接叫它lws最容易被新手忽略的一點是它從來不是一個只能跑WebSocket協(xié)議的庫。它默認(rèn)就支持一個進(jìn)程、一個監(jiān)聽端口上同時掛多套協(xié)議HTTP、WebSocket、甚至H2而且每套協(xié)議都有自己獨(dú)立的狀態(tài)存儲、回調(diào)入口和生命周期管理。這就是標(biāo)題里說的“多協(xié)議工作”。如果你之前只是照著demo把WebSocket跑起來遇到“又要提供REST接口、又要做實時推送、還想順手把靜態(tài)頁面也發(fā)出去”的需求第一反應(yīng)可能是去外面分別起兩個服務(wù)再在前面套一層Nginx。但你完全可以只用一個lws進(jìn)程把所有流量收口在一個端口上。這篇文章我就把lws的多協(xié)議機(jī)制從數(shù)據(jù)結(jié)構(gòu)、回調(diào)分發(fā)到實際編碼完整捋一遍適合正在折騰C語言網(wǎng)絡(luò)服務(wù)、或者想把服務(wù)端部署結(jié)構(gòu)做簡單的開發(fā)者看。1. 先搞明白libwebsockets的多協(xié)議到底“多”的是什么1.1 三個層次context、vhost 與 wsi想理解lws的多協(xié)議得先接受它分層的抽象模型。最頂層是lws_context它是一個全局的服務(wù)實例負(fù)責(zé)管理事件循環(huán)、TLS配置、內(nèi)存池和所有監(jiān)聽套接字。一個進(jìn)程一般只創(chuàng)建一個context。中間層是lws_vhost每個vhost可以理解為“一組監(jiān)聽配置 一組協(xié)議表”它可以綁定一個端口也可以和其他vhost共享同一個端口。最底層是lws_wsi它對應(yīng)一個已經(jīng)建立的連接無論是HTTP請求連接還是WebSocket全雙工連接。多協(xié)議體現(xiàn)在兩個地方一是同一個vhost上可以注冊多個struct lws_protocols這是最直接的多協(xié)議二是同一個context下可以掛多個vhost每個vhost有獨(dú)立的端口和協(xié)議表。兩者疊加你就能在一個進(jìn)程里同時提供“80端口HTTPWebSocket混合服務(wù)”和“443端口HTTPS服務(wù)”而不用拆成多個進(jìn)程。我自己的理解是lws把“協(xié)議”定義為“回調(diào)函數(shù) 會話數(shù)據(jù)格式 接收緩沖區(qū)大小”的組合而不是傳統(tǒng)意義上寫死在代碼里的協(xié)議棧。它通過事件驅(qū)動把所有連接上的數(shù)據(jù)先吃進(jìn)來再根據(jù)連接屬于哪個協(xié)議把數(shù)據(jù)交給你注冊的回調(diào)去處理。1.2 為什么現(xiàn)實中需要多協(xié)議并存單協(xié)議服務(wù)的痛點是拆服務(wù)。比如你做一款I(lǐng)oT設(shè)備管理后臺設(shè)備端需要長連接接收指令Web端需要REST API查詢設(shè)備狀態(tài)前端頁面還得有人發(fā)出靜態(tài)HTML。傳統(tǒng)做法是設(shè)備連接走一個MQTT或自定義TCP服務(wù)REST走Spring Boot靜態(tài)頁面交給Nginx。三個服務(wù)、三個端口、三套部署、三份日志運(yùn)維成本全堆在這。lws的思路是把這些流量統(tǒng)一到一張協(xié)議表里。設(shè)備連接走注冊好的某個WebSocket子協(xié)議REST請求走HTTP協(xié)議回調(diào)靜態(tài)頁面由HTTP協(xié)議內(nèi)部路由。所有連接都在同一個事件循環(huán)里跑所有資源都在同一個進(jìn)程內(nèi)部分配調(diào)試的時候抓一個端口的包就夠了。還有個容易被忽略的場景升級平滑期。你想把老客戶端的HTTP輪詢改成WebSocket推送但是不能一刀切下線HTTP接口。多協(xié)議并存可以讓你在同一個端口上同時保留兩條通道老的繼續(xù)走REST新的走WS等服務(wù)端數(shù)據(jù)統(tǒng)計確認(rèn)遷移比例后再關(guān)掉舊通道。1.3 單端口部署帶來的實際收益有一個非?，F(xiàn)實的收益是TLS證書。如果拆成多個服務(wù)每個HTTPS入口都要單獨(dú)配證書、處理證書續(xù)期。而lws把所有監(jiān)聽都收口在同一個context里TLS證書只加載一次握手邏輯統(tǒng)一走一套。第二個收益是防火墻和端口管理。物聯(lián)網(wǎng)設(shè)備部署在客戶現(xiàn)場網(wǎng)管只給你開一個端口的情況非常常見。多協(xié)議合流后80或443一個端口就能同時承擔(dān)設(shè)備長連接、控制命令下發(fā)、固件下載、狀態(tài)查詢這些所有工作不用去跟客戶IT部門反復(fù)磨端口。第三個收益是內(nèi)存和線程的資源復(fù)用。lws默認(rèn)是單線程事件循環(huán)連接多起來之后不需要像多線程模型那樣為每個連接分配線程棧。協(xié)議再多共享的還是同一套內(nèi)存池和poll循環(huán)。這一點在資源受限的嵌入式環(huán)境里尤其值錢。2. 核心機(jī)制拆解protocols數(shù)組、回調(diào)與事件循環(huán)2.1 struct lws_protocols 的字段到底在控什么多協(xié)議最終都會落到一個struct lws_protocols數(shù)組數(shù)組里每一項定義一套協(xié)議。這個結(jié)構(gòu)體的核心字段如下struct lws_protocols { const char *name; /* 協(xié)議名字用于子協(xié)議匹配 */ lws_callback_function *callback; /* 該協(xié)議的回調(diào)函數(shù) */ size_t per_session_data_size; /* 每個連接私有數(shù)據(jù)的字節(jié)數(shù) */ size_t rx_buffer_size; /* 接收緩沖區(qū)大小 */ unsigned int id; /* 自定義id方便區(qū)分是哪個協(xié)議 */ void *user; /* 協(xié)議級共享數(shù)據(jù)指針 */ size_t tx_packet_size; /* 發(fā)送分片大小一般為0用默認(rèn)值 */ unsigned int pkt_sequential; /* 是否順序處理發(fā)送包 */ };name字段不只是給人看的。WebSocket握手時客戶端請求頭可以帶Sec-WebSocket-Protocol服務(wù)端就是拿它跟數(shù)組里的name逐個做字符串匹配。callback不用多解釋協(xié)議所有事件都會進(jìn)這個函數(shù)。per_session_data_size是關(guān)鍵lws每接收一個新連接就會按這個大小給連接分配一塊獨(dú)立內(nèi)存然后把這塊內(nèi)存的首地址通過回調(diào)函數(shù)的user參數(shù)傳給你。這相當(dāng)于框架幫你做了會話隔離。rx_buffer_size決定lws從內(nèi)核讀數(shù)據(jù)時緩沖區(qū)的上限。如果業(yè)務(wù)消息很大這里設(shè)小了會觸發(fā)分塊回調(diào)增加協(xié)議處理復(fù)雜度。我一般習(xí)慣直接設(shè)成業(yè)務(wù)最大消息尺寸比如聊天服務(wù)設(shè)成4096或8192。2.2 回調(diào)是什么時候、被誰調(diào)用的lws內(nèi)部維護(hù)一個poll循環(huán)典型代碼就是while (lws_service(context, 50) 0);lws_service會等待并處理所有已注冊的fd。每當(dāng)某個連接上有數(shù)據(jù)可讀、可寫或者關(guān)閉事件lws會根據(jù)這個連接保存在wsi里的協(xié)議指針找到對應(yīng)的回調(diào)函數(shù)和會話數(shù)據(jù)然后調(diào)用int callback(struct lws *wsi, enum lws_callback_reasons reason, void *user, void *in, size_t len);reason是回調(diào)原因枚舉常見的有LWS_CALLBACK_ESTABLISHED連接建立、LWS_CALLBACK_RECEIVE收到數(shù)據(jù)、LWS_CALLBACK_SERVER_WRITEABLE可以寫數(shù)據(jù)了、LWS_CALLBACK_CLOSED連接關(guān)閉。你不需要自己在業(yè)務(wù)代碼里管理fd事件框架把“什么時候調(diào)”這件事全部接管了。這里有一個對多協(xié)議極其重要的結(jié)論不管注冊了多少個協(xié)議回調(diào)都跑在同一個線程里、同一個循環(huán)里。這是好事因為你的業(yè)務(wù)邏輯天然不需要加鎖。但也意味著任何一個回調(diào)里出現(xiàn)了阻塞操作比如sleep(1)、或者做數(shù)據(jù)庫同步查詢整個服務(wù)的所有協(xié)議都會被拖慢。我見過一個同事在WS收到設(shè)備數(shù)據(jù)后直接同步發(fā)了一個HTTP請求去別的服務(wù)結(jié)果所有在線設(shè)備都開始延遲排查了半天。2.3 多協(xié)議在握手階段怎么定位HTTP升級與子協(xié)議協(xié)商客戶端訪問一個地址第一個請求往往是HTTP。lws內(nèi)部先按HTTP協(xié)議解析請求頭然后根據(jù)請求頭里的字段決定把這連接交給哪套邏輯。如果是一個普通HTTP請求連接保持HTTP角色事件進(jìn)HTTP協(xié)議回調(diào)。如果客戶端請求頭里有Upgrade: websocket、Connection: Upgrade和Sec-WebSocket-Protocollws就會進(jìn)入WebSocket角色的升級流程。這個流程里最重要的匹配邏輯是子協(xié)議協(xié)商。舉個例子?？蛻舳税l(fā)來GET /ws/chat HTTP/1.1 Host: 192.168.1.10:8080 Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: xxxxx Sec-WebSocket-Version: 13 Sec-WebSocket-Protocol: chat-wslws在protocols數(shù)組里找name等于chat-ws的項。找到了就把連接掛到這個協(xié)議下回給客戶端HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Protocol: chat-ws從這一刻起這個連接上后續(xù)的數(shù)據(jù)收發(fā)都只走chat-ws協(xié)議的回調(diào)。沒找到匹配項lws默認(rèn)會拒絕升級返回握手失敗。如果你的協(xié)議數(shù)組第一個是HTTP協(xié)議而客戶端恰好沒帶子協(xié)議連接就會落入HTTP協(xié)議作為普通請求處理。2.4 一句話總結(jié)協(xié)議選擇規(guī)則規(guī)則的底層邏輯其實很簡單協(xié)議是按“連接”綁定的不是按數(shù)據(jù)包綁定的。一個連接一旦經(jīng)過握手確定了協(xié)議后續(xù)所有包都是同一協(xié)議。多協(xié)議維護(hù)的本質(zhì)是維護(hù)一張“名字到回調(diào)集合”的映射表lws在握手階段查表在后續(xù)事件里查表查到的回調(diào)只管處理這個連接。搞清楚這條主線后面看代碼就會很順。3. 實操復(fù)現(xiàn)寫一個HTTPWebSocket靜態(tài)頁面的多協(xié)議服務(wù)3.1 設(shè)計一個混合接入的業(yè)務(wù)場景這次我把目標(biāo)定得具體一點用一個lws進(jìn)程監(jiān)聽8080端口對外提供三類服務(wù)。第一是REST接口客戶端GET /api/status時返回一段JSON比如當(dāng)前在線設(shè)備數(shù)。第二是WebSocket通道客戶端連接/ws/chat服務(wù)端收到任意文本消息后向所有在線客戶端廣播。第三是靜態(tài)頁面訪問GET /時返回一個最簡單的HTML頁面頁面上用WebSocket連接聊天通道。這三個服務(wù)分別對應(yīng)HTTP協(xié)議、WS協(xié)議但WS和頁面消費(fèi)的是同一個業(yè)務(wù)域。這個場景很典型直接把一個雛形的管理后臺/聊天室/設(shè)備監(jiān)控面板串起來了。3.2 依賴準(zhǔn)備和工程結(jié)構(gòu)環(huán)境準(zhǔn)備不用太復(fù)雜。Ubuntu系統(tǒng)上直接裝庫sudo apt-get install libwebsockets-dev自己編譯的話從官網(wǎng)拉源碼后cmake一把就能過。代碼文件就一個main.c編譯命令gcc -o multi_proto main.c -lwebsockets需要注意頭文件路徑老版本可能是libwebsockets.h新版通常在/usr/include/libwebsockets.h。3.3 完整代碼實現(xiàn)與關(guān)鍵行解讀下面是核心代碼我按模塊拆開講。首先是協(xié)議回調(diào)先寫HTTP協(xié)議回調(diào)#include libwebsockets.h #include string.h #include stdio.h static int client_fds[64]; static int client_count 0; static int callback_http(struct lws *wsi, enum lws_callback_reasons reason, void *user, void *in, size_t len) { char uri[128]; switch (reason) { case LWS_CALLBACK_HTTP: lws_hdr_copy(wsi, uri, sizeof(uri), WSI_TOKEN_GET_URI); if (strcmp(uri, /api/status) 0) { unsigned char buf[LWS_PRE 128]; const char *body {\online\:\12\}; int n sprintf((char *)buf LWS_PRE, HTTP/1.1 200 OK\r\n Content-Type: application/json\r\n Content-Length: %d\r\n \r\n%s, (int)strlen(body), body); lws_write(wsi, buf LWS_PRE, n, LWS_WRITE_HTTP); return 0; } /* 簡單處理靜態(tài)頁面 */ if (strcmp(uri, /) 0) { static const char html[] htmlbody h1lws multi-protocol/h1 /body/html; unsigned char buf[LWS_PRE 512]; int n sprintf((char *)buf LWS_PRE, HTTP/1.1 200 OK\r\n Content-Type: text/html\r\n Content-Length: %d\r\n \r\n%s, (int)strlen(html), html); lws_write(wsi, buf LWS_PRE, n, LWS_WRITE_HTTP); return 0; } return -1; default: break; } return 0; }這里是LWS_CALLBACK_HTTP這個reasonlws在解析完HTTP頭之后會觸發(fā)它。lws_hdr_copy是取請求URI的標(biāo)準(zhǔn)辦法很多人第一次寫lws HTTP服務(wù)都在這里卡住總想從in參數(shù)里拿URI其實URI要從header token里取。接著是WebSocket協(xié)議回調(diào)static int callback_ws(struct lws *wsi, enum lws_callback_reasons reason, void *user, void *in, size_t len) { (void)user; switch (reason) { case LWS_CALLBACK_ESTABLISHED: if (client_count 64) client_fds[client_count] lws_get_socket_fd(wsi); break; case LWS_CALLBACK_RECEIVE: /* 收到消息向所有在線ws客戶端廣播 */ for (int i 0; i client_count; i) { struct lws *target lws_get_peer_wsi(wsi); /* 簡化真實場景應(yīng)保存wsi */ } /* 強(qiáng)制所有客戶端可寫延遲到writeable回調(diào)里發(fā)送 */ for (int i 0; i client_count; i) { /* 需要一個保存lws指針的靜態(tài)數(shù)組我這里先展示思路 */ } break; case LWS_CALLBACK_CLOSED: /* 移除斷開連接 */ break; default: break; } return 0; }上面這段我故意留了簡化痕跡真實項目里不能只存socket fd因為lws的wsi才是操作句柄。正確的做法是保存struct lws *指針數(shù)組然后在writeable回調(diào)中發(fā)送。但這行代碼主要是讓你看清協(xié)議回調(diào)的骨架。我下面給一個能真正運(yùn)行的正確版本思路在ESTABLISHED里把wsi指針存進(jìn)靜態(tài)數(shù)組在RECEIVE里逐一對每個wsi調(diào)用lws_callback_on_writable然后在LWS_CALLBACK_SERVER_WRITEABLE里用lws_write把緩存的數(shù)據(jù)發(fā)出去。協(xié)議表和主函數(shù)static struct lws_protocols protocols[] { { http, callback_http, sizeof(void *), 4096, 0, NULL, 0 }, { chat-ws, callback_ws, sizeof(void *), 4096, 0, NULL, 0 }, { NULL, NULL, 0, 0, 0, NULL, 0 } }; int main(void) { struct lws_context_creation_info info; memset(info, 0, sizeof(info)); info.port 8080; info.protocols protocols; info.gid -1; info.uid -1; struct lws_context *context lws_create_context(info); if (!context) { fprintf(stderr, create context failed\n); return 1; } while (lws_service(context, 50) 0); lws_context_destroy(context); return 0; }協(xié)議表最后一項必須是空的{ NULL, NULL, 0, 0, 0, NULL, 0 }這是結(jié)束標(biāo)記漏了會崩。兩個協(xié)議掛在同一個vhost下這也是多協(xié)議最基礎(chǔ)的使用姿勢。3.4 編譯、啟動和驗證代碼保存好之后直接編譯運(yùn)行然后分三路驗證。HTTP驗證curl http://127.0.0.1:8080/api/status能看到{online:12}說明HTTP協(xié)議回調(diào)生效。WebSocket驗證我推薦用websocat或wscatwscat -c ws://127.0.0.1:8080/ws/chat --header Sec-WebSocket-Protocol: chat-ws連上之后再開一個終端同樣連接在任一端輸入字符串看另一端是否收到。如果收到說明子協(xié)議協(xié)商成功WS協(xié)議的回調(diào)正確觸發(fā)。靜態(tài)頁面驗證curl http://127.0.0.1:8080/返回HTML就說明HTTP協(xié)議里的URI路由也正常工作。你可以在瀏覽器里打開這個頁面然后看控制臺能不能建立WS連接這樣三類服務(wù)就在一個端口上完成了合流。3.5 還不夠的話多個vhost與多端口有時候同一套協(xié)議不能滿足兩個業(yè)務(wù)域的需求比如一個進(jìn)程既要給內(nèi)部管理端提供HTTP接口又要給外部設(shè)備提供長連接兩邊鑒權(quán)邏輯完全不一樣。這時可以在同一個context下創(chuàng)建多個vhost。API大致是這樣struct lws_context_creation_info info; memset(info, 0, sizeof(info)); info.port 8080; info.protocols internal_protocols; context lws_create_context(info); struct lws_vhost *vhost2 lws_create_vhost(context, info2);info2里設(shè)置port 8081、protocols device_protocols。這樣一個進(jìn)程監(jiān)聽兩個端口兩套協(xié)議表互相隔離但共享同一個事件循環(huán)和TLS配置參數(shù)。實際部署里這種手法常用于區(qū)分內(nèi)部流量和外部流量。4. 多協(xié)議協(xié)作的三個關(guān)鍵細(xì)節(jié)數(shù)據(jù)隔離、共享與切換4.1 per_session_data_size 是協(xié)議隔離的基石很多新手看到回調(diào)函數(shù)里的user參數(shù)會一頭霧水。其實它就是每個連接獨(dú)立分配的那塊會話內(nèi)存的首地址。lws在為某個連接初始化協(xié)議時會根據(jù)該協(xié)議的per_session_data_size值分配內(nèi)存。如果你在HTTP協(xié)議里寫struct http_session { char client_ip[48]; int request_count; };然后在protocols數(shù)組里對應(yīng)寫sizeof(struct http_session)那么每個HTTP連接都自動擁有獨(dú)立的http_session實例?；卣{(diào)里你可以安全地把user強(qiáng)轉(zhuǎn)成struct http_session *。WS協(xié)議也可以有完全不同的結(jié)構(gòu)struct ws_session { char username[32]; int room_id; int last_ping; };兩者的會話數(shù)據(jù)結(jié)構(gòu)完全不同但因為協(xié)議表把它們分開了lws為每個連接分配的內(nèi)存類型也就互不干擾。多協(xié)議并存的代碼不會因為數(shù)據(jù)格式不同而互相踩內(nèi)存。這是整個多協(xié)議設(shè)計里最核心的隔離機(jī)制。但要注意user指針在你自己的回調(diào)里不代表“線程安全”。lws默認(rèn)單線程所以沒有問題如果你自己又開了額外的線程去操作這些會話內(nèi)存那還是需要加鎖。4.2 協(xié)議之間共享數(shù)據(jù)的常見套路協(xié)議之間不是完全隔絕的。比如REST接口要查詢當(dāng)前在線設(shè)備數(shù)而這個數(shù)據(jù)是在WS協(xié)議那邊維護(hù)的。怎么做最簡單的辦法是用全局變量或者一個全局結(jié)構(gòu)體。由于lws默認(rèn)單線程你在HTTP回調(diào)里讀、在WS回調(diào)里寫只要都在lws線程內(nèi)就不會有并發(fā)問題。這個共享結(jié)構(gòu)可以是一個計數(shù)器、一個消息隊列、甚至一個訂閱列表。實際項目中更推薦把共享數(shù)據(jù)掛在context級別。創(chuàng)建context時設(shè)置info.user字段回調(diào)里通過lws_context_user(lws_get_context(wsi))拿回來這樣不用全局變量一個進(jìn)程多套實例也不會串?dāng)?shù)據(jù)。4.3 需要切換協(xié)議lws_set_wsi_protocol有一種場景是連接先以HTTP角色進(jìn)來完成某些鑒權(quán)動作后服務(wù)端希望把這個連接升級成自定義的數(shù)據(jù)協(xié)議。lws提供lws_set_wsi_protocol(wsi, target_protocol)可以做協(xié)議切換但要注意切換后的回調(diào)生命周期管理它會觸發(fā)舊協(xié)議的關(guān)閉流程同時初始化新協(xié)議的會話數(shù)據(jù)。不過必須提醒這種動態(tài)切換不能跟WebSocket握手升級混為一談。WebSocket握手升級用的是HTTP Upgrade機(jī)制一般不在業(yè)務(wù)代碼里手動調(diào)用而lws_set_wsi_protocol多用于運(yùn)行過程中為連接動態(tài)換綁協(xié)議。我實際使用中的體會是能通過握手階段把協(xié)議定好就別拖到運(yùn)行中再換換協(xié)議牽扯的邊界情況很多比如接收緩沖區(qū)里殘留的數(shù)據(jù)、TLS狀態(tài)下重新協(xié)商的時序處理不好容易留下隱蔽bug。4.4 寫回數(shù)據(jù)的正確姿勢多協(xié)議服務(wù)里跨協(xié)議推送最容易寫錯。很多初學(xué)者在HTTP回調(diào)里拿到一條請求想立刻向所有WS連接發(fā)消息就嘗試直接遍歷WS連接并調(diào)用lws_write。這在lws里是不安全的因為在當(dāng)前回調(diào)流程里目標(biāo)wsi可能正處于不可寫狀態(tài)。正確姿勢是先把數(shù)據(jù)存到共享區(qū)然后對目標(biāo)wsi調(diào)用lws_callback_on_writable(wsi)把“可寫”事件掛到事件循環(huán)上。等lws服務(wù)到這個wsi時會觸發(fā)目標(biāo)協(xié)議的LWS_CALLBACK_SERVER_WRITEABLE回調(diào)你在這個回調(diào)里統(tǒng)一lws_write。這套機(jī)制的好處是發(fā)數(shù)據(jù)這個動作永遠(yuǎn)發(fā)生在目標(biāo)wsi自己的協(xié)議上下文里不會跨協(xié)議直接操作對方內(nèi)部狀態(tài)。5. 實戰(zhàn)中容易踩的五個坑以及排查思路5.1 問題速查表現(xiàn)象常見原因解決思路所有連接周期性卡頓某個協(xié)議回調(diào)里有阻塞操作檢查回調(diào)里有沒有sleep、同步鎖、同步網(wǎng)絡(luò)請求WebSocket握手總是失敗protocols數(shù)組里沒有匹配的子協(xié)議名確認(rèn)客戶端Sec-WebSocket-Protocol與數(shù)組name完全一致收到數(shù)據(jù)不完整rx_buffer_size小于單次業(yè)務(wù)包調(diào)大rx_buffer_size或用LWS_CALLBACK_RECEIVE分幀邏輯重組兩個協(xié)議互相串?dāng)?shù)據(jù)per_session_data_size設(shè)置錯誤確認(rèn)每個協(xié)議的會話結(jié)構(gòu)體大小正確回調(diào)里強(qiáng)轉(zhuǎn)類型要對應(yīng)新協(xié)議加入后行為異常協(xié)議表順序或結(jié)束標(biāo)記問題保留最后的空協(xié)議項檢查第一個非空協(xié)議是否被誤設(shè)為默認(rèn)協(xié)議5.2 日志與抓包的排查配合lws自身日志非常詳細(xì)。編譯時加-DLWS_LOGGING運(yùn)行前設(shè)置環(huán)境變量export LWS_LOG_LEVEL1023能看到每個連接的握手過程、協(xié)議匹配結(jié)果、read/write事件。排查子協(xié)議協(xié)商問題優(yōu)先看日志里有沒有accept ws或reject標(biāo)記。日志不夠再用網(wǎng)絡(luò)抓包工具看TCP層。抓一次握手包重點看請求頭的Sec-WebSocket-Protocol和服務(wù)端響應(yīng)頭。很多時候問題不在lws代碼而是客戶端帶錯了協(xié)議名字。5.3 保命調(diào)試經(jīng)驗我踩過的最大一個坑是在回調(diào)里做了重計算導(dǎo)致lws無法及時處理內(nèi)核緩沖區(qū)里的數(shù)據(jù)最終觸發(fā)客戶端超時重連。現(xiàn)在我的開發(fā)習(xí)慣是回調(diào)函數(shù)里只做狀態(tài)機(jī)切型和數(shù)據(jù)入隊重活放到獨(dú)立工作線程去處理。進(jìn)程啟動時開幾個worker線程共享一個帶鎖的任務(wù)隊列回調(diào)push任務(wù)后立刻返回。多協(xié)議再多只要保持“回調(diào)快進(jìn)快出”整個服務(wù)的穩(wěn)定性就有保障。另一個經(jīng)驗是新協(xié)議上線先只跑測試端口不要直接混進(jìn)生產(chǎn)vhost。lws的協(xié)議表改變會影響事件循環(huán)的初始化單獨(dú)vhost調(diào)試起來定位問題快很多。等協(xié)議穩(wěn)定了再和主vhost合并。6. 最后分享一點我的使用心得和lws打了幾年交道我最大的感受是它的多協(xié)議能力被嚴(yán)重低估了。很多人把它當(dāng)WebSocket庫用遇到HTTP需求就繞道其實lws的HTTP協(xié)議、靜態(tài)文件服務(wù)、多vhost隔離這些能力拼在一起就是一個小而完整的網(wǎng)關(guān)。做設(shè)備后端這類場景一個lws進(jìn)程把設(shè)備接入、管理API、頁面下發(fā)全部吃掉部署時只需要一個二進(jìn)制、一個配置文件非常省心。如果你接下來想深入建議沿著三條線繼續(xù)抄作業(yè)一是給多協(xié)議服務(wù)加上TLS證書只掛一份四個協(xié)議共享加密通道二是用lws_create_vhost把內(nèi)部API和外部設(shè)備流量徹底分開日志也各走各的三是在回調(diào)里結(jié)合lws自帶的工作隊列把重計算任務(wù)挪出去。等你把這三件事做完再回頭看“多協(xié)議工作”這個概念就會覺得它根本不是某個高級特性而只是lws作為網(wǎng)絡(luò)服務(wù)框架的基礎(chǔ)設(shè)計。 libwebsockets多協(xié)議同端口實戰(zhàn)：HTTP與WebSocket共存機(jī)制解析
libwebsockets我習(xí)慣直接叫它lws最容易被新手忽略的一點是它從來不是一個只能跑WebSocket協(xié)議的庫。它默認(rèn)就支持一個進(jìn)程、一個監(jiān)聽端口上同時掛多套協(xié)議HTTP、WebSocket、甚至H2而且每套協(xié)議都有自己獨(dú)立的狀態(tài)存儲、回調(diào)入口和生命周期管理。這就是標(biāo)題里說的“多協(xié)議工作”。如果你之前只是照著demo把WebSocket跑起來遇到“又要提供REST接口、又要做實時推送、還想順手把靜態(tài)頁面也發(fā)出去”的需求第一反應(yīng)可能是去外面分別起兩個服務(wù)再在前面套一層Nginx。但你完全可以只用一個lws進(jìn)程把所有流量收口在一個端口上。這篇文章我就把lws的多協(xié)議機(jī)制從數(shù)據(jù)結(jié)構(gòu)、回調(diào)分發(fā)到實際編碼完整捋一遍適合正在折騰C語言網(wǎng)絡(luò)服務(wù)、或者想把服務(wù)端部署結(jié)構(gòu)做簡單的開發(fā)者看。1. 先搞明白libwebsockets的多協(xié)議到底“多”的是什么1.1 三個層次context、vhost 與 wsi想理解lws的多協(xié)議得先接受它分層的抽象模型。最頂層是lws_context它是一個全局的服務(wù)實例負(fù)責(zé)管理事件循環(huán)、TLS配置、內(nèi)存池和所有監(jiān)聽套接字。一個進(jìn)程一般只創(chuàng)建一個context。中間層是lws_vhost每個vhost可以理解為“一組監(jiān)聽配置 一組協(xié)議表”它可以綁定一個端口也可以和其他vhost共享同一個端口。最底層是lws_wsi它對應(yīng)一個已經(jīng)建立的連接無論是HTTP請求連接還是WebSocket全雙工連接。多協(xié)議體現(xiàn)在兩個地方一是同一個vhost上可以注冊多個struct lws_protocols這是最直接的多協(xié)議二是同一個context下可以掛多個vhost每個vhost有獨(dú)立的端口和協(xié)議表。兩者疊加你就能在一個進(jìn)程里同時提供“80端口HTTPWebSocket混合服務(wù)”和“443端口HTTPS服務(wù)”而不用拆成多個進(jìn)程。我自己的理解是lws把“協(xié)議”定義為“回調(diào)函數(shù) 會話數(shù)據(jù)格式 接收緩沖區(qū)大小”的組合而不是傳統(tǒng)意義上寫死在代碼里的協(xié)議棧。它通過事件驅(qū)動把所有連接上的數(shù)據(jù)先吃進(jìn)來再根據(jù)連接屬于哪個協(xié)議把數(shù)據(jù)交給你注冊的回調(diào)去處理。1.2 為什么現(xiàn)實中需要多協(xié)議并存單協(xié)議服務(wù)的痛點是拆服務(wù)。比如你做一款I(lǐng)oT設(shè)備管理后臺設(shè)備端需要長連接接收指令Web端需要REST API查詢設(shè)備狀態(tài)前端頁面還得有人發(fā)出靜態(tài)HTML。傳統(tǒng)做法是設(shè)備連接走一個MQTT或自定義TCP服務(wù)REST走Spring Boot靜態(tài)頁面交給Nginx。三個服務(wù)、三個端口、三套部署、三份日志運(yùn)維成本全堆在這。lws的思路是把這些流量統(tǒng)一到一張協(xié)議表里。設(shè)備連接走注冊好的某個WebSocket子協(xié)議REST請求走HTTP協(xié)議回調(diào)靜態(tài)頁面由HTTP協(xié)議內(nèi)部路由。所有連接都在同一個事件循環(huán)里跑所有資源都在同一個進(jìn)程內(nèi)部分配調(diào)試的時候抓一個端口的包就夠了。還有個容易被忽略的場景升級平滑期。你想把老客戶端的HTTP輪詢改成WebSocket推送但是不能一刀切下線HTTP接口。多協(xié)議并存可以讓你在同一個端口上同時保留兩條通道老的繼續(xù)走REST新的走WS等服務(wù)端數(shù)據(jù)統(tǒng)計確認(rèn)遷移比例后再關(guān)掉舊通道。1.3 單端口部署帶來的實際收益有一個非?，F(xiàn)實的收益是TLS證書。如果拆成多個服務(wù)每個HTTPS入口都要單獨(dú)配證書、處理證書續(xù)期。而lws把所有監(jiān)聽都收口在同一個context里TLS證書只加載一次握手邏輯統(tǒng)一走一套。第二個收益是防火墻和端口管理。物聯(lián)網(wǎng)設(shè)備部署在客戶現(xiàn)場網(wǎng)管只給你開一個端口的情況非常常見。多協(xié)議合流后80或443一個端口就能同時承擔(dān)設(shè)備長連接、控制命令下發(fā)、固件下載、狀態(tài)查詢這些所有工作不用去跟客戶IT部門反復(fù)磨端口。第三個收益是內(nèi)存和線程的資源復(fù)用。lws默認(rèn)是單線程事件循環(huán)連接多起來之后不需要像多線程模型那樣為每個連接分配線程棧。協(xié)議再多共享的還是同一套內(nèi)存池和poll循環(huán)。這一點在資源受限的嵌入式環(huán)境里尤其值錢。2. 核心機(jī)制拆解protocols數(shù)組、回調(diào)與事件循環(huán)2.1 struct lws_protocols 的字段到底在控什么多協(xié)議最終都會落到一個struct lws_protocols數(shù)組數(shù)組里每一項定義一套協(xié)議。這個結(jié)構(gòu)體的核心字段如下struct lws_protocols { const char *name; /* 協(xié)議名字用于子協(xié)議匹配 */ lws_callback_function *callback; /* 該協(xié)議的回調(diào)函數(shù) */ size_t per_session_data_size; /* 每個連接私有數(shù)據(jù)的字節(jié)數(shù) */ size_t rx_buffer_size; /* 接收緩沖區(qū)大小 */ unsigned int id; /* 自定義id方便區(qū)分是哪個協(xié)議 */ void *user; /* 協(xié)議級共享數(shù)據(jù)指針 */ size_t tx_packet_size; /* 發(fā)送分片大小一般為0用默認(rèn)值 */ unsigned int pkt_sequential; /* 是否順序處理發(fā)送包 */ };name字段不只是給人看的。WebSocket握手時客戶端請求頭可以帶Sec-WebSocket-Protocol服務(wù)端就是拿它跟數(shù)組里的name逐個做字符串匹配。callback不用多解釋協(xié)議所有事件都會進(jìn)這個函數(shù)。per_session_data_size是關(guān)鍵lws每接收一個新連接就會按這個大小給連接分配一塊獨(dú)立內(nèi)存然后把這塊內(nèi)存的首地址通過回調(diào)函數(shù)的user參數(shù)傳給你。這相當(dāng)于框架幫你做了會話隔離。rx_buffer_size決定lws從內(nèi)核讀數(shù)據(jù)時緩沖區(qū)的上限。如果業(yè)務(wù)消息很大這里設(shè)小了會觸發(fā)分塊回調(diào)增加協(xié)議處理復(fù)雜度。我一般習(xí)慣直接設(shè)成業(yè)務(wù)最大消息尺寸比如聊天服務(wù)設(shè)成4096或8192。2.2 回調(diào)是什么時候、被誰調(diào)用的lws內(nèi)部維護(hù)一個poll循環(huán)典型代碼就是while (lws_service(context, 50) 0);lws_service會等待并處理所有已注冊的fd。每當(dāng)某個連接上有數(shù)據(jù)可讀、可寫或者關(guān)閉事件lws會根據(jù)這個連接保存在wsi里的協(xié)議指針找到對應(yīng)的回調(diào)函數(shù)和會話數(shù)據(jù)然后調(diào)用int callback(struct lws *wsi, enum lws_callback_reasons reason, void *user, void *in, size_t len);reason是回調(diào)原因枚舉常見的有LWS_CALLBACK_ESTABLISHED連接建立、LWS_CALLBACK_RECEIVE收到數(shù)據(jù)、LWS_CALLBACK_SERVER_WRITEABLE可以寫數(shù)據(jù)了、LWS_CALLBACK_CLOSED連接關(guān)閉。你不需要自己在業(yè)務(wù)代碼里管理fd事件框架把“什么時候調(diào)”這件事全部接管了。這里有一個對多協(xié)議極其重要的結(jié)論不管注冊了多少個協(xié)議回調(diào)都跑在同一個線程里、同一個循環(huán)里。這是好事因為你的業(yè)務(wù)邏輯天然不需要加鎖。但也意味著任何一個回調(diào)里出現(xiàn)了阻塞操作比如sleep(1)、或者做數(shù)據(jù)庫同步查詢整個服務(wù)的所有協(xié)議都會被拖慢。我見過一個同事在WS收到設(shè)備數(shù)據(jù)后直接同步發(fā)了一個HTTP請求去別的服務(wù)結(jié)果所有在線設(shè)備都開始延遲排查了半天。2.3 多協(xié)議在握手階段怎么定位HTTP升級與子協(xié)議協(xié)商客戶端訪問一個地址第一個請求往往是HTTP。lws內(nèi)部先按HTTP協(xié)議解析請求頭然后根據(jù)請求頭里的字段決定把這連接交給哪套邏輯。如果是一個普通HTTP請求連接保持HTTP角色事件進(jìn)HTTP協(xié)議回調(diào)。如果客戶端請求頭里有Upgrade: websocket、Connection: Upgrade和Sec-WebSocket-Protocollws就會進(jìn)入WebSocket角色的升級流程。這個流程里最重要的匹配邏輯是子協(xié)議協(xié)商。舉個例子?？蛻舳税l(fā)來GET /ws/chat HTTP/1.1 Host: 192.168.1.10:8080 Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: xxxxx Sec-WebSocket-Version: 13 Sec-WebSocket-Protocol: chat-wslws在protocols數(shù)組里找name等于chat-ws的項。找到了就把連接掛到這個協(xié)議下回給客戶端HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Protocol: chat-ws從這一刻起這個連接上后續(xù)的數(shù)據(jù)收發(fā)都只走chat-ws協(xié)議的回調(diào)。沒找到匹配項lws默認(rèn)會拒絕升級返回握手失敗。如果你的協(xié)議數(shù)組第一個是HTTP協(xié)議而客戶端恰好沒帶子協(xié)議連接就會落入HTTP協(xié)議作為普通請求處理。2.4 一句話總結(jié)協(xié)議選擇規(guī)則規(guī)則的底層邏輯其實很簡單協(xié)議是按“連接”綁定的不是按數(shù)據(jù)包綁定的。一個連接一旦經(jīng)過握手確定了協(xié)議后續(xù)所有包都是同一協(xié)議。多協(xié)議維護(hù)的本質(zhì)是維護(hù)一張“名字到回調(diào)集合”的映射表lws在握手階段查表在后續(xù)事件里查表查到的回調(diào)只管處理這個連接。搞清楚這條主線后面看代碼就會很順。3. 實操復(fù)現(xiàn)寫一個HTTPWebSocket靜態(tài)頁面的多協(xié)議服務(wù)3.1 設(shè)計一個混合接入的業(yè)務(wù)場景這次我把目標(biāo)定得具體一點用一個lws進(jìn)程監(jiān)聽8080端口對外提供三類服務(wù)。第一是REST接口客戶端GET /api/status時返回一段JSON比如當(dāng)前在線設(shè)備數(shù)。第二是WebSocket通道客戶端連接/ws/chat服務(wù)端收到任意文本消息后向所有在線客戶端廣播。第三是靜態(tài)頁面訪問GET /時返回一個最簡單的HTML頁面頁面上用WebSocket連接聊天通道。這三個服務(wù)分別對應(yīng)HTTP協(xié)議、WS協(xié)議但WS和頁面消費(fèi)的是同一個業(yè)務(wù)域。這個場景很典型直接把一個雛形的管理后臺/聊天室/設(shè)備監(jiān)控面板串起來了。3.2 依賴準(zhǔn)備和工程結(jié)構(gòu)環(huán)境準(zhǔn)備不用太復(fù)雜。Ubuntu系統(tǒng)上直接裝庫sudo apt-get install libwebsockets-dev自己編譯的話從官網(wǎng)拉源碼后cmake一把就能過。代碼文件就一個main.c編譯命令gcc -o multi_proto main.c -lwebsockets需要注意頭文件路徑老版本可能是libwebsockets.h新版通常在/usr/include/libwebsockets.h。3.3 完整代碼實現(xiàn)與關(guān)鍵行解讀下面是核心代碼我按模塊拆開講。首先是協(xié)議回調(diào)先寫HTTP協(xié)議回調(diào)#include libwebsockets.h #include string.h #include stdio.h static int client_fds[64]; static int client_count 0; static int callback_http(struct lws *wsi, enum lws_callback_reasons reason, void *user, void *in, size_t len) { char uri[128]; switch (reason) { case LWS_CALLBACK_HTTP: lws_hdr_copy(wsi, uri, sizeof(uri), WSI_TOKEN_GET_URI); if (strcmp(uri, /api/status) 0) { unsigned char buf[LWS_PRE 128]; const char *body {\online\:\12\}; int n sprintf((char *)buf LWS_PRE, HTTP/1.1 200 OK\r\n Content-Type: application/json\r\n Content-Length: %d\r\n \r\n%s, (int)strlen(body), body); lws_write(wsi, buf LWS_PRE, n, LWS_WRITE_HTTP); return 0; } /* 簡單處理靜態(tài)頁面 */ if (strcmp(uri, /) 0) { static const char html[] htmlbody h1lws multi-protocol/h1 /body/html; unsigned char buf[LWS_PRE 512]; int n sprintf((char *)buf LWS_PRE, HTTP/1.1 200 OK\r\n Content-Type: text/html\r\n Content-Length: %d\r\n \r\n%s, (int)strlen(html), html); lws_write(wsi, buf LWS_PRE, n, LWS_WRITE_HTTP); return 0; } return -1; default: break; } return 0; }這里是LWS_CALLBACK_HTTP這個reasonlws在解析完HTTP頭之后會觸發(fā)它。lws_hdr_copy是取請求URI的標(biāo)準(zhǔn)辦法很多人第一次寫lws HTTP服務(wù)都在這里卡住總想從in參數(shù)里拿URI其實URI要從header token里取。接著是WebSocket協(xié)議回調(diào)static int callback_ws(struct lws *wsi, enum lws_callback_reasons reason, void *user, void *in, size_t len) { (void)user; switch (reason) { case LWS_CALLBACK_ESTABLISHED: if (client_count 64) client_fds[client_count] lws_get_socket_fd(wsi); break; case LWS_CALLBACK_RECEIVE: /* 收到消息向所有在線ws客戶端廣播 */ for (int i 0; i client_count; i) { struct lws *target lws_get_peer_wsi(wsi); /* 簡化真實場景應(yīng)保存wsi */ } /* 強(qiáng)制所有客戶端可寫延遲到writeable回調(diào)里發(fā)送 */ for (int i 0; i client_count; i) { /* 需要一個保存lws指針的靜態(tài)數(shù)組我這里先展示思路 */ } break; case LWS_CALLBACK_CLOSED: /* 移除斷開連接 */ break; default: break; } return 0; }上面這段我故意留了簡化痕跡真實項目里不能只存socket fd因為lws的wsi才是操作句柄。正確的做法是保存struct lws *指針數(shù)組然后在writeable回調(diào)中發(fā)送。但這行代碼主要是讓你看清協(xié)議回調(diào)的骨架。我下面給一個能真正運(yùn)行的正確版本思路在ESTABLISHED里把wsi指針存進(jìn)靜態(tài)數(shù)組在RECEIVE里逐一對每個wsi調(diào)用lws_callback_on_writable然后在LWS_CALLBACK_SERVER_WRITEABLE里用lws_write把緩存的數(shù)據(jù)發(fā)出去。協(xié)議表和主函數(shù)static struct lws_protocols protocols[] { { http, callback_http, sizeof(void *), 4096, 0, NULL, 0 }, { chat-ws, callback_ws, sizeof(void *), 4096, 0, NULL, 0 }, { NULL, NULL, 0, 0, 0, NULL, 0 } }; int main(void) { struct lws_context_creation_info info; memset(info, 0, sizeof(info)); info.port 8080; info.protocols protocols; info.gid -1; info.uid -1; struct lws_context *context lws_create_context(info); if (!context) { fprintf(stderr, create context failed\n); return 1; } while (lws_service(context, 50) 0); lws_context_destroy(context); return 0; }協(xié)議表最后一項必須是空的{ NULL, NULL, 0, 0, 0, NULL, 0 }這是結(jié)束標(biāo)記漏了會崩。兩個協(xié)議掛在同一個vhost下這也是多協(xié)議最基礎(chǔ)的使用姿勢。3.4 編譯、啟動和驗證代碼保存好之后直接編譯運(yùn)行然后分三路驗證。HTTP驗證curl http://127.0.0.1:8080/api/status能看到{online:12}說明HTTP協(xié)議回調(diào)生效。WebSocket驗證我推薦用websocat或wscatwscat -c ws://127.0.0.1:8080/ws/chat --header Sec-WebSocket-Protocol: chat-ws連上之后再開一個終端同樣連接在任一端輸入字符串看另一端是否收到。如果收到說明子協(xié)議協(xié)商成功WS協(xié)議的回調(diào)正確觸發(fā)。靜態(tài)頁面驗證curl http://127.0.0.1:8080/返回HTML就說明HTTP協(xié)議里的URI路由也正常工作。你可以在瀏覽器里打開這個頁面然后看控制臺能不能建立WS連接這樣三類服務(wù)就在一個端口上完成了合流。3.5 還不夠的話多個vhost與多端口有時候同一套協(xié)議不能滿足兩個業(yè)務(wù)域的需求比如一個進(jìn)程既要給內(nèi)部管理端提供HTTP接口又要給外部設(shè)備提供長連接兩邊鑒權(quán)邏輯完全不一樣。這時可以在同一個context下創(chuàng)建多個vhost。API大致是這樣struct lws_context_creation_info info; memset(info, 0, sizeof(info)); info.port 8080; info.protocols internal_protocols; context lws_create_context(info); struct lws_vhost *vhost2 lws_create_vhost(context, info2);info2里設(shè)置port 8081、protocols device_protocols。這樣一個進(jìn)程監(jiān)聽兩個端口兩套協(xié)議表互相隔離但共享同一個事件循環(huán)和TLS配置參數(shù)。實際部署里這種手法常用于區(qū)分內(nèi)部流量和外部流量。4. 多協(xié)議協(xié)作的三個關(guān)鍵細(xì)節(jié)數(shù)據(jù)隔離、共享與切換4.1 per_session_data_size 是協(xié)議隔離的基石很多新手看到回調(diào)函數(shù)里的user參數(shù)會一頭霧水。其實它就是每個連接獨(dú)立分配的那塊會話內(nèi)存的首地址。lws在為某個連接初始化協(xié)議時會根據(jù)該協(xié)議的per_session_data_size值分配內(nèi)存。如果你在HTTP協(xié)議里寫struct http_session { char client_ip[48]; int request_count; };然后在protocols數(shù)組里對應(yīng)寫sizeof(struct http_session)那么每個HTTP連接都自動擁有獨(dú)立的http_session實例?；卣{(diào)里你可以安全地把user強(qiáng)轉(zhuǎn)成struct http_session *。WS協(xié)議也可以有完全不同的結(jié)構(gòu)struct ws_session { char username[32]; int room_id; int last_ping; };兩者的會話數(shù)據(jù)結(jié)構(gòu)完全不同但因為協(xié)議表把它們分開了lws為每個連接分配的內(nèi)存類型也就互不干擾。多協(xié)議并存的代碼不會因為數(shù)據(jù)格式不同而互相踩內(nèi)存。這是整個多協(xié)議設(shè)計里最核心的隔離機(jī)制。但要注意user指針在你自己的回調(diào)里不代表“線程安全”。lws默認(rèn)單線程所以沒有問題如果你自己又開了額外的線程去操作這些會話內(nèi)存那還是需要加鎖。4.2 協(xié)議之間共享數(shù)據(jù)的常見套路協(xié)議之間不是完全隔絕的。比如REST接口要查詢當(dāng)前在線設(shè)備數(shù)而這個數(shù)據(jù)是在WS協(xié)議那邊維護(hù)的。怎么做最簡單的辦法是用全局變量或者一個全局結(jié)構(gòu)體。由于lws默認(rèn)單線程你在HTTP回調(diào)里讀、在WS回調(diào)里寫只要都在lws線程內(nèi)就不會有并發(fā)問題。這個共享結(jié)構(gòu)可以是一個計數(shù)器、一個消息隊列、甚至一個訂閱列表。實際項目中更推薦把共享數(shù)據(jù)掛在context級別。創(chuàng)建context時設(shè)置info.user字段回調(diào)里通過lws_context_user(lws_get_context(wsi))拿回來這樣不用全局變量一個進(jìn)程多套實例也不會串?dāng)?shù)據(jù)。4.3 需要切換協(xié)議lws_set_wsi_protocol有一種場景是連接先以HTTP角色進(jìn)來完成某些鑒權(quán)動作后服務(wù)端希望把這個連接升級成自定義的數(shù)據(jù)協(xié)議。lws提供lws_set_wsi_protocol(wsi, target_protocol)可以做協(xié)議切換但要注意切換后的回調(diào)生命周期管理它會觸發(fā)舊協(xié)議的關(guān)閉流程同時初始化新協(xié)議的會話數(shù)據(jù)。不過必須提醒這種動態(tài)切換不能跟WebSocket握手升級混為一談。WebSocket握手升級用的是HTTP Upgrade機(jī)制一般不在業(yè)務(wù)代碼里手動調(diào)用而lws_set_wsi_protocol多用于運(yùn)行過程中為連接動態(tài)換綁協(xié)議。我實際使用中的體會是能通過握手階段把協(xié)議定好就別拖到運(yùn)行中再換換協(xié)議牽扯的邊界情況很多比如接收緩沖區(qū)里殘留的數(shù)據(jù)、TLS狀態(tài)下重新協(xié)商的時序處理不好容易留下隱蔽bug。4.4 寫回數(shù)據(jù)的正確姿勢多協(xié)議服務(wù)里跨協(xié)議推送最容易寫錯。很多初學(xué)者在HTTP回調(diào)里拿到一條請求想立刻向所有WS連接發(fā)消息就嘗試直接遍歷WS連接并調(diào)用lws_write。這在lws里是不安全的因為在當(dāng)前回調(diào)流程里目標(biāo)wsi可能正處于不可寫狀態(tài)。正確姿勢是先把數(shù)據(jù)存到共享區(qū)然后對目標(biāo)wsi調(diào)用lws_callback_on_writable(wsi)把“可寫”事件掛到事件循環(huán)上。等lws服務(wù)到這個wsi時會觸發(fā)目標(biāo)協(xié)議的LWS_CALLBACK_SERVER_WRITEABLE回調(diào)你在這個回調(diào)里統(tǒng)一lws_write。這套機(jī)制的好處是發(fā)數(shù)據(jù)這個動作永遠(yuǎn)發(fā)生在目標(biāo)wsi自己的協(xié)議上下文里不會跨協(xié)議直接操作對方內(nèi)部狀態(tài)。5. 實戰(zhàn)中容易踩的五個坑以及排查思路5.1 問題速查表現(xiàn)象常見原因解決思路所有連接周期性卡頓某個協(xié)議回調(diào)里有阻塞操作檢查回調(diào)里有沒有sleep、同步鎖、同步網(wǎng)絡(luò)請求WebSocket握手總是失敗protocols數(shù)組里沒有匹配的子協(xié)議名確認(rèn)客戶端Sec-WebSocket-Protocol與數(shù)組name完全一致收到數(shù)據(jù)不完整rx_buffer_size小于單次業(yè)務(wù)包調(diào)大rx_buffer_size或用LWS_CALLBACK_RECEIVE分幀邏輯重組兩個協(xié)議互相串?dāng)?shù)據(jù)per_session_data_size設(shè)置錯誤確認(rèn)每個協(xié)議的會話結(jié)構(gòu)體大小正確回調(diào)里強(qiáng)轉(zhuǎn)類型要對應(yīng)新協(xié)議加入后行為異常協(xié)議表順序或結(jié)束標(biāo)記問題保留最后的空協(xié)議項檢查第一個非空協(xié)議是否被誤設(shè)為默認(rèn)協(xié)議5.2 日志與抓包的排查配合lws自身日志非常詳細(xì)。編譯時加-DLWS_LOGGING運(yùn)行前設(shè)置環(huán)境變量export LWS_LOG_LEVEL1023能看到每個連接的握手過程、協(xié)議匹配結(jié)果、read/write事件。排查子協(xié)議協(xié)商問題優(yōu)先看日志里有沒有accept ws或reject標(biāo)記。日志不夠再用網(wǎng)絡(luò)抓包工具看TCP層。抓一次握手包重點看請求頭的Sec-WebSocket-Protocol和服務(wù)端響應(yīng)頭。很多時候問題不在lws代碼而是客戶端帶錯了協(xié)議名字。5.3 保命調(diào)試經(jīng)驗我踩過的最大一個坑是在回調(diào)里做了重計算導(dǎo)致lws無法及時處理內(nèi)核緩沖區(qū)里的數(shù)據(jù)最終觸發(fā)客戶端超時重連。現(xiàn)在我的開發(fā)習(xí)慣是回調(diào)函數(shù)里只做狀態(tài)機(jī)切型和數(shù)據(jù)入隊重活放到獨(dú)立工作線程去處理。進(jìn)程啟動時開幾個worker線程共享一個帶鎖的任務(wù)隊列回調(diào)push任務(wù)后立刻返回。多協(xié)議再多只要保持“回調(diào)快進(jìn)快出”整個服務(wù)的穩(wěn)定性就有保障。另一個經(jīng)驗是新協(xié)議上線先只跑測試端口不要直接混進(jìn)生產(chǎn)vhost。lws的協(xié)議表改變會影響事件循環(huán)的初始化單獨(dú)vhost調(diào)試起來定位問題快很多。等協(xié)議穩(wěn)定了再和主vhost合并。6. 最后分享一點我的使用心得和lws打了幾年交道我最大的感受是它的多協(xié)議能力被嚴(yán)重低估了。很多人把它當(dāng)WebSocket庫用遇到HTTP需求就繞道其實lws的HTTP協(xié)議、靜態(tài)文件服務(wù)、多vhost隔離這些能力拼在一起就是一個小而完整的網(wǎng)關(guān)。做設(shè)備后端這類場景一個lws進(jìn)程把設(shè)備接入、管理API、頁面下發(fā)全部吃掉部署時只需要一個二進(jìn)制、一個配置文件非常省心。如果你接下來想深入建議沿著三條線繼續(xù)抄作業(yè)一是給多協(xié)議服務(wù)加上TLS證書只掛一份四個協(xié)議共享加密通道二是用lws_create_vhost把內(nèi)部API和外部設(shè)備流量徹底分開日志也各走各的三是在回調(diào)里結(jié)合lws自帶的工作隊列把重計算任務(wù)挪出去。等你把這三件事做完再回頭看“多協(xié)議工作”這個概念就會覺得它根本不是某個高級特性而只是lws作為網(wǎng)絡(luò)服務(wù)框架的基礎(chǔ)設(shè)計。