網(wǎng)絡(luò)測(cè)試2版課件ch7

第7章應(yīng)用層測(cè)試和故障診斷7.1應(yīng)用層測(cè)試相關(guān)知識(shí)1．?dāng)?shù)據(jù)格式（1）原始數(shù)據(jù)原始數(shù)據(jù)即通過(guò)測(cè)試工具捕獲的網(wǎng)絡(luò)中實(shí)際傳送的數(shù)據(jù)分組，并存儲(chǔ)成專用的文件格式，如pcap或cap格式。（2）流格式數(shù)據(jù)借助于網(wǎng)絡(luò)設(shè)備，將數(shù)據(jù)分組形成流記錄，每條流記錄包含源地址或目標(biāo)地址、源端口號(hào)或目標(biāo)端口號(hào)、端口標(biāo)簽或時(shí)間標(biāo)簽等信息。網(wǎng)絡(luò)設(shè)備將流數(shù)據(jù)發(fā)送至專用分析測(cè)試平臺(tái)進(jìn)行數(shù)據(jù)存儲(chǔ)。流存儲(chǔ)節(jié)省了大量數(shù)據(jù)內(nèi)容信息，大大壓縮了原始數(shù)據(jù)量。2．應(yīng)用協(xié)議分析中的關(guān)鍵技術(shù)（1）捕包（2）線速存儲(chǔ)（3）海量存儲(chǔ)（4）流量分類（5）協(xié)議和應(yīng)用（6）異常事件的可視性（7）多級(jí)架構(gòu)（8）點(diǎn)對(duì)點(diǎn)方式3．常用應(yīng)用介紹（1）電子郵件1）SMTP三個(gè)基本路徑。①M(fèi)UA（MailUserAgent，郵件用戶代理）通過(guò)SMTP將郵件發(fā)送給本地MTA（MailTransferAgent，郵件傳輸代理）（位于郵件服務(wù)器中）。②本地MTA查詢所需投遞域名的MX（MailExchanger）記錄，如果位于本地服務(wù)器中，則傳遞給本郵件服務(wù)器的MDA（MailDeliveryAgent，郵件投遞代理）；如果在異地，則通過(guò)SMTP將郵件發(fā)送到對(duì)端MTA。③對(duì)端MUA通過(guò)POP3將郵件接收到本地MUA。常用的SMTP命令和ESMTP命令命

令描

述HELO向接收方標(biāo)記發(fā)送方MAIL初始化郵件傳輸RCPT標(biāo)記郵件接收方DATA聲明郵件數(shù)據(jù)開(kāi)始（消息的主體）RSET中止當(dāng)前的傳輸VRFY用于確認(rèn)接收用戶NOOP無(wú)操作QUIT關(guān)閉連接SEND使接收主機(jī)知道消息必須送到另一個(gè)終端命

令描

述EHLOHELO的擴(kuò)展8BITMIME指明8位MIME傳輸SIZE限制消息的長(zhǎng)度2）POP3POP（PostOfficeProtocol，郵局協(xié)議）是適用于客戶-服務(wù)器結(jié)構(gòu)的脫機(jī)模型的電子郵件協(xié)議，目前已發(fā)展到第3版（POP3）。POP3的工作過(guò)程如下。①服務(wù)器通過(guò)偵聽(tīng)TCP端口110開(kāi)始POP3服務(wù)，當(dāng)客戶端主機(jī)需要使用服務(wù)時(shí)，與服務(wù)器主機(jī)建立TCP連接。②連接建立后，POP3發(fā)送確認(rèn)消息。③客戶端和POP3服務(wù)器相互交換命令和響應(yīng)，此過(guò)程持續(xù)到連接終止。命

令描

