1，簡介

作為一個安卓開發者，從安卓開發的角度學習下HTTP。先來對HTTP有個大概的印象吧，一步一步慢慢了解。

Http：HyperText Transfer Protocol，即是超文本傳輸協議，是一個基于TCP/IP通信協議來傳遞數據。最新版本 HTTP/2 更是讓它成為技術熱點。

• 支持客戶/服務器模式。支持基本認證和安全認證。
• 簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯系的類型不同。由于HTTP協議簡單，使得HTTP服務器的程序規模小，因而通信速度很快。
• 靈活：HTTP允許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。
• HTTP 1.1使用持續連接：不必為每個web對象創建一個新的連接，一個連接可以傳送多個對象。
• 無狀態：HTTP協議是無狀態協議。無狀態是指協議對于事務處理沒有記憶能力。缺少狀態意味著如果后續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大。另一方面，在服務器不需要先前信息時它的應答就較快。

2，工作流程

簡單介紹下工作流程，下面一章開始簡單介紹，每個點都能詳細說上一本書了，下面的介紹并不鉆入細節研究。

1. 首先客戶機與服務器需要建立連接。只要單擊某個超級鏈接，HTTP的工作開始。
2. 建立連接后，客戶機發送一個請求給服務器，請求方式的格式為：統一資源標識符（URL）、協議版本號，后邊是MIME信息包括請求修飾符、客戶機信息和可能的內容。
3. 服務器接到請求后，給予相應的響應信息，其格式為一個狀態行，包括信息的協議版本號、一個成功或錯誤的代碼，后邊是MIME信息包括服務器信息、實體信息和可能的內容。
4. 客戶端接收服務器所返回的信息通過瀏覽器顯示在用戶的顯示屏上，然后客戶機與服務器斷開連接。如果在以上過程中的某一步出現錯誤，那么產生錯誤的信息將返回到客戶端，有顯示屏輸出。

3，詳解

一，URL

Http請求第一步肯定是要知道請求地址啊，地址都錯了還玩蛋啊！404什么的多蛋疼。

URL是尋找信息時所需要的資源位置。通過URL客戶端才能找到網絡中的大量數據資源。

URL語法：<方案>://<用戶名>:<密碼>@主機:端口/路徑;參數?查詢#片段，幾乎沒有幾個URL包含了所有這些組件。如：https://www.qycloud.com.cn/notice/index

• 第一部分http是URL的方案，方案告訴客戶端使用什么樣的協議去訪問服務器了，也可以是fpt或https等。
• 第二部分 www.qycloud.com.cn ，localhost：8080，指服務器的位置。端口號默認80
• 第三部分 /notice/index是資源路徑，說明了請求的是服務器上哪個特定的本地資源。

二. 發送請求：

HTTP在開始傳輸之前，首先需要建立TCP連接，而TCP連接的過程需要所謂的“三次握手”?！?gt;請求 <——確認 連接——>。一個重要的概念是面向連接，既HTTP在傳輸完成之間并不斷開TCP連接，默認都開啟了Keep-Alive。

http請求由三部分組成，分別是：請求行、消息報頭、請求正文。
請求報文的格式：

<方法><資源路徑><協議版本>
<報文頭信息>
<報文體信息>

如：

GET /notice/index  HTTP/1.1 
Host:www.qycloud.com.cn

1. 請求行

請求行以一個方法符號開頭，以空格分開，后面跟著請求的URI和協議的版本，格式如下：Method Request-URI HTTP-Version CRLF 。

看上面那個請求報文，表示從/notice目錄下請求index這個文件，這個請求行和消息報頭的可以看出請求的URL：https://www.qycloud.com.cn/notice/index。

其中 Method表示請求方法；Request-URI是一個統一資源標識符；HTTP-Version表示請求的HTTP協議版本；CRLF表示回車和換行（除了作為結尾的CRLF外，不允許出現單獨的CR或LF字符）。

2. 消息報頭

請求報頭允許客戶端向服務器端傳遞請求的附加信息以及客戶端自身的信息。
在HTTP/1.1 協議中，所有的請求頭，除Host外，都是可選的。上面那個例子中的Host就是。

簡單介紹幾個請求報頭：

