12.1 http協議簡介

http（HyperText Transfer Protocol，超文本傳輸協議）是互聯網上應用最為廣泛的一種網絡協議。所有的www文件都必須遵守這個標準。設計HTTP最初的目的是為了提供一種發布和接收HTML頁面的方法。1960年美國人Ted Nelson構思了一種通過計算機處理文本信息的方法，並稱之為超文本（hypertext)。這成為HTTP超文本傳輸協議標準架構的發展根基。

超文本就是帶有超鏈接的文本，超鏈接就是基於一些鏈接實現文檔間跳轉的文本。

http協議是一種無狀態的協議（stateless）：

服務器無法持續追蹤訪問者來源，為了解決此問題引入了cookie和session，實現追蹤與保存用戶的行為

12.2 http技術架構

http是一個客戶端和服務器端請求和應答的標準（TCP）。客戶端是終端用戶，服務器端是網站。

通過使用web瀏覽器、網絡爬蟲或者其它的工具，客戶端發起一個到服務器上指定端口（默認端口為80）的HTTP請求。

這個客戶端被稱作用戶代理（User Agent）。

應答的服務器上存儲著一些資源，比如HTML文件和圖像，這個應答服務器被稱作源服務器（Origin Server）。

在用戶代理和源服務器中間可能存在多個中間層，比如代理，網關，或者隧道。盡管TCP/IP協議是互聯網上最流行的應用，HTTP協議並沒有規定必須使用它和基於它支持的層。事實上，HTTP可在任何其他互聯網協議上，或者在其他網絡上實現。HTTP只假定其下層協議提供可靠的傳輸，任何能夠提供這種保證的協議都可以被其使用。

通常，由HTTP客戶端發起一個請求，建立一個到服務器指定端口的TCP連接。HTTP服務器則在那個端口監聽客戶端發送過來的請求。一旦收到請求，服務器向客戶端發回一個狀態行，比如“HTTP/1.1 200 OK”和響應的消息，消息的消息團體可能是請求的文件、錯誤消息或者其它一些信息。HTTP使用TCP而不是UDP的原因在於打開一個網頁必須傳送很多數據，而TCP協議提供傳輸控制，按順序組織數據和錯誤糾正。

通過HTTP或者HTTPS協議請求的資源由統一資源標示符（Uniform Resource Identifiers）來標識。

12.3 http協議功能

http協議是用於從www服務器傳輸超文本到本地瀏覽器的傳輸協議。它可以使瀏覽器更加高效，使網絡傳輸減少。它不僅保證計算機正確快速地傳輸超文本文檔，還確定傳輸文檔中的哪一部分以及哪些部分內容首先顯示（如文本先於圖形）等。

http是客戶端瀏覽器或其他程序與web服務器之間的應用層通信協議。在internet上的web服務器上存放的都是超文本信息，客戶機需要通過http協議傳輸所要訪問的超文本信息。http包含命令和傳輸信息，不僅可用於web訪問，也可以用於其他因特網/內聯網應用系統之間的通信，從而實現各類應用資源超媒體訪問的集成。

我們在瀏覽器的地址欄裏輸入的網站地址叫做URL（Uniform Resource Locator，統一資源定位符）。就像每家每戶都有一個門牌地址一樣，每個網頁也都有一個internet地址。當你在瀏覽器的地址框中輸入一個URL或是單擊一個超鏈接時，URL就確定了林瀏覽的地址。瀏覽器通過HTTP將web服務器上站點的網頁代碼提取出來，並翻譯成漂亮的網頁。

12.4 http協議版本

超文本傳輸協議已經演化出了很多版本，它們中的大部分都是向下兼容的。在RFC 2145中描述了HTTP版本號的用法。客戶端在請求的開始告訴服務器它采用的協議版本號，而後者則在響應中采用相同或者更早的協議版本。

http協議的版本主要有以下這些：

HTTP/0.9：最原始版本，功能簡陋。只接受GET一種請求方法，沒有在通訊中指定版本號，且不支持請求頭。由於該版本不支持POST方法，所以客戶端無法向服務器傳遞太多信息。

HTTP/1.0：這是第一個在通訊中指定版本號的HTTP協議版本，至今仍被廣泛采用，特別是在代理服務器中。支持MIME。

