第三次實驗報告：使用Packet Tracer分析TCP鏈接創建過程

1.我的信息

• 陳韻
• 201821121053
• 計算1812

2.實驗目的

• 使用路由器鏈接不一樣的網絡
• 使用命令行操做路由器
• 經過抓取HTTP報文，分析TCP鏈接創建的過程

3.實驗內容

使用Packet Tracer，正確配置網絡參數，經過抓取HTTP數據包，分析TCP鏈接創建過程。

• 創建網絡拓撲結構
• 配置參數
• 抓包
• 分析數據包

4. 實驗報告

4.1 創建網絡拓撲結構

　　　

4.2 配置參數

4.2.1 配置客戶端

　　客戶端的參數配置以下：

　　

4.2.2 配置服務端

　　服務端的參數配置以下：

　　

 

 

4.2.3 配置路由器

　　(1)激活路由器

　　

 

 

　　解釋： 　　

　　Router>enable # 進入特權執行模式 

　　Router#configure terminal # 進入全局配置模式 

　　Router(config)# no ip domain-lookup # 禁用DNS查找

　　Router(config)#hostname R # 將路由器名稱配置爲R 

 

　　(2)配置端口 Fa0/0與Fa0/1

 　　

 

 

 　　解釋：

　　R(config)#interface Fa0/0 

　　R(config-if)#ip address 192.168.1.80 255.255.255.0 

　　R(config-if)#no shutdown # 激活接口 

 

　　(3)配置路由器協議

　　

 

 

 　　解釋：　

　　R(config)#router rip                  　　　　 # 進入配置路由協議的模式

　　R(config-router)#version 2         　  　　 # 使用rip2版本

　　R(config-router)#no auto-summary　　  # 關閉自動路由總結

　　R(config-router)#network 192.168.1.0　 # 設置參與配置協議的網絡地址

 

　　(4)查看是否配置完成

　　

 

 

 

4.3 抓包，分析TCP鏈接創建過程

4.3.1用客戶端的Web Browser訪問服務器：

 

 

4.3.2 仿真界面完成抓包

　　　

 

 

 　　

 

 

4.3.3畫出TCP鏈接創建示意圖

 

4.3.4分析序列號和確認號的變化

 　   （1）第一次握手:Client將標誌位SYN置爲1，隨機產生一個序列號值seq=x，並將該數據包發送給Serve，PC進入SYN_SENT狀態，等待Serve確認

　　（2）第二次握手:Serve收到數據包後由標誌位SYN=1知道Client請求創建鏈接，Serve將標誌位SYN和ACK都置爲1，ack=x+1，隨機產生一個值seq=y，並將該數據包發送給Client以確認鏈接請求，Server進入SYN_RCVD狀態。

　　（3）第三次握手:Client收到確認後，檢查ack是否爲x+1，ACK是否爲1，若是正確則將標誌位ACK置爲1，ack=y+1，並將該數據包發送給Server，Server檢查ack是否爲y+1，ACK是否爲1，若是正確則鏈接創建成功，Client和Server進入ESTABLISHED狀態，完成三次握手，隨後Client與Server之間能夠開始傳輸數據了。

4.3.5解答：爲何鏈接創建須要第三次握手

　　3次握手完成兩個重要的功能，既要雙方作好發送數據的準備工做，也要容許雙方就初始序列號進行協商，這個序列號在握手過程當中被髮送和確認。目的是爲了解決網絡中存在延遲的重複分組問題。

　　只有2 次握手極可能形成「死鎖」：假定C給S發送一個鏈接請求分組，S收到了這個分組，併發 送了確認應答分組。按照兩次握手的協定，S認爲鏈接已經成功地創建了，能夠開始發送數據分組。但是，C在S的應答分組在傳輸中被丟失的狀況下，將不知道S 是否已準備好，不知道S創建什麼樣的序列號，C甚至懷疑S是否收到本身的鏈接請求分組。在這種狀況下，C認爲鏈接還未創建成功，將忽略S發來的任何數據分 組，只等待鏈接確認應答分組。而S在發出的分組超時後，重複發送一樣的分組。致使死鎖的形成。

5. 拓展

（1）分析TCP鏈接釋放

 

（2）圖爲何會跟課本不同

　　在半關閉狀態，服務器極可能又發送了一些數據。而客戶端收到服務器的鏈接釋放報文後，必須發出確認。此時的TCP鏈接尚未釋放。

（3）爲何須要第四次握手 

　　關閉鏈接時，當Server端收到FIN報文時，極可能並不會當即關閉SOCKET，因此只能先回復一個ACK報文，告訴Client端，"你發的FIN報文我收到了"。只有等到我Server端全部的報文都發送完了，我才能發送FIN報文，所以不能一塊兒發送。故須要四步握手。

 （4）疑問

若是鏈接已經創建，但客戶端忽然出現故障的話，服務端會立刻終止交易仍是傻傻等下去？又或者機制比較聰明先試探一下確認客戶端真的崩潰後才斷開鏈接？？