前言
最近在看面經的時候，發現大部分的公司面試的時候都會問到http協議，大部分的博客寫的不是很系統，所以決定自己寫一篇。
統一資源定位符URL
在說HTTP協議之前必須要先了解URL（統一資源定位符）統一資源定位符是對可以從互聯網上得到的資源的位置和訪問方法的一種簡潔的表示，是互聯網上標準資源的地址。互聯網上的每個文件都有一個唯一的URL，它包含的信息指出文件的位置以及瀏覽器應該怎麼處理它。
基本URL包含模式（或稱協議）、服務器名稱（或IP地址）、路徑和文件名，如“協議://授權/路徑?查詢”。完整的、帶有授權部分的普通統一資源標誌符語法看上去如下：協議://用戶名:密碼@子域名.域名.頂級域名:端口號/目錄/文件名.文件後綴?參數=值#標誌
第一部分
模式/協議（scheme）：它告訴瀏覽器如何處理將要打開的文件。最常用的模式是超文本傳輸協議（Hypertext Transfer Protocol，縮寫爲HTTP），這個協議可以用來訪問網絡。其他協議如下：
http——超文本傳輸協議資源
https——用安全套接字層傳送的超文本傳輸協議
ftp——文件傳輸協議
mailto——電子郵件地址
ldap——輕型目錄訪問協議搜索
file——當地電腦或網上分享的文件
news——Usenet新聞組
gopher——Gopher協議
telnet——Telnet協議
第二部分
文件所在的服務器的名稱或IP地址，後面是到達這個文件的路徑和文件本身的名稱。服務器的名稱或IP地址後面有時還跟一個冒號和一個端口號。它也可以包含接觸服務器必須的用戶名稱和密碼。路徑部分包含等級結構的路徑定義，一般來說不同部分之間以斜線（/）分隔。詢問部分一般用來傳送對服務器上的數據庫進行動態詢問時所需要的參數。
超文本傳送協議HTTP
HTTP協議（HyperText Transfer Protocol，超文本傳輸協議）是用於從WWW服務器傳輸超文本到本地瀏覽器的傳輸協議。它可以使瀏覽器更加高效，使網絡傳輸減少。它不僅保證計算機正確快速地傳輸超文本文檔，還確定傳輸文檔中的哪一部分，以及哪部分內容首先顯示(如文本先於圖形)等。
HTTP是客戶端瀏覽器或其他程序與Web服務器之間的應用層通信協議。在Internet上的Web服務器上存放的都是超文本信息，客戶機需要通過HTTP協議傳輸所要訪問的超文本信息。HTTP包含命令和傳輸信息，不僅可用於Web訪問，也可以用於其他因特網/內聯網應用系統之間的通信，從而實現各類應用資源超媒體訪問的集成。
HTTP協議是OSI模型中的第七層應用程中協議具有以下特點：
1、支持客戶/服務器模式;
2、簡單快速;
3、靈活;
4、無連接;
5、無狀態；
給一個簡單的實例來看看http協議的執行過程上圖中用戶點擊了一個鏈接指向清華大學院系設置的頁面，其URL是http://www.tsinghua.edu.cn/chn/yxsz/index.htm用http/1.0更具體的說明用戶在點擊鼠標後發生的事件：
（1）瀏覽器分析鏈接指向頁面的URL。
（2）瀏覽器向DNS請求解析http://www.tsinghua.edu.cn的IP地址。
（3）域名系統DNS解析出清華大學的IP地址爲166.111.4.100。
（4）瀏覽器與服務器建立TCP連接（服務器的IP地址是166.111.4.100，端口號是80）。
（5）瀏覽器發出取文件命令：GET/chn/yxsz/index.htm。
（6）服務器http://www.tsinghua.edu.cn做出響應，把文件index.htm發送給瀏覽器。
（7）釋放TCP連接。
（8）瀏覽器顯示“清華大學院系設置”文件index.htm中的所有文件。
瀏覽器在下載文件時，可以設置爲只下載其中的文本部分。這樣可使下載的速度加快。在這種情況下，文本中原來嵌入圖像或聲音的地方只用一個小圖標來顯示。用戶若要下載這些圖像或聲音，可再用鼠標分別點擊這些圖標。每點擊一次鼠標就重複執行一次類似於上面的8個步驟。也就是先建立TCP連接，再使用TCP連接傳送命令和文件，最後釋放TCP連接。
HTTP使用了面向連接的TCP作爲運輸層協議，保證了數據的可靠傳輸。
HTTP是無連接的
無連接的含義是限制每次連接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開連接。採用這種方式可以節省傳輸時間。
早期這麼做的原因是 HTTP 協議產生於互聯網，因此服務器需要處理同時面向全世界數十萬、上百萬客戶端的網頁訪問，但每個客戶端(即瀏覽器)與服務器之間交換數據的間歇性較大(即傳輸具有突發性、瞬時性)，並且網頁瀏覽的聯想性、發散性導致兩次傳送的數據關聯性很低，大部分通道實際上會很空閒、無端佔用資源。因此 HTTP 的設計者有意利用這種特點將協議設計爲請求時建連接、請求完釋放連接，以儘快將資源釋放出來服務其他客戶端。
HTTP是無狀態的
無狀態是指協議對於事務處理沒有記憶能力，服務器不知道客戶端是什麼狀態。即我們給服務器發送 HTTP 請求之後，服務器根據請求，會給我們發送數據過來，但是，發送完，不會記錄任何信息。HTTP 是一個無狀態協議，這意味着每個請求都是獨立的。
缺少狀態意味着如果後續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大。另一方面，在服務器不需要先前信息時它的應答就較快。
HTTP 協議這種特性有優點也有缺點，優點在於解放了服務器，每一次請求“點到爲止”不會造成不必要連接佔用，缺點在於每次請求會傳輸大量重複的內容信息。
一次HTTP過程
如上圖用戶點擊某個萬維網文檔連接時，HTTP協議首先要和服務器建立TCP連接。這是需要三次握手。當三次握手的前兩部分完成後（經過了一個RTT時間後），萬維網客戶就把HTTP請求報文作爲第三次握手的第三個報文的數據發送給萬維網服務器。萬維網服務器收到HTTP請求報文後，就把所請求的文檔作爲響應報文返回給客戶。
HTTP/1.0協議的缺點
HTTP的主要缺點，就是每請求一個文檔就要兩倍RTT的開銷。若一個主頁上有很多鏈接的對象（如圖片等）需要一次進行鏈接，那麼每一次鏈接下載都導致2RTT的開銷。另一種開銷就是萬維網客戶和服務器沒一次建立新的TCP連接都要分配緩存和變量。
HTTP/1.1協議較好的解決了上面的問題，它使用持續連接。在萬維網服務器發送響應後仍然在一段時間內保持這條連接，使同一個客戶（瀏覽器）和服務器可以繼續在這條連接上傳送後續的HTTP請求報文和響應報文。並且不限於傳送同一個頁面上鍊接的文檔，而是隻要這些文檔都在一個服務器上就行。
HTTP/1.1協議的持續連接有兩種方式，即非流水線方式和流水線方式。
HTTP的報文結構
HTTP有兩類報文：
（1）請求報文—–從客戶端向服務器發送請求報文。
（2）響應報文—–從服務器到客戶的回答。
請求報文的結構如下圖：
響應報文的結構如下圖：
HTTP請求報文和響應報文都是由三個部分組成。可以看出這兩種報文的區別就在於開始行不同。
（1）開始行，用於區別是請求報文還是響應報文。在請求報文中的開始行叫做請求行，而在響應報文中的開始行就叫做狀態行。
（2）首部行，用於說明瀏覽器、服務器、或報文主體的一些信息。首部可以有好幾行，但也可以不用。
（3）實體主體，在請求報文中一般不用這個字段，在響應報文中返回請求的內容，也可以不用。
請求報文的第一行“請求行”只有三個內容，方法，請求資源的URL，以及HTTP的版本。這裏的方法是對請求的對象進行的操作，這些方法實際上也就是一些命令，請求報文的類型就是由它採用的方法決定的。
HTTP的請求方法
1、OPTIONS
返回服務器針對特定資源所支持的HTTP請求方法，也可以利用向web服務器發送‘*’的請求來測試服務器的功能性
2、HEAD
向服務器索與GET請求相一致的響應，只不過響應體將不會被返回。這一方法可以再不必傳輸整個響應內容的情況下，就可以獲取包含在響應小消息頭中的元信息。
3、GET
向特定的資源發出請求。注意：GET方法不應當被用於產生“副作用”的操作中，例如在Web Application中，其中一個原因是GET可能會被網絡蜘蛛等隨意訪問。
4、POST
向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST請求可能會導致新的資源的建立和/或已有資源的修改。
5、PUT
向指定資源位置上傳其最新內容
6、DELETE
請求服務器刪除Request-URL所標識的資源
7、TRACE
回顯服務器收到的請求，主要用於測試或診斷
8、CONNECT
HTTP/1.1協議中預留給能夠將連接改爲管道方式的代理服務器。
GET和POST的比較
GET - 從指定的服務器中獲取數據
POST - 提交數據給指定的服務器處理
GET方法：
使用GET方法時，查詢字符串（鍵值對）被附加在URL地址後面一起發送到服務器：
/test/demo_form.jsp?name1=value1&name2=value2
特點：
（1）GET請求能夠被緩存
（2）GET請求會保存在瀏覽器的瀏覽記錄中
（3）以GET請求的URL能夠保存爲瀏覽器書籤
（4）GET請求有長度限制
（5）GET請求主要用以獲取數據
POST方法：
使用POST方法時，查詢字符串在POST信息中單獨存在，和HTTP請求一起發送到服務器：
POST /test/demo_form.jsp
HTTP/1.1 Host: w3schools.com
name1=value1&name2=value2
特點：
（1）POST請求不能被緩存下來
（2）POST請求不會保存在瀏覽器瀏覽記錄中
（3）以POST請求的URL無法保存爲瀏覽器書籤
（4）POST請求沒有長度限制
HTTP狀態碼
HTTP狀態碼（HTTP Status Code）是用以表示網頁服務器HTTP響應狀態的3位數字代碼。每一個請求報文發出後，都能收到一個響應報文。響應報文的第一行就是狀態行。狀態行包含三項內容，HTTP的版本、狀態碼、以及解釋狀態碼的簡單短語。狀態碼共分爲5大類33種。如：
下面是在狀態行中常見的狀態碼：
100 Continue
客戶端應當繼續發送請求。這個臨時響應是用來通知客戶端它的部分請求已經被服務器接收，且仍未被拒絕。客戶端應當繼續發送請求的剩餘部分，或者如果請求已經完成，忽略這個響應。服務器必須在請求完成後向客戶端發送一個最終響應。
101 Switching Protocols
服務器已經理解了客戶端的請求，並將通過Upgrade 消息頭通知客戶端採用不同的協議來完成這個請求。在發送完這個響應最後的空行後，服務器將會切換到在Upgrade 消息頭中定義的那些協議。
200 OK
請求已成功，請求所希望的響應頭或數據體將隨此響應返回。
201 Created
請求已經被實現，而且有一個新的資源已經依據請求的需要而建立，且其 URI 已經隨Location 頭信息返回。假如需要的資源無法及時建立的話，應當返回 ‘202 Accepted’。
202 Accepted
服務器已接受請求，但尚未處理。正如它可能被拒絕一樣，最終該請求可能會也可能不會被執行。在異步操作的場合下，沒有比發送這個狀態碼更方便的做法了。
300 Multiple Choices
被請求的資源有一系列可供選擇的回饋信息，每個都有自己特定的地址和瀏覽器驅動的商議信息。用戶或瀏覽器能夠自行選擇一個首選的地址進行重定向。
301 Moved Permanently
被請求的資源已永久移動到新位置，並且將來任何對此資源的引用都應該使用本響應返回的若干個 URI 之一。如果可能，擁有鏈接編輯功能的客戶端應當自動把請求的地址修改爲從服務器反饋回來的地址。除非額外指定，否則這個響應也是可緩存的。
400 Bad Request
1、語義有誤，當前請求無法被服務器理解。除非進行修改，否則客戶端不應該重複提交這個請求。
2、請求參數有誤。
404 Not Found
請求失敗，請求所希望得到的資源未被在服務器上發現。沒有信息能夠告訴用戶這個狀況到底是暫時的還是永久的。假如服務器知道情況的話，應當使用410狀態碼來告知舊資源因爲某些內部的配置機制問題，已經永久的不可用，而且沒有任何可以跳轉的地址。404這個狀態碼被廣泛應用於當服務器不想揭示到底爲何請求被拒絕或者沒有其他適合的響應可用的情況下。出現這個錯誤的最有可能的原因是服務器端沒有這個頁面。
HTTP與HTTPS的區別
到現在爲止，我們已瞭解到 HTTP 具有相當優秀和方便的一面，然而 HTTP 並非只有好的一面，事物皆具兩面性，HTTP 也是有不足之處的。
1、通信使用明文（ 不加密） ， 內容可能會被竊聽
2、不驗證通信方的身份， 因此有可能遭遇僞裝
3、無法證明報文的完整性， 所以有可能已遭篡改
通信使用明文可能會被竊聽由於 HTTP 本身不具備加密的功能，所以也無法做到對通信整體（使用 HTTP 協議通信的請求和響應的內容）進行加密。即，HTTP 報文使用明文（指未經過加密的報文）方式發送。
HTTP 協議的實現本身非常簡單，不論是誰發送過來的請求都會返回響應，因此不確認通信方，會存在以下各種隱患。
1、無法確定請求發送至目標的 Web 服務器是否是按真實意圖返回響應的那臺服務器。有可能是已僞裝的 Web 服務器。
2、無法確定響應返回到的客戶端是否是按真實意圖接收響應的那個客戶端。有可能是已僞裝的客戶端。
3、無法確定正在通信的對方是否具備訪問權限。因爲某些Web 服務器上保存着重要的信息， 只想發給特定用戶通信的權限。
4、無法判定請求是來自何方、出自誰手。
5、即使是無意義的請求也會照單全收。無法阻止海量請求下的DoS 攻擊（ Denial of Service， 拒絕服務攻擊） 。
確保 Web 安全的 HTTPS
在 HTTP 協議中有可能存在信息竊聽或身份僞裝等安全問題。使用 HTTPS 通信機制可以有效地防止這些問題。
HTTP+ 加密 + 認證 + 完整性保護 =HTTPS
HTTP 加上加密處理和認證以及完整性保護後即是 HTTPS如果在 HTTP 協議通信過程中使用未經加密的明文，比如在 Web 頁面中輸入信用卡號，如果這條通信線路遭到竊聽，那麼信用卡號就暴露了。另外，對於 HTTP 來說，服務器也好，客戶端也好，都是沒有辦法確認通信方的。因爲很有可能並不是和原本預想的通信方在實際通信。並且還需要考慮到接收到的報文在通信途中已經遭到篡改這一可能性。爲了統一解決上述這些問題，需要在 HTTP 上再加入加密處理和認證等機制。我們把添加了加密及認證機制的 HTTP 稱爲 HTTPS （HTTP Secure）。
參考文獻
1、計算機網絡第五版（謝希仁）
2、TCP/IP協議詳解卷1
3、http://www.cnblogs.com/zxj015/p/6530766.html