HTTP既可以使用非持久連接(nonpersistent connection)，也可以使用持久連接(persistent connection)。HTTP/1.0使用非持久連接，HTTP/1.1默認使用持久連接。
非持久連接
讓我們查看一下非持久連接情況下從服務(wù)器到客戶傳送一個Web頁面的步驟。假設(shè)該貝面由1個基本HTML文件和10個JPEG圖像構(gòu)成，而且所有這些對象都存放在同一臺服務(wù)器主機中。 再假設(shè)該基本HTML文件的URL為:www.yesky.com/somepath/index.html。
下面是具體步騾:
1.HTTP客戶初始化一個與服務(wù)器主機www.yesky.com中的HTTP服務(wù)器的TCP連接。HTTP服務(wù)器使用默認端口號80監(jiān)聽來自HTTP客戶的連接建立請求。
2.HTTP客戶經(jīng)由與TCP連接相關(guān)聯(lián)的本地套接字發(fā)出—個HTTP請求消息。這個消息中包含路徑名/somepath/index.html。
3.HTTP服務(wù)器經(jīng)由與TCP連接相關(guān)聯(lián)的本地套接字接收這個請求消息，再從服務(wù)器主機的內(nèi)存或硬盤中取出對象/somepath/index.html，經(jīng)由同一個套接字發(fā)出包含該對象的響應消息。
4.HTTP服務(wù)器告知TCP關(guān)閉這個TCP連接(不過TCP要到客戶收到剛才這個響應消息之后才會真正終止這個連接)。
5.HTTP客戶經(jīng)由同一個套接字接收這個響應消息。TCP連接隨后終止。該消息標明所封裝的對象是一個HTML文件。客戶從中取出這個文件，加以分析后發(fā)現(xiàn)其中有10個JPEG對象的引用。
6.給每一個引用到的JPEG對象重復步騾1-4。
瀏覽器在接收web頁面的同時把它顯示給用戶。不同的瀏覽器可能會以略有不同的方式解釋(也就是向用戶顯示)同一個web頁面。HTTP與客戶如何解釋Web頁面沒有任何關(guān)系，其規(guī)范([RFC 1945]和[RFC 2616I)僅僅定義HTTP客戶程序和服務(wù)器程序之間的通信協(xié)議。
上述步驟之所以稱為使用非持久連接，原因是每次服務(wù)器發(fā)出一個對象后，相應的TCP連接就被關(guān)閉，也就是說每個連接都沒有持續(xù)到可用于傳送其他對象。每個TCP連接只用于傳輸一個請求消息和一個響應消息。就上述例子而言，用戶每請求一次那個web頁面，就產(chǎn)生11個TCP連接。
在上述步騾中，我們有意不說清客戶是通過10個串行的TCP連接先后取得所有JPEG對象，還是通過并行的TCP連接同時取得其中某些JPEG對象。實際上，現(xiàn)今的瀏覽器允許用戶通過配置來控制并行連接的程度。大多數(shù)瀏覽器默認可以打開5到10個并行的TCP連接，每個連接處理一個請求—響應事務(wù)。用戶要是喜歡，可以把最大并行連接數(shù)設(shè)為l，那樣的話這10個連接是串行地建立的。我們將在第3章看到，使用并行連接可以縮短響應時間。
繼續(xù)介紹之前，先估算一下從客戶請求基本HTML文件到它收到該文件所經(jīng)歷的時間。為此我們定義往返時間(round trip time，簡稱RTT)，它是一個小分組從客戶主機游動到服務(wù)器主機再返回客戶主機所花的時間。RTT包括分組傳播延遲、在中間路由器和交換機土的分組排隊延遲以及分組處理延遲。下面考慮用戶點擊某個超鏈接時會發(fā)生什么。用戶的點擊導致瀏覽器發(fā)起建立一個與Web服務(wù)器的TCP連接;這里涉及·—次“三次握手”過程——首先是客戶向服務(wù)器發(fā)送一個小的冗余消息，接著是服務(wù)器向客戶確認并響應以一個小的TCP消息，最后是客戶向服務(wù)器回確認。三次握手過程的前兩次結(jié)束時，流逝的時間為1個RTT。此時客戶把HTTP請求消息發(fā)送到TCP連接中，客戶接著把三次握手過程最后一次中的確認捎帶在包含這個消息的數(shù)據(jù)分節(jié)中發(fā)送以去。服務(wù)器收到來自TCP連接的請求消息后，把相應的HTML文件發(fā)送到TCP連接中，服務(wù)器接著把對早先收到的客戶請求的確認捎帶在包含該HTML文件的數(shù)據(jù)分節(jié)中發(fā)送出去。這個HTTP請求順應交互也花去1個RTT時間。因此，總的響應時間粗略地算是2個RTT加上服務(wù)器發(fā)送這個HTMI文件的時間。
持久連接
非持久連接有些缺點。首先，客戶得為每個待請求的對象建立并維護一個新的連接。對于每個這樣的連接，TCP得在客戶端和服務(wù)器端分配TCP緩沖區(qū)，并維持TCP變量。對于有可能同時為來自數(shù)百個不同客戶的請求提供服務(wù)的web服務(wù)器來說，這會嚴重增加其負擔。其次，如前所述，每個對象都有2個RTT的響應延長——一個RTT用于建立TCP連接，另—個RTT用于請求和接收對象。最后，每個對象都遭受TCP緩啟動，因為每個TCP連接都起始于緩啟動階段。不過并行TCP連接的使用能夠部分減輕RTT延遲和緩啟動延遲的影響。
在持久連接情況下，服務(wù)器在發(fā)出響應后讓TCP連接繼續(xù)打開著。同一對客戶/服務(wù)器之間的后續(xù)請求和響應可以通過這個連接發(fā)送。整個Web頁面(上例中為包含一個基本HTMLL文件和10個圖像的頁面)自不用說可以通過單個持久TCP連接發(fā)送:甚至存放在同一個服務(wù)器中的多個web頁面也可以通過單個持久TCP連接發(fā)送。通常，HTTP服務(wù)器在某個連接閑置一段特定時間后關(guān)閉它，而這段時間通常是可以配置的。持久連接分為不帶流水線(without pipelining)和帶流水線(with pipelining)兩個版本。如果是不帶流水線的版本，那么客戶只在收到前一個請求的響應后才發(fā)出新的請求。這種情況下，web頁面所引用的每個對象(上例中的10個圖像)都經(jīng)歷1個RTT的延遲，用于請求和接收該對象。與非持久連接2個RTT的延遲相比，不帶流水線的持久連接已有所改善，不過帶流水線的持久連接還能進一步降低響應延遲。不帶流水線版本的另一個缺點是，服務(wù)器送出一個對象后開始等待下一個請求，而這個新請求卻不能馬上到達。這段時間服務(wù)器資源便閑置了。
HTTP/1.1的默認模式使用帶流水線的持久連接。這種情況下，HTTP客戶每碰到一個引用就立即發(fā)出一個請求，因而HTTP客戶可以一個接一個緊挨著發(fā)出各個引用對象的請求。服務(wù)器收到這些請求后，也可以一個接一個緊挨著發(fā)出各個對象。如果所有的請求和響應都是緊挨著發(fā)送的，那么所有引用到的對象一共只經(jīng)歷1個RTT的延遲(而不是像不帶流水線的版本那樣，每個引用到的對象都各有1個RTT的延遲)。另外，帶流水線的持久連接中服務(wù)器空等請求的時間比較少。與非持久連接相比，持久連接(不論是否帶流水線)除降低了1個RTT的響應延遲外，緩啟動延遲也比較小。其原因在于既然各個對象使用同一個TCP連接，服務(wù)器發(fā)出第一個對象后就不必再以一開始的緩慢速率發(fā)送后續(xù)對象。相反，服務(wù)器可以按照第一個對象發(fā)送完畢時的速率開始發(fā)送下一個對象。