• Accept：瀏覽器端可以接受的MIME類型。例如：Accept: text/html 代表瀏覽器可以接受服務器回發的類型為 text/html 也就是我們常說的html文檔。Accept: / 代表瀏覽器可以處理所有類型，(一般瀏覽器發給服務器都是發這個)。
• Accept-Charset：瀏覽器可接受的字符集。如果在請求消息中沒有設置這個域，缺省表示任何字符集都可以接受。
• Content-Type：例如：Content-Type: application/x-www-form-urlencoded,application/json。
• Host：（發送請求時，該報頭域是必需的）
  Host請求報頭域主要用于指定被請求資源的Internet主機和端口號，它通常從HTTP URL中提取出來的。
• Connection：例如：Connection: keep-alive 當一個網頁打開完成后，客戶端和服務器之間用于傳輸HTTP數據的TCP連接不會關閉。Connection: close 代表一個Request完成后，客戶端和服務器之間用于傳輸HTTP數據的TCP連接會關閉。
• Cookie：最重要的請求頭之一, 將cookie的值發送給HTTP服務器。
• Authorization：授權信息，通常出現在對服務器發送的WWW-Authenticate頭的應答中。主要用于證明客戶端有權查看某個資源。當瀏覽器訪問一個頁面時，如果收到服務器的響應代碼為401（未授權），可以發送一個包含Authorization請求報頭域的請求，要求服務器對其進行驗證。

3. 請求正文

就是我們Post請求傳遞的請求內容放在報文體信息中。

三. 返回響應信息

響應報文會將請求的結果返回給客戶端。請求報文和響應報文的結構基本相同。
響應報文格式：

<協議版本><狀態碼><原因短語>
<報文頭信息>
<報文體信息>

如：

HTTP/1.1 200 OK
Content-Type:image/gif
Conetnt-Length4567

可以看出請求報文和響應報文只有起始行的語法不同。

1. 狀態行

格式如下：
HTTP-Version Status-Code Reason-Phrase CRLF

其中，HTTP-Version表示服務器HTTP協議的版本；Status-Code表示服務器發回的響應狀態代碼；Reason-Phrase表示狀態代碼的文本描述。
狀態代碼有三位數字組成，第一個數字定義了響應的類別，且有五種可能取值.

狀態碼取值：

• 100~199 信息，服務器收到請求，需要請求者繼續執行操作
• 200~299 成功，操作被成功接收并處理
• 300~399 重定向，需要進一步的操作以完成請求
• 400~499 客戶端錯誤，請求包含語法錯誤或無法完成請求
• 500~599 服務器錯誤，服務器在處理請求的過程中發生了錯誤
  常用的有：
• 200-請求成功
• 404-請求的資源不存在
• 500-內部服務器錯誤

2. 響應報頭：

響應報頭允許服務器傳遞不能放在狀態行中的附加響應信息，以及關于服務器的信息和對Request-URI所標識的資源進行下一步訪問的信息。

• Date：表示消息發送的時間，時間的描述格式由rfc822定義。例如，Date:Mon,31Dec200104:25:57GMT。Date描述的時間表示世界標準時，換算成本地時間，需要知道用戶所在的時區。
• Content-Type：告訴客戶端自己響應的對象的類型和字符集。
• Content-Length：指明實體正文的長度，以字節方式存儲的十進制數字來表示。只有當瀏覽器使用持久HTTP連接時才需要這個數據。
• Connection：例如：Connection: keep-alive 當一個網頁打開完成后，客戶端和服務器之間用于傳輸HTTP數據的TCP連接不會關閉，如果客戶端再次訪問這個服務器上的網頁，會繼續使用這一條已經建立的連接。
• Connection: close 代表一個Request完成后，客戶端和服務器之間用于傳輸HTTP數據的TCP連接會關閉，當客戶端再次發送Request，需要重新建立TCP連接。
• Location：響應報頭域用于重定向接受者到一個新的位置。Location響應報頭域常用在更換域名的時候。

4. HTTPS

HTTPS（全稱：Hypertext Transfer Protocol over Secure Socket Layer），是以安全為目標的HTTP通道，簡單講是HTTP的安全版。可以說HTTPS = HTTP + SSL。

1. HTTPS通信過程

(來源)

image

2. HTTP 和 HTTPS 的不同之處

