1. 關(guān)于http協(xié)議

• 應(yīng)用層協(xié)議是我們程序員自己定的。
• 實際上已經(jīng)有大佬們定義了一些現(xiàn)成的，又非常好用的應(yīng)用層協(xié)議，供我們直接參考使用， HTTP(超文本傳輸協(xié)議)就是其中之一。
• 在互聯(lián)網(wǎng)世界中， HTTP（HyperText Transfer Protocol，超文本傳輸協(xié)議）是一個至關(guān)重要的協(xié)議。 它定義了客戶端（如瀏覽器）與服務(wù)器之間如何通信，以及交換或傳輸超文本（如 HTML 文檔）
• HTTP 協(xié)議是客戶端與服務(wù)器之間通信的基礎(chǔ)。 客戶端通過 HTTP 協(xié)議向服務(wù)器發(fā)送請求，服務(wù)器收到請求后處理并返回響應(yīng)。
• HTTP 協(xié)議是一個無連接、無狀態(tài)的協(xié)議，即每次請求都需要建立新的連接，且服務(wù)器不會保存客戶端的狀態(tài)信息。

2. 認識URL

平時我們俗稱的 “網(wǎng)址” 其實就是說的 URL

• urlencode 和 urldecode

像 / ? : 等這樣的字符，已經(jīng)被 url 當做特殊意義理解了，因此這些字符不能隨意出現(xiàn)。比如，某個參數(shù)中需要帶有這些特殊字符，就必須先對特殊字符進行轉(zhuǎn)義。
轉(zhuǎn)義的規(guī)則如下：將需要轉(zhuǎn)碼的字符轉(zhuǎn)為 16 進制，然后從右到左， 取 4 位(不足 4 位直接處理)， 每 2 位 做一位，前面加上%，編碼成%XY 格式。

“+” 被轉(zhuǎn)義成了 "%2B。 + 的acsll碼值為43，轉(zhuǎn)換成16進制就是2B

3. http協(xié)議請求與響應(yīng)格式

3.1 請求

• 請求行

• 請求報頭Header：請求的屬性，冒號分割的鍵值對；每組屬性之間使用\r\n 分隔；

• 空行：遇到空行表示 Header 部分結(jié)束

• 請求正文Body：空行后面的內(nèi)容都是 Body。Body 允許為空字符串，如果 Body 存在，則在Header 中會有一個 Content-Length 屬性來標識 Body 的長度；如果服務(wù)器返回了一個 html 頁面，那么 html 頁面內(nèi)容就是在 body 中。

下面是一個簡單的請求：

下面是一個較為完整的請求報頭：

3.2 響應(yīng)

Http常見Header:

請求：

• Content-Type：返回的內(nèi)容的內(nèi)容類型或者編碼類型
• Content-Length：Body 的長度
• Host：客戶端告知服務(wù)器，所請求的資源是在哪個主機的哪個端口上
• User-Agent：聲明用戶的操作系統(tǒng)和瀏覽器版本信息
• Cookie：用于在客戶端存儲少量信息，通常用于實現(xiàn)會話(session)的功能

響應(yīng)：

• Location：搭配 3xx 狀態(tài)碼使用，告訴客戶端接下來要去哪里訪問;
• referer：當前頁面是從哪個頁面跳轉(zhuǎn)過來的
• ETag：對于某個資源的某個特定版本的一個標識符，通常是一個消息散列

關(guān)于 connection 報頭
HTTP 中的 Connection 字段是 HTTP 報文頭的一部分，它主要用于控制和管理客戶端與服務(wù)器之間的連接狀態(tài)

核心作用

• 管理持久連接： Connection 字段還用于管理持久連接（也稱為長連接）。持久連接允許客戶端和服務(wù)器在請求/響應(yīng)完成后不立即關(guān)閉 TCP 連接，以便在同一個連接上發(fā)送多個請求和接收多個響應(yīng)。

持久連接（長連接）

