你需要知道的http協議

kinnylee發表於2018-09-24
HTTP協議

前言

1. http和tcp有什麼區別和聯絡？

2. http報文格式是什麼樣的？

3. http常用的頭部欄位分別代表什麼含義？

4. http常用的狀態碼分別代表什麼含義？

5. https提供了哪些機制保證安全？

6. websocket解決了http的什麼弊端？

目錄

http相關基本概念

http報文

http響應狀態碼

http安全-https

http認證

websocket協議

一. 基本概念

1. 概述

  • web理念：文件之間相關關聯，連成可相互參閱的全球資訊網（www）
  • web互連（通訊）的基礎：tcp/ip協議族，http屬於它內部的子集
  • web（www）的三項構建技術：
    • html：頁面使用什麼語言展示
    • URL：頁面在什麼位置
    • http：文件之間傳遞的協議是什麼
  • tcp/ip協議族分層包括：資料鏈路層，網路層，傳輸層 ，應用層
  • tcp/ip協議族分層作用：各層各司其職，模組劃分清晰，便於維護，解耦

2. 各分層概述

2.1 應用層

  • 決定了向使用者提供應用服務時通訊的活動
  • 包括：FTP，DNS，HTTP等

2.2 傳輸層

  • 提供網路中兩臺計算機之間的資料傳輸
  • 包括：TCP，UDP

2.3 網路層

  • 眾多選項中選擇合適的傳輸路徑傳輸資料包

2.4 鏈路層

  • 用來處理網路的硬體部分

3. tcp/ip資料傳輸方式

你需要知道的http協議

  • 利用tcp/ip協議族通訊時，通過分層順序通訊。
  • 傳送端從應用層往下走，接收端從應用層往上走
  • 傳送端每經過一層都會被打上該層所屬的首部資訊，接收端每經過一層將把首部去掉

4. 與http協議密不可分的協議

4.1 IP協議

  • 位於網路層
  • 作用是把各種資料包傳送給對方
  • 確保傳送正確的兩個條件
    • IP地址：指明瞭節點被分配到的地址。可變。
    • MAC地址：網路卡所屬的固定地址。不可變。

4.2 TCP協議

  • 位於傳輸層
  • 作用是提供可靠的位元組流服務
  • 位元組流服務：將大塊資料分割成以報文段為單位的資料包
  • 可靠：採用三次握手策略

4.3 DNS協議

  • 應用層協議
  • 作用是提供域名到ip地址之間的解析服務

4.4 各種協議的關係

你需要知道的http協議

4.5 http協議和tcp協議的區別與聯絡

區別

  • 所屬協議層不同：tcp屬於傳輸層，http屬於應用層
  • 職責不同：tcp解決資料傳輸問題，http解決資料包裝問題

聯絡

  • http協議是構建在tcp協議之上的
  • 打個比方：ip是高速公路，tcp是跑在高速公路上的卡車，http是卡車裡面的包裹

5. URL與URI

  • URL：統一資源定位符，資源的地址。是URI的子集
  • URI：統一資源識別符號，用字串標識某一網際網路資源
  • URI的格式
    你需要知道的http協議

6. 應用程式劃分

  • 客戶端：請求資源的一端
  • 服務端：提供資源響應的一端
  • 代理：有轉發功能的應用程式，位於客戶端和伺服器的中間人角色
    • 作用：快取，訪問控制
  • 閘道器：轉發其他伺服器通訊資料的伺服器。與代理類似，不過閘道器能使通訊線路上的伺服器提供非http協議服務
    • 作用：提高安全性：客戶端與閘道器之間的通訊線路加密
  • 隧道：客戶端與服務端建立一條特殊通訊線路，使用ssl等手段加密，提高安全性

二. HTTP報文

1. 概述

  • 用於http協議互動的資訊被稱為報文
  • 報文分為請求報文和響應報文
  • 報文首部欄位包括很多維度：內容編碼，分塊傳輸，多部分物件集合，範圍請求，內容協商等

