wireshark應(yīng)用層抓包分析報(bào)告模版

1、 . . 7/7Wireshark抓包分析CONTENT引言1 利用wireshark抓取網(wǎng)頁服務(wù)協(xié)議并分析 1.1 協(xié)議報(bào)文結(jié)構(gòu)與分析 1.2 S是什么 1.3 與 S的比較 1.4分別在網(wǎng)絡(luò)空閑與網(wǎng)絡(luò)繁忙時(shí)比較相關(guān)報(bào)文傳送的區(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ā)時(shí)使用協(xié)議的比較3 利用wireshark抓取ftp文件傳輸協(xié)議 3.1 ftp協(xié)議的格式與特點(diǎn)分析4 分析DNS的解析過程4.1“.hzbook.”域名解析實(shí)例分析4.2“.”域名解析實(shí)例分析Ps：之前在寫目錄的時(shí)候覺得

2、這樣來分析分析會(huì)對(duì)應(yīng)用層協(xié)議的理解更加全面一點(diǎn)，但是基于各種原因只是完成了黑色字體部分，而且還可能存在很多錯(cuò)誤。有機(jī)會(huì)可以進(jìn)一步完善。引言 經(jīng)過計(jì)算機(jī)網(wǎng)絡(luò)基礎(chǔ)前面時(shí)間的學(xué)習(xí)，使我們對(duì)網(wǎng)絡(luò)應(yīng)用層的協(xié)議有了一定的了解。協(xié)議就像一門語言，需要定義語法、語意和語序（時(shí)序、同步）。語法即為協(xié)議的具體格式；語意定義了具體格式中具體指代，比如說，空一行后的數(shù)據(jù)表示為數(shù)據(jù)字段；就目前說掌握的只是而言，我對(duì)語序的理解還不是很清楚，這里就不加贅述。 下面將主要從應(yīng)用層的協(xié)議出發(fā)，利用我們所學(xué)習(xí)過的知識(shí)，對(duì)不同的應(yīng)用請(qǐng)求響應(yīng)過程進(jìn)行分析，探究在不同網(wǎng)絡(luò)工作環(huán)境下網(wǎng)絡(luò)協(xié)議的變化。本次抓包分析的環(huán)境為IE9瀏覽器，使用

3、wireshark的版本為32位第1.4.9版。1 利用wireshark抓取網(wǎng)頁服務(wù)協(xié)議并分析1.1 協(xié)議報(bào)文結(jié)構(gòu)與分析 首先清空IE瀏覽器的緩存、cookie等信息，并運(yùn)行wireshark。輸入“”后得到抓包文件如圖1所示。圖1“”后得到抓包數(shù)據(jù)第1行的SSDP協(xié)議也是應(yīng)用層的協(xié)議，大致意思就是用來申明自己的存在。從在No.14時(shí)用戶向服務(wù)器（web緩存）發(fā)起360云盤的網(wǎng)頁請(qǐng)求。在No.25時(shí)用戶想360云盤的服務(wù)器直接發(fā)起請(qǐng)求，說明在此之前web緩存已將360云盤服務(wù)器的地址信息轉(zhuǎn)發(fā)給用戶。同時(shí)此后的通信雙方為用戶與360云盤服務(wù)器，并沒有經(jīng)過web緩存，說明實(shí)際web緩存的作用并不

4、像我們所學(xué)習(xí)的那樣web緩存要緩存小區(qū)域說用用戶請(qǐng)求過的網(wǎng)頁文件，并在超時(shí)時(shí)才給以刪除。在No.25時(shí)，用戶向服務(wù)器發(fā)起網(wǎng)頁請(qǐng)求，同時(shí)在No.32時(shí)服務(wù)器向用戶返回請(qǐng)求的信息（html）即基本的網(wǎng)頁文件。此后，用戶發(fā)應(yīng)用文件的申請(qǐng)。No.34、35中用戶發(fā)起的申請(qǐng)并為按照次序返回給用戶，而是No.35的請(qǐng)求先到達(dá)，No.34后到，但是用戶卻沒有再次發(fā)出請(qǐng)求報(bào)文，說明定時(shí)器還沒有超時(shí)，并且兩個(gè)響應(yīng)報(bào)文可能走了不同的路由路徑。圖2 TCP out-of-order 在No.135時(shí)，出現(xiàn)了陌生地址發(fā)送來的 報(bào)文，該報(bào)文采用的是 1.0協(xié)議，可見 1.0與 1.1監(jiān)聽的端口都是80。 報(bào)文的傳輸層協(xié)

