HTTP協議簡述

前言

HTTP協議是整個Web的基礎，是客戶端和服務器端協同工做的基石，要想了解Web的工做原理、優化Web應用，就要徹底理解HTTP協議。

HTTP的操做過程

1 ，瀏覽器分析指向頁面的URL
2 ，瀏覽器向DNS系統請求解析域名所對應的服務器IP地址
3 ，DNS系統解析出服務器的IP，並返回給主機
4 ，瀏覽器與該服務器的進程創建TCP連接（三次握手，端口默認爲80）
5 ，瀏覽器發出HTTP請求：如GET /article/index.html
6 ，服務器收到請求並做出相應處理，把文件index.html發送給瀏覽器
7 ，釋放TCP連接（四次握手）
8 ，瀏覽器解析index.html文件，將web頁顯示出來。

HTTP協議的特色

HTTP協議是無狀態的，即屢次訪問一個服務器上的頁面，服務器並不知道你曾經訪問過，每次訪問的響應都當作第一次訪問同樣。因此，在實際應用中，一般使用CooKie加數據庫的方式記錄和跟蹤用戶的活動。
HTTP有非持久鏈接和持久鏈接：

                                            採用非持久鏈接時，網頁的每一個元素對象（如.png，jpeg圖等）的傳輸都需單獨創建一個TCP鏈接（第三次握手可攜帶請求信息）
                                            採用持久鏈接時，僅需創建一次TCP鏈接，服務器發送響應後仍保持鏈接，客戶和服務器能夠繼續在這條鏈接上發送請求和響應報文。

Cookie以及其做用

CooKie是由服務器生成，但存儲在用戶主機上的文本文件，它保存了服務器和客戶之間傳遞的狀態信息，做爲識別用戶的手段。經過Cookie服務器就能從數據庫中查詢該用戶的活動記錄，進而能夠執行一些個性化操做

get和post方法的區別： 

通常咱們在瀏覽器輸入一個網址訪問網站都是GET請求；在FORM表單中，能夠經過設置Method指定提交方式爲GET或POST，默認時爲GET提交方式。

　　　　　　　　　　　　　　　　　　　　　　get請求通常不會修改服務器的信息，僅用於請求頁面；post請求可能會修改服務器中的資源信息，如提交評論、博客等都是經過post請求實現。
　　　　　　　　　　　　　　　　　　　　　　get請求的信息附加在URL後面，這些被顯示的暴露在外面。post請求的數據放在包體中，不容易暴露，所以通常用戶登陸等保密性高的不宜採用get請求，而用post請求。

HTTP協議與SPDY協議

HTTP（HyperText Transfer Protocol，超文本傳輸協議）是萬維網協會（World Wide Web Consortium）和Internet工做小組（Internet Engineering Task Force, IETF）合做的結果，最終發佈了一系列的RFC(Request For Comments)。RFC1945定義了HTTP1.0版本，最著名的是RFC2616，其中定義了今天廣泛使用的版本——HTTP 1.1。

HTTP是一個應用層協議，由請求和相應構成，是一個標準的客戶端服務器模型。HTTP一般承載於TCP協議之上，有時也承載於TLS或SSL協議層之上，這個時候，就成了常說的HTTPS。默認HTTP的端口號爲80，HTTPS的端口號爲443。

HTTP協議在OSI模型中的位置如圖所示：

HTTP協議的模型就是客戶端發起請求，服務器回送響應，如圖4-2所示。HTTP協議是一個無狀態的協議，同一個客戶端的此次請求和上次請求沒有對應關係。

這種設計屬於典型」問答式」交互，客戶端和服務器端一問一答，使HTTP協議模型異常簡單。這種設計也存在問題，好比服務器不會主動向客戶端PUSH，一問一答的輪詢也會使TCP鏈接頻繁創建和斷開，致使其交互效率不高。基於以上缺點，SPDY協議應運而生。

SPDY協議是Google推出的協議，優化了瀏覽器和服務器之間的通訊，支持流複用，具有優先級的請求、主動發起請求、強制SSL安全傳輸等先進的特性。目前，Chrome和Firefox瀏覽器均支持SPDY協議，一些服務器也紛紛開始支持SPDY協議。能夠預見，在將來幾年，SPDY協議將獲得大大推廣。

注：SPDY並不用於取代HTTP，它只是修改了HTTP的請求與應答在網絡上傳輸的方式；這意味着只需增長一個SPDY傳輸層，現有的全部服務端應用均不用作任何修改。SPDY協議相似於HTTP，但旨在縮短網頁的加載時間和提升安全性。SPDY協議經過壓縮、多路複用和優先級來縮短加載時間。SPDY協議的應用須要客戶端和服務器端同時支持。

