01、準備
1.1、先了解下網絡模型/TCP
HTTP 連接是建立在 TCP* 協議之上的，其數據傳輸功能是由TCP完成的，那TCP又是什麼呢？
TCP 是一個單純用來建立通信連接，並傳輸數據的基礎協議，屬於網絡模型中的的傳輸層。
OSI 模型（Open System Interconnection Model）是一個由國際標準化組織（ISO）提出的概念模型，目的是爲計算機網絡提供一個標準框架。它將計算機網絡體系結構劃分爲七層，每層都提供抽象良好的接口，負責不同的職責。瞭解 OSI 模型有助於理解實際上互聯網絡的工業標準——TCP/IP 協議，以及前端開發常用的HTTP協議。
| OSI七層模型 | TCP/IP概念層模型 | 功能 | TCP/IP協議族 |
|---|---|---|---|
| 應用層 | 應用層 | 文件傳輸，電子郵件，文件服務，虛擬終端 | TFTP， HTTP，SNMP，FTP，SMTP，DNS，Telnet |
| 表示層 | 數據格式化，代碼轉換，數據加密 | 沒有協議 | |
| 會話層 | 解除或建立與別的連接點的聯繫 | 沒有協議 | |
| 傳輸層 | 傳輸層 | 提供端對端的接口 | TCP，UDP |
| 網絡層 | 網絡層 | 爲數據包選擇路由 | IP，ICMP， RIP，OSPF，BGP，IGMP |
| 數據鏈路層 | 鏈路層 | 傳輸有地址的幀以及錯誤檢測功能 | SLIP，CSLIP，PPP，ARP，RARP，MTU |
| 物理層 | 以二進制數據形式在物理媒體上傳輸數據 | IS02110，IEEE802，IEEE802.2 |
要建立TCP連接需要：①請求 --> ②確認 --> ③建立連接，就是著名的三次握手 🤝🏻。TCP的三次握手建立連接後，就可以開始進行通信（數據傳輸）了。所以要正式通信一次，前期要傳輸交換多次信息（多次握手），這麼做的目的是爲了確保雙方的狀態正確，保障數據的傳輸是完整、有序、可靠無差錯的。
- 第一次握手：客戶端發送syn包到服務器，並進入SYN_SENT狀態，等待服務器確認。
- 第二次握手：服務器收到syn包，必須確認客戶的SYN，同時自己也發送一個SYN包（syn=y），即SYN+ACK包，此時服務器進入SYN_RECV狀態。
- 第三次握手：客戶端收到服務器的SYN+ACK包，向服務器發送確認包ACK，此包發送完畢，客戶端和服務器進入連接成功狀態，完成三次握手。夫妻對拜，禮成，進入洞房！
02、認識HTTP協議
2.1、HTTP 是什麼？
HTTP —— HyperText Transfer Protocol，超文本傳輸協議。是當今互聯網上應用最爲廣泛的一種網絡協議，所有的 WWW（萬維網） 文件都必須遵守這個標準。包括三個部分：超文本、傳輸、協議。
- 🔸協議：協議就是一種事先的約定規範，HTTP協議是面向計算機，用於計算機之間通信的規範，規範了內容的結構、行爲、錯誤處理機制等。就像我們以前用的“郵編+地址”也是一種通信協議。
- 🔸傳輸：從一端（A）傳輸內容導另一端（B）的過程，就是傳輸，傳輸過程A、B是雙向的。客戶端（瀏覽器）向服務端請求網頁數據，服務端收到請求後返回對應的數據，客戶端（瀏覽器）收到數據後渲染出網頁展示給用戶。
- 🔸超文本：HTTP 傳輸的內容是「超文本」，字面意思就是超越了基本文字內容各種互聯網內容，包括圖片、音頻、視頻、壓縮包、文件等，都是HTTP的「超文本」，這些內容通過瀏覽器渲染展現出來，創造了豐富多彩的網絡生活。
🔵 HTTP 就是用來在計算機/網絡裏傳輸超文本數據的一種協議規範，主要特點是：
- 簡單，基本報文結構就是
header+body，header中信息都是key:vlaue結構的。 - 靈活：結構中的各種數據字段並沒有嚴格的限制，可以靈活的自定義擴展。如可以添加新的狀態碼，可以在
header中擴展任意字段。 - 跨平臺：HTTP的應用非常廣泛，幾乎所有平臺都支持。
🟠缺點：
- 無狀態：客戶端與服務端通信都是無狀態的，沒有前後文的概念。好處是不用管理狀態，只單純的處理好每一次請求即可。但當遇到一些場景，如登錄、選購商品、下單支付，是一連串的操作，有前後關聯的，就得自己實現上下文管理了。常用
cookie、session、sessionStorage來解決。 - 明文傳輸不安全：明文傳輸，在傳輸過程中很容易被截獲、篡改，解決辦法就是啓用HTTPS。
2.2、HTTP協議結構
HTTP協議的報文結構：start-line、header、body
Header中的字段爲 key: value結構，按行分割。
| 常用Header字段 | 描述 |
|---|---|
| 🪧請求頭 request-line | 第一行爲 請求行：請求方法 URL HTTP協議版本，空格分割。請求方法有GET、POST等 |
| Host | 發送的目標，服務器的域名、端口號 |
| Connection | 網絡連接方式，默認值keep-alive表示使用 TCP 持久連接，以便其他請求複用 |
| Accept | 告訴服務端可以接受的資源的（MME）類型 |
| Accept-Encoding | 告訴服務端可以支持哪些壓縮方式，常用壓縮方式：gzip主流、deflate、brHTTP專用壓縮算法 |
| Cookie | Cookie數據 |
| User-Agent | 瀏覽器表明自己的身份 |
| Referer | 表示請求引用自哪個地址 |
| 🪧響應頭 status-line | 第一行爲 狀態行：HTTP協議版本 狀態碼 狀態碼描述，空格分割 |
| Content-Length | 服務器返回數據的長度 |
| Content-Type | 資源的（MME）類型，告訴客戶端是什麼類型的資源 |
| Content-Encoding | 發送的實體數據採用的編碼類型（壓縮方式），和Accept-Encoding對應 |
| Transfer-Encoding | 值chunked表示分塊傳輸數據 |
| Server | 表示服務器名稱 |
| Set-Cookie | 後端設置的 Cookie 信息 |
| Expires | 緩存過期時長 |
🪧請求HTTP報文：
GET / HTTP/1.1 //* 請求行，URL中的域名部分再Host字段， *//
Host: www.baidu.com //* 請求的地址 *//
Accept: text/html,image/avif,image/webp,*/*; //* 告訴服務端可以接受的資源的（MME）類型 *//
Accept-Encoding: gzip, deflate, br //* 告訴服務端可以支持哪些壓縮方式 *//
Connection: keep-alive
🪧響應HTTP報文：
HTTP/1.1 200 OK //* 響應狀態行 *//
Connection: keep-alive //* 保持長連接 *//
Content-Encoding: gzip //* 數據採用了gzip壓縮，客戶端對應採用gzip進行解壓 *//
Content-Type: text/html; charset=utf-8 //* 返回數據的類型爲文本/網頁html，編碼格式爲utf-8 *//
content-length: 4560 //* 返回實體數據的長度 *//
2.3、HTTP狀態碼
| 狀態碼 | 描述 | 常用狀態碼 |
|---|---|---|
| 1xx | 🪧提示信息，處理的中間狀態，很少用 | 無 |
| 2xx | ✅處理成功的狀態 | - 200: OK 成功，一切正常，最常用。- 204: No Content 成功但沒有body數據- 206: Partial Content 成功但仍需繼續，常用於分塊下載、斷點續傳 |
| 3xx | ⚠️重定向，客戶端請求的資源發送了變動，需要重新發起請求繼續處理 | - 301: Moved Permanently 永久重定向，請求的資源轉移到了新URL- 302: Found 請求的頁面臨時移動到新URL，後續請求繼續用原URL- 304: Not Modified 資源未修改，客戶端緩存了資源，重定向到本地 |
| 4xx | 🚫客戶端發生錯誤：語法、請求錯誤等，服務端無法處理 | - 400: Bad Request 請求的報文有錯誤，具體不明- 403: Forbidden 請求了服務端禁止訪問的資源（ /fərˈbɪdn/ 禁止的）- 404: Not Found 請求的資源不存在、未找到 |
| 5xx | ⛔服務端發生錯誤：不能滿足客戶端請求 | - 500: Internal Server Error 服務端錯誤，具體不明- 501: Not Implemented 還沒實現，暫不支持- 502: Bad Gateway 網關、代理錯誤- 503: Service Unavailable 服務端很忙，請稍後再試 |
打開百度首頁資源列表-狀態：
2.4、請求方式GET/POST/...
| 請求方式 | 描述 |
|---|---|
| GET | 請求指定的頁面數據，請求的參數放在URL地址中 |
| POST | 向指定資源提交數據，請求服務器處理，數據在請求體body中。數據可以是ASCII字符也可以是字節型數據 |
| HEAD | 類似GET請求，用於獲取響應的頭部信息，不返回內容。 |
| PUT | 即向指定資源位置上傳其最新內容，可用於上傳、更新資源。 |
| DELETE | 請求服務器刪除所標識的資源 |
| TRACE | 回顯服務器收到的請求，主要用於測試或診斷。 |
| OPTIONS | 允許客戶端訪問服務器的性能 |
| CONNECT | HTTP/1.1協議中預留給能夠將連接改爲管道方式的代理服務器。通常用於SSL加密服務器的鏈接（經由非加密的HTTP代理服務器）。 |
✔️最常用的是GET、POST兩種方式。RESful API 接口規範的一般會用到
POST、DELETE、GET、PUT（分別對應增刪查改）。
❓GET、POST區別：
| GET | POST | |
|---|---|---|
| 提交方式 | 數據在url的問號?後：url?key=value&key=... |
數據在請求體body中 |
| 編碼enctype | 只有appliacation-x-www-form-urlencoded | 支持多種 |
| 書籤/歷史 | 可以加入收藏，歷史記錄、日誌會保留數據 | 不可收藏、不會保留數據 |
| 緩存/效率 | 可以被瀏覽器緩存，效率（速度）更高 | 不可緩存 |
| 數據類型/長度 | 只允許 ASCII 字符，URL長度有限制（2048），不同瀏覽器不同。 | 類型沒有限制，支持二進制數據。長度（幾乎）無限制 |
| 安全性 | 安全性更低，數據在URL中容易暴露 | 安全性稍高，不過傳輸過程也是明文的，不會在瀏覽記錄、日誌中存儲 |
| 回退/刷新？ | 無副作用（冪等），可重複訪問，因爲只是 讀取 信息 | 有副作用，數據會被重新提交（不冪等），瀏覽器一般會提示用戶數據會被重新提交 |
| 使用場景 | 獲取數據 | 提交數據：添加、修改、刪除 |
📢「冪等」，意思是多次執行相同的操作，結果都是「相同」。
- 在 HTTP 協議裏，所謂的「安全」是指請求方法不會「破壞」服務器上的資源。
03、HTTPS有什麼用？
3.1、什麼是HTTPS？
HTTPS：超文本傳輸安全協議（Hyper Text Transfer Protocol over Secure Socket Layer）。可以理解爲多了個一個S（Secure）的HTTP，主要是解決HTTP不安全的問題。
HTTP 是明文傳輸，存在安全風險的問題。HTTPS 則解決了 HTTP 不安全的缺陷，在 TCP 和 HTTP 網絡層之間加入了 SSL/TLS 安全協議，使得報文能夠加密傳輸，解決了HTTP存在的安全問題。SSL / TLS 全稱安全傳輸層協議 Transport Layer Security，是介於 TCP 和 HTTP 之間的一層安全協議，不影響原有 TCP、HTTP 協議，所以使用 HTTPS 基本上不需要對 HTTP 頁面進行改造。
- ✅ 加密防竊聽：採用對稱加密+非對稱加密的混合加密的方式，對傳輸的數據加密，實現信息的機密性，解決了竊聽的風險。
- ✅ 摘要防篡改：用摘要算法爲數據生成獨一無二的「指紋」校驗碼，指紋用來校驗數據的完整性，解決了被篡改的風險。
- ✅ CA證書防假冒：將服務端的公鑰放入到CA數字證書中，解決了服務端被冒充的風險。特別是一些假冒的淘寶、銀行網站就無處遁形了。
➤ HTTP、HTTPS的主要區別：
| HTTP | HTTPS | |
|---|---|---|
| 加密傳輸？ | 明文傳輸 | 混合加密傳輸，比較安全 |
| 建立連接 | TCP三次握手 | TCP三次握手 + SSL/TLS握手 |
| 默認端口號 | 80 | 443 |
| 證書 | 沒有 | 服務端需要CA數字證書，保障服務端身份是可信的 |
📢總結：HTTPS相比HTTP，在建立連接時多了一次握手（SSL/TLS握手），傳輸數據時，多了數據加密。
HTTPS 在 TCP 三次握手之後，還需進行 SSL/TLS 的握手過程🤝🏻，纔可開始加密通信。SSL/TLS 協議基本流程：
- ① 客戶端向服務器索要並驗證服務器的公鑰。客戶端收到服務端的數字證書後，會基於瀏覽器、操作系統中的CA公鑰進行驗證，確保服務端是可信的，這裏的CA數字證書是由專門的權威的機構來簽發、認證和管理的。
- ② 雙方協商產生「會話祕鑰」。基於數字證書，及多次握手中產生的數據，成本次通信的「會話祕鑰」。
- ③ 雙方採用「會話祕鑰」進行加密通信。後面就和普通的HTTP通信類似，多了數據加密、數據摘要。
- 🔐對稱加密：使用相同密鑰加密/解密，密鑰容易泄漏。
- 🔐非對稱加密：公鑰加密數據，私鑰解密數據，但是加密/解密耗時多。
- 🔐混合加密：二者結合，公鑰加密密鑰，密鑰加密數據，私鑰解密密鑰，密鑰解密數據（非對稱傳送密鑰，對稱密鑰傳送數據，完美！）。
3.2、SSL/TLS是什麼？和HTTPS的關係？
SSL/TLS可以理解爲HTTPS的一部分，是HTTPS的安全協議，實現了HTTP安全的數據傳輸（加密+校驗）。SSL、TLS兩者算是同伴關係，作用一樣，TLS是SSL的升級版，兩者都在使用，瀏覽器都支持。
- SSL（Secure Sockets Layer ，安全套接層）： 是由公司設計的用於Web的安全傳輸協議，使用廣泛。
- TLS（Transport Layer Security，傳輸層安全）：1999年，互聯網標準化組織ISOC接替網景（NetScape）公司，發佈了SSL的升級版 TLS。
04、HTTP協議版本1.0/1.1/2
1997年發佈的HTTP/1.1版本使用至今，是目前主流的HTTP協議版本。2015年HTTP/2 發佈，是基於谷歌的SPDY 協議，在Chrome瀏覽器中率先支持，可能有不到一般的網站支持。
| HTTP版本 | 特點/描述 |
|---|---|
| HTTP/1.0 | 🔵主要特點（不足）： - 短連接：每次通信都需建立新的TCP連接，請求、響應完成後結束連接。通信效率低，需要頻繁的建立連接。 - 串行：一次通信（請求、響應）結束後才能繼續下一次。 |
| HTTP/1.1 | 🔵主要特點： - 長鏈接：也叫持久連接，建立一次TCP連接後可重複使用，一直保持TCP連接，任意一方主動斷開纔會結束連接。 - 管道傳輸：不必串行排隊等候了，可以並行連續發送多次請求，但服務端會順序處理。 🟠缺點： - Header：不支持壓縮（只有Body支持壓縮），每次相同的 header浪費，特別是Cookie、User Agent- 隊頭阻塞，在服務端，如果前面的請求服務端還沒處理完，後面的請求就會排隊等候，順序執行沒有優先級控制。 - 單向請求：客戶端請求，服務端被動響應，服務端無法主動聯繫客戶端。 |
| HTTP/2 | 🟢基於HTTPS，所以是有安全保障的： - Header：支持頭部 header壓縮，以及重複header的優化。- 幀數據： header/body都是二進制格式，統稱爲幀（frame）。HTTP/1.1的header爲文本（ASCII編碼），body支持文本/二進制。- 多路複用：支持並行請求、響應，客戶端、服務端都不用排隊等待了。 - 服務器推送，服務器可以主動推送數據到客戶端。 |
| HTTP/3 | 主要改進在傳輸層上，基於UDP協議，主要特點是快⚡。HTTP 3.0 於 2022 年 6 月正式發佈，依然是谷歌發起的。 |
HTTP連接是建立在TCP協議之上的，屬於應用層協議，所以HTTP通信需要先建立TCP連接。
參考資料
©️版權申明：版權所有@安木夕，本文內容僅供學習，歡迎指正、交流，轉載請註明出處！原文編輯地址-語雀