• HTTP/1.1：在 HTTP/1.1 協(xié)議中，默認使用持久連接。當客戶端和服務(wù)器都不明確指定關(guān)閉連接時，連接將保持打開狀態(tài)，以便后續(xù)的請求和響應(yīng)可以復(fù)用同一個連接。
• HTTP/1.0：在 HTTP/1.0 協(xié)議中，默認連接是非持久的。 如果希望在 HTTP/1.0上實現(xiàn)持久連接，需要在請求頭中顯式設(shè)置 Connection: keep-alive。

語法格式

• Connection: keep-alive：表示希望保持連接以復(fù)用 TCP 連接。
• Connection: close：表示請求/響應(yīng)完成后，應(yīng)該關(guān)閉 TCP 連接。

3. http的常見方法

最常用的就是 GET 方法和 POST 方法

1. GET方法

用途：用于請求 URL 指定的資源。
示例：GET /index.html HTTP/1.1
特性：指定資源經(jīng)服務(wù)器端解析后返回響應(yīng)內(nèi)容；若攜帶參數(shù)，參數(shù)會拼接到uri后面

2. POST方法

用途：用于傳輸實體的主體，通常用于提交表單數(shù)據(jù)。
示例：POST /login HTTP/1.1
特性：可以發(fā)送大量的數(shù)據(jù)給服務(wù)器，并且數(shù)據(jù)包含在請求體中。若攜帶參數(shù)，參數(shù)會放到正文中，傳參更加私密。

3. PUT 方法（不常用）

用途：用于傳輸文件，將請求報文主體中的文件保存到請求 URL 指定的位置。
示例：PUT /example.html HTTP/1.1
特性：不太常用，但在某些情況下，如 RESTful API 中，用于更新資源。

4. HEAD 方法

用途：與 GET 方法類似，但不返回報文主體部分，僅返回響應(yīng)頭。
示例：HEAD /index.html HTTP/1.1
特性：用于確認 URL 的有效性及資源更新的日期時間等。

5. DELETE 方法（不常用）

用途：用于刪除文件，是 PUT 的相反方法。
示例：DELETE /example.html HTTP/1.1
特性：按請求 URL 刪除指定的資源。

6. OPTIONS 方法

用途： 用于查詢針對請求 URL 指定的資源支持的方法。
示例： OPTIONS * HTTP/1.1
特性： 返回允許的方法，如 GET、 POST 等。

4. 狀態(tài)碼

4.1 常見狀態(tài)碼

最常見的狀態(tài)碼，比如 200(OK)，404(Not Found)，403(Forbidden)，302(Redirect 重定向)，504(Bad Gateway)

4.2 重定向

下面，我們來重點關(guān)注重定向部分。
HTTP 狀態(tài)碼 301（永久重定向） 和 302（臨時重定向）都依賴 Location 選項。 這個 Location 選項是一個標準的 HTTP 響應(yīng)頭部，用于告訴瀏覽器應(yīng)該將請求重定向到哪個新的 URL 地址。

1. 臨時重定向 302

當服務(wù)器返回 HTTP 302 狀態(tài)碼時， 表示請求的資源臨時被移動到新的位置。
同樣地， 服務(wù)器也會在響應(yīng)中添加一個 Location 頭部來指定資源的新位置。 瀏覽器會暫時使用新的 URL 進行后續(xù)的請求， 但不會緩存這個重定向。

2. 永久重定向 301

當服務(wù)器返回 HTTP 301 狀態(tài)碼時， 表示請求的資源已經(jīng)被永久移動到新的位置。
在這種情況下，服務(wù)器會在響應(yīng)中添加一個 Location 頭部，用于指定資源的新位置。 這個 Location 頭部包含了新的 URL 地址，瀏覽器會自動重定向到該地址，瀏覽器通常會緩存重定向信息。

例如， 在 HTTP 響應(yīng)中， 可能會看到類似于以下的頭部信息：

HTTP/1.1 301 Moved Permanently\r\n
Location: https://www.new-url.com\r\n

5. Cookie與Session

在我們登錄了一個網(wǎng)頁之后，會發(fā)現(xiàn)很長一段時間它都不需要我們再次登錄了?？墒荋TTP是無連接、無狀態(tài)的，它怎么能夠記住我們的呢？

