【計算機網絡】你真的瞭解HTTP（HTTPS）協議的這12個知識點嗎

HTTP協議

1. 介紹一下OSI七層參考模型和TCP/IP五層模型

1.1 OSI七層模型

1.2 TCP/IP五層模型

1.3 各層的設備

[各層設備]

1.4 各層對應協議

2. HTTP協議和特色

2.1 基本概念

[!NOTE]
HTTP是Hyper Text Transfer Protocol（超文本傳輸協議）的縮寫。它是一個應用層協議，由請求和響應構成，是一個標準的客戶端服務器模型。HTTP是一個無狀態的協議。

2.2 數據包結構

數據包細節

2.3 協議的特色

1. 無鏈接(重點理解)

• 限制每次鏈接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接。採用這種方式能夠節省傳輸時間。

1. 無狀態

• 協議對於事務處理沒有記憶能力。

1. 簡單快速

• 客戶向服務器請求服務時，只需傳送請求方法和路徑。

1. 靈活

• HTTP容許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。

2.4 請求報文

• 請求行
  • 請求類型
  • 要訪問的資源
  • HTTP協議版本號
• 請求頭
  • 用來講明服務器要使用的附加信息（一些鍵值對）
  • 例如：User-Agent、 Accept、Content-Type、Connection
• 空行
  • 分割請求頭與請求體
• 請求體
  • 能夠添加任意的其餘數據

2.5 響應報文

• 狀態行
  • 狀態碼
  • 狀態消息
  • HTTP協議版本號
• 消息報頭
  • 說明客戶端要使用的一些附加信息
  • 如：Content-Type、charset、響應的時間
• 響應正文
  • 返回給客戶端的文本信息

2.6 HTTP 方法

• GET
  • 獲取資源
• POST
  • 傳輸資源
• PUT
  • 更新資源
• DELETE
  • 刪除資源
• HEAD
  • 獲取報文首部

2.6.1 Post 和 Get 的區別

• GET在瀏覽器回退時是無害的，而POST會再次提交
• 重點Get請求能緩存，Post不能
• Post相對Get相對安全一些，由於Get請求都包含在URL中，並且會被瀏覽器保存記錄，Post不會。可是再抓包的狀況下都是同樣的。
• Post 能夠經過 request body來傳輸比 Get 更多的數據
• URL有長度限制，會影響 Get 請求，可是這個長度限制是瀏覽器規定的
• Post 支持更多的編碼類型且不對數據類型限制
• 重點POST，瀏覽器先發送header，服務器響應100 continue，瀏覽器再發送data，服務器響應200 ok(返回數據)
• 補充：100狀態碼錶示（繼續）請求者應當繼續提出請求。 服務器返回此代碼表示已收到請求的第一部分，正在等待其他部分。

反作用和冪等的概念

[!NOTE]

1. 反作用：指對服務器上的資源作改變，搜索是無反作用的，註冊是反作用的。
2. 冪等：指發送 M 和 N 次請求（二者不相同且都大於 1），服務器上資源的狀態一致，好比註冊 10 個和 11 個賬號是不冪等的，對文章進行更改 10 次和 11 次是冪等的。

[!NOTE]
在規範的應用場景上說，Get 多用於無反作用，冪等的場景，例如搜索關鍵字。Post 多用於反作用，不冪等的場景，例如註冊。

2.7 常見狀態碼

2.7.1 1XX 指示信息（面試考點）

表示請求已接收，繼續處理

2.7.2 2XX 成功

• 200 OK
• 204 No content，表示請求成功，但響應報文不含實體的主體部分
• 205 Reset Content，表示請求成功，但響應報文不含實體的主體部分，可是與 204 響應不一樣在於要求請求方重置內容
• 206 Partial Content，進行範圍請求

2.7.3 3XX 重定向

• 301 永久性重定向，表示資源已被分配了新的 URL
• 302 臨時性重定向，表示資源臨時被分配了新的 URL
• 303 表示資源存在着另外一個 URL，應使用 GET 方法獲取資源
• 304 未修改，重定位到瀏覽器。自從上次請求後，請求的網頁未修改過。服務器返回此響應時，不會返回網頁內容。若是網頁自請求者上次請求後再也沒有更改過，您應將服務器配置爲返回此響應（稱爲 If-Modified-Since HTTP 標頭）。服務器能夠告訴 Googlebot 自從上次抓取後網頁沒有變動，進而節省帶寬和開銷。
• 307 臨時重定向，和302含義相似，可是指望客戶端保持請求方法不變向新的地址發出請求

2.7.4 4XX 客戶端錯誤

• 404 在服務器上沒有找到請求的資源
• 403 forbidden，表示對請求資源的訪問被服務器拒絕
• 400 請求報文存在語法錯誤
• 401 表示發送的請求須要有經過 HTTP 認證的認證信息

2.7.5 5XX 服務器錯誤

