HTTP---基礎知識

天天開心！！！

文章目錄

一、HTTP基本概念
- 1. 什么是HTTP，又有什么用？
- 2. 一次HTTP請求的過程
- 3.HTTP的協議頭
- 4.POST和GET的區別
- 5. HTTP狀態碼
- 6.HTTP的優缺點
二、HTTP的版本演進
- 1.各個版本的應用場景
- 2、注意要點
三、HTTP與HTTPS
- 1.HTTTPS的工作原理

一、HTTP基本概念

1. 什么是HTTP，又有什么用？

HTTP（Hyper Text Transfer Protocol，超文本傳輸協議），是用于客戶端和服務器之間數據傳輸的應用層協議，主要用在Web瀏覽器和服務器之間的通信。HTTP最初是為傳輸HTML文檔設計的，但現在支持多種類型的數據，如圖片、視頻、文本等。

舉個例子
Web瀏覽：瀏覽器使用HTTP從服務器獲取網頁和資源，如圖片和CSS文件
數據傳輸：開發者使用HTTP在客戶端和服務器之間發送和接收數據，特別是在Web API和RESTT服務中。每當你通過瀏覽器訪問一個網頁的時候。你往往會輸入：http://www.baidu.com…

在這里插入圖片描述

無狀態性：每個HTTP請求都是獨立的，不記錄之前的任何請求，請求一次，就返回一次（與之前的單播類似）。這簡化了協議的實現，但可能會需要使用其他格式（如Cookies或Sessions）來保存狀態

2. 一次HTTP請求的過程

在這里插入圖片描述

底層過程：

1. 輸入域名 -> 瀏覽器跳轉 -> 瀏覽器DNS緩存 -> 本地DNS緩存 -> 路由器DNS緩存 -> DNS服務器  - 客戶端向服務端發起查詢：遞歸查詢  - 服務端向服務端發起查詢：迭代查詢  2. 瀏覽器向服務器發起TCP連接（三次握手）  - 客戶端：請求包連接，`SYN=1 seq=x`  - 服務端：響應客戶端，`SYN=1 ACK=1 seq=y ack=x+1`  - 客戶端：建立連接，`ACK=1 seq=x+1 ack=y+1`  3. 客戶端發起http請求：  1）請求方法：`GET/POST/HEAD/...`  2）請求的Host主機：從URL中提取  3）請求資源：如`/xxx.html` `/statics/image/xxx.jpg`  4）請求端口：默認`http是80`，`https是443`  5）請求攜帶參數：請求首部信息  6）請求最后空行  4. 服務端響應內容：  1）使用WEB服務軟件  2）響應請求文件類型  3）文件是否壓縮  4）主機是否長連接  5. 客戶端向服務端發起TCP斷開（四次揮手）  - 客戶端：斷開請求，`FIN=1 seq=x`服務端 --> 響應斷開 `FIN=1 ACK=1 ack=x+1 seq=y` --> 客戶端  服務端 --> 斷開連接 `FIN=1 ACK=1 ack=x+1 seq=z` --> 客戶端  客戶端 --> 確認斷開 `FIN=1 ACK=1 ack=z+1 seq=x+1` --> 服務端

3.HTTP的協議頭

HTTP的協議頭分為請求頭和響應頭

HTTP的請求頭（對應客戶端）

HTTP請求頭包含三部分：請求行（構建請求階段）、請求頭、請求體。

在這里插入圖片描述

需要注意的點

Host：指定服務器的域名和端口號（例如：Host.example.com）
User-Agent：描述客戶端應用程序的名稱和版本（例如：User-Agent：Mozilla/5.0）
Accept：指示客戶端可以處理的媒體類型（例如：Accept：text/html）
Content-Type：指示請求主體的數據類型，常見于POST和PUT請求（例如：Content-Type：application/json）
Authorization：包含認證憑據，用于保護的資源訪問（例如：Authorization：Basic）

在這里插入圖片描述

響應頭（對應服務器）
服務器端接收客戶端的請求，將做出處理并返回相應數據，包含響應行，響應頭和響應體

瀏覽器會根據響應數據作出不同的反應，例如不同的Content-Encoding（編碼格式）對應使用不同的解碼方式；Content-type（數據類型）若為文件類型返回服務器文件，若為json返回XHR；狀態碼為200代表請求成功，404表示路徑不存在等。
需要注意：

Content-Type：描述響應內容的媒體類型（例如：Content-Type：text/html）
Content-length：指示響應主體的長度（以字節為單位）
Cach-Control：指定緩存策略（例如：Cache-Control：no-cache）
Set-Cookie：在客戶端存儲一個Cookie，以后可以用于會話管理

4.POST和GET的區別

在這里插入圖片描述

5. HTTP狀態碼

在這里插入圖片描述

6.HTTP的優缺點

在這里插入圖片描述

二、HTTP的版本演進

HTTp協議從1.0發展到3.0，經歷了多次改進。每個版本都有其特定的功能改進和性能優化。

