web伺服器架構

基礎知識普及：

http: HyperText Transfer Protocol: 超文本傳輸協定

它不僅能夠保證計算機快速地傳輸超文本文檔，還能确定傳輸文檔中的哪一部分，以及哪部分内容先顯示（如文本先于圖形）等。

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張p_w_picpath，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是所有伺服器裡面做反向代理最牛的。之後的文章我将圍繞ngix進行展開普及。

代理

Web代理伺服器工作于web用戶端和web伺服器之間，它負責接收來自于用戶端的http請求，并将其轉發至對應的服務；而後接收來自于服務端的響應，并将響應封包回送至用戶端。