你須要知道的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數據傳輸方式

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

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

4.1 IP協議

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

4.2 TCP協議

• 位於傳輸層
• 做用是提供可靠的字節流服務
• 字節流服務：將大塊數據分割成以報文段爲單位的數據包
• 可靠：採用三次握手策略

4.3 DNS協議

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

4.4 各類協議的關係

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

區別

• 所屬協議層不一樣：tcp屬於傳輸層，http屬於應用層
• 職責不一樣：tcp解決數據傳輸問題，http解決數據包裝問題

聯繫

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

5. URL與URI

• URL：統一資源定位符，資源的地址。是URI的子集
• URI：統一資源標識符，用字符串標識某一互聯網資源
• URI的格式

  

6. 應用程序劃分

• 客戶端：請求資源的一端
• 服務端：提供資源響應的一端
• 代理：有轉發功能的應用程序，位於客戶端和服務器的中間人角色
  • 做用：緩存，訪問控制
• 網關：轉發其餘服務器通信數據的服務器。與代理相似，不過網關能使通訊線路上的服務器提供非http協議服務
  • 做用：提升安全性：客戶端與網關之間的通訊線路加密
• 隧道：客戶端與服務端創建一條特殊通訊線路，使用ssl等手段加密，提升安全性

二. HTTP報文

1. 概述

• 用於http協議交互的信息被稱爲報文
• 報文分爲請求報文和響應報文
• 報文首部字段包括不少維度：內容編碼，分塊傳輸，多部分對象集合，範圍請求，內容協商等

2. 報文格式

• 報文由報文首部和報文主體兩部分組成，中間由空行分開

  

• 請求行：包含請求方法（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的加密方式

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

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》