HTTP協議如何工做

瀏覽器網頁是HTTP協議的主要應用，但並不表明HTTP協議只能應用於網頁的瀏覽，只要通訊的雙方都遵照HTTP協議，其就有用武之地。好比騰訊QQ、迅雷等軟件都使用HTTP協議（固然還包括其餘的協議）。

那麼，HTTP協議是如何工做的呢？

首先，客戶端發送一個請求給服務器，服務器在接收到這個請求後將生成一個響應返回客戶端。一次HTTP協議稱爲一個事務，其工做過程可分爲四步：

1）客戶端與服務器須要創建鏈接。單擊某個超連接，HTTP協議的工做開始。

2）創建鏈接後，客戶端發送一個請求給服務器。格式爲：前邊是統一 資源標識符（URL）、中間是協議版本號，後邊是MIME信息（包括請求修飾符、客戶機信息和可能的內容）。

3）服務器接到請求後，給予相應的響應信息。格式爲：首先是一個狀態運行（包括信息的協議版本號、一個成功或錯誤的代碼），而後是MIME信息（包括服務器信息、實體信息和可能的內容）。

4）客戶端接收服務器返回的信息並顯示在用戶的顯示屏上，而後客戶端機與服務器斷開鏈接

若是這四步的某一步出錯產生錯誤的信息將返回到客戶端，由顯示屏輸出。這些過程是由HTTP協議本身完成的，用戶只須要單擊鼠標，等待信息顯示就能夠了。

主要概念

一、請求

在發起請求前，須要先創建連接。

鏈接是一個傳輸層的實際環流，它創建在兩個相互通訊的應用程序之間。在HTTP1.1協議中，request和response頭中都有可能出現一個connection的頭，其決定當Client和Server通訊時對於長連接如何處理。

HTTP1.1協議中，Client和Server默認對方支持長連接，若是Client使用HTTP1.1協議，但又不但願使用長連接，須要在header指明connection的值爲close；同理，Server端也同樣。不論request仍是responese的header中包含了值爲close的connection，都代表當前正在使用的TCP鏈接在請求處理完畢後會被斷掉，之後Client再進行新的請求時必須建立新的TCP鏈接。

HTTP請求由三部分組成：請求行、消息報頭、請求正文。

請求行以一個方法符號開頭，以空格分開，後面跟着請求的URI和協議的版本，格式以下：

Method Request-URI HTTP-Version CRLF

上述格式中各參數說明以下：

Method：請求方法。
Request-URI：一個統一資源標識銜。
HTTP-Version：請求的HTTP協議版本。
CRLF：回車和換行（除了做爲結尾的CRLF外，不容許出現單獨的CR或LF字符）。
請求方法（全部方法全爲大寫）有多種，各個方法的解釋以下：
GET：請求獲取Request-URI所標識的資源。
POST：在Request-URI標識的資源後附加新的數據。
HEAD：請求獲取由Request-URI的標識資源的響應消息報頭。
PUT：請求服務器存儲一個資源，並用Request-URI做爲其標識。
DELETE：請求服務器刪除Request-URI所標識的資源。
TRACE：請求服務器回送收到的請求信息，主要用於測試或診斷。
CONNECT：保留以備未來使用。
OPTIONS：請求查詢服務器的性能，或者查詢與資源相關的選項和要求。

2.響應

在接收和解釋請求消息後，服務器返回一個HTTP響應消息。HTTP響應也由三個部分組成，分別是：狀態行、消息報頭、響應正文。

狀態行格式以下：

HTTP-Version Status-Code Reason-Phrase CRLF

上述格式中各參數說明以下：

HTTP-Version：服務器HTTP協議的版本。
Status-Code：服務器發回的響應狀態代碼。
Reasion-Phrase：狀態代碼的文本描述。

狀態代碼由三位數字組成，第一個數字定義了響應的級別，有五種可能取值：

1xx：指示信息—請求已接收，繼續處理。
2xx：成功—請求已被成功接收、理解、接受。
3xx：重定向—要完成請求必須進行更進一步的操做。
4xx：客戶端錯誤–請求有語法錯誤或請求沒法實現。
5xx：服務器端錯誤—服務器未能實現合法的請求。

常見的狀態代碼、狀態描述和說明以下：

