基于OPNET的HTTP性能仿真研究

姜瑞娟，薛曉瑾，劉藝蘭，潘耘

(中國傳媒大學計算機學院，北京 100024)

?

基于OPNET的HTTP性能仿真研究

姜瑞娟，薛曉瑾，劉藝蘭，潘耘

(中國傳媒大學計算機學院，北京 100024)

摘要：本文以研究HTTP性能為目標，基于OPNET仿真平臺創(chuàng)建HTTP網(wǎng)絡(luò)仿真模型，并進行了仿真實驗。仿真中，針對HTTP的不同性能設(shè)計了不同的場景，通過對比各場景的仿真結(jié)果，分析了HTTP的不同性能對Web應用產(chǎn)生的影響。

關(guān)鍵詞：HTTP；Web應用；OPNET

1引言

HTTP(Hyper Text Transfer Protocol)是在1990年開始使用的超文本傳輸協(xié)議，HTTP/0.9、HTTP/1.0是公布比較早的版本，目前最新版本是HTTP/1.1[1]。HTTP協(xié)議是客戶端瀏覽器或者其他程序與Web服務器之間的應用層通信協(xié)議，此協(xié)議指定了客戶端可以向服務器發(fā)送什么樣的消息，并且得到什么樣的回應消息。HTTP協(xié)議采用請求/響應模式，工作在TCP(Transmission Control Protocol)協(xié)議之上。通常，由HTTP客戶端發(fā)起一個請求，建立一個到服務器指定端口的TCP連接。連接建立后，HTTP服務器則在指定好的端口監(jiān)聽客戶端發(fā)送過來的請求。一旦收到請求，服務器就會處理該請求，并向客戶端發(fā)送響應消息，從而完成客戶端與服務器的信息交換。

不同版本的HTTP(本文主要研究HTTP/1.0和HTTP/1.1)在性能方面存在很大差異，同一版本不同配置的HTTP(帶有流水線的HTTP/1.1和不帶流水線的HTTP/1.1)也有性能上的差異，它們都會對Web應用產(chǎn)生不同的影響。

本文基于OPNET對HTTP性能進行研究。OPNET(Optimal Network Engineering Tools)是一款仿真軟件，由美國的OPNET Technology開發(fā)[2-4]。它可以對現(xiàn)實生活中的網(wǎng)絡(luò)進行仿真，也能對現(xiàn)實網(wǎng)絡(luò)的性能進行評估。OPNET采用了層次化的建模機制，自頂向下分別是網(wǎng)絡(luò)層、節(jié)點層和進程層[5]，比較全面地反映了實際網(wǎng)絡(luò)的特性。OPNET軟件具有方便操作的圖形用戶界面，用戶只需通過簡單的拖放動作和單擊動作就可以構(gòu)建出各種網(wǎng)絡(luò)配置并對其性能進行測試。OPNET軟件中包含了大量的模型庫，可以對現(xiàn)有的大多數(shù)硬件設(shè)備和通信協(xié)議進行仿真。OPNET中豐富的仿真模型，為我們仿真研究復雜的計算機網(wǎng)絡(luò)提供了極大的方便。

2HTTP協(xié)議

2.1　HTTP/1.0與HTTP/1.1

HTTP/1.0協(xié)議很重要的一個特點是支持非持久連接，規(guī)定瀏覽器與服務器只保持短暫的連接。瀏覽器每次發(fā)出請求前都需要與服務器建立一個TCP連接，服務器處理完請求后就會斷開TCP連接，即一個TCP連接只處理一個請求，如圖1所示。因此，當訪問一個嵌入多個圖像的網(wǎng)頁時，訪問過程將包含多次請求和響應，每一對請求和響應都需要獨立建立一個TCP連接，所以一次訪問中會建立多個TCP連接，如圖2所示。雖然HTTP/1.0的非持久連接方式節(jié)省了單個對象的傳輸時間[6]，但客戶端和服務器端每次建立和關(guān)閉連接的過程卻耗費了大量時間。此外HTTP/1.0還存在一些其他缺點，如不支持Host請求頭字段、存在帶寬浪費現(xiàn)象、只定義了16個狀態(tài)響應碼以及對錯誤或警告的提示不夠具體等等。

圖1　HTTP/1.0下的客戶端與服務器信息交換過程

圖2　HTTP/1.0下的網(wǎng)頁請求過程