HTTPS 和 HTTP 唯一不同的只是一個協議頭(https)的說明，其他都是一樣的。

• HTTP 的 URL 以 http:// 開頭，而 HTTPS 的 URL 以 https:// 開頭
• HTTP 標準端口是 80 ，而 HTTPS 的標準端口是 443
• 在 OSI 網絡模型中，HTTP 工作于應用層，而 HTTPS 工作在傳輸層
• HTTP 無需加密，而 HTTPS 對傳輸的數據進行加密
• HTTP 無需證書，而 HTTPS 需要認證證書

HTTPS 跟 HTTP 一樣，只不過增加了 SSL。

HTTP 包含如下動作：

• 瀏覽器打開一個 TCP 連接
• 瀏覽器發送 HTTP 請求到服務器端
• 服務器發送 HTTP 回應信息到瀏覽器
• TCP 連接關閉

SSL 包含如下動作：

• 驗證服務器端
• 允許客戶端和服務器端選擇加密算法和密碼，確保雙方都支持
• 驗證客戶端(可選)
• 使用公鑰加密技術來生成共享加密數據
• 創建一個加密的 SSL 連接
• 基于該 SSL 連接傳遞 HTTP 請求

3. Https解決的問題

• 信任主機的問題
• 通訊過程中的數據的泄密和被篡改

4. SSL協議的握手協議

結合前面那張通信圖看，這里只是詳細解釋。

• 1,客戶端的瀏覽器向服務器傳送客戶端SSL 協議的版本號，加密算法的種類，產生的隨機數，以及其他服務器和客戶端之間通訊所需要的各種信息。
• 2,服務器向客戶端傳送SSL 協議的版本號，加密算法的種類，隨機數以及其他相關信息，同時服務器還將向客戶端傳送自己的證書。
• 3,客戶利用服務器傳過來的信息驗證服務器的合法性，服務器的合法性包括：證書是否過期，發行服務器證書的CA 是否可靠，發行者證書的公鑰能否正確解開服務器證書的“發行者的數字簽名”，服務器證書上的域名是否和服務器的實際域名相匹配。如果合法性驗證沒有通過，通訊將斷開；如果合法性驗證通過，將繼續進行第四步。
• 4,用戶端隨機產生一個用于后面通訊的“對稱密碼”，然后用服務器的公鑰（服務器的公鑰從步驟2中的服務器的證書中獲得）對其加密，然后將加密后的“預主密碼”傳給服務器。
• 5,如果服務器要求客戶的身份認證（在握手過程中為可選），用戶可以建立一個隨機數然后對其進行數據簽名，將這個含有簽名的隨機數和客戶自己的證書以及加密過的“預主密碼”一起傳給服務器。
• 6,如果服務器要求客戶的身份認證，服務器必須檢驗客戶證書和簽名隨機數的合法性，具體的合法性驗證過程包括：客戶的證書使用日期是否有效，為客戶提供證書的CA 是否可靠，發行CA 的公鑰能否正確解開客戶證書的發行CA 的數字簽名，檢查客戶的證書是否在證書廢止列表（CRL）中。檢驗如果沒有通過，通訊立刻中斷；如果驗證通過，服務器將用自己的私鑰解開加密的“預主密碼”，然后執行一系列步驟來產生主通訊密碼（客戶端也將通過同樣的方法產生相同的主通訊密碼）。
• 7,服務器和客戶端用相同的主密碼即“通話密碼”，一個對稱密鑰用于SSL 協議的安全數據通訊的加解密通訊。同時在SSL 通訊過程中還要完成數據通訊的完整性，防止數據通訊中的任何變化。
• 8,客戶端向服務器端發出信息，指明后面的數據通訊將使用的步驟7中的主密碼為對稱密鑰，同時通知服務器客戶端的握手過程結束。
• 9,服務器向客戶端發出信息，指明后面的數據通訊將使用的步驟7中的主密碼為對稱密鑰，同時通知客戶端服務器端的握手過程結束。
• 10,SSL 的握手部分結束，SSL 安全通道的數據通訊開始，客戶和服務器開始使用相同的對稱密鑰進行數據通訊，同時進行通訊完整性的檢驗。

參考：
Http協議
HTTP協議詳解（真的很經典）
HTTP協議詳解