后端網絡【免費下載鏈接】cpp-httplibA C header-only HTTP/HTTPS server and client library項目地址https://gitcode.com/GitHub_Trending/cp/cpp-httplib點擊查看免費下載本篇指南聚焦 cpp-httplib 頭文件庫中 WebSocket 連接的心跳Heartbeat機制如何通過自動發(fā)送 Ping 幀保持長連接不被代理或負載均衡器因空閑而斷開如何利用 Pong 超時max missed pongs檢測靜默失聯(lián)的對端以及如何在服務端與客戶端兩側正確設置心跳間隔。讀完本文你將掌握set_websocket_ping_interval()、set_websocket_max_missed_pongs()兩個核心 API 的用法、編譯期默認宏的調優(yōu)方式以及心跳線程的底層實現(xiàn)原理并能結合倉庫內的測試用例驗證行為。為什么 WebSocket 需要心跳WebSocket 連接通常會保持很長時間。鏈路中間的代理Proxy或負載均衡器Load Balancer往往會在連接長時間空閑idle時將其斷開以回收資源。即便 TCP 連接兩端都還健在中間設備一斷兩端都會失去這條通道。解決思路是在空閑期間周期性地發(fā)送 Ping 控制幀讓連接持續(xù)有流量活躍從而騙過空閑超時判定。RFC 6455 協(xié)議規(guī)定 Ping 幀必須由對端以 Pong 幀應答這正是 WebSocket 協(xié)議自帶的?；顧C制。cpp-httplib 把這件事做成了內置能力你只需要設置一個間隔庫就會自動定時發(fā)送 Ping 幀無需在應用代碼里手工處理。服務端設置心跳間隔服務端通過Server::set_websocket_ping_interval()設置心跳間隔單位是秒。設置在WebSocket()注冊路由之前或之后均可它作用于該服務端接受的所有 WebSocket 連接httplib::Server svr; svr.set_websocket_ping_interval(30); // 每 30 秒發(fā)送一次 Ping svr.WebSocket(/chat, [](const auto req, auto ws) { // ... });只需傳入以秒為單位的間隔。此后該服務端接受的每條 WebSocket 連接都會按這個間隔被自動 Ping 一次。該接口還提供std::chrono重載語義完全等價using namespace std::chrono_literals; svr.set_websocket_ping_interval(30s);從源碼看chrono 重載會通過detail::duration_to_sec_and_usec()把時長換算成秒后落到同一個time_t版本最終寫入成員websocket_ping_interval_sec_見 httplib.h。服務端在升級握手完成后構造ws::WebSocket時會把該成員連同websocket_max_missed_pongs_一起傳給每個連接見 httplib.h所以這個設置是服務端全局生效的?？蛻舳嗽O置心跳間隔客戶端的 API 與服務端完全一致WebSocketClient同樣提供set_websocket_ping_interval()httplib::ws::WebSocketClient cli(ws://localhost:8080/chat); cli.set_websocket_ping_interval(30); cli.connect();注意客戶端必須在調用connect()之前設置。源碼中WebSocketClient::set_websocket_ping_interval()只寫入成員websocket_ping_interval_sec_見 httplib.h實際的心跳線程是在連接建立、ws::WebSocket對象構造時啟動的因此 connect 之后再改間隔不會生效。同理WebSocketClient::set_websocket_max_missed_pongs()也必須在connect()之前調用見 httplib.h。默認值編譯期宏 CPPHTTPLIB_WEBSOCKET_PING_INTERVAL_SECOND默認心跳間隔由編譯期宏CPPHTTPLIB_WEBSOCKET_PING_INTERVAL_SECOND決定在 httplib.h 中定義默認值為30 秒#ifndef CPPHTTPLIB_WEBSOCKET_PING_INTERVAL_SECOND #define CPPHTTPLIB_WEBSOCKET_PING_INTERVAL_SECOND 30 #endif通常不需要改動這個宏——運行時調用set_websocket_ping_interval()即可覆蓋默認值。但如果你的部署環(huán)境面臨非常激進的代理空閑超時很短可以把它調低例如在編譯時通過-DCPPHTTPLIB_WEBSOCKET_PING_INTERVAL_SECOND15全局生效。與心跳相關的還有一組編譯期宏同樣位于 httplib.h在調參時值得一并了解宏默認值說明CPPHTTPLIB_WEBSOCKET_PING_INTERVAL_SECOND30自動 Ping 心跳間隔秒CPPHTTPLIB_WEBSOCKET_MAX_MISSED_PONGS0禁用連續(xù) N 次 Ping 無 Pong 應答后關閉連接CPPHTTPLIB_WEBSOCKET_SERVER_READ_TIMEOUT_SECOND300服務端讀取超時兜底秒CPPHTTPLIB_WEBSOCKET_CLIENT_READ_TIMEOUT_SECOND0客戶端讀取超時秒0表示永遠等待CPPHTTPLIB_WEBSOCKET_CLOSE_TIMEOUT_SECOND5等待對端 Close 應答的超時秒Pong 自動應答應用代碼無需關心WebSocket 協(xié)議要求 Ping 幀必須以 Pong 幀應答。cpp-httplib 對此是全自動處理的——無論服務端還是客戶端收到 Ping 幀都會在內部直接回送 Pong應用代碼完全不需要參與。從 httplib.h 的WebSocket::read()實現(xiàn)可以看到當解析出的幀是Opcode::Ping時庫會在寫鎖保護下立即把相同的載荷以Opcode::Pong寫回當收到Opcode::Pong時則會把未應答計數unacked_pings_清零這一點對后面的失聯(lián)檢測至關重要。這些處理發(fā)生在read()內部所以只要你的應用代碼在正常的read()循環(huán)中對端的 Ping 就會被自動應答。如何選擇心跳間隔間隔的選擇需要在?；钚Чc帶寬/CPU 開銷之間權衡。原文檔給出了基于環(huán)境的建議值環(huán)境建議間隔普通互聯(lián)網30–60 秒嚴格代理如 AWS ALB15–30 秒移動網絡60 秒以上過短會額外耗電間隔太短會浪費帶寬并增加 CPU 開銷太長則可能在中間設備判定空閑之前來不及續(xù)命導致連接被斷開。經驗法則是把間隔設為你與客戶端之間鏈路空閑超時的一半左右。需要特別注意的是過短的心跳間隔會為每一條連接都產生周期性的后臺工作從而推高 CPU 占用。對于連接數很多的服務器請保持一個適中的間隔見原文檔的 Warning。檢測無響應的對端max missed pongs僅發(fā)送 Ping 并不能告訴你對端是否還活著——如果對端進程已經崩潰但 TCP 連接尚未被系統(tǒng)回收socket 看起來仍是打開的Ping 發(fā)出去也無人應答。要抓住這種情況需要啟用最大未應答 Ping 數檢查當連續(xù) N 次 Ping 都沒有收到 Pong 時連接將被關閉。cli.set_websocket_max_missed_pongs(2); // 連續(xù) 2 次 Ping 無應答即關閉服務端也有完全相同的set_websocket_max_missed_pongs()見 httplib.h。心跳線程的實現(xiàn)邏輯在WebSocket::start_heartbeat()見 httplib.hinline void WebSocket::start_heartbeat() { if (ping_interval_sec_ 0) { return; } // 間隔為 0 則完全禁用心跳 ping_thread_ std::thread([this]() { std::unique_lockstd::mutex lock(ping_mutex_); while (!closed_) { ping_cv_.wait_for(lock, std::chrono::seconds(ping_interval_sec_)); if (closed_) { break; } // 連續(xù)未應答數達到上限時主動關閉連接 if (max_missed_pongs_ 0 unacked_pings_ max_missed_pongs_) { lock.unlock(); close(CloseStatus::GoingAway, pong timeout); return; } lock.unlock(); if (!send_frame(Opcode::Ping, nullptr, 0)) { // 發(fā)送失敗也關閉 lock.lock(); closed_ true; break; } lock.lock(); unacked_pings_; // 每次發(fā)出 Ping 后計數加 1 } }); }關鍵點在于每經過一個ping_interval_sec_周期心跳線程發(fā)出一個 Ping 幀并把unacked_pings_加 1當read()消費到對端的 Pong 幀時unacked_pings_被清零一旦unacked_pings_達到max_missed_pongs_心跳線程以CloseStatus::GoingAway和原因pong timeout主動關閉連接。以 30 秒心跳間隔、max_missed_pongs 2為例對端死亡后約 60 秒內即可被檢測到連接以CloseStatus::GoingAway、原因為pong timeout關閉。前提條件計數器只有在read()真正消費到 Pong 幀時才會重置所以該機制只有在你持續(xù)調用read()循環(huán)時才生效——這正是正常 WebSocket 客戶端/服務端代碼的常見寫法。為什么默認值是 0max_missed_pongs默認值為0含義是永遠不因缺少 Pong 而關閉連接。此時 Ping 幀仍會按心跳間隔照常發(fā)送保持連接活躍但它們的應答不會被檢查。即使為0服務端的死連接也不會永遠滯留當 handler 阻塞在read()內時編譯期宏CPPHTTPLIB_WEBSOCKET_SERVER_READ_TIMEOUT_SECOND默認300 秒 5 分鐘充當兜底——服務端在升級握手后會把流讀取超時設置為該值見 httplib.h超時后read()返回Fail并關閉連接?？蛻舳藙t沒有任何內置兜底——除非你自己調用set_read_timeout()否則它會無限期等待。因此對客戶端而言max_missed_pongs是唯一能感知無響應對端的機制對服務端而言max_missed_pongs是比 5 分鐘兜底更快地發(fā)現(xiàn)失聯(lián)對端的手段。如果你需要失聯(lián)檢測請顯式把它設置為1或更大的值。心跳線程模型與開銷cpp-httplib 的 WebSocket 實現(xiàn)是阻塞 I/O、每連接一個線程外加每連接一個心跳線程的模型見 README-websocket.md。start_heartbeat()會為每條連接創(chuàng)建獨立的心跳線程它通過條件變量ping_cv_定時喚醒與處理read()的應用線程并發(fā)工作。這也是原文檔警告過短的心跳間隔會為每連接引入后臺工作、增加 CPU 占用的根源連接數越多、心跳越頻繁心跳線程喚醒與寫幀的開銷越大。對于大規(guī)模并發(fā)連接場景應把間隔保持在合理范圍內需要多線程并發(fā)讀寫的場景如一個線程read()、另一個線程send()/close()在庫內是受支持的心跳線程的 Ping 與你的read()循環(huán)共享寫路徑庫內部已做串行化處理。測試用例驗證倉庫在 test/test_websocket_heartbeat.cc 中提供了專門針對心跳行為的獨立測試。該文件在編譯時通過宏把間隔壓縮為 1 秒#define CPPHTTPLIB_WEBSOCKET_PING_INTERVAL_SECOND 1見 L5-L7從而可以在數秒內驗證本需要 30 秒才可見的行為測試還設置了 3 秒的讀寫超時來對照。其覆蓋的場景與本文講解一一對應IdleConnectionStaysAlive空閑連接靠 1 秒心跳活過 3 秒讀超時5 秒后仍能正常收發(fā)消息L43-L61RuntimePingIntervalOverride客戶端set_websocket_ping_interval(2)覆蓋編譯期默認L64-L81ZeroDisablesHeartbeatset_websocket_ping_interval(0)禁用心跳但不破壞基本收發(fā)L84-L96ServerRuntimeInterval服務端運行時設置 2 秒間隔同樣生效L125-L140ClientDetectsNonResponsivePeer服務端禁用心跳且 handler 不調用read()不產生自動 Pong客戶端設max_missed_pongs 2后在約 3 秒內自行關閉L179-L195ResponsivePeerNeverTimesOut正常交互的對端即使max_missed_pongs 2也不會被誤殺——read()持續(xù)消費 Pong 重置計數L271-L290BackstopEndsHandlerLoop服務端讀超時兜底觸發(fā)后while (ws.read(msg))循環(huán)按預期結束L246-L265。這些測試通過test/Makefile中的test_websocket_heartbeat目標編譯運行見 test/Makefile可直接作為心跳行為是否如本文所述的驗證依據。相關文檔連接關閉包括如何區(qū)分主動關閉與被踢下線、處理CloseStatus與關閉原因是心跳機制的自然延伸請參見 W03. Handle connection closeWebSocket 的整體 API 與線程模型可參閱 README-websocket.md完整的可運行示例見 example/wsecho.cc。贊分享后端網絡【免費下載鏈接】cpp-httplibA C header-only HTTP/HTTPS server and client library項目地址https://gitcode.com/GitHub_Trending/cp/cpp-httplib點擊查看免費下載相關推薦Camunda DMN 模型 API 詳解基于 DMN 1.1 Schema 的 Java 決策模型讀寫引擎Camunda DMN 模型 API 詳解基于 DMN 1.1 Schema 的 Java 決策模型讀寫引擎 camunda dmn model 是 Camu后端網絡WebSocket庫連接管理Ping-Pong機制與心跳檢測終極指南WebSocket庫連接管理Ping Pong機制與心跳檢測終極指南 在現(xiàn)代Web應用中實時通信已成為不可或缺的功能。WebSocket作為一種全雙工通信協(xié)后端SocketRocket ping/pong機制保持WebSocket連接活性SocketRocket ping/pong機制保持WebSocket連接活性 在移動應用開發(fā)中WebSocket套接字連接經常因網絡不穩(wěn)定或服務器超時網絡通信上一篇Hyperopt與其他優(yōu)化庫對比5大超參優(yōu)化工具深度評測下一篇5分鐘快速上手Sionna構建你的第一個5G通信系統(tǒng)仿真創(chuàng)作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考 cpp-httplib WebSocket 心跳配置指南：Ping/Pong ?；钆c無響應對端檢測
后端網絡【免費下載鏈接】cpp-httplibA C header-only HTTP/HTTPS server and client library項目地址https://gitcode.com/GitHub_Trending/cp/cpp-httplib點擊查看免費下載本篇指南聚焦 cpp-httplib 頭文件庫中 WebSocket 連接的心跳Heartbeat機制如何通過自動發(fā)送 Ping 幀保持長連接不被代理或負載均衡器因空閑而斷開如何利用 Pong 超時max missed pongs檢測靜默失聯(lián)的對端以及如何在服務端與客戶端兩側正確設置心跳間隔。讀完本文你將掌握set_websocket_ping_interval()、set_websocket_max_missed_pongs()兩個核心 API 的用法、編譯期默認宏的調優(yōu)方式以及心跳線程的底層實現(xiàn)原理并能結合倉庫內的測試用例驗證行為。為什么 WebSocket 需要心跳WebSocket 連接通常會保持很長時間。鏈路中間的代理Proxy或負載均衡器Load Balancer往往會在連接長時間空閑idle時將其斷開以回收資源。即便 TCP 連接兩端都還健在中間設備一斷兩端都會失去這條通道。解決思路是在空閑期間周期性地發(fā)送 Ping 控制幀讓連接持續(xù)有流量活躍從而騙過空閑超時判定。RFC 6455 協(xié)議規(guī)定 Ping 幀必須由對端以 Pong 幀應答這正是 WebSocket 協(xié)議自帶的?；顧C制。cpp-httplib 把這件事做成了內置能力你只需要設置一個間隔庫就會自動定時發(fā)送 Ping 幀無需在應用代碼里手工處理。服務端設置心跳間隔服務端通過Server::set_websocket_ping_interval()設置心跳間隔單位是秒。設置在WebSocket()注冊路由之前或之后均可它作用于該服務端接受的所有 WebSocket 連接httplib::Server svr; svr.set_websocket_ping_interval(30); // 每 30 秒發(fā)送一次 Ping svr.WebSocket(/chat, [](const auto req, auto ws) { // ... });只需傳入以秒為單位的間隔。此后該服務端接受的每條 WebSocket 連接都會按這個間隔被自動 Ping 一次。該接口還提供std::chrono重載語義完全等價using namespace std::chrono_literals; svr.set_websocket_ping_interval(30s);從源碼看chrono 重載會通過detail::duration_to_sec_and_usec()把時長換算成秒后落到同一個time_t版本最終寫入成員websocket_ping_interval_sec_見 httplib.h。服務端在升級握手完成后構造ws::WebSocket時會把該成員連同websocket_max_missed_pongs_一起傳給每個連接見 httplib.h所以這個設置是服務端全局生效的?？蛻舳嗽O置心跳間隔客戶端的 API 與服務端完全一致WebSocketClient同樣提供set_websocket_ping_interval()httplib::ws::WebSocketClient cli(ws://localhost:8080/chat); cli.set_websocket_ping_interval(30); cli.connect();注意客戶端必須在調用connect()之前設置。源碼中WebSocketClient::set_websocket_ping_interval()只寫入成員websocket_ping_interval_sec_見 httplib.h實際的心跳線程是在連接建立、ws::WebSocket對象構造時啟動的因此 connect 之后再改間隔不會生效。同理WebSocketClient::set_websocket_max_missed_pongs()也必須在connect()之前調用見 httplib.h。默認值編譯期宏 CPPHTTPLIB_WEBSOCKET_PING_INTERVAL_SECOND默認心跳間隔由編譯期宏CPPHTTPLIB_WEBSOCKET_PING_INTERVAL_SECOND決定在 httplib.h 中定義默認值為30 秒#ifndef CPPHTTPLIB_WEBSOCKET_PING_INTERVAL_SECOND #define CPPHTTPLIB_WEBSOCKET_PING_INTERVAL_SECOND 30 #endif通常不需要改動這個宏——運行時調用set_websocket_ping_interval()即可覆蓋默認值。但如果你的部署環(huán)境面臨非常激進的代理空閑超時很短可以把它調低例如在編譯時通過-DCPPHTTPLIB_WEBSOCKET_PING_INTERVAL_SECOND15全局生效。與心跳相關的還有一組編譯期宏同樣位于 httplib.h在調參時值得一并了解宏默認值說明CPPHTTPLIB_WEBSOCKET_PING_INTERVAL_SECOND30自動 Ping 心跳間隔秒CPPHTTPLIB_WEBSOCKET_MAX_MISSED_PONGS0禁用連續(xù) N 次 Ping 無 Pong 應答后關閉連接CPPHTTPLIB_WEBSOCKET_SERVER_READ_TIMEOUT_SECOND300服務端讀取超時兜底秒CPPHTTPLIB_WEBSOCKET_CLIENT_READ_TIMEOUT_SECOND0客戶端讀取超時秒0表示永遠等待CPPHTTPLIB_WEBSOCKET_CLOSE_TIMEOUT_SECOND5等待對端 Close 應答的超時秒Pong 自動應答應用代碼無需關心WebSocket 協(xié)議要求 Ping 幀必須以 Pong 幀應答。cpp-httplib 對此是全自動處理的——無論服務端還是客戶端收到 Ping 幀都會在內部直接回送 Pong應用代碼完全不需要參與。從 httplib.h 的WebSocket::read()實現(xiàn)可以看到當解析出的幀是Opcode::Ping時庫會在寫鎖保護下立即把相同的載荷以Opcode::Pong寫回當收到Opcode::Pong時則會把未應答計數unacked_pings_清零這一點對后面的失聯(lián)檢測至關重要。這些處理發(fā)生在read()內部所以只要你的應用代碼在正常的read()循環(huán)中對端的 Ping 就會被自動應答。如何選擇心跳間隔間隔的選擇需要在?；钚Чc帶寬/CPU 開銷之間權衡。原文檔給出了基于環(huán)境的建議值環(huán)境建議間隔普通互聯(lián)網30–60 秒嚴格代理如 AWS ALB15–30 秒移動網絡60 秒以上過短會額外耗電間隔太短會浪費帶寬并增加 CPU 開銷太長則可能在中間設備判定空閑之前來不及續(xù)命導致連接被斷開。經驗法則是把間隔設為你與客戶端之間鏈路空閑超時的一半左右。需要特別注意的是過短的心跳間隔會為每一條連接都產生周期性的后臺工作從而推高 CPU 占用。對于連接數很多的服務器請保持一個適中的間隔見原文檔的 Warning。檢測無響應的對端max missed pongs僅發(fā)送 Ping 并不能告訴你對端是否還活著——如果對端進程已經崩潰但 TCP 連接尚未被系統(tǒng)回收socket 看起來仍是打開的Ping 發(fā)出去也無人應答。要抓住這種情況需要啟用最大未應答 Ping 數檢查當連續(xù) N 次 Ping 都沒有收到 Pong 時連接將被關閉。cli.set_websocket_max_missed_pongs(2); // 連續(xù) 2 次 Ping 無應答即關閉服務端也有完全相同的set_websocket_max_missed_pongs()見 httplib.h。心跳線程的實現(xiàn)邏輯在WebSocket::start_heartbeat()見 httplib.hinline void WebSocket::start_heartbeat() { if (ping_interval_sec_ 0) { return; } // 間隔為 0 則完全禁用心跳 ping_thread_ std::thread([this]() { std::unique_lockstd::mutex lock(ping_mutex_); while (!closed_) { ping_cv_.wait_for(lock, std::chrono::seconds(ping_interval_sec_)); if (closed_) { break; } // 連續(xù)未應答數達到上限時主動關閉連接 if (max_missed_pongs_ 0 unacked_pings_ max_missed_pongs_) { lock.unlock(); close(CloseStatus::GoingAway, pong timeout); return; } lock.unlock(); if (!send_frame(Opcode::Ping, nullptr, 0)) { // 發(fā)送失敗也關閉 lock.lock(); closed_ true; break; } lock.lock(); unacked_pings_; // 每次發(fā)出 Ping 后計數加 1 } }); }關鍵點在于每經過一個ping_interval_sec_周期心跳線程發(fā)出一個 Ping 幀并把unacked_pings_加 1當read()消費到對端的 Pong 幀時unacked_pings_被清零一旦unacked_pings_達到max_missed_pongs_心跳線程以CloseStatus::GoingAway和原因pong timeout主動關閉連接。以 30 秒心跳間隔、max_missed_pongs 2為例對端死亡后約 60 秒內即可被檢測到連接以CloseStatus::GoingAway、原因為pong timeout關閉。前提條件計數器只有在read()真正消費到 Pong 幀時才會重置所以該機制只有在你持續(xù)調用read()循環(huán)時才生效——這正是正常 WebSocket 客戶端/服務端代碼的常見寫法。為什么默認值是 0max_missed_pongs默認值為0含義是永遠不因缺少 Pong 而關閉連接。此時 Ping 幀仍會按心跳間隔照常發(fā)送保持連接活躍但它們的應答不會被檢查。即使為0服務端的死連接也不會永遠滯留當 handler 阻塞在read()內時編譯期宏CPPHTTPLIB_WEBSOCKET_SERVER_READ_TIMEOUT_SECOND默認300 秒 5 分鐘充當兜底——服務端在升級握手后會把流讀取超時設置為該值見 httplib.h超時后read()返回Fail并關閉連接?？蛻舳藙t沒有任何內置兜底——除非你自己調用set_read_timeout()否則它會無限期等待。因此對客戶端而言max_missed_pongs是唯一能感知無響應對端的機制對服務端而言max_missed_pongs是比 5 分鐘兜底更快地發(fā)現(xiàn)失聯(lián)對端的手段。如果你需要失聯(lián)檢測請顯式把它設置為1或更大的值。心跳線程模型與開銷cpp-httplib 的 WebSocket 實現(xiàn)是阻塞 I/O、每連接一個線程外加每連接一個心跳線程的模型見 README-websocket.md。start_heartbeat()會為每條連接創(chuàng)建獨立的心跳線程它通過條件變量ping_cv_定時喚醒與處理read()的應用線程并發(fā)工作。這也是原文檔警告過短的心跳間隔會為每連接引入后臺工作、增加 CPU 占用的根源連接數越多、心跳越頻繁心跳線程喚醒與寫幀的開銷越大。對于大規(guī)模并發(fā)連接場景應把間隔保持在合理范圍內需要多線程并發(fā)讀寫的場景如一個線程read()、另一個線程send()/close()在庫內是受支持的心跳線程的 Ping 與你的read()循環(huán)共享寫路徑庫內部已做串行化處理。測試用例驗證倉庫在 test/test_websocket_heartbeat.cc 中提供了專門針對心跳行為的獨立測試。該文件在編譯時通過宏把間隔壓縮為 1 秒#define CPPHTTPLIB_WEBSOCKET_PING_INTERVAL_SECOND 1見 L5-L7從而可以在數秒內驗證本需要 30 秒才可見的行為測試還設置了 3 秒的讀寫超時來對照。其覆蓋的場景與本文講解一一對應IdleConnectionStaysAlive空閑連接靠 1 秒心跳活過 3 秒讀超時5 秒后仍能正常收發(fā)消息L43-L61RuntimePingIntervalOverride客戶端set_websocket_ping_interval(2)覆蓋編譯期默認L64-L81ZeroDisablesHeartbeatset_websocket_ping_interval(0)禁用心跳但不破壞基本收發(fā)L84-L96ServerRuntimeInterval服務端運行時設置 2 秒間隔同樣生效L125-L140ClientDetectsNonResponsivePeer服務端禁用心跳且 handler 不調用read()不產生自動 Pong客戶端設max_missed_pongs 2后在約 3 秒內自行關閉L179-L195ResponsivePeerNeverTimesOut正常交互的對端即使max_missed_pongs 2也不會被誤殺——read()持續(xù)消費 Pong 重置計數L271-L290BackstopEndsHandlerLoop服務端讀超時兜底觸發(fā)后while (ws.read(msg))循環(huán)按預期結束L246-L265。這些測試通過test/Makefile中的test_websocket_heartbeat目標編譯運行見 test/Makefile可直接作為心跳行為是否如本文所述的驗證依據。相關文檔連接關閉包括如何區(qū)分主動關閉與被踢下線、處理CloseStatus與關閉原因是心跳機制的自然延伸請參見 W03. Handle connection closeWebSocket 的整體 API 與線程模型可參閱 README-websocket.md完整的可運行示例見 example/wsecho.cc。贊分享后端網絡【免費下載鏈接】cpp-httplibA C header-only HTTP/HTTPS server and client library項目地址https://gitcode.com/GitHub_Trending/cp/cpp-httplib點擊查看免費下載相關推薦Camunda DMN 模型 API 詳解基于 DMN 1.1 Schema 的 Java 決策模型讀寫引擎Camunda DMN 模型 API 詳解基于 DMN 1.1 Schema 的 Java 決策模型讀寫引擎 camunda dmn model 是 Camu后端網絡WebSocket庫連接管理Ping-Pong機制與心跳檢測終極指南WebSocket庫連接管理Ping Pong機制與心跳檢測終極指南 在現(xiàn)代Web應用中實時通信已成為不可或缺的功能。WebSocket作為一種全雙工通信協(xié)后端SocketRocket ping/pong機制保持WebSocket連接活性SocketRocket ping/pong機制保持WebSocket連接活性 在移動應用開發(fā)中WebSocket套接字連接經常因網絡不穩(wěn)定或服務器超時網絡通信上一篇Hyperopt與其他優(yōu)化庫對比5大超參優(yōu)化工具深度評測下一篇5分鐘快速上手Sionna構建你的第一個5G通信系統(tǒng)仿真創(chuàng)作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考