web伺服器架構

標籤：web伺服器詳解

基礎知識普及：

http: HyperText Transfer Protocol: 超文字傳輸通訊協定 (HTTP)

它不僅能夠保證電腦快速地傳輸超文字文件，還能確定傳輸文檔中的哪一部分，以及哪部分內容先顯示（如文本先於圖形）等。

http協議是一個應用程式層協議，由請求和響應構成，是一個標準的用戶端伺服器模型。HTTP是一個無狀態的協議。

能夠在文檔中實現跳轉的協議；

web：能夠讓所有人實現http協議，使用的版本是0.9的版本；

http/0.9:僅支援純文字（超級連結）格式，ASCII；

HTML：編寫超文本的語言；HYPER TEXT Mark Language;

使用者通過用戶端瀏覽器進行瀏覽的時候能夠變成固定的格式。

Browser（瀏覽器）：用戶端

資源：

比如：

1.1.1.1：伺服器上面提供一個web頁面，叫做a.html;

2.2.2.2: 伺服器上面也提供一個web頁面，也叫做a.html;

但是僅僅依靠文檔名，是無法讓使用者識別不同的文檔的。

於是出現了：

URI：Unifom Resource  Indentifier；在互連網上可以在全域唯一引用某一個服務的方式；統一資源定位器。

統一：路徑格式上的統一；叫做統一資源識別項；統一資源識別項有一個子物件叫做URL。統一資源定位器。

URL：統一資資源定位器。

protocol：//HOST:port/path/to/file

http://www.zledu.com/download/linux.tar.gz說明：協議名字：主機名稱；路徑

資源:每一個圖片都是一個資源；

而多個資源很可能被整合為一個html文檔；

web對象與web資源是同一個概念。

資源訪問的方法：HTTP方法；可以跨越不同的主機，對資源進行整合，然後在同一個頁面進行展示。

既然頁面是有資源群組成的，那麼我們訪問伺服器的時候，如何擷取伺服器上的資源？目前我們既可以將本地的資料

傳到遠端，也可以將遠端的顯示到當前頁面。因此資源擷取的方式不同。我們稱為http方法。

http；0.9版本的時候只有這一種方法叫做GET；擷取遠端伺服器的資源到本地。通過瀏覽器進行顯示。

http協議1.0的方法有如下幾種：PUT,POST,DELETE；

put：修改伺服器上面的內容；

POST：向指定的資源提交要被處理的資料；通過表單進行處理。

GET：請求擷取Request-URI所標識的資源；從指定的資源請求資料；直接從伺服器上擷取資源到本地；

DELETE：請求伺服器刪除Request-URI

http協議一共有8種方法，最常用的方法就上面幾種方法類型。

MIME：Multipurpose Internet Mail Extension，多用途互連網郵件擴充。將非文本資料在傳輸前重新編碼為文字格式設定，

接收方能夠用相反的方式將其重新還原為原來的格式，還能夠調用相應的程式來開啟此檔案。

SMTP: Simple Mail Transmission Protocol, 純文字 早期傳輸郵件只能傳輸純文字的資料。

http協議將mime協議引入到其中，導致現在瀏覽器能夠獲得各種各樣的資料。瀏覽器以外掛程式的形式來解析mime傳輸的各種文檔的。如pdf。

動態網頁：正是由於外掛程式的出現，出現了動態網頁。

動態網頁：伺服器端儲存的文檔是非html格式，而是程式設計語言開發的指令碼。指令碼接受參數之後在伺服器運行一次，

運行完成之後會產生HTML格式的文檔，把產生的文檔發給用戶端；這樣一來伺服器端就需要運行解譯器，

伺服器端承受的壓力就會比較大。

web伺服器不能夠幫我們執行這些指令碼？web伺服器不能幫我們執行這些指令碼web伺服器需要藉助額外的工具來實現。

 

web伺服器常見的有APACHE,NGIX,LIGHTTPD,TOMCAT。

如：asp，php。結尾的。web伺服器會根據某種協議去調用php的解譯器，讓其運行index.php的指令碼。將產生的文檔再通過協議返回給

web伺服器。web伺服器再返回給用戶端。web伺服器只是一個http伺服器。

詳細講解使用者訪問web伺服器的整個過程？

簡單點訪問原理：用戶端使用者發送一個http請求，http請求到達伺服器之後。先進入伺服器的核心空間，伺服器的核心空間，將其進行解析。

發現其實一個web請求。然後將其給原生使用者進程http進程。http進程再發送一個請求，到核心空間，核心空間將我們

要訪問的資料從硬碟上提取出來。返回給我們的使用者空間進程。使用者空間進程再將其內容發送給核心空間。

核心空間經過層層轉換髮送給用戶端。

複雜點訪問原理：用戶端使用者發送一個http請求，http請求到達伺服器之後。先進入伺服器的核心空間，伺服器的核心空間，將其進行解析。

發現其實一個web請求。然後將其給原生使用者進程http進程。http進程發現其要訪問的是動態網頁，通過其他協議，