HTTP/1.1協(xié)議在繼承HTTP/1.0優(yōu)點的基礎(chǔ)上，也對其性能的不足進行了改進，如添加了更多的方法、增加了狀態(tài)響應碼、支持Host請求頭字段等，但HTTP/1.1支持持久連接是與HTTP/1.0最大的不同之處。所謂持久連接，就是客戶端與服務器建立TCP連接，在服務器處理完一個請求之后，并不是馬上關(guān)閉連接，而是在傳輸完多個請求和響應之后，才關(guān)閉連接，這樣將明顯減少建立連接和關(guān)閉連接所消耗的時間。HTTP/1.1默認情況下使用流水線技術(shù)，把各內(nèi)聯(lián)對象的多個請求組合成單條消息，客戶端可以連續(xù)發(fā)送多個請求，而無需等待上一次請求結(jié)果的返回，這也減少了整個訪問過程所需要的時間，如圖3所示。

圖3　帶有流水線的HTTP/1.1下的客戶端與服務器信息交換過程

2.2　帶流水線和不帶流水線的HTTP

在不帶流水線的HTTP中，客戶端每次只能向服務器發(fā)送一個請求，必須在收到這個請求的響應之后才能發(fā)送下一個請求，如圖4所示。在一個往返時間(RTT，Round-Trip Time)內(nèi)，我們只發(fā)送了一個請求，而且在服務器向客戶端做出響應之后，服務器便開始等待客戶端發(fā)出下一個請求，但是下一個請求并不能馬上到達，所以會造成資源的浪費。在帶流水線的HTTP中，客戶端可以依次發(fā)送多個請求，不必等待收到上一個請求的響應[7]，服務器收到這些請求后，會按照請求的先后到達順序依次對這些請求做出響應，如圖3所示，而且在帶流水線的持久連接中服務器空等請求的時間比較少，這就提高了網(wǎng)絡(luò)的利用率。

圖4　不帶流水線的HTTP/1.1下的客戶端與服務器信息交換過程

3基于OPNET的HTTP應用仿真實驗設(shè)計

3.1　仿真原理

本文使用OPNET 17.5仿真軟件對HTTP性能問題進行仿真研究，仿真內(nèi)容為客戶端通過互聯(lián)網(wǎng)瀏覽網(wǎng)頁。實驗中，一個客戶端節(jié)點會周期性地向Web服務器發(fā)送請求，以實現(xiàn)對請求網(wǎng)頁的檢索和瀏覽。在OPNET中，把每個被請求的網(wǎng)頁建模為一個文本對象(即HTML文件)和幾個內(nèi)嵌于文本對象的其他對象(如圖像)的一個組合體。HTTP應用的仿真原理大致如下：首先，客戶端與服務器建立TCP連接，然后客戶端會向服務器發(fā)送一個HTTP請求來索要網(wǎng)頁；服務器收到客戶端發(fā)來的請求后，將請求進行處理，并向客戶端發(fā)送它請求的網(wǎng)頁。在客戶端對網(wǎng)頁進行解析的過程中，如果這個網(wǎng)頁包含有多個內(nèi)嵌對象，那么客戶端會后續(xù)地向服務器發(fā)出對這些對象的請求。

3.2　仿真模型

本文共設(shè)計三個實驗場景，各場景的Web應用配置如表1所示，每個場景的網(wǎng)絡(luò)拓撲都由3個客戶端節(jié)點、1個Web服務器節(jié)點和1個IP云節(jié)點構(gòu)成，如圖5所示。選擇頁面響應時間、對象響應時間作為統(tǒng)計量。

表1　Web應用配置表

圖5　網(wǎng)絡(luò)拓撲圖

3.3　請求對象數(shù)目設(shè)定

客戶端請求對象數(shù)目的不同使得對象響應時間也不同。圖6給出了在文本對象中嵌入不同數(shù)目圖像對象的情況下，不同性能的HTTP所對應的對象響應時間。

圖6　不同性能HTTP對象響應時間比較

由圖6可知，在請求數(shù)量較少的情況下，不同性能的HTTP對應的對象響應時間差距不大；隨著請求數(shù)量的不斷增加，對象響應時間的差距逐漸體現(xiàn)出來。本實驗中，我們將文本對象中嵌入7幅大型圖像(總共8個對象)來模擬現(xiàn)實網(wǎng)絡(luò)的Web應用。

4實驗結(jié)果分析

4.1　對象響應時間與頁面響應時間

場景1中對象響應時間與頁面響應時間的統(tǒng)計結(jié)果如圖7所示。

圖7　對象響應時間與頁面響應時間對比

客戶端向服務器發(fā)出一個對象請求，服務器收到請求并向客戶端做出響應，這個往返時間就是對象響應時間。一般情況下，一個網(wǎng)頁通常包含多個對象，所以當客戶端收到服務器返回的所有請求的響應時，才算完成了整個頁面的響應。因此如圖7所示，頁面響應時間明顯大于對象響應時間。

4.2　對象響應時間對比與分析

場景1、場景2和場景3中的對象響應時間統(tǒng)計結(jié)果如圖8所示。

圖8　對象響應時間仿真結(jié)果對比