HTTP/1.1：增加了緩存功能，引入了長連接（默認采用），能很好的配合代理服務器工作 ，支持以管理方式同時發送多個請求，以便降低線路負載，提高傳輸速度。

HTTP/2.0：大幅度提升了web性能，減少網絡延遲，通常用於https

HTTP/1.1相較於 HTTP/1.0 協議的區別主要體現在：

a) 緩存處理

b) 帶寬優化及網絡連接的使用

c) 錯誤通知的管理

d) 消息在網絡中的發送

e) 互聯網地址的維護

f) 安全性及完整性

12.5 名詞解釋

HTML：HyperText Mark Language，超文本標記語言

URI：Uniform Resource Indentifier，統一資源標識符。用於定義全局範圍內（包括但不僅限於互聯網）去標記唯一的、定位一種資源訪問路徑的方式，或者命名方式，被稱作統一資源標識符。這裏的統一指的是路徑格式上的統一。

URL：Uniform Resource Location，統一資源定位符，是URI的一個子集，用於描述在互聯網上互聯網資源的統一表示格式（protocol://host:port/path/to/file）

URL基本語法：

<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>

params：參數，如http://www.idfsoft.com/bbs/index.html;gender=f，這裏的gender=f就是一個參數

query：傳遞給關系型數據庫頁面的特定行為。如http://www.idfsoft.com/bbs/item.php?username=tom&title=abc，這個URL表示要查詢的是username=name並且title=abc的條目

frag：用來定義一個較大頁面中的某一個位置，而不是頁面的開始處。說白點就是位置錨定

URN：Uniform Resource Naming，統一資源命名符，也是URI的一個子集

MIME：Multipurpose Internet Mail Extension，多用途互聯網郵件擴展。

MIME可以將非文本數據在傳輸前重新編碼為文本格式再傳輸給對方，接收方能夠用相反的方式將其重新還原為原來的格式，還能夠調用相應的程序來打開此文件

http事務：http協議的一次請求（request）和響應（response）的過程就稱之為http事務

動態網頁：包含靜態內容和動態內容（動態內容需要執行）

服務器端存儲的不是HTML文檔，而是編程語言開發的腳本，腳本接受參數之後在服務器端運行一次，運行完成之後會生成HTML格式的文檔，並把生成好的HTML文檔傳給客戶端

Web資源：web resource。

靜態文件：.jpg，.gif，.html，.txt，.js，.css，.mp3，.avi

動態文件：.php，.jsp

PV：Page View，打開了多少頁面

UV：User View，獨立IP量

12.6 http協議報文

http協議采用了請求/響應模型。客戶端向服務器發送一個請求，請求頭包含請求的方法、URL、協議版本以及包含請求修飾符、客戶信息和內容的類似於MIME的消息結構。服務器以一個狀態行作為響應，響應的內容包括消息協議的版本，成功或者錯誤編碼加上包含服務器信息、實體元信息以及可能的實體內容。

http協議的報文有請求報文和響應報文2種，其語法樣式如下：

請求報文語法：

<method> <request-URL> <version>
<headers>

<entity-body>

響應報文語法：

<version> <status> <reason-phrass>
<headers>

<entity-body>

報文的第一行通常稱作報文“起始行（start line）”，後面的標簽格式的內容稱作首部域（Header Field），每個首部域由名稱（name）和值（value）組成，中間用逗號分隔。

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

method：請求方法，標明客戶端希望服務器對資源執行的動作，常見的有以下幾種：

GET：從服務器獲取一個資源

HEAD：只從服務器獲取文檔的響應首部，而不會發送響應內容。當我們只需要查看某個頁面的狀態的時候，使用HEAD是非常高效的

POST：向服務器發送要處理的數據。服務器端通常通過提供一個表單，客戶端填入數據時會把內容放入entity-body中提交提交給服務器端

PUT：將請求的主體部分存儲在服務器上。說白點就是上傳數據

DELETE：請求刪除服務器上指定的文檔

TRACE：追蹤請求到達服務器中間經過的代理服務器

OPTIONS：請求服務器返回對指定資源支持使用的請求方法