首先調用動態網頁的程式即動態網頁解譯器再將內容給送到核心空間，核心空間將我們要訪問的資料從硬碟上提取出來進行處理。返回給我們的

   使用者空間的的解譯器進程。解譯器進程再將產生的文檔再通過協議返回給web使用者進程。web伺服器再將其發送給我們的核心

。核心空間經過層層轉換髮送給用戶端。

一個使用者訪問我們需要開啟一個進程，1萬個使用者過來訪問就需要開啟更多的進程。這個時候就需要更多的系統資源。

動態網頁：包含靜態內容和動態內容。當動態程式運行完之後，一併返回給用戶端。

http協議1.0之後，這些都能夠滿足這些需要了。當然1.0當中我們也引入了緩衝的機制。

從純靜態頁面來講：

www.zledu.com         首先使用dns將FQDN解析成IP地址；然後再去訪問這個主機。伺服器端接受請求之後。

兩種方式：阻塞:一直處於等待狀態；

  非阻塞：需要過一段時間，過來進行請求訪問。輪詢模式；

 

IP首部：

Source IP   

Destination IP

TCP

Source   port

Destination Port

HTTP首部:明確定義我要基於這個主機訪問那些資源；

GET/2.HTML

    HOST：wwwzledu.com(虛擬機器主機）

HTTP格式的報文：請求報文，響應報文。

請求報文文法：

<method>#資源擷取方法 <request-URL>#您請求的資源是什麼； <version> #對應請求協議的版本號碼；

<headers>#http協議首部；

#空白行是必須的；

<entity-body> #報文主體；

響應報文文法：

<version>#對應的協議版本 <status>#狀態代碼，標明存在的結果是否正確；<reason-phrase>#具體解釋原因       ###請求行

<headers>#告訴用戶端，伺服器端的MIME類型             ###報文首部

####空白行必須的

<entity-body>#####報文主體

狀態代碼分類：

1xx：純資訊，很少用；

2xx：“成功類”的資訊；（200，201...）

3xx： 重新導向類的資訊；（301,302,304...）

4xx： 用戶端錯誤類的資訊；（404，伺服器端不存在...）

5xx： 伺服器端錯誤類資訊；(500,501....)

例如：

請求報文：

GET / HTTP/1.1          #GET後面什麼都沒有，預設獲得對方的首頁面資訊；

Host: www.zldu.com      #

Connection: keep-alive

 

響應報文：

HTTP/1.1 200 OK   #對應的協議版本，狀態代碼；後接reason-phrase。

X-Powered-By: PHP/5.2.17#header內容

Vary: Accept-Encoding,Cookie,User-Agent#

Cache-Control: max-age=3, must-revalidate#

Content-Encoding: gzip#內容編碼機制

Content-Length: 6931#內容格式的長度

上面兩個報文的第一行通常稱作報文“起始行(start line)”；後面的標籤格式的內容稱作首部域(Header field)，

每個首部域都由名稱(name)和值(value)組成，中間用逗號分隔。

另外，響應報文通常還有一個稱作Body的資訊主體，即響應給用戶端的內容。

web伺服器的主要操作有哪些：

1、建立串連——接受或拒絕用戶端串連請求；

2、接收請求——通過網路讀取HTTP請求報文；

3、處理請求——解析請求報文並做出相應的動作；

4、訪問資源——訪問請求報文中相關的資源；

5、構建響應——使用正確的首部產生HTTP響應報文；

6、發送響應——向用戶端發送產生的響應報文；

7、記錄日誌——當已經完成的HTTP事務記錄進記錄檔；

綜上所述，要開發一個web伺服器也是很簡單的，只需要能夠解碼協議，響應請求，訪問資源，構建報文，記錄日誌即可。

那麼緩衝到底是幹什麼的？

想象這樣一種情境：我們需要擷取這樣的一個網頁內容：10張image，3個css樣式，5個htmls。那麼這個網頁包含了18個請求；

這18個請求是一個一個請求的，還是一塊請求的。注意：每一個資源都是單獨請求，單獨傳輸的。那麼我開啟一個web頁面就要

發送n次請求（因為每一個資源都要單獨請求）。當我們開啟一個比較慢的網站的時候，都是先有文字，後出現圖片的。其實圖片

內容太大了，發送的比較慢些。因此為了讓用戶端開啟我們的網站速度快點，我們的瀏覽器多數都是多線程的。比如IE6是4線程的。

google瀏覽器是2個線程的。這樣每個線程發送一個請求，多個資源同時往本地拉取。這樣看著網頁的速度會稍微快點。

http協議是基於tcp的協議。三向交握，四次斷開。

這樣的話伺服器端的壓力非常大，因此就需要緩衝機制。清理垃圾就會將我們的流量給增大了。

http1.0裡面引入的機制就有緩衝的機制。

http1.1版本：

增強了緩衝的功能；

引入了長串連的機制。（表示用戶端與伺服器之間擷取一個資源之後，不斷開，繼續擷取第二個資源等等）。

大多數情況下，使用長串連能夠大大的提高伺服器的效能。

設定長串連的逾時時間。

Web伺服器處理並發串連請求的架構方式：

1、單線程web伺服器(Single-threaded web servers)（單進程）

此種架構方式中，web伺服器一次處理一個請求，結束後讀取並處理下一個請求。在某請求處理過程中，其它所有的請求將被忽略，

因此，在並發請求較多的情境中將會出現嚴重的問題。

2、多進程/多線程web伺服器

此種架構方式中，平時有一個伺服器處理序工作著，自己不響應，產生一個子進程。

web伺服器產生多個進程或線程平行處理多個使用者請求，進程或線程可以按需或事先產生。

有的web伺服器應用程式為每個使用者請求產生一個單獨的進程或線程來進行響應，優點就是穩定性還可以。早期

大量的伺服器使用的是這個類型的架構方式。不過，一旦並發請求數量達到成千上萬時，多個同時啟動並執行進程或

線程將會消耗大量的系統資源。

3、I/O多工web伺服器（這種機制是，自己一個人負責多個使用者的請求。如何完成的呢？一個進程來完成多個使用者的響應請求，這個進程只負責將使用者請求，接進來。

採用輪詢的狀態檢查機制，每隔固定時間挨個進行查詢響應的具體情況即可。當發現某一個完成了，將其響應給固定的客戶即可。

效果也不太好。最佳化下就成了事件處理機制型的。每個客戶響應都有一個狀態代碼，只查看狀態代碼即可。但是也需要掃描一遍，這樣開銷也挺大的。第三種就是

當狀態發生變化之後，主動通知我，自己管理自己。這樣就可以一個進程處理多個請求，而且每一個請求都有自己的狀態，而且這個請求還可以向我發送通知。發送

通知的方法有兩種：水平觸發和邊緣觸發。水平觸發是只通知一次，無論你是否進行處理。這個呢，類似於你在逛大賣場，你在某家店預訂了一碗飯，飯好之後，在大螢幕

滾動播出一次。邊緣觸發是定期發送通知，直到該進程進行處理邊不發送。但這兩種都不太好，又引入了第三中觸發機制，直接發送通知到進程本身。類似於簡訊通知）

為了能夠支援更多的並發使用者請求，越來越多的web伺服器正在採用多工架構——同步監控所有的串連請求的活動狀態，

當一個串連的狀態發生改變時(如資料準備完畢或發生某錯誤)，將為其執行一系列特定操作；在操作完成後，此串連將重新

變回暫時的穩定態並返回至開啟的串連列表中，直到下一次的狀態改變。由於其多工特性，進程或線程不會被空閑

的串連所佔用，因而可以提供高效的工作模式。但是如果這個進程服務於過多的使用者，多個使用者同時通知進程我已經好了，進程響應使用者的請求還是會吃緊。

4、多工多線程web伺服器（有一個進程叫做master進程，不響應任何的請求工作。只負責將響應接進來。分配給自己管理的進程，

交給一個自己複製的進程，自己用來管理，將使用者請求，分給哪一個進程，每一個進程可以接受多個使用者請求。一個進程處理固定數目的使用者請求，

當請求數目多的時候，複製多個進程。請求不多的時候，銷毀多餘的進程，留下幾個進程即可。）

將多進程和多工功能結合起來形成的web伺服器架構，其避免了讓一個進程服務於過多的使用者請求，並能充分利用多CPU主機所提供的計算能力。

總結：

web伺服器是C/S架構的模型或者B/S架構：

C（CLIENT）（用戶端代理程式，BROWSER(瀏覽器）,spider（蜘蛛））

client--》request-->server

URL

S（Server）：

server-->response--->client

http method:get,head,post,put,delete,trace,options,connect.最常用的方法是前三種。

http headers(http首部類別非常多）：

Name：VALUES

host：www.zledu.com

connection:keep-alive;

httpd軟體：提供的模型有prefork，work，event。三種模型對應上面不同的架構方式。

http用戶端類型：IE,FIREFOX,CHROME,OPERA,SAFARI...

伺服器端類型：APACHE,IIS，ngix，lighttpd,thttpd....

應用程式伺服器：這種伺服器不但能夠處理靜態內容，還能夠處理某種特定格式的動態內容。常用的有：IIS,TOMCAT（支援解析java）開源的、Websphere（IBM，jsp）商業產品。

weblogic(Oracle,JSP,commodity);JBOSS(REDHAT)：核心是一個tomcat，都可以提供web伺服器。

www.netcraft.com這裡可以查看最近的全球互連網上web伺服器所佔的比例。

發現ngix是所有伺服器裡面做反向 Proxy最牛的。之後的文章我將圍繞ngix進行展開普及。

代理

WebProxy 伺服器工作於web用戶端和web伺服器之間，它負責接收來自於用戶端的http請求，並將其轉寄至對應的服務；而後接收來自於服務端的響應，並將響應報文回送至用戶端。

本文出自 “汗水成就夢想” 部落格，請務必保留此出處http://redhatdragon.blog.51cto.com/9183870/1441261

web伺服器架構