簡介這是一份計算機網(wǎng)絡(luò)課程實驗源碼基于Python模擬數(shù)據(jù)鏈路層的Go-Back-NGBN協(xié)議借助UDP套接字實現(xiàn)可靠文件傳輸。協(xié)議采用發(fā)送窗口滑動機制當接收端檢測到數(shù)據(jù)出錯或丟包時發(fā)送端從出錯幀開始回退重發(fā)代碼完整復現(xiàn)了這一過程。資源面向計算機、通信、自動化、電子信息等專業(yè)的學生與學習者既適合完成課程設(shè)計、上機作業(yè)也適合作為理解滑動窗口、超時重傳和確認機制的動手示例。壓縮包共含21個文件整體大小僅22KB其中12個Python腳本構(gòu)成項目核心覆蓋幀封裝與解析、文件分包與重組、UDP數(shù)據(jù)收發(fā)、地址及字節(jié)轉(zhuǎn)換、隨機差錯注入、日志輸出和配置讀取等模塊7個配置文件可調(diào)整仿真參數(shù)另有1份txt與1份md說明文檔輔助環(huán)境搭建與使用。代碼模塊劃分清晰可直接在本地運行觀察不同丟包場景下GBN協(xié)議的重傳行為也可作為基礎(chǔ)擴展實現(xiàn)選擇性重傳SR或停等式ARQ實驗。目前該資源已有425人瀏覽學習經(jīng)測試運行成功適合網(wǎng)絡(luò)課程實驗參考與二次開發(fā)。1. 傳輸總卡在“文件收不全”GBN協(xié)議實驗到底考什么很多做過《計算機網(wǎng)絡(luò)》課程實驗的人都有這種體驗用 Python 寫個 UDP 收發(fā)單條消息來回傳都正常ping 也通但只要把數(shù)據(jù)鏈路層的 GBN 協(xié)議掛上去做“可靠文件傳輸”就總在最后階段出問題——文件傳了一半卡住、校驗值對不上、重傳風暴把吞吐打沒。這個實驗考的不是你會不會調(diào) socket而是你知不知道滑動窗口、累計確認、超時重傳這三個機制如何配合才能在一個會隨機丟幀、損壞、亂序的信道上把文件原樣傳完。本篇文章會沿著“原理→源碼實現(xiàn)→參數(shù)調(diào)優(yōu)→踩坑→驗證”的順序把一個能跑通的 Python GBN 模擬數(shù)據(jù)鏈路層方案拆開講清楚。適合正在做計網(wǎng)課設(shè)的學生也適合想補一補“可靠傳輸協(xié)議落地細節(jié)”的開發(fā)者。2. 先弄懂 GBN 的可靠傳輸模型滑動窗口、累計確認與超時重傳為什么缺一不可2.1 GBN 協(xié)議在數(shù)據(jù)鏈路層管什么丟包、損壞、亂序三個對手數(shù)據(jù)鏈路層的基本功能里有一項叫可靠傳輸。物理鏈路上會出現(xiàn)三種典型的“壞人”噪聲導致比特翻轉(zhuǎn)從而讓幀損壞網(wǎng)絡(luò)擁塞或沖突導致幀丟失并行路徑或緩存抖動導致幀到達順序錯亂。如果直接把這些壞幀交給上層文件寫入輕則文件內(nèi)容對不上重則寫入流程直接崩潰。GBNGo-Back-N后退 N 幀就是針對這三類問題設(shè)計的一套滑動窗口協(xié)議。GBN 的思路非常樸素發(fā)送端允許連續(xù)發(fā)送 N 個幀但只保留一個定時器接收端只按順序接收凡是序號不是自己期望的那個幀一概丟棄。丟掉的幀怎么補靠發(fā)送端超時后把窗口內(nèi)所有已發(fā)送未確認的幀從頭重傳一遍。為什么要全部重傳而不是只傳那一個壞幀因為接收端不緩存亂序幀發(fā)送端無法確定窗口內(nèi)哪些幀被接收端收下了干脆從最早的未確認幀開始整體后退這正是“Go-Back-N”得名的由來。很多初學者會拿 TCP 的經(jīng)驗來套 GBN覺得應(yīng)該像 TCP 那樣接收端緩存亂序數(shù)據(jù)、發(fā)送端只重傳缺失段。如果你這么想就混淆了 GBN 和 SR選擇重傳。在課程實驗這種簡化模型里接收窗口為 1 是 GBN 的標志性設(shè)定接受“亂序幀必須丟棄”這個設(shè)定后面的代碼才寫得順。2.2 為什么用 Python UDP 模擬數(shù)據(jù)鏈路層而不是直接寫鏈路層課程實驗不可能讓你去改網(wǎng)卡驅(qū)動或直接操作 HDLC/PPP 幀所以常見做法是在 UDP socket 之上模擬出“一條不可靠信道”然后再在這條信道上實現(xiàn) GBN 協(xié)議。換句話說你的應(yīng)用進程里跑的這段代碼就是“模擬的數(shù)據(jù)鏈路層”UDP 扮演的是底下那根會出錯、會丟幀的物理線路。這里有一個高頻誤解有人覺得“既然學的是數(shù)據(jù)鏈路層就應(yīng)該拿 TCP 來做”。恰恰相反UDP 沒有擁塞控制、沒有重傳、沒有滑動窗口才能讓你自己實現(xiàn)完整鏈路邏輯如果用 TCP底層把丟包重傳全干了你的 GBN 代碼根本觸發(fā)不了超時實驗結(jié)果永遠是“一次通過”什么都學不到。還有一個重要細節(jié)UDP 只能保證“數(shù)據(jù)報的發(fā)送順序”在絕大多數(shù)情況下等于到達順序但它不承諾不丟、不亂、不錯。在局域網(wǎng)本地回環(huán)上測試時丟包率接近 0很多問題根本暴露不出來。為了讓實驗具有演示價值和說服力通常需要在發(fā)送端或一個中間轉(zhuǎn)發(fā)函數(shù)里人為引入丟包和損壞概率制造“不可靠信道”的效果。這一步看著不復雜但恰恰是后面驗證 GBN 是否真的可靠的關(guān)鍵。2.3 窗口模型與序號空間的約束WINDOW 能設(shè)多大、為什么 W 必須小于序號空間GBN 的性能優(yōu)勢來自連續(xù)發(fā)送。設(shè)信道時延為 RTT若采用停等協(xié)議發(fā)送端每發(fā)一幀都要等確認鏈路利用率大致是 1/(1 2a)而 GBN 的發(fā)送窗口為 W 時理論上可以把利用率拉到接近 W 倍。窗口越寬吞吐越高但窗口不可能無限大因為序號字段是有限的。以常見實現(xiàn)為例如果序號用 1 字節(jié)表示取值范圍是 0~255那么發(fā)送窗口 W 的最大值必須滿足 W 256。更嚴謹?shù)慕Y(jié)論來自“新舊幀區(qū)分問題”發(fā)送端重傳一個舊幀時如果它的序號和接收端期待的“下一個新幀序號”重合接收端會誤判新幀導致重復寫入。因此標準結(jié)論是對于 n 位序號GBN 的最大發(fā)送窗口為 W_max 2^n - 1。我在課設(shè)里一般會做兩層冗余保險序號字段直接用 2 字節(jié)struct 的 H 格式取值范圍擴大到 0~65535窗口大小壓到 4~16 之間。窗口開得過大不僅讓“新舊識別”變得危險還會把 UDP 接收緩沖區(qū)打爆這在 5.3 節(jié)會細說。你如果看到一個 WINDOW 參數(shù)第一反應(yīng)應(yīng)該是把序號位數(shù)抄出來算一下邊界而不是直接調(diào)大窗口跑。邊界沒守住時出現(xiàn)的故障現(xiàn)象往往非常隱蔽——文件偶爾能傳對偶爾會在中間多出一段重復內(nèi)容。3. 把 GBN 協(xié)議跑起來Python 發(fā)送端、接收端與文件分幀實現(xiàn)3.1 實驗環(huán)境Python 安裝與 vscode 配置只依賴標準庫開始寫代碼前先確認環(huán)境裝好 Python 3.8 以上版本即可Windows、Linux、macOS 都行。用 vscode 的話裝一下官方 Python 擴展就能跑用 pycharm 配置 python 環(huán)境也一樣。這個實驗只用 socket、struct、zlib、threading、random 這些標準庫不需要 pip install 任何第三方包所以環(huán)境問題幾乎不會卡住你。工程文件建議拆成三個模塊gbn_common.py放幀封裝、解析和 CRC 校驗函數(shù)gbn_sender.py放發(fā)送端邏輯gbn_receiver.py放接收端邏輯。這樣你在調(diào) bug 時可以單獨 import 某個函數(shù)做單元測試。UDP 通信地址用127.0.0.1:8000接收端 bind 這個端口發(fā)送端向它發(fā)數(shù)據(jù)。如果要在兩臺機器上做演示把收發(fā)地址換成真實 IP 即可但記得關(guān)閉防火墻或放行對應(yīng) UDP 端口。3.2 幀結(jié)構(gòu)設(shè)計與 CRC 校驗兩個函數(shù)搞定組幀和驗幀幀結(jié)構(gòu)是整個協(xié)議的地基。我采用的幀格式為2 字節(jié)序號、1 字節(jié)幀類型、2 字節(jié)數(shù)據(jù)長度、4 字節(jié) CRC32、變長 payload。幀類型定義兩個值0 表示文件頭幀寫入文件名、文件大小、總塊數(shù)1 表示數(shù)據(jù)幀。文件頭單獨用一種幀是因為接收端必須先拿到文件信息才能創(chuàng)建文件和判斷傳輸完成條件。# gbn_common.py幀封裝、解析、CRC校驗 import struct, zlib TYPE_FILE_HEADER 0 TYPE_DATA 1 HEADER_LEN 9 # H B H I 2 1 2 4 def make_file_header(seq: int, name: str, size: int, total_blocks: int) - bytes: payload b\n.join([name.encode(), str(size).encode(), str(total_blocks).encode()]) return make_frame(seq, TYPE_FILE_HEADER, payload) def make_data_frame(seq: int, payload: bytes) - bytes: return make_frame(seq, TYPE_DATA, payload) def make_frame(seq: int, ftype: int, payload: bytes) - bytes: # 校驗對象包含 序號類型payload防止 seq/type 被篡改而漏檢 crc zlib.crc32(struct.pack(!H B, seq, ftype) payload) 0xffffffff header struct.pack(!H B H I, seq, ftype, len(payload), crc) return header payload def parse_frame(frame: bytes): if len(frame) HEADER_LEN: return None seq, ftype, length, crc struct.unpack(!H B H I, frame[:HEADER_LEN]) payload frame[HEADER_LEN:HEADER_LEN length] calc zlib.crc32(struct.pack(!H B, seq, ftype) payload) 0xffffffff if calc ! crc: return None # 校驗失敗調(diào)用方直接丟幀 return seq, ftype, payload代碼邏輯不復雜但有三個關(guān)鍵點值得說。第一CRC 的計算范圍把“序號類型”也包括進去了這樣如果有人模擬鏈路層噪聲把 seq 字段翻轉(zhuǎn)了校驗也能發(fā)現(xiàn)只對著 payload 算 CRC 是課設(shè)里最常見的漏檢寫法。第二struct.pack(!H B H I, ...)里的感嘆號表示網(wǎng)絡(luò)字節(jié)序發(fā)送和解析統(tǒng)一用這個格式就不會出現(xiàn) ACK 序號解析錯位的怪問題。第三幀頭固定 9 字節(jié)接收端拿到完整幀后先校驗再處理先處理后校驗是本實驗頭號坑之一。3.3 發(fā)送端核心循環(huán)窗口發(fā)送、累計確認、超時重傳發(fā)送端是 GBN 機制中邏輯最重的一端。它要維護兩個指針base指向窗口內(nèi)最老的未確認幀next_seq指向下一個待發(fā)送的新幀。窗口未滿且還有數(shù)據(jù)就連續(xù)發(fā)送收到 ACK 后把base推進超時則把base到next_seq-1的所有幀全部重發(fā)。# gbn_sender.py發(fā)送端核心循環(huán)節(jié)選 import socket, struct, zlib, time from collections import deque HOST, PORT 127.0.0.1, 8000 WINDOW 8 # 發(fā)送窗口大小 TIMEOUT 0.3 # 重傳超時秒局域網(wǎng)可取 0.2~0.5 BLOCK 1024 # 每個數(shù)據(jù)幀 payload 大小 sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.settimeout(TIMEOUT) addr (HOST, PORT) # 第0幀文件頭用停等方式先確認保證接收端拿到文件信息 header_frame make_file_header(0, test.bin, file_size, total_blocks) while True: sock.sendto(header_frame, addr) try: ack, _ sock.recvfrom(1024) if parse_ack(ack) 0: break except socket.timeout: continue base, next_seq 1, 1 frame_cache {} # 窗口內(nèi)緩存用于超時重傳 while base total_blocks: # 窗口沒滿就繼續(xù)發(fā)這是 GBN 連續(xù)發(fā)送的關(guān)鍵 while next_seq base WINDOW and next_seq total_blocks: frame make_data_frame(next_seq, chunks[next_seq - 1]) frame_cache[next_seq] frame sock.sendto(frame, addr) next_seq 1 try: ack, _ sock.recvfrom(1024) ack_seq parse_ack(ack) if ack_seq base: base ack_seq 1 # 累計確認ACK(5) 表示 0~5 全部收到 for i in list(frame_cache): if i ack_seq: del frame_cache[i] except socket.timeout: # Go-Back-N 的核心動作超時窗口內(nèi)全部重傳 for i in range(base, next_seq): sock.sendto(frame_cache[i], addr) time.sleep(0.001) # 輕微限速避免瞬間打爆 UDP 緩沖這個循環(huán)里有三個決定可靠性的細節(jié)。第一個是“累計確認推進 base”收到ack_seq后直接讓base ack_seq 1因為 GBN 的 ACK 攜帶的是“目前已連續(xù)確認到的最大序號”不需要為窗口內(nèi)每一幀單獨確認。第二個是超時后重傳全部窗口幀而不是只重傳base幀這正是和 SR 協(xié)議的最大區(qū)別。第三個是frame_cache只保留窗口內(nèi)的幀ACK 推進后及時清理避免大文件造成內(nèi)存膨脹。3.4 接收端核心循環(huán)期望序號校驗、落盤與重復 ACK接收端比發(fā)送端簡單很多它只有一個狀態(tài)expected即下一個期待到達的幀序號。任何 CRC 失敗或序號不等于expected的幀一律丟棄但要把上一次正確確認的 ACK 再回一遍這就是“重復 ACK”。發(fā)送端收到重復 ACK 后不會立即重傳而是在超時后把整個窗口再推一遍從而補上缺失的幀。# gbn_receiver.py接收端核心循環(huán)節(jié)選 import socket, struct, zlib HOST, PORT 127.0.0.1, 8000 sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.bind((HOST, PORT)) sock.setsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF, 1 20) # 階段1循環(huán)收文件頭直到校驗通過且序號為0 file_info None while file_info is None: data, peer sock.recvfrom(2048) parsed parse_frame(data) if parsed is None: continue seq, ftype, payload parsed if ftype TYPE_FILE_HEADER and seq 0: parts payload.split(b\n) file_name, file_size, total_blocks parts[0].decode(), int(parts[1]), int(parts[2]) send_ack(sock, peer, 0) file_info (file_name, file_size, total_blocks) expected 1 # 階段2按序收數(shù)據(jù)幀寫文件 received 0 with open(file_name, wb) as f: while received total_blocks: data, peer sock.recvfrom(2048) parsed parse_frame(data) if parsed is None: send_ack(sock, peer, expected - 1) # 損壞幀回重復ACK continue seq, ftype, payload parsed if seq ! expected: send_ack(sock, peer, expected - 1) # 亂序幀丟棄不緩存 continue f.write(payload) received 1 expected 1 send_ack(sock, peer, expected - 1)重復 ACK 的設(shè)計容易被人忽略但它是 GBN 接收端唯一的“反饋手段”。如果沒有這一行接收端丟棄壞幀后保持沉默發(fā)送端就只能在超時后才反應(yīng)過來平均恢復時間變長。有了重復 ACK發(fā)送端雖然不會立即重傳但至少能確認“鏈路還活著、發(fā)送窗口也沒有被錯誤推進”。另外注意send_ack(sock, peer, expected - 1)中發(fā)送的是expected - 1而不是expected因為 ACK 的含義是“序號為 n 的幀及其之前的全部幀都已收到”發(fā)expected會被發(fā)送端誤認為一個超前確認。4. 可靠文件傳輸?shù)年P(guān)鍵參數(shù)幀長、RTO、WINDOW 怎么配合4.1 控制幀與數(shù)據(jù)幀分開發(fā)文件名的可靠傳法文件頭幀承載文件名、文件大小、總塊數(shù)這三項缺一不可。文件頭如果混入 GBN 窗口里一起發(fā)會引入一個確定性的死鎖接收端還沒收到文件頭不知道總塊數(shù)數(shù)據(jù)幀來了也無法判斷“這是第幾塊、要不要落盤”只能全丟。而發(fā)送端又可能在窗口推進后把文件頭幀清出緩存導致永遠無法重傳。常見做法是讓文件頭走一次“停等確認”流程——發(fā)送端循環(huán)發(fā)送文件頭幀直到收到針對序號 0 的 ACK再進入數(shù)據(jù)段。這在代碼層面多寫一個while True但把兩條不同可靠性的路徑徹底分開避免了大量邊界 bug。有些現(xiàn)成源碼把文件頭也當成普通數(shù)據(jù)幀直接塞進窗口我的經(jīng)驗是這種實現(xiàn)大概率在丟包率稍高時“偶發(fā)失敗”且極難復現(xiàn)。4.2 校驗選 zlib.crc32 還是 hashlib.md5代價與收益幀級校驗我用zlib.crc32運算速度快單個 1024 字節(jié)幀校驗耗時微秒級。CRC32 對隨機比特損壞的漏檢率約為 2^-32對這個實驗已經(jīng)非常安全。哈希完成后做一次“整文件比對”會更有說服力傳輸結(jié)束在接收端算一個 MD5發(fā)送端也算一個 MD5兩邊一致說明全程沒有出現(xiàn)檢測不到的損壞。整文件用 MD5 沒問題但把 MD5 放進每一幀就很不劃算處理器的開銷會拉低吞吐而且每一幀都做安全哈希對課設(shè)來說沒有必要。還有一個容易踩的細節(jié)有些實現(xiàn)會把序號和類型字段排除在 CRC 范圍之外。如果信道噪聲恰好轉(zhuǎn)了序號位payload 的校驗還是通過接收端就會把這個幀當作另一個序號的合法幀寫入文件造成靜默數(shù)據(jù)錯位。只要把struct.pack(!H B, seq, ftype) payload一起丟進 CRC 計算這個隱患就從根上消除了。4.3 三個必調(diào)參數(shù)WINDOW、TIMEOUT、塊大小的經(jīng)驗值與公式參數(shù)建議值設(shè)置依據(jù)塊大小512~1024 字節(jié)小于常規(guī) UDP 路徑 MTU減少 IP 分片本實驗 buffer 設(shè) 2048 也夠WINDOW4~16序號用 2 字節(jié)時最大窗口為 65535但實際受接收緩沖和演示效果限制TIMEOUT2 倍 RTT先測出單程 RTT再乘 2局域網(wǎng)一般 0.1~0.5 秒別低于 50ms序號位寬2 字節(jié)用 struct 的!H打包天然規(guī)避 1 字節(jié)序號的“新老幀撞車”TIMEOUT 設(shè)小了會發(fā)生“重傳風暴”幀其實沒丟只是 ACK 慢了一點發(fā)送端就急著重傳導致接收端收到大量重復幀吞吐率直線下降。TIMEOUT 設(shè)大了則丟幀后恢復慢假設(shè) RTT 是 5ms超時設(shè) 2 秒那么一個丟幀要等 2 秒才觸發(fā)重傳傳一個大文件要卡很多次。我調(diào)試時會在代碼里打印每次 ACK 的到達間隔取平均值的 2~3 倍作為超時值。WINDOW 和接收端緩沖區(qū)要配套。窗口開到 16每幀 1024 字節(jié)一瞬間就是 16KB 數(shù)據(jù)涌進接收端如果接收端的recvfrom處理速度不夠UDP 接收緩沖滿了就直接丟幀底層丟幀會讓 GBN 進入反復重傳的惡性循環(huán)。接收端初始化時調(diào)大 socket 緩沖區(qū)是個好習慣sock.setsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF, 1 20)可以放到開頭。4.4 文件寫回的邊界處理最后一塊不滿和重復幀寫文件的邏輯看起來只是一句f.write(payload)但邊界問題全在“塊大小”上。文件的最后一個分塊很可能不足 512 或 1024 字節(jié)接收端如果總按固定大小寫文件尾部就會多出一截舊數(shù)據(jù)或空字節(jié)。解決方式是以幀頭里的 length 字段為準parse_frame返回的 payload 本身就是按 length 切開的字節(jié)串write出來長度天然正確。重復幀是另一個邊界問題。超時重傳機制會帶來重復幀接收端靠seq ! expected直接丟棄這是對的。但要警惕一種“部分重復”的情形假設(shè)接收端已經(jīng)寫入了第 5 幀并推進expected到 6此時一個重傳的第 5 幀到達會被丟棄可是如果這個重傳幀在傳輸過程中又被截斷而變成另一個長度CRC 會先失敗根本進不到序號判斷這層。所以說“先校驗、后判斷序號、最后寫文件”這三步順序一個都不能換。5. GBN 實驗避坑與排查從卡死到文件對不上的五條踩坑記錄5.1 現(xiàn)象打開丟包模擬后程序卡死進度條不動原因出在校驗和執(zhí)行順序上。不少實現(xiàn)把parse_frame的結(jié)果直接拿來寫文件忽略了 CRC 校驗失敗時的處理分支或者在校驗前就把數(shù)據(jù)寫入了文件導致文件內(nèi)容錯位后續(xù)所有幀的序號判斷都亂了。還有一種情況是丟包率設(shè)置過高比如 30% 甚至 50%發(fā)送端重傳的幀也一直在丟窗口內(nèi)所有幀全部被清空recvfrom永遠等不到 ACK。解決思路分兩步。先檢查接收端是否是“先校驗、后寫文件、再回 ACK”的正確順序在parse_frame返回None時一定要走重復 ACK 分支。再把丟包率降到 5%~10%這是讓 GBN 表現(xiàn)出“重傳后仍能完成傳輸”的合理區(qū)間。最后給發(fā)送端加日志打印base、next_seq和ack_seq看是不是base一直停在原地——如果是說明某幀永遠沒收到而接收端也沒能把期望序號推進。5.2 現(xiàn)象傳完了但 md5 不一致文件尾部多了幾行舊數(shù)據(jù)現(xiàn)象是 md5 對比失敗仔細檢查發(fā)現(xiàn)接收文件比原文件長。原因基本可以鎖定在“最后一塊寫滿固定長度”這個錯誤上。比如塊大小是 1024文件大小是 2500 字節(jié)分成三塊分別是 1024、1024、452如果第三塊寫文件時硬寫 1024 字節(jié)文件就變成 3072 字節(jié)多出 572 字節(jié)的殘留數(shù)據(jù)。這些殘留往往來自發(fā)送緩沖區(qū)的舊數(shù)據(jù)很難靠肉眼發(fā)現(xiàn)。解決方法是所有寫入的 payload 都嚴格按幀頭給出的 length 字段切片不要用BLOCK常量去截斷。同時傳輸完成后可以用一個最終校驗來復盤接收端用hashlib.md5()對整個文件算一遍摘要打印出來和發(fā)送端比對。參考命令是md5sum received.bin和md5sum original.bin兩邊一致就說明這個鏈路真正做到了可靠文件傳輸。5.3 現(xiàn)象窗口調(diào)到 32 后性能暴跌甚至數(shù)據(jù)錯亂窗口增大通常預(yù)期吞吐提升但調(diào)到 32 后反而出現(xiàn)大量重傳、文件內(nèi)容偶爾重復。根源是序號空間不夠用。如果實現(xiàn)中序號用 1 字節(jié)表示取值范圍只有 0~255當窗口滑動到接近 256 時新幀序號的剩余空間不足重傳一個舊幀時接收端無法區(qū)分“這是重傳的舊幀”還是“合法的新幀”于是把重復數(shù)據(jù)寫入文件。解決方法是把序號改到 2 字節(jié)用struct.pack(!H, seq)取值范圍拉到 65535窗口 32 就不再觸碰邊界。同時記得遵守“2^n - 1”的最大窗口約束加上實驗習慣性的保守策略窗口不超過序號空間一半。調(diào)試時打印一下重傳次數(shù)如果發(fā)現(xiàn)窗口增大后每傳 100 幀重傳超過 30 次就要回頭查序號位寬和接收緩沖兩個地方。5.4 現(xiàn)象base 一直不動超時后反復重傳但 ACK 序號不對表現(xiàn)為發(fā)送端一直在超時重傳但收到的 ACK 總是小于base窗口推不動。先不要懷疑丟包率先懷疑 ACK 包的語義和解析。常見錯誤有兩種一是接收端發(fā)了expected而不是expected - 1導致發(fā)送端認為“接收端在等一個更靠后的幀”base永遠小于ack_seq二是struct.pack和unpack的字節(jié)序不一致比如發(fā)送用!H解析用H序號在本地小端和網(wǎng)絡(luò)大端之間被錯誤解釋。解決方法是統(tǒng)一字節(jié)序在gbn_common.py的parse_ack和make_ack里都用!H格式。然后加一行調(diào)試日志在發(fā)送端收到 ACK 后打印ack_seq人工驗證它是否符合“收到的最后一個連續(xù)序號”語義。還要注意 ACK 幀也應(yīng)該包含類型字段防止把數(shù)據(jù)幀的 payload 誤當成 ACK 序號來解析。5.5 現(xiàn)象本機回環(huán)測試正常局域網(wǎng)測試卻偶發(fā)卡頓在127.0.0.1上跑UDP 基本不會丟包內(nèi)核直接走回環(huán)路徑GBN 很難真正體現(xiàn)重傳。一旦換到真實局域網(wǎng)無線信號波動、網(wǎng)卡隊列溢出、交換機緩存抖動都會造成真實丟包這時重傳頻率升高是正常的。但如果卡頓嚴重到無法完成大文件傳輸更可能是接收端 UDP 緩沖區(qū)過小發(fā)送端瞬時灌入的窗口幀被內(nèi)核直接丟棄導致每次都是整窗重傳。解決方法是接收端初始化時設(shè)置SO_RCVBUF為 1MB 以上發(fā)送端在重傳循環(huán)里加一個time.sleep(0.001)做輕微限速。另一個實用技巧是在發(fā)送端統(tǒng)計“總發(fā)送幀數(shù) / 文件總幀數(shù)”這個比值稱為重傳開銷系數(shù)系數(shù)越接近 1 說明信道越干凈大于 2 說明鏈路條件很差或參數(shù)沒調(diào)對。把這個指標打到終端比盯著進度條更容易看出系統(tǒng)的健康狀況。6. 三個必測場景驗證 GBN 實現(xiàn)丟包率、校驗損壞與窗口對比驗證 GBN 做沒做對不能只跑一次“順利傳輸”就收工。我通常會準備三個固定場景在發(fā)送端掛一個信道模擬函數(shù)# channel.py模擬不可靠信道的丟包與比特損壞 import random def channel(frame: bytes, loss_rate0.1, corrupt_rate0.03): if random.random() loss_rate: return None # 模擬丟幀 if random.random() corrupt_rate: frame bytearray(frame) pos 9 random.randrange(len(frame) - 9) frame[pos] ^ 0xff # 模擬比特翻轉(zhuǎn) return bytes(frame) return frame場景一是loss_rate0, corrupt_rate0的全干凈信道。這個場景驗證的是基準正確性窗口發(fā)送、ACK 推進、文件落盤三個環(huán)節(jié)沒有邏輯錯誤。文件傳完后 md5 必須一致且重傳次數(shù)應(yīng)該為 0如果此時出現(xiàn)了重傳說明超時閾值設(shè)得太小。場景二是loss_rate0.1, corrupt_rate0.03的常規(guī)不可靠信道。這個場景驗證 GBN 的糾錯能力允許重傳次數(shù)小幅上升但傳輸必須完成且 md5 一致。重點觀察每次丟幀后發(fā)送端恢復的速度以及重復 ACK 是否讓發(fā)送端及時感知鏈路狀況。如果卡住超過 2 秒多半是超時閾值設(shè)得過大或接收端丟棄亂序幀后沒有回重復 ACK。場景三是窗口對比測試。把WINDOW分別設(shè)為 1、4、8、16 各跑一遍同一個文件記錄耗時和重傳次數(shù)。其結(jié)果通常是一條先降后升的曲線窗口 1 接近停等吞吐最低窗口 8 左右最優(yōu)窗口 16 時如果接收緩沖沒調(diào)大吞吐反而會因重傳而下降。把這個結(jié)果放進實驗報告比空談“滑動窗口提升利用率”有說服力得多。我自己的一個習慣是跑正式演示前先保留一份帶丟包模擬的腳本版本課堂上專門用它表演丟幀和自愈最后再切換到干凈信道做完整文件接收。這樣的演示既有說服力又不會在關(guān)鍵時刻因為人為故障而翻車。希望這份 GBN 協(xié)議的落地拆解能幫你把課設(shè)做得更扎實也少走一點那些只有踩過才知道的彎路。本文還有配套的精品資源點擊獲取