簡(jiǎn)介這是一份源自黑龍江大學(xué)計(jì)算機(jī)網(wǎng)絡(luò)課程的實(shí)驗(yàn)報(bào)告與Python源碼包適合正在學(xué)習(xí)網(wǎng)絡(luò)原理、需要完成類似實(shí)驗(yàn)或復(fù)習(xí)協(xié)議實(shí)現(xiàn)的學(xué)生。包內(nèi)共有二十四個(gè)文件以十一個(gè)Python腳本為主另有五份Word實(shí)驗(yàn)報(bào)告、四個(gè)HTML輔助頁面及說明文本等壓縮包約三百四十一KB結(jié)構(gòu)清晰便于對(duì)照查閱。目前已有一千零八十一人學(xué)習(xí)下載。內(nèi)容包括Winsock編程實(shí)現(xiàn)TCP/IP通信、簡(jiǎn)單HTTP服務(wù)器與請(qǐng)求處理、停止等待ARQ算法模擬、RIP路由協(xié)議的路由更新模擬以及常用網(wǎng)絡(luò)命令的實(shí)踐。通過報(bào)告中的設(shè)計(jì)思路與可運(yùn)行代碼讀者能直觀理解數(shù)據(jù)封裝、差錯(cuò)控制、路由選擇等核心機(jī)制同時(shí)提升Python網(wǎng)絡(luò)編程與調(diào)試能力。所有源碼均直接可運(yùn)行適合課后驗(yàn)證與二次練習(xí)。1. 為什么計(jì)算機(jī)網(wǎng)絡(luò)實(shí)驗(yàn)需要自己動(dòng)手寫一套Python方案很多人以為計(jì)算機(jī)網(wǎng)絡(luò)實(shí)驗(yàn)就是看課件、抓幾個(gè)包、截圖交差。等到課程設(shè)計(jì)要求“實(shí)驗(yàn)報(bào)告源碼”才發(fā)現(xiàn)課講的三次握手、停止等待、滑動(dòng)窗口自己一行能跑的Python都寫不出來。要么抄開源demo要么只會(huì)用requests調(diào)接口問到底層socket怎么收發(fā)、報(bào)文怎么解析一句都答不上。這套方案就解決這個(gè)缺口把HTTP報(bào)文分析、UDP報(bào)文構(gòu)造、TCP可靠傳輸模擬、滑動(dòng)窗口這些核心實(shí)驗(yàn)從課本翻譯成直接可運(yùn)行、可驗(yàn)證的Python代碼并順手整理出寫實(shí)驗(yàn)報(bào)告要的格式與輸出。適合正在趕課程設(shè)計(jì)的學(xué)生、為網(wǎng)絡(luò)方向面試做基礎(chǔ)準(zhǔn)備的人以及想補(bǔ)協(xié)議棧底子的開發(fā)新手。我見過不少人在Socket編程上卡了整整一周最后交上去的報(bào)告只有運(yùn)行截圖沒有協(xié)議分析原因不是懶而是不知道代碼應(yīng)該長(zhǎng)什么樣。下面會(huì)把一套能直接落地的Python實(shí)驗(yàn)源碼拆開講代碼結(jié)構(gòu)、關(guān)鍵參數(shù)、運(yùn)行結(jié)果怎么驗(yàn)證、出錯(cuò)時(shí)看哪里一層層交代清楚。2. 實(shí)驗(yàn)?zāi)K劃分與代碼骨架從課程要求倒推Python結(jié)構(gòu)2.1 四個(gè)核心實(shí)驗(yàn)?zāi)K我先拆成哪些計(jì)算機(jī)網(wǎng)絡(luò)課程的知識(shí)點(diǎn)分布在應(yīng)用層、傳輸層、網(wǎng)絡(luò)層和鏈路層。做實(shí)驗(yàn)不能貪多我一般只挑四個(gè)模塊正好把課程的幾個(gè)重點(diǎn)串起來報(bào)告也好組織。每個(gè)模塊對(duì)應(yīng)一個(gè)獨(dú)立腳本腳本間通過公共工具層復(fù)用代碼。實(shí)驗(yàn)?zāi)K對(duì)應(yīng)知識(shí)點(diǎn)代碼文件報(bào)告驗(yàn)證方式HTTP報(bào)文解析HTTP/1.1報(bào)文格式、請(qǐng)求方法、頭部字段http_client.py http_parser.py抓包能看到GET請(qǐng)求和服務(wù)器響應(yīng)的完整報(bào)文UDP數(shù)據(jù)報(bào)構(gòu)造UDP報(bào)文格式、Internet校驗(yàn)和、字節(jié)序udp_packet.py構(gòu)造的報(bào)文能用Wireshark或hexdump人工解析停等協(xié)議可靠傳輸原理、超時(shí)重傳stop_wait.py模擬丟包后能觀察到重傳事件日志滑動(dòng)窗口流量控制、窗口狀態(tài)遷移sliding_window.py打印出窗口坐標(biāo)和左移過程這個(gè)拆法有兩條原則。第一每個(gè)模塊只講一個(gè)協(xié)議別把滑動(dòng)窗口和擁塞控制揉進(jìn)一個(gè)腳本。代碼一旦交叉老師追問關(guān)聯(lián)關(guān)系時(shí)很難講清楚而且調(diào)試時(shí)一個(gè)邏輯錯(cuò)誤會(huì)牽扯另一段邏輯。第二每個(gè)模塊必須有可觀測(cè)的輸出——要么是抓包截圖要么是帶序號(hào)的狀態(tài)日志不能只有一行“運(yùn)行成功”。我見過有人寫了一個(gè)tcp_simulator.py里面塞了滑動(dòng)窗口、擁塞避免、快速重傳三個(gè)部分結(jié)果窗口狀態(tài)和擁塞窗口更新相互干擾報(bào)告里的圖根本對(duì)不上。正確的做法是先讓每個(gè)實(shí)驗(yàn)獨(dú)立成進(jìn)程再通過統(tǒng)一入口管理代碼邏輯清晰報(bào)告也能按模塊復(fù)制輸出不用從一堆日志里找自己需要的那一段。2.2 公共工具層校驗(yàn)和、字節(jié)序、十六進(jìn)制轉(zhuǎn)儲(chǔ)四個(gè)模塊里有些底層操作會(huì)反復(fù)用到整數(shù)轉(zhuǎn)網(wǎng)絡(luò)字節(jié)序、二進(jìn)制流里讀寫頭部字段、計(jì)算Internet校驗(yàn)和、打印原始報(bào)文。這些要提前收進(jìn)utils.py否則每個(gè)腳本各寫一遍很容易出現(xiàn)實(shí)現(xiàn)不一致。尤其是校驗(yàn)和這種算法細(xì)節(jié)寫錯(cuò)一次排查半天還容易被誤判為網(wǎng)絡(luò)環(huán)境問題。先看校驗(yàn)和函數(shù)UDP和IP報(bào)文里都用同一套算法def checksum(data: bytes) - int: 計(jì)算Internet校驗(yàn)和把數(shù)據(jù)按16位分組求和進(jìn)位回卷最后取反。 返回的是0~65535之間的整數(shù)寫入報(bào)文時(shí)要轉(zhuǎn)成網(wǎng)絡(luò)字節(jié)序。 if len(data) % 2 1: data b\x00 # 奇數(shù)長(zhǎng)度補(bǔ)一個(gè)零字節(jié)參與計(jì)算這個(gè)字節(jié)不發(fā)送 s 0 for i in range(0, len(data), 2): word (data[i] 8) data[i 1] # 大端拼法前一個(gè)字節(jié)是高8位 s word # 每次累加后把高16位進(jìn)位回卷到低16位 s (s 0xffff) (s 16) return (~s) 0xffff邏輯說明Internet校驗(yàn)和來自RFC 1071要求把數(shù)據(jù)切成16位的序列按大端拼成整數(shù)后累加。累加可能產(chǎn)生超過16位的進(jìn)位必須把進(jìn)位不斷回卷到低16位直到?jīng)]有進(jìn)位為止。最后對(duì)整個(gè)累加和取反碼得到的就是發(fā)送端要填進(jìn)報(bào)文里的校驗(yàn)和。這里補(bǔ)零只參與計(jì)算并不真正發(fā)送這是很多人容易搞混的地方。這個(gè)函數(shù)里最容易寫錯(cuò)的是s (s 0xffff) (s 16)這一行。有人會(huì)圖省事寫成s s 16但這樣只做了一次回卷如果累加過程中持續(xù)產(chǎn)生進(jìn)位最終結(jié)果就會(huì)出錯(cuò)。我在調(diào)試UDP校驗(yàn)和時(shí)在這個(gè)地方翻過車最后是拿全零數(shù)據(jù)和已知報(bào)文逐字節(jié)比對(duì)才定位到問題。另外發(fā)送端計(jì)算校驗(yàn)和時(shí)報(bào)文里的校驗(yàn)和字段本身要先置為0接收端則要把整個(gè)偽頭部、UDP頭和數(shù)據(jù)一起做校驗(yàn)結(jié)果應(yīng)為0xFFFF才算通過。再看字節(jié)序轉(zhuǎn)換和hexdump這兩個(gè)是排障的利器def to_net_bytes(value: int, length: int 2) - bytes: 把整數(shù)轉(zhuǎn)成網(wǎng)絡(luò)字節(jié)序大端的字節(jié)串length指定字節(jié)數(shù)。 return value.to_bytes(length, byteorderbig) def hexdump(data: bytes, base_addr: int 0) - str: 把字節(jié)串按16字節(jié)一行打印左邊是偏移地址中間十六進(jìn)制右邊ASCII可見字符。 lines [] for offset in range(0, len(data), 16): chunk data[offset:offset 16] hex_part .join(f{b:02x} for b in chunk) ascii_part .join(chr(b) if 32 b 127 else . for b in chunk) lines.append(f{base_addr offset:04x} {hex_part:48} {ascii_part}) return \n.join(lines)網(wǎng)絡(luò)字節(jié)序固定是大端Python的socket庫在做地址轉(zhuǎn)換時(shí)會(huì)自動(dòng)處理但自己拼報(bào)文時(shí)不會(huì)。to_net_bytes保證了塞進(jìn)頭部字段的端口號(hào)、長(zhǎng)度、校驗(yàn)和按正確順序排列。hexdump則是給報(bào)告加分的工具老師看到帶偏移地址的十六進(jìn)制轉(zhuǎn)儲(chǔ)就知道你有真正的報(bào)文級(jí)調(diào)試能力而不是拿print(done)糊弄。2.3 統(tǒng)一入口每個(gè)實(shí)驗(yàn)一條命令跑完四個(gè)模塊不要各寫各的main函數(shù)收進(jìn)一個(gè)帶子命令的入口文件。我用argparse實(shí)現(xiàn)一個(gè)很輕的CLI每個(gè)實(shí)驗(yàn)對(duì)應(yīng)一個(gè)子命令運(yùn)行參數(shù)里帶URL、模擬丟包率、窗口大小等報(bào)告里寫“運(yùn)行命令如下”老師照著跑就能復(fù)現(xiàn)。# 各實(shí)驗(yàn)統(tǒng)一從lab_runner.py進(jìn)入?yún)?shù)含義在下方說明 python lab_runner.py http get --url http://127.0.0.1:8080/index.html python lab_runner.py udp send --dest 127.0.0.1 --port 9000 --payload hello python lab_runner.py stopwait run --loss 0.2 --timeout 0.5 python lab_runner.py window run --window 4 --loss 0.1 --packets 100參數(shù)說明url是HTTP實(shí)驗(yàn)要請(qǐng)求的地址支持http和httpshttps的證書處理在避坑章節(jié)單獨(dú)說明dest和port是UDP目標(biāo)地址端口loss是模擬丟包率0到1之間的浮點(diǎn)數(shù)timeout是停等協(xié)議超時(shí)時(shí)間單位秒window是滑動(dòng)窗口大小單位是報(bào)文數(shù)packets是要發(fā)送的包總數(shù)。這里的丟包率和窗口大小是實(shí)驗(yàn)報(bào)告里的兩個(gè)核心自變量改參數(shù)跑多組是后面做對(duì)比曲線的基礎(chǔ)。報(bào)告里的“實(shí)驗(yàn)環(huán)境”一節(jié)也需要固定格式。我建議在入口里加一個(gè)--env開關(guān)輸出當(dāng)前Python解釋器和主要庫的版本做報(bào)告時(shí)直接貼結(jié)果def cmd_env(args): 輸出當(dāng)前運(yùn)行環(huán)境信息供實(shí)驗(yàn)報(bào)告“實(shí)驗(yàn)環(huán)境”一節(jié)使用。 import platform import sys print(fPython: {sys.version.split()[0]}) print(fOS: {platform.platform()}) for mod in (socket, struct, time, threading): try: __import__(mod) print(f{mod}: 標(biāo)準(zhǔn)庫) except ImportError: print(f{mod}: 缺失)邏輯說明socket、struct、time、threading都是標(biāo)準(zhǔn)庫不涉及第三方依賴代碼在Python 3.6以上的機(jī)器上能直接跑。第三方庫不是不能用而是多一道安裝步驟有些評(píng)審環(huán)境禁止在線安裝純標(biāo)準(zhǔn)庫最穩(wěn)。這一節(jié)內(nèi)容雖然簡(jiǎn)單但能把“為什么實(shí)驗(yàn)環(huán)境可復(fù)現(xiàn)”講清楚很多報(bào)告里環(huán)境寫得含糊答辯時(shí)一問就露餡。3. 手寫HTTP請(qǐng)求與報(bào)文解析只用socket不看requests3.1 發(fā)送GET請(qǐng)求的最小實(shí)現(xiàn)做HTTP實(shí)驗(yàn)得分點(diǎn)不在于“你能訪問一個(gè)網(wǎng)頁”而在于你能解釋請(qǐng)求報(bào)文里每一行的含義。所以這里不用requests而是用socket手工拼HTTP請(qǐng)求文本再完整讀取服務(wù)器的二進(jìn)制響應(yīng)。import socket def send_http_get(host: str, port: int, path: str) - bytes: 用socket發(fā)一個(gè)HTTP/1.1 GET請(qǐng)求返回服務(wù)器響應(yīng)的完整字節(jié)流。 sock socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.settimeout(5.0) # 5秒沒響應(yīng)就拋異常防止程序掛死 sock.connect((host, port)) # HTTP請(qǐng)求報(bào)文請(qǐng)求行 首部字段 空行 request ( fGET {path} HTTP/1.1\r\n fHost: {host}:{port}\r\n fConnection: close\r\n fUser-Agent: lab-http-client\r\n \r\n ) sock.sendall(request.encode(utf-8)) chunks [] while True: data sock.recv(4096) if not data: break chunks.append(data) sock.close() return b.join(chunks)邏輯說明socket(AF_INET, SOCK_STREAM)創(chuàng)建TCP套接字connect完成三次握手sendall發(fā)送完整的請(qǐng)求字節(jié)流。HTTP請(qǐng)求必須用\r\n\r\n結(jié)尾的空行表示頭部結(jié)束否則服務(wù)器一直等請(qǐng)求頭。recv在TCP對(duì)端正常關(guān)閉后會(huì)返回空字節(jié)串b正好作為循環(huán)退出條件。參數(shù)說明host傳主機(jī)名或IPport默認(rèn)80path是資源路徑。Connection: close這個(gè)請(qǐng)求頭很重要如果不加服務(wù)器可能按HTTP/1.1的keep-alive機(jī)制保持連接recv循環(huán)會(huì)一直阻塞直到超時(shí)拿不到完整響應(yīng)。如果你就是想測(cè)keep-alive那不能靠斷開判斷結(jié)束要靠Content-Length或chunked編碼來解析邊界這是后面一節(jié)的內(nèi)容。3.2 響應(yīng)解析狀態(tài)行、首部字段、正文的邊界判定請(qǐng)求發(fā)出去后收到的響應(yīng)是二進(jìn)制流格式是狀態(tài)行、若干首部字段、空行、實(shí)體正文。解析的關(guān)鍵在于\r\n分隔的位置狀態(tài)行和首部字段是按行分界的首部結(jié)束后是一個(gè)空行之后是正文。如果響應(yīng)頭里有Content-Length正文長(zhǎng)度就固定如果是chunked編碼要按chunk size逐塊解析。實(shí)驗(yàn)里處理Content-Length這一種就夠。def parse_http_response(raw: bytes) - dict: 把HTTP響應(yīng)字節(jié)流解析成狀態(tài)行、頭部字典和正文三部分。 head, sep, body raw.partition(b\r\n\r\n) if not sep: raise ValueError(未找到頭部與正文的分隔符報(bào)文不完整) lines head.split(b\r\n) status_line lines[0].decode(utf-8, errorsreplace) headers {} for line in lines[1:]: if b: in line: name, _, value line.partition(b:) headers[name.decode(utf-8).strip().lower()] ( value.decode(utf-8).strip() ) declared int(headers.get(content-length, 0)) if declared and len(body) ! declared: raise RuntimeError(fContent-Length不匹配聲明{declared}收到{len(body)}) return { status_line: status_line, status_code: int(status_line.split( )[1]), headers: headers, body: body, body_text: body.decode(utf-8, errorsreplace), }邏輯說明partition(b\r\n\r\n)把響應(yīng)切成兩段前半段是狀態(tài)行和首部后半段是正文。首部字段按冒號(hào)拆開名字和值名字統(tǒng)一轉(zhuǎn)小寫這樣后續(xù)用headers[content-length]訪問時(shí)不用考慮大小寫。Content-Length斷言是這個(gè)函數(shù)最提分的地方只有確認(rèn)實(shí)際收到的字節(jié)數(shù)和聲明一致才說明recv循環(huán)完整讀取了響應(yīng)否則程序可能只打印前幾百字節(jié)卻沒被發(fā)現(xiàn)。參數(shù)說明status_code用于快速判斷請(qǐng)求是否成功報(bào)告里寫“服務(wù)器返回200 OK”就靠它headers字典建議報(bào)告里挑content-type、content-length、server、date幾個(gè)字段展示正好對(duì)應(yīng)課程里HTTP首部字段一節(jié)。如果把頭部字段全部打印出來報(bào)告會(huì)顯得沒有篩選能力老師反而覺得你在湊字?jǐn)?shù)。3.3 輸出報(bào)告素材程序打印加抓包對(duì)照實(shí)驗(yàn)報(bào)告需要截圖。與其用截圖工具截控制臺(tái)不如讓程序直接生成緊湊的結(jié)果塊。解析完成后輸出關(guān)鍵信息# HTTP實(shí)驗(yàn)收尾打印核心字段供報(bào)告截圖使用 resp parse_http_response(raw_data) print(f狀態(tài)行: {resp[status_line]}) print(f狀態(tài)碼: {resp[status_code]}) print(關(guān)鍵響應(yīng)頭:) for k in (content-type, content-length, server, date): if k in resp[headers]: print(f {k}: {resp[headers][k]}) print(f正文前100字節(jié): {resp[body_text][:100]!r})運(yùn)行這個(gè)實(shí)驗(yàn)前先在本機(jī)起一個(gè)簡(jiǎn)單的HTTP服務(wù)。Python自帶的模塊就能做到# 在項(xiàng)目目錄下啟動(dòng)簡(jiǎn)易HTTP服務(wù)綁定本機(jī)8080端口 python -m http.server 8080 --bind 127.0.0.1然后另開一個(gè)終端跑實(shí)驗(yàn)客戶端。報(bào)告里我一般建議放兩張圖一張是程序輸出的請(qǐng)求行和響應(yīng)字段另一張是Wireshark里捕獲到的同一個(gè)請(qǐng)求的原始報(bào)文。兩邊一對(duì)照Wireshark里看到的GET /index.html HTTP/1.1\r\nHost:...和代碼里拼出來的字符串逐字符對(duì)應(yīng)這個(gè)實(shí)驗(yàn)的報(bào)文分析部分就拿穩(wěn)了。注意Wireshark要在回環(huán)接口上抓包具體原因避坑章節(jié)會(huì)說。4. 停等協(xié)議與滑動(dòng)窗口把TCP可靠傳輸從課本搬到代碼里4.1 為什么要在模擬鏈路上跑協(xié)議而不是直接連真實(shí)網(wǎng)絡(luò)TCP可靠傳輸是最難直觀看到的部分因?yàn)檎鎸?shí)網(wǎng)絡(luò)里丟包和亂序你控制不了。做這個(gè)實(shí)驗(yàn)的常見做法是自己寫一個(gè)模擬鏈路層在發(fā)送端和接收端之間夾一層帶丟包率、延遲參數(shù)的“虛擬通道”每次重傳都在掌控中報(bào)告里可以精確寫“丟包率10%時(shí)發(fā)生3次超時(shí)重傳”。我見過有人在兩臺(tái)物理機(jī)器之間用真實(shí)網(wǎng)絡(luò)做停等實(shí)驗(yàn)結(jié)果局域網(wǎng)太穩(wěn)定跑了十分鐘一次重傳都沒發(fā)生報(bào)告里根本沒有重傳數(shù)據(jù)可寫。另一個(gè)極端是在本機(jī)回環(huán)上跑但沒有丟包邏輯純屬自欺欺人。下面實(shí)現(xiàn)一個(gè)帶隨機(jī)丟包的模擬鏈路類停等協(xié)議和滑動(dòng)窗口都用它import random import time class LossyChannel: 模擬不可靠鏈路以loss_rate概率丟棄數(shù)據(jù)以delay秒模擬傳播時(shí)延。 def __init__(self, loss_rate: float 0.1, delay: float 0.01): self.loss_rate loss_rate self.delay delay def send(self, sender, receiver, packet): # 先判斷是否丟包再判斷是否延遲兩個(gè)過程互不影響 if random.random() self.loss_rate: return time.sleep(self.delay) receiver.receive(packet)邏輯說明LossyChannel是雙方共享的虛擬鏈路。send先判斷隨機(jī)數(shù)是否小于loss_rate是則直接返回相當(dāng)于報(bào)文在鏈路中被丟棄接收方無感知否則sleep模擬傳播時(shí)延再調(diào)用接收方的receive方法。丟包邏輯不侵入?yún)f(xié)議代碼跑丟包實(shí)驗(yàn)只需要改構(gòu)造時(shí)的loss_rate參數(shù)。參數(shù)說明loss_rate建議取0、0.05、0.1、0.2四檔覆蓋“無丟包”“輕度丟包”“中度丟包”三種場(chǎng)景delay設(shè)成固定值10ms不要用隨機(jī)抖動(dòng)固定時(shí)延才能在對(duì)比實(shí)驗(yàn)里保持單一變量。報(bào)告里窗口大小和丟包率兩個(gè)參數(shù)正交一次只改一個(gè)曲線才講得清因果。4.2 停等協(xié)議發(fā)送方超時(shí)重傳的定時(shí)器怎么設(shè)計(jì)停等協(xié)議邏輯用偽代碼描述像流程圖但落到Python時(shí)難點(diǎn)在定時(shí)器。發(fā)送方發(fā)一個(gè)包后要等ACK等不到就重發(fā)每個(gè)send動(dòng)作必須在“等待超時(shí)”和“收到ACK”兩條路徑之間切換。import time class StopWaitSender: 停等協(xié)議發(fā)送方每發(fā)一個(gè)數(shù)據(jù)包就等ACK超時(shí)則重傳。 def __init__(self, channel, receiver, timeout: float 0.5): self.channel channel self.receiver receiver self.timeout timeout self.ack_received None # 由接收方線程寫入當(dāng)前收到的ACK序號(hào) def send_data(self, data_packets): for seq, packet in enumerate(data_packets): self.ack_received None while self.ack_received ! seq: print(f[發(fā)送] seq{seq}) self.channel.send(self, self.receiver, (seq, packet)) deadline time.time() self.timeout while time.time() deadline: if self.ack_received seq: print(f[確認(rèn)] seq{seq}) break time.sleep(0.01) # 輪詢ACK避免忙等占滿CPU if self.ack_received seq: break print(f[超時(shí)] seq{seq}觸發(fā)重傳)邏輯說明外層循環(huán)遍歷所有數(shù)據(jù)包內(nèi)層循環(huán)負(fù)責(zé)等到ACK。deadline用time.time() timeout計(jì)算絕對(duì)超時(shí)點(diǎn)而不是每輪減剩余時(shí)間這樣判斷不會(huì)因?yàn)檠h(huán)開銷累積誤差。ack_received由接收方的ACK處理線程寫入發(fā)送方輪詢它每10ms檢查一次避免忙等。內(nèi)層循環(huán)退出后檢查是否收到ACK沒有就打印超時(shí)并回到while循環(huán)重傳。序列號(hào)從0開始每發(fā)送一個(gè)包遞增。真實(shí)TCP的序號(hào)是字節(jié)序號(hào)且初始值隨機(jī)這里用包序號(hào)是為了讓日志更直觀。如果想更接近TCP可以改成分組編號(hào)加初始隨機(jī)偏移但報(bào)告的講解重點(diǎn)會(huì)從“重傳機(jī)制”偏到“序號(hào)空間管理”沒有必要。參數(shù)timeout設(shè)0.5秒時(shí)在10ms延遲鏈路上足夠從容如果鏈路延遲改成100ms超時(shí)要相應(yīng)調(diào)大到1秒以上否則會(huì)頻繁誤判超時(shí)報(bào)告里寫參數(shù)時(shí)把這條對(duì)應(yīng)關(guān)系寫清楚就能加分。4.3 滑動(dòng)窗口發(fā)送方窗口移動(dòng)、累積確認(rèn)和緩沖區(qū)清理滑動(dòng)窗口比停等復(fù)雜在發(fā)送方不必等ACK就能連續(xù)發(fā)多個(gè)包所以要有兩個(gè)核心狀態(tài)窗口左沿base和下一個(gè)待發(fā)序號(hào)next_seq。收到累積ACK時(shí)base整體右移緩沖區(qū)里已經(jīng)確認(rèn)的包釋放。class SlidingWindowSender: 滑動(dòng)窗口發(fā)送方窗口大小固定收到累積ACK后窗口左移。 def __init__(self, channel, receiver, window_size: int 4): self.channel channel self.receiver receiver self.window_size window_size self.base 0 # 窗口左沿最早的未確認(rèn)包 self.next_seq 0 # 下一個(gè)要發(fā)送的序列號(hào) self.buffer {} # seq - packet保存已發(fā)未確認(rèn)的包 self.ack_received -1 # 累積ACK0..ack_received都已收到 def send_all(self, total: int): while self.base total: # 窗口沒滿就繼續(xù)發(fā)送 while (self.next_seq self.base self.window_size and self.next_seq total): print(f[發(fā)送] seq{self.next_seq}) self.channel.send(self, self.receiver, (self.next_seq, fdata-{self.next_seq})) self.buffer[self.next_seq] fdata-{self.next_seq} self.next_seq 1 # 收到累積ACK就把窗口整體左移 if self.ack_received self.base: new_base self.ack_received 1 for seq in list(self.buffer): if seq new_base: del self.buffer[seq] print(f[窗口左移] base {self.base} - {new_base}) self.base new_base else: time.sleep(0.01)邏輯說明第一個(gè)while循環(huán)把窗口內(nèi)允許發(fā)送的包全部發(fā)出第二個(gè)if分支處理累積ACK的推進(jìn)。所謂累積ACK就是ACKn表示0到n-1的包都已正確收到所以base可以跳到n1窗口左移后緩沖區(qū)里小于新base的包條目清理掉。這是在接收方每收到一個(gè)有序包就更新ack_received的前提下成立的。代碼里沒有把接收線程寫進(jìn)來是為了讓發(fā)送方狀態(tài)機(jī)更突出報(bào)告里需要說明“簡(jiǎn)化模型只體現(xiàn)窗口移動(dòng)邏輯”。window_size是窗口內(nèi)可容納的最大未確認(rèn)包數(shù)建議實(shí)驗(yàn)時(shí)分別跑1、4、8、16四組。total是要發(fā)送的包總數(shù)建議至少100個(gè)這樣才能在丟包率變化時(shí)看出吞吐量差異。窗口大小為1時(shí)滑動(dòng)窗口退化為停等協(xié)議這個(gè)對(duì)照實(shí)驗(yàn)?zāi)茯?yàn)證代碼的正確性兩種實(shí)現(xiàn)的吞吐量應(yīng)該基本一致。4.4 跑一輪對(duì)比實(shí)驗(yàn)把吞吐量曲線填進(jìn)報(bào)告代碼寫完后拉開差距的是數(shù)據(jù)組織方式。用bash腳本循環(huán)調(diào)用滑動(dòng)窗口實(shí)驗(yàn)分別控制丟包率和窗口大小記錄總耗時(shí)# 固定窗口4改變丟包率記錄發(fā)送100個(gè)包的耗時(shí) for loss in 0 0.05 0.1 0.2; do python lab_runner.py window run --window 4 --loss $loss --packets 100 done # 固定丟包率5%改變窗口大小再跑一組 for win in 1 4 8 16; do python lab_runner.py window run --window $win --loss 0.05 --packets 100 done把兩組命令的輸出整理進(jìn)表格算出發(fā)送速率就是報(bào)告里的吞吐量對(duì)比數(shù)據(jù)。曲線會(huì)呈現(xiàn)兩個(gè)結(jié)論窗口增大吞吐量提升但超過某個(gè)閾值后提升變緩因?yàn)槠款i轉(zhuǎn)向了鏈路時(shí)延和確認(rèn)往返時(shí)間丟包率升高時(shí)重傳增多有效吞吐量明顯下滑。這兩個(gè)結(jié)論寫進(jìn)“實(shí)驗(yàn)結(jié)果分析”比空喊“實(shí)現(xiàn)了可靠傳輸”有說服力得多。報(bào)告的表格里要注明每次實(shí)驗(yàn)的窗口、丟包率、總包數(shù)、耗時(shí)、推算吞吐量五列老師掃一眼就知道你的實(shí)驗(yàn)設(shè)計(jì)是完整的。5. 計(jì)算機(jī)網(wǎng)絡(luò)實(shí)驗(yàn)避坑指南最容易踩到的幾個(gè)坑5.1 recv永遠(yuǎn)收不齊數(shù)據(jù)TCP是字節(jié)流不是報(bào)文現(xiàn)象發(fā)送一個(gè)完整請(qǐng)求recv只返回一部分或者第一次recv拿到了頭部第二次recv卻是空的程序報(bào)“Content-Length不匹配”。原因TCP是面向字節(jié)流的協(xié)議沒有“報(bào)文邊界”概念。應(yīng)用層read可能拿到半包、整包甚至多個(gè)包粘在一起。如果recv只讀一次就退出多讀或漏讀都是正常的。解決在第3章的send_http_get里已經(jīng)用循環(huán)接收解決——while True里不停recv直到拿到空字節(jié)串。另一個(gè)關(guān)鍵點(diǎn)實(shí)驗(yàn)里必須在請(qǐng)求頭加Connection: close否則服務(wù)器不主動(dòng)斷開連接recv循環(huán)阻塞到超時(shí)拋socket.timeout。如果確實(shí)要測(cè)keep-alive就不能靠斷開判斷數(shù)據(jù)結(jié)束而是按Content-Length收完指定字節(jié)再退出循環(huán)。5.2 校驗(yàn)和怎么算都不對(duì)進(jìn)位回卷寫錯(cuò)現(xiàn)象自己構(gòu)造的UDP報(bào)文發(fā)出去對(duì)方一直不回包Wireshark里協(xié)議棧標(biāo)記checksum錯(cuò)誤包字體變紅。原因大部分人在實(shí)現(xiàn)校驗(yàn)和時(shí)漏了“進(jìn)位回卷”。Internet校驗(yàn)和不是簡(jiǎn)單的16位累加取反每加一個(gè)16位字后必須把超過16位的進(jìn)位回卷到低16位而且要反復(fù)執(zhí)行直到?jīng)]有進(jìn)位。有人寫的s s 16只做了一次回卷累加過程中產(chǎn)生多次進(jìn)位時(shí)結(jié)果必錯(cuò)。解決按2.2節(jié)的checksum實(shí)現(xiàn)關(guān)鍵是s (s 0xffff) (s 16)寫在for循環(huán)里每個(gè)16位字相加后都做回卷。完成后用已知數(shù)據(jù)自測(cè)全零數(shù)據(jù)校驗(yàn)和應(yīng)為0xFFFF單字節(jié)0x00補(bǔ)零后校驗(yàn)和也應(yīng)為0xFFFF。這兩個(gè)自測(cè)用例寫進(jìn)報(bào)告能直接證明算法實(shí)現(xiàn)正確。5.3 校驗(yàn)和字段字節(jié)序反轉(zhuǎn)高字節(jié)變低字節(jié)現(xiàn)象校驗(yàn)和算出來是0x1234Wireshark里顯示0x3412。原因計(jì)算結(jié)果是16位整數(shù)寫進(jìn)報(bào)文時(shí)要按網(wǎng)絡(luò)字節(jié)序大端寫入即高字節(jié)在前。有人用struct.pack(H, checksum)用了小端于是高低字節(jié)互換了。解決用struct.pack(!H, checksum)或第2章的to_net_bytes(checksum, 2)。注意UDP偽頭部里的IP地址字段也按大端讀取不要逐個(gè)字節(jié)做反轉(zhuǎn)。字節(jié)序這類問題最折磨人看起來運(yùn)行成功但協(xié)議棧不認(rèn)自測(cè)方法就是把Wireshark的checksum字段值和代碼輸出逐一對(duì)比能對(duì)上就說明字節(jié)序沒寫反。5.4 抓包工具在虛擬機(jī)里抓不到自己的流量現(xiàn)象在虛擬機(jī)上跑實(shí)驗(yàn)Wireshark選了網(wǎng)卡后只看到ARP和廣播看不到自己程序的TCP/UDP流量。原因虛擬機(jī)默認(rèn)NAT模式下流量經(jīng)過宿主機(jī)的NAT引擎轉(zhuǎn)發(fā)虛擬網(wǎng)卡上不一定能看到本機(jī)回環(huán)流量也可能抓包網(wǎng)卡選錯(cuò)選成了僅主機(jī)模式。解決把虛擬機(jī)的網(wǎng)絡(luò)適配器改成橋接模式讓虛擬機(jī)和宿主機(jī)在同一網(wǎng)段或者更省事實(shí)驗(yàn)里程序都連127.0.0.1回環(huán)地址Wireshark選Loopback接口直接抓?；丨h(huán)實(shí)驗(yàn)一樣能證明協(xié)議實(shí)現(xiàn)因?yàn)門CP/UDP協(xié)議棧的處理路徑?jīng)]有變只是物理網(wǎng)卡變成了虛擬回環(huán)接口。抓不到包時(shí)優(yōu)先檢查接口選擇其次是網(wǎng)絡(luò)模式。5.5 實(shí)驗(yàn)報(bào)告“截圖漂亮但邏輯不自洽”現(xiàn)象報(bào)告里有截圖、有代碼但代碼輸出里的序列號(hào)和截圖對(duì)不上或者文字寫“丟包率20%時(shí)有大量重傳”截圖里卻一次重傳記錄都沒有。原因報(bào)告是后補(bǔ)的截圖從別的實(shí)驗(yàn)復(fù)制或重新跑時(shí)改了參數(shù)。解決實(shí)驗(yàn)日志要自帶參數(shù)前綴。比如停等協(xié)議的每行輸出都前置[loss0.2][seq3]截圖里天然帶實(shí)驗(yàn)條件后補(bǔ)時(shí)一眼能看出不一致。每張截圖下方用一行字寫清“運(yùn)行命令關(guān)鍵參數(shù)”這個(gè)習(xí)慣是我在幫人看課設(shè)代碼時(shí)驗(yàn)證出來的凡是這么寫的報(bào)告基本不會(huì)被老師挑格式毛病。6. 把實(shí)驗(yàn)方案升級(jí)成可復(fù)用腳本自動(dòng)校驗(yàn)、配置化參數(shù)和驗(yàn)收標(biāo)準(zhǔn)這套方案在校內(nèi)課程場(chǎng)景已經(jīng)夠用但想讓它經(jīng)得起反復(fù)修改和復(fù)用我建議加三層。第一層是自動(dòng)校驗(yàn)。把Content-Length斷言、校驗(yàn)和自測(cè)、重傳計(jì)數(shù)、窗口推進(jìn)檢查都收進(jìn)一個(gè)驗(yàn)證腳本跑完實(shí)驗(yàn)直接輸出通過/失敗。改代碼時(shí)不必逐個(gè)實(shí)驗(yàn)人工復(fù)查。# validate_report.py 片段校驗(yàn)各實(shí)驗(yàn)輸出是否滿足驗(yàn)收條件 import json results { http_status_ok: resp[status_code] 200, http_content_length_ok: len(resp[body]) int(resp[headers][content-length]), checksum_zero_ok: checksum(b\x00\x00\x00\x00) 0xffff, stopwait_retransmit_ok: retransmit_count 0 if loss_rate 0 else True, window_base_advance_ok: final_base total_packets, } print(json.dumps(results, indent2, ensure_asciiFalse))邏輯說明每個(gè)檢查項(xiàng)對(duì)應(yīng)一個(gè)布爾表達(dá)式只有前四項(xiàng)全為true且窗口推進(jìn)正確才說明這輪實(shí)驗(yàn)完整跑通。loss_rate 0條件保證了“無丟包時(shí)要求重傳次數(shù)大于0”這種錯(cuò)誤判斷不會(huì)出現(xiàn)。第二層是參數(shù)配置化。把丟包率、時(shí)延、窗口、超時(shí)從代碼里抽出來放到一個(gè)配置文件或命令行參數(shù)里。當(dāng)前代碼已經(jīng)通過lab_runner.py接收這些參數(shù)可以進(jìn)一步加一個(gè)config.yaml或簡(jiǎn)單的config.json報(bào)告里直接貼配置文件內(nèi)容老師和評(píng)審都能看到你的默認(rèn)參數(shù)不用猜。第三層是連接建立與釋放的狀態(tài)機(jī)。目前滑動(dòng)窗口實(shí)驗(yàn)只覆蓋數(shù)據(jù)傳輸階段你可以繼續(xù)加三次握手和四次揮手的日志輸出把連接狀態(tài)遷移打印出來。這樣報(bào)告就從“兩個(gè)孤立協(xié)議點(diǎn)”擴(kuò)展成“一條完整傳輸鏈路”在課程設(shè)計(jì)里的完備性會(huì)明顯高一個(gè)檔次。這幾層升級(jí)的內(nèi)在邏輯是我在校驗(yàn)?zāi)硞€(gè)帶丟包率前綴的協(xié)議日志時(shí)悟出來的網(wǎng)絡(luò)實(shí)驗(yàn)的第一原則是可觀測(cè)性日志和斷言比代碼本身更能體現(xiàn)工程素養(yǎng)。后來我把“所有日志必須帶參數(shù)前綴、所有結(jié)論必須有斷言支撐”寫進(jìn)了自己的實(shí)驗(yàn)規(guī)范就再?zèng)]在答辯時(shí)被問住過。希望這篇東西能幫你把計(jì)算機(jī)網(wǎng)絡(luò)實(shí)驗(yàn)做成一套真正跑得動(dòng)、講得清、識(shí)得破的方案祝順利。本文還有配套的精品資源點(diǎn)擊獲取