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