• 500 表示服務器端在執行請求時發生了錯誤
• 501 表示服務器不支持當前請求所須要的某個功能
• 503 代表服務器暫時處於超負載或正在停機維護，沒法處理請求

2.8 HTTP持久鏈接（HTTP1.1支持）

[!NOTE]
HTTP協議採用「請求-應答」模式，而且HTTP是基於TCP進行鏈接的。普通模式（非keep-alive）時，每一個請求或應答都須要創建一個鏈接，完成以後當即斷開。

當使用Conection: keep-alive模式（又稱持久鏈接、鏈接重用）時，keep-alive使客戶端道服務器端鏈接持續有效，即不關閉底層的TCP鏈接，當出現對服務器的後繼請求時，keep-alive功能避免從新創建鏈接。

2.9 HTTP管線化 （HTTP1.1支持）

管線化後，請求和響應再也不是依次交替的了。他能夠支持一次性發送多個請求，並一次性接收多個響應。

• 只有get與head請求能夠進行管線化，POST有限制
• 初次建立鏈接時不該該啓動管線機制，由於服務器不必定支持該協議

2.10 HTTP數據協商

在客戶端向服務端發送請求的時候，客戶端會申明能夠接受的數據格式和數據相關的一些限制是什麼樣的；服務端在接受到這個請求時他會根據這個信息進行判斷到底返回怎樣的數據。

2.10.1 請求

• cookie
• Host
  
• Connection
• Accept
  • 在請求中使用Accept可申明想要的數據格式(image/webp,image/apng,image/)
• Accept-Encoding
  • 告訴服務端使用什麼的方式來進行壓縮
  • 例如：gzip、deflate、br
• Accept-Language
  • 描述語言信息(zh-CN)
• User-Agent(Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.15 Safari/537.36)
  • 用來描述客戶端瀏覽器相關信息
  • 能夠用來區分PC端頁面和移動端頁面

2.10.2 響應

• Content-Type
  • 對應Accept，從請求中的Accept支持的數據格式中選一種來返回
• Content-Encoding
  • 對應 Accept-Encoding，指服務端到底使用的是那種壓縮方式
• Content-Language
  • 對應Accept-Language

2.10.3 form 表單中enctype數據類型

• application/x-www-form-urlencoded
  • key=value&key=value 格式
• multipart/form-data
  • 用於提交文件
  • multipart表示請求是由多個部分組成（由於上傳文件的時候文件不能以字符串形式提交，須要單獨分出來）
  • boundary 用來分隔不一樣部分
• text/plain

// 原生ajax 方式對get的url，使用POST請求方式進行發送
document.querySelector("#btnAjax").onclick = function () {
     var ajax = new XMLHttpRequest();

     // 使用post請求
     ajax.open('post','ajax_post.php');

     // 若是 使用post發送數據 必須 設置 以下內容
     // 修改了 發送給 服務器的 請求報文的 內容
     // 若是須要像 HTML 表單那樣 POST 數據，請使用 setRequestHeader() 來添加 HTTP 頭。而後在 send() 方法中規定您但願發送的數據：
     ajax.setRequestHeader("Content-type","application/x-www-form-urlencoded");
     // 發送
     // post請求 發送的數據 寫在 send方法中
     // 格式 name=jack&age=18 字符串的格式
     ajax.send('name=jack&age=998');

     // 註冊事件
     ajax.onreadystatechange = function () {
         if (ajax.readyState==4&&ajax.status==200) {
             console.log(ajax.responseText);
         }
     }
 }

2.11 HTTP Redirect 重定向

• 302 暫時重定向
  • 瀏覽器每次訪問都要先去目標網址訪問，再重定向到新的網址
• 301 永久重定向
  • 當瀏覽器收到的HTTP狀態碼爲301時，下次訪問對應網址就直接調整到新的網址，不會再訪問原網址

2.12 HTTP CSP 內容安全策略

HTTP CSP 內容安全策略

CSP Content-Security-Policy

• 限制資源獲取
• 報告資源獲取越權

例子：

• Content-Security-Policy: default-src http: https: 表示只容許經過http、https的方式加載資源
• 'Content -Security-Policy': 'default-src' \'self\'; form-action\'self\' ' 表示只能加載本域下的資源，只能向本域發送表單請求

2.12.1 TLS 握手過程以下圖

1. 客戶端發送一個隨機值，須要的協議和加密方式
2. 服務端收到客戶端的隨機值，本身也產生一個隨機值，並根據客戶端需求的協議和加密方式來使用對應的方式，發送本身的證書（若是須要驗證客戶端證書須要說明）
3. 客戶端收到服務端的證書並驗證是否有效，驗證經過會再生成一個隨機值，經過服務端證書的公鑰去加密這個隨機值併發送給服務端，若是服務端須要驗證客戶端證書的話會附帶證書
4. 服務端收到加密過的隨機值並使用私鑰解密得到第三個隨機值，這時候兩端都擁有了三個隨機值，能夠經過這三個隨機值按照以前約定的加密方式生成密鑰，接下來的通訊就能夠經過該密鑰來加密解密.

