【深刻HTTP協議】

"HTTP是（Hyper Text Transfer Protocol）超文本傳輸協議的縮寫.

HTTP的發展是萬維網協會（World Wide Web Consortium）和Internet工做小組IETF（Internet Engineering Task Force）合做的結果，（他們）最終發佈了一系列的RFC.

RFC 1945定義了HTTP/1.0版本，其中最著名的就是RFC 2616，RFC 2616定義了今天廣泛使用一個版本——HTTP 1.1

------->

HTTP協議（Hyper Text Transfer Protocol）超文本傳輸協議是用於從WWW服務器傳輸超文本到本地瀏覽器的傳送協議.

它可使瀏覽器更加高效，使網絡傳輸減小。它不只保證計算機正確快速地傳輸超文本文檔，還肯定傳輸文檔中的哪一部分，以及哪部份內容首先顯示（如文本先於圖形）等.

@

目錄

• HTTP 請求
  • HTTP請求方式大全
  • HTTP請求包括的內容
  • HTTP請求細節——請求頭
  • HTTP請求細節——消息頭
• HTTP 響應
  • HTTP響應包括的內容
  • HTTP響應細節——狀態行
  • HTTP響應細節——經常使用響應頭

 

HTTP響應模型
·
HTTP協議永遠都是客戶端發起請求，服務器回送響應，以下圖：

這樣就限制了使用HTTP協議，沒法實如今客戶端沒有發起請求的時候，服務器將消息推送給客戶端.

HTTP工做流程
·
一次HTTP操做稱爲一個事務，其工做過程可分爲四步：

1. 首先客戶機與服務器須要創建鏈接。只要單擊某個超級連接，HTTP的工做開始.
2. 創建鏈接後，客戶機發送一個請求給服務器，請求方式的格式爲：統一資源標識符（URL）、協議版本號.
   後邊是MIME(聲明文本信息)信息包括請求修飾符、客戶機信息和可能的內容.
3. 服務器接到請求後，給予相應的響應信息，其格式爲一個狀態行，包括信息的協議版本號、一個成功或錯誤的代碼.
   後邊是MIME信息包括服務器信息、實體信息和可能的內容.
4. 客戶端接收服務器所返回的信息並經過瀏覽器顯示在用戶的顯示屏上，而後客戶機與服務器斷開鏈接.

·
若是在以上過程當中的某一步出現錯誤，那麼產生錯誤的信息將返回到客戶端，由顯示屏輸出.
對於用戶來講，這些過程是由HTTP本身完成的，用戶只要用鼠標點擊，等待信息顯示就能夠了.

---

HTTP 請求

HTTP請求方式大全

序號	方法	描述
1	GET	請求指定的頁面信息，並返回實體主體。
2	HEAD	相似於get請求，只不過返回的響應中沒有具體的內容，用於獲取報頭
3	POST	向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST請求可能會致使新的資源的創建和/或已有資源的修改。
4	PUT	從客戶端向服務器傳送的數據取代指定的文檔的內容。
5	DELETE	請求服務器刪除指定的頁面。
6	CONNECT	HTTP/1.1協議中預留給可以將鏈接改成管道方式的代理服務器。
7	OPTIONS	容許客戶端查看服務器的性能。
8	TRACE	回顯服務器收到的請求，主要用於測試或診斷。
9	PATCH	實體中包含一個表，表中說明與該URI所表示的原內容的區別。
10	MOVE	請求服務器將指定的頁面移至另外一個網絡地址。
11	COPY	請求服務器將指定的頁面拷貝至另外一個網絡地址。
12	LINK	請求服務器創建連接關係。
13	UNLINK	斷開連接關係。
14	WRAPPED	容許客戶端發送通過封裝的請求。
15	Extension-mothed	在不改動協議的前提下，可增長另外的方法。

HTTP請求包括的內容

·
客戶端連上服務器後，向服務器請求某個Web資源，稱之爲客戶端向服務器發送了一個HTTP請求.
·
一個完整的HTTP請求包括的內容：一個請求行、若干消息頭、實體內容.
·
以下圖：

HTTP請求細節——請求頭

·
請求行中的GET稱之爲請求方式，請求方式有：POST、GET、HEAD、OPTIONS、DELETE、TRACE、PUT，經常使用的有： GET、 POST
·
用戶若是沒有設置，默認狀況下瀏覽器向服務器發送的都是GET請求，例如在瀏覽器直接輸地址訪問，點超連接訪問等都是GET，用戶如想把請求方式改成POST，可經過更改表單的提交方式實現.
·
無論POST或GET，都用於向服務器請求某個WEB資源，這兩種方式的區別主要表如今數據傳遞上：若是請求方式爲GET方式，則能夠在請求的URL地址後以?的形式帶上交給服務器的數據，多個數據之間以&進行分隔，例如：GET /mail/1.html?name=abc&password=xyz HTTP/1.1
·
GET請求的特色：在URL地址後附帶的參數是有限制的，其數據容量一般不能超過1K.
·
若是請求方式爲POST方式，則能夠在請求的實體內容中向服務器發送數據，Post方式的特色：傳送的數據量無限制.