version：http的協議版本，格式如HTTP/<major>.<minor>

status：響應狀態碼，用於標記請求處理過程中發生的情況，常見的響應狀態碼有以下幾種：

1xx：100-101，純信息提示

100：服務器僅接收到部分請求，但是一旦服務器並沒有拒絕該請求，客戶端應該繼續發送其余的請求，響應狀態碼為"Continue"

101：服務器轉換協議，服務器將遵從客戶的請求轉換到另外一種協議，響應狀態碼為"Switching Protocols"

2XX：200-206，“成功”類的信息

200：請求資源正常。請求的所有數據通過響應報文的entity-body部分發送，響應狀態碼為“OK”

201：請求被創建完成，同時新的資源被創建，響應狀態碼為"Created"

202：供處理的請求已被接受，但處理未完成，響應狀態碼為"Accepted"

203：文檔已經正常地返回，但一些應答頭可能不正確，因為使用的是文檔的拷貝，響應狀態碼為"Non-authoritative information"

204：沒有新文檔。瀏覽器應該繼續顯示原來的文檔。響應狀態碼為"No Content"

205：沒有新文檔。但瀏覽器應該重置它所顯示的內容。用來強制瀏覽器清除表單輸入內容，響應狀態碼為"Reset Content"

206：客戶發送了一個帶有Range頭的GET請求，服務器完成了它

3XX：300-305，“重定向”類的信息

301：永久重定向，響應狀態碼為“Moved Permanently”

請求的URL指向的資源已經被刪除，但在響應報文中通過首部Location指明了資源現在所處的新位置，客戶端需要請求新位置的資源

302：臨時重定向，我這裏正忙，你要的資源在另一個地方也有，你先去那裏要，響應狀態碼為“Found”

與301相似，但在響應報文中通過Location指明資源現在所處的臨時新位置

304：客戶端發出了條件式請求，但服務器端發現客戶端請求的資源已被客戶端緩存過且未發生改變，讓客戶端直接到緩存裏去取。響應狀態碼為“Not Modified”

4XX：400-415，“客戶端錯誤”類的信息

400：由於客戶端請求有語法錯誤，不能被服務器所理解，響應狀態碼為“Bad Request”

401：需要輸入帳號和密碼認證方能訪問資源，響應狀態碼為“Unauthorized”

403：請求被禁止，響應狀態碼為“Forbidden”

404：服務器無法找到客戶端請求的資源，響應狀態碼為“Not Found”

5XX：500-505，“服務端錯誤”類的信息

500：服務器內部錯誤，響應狀態碼為“Internal Server Error”

502：代理服務器從後端服務器收到了一條偽響應，響應狀態碼為“Bad Gateway”

503：服務器當前不能夠處理客戶端的請求，在一段時間之後，響應狀態碼為“Service”

reason-phrass：解釋status狀態碼的情況，你成功了，是什麽成功了，你失敗了，是什麽失敗了，是獲取文件成功/失敗還是上傳文件成功/失敗等等。

headers：用來標記請求或響應的屬性

每個請求或響應報文可包含任意個首部；

每個首部都有首部名稱，後面跟一個冒號，而後跟上一個可選空格，接著是一個值

格式：Name: Value

首部的分類：

通用首部：可用在請求報文和響應報文中，常見的內容如下：

Date：報文的創建時間

Connection：連接狀態，如keep-alive，close等

Via：顯示報文經過的中間節點

Cache-Control：控制緩存的生效方法和機制

請求首部：只能在請求報文中使用，常見的內容如下：

Accept：通知服務器客戶端可以接受的媒體類型

Accept-Charset：通知服務器客戶端可以接受的字符集

Accept-Encoding：通知服務器客戶端可以接受的內容編碼格式，如gzip

Accept-Language：通知服務器客戶端可以接受的語言

Client-IP：客戶端的IP

Host：請求的服務器名稱和端口號

Referer：包含當前正在請求的資源的上一級資源

User-Agent：客戶端代理

條件式請求首部：

Expect：期望服務器端發什麽信息

If-Modified-Since：自從此處指定的時間之後請求的資源是否發生修改

If-Unmodified-Since：自從此處指定的時間之後請求的資源是否未發生修改