述USER輸入用戶名PASS此命令若成功，將導(dǎo)致?tīng)顟B(tài)轉(zhuǎn)換APOPDigest是MD5消息摘要STAT請(qǐng)求服務(wù)器發(fā)回關(guān)于郵箱的統(tǒng)計(jì)資料UIDL返回郵件的唯一標(biāo)識(shí)符LIST返回郵件數(shù)量和每個(gè)郵件的大小RETR返回由參數(shù)標(biāo)識(shí)的郵件的全部文本DELE服務(wù)器將由參數(shù)標(biāo)識(shí)的郵件標(biāo)記為刪除RSET服務(wù)器將重置所有標(biāo)記為刪除的郵件TOP服務(wù)器將返回由參數(shù)標(biāo)識(shí)的郵件前n行內(nèi)容NOOP服務(wù)器返回一個(gè)肯定的響應(yīng)QUIT刪除標(biāo)記的郵件（3）超文本傳輸協(xié)議目前使用的最為廣泛的應(yīng)用層協(xié)議是HTTP（超文本傳輸協(xié)議），其將HTML（超文本置標(biāo)語(yǔ)言）文檔從Web服務(wù)器傳送到Web瀏覽器，是一種基于客戶-服務(wù)器模式、面向事務(wù)的應(yīng)用層協(xié)議，可以傳送任意類型的數(shù)據(jù)對(duì)象。典型的HTTP事務(wù)處理過(guò)程如下：①客戶端和服務(wù)器建立連接；②客戶端向服務(wù)器提出請(qǐng)求；③服務(wù)器接受請(qǐng)求，并根據(jù)請(qǐng)求返回相應(yīng)的文件作為應(yīng)答；④客戶端與服務(wù)器關(guān)閉連接。7.2應(yīng)用層故障分類應(yīng)用層故障的原因非常復(fù)雜，甚至有下層傳遞給應(yīng)用層的故障。應(yīng)用層故障大致可分為兩類：①可用性類故障，即不能訪問(wèn)特定的服務(wù)；②性能類故障，如訪問(wèn)緩慢，時(shí)斷時(shí)續(xù)等現(xiàn)象。7.2.1應(yīng)用可用性類故障應(yīng)用層測(cè)試和故障診斷時(shí)一般按以下步驟進(jìn)行：①應(yīng)用程序的配置；②進(jìn)程是否異常（如處于高負(fù)荷狀態(tài)導(dǎo)致無(wú)法及時(shí)響應(yīng)）；③應(yīng)用程序所需相關(guān)服務(wù)是否正常啟用。1．網(wǎng)絡(luò)基本服務(wù)DNS故障借助于Windows操作系統(tǒng)中自帶的Nslookup工具可以查詢主機(jī)名、MX記錄和NS記錄等。2．郵件認(rèn)證故障SMTP在發(fā)送郵件時(shí)經(jīng)常遇到不能通過(guò)認(rèn)證的情況，除了密碼錯(cuò)誤外，主要原因是認(rèn)證方式配置不匹配。ESMTP有三個(gè)認(rèn)證方式：CRAM-MD5、PLAIN和LOGIN。不同的郵件服務(wù)器要求的認(rèn)證方式可能不同，如果配置錯(cuò)誤結(jié)果就會(huì)導(dǎo)致認(rèn)證不通過(guò)。圖（a）為運(yùn)用Wireshark協(xié)議分析軟件的TCP流功能還原指令流，圖（a）為成功認(rèn)證的情形，圖（b）為L(zhǎng)OGIN方式時(shí)錯(cuò)誤口令的情形。7.2.2應(yīng)用性能類故障以下列舉5種常見(jiàn)的應(yīng)用性能故障。1．代碼效率問(wèn)題2．分層服務(wù)環(huán)境中的訪問(wèn)故障對(duì)采用分層架構(gòu)的網(wǎng)絡(luò)進(jìn)行故障排查是極其困難的，除非對(duì)所有服務(wù)器的流量進(jìn)行監(jiān)控。NPM、APM和BPM是三種不完全相同的應(yīng)用分析方式。APM采用Agent技術(shù)，可以覆蓋應(yīng)用節(jié)點(diǎn)；NPM采用探針部署，可以覆蓋網(wǎng)絡(luò)節(jié)點(diǎn)；而B(niǎo)PM并不是前兩者相加，因?yàn)樗扇〉姆绞绞牵园膶用娣治鰳I(yè)務(wù)數(shù)據(jù)，覆蓋應(yīng)用節(jié)點(diǎn)和網(wǎng)絡(luò)節(jié)點(diǎn)，實(shí)現(xiàn)網(wǎng)絡(luò)與應(yīng)用的關(guān)聯(lián)，以業(yè)務(wù)為導(dǎo)向?qū)崿F(xiàn)對(duì)全鏈路性能的監(jiān)控。

