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連線。
參考資料
©️版權申明：版權所有@安木夕，本文內容僅供學習，歡迎指正、交流，轉載請註明出處！原文編輯地址-語雀