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