計算機網絡實驗報告一(例文)含五篇-資料下載頁

　　

【正文】 outer1和 PC2的下一個事件，單擊其彩色正方形。這分別是第一條 ICMP超時錯誤報告報文和應答報告報文。單擊 InboundPDUDetails 查看 ICMP 報文的內容。 traert 命令中，為什么源主機對于每個 TTL值都要重復進行多次探測？ Inter帶來安全隱患？ 41 運輸層端口觀察實驗 實驗目的： 了解端口號的劃分和分配。實驗步驟： 任務一：通過捕獲的 DNS事件查看并分析 UDP 的端口號 步驟 1：捕獲 DNS事件 步驟 2：查看并分析 UDP用戶數據報中的端口號 步驟 3：分析端口號的變化規律 重新回到 PC 機的瀏覽器窗口單擊 Go（轉到）按鈕再次請求相同的網頁，從新捕獲的 DNS 事件中觀察 DNS 客戶端與 DNS 服務器端的端口號是否發生變化。如果沒有，分析其原因；如果有，分析其變化的規律。 PC 端的端口發生了改變，而服務器的端口號沒有改變。服務器的端口號是固定的，而客戶端的端口不固定。 任務二：通過捕獲的 HTTP事件查看并分析 TCP的端口號 步驟 1：捕獲 HTTP事件 步驟 2：查看并分析 TCP報文中的端口號 PC 端的端口號是 1028，服務器端的端口號是 80. 任務三：分析運輸層端口號 步驟 1：分析運輸層端口號與應用進程之間的關系 不一樣，任務一服務器端口號是 53，任務二中是 80. 步驟 2：分析運輸層動態端口號的分配規律 前后兩次客戶端的端口號都改變了，而服務器的端口號沒有改變。思考： 運輸層如何區分應用層的不同進程？通過數據包的源端口號。 若使用 ResetSimulation（重置模擬）按鈕后再重新進行捕獲，端口號如何變化？新的值與重置前有關嗎？端口號會改變，和之前的沒有關系。 42UDP協議與 TCP 協議的對比分析 實驗目的： 熟 悉 UDP與 TCP 理解 UDP的無連接通信與 TCP 熟悉 TCP報文段和 UDP報文的數據封裝格式。實驗步驟： 任務一：觀察 UDP無連接的工作模式 步驟 1：捕獲 UDP事件 步驟 2：分析 UDP無連接的工作過程 沒有建立連接，直接由服務器發送數據包過來。 LENGTH長為 35。首部占用 8字節，數據部分為 23 任務二：觀察 TCP面向連接的工作模式 步驟 1：捕獲 TCP事件 步驟 2：分析 TCP面向連接的工作過程 在捕獲到的第一個 HTTP 事件之前及最后一個 HTTP 事件之后是否有 TCP 事件；都有 TCP事件。 第一個以 及最后一 個 HTTP 事 件對應 的 TCP 報文 中的sequencenumber（序號）、 ACKnumber（確認號）的值以及它們與datalength（數據長度）的關系； sequencenumber（序號）、 ACKnumber（確認號）的值兩次的都不一樣。 datalangth都是 20。 思考： TCP 報文首部中的序號和確認號有什么作用？ 序號是：當前所攜帶的數據的第一個字節的順序號（如：本次連接共要發送 1000個字節，已發出了 100個字節，現在發送下一個報文，假設每個報文攜帶的數據為 100 字節，則這個報文的頭結構中的序號是 100【注：從 0開始編號】）。 確認序號是：接收端期望接收的下一個報文的序號，如上例中那個報文已被正確 接收，則接收端會發送一個 ACK=1 且確認序號 =200 的 無連接的 UDP和面向連接的 TCP各有什么優缺點？ TCP 面向連接（如打電話要先撥號建立連接） 。UDP 是無連接的，即發送數據之前不需要建立連接 TCP 提供可靠的服務。也就是說，通過 TCP 連接傳送的數據，無差錯，不丟失，不重復，且按序到達 。UDP 盡最大努力交付，即不保證可靠交付 TCP 面向字節流，實際上是 TCP把數據看成一連串無結構的字節流 。UDP是面向報文的 UDP 沒有擁塞控制，因此 網絡出現擁塞不會使源主機的發送速率降低（對實時應用很有用，如 IP電話，實時視頻會議等） 每一條 TCP 連接只能是點到點的 。UDP 支持一對一，一對多，多對一和多對多的交互通信 TCP首部開銷 20字節 。UDP的首部開銷小，只有 8個字節 TCP 的邏輯通信信道是全雙工的可靠信道， UDP 則是不可靠信道 43TCP的連接管理 實驗目的： 熟悉 TCP通信的三個階段； 理解 TCP連接建立過程和 TCP連接釋放過程。實驗步驟： 任務一：捕獲 TCP事件 任務二：分析 TCP連接建立階段的三次握手 任務三：分析 TCP連接釋放階段的四次握手 、 思考： 連接建立階段的第一次握手是否需要消耗一個序號？其 SYN 報文段是否攜帶數據？為什么？第二次握手呢？ 第一次要消耗一個序號， SYN沒有攜帶數據。因為 TCP規定， SYN不能攜帶數據。第二次握手，也需要消耗一個序號，同樣也不能攜帶信息。 本實驗中連接釋放過程的第 二、三次握手是同時進行的還是分開進行的？這兩次握手何時需要分開進行？ 是同時進行的，當雙方均有數據需要發送時，而只有一方數據發送完畢而關閉單方向的 TCP連接時，第二第三次握手才需要分開進行。 本實驗中連接釋放階段的第四次握手， PC 向 Server 發送最后一個 TCP 確認報文段后，為什么不是直接進入 CLOSED（已關閉）連接狀態，而是進入 CLOSING（正在關閉）連接狀態？ 因為此時 PC 還需要進入 TIMEWAIT 狀態，以保證 PC 發送的最后一個 ACK 保溫能夠到達 Server，同時還可以防止失效的連接請求報文 本實驗中 TCP 連接建立后的數據通信階段， PC 向 Server 發送的了多少數據？ Server向 PC 發送的數據呢？ PC向 Server發送了 107B數據， Server向 PC發送了 333B的數據。 51DNS解析實驗實驗目的： 理解 DNS 熟悉 DNS 熟悉 DNS 理解 DNS緩存的作用。實驗步驟： 任務一：觀察本地域名解 析過程 步驟 1：在 PC 的瀏覽器窗口請求內部 Web服務器的網頁 步驟 2：捕獲 DNS事件并分析本地域名解析過程 任務二：觀察外網域名解析過程 步驟 1：在 PC 的瀏覽器窗口請求外部 Web服務器的網頁 步驟 2：捕獲 DNS事件并分析外網域名解析過程 任務三：觀察緩存的作用 步驟 1：查看本地域名服務器 _dns的緩存 步驟 2：在 PC 的瀏覽器窗口請求外部 Web服務器的網頁 思考： DNS 協議使用運輸層的什么協議？ UDP 協議 DNS 緩存有什么作用？在 PacketTracer中如何清空 DNS緩存？ DNS 緩存用來存放最近解析過的域名等信息，因此可以提高解析效率。若需要在 PacketTracer 中清空某個 DNS 服務器的緩存，可以進入該 DNS服務器的配置窗口，單擊窗口下方的 DNSCache按鈕，在彈出的窗口中單擊下方的 ClearCache按鈕即可把 DNS緩存 清空。 本實驗中 PC 與本地域名服務器 _dns 之間的解析是遞歸還是迭代？本地域名服務器 _dns 與根域名服務器 root_dns 之間呢？若后者用另一種解析方法，則域名服務器之間 DNS 的請求和應答的交互過程應如何？ 本實驗中 PC 與本地域名服務器 _dns 之間的解析是遞歸查詢，本地域名服務器 _dns與根域名服務器 root_dns之間也是遞歸查詢。若后者用的是迭代查詢，則當 _dns 向根域名服務器 root_dns 請求解析而 root_dns無法解析出結果時，不是由 root_dns全權幫助 _dns直接解析出結果并將解析結果告知 _dns 而是 root_dns 會告訴_dns應該向哪一個域名服務器進行查詢，剩下的解析由 _dns自己進行。 52DHCP分析 實驗目的： 了解 DHCP 熟悉 DHCP 熟悉 DHCP的報文格式。實驗步驟： 任務一： DHCP服務器為內網主機 PC1 動態分配 IP 地址 步驟 1：捕獲 DHCP事件 步驟 2：分析 DHCP的工作過程及報文格式 分析 DHCP協議的工作過程； DHCP 客戶端發送 Discover包 PC0 接收 DHCP發來的 DHCPofferpacket DHCP服務器接收到來自 PC0的 DHCPrequestedpacket PC0 接收 DHCP發來的 DHCPACKpacket 回到靜態配置 IP 狀態 PC給 DHCP發送 releasepacket DHCP報文類型；是 UDP報文類型 丟棄路由器 Router1對 DHCP報文的處理方式； 判斷 DHCP 報文的發送方式（單播 /廣播）；廣播的形式，交換機將數據包轉發給了所有連接的主機 DHCP報文格式中各字段的值及其含義； PC1 分配到的 IP地址。最后 IP 為 任務二： DHCP服務器為外網主機 PC2 動態分配 IP 地址 步驟 1：捕獲 DHCP事件 步驟 2：配置 DHCP中繼后重新捕獲 DHCP 步驟 3：分析 DHCP PC2 分配到的 IP地址。 完成后單擊 ResetSimulation（重置模擬）按鈕，將原有的事件全部清空；同時關閉 PC1 的配置窗口。 思考： 如何判斷報文的發送方式是單播還是廣播？查看報文的目的 IP地址。 任務二中為何需要在路由器 Router2 中配置 DHCP 中繼？ DHCP 中 分析 DHCP服務器在分配 IP 地址時的規律。 若有多個 DHCP 服務器， DHCP 協議的工作過程會有變化嗎？為什么？ 53HTTP分析 實驗目的： 熟悉 HTTP 理解 HTTP報文的封裝格式。實驗步驟： 任務一： PC請求較小的頁面文檔 步驟 1：捕獲 PC與 Web1之間的 HTTP 事件 步驟 2：理解 HTTP協議的工作過程并分析 HTTP報文格式 任務二： PC請求較大的頁面文檔并與任務一對比 步驟 1：捕獲 PC與 Web2之間的 HTTP 事件 步驟 2：與任務一進行對比 本任務中 PC 請求的頁面文檔長度比任務一中更大， Web2 回發的HTTP 響應報文中需要使用多個 TCP報文段。 思考： HTTP響應報文使用的 TCP報文段的個數由什么值決定？該值在什么時候確定？本實驗中該值為多少？ HTTP 響應報文使用的 TCP 報文段的個數由 MSS 決定，該值在 TCP連接建立階段確定。本實驗中該值在 TCP連接建立階段確定為 536B。 若 PC 請求的頁面文檔長度超過 66000 字節， HTTP 的整個通信過程如何？ 若在 PC 的 Web 瀏覽器中輸入的域名有誤，是否能捕獲到 HTTP 事件？為什么？ 若在 PC 的 Web 瀏覽器中輸入的域名有誤，將無法捕獲到 HTTP