wireshark應用層抓包分析.doc

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