簡介這份PDF文檔聚焦TCP與UDP Socket編程面向具備Python語法基礎(chǔ)和簡單網(wǎng)絡(luò)概念的學習者適合課程配套實驗或自學實踐。文檔從PyCharm安裝與環(huán)境配置講起完整梳理Socket開發(fā)流程重點演示UDP套接字的數(shù)據(jù)發(fā)送接收、超時設(shè)置以及Ping應(yīng)用中的丟包模擬同時給出TCP客戶端與服務(wù)端的連接創(chuàng)建、數(shù)據(jù)收發(fā)和關(guān)閉套接字的全流程代碼。讀者按步驟操作可以獨立寫出UDP Pinger客戶端和TCP通信程序直觀對比兩種協(xié)議在連接建立、可靠性、傳輸效率等方面的差異。文中提供可直接運行的參考代碼和關(guān)鍵注釋便于排查常見錯誤。資源僅包含1個PDF文件壓縮包體積735KB內(nèi)容精煉、章節(jié)清晰目前已吸引170人學習可作為實驗報告參考或教學演示材料幫助讀者在較短時間內(nèi)掌握網(wǎng)絡(luò)編程的核心方法并為后續(xù)深入學習奠定基礎(chǔ)。1. TCP和UDP在Python里差的不是API是數(shù)據(jù)邊界接手過一個用Python寫的數(shù)據(jù)采集服務(wù)局域網(wǎng)里跑得好好的一上跨網(wǎng)段就“玄學”斷連。后來確認是TCP連接被防火墻靜默重置而對面設(shè)備只支持UDP。這件事讓我意識到TCP與UDP的Socket編程表面是同一個socket模塊的幾句調(diào)用實際是兩個完全不同的調(diào)試世界。TCP有嚴格連接狀態(tài)、有重傳、有粘包問題UDP無連接、無邊界之外的任何保證。這篇筆記面向要用Python做數(shù)據(jù)采集、設(shè)備通信、后端消息轉(zhuǎn)發(fā)的從業(yè)者按“先立規(guī)則、再寫代碼、最后排坑”的順序把可直接照抄的實現(xiàn)和必須知道的參數(shù)陷阱一起講清楚。適合新手照著寫也適合熟手確認自己沒踩漏是否處理了半包、心跳、端口復(fù)用、UDP無回包這三種最容易翻車的場景。2. 先跑通TCP用Python驗證三次握手并拆解阻塞模型寫TCP socket代碼前需要把三個狀態(tài)搞清楚socket()只是拿到一個文件描述符connect()返回時TCP棧已經(jīng)走完三次握手accept()拿到的連接則是已經(jīng)完成握手的成品。很多人把accept看成“創(chuàng)建連接”其實它更像“從隊列里取出連接”。我先寫最小實現(xiàn)再講狀態(tài)和超時。2.1 最小服務(wù)端bind、listen、accept背后發(fā)生了什么import socket server socket.socket(socket.AF_INET, socket.SOCK_STREAM) server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) server.bind((0.0.0.0, 9000)) server.listen(10) print(TCP server listening on 0.0.0.0:9000) while True: conn, addr server.accept() print(faccept from {addr}) data conn.recv(1024) print(frecv {len(data)} bytes: {data!r}) conn.sendall(bpong) conn.close()這段代碼能跑但它有幾個關(guān)鍵點值得掰開說。socket(AF_INET, SOCK_STREAM)組合固定了“IPv4 TCP”這個協(xié)議族SOCK_STREAM就是“基于字節(jié)流的可靠傳輸”如果想改用UDP把SOCK_STREAM換成SOCK_DGRAM后半段代碼全部要改這點后面再展開。setsockopt(SOL_SOCKET, SO_REUSEADDR, 1)的作用是允許TIME_WAIT狀態(tài)下端口被重新綁定第5章會專門講避坑但開發(fā)環(huán)境建議直接寫上。bind的“0.0.0.0”表示監(jiān)聽所有網(wǎng)卡換成“127.0.0.1”則只能本機訪問做端口測試時最容易在這個地方看反。listen(10)里的10經(jīng)常被誤會成“最大并發(fā)連接數(shù)”實際上它只控制內(nèi)核里已完成三次握手的隊列長度?？蛻舳送瓿晌帐侄?wù)端還沒accept時連接會堆在這個隊列里隊列滿了之后新的連接請求會被內(nèi)核直接丟棄或返回拒絕表現(xiàn)就是客戶端connect超時但進程明明還活著。所以業(yè)務(wù)代碼里要么快速accept要么accept完立即交給線程池不要讓握手成功的連接在隊列里等太久。accept()返回的conn是服務(wù)端一側(cè)的新socket負責這條連接上收發(fā)原server socket只負責繼續(xù)接收新連接這個“一服務(wù)一連接”的關(guān)系也是初學最容易暈的點。2.2 客戶端connect與sendall握手完成但recv仍然沒有消息邊界客戶端的代碼更短import socket client socket.socket(socket.AF_INET, socket.SOCK_STREAM) client.settimeout(3) client.connect((192.168.1.50, 9000)) client.sendall(bping) try: data client.recv(1024) except socket.timeout: print(recv timeout, close it) client.close() else: print(recv:, data) client.close()connect()成功返回只代表三次握手完成了本端發(fā)SYN、對端回SYNACK、本端回ACK這三次交換已經(jīng)結(jié)束。這時候如果立刻抓包會看到連接狀態(tài)是ESTABLISHED但這只表示“TCP棧認為連接可用”不代表對端應(yīng)用已經(jīng)準備好消息。connect可能拋出的異常有三種值得記ConnectionRefusedError說明對端回了RST通常是端口沒服務(wù)TimeoutError說明SYN發(fā)出后沒人理常見于防火墻丟棄OSError里最常見的子類是“Network is unreachable”或“Operation now in progress”前者是路由問題后者多半是在非阻塞socket上重復(fù)connect。sendall和send是另一個高頻坑。send()未必一次發(fā)完所有字節(jié)返回值是本次實際寫入內(nèi)核發(fā)送緩沖區(qū)的字節(jié)數(shù)sendall()內(nèi)部循環(huán)發(fā)送保證全部字節(jié)進入緩沖區(qū)但同recv一樣“發(fā)送成功”不代表對端收到了只代表本端內(nèi)核收了。TCP的可靠傳輸由內(nèi)核的ACK/重傳機制保證應(yīng)用層能觀測到的可靠信號只有對端recv返回非空、或者對端正常close。recv(1024)在阻塞模式下會一直等到本連接上有數(shù)據(jù)或?qū)Χ岁P(guān)閉對端關(guān)閉后recv返回空字節(jié)串這個信號后面要單獨講。阻塞模式還有一個必須接受的事實一個recv只能屬于一個線程。上面這版服務(wù)端在while True里accept后阻塞在recv第二個客戶端連上來時即使三次握手已經(jīng)完成accept也取不出來因為第一個客戶端還沒斷開。這就是為什么生產(chǎn)級TCP服務(wù)端不能用這種寫法?？吹竭@里不要急著學并發(fā)先記住這個瓶頸第3章會把幀協(xié)議和心跳補上第6章再寫事件驅(qū)動。2.3 用抓包和空字符串確認握手、揮手時序想在代碼層面“看”到三次握手最直接的辦法是抓回環(huán)包。服務(wù)端和客戶端在同一臺機器時用tcpdump能精確看到整個過程tcpdump -i lo -nn tcp port 9000運行服務(wù)端和客戶端后輸出里會出現(xiàn)SYN、SYNACK、ACK三行這就是三次握手隨后如果客戶端先close會看到FIN、ACK、FIN、ACK四行也就是常說的四次揮手。這里有一個容易誤導新手的現(xiàn)象服務(wù)端代碼里看不到任何握手狀態(tài)因為握手由TCP協(xié)議棧自動完成但這不代表“沒有握手”只是內(nèi)核替你做了。排錯時與其盯著客戶端打印不如用ss -tnp看連接狀態(tài)LISTEN表示服務(wù)端還在監(jiān)聽ESTABLISHED表示握手完成TIME_WAIT表示主動關(guān)閉方進入的2MSL等待。揮手階段的代碼語義也要對齊客戶端close后服務(wù)端下一次recv會拿到b這不是數(shù)據(jù)是EOF信號。很多人在recv里沒判斷空串直接拿空數(shù)據(jù)去解析然后就翻車。所以處理TCP關(guān)閉的正確姿勢是recv返回空串 - 對端已關(guān)閉 - 服務(wù)端也執(zhí)行close釋放連接如果服務(wù)端在收到EOF前直接close而客戶端還在等回包可能觸發(fā)RST而不是優(yōu)雅的FIN揮手。這里提到的空串判斷會和RST問題一起在第5章展開。3. 把TCP做穩(wěn)幀協(xié)議、粘包處理與三層保活參數(shù)TCP能保證字節(jié)順序和最終交付但它不關(guān)心你的消息邊界。你要發(fā)一句“hello”和一句“world”內(nèi)核可能把8個字節(jié)連續(xù)放在緩沖區(qū)里接收方一次讀走這就是粘包反過來一條“helloworld”也可能被拆成兩次讀這是拆包。解決思路只有一個在應(yīng)用層定義“幀”讓接收方知道一條消息從哪里開始、在哪里結(jié)束。3.1 粘包與拆包先弄清內(nèi)核緩沖區(qū)和應(yīng)用緩沖區(qū)先解釋現(xiàn)象發(fā)送端連續(xù)sendall三個100字節(jié)的數(shù)據(jù)接收端一次recv(1024)可能收到300字節(jié)也可能收到70字節(jié)。原因不是“TCP把數(shù)據(jù)粘在一起”而是recv()的語義是“從內(nèi)核接收隊列里取出不超過指定長度的字節(jié)”內(nèi)核隊列里有多少字節(jié)和你的sendall次數(shù)沒有對應(yīng)關(guān)系。TCP是字節(jié)流協(xié)議它只保證順序和可靠性不保證把每條sendall當作獨立消息這就是為什么很多從UDP轉(zhuǎn)過來的人剛寫TCP就會翻車。另一個容易混淆的點是“tcp協(xié)議包如何修改”這類問題。粘包是應(yīng)用層邊界問題改不了TCP頭也不能通過調(diào)整TCP_NODELAY完全消除。TCP_NODELAY只關(guān)閉Nagle算法減少小包延遲但不等同于消息邊界真正決定邊界的是你自己的幀格式。tcp dup ack機制則是TCP棧在丟包重傳時的ACK行為跟粘包無關(guān)調(diào)試時別把這兩件事攪在一起。選擇幀格式時固定長度最簡單但短包要補零浪費帶寬分隔符適合文本協(xié)議但payload里不能出現(xiàn)分隔符要轉(zhuǎn)義長度前綴最通用適合二進制協(xié)議。Modbus TCP的MBAP頭就是典型長度前綴結(jié)構(gòu)“事務(wù)標識協(xié)議標識長度單元標識”4個字段里長度字段讓接收方知道后面PDU有多少字節(jié)如果你要對接PLC設(shè)備幾乎繞不開這套結(jié)構(gòu)。3.2 長度前綴幀協(xié)議send_frame / recv_frame直接復(fù)制import socket import struct def send_frame(sock: socket.socket, payload: bytes): header struct.pack(!I, len(payload)) sock.sendall(header payload) def recv_exact(sock: socket.socket, length: int) - bytes: chunks b while len(chunks) length: piece sock.recv(length - len(chunks)) if not piece: raise ConnectionError(peer closed during frame) chunks piece return chunks def recv_frame(sock: socket.socket) - bytes: header recv_exact(sock, 4) (length,) struct.unpack(!I, header) if length 4 * 1024 * 1024: raise ValueError(frame too large, refuse it) return recv_exact(sock, length)這個封裝是TCP應(yīng)用層協(xié)議常見做法。struct.pack(!I, len(payload))把長度壓成4字節(jié)大端整數(shù)大端網(wǎng)絡(luò)序是約定俗成跨機器不需要考慮字節(jié)序recv_exact循環(huán)讀滿length字節(jié)是因為底層recv一次未必返回所有字節(jié)拆包會被這里吸收掉。recv_frame里對length做上限校驗是生產(chǎn)環(huán)境必須加的如果不限制攻擊方只要發(fā)一個聲明長度為4GB的幀頭你的recv_exact就會一直空等或申請巨大內(nèi)存把進程拖死。4MB不是硬標準但一定要有。幀格式可以列成一張小表字段長度字節(jié)序用途length4字節(jié)大端記錄payload字節(jié)數(shù)payload0~4MB-實際業(yè)務(wù)數(shù)據(jù)服務(wù)端主循環(huán)里配合使用server socket.socket(socket.AF_INET, socket.SOCK_STREAM) server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) server.bind((0.0.0.0, 9000)) server.listen(16) while True: conn, addr server.accept() print(connected:, addr) try: while True: payload recv_frame(conn) print(addr, -, payload.decode(errorsreplace)) except (ConnectionError, ValueError): pass finally: conn.close()這里把ConnectionError和ValueError都當作“斷開或非法幀”因為一次非法幀后應(yīng)用層狀態(tài)已經(jīng)不可信直接關(guān)閉連接比試圖恢復(fù)更穩(wěn)。如果業(yè)務(wù)需要區(qū)分是掉線還是非法數(shù)據(jù)可以分別except后再打日志。send_frame里的sendall會循環(huán)發(fā)送所以上層不需要關(guān)心寫緩沖滿的問題真正需要關(guān)心的是sendall也可能長時間阻塞配合后面的settimeout才能避免一個慢客戶端拖死服務(wù)端。3.3 心跳與斷線檢測SO_KEEPALIVE、TCP_KEEPIDLE、業(yè)務(wù)心跳TCP連接斷開應(yīng)用層不是立刻知道的。如果對端直接斷電或網(wǎng)線斷開本端可能一直覺得連接還在直到recv超時或發(fā)送失敗才反應(yīng)。內(nèi)核內(nèi)置的TCP?；钅芫徑獾J2小時才開始探測太慢了?？梢杂胹etsockopt調(diào)參數(shù)import socket s.setsockopt(socket.SOL_SOCKET, socket.SO_KEEPALIVE, 1) if hasattr(socket, TCP_KEEPIDLE): s.setsockopt(socket.IPPROTO_TCP, socket.TCP_KEEPIDLE, 60) if hasattr(socket, TCP_KEEPINTVL): s.setsockopt(socket.IPPROTO_TCP, socket.TCP_KEEPINTVL, 5) if hasattr(socket, TCP_KEEPCNT): s.setsockopt(socket.IPPROTO_TCP, socket.TCP_KEEPCNT, 3)參數(shù)含義TCP_KEEPIDLE是空閑多久開始探測TCP_KEEPINTVL是每次探測間隔TCP_KEEPCNT是連續(xù)失敗幾次判定斷開。設(shè)成空閑60秒、每5秒探測、3次失敗后判定死連接一共耗時75秒左右比默認2小時快得多。但內(nèi)核?；钪荒鼙ＷC“TCP棧層面探測到對端消失”應(yīng)用層業(yè)務(wù)仍然可能卡在處理邏輯里所以更可靠的是應(yīng)用級心跳。業(yè)務(wù)心跳常見做法連接建立后雙方約定一個心跳幀比如每5秒客戶端發(fā)PING服務(wù)端回PONG或者只記錄最后活躍時間服務(wù)端每次收到任意幀都更新last_seen后臺線程每10秒掃一遍發(fā)現(xiàn)超過閾值就close。這樣即使對端不響應(yīng)也能在應(yīng)用層主動斷開。底層的SO_KEEPALIVE可以繼續(xù)開著但它作用有限不要當作唯一?；钍侄?。調(diào)參時還可以留意Windows上netsh interface tcp show global查看系統(tǒng)級keepalive配置但應(yīng)用層心跳參數(shù)不受它控制兩者是獨立的。4. 切到UDP收發(fā)、端口探測與多客戶端會話管理UDP在Python里的代碼量比TCP少但坑一點不少。少的是connect、listen、accept這些連接狀態(tài)管理多的是收發(fā)邊界、端口探測和廣播。它的定位是“接受數(shù)據(jù)報丟了再補”的場景比如設(shè)備狀態(tài)上報、日志傳輸、視頻流、以及很多控制協(xié)議的廣播發(fā)現(xiàn)。4.1 UDP的recvfrom與sendto無連接模型下的最小實現(xiàn)import socket s socket.socket(socket.AF_INET, socket.SOCK_DGRAM) s.bind((0.0.0.0, 8000)) print(UDP listening on 0.0.0.0:8000) while True: data, addr s.recvfrom(2048) print(ffrom {addr}: {data!r}) s.sendto(back, addr)這里沒有l(wèi)isten沒有accepts就是唯一的socket。recvfrom返回兩個值data是這一條數(shù)據(jù)報的內(nèi)容addr是來源(ip, port)sendto把應(yīng)答發(fā)回同一個addr就能天然回給那個客戶端。這跟TCP完全不同TCP每個連接有自己的socketUDP所有包都從同一個socket進。第二個參數(shù)2048是單次接收緩沖區(qū)上限超過的部分會被內(nèi)核丟棄這會造成“收到了包但不是完整包”的假象。如果業(yè)務(wù)字段可能超過1500字節(jié)建議把緩沖區(qū)調(diào)到4096或更高但別盲目調(diào)大超過路徑MTU的包仍可能在IP層被分片。UDP選型還要知道它的“假更快”UDP少了握手和重傳單包延遲低但應(yīng)用層自己補重傳、排序、去重的成本并不低。做端口測試時UDP的“無狀態(tài)”也是一把雙刃劍——TCP connect能立刻告訴你端口通不通UDP只能靠應(yīng)用回包判斷。另外UDP socket其實也可以調(diào)用connect()它的作用是記錄默認目標地址之后sendto可以只傳數(shù)據(jù)但recvfrom仍然能從任何來源收包這個行為不要和TCP的connect混為一談。4.2 UDP端口探測為什么“沒回包”不等于不通import socket def udp_probe(host, port, timeout1.0): s socket.socket(socket.AF_INET, socket.SOCK_DGRAM) s.settimeout(timeout) s.sendto(bprobe, (host, port)) try: data, _ s.recvfrom(2048) return True except socket.timeout: return None它先發(fā)一條“probe”給目標等回包如果目標主機不存在或者端口沒有服務(wù)常見情況下內(nèi)核會回ICMP Port Unreachable但Python的UDP socket默認收不到這個ICMP因為ICMP屬于另一層協(xié)議所以recvfrom只能等超時。不能把“無回包”直接判定為“端口不通”因為防火墻可以靜默丟棄UDP目標應(yīng)用也可以選擇不回應(yīng)任何未知數(shù)據(jù)。這個腳本真正的用途是“探測服務(wù)是否存活”如果目標服務(wù)設(shè)計為必須響應(yīng)特定UDP報文回包就是活著的證據(jù)如果只是往空端口灌數(shù)據(jù)只能得到“未知”這個結(jié)論。這個差異在做udp端口測試時非常關(guān)鍵。TCP端口測試只要connect()收到RST就能確定端口不可達UDP沒有等價物。所以生產(chǎn)環(huán)境做UDP連通性監(jiān)控時要在應(yīng)用層設(shè)計一個握手包客戶端發(fā)特定魔數(shù)服務(wù)端必須回另一個魔數(shù)雙方約定好探測結(jié)論才可信。UDP網(wǎng)絡(luò)調(diào)試工具也是這個思路先確認對端會不會回應(yīng)再談丟包率。4.3 廣播與多客戶端地址字典和SO_BROADCAST的用法廣播在局域網(wǎng)設(shè)備發(fā)現(xiàn)里很常用。發(fā)送廣播包需要顯式打開SO_BROADCASTimport socket s socket.socket(socket.AF_INET, socket.SOCK_DGRAM) s.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1) s.sendto(bDISCOVER, (255.255.255.255, 8000))服務(wù)端收到DISCOVER后用recvfrom得到的addr回包客戶端就能知道設(shè)備在哪。注意廣播只能覆蓋同一廣播域路由器不會轉(zhuǎn)發(fā)跨網(wǎng)段要改用組播或單播探測。嵌入式設(shè)備做以太網(wǎng)UDP測試時通常也是先用廣播發(fā)現(xiàn)設(shè)備再轉(zhuǎn)單播傳數(shù)據(jù)。多客戶端會話管理在UDP下有點特殊沒有連接對象只能靠地址字典。常見做法是維護一個dictkey是addr元組value是會話狀態(tài)和最后活躍時間sessions {} while True: data, addr s.recvfrom(2048) sessions[addr] time.time() if data bkeepalive: s.sendto(balive, addr) now time.time() for a in [a for a, t in sessions.items() if now - t 15]: del sessions[a]注意dict的key必須是recvfrom返回的addr原樣不能自己拼“ip:port”再當作元組。另外客戶端在NAT后面時這個addr是NAT網(wǎng)關(guān)分配的臨時映射長時間不發(fā)包會被回收所以UDP應(yīng)用層心跳間隔要比NAT超時短很多局域網(wǎng)內(nèi)則不用太擔心。清理會話時要避免在遍歷dict時刪除先取待刪地址快照再刪除代碼里我用列表推導式生成待刪地址。5. 避坑清單端口占用、空串返回與RST重連的排查記錄這一章是我自己踩過不少次的坑每一條都按“現(xiàn)象-原因-解決”來寫方便你遇到問題直接對號入座。5.1 bind失敗Address already in use / Windows套接字地址已使用現(xiàn)象服務(wù)端代碼第二次啟動時報OSError: [Errno 98] Address already in use或者Windows下報“通常每個套接字地址(協(xié)議/網(wǎng)絡(luò)地址/端口)只允許使用一次。”原因通常有三類上一個進程還沒退出進程退出了但連接還在TIME_WAIT另一個程序占用了同一端口。解決先用lsof -i :9000Linux或netstat -ano | findstr :9000Windows查占用進程確認沒有僵尸進程后再換端口重試。代碼層面bind前設(shè)置SO_REUSEADDR能解決TIME_WAIT導致的重復(fù)綁定但要注意Windows上SO_REUSEADDR語義和Linux不完全一樣。Linux上SO_REUSEADDR允許在TIME_WAIT狀態(tài)下重用端口Windows上多個socket同時設(shè)置它也能綁定同一端口后果是數(shù)據(jù)可能被隨機分給其中一個socket。所以Windows上不要為了省事給所有socket都開SO_REUSEADDR只有明確需要“TIME_WAIT后立刻重啟服務(wù)端”時才開。如果要用多進程負載均衡Linux的SO_REUSEPORT是另一個選項不能和SO_REUSEADDR混為一談。順帶說一句部署到容器環(huán)境時見過的“error response from daemon: ports are not available: exposing port tcp 0.0.0.0”本質(zhì)也是端口被占用或未釋放不是網(wǎng)絡(luò)問題。在宿主機上用ss -lntp看監(jiān)聽端口確認沒有沖突再啟動比反復(fù)重啟容器有效。5.2 recv返回空字符串是正常關(guān)閉還是被重置現(xiàn)象服務(wù)端recv()返回b日志上沒有異常客戶端進程也還在跑。原因這是對端正常調(diào)用close()后FIN到達本端recv返回EOF信號。它不是一個錯誤是“連接關(guān)閉”的標準通知。解決把b當成“關(guān)閉連接”分支不要交給業(yè)務(wù)解析。繼續(xù)在這個連接上recv會一直返回b毫無意義。如果還想?yún)^(qū)分“正常關(guān)閉”和“異常RST”可以嘗試再寫一次寫的時候拋BrokenPipeError或ConnectionResetError說明對端已經(jīng)發(fā)送了RST寫成功但recv還是空串則可能是對端只關(guān)閉了讀半端。實際業(yè)務(wù)里不需要太糾結(jié)記一條warn日志即可。這里最容易翻車的寫法是data conn.recv(1024); if data:然后省略else導致關(guān)閉信號被誤認為空消息處理。5.3 客戶端重連被RST先查未讀數(shù)據(jù)和close順序現(xiàn)象客戶端斷開后立即重連connect拋ConnectionResetError或服務(wù)端accept到的連接一收就報ECONNRESET。原因常見的是上一次連接中一端close時另一端還有未讀取的數(shù)據(jù)TCP棧于是不回FIN而是回RST把連接強制重置。解決改close順序。規(guī)范做法是“對端先close本端讀到空串后再close”或者本端先shutdown(SHUT_WR)告訴對端“我不再發(fā)數(shù)據(jù)”等對端close后再close。不要兩端同時執(zhí)行close尤其不要在自己還有未讀數(shù)據(jù)時直接close?？蛻舳酥剡B也一樣如果老的conn已經(jīng)處于異常狀態(tài)重新new一個socket不要試著把舊的conn再connect一遍?？蛻舳酥剡B時報地址已在使用本質(zhì)也是舊連接還占著本地端口新連接想復(fù)用相同四元組會被拒絕所以重連邏輯一定要“換socket、換本地端口”不要復(fù)用舊fd。5.4 UDP丟包與亂序先確認緩沖區(qū)再懷疑網(wǎng)絡(luò)現(xiàn)象UDP客戶端每秒發(fā)100個包服務(wù)端只收到70個收到的順序還有跳號。原因可能有兩個層次應(yīng)用太慢收包循環(huán)沒及時從內(nèi)核隊列取數(shù)據(jù)內(nèi)核緩沖區(qū)溢出后到的包被丟棄或者網(wǎng)絡(luò)路徑本身丟包。UDP不保證順序亂序是正常的丟包則要看是發(fā)生在哪一側(cè)。解決先調(diào)大接收緩沖區(qū)s.setsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF, 4 * 1024 * 1024)注意Linux上內(nèi)核會把設(shè)置值翻倍或者受net.core.rmem_max限制設(shè)完可以用getsockopt看一下實際生效值。然后把“收包”和“業(yè)務(wù)處理”解耦recvfrom循環(huán)只負責把包放進queue.Queue業(yè)務(wù)線程再消費這樣收包循環(huán)永遠不堵。亂序則要靠應(yīng)用層加序號接收端檢查序號缺口并做緩存重排不要假設(shè)先到先處理。排查時用netstat -su看UDP buffer errors如果這個計數(shù)器在增長說明本端丟包是應(yīng)用處理慢導致的跟網(wǎng)絡(luò)沒關(guān)系。5.5 shutdown socket創(chuàng)建失敗同機端口池耗盡的長尾問題現(xiàn)象某些服務(wù)框架停機時日志出現(xiàn)“failed to create server shutdown socket on address [localhost] and port [802]”之類的報錯看起來像網(wǎng)絡(luò)崩潰隨后端口遲遲起不來。原因很多框架會在本機臨時端口上創(chuàng)建控制socket用來通知停機如果這個端口被其他進程占用或者系統(tǒng)端口池因為大量TIME_WAIT連接耗盡創(chuàng)建就會失敗。解決先查端口占用再查TIME_WAIT數(shù)量。Linux上用ss -tan state time-wait | wc -l看堆積Windows下netsh interface tcp show global只能看全局TCP參數(shù)查TIME_WAIT還是用netstat -ano | findstr TIME_WAIT更直觀。更實際的做法是給服務(wù)設(shè)置固定的shutdown端口并通過配置文件下發(fā)避免每次啟動隨機撞端口同時啟動前先嘗試綁定綁定失敗就快速失敗并給出明確錯誤而不是讓應(yīng)用內(nèi)部把網(wǎng)絡(luò)故障誤報成“無法創(chuàng)建shutdown socket”。這個問題日志上很嚇人但解決起來就是端口管理四件事誰占用誰釋放誰在等待誰在復(fù)用。6. 進階用selectors做事件驅(qū)動再用UDP打流驗證吞吐6.1 selectors替換多線程阻塞模型當連接數(shù)到幾百線程池反而是瓶頸每個線程默認8MB棧空間上下文切換吃CPU還要處理線程安全的收發(fā)緩沖。用事件驅(qū)動可以讓一個線程管住上千連接。Python標準庫的selectors模塊在這里最合適它底層按平臺選select/poll/epollWindows也能跑import selectors import socket sel selectors.DefaultSelector() def on_accept(server): conn, addr server.accept() conn.setblocking(False) sel.register(conn, selectors.EVENT_READ, on_read) def on_read(conn): data conn.recv(1024) if not data: sel.unregister(conn) conn.close() return conn.sendall(becho: data) server socket.socket(socket.AF_INET, socket.SOCK_STREAM) server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) server.bind((0.0.0.0, 9000)) server.listen(64) server.setblocking(False) sel.register(server, selectors.EVENT_READ, on_accept) while True: for key, mask in sel.select(timeout1): key.data(key.fileobj)這段代碼里每個socket注冊了一個回調(diào)select()返回可讀事件后由回調(diào)處理。非阻塞模式下recv不會傻等所以一個線程就能循環(huán)服務(wù)多個連接。selectors模塊不是性能最強的但足夠覆蓋絕大多數(shù)業(yè)務(wù)且跨平臺。6.2 半包緩沖是事件驅(qū)動的分水嶺上面這個echo例子埋了一個雷on_read里如果一次recv只讀到半個長度前綴幀直接把data當完整消息處理協(xié)議就錯了。事件驅(qū)動模式下on_read會被反復(fù)觸發(fā)所以必須有一個半包緩沖器class FrameBuffer: def __init__(self): self.buf b def feed(self, chunk): self.buf chunk frames [] while len(self.buf) 4: length, struct.unpack(!I, self.buf[:4]) if len(self.buf) 4 length: break frames.append(self.buf[4:4 length]) self.buf self.buf[4 length:] return frames每次on_read把recv到的chunk丟進feed拿出來的frames是已經(jīng)收完整的若干幀不夠一幀就留在self.buf里等下一次事件。這正是阻塞模型里由recv_exact循環(huán)做的事事件模型下必須自己管理剩余狀態(tài)。我最開始寫selectors時沒加這一層半包一來就亂拼日志里全是壞幀后來才意識到事件循環(huán)不等于自動處理拆包幀邊界只能靠應(yīng)用狀態(tài)維護。6.3 用UDP打流驗證設(shè)計TCP性能可以直接用iperf3壓但UDP更需要自己定義“設(shè)計驗證”打流前先約定回包格式接收端統(tǒng)計到達包的序號。在Python里做局域網(wǎng)UDP打流發(fā)送端給每個包帶自增序號接收端每秒打印收到的總數(shù)和最大連續(xù)缺口。用iperf3時習慣iperf3 -u -c 192.168.1.50 -b 100M來壓網(wǎng)卡但應(yīng)用層丟包率還是要自己的序號統(tǒng)計才準因為iperf3測的是內(nèi)核棧能收多少而Python應(yīng)用還要考慮GIL和業(yè)務(wù)耗時。我最常犯的錯是用阻塞模型搭完就上線等到并發(fā)上來才補selectors結(jié)果半包、超時一起炸?，F(xiàn)在無論多小的工具我都會先把幀緩沖器和超時策略寫進去再開始寫業(yè)務(wù)邏輯。希望這些實現(xiàn)和踩坑記錄能幫到你少走這幾段彎路。本文還有配套的精品資源點擊獲取