計算機網絡自頂向下方法 第三章 Wireshark實驗：探究TCP 答案

https://github.com/jzplp/Computer-Network-A-Top-Down-Approach-Answer

Wireshark實驗：探究TCP

• 官方文檔 第六版 第七版 第七版翻譯
• Wireshark_TCP 實驗答案

1.捕獲從計算機到遠程服務器的批量TCP傳輸

• 實驗圖像 

下面題目中如沒有特別指明，就根據要求使用下載的Wireshark捕獲的數據包文件tcp-ethereal-trace-1

2.初步瞭解捕獲的軌跡

1. 源IP地址爲 192.168.1.102 TCP源端口號爲1161

2. gaia.cs.umass.edu 的IP地址是128.119.245.12，在端口號80上發送和接收此連接。

3. 客戶端使用的IP地址爲 192.168.2.239 ，端口號爲8436

3.TCP基礎

1. 序列號Seq = 0。SYN報文負責建立連接，選擇客戶端初始的序列號

2. 序列號Seq = 0。 Acknowledgment欄位的值是1。將SYN中的Seq值加1。確認客戶端的連接，選擇服務器端初始的序列號

3. 序列號Seq = 1。

4. 前六個TCP報文的具體信息：

計數	序列號	發送時間	ACK時間	RTT值	EstimatedRTT值
1	1	0.026477	0.053937	0.02746‬	0.02746
2	566	0.041737	0.077294	0.035557‬	0.028472125
3	2026	0.054026	0.124085	0.070059‬‬	0.033670484375
4	3486	0.054690	0.169118	0.114428‬‬	0.043765173828125
5	4946	0.077405	0.217299	0.139894‬‬	0.05578127709960937
6	6406	0.078157	0.267802	0.189645‬‬	0.07251424246215821

1. 前6個TCP報文的長度分別爲：565，1460，1460，1460，1460，1460

2. 接收窗口最小爲5840。缺少接收窗口會限制發送方發送TCP報文，但包中實際的接收窗口遠大於發送的報文數量，因此不會限制

3. 使用ip.src==192.168.1.102查看客戶端發出的所有報文，發現序列號一直在增加，因此沒有重傳報文。

4. 觀察了一些報文，發現是接收方收到一個報文即發送一個ACK，沒有報多個確認合併。

5. WireShark輸出的吞吐量折線：
   
   吞吐量的實際計算：每秒收到的字節數

4.TCP擁塞控制

1. 從圖中我看不出來，感覺好像0-0.3s像是慢啓動階段，後面是擁塞避免階段，但是又不太像。

2. 我自己捕獲的報文的時序圖 
   從這個圖中，更看不出來了。