簡介這是計算機(jī)網(wǎng)絡(luò)課程設(shè)計場景下的一份Python實現(xiàn)資源包圍繞UDP設(shè)計可靠數(shù)據(jù)傳輸協(xié)議完整覆蓋停等協(xié)議、GBN和SR的改進(jìn)思路。內(nèi)容對應(yīng)實驗要求包括單向可靠傳輸、丟包模擬、雙向數(shù)據(jù)傳輸以及基于協(xié)議的C/S文件傳輸應(yīng)用適合正在學(xué)習(xí)網(wǎng)絡(luò)原理或需要完成課程設(shè)計參考的讀者。壓縮包共14個文件約723KB以8個Python源文件為核心配合txt數(shù)據(jù)文件、docx實驗報告、README說明和License文件既有可運行的server與client源碼也有配置工具和數(shù)據(jù)樣本。已有596人學(xué)習(xí)下載作者s1t16按實驗步驟組織文件便于從基礎(chǔ)停等協(xié)議逐級擴(kuò)展到GBN與SR。參考README和報告可快速理解協(xié)議狀態(tài)機(jī)、滑動窗口與丟包重傳機(jī)制也可將其中的UDP可靠性擴(kuò)展思路遷移到文件傳輸場景適合實踐入門或二次開發(fā)。1. 從 UDP 不可靠說起這門課設(shè)到底要你交出什么很多同學(xué)拿到“基于 Python 實現(xiàn)可靠數(shù)據(jù)傳輸協(xié)議”這個題目第一反應(yīng)是“直接用 TCP 不就行了”。但如果真這么做課程設(shè)計基本就翻車了。題目要求的是基于 UDP 設(shè)計并實現(xiàn)停等協(xié)議、GBN 協(xié)議再演進(jìn)到 SR 協(xié)議整個實驗的核心不是“傳數(shù)據(jù)”而是讓你在 UDP 這種不可靠、不保序、無擁塞控制的信道上通過協(xié)議機(jī)制去解決丟包、重復(fù)、亂序的問題。換句話說你需要親手寫出一套“迷你 TCP”這才是這份資源真正的價值所在。這份編號為 100010493 的課程設(shè)計資源覆蓋了從停等協(xié)議到 GBN、再到 SR 的完整演進(jìn)鏈路并且包含服務(wù)器到客戶端的單向傳輸、雙向數(shù)據(jù)傳輸模擬、基于停等協(xié)議的 C/S 文件傳輸應(yīng)用等全部實驗內(nèi)容。它的設(shè)計目標(biāo)很明確讓你從零開始理解可靠數(shù)據(jù)傳輸?shù)幕驹碚莆栈瑒哟翱趨f(xié)議的工作原理并且能直接用 Python 代碼驗證自己的思路。無論你是計算機(jī)網(wǎng)絡(luò)課程需要交課設(shè)報告還是想深入理解 TCP 可靠傳輸背后的設(shè)計哲學(xué)這套方案都能作為你直接參考甚至照搬的完整藍(lán)本。接下來我會按照實際做項目的順序從總體設(shè)計、模塊實現(xiàn)、避坑指南到最終驗收把這份資源里的關(guān)鍵技術(shù)點和工程實現(xiàn)細(xì)節(jié)全部拆給你看。2. 總體架構(gòu)設(shè)計協(xié)議分層與四個核心模塊的職責(zé)劃分做網(wǎng)絡(luò)協(xié)議這類項目最忌諱一上來就寫代碼。我一般會先把架構(gòu)圖在腦子里畫清楚數(shù)據(jù)從服務(wù)器端產(chǎn)生經(jīng)過協(xié)議層封裝通過 UDP Socket 發(fā)送再在客戶端經(jīng)過對應(yīng)的協(xié)議層解封裝最后交給應(yīng)用層處理。這份資源里的源碼組織方式非常標(biāo)準(zhǔn)適合直接作為課設(shè)報告中的“系統(tǒng)設(shè)計”章節(jié)素材。2.1 工程文件結(jié)構(gòu)與啟動入口解析拿到壓縮包后首先需要讀懂它的目錄結(jié)構(gòu)這決定了你能否快速跑通整個項目。標(biāo)準(zhǔn)的資源解壓后通常是這樣的結(jié)構(gòu)datatransferprotocol/ ├── src/ │ ├── protocol/ │ │ ├── __init__.py │ │ ├── server.py │ │ ├── client.py │ │ └── util.py │ ├── config.py │ └── data/ │ ├── client_data.txt │ └── server_data.txt ├── recv/ │ └── client_recv.txt ├── report.docx ├── README.md └── LICENSE這個結(jié)構(gòu)劃分非常清晰。src/protocol/下是協(xié)議棧的核心實現(xiàn)其中server.py負(fù)責(zé)發(fā)送端邏輯client.py負(fù)責(zé)接收端邏輯util.py通常封裝了校驗和計算、數(shù)據(jù)包序列化等公共工具函數(shù)。config.py是全局配置項比如 IP 地址、端口號、窗口大小、超時重傳時間等參數(shù)都定義在這里。data/目錄存放測試數(shù)據(jù)文件recv/目錄存放客戶端接收到的數(shù)據(jù)。整體是標(biāo)準(zhǔn)的 C/S 架構(gòu)非常適合作為計算機(jī)網(wǎng)絡(luò)課程設(shè)計的演示項目。2.2 數(shù)據(jù)包格式設(shè)計與序列化方法可靠傳輸協(xié)議的基石是數(shù)據(jù)包的格式設(shè)計這和 HTTP 協(xié)議頭、TCP 報文段格式是一樣的道理。在這個項目里每個數(shù)據(jù)包都必須包含幾個關(guān)鍵字段序列號Sequence Number、確認(rèn)號Acknowledgment Number、校驗和Checksum、數(shù)據(jù)長度Length以及實際數(shù)據(jù)負(fù)載。用 Python 實現(xiàn)時struct模塊是處理二進(jìn)制序列化最方便的工具。import struct # 數(shù)據(jù)包格式: [序列號(4字節(jié)) | 確認(rèn)號(4字節(jié)) | 校驗和(2字節(jié)) | 長度(2字節(jié)) | 載荷] PACKET_HEADER_FORMAT !IIHH HEADER_SIZE struct.calcsize(PACKET_HEADER_FORMAT) MAX_PAYLOAD_SIZE 1024 # 最大載荷 1KB def make_packet(seq_num: int, ack_num: int, payload: bytes b) - bytes: length len(payload) # 計算校驗和: 先將頭部和載荷拼在一起對每個16位字求和 header_no_checksum struct.pack(PACKET_HEADER_FORMAT, seq_num, ack_num, 0, length) checksum compute_checksum(header_no_checksum payload) header struct.pack(PACKET_HEADER_FORMAT, seq_num, ack_num, checksum, length) return header payload def parse_packet(packet: bytes): header packet[:HEADER_SIZE] seq_num, ack_num, checksum, length struct.unpack(PACKET_HEADER_FORMAT, header) payload packet[HEADER_SIZE:HEADER_SIZE length] return { seq_num: seq_num, ack_num: ack_num, checksum: checksum, length: length, payload: payload, }注意這里的校驗和計算類似 TCP 的校驗和算法將整個數(shù)據(jù)包包括頭部和載荷按 16 位一組進(jìn)行反碼求和。接收端收到數(shù)據(jù)包后重新計算校驗和如果與包內(nèi)攜帶的校驗和不一致就說明數(shù)據(jù)在傳輸過程中被破壞了必須丟棄并請求重傳。使用!IIHH格式化串表示使用網(wǎng)絡(luò)字節(jié)序大端序避免不同主機(jī)架構(gòu)間的字節(jié)序問題。2.3 滑動窗口協(xié)議的狀態(tài)變量設(shè)計與職責(zé)邊界從停等協(xié)議演進(jìn)到 GBN 協(xié)議核心在于引入滑動窗口窗口大小決定了信道利用率。停等協(xié)議的利用率太低了發(fā)一個包等一個確認(rèn)往返時間(RTT)內(nèi)發(fā)送方完全空閑。如果鏈路帶寬高、延遲大停等協(xié)議的信道利用率會趨近于零。GBN 協(xié)議通過允許發(fā)送方連續(xù)發(fā)送多個未被確認(rèn)的分組把窗口“滑”起來從而大幅度提升吞吐量。在這份資源的 GBN 實現(xiàn)中發(fā)送端需要維護(hù)以下狀態(tài)變量base窗口基序號、next_seq_num下一個要發(fā)送的序號、window_size窗口大小、timer計時器。接收端則維護(hù)expected_seq_num期望接收到的序號。整體設(shè)計上protocol/server.py負(fù)責(zé)發(fā)送窗口管理和超時重傳邏輯protocol/client.py負(fù)責(zé)接收端的累積確認(rèn)和丟包檢測邏輯兩個模塊通過 UDP Socket 通信職責(zé)邊界非常清晰。3. 協(xié)議演進(jìn)實現(xiàn)從停等機(jī)制到滑動窗口的工作原理中間這章是整個課設(shè)的核心和價值所在。你需要向答辯老師展示的不僅是能跑通的代碼更是你對這幾種協(xié)議機(jī)制差異的深刻理解。3.1 停等協(xié)議設(shè)計超時重傳與確認(rèn)機(jī)制停等協(xié)議是最基礎(chǔ)的可*靠數(shù)據(jù)傳輸協(xié)議原理非常簡單發(fā)送方發(fā)送一個分組后必須等待接收方返回確認(rèn)(ACK)收到確認(rèn)后才能發(fā)送下一個分組。如果發(fā)送方在超時時間內(nèi)沒有收到 ACK就重傳該分組。def stop_and_wait_send(sock, dest_addr, payload, timeout2.0): packet make_packet(seq_num0, ack_num0, payloadpayload) while True: sock.sendto(packet, dest_addr) sock.settimeout(timeout) try: response, _ sock.recvfrom(HEADER_SIZE) ack_packet parse_packet(response) if ack_packet[ack_num] 0: print(f[發(fā)送端] 收到對 seq0 的確認(rèn)發(fā)送完成) return True except socket.timeout: # 血淚經(jīng)驗超時后必須重新發(fā)送并且要重新設(shè)置計時器 print(f[發(fā)送端] 超時未收到ACK重傳 seq0) continue這個實現(xiàn)里的關(guān)鍵點有兩個。第一個是超時重傳很多同學(xué)在這里踩坑單程超時時間設(shè)置得太短導(dǎo)致頻繁重傳設(shè)置得太長又會大幅降低傳輸效率。我一般建議超時時間設(shè)置為略大于往返時間的兩倍。第二個是 ACK 確認(rèn)號的設(shè)計停等協(xié)議中確認(rèn)號的含義是“我已經(jīng)正確收到序號為 N 的數(shù)據(jù)包下一個期望收到的是 N1”。3.2 累積確認(rèn)、超時重傳與窗口滑動把停等協(xié)議的等待時間“填滿”就得到了 GBN 協(xié)議的核心機(jī)制發(fā)送窗口。發(fā)送方維護(hù)一個窗口窗口內(nèi)所有分組都可以連續(xù)發(fā)送而不用等待各自的 ACK。接收方只按序接收一旦收到亂序分組就直接丟棄并對最后一個按序接收到的分組發(fā)送累積確認(rèn)。GBN 發(fā)送端的核心邏輯是判斷哪些分組可以發(fā)送哪些分組必須等 ACKdef gbn_send(sock, dest_addr, data_packets): 按 GBN 協(xié)議發(fā)送一組數(shù)據(jù)包。 :param data_packets: 已按序號排好的數(shù)據(jù)包列表 window_size config.WINDOW_SIZE base 0 # 窗口起始序號(絕對序號) next_seq_num 0 # 下一個待發(fā)送的序號 total_packets len(data_packets) while base total_packets: # 發(fā)送窗口還沒滿且還有包可發(fā)就繼續(xù)發(fā)包 while next_seq_num base window_size and next_seq_num total_packets: sock.sendto(data_packets[next_seq_num], dest_addr) print(f[發(fā)送端] 發(fā)送 seq{next_seq_num}) next_seq_num 1 # 啟動一個計時窗口等待累積確認(rèn) sock.settimeout(config.TIMEOUT) try: response, _ sock.recvfrom(MAX_PACKET_SIZE) ack_packet parse_packet(response) # 累積確認(rèn)收到對 n 的確認(rèn)意味著前面 n 個包全部正確到達(dá) new_base ack_packet[ack_num] 1 if new_base base: print(f[發(fā)送端] 收到累積確認(rèn) ACK{ack_packet[ack_num]}窗口滑到 {new_base}) base new_base except socket.timeout: # 超時從 base 開始重傳整個窗口 print(f[發(fā)送端] 超時從 seq{base} 開始重傳整個窗口) next_seq_num base continue這里最容易理解錯的是累積確認(rèn)。比如接收方已經(jīng)按序接收了 0、1、2那么發(fā)送 ACK 中的確認(rèn)號為 2表示“0~2 全部收到請發(fā) 3”。如果發(fā)送方收到 ACK2窗口基序號直接變成 3窗口向前滑動 3 個位置。如果第三個包丟失了接收方收到第四個包時發(fā)現(xiàn)序號不連續(xù)會直接丟棄并重復(fù)發(fā)送 ACK2發(fā)送方重復(fù)收到同一個 ACK達(dá)到一定次數(shù)后觸發(fā)快速重傳或超時重傳。3.3 GBN 改進(jìn)為 SR 協(xié)議接收窗口與選擇重傳GBN 協(xié)議的致命缺點是單個丟包會導(dǎo)致大量重傳。比如窗口大小是 16第 4 個包丟了接收方會丟棄所有后續(xù)按序到達(dá)的包發(fā)送方超時后必須重傳 5~16 號包。在誤碼率高的信道上這種“回退 N”策略的吞吐量會受到明顯影響。SR選擇性重傳協(xié)議就是針對這個問題做的優(yōu)化。SR 不僅為發(fā)送方提供滑動窗口也為接收方提供滑動窗口緩存機(jī)制。接收方不再丟棄亂序到達(dá)的分組而是先緩存起來等缺失的分組到達(dá)后再一起按序交付給上層。def sr_receive(sock, base, window_size, buffer_dict): SR 接收端處理邏輯。 :param buffer_dict: 序號-包內(nèi)容的緩存字典 while True: packet_data, addr sock.recvfrom(MAX_PACKET_SIZE) pkt parse_packet(packet_data) seq pkt[seq_num] # 接收窗口范圍判定 if base seq base window_size: buffer_dict[seq] pkt # 先緩存起來存著 # 移動窗口如果當(dāng)前 base 指向的數(shù)據(jù)已經(jīng)到達(dá)就持續(xù)前移 while base in buffer_dict: # 將緩存中的數(shù)據(jù)按序交付給上層應(yīng)用 deliver_to_app(buffer_dict[base][payload]) del buffer_dict[base] base 1 send_ack(seq) # 對已收到的包確認(rèn)注意這里是選擇確認(rèn) elif seq base: # 說明這個包是重復(fù)的舊包接收方已經(jīng)滑過去了但還是得再發(fā)一次ACK send_ack(seq)SR 與 GBN 的差異在實現(xiàn)中非常關(guān)鍵。GBN 的 ACK 是“累積”的SR 的 ACK 是“選擇”的。SR 接收端需要為沒有到達(dá)的分組設(shè)置定時器或者在發(fā)送端單獨計時重傳每個超時分組的 ACK。從代碼量來看SR 的實現(xiàn)復(fù)雜度比 GBN 高許多。這也是實驗內(nèi)容的最后一個進(jìn)階步驟將所設(shè)計的 GBN 協(xié)議改進(jìn)為 SR 協(xié)議。如果你做到這一步說明你已經(jīng)完全掌握了滑動窗口協(xié)議的精髓完全可以作為課設(shè)報告里的“創(chuàng)新點”來寫。4. 工程落地實現(xiàn)單向傳輸、雙向傳輸與文件傳輸應(yīng)用協(xié)議機(jī)制的代碼是骨架工程落地則是血肉。課設(shè)要求里明確提到了三個必須實現(xiàn)的場景單向可靠數(shù)據(jù)傳輸、模擬數(shù)據(jù)包丟失驗證協(xié)議有效性、雙向數(shù)據(jù)傳輸以及一個 C/S 結(jié)構(gòu)的文件傳輸應(yīng)用。4.1 基于 UDP 的單向可靠傳輸測試鏈路先從最基本的單向傳輸鏈路說起。服務(wù)器端按順序讀取文本數(shù)據(jù)切分成固定大小的數(shù)據(jù)塊用 GBN 協(xié)議發(fā)送給客戶端客戶端接收后重組數(shù)據(jù)寫回本地文件。整個鏈路的測試步驟如下先跑通“無丟包”場景修改config.py中的丟包率配置為 0驗證基礎(chǔ)傳輸功能是否正常。再跑通“模擬丟包”場景把丟包率設(shè)為 10%~30%觀察協(xié)議在隨機(jī)丟包環(huán)境下是否仍能保證數(shù)據(jù)完整交付。模擬丟包時注意util.py里通常有一個隨機(jī)數(shù)丟失判斷。這個判斷會直接改變實驗結(jié)果def should_drop_packet(drop_rate: float 0.0) - bool: 按丟包率決定是否丟棄當(dāng)前數(shù)據(jù)包 return random.random() drop_rate def udt_send(sock, packet, dest_addr, drop_rate0.0): 不可靠信道傳輸按概率丟包 if should_drop_packet(drop_rate): print(f[信道] 數(shù)據(jù)包 seq{parse_packet(packet)[seq_num]} 在傳輸中丟失...) return sock.sendto(packet, dest_addr)一定要理解這段代碼的位置關(guān)系。丟包模擬發(fā)生在“發(fā)送端調(diào)用 sendto 之前”模擬的是數(shù)據(jù)在網(wǎng)絡(luò)上傳輸時被路由器丟棄的過程。實際實驗中可以通過打印日志對比相同序號數(shù)據(jù)包的出現(xiàn)次數(shù)來證明重傳機(jī)制確實觸發(fā)了。這也是報告里“實驗結(jié)果與分析”部分的關(guān)鍵截圖依據(jù)。4.2 雙向數(shù)據(jù)傳輸?shù)膶崿F(xiàn)方式與沖突避免很多同學(xué)在把單向傳輸改成雙向傳輸時犯了難。雙向傳輸并不是簡單地開兩個 Socket 各收各的而是要在一個事件循環(huán)里同時處理“發(fā)送數(shù)據(jù)”和“接收確認(rèn)”兩條邏輯流。如果處理不當(dāng)就會出現(xiàn)死鎖雙方都在等對方的 ACK但雙方的 ACK 都發(fā)送不出去。實現(xiàn)雙向傳輸我一般會采用單 Socket 狀態(tài)切換的策略把收發(fā)邏輯合并到同一個循環(huán)里在每個循環(huán)周期內(nèi)先檢查有沒有需要重傳的超時分組再嘗試接收對端的數(shù)據(jù)和確認(rèn)最后發(fā)送新數(shù)據(jù)。通過 socketselect或設(shè)置settimeout來避免阻塞def bidirectional_send_receive(sock, dest_addr, local_data): 在同一線程內(nèi)交替處理發(fā)送和接收避免雙向傳輸死鎖 base 0 next_seq_num 0 while base len(local_data) or has_received_data: # 先從窗口里往外發(fā)數(shù)據(jù) while next_seq_num base config.WINDOW_SIZE and next_seq_num len(local_data): sock.sendto(make_packet(next_seq_num, 0, local_data[next_seq_num]), dest_addr) next_seq_num 1 # 再嘗試接收對方的數(shù)據(jù)/確認(rèn) sock.settimeout(0.5) # 非阻塞式檢查停頓 500ms try: packet sock.recvfrom(MAX_PACKET_SIZE)[0] handle_packet_type(packet) # 根據(jù)類型分發(fā)到數(shù)據(jù)/確認(rèn)處理邏輯 except socket.timeout: pass # 處理下一批數(shù)據(jù) # 最后檢查是否超時需要重傳 if timer_expired(): next_seq_num base這里有個非常實用的細(xì)節(jié)如果兩端的發(fā)送節(jié)奏不是對等的比如服務(wù)器要發(fā)大文件而客戶端只返回少量確認(rèn)那么客戶端的發(fā)送緩沖區(qū)會很快清空。此時客戶端不能退出循環(huán)必須繼續(xù)處理接收到的數(shù)據(jù)包并發(fā)送 ACK。正確做法是客戶端在自己的循環(huán)里等到“收到服務(wù)器的傳輸結(jié)束標(biāo)志”或“超時退出”后再關(guān)閉 Socket。這是課設(shè)答辯時老師最喜歡追問的細(xì)節(jié)之一。4.3 基于停等協(xié)議的 C/S 文件傳輸應(yīng)用實現(xiàn)文件傳輸應(yīng)用是停等協(xié)議最直觀的應(yīng)用場景。實現(xiàn)邏輯是服務(wù)器讀取文件內(nèi)容、按 chunk 分割、加序號封裝成包客戶端收包后按序號重組并寫入新文件。這個場景和純文本傳輸?shù)膮^(qū)別在于它必須考慮到大文件的處理效率和異?；謴?fù)能力。def send_file(sock, file_path, dest_addr, chunk_size1024): 基于停等協(xié)議發(fā)送文件 :return: 成功發(fā)送的字節(jié)數(shù) seq 0 total_bytes 0 with open(file_path, rb) as f: while True: chunk f.read(chunk_size) if not chunk: break packet make_packet(seq_numseq, ack_num0, payloadchunk) stop_and_wait_send(sock, dest_addr, packet) seq 1 total_bytes len(chunk) print(f[文件傳輸] 完成共發(fā)送 {seq} 個數(shù)據(jù)包{total_bytes} 字節(jié)) return total_bytes文件傳輸?shù)膶崿F(xiàn)要注意幾個問題。每次只發(fā)送 1024 字節(jié)如果文件有幾十 MB就需要發(fā)送幾萬個數(shù)據(jù)包停等協(xié)議的效率會非常低。這也是為什么課設(shè)要求里先做停等協(xié)議的文件傳輸再在 GBN 基礎(chǔ)上做同樣的文件傳輸時你會明顯感受到性能差異GBN 的吞吐量可能是停等協(xié)議的幾十倍甚至上百倍。這個對比數(shù)據(jù)寫到課設(shè)報告的“實驗結(jié)果分析”里是非常有說服力的論據(jù)。5. 避坑指南協(xié)議實現(xiàn)中五個最容易翻車的故障排查計算機(jī)網(wǎng)絡(luò)課設(shè)的調(diào)試過程往往是玄學(xué)般的體驗。代碼寫好了、網(wǎng)絡(luò)配置也對但數(shù)據(jù)就是傳不過去。基于這份資源里協(xié)議的實現(xiàn)經(jīng)驗我整理了五個高頻故障點按照現(xiàn)象、原因、解決的思路來排查能幫你少走很多彎路。5.1 重傳日志打了一堆但接收端還是收不全數(shù)據(jù)現(xiàn)象服務(wù)器端瘋狂打印“超時重傳”日志客戶端卻始終只能收到前幾個數(shù)據(jù)包后面全部丟失。原因這是典型的“發(fā)送窗口推進(jìn)”邏輯錯誤。在很多初版 GBN 實現(xiàn)里發(fā)送方在超時后直接把next_seq_num重置為base但此時窗口內(nèi)可能還有之前未發(fā)送完的數(shù)據(jù)包。如果重傳后沒有正確更新base窗口就永遠(yuǎn)滑不動形成死循環(huán)。解決逐行檢查窗口滑動的狀態(tài)轉(zhuǎn)移。在超時重傳后必須重新發(fā)送從base到next_seq_num的所有數(shù)據(jù)包并且每次收到 ACK 后base的更新邏輯必須嚴(yán)格等于“ACK序號 1”。我建議在每次狀態(tài)變化時打印一行包含base、next_seq_num、window_size的日志輔助判斷問題所在。5.2 接收端收到的數(shù)據(jù)完整但順序錯亂文件打不開現(xiàn)象客戶端收到的數(shù)據(jù)量是對的但重組后的文件與原始文件不一致或者圖片文件直接無法打開。原因數(shù)據(jù)包亂序。UDP 本身不保證數(shù)據(jù)包的到達(dá)順序雖然 GBN 接收端會丟棄亂序包但如果你錯誤地實現(xiàn)了“直接收下所有包”的邏輯就會出現(xiàn)亂序交付。解決檢查接收端是否嚴(yán)格按“期望序號”進(jìn)行過濾。GBN 接收端唯一的合法交付依據(jù)是if seq_num expected_seq_num:只有序號完全匹配才接收并交付上層否則直接丟棄。SR 接收端允許緩存亂序包但在交付給應(yīng)用層時也必須按緩存中的序號從小到大依次交付序號中間有空洞時絕不能提前交付后面的包。5.3 開啟模擬丟包后程序運行了幾分鐘還沒有結(jié)束現(xiàn)象丟包率設(shè)置為 20% 后程序就像卡死了一樣日志長時間不更新。原因不是程序死鎖而是超時時間設(shè)置太長。假設(shè)你的 RTT 是 100ms但超時時間設(shè)了 10 秒。每遇到一個丟包發(fā)送方就要干等 10 秒才重傳傳輸效率斷崖式下降。解決把超時時間調(diào)到理論 RTT 的兩倍左右。在局域網(wǎng)環(huán)境中一般 0.5~1 秒足夠充分。如果不知道網(wǎng)絡(luò) RTT可以先用ping命令粗測再在config.py里動態(tài)配置。更高級的做法是實現(xiàn)自適應(yīng)重傳根據(jù)最近的 RTT 樣本計算加權(quán)平均 RTT 和偏差設(shè)置動態(tài)超時時間這也是報告里可以展開寫的優(yōu)化點。5.4 雙向傳輸時兩邊都在等 ACK程序死鎖現(xiàn)象開啟雙向傳輸功能后程序要么直接卡死要么等待很長時間后才開始傳輸。原因這是典型的“全雙工通信中的死鎖問題”。如果發(fā)送方在等待 ACK 時使用阻塞式recvfrom且接收方也在等待對方的數(shù)據(jù)才發(fā)送 ACK比如雙方都嘗試先發(fā)送數(shù)據(jù)再接收就會形成循環(huán)等待。解決采用事件循環(huán)或select機(jī)制處理 Socket。在等待超時時間內(nèi)同時監(jiān)聽“可讀事件”和“可寫事件”有數(shù)據(jù)可讀就先讀有 ACK 需要確認(rèn)就先處理 ACK。關(guān)注點轉(zhuǎn)移把“發(fā)送-等待”的線性模型改成“發(fā)送-監(jiān)聽-處理”的并發(fā)模型這是工程實現(xiàn)里非常重要的思維轉(zhuǎn)變。5.5 校驗和算不對接收端把所有包都視為損壞現(xiàn)象接收端報錯丟棄所有數(shù)據(jù)包。調(diào)試發(fā)現(xiàn)明明在同一個機(jī)器上收發(fā)校驗和計算方式?jīng)]有問題但解析出的數(shù)據(jù)和發(fā)送前不一致。原因字節(jié)序問題或者是沒把校驗和字段本身置零。計算校驗和時頭部中的checksum字段必須為 0計算完再填入接收端解析時要先取校驗和字段將它置為 0 后重新計算整體校驗和與取出值比較。解決嚴(yán)格順序是“置零 → 拼接 → 計算 → 填充收到時 取校驗和 → 置零 → 拼接 → 重算 → 對比”。此外如果是在 Windows 和 Linux 主機(jī)間跨平臺傳輸要注意 sockaddr 結(jié)構(gòu)和字節(jié)序的差異。6. 驗收與答辯準(zhǔn)備如何把實驗結(jié)果講清楚、拿高分做課程設(shè)計最后一步就是寫報告和現(xiàn)場演示了。很多同學(xué)程序能跑但講不清楚原理答辯時被老師追問幾句就答不上來白白丟了分。這一章我重點講驗收的方法論和答辯時的準(zhǔn)備策略。6.1 制定可量化的驗收標(biāo)準(zhǔn)清單驗收之前先明確“什么算完成什么算優(yōu)秀”。我會建議你用下面這個表格來逐項自查驗收項合格標(biāo)準(zhǔn)優(yōu)秀標(biāo)準(zhǔn)停等協(xié)議在無丟包網(wǎng)絡(luò)下能正確傳輸 1KB 文本接收端數(shù)據(jù)與發(fā)送端一致在 10% 丟包率下仍能正確傳輸且日志清晰展示重傳過程GBN 協(xié)議在模擬丟包環(huán)境下傳輸數(shù)據(jù)保證 100% 完整性用兩組不同丟包率如 5% 和 30%做對比實驗計算出信道利用率的變化趨勢雙向數(shù)據(jù)傳輸兩個方向的數(shù)據(jù)都能正確到達(dá)對方雙方同時發(fā)送大數(shù)據(jù)量時不會死鎖傳輸完畢后正確關(guān)閉連接文件傳輸應(yīng)用傳輸一個 1MB 文件MD5 校驗一致對比停等協(xié)議和 GBN 協(xié)議傳輸同一文件的總耗時給出統(tǒng)計圖表SR 協(xié)議改進(jìn)能正確實現(xiàn)選擇重傳亂序到達(dá)的分組能被緩存并最終按序交付與 GBN 協(xié)議在相同丟包率下對比“重傳數(shù)據(jù)包數(shù)量”SR 明顯小于 GBN把這張表里的每一項都實際跑通一遍你的報告里的“實驗結(jié)果”章節(jié)就有血有肉了。6.2 答辯演示腳本的編排技巧答辯的現(xiàn)場演示時間是有限的通常只有 5~10 分鐘。不要現(xiàn)場去敲代碼或臨時改配置。提前準(zhǔn)備一個 5 分鐘的演示腳本強(qiáng)烈建議按以下流程編排第一步先花半分鐘展示項目結(jié)構(gòu)快速過一眼代碼組織證明這是你的自主實現(xiàn)。第二步啟動停等協(xié)議傳輸一個文本文件全程無丟包速度很慢展示成功結(jié)果。第三步開啟 20% 丟包率展示協(xié)議重傳流程和接收結(jié)果。第四步啟動 GBN 協(xié)議傳輸大文件展示窗口滑動的高吞吐量對比第二步明顯提速。第五步展示 SR 協(xié)議的重傳統(tǒng)計對比 GBN 的重傳數(shù)量說明自己理解了改進(jìn)動機(jī)。演示中最容易翻車的點是“開著丟包率但程序崩潰了”。為了保險起見我會把丟包率和丟包種子隨機(jī)種子配置成可復(fù)現(xiàn)的固定值確保演示過程每次都能重現(xiàn)相同的結(jié)果而不是依賴于不可控的隨機(jī)數(shù)。6.3 答辯追問環(huán)節(jié)的應(yīng)答框架與經(jīng)驗教訓(xùn)答辯老師幾乎必問的幾個問題我?guī)湍惆汛鸱ㄌ崆皽?zhǔn)備好。第一個問題為什么信道不可靠但還要基于 UDP 設(shè)計可靠協(xié)議回答核心是TCP 的可靠傳輸是在內(nèi)核協(xié)議棧里的看不到隱藏的實現(xiàn)細(xì)節(jié)基于 UDP 自己實現(xiàn)能理解和控制每一個機(jī)制這才是協(xié)議設(shè)計的本質(zhì)。第二個問題GBN 為什么叫回退 N回退的是哪 N 個你要能畫出時序圖指出丟失的包 N 以及其后的所有數(shù)據(jù)包都需要重傳。第三個問題SR 協(xié)議是怎么減少無效重傳的答案是接收端緩存窗口 發(fā)送端單獨定時器。關(guān)于資源里的代碼如何避免被質(zhì)疑雷同我有個實際的經(jīng)驗不要原封不動地提交代碼。哪怕只改動一些變量命名、增加注釋、調(diào)整函數(shù)拆分的粒度都能體現(xiàn)你對代碼的理解。更推薦的做法是基于資源里的框架自己重新實現(xiàn)一遍核心的窗口管理邏輯遇到問題再來對照參考源碼。從那以后我每次做協(xié)議類項目都會給自己定一條規(guī)矩交給驗收的東西一定是在我腦子里完整過過一遍流程的能畫得出時序圖能解釋得清狀態(tài)變化絕不交一份“能跑但講不明白”的代碼上去。課設(shè)和真實項目都是一樣能清晰表達(dá)出來的設(shè)計才算真正掌握。希望這份基于 Python 實現(xiàn)可靠數(shù)據(jù)傳輸協(xié)議的完整拆解能幫你在課程設(shè)計和畢業(yè)設(shè)計中少踩幾個坑。祝做出一個能讓你站上講臺自信講演的優(yōu)秀作品。本文還有配套的精品資源點擊獲取