5、議是TCP協(xié)議，采用IP地址以與端口號(hào)同時(shí)建立一對(duì)一的連接關(guān)系，接收到陌生地址報(bào)文的原因或許是360云盤的網(wǎng)頁上引用了其他服務(wù)器的信息。但更多的可能是報(bào)文地址出錯(cuò)，錯(cuò)發(fā)到這里了。圖3 同樣也是第三方的服務(wù)器地址No.364時(shí)，又是出現(xiàn)了第三方的服務(wù)器地址，并沒有出現(xiàn)圖2中TCP亂序的說法，因此此處的第三方服務(wù)器更像是360云盤網(wǎng)頁上引用的其他服務(wù)器的信息。1.2 S協(xié)議報(bào)文結(jié)構(gòu)與分析 當(dāng)我們?cè)谑褂镁W(wǎng)盤的時(shí)候，比如說酷盤，不難發(fā)現(xiàn)它使用的URL是以 s開頭的協(xié)議而不是我們所熟知的 協(xié)議。想必這二者之間必定存在一定聯(lián)系，但是又有一定區(qū)別。下面就利用wireshark抓的酷盤登陸時(shí)的數(shù)據(jù)包來探究上述

6、二者的異同。 百度百科中對(duì) S即安全超文本傳輸協(xié)議是： S又稱S- 是一種結(jié)合 而設(shè)計(jì)的消息的安全通信協(xié)議。S- 協(xié)議為 客戶機(jī)和服務(wù)器提供了多種安全機(jī)制，這些安全服務(wù)選項(xiàng)是適用于Web上各類用戶的。還為客戶機(jī)和服務(wù)器提供了對(duì)稱能力，同時(shí)維持 的通信模型和實(shí)施特征。 S- 不需要客戶方的公用密鑰證明，但它支持對(duì)稱密鑰的操作模式。這意味著在沒有要求用戶個(gè)人建立公用密鑰的情況下，會(huì)自發(fā)地發(fā)生私人交易。它支持端對(duì)端安全傳輸，客戶機(jī)可能首先啟動(dòng)安全傳輸（使用報(bào)頭的信息），用來支持加密技術(shù)。 在語法上，S- 報(bào)文與 一樣，由請(qǐng)求行或狀態(tài)行組成，后面是信頭和主體。請(qǐng)求報(bào)文的格式由請(qǐng)求行、通用信息頭、請(qǐng)求頭

7、、實(shí)體頭、信息主體組成。相應(yīng)報(bào)文由響應(yīng)行、通用信息頭、響應(yīng)頭、實(shí)體頭、信息主體組成。 以上解釋并沒有十分透徹的說明 與 S到底有沒有關(guān)系，如果有又是什么關(guān)系。下面直接通過酷盤網(wǎng)頁登錄的數(shù)據(jù)包情況直接分析，看是否能夠?qū)?S有所了解。圖4 酷盤 s:/.kanbox./登錄的部分?jǐn)?shù)據(jù)報(bào)從圖4不難發(fā)現(xiàn)，酷盤 s:/.kanbox./的響應(yīng)報(bào)文與之前想象的幾乎沒有相似之處。此前認(rèn)為 s協(xié)議仍是類似于 協(xié)議一樣的網(wǎng)頁文件傳輸協(xié)議。但是從抓包的結(jié)果來看，太令人失望了，在數(shù)據(jù)包的前段部分我們沒有看見一點(diǎn)網(wǎng)頁文件的影子，取而代之的是一大片TCP協(xié)議建立連接的請(qǐng)求與響應(yīng)報(bào)文。還算令人欣慰的是，在No.11、13

