一、HTTP協議
最近看了一些網絡通信方面的書籍，研究了一下 HTTP 和 TCP/IP，有了一些新的收獲和理解，在這里做個歸納和總結。
（1）什么是HTTP協議
HTTP (HyperText Transfer Protocol，超文本傳輸協議) 是一種通信協議，是指計算機網絡中兩台計算機之間進行通信所必須共同遵守的規定或規則，它允許將超文本標記語言(HTML)文檔從Web服務器傳送到客戶端，是互聯網上應用最為廣泛的一種網絡協議。
（2）一種無狀態協議
HTTP協議是不保存狀態的協議，即HTTP是無狀態協議。HTTP協議自身不對請求和響應之間的通信狀態進行保存。也就是說在HTTP這個級別，協議對於發送過來的請求或響應都不做持久化處理。
使用HTTP協議，每當有新的請求發送時，就會有對應的新的響應產生。協議本身不保留之前一切的請求或響應報文的信息。也就是說，無法根據之前的狀態進行本次請求的處理。
無狀態優點： ①更快地處理大量事務，確保協議的可伸縮性。②由於不必保存狀態，這就可以減少服務器的CPU及內存資源的消耗。
HTTP/1.1雖然是無狀態協議，但為了實現期望的保持狀態功能，引入了Cookie技術。有了Cookie再用HTTP協議通信，就可以管理狀態了。
Cookie會根據從服務器端發送的響應報文類中的Set-Cookie的首部字段信息，通知客戶端保存Cookie。當下次客戶端再往服務器發送請求時，客戶端會自動的請求報文中加入Cookie值后發送出去。服務器端接收到客戶端發送過來的Cookie后，回去檢查究竟是從哪一個客戶端發來的請求，然后對比服務器上的記錄，最后得到之前狀態的信息。
（3）HTTP方法
HTTP/1.0 和 HTTP/1.1支持的方法
其中LINK 和 UNLINE 已被HTTP/1.1廢棄，不再支持。
（4）HTTP協議的報文
用於HTTP協議交互的信息被稱為HTTP報文。請求端（客戶端）的HTTP報文叫做請求報文，響應端（服務器端）的HTTP報文叫做響應報文。HTTP報文本身是由多行數據構成的字符串文本。
HTTP報文包括以下三部分：
1. 報文首部
客戶端或服務器端需處理的請求或響應的內容及屬性。包括：請求行(包含用於請求的方法，請求URI，HTTP版本)，狀態行(包含表明響應結果的狀態碼，原因短語，HTTP版本)，首部字段(包含表明請求和響應的各種條件和屬性的各類首部)。
2. 空行
CR+LF，CR(Crriage Return，回車符) 和 LF(Line Feed，換行符)。
3. 報文主體
應被發送的數據。
請求報文和響應報文的示例圖：
（5）HTTP持久化連接
1. 持久連接
HTTP協議的初始版本中，每進行一次HTTP通信就要斷開一次TCP連接，增加了通行量的開銷。
為了解決上述TCP的問題，HTTP/1.1推出了持久連接（HTTP Persistent Connections，也稱為HTTP keep-alive 或 HTTP connection reuse）的方法。
持久連接的特點是，只要任意一端沒有明確提出斷開連接，則保持TCP連接狀態。
優點：減少了TCP連接的重復建立和斷開所造成的額外開銷，減輕了服務器端的負載。減少開銷的那部分時間，使HTTP請求和響應能夠更早地結束，這樣Web頁面的顯示速度就相應提高了。
在HTTP/1.1中，所有連接默認都是持久連接，但在HTTP/1.0內並未標准化。
2. 管線化
持久連接使得多數請求以管線化方式發送成為可能。之前發送請求后需等待並收到響應之后，才能發送下一個請求。管線化技術出現后，不用等待響應就可直接發送下一個請求。
（6）HTTP結果的狀態碼
HTTP狀態碼的職責是當客戶端向服務端發送請求時，描述返回的請求結果。通過狀態碼，用戶可以知道服務器是正常的處理了請求，還是出現了錯誤。
每條HTTP響應報文返回時都會攜帶一個狀態碼，狀態碼是由一個三位數字和原因短語組成，如200 OK。數字的第一位是響應類別(狀態碼類別)，后兩位無分類。
5種狀態碼的類別：
只要遵守狀態碼類別的定義，及時改變RFC2616總定義的狀態碼，或服務器端自行創建裝條碼都沒問題。
幾個常見的狀態碼：
- 200 OK。 表示從客戶端發來的請求在服務器端被正常處理了。
- 204 No Content。 表示服務器接收的請求已成功處理，但在返回的響應報文中不含實體的主體部分，也不允許返回任何實體的主體。一般在只需要重客戶端往服務器發送信息，而對客戶端不需要發送新信息內容的情況下使用。
- 301 Moved Permanently。 永久性重定向。表示請求的資源已被分配了新的URI，以后應使用資源現在所指的URI。也就是說，如果已經把資源對應的URI保存為書簽了，這是應該按Location首部字段提示的URI重新保存。
- 302 Found。 臨時性重定向。表示請求的資源已被分配了新的URI，希望用戶（本次）能使用新的URI訪問。
- 304 Not Modified。 表示客戶端發送附帶條件的請求時，服務器端允許請求訪問資源，但未滿足條件的情況。304狀態碼返回時，不包含任何響應的主體部分。304雖然被划分在3XX類別中，其實和重定向沒有關系。
- 400 Bad Request。 表示報文中存在語法錯誤。當錯誤發生時，需修改請求的內容后再次發送請求。
- 401 Unauthorized。 表示發送的請求需要通過HTTP認證（BASIC認證，DIGEST認證）的認證信息。若之前已經進行過1次請求，則表示用戶認證失敗。
- 404 Not Found。 表示服務器上無法找到請求的資源。除此之外，也可以在服務器端拒絕請求且不想說明理由時使用。
- 500 Internal Server Error。 表示服務器端在執行請求時發生了錯誤。也有可能是Web應用存在的bug或某些臨時的故障。
- 503 Service Unavailable。 表示服務器暫時處於超負載或正在進行停機維護，現在無法處理請求。如果事先得知解除以上狀況所需要的時間，最好寫入Retry-After首部字段再返回給客戶端。
（7）常見的疑問
1. HTTP 和 TCP/IP 的區別
TCP/IP協議是傳輸層協議，主要解決數據如何在網絡中傳輸，而HTTP是應用層協議，主要解決如何包裝數據。
詳細點說就是，我們在傳輸數據的時候，可以只使用 TCP/IP協議，但是那樣的話，如果沒有應用層，便無法識別數據內容，如果想要使傳輸的數據有意義，則必須使用到應用層協議，應用層協議有很多，比如HTTP、FTP、TELNET等，也可以自己定義應用層協議。WEB使用HTTP協議作應用層協議，以封裝HTTP 文本信息，然后使用TCP/IP做傳輸層協議將它發到網絡上。
2. URI、URL、URN 的區別
URI：Uniform Resorce Identifier，統一資源標識符。
URL：Uniform Resource Locator，統一資源定位符。
URN：Uniform Resource Name，統一資源名稱。
URI用字符串表標識某一互聯網資源，而URL表示資源的地點(互聯網上所處的位置)。可見URL是URI的子集。
三者關系圖：
如果是一個人，我們會想到他的姓名和住址。URL類似於住址，它告訴你一種尋找目標的方式（在這個例子中，是通過街道地址找到一個人）。要知道，上述定義同時也是一個URI。相對地，我們可以把一個人的名字看作是URN；因此可以用URN來唯一標識一個實體。由於可能存在同名（姓氏也相同）的情況，所以更准確地說，人名這個例子並不是十分恰當。更為恰當的是書籍的ISBN碼和產品在系統內的序列號，盡管沒有告訴你用什么方式或者到什么地方去找到目標，但是你有足夠的信息來檢索到它。
二、HTTPS 協議
（1）為什么要使用HTTPS
上面已經介紹了HTTP協議，雖然HTTP協議用的很普遍，但是它也有些不足。列舉如下：
- 通信使用明文(不加密)，內容可能會被竊聽。
- 不驗證通信方的身份，因此有可能遭遇偽裝。
- 無法驗證報文的完整性，所以有可能已遭篡改。
這些問題不僅在HTTP上出現，其他未加密的協議中也會存在這類問題。
為了統一解決上述這些問題，需要在HTTP上在加入加密處理和認證等機制。我們把添加了加密及認證機制的HTTP稱為HTTPS(HTTP Secure)。
簡單的說，其實 HTTPS = HTTP + 加密 + 認證 + 完整性保護。
經常會在Web的登錄頁面和購物結算界面使用HTTPS通信。使用HTTPS通信時，不再用http://，而是改用https://。當瀏覽器訪問HTTPS通信有效的Web網站時，瀏覽器的地址欄會出現一個帶鎖的標記。
（2）特殊的HTTP
HTTPS並非是應用層的一種新協議。只是HTTP通信接口部分用SSL（Secure Socker Layer）和 TLS（Transport Layer Security）協議代替而已。
通常，HTTP 直接和 TCP 通信。當使用 SSL 時，則演變成先和 SSL 通信，再由 SSL 和 TCP 通信了。簡言之，所謂HTTPS，其實就是身披 SSL 協議這層外殼的HTTP。
TLS/SSL 是獨立於HTTP的協議，是介於 TCP 和 HTTP 之間的一層安全協議，不影響原有的 TCP 協議和 HTTP 協議，所以使用 HTTPS 基本上不需要對 HTTP 頁面進行太多的改造。不光是HTTP協議，其他運行在應用層的SMTP 和 Telnet等協議均可配合SSL協議的使用。
（3）為什么不都使用HTTPS
既然HTTPS那么完全可靠，那為何所有的Web網站不一直使用HTTPS？
主要是因為以下幾個原因：
1. 與純文本通信相比，加密通信會消耗更多的CPU及內存資源。
如果每次通信都加密，會消耗相當多的資源，平攤到一台計算機上時，能處理的請求數量必定會隨之減少。因此，如果是非敏感信息還是用HTTP通信，只有在包含個人敏感數據時，才利用HTTPS加密通信。特別是每當那些訪問量較多的Web網站在進行加密處理時，並非對所有內容都進行加密處理，而是僅對那些需要信息隱藏時才會加密，以節約資源。
2. 節約購買證書的開銷。
要進行HTTPS通信，證書是必不可少的。而使用的證書必須向認證機構（CA）購買。證書價格根據不同的認證機構略有不同，一年幾百到幾千的都有，那些購買證書並不合算的服務以及一些個人網站，可能只會選擇采用HTTP的通信方式。
3. HTTPS使用SSL時，它的處理速度會變慢。
SSL的慢有兩種，一是通信慢，二是大量消耗CPU及內存等資源，導致處理速度變慢。和HTTP相比，網絡負載可能會慢2到100倍。除去和TCP連接、發送HTTP請求和響應以外，還必須進行SSL通信，因此整體上處理通行量不可避免會增加。SSL必須進行加密處理。在服務器和客戶端都需要進行加密和解密的運算處理。因此，比起HTTP會更多地消耗服務器和客戶端的硬件資源，導致負載增強。當然，可以通過使用SSL加速器這種硬件來改善該問題。
本文主要收集整理自《圖解HTTP》