5.1 Cookie

5.1.1 認識Cookie

HTTP Cookie（也稱為 Web Cookie、 瀏覽器 Cookie 或簡稱 Cookie）是服務(wù)器發(fā)送到用戶瀏覽器并保存在瀏覽器上的一小塊數(shù)據(jù)，它會在瀏覽器以后向同一服務(wù)器再次發(fā)起請求時被攜帶并發(fā)送到服務(wù)器上，有大小限制，通常不能超過4KB。

通常，它用于告知服務(wù)端兩個請求是否來自同一瀏覽器，以便保持用戶的登錄狀態(tài)、記錄用戶偏好等

用途：

• 用戶認證和會話管理(最重要)
• 跟蹤用戶行為
• 緩存用戶偏好等

1. Cookie的工作原理

• 當用戶第一次訪問網(wǎng)站時，服務(wù)器會在響應(yīng)的 HTTP 頭中設(shè)置 Set-Cookie字段，用于發(fā)送 Cookie 到用戶的瀏覽器。
• 瀏覽器在接收到 Cookie 后，會將其保存在本地（通常是按照域名進行存儲）。
• 在之后的請求中， 瀏覽器會自動在 HTTP 請求頭中攜帶 Cookie 字段，將之前保存的 Cookie 信息發(fā)送給服務(wù)器

2. Cookie的種類

• 會話 Cookie：在瀏覽器關(guān)閉時失效。（內(nèi)存級）
• 持久 Cookie：帶有明確的過期日期或持續(xù)時間，可以跨多個瀏覽器會話存在。 (文件級)
• 如果 cookie 是一個持久性的 cookie，那么它其實就是瀏覽器相關(guān)的特定目錄下的一個文件。 但直接查看這些文件可能會看到亂碼或無法讀取的內(nèi)容，因為 cookie 文件通常以二進制或 sqlite 格式存儲。 一般我們查看，直接在瀏覽器對應(yīng)的選項中直接查看即可。

由于 Cookie 是存儲在客戶端的，因此存在被篡改或竊取的風險。

5.1.2 設(shè)置Cookie

• HTTP存在一個報頭選項： Set-Cookie，服務(wù)端可以用來進行給瀏覽器設(shè)置 Cookie值。
• 客戶端（如瀏覽器）獲取并自行設(shè)置并保存Cookie，并在 HTTP 響應(yīng)頭中添加

設(shè)置的基本格式：

Set-Cookie: name = value;
其中 name 是 Cookie 的名稱， value 是 Cookie 的值。

Cookie的其它屬性

• expires=date： 設(shè)置 Cookie 的過期日期/時間。 如果未指定此屬性，則 Cookie 默認為會話 Cookie，即當瀏覽器關(guān)閉時過期。
  • 時間格式必須遵守 RFC 1123 標準， 具體格式樣例： Tue, 01 Jan 2030 12:34:56GMT 或者 UTC(推薦)。
• path=some_path： 限制 Cookie 發(fā)送到服務(wù)器的哪些路徑。 請求該路徑上，請求會自動加上Cookie，當路徑為根目錄時，所有的請求都會加上Cookie。
• domain=domain_name（了解即可）：指定哪些主機可以接受該 Cookie。 默認為設(shè)置它的主機。
• secure（了解即可）：僅當使用 HTTPS 協(xié)議時才發(fā)送 Cookie。 這有助于防止Cookie 在不安全的 HTTP 連接中被截獲。
• HttpOnly（了解即可）：標記 Cookie 為 HttpOnly，意味著該 Cookie 不能被客戶端腳本（如 JavaScript）訪問。 這有助于防止跨站腳本攻擊（XSS）。

注意事項：

• 每個 Cookie 屬性都以分號（;） 和空格（ ） 分隔。
• 名稱和值之間使用等號（=） 分隔。
• 如果 Cookie 的名稱或值包含特殊字符（如空格、 分號、 逗號等） ， 則需要進行 URL 編碼。

5.1.3 Cookie的生命周期

