wireshark應(yīng)用層抓包分析.doc

資料收集于網(wǎng)絡(luò) 如有侵權(quán)請聯(lián)系網(wǎng)站 刪除 謝謝 Wireshark抓包分析CONTENT引言1 利用wireshark抓取網(wǎng)頁服務(wù)協(xié)議并分析 1.1 HTTP協(xié)議報文結(jié)構(gòu)及分析 1.2 HTTPS是什么 1.3 HTTP與HTTPS的比較 1.4分別在網(wǎng)絡(luò)空閑與網(wǎng)絡(luò)繁忙時比較相關(guān)報文傳送的區(qū)別2 利用wireshark抓取郵件傳輸協(xié)議并分析 2.1 SMTP郵件發(fā)送協(xié)議的結(jié)構(gòu) 2.2 POP3與IMAP協(xié)議結(jié)構(gòu)的區(qū)別 2.3網(wǎng)頁版收發(fā)郵件與郵件客戶端收發(fā)時使用協(xié)議的比較3 利用wireshark抓取ftp文件傳輸協(xié)議 3.1 ftp協(xié)議的格式及特點(diǎn)分析4 分析DNS的解析過程4.1“”域名解析實例分析4.2“”域名解析實例分析Ps：之前在寫目錄的時候覺得這樣來分析分析會對應(yīng)用層協(xié)議的理解更加全面一點(diǎn)，但是基于各種原因只是完成了黑色字體部分，而且還可能存在很多錯誤。有機(jī)會可以進(jìn)一步完善。引言 經(jīng)過計算機(jī)網(wǎng)絡(luò)基礎(chǔ)前面時間的學(xué)習(xí)，使我們對網(wǎng)絡(luò)應(yīng)用層的協(xié)議有了一定的了解。協(xié)議就像一門語言，需要定義語法、語意和語序（時序、同步）。語法即為協(xié)議的具體格式；語意定義了具體格式中具體指代，比如說，空一行后的數(shù)據(jù)表示為數(shù)據(jù)字段；就目前說掌握的只是而言，我對語序的理解還不是很清楚，這里就不加贅述。 下面將主要從應(yīng)用層的協(xié)議出發(fā)，利用我們所學(xué)習(xí)過的知識，對不同的應(yīng)用請求響應(yīng)過程進(jìn)行分析，探究在不同網(wǎng)絡(luò)工作環(huán)境下網(wǎng)絡(luò)協(xié)議的變化。本次抓包分析的環(huán)境為IE9瀏覽器，使用wireshark的版本為32位第1.4.9版。1 利用wireshark抓取網(wǎng)頁服務(wù)協(xié)議并分析1.1 HTTP協(xié)議報文結(jié)構(gòu)及分析 首先清空IE瀏覽器的緩存、cookie等信息，并運(yùn)行wireshark。輸入“”后得到抓包文件如圖1所示。圖1“”后得到抓包數(shù)據(jù) 第1行的SSDP協(xié)議也是應(yīng)用層的協(xié)議，大致意思就是用來申明自己的存在。從在No.14時用戶向服務(wù)器（web緩存）發(fā)起360云盤的網(wǎng)頁請求。在No.25時用戶想360云盤的服務(wù)器直接發(fā)起請求，說明在此之前web緩存已將360云盤服務(wù)器的地址信息轉(zhuǎn)發(fā)給用戶。同時此后的通信雙方為用戶與360云盤服務(wù)器，并沒有經(jīng)過web緩存，說明實際web緩存的作用并不像我們所學(xué)習(xí)的那樣web緩存要緩存小區(qū)域內(nèi)說用用戶請求過的網(wǎng)頁文件，并在超時時才給以刪除。在No.25時，用戶向服務(wù)器發(fā)起網(wǎng)頁請求，同時在No.32時服務(wù)器向用戶返回請求的信息（html）即基本的網(wǎng)頁文件。此后，用戶發(fā)應(yīng)用文件的申請。No.34、35中用戶發(fā)起的申請并為按照次序返回給用戶，而是No.35的請求先到達(dá)，No.34后到，但是用戶卻沒有再次發(fā)出請求報文，說明定時器還沒有超時，并且兩個響應(yīng)報文可能走了不同的路由路徑。圖2 TCP out-of-order 在No.135時，出現(xiàn)了陌生地址發(fā)送來的HTTP報文，該報文采用的是HTTP1.0協(xié)議，可見HTTP1.0與HTTP1.1監(jiān)聽的端口都是80。HTTP報文的傳輸層協(xié)議是TCP協(xié)議，采用IP地址以及端口號同時建立一對一的連接關(guān)系，接收到陌生地址報文的原因或許是360云盤的網(wǎng)頁上引用了其他服務(wù)器的信息。但更多的可能是報文地址出錯，錯發(fā)到這里了。圖3 同樣也是第三方的服務(wù)器地址 No.364時，又是出現(xiàn)了第三方的服務(wù)器地址，并沒有出現(xiàn)圖2中TCP亂序的說法，因此此處的第三方服務(wù)器更像是360云盤網(wǎng)頁上引用的其他服務(wù)器的信息。1.2 HTTPS協(xié)議報文結(jié)構(gòu)及分析 當(dāng)我們在使用網(wǎng)盤的時候，比如說酷盤，不難發(fā)現(xiàn)它使用的URL是以https開頭的協(xié)議而不是我們所熟知的http協(xié)議。想必這二者之間必定存在一定聯(lián)系，但是又有一定區(qū)別。下面就利用wireshark抓的酷盤登陸時的數(shù)據(jù)包來探究上述二者的異同。 百度百科中對HTTPS即安全超文本傳輸協(xié)議是：HTTPS又稱S-HTTP是一種結(jié)合HTTP而設(shè)計的消息的安全通信協(xié)議。S-HTTP協(xié)議為HTTP客戶機(jī)和服務(wù)器提供了多種安全機(jī)制，這些安全服務(wù)選項是適用于Web上各類用戶的。還為客戶機(jī)和服務(wù)器提供了對稱能力，同時維持HTTP的通信模型和實施特征。 S-HTTP不需要客戶方的公用密鑰證明，但它支持對稱密鑰的操作模式。這意味著在沒有要求用戶個人建立公用密鑰的情況下，會自發(fā)地發(fā)生私人交易。它支持端對端安全傳輸，客戶機(jī)可能首先啟動安全傳輸（使用報頭的信息），用來支持加密技術(shù)。 faith n. 信任；信心；信念在語法上，S-HTTP報文與HTTP相同，由請求行或狀態(tài)行組成，后面是信頭和主體。請求報文的格式由請求行、通用信息頭、請求頭、實體頭、信息主體組成。相應(yīng)報文由響應(yīng)行、通用信息頭、響應(yīng)頭、實體頭、信息主體組成。 以上解釋并沒有十分透徹的說明HTTP與HTTPS到底有沒有關(guān)系，如果有又是什么關(guān)系。下面直接通過酷盤網(wǎng)頁登錄的數(shù)據(jù)包情況直接分析，看是否能夠?qū)TTPS有所了解。圖4 酷盤/登錄的部分?jǐn)?shù)據(jù)報 從圖4不難發(fā)現(xiàn)，酷盤/的響應(yīng)報文與之前想象的幾乎沒有相似之處。此前認(rèn)為https協(xié)議仍是類似于http協(xié)議一樣的網(wǎng)頁文件傳輸協(xié)議。但是從抓包的結(jié)果來看，太令人失望了，在數(shù)據(jù)包的前段部分我們沒有看見一點(diǎn)網(wǎng)頁文件的影子，取而代之的是一大片TCP協(xié)議建立連接的請求與響應(yīng)報文。還算令人欣慰的是，在No.11、13、17、18的TCP報文后出現(xiàn)了https字樣。由此可以基本推測出來HTTPS并不是應(yīng)用層的協(xié)議，而是傳輸層，可能是TCP向上到HTTP協(xié)議的一個有點(diǎn)類似于套接字的某個東西。令我很不解的一點(diǎn)就是，原本請求的是一個網(wǎng)頁文件，但是抓到的數(shù)據(jù)包中沒有網(wǎng)頁文件的請求以及相應(yīng)報文，全部是TCP、TLSv1、DNS以及SSDP協(xié)議。1.3 HTTP與HTTPS的比較 與沒有看過數(shù)據(jù)包之前的想法大相徑庭，HTTPS并不是應(yīng)用層協(xié)議，與HTTP也沒有什么直接的關(guān)系。百度上所說的S-HPPT為HTTP提供安全的運(yùn)行環(huán)境，估計就是從傳輸層的角度出發(fā)來講的，即提供更為可靠的傳輸層向上的借口。 實踐告訴我們并不能想當(dāng)然的認(rèn)為一個命題成立，必須經(jīng)過有理有據(jù)才能下推斷。猜想是可以的，但是必須驗證。就像HTTPS與HTTP一樣，要不然到現(xiàn)在仍然會認(rèn)為HTTPS與HTTP必然有某種聯(lián)系。1.4分別在網(wǎng)絡(luò)空閑與網(wǎng)絡(luò)繁忙時比較相關(guān)報文傳送的區(qū)別圖5 網(wǎng)絡(luò)繁忙時的響應(yīng)以及請求報文圖6 網(wǎng)絡(luò)空閑時的響應(yīng)以及請求報文 圖5中No.467、469、476的報文都出現(xiàn)了丟包現(xiàn)象，而圖6中的報文接收與請求都十分流暢。 綜上，通過對HTTP網(wǎng)頁請求服務(wù)抓包信息的觀察以及分析以后，了解了HTTP請求以及相應(yīng)報文的基本信息，以及WEB緩存的實際作用。同時也明白了報文的層次包裹結(jié)構(gòu)。4 分析DNS的解析過程4.1“”域名解析實例分析圖7“”域名解析 從No.6開始用戶向服務(wù)器web緩存發(fā)起域名解析請求，不清楚為什么是google的域名開始。但是服務(wù)器向用戶返回一個地址后，用戶后面域名解析的請求直接向該地址的服務(wù)器發(fā)起。在No.42時，用戶輸入的請求，服務(wù)器直接響應(yīng)了地址給用戶。由此可見用戶到服務(wù)器的地址查詢請求的算法為循環(huán)算法，而服務(wù)器向上解析的過程采用何種算法在這里我們就不得而知了。 上述的域名解析是關(guān)于國內(nèi)的一個網(wǎng)址進(jìn)行的，那么對于國外網(wǎng)址的解析又會有什么不同？下面就應(yīng)用wireshark對喬治亞理工學(xué)院網(wǎng)址解析時的抓包數(shù)據(jù)進(jìn)行分析。4.2“”域名解析實例分析圖8“”域名解析 與圖7中的信息類似，用戶首先向IP為51的服務(wù)器發(fā)起域名解析請求，大約一個單位時間過后用戶又向IP為9的服務(wù)器發(fā)起域名解析請求。一定時間過后，兩個服務(wù)器都返回了相同的IP地址給用戶。就用戶發(fā)起請求后的等待響應(yīng)的時間來看，IP為9的服務(wù)器能夠更快的響應(yīng)用戶。圖7中可以看出在用戶與IP為9的服務(wù)器建立連接后，用戶的域名解析請求全部又該服務(wù)器完成，IP為51的服務(wù)器不在參與與用戶之間的通信。然而圖8中可以看出，兩個域名解析服務(wù)器均在于用戶通信，并且通信的主體服務(wù)器為IP為51的服務(wù)器。那么學(xué)校為什么要用兩臺服務(wù)器完成域名解析的功能？ 結(jié)合前面HTTP網(wǎng)頁文件請求的直接相應(yīng)服務(wù)器與域名解析的直接響應(yīng)服務(wù)器IP地