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

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

2. 認(rèn)識(shí)URL

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

• urlencode 和 urldecode

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

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

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

3.1 請(qǐng)求

• 請(qǐng)求行

• 請(qǐng)求報(bào)頭Header：請(qǐng)求的屬性，冒號(hào)分割的鍵值對(duì)；每組屬性之間使用\r\n 分隔；

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

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

下面是一個(gè)簡(jiǎn)單的請(qǐng)求：

下面是一個(gè)較為完整的請(qǐng)求報(bào)頭：

3.2 響應(yīng)

Http常見Header:

請(qǐng)求：

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

響應(yīng)：

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

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

核心作用

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

持久連接（長(zhǎng)連接）

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

語法格式

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

3. http的常見方法

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

1. GET方法

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

2. POST方法

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

3. PUT 方法（不常用）

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

4. HEAD 方法

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

5. DELETE 方法（不常用）

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

6. OPTIONS 方法

用途： 用于查詢針對(duì)請(qǐng)求 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 重定向

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

1. 臨時(shí)重定向 302

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

2. 永久重定向 301

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

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

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

5. Cookie與Session

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

5.1 Cookie

5.1.1 認(rèn)識(shí)Cookie

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

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

用途：

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

1. Cookie的工作原理

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

2. Cookie的種類

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

由于 Cookie 是存儲(chǔ)在客戶端的，因此存在被篡改或竊取的風(fēng)險(xiǎn)。

5.1.2 設(shè)置Cookie

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

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

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

Cookie的其它屬性

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

注意事項(xiàng)：

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

5.1.3 Cookie的生命周期

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

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

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

5.2 Session

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

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

用途：

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

1. 工作原理

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

2. 安全性

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

3. 超時(shí)和失效：

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

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

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

6. HTTP版本（了解）

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

1. HTTP/0.9

核心技術(shù)：

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

時(shí)代背景：

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

2. HTTP/1.0

核心技術(shù)：

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

時(shí)代背景：

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

3. HTTP/1.1

核心技術(shù)：

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

時(shí)代背景：

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

4. HTTP/2.0

核心技術(shù)：

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

時(shí)代背景：

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

5. HTTP/3.0

核心技術(shù)：

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

時(shí)代背景：

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