目前主流使用的HTTP版本仍然是HTTP /1.1,但HTTP/2.0正在快速普及，尤其是在性能要求高的環境中，CDN（內容分發網絡）服務商普遍采用HTTP/2來提升性能，而HTTP/3也正在逐步被采用，未來可能會成為新的標準，它已經得到了許多現代瀏覽器（如Chrome、Firefox和Edge）和部分大型互聯網公司的支持（如Google和FaceBook）。

各版本的區別

在這里插入圖片描述

關于SPDY
SPDY是Google開發的基于TCP的會話層協議，用以最小化網絡延遲，提升網絡速度，優化用戶的網絡使用體驗。SPDY并不是一種用于替代HTTP的協議，而是對HTTP協議的增強
新協議的功能包括數據流多路復用、請求優先級以及HTTP報頭壓縮，谷歌表示引入SPDY協議后，在實驗室測試中頁面加載速度比原先快64%。
隨后SPDY協議得到Chrome、Firefox等大型瀏覽器的支持，在一些大型網站和小型網站中部署，這個高效的協議引起了HTTP工作組的注意在，在此基礎上制定了官方HTTP2.0標準，
之后幾年SPDY和http2.0繼續演進互相促進，Htt2.9讓服務器、瀏覽器和網站開發者在新協議中獲得更好的體驗，很快被大眾所認可。
關于HTTP2.0的多路復用
客戶端和服務器將交互數據分解為相互獨立的幀，互不影響地交錯傳輸，最后再對端根據幀頭眾的流標識符把它們重新組裝起來，從而實現了TCP鏈接的多路復用。

在這里插入圖片描述

關于服務端推送
服務器推送是2.0版本新增的一個強大的功能，和一般而對一問一答的C/S交互不同，推送式交互中服務器可以對客戶端的一個請求發送多個響應，除了對最初請求的響應外還向客戶端推送額外的資源，無需客戶端明確地請求也可以推送。
就比如我們去餐廳吃飯，服務好的快的餐廳在我們點好一份牛肉面之后，還會給你送上餐巾紙、筷子、勺子等。這樣主動式的服務，節約了客人的事件并且提高了用餐體驗。
在實際的C/S交互眾，這種主動推送額外資源的方法很有效，因為幾乎滅個網絡應用都會包含多種資源，客戶端需要全部逐個獲取它們，此時如果讓服務器提前推送這些資源，從而可以有效減少額外的延遲時間，因為服務器可以知道客戶端下一步要請求什么資源。

在這里插入圖片描述

1.各個版本的應用場景

HTTP/1.0：簡單的網頁加載場景
假設，你正在訪問一個包含多個圖片的簡單網頁，比如一個文章頁面，其中包含文本、多個圖片和有些樣式表。

HTTP/1.0的處理方式：每個資源（HTML文檔、每張圖片、每個CSS文件）都需要單獨建立一個TCP連接。當你加載這個網頁時，瀏覽器必須為每個資源與服務器進行三次握手和連接，再請求資源，最后關閉連接，假如，你的這個網頁上有1000個資源，那么它就會建立1000個TCP連接，當然每個連接都需要經歷三次握手、四次揮手，整個過程非常費勁

HTTP/1.1：電商網站優化加載假設，你正在瀏覽一個電商網站，頁面包含幾十個商品圖片、JavaScript文件和樣式表

HTTP/1.1的改進：
持久連接：瀏覽器和服務器可以復用同一個TCP連接進行多個請求和響應，這意味著加載整個頁面只需要建立一次TCP連接，極大減少了延遲
分塊傳輸編碼：如果網頁內容是動態生成的，服務器可以逐塊發送數據，而不必等所有內容準備好再發送，這提升了用戶體驗。

HTTP/2：高流量新聞網站場景
假設，你在訪問一個新聞網站，頁面有大量圖片、視頻、廣告和動態加載的內容

HTTP/2的多路復用，所有這些資源都可以通過一個TCP連接同時傳輸。圖片、視頻、廣告等內容不需要排隊等待，而是可以并行加載
頭部壓縮：HTTP/2會壓縮請求和響應頭部，節省帶寬，尤其是在使用CDN加載全球資源時效果顯著
服務器推送：如果你在加載一個新聞頁面時，服務器可以主動推送相關資源（如常用的CSS和JavaScript），即使瀏覽器還沒有請求
整個頁面幾乎同時加載完畢，沒有明顯的等待，頭部壓縮還減少了數據流量，特別有助于移動網絡用戶

4.HTTP/3：實時視頻應用場景
假設，你在使用一個實時視頻會議應用，或者在玩一款實時在線游戲，這些應用都延遲非常敏感，且需要在網絡波動時保持穩定。

HTTP/3的優勢
基于QUIC協議：HTTP/3使用UDP而非TCP傳輸數據，連接建立時間極短，即使網絡有波動或數據包丟失，QUIC也能快速恢復，不會像TCP那樣出現明顯的卡頓
低延遲：HTTP/3能在一個連接上并行傳輸多個數據流，任何一個流的數據包丟失不會影響其他流，確保視頻和音頻流暢。
在網絡不穩定的情況下，視頻和音頻仍然非常清晰，延遲顯著降低。你不會感受到明顯的卡頓，體驗更流暢