200 OK：客戶端請求成功。
400 Bad Request：客戶端請求有語法錯誤，不能被服務器所理解
401 Uauthorize：請求未經受權，這個狀態碼必須和WWW-Authenticate報頭域一塊兒使用
403 Forbidden：服務器端收到請求，可是拒絕提供服務器。
404 Not Found：請求資源不存在，例如輸出了錯誤的URL。
500 Internal Server Error：服務器發生不可預期的錯誤。
503 Server Unavailable：服務器當前不能處理客戶端的請求，一段時間後可能恢復正常。

例如，響應信息「HTTP/1.1 200 OK（CRLF）」,表示響應請求到達服務器後被成功識別成功標記。響應正文就是服務器返回的資源的內容。

3.報頭

HTTP消息報包括普通報頭、請求報頭、響應報頭、實體報頭。每一個報頭域的組成以下：

名字+：+空格+值

1）普通報頭中有少數報頭域用於全部的請求和響應信息，但並不用於被傳輸的實體，只用於傳輸的消息（如緩存控制、鏈接控制）。

2）請求報頭容許客戶端向服務器端傳遞請求的附加信息以及客戶端自身的信息（如UA頭、Accept等）。

3）響應報頭容許客戶端向服務器端傳遞不能放在狀態行中的附加響應信息，以及關於服務器的信息和對Request-URI所標識的資源進行下一步訪問的信息（如Location）。

4）實體報頭定義了關於實體正文和請求所標識的資源的元信息，例若有無實體正文。

比較重要的幾個報頭以下。

Host：頭域指定請求資源的Internet主機和端口號，必須表示請求URL的原始服務器或網關的位置。HTTP1.1請求必須包含主機頭域，不然系統會以400狀態碼返回。

Use-Agent：簡稱UA，內容包含發出請求的用戶信息。一般UA包含瀏覽者的信息，主要是瀏覽器的名稱版本和所用的操做系統。這個UA頭不只僅是否使用瀏覽器才存在，只要使用使用了基於HTTP協議的客戶端軟件都會發送這個請求，不管是手機端仍是PDA等。這個UA頭是辨別客戶端所用設備的重要依據。

Accept：告訴服務器能夠接受的文件格式一般這個值在各類瀏覽器中都差很少。不過WAP瀏覽器所能接受的格式要少一些，這也是用來區分WAP和計算機瀏覽器的主要依據之一。隨着WAP瀏覽器的升級，其已經和計算機瀏覽器愈來愈接近，所以這個判斷所起的做用也變得愈來愈弱。

Cookie：Cookie分兩種，一種是客戶端向服務器端發送的，使用Cookie報頭，用來標記一些信息；別一種是服務器發送給瀏覽器的，報頭爲Set-Cookie.兩者的主要區別是Cookie報頭的value裏能夠有多個Cookie值，而且不須要顯式指定domain等。而Set-Cookie報頭裏一條記錄只能一個Cookie的value，須要指明domain、path等。

Cache-Control：指定請求和響應遵循的緩存機制。在請求消息或響應消息中設置Cache-Control並不會修改另外一個消息處理過程當中的緩存處理過程。請求時緩存指令包括：no-cache、no-store、max-age、max-stale、min-fresh、only-if-cached；響應消息中的指令包括public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age。

Referer：頭域容許客戶指定請求URI的源資源地址，這能夠容許服務器生成回退鏈表，可用來登陸、優化緩存等。也允廢除的或錯誤的鏈接因爲 維護的目的被追蹤，若是請求的URI沒有本身的URI地址，Referer不能被髮送。若是指定的是部分URI地址，則此地址應該是一個相對地址。Referer一般是流量統計系統用來記錄來訪者地址的參數。

Content-Length：內容長度。

Content-Range：響應的資源範圍。能夠在每次請求中標記請求的資源範圍，在鏈接斷開重連時，客戶端只請求該資源未下載的部分。而不是從新請求整個資源，實現斷點續傳。迅雷就是基於這個原理，使用多線程分段讀取網絡上的資源，最後再合併。

Accept-Encoding：指定所可以接受的編碼方式。一般服務器會對頁面進行GZIP壓縮後再輸出以減小流量，通常瀏覽器均支持對這種壓縮後的數據進行處理。但對於咱們來講，若是不想接收到這些看似「亂碼」的數據，能夠指定不接受任何服務器端壓縮處理，要求其原樣返回。 自定義報頭：在HTTP消息中，也可以使用一些在HTTP1.1正式規範裏沒有定義的頭字段，這些頭字段統稱爲自定義的HTTP頭或者擴展頭。好比sever字段，這個報頭通常是由服務器發送的。也能夠定義一些「不正規」的報頭，如「WEBMASTER：chenqionghe@qq.com」。在PHP裏，使用header便可實現 。