HTTP協議（包含與HTTPS的區別） 知識筆記

HTTP協議處於OSI七層模型的應用頂層。

使用 HTTP 協議時，客戶端首先與服務端的 80 埠建立一個 TCP 連線，然後在這個連線的基礎上進行請求和應答，以及資料的交換。無連線狀態的。

---

1、HTTP 各版本的區別

由 HTTP 協議載入出來的網頁，通常使用 HTML 語言來描述，因此 HTML 也可以理解為網頁的一種資料格式。HTML 是一段純文字，可以指定網頁中的文字、影象、音訊視訊圖片、連結，以及它們的顏色、位置等。無論計算機的底層結構如何，也無論網路底層使用了哪些協議，使用 HTML 展示出來的效果基本上是一致的。從這個角度來說 HTML 位於 OSI 七層模型的表現層。

http1.0：
每對Request/Response都使用一個新的短連線；
不支援斷點續傳，每次都從RANGE:0(http1.0新增加的欄位)開始；
其中Http1.0需要在request中增加“Connection：keep-alive”header才能支援，而Http1.1預設支援。

http1.1：
預設使用長連線，在同一個TCP連線可以傳送多個http請求和相應，同時也支援更多的請求頭和相應頭；
還提供了身份認證、狀態管理和cache快取機制相關的頭。

http2.0：
支援頭部壓縮，流量控制，多路複用和更加安全的ssl加密演算法等。這些特性都是2.0特有的。

參考：< http://www.jianshu.com/p/3b4f2c84e70f >

比較重要的點就是在於 HTTP 1.0 中每次請求和應答都會使用一個新的 TCP 連線，而從 HTTP 1.1 開始，執行在一個 TCP 連線上傳送多個命令和應答。因此大幅度減少了 TCP 連線的建立和斷開，提高了效率。

---

2、HTTP 的請求方法

HTTP的常見請求方法包括：

HTTP1.0定義了三種請求方法： GET, POST 和 HEAD方法。
HTTP1.1新增了五種請求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。

方法	描述
GET	請求指定的頁面資訊，並返回實體主體。
POST	向指定資源提交資料進行處理請求（例如提交表單或者上傳檔案）。資料被包含在請求體中。POST請求可能會導致新的資源的建立和/或已有資源的修改。
HEAD	類似於get請求，只不過返回的響應中沒有具體的內容，用於獲取報頭。
PUT	從客戶端向伺服器傳送的資料取代指定的文件的內容。
DELETE	請求伺服器刪除指定的頁面。
CONNECT	HTTP/1.1協議中預留給能夠將連線改為管道方式的代理伺服器。
OPTIONS	允許客戶端檢視伺服器的效能。
TRACE	回顯伺服器收到的請求，主要用於測試或診斷。

其中在Android中最常用的就是GET和POST了。兩者存在的主要區別如下:

Get請求資料會附在URL之後，以 ? 分隔URL和傳輸的資料，多個引數用 & 連線，一般瀏覽器會對URL的長度有
限制（如IE對URL長度限制為2083位元組），所以get傳送的資料是有限的。而且因為明文傳輸，他是不安全的。

Post請求把提交的資料放置在HTTP包的包體中，不會顯示在瀏覽器上，其引數也是作為key/value對傳輸的，多
個引數也是用 & 連線，所以他的安全性相對較高，但也是明文傳輸。且post一般用來遞交資料，在資料傳輸方
面，理論上是沒有大小限制的，但是WEB伺服器會規定對post提交資料大小進行限制。

HTTP報文格式：

請求報文格式

<request-line>
<headers>
<blank line>
[<request-body>]

響應報文格式

<status-line>
<headers>
<blank line>
[<request-body>]

請求與響應報文的區別就是第一行，一個是請求行，一個是狀態行。

GET請求報文示例：

 GET /books/?sex=man&name=Professional HTTP/1.1
 Host: www.example.com
 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
 Gecko/20050225 Firefox/1.0.1
 Connection: Keep-Alive

POST請求報文示例（需要指定Content-Type，用於指示資源的MIME型別）：

 POST / HTTP/1.1
 Host: www.example.com
 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
 Gecko/20050225 Firefox/1.0.1
 Content-Type: application/x-www-form-urlencoded
 Content-Length: 40
 Connection: Keep-Alive

 sex=man&name=Professional  

注意:
    GET 可提交的資料量受到URL長度的限制，HTTP 協議規範沒有對 URL 長度進行限制。這個限制是特定的瀏覽器及伺服器對它的限制
    理論上講，POST 是沒有大小限制的，HTTP 協議規範也沒有進行大小限制，出於安全考慮，伺服器軟體在實現時會做一定限制
    參考上面的報文示例，可以發現 GET 和 POST 資料內容是一模一樣的，只是位置不同，一個在URL裡，一個在 HTTP 包的包體裡

---

3、HTTP 的響應報文的常見狀態碼

• 1xx : 指示資訊–表示請求已接收，繼續處理。
• 2xx : 成功–表示請求已經被成功接收、理解、接收。
• 3xx : 重定向–要完成請求必須進行更進一步的操作。
• 4xx : 客戶端錯誤–請求有語法錯誤或請求無法實現。
• 5xx : 服務端錯誤–伺服器未能實現合法的請求。

