簡介這份西安電子科技大學(xué)計算機(jī)網(wǎng)絡(luò)課程實驗報告面向正在學(xué)習(xí)計網(wǎng)課程、需要完成實驗或整理報告的學(xué)生也可供復(fù)習(xí)網(wǎng)絡(luò)基礎(chǔ)配置的讀者參考。內(nèi)容圍繞六個實驗展開雙絞線制作與網(wǎng)絡(luò)設(shè)備訪問配置、交換機(jī)VLAN劃分、Windows下DNS與DHCP服務(wù)器配置、WEB與FTP服務(wù)搭建、路由器基礎(chǔ)配置以及靜態(tài)路由和三層交換機(jī)配置每部分包含實驗?zāi)康?、設(shè)備環(huán)境、拓?fù)渑c配置截圖、要點和心得體會。壓縮包內(nèi)共1個doc文件大小約3.67MB匯總成一份可直接查閱的文檔便于按實驗?zāi)K對照操作與查漏補(bǔ)缺。已有1197人學(xué)習(xí)適合作為課程實驗的過程記錄和配置思路參考幫助讀者理解星型以太網(wǎng)、IP與子網(wǎng)掩碼、VLAN隔離、域名解析、動態(tài)地址分配、IIS與FTP服務(wù)、路由表及三層交換等知識點。1. 實驗報告不是指導(dǎo)書的復(fù)印件一份能被別人照著復(fù)現(xiàn)的記錄長什么樣期末前一周某高校的實驗室里最常見的場景是有人把實驗指導(dǎo)書的截圖拼成三十頁 PDF交上去被打回來重寫。計算機(jī)網(wǎng)絡(luò)這門課的實驗報告真正被審的從來不是排版和頁數(shù)而是證據(jù)鏈別人拿著你寫的命令、過濾表達(dá)式和字段表能不能在他自己的機(jī)器上把同一個現(xiàn)象再抓一遍、再對一次數(shù)。這篇筆記講的就是這件事——抓包取證怎么留痕Socket 編程怎么把并發(fā)和異常寫成可核對的記錄可靠傳輸?shù)臓顟B(tài)機(jī)怎么用可觀察的量說話以及那些讓報告看起來完整、其實被追問一句就露餡的地方。適合正在做計網(wǎng)課程實驗、或者要把網(wǎng)絡(luò)行為寫成可復(fù)核文檔的讀者。2. 抓包取證Wireshark 顯示過濾與 tshark 字段導(dǎo)出的證據(jù)鏈寫法抓包實驗是計網(wǎng)課程里最容易拿分也最容易丟分的一塊。拿分是因為現(xiàn)象直觀丟分是因為大部分人只交了一張截圖圖上沒有任何上下文不知道是在哪個接口抓的、抓的時候跑了什么命令、過濾條件是什么、時間基準(zhǔn)從哪一刻算起。換個同學(xué)拿著這張圖根本沒法復(fù)現(xiàn)。我在整理這類材料時給自己定了一條硬規(guī)矩任何一張抓包截圖旁邊必須配一行能直接粘貼執(zhí)行的命令否則這張圖就等于沒做。2.1 一條合格的證據(jù)鏈得湊齊四樣?xùn)|西先說清楚“證據(jù)鏈”具體指什么。它不是一個抽象概念而是四件可以逐項核對的東西時間基準(zhǔn)、過濾表達(dá)式原文、關(guān)鍵字段表、結(jié)論句。時間基準(zhǔn)指frame.time_relative這類相對時間而不是絕對時間戳絕對時間戳受抓包機(jī)時鐘和時區(qū)影響讀者沒法對齊過濾表達(dá)式原文指的是你用了哪條顯示過濾器把無關(guān)流量篩掉比如tcp.port8080 tcp.flags.syn1這條必須原樣寫進(jìn)報告關(guān)鍵字段表是把同一批包里你要論證的那幾個字段抽出來排成表格讓讀者一眼看出序號、標(biāo)志位和確認(rèn)號之間的對應(yīng)關(guān)系結(jié)論句則要落到具體數(shù)字上比如“SYN 到 SYN-ACK 之間耗時 0.42 ms”而不是“握手成功”。很多報告翻車是因為把“Wireshark 里看到了三次握手”當(dāng)成結(jié)論。這句話既不可證偽也不可復(fù)現(xiàn)。換成“在 lo 接口上以tcp port 8080為捕獲過濾器抓包客戶端端口 51234、服務(wù)端端口 8080第 1 幀 SYN 帶 seq0第 2 幀 SYN-ACK 帶 seq0 ack1第 3 幀 ACK 帶 seq1 ack1相對時間分別為 0.000、0.042、0.048 秒”性質(zhì)就完全不一樣了任何一個裝了同版本工具的人都能對著跑一遍。下面這張表是我在每份抓包報告開頭都會附的字段說明把“圖里那條橫線到底是什么意思”一次講清楚字段抓包里的含義報告里為什么必須寫frame.number幀在整個 pcap 里的絕對序號結(jié)論句引用幀號才不會指錯frame.time_relative相對第一幀的時間單位秒唯一可跨機(jī)器對齊的時間基準(zhǔn)tcp.seq/tcp.ack相對序號與相對確認(rèn)號判斷重傳、亂序、丟包的依據(jù)tcp.flags.str標(biāo)志位組合的字符串形式比單獨(dú)看 SYN/ACK 位更不容易誤判tcp.analysis.retransmission工具推斷的重傳標(biāo)記報告里要注明“工具推斷”不是原始字段tcp.len本幀承載的 TCP 載荷長度算吞吐、判斷是否純 ACK 的依據(jù)表格最后一行值得單獨(dú)強(qiáng)調(diào)tcp.analysis.*這一族是 Wireshark 根據(jù)序列號推出來的派生字段不是協(xié)議頭里真實存在的東西。報告里引用它必須寫清楚是推斷值否則一旦讀者的抓包點位置不同比如抓在中間設(shè)備上同一個包可能不再被判為重傳結(jié)論就對不上了。這一點屬于典型的血淚經(jīng)驗被追問過一次就再也不會忘。2.2 先造可控流量再談抓包對著瀏覽器亂點然后抓一堆包是效率最低的做法。比較穩(wěn)的方式是自己起一個行為完全確定的被測服務(wù)讓流量的數(shù)量、順序、大小都在你的掌控之內(nèi)。下面這段代碼起了一個本地 HTTP 服務(wù)每次 GET 返回固定長度的純文本方便你在抓包結(jié)果里精確數(shù)出請求和響應(yīng)的字節(jié)數(shù)from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer class Handler(BaseHTTPRequestHandler): # HTTP/1.1 才會復(fù)用連接默認(rèn)的 1.0 每條請求后關(guān)閉 protocol_version HTTP/1.1 def do_GET(self): body bhello-cn-lab\n # 固定 13 字節(jié)便于核對 tcp.len self.send_response(200) self.send_header(Content-Type, text/plain) self.send_header(Content-Length, str(len(body))) # 必須給否則靠 FIN 分幀 self.end_headers() self.wfile.write(body) def log_message(self, fmt, *args): pass # 關(guān)掉默認(rèn)日志避免干擾終端輸出 if __name__ __main__: srv ThreadingHTTPServer((127.0.0.1, 8080), Handler) srv.serve_forever()邏輯上沒幾行但每行都有講究。protocol_version HTTP/1.1決定了連接能不能復(fù)用如果你要觀察的是“一個 TCP 連接上跑多條 HTTP 請求”就必須設(shè)這一行否則每條請求結(jié)束都會看到一次 FIN抓出來的圖會讓你誤以為服務(wù)端在頻繁斷連。Content-Length是響應(yīng)分幀的唯一依據(jù)少了這個頭客戶端只能靠連接關(guān)閉來判斷響應(yīng)結(jié)束那你在抓包里看到的結(jié)束標(biāo)志就不是長度而是四次揮手結(jié)論會整個偏掉。ThreadingHTTPServer而不是普通的HTTPServer是因為前者每來一個連接起一個線程你能同時壓多個并發(fā)連接而不會互相阻塞。參數(shù)方面端口選 8080 是為了避開需要特權(quán)的低位端口在非 root 環(huán)境下也能直接綁定綁定127.0.0.1而不是0.0.0.0是為了讓流量只走回環(huán)不經(jīng)過任何外部網(wǎng)絡(luò)抓出來的包干凈且沒有隱私顧慮。這兩點看起來是小事但在多人共用一臺實驗機(jī)的時候綁定范圍選錯會導(dǎo)致端口沖突和抓包串流兩個問題同時出現(xiàn)。流量造好之后抓包這一步用命令行工具比圖形界面更適合留證據(jù)因為命令本身就是報告內(nèi)容的一部分# 終端 1后臺抓包只抓 8080 端口的 TCP20 秒后自動停 tshark -i lo -f tcp port 8080 -w handshake.pcap -a duration:20 # 終端 2起服務(wù)并制造三條請求 python3 http_echo.py sleep 1 for i in 1 2 3; do curl -s -o /dev/null http://127.0.0.1:8080/item$i; done-i lo指定回環(huán)接口這一步是最常出錯的地方Linux 上回環(huán)叫l(wèi)o部分系統(tǒng)上需要在下拉框里單獨(dú)選中回環(huán)適配器選成物理網(wǎng)卡的話一個包也抓不到然后你會以為是服務(wù)沒起來。-f是捕獲過濾器用 BPF 語法在抓取階段就丟包能顯著減小文件體積它和 Wireshark 里那個顯示過濾器不是一回事別混用。-a duration:20表示抓滿 20 秒自動停止并落盤比手動 Ctrl-C 更可控尤其是在寫腳本自動跑的時候。2.3 tshark 一行命令把 pcap 變成表格圖形界面適合看不適合貼。報告里真正有價值的是把關(guān)鍵字段導(dǎo)成 CSV 或?qū)R文本讓讀者能逐行核對。下面這條命令是我每次都會跑一遍的tshark -r handshake.pcap \ -Y tcp.port 8080 tcp.flags.syn 1 \ -T fields \ -e frame.number -e frame.time_relative \ -e ip.src -e tcp.srcport -e tcp.dstport \ -e tcp.flags.str -e tcp.seq -e tcp.ack -e tcp.len \ -E headery -E separator, -E quoted \ handshake_syn.csv逐段解釋-r讀已有文件-Y是顯示過濾器語法和 Wireshark 界面里那個輸入框完全一致所以報告里寫一次過濾表達(dá)式界面和命令行都能復(fù)用。-T fields表示按字段輸出而不是按包輸出這是把抓包變成表格的關(guān)鍵開關(guān)。每個-e跟一個字段名字段名可以在 Wireshark 狀態(tài)欄里直接看到不用背。-E headery輸出表頭-E separator,用逗號分隔-E quoted給字符串字段加雙引號防止標(biāo)志位那種帶逗號的值把列沖散。常見做法是先跑一個不帶-Y的版本看看有多少條再逐步收窄過濾條件。如果導(dǎo)出的表是空的九成是顯示過濾器寫錯了tcp.port只匹配 TCP如果你抓的是 UDP 的 DNS 查詢就得換成udp.port 53想同時匹配兩個端口要用tcp.port 8080 || tcp.port 8081寫成逗號是不行的。另外tcp.flags.syn 1會把 SYN-ACK 也算進(jìn)來因為 SYN-ACK 的 SYN 位同樣是 1。如果你要的只是純 SYN得寫成tcp.flags.syn 1 tcp.flags.ack 0。這個坑我在第一次交報告時就踩過導(dǎo)出的表里混進(jìn)了 SYN-ACK導(dǎo)致“客戶端發(fā)起連接數(shù)”多算了一倍。導(dǎo)出之后表格不會自己變成結(jié)論還需要一步人工對照。我的習(xí)慣是把客戶端端口、服務(wù)端端口、三個包的 seq/ack 關(guān)系寫成一句話再附上 CSV 的前三行。這樣讀者既能看結(jié)論也能驗證結(jié)論是不是從數(shù)據(jù)里來的。抓包實驗的評分點基本都落在這個“數(shù)據(jù)到結(jié)論”的推導(dǎo)上而不是你抓了多少個包。3. Socket 編程實驗從阻塞回顯到 select 多路復(fù)用的三個必調(diào)參數(shù)Socket 編程這一塊大部分人卡住不是因為不會寫socket()而是因為寫出來的東西只能在自己機(jī)器上、只連一個客戶端、只發(fā)一條短消息的時候正常工作。課程實驗的驗收往往會加兩個動作同時連多個客戶端、發(fā)一條超過緩沖區(qū)大小的長消息。這兩個動作一加阻塞式寫法立刻原形畢露。所以這部分我一般按“能跑通的最小骨架 → 參數(shù)怎么調(diào) → 并發(fā)怎么改 → 壓測數(shù)據(jù)怎么留”四步走每一步都在報告里留一條對應(yīng)的記錄。3.1 阻塞式 TCP 回顯二十行代碼與四個必調(diào)參數(shù)先看能跑通的最小版本所有參數(shù)都顯式寫出來不用默認(rèn)值import socket HOST, PORT 127.0.0.1, 9000 BACKLOG 128 # 已完成三次握手但還沒被 accept 的連接隊列長度 BUF 4096 # 單次 recv 的上限不是“一條消息”的長度 def serve(): srv socket.socket(socket.AF_INET, socket.SOCK_STREAM) # 允許綁定處于 TIME_WAIT 的地址避免重啟時 Address already in use srv.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) srv.bind((HOST, PORT)) srv.listen(BACKLOG) print(flistening on {HOST}:{PORT}) while True: conn, addr srv.accept() # 阻塞點 1沒有新連接就停在這 with conn: conn.settimeout(30) # 防止某個客戶端掛住不放 while True: data conn.recv(BUF) # 阻塞點 2沒有數(shù)據(jù)就停在這 if not data: # 對端關(guān)閉recv 返回空字節(jié) break conn.sendall(data) # sendall 內(nèi)部循環(huán)保證全部寫出 if __name__ __main__: serve()四個參數(shù)值得在報告里各寫一句話。SO_REUSEADDR解決的是服務(wù)端主動關(guān)閉后端口進(jìn)入 TIME_WAIT、立刻重啟綁不上端口的問題這個在反復(fù)調(diào)試階段幾乎每天都會遇到加上它之后不用再等兩分鐘。BACKLOG不是“最大連接數(shù)”而是內(nèi)核里已完成握手等待應(yīng)用層accept的隊列長度隊列滿了之后新來的 SYN 會被丟棄或收到 RST所以壓測時如果并發(fā)上不去先懷疑這個值太小而不是代碼寫錯。BUF決定單次recv最多拿多少字節(jié)TCP 是字節(jié)流協(xié)議recv(4096)可能只返回 100 字節(jié)也可能一次返回 4096 字節(jié)絕不能假設(shè)“一次 recv 等于一條完整消息”。settimeout(30)是給阻塞調(diào)用加一個上限避免某個客戶端連上不發(fā)數(shù)據(jù)把整個單線程服務(wù)拖死。sendall和send的區(qū)別也要寫清楚這是新手最容易忽略的一處。send返回實際寫出的字節(jié)數(shù)可能小于你傳入的長度sendall內(nèi)部循環(huán)直到全部寫出或者拋異常。報告里如果只寫send又不檢查返回值長消息場景下就會丟數(shù)據(jù)而且丟得很隱蔽——短消息測試完全正常一上長度就出問題。3.2 用 select 改成事件驅(qū)動順帶解釋粘包阻塞版只能順序服務(wù)第二個客戶端必須等第一個斷開。改成多路復(fù)用之后一個線程就能盯住所有連接。下面這個版本用select邏輯直白適合寫進(jìn)報告當(dāng)對照組import select import socket srv socket.socket(socket.AF_INET, socket.SOCK_STREAM) srv.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) srv.bind((127.0.0.1, 9000)) srv.listen(128) srv.setblocking(False) # 非阻塞是 select 版本的前提 rlist [srv] pending {} # 每個連接一個應(yīng)用層緩沖區(qū) while True: readable, _, _ select.select(rlist, [], [], 1.0) # 1 秒超時便于退出 for s in readable: if s is srv: conn, _ srv.accept() conn.setblocking(False) rlist.append(conn) pending[conn] b else: chunk s.recv(4096) if not chunk: rlist.remove(s) pending.pop(s, None) s.close() else: pending[s] chunk # 先攢 s.sendall(chunk) # 再原樣回寫關(guān)鍵點在最后兩行。select告訴你“這個 socket 可讀”但沒告訴你“讀到的是一條完整消息”。如果客戶端連續(xù)發(fā)了兩條短消息兩次recv可能一次拿到兩條拼接的內(nèi)容也可能第一條被切成兩半分兩次拿到這就是粘包和拆包。解決辦法只有一個應(yīng)用層自己定邊界要么用長度前綴要么用分隔符然后在緩沖區(qū)里判斷“夠不夠一條”。報告里如果能寫出這一段并且給出一次“連續(xù)發(fā)三條 5 字節(jié)消息、服務(wù)端分兩次讀到 12 字節(jié)”的實測記錄說服力比貼十張截圖都強(qiáng)。非阻塞模式還有一個必須處理的返回值recv在沒有數(shù)據(jù)可讀時會拋BlockingIOErrorsendall在發(fā)送緩沖區(qū)滿時也可能阻塞。select保證的是“可讀”而不是“一定讀得到完整數(shù)據(jù)”所以真實的非阻塞服務(wù)端通常還要維護(hù)一個寫緩沖隊列把沒發(fā)完的部分掛起來等下一次可寫事件。課程實驗做到select這一層已經(jīng)夠用但報告里提一句這個邊界能明顯看出你知道自己在做什么。3.3 并發(fā)壓測怎么留數(shù)據(jù)而不是只說“能同時連多個”“能同時連多個客戶端”是一句沒法驗證的話?？沈炞C的寫法是給出并發(fā)數(shù)、每連接消息數(shù)、成功率和耗時。下面這段壓測腳本會啟動 200 個線程每個線程建一條連接、往返 20 次最后統(tǒng)計成功連接數(shù)import socket import threading import time N, MSG, ROUNDS 200, bping * 64, 20 ok 0 lock threading.Lock() def worker(): global ok try: with socket.create_connection((127.0.0.1, 9000), timeout5) as s: for _ in range(ROUNDS): s.sendall(MSG) got b # TCP 是字節(jié)流必須循環(huán)讀到長度夠不能只 recv 一次 while len(got) len(MSG): chunk s.recv(4096) if not chunk: return got chunk with lock: ok 1 except (ConnectionError, OSError): pass t0 time.time() threads [threading.Thread(targetworker) for _ in range(N)] for t in threads: t.start() for t in threads: t.join() print(fsuccess{ok}/{N} elapsed{time.time() - t0:.2f}s)MSG取 256 字節(jié)、ROUNDS取 20這兩個數(shù)字不是隨手寫的消息短到能塞進(jìn)一個 MSS往返次數(shù)多到足以暴露緩沖區(qū)處理不當(dāng)?shù)膯栴}同時又不會讓測試跑太久。timeout5是為了在服務(wù)端卡死時不至于永遠(yuǎn)等下去。那段while len(got) len(MSG)的循環(huán)是整個腳本的核心少了它你就會遇到“明明服務(wù)端回寫了客戶端卻偶爾讀不全”的詭異現(xiàn)象而這類現(xiàn)象往往會被誤判成服務(wù)端 bug。壓測結(jié)果寫進(jìn)報告時至少要帶三樣并發(fā)數(shù)、成功率和耗時再加一句環(huán)境說明同機(jī)回環(huán)、單線程select服務(wù)端。同機(jī)回環(huán)的時延極低測出來的數(shù)字不能拿去和真實網(wǎng)絡(luò)比這一點要在報告里主動聲明反而顯得嚴(yán)謹(jǐn)。如果兩個版本的對比數(shù)據(jù)都有——阻塞版在 200 并發(fā)下的成功率和select版的成功率——那這張對比表基本就是這一章最有分量的內(nèi)容。4. 可靠傳輸實驗停等、GBN 的窗口參數(shù)與丟包注入怎么在報告里說清楚可靠傳輸這部分是計網(wǎng)課程里理論味最重的一塊也是最容易寫成“抄一遍協(xié)議流程”的地方。把它拉回可復(fù)現(xiàn)的關(guān)鍵是把“協(xié)議”變成“狀態(tài)機(jī) 參數(shù) 可觀測指標(biāo)”。狀態(tài)機(jī)決定有哪些狀態(tài)和遷移條件參數(shù)決定它在什么條件下會退化指標(biāo)決定你怎么證明它按預(yù)期退化。三者缺一個報告就還是描述性文字。4.1 狀態(tài)機(jī)該怎么畫進(jìn)報告而不是貼一張流程圖很多報告里的狀態(tài)機(jī)圖只有發(fā)送方而且只有“發(fā)送—等待—收到確認(rèn)—繼續(xù)”這條主干。真正能看出理解的是異常路徑超時重傳、收到重復(fù)確認(rèn)、收到失序幀、收到否定確認(rèn)。這四條邊如果不畫讀者沒法判斷你的實現(xiàn)到底有沒有處理這些情況。我一般用表格代替流程圖因為表格能把“事件 / 當(dāng)前狀態(tài) / 動作 / 下一狀態(tài)”四列一次擺清楚比圖形更容易核對。發(fā)送方大致是這幾個狀態(tài)空閑、等待確認(rèn)、重傳中、窗口滿阻塞。接收方簡化成兩個期望序號匹配、期望序號不匹配。把“收到序號等于期望值的幀”和“收到序號不等于期望值的幀”分別寫一行那么 GBN 和 SR 的差別就自然地落在了“不匹配時丟棄還是緩存”這一格上。表格還有一個好處是能和代碼對得上。如果你在報告里寫了“收到失序幀時回送最后一個正確接收幀的確認(rèn)號”那么代碼里就必須能找到這句邏輯對應(yīng)的那一行否則評審一句“你這里實際是怎么處理的”就問住了。4.2 停等、GBN、SR 的窗口與序列號空間約束這三者的對比如果只寫“窗口大小不同”基本等于沒寫。真正要寫的是約束條件和它背后的原因。下面這張表可以直接用協(xié)議發(fā)送窗口序列號空間 k 位下的約束接收端緩存重傳粒度停等1序列號 1 位即可無單幀GBNWW ≤ 2^k ? 1無失序即丟窗口內(nèi)全部未確認(rèn)幀SRWW ≤ 2^(k?1)有逐幀緩存僅丟失那一幀GBN 的W ≤ 2^k ? 1和 SR 的W ≤ 2^(k?1)這兩個約束是報告里最值錢的兩行因為它們是“為什么序列號位數(shù)不能隨便定”的直接答案。拿 3 位序列號0~7舉例GBN 的窗口最多取 7取到 8 就會出現(xiàn)“新幀和老幀的序號完全重合、接收方分不清是重傳還是新數(shù)據(jù)”的死局。這個推導(dǎo)過程可以寫一小段配上一次故意把窗口設(shè)成 8 的失敗實驗說服力會非常強(qiáng)。超時時間 RTO 也別用固定值糊過去。教科書上的 Jacobson/Karels 估算可以直接實現(xiàn)報告里附上公式和一段樣本數(shù)據(jù)就能把“RTO 為什么要自適應(yīng)”講明白# RFC 6298 風(fēng)格的 RTO 估算alpha1/8, beta1/4 alpha, beta 0.125, 0.25 srtt, rttvar, rto None, None, 1.0 for sample in rtt_samples: # 每次測得的往返時延 if srtt is None: srtt, rttvar sample, sample / 2.0 else: rttvar (1 - beta) * rttvar beta * abs(srtt - sample) srtt (1 - alpha) * srtt alpha * sample rto srtt max(0.2, 4 * rttvar) # 下限 0.2s防止過度重傳 print(fsrtt{srtt:.4f}s rttvar{rttvar:.4f}s rto{rto:.4f}s)alpha小意味著平滑后的 RTT 更穩(wěn)、對突發(fā)抖動不敏感beta大一點意味著方差估計跟得更快。4 * rttvar這個系數(shù)是讓 RTO 覆蓋大部分正常波動max(0.2, ...)的下限是為了防止 RTT 極小的回環(huán)環(huán)境里 RTO 被算到毫秒級、導(dǎo)致大量無謂重傳。在回環(huán)上跑這段代碼你會發(fā)現(xiàn) RTO 很容易被壓到 0.2 秒的下限這正好可以寫進(jìn)報告當(dāng)一個觀察結(jié)論低時延環(huán)境下固定下限起主導(dǎo)作用自適應(yīng)部分體現(xiàn)不出來。4.3 丟包注入與可觀測指標(biāo)實驗要在“沒有真實丟包”的環(huán)境里驗證重傳邏輯只能自己造丟包。最可控的方式是在發(fā)送路徑上加一個隨機(jī)丟包過濾器按固定種子丟棄這樣每次跑出來的序列完全一樣報告里的數(shù)字才能被復(fù)現(xiàn)import random def gbn_simulate(total20, window4, drop_rate0.15, seed1): rng random.Random(seed) # 固定種子 結(jié)果可復(fù)現(xiàn) base, expected 0, 0 # 窗口左沿 / 接收方期望序號 acked set() # 接收方已按序收到的序號 frames_sent 0 # 含重傳的總發(fā)送次數(shù) while base total: for seq in range(base, min(base window, total)): frames_sent 1 if rng.random() drop_rate: continue # 這一幀在信道上丟了 if seq expected: # 按序到達(dá)接收方累計確認(rèn)前移 acked.add(seq) expected 1 while expected in acked: expected 1 # 失序到達(dá)GBN 接收方直接丟棄不回緩存 while base in acked: base 1 # 窗口左沿前移到第一個未確認(rèn)幀 return frames_sent for p in (0.0, 0.05, 0.15, 0.30): print(fdrop{p:.2f} frames_sent{gbn_simulate(drop_ratep)})seed固定是這份代碼能進(jìn)報告的前提否則每跑一次數(shù)字都不一樣讀者沒法核對。window和drop_rate是兩個自變量frames_sent是應(yīng)變量跑出四組數(shù)據(jù)就是一張“丟包率—發(fā)送次數(shù)”曲線。把它和停等協(xié)議window1的同口徑數(shù)據(jù)放在一起能直接看出“窗口越大單次丟包的代價越高”這個結(jié)論而不是靠嘴說。參數(shù)怎么選也有講究。drop_rate從 0 開始是為了拿到一個無丟包的基準(zhǔn)值任何實驗都要有基準(zhǔn)0.30 這種高丟包率是為了把重傳邏輯逼到極限看會不會出現(xiàn)死循環(huán)或者窗口卡死。window取 4 是在 3 位序列號的約束上限 7之內(nèi)留了余量方便你另外再跑一組window8的越界實驗做對照那一組的表現(xiàn)會明顯異常正好用來支撐前面那張約束表?？捎^測指標(biāo)除了發(fā)送次數(shù)還有兩個值得寫一是“從開始到全部確認(rèn)的輪次數(shù)”反映吞吐二是“重復(fù)收到的幀數(shù)”反映帶寬浪費(fèi)。這兩個數(shù)都能從同一份模擬里順手統(tǒng)計出來報告里三個指標(biāo)并排比單個數(shù)字更像一次正經(jīng)實驗。5. 避坑與排查計網(wǎng)實驗報告被打回的 5 個高頻原因下面這五條基本覆蓋了我見過和踩過的絕大多數(shù)退回理由每一條都按“現(xiàn)象—原因—解決”寫方便對著自查。第一條截圖很漂亮但沒人能復(fù)現(xiàn)。現(xiàn)象是報告里每張圖都能看清三次握手但看不到抓的是哪個接口、用的什么過濾條件。原因是把“看到”當(dāng)成了“證據(jù)”忽略了抓包是受環(huán)境和過濾條件影響的。解決辦法是每張圖配一行完整命令包含接口、捕獲過濾器、顯示過濾器和時間基準(zhǔn)字段命令放在圖的上方而不是附錄里。第二條回環(huán)上抓不到任何包?，F(xiàn)象是服務(wù)明明起來了、curl也有返回抓包文件卻只有幾十字節(jié)。原因是接口選錯了抓在了物理網(wǎng)卡上而流量走的是回環(huán)。解決是先確認(rèn)流量路徑回環(huán)流量必須在回環(huán)接口上抓Linux 上是lo部分系統(tǒng)需要顯式選擇回環(huán)適配器實在不確定就用不帶接口限制的方式先抓幾秒看看有沒有包再收窄。第三條服務(wù)端重啟時報 Address already in use。現(xiàn)象是第一次跑正常Ctrl-C 之后立刻重跑就綁不上端口。原因是上一個進(jìn)程的套接字還在 TIME_WAIT 狀態(tài)占著四元組。解決辦法是給監(jiān)聽套接字加上SO_REUSEADDR同時在調(diào)試階段用ss -lntp或lsof -i :9000確認(rèn)端口上到底還掛著哪個進(jìn)程別急著重啟機(jī)器。第四條GBN 窗口設(shè)成序列號空間大小出現(xiàn)“幽靈幀”?，F(xiàn)象是全部確認(rèn)都收到了接收端卻把新數(shù)據(jù)當(dāng)成重復(fù)幀丟掉或者把重傳當(dāng)成新數(shù)據(jù)收下。原因是窗口取到了2^k新老幀的序號完全重合接收方無從區(qū)分。解決是嚴(yán)格按W ≤ 2^k ? 1取值并且在報告里把這個約束的推導(dǎo)寫出來而不是只寫一個數(shù)字。第五條吞吐量算錯數(shù)字大得離譜?，F(xiàn)象是報告里算出幾百 Mbps和實驗環(huán)境明顯不符。原因通常有兩個把 RTT 當(dāng)成單程時延代進(jìn)公式或者把“窗口大小”直接當(dāng)成“帶寬”。解決是統(tǒng)一用“傳輸字節(jié)數(shù) / 起止時間差”來算起止時間取同一份抓包里的frame.time_relative并在報告里注明時間戳來自哪一端、是否包含握手階段。6. 把實驗變成可復(fù)現(xiàn)的驗收腳本一份 40 行的 run_all.sh 與判定閾值表做到前面幾章每項實驗單獨(dú)跑都沒問題但交報告前還要把這些步驟重新走一遍截圖這個過程很容易漏步驟、也容易在不同時間點跑出不一致的結(jié)果。我后來的習(xí)慣是把所有能自動化的部分收進(jìn)一個腳本跑一次生成全部證據(jù)文件報告里只引用文件名。這樣即使隔兩周再改報告數(shù)據(jù)也是同一批。下面這份腳本的順序是有講究的先起后臺抓包再起被測服務(wù)然后造流量最后等抓包自然結(jié)束再導(dǎo)出。順序錯了會抓到空文件。#!/usr/bin/env bash set -euo pipefail OUTevidence mkdir -p $OUT # 1) 后臺抓包20 秒后自動停止落盤 tshark -i lo -f tcp port 8080 -w $OUT/http.pcap -a duration:20 CAP$! # 2) 起被測服務(wù) python3 http_echo.py SRV$! trap kill $SRV $CAP 2/dev/null || true EXIT sleep 1 # 3) 造三條可數(shù)的請求 for i in 1 2 3; do curl -s -o /dev/null http://127.0.0.1:8080/item$i done # 4) 等抓包進(jìn)程結(jié)束再導(dǎo)出字段表 wait $CAP tshark -r $OUT/http.pcap -Y http.request -T fields \ -e frame.number -e frame.time_relative -e ip.src -e tcp.srcport -e http.request.uri \ -E headery -E separator, $OUT/http_requests.csv echo done: $OUT/http_requests.csvset -euo pipefail讓腳本在任一命令失敗時立刻退出避免“前半段失敗后半段還在跑”產(chǎn)生看起來正常實則缺數(shù)據(jù)的文件。trap保證異常退出時后臺進(jìn)程被清理否則下一次跑會撞上端口占用。wait $CAP是這份腳本里最關(guān)鍵的一行-a duration:20到點后抓包進(jìn)程才把緩沖區(qū)刷進(jìn)文件如果不 wait 就直接讀很可能讀到一個還沒寫完的 pcap。配合腳本我在報告里會放一張判定閾值表把“什么樣算通過”寫死避免自評時含糊實驗項驗收命令期望輸出判定閾值HTTP 請求數(shù)wc -l evidence/http_requests.csv表頭 3 行恰好 4 行三次握手完整tshark -r evidence/http.pcap -Y tcp.flags.syn1 -T fields -e frame.number | wc -l含 SYN 與 SYN-ACK≥ 2并發(fā)回顯python3 stress.pysuccess200/200成功率 100%GBN 重傳次數(shù)python3 gbn_simulate.py隨丟包率單調(diào)上升0.15 時 0.0 時的 2 倍閾值這一列是給自己看的也是給別人復(fù)現(xiàn)時對答案的。比如“0.15 丟包率下的發(fā)送次數(shù)要超過無丟包時的兩倍”這個數(shù)不是拍腦袋是前面模擬跑出來的一旦某次重跑沒達(dá)到說明代碼或參數(shù)被改過能第一時間發(fā)現(xiàn)。最后說一個我自己的習(xí)慣。每次交報告前我會把整個目錄復(fù)制到另一個路徑刪掉所有中間文件只保留腳本和源文件然后從頭跑一遍bash run_all.sh。如果它能在一臺“干凈”的目錄里重新生成全部證據(jù)文件這份報告才算真的可復(fù)現(xiàn)跑不出來問題一定在我自己寫的某一行命令里而不是在評審那邊。這個動作花不了五分鐘但省下來的返工時間遠(yuǎn)不止五分鐘。希望幫到你。本文還有配套的精品資源點擊獲取