2、注意要點

HTTP/1.1的管道化問題

管道化的工作原理
在HTTP/1.1中，管道化允許客戶端在同一個TCP連接上同時發送多個請求，而不必等待第一個請求的響應回來，然而，響應必須按順序返回
例如：如果你發送了三個請求（請求A、B和C），服務器必須按順序處理并發送響應（A的響應必須先到，然后是B，再是C），即使后面的請求可以更早完成
問題
推頭阻塞（Head-of-Line Blocking）：如果第一個請求A的響應很慢，所有后續請求（B和C）的響應都會被阻塞，必須等待A的響應完成才能處理，這大大限制了并行請求的效率
實現復雜性：由于隊頭阻塞和一些不兼容的問題，HTTP/1.1的管道化很少被實際采用，大多數瀏覽器甚至默認禁用這項功能。

多路復用的工作原理

HTTP/2通過再同一個TCP連接上使用二進制分幀技術，將所有數據分成小的幀（frame），并為沒餓過請求和響應分配唯一的流ID，這樣，多個請求和響應可以同時在一個連接上傳輸，且幀可以交錯進行，不需要按順序
例如，如你發送了三個請求（A、B和C），這些請求的幀可以交錯發送，且服務器可以按任意順序發送響應幀，即使一個請求（如A）變慢了，其他請求（B和C）的響應仍然可以及時送達。
優勢：
無對頭阻塞：由于請求和響應可以交錯傳輸，HTTP /2避免了HTTP/1.1中的隊頭阻塞問題，顯著提升了傳輸效率
更高的并行性：所有請求和響應在一個TCP連接上獨立傳輸，即使一個流變慢，也不會影響其他流。

QUIC為什么那么快？為什么拋棄TCP？
QUIC（Quick UDP Internet Connections）是一種基于UDP的新一代傳輸協議，最早由Google開發，后來被HTTP/3采用。QUIC之所以比TCP快，是因為它解決了TCP在現代網絡中存在的一些效率和延遲問題。

QUIC為什么棄用TCP？
TCP自1970年誕生以來，設計上并為考慮現代網絡的復雜性和需求。雖然TCP已經通過各種拓展（如快速重傳、窗口縮放）來優化性能，但它仍然受到一些歷史限制，例如隊頭阻塞和無法靈活調整的擁塞控制
QUIC基于UDP重新設計協議，可以繞過TCP的這些局限性，專注于現代網絡需求
另外，現代互聯網應用（如視頻流、實施游戲和網頁加載）對低延遲和高效率的需求越來越高，QUIC的設計更符合這些應用場景，可以在高延遲或丟包率高的環境中表現更佳。

在這里插入圖片描述

QUIC為什么快？
1. 減少連接建立的延遲
  TCP的連接建立：TCP使用三次握手來建立一個安全的連接，對于HTTPS連接，還需要再進行一次TLS握手，這意味著要經歷多個來回，才能開始傳輸數據，這會導致較高的延遲，尤其是在高延遲的網絡環境中（比如跨國網絡訪問）。
  QUIC的連接建立：QUIC將加密和連接握手合并在一起，通常只需要一個往返（1-RTT）甚至零個往返（0-RTT，基于之前的會話緩存）就可以建立連接，這顯著減少了初次連接時的延遲

在這里插入圖片描述
2. 內置加密（TLS 1.3）
QUIC在設計之初就內置了加密機制，使用了TLS 1.3來加密所有數據。相比之下，TCP需要通過一個單獨的握手過程來啟動TLS加密，QUIC的這種內置設計簡化了加密過程并提高了安全性和連接速度。
3. 解決隊頭阻塞問題
TCP的隊頭阻塞：TCP是一個面向字節流的協議，如果某個數據包丟失，接收者必須等待該數據包被重新傳輸并恢復順序，才能繼續處理后面的數據包。這種重傳機制會阻塞整個流的數據傳輸，增加延遲。
QUIC的多路復用：QUIC使用獨立的流來傳輸數據，即使一個數據包丟失，也只會影響特定的流，不會阻塞其他流的數據傳輸。這種多路復用機制大幅減少了延遲，尤其在丟包率較高的網絡中表現更優。
4. 更高效的丟包處理
TCP的擁塞控制：TCP的擁塞控制機制并不總能高效應對網絡變化，而QUIC可以靈活的應對丟包和網絡擁塞，使用高級的擁塞控制算法來優化傳輸性能
更快的丟包恢復：QUIC可以在傳輸層更快檢測丟包并恢復數據，而不用等待傳輸層和應用層之間的多次交互。

三、HTTP與HTTPS

簡單來說，https=http+ssl/tls，即加密的http
HTTP（HyperText Transfer Protocol Secure）是HTTP協議的安全版本，用于在客戶端（如瀏覽器）和服務器之間安全地傳輸數據。HTTPS通過加密機制來保護用戶和網站之間傳輸的信息，確保數據的機密性和完整性。