httpd协议概述
HTTPD協議詳解
http簡介
HTTP：全稱為HyperText ?Transfer Protocol（超文本傳輸協議），是目前互聯網使用最多最廣泛的一種協議。在早期的HTTP協議版本（http/0.9）中，http服務僅支持二進制（ASCII）的純文本文件。而在http/0.9以后的版本中，http協議可以支持MIME機制，使得http協議可以支持多種格式的文本文件，例如視頻、圖像、語音等等。從而豐富了http協議的發展。
?
什么是MIME？
MIME：全稱是Mulitpurpose ?Internet ?Mail Extension,多用途郵件擴展，MIME是一種協議，早期應用于郵件系統，后來該協議也被應用到了瀏覽器當中，所以至今我們打開某個網頁時，可以出現多種格式的文本信息。這是因為MIME引進了base64編碼機制，它能夠將非文本信息（如二進制格式的數據）在傳輸前重新編碼為文本格式，接收方能夠用相反的機制將其還原為原來的格式，并且可以調用相應的程序來打開此文件。
?
什么是URI和URL？
我們在打開某一個頁面時，常常看到有圖片、視頻及文檔等信息，我們把這樣每一個信息叫做一個資源或者也可以稱作一個web對象。多個資源或者web對象就組成了一個html格式的頁面。 而我們常常打開瀏覽器時，在瀏覽器上面需要輸入網址，才可以訪問那個頁面的資源。這個網址就是我們常說的URL。
URL：全稱Uniform ?Record ?Locator，統一資源定位符，它不僅定義了資源，還明確指定了資源所在的位置。
URL通常由以下三部分組成：
a、方案（其實簡單的理解就是我們常說的訪問協議，如http、ftp等）
b、存放資源的主機地址（主機名或ip，有時也包括端口號）
c、資源的具體路徑（文件名或目錄）
如http://www.baidu.com/a/a.html這就是一個URL。其中方案為http，主機為www.baidu.com，資源路徑為/a/a.html。
?
有時候我們也會常常看到URI，那么URI是什么呢？它和URL是什么關系？
URI：全稱Uniform Record ?Indentifier，全局統一資源標識符，它籠統地定義了資源且是全局的，不限于客戶端和服務器端，雖然URI也是用來定義資源的，但是它的定義是抽象的，而URL是具體的定義了這個資源的所在位置，因此URL是URI的子對象或者是子集。
?
但是我們常常在點擊某個頁面時，瀏覽器上面顯示的不是以.html為后綴的URL，而是以.php為后綴的URL。這是什么原因造成的呢？
這是因為在我們的web服務器上面存的并不是html格式的文件，而是一些腳本文件，當客戶端發起請求時，web服務器會調用某個協議來執行這些腳本，這些腳本執行完畢后，就會生成一個html格式的文檔，web服務器在將生成的HTML格式的文檔返回給客戶端。這就是我們為什么看到的是一個html格式的文檔，而瀏覽器上面顯示的就是以.php為后綴的URL。而這種腳本文件是通過PHP語言來實現的。而這種機制就是動態網頁的實現機制。
對于動態網頁來說，既包括靜態內容也包括動態內容。
靜態內容一般指的是圖片等信息，這些靜態內容是直接存在服務器是上的。
動態內容需要通過腳本來執行，所以一般的，只有動態內容才會運行腳本，靜態內容不會。
?
在有些時候，我們打開某個網頁會很快，但打開其他的頁面時會很稍微慢一點，這是為什么呢？
這是在http/1.0以后，由于增加了緩存機制，所以當我們第一次打開某個網頁時，web服務器會將這個URL緩存在本地，所以第二次打開網頁時明顯要比第一次快些。因此，建議大家不要隨便清理緩存，這樣會導致網頁加載速度比較慢哦！
?
http的報文格式
由于http是基于tcp協議的，所以在建立http會話的過程中，會經歷過三次握手和四次斷開。因此，當客戶端發起時，服務器必須對該請求給予響應。http協議的端口號是80
http報文的請求格式
<method> ?<request-URI> ?<version>
<headers>????
<entity-body>
?
http報文的響應格式
<version> <status> ?<reason-phrase>
<headers>
<entity-body>
?
其中<method>表示為請求的方法。一般常用的方法有GET、POST、HEAD、DELETE、PUT等等。
<request-URI>表示請求的URI地址。
<version>表示http協議的版本號。
<headers>表示http的首部信息。首部信息一般有多行，每一行使用name:value的形式顯示。
<entity-body>表示的是報文主體，報文主體分為請求報文主體和響應報文主體。
<status>表示的是響應報文的狀態碼。
<reason-phase>:用來描述響應的結果或者理解成用來描述狀態碼的文本信息。
?
http協議版本
http0.9：只能傳輸html文檔；
http1.0：支持多媒體數據的處理，保持連接。有緩存功能；
http1.1：支持更多的請求方法，更加精細的緩存控制，支持持久連接；
?
http的請求方法
http的請求方法大概有如下這些：
GET、HEAD、PUT、POST、DELETE、OPTIONS、TRACE等等。常用的請求方法及其功能有如下幾種：
| 請求的方法類型 | 該方法的用途 |
| GET | 請求獲取一個資源，該資源需要服務器發送。 |
| HEAD | 和GET方法相似，只不過服務不需要發送資源，只返回響應首部信息。 |
| PUT | 與GET方法相反，用于上傳信息，向服務器寫入文檔。用于發布系統。 |
| POST | 支持HTML表單提交，表單中有用戶填入的數據，這些數據會上傳至服務器，并存儲到某個位置。 |
| DELETE | 請求刪除URL指向的資源。 |
| OPTIONS | 探測服務器端對某資源所支持的請求方法。 |
| TRACE | 追蹤資源所經過的代理、防火墻和網關。 |
?
?
http的響應狀態碼
http的狀態碼主要分為這幾類：
1xx:表示純信息。
2xx:表示成功狀態碼（例如：200、201、202...）
????????200：表示ok，響應成功。
3xx:表示重定向類的狀態碼（例如301，302，304），表示該資源不在此處，重定向到其他服務器或其他位置去了。
????????301：Moved? Permanebtly，表示永久重定向。在響應報文中使用"Location:URL"的方式來指定該資源所在的位置，然后在向該資源現在所在的服務器發起請求。以后客戶端在請求該資源時，直接請求Location中指定資源的位置，不在向本服務器發起請求，這就是所謂的永久重定向。
????????302：Found，表示臨時重定向。在響應報文中使用"Location:URL"的方式來指定該資源臨時存放的位置，然后在向該資源現在所在的位置發起請求。當客戶端下次請求該資源時，仍然向本服務器發起請求。由于是臨時重定向，因此資源位置并不是固定的。
????????304：Not modify，資源沒有被修改，用于http條件式緩存機制中。
4xx:表示客戶端錯誤類狀態碼（例如403，404）。
????????401：服務器端拒絕客戶端請求，說明請求時需要提供用戶名和密碼。
????????403：Forbidden，請求被服務器拒絕。可能由于沒有權限導致的。
??????? 404：Not Found，服務器端無法找到請求的URL，該資源可能不在該服務器上。
??????? 405：Method Not Allow，不允許使用此方法來請求響應的URL。
5xx:表示服務器端錯誤類狀態碼。
????????500：Internet Server Error，服務器內部錯誤。
????????502：Bad Gateway，代理服務器從上游收到一條偽響應。
??????? 503：Service? Unavailable，服務器此時無法提供服務，但是將來可能有用。
?
?
http報文首部
http的報文首部包括：通用報文首部、請求報文首部、響應報文首部這三大類。
通用首部：通用首部既可以用于請求報文首部中又可以用于響應報文首部中。
????????Connection：定義C/S之間關于請求/響應的有關選項；
????????Via：顯示了報文經過的中間節點（代理或網關）；
??????? Cache-Control：緩存指示；
??????? Pragma?：另一種隨報文傳送指示的方式，但并不專用于緩存；
?
請求報文首部
?????? Cilent-IP：請求端IP；
?????? Host：請求的主機名和端口號，在虛擬主機環境下用于不同的虛擬主機；
?????? Referer：指明了請求當前資源的原始資源的URL，即當前資源從哪個URL跳轉過來的。
?????? User-Agent：用戶代理，客戶端使用什么工具發出的請求；
?????? Accept首部：用戶標明客戶自己更傾向于支持使用的能力；
???????Accept：指明服務器能發送哪些媒體類型；
???????Accept-Charset：客戶端支持使用的字符集；
???????Accept-Encoding：客戶端支持使用的編碼方式；
???????Accept-Language：客戶端支持使用的語言；
?????? 條件請求首部：
???????Expect：允許客戶端列出某請求要求服務器的行為；
???????If-Modified-Since：是否在指定的時間以來修改過此資源；
???????If-None-Match
???????跟安全相關的請求首部：
???????Authorization：客戶端提交給服務端的認證數據，如賬號和密碼及認證算法；
???????Cookie：客戶端發送給服務器端身份標識,這樣服務器端就可以判斷該客戶端之前是否訪問過。
???????Cookie2
代理請求首部：
???????Max-Forword?：在通往后端服務器的路徑上，將請求轉發給其他代理或網關的最大次數-與TRACE方法一同使用
?????? Proxy-Authorization ：與Authorization首部相同，但這個首部是在與代理進行認證時使用的
?????? Proxy-Connection ：與Connection首部相同，但這個首部是在與代理建立連接時使用的
?
響應報文首部：
?????? Age：響應持續的時間
?????? Server：向客戶端標明服務器程序名稱和版本
???????public：服務器支持某資源的請求方法列表
?????? 協商首部：
?????? Accept-Ranges：對當前資源來講，服務器所能夠接受的范圍類型；
?????? Vary：?服務器查看的其他首部的列表，可能會使響應發生變化；也就是說，這是一個首部列表，服務器會根據這些首部的內容挑選出最合適的資源版本發送給客戶端。
??????? 跟安全相關的響應首部
????????Proxy-Authenticate 來自代理服務器對客戶端的質詢列表；
??????? Set-Cookie：服務器端在某客戶端第一次請求時發給的令牌；
??????? Set-Cookie2：
??????? WWW-Authenication：質詢，即要求客戶端提供賬號和密碼；
??????? 實體首部：
??????? Location：資源的新位置；
??????? Allow：允許對此資源使用的請求方法；
??????? 內容首部：
????????Content-Encoding：??????實體使用的編碼方式
????????Content-Language：???? 實體所使用的語言
????????Content-Length：?????????? 實體的長度或尺寸
????????Content-type?：????????????? 實體的類型
????????Content-Range：?????????? 實體的字節范圍
????????Content-Location：?????? 資源實際所處的位置
??????? 緩存首部：
??????? ETag：與實體有關的實體標簽；
??????? Expires：實體內容過期標簽；
??????? Last-Modified：實體內容上一次的修改時間；
?
?
?
例如：請求報文：
GET / HTTP/1.1
Host: www.xsl.com
Connection: keep-alive
?
響應報文：
HTTP/1.1 200 OK
X-Powered-By: PHP/5.2.17
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服務器的工作流程?
web服務器是如何工作的呢？
web服務器的主要操作：
1、建立連接---接受或拒絕客戶端的連接請求
2、接受請求---通過網絡讀取HTTP請求報文
3、處理資源---解析請求報文并作出相應的動作
4、訪問資源---訪問請求報文中的相應資源
5、構建響應---使用正確的首部生成HTTP響應報文
6、發送響應---向客戶端發送生成的響應報文
7、記錄日志---把已經完成的HTTP事務記錄進日志文件
?
?
Web服務器處理請求的幾種架構：
1、單線程web服務器(Single-threaded web servers)
此種架構方式中，web服務器只生成一個進程或線程，因此一次只處理一個請求，結束后讀取并處理下一個請求。在某請求處理過程中，其它所有的請求將被忽略，因此，在并發請求較多的場景中將會出現嚴重的必能問題。
?
2、多進程/多線程web服務器
此種架構方式中，web服務器生成多個進程或線程并行處理多個用戶請求，進程或線程可以按需或事先生成。有的web服務器應用程序為每個用戶請求生成一個單獨的進程或線程來進行響應，不過，一旦并發請求數量達到成千上萬時，多個同時運行的進程或線程將會消耗大量的系統資源。
?
3、I/O多路復用web服務器
為了能夠支持更多的并發用戶請求，越來越多的web服務器正在采用多路復用的架構——同步監控所有的連接請求的活動狀態，當一個連接的狀態發生改變時(如數據準備完畢或發生某錯誤)，將為其執行一系列特定操作；在操作完成后，此連接將重新變回暫時的穩定態并返回至打開的連接列表中，直到下一次的狀態改變。由于其多路復用的特性，進程或線程不會被空閑的連接所占用，因而可以提供高效的工作模式。這種結構下，一個線程處理多個請求。
?
4、多路復用多線程web服務器
將多進程和多路復用的功能結合起來形成的web服務器架構，其生成多個線程，每一個線程響應多個請求。避免了讓一個進程服務于過多的用戶請求，并能充分利用多CPU主機所提供的計算能力。由于一個進程生成多個線程，這些生成的線程之間的資源是共享的，因此會產生資源。
?
?
?
?
?
轉載于:https://blog.51cto.com/xslwahaha/1548852
總結
- 上一篇： Ext.js4.x 的面板中嵌入UEdi
- 下一篇： 法制宣传标语文案30句