1.前言

這篇文章主要是我平時在學習HTTP過程中看到的一些知識點，現在把他們總結成一篇文章，建立一個自己的知識體系。

1.1基礎知識鋪墊

OSI是Open System Interconnection的縮寫，意為開放式系統互聯。

OSI有7層框架 如圖：

1）應用層(dns，http)DNS解析域名為IP併發送http地址

2）傳輸層(tcp,udp)建立tcp連線(三次握手)

3）網路層(IP,ARP)IP定址

4）資料鏈路層(PPP)封裝成幀

今天的主角是http：http是基於TCP/IP協議的應用層協議，用於客戶端和伺服器之間的通訊。HTTP是一個無狀態的協議。

1.2在TCP/IP協議棧中的位置

HTTP協議通常承載於TCP協議之上，有時也承載於TLS或SSL協議層之上，這個時候，就成了我們常說的HTTPS。如下圖所示：

預設HTTP的埠號為80，HTTPS的埠號為443。

2. HTTP發展歷程

1. HTTP/0.9版本，這個時候的HTTP只支援GET請求，且不支援請求頭，
2. HTTP/1.0版本，這是第一個在通訊中指定版本號的HTTP協議版本，至今仍被廣泛採用，特別是在代理伺服器中。
3. HTTP/1.1版本，持久連線被預設建立，並能很好地配合代理伺服器工作。還支援以管道方式在同時傳送多個請求，以便降低線路負載，提高傳輸速度。現在使用最廣泛的。
4. HTTP/2.0版本，當前版本，於2015年5月作為網際網路標準正式釋出。

3.HTTP請求

HTTP請求第一步，應該是由客戶端發起一個HTTP請求，當然這個客戶端可以是例如我們的瀏覽器，F12除錯，發起我們的第一個請求頭資訊。

http報文一般包括：通用頭部、請求/響應頭部、請求/響應體

假設我們現在開始請求CSDN主頁

通用頭部：

請求頭部

響應頭部

說一點：Content-Length當瀏覽器使用持久http連線才需要。

如果存在Transfer-Encoding（重點是chunked），則在header中不能有Content-Length，有也會被忽視

這裡插一句，HTTP/1.1沿用的是文字型別的請求頭，HTTP/2則會使用二進位制資料。

4.HTTP是如何建立連線的

說道如何連線的，我們必須要回顧一個東西，那就是大學學到過的計算機網路基礎，幾乎所有的大學生都應該瞭解過計算機的網路模型，也就是我們熟知的七層網路模型，如下圖

但是計算機網路中的七層模型畢竟是理想中的情況，現實是很少有應用實現了七層模型，一般都是整合其中兩個或多個，實現一個四層或者五層的模型。

TCP/IP模型

在這裡我們研究的是HTTP，自然要知道它所處在哪個模型中，答案是應用層。這裡要引入一個TCP/IP的概念，大家應該知道，TCP處於傳輸層，IP屬於網路層，而我們這裡所探究的HTTP，實際上就是基於TCP/IP協議開發的，至於TCP/IP的網路模型，它沒有照搬計算機網路的七層模型，而是整合了表示層,會話層，應用層,統一為應用層，比較有爭議的是，關於TCP/IP究竟是幾層協議，目前為止沒有定論，一般我比較習慣統稱為四層協議，至於別人說的五層協議，其實就是資料鏈路層,物理層是不是一層有所爭議吧。如圖：

因為HTTP是基於TCP/IP開發的協議，看過HTTP協議的同學肯定都知道，有句話概述HTTP協議為無差錯的協議，按序傳輸，未分段的資料流，這其實說的就是TCP協議。

5 傳送一條HTTP請求會發生什麼？

當你在瀏覽器輸入一個URL的時候，有沒有想過這其中發生了什麼？

1. 獲取主機名，例如：http://www.nowamagic.net/academy/

2. 通過DNS獲取伺服器IP

3. 獲取埠，預設是80埠

4. 連線到 121.199.24.143:80伺服器

5. 通過TCP通道傳送一個HTTP請求

6. 伺服器讀取一個HTTP請求

7. 伺服器查詢所需資源並通過TCP通道返回資源

8. 關閉TCP連線

6 .欄位解釋

通用頭部

這也是開發人員見過的最多的資訊，包括如下：

Request Url: 請求的web伺服器地址

Request Method: 請求方式（Get、POST、OPTIONS、PUT、HEAD、DELETE、CONNECT、TRACE）

Status Code: 請求的返回狀態碼，如200代表成功

Remote Address: 請求的遠端伺服器地址（會轉為IP）

這裡面最常用到的就是狀態碼，很多時候都是通過狀態碼來判斷，如（列舉幾個最常見的）：