帶流水線的HTTP/1.1一次可以向服務器發(fā)送多個對象請求，因為服務器要同時處理多個請求，所以對象響應時間就會被相應拉長，而不帶流水線的HTTP/1.1一次只處理一個請求，所以前者的對象響應時間大于后者。

雖然HTTP/1.0為每個請求建立TCP連接需要一定的時間，但在請求數(shù)量較多的情況下，HTTP/1.1的流水線機制使服務器需要額外耗費更長的時間來處理這些請求，所以后者被拉長的對象響應時間大于前者。

相對于不支持持久連接的HTTP/1.0，支持持久連接的不帶流水線的HTTP/1.1重用已經(jīng)打開的TCP連接，省去了為每個請求建立TCP連接的時間，所以它的對象響應時間小于前者。

4.3　頁面響應時間對比與分析

場景1、場景2和場景3中頁面響應時間統(tǒng)計結(jié)果如圖9所示。

圖9　頁面響應時間仿真結(jié)果對比

因為在不帶流水線的HTTP/1.1中，客戶端每次只能向服務器發(fā)送一個請求，要等收到這個請求的響應之后才能發(fā)送下一個請求，而帶有流水線的HTTP/1.1無需等到服務器返回的響應就可以連續(xù)發(fā)送請求，從而節(jié)省了請求等待時間。所以，前者的頁面響應時間大于后者。

一般情況下，HTTP/1.0使用并行TCP連接，最大并行連接數(shù)為4，相比于每次只能發(fā)送一個請求的不帶流水線的HTTP/1.1，減少了整個頁面的響應時間。

HTTP/1.1支持持久連接，比起非持久連接的HTTP/1.0，減少了不必要的TCP連接建立時間，而且?guī)Я魉€的HTTP/1.1一次發(fā)送的對象請求數(shù)目大于HTTP/1.0并行連接下的最多請求數(shù)目。所以，前者的頁面響應時間小于后者。

5總結(jié)

本文基于OPNET，實現(xiàn)了對HTTP協(xié)議應用的仿真，通過比較不同場景下的對象響應時間和頁面響應時間，了解到HTTP的不同性能會對Web應用產(chǎn)生不同的影響，并基于HTTP的實現(xiàn)機制對仿真結(jié)果進行了分析。本文所做的研究僅包括HTTP/1.0和HTTP/1.1兩個版本，也有學者對正在制定中的HTTP/2.0[8]進行了研究，HTTP/2.0作為HTTP/1.1發(fā)布后的首個更新版本，它的異步并發(fā)、增量傳輸和關(guān)鍵內(nèi)容優(yōu)先等機制為我們進一步研究HTTP性能提供了新的方向。

參考文獻

[1]查志琴，李慧.HTTP協(xié)議的發(fā)展對Web服務器性能的影響[J].常州工學院學報，2003，02：49-52.

[2]宋文苑，樊水康，張日飛.OPNET網(wǎng)絡(luò)仿真與建模方法[J].電腦開發(fā)與應用，2007，09：51-52，55.

[3]周慧.OPNET網(wǎng)絡(luò)仿真及其應用研究[D].武漢科技大學，2009.

[4]張劍.基于OPNET仿真建模方法研究[D].武漢理工大學，2005.

[5]王娟，王亞民.OPNET的關(guān)鍵技術(shù)研究[J].實驗科學與技術(shù)，2007，03：66-68，79.

[6]徐健，王濤.HTTP/1.1的分析[J].西南師范大學學報(自然科學版)，2004，02：315-319.

[7]肖戈林.HTTP協(xié)議技術(shù)探析[J].江西通信科技，2001，01：17-24.

[8]范菁菁.HTTP/2.0關(guān)鍵技術(shù)及標準化進展[J].電信網(wǎng)技術(shù)，2014，06：60-63.

(責任編輯：馬玉鳳)

Simulation Study of HTTP Performance Based on OPNET

JIANG Rui-juan，XUE Xiao-jin，LIU Yi-lan，PAN Yun

(School of Computer Science，Communication University of China，Beijing 100024)

Abstract：To study the HTTP performance，based on OPNET simulation platform，we do simulations with some HTTP network simulation models.In the simulation，we design different scenarios according to different performances of HTTP.By comparing the simulation results of each scenario，we analyze the influence of different performance of HTTP to Web applications.

Keywords：HTTP；web applications；OPNET

作者簡介：姜瑞娟(1988-)，女(漢族)，山東臨沂人，中國傳媒大學計算機學院研究生.E-mail：jiangruijuan@cuc.edu.cn

基金項目：中國傳媒大學2014年教學改革項目

收稿日期：2015-03-12

中圖分類號：TP393

文獻標識碼：A

文章編號：1673-4793(2015)05-0050-05