If-None-Match：本地緩存中存儲的文檔的ETag標簽是否與服務器文檔的ETag不匹配

If-Match：本地緩存中存儲的文檔的Etag是否與服務器文檔的Etag匹配

安全請求首部：

Authorization：向服務器發送認證信息，如帳號和密碼

Cookie/Cookie2：客戶端向服務器發送cookie

代理請求首部：

Proxy-Authorization：向代理服務器認證

響應首部：只能在響應報文中使用

信息性：

Age：響應持續時長

Server：服務器程序軟件名稱和版本

協商首部：某資源有多種表示方法時使用

Accept-Ranges：服務器可接受的請求範圍類型

Vary：服務器查看的其它首部列表

安全響應首部：

Set-Cookie：向客戶端設置cookie

Set-Cookie2：向客戶端設置cookie2

WWW-Authenticate：來自服務器的對客戶端的質詢認證表單

實體首部：標識實體的相關信息

Allow：列出對此實體可使用的請求方法

Location：告訴客戶端真正的實體位於何處

Content-Encoding：內容的編碼格式

Content-Language：內容使用的語言

Content-Length：主體的長度

Content-Location：實體真正所處的位置

Content-Type：主體的對象類型

緩存相關：

ETag：實體的擴展標簽

Expires：實體的過期時間

Last-Modified：最後一次修改的時間

擴展首部

entity-body：請求時附加的數據或響應時附加的數據，有可能為空

請求報文示例：

GET / HTTP/1.1
HOST：www.baidu.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

12.7 http周邊

常見的協議查看、分析的工具：

tcpdump

tshark

wireshark

常見的http服務器程序：

httpd（apache）

nginx

lighttpd

應用程序服務器：可以處理動態文件

IIS

tomcat，jetty，jboss，resin

webshpere，weblogic，oc4j

常用的http壓力測試工具：

ab：

語法：ab [options] URL

-n：總的請求數

-c：模擬的並發數

-k：以持久連接模式測試

webbench

http_load

jmeter

loadrunner

tcpcopy

ulimit -n #：調整當前用戶所能夠同時打開的文件數

web服務器資源路徑映射方式：

docroot

alias

虛擬主機docroot

用戶家目錄docroot

並發訪問響應模型（Web I/O）：此處假定每個進程內只有一個線程

單進程I/O結構：啟動一個進程處理請求，而且一次只處理一個，多個請求被串行響應

多進程I/O結構：並行啟動多個進程，每個進程響應一個請求

復用I/O結構：一個進程響應多個請求

多線程模型：一個進程生成多個線程，每個線程響應一個用戶請求

事件驅動

復用的多進程I/O結構：啟動多個（m）進程，每個進程響應n個請求

12.8 https

https其實就是將ssl或tls應用於http協議的結果，https監聽於tcp/443端口

ssl會話的簡化過程如下：

（1）客戶端發送可供選擇的加密方式，並向服務器請求證書

（2）服務器端發送證書以及選定的加密方式給客戶端

（3）客戶端取得證書並進行證書驗證

如果信任給其發證書的CA：

a) 驗證證書來源的合法性：用CA的公鑰解密證書上的數字簽名

b) 驗證證書內容的合法性：完整性驗證

c) 檢查證書的有效期限

d) 檢查證書是否被吊銷

e) 證書中擁有者的名字，與訪問的目標主機要一致

（4）客戶端生成臨時會話密鑰（對稱密鑰），並使用服務器端的公鑰加密此數據發送給服務器，完成密鑰交換

（5）服務器用密鑰加密用戶請求的資源，響應給客戶端

註意：SSL會話是基於IP地址創建，所以單IP的主機上，僅可以使用一個https虛擬主機

WEB服務器的主要操作：

建立連接——接受或拒絕客戶端連接請求；

接收請求——通過網絡讀取HTTP請求報文；

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

訪問資源——訪問請求報文中相應的資源；

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

發送響應——向客戶端發送生成的響應報文；

記錄日誌——當已經完成的HTTP事務記錄進日誌文件

本文出自 “忘情居” 博客，請務必保留此出處http://itchentao.blog.51cto.com/5168625/1931364

第十二章 http協議