8、、17、18的TCP報(bào)文后出現(xiàn)了 s字樣。由此可以基本推測(cè)出來 S并不是應(yīng)用層的協(xié)議，而是傳輸層，可能是TCP向上到 協(xié)議的一個(gè)有點(diǎn)類似于套接字的某個(gè)東西。令我很不解的一點(diǎn)就是，原本請(qǐng)求的是一個(gè)網(wǎng)頁文件，但是抓到的數(shù)據(jù)包中沒有網(wǎng)頁文件的請(qǐng)求以與相應(yīng)報(bào)文，全部是TCP、TLSv1、DNS以與SSDP協(xié)議。1.3 與 S的比較與沒有看過數(shù)據(jù)包之前的想法大相徑庭， S并不是應(yīng)用層協(xié)議，與 也沒有什么直接的關(guān)系。百度上所說的S-HPPT為 提供安全的運(yùn)行環(huán)境，估計(jì)就是從傳輸層的角度出發(fā)來講的，即提供更為可靠的傳輸層向上的借口。 實(shí)踐告訴我們并不能想當(dāng)然的認(rèn)為一個(gè)命題成立，必須經(jīng)過有理有據(jù)才能下推斷。猜

9、想是可以的，但是必須驗(yàn)證。就像 S與 一樣，要不然到現(xiàn)在仍然會(huì)認(rèn)為 S與 必然有某種聯(lián)系。1.4分別在網(wǎng)絡(luò)空閑與網(wǎng)絡(luò)繁忙時(shí)比較相關(guān)報(bào)文傳送的區(qū)別圖5 網(wǎng)絡(luò)繁忙時(shí)的響應(yīng)以與請(qǐng)求報(bào)文圖6 網(wǎng)絡(luò)空閑時(shí)的響應(yīng)以與請(qǐng)求報(bào)文 圖5中No.467、469、476的報(bào)文都出現(xiàn)了丟包現(xiàn)象，而圖6中的報(bào)文接收與請(qǐng)求都十分流暢。 綜上，通過對(duì) 網(wǎng)頁請(qǐng)求服務(wù)抓包信息的觀察以與分析以后，了解了 請(qǐng)求以與相應(yīng)報(bào)文的基本信息，以與WEB緩存的實(shí)際作用。同時(shí)也明白了報(bào)文的層次包裹結(jié)構(gòu)。4 分析DNS的解析過程4.1“.hzbook.”域名解析實(shí)例分析圖7“.hzbook.”域名解析 從No.6開始用戶向服務(wù)器web緩存發(fā)起域

10、名解析請(qǐng)求，不清楚為什么是google的域名開始。但是服務(wù)器向用戶返回一個(gè)地址后，用戶后面域名解析的請(qǐng)求直接向該地址的服務(wù)器發(fā)起。在No.42時(shí)，用戶輸入 hzbook 的請(qǐng)求，服務(wù)器直接響應(yīng)了地址給用戶。由此可見用戶到服務(wù)器的地址查詢請(qǐng)求的算法為循環(huán)算法，而服務(wù)器向上解析的過程采用何種算法在這里我們就不得而知了。 上述的域名解析是關(guān)于國的一個(gè)網(wǎng)址進(jìn)行的，那么對(duì)于國外網(wǎng)址的解析又會(huì)有什么不同？下面就應(yīng)用wireshark對(duì)喬治亞理工學(xué)院網(wǎng)址解析時(shí)的抓包數(shù)據(jù)進(jìn)行分析。4.2“.”域名解析實(shí)例分析圖8“.”域名解析與圖7中的信息類似，用戶首先向IP為51的服務(wù)器發(fā)起域名解析請(qǐng)求，大約一個(gè)單位時(shí)間過

11、后用戶又向IP為9的服務(wù)器發(fā)起域名解析請(qǐng)求。一定時(shí)間過后，兩個(gè)服務(wù)器都返回了一樣的IP地址給用戶。就用戶發(fā)起請(qǐng)求后的等待響應(yīng)的時(shí)間來看，IP為9的服務(wù)器能夠更快的響應(yīng)用戶。圖7中可以看出在用戶與IP為9的服務(wù)器建立連接后，用戶的域名解析請(qǐng)求全部又該服務(wù)器完成，IP為51的服務(wù)器不在參與與用戶之間的通信。然而圖8中可以看出，兩個(gè)域名解析服務(wù)器均在于用戶通信，并且通信的主體服務(wù)器為IP為51的服務(wù)器。那么學(xué)校為什么要用兩臺(tái)服務(wù)器完成域名解析的功能？ 結(jié)合前面 網(wǎng)頁文件請(qǐng)求的直接相應(yīng)服務(wù)器與域名解析的直接響應(yīng)服務(wù)器IP地址的不同可以看出，二者不是同一服務(wù)器，也就是說，web緩存很可能只是起到中轉(zhuǎn)站的作用。從而web