• 如果設(shè)置了 expires 屬性， 則 Cookie 將在指定的日期/時間后過期。
• 如果沒有設(shè)置 expires 屬性， 則 Cookie 默認為會話 Cookie， 即當瀏覽器關(guān)閉時過期。

通過合理設(shè)置 Set-Cookie 的格式和屬性， 可以確保 Cookie 的安全性、 有效性和可訪問性， 從而滿足 Web 應(yīng)用程序的需求。
可是單獨使用 Cookie，有什么問題嗎？

• 我們寫入的是測試數(shù)據(jù)， 如果寫入的是用戶的私密數(shù)據(jù)呢？ 比如， 用戶名密碼，瀏覽痕跡等，Cookie在瀏覽器中是明文顯示的，不安全。
• 本質(zhì)問題在于這些用戶私密數(shù)據(jù)在瀏覽器(用戶端)保存，非常容易被人盜取，更重要的是，除了被盜取，還有就是用戶私密數(shù)據(jù)也就泄漏了。

5.2 Session

為了解決Cookie遺留的問題，引入了Session。

HTTP Session 是服務(wù)器用來跟蹤用戶與服務(wù)器交互期間用戶狀態(tài)的機制。 由于 HTTP協(xié)議是無狀態(tài)的（每個請求都是獨立的），因此服務(wù)器需要通過 Session 來記住用戶的信息。

用途：

• 用戶認證和會話管理
• 存儲用戶的臨時數(shù)據(jù)（如購物車內(nèi)容）
• 實現(xiàn)分布式系統(tǒng)的會話共享（通過將會話數(shù)據(jù)存儲在共享數(shù)據(jù)庫或緩存中）

1. 工作原理

• 當用戶首次訪問網(wǎng)站時，服務(wù)器會為用戶創(chuàng)建一個唯一的 Session ID，并通過Cookie 將其發(fā)送到客戶端。
• 客戶端在之后的請求中會攜帶這個 Session ID，服務(wù)器通過 Session ID 來識別用戶，從而獲取用戶的會話信息。
• 服務(wù)器通常會將 Session 信息存儲在內(nèi)存、 數(shù)據(jù)庫或緩存中，Session中包含用戶的基本屬性。

2. 安全性

• 與 Cookie 相似，由于 Session ID 是在客戶端和服務(wù)器之間傳遞的，因此也存在被竊取的風險。
• 但是一般雖然 Cookie 被盜取了，但是用戶只泄漏了一個 Session ID，私密信息暫時沒有被泄露的風險，Session ID 便于服務(wù)端進行客戶端有效性的管理，比如異地登錄。
• 可以通過 HTTPS 和設(shè)置合適的 Cookie 屬性（如 HttpOnly 和 Secure） 來增強安全性。

3. 超時和失效：

• Session 可以設(shè)置超時時間， 當超過這個時間后， Session 會自動失效。
• 服務(wù)器也可以主動使 Session 失效， 例如當用戶登出時。

此時，服務(wù)器已經(jīng)能夠識別瀏覽器了(瀏覽器所攜帶的sessionid、id對應(yīng)的客戶端屬性，在服務(wù)器端的均有存儲)

HTTP Cookie 和 Session 都是用于在 Web 應(yīng)用中跟蹤用戶狀態(tài)的機制。 Cookie 是存儲在客戶端的， 而 Session 是存儲在服務(wù)器端的。 它們各有優(yōu)缺點， 通常在實際應(yīng)用中會結(jié)合使用， 以達到最佳的用戶體驗和安全性。

6. HTTP版本（了解）

HTTP（Hypertext Transfer Protocol， 超文本傳輸協(xié)議） 作為互聯(lián)網(wǎng)中瀏覽器和服務(wù)器間通信的基石， 經(jīng)歷了從簡單到復(fù)雜、 從單一到多樣的發(fā)展過程。 以下將按照時間順序， 介紹 HTTP 的主要版本、 核心技術(shù)及其對應(yīng)的時代背景。

1. HTTP/0.9

核心技術(shù)：

