前言

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》