簡介一份計算機網絡課程實驗源碼基于Python模擬數(shù)據鏈路層的GBNGo-Back-N回退N幀協(xié)議并實現(xiàn)可靠文件傳輸適合計算機網絡、通信工程、自動化等專業(yè)的在校學生和教師用于課程設計、實驗與畢業(yè)設計也適合初學者對照理解滑動窗口、序號確認和自動重傳機制。資源為zip壓縮包大小約22KB共21個文件其中12個Python源文件構成協(xié)議核心與工具模塊7個INI配置文件用于參數(shù)初始化另有README和說明文檔輔助快速上手。實現(xiàn)內容涵蓋幀構造與解析、差錯校驗、發(fā)送和接收窗口維護、超時重傳、文件分塊重組、UDP封裝及日志配置等完整流程并附有自動測試腳本可直接運行驗證協(xié)議狀態(tài)變化也方便在此基礎上擴展其他功能。目前已有425人學習/下載是一份輕量且典型的GBN可靠傳輸參考實現(xiàn)。1. 計算機網絡課程實驗里的GBN一個Python模擬器能解決什么數(shù)據鏈路層GBN協(xié)議的課程實驗通常有個硬性交付要求用Python模擬實現(xiàn)協(xié)議并讓它完成一次可靠文件傳輸。教材上的滑動窗口畫得清清楚楚真到寫代碼收發(fā)文件時丟包重傳、超時定時、序號回繞輪番上場能把一臺電腦從“傳輸完成”卡到“進程假死”。這個實驗的意義不在于背下Go-Back-N的定義而是把“確認”“重傳”“窗口”這些抽象機制落到socket、字節(jié)流和定時器上讓自己親手造出一個能在不可靠信道里把文件原樣送到的程序。本文按課程實驗的常見做法把GBN協(xié)議從原理到源碼拆開講該寫哪些類、幀怎么設計、參數(shù)怎么定、哪里最容易翻車照著復現(xiàn)就能交付。2. 先把GBN協(xié)議拆明白滑動窗口、累積確認與序號回繞在動手寫任何代碼之前先把協(xié)議的行為邊界定清楚。GBN全稱Go-Back-N發(fā)送端維護一個大小為N的滑動窗口窗口內未確認的幀可以連續(xù)發(fā)出去接收端只按序接收、只回累積確認。信道只要丟一個幀發(fā)送端超時后就把窗口內所有幀重傳一遍“后退N幀”因此得名——這是它在效率上優(yōu)于停等協(xié)議、又比選擇重傳SR簡單的原因。2.1 滑動窗口為什么比停等協(xié)議快帶寬時延積是根本原因停等協(xié)議發(fā)送一幀就要等確認一個RTT內信道大部分時間是空的。GBN用窗口把多個幀“塞”在鏈路上讓吞吐量逼近帶寬與時延之積。課程實驗里通常用UDP模擬底層信道接收方收到正確幀就回一個ACK發(fā)送方在沒有收到ACK的超時點重傳這樣就把“流水線”效果跑出來了。窗口數(shù)N不是越大越好。N受兩個約束一是接收端的接收能力二是序號空間必須能容納窗口內所有幀否則接收端無法區(qū)分新幀和重傳幀。實驗里常見做法是把N設成4到16之間的整數(shù)幀大小1KB既能看到窗口滑動效果又不會因為序號回繞把自己繞進去。2.2 累積確認是GBN的命門接收端只認按序到達的幀GBN接收端的邏輯比發(fā)送端簡單得多只接收seq等于期望序號的那一幀收到后把期望序號加1同時回一個攜帶該序號的ACK任何亂序到達的幀無論它是不是已經在接收緩存里全部丟棄并重新發(fā)送最后一個ACK。這個“丟棄亂序幀”的行為是GBN和SR協(xié)議最本質的區(qū)別。不少人在實現(xiàn)里給接收端加了緩存把亂序幀先存起來——這實際上是SR的做法不是GBN。接收端不加緩存換來的是接收邏輯極其簡單一個expected_seq變量、一個按序存儲的字典、一條“丟幀就重發(fā)ACK”的規(guī)則。發(fā)送端收到重復ACK后不會立即重傳那是快速重傳屬于TCP的機制而是繼續(xù)等超時超時后才把整個窗口重發(fā)這就是“后退N”的含義。實驗報告里如果能把這個區(qū)別寫清楚老師會認為你是真的理解協(xié)議而不是照抄。2.3 序號空間與窗口大小的不等式回繞問題在動手前就定死序號回繞是GBN實驗里最隱蔽的坑。假如序號空間只有8個序號0到7窗口也是8發(fā)送端發(fā)完0到7號幀后下一個待發(fā)序號變成0此時接收端收到的0號幀到底是新幀還是重傳幀根本無法區(qū)分。標準結論是序號空間必須大于等于窗口大小的兩倍即max_seq 2 * window_size才能確保窗口內的任意兩個幀序號互不重疊。實驗里我一般把序號上限設成256窗口設成8留足余量。這樣在判斷“收到ACK后窗口下沿base移動到哪里”時只需要簡單的整數(shù)加法和取模不需要處理“窗口跨過序號最大值”的環(huán)形邊界。如果你想讓窗口和序號空間都壓到極限比如窗口8、序號空間16那就要在收發(fā)兩端同時維護“當前窗口跨越0點”的狀態(tài)位復雜度會明顯上升——課程實驗不追求這個勸你不要自己加難度。2.4 Python模擬不可靠信道丟包、損壞、亂序三層疊加GBN的“可靠”是相對“不可靠信道”而言的。如果直接用TCP傳輸協(xié)議棧自己就做了重傳和排序GBN的模擬就完全失去意義。課程實驗的標準做法是用UDP收發(fā)數(shù)據在UDP之上自己加一個信道模擬層讓幀以一定概率被丟棄、被破壞、被延遲。模擬信道通常做成一個獨立類內部維護三個參數(shù)丟包率loss_rate、損壞率corrupt_rate、亂序開關。丟包就是隨機丟幀不發(fā)損壞是把幀里的某個字節(jié)翻轉后發(fā)送亂序則是把后發(fā)送的幀先發(fā)出去一般通過隨機交換sendto順序來模擬。這三層可以疊加也能單獨開關用來做對照實驗非常方便。后面的實現(xiàn)章節(jié)里這個信道類只需要幾十行代碼重點在于參數(shù)暴露給外部方便測試時調。3. 用Python實現(xiàn)GBN最小閉環(huán)幀格式、Sender與Receiver三個核心代碼結構上我建議按三個文件拆分frame.py放幀封裝和解析channel.py放不可靠信道模擬gbn.py放Sender和Receiver兩個類。課程設計查重看的是邏輯不是文件數(shù)量但清晰分層的好處是排錯時能快速定位問題。下面從幀格式開始逐個給出可直接用的實現(xiàn)。3.1 幀格式與校驗和struct打包把頭部定死幀是收發(fā)雙方唯一的交流語言格式必須完全一致。常見的做法是頭部固定11字節(jié)按網絡序大端打包1字節(jié)類型、2字節(jié)序號、4字節(jié)數(shù)據長度、4字節(jié)校驗和后面緊跟數(shù)據體。校驗和用zlib.crc32對數(shù)據部分取低16位雖然碰撞概率在實驗場景下足夠低但比純加和取模可靠得多。import struct import zlib FRAME_TYPE_DATA 1 FRAME_TYPE_ACK 2 FRAME_TYPE_FIN 3 BASE_HEADER_SIZE struct.calcsize(!BHII) def build_frame(seq, data, ftypeFRAME_TYPE_DATA): # 數(shù)據部分是 bytes長度由 len(data) 決定 checksum zlib.crc32(data) 0xffff header struct.pack(!BHII, ftype, seq, len(data), checksum) return header data def parse_frame(raw): if len(raw) BASE_HEADER_SIZE: return None ftype, seq, length, checksum struct.unpack(!BHII, raw[:BASE_HEADER_SIZE]) data raw[BASE_HEADER_SIZE:] if len(data) ! length: return None if (zlib.crc32(data) 0xffff) ! checksum: return None # 校驗失敗按損壞幀丟棄 return ftype, seq, datastruct.pack的格式串!BHII表示網絡字節(jié)序、1字節(jié)無符號整數(shù)、2字節(jié)無符號整數(shù)、兩個4字節(jié)無符號整數(shù)收發(fā)兩端只要用同一套格式和順序就不會解析錯。校驗和在這里只覆蓋數(shù)據體嚴謹?shù)膮f(xié)議會把頭部字段一并納入校驗范圍課程實驗這樣寫已經夠用但報告里可以主動指出這個取舍。接收端解析時先判斷長度是否達到頭部大小再核對數(shù)據長度與校驗和。任何一個環(huán)節(jié)失敗都返回None調用方直接丟棄該幀——這就是模擬“損壞幀被接收端識別并拋棄”的過程。3.2 不可靠信道類把UDP變成會丟幀的黑匣子信道類的設計目標是讓Sender和Receiver在代碼里感受不到“信道不可靠”這回事所有丟包、損壞都發(fā)生在sendto的一瞬間。這樣做的好處是協(xié)議代碼里不需要摻入random判斷邏輯更貼近教材描述。import random class UnreliableChannel: def __init__(self, sock, loss_rate0.2, corrupt_rate0.05): self.sock sock self.loss_rate loss_rate self.corrupt_rate corrupt_rate def sendto(self, package, addr): # 模擬信道丟包直接不發(fā) if random.random() self.loss_rate: return # 模擬信道損壞翻轉數(shù)據體的第1個字節(jié) if random.random() self.corrupt_rate: pkg bytearray(package) pkg[BASE_HEADER_SIZE] ^ 0xFF package bytes(pkg) self.sock.sendto(package, addr)調用時只要把全局所有sendto換成分發(fā)到channel.sendto收發(fā)雙方便都不需要感知丟包邏輯方便后面做對照實驗。損壞幀翻轉的是數(shù)據體首字節(jié)這個位置最容易讓接收端的校驗失敗同時又不會破壞頭部導致解析直接崩潰——故意設計成“能被識別出來的損壞”。注意亂序模擬這里沒有展開。常見的做法是在信道內部維護一個小隊列隨機把新到的幀插到隊首實現(xiàn)亂序到達。課程實驗里丟包和損壞兩檔已經足夠演示可靠傳輸?shù)暮诵倪壿媮y序開關按需再加。3.3 Sender端發(fā)送窗口、緩存隊列與超時重傳Sender是GBN實現(xiàn)中最復雜的部分它同時要管三件事窗口沒滿時持續(xù)發(fā)幀、收到ACK后推進窗口下沿、超時后重傳窗口內所有幀。下面這個實現(xiàn)用select.select做定時等待避免了用time.sleep阻塞主循環(huán)導致無法及時響應ACK的問題。import select import socket class GbnSender: def __init__(self, sock, receiver_addr, window_size8, timeout0.5): self.sock sock self.receiver_addr receiver_addr self.window_size window_size self.timeout timeout self.base 0 # 窗口下沿最小的未確認序號 self.next_seq 0 # 下一個待發(fā)送幀的序號 self.buffer {} # 已發(fā)出但未確認的幀緩存 self.channel UnreliableChannel(sock) def run(self, file_bytes, chunk_size1024): chunks [file_bytes[i:ichunk_size] for i in range(0, len(file_bytes), chunk_size)] total len(chunks) fin_sent False while self.base total or not fin_sent: # 窗口未滿且還有數(shù)據幀要發(fā) while self.next_seq total and \ self.next_seq - self.base self.window_size: pkg build_frame(self.next_seq, chunks[self.next_seq]) self.buffer[self.next_seq] pkg self.channel.sendto(pkg, self.receiver_addr) self.next_seq 1 # 所有數(shù)據幀已發(fā)出補一發(fā) FIN 幀 if self.next_seq total and not fin_sent: self.channel.sendto(build_frame(total, b, FRAME_TYPE_FIN), self.receiver_addr) fin_sent True readable, _, _ select.select([self.sock], [], [], self.timeout) if readable: raw, _ self.sock.recvfrom(65535) frame parse_frame(raw) if frame and frame[0] FRAME_TYPE_ACK: ack_seq frame[1] while self.base ack_seq: self.buffer.pop(self.base, None) self.base 1 else: # 超時把窗口內所有未確認幀全部重傳 for seq in range(self.base, self.next_seq): if seq in self.buffer: self.channel.sendto(self.buffer[seq], self.receiver_addr)while self.base total or not fin_sent是整個發(fā)送過程的終止條件窗口內的幀沒確認完或者FIN沒發(fā)出循環(huán)就不能結束。select.select收到超時返回時會命中else分支把base到next_seq之間的所有緩存幀重新發(fā)一遍——這正是“后退N”的體現(xiàn)而不是只重傳丟失的那一幀。窗口是否滿的判斷寫成了self.next_seq - self.base self.window_size。窗口大小為8時未確認的幀數(shù)最多8個。需要注意這里沒有處理序號回繞因為實驗里文件拆出的幀數(shù)遠小于序號上限序號單調遞增不會繞回0。3.4 Receiver端按序接收、丟棄亂序幀與ACK回傳Receiver的任務比Sender簡單循環(huán)收幀校驗遇到期望的幀就存下來并回ACK遇到亂序幀就丟棄并重發(fā)上一次的ACK。流程寫得樸素一點反而更符合GBN的語義。class GbnReceiver: def __init__(self, sock, output_path): self.sock sock self.output_path output_path self.channel UnreliableChannel(sock) def run(self): frames {} expected_seq 0 while True: raw, addr self.sock.recvfrom(65535) frame parse_frame(raw) if frame is None: continue # 損壞幀直接丟 ftype, seq, data frame if ftype FRAME_TYPE_FIN and seq expected_seq: break # FIN 序號等于期望序號說明數(shù)據幀全部收完 if ftype FRAME_TYPE_DATA and seq expected_seq: frames[seq] data self.channel.sendto(build_frame(seq, b, FRAME_TYPE_ACK), addr) expected_seq 1 else: # 亂序幀或重復幀丟棄并重發(fā)最后一個 ACK last_ack build_frame(expected_seq - 1, b, FRAME_TYPE_ACK) self.channel.sendto(last_ack, addr) with open(self.output_path, wb) as f: for i in range(expected_seq): f.write(frames[i])亂序幀被丟棄時重發(fā)expected_seq - 1的ACK這個細節(jié)很關鍵。發(fā)送端收到重復ACK只會知道“某些幀還沒到”仍然等超時重傳符合GBN不采用快速重傳的設定。如果在這里發(fā)送expected_seq而不是expected_seq - 1反而會誤導發(fā)送端把窗口下沿往前推進破壞累積確認的語義。Receiver結束條件是收到FIN且其序號正好等于期望序號。這意味著在所有數(shù)據幀已經被按序接收之后FIN才會被接受。FIN幀本身攜帶的序號等于total正常情況下FIN不會被誤認為數(shù)據幀。3.5 文件拆幀與重組跑通一次完整還原把上面兩個類串起來的主流程非常簡單發(fā)送方讀文件字節(jié)、調用run接收方預先開始run等待幀到達。要注意UDP socket需要綁定端口且兩端端口不能沖突。# 接收端 sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.bind((127.0.0.1, 9000)) receiver GbnReceiver(sock, received.bin) receiver.run() # 發(fā)送端在另一個進程/線程 sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sender GbnSender(sock, (127.0.0.1, 9000), window_size8, timeout0.5) with open(original.bin, rb) as f: sender.run(f.read())發(fā)送端跑完后比較original.bin和received.bin的字節(jié)數(shù)以及內容哈希就能判斷傳輸是否可靠。這一步是整個實驗的驗收標準文件必須逐字節(jié)一致而不是“傳輸過程中偶爾丟點數(shù)據沒關系”。用zlib.crc32或者hashlib.md5做一致性校驗是最省事的驗證方式。4. 可靠文件傳輸?shù)膮?shù)怎么調才不翻車窗口、超時與序號空間代碼能跑通只是第一步課程實驗通常要求做性能對照——調整參數(shù)觀察重傳次數(shù)和傳輸時間的變化。參數(shù)選得不合理最典型的結果是丟包率只有10%傳輸時間卻暴漲十倍看起來像死循環(huán)。這一章把四個必調參數(shù)的取值邏輯講清楚。4.1 幀大小1KB是保守起點別挑戰(zhàn)UDP MTU幀大小直接影響兩個東西單幀的傳輸效率和損壞概率。以太網MTU通常是1500字節(jié)UDP數(shù)據報超過這個值會觸發(fā)IP分片分片后只要一片丟失整個UDP數(shù)據報就廢了——這會讓你的“GBN重傳”實際在重傳一個超過MTU的大包效率極低。課程實驗里把幀大小設為1024字節(jié)是穩(wěn)妥的既不超過常見MTU又能把1MB文件拆成1024幀左右便于觀察窗口滑動。幀調大確實能減少ACK數(shù)量但帶來的問題是單幀損壞時重傳的代價更大。GBN對每個損壞幀都要重傳窗口內的所有幀幀越大一次錯誤付出的帶寬成本越高。做過對照實驗你會發(fā)現(xiàn)幀從1KB跳到8KB時丟包率10%環(huán)境下傳輸耗時幾乎翻了四倍這就是“后退N”的放大效應。結論本地回環(huán)實驗用1024字節(jié)起步不要貪大。4.2 超時時間RTT測量的兩個極端與重傳風暴線超時時間設多長是GBN實驗里最典型的玄學。設太短ACK只是稍微晚到一點就觸發(fā)重傳信道里會堆滿重復幀接收端忙于丟棄亂序幀、重發(fā)ACK形成重傳風暴設太長丟一個幀后信道空轉很久吞吐率慘不忍睹。本地回環(huán)測試中UDP的RTT通常在亞毫秒到幾毫秒量級0.1秒的超時已經足夠寬松。如果移動到局域網環(huán)境測試建議先發(fā)幾個探測幀測量RTT把超時設為2到3倍平均RTT這是能兼顧客錯敏感性和吞吐量的經驗值。課程實驗固定用0.5秒也能過但報告里如果能寫“根據RTT動態(tài)調整超時”會明顯加分。端口和防火墻也會影響超時表現(xiàn)。如果接收端進程崩潰或者端口沒綁定發(fā)送端會一直收不到ACK每0.5秒重傳一輪看起來像死循環(huán)。排查時先確認接收端socket確實在監(jiān)聽再處理協(xié)議邏輯。4.3 窗口大小與序號空間怎么配合一個不等式兩條經驗前面2.3節(jié)講過序號空間必須至少是窗口大小的兩倍。實現(xiàn)時序號上限MAX_SEQ通常固定為256窗口大小表驅動可調。課程實驗里窗口從1調到16能畫出“吞吐率隨窗口增大而上升隨后趨平甚至下降”的曲線這條曲線本身就是報告里最好的圖表素材。窗口繼續(xù)增大會發(fā)生什么窗口內未確認幀太多接收端緩沖區(qū)壓力變大ACK返回前發(fā)送端就已經把窗口發(fā)滿后續(xù)只能干等。真實的GBN協(xié)議接收端不需要大緩存但發(fā)送端緩存會線性增長。本實驗里緩存是Python字典窗口16時占用不大如果為了性能把窗口調到64以上緩存和重傳開銷都會明顯上升曲線會出現(xiàn)拐點。兩條經驗窗口大小不超過序號空間的一半本地實驗窗口取8即可不需要追高。4.4 最后一幀確認丟失怎么辦FIN握手把文件傳輸收干凈很多人在數(shù)據幀全部發(fā)完、收到所有ACK后直接退出程序結果接收端文件少了一截——因為沒有處理“最后一個ACK丟失”的場景。數(shù)據幀重傳機制只能保證發(fā)送端確認接收如果最后一幀的ACK丟了發(fā)送端會把最后一幀重傳接收端收到重復幀后回ACK這個循環(huán)能自行收斂。但結束階段不同發(fā)送端發(fā)完FIN后如果FIN的ACK丟了接收端會一直等FIN發(fā)送端會一直以為自己已經結束并退出兩邊就僵住了。可靠的做法是發(fā)送端發(fā)FIN后不立即退出而是繼續(xù)用select等待ACK超時則重發(fā)FIN直到收到FIN對應的ACK。接收端收到FIN后回ACK并進入結束流程。下面這段是對3.3節(jié)Sender的補充邏輯# FIN 已發(fā)出繼續(xù)等待 FIN 的 ACK fin_ack_seq total fin_ack_received False while not fin_ack_received: readable, _, _ select.select([self.sock], [], [], self.timeout) if readable: raw, _ self.sock.recvfrom(65535) frame parse_frame(raw) if frame and frame[0] FRAME_TYPE_ACK and frame[1] fin_ack_seq: fin_ack_received True else: self.channel.sendto(build_frame(total, b, FRAME_TYPE_FIN), self.receiver_addr)注意frame[1] fin_ack_seq的判斷。因為FIN序號是total接收端回ACK時攜帶的序號是FIN的序號所以這里要比較大于等于而不是嚴格的等于——重復ACK可能晚到但不會小于total。這是整個可靠文件傳輸?shù)摹瓣P門動作”少了它會成為驗收時最尷尬的失敗場景。5. GBN實驗常見踩坑排查五個典型問題的現(xiàn)象與解法寫GBN實驗翻車翻得最多的不是協(xié)議理解而是實現(xiàn)細節(jié)。下面五條都是實操中反復出現(xiàn)的坑按“現(xiàn)象→原因→解決”給出排查路徑每一條都能直接對照你自己的代碼。5.1 坑1序號回繞判斷寫錯協(xié)議窗口徹底錯亂現(xiàn)象文件傳了三分之一后突然開始瘋狂重傳接收端寫入的文件出現(xiàn)大段重復數(shù)據或者程序直接拋KeyError。原因幀數(shù)量超過序號上限next_seq模運算回繞到0新幀和未確認的舊幀共享同一個序號接收端無法區(qū)分。解決把序號上限設為遠大于總幀數(shù)的值比如文件1MB、幀1KB共有1024幀序號上限設4096就足夠。如果你一定要壓著上限跑就必須在窗口跨過0點時額外維護一個current_epoch狀態(tài)接收端按“序號批次”雙重判斷復雜度翻倍不推薦。5.2 坑2校驗和用sum取模損壞幀被當成了好幀現(xiàn)象丟包率設為0、損壞率設為20%時接收端完全不報錯但還原出的文件和原文件不一致。原因用sum(data) % 65536計算校驗和字節(jié)順序調整或成對翻轉時校驗和不變損壞幀通過校驗。解決改用zlib.crc32或hashlib.md5至少在實驗報告中給出“因簡單加和無法檢測字節(jié)順序變化故改用CRC32”的說明。校驗不能覆蓋頭部的另一個隱患是攻擊者或信道篡改序號后接收端按錯誤序號存幀重組時數(shù)據錯位這種錯誤同樣要靠在頭部上增加校驗來兜底。5.3 坑3超時重傳用time.sleep程序卡成單線程現(xiàn)象設置了丟包率后發(fā)送端表現(xiàn)極不穩(wěn)定有時等好幾秒才發(fā)下一批幀接收端進度條一動不動。原因time.sleep(timeout)會阻塞整個線程阻塞期間ACK到達了也收不到只能等sleep結束再處理于是每個丟包都額外付出一個超時時間的代價。解決用select.select替代sleep把等待時間交給內核去監(jiān)聽socket可讀狀態(tài)超時只在“確實沒有ACK到達”時觸發(fā)。這是整個實現(xiàn)里最值得改的一處改完后丟包率20%環(huán)境下的傳輸時間能縮短一個數(shù)量級。5.4 坑4文件末尾不足一幀重組時少一段數(shù)據現(xiàn)象發(fā)送端send完后直接退出接收端報錯或生成文件比原文件小幾個字節(jié)。原因拆幀時按chunk_size切片最后一塊通常不滿1KB接收端按固定幀長去讀或者按頭部length字段解析時把最后一次recvfrom的數(shù)據截斷了。解決幀頭的length字段必須用于重組邏輯而不是默認湊滿chunk_size接收端寫文件時也要累計實際收到的字節(jié)數(shù)不能簡單按“幀數(shù)乘幀長”計算。用文件大小除以幀大小得到的余數(shù)正是末尾幀的真實長度務必讓接收端依賴length字段而不是固定值。5.5 坑5收發(fā)共用一個端口ACK被解析成數(shù)據幀現(xiàn)象數(shù)據幀和ACK都發(fā)往同一個接收端口接收端的處理邏輯里沒有對幀類型做分支導致ACK被當成數(shù)據幀寫入文件文件內容混入亂碼。原因收發(fā)雙方共用一個socket發(fā)送端發(fā)出的數(shù)據幀和接收端發(fā)出的ACK源端口相同接收端收到后只看了序號沒看類型。解決在解析幀后的第一個分支里就判斷ftype只對FRAME_TYPE_DATA做數(shù)據寫入FRAME_TYPE_ACK直接跳過FIN幀必須有獨立分支。類型字段設了三種卻在接收端只寫了一個if這種疏忽會在混合測試時暴露得很徹底。6. 拿什么證明你的GBN真的可靠三檔丟包測試與窗口滑動驗證代碼寫完不是終點課程實驗驗收通常要看“你憑什么說它可靠”。只用一句話“測試通過”說服力不足做三檔對照實驗把數(shù)據記錄下來比任何解釋都管用。6.1 對照實驗丟包率0%、20%、50%的吞吐與重傳統(tǒng)計信道類把丟包率做成參數(shù)跑測試時分別設成0、0.2、0.5傳輸同一個文件分別記錄發(fā)送幀總數(shù)、重傳幀總數(shù)、實際耗時。0%檔的重傳數(shù)應該為020%檔重傳數(shù)約等于總幀數(shù)的三分之一到一半50%檔耗時明顯上升且發(fā)送端會頻繁重傳整個窗口。這三組數(shù)據能直接證明兩層結論丟包率升高時重傳確實發(fā)生了同時文件內容依然保持一致。對比時注意固定窗口大小和超時時間否則兩組數(shù)據之間沒有可比性。6.2 用發(fā)送序號曲線驗證窗口真的在滑動把Sender每個時刻的base和next_seq打印到日志里橫軸是時間、縱軸是序號你會看到一條階梯狀曲線next_seq上升得快base跟隨ACK慢慢追趕兩條線的垂直距離就是當前窗口中未確認的幀數(shù)。如果畫出來的next_seq一直不動說明發(fā)送窗口被堵死了大概率是ACK處理有問題如果base和next_seq幾乎同步上升說明窗口形同虛設退化成停等協(xié)議。打印方式很簡單在Sender主循環(huán)里每處理一個ACK就追加一行base, next_seq, time.time()到列表結束時寫CSV。這個日志本身也是排錯工具比單步斷點更直觀——你能看到整個傳輸過程中窗口有沒有卡住。6.3 進階把窗口狀態(tài)落成CSV用matplotlib畫滑動圖如果想在報告里放一張有說服力的圖把上面的日志存成CSV后用matplotlib畫兩條折線即可。橫軸elapsed_ms縱軸seqbase和next_seq兩條線之間的陰影面積就是滑動窗口的實時占用。import matplotlib.pyplot as plt seqs [] with open(window_log.csv) as f: for line in f: t, base, next_seq map(float, line.strip().split(,)) seqs.append((t, base, next_seq)) ts [row[0] for row in seqs] base [row[1] for row in seqs] next_seq [row[2] for row in seqs] plt.plot(ts, base, labelbase, linewidth1.5) plt.plot(ts, next_seq, labelnext_seq, linewidth1.5) plt.fill_between(ts, base, next_seq, alpha0.2) plt.xlabel(elapsed time (ms)) plt.ylabel(sequence number) plt.legend() plt.savefig(gbn_window.png, dpi150)畫出來的圖如果“兩條線咬得很緊”說明信道的重傳主導了傳輸如果“剪刀差”穩(wěn)定在8左右說明窗口在正常工作。我自己的習慣是先把0%丟包跑一遍存圖再跑20%和50%三張圖放在一起重傳風暴一目了然。這也成了我后來寫所有協(xié)議實驗的固定套路不急著調代碼先讓數(shù)據說話。希望這套方法能幫你的GBN實驗少走幾輪彎路。本文還有配套的精品資源點擊獲取