200——表明該請求被成功地完成，所請求的資源傳送回客戶端
304——自從上次請求後，請求的網頁未修改過，請客戶端使用本地快取
400——客戶端請求有錯（譬如可以是安全模組攔截）
401——請求未經授權
403——禁止訪問（譬如可以是未登入時禁止）
404——資源未找到
500——伺服器內部錯誤
503——服務不可用

再列舉下大致不同範圍狀態的意義

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

請求/響應頭部

請求和響應頭部也是分析時常用到的

常用的請求頭部（部分）：

Accept:接收型別，表示瀏覽器支援的MIME型別（對標服務端返回的Content-Type）
Accept-Encoding：瀏覽器支援的壓縮型別,如gzip等,超出型別不能接收
Content-Type：客戶端傳送出去實體內容的型別
Cache-Control:指定請求和響應遵循的快取機制，如no-cache
If-Modified-Since：對應服務端的Last-Modified，用來匹配看檔案是否變動，只能精確到1s之內，http1.0中
Expires：快取控制，在這個時間內不會請求，直接使用快取，http1.0，而且是服務端時間
Max-age：代表資源在本地快取多少秒，有效時間內不會請求，而是使用快取，http1.1中
If-None-Match：對應服務端的ETag，用來匹配檔案內容是否改變（非常精確），http1.1中
Cookie:有cookie並且同域訪問時會自動帶上
Connection:當瀏覽器與伺服器通訊時對於長連線如何進行處理,如keep-alive
Host：請求的伺服器URL
Origin：最初的請求是從哪裡發起的（只會精確到埠）,Origin比Referer更尊重隱私
Referer：該頁面的來源URL(適用於所有型別的請求，會精確到詳細頁面地址，csrf攔截常用到這個欄位)
User-Agent：使用者客戶端的一些必要資訊，如UA頭部等

常用的響應頭部（部分）：

Access-Control-Allow-Headers: 伺服器端允許的請求Headers
Access-Control-Allow-Methods:伺服器端允許的請求方法
Access-Control-Allow-Origin:伺服器端允許的請求Origin頭部（譬如為*）
Content-Type：服務端返回的實體內容的型別
Date：資料從伺服器傳送的時間
Cache-Control：告訴瀏覽器或其他客戶，什麼環境可以安全的快取文件
Last-Modified：請求資源的最後修改時間
Expires：應該在什麼時候認為文件已經過期,從而不再快取它
Max-age：客戶端的本地資源應該快取多少秒，開啟了Cache-Control後有效
ETag：請求變數的實體標籤的當前值
Set-Cookie：設定和頁面關聯的cookie，伺服器通過這個頭部把cookie傳給客戶端
Keep-Alive：如果客戶端有keep-alive，服務端也會有響應（如timeout=38）
Server：伺服器的一些相關資訊

一般來說，請求頭部和響應頭部是匹配分析的。

譬如，請求頭部的Accept要和響應頭部的Content-Type匹配，否則會報錯

譬如，跨域請求時，請求頭部的Origin要匹配響應頭部的Access-Control-Allow-Origin，否則會報跨域錯誤

譬如，在使用快取時，請求頭部的If-Modified-Since、If-None-Match分別和響應頭部的Last-Modified、ETag對應

7.HTTPS

HTTPS = HTTP+加密+認證+完整性保護

它的加密過程是：

1.瀏覽器請求建立SSL連結，並向服務端傳送一個隨機數–Client random和客戶端支援的加密方法，比如RSA加密，此時是明文傳輸。
2.服務端從中選出一組加密演算法與Hash演算法，回覆一個隨機數–Server random，並將自己的身份資訊以證書的形式發回給瀏覽器（證書裡包含了網站地址，非對稱加密的公鑰，以及證書頒發機構等資訊）
3.瀏覽器收到服務端的證書後:

       -驗證證書的合法性（頒發機構是否合法，證書中包含的網址是否和正在訪問的一樣），如果證書信任，則瀏覽器會顯示一個小鎖頭，否則會有提示

      -使用者接收證書後（不管信不信任），瀏覽會生產新的隨機數–Premastersecret，然後證書中的公鑰以及指定的加密方法加密`Premaster secret`，傳送給伺服器。

      -利用Client random、Server random和Premaster secret通過一定的演算法生成HTTP連結資料傳輸的對稱加密key-`session key`

      -使用約定好的HASH演算法計算握手訊息，並使用生成的`session key`對訊息進行加密，最後將之前生成的所有資訊傳送給服務端.

4.服務端收到瀏覽器的回覆

    -利用已知的加解密方式與自己的私鑰進行解密，獲取`Premaster secret`

    -和瀏覽器相同規則生成`session key`

    -使用`session key`解密瀏覽器發來的握手訊息，並驗證Hash是否與瀏覽器發來的一致

    -使用`session key`加密一段握手訊息，傳送給瀏覽器