經過以上步驟可知，在 TLS 握手階段，兩端使用非對稱加密的方式來通訊，可是由於非對稱加密損耗的性能比對稱加密大，因此在正式傳輸數據時，兩端使用對稱加密的方式通訊。

3. HTTP2(面試重點)

[!NOTE]
HTTP 2.0 相比於 HTTP 1.X，能夠說是大幅度提升了 web 的性能。

在 HTTP 1.X 中，爲了性能考慮，咱們會引入雪碧圖、將小圖內聯、使用多個域名等等的方式。這一切都是由於瀏覽器限制了同一個域名下的請求數量，當頁面中須要請求不少資源的時候，隊頭阻塞（Head of line blocking）會致使在達到最大請求數量時，剩餘的資源須要等待其餘資源請求完成後才能發起請求。

3.1 二進制傳輸

HTTP 2.0 中全部增強性能的核心點在於此。在以前的 HTTP 版本中，咱們是經過文本的方式傳輸數據。在 HTTP 2.0 中引入了新的編碼機制，全部傳輸的數據都會被分割，並採用二進制格式編碼。

3.2 多路複用

在 HTTP 2.0 中，有兩個很是重要的概念，分別是幀（frame）和流（stream）。

幀表明着最小的數據單位，每一個幀會標識出該幀屬於哪一個流，流也就是多個幀組成的數據流。

多路複用，就是在一個 TCP 鏈接中能夠存在多條流。換句話說，也就是能夠發送多個請求，對端能夠經過幀中的標識知道屬於哪一個請求。經過這個技術，能夠避免 HTTP 舊版本中的隊頭阻塞問題，極大的提升傳輸性能。

3.3 Header 壓縮

在 HTTP 1.X 中，咱們使用文本的形式傳輸 header，在 header 攜帶 cookie 的狀況下，可能每次都須要重複傳輸幾百到幾千的字節。

在 HTTP 2.0 中，使用了 HPACK 壓縮格式對傳輸的 header 進行編碼，減小了 header 的大小。並在兩端維護了索引表，用於記錄出現過的 header ，後面在傳輸過程當中就能夠傳輸已經記錄過的 header 的鍵名，對端收到數據後就能夠經過鍵名找到對應的值。

3.4 服務端 Push

在 HTTP 2.0 中，服務端能夠在客戶端某個請求後，主動推送其餘資源。

能夠想象如下狀況，某些資源客戶端是必定會請求的，這時就能夠採起服務端 push 的技術，提早給客戶端推送必要的資源，這樣就能夠相對減小一點延遲時間。固然在瀏覽器兼容的狀況下你也可使用 prefetch。

4. HTTP首部

通用字段	做用
Cache-Control	控制緩存的行爲
Connection	瀏覽器想要優先使用的鏈接類型，好比 keep-alive
Date	建立報文時間
Pragma	報文指令
Via	代理服務器相關信息
Transfer-Encoding	傳輸編碼方式
Upgrade	要求客戶端升級協議
Warning	在內容中可能存在錯誤

請求字段	做用
Accept	能正確接收的媒體類型
Accept-Charset	能正確接收的字符集
Accept-Encoding	能正確接收的編碼格式列表
Accept-Language	能正確接收的語言列表
Expect	期待服務端的指定行爲
From	請求方郵箱地址
Host	服務器的域名
If-Match	兩端資源標記比較
If-Modified-Since	本地資源未修改返回 304（比較時間）
If-None-Match	本地資源未修改返回 304（比較標記）
User-Agent	客戶端信息
Max-Forwards	限制可被代理及網關轉發的次數
Proxy-Authorization	向代理服務器發送驗證信息
Range	請求某個內容的一部分
Referer	表示瀏覽器所訪問的前一個頁面
TE	傳輸編碼方式

響應字段	做用
Accept-Ranges	是否支持某些種類的範圍
Age	資源在代理緩存中存在的時間
ETag	資源標識
Location	客戶端重定向到某個 URL
Proxy-Authenticate	向代理服務器發送驗證信息
Server	服務器名字
WWW-Authenticate	獲取資源須要的驗證信息

實體字段	做用
Allow	資源的正確請求方式
Content-Encoding	內容的編碼格式
Content-Language	內容使用的語言
Content-Length	request body 長度
Content-Location	返回數據的備用地址
Content-MD5	Base64加密格式的內容 MD5檢驗值
Content-Range	內容的位置範圍
Content-Type	內容的媒體類型
Expires	內容的過時時間
Last_modified	內容的最後修改時間

參考文章： http://www.javashuo.com/article/p-mjsgoetv-bt.html

參考連接：https://blog.csdn.net/sinat_21455985/article/details/53508115