NetSensor業(yè)務(wù)應(yīng)用拓?fù)浣Y(jié)構(gòu)NetSensor負(fù)載量分析NetSensor延時(shí)（時(shí)延）和重傳分析NetSensor網(wǎng)上銀行詳單3．資源用盡或匱乏導(dǎo)致訪問(wèn)緩慢服務(wù)器資源不足會(huì)導(dǎo)致訪問(wèn)性能下降，這類情況也可以借助NetFlow協(xié)議軟件采集的數(shù)據(jù)和統(tǒng)計(jì)信息進(jìn)行應(yīng)用層分析4．網(wǎng)絡(luò)設(shè)計(jì)缺陷導(dǎo)致服務(wù)器訪問(wèn)緩慢在此類網(wǎng)絡(luò)中，網(wǎng)管人員需要監(jiān)控不同區(qū)域內(nèi)網(wǎng)絡(luò)的流量，監(jiān)控每個(gè)VLAN內(nèi)的流量和協(xié)議分布，必要時(shí)在防火墻上添加策略，限制某些網(wǎng)段或某些應(yīng)用的訪問(wèn)，還必須監(jiān)測(cè)上行鏈路。5．病毒攻擊導(dǎo)致整個(gè)網(wǎng)絡(luò)應(yīng)用變慢在網(wǎng)絡(luò)主干鏈路（特別是與外部相連的廣域鏈路）中，流量的組成情況異常復(fù)雜，需要進(jìn)行高粒度分析，而NetFlow軟件非常適合此類故障中的分析應(yīng)用。從OutboundSymantec流量觀察，測(cè)試期間，流量也是維持在210kbps左右，但使用者只有一個(gè)IP地址（91），而該地址沒(méi)有分配給服務(wù)器，故判斷該機(jī)器有可能中毒了。7.3應(yīng)用層的測(cè)試和故障診斷7.3.1故障分析和排除環(huán)境中的測(cè)試1．部署方式進(jìn)行分析前需要了解被測(cè)系統(tǒng)的大致情況，以確定如何部署測(cè)試工具和以何種方式進(jìn)行分析。一般的Web訪問(wèn)可分為以下4個(gè)步驟。①DNS查找解析：客戶端首先查找DNS服務(wù)器，然后通過(guò)DNS獲取訪問(wèn)網(wǎng)站的IP地址信息，DNS將信息返回給客戶端。②TCP連接建立：客戶端和Web服務(wù)器建立連接。③服務(wù)器響應(yīng)：服務(wù)器在接收到客戶端請(qǐng)求后，通常會(huì)先運(yùn)行處理后再傳送數(shù)據(jù)。④數(shù)據(jù)傳送：服務(wù)器將數(shù)據(jù)傳送給客戶端。在進(jìn)行Web應(yīng)用類故障分析時(shí)，要特別注意服務(wù)群的訪問(wèn)流程（又稱為分層應(yīng)用），如果采用的是多級(jí)架構(gòu)的模式，由于Web應(yīng)用是前端應(yīng)用，后端還有其他服務(wù)器（如認(rèn)證服務(wù)器或數(shù)據(jù)庫(kù)服務(wù)器等），因此在進(jìn)行分析時(shí)，需要同時(shí)捕獲其他服務(wù)器的流量，合并后進(jìn)行協(xié)同分析。另外，需要注意Web應(yīng)用路徑中相關(guān)設(shè)備的配置，如采用Cache（緩存）技術(shù)、鏡像服務(wù)器技術(shù)和CDN（內(nèi)容分發(fā)網(wǎng)絡(luò)）技術(shù)等。在這類環(huán)境中測(cè)試時(shí)，需要在多個(gè)網(wǎng)絡(luò)路徑上部署探針以捕獲數(shù)據(jù)。4個(gè)分析位置，對(duì)應(yīng)4種不同的情形①分析位置1：分析重點(diǎn)是客戶端是否存在問(wèn)題，如DNS響應(yīng)請(qǐng)求慢、客戶端延時(shí)是否合理等。②分析位置2：分析重點(diǎn)是服務(wù)器是否存在問(wèn)題，區(qū)分問(wèn)題出在服務(wù)器還是網(wǎng)絡(luò)中。③分析位置3：分析重點(diǎn)是數(shù)據(jù)包途經(jīng)設(shè)備后是否存在內(nèi)容變化或者延時(shí)變化。④分析位置4：分析重點(diǎn)是多級(jí)架構(gòu)服務(wù)器中的數(shù)據(jù)流訪問(wèn)是否有異常。2．分析方法一般協(xié)議分析過(guò)程包括三個(gè)階段：實(shí)時(shí)監(jiān)控、捕獲數(shù)據(jù)和事后分析。設(shè)備接入被測(cè)系統(tǒng)后，開(kāi)始進(jìn)行實(shí)時(shí)監(jiān)控；在需要時(shí)進(jìn)行捕包；捕包完成后，啟用數(shù)據(jù)分析顯示功能。分析Web應(yīng)用類故障需要對(duì)網(wǎng)頁(yè)的加載過(guò)程逐步進(jìn)行詳細(xì)分析。在DNS查詢并返回結(jié)果后，客戶端和服務(wù)器會(huì)進(jìn)行3次握手建立TCP連接。在連接建立后，客戶端會(huì)向服務(wù)器請(qǐng)求數(shù)據(jù)，一般HTTP服務(wù)器會(huì)向客戶端回應(yīng)其相應(yīng)的HTTP報(bào)頭和數(shù)據(jù)，當(dāng)數(shù)據(jù)傳輸完畢后，客戶端發(fā)送FIN關(guān)閉連接。假設(shè)測(cè)試儀接在客戶端（分析位置1）通過(guò)在分析位置1和分析位置2部署測(cè)試儀，可以分析Web應(yīng)用訪問(wèn)緩慢的原因。①如果客戶端與服務(wù)器距離太遠(yuǎn)，將導(dǎo)致3次握手的時(shí)間過(guò)長(zhǎng)，兩者之間的路由器增多，數(shù)據(jù)包經(jīng)過(guò)的路徑增長(zhǎng)會(huì)導(dǎo)致訪問(wèn)速度慢。②服務(wù)器響應(yīng)時(shí)間過(guò)長(zhǎng)。某些操作（如請(qǐng)求）中存在過(guò)多的頁(yè)面腳本或圖片等，會(huì)造成響應(yīng)時(shí)間的增加，導(dǎo)致訪問(wèn)速度變慢。對(duì)比常態(tài)和故障時(shí)服務(wù)器的耗時(shí)比例，可以判斷是否由于服務(wù)器問(wèn)題而導(dǎo)致故障。如果測(cè)試儀處在分析位置3（相當(dāng)于在網(wǎng)絡(luò)傳輸路徑上設(shè)置監(jiān)控點(diǎn)）。在合并后的視圖中顯示了同一個(gè)數(shù)據(jù)幀經(jīng)過(guò)不同網(wǎng)絡(luò)設(shè)備傳輸后的情況，通過(guò)對(duì)比可以獲知數(shù)據(jù)包有沒(méi)有被改變和延時(shí)等信息。如果測(cè)試儀處在分析位置4（相當(dāng)于在網(wǎng)絡(luò)服務(wù)群中的傳輸路徑上設(shè)置監(jiān)控點(diǎn)）則可以監(jiān)控經(jīng)過(guò)不同服務(wù)器后的數(shù)據(jù)包變化情況。在分析時(shí)可以進(jìn)行分層查看，如圖7.31所示，將用戶訪問(wèn)分為三層，每層實(shí)現(xiàn)不同的功能，并記錄時(shí)間信息。這樣，多級(jí)架構(gòu)網(wǎng)絡(luò)中的應(yīng)用訪問(wèn)就變得可視了，可以清楚地了解每層中所消耗的時(shí)間。導(dǎo)致服務(wù)器變慢的因素可能包括：①