2. 報文格式

  • 報文由報文首部和報文主體兩部分組成，中間由空行分開
    你需要知道的http協議
  • 請求行：包含請求方法（get，post），請求URI，http版本
  • 狀態行：響應結果狀態碼，原因，http版本
  • 首部欄位：通用首部，實體首部，請求首部，響應首部
  • 其他：cookie等資訊

3. 內容編碼

  • 指明內容等編碼格式，客戶端負責解碼
  • 能有效地處理大量等訪問請求，不過會消耗更多cpu
  • 常用的內容編碼
    • gzip（GNU zip）
    • compress（unix系統標識壓縮）
    • deflate（zlib）
    • identity（不編碼）

4. 分塊傳輸

  • 把實體主體分塊的功能
  • 用於傳輸大容量資料
  • 每一塊都標記大小，最後一塊用0標記

5. 多部分物件集合

  • 傳送一份報文主體內可包含多型別實體
  • 使用時需要在首部欄位裡新增：Content-type
  • 包含的物件如下（content-type的值）：
    • multipart/form-data：web表單檔案上傳時使用
    • multipart/byteranges：響應報文包含多個範圍的內容時使用

6. 範圍請求

  • 指定範圍傳送的請求
  • 解決網路中斷必須從頭下載的問題
  • 用到首部欄位Range指定資源的byte範圍：Ranges：bytes=5001-10000
  • 響應會返回206狀態碼和響應報文

7. 內容協商

  • 客戶端和服務端就響應內容進行交涉，提供最合適的資源
  • 協商判斷的依據有：響應資源的語言，字符集，編碼方式
  • 包含的首部欄位：Accept，Accept-Charset，Accept-Encoding，Accept-Language，Content-Language

三. 響應狀態碼

1. 概述

  • 描述請求的處理結果
  • 狀態碼的類別
    狀態碼 類別 描述
    1XX 資訊性狀態碼 接收的請求正在處理
    2XX 成功的狀態碼 請求正常處理完畢
    3XX 重定向狀態碼 需要進行附加操作以完成請求
    4XX 客戶端錯誤狀態碼 伺服器無法處理請求
    5XX 伺服器錯誤狀態碼 伺服器處理請求出錯

2. 2XX成功

  • 200： OK：正常處理
  • 204： No Content，伺服器接受的請求成功處理，但返回但響應報文不包含主體部分
  • 206: Partial Content，伺服器成功執行客戶端的範圍請求，響應報文中包含Content-Range指定範圍的內容

3. 3XX重定向

  • 301: 永久性重定向，表示請求的資源已經分配了新的uri，以後應使用新的uri

  • 302: 臨時性重定向，表示請求的資源uri臨時性被移動

  • 303: 指明客戶端應該用Get方法去請求，而不是post

    當301， 302， 303狀態碼返回時，幾乎所有瀏覽器都會把Post改為Get，並刪除請求報文的主體，之後請求會自動再次傳送

  • 304: Get請求中含有附加條件時，請求的資源不滿足這些條件。這些附加條件包括：If-Math，If-Modified-Since，If-None-Match，If-Range，If-UnModified-Since中的任意一個

  • 307：臨時重定向，類似302，不過不會從post變為get

4. 4XX客戶端錯誤

  • 400：請求報文中存在語法錯誤
  • 401: 使用者認證失敗
  • 403: 無許可權訪問
  • 404: 無法找到請求的資源，url不存在

5. 5XX服務端錯誤

  • 500: 伺服器處理出錯，可能是內部的bug
  • 502: 錯誤的閘道器，資源傳送給上游伺服器時傳送不了
  • 503: 伺服器處理高負載或停機維護狀態，無法處理請求

四. Http首部

1. 首部欄位的格式

  • 首部欄位名：欄位值（可為多個）
  • 單值：Content-Type: text/html
  • 多值：Keep-Alive：timeout=15, max=100
  • 首部欄位重複，規範裡沒有明確規定如何處理，各個瀏覽器不同

