HTTP協議
概述
HTTP超文本傳輸協議規定了瀏覽器怎樣向萬維網服務器請求萬維網文檔, 以及服務器怎樣把文檔傳送給瀏覽器。
HTTP通過同一資源定位符URL獲得互聯網上資源的位置和訪問這些資源的方法。
URL, URN和URI
- URI (Uniform Resource Identifier) : 統一資源標識符
URI 是一種更高層次, 更抽象的概念, URN 和 URL 都是 URI 的子集 - URL(Uniform Resource Locator) : 統一資源定位器
URL是URI的一種, 不僅標識了Web 資源, 還指定了操作或者獲取方式, 同時指出了主要訪問機制和網絡位置。 - URN( Uniform Resource Name) : 統一資源命名
URN是URI的一種，用特定命名空間的名字標識資源。
HTTP報文
HTTP報文是由多行數據構成的字符串文本
客戶端發送的報文叫做請求報文，服務端回覆的報文爲響應報文。
報文結構
通用首部
| 首部字段名 | 說明 |
|---|---|
| Cache-Control | 控制緩存的行爲 |
| Connection | 控制不再轉發給代理的首部字段、管理持久連接 |
| Date | 創建報文的日期時間 |
| Pragma | 報文指令 |
| Trailer | 報文末端的首部一覽 |
| Transfer-Encoding | 指定報文主體的傳輸編碼方式 |
| Upgrade | 升級爲其他協議 |
| Via | 代理服務器的相關信息 |
| Warning | 錯誤通知 |
請求首部
| 首部字段名 | 說明 |
|---|---|
| Accept | 用戶代理可處理的媒體類型 |
| Accept-Charset | 優先的字符集 |
| Accept-Encoding | 優先的內容編碼 |
| Accept-Language | 優先的語言（自然語言） |
| Authorization | Web 認證信息 |
| Expect | 期待服務器的特定行爲 |
| From | 用戶的電子郵箱地址 |
| Host | 請求資源所在服務器 |
| If-Match | 比較實體標記（ETag） |
| If-Modified-Since | 比較資源的更新時間 |
| If-None-Match | 比較實體標記（與 If-Match 相反） |
| If-Range | 資源未更新時發送實體 Byte 的範圍請求 |
| If-Unmodified-Since | 比較資源的更新時間（與 If-Modified-Since 相反） |
| Max-Forwards | 最大傳輸逐跳數 |
| Proxy-Authorization | 代理服務器要求客戶端的認證信息 |
| Range | 實體的字節範圍請求 |
| Referer | 對請求中 URI 的原始獲取方 |
| TE | 傳輸編碼的優先級 |
| User-Agent | HTTP 客戶端程序的信息 |
響應首部
| 首部字段名 | 說明 |
|---|---|
| Accept-Ranges | 是否接受字節範圍請求 |
| Age | 推算資源創建經過時間 |
| ETag | 資源的匹配信息 |
| Location | 令客戶端重定向至指定 URI |
| Proxy-Authenticate | 代理服務器對客戶端的認證信息 |
| Retry-After | 對再次發起請求的時機要求 |
| Server | HTTP 服務器的安裝信息 |
| Vary | 代理服務器緩存的管理信息 |
| WWW-Authenticate | 服務器對客戶端的認證信息 |
實體首部
| 首部字段名 | 說明 |
|---|---|
| Accept-Ranges | 是否接受字節範圍請求 |
| Age | 推算資源創建經過時間 |
| ETag | 資源的匹配信息 |
| Location | 令客戶端重定向至指定 URI |
| Proxy-Authenticate | 代理服務器對客戶端的認證信息 |
| Retry-After | 對再次發起請求的時機要求 |
| Server | HTTP 服務器的安裝信息 |
| Vary | 代理服務器緩存的管理信息 |
| WWW-Authenticate | 服務器對客戶端的認證信息 |
HTTP請求方法
- GET
請求獲取資源 - POST
傳輸實體主體, 用來傳輸數據 - HEAD
獲取報文首部，與GET類似 - PUT
上傳文件，沒有驗證機制，不安全，一般不用 - PATCH
對資源進行部分修改 - DELETE
刪除文件，與PUT功能相反 - OPTIONS
查詢URL能支持的方法 - CONNECT
用於代理服務器
HTTP狀態碼
| 狀態碼 | 類別 | 含義 |
|---|---|---|
| 1XX | Informational（信息性狀態碼） | 接收的請求正在處理 |
| 2XX | Success（成功狀態碼） | 請求正常處理完畢 |
| 3XX | Redirection（重定向狀態碼） | 需要進行附加操作以完成請求 |
| 4XX | Client Error（客戶端錯誤狀態碼） | 服務器無法處理請求 |
| 5XX | Server Error（服務器錯誤狀態碼） | 服務器處理請求出錯 |
1XX 信息
- 100 Continue : 表明到目前爲止都很正常, 客戶端可以繼續發送請求或者忽略這個響應
2XX 成功
- 200 OK
- 204 No Content 請求成功處理, 返回的響應報文不包含實體的主體部分。 表示沒有數據返回。
- 206 Partial Content 表示客戶端進行了範圍請求，相應報文包含指定範圍的內容。
3XX 重定向
- 301 Moved Permanently 永久重定向
- 302 Found 臨時重定向
- 304 Not Modified 沒有滿足請求報文包含的一些條件。
4XX客戶端錯誤
- 400 Bad Requset 請求報文出現語法錯誤
- 401 Unauthorized 發送的請求需要有認證信息
- 403 Forbidden 請求被拒絕
- 404 Not Found 沒有找到對應的網頁信息
5XX服務器錯誤
- 500 Internal Server Error 服務器正在執行請求時發生錯誤
- 503 Service Unavailable 服務器處於超負荷或正停機維護
Cookie和Session
HTTP是無狀態的， 因此想要實現連接會話的管理（登陸狀態，信息記錄等），就需要引入Cookie來保存狀態信息。
Cookie是服務器發送到用戶瀏覽器並保存在本地的一塊小數據，它會在下次請求時被攜帶，用來維持會話。
創建過程
服務器發送響應報文時，在首部添加Set-Cookie字段
Set-Cookie: info=test
客戶端收到該報文時，取出Cookie信息並且在下次發送請求報文時攜帶上。
Cookie：info=test
Set-Cookie字段可設置一些Cookie的屬性
| 屬性 | 說明 |
|---|---|
| NAME=VALUE | 給Cookie賦予名稱和值（必選） |
| expires=DATA | Cookie的有效期，默認到瀏覽器關閉 |
| path=PATH | 到服務器上的目錄爲Cookie適用對象 |
| domain=域名 | Cookie使用的域名 |
| Secure | 僅在HTTPS下發送Cookie |
| HttpOnly | 防止Cookie被JavaScript訪問 |
長連接，短連接和流水線
當瀏覽器訪問一個HTML頁面是， 同時需要訪問多個頁面資源，還要請求圖片等，如果使用端連接每次請求訪問都建立一個TCP連接，那麼會有多餘的開銷浪費，如圖1。
HTTP/1.1 提出了長連接的方法，長連接如圖2， 只用建立一次連接即可進行多次HTTP通信，只要任意一段沒有明確提出斷開連接，則保持TCP連接狀態。
- HTTP/1.1默認長連接，設置通用首部Connection：close；即可斷開連接
- HTTP/1.1之前默認是短鏈接，使用長連接需設置Connection：Keep-Alive
流水線指在一條長連接上不等待響應返回而是連續發出請求，減少網絡傳輸的延遲開銷。
HTTPS
加密
對稱加密
加密和解密使用同一密鑰
- 優點 : 加密和解密速度快, 適合大數據場景
- 缺點 : 一對多的通信中需要維護多組密鑰, 且密鑰傳輸時容易被竊取。
非對稱加密
使用公鑰和私鑰一對密鑰，使用其中一個加密則需要用另一個解密。
- 優點：加密和解密使用不同的密鑰， 方便密鑰的傳輸和分發。
- 缺點：加密和解密的速度較慢。
HTTPS採用的加密方式
HTTPS採用混合的加密方式
- 客戶端向服務器發送請求, 獲取服務端的證書(帶有公鑰)
- 客戶端用公鑰加密對稱密鑰, 再發送給服務器.
- 服務器收到了加密的密鑰後, 用自己的私鑰進行解密, 這樣雙方就安全地獲得了對稱密鑰.
- 之後雙方使用對稱密鑰加密進行通信。
數字簽名
數字簽名就是加了密的校驗和
-
簽名的作用: 數字簽名對原文的保密性沒有要求, 主要負責發送者身份的驗證和發送內容完整的檢驗。
-
簽名原理：對要發送的內容採用哈希算法生成一段摘要，根據摘要可以驗證內容的完整性。 爲了防止摘要被篡改僞造，發送者可以用自己的私鑰對摘要進行加密，接受者將收到的內容生成的摘要和用公鑰就解密後的摘要進行對比，即可防止僞造摘要，也可以確認發送者身份。
-
存在的問題： 公鑰會被僞造
認證
爲了解決公鑰被僞造的問題， 引入了證書中心（CA機構）， 爲服務端的公鑰做認證。
證書的獲得：
- A找CA證書中心， 提供私鑰，組織信息，個人信息等，申請認證
- 證書中心通過線上，線下等手段驗證申請者的身份，向申請者發送數字證書。
- 數字證書的內容：A的公開密鑰，A的名稱，過期時間，證書發佈者，來自證書發佈者的數字簽名
證書的驗證：
- 客戶端收到證書後會對簽名的頒發機構進行檢查，如果堆機構一無所知，瀏覽器會提示是否信任該證書頒發機構
- 如果該機構是可信任的，客戶端會用簽名頒發機構的公鑰密鑰解密證書附帶的數字簽名，驗證證書的完整性和發送方的可靠性。
GET和POST比較
| GET | POST | |
|---|---|---|
| 用途 | 從服務器上獲取數據 | 向服務器上傳數據 |
| 請求行 | GET /url HTTP/1.1 | POST /url HTTP/1.1 |
| 請求體 | 沒有請求體 | 在首部後 以空行分割 |
| 參數 | 參數拼接在URL裏, 安全性較低，參數只能是ASCII，長度最大2048 | 參數放在請求體裏, 安全性較高，參數類型和長度均無限制 |
| 冪等性 | 瀏覽器退回和刷新無害 | 退回和刷新會重複提交 |
HTTP1.0 HTTP1.1 和 HTTP2.0的區別
| HTTP1.0 | HTTP1.1 | |
|---|---|---|
| 連接 | 默認使用短連接 | 默認長連接， 支持流水線 |
| 緩存 | 主要以header裏的If-Modified-Since,Expires爲判斷 | 增加了Entity tag, If-Unmodified-Since, If-Match等更多的緩存控制策略 |
| 帶寬優化 | header和body一起發送 | 支持只發送header信息, 如果服務器認爲客戶端有權限則返回100, 客戶端可繼續發送body, 無權限返回401, 則不需發送body, 節約帶寬。支持range範圍請求。 |
| Host請求首部 | 無法訪問同一個服務器IP地址上的不同主機 | 支持Host頭域，可以訪問同一服務器的不同主機。 |
| HTTP1.1 | HTTP2.0 | |
|---|---|---|
| 多路複用 | 客戶端在同一時間對同一域名的請求有一定數目限制 | 採用多路複用技術，給request加上id區分，一個連接可以併發處理多個request |
| 首部壓縮 | 不支持header數據壓縮 | 支持header數據壓縮，且雙方同時維護更新一個首部字段表，從而避免首部重複傳輸 |
| 服務器推送 | 不支持 | 在客戶端請求數據時，服務器會把相關的數據一同發送。比如請求一個page.html頁面時，服務器會將script.js和style.css等一起發送。 |