服務(wù)器資源不夠，導(dǎo)致性能下降；②

服務(wù)器在等待后續(xù)服務(wù)器的響應(yīng)；③

服務(wù)器處于其他基礎(chǔ)應(yīng)用服務(wù)等待中延時(shí)發(fā)生于第一層延時(shí)發(fā)生于第二層延時(shí)發(fā)生于第三層區(qū)別于測(cè)試儀處在分析位置3的情況，采用多級(jí)架構(gòu)服務(wù)器時(shí)，數(shù)據(jù)包的對(duì)應(yīng)關(guān)系不復(fù)存在。如果客戶端請(qǐng)求Web服務(wù)器，而Web服務(wù)器繼而訪問(wèn)數(shù)據(jù)庫(kù)服務(wù)器，那么客戶端同Web服務(wù)器之間的數(shù)據(jù)以及Web服務(wù)器和數(shù)據(jù)庫(kù)服務(wù)器之間的數(shù)據(jù)通常只有時(shí)間上的關(guān)聯(lián)，內(nèi)容上的關(guān)聯(lián)性可能很小。分析時(shí)需要將流程相關(guān)服務(wù)器進(jìn)行手動(dòng)關(guān)聯(lián)，指定時(shí)間點(diǎn)后展現(xiàn)在同一視圖中在故障定位時(shí)，如果已經(jīng)獲得了引起延時(shí)的位置，可以分析具體的訪問(wèn)流程。如果是因?yàn)槟硹l數(shù)據(jù)庫(kù)查詢語(yǔ)句導(dǎo)致的，則有以下典型的可能性：①數(shù)據(jù)庫(kù)檢索對(duì)象為全局而非某一字段；②被查詢內(nèi)容沒(méi)有建立索引；③數(shù)據(jù)庫(kù)系統(tǒng)優(yōu)化不夠，如重復(fù)提交等。7.3.2監(jiān)控網(wǎng)絡(luò)運(yùn)行場(chǎng)景中的測(cè)試1．部署方式應(yīng)用層的流量監(jiān)控比網(wǎng)絡(luò)層的要復(fù)雜得多，其主要目的如下。①分析指定應(yīng)用的響應(yīng)時(shí)間和趨勢(shì)，以及應(yīng)用的組成和分布。②分析指定的事務(wù)過(guò)程，可能涉及不同的應(yīng)用協(xié)議并同時(shí)進(jìn)行分析。③分析行為和過(guò)程，評(píng)估訪問(wèn)效率。常用的應(yīng)用層流量監(jiān)控基于以下三種方式。①SNMP分析（基于RMON、RMONII提供應(yīng)用層的相關(guān)信息）：是端口級(jí)的分析。②NetFlow分析（基于流）：是FDR和IP級(jí)分析。③