2. 首部欄位分類

  • 通用首部欄位：請求和響應都使用的欄位
  • 請求首部欄位：客戶端資訊，請求的附加資訊等
  • 響應首部欄位：響應的附加資訊
  • 實體首部欄位：請求和響應的實體部分使用的欄位

3. 首部欄位概覽

  • http1.1共規定裡47中首部欄位

3.1 通用首部欄位有：

  • Cache-Control：控制快取的行為
  • Connection：連線的管理
    • Keep-Alive：維持持續連線（http1.1預設持久連線，之前版本沒有）
    • close：表示關閉持久連線
    • 其他首部欄位：表示這個首部欄位不再轉發給代理伺服器
  • Date：建立時間
  • Pragma：報文指令
    • http1.0及向前版本的相容欄位
  • Trailer：報文末端的首部
  • Transfer-Encoding：報文主體傳輸編碼方式
    • http1.1僅對分塊傳輸有效
  • Upgrade：升級為其他協議
  • Via：代理伺服器相關資訊
  • Warning：錯誤通知

3.2 常用的請求首部欄位有：

  • Accept：使用者代理可處理的媒體型別
  • Accept-Charset：優先的字符集
  • Accept-Encoding：優先的內容編碼
    • gizp
    • compress
    • deflate
    • identity
  • Accept-Language：優先的語言
  • Authorization：web認證資訊
  • Host：請求資源的伺服器
  • User-Agent：客戶端程式資訊
  • Range：欄位範圍請求
  • Referer：請求的原始資源的URI

3.3 常用的響應首部欄位有：

  • Accept-Ranges：是否接受欄位範圍請求
  • Age：推算欄位建立經過時間
  • Server：伺服器的安裝資訊
  • Retry-After：再次發起請求的時機要求

3.4 常用的實體首部欄位有：

  • Allow：可支援的http方法
  • Content-Encoding：實體主體的編碼方式
  • Content-Language：實體主體的自然語言
  • Content-Length：實體主體大小
  • Content-Type：實體主體的媒體型別
  • Expires：過期時間
  • Last-Modified：最後修改時間

3.5 其他首部欄位

  • Cookie：請求首部欄位，伺服器收到客戶端傳來的cookie
  • Set-Cookie：響應欄位，伺服器傳給客戶端的cookie。包含的屬性：
    • name=value：cookie的名稱和值
    • expires：有效期，不指定則預設為瀏覽器關閉時
    • path：伺服器上的檔案目錄作為Cookie的適用物件
    • domain：cookie適用物件的域名
    • Secure：僅在https安全通訊時才會傳送cookie
    • HttpOnly：Cookie不能被javascript指令碼訪問
  • Connection
  • Keep-Alive

五. HTTPS

1. http的缺點

  • 通訊適用明文（不加密），內容可能會被竊聽
  • 不驗證通訊方的身份，可能遭遇偽裝。典型如：DOS攻擊
  • 無法證明報文的完整性，內容可以被篡改。典型如：中間人攻擊（MITM）

2. 解決策略

2.1 防止被竊聽的對策

  • 內容的加密：將http報文所含的內容進行加密。該方案的缺點：
    • 需要客戶端和伺服器都有加密和解密機制
    • 內容也有被篡改的風險
  • 通訊的加密：http協議中沒有加密機制，通過和SSL，TLS組合使用，加密http的通訊內容。SSL在客戶端和伺服器建立安全的通訊線路。

2.2 防止偽裝的對策

  • SSL提供的證照，可以作為通訊雙方身份認證的功能

2.3 防止內容被篡改的策略

  • SSL提供的摘要功能可以解決

3. HTTPS

3.1 概述

  • https = http + 加密 + 認證 + 完整性保護
  • https並非應用層新協議，只是通訊介面部分用SSL和TLS協議代替而已
  • http直接和tcp通訊。使用ssl時，http先和ssl通訊，再由ssl和tcp通訊

