用于支持WWW瀏覽的網(wǎng)絡(luò)協(xié)議為HTTP，這是一種最基本的客戶機/服務(wù)器的訪問協(xié)議。
瀏覽器向服務(wù)器發(fā)送請求，而服務(wù)器回應(yīng)相應(yīng)的網(wǎng)頁。HTTP協(xié)議從1990年開始出現(xiàn)，發(fā)展
到當前的HTTP
1.1標準，已經(jīng)有了相當多的擴展，然而其最基本的實現(xiàn)是非常簡單的，服務(wù)器需要進行
的額外處理相當少，這也是為什么Web服務(wù)器軟件如此眾多的原因之一。


請求方法

通常，HTTP協(xié)議使用端口80來提供客戶訪問，因此也可以使用其他的網(wǎng)絡(luò)軟件，如telnet
，模擬客戶向服務(wù)器發(fā)送請求，來查看HTTP的傳輸方式。

$telnetwebserver80
Trying192.168.0.1...
Connectedtowebserver.
Escapecharacteris'^]'.
GET/index.Html



　　當telnet顯示了Connect等信息建立了連接之后，服務(wù)器就等待使用者輸入請求，而
不進行任何提示。上例中，使用者輸入GET/index.html指令，則服務(wù)器立即將相應(yīng)的網(wǎng)
頁返回，然后關(guān)閉連接。

　　客戶程序向服務(wù)器發(fā)送的請求可以有不同的類型，這樣服務(wù)器可以根據(jù)不同的請求類
型進行不同的處理。在HTTP1.0中，定義了三種最基本的請求類型，GET、POST和HEAD，
這些請求方法的實現(xiàn)方式均與上例相同，客戶程序用大寫指令將請求發(fā)送給服務(wù)器，后面
跟隨具體的數(shù)據(jù)。

　　GET請求最為常見，它后面跟隨一個網(wǎng)頁的位置，服務(wù)器接受請求并返回其請求的頁
面。除了頁面位置作參數(shù)之外，請求還可以跟隨協(xié)議的版本如HTTP/1.0等作為參數(shù)，以發(fā)
送給服務(wù)器更多的信息。

　　POST請求要求服務(wù)器接收大量的信息，除了POST后面跟隨的參數(shù)之外，瀏覽器還會在
后面持續(xù)發(fā)送數(shù)據(jù)，讓服務(wù)器進行處理。通常，POST方法是和CGI程序分不開的，服務(wù)器
應(yīng)該啟動一個CGI程序來處理POST發(fā)送來的數(shù)據(jù)。

　　HEAD請求在客戶程序和服務(wù)器之間進行交流，而不會返回具體的文檔。當使用GET和
POST方法時，服務(wù)器最后都將結(jié)果文檔返回給客戶程序，瀏覽器將刷新顯示。而HEAD請求
則不同，它僅僅交流一些內(nèi)部數(shù)據(jù)，這些數(shù)據(jù)不會影響瀏覽的過程。因此HEAD方法通常不
單獨使用，而是和其他
的請求方法一起起到輔助作用。一些搜尋引擎使用的自動搜索機器人使用這個方法來獲得
網(wǎng)頁的標志信息，或者進行安全認證時，使用這個方法來傳遞認證信息。

　　除了這三種最常見的訪問方法之外，在HTTP
1.1中還定義了更多的訪問方法類型，如PUT，用于將網(wǎng)頁放置到正確位置，DELETE用于刪
除相關(guān)文檔等。這些方法并不常用，因而大部分Web服務(wù)器軟件并沒有實現(xiàn)他們。然而對
于特定場合他們還是非常有用的，例如使用軟件編輯網(wǎng)頁時，網(wǎng)頁編輯器可以使用這些方
法，治理不同的網(wǎng)頁。

　　假如服務(wù)器不支持客戶發(fā)送的請求方法，服務(wù)器將返回錯誤并立即關(guān)閉連接。


服務(wù)器對HTTP的處理方式

　　HTTP協(xié)議的這種請求/回應(yīng)的模式，使得服務(wù)器只能根據(jù)客戶程序的請求發(fā)送回信息
，這樣的好處是客戶具備很大的自由度，可以任意訪問服務(wù)器上的信息。因此就存在多個
客戶同時訪問一個服務(wù)器的問題。

　　在Unix下，由一個守護進程來監(jiān)視來自客戶程序的請求，當守護進程接受到一個請求
時，就建立一個新的進程對請求進行處理。通常服務(wù)器能創(chuàng)建足夠多的新進程往返應(yīng)客戶
的請求，然而假如同時發(fā)送請求的客戶太多，那么服務(wù)器就有可能出現(xiàn)超載的情況，創(chuàng)建
進程的速度跟不上眾多
客戶發(fā)送請求的速度，這樣就造成了服務(wù)器對外表現(xiàn)反應(yīng)遲緩。此外，為了提高用戶使用
瀏覽器時的性能，現(xiàn)代瀏覽器還支持并發(fā)的訪問方式，瀏覽一個網(wǎng)頁時同時建立多個連接
，以迅速獲得一個網(wǎng)頁上的多個圖標，這樣能更快速完成整個網(wǎng)頁的傳輸。但是對服務(wù)器
來講，更增加了瞬間負
載。

　　顯然，造成這個問題的要害是服務(wù)器對HTTP協(xié)議的處理方式，一次請求就要建立一個
連接，在網(wǎng)頁上布滿了多個較小的圖象文件的時候，那么服務(wù)器和客戶程序之間的大部分
工作是用于建立連接，而真正用于傳遞數(shù)據(jù)的工作卻很輕松。因此，更好的利用現(xiàn)有連接
，減少建立連接的消耗
，就需要能在一次連接中回應(yīng)多個請求。在HTTP1.1中提供了這種持續(xù)連接的方式，而下
一代HTTP協(xié)議：HTTP-NG更增加了有關(guān)會話控制、豐富的內(nèi)容協(xié)商等方式的支持，來提供
更高效率的連接。

　　除了針對每次請求都建立一個新進程的處理方式之外，HTTP守護進程也能使用其他的
方式處理多個請求，例如使用多線程，或者使用異步方式在不同請求之間進行切換，就能
在一個進程內(nèi)處理多個請求。雖然比起建立新進程來講，這樣消耗的處理器資源略微減少
，但是并不能從根本上
消除并發(fā)訪問帶來的處理器資源不足的問題。一般使用線程和異步方式的程序較為復雜，
不能很輕易擴充對新特性的支持，并有可能因為程序內(nèi)部要自己進行同步等原因也會造成
資源消耗。使用這些方式，雖然對處理靜態(tài)的網(wǎng)頁有好處，但對于執(zhí)行CGI程序，仍然要
創(chuàng)建子進程進行處理。
因此，大部分運行在Unix上的守護程序仍然使用多進程的方式，這種方式簡單卻有效。

　　即使對于使用多進程方式進行處理的Web服務(wù)器，也有不同的處理方式。Unix系統(tǒng)中
提供了超級服務(wù)器進程inetd，因此簡單的Web服務(wù)器可以使用inetd來啟動真正的Web服
務(wù)器。然而，inetd效率不高，使用in
etd的服務(wù)器不能用作高負載的服務(wù)器系統(tǒng)，因此高負載的Web服務(wù)器，本身來監(jiān)聽客戶連
接請求，并負責啟動子進程真正處理客戶的請求。

　　假如選擇的服務(wù)器程序的確需要使用inetd來啟動，可以選擇與inetd功能相同，但效
率更高的超級服務(wù)器進程tcpserver，它可以比inetd更高效的啟動服務(wù)進程。