探針?lè)治觯ɑ谠紨?shù)據(jù)）：是應(yīng)用協(xié)議和應(yīng)用級(jí)分析。（1）NetFlow分析NetFlow架構(gòu)如圖7.37所示。其中，NetFlow分析器和NetFlow源設(shè)備是NetFlow架構(gòu)中的兩個(gè)關(guān)鍵因素。判斷Flow記錄是否到期的4個(gè)原則如下。①當(dāng)TCP連接完成（FIN）或被重置（RST）時(shí)，F(xiàn)low記錄將終止。②當(dāng)緩存滿時(shí)，刪除多余的Flow記錄。③如果Flow記錄在一段時(shí)間內(nèi)均為Idle狀態(tài)，則認(rèn)為該Flow超時(shí)，并將其從緩存中移除。④將長(zhǎng)時(shí)間存在的Flow記錄從緩存中移除。在默認(rèn)情況下，F(xiàn)low記錄的生存時(shí)間不允許超過(guò)30min。路由器每秒檢查一次緩存，若Flow記錄的不活動(dòng)時(shí)間超過(guò)15s或者Flow記錄的活動(dòng)時(shí)間超過(guò)30min，都將造成Flow記錄在緩存中超時(shí)。具體時(shí)間可以根據(jù)需要進(jìn)行配置。（2）探針?lè)治鰹榱藦母顚哟紊狭私饩W(wǎng)絡(luò)，通常采用將探針部署在網(wǎng)絡(luò)不同位置的方式，以獲得原始數(shù)據(jù)。探針是泛指的概念，有Box架構(gòu)或Server架構(gòu)之分，有基于廣域網(wǎng)和局域網(wǎng)之分，有基于本地存儲(chǔ)數(shù)據(jù)和異地存儲(chǔ)數(shù)據(jù)之分，有基于串行接入和基于旁路接入之分。2．分析方法（1）NetFlow分析①基于端口的網(wǎng)絡(luò)流量監(jiān)控②基于應(yīng)用的網(wǎng)絡(luò)流量監(jiān)控（2）探針?lè)治?.3.3性能評(píng)估場(chǎng)景中的測(cè)試1．部署方式應(yīng)用層測(cè)試中，性能測(cè)試是非常重要的測(cè)試內(nèi)容，分為應(yīng)用性能仿真測(cè)試和功能仿真測(cè)試。應(yīng)用層的性能測(cè)試是主動(dòng)測(cè)試方式，可以根據(jù)測(cè)試需要定制各類仿真流量。此時(shí)，被測(cè)網(wǎng)絡(luò)被視作黑盒，在其中注入不同的應(yīng)用流，以獲得在不同條件下被測(cè)網(wǎng)絡(luò)對(duì)于各類激勵(lì)流量的響應(yīng)情況。在測(cè)試部署時(shí)，通過(guò)TrafficAgent（TA，流量代理）加TestCenter（TC，測(cè)試中心）的方式組成測(cè)試系統(tǒng)TA可以是網(wǎng)絡(luò)設(shè)備，也可以是PC機(jī)或者服務(wù)器、測(cè)試工具等。TA負(fù)責(zé)執(zhí)行測(cè)試過(guò)程并提交測(cè)試數(shù)據(jù)，TC負(fù)責(zé)下發(fā)測(cè)試要求并統(tǒng)計(jì)TA提交的數(shù)據(jù)。復(fù)雜的應(yīng)用仿真系統(tǒng)在TA和TC的基礎(chǔ)上還會(huì)擴(kuò)展出UI（UserInterface，用戶接口）、腳本代理（免安裝TA）等。電信運(yùn)營(yíng)商網(wǎng)絡(luò)的主動(dòng)應(yīng)用性能仿真測(cè)試系統(tǒng)示意圖，TA分布在不同的數(shù)據(jù)中心、分支機(jī)構(gòu)、小型分支、辦公室等處，位于總部數(shù)據(jù)中心的TC則負(fù)責(zé)下發(fā)和收集測(cè)試數(shù)據(jù)，并進(jìn)行匯總，獲得全網(wǎng)的主動(dòng)測(cè)試數(shù)據(jù)。2．分析方法應(yīng)用性能測(cè)試主要有三種方法。（1）端到端的End-to-End測(cè)試