3.2 常用的加密方式

共享金鑰加密

  • 也叫對稱金鑰加密，加密和解密用同一個金鑰
  • 缺點：無法安全的將金鑰傳送給接收方

公開金鑰加密

  • 使用一對非對稱的金鑰，一把交私有金鑰，一把交公開金鑰。
  • 傳送密文的一方使用對方的公開金鑰進行加密，對方收到加密資訊後用自己的私鑰解密
  • 不需要傳送私鑰，不用擔心資訊被竊取
  • 要根據密文和公鑰恢復原文資訊，以目前的技術是非常困難的
  • 缺點：處理速度較慢

3.3 https的加密方式

你需要知道的http協議

  • 採用共享金鑰加密和公開金鑰加密兩種方式
  • 交換金鑰環節採用公開金鑰加密
  • 建立通訊之後，報文交換階段採用共享金鑰加密

3.4 數字證照

  • 公開金鑰加密的問題：無法證明公開金鑰本身的正確性
  • 解決方案：由數字證照機構和相關機構頒發的公開金鑰證照

3.5 為什麼不一直使用https

  • 加密通訊會消耗更多的cpu和記憶體資源，伺服器處理的請求量會降低。所以一般非敏感資訊使用http，敏感資訊才使用https
  • 購買證照的開銷比較大

六. http認證

1. 概述

http1.1使用的認證方式有：

  • Basic認證
  • Digest認證
  • SSL客戶端認證
  • FormBase認證

2. Basic認證

  • http1.0就定義的認證方式
  • 原理：將”使用者名稱：密碼”字串做base64加密，然後作為首部Authorization欄位的值傳給服務端
  • 缺點：沒有加密，安全等級低
  • 使用率：並不常用

3. Digest認證

  • http1.1定義的認證，為了彌補basic認證的不足
  • 原理：傳送方請求認證->接收方返回質詢碼->傳送方根據質詢碼計算響應碼發給接收方做驗證
  • 優點：提供防止密碼被竊聽的保護機制
  • 缺點：無法保證使用者被偽裝
  • 使用率：仍達不到web網站安全要求，使用受限

4. SSL客戶端認證

  • 藉助客戶端的證照完成認證
  • 雙因素認證方式：密碼+證照。
  • 使用率：客戶端證照需要一定費用，尚未普及

5. FormBase認證

  • web應用程式各自實現的認證方式
  • 使用率：web應用常用的認證方式

6. 狀態的管理

  • http本身沒有狀態管理，每次請求並不知道上次請求內容
  • 使用Cookie和Session作為狀態管理，彌補了http的不足

六. WebSocket協議

1. 概述

  • 是html5提供的一種在單個tcp連線上進行全雙工通訊的協議

2. 為什麼會出現該協議？

http協議有以下弊端：

  • 一條連線上只可以傳送一條請求
  • 請求只能從客戶端開始，客戶端不可用接受除響應以外的指令
  • 首部資訊沒有壓縮，延遲大
  • 每次請求都要傳送冗長的首部資訊
  • 可任意選擇壓縮格式，沒有強制壓縮

websocket協議為解決這些弊端而生。

3. websocket的特點

  • 支援伺服器向客戶端推送資料的功能。伺服器可直接傳送資料，不用等待客戶端請求
  • 減少通訊量：只要建立連線，就一直保持連線狀態。不僅連線開銷小，且首部資訊很少，減少通訊量

4. websocket通訊機制

  • 在http建立連線後，需要完成一次“握手”步驟
  • 附加頭資訊中新增"Upgrade: WebSocket"，表明這是一個申請協議升級的 HTTP 請求
  • Sec-WebSocket-Key:記錄握手過程中的鍵值
  • Sec-WebSocket-Protocol：記錄使用的子協議

參考文獻

《圖解http》

相關文章