HTTP請求細節——消息頭

·
Accept
聲明瀏覽器支持的數據類型
·
Accept-Charset
聲明瀏覽器支持的字符集
·
Accept-Encoding
聲明瀏覽器支持的壓縮格式
·
Accept-Language
聲明瀏覽器的語言環境
·
Host
聲明瀏覽器要訪問那臺主機
·
If-Modified-since
聲明瀏覽器緩存數據的時間
·
Referer
聲明客戶機是哪一個頁面來的，用於防盜鏈
·
Connection
瀏覽器經過這個頭告訴服務器，請求完後是斷開連接仍是保持連接
·
X-Requested-with: XMLHttpRequest
表明經過ajax方式進行訪問
·
User-Agent
請求載體的身份標識，瀏覽器標識
·
以上爲HTTP請求中的經常使用消息頭，以下圖：

---

HTTP 響應

HTTP響應包括的內容

·
HTTP響應表明服務器向客戶端回送的數據.
它包括：一個狀態行、若干消息頭、以及實體內容.

HTTP響應細節——狀態行

·
狀態行格式：
HTTP/1.1 200 OK HTTP版本號 狀態碼 緣由敘述<CRLF>
·
狀態碼用於表示服務器對請求的處理結果.
狀態碼是一個三位的十進制數，響應狀態碼分爲5類.

·
常見的HTTP狀態碼
·
100 客戶端應繼續發送請求
客戶端應當繼續發送請求，客戶端應當繼續發送請求的剩餘部分.
或若是請求已經完成，忽略這個響應.
·
101 轉換協議
在發送完這個響應的最後空行後，服務器將會切換到在Upgrade消息頭中定義的那些協議.
只有在切換到新的協議更有好處的時候才應該採起相似的措施.
·
102 繼續處理
由WebDAV（RFC 2518）擴展的狀態碼，表明請求將被繼續執行.
·
200 請求成功
表示這條請求執行成功了.
處理方式：得到響應的內容，進行處理.
·
201 請求完成
表示這條請求執行完成了
結果是建立了新資源，新建立的資源的URL可在響應的實體中獲得.
處理方式在爬蟲中不會遇到.
·
202 請求被接受
請求被接受了，但處理還沒有完成.
處理方式：阻塞等待.
·
204 服務器以實現請求
服務器已經實現了請求，但未返回新的信息.
若是客戶端是用戶代理，則無需爲此更新自身的文檔視圖.
處理方式：丟棄.
·
300
該狀態碼不被HTTP/1.0的應用程序直接使用，只是做爲3XX類型迴應的默認解釋，存在多個可用的被請求資源.
處理方式：若程序中可以處理，則進一步處理；若程序中不可以處理，則丟棄.
·
301 永久重定向
請求到的資源都會分配一個永久的URL，這樣就能夠在未來經過該URL來訪問此資源.
處理方式：重定向到分配的URL，永久重定向.
·
302 臨時重定向
請求到資源在一個不一樣的URL處臨時保存.
處理方式：重定向到臨時的URL，臨時重定向.
·
304 請求的資源未更新
請求的資源未更新.
使用的是本地緩存文件（不會發送請求）.
處理方式：丟棄.
·
400 非法請求
處理方式：丟棄.
·
401 未受權
處理方式：丟棄.
·
403 禁止
處理方式：丟棄.
·
404 沒有找到
處理方式：丟棄.
·
500 服務器內部錯誤
服務器遇到了一個不曾預料的情況，致使它沒法完成對請求的處理.
通常這個問題會在服務器端的源代碼出現錯誤時出現.
即服務器問題，代碼邏輯有問題.
·
501 服務器沒法識別
服務器不支持當前請求須要的某個功能.
當服務器沒法識別請求的方法時，將沒法支持其對任何資源的請求.
·
502 錯誤網關
做爲網關或代理工做的服務器嘗試執行請求時，從上游服務器接收到無效的響應.

HTTP響應細節——經常使用響應頭

·
Location
服務器經過這個頭，來告訴瀏覽器跳到哪裏
·
Server
聲明服務器的型號
·
Content-Encoding
服務器經過這個頭，告訴瀏覽器，數據的壓縮格式
·
Content-Length
聲明服務器回送的數據的長度
·
Content-Language
服務器經過這個頭，告訴瀏覽器語言環境
·
Content-Type
聲明服務器回送的數據的類型
·
Refresh
服務器經過這個頭，告訴瀏覽器定時刷新
·
Content-Disposition
服務器經過這個頭，告訴瀏覽器如下載方式打開數據
·
Transfer-Encoding
服務器經過這個頭，告訴瀏覽器數據是以分塊方式回送的
·
Expires: -1
控制瀏覽器不要緩存
·
Cache-Control: no-cache
·
Pragma: no-cache