* 200 OK 客戶端請求成功
301 Moved Permanently 請求永久重定向（表示原 URL 不應再被使用，而應該優先選用新的 URL）
302 Moved Temporarily 請求臨時重定向（表示請求的資源現在臨時從不同的URI響應請求，由於
這樣的重定向是臨時的，客戶端應當繼續向原有地址傳送以後的請求。意思就是說訪問的資源可能暫時先用
location的URI訪問，但舊資源還在的，下次你再來訪問的時候可能就不用重定向了。）
304 Not Modified 檔案未修改，可以直接使用快取的檔案。
400 Bad Request 由於客戶端請求有語法錯誤，不能被伺服器所理解。
401 Unauthorized 請求未經授權。這個狀態程式碼必須和WWW-Authenticate報頭域一起使用
* 403 Forbidden 伺服器收到請求，但是拒絕提供服務。伺服器通常會在響應正文中給出不提供服務的原因
* 404 Not Found 請求的資源不存在，例如，輸入了錯誤的URL
500 Internal Server Error 伺服器發生不可預期的錯誤，導致無法完成客戶端的請求。
503 Service Unavailable 伺服器當前不能夠處理客戶端的請求，在一段時間之後，伺服器可能會恢復正常。

---

4、Cookie 和 Session

HTTP 是一種無狀態的連線，客戶端每次讀取 web 頁面時，伺服器都會認為這是一次新的會話。但有時候我們又需要持久保持某些資訊，比如登入時的使用者名稱、密碼，使用者上一次連線時的資訊等。這些資訊就由 Cookie 和 Session 儲存。

這兩者的根本性區別在於，cookie 儲存在客戶端上，而 session 則儲存在伺服器中。由此我們還可以擴充出以下結論：

1、cookie 相對來說不安全，瀏覽器可以分析本地的 cookie 進行 cookie 欺騙。
2、session 可以設定超時時間，超過這個時間後就失效，以免長期佔用服務端記憶體。
3、單個 cookie 的大小有限制（4 Kb），每個站點的 cookie 數量一般也有限制（20個）。
4、客戶端每次都會把 cookie 傳送到服務端，因此服務端可以知道 cookie，但是客戶端不知道 session。

當伺服器接收到 cookie 後，會根據 cookie 中的 SessionID 來找到這個客戶的 session。如果沒有，則會生成一個新的 SessionID 傳送給客戶端。session 的執行依賴 session id，而 session id 是存在 cookie 中的，也就是說，如果瀏覽器禁用了 cookie ，同時 session 也會失效（但是可以通過其它方式實現，比如在 url 中傳遞 session_id）。

---

4、與HTTPS的比較（預設使用443埠）

HTTP 協議直接使用了 TCP 協議進行資料傳輸。由於資料沒有加密，都是直接明文傳輸，會存在安全風險：

1、竊聽風險：第三方節點可以獲知通訊內容。
2、篡改風險：第三方節點可以修改通訊內容。
3、冒充風險：第三方節點可以冒充他人身份參與通訊。

HTTPS 協議則是在 HTTP 和 TCP 之間新增了一個 TLS/SSL 加密層，旨在：

1、保證所有資訊加密傳輸，無法被第三方竊取。
2、為資訊新增校驗機制，如果被第三方惡意破壞，可以檢測出來。
3、配備身份證書，防止第三方偽裝參與通訊。

這裡的證書是伺服器證明自己身份的工具，它由權威的證書頒發機構（CA）發給申請者。如果證書是虛假的，或者是自己給自己頒發的證書，伺服器就會不認可這個證書併發出警告：

總結一下 HTTPS 協議是如何避免前文所說的三大風險的：
1、先用非對稱加密傳輸密碼，然後用這個密碼對稱加密資料，使得第三方無法獲得通訊內容
2、傳送方將資料的雜湊結果寫到資料中，接收方解密後對比資料的雜湊結果，如果不一致則說明被修改。由於傳輸資料加密，第三方無法修改雜湊結果。
3、由權威機構頒發證書，再加上證書校驗機制，避免第三方偽裝參與通訊。

在使用HTTPS協議進行通訊的時候，採用的是混合加密方式，在SSL通訊階段利用（公開金鑰加密，即有兩個金鑰，一個是公鑰，一個是私鑰）非對稱加密對交換隨機密碼串，然後在資料通訊階段利用同一隨機密碼串進行資料加密傳輸，即共享金鑰加密（對稱金鑰加密）。
在進行SSL通訊階段，主要目的是將從客戶端生成的一種被稱為Pre-master secret的隨機密碼串傳輸給服務端，然後兩端就可以通過該密碼串對資料進行加密傳輸了。
而將隨機密碼串安全的從客戶端傳輸給服務端就是SSL通訊的關鍵，大致的步驟就是客戶端將自己支援的SSL的指定版本、加密元件列表（所使用的加密演算法及金鑰長度等）告知給服務端，服務端從中選出一種加密元件內容以及公開金鑰證書告知給客戶端，客戶端在接收到之後會利用證書驗證公開金鑰，在驗證成功之後，會生成一個隨機密碼串並用公開金鑰進行以及服務端指定的加密演算法進行加密，然後傳輸給服務端，服務端在接收之後利用私鑰以及對應的解密演算法進行解密，之後，兩端就可以利用該隨機密碼串進行資料等加密傳輸。

（具體的加密演算法暫不涉及）

---

參考文章：
【1】https://hit-alibaba.github.io/interview/basic/network/HTTP.html
【2】[面試∙網路] TCP/IP（六）：HTTP 與 HTTPS 簡介
【3】HTTPS科普掃盲帖