（2）端到端的End-through-End測(cè)試（3）端到端的Client-Server測(cè)試7.4應(yīng)用層的測(cè)試和故障診斷案例7.4.1典型案例1：大型數(shù)據(jù)中心的網(wǎng)絡(luò)訪問(wèn)異常狀況分析NTM捕獲的數(shù)據(jù)如圖7.70所示，系統(tǒng)分析過(guò)程如下。（1）查看DLC低層情況①查看廣播包：本例中是正常的。②查看流量趨勢(shì)：本例中無(wú)明顯異常（如流量突發(fā)或趨勢(shì)變大）。（2）查看網(wǎng)絡(luò)層數(shù)據(jù)觀察流量最大的188和186服務(wù)器的數(shù)據(jù)流，分別如圖7.71和圖7.72所示。如果有以往的數(shù)據(jù)（如一個(gè)月前的相應(yīng)數(shù)據(jù)），則可進(jìn)行時(shí)間上的縱向比較。本例中從趨勢(shì)圖無(wú)法獲得更詳細(xì)的信息。（3）查看應(yīng)用層統(tǒng)計(jì)單擊進(jìn)入應(yīng)用層統(tǒng)計(jì)數(shù)據(jù)顯示，如圖7.73所示，發(fā)現(xiàn)存在大量錯(cuò)誤，主要是401未認(rèn)證錯(cuò)誤。特別要注意的是，這類錯(cuò)誤并不一定與網(wǎng)絡(luò)訪問(wèn)緩慢有直接關(guān)系，可能是由于代碼效率問(wèn)題導(dǎo)致的，需要進(jìn)一步細(xì)查，并做出優(yōu)化。（4）應(yīng)用流分析由于本次故障現(xiàn)象集中表現(xiàn)在訪問(wèn)速度慢或不能提供服務(wù)，因此對(duì)訪問(wèn)188服務(wù)器的流量進(jìn)行分析，如圖7.74和圖7.75所示為其中流量最大的IP地址為93的客戶端的過(guò)濾分析數(shù)據(jù)。故障狀態(tài)下服務(wù)器訪問(wèn)延時(shí)數(shù)據(jù)正常工作時(shí)服務(wù)器訪問(wèn)延時(shí)數(shù)據(jù)由于NTM部署于服務(wù)器前端，可以認(rèn)為處于同一位置，從有關(guān)數(shù)據(jù)和解碼界面進(jìn)行分析判斷，數(shù)據(jù)POST請(qǐng)求已經(jīng)到達(dá)NTM，那么可以認(rèn)為也到達(dá)了服務(wù)器端口，基本可以判斷訪問(wèn)速度慢或服務(wù)不可用的主要原因來(lái)自服務(wù)器。報(bào)文到達(dá)了服務(wù)器端口，但是服務(wù)器沒(méi)有及時(shí)做出響應(yīng)，需要應(yīng)用服務(wù)軟件開(kāi)發(fā)人員進(jìn)一步確認(rèn)具體原因。7.4.2典型案例2：大型數(shù)據(jù)中心的網(wǎng)絡(luò)流量監(jiān)控和優(yōu)化對(duì)于大型數(shù)據(jù)中心，經(jīng)常需要對(duì)網(wǎng)絡(luò)流量趨勢(shì)進(jìn)行分析，以了解網(wǎng)絡(luò)中的流量成分，從而根據(jù)業(yè)務(wù)進(jìn)行流量?jī)?yōu)化。①網(wǎng)絡(luò)流量突發(fā)嚴(yán)重，需要進(jìn)行錯(cuò)峰處理，做到削峰填谷。②網(wǎng)絡(luò)流量中存在很大的背景流量，需要給出應(yīng)用整改建議，同時(shí)定位耗用帶寬大戶。③關(guān)鍵網(wǎng)絡(luò)設(shè)備的CPU利用率居高不下，響應(yīng)時(shí)間增加或不響應(yīng)，需要確認(rèn)原因。BPC對(duì)存在問(wèn)題的系統(tǒng)發(fā)出告警，并且通過(guò)企業(yè)微信告警平臺(tái)給客戶發(fā)送微信。客戶收到告警后，可以進(jìn)行處理。BPC發(fā)出告警140和141服務(wù)器響應(yīng)率低140和141服務(wù)器各項(xiàng)指標(biāo)的曲線圖多維統(tǒng)計(jì)分析中，對(duì)異常交易類型的層層鉆取新增服務(wù)器之后，從應(yīng)用層視圖明顯發(fā)現(xiàn)響應(yīng)時(shí)間降低，響應(yīng)率提高多維統(tǒng)計(jì)分析中，重要業(yè)務(wù)類型響應(yīng)率恢復(fù)正常，各臺(tái)服務(wù)器響應(yīng)時(shí)間和響應(yīng)率也都處于正常值7.4.3典型案例3：大型數(shù)據(jù)中心復(fù)雜應(yīng)用環(huán)境下的分析大型數(shù)據(jù)中心中經(jīng)常需要進(jìn)行多級(jí)應(yīng)用架構(gòu)的網(wǎng)絡(luò)分析，特別是當(dāng)客戶端訪問(wèn)緩慢或提交表單數(shù)據(jù)響應(yīng)時(shí)間長(zhǎng)時(shí)，基于多級(jí)應(yīng)用架構(gòu)的分析尤為重要。部署于數(shù)據(jù)中心，旁路接在交換機(jī)上即可。通過(guò)鏡像口設(shè)置將客戶端IP地址為99、Web服務(wù)器（IP地址為5）、報(bào)表服務(wù)器（IP地址為3）、數(shù)據(jù)庫(kù)服務(wù)器（IP地址為1）等數(shù)據(jù)導(dǎo)入測(cè)試儀。本