簡介這份資源聚焦TCP協(xié)議下的異步通信實現(xiàn)面向具備一定網(wǎng)絡(luò)編程基礎(chǔ)、希望深入理解高并發(fā)網(wǎng)絡(luò)應(yīng)用開發(fā)的開發(fā)者與學(xué)習(xí)者。包內(nèi)包含TCP服務(wù)端與TCP客戶端兩套異步通信示例代碼可用于對照學(xué)習(xí)異步I/O模型、回調(diào)函數(shù)、事件循環(huán)、線程池等關(guān)鍵技術(shù)點幫助理解連接建立、數(shù)據(jù)收發(fā)等環(huán)節(jié)在非阻塞模式下的處理流程。資源共2個文件均為cpp源文件壓縮包約2KB分別對應(yīng)服務(wù)端與客戶端的實現(xiàn)邏輯便于直接編譯調(diào)試與逐行分析。目前已有189人學(xué)習(xí)下載適合作為網(wǎng)絡(luò)編程入門到進階的實踐參考通過運行與修改代碼可直觀掌握異步TCP通信的工作機制與常見排錯思路為構(gòu)建高性能、高并發(fā)網(wǎng)絡(luò)應(yīng)用打下基礎(chǔ)。1. 從 tc.zip 說起TCP 服務(wù)端與客戶端異步到底解決什么問題很多人第一次看到tc.zip_TCP 服務(wù)端_TCP客戶端異步_tcp 異步這個標題腦子里冒出來的是一堆問號TCP 服務(wù)端和客戶端異步到底是一回事還是兩回事我直接說結(jié)論——它講的是一套用異步 I/O 模型同時撐起 TCP 服務(wù)端和 TCP 客戶端的通信骨架核心矛盾只有一個怎么讓一個線程或極少線程扛住成百上千條連接而不是一條連接開一個線程。傳統(tǒng)阻塞式寫法里accept一個連接就pthread_create一個線程幾百個連接就是幾百個線程上下文切換和內(nèi)存開銷直接把你拖垮。異步模型把「等待數(shù)據(jù)」這件事從線程身上剝離出來交給事件循環(huán)去管線程只在數(shù)據(jù)真正就緒時才干活。這套東西適合誰做即時通訊、物聯(lián)網(wǎng)設(shè)備接入、游戲網(wǎng)關(guān)、內(nèi)部 RPC 框架的工程師尤其是那些連接數(shù)上去了但單連接流量不大的場景。下面我按「原理選型 → 服務(wù)端落地 → 客戶端落地 → 避坑 → 進階驗證」的順序把這條鏈路拆開講透。2. 異步 TCP 的模型選型epoll、IOCP 和 asyncio 到底怎么挑2.1 先搞清楚「異步」在 TCP 里指什么TCP 本身是面向連接的可靠字節(jié)流協(xié)議它不關(guān)心你用阻塞還是非阻塞去讀寫。所謂「TCP 異步」指的是應(yīng)用層用非阻塞 socket 配合 I/O 多路復(fù)用或完成端口來管理連接而不是讓線程卡在recv上死等。這里有兩個容易混淆的概念I(lǐng)/O 多路復(fù)用select/poll/epoll/kqueue和真正的異步 I/OWindows IOCP、Linux io_uring。前者是「告訴你哪個 fd 就緒了你自己去讀」后者是「你提交讀請求讀完內(nèi)核通知你」。絕大多數(shù)所謂「TCP 異步框架」用的是前者因為跨平臺成熟、生態(tài)好。選型上我一般這么分模型適用平臺連接量級編程復(fù)雜度典型代表select跨平臺幾百低教學(xué)demoepoll (LT)Linux幾千到幾萬中大多數(shù)服務(wù)端epoll (ET)Linux幾萬以上高高性能網(wǎng)關(guān)IOCPWindows幾萬中高Windows服務(wù)asyncio跨平臺幾千到幾萬低Python服務(wù)新手我建議從 epoll 水平觸發(fā)LT或 Python asyncio 入手別一上來就搞邊緣觸發(fā)ETET 模式下漏讀一次數(shù)據(jù)就卡死連接血淚經(jīng)驗。2.2 服務(wù)端和客戶端的異步不是對稱的很多人以為服務(wù)端異步和客戶端異步寫法一樣其實側(cè)重點完全不同。服務(wù)端的核心是「一個循環(huán)管所有連接」監(jiān)聽 fd 注冊到 epoll新連接進來后把 connfd 也注冊進去事件循環(huán)里統(tǒng)一分發(fā)讀寫。客戶端的核心是「一個循環(huán)管我要發(fā)的請求和要收的響應(yīng)」你可能有幾十個目標地址每個地址一條連接異步客戶端要能同時發(fā)起、按序或亂序收結(jié)果。服務(wù)端怕的是連接管理混亂客戶端怕的是請求響應(yīng)錯配。所以下面我分兩章寫服務(wù)端講連接生命周期管理客戶端講請求-響應(yīng)配對。2.3 一個最小可跑的 epoll 服務(wù)端骨架先看代碼再解釋。這是 Linux 下 C 語言的 epoll LT 模式服務(wù)端核心#include sys/epoll.h #include sys/socket.h #include netinet/in.h #include unistd.h #include fcntl.h #include stdio.h #include string.h #define MAX_EVENTS 1024 #define PORT 9000 // 設(shè)置 fd 非阻塞異步模型的前提 int set_nonblocking(int fd) { int flags fcntl(fd, F_GETFL, 0); return fcntl(fd, F_SETFL, flags | O_NONBLOCK); } int main() { int listen_fd socket(AF_INET, SOCK_STREAM, 0); set_nonblocking(listen_fd); struct sockaddr_in addr; memset(addr, 0, sizeof(addr)); addr.sin_family AF_INET; addr.sin_addr.s_addr INADDR_ANY; addr.sin_port htons(PORT); bind(listen_fd, (struct sockaddr*)addr, sizeof(addr)); listen(listen_fd, 128); int epfd epoll_create1(0); struct epoll_event ev, events[MAX_EVENTS]; ev.events EPOLLIN; // LT 模式不寫 EPOLLET ev.data.fd listen_fd; epoll_ctl(epfd, EPOLL_CTL_ADD, listen_fd, ev); while (1) { int n epoll_wait(epfd, events, MAX_EVENTS, -1); for (int i 0; i n; i) { int fd events[i].data.fd; if (fd listen_fd) { // 新連接accept 后立刻設(shè)為非阻塞并注冊 int connfd accept(listen_fd, NULL, NULL); set_nonblocking(connfd); ev.events EPOLLIN; ev.data.fd connfd; epoll_ctl(epfd, EPOLL_CTL_ADD, connfd, ev); } else { char buf[4096]; int len read(fd, buf, sizeof(buf)); if (len 0) { // 對端關(guān)閉或出錯摘除并關(guān)閉 epoll_ctl(epfd, EPOLL_CTL_DEL, fd, NULL); close(fd); } else { // 業(yè)務(wù)處理這里簡單回顯 write(fd, buf, len); } } } } return 0; }邏輯說明epoll_create1創(chuàng)建事件表epoll_ctl注冊監(jiān)聽 fdepoll_wait阻塞等待事件。新連接到來時accept拿到 connfd必須立刻設(shè)為非阻塞否則后續(xù)read可能阻塞整個事件循環(huán)。讀返回 0 表示對端關(guān)閉返回 -1 且 errno 為 EAGAIN 表示暫時無數(shù)據(jù)LT 模式下一般不會走到。參數(shù)上MAX_EVENTS決定單次epoll_wait最多返回多少事件設(shè)太小會頻繁喚醒設(shè)太大浪費內(nèi)存1024 是常見起點。listen的 backlog 設(shè) 128 到 1024取決于你的并發(fā)建連速度。提示LT 模式下如果一次沒讀完數(shù)據(jù)下次epoll_wait還會通知你所以不容易丟數(shù)據(jù)ET 模式必須循環(huán)讀到 EAGAIN否則事件不再觸發(fā)。3. TCP 服務(wù)端異步落地連接生命周期與緩沖區(qū)管理3.1 連接對象要自己管別只存一個 fd上面那個骨架只能跑 demo真實服務(wù)端必須為每條連接維護一個結(jié)構(gòu)體至少包含fd、讀緩沖區(qū)、寫緩沖區(qū)、連接狀態(tài)、最后活躍時間。為什么需要寫緩沖區(qū)因為異步write不一定一次把數(shù)據(jù)全發(fā)出去內(nèi)核發(fā)送緩沖區(qū)滿了會返回 EAGAIN剩下的數(shù)據(jù)你得自己緩存等 fd 可寫時再發(fā)。這就是「異步寫」的坑你調(diào)了 write 不代表數(shù)據(jù)發(fā)出去了。typedef struct { int fd; char rbuf[8192]; size_t rlen; char *wbuf; // 動態(tài)寫緩沖 size_t wlen; size_t wpos; time_t last_active; } conn_t;參數(shù)說明rbuf固定 8KB 做讀緩沖夠大多數(shù)協(xié)議頭解析wbuf用動態(tài)分配因為待發(fā)數(shù)據(jù)長度不可控last_active用于空閑連接清理一般 60 到 300 秒沒數(shù)據(jù)就踢掉。連接數(shù)上萬時每個連接固定 8KB 讀緩沖就是 80MB還能接受但如果設(shè)成 64KB 就是 640MB內(nèi)存直接爆炸所以讀緩沖別貪大。3.2 事件循環(huán)里讀寫要分開處理注冊事件時默認只監(jiān)聽EPOLLIN。當你有數(shù)據(jù)要發(fā)且一次沒發(fā)完時動態(tài)加上EPOLLOUT發(fā)完后立刻改回只監(jiān)聽EPOLLIN。原因是如果一直監(jiān)聽 EPOLLOUT只要內(nèi)核發(fā)送緩沖區(qū)有空位就會不斷觸發(fā)可寫事件CPU 空轉(zhuǎn)。這是新手最常見的性能翻車點。// 需要發(fā)送數(shù)據(jù)時 ev.events EPOLLIN | EPOLLOUT; ev.data.fd conn-fd; epoll_ctl(epfd, EPOLL_CTL_MOD, conn-fd, ev); // 在事件循環(huán)中處理可寫 if (events[i].events EPOLLOUT) { int n write(conn-fd, conn-wbuf conn-wpos, conn-wlen - conn-wpos); if (n 0) { conn-wpos n; if (conn-wpos conn-wlen) { // 發(fā)完了摘掉 EPOLLOUT ev.events EPOLLIN; epoll_ctl(epfd, EPOLL_CTL_MOD, conn-fd, ev); conn-wpos conn-wlen 0; } } }邏輯上wpos記錄已發(fā)送位置每次可寫事件推進全部發(fā)完才取消 EPOLLOUT 監(jiān)聽。參數(shù)上write的第三個參數(shù)是剩余待發(fā)字節(jié)數(shù)不要傳整個 wlen否則會重復(fù)發(fā)送已發(fā)部分。3.3 用 Python asyncio 快速驗證服務(wù)端邏輯如果你不想一上來寫 C用 Python asyncio 可以在幾十行內(nèi)驗證異步服務(wù)端的行為適合先跑通協(xié)議再移植import asyncio async def handle(reader, writer): addr writer.get_extra_info(peername) print(f新連接: {addr}) try: while True: data await reader.read(4096) # 異步讀不阻塞事件循環(huán) if not data: break writer.write(data) # 寫入緩沖區(qū) await writer.drain() # 背壓控制緩沖滿時掛起 except ConnectionResetError: pass finally: writer.close() await writer.wait_closed() async def main(): server await asyncio.start_server(handle, 0.0.0.0, 9000) async with server: await server.serve_forever() asyncio.run(main())邏輯說明reader.read是協(xié)程沒數(shù)據(jù)時讓出控制權(quán)給事件循環(huán)writer.drain()是關(guān)鍵它實現(xiàn)背壓——當寫緩沖超過高水位時掛起當前協(xié)程防止內(nèi)存無限增長。參數(shù)上read(4096)的 4096 是單次最多讀多少字節(jié)start_server的 backlog 默認 100高并發(fā)場景要調(diào)大。這套代碼在 Linux 上底層就是 epoll在 Windows 上是 IOCP跨平臺不用改。注意asyncio 單線程跑滿一個核后不會自動多核擴展生產(chǎn)環(huán)境要配合多進程SO_REUSEPORT或多個 worker才能吃滿多核。4. TCP 客戶端異步請求響應(yīng)配對與超時控制4.1 異步客戶端最難的是「誰是誰的響應(yīng)」服務(wù)端處理連接相對獨立客戶端不一樣你可能同時向 10 個后端發(fā)請求每個請求的響應(yīng)長度和到達順序都不確定。如果只是簡單send然后recv響應(yīng)會錯配。常見做法是給每個請求分配一個序列號seq響應(yīng)里帶回 seq客戶端用字典維護 seq 到回調(diào)/future 的映射。這是所有異步 RPC 框架的基本功。import asyncio class AsyncTCPClient: def __init__(self, host, port): self.host host self.port port self.seq 0 self.pending {} # seq - Future self.reader None self.writer None async def connect(self): self.reader, self.writer await asyncio.open_connection(self.host, self.port) asyncio.create_task(self._recv_loop()) # 后臺收包循環(huán) async def _recv_loop(self): while True: header await self.reader.readexactly(4) # 假設(shè)4字節(jié)長度頭 length int.from_bytes(header, big) body await self.reader.readexactly(length) seq int.from_bytes(body[:4], big) fut self.pending.pop(seq, None) if fut and not fut.done(): fut.set_result(body[4:]) async def request(self, payload, timeout3.0): self.seq 1 seq self.seq fut asyncio.get_event_loop().create_future() self.pending[seq] fut msg seq.to_bytes(4, big) payload self.writer.write(len(msg).to_bytes(4, big) msg) await self.writer.drain() try: return await asyncio.wait_for(fut, timeout) # 超時控制 except asyncio.TimeoutError: self.pending.pop(seq, None) raise邏輯說明_recv_loop是獨立后臺任務(wù)按「長度頭 包體」拆包從包體里取 seq 找到對應(yīng)的 Future 并設(shè)置結(jié)果。request方法發(fā)完請求后await這個 Future誰先回來誰先完成。參數(shù)上timeout3.0是單請求超時超時后必須從pending里刪掉否則內(nèi)存泄漏長度頭用 4 字節(jié)大端支持單包最大 4GB實際業(yè)務(wù)一般限制在幾 MB。4.2 超時、重連和心跳一個都不能少異步客戶端三個必備機制超時上面已做、重連連接斷了要自動重連并重發(fā)未完成請求或報錯、心跳長時間無數(shù)據(jù)時發(fā) ping 保活防止中間設(shè)備靜默斷鏈。重連我一般用指數(shù)退避第一次 1 秒第二次 2 秒最多 30 秒避免服務(wù)端剛重啟就被客戶端打爆。async def reconnect_loop(self): backoff 1 while True: try: await self.connect() backoff 1 # 連上后重置退避 await self.writer.wait_closed() # 阻塞直到斷開 except Exception: await asyncio.sleep(backoff) backoff min(backoff * 2, 30) # 指數(shù)退避上限30秒?yún)?shù)說明backoff初始 1 秒每次翻倍封頂 30 秒。wait_closed讓協(xié)程掛起直到連接斷開斷開后自動進入下一輪重連。注意重連成功后pending里的舊請求要全部置為異常否則調(diào)用方永遠等不到結(jié)果。4.3 客戶端并發(fā)壓測怎么跑寫完客戶端別急著上生產(chǎn)先用它自己壓自己。用 asyncio 的gather并發(fā)發(fā) 1000 個請求看服務(wù)端和客戶端表現(xiàn)async def bench(): client AsyncTCPClient(127.0.0.1, 9000) await client.connect() tasks [client.request(bhello, timeout5.0) for _ in range(1000)] results await asyncio.gather(*tasks, return_exceptionsTrue) ok sum(1 for r in results if not isinstance(r, Exception)) print(f成功 {ok}/1000) asyncio.run(bench())邏輯上gather并發(fā)調(diào)度 1000 個協(xié)程return_exceptionsTrue讓異常也作為結(jié)果返回方便統(tǒng)計成功率。參數(shù)上并發(fā)數(shù)從 100 開始逐步加到 1000、5000觀察 QPS 和延遲拐點。如果成功率驟降先查服務(wù)端 backlog 和文件描述符上限ulimit -n再看客戶端pending字典是否泄漏。5. 異步 TCP 避坑排查那些讓你加班到凌晨的細節(jié)5.1 現(xiàn)象連接數(shù)一上去就報「Too many open files」原因Linux 默認單進程文件描述符上限是 1024每條 TCP 連接占一個 fd加上監(jiān)聽 fd、日志文件等1000 連接就頂?shù)教旎ò?。解決ulimit -n 65535臨時生效永久生效改/etc/security/limits.conf加* soft nofile 65535和* hard nofile 65535重啟會話后ulimit -n確認。注意 systemd 管理的服務(wù)還要在 unit 文件里加LimitNOFILE65535否則不生效。5.2 現(xiàn)象客戶端發(fā)了數(shù)據(jù)服務(wù)端半天收不到原因TCP 默認開啟 Nagle 算法小包會攢著一起發(fā)延遲最高 40ms。異步場景下如果每次只發(fā)幾十字節(jié)這個延遲很致命。解決對延遲敏感的連接設(shè)置TCP_NODELAYint flag 1; setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, flag, sizeof(flag));Python 里writer.get_extra_info(socket).setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)。代價是網(wǎng)絡(luò)包數(shù)量增加帶寬換延遲內(nèi)網(wǎng)服務(wù)基本無腦開。5.3 現(xiàn)象epoll 邊緣觸發(fā)模式下連接突然不再收數(shù)據(jù)原因ET 模式要求每次事件觸發(fā)必須循環(huán)read直到返回 EAGAIN如果只讀一次剩余數(shù)據(jù)不會再次觸發(fā)事件連接就「假死」了。解決ET 模式下讀循環(huán)寫成while ((n read(fd, buf, sizeof(buf))) 0) { 處理 }讀到n -1 errno EAGAIN才退出。我一般建議新手先用 LT性能差距在大多數(shù)業(yè)務(wù)里沒那么大等真扛不住了再換 ET。5.4 現(xiàn)象服務(wù)端內(nèi)存持續(xù)增長最后 OOM原因?qū)懢彌_區(qū)只增不減或者pending字典里的請求超時后沒清理。解決給寫緩沖設(shè)上限比如 1MB超過就斷開慢客戶端超時請求必須在except里pop掉定期用len(pending)打點監(jiān)控。另外讀緩沖如果按連接固定分配且設(shè)得過大上萬連接也會吃光內(nèi)存按需分配或設(shè)小一點。5.5 現(xiàn)象壓測時 QPS 上不去CPU 卻不高原因多半是鎖競爭或系統(tǒng)調(diào)用過多。異步單線程模型里如果用了線程鎖或者每個事件都調(diào)epoll_ctl修改監(jiān)聽開銷會很大。解決減少epoll_ctl調(diào)用能一次注冊就一次注冊避免在事件循環(huán)里做阻塞操作文件 IO、數(shù)據(jù)庫同步查詢用strace -c看系統(tǒng)調(diào)用分布perf top看熱點函數(shù)。6. 進階驗證用 io_uring 和連接池把異步 TCP 再推一步前面講的 epoll 本質(zhì)還是「就緒通知」每次讀寫都要一次系統(tǒng)調(diào)用。Linux 5.1 之后有了 io_uring可以批量提交讀寫請求減少系統(tǒng)調(diào)用次數(shù)在高連接高吞吐場景下比 epoll 有明顯優(yōu)勢。我一般用liburing做驗證核心思路是把 accept、read、write 都封裝成 SQE 提交到環(huán)形隊列內(nèi)核完成后通過 CQE 通知。不過 io_uring 生態(tài)還在成熟中生產(chǎn)環(huán)境要評估內(nèi)核版本和運維成本別為了追新把穩(wěn)定性搭進去。另一個更實用的進階方向是連接池。異步客戶端如果每次請求都新建連接三次握手開銷會吃掉大量性能。做法是維護一組長連接請求時從池里取空閑連接用完歸還。池大小按「目標 QPS × 平均請求耗時」估算比如 10000 QPS、單請求 5ms理論上 50 個連接就夠?qū)嶋H留 2 倍余量設(shè) 100。配合前面講的 seq 配對一個連接上可以并發(fā)多個請求吞吐還能再上一個臺階。驗證異步 TCP 方案是否達標我習(xí)慣看三個指標單連接吞吐用iperf3打底、并發(fā)連接下的 P99 延遲用wrk或自寫壓測客戶端、CPU 和內(nèi)存隨連接數(shù)的增長曲線。如果連接數(shù)翻倍而 CPU 增長遠低于線性說明異步模型生效了如果內(nèi)存線性暴漲回去查緩沖區(qū)分配。最后說個我自己的習(xí)慣每次寫完異步 TCP 代碼先不接業(yè)務(wù)用tcpdump抓包確認收發(fā)字節(jié)數(shù)和預(yù)期一致再上壓測。這個笨辦法幫我省過至少三次「代碼邏輯對但線上就是不通」的排查時間。異步 TCP 這東西原理不復(fù)雜坑全在細節(jié)里把連接生命周期、緩沖區(qū)、超時這三樣管住基本就穩(wěn)了。希望幫到你。本文還有配套的精品資源點擊獲取