• 僅支持 GET 請求方法。
• 僅支持純文本傳輸， 主要是 HTML 格式。
• 無請求和響應(yīng)頭信息。

時代背景：

• 1991 年， HTTP/0.9 版本作為 HTTP 協(xié)議的最初版本， 用于傳輸基本的超文本HTML 內(nèi)容。
• 當時的互聯(lián)網(wǎng)還處于起步階段，網(wǎng)頁內(nèi)容相對簡單，主要以文本為主。

2. HTTP/1.0

核心技術(shù)：

• 引入 POST 和 HEAD 請求方法。
• 請求和響應(yīng)頭信息，支持多種數(shù)據(jù)格式（MIME）。
• 支持緩存（cache）。
• 狀態(tài)碼（status code）、多字符集支持等。

時代背景：

• 1996 年， 隨著互聯(lián)網(wǎng)的快速發(fā)展， 網(wǎng)頁內(nèi)容逐漸豐富， HTTP/1.0 版本應(yīng)運而生。
• 了滿足日益增長的網(wǎng)絡(luò)應(yīng)用需求， HTTP/1.0 增加了更多的功能和靈活性。
• 然而， HTTP/1.0 的工作方式是每次 TCP 連接只能發(fā)送一個請求， 性能上存在一定局限。

3. HTTP/1.1

核心技術(shù)：

• 引入持久連接 connection，支持管道化 。
• 引入options，put，delete，trace，
• 支持 Host 頭， 允許在一個 IP 地址上部署多個 Web 站點。
• 允許在單個 TCP 連接上進行多個請求和響應(yīng)， 提高了性能。
• 引入分塊傳輸編碼 。

時代背景：

• 1999 年， 隨著網(wǎng)頁加載的外部資源越來越多， HTTP/1.0 的性能問題愈發(fā)突出。
• HTTP/1.1 通過引入持久連接和管道化等技術(shù)， 有效提高了數(shù)據(jù)傳輸效率。
• 同時， 互聯(lián)網(wǎng)應(yīng)用開始呈現(xiàn)出多元化、 復(fù)雜化的趨勢， HTTP/1.1 的出現(xiàn)滿足了這些需求。

4. HTTP/2.0

核心技術(shù)：

• 多路復(fù)用，一個 TCP 連接允許多個 HTTP 請求。
• 二進制幀格式 ，優(yōu)化數(shù)據(jù)傳輸。
• 頭部壓縮 ，減少傳輸開銷。
• 服務(wù)器推送，提前發(fā)送資源到客戶端。

時代背景：

• 2015 年， 隨著移動互聯(lián)網(wǎng)的興起和云計算技術(shù)的發(fā)展， 網(wǎng)絡(luò)應(yīng)用對性能的要求越來越高。
• HTTP/2.0 通過多路復(fù)用、 二進制幀格式等技術(shù)， 顯著提高了數(shù)據(jù)傳輸效率和網(wǎng)絡(luò)性能。
• 同時， HTTP/2.0 還支持加密傳輸（HTTPS），提高了數(shù)據(jù)傳輸?shù)陌踩浴?/li>

5. HTTP/3.0

核心技術(shù)：

• 使用 QUIC 協(xié)議替代 TCP 協(xié)議， 基于 UDP 構(gòu)建的多路復(fù)用傳輸協(xié)議。
• 減少了 TCP 三次握手及 TLS 握手時間， 提高了連接建立速度。
• 解決了 TCP 中的線頭阻塞問題， 提高了數(shù)據(jù)傳輸效率。

時代背景：

• 2022 年， 隨著 5G、 物聯(lián)網(wǎng)等技術(shù)的快速發(fā)展， 網(wǎng)絡(luò)應(yīng)用對實時性、 可靠性的要求越來越高。
• HTTP/3.0 通過使用 QUIC 協(xié)議， 提高了連接建立速度和數(shù)據(jù)傳輸效率， 滿足了這些需求。
• 同時， HTTP/3.0 還支持加密傳輸（HTTPS），保證了數(shù)據(jù)傳輸?shù)陌踩浴?/li>