基礎知識普及：
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請求，並將其轉發至對應的服務；而後接收來自於服務端的響應，並將響應報文回送至客戶端。