5.瀏覽器解密並計算握手訊息的HASH，如果與服務端發來的HASH一致，此時握手過程結束.

8. http2.0

http2.0不是https，它相當於是http的下一代規範（譬如https的請求可以是http2.0規範的）

然後簡述下http2.0與http1.1的顯著不同點：

http1.1中，每請求一個資源，都是需要開啟一個tcp/ip連線的，所以對應的結果是，每一個資源對應一個tcp/ip請求，由於tcp/ip本身有併發數限制，所以當資源一多，速度就顯著慢下來

http2.0中，一個tcp/ip請求可以請求多個資源，也就是說，只要一次tcp/ip請求，就可以請求若干個資源，分割成更小的幀請求，速度明顯提升。

所以，如果http2.0全面應用，很多http1.1中的優化方案就無需用到了（譬如打包成精靈圖，靜態資源多域名拆分等）

然後簡述下http2.0的一些特性：

• 多路複用（即一個tcp/ip連線可以請求多個資源）
• 首部壓縮（http頭部壓縮，減少體積）
• 二進位制分幀（在應用層跟傳送層之間增加了一個二進位制分幀層，改進傳輸效能，實現低延遲和高吞吐量）
• 伺服器端推送（服務端可以對客戶端的一個請求發出多個響應，可以主動通知客戶端）
• 請求優先順序（如果流被賦予了優先順序，它就會基於這個優先順序來處理，由伺服器決定需要多少資源來處理該請求。)

9. 跨域

跨域產生的原因，是因為受到同源策略的限制。同源策略指的是協議、域名、埠不相同。這裡我將介紹三種跨域的方式：JSONP、CORS(跨域資源共享)、document.domain + iframe。

9.1 JSONP

1. 原理

動態插入script標籤（因為script標籤不受同源策略的限制），通過插入script標籤引入一個js檔案，這個js檔案載入成功之後會執行我們在url中指定的回撥函式，並且會把我們需要的json資料作為引數傳入。

2. 實現

（1）原生實現：

var script = document.createElement('script');
script.type = 'text/javascript';
// 傳參並指定回撥執行函式為onBack
script.src = 'http://www.domain2.com:8080/login?user=admin&callback=onBack';
document.head.appendChild(script);
// 回撥函式
function onBack(res) 
{
   alert(JSON.stringify(res));
}
//服務端返回如下（返回時即執行全域性函式）：
onBack({"status": true, "user": "admin"})

（2）jquery ajax：

$.ajax({url:'http://www.domain2.com:8080/login',    
type: 'get',
dataType: 'jsonp',  // 請求方式為jsonp
jsonpCallback: "onBack", // 自定義回撥函式名
data: {}
});

9.2 CORS

1. 原理

伺服器在響應頭中設定相應的選項，瀏覽器如果支援這種方法的話就會將這種跨站資源請求視為合法，進而獲取資源。

2. 實現

CORS分為簡單請求和複雜請求，簡單請求指的是：

（1）請求方法是以下三種方法之一：HEAD、GET、POST；

（2）HTTP的頭資訊不超出以下幾種欄位：Accept、Accept-Language、Content-Language、Last-Event-ID、
         Content-Type（只限於三個值application/x-www-form-urlencoded、multipart/form-data、text/plain）。

其他情況就是非簡單請求了。

• 簡單請求

（1）請求頭：

Origin: http://www.domain.com

（2）響應頭：

Access-Control-Allow-Origin: http://www.domain.com
Access-Control-Allow-Credentials: true //`是否允許傳送cookie`
Access-Control-Expose-Headers: FooBar //`CORS請求時，只能拿到6個基本欄位：Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma。如果想拿到其他欄位，就必須指定。`

（3）另外，ajax請求中,如果要傳送Cookie，Access-Control-Allow-Origin就不能設為星號，必須指定明確的、與請求網頁一致的域名，還要設定以下內容：

var xhr = new XMLHttpRequest();

xhr.withCredentials = true;

• 非簡單請求

（1）預檢請求:

OPTIONS /cors HTTP/1.1  `OPTIONS請求是用來詢問的`
Origin: http://www.domian.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: X-Custom-Header

（2）響應頭：

Access-Control-Allow-Origin: http://www.domain.com
Access-Control-Allow-Methods: GET, POST, PUT  `伺服器支援的所有跨域請求的方法`
Access-Control-Allow-Headers: X-Custom-Header  `伺服器支援的所有頭資訊欄位，不限於瀏覽器在"預檢"中請求的欄位。`
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 1728000  `指定本次預檢請求的有效期，單位為秒`

（3）之後的步驟就同簡單請求了。

這是CORS的整個流程圖：

與JSOP的比較：

JSONP只支援GET請求，CORS支援所有型別的HTTP請求。JSONP的優勢在於支援老式瀏覽器，以及可以向不支援CORS的網站請求資料。