1.?HTTP的概述

????????HTTP（超文本傳輸協(xié)議），定義在RFC2616中，是用于分布式和協(xié)作式多媒體系統(tǒng)之間交互的應(yīng)用層通信協(xié)議。

1.1 無狀態(tài)

????????HTTP是一個無狀態(tài)協(xié)議，意味著它不保存先前交互的記錄。每個請求都獨立于其他請求處理。

1.2?分布式和協(xié)作式多媒體系統(tǒng)間的交互

????????HTTP旨在促進(jìn)客戶端和服務(wù)器在分布式系統(tǒng)中的互動，包括傳輸多媒體數(shù)據(jù)和在線協(xié)作。

1.3?HTTP的客戶端/服務(wù)器模型

????????客戶端（通常是網(wǎng)絡(luò)瀏覽器）向服務(wù)器（托管網(wǎng)站或應(yīng)用程序的服務(wù)器）發(fā)送請求。然后服務(wù)器處理這個請求，并向客戶端發(fā)送回應(yīng)。

1.4 請求-響應(yīng)連接

????????客戶端和服務(wù)器之間建立連接，以傳輸請求和響應(yīng)。這可能是持久連接（為多個請求-響應(yīng)保持開放）或非持久連接（每對請求-響應(yīng)新建連接）。

1.5 HTTP消息：HTTP通信以消息的形式進(jìn)行

????????主要有兩種類型的HTTP消息：請求和響應(yīng)。

????????請求通常由客戶端發(fā)出，用于請求服務(wù)器上的特定資源，而響應(yīng)則由服務(wù)器返回，以提供所請求的資源。

1.6 可靠的傳輸或會話協(xié)議

????????HTTP依賴于可靠的傳輸協(xié)議，如TCP（傳輸控制協(xié)議），以確保傳輸?shù)臄?shù)據(jù)可靠。TCP確保數(shù)據(jù)按正確的順序到達(dá)目的地，并且沒有損壞。

1.7 GET請求

????????大多數(shù)HTTP通信涉及到GET請求。GET請求用于請求服務(wù)器上特定資源的表示。例如，當(dāng)您在瀏覽器中輸入URL時，通常會向Web服務(wù)器發(fā)送一個GET請求，以獲取相應(yīng)的網(wǎng)頁。

1.8 雙向連接

????????HTTP基于客戶端-服務(wù)器通信模型，其中客戶端發(fā)送請求到服務(wù)器，服務(wù)器則以響應(yīng)方式回應(yīng)。客戶端和服務(wù)器之間的連接通常在通信期間保持打開，這允許雙向交互，例如實時數(shù)據(jù)流傳輸。

????????HTTP/1.1和之前的版本通常為每個請求/響應(yīng)使用單獨的TCP連接，這可能在某些情況下會導(dǎo)致延遲過高。

????????HTTP/2和HTTP/3引入了改進(jìn)，通過使用單個雙向連接來處理多個請求和響應(yīng)，以優(yōu)化性能。

????????總之，HTTP是Web的重要協(xié)議，允許Web瀏覽器可靠地向Web服務(wù)器請求資源，并提供保持雙向連接以進(jìn)行持續(xù)交互的能力。

2.?HTTP協(xié)議的中介

????????客戶端、服務(wù)器和中介都可能具有緩存能力。圖中展示了這些實體之間請求和響應(yīng)的流程。

2.1 HTTP中介

????????在HTTP通信中，“中介”（Intermédiaire）可以理解為在客戶端和服務(wù)器之間傳遞信息的任何實體

????????建立了一個連接鏈。

????????HTTP的選項可以應(yīng)用到最接近的中介上（隧道除外）。

????????最終接收者。

????????所有的中介。

????????網(wǎng)絡(luò)中的一個中介（比如代理、網(wǎng)關(guān)或隧道）可以介于客戶端和服務(wù)器之間。

2.2 代理（Proxy）

????????它像是一個中轉(zhuǎn)站，客戶端發(fā)送的請求會先到達(dá)代理，代理有可能會修改這個請求，然后再發(fā)送給真正的服務(wù)器。

2.3 網(wǎng)關(guān)（Passerelle）

????????如果客戶端和服務(wù)器之間的通信協(xié)議不同，網(wǎng)關(guān)會將客戶端的請求翻譯成服務(wù)器能理解的協(xié)議。

2.4 隧道（Tunnel）????????

????????隧道更像是一個直通管道，它不會修改經(jīng)過的信息。當(dāng)需要通過某些特殊的中介（比如防火墻）時，就會用到隧道。

2.5 緩存

????????客戶端、服務(wù)器和中介可能都設(shè)有緩存，以提高數(shù)據(jù)傳輸效率和減少延遲。

2.6 數(shù)據(jù)流

????????客戶端發(fā)送請求到服務(wù)器，以及服務(wù)器響應(yīng)返回給客戶端的過程，中間可能通過一個中介來完成數(shù)據(jù)傳輸。

????????簡單來說，這些描述指出在HTTP協(xié)議中，信息可以通過一個或多個中介（如代理服務(wù)器、網(wǎng)關(guān)等）來傳遞。每個中介都可以根據(jù)HTTP協(xié)議的選項進(jìn)行操作，但是隧道類型的中介是個例外，它通常只是簡單地傳遞信息而不做修改。最終，信息會到達(dá)最終的接收者，也就是目標(biāo)服務(wù)器。在這個過程中，每個中介都可能會對信息流產(chǎn)生影響。

3. HTTP協(xié)議中的兩種鏈接

3.1 非持久連接

????????對于每個請求的URI（統(tǒng)一資源標(biāo)識符），都會建立一個單獨的連接。這種方式可能會導(dǎo)致服務(wù)器負(fù)載過重，互聯(lián)網(wǎng)擁堵。在HTTP1.1之前的版本中，默認(rèn)的連接是非持久的，有時候甚至不支持持久連接。

3.2?持久連接

????????通過一次連接，可以發(fā)送多個請求并接收多個響應(yīng)，不需要每次都重新建立連接。這減少了開啟和關(guān)閉連接的頻繁操作，提高了效率。

3.2.1 管道化（Pipeline）

????????在HTTP1.1中，客戶端可以同時發(fā)送多個請求，而不用等待對前一個請求的響應(yīng)。服務(wù)器按照請求接收的順序發(fā)送回響應(yīng)。這進(jìn)一步提高了傳輸效率。

3.2.2 持久性

????????如果服務(wù)器關(guān)閉了連接，客戶端應(yīng)該準(zhǔn)備好重新發(fā)起請求。這意味著客戶端在連接被關(guān)閉時能夠恢復(fù)通信，而不會丟失請求。

????????簡而言之，HTTP的持久連接和管道化技術(shù)都是為了讓網(wǎng)頁加載更快、更高效，減少因頻繁建立連接造成的延遲和資源消耗。

4. HTTP消息結(jié)構(gòu)——HTTP消息的基本組成部分

????????兩種類型的消息：請求（requête）和響應(yīng)（réponse）

????????消息結(jié)構(gòu)：一個消息包含四個部分

4.1?起始行（start-line）

4.1.1 基本概念

????????HTTP消息的第一行非常重要，因為它定義了消息是一個請求還是一個響應(yīng)：

????????對于請求來說，包括了方法（GET、POST等）、請求的URI和HTTP版本。

????????對于響應(yīng)來說，包括了HTTP版本、狀態(tài)碼和狀態(tài)消息。

4.1.2 具體解釋

????????起始行（start-line）：這一行指定了消息的類型。它可以是請求行（Request-Line）或狀態(tài)行（Status-Line）。

????????如果是請求行，它會包含三個部分：

4.1.2.1 方法（Method）????????

????????這指的是HTTP請求的類型，例如GET（獲取數(shù)據(jù)）、POST（發(fā)送數(shù)據(jù)）等。

????????HTTP協(xié)議中不同方法的說明：

????????GET：用于請求訪問由URI（統(tǒng)一資源標(biāo)識符）所標(biāo)識的資源。

????????HEAD：類似于GET方法，但是服務(wù)器在響應(yīng)中只返回頭部信息，不返回實際的資源內(nèi)容。

????????POST：用于向指定的資源提交數(shù)據(jù)，例如，提交表單或上傳文件。數(shù)據(jù)包含在請求體中。

????????PUT：用于上傳指定的資源。如果URI指向的資源不存在，服務(wù)器可以創(chuàng)建這個資源。

????????DELETE：請求服務(wù)器刪除指定的URI所標(biāo)識的資源。

????????TRACE：回顯服務(wù)器收到的請求，主要用于測試或診斷。

????????CONNECT：將連接轉(zhuǎn)換為透明的TCP/IP隧道，通常用于SSL加密服務(wù)器的連接（通過HTTP代理）。

????????OPTIONS：用于描述通信選項的測試方法，用于了解服務(wù)器或其他網(wǎng)絡(luò)組件的能力。

????????這些方法定義了客戶端與服務(wù)器之間交互的不同方式，使得HTTP協(xié)議能夠支持多種不同的網(wǎng)絡(luò)操作。

4.1.2.2?請求目標(biāo)（request-target）

????????通常是你要請求的網(wǎng)址，即統(tǒng)一資源標(biāo)識符（URI）。

4.1.2.3?協(xié)議版本（HTTP-Version）

????????表明使用的HTTP協(xié)議的版本，如HTTP/1.1。

????????每部分之間通常用空格分開，并且以CRLF（回車換行）符號結(jié)束這一行。所以，如果是一個請求，起始行會告訴服務(wù)器你想要做什么（方法），你想在哪里做（請求目標(biāo)），以及你打算使用哪個版本的HTTP協(xié)議來通信。

4.2.頭部（message-header）

4.2.1 基本定義

????????跟隨起始行，包含了鍵值對形式的元數(shù)據(jù)，如內(nèi)容類型、內(nèi)容長度、緩存控制等。

????????HTTP頭部：它由一個名字和一個值組成，這些都是用ASCII碼編碼的。

????????一個消息頭的格式是這樣的：field-name: field-value

????????舉例來說，Content-Type: text/html就是一個消息頭，其中Content-Type是字段名，text/html是字段值。

4.2.2 頭部類型

????????HTTP頭部可以是通用頭部，也可以是請求或響應(yīng)特有的頭部，或者是與消息體中所含實體相關(guān)的頭部。

4.2.2.1 通用頭部（General header）

????????是指那些請求和響應(yīng)消息都可能使用的頭部，比如`Date`或者`Cache-Control`

????????通用頭部：這些頭部與整個消息有關(guān)，而不是僅與消息的內(nèi)容（即消息體）有關(guān)。

????????用途：通用頭部用于控制消息的處理過程，這個處理過程可能涉及客戶端、服務(wù)器或中間件。它們也可以提供一些額外的信息。

????????特性：通用頭部不特定于任何一個請求、響應(yīng)或消息體中的實體。

????????通用頭部的例子包括：

????????Cache-Control：指示緩存行為。

????????Connection：指示是否持久連接。連接選項，不會通過代理傳遞。例如：`Connection: close`，表示關(guān)閉連接，不使用持久連接。

????????Date：消息創(chuàng)建的日期和時間。消息生成的日期。示例為`Date: Tue, 15 Nov 1994 08:12:31 GMT`，表示消息是在1994年11月15日格林尼治時間上午8點12分31秒生成的。

????????Transfer-Encoding：傳輸消息體時使用的編碼類型。

????????no-cache：指示緩存必須向服務(wù)器驗證響應(yīng)的有效性。

????????no-store：指示請求或響應(yīng)不能被緩存。

????????這些頭部用于控制HTTP消息如何被發(fā)送、接收和處理，它們對于管理網(wǎng)絡(luò)連接和緩存行為非常重要。????????

4.2.2.2 請求頭部（Request header）

????????是指那些只在請求消息中使用的頭部，比如User-Agent或Accept。

????????請求頭部的一些例子：

????????Accept：客戶端能夠接收的媒體類型。示例`Accept: audio/*; q=0.2, audio/basic`表示客戶端優(yōu)先接收基本的音頻類型，但也可以接受其他類型的音頻內(nèi)容，盡管它們的優(yōu)先級較低（q=0.2）。

????????Accept-Charset：客戶端支持的字符集。示例`Accept-Charset: iso-8859-5, unicode-1-1;q=0.8`表示客戶端優(yōu)先接受ISO-8859-5編碼的字符集，但也可以接受Unicode-1-1，盡管其優(yōu)先級稍低（q=0.8）。

????????Accept-Encoding：客戶端支持的內(nèi)容編碼。示例`Accept-Encoding: 表示客戶端接受任何類型的內(nèi)容編碼。

????????Accept-Language：客戶端優(yōu)先接受的語言。示例`Accept-Language: en-gb;q=0.8, en;q=0.7`表示客戶端優(yōu)先接受英國英語，其次是其他類型的英語。

????????Accept-Ranges：服務(wù)器可以接受的部分請求的單位。示例`Accept-Ranges: bytes`表示服務(wù)器可以處理以字節(jié)為單位的部分請求。

????????Allow：服務(wù)器支持的HTTP方法。示例`Allow: GET, HEAD, PUT`表示服務(wù)器支持GET、HEAD和PUT這三種請求方法。

????????If-Modified-Since：告訴服務(wù)器如果請求的資源自指定的日期之后被修改過，就發(fā)送資源。示例`If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT`表示如果自1994年10月29日19點43分31秒GMT之后資源有變更，就發(fā)送該資源；否則，返回304狀態(tài)碼，表示資源未修改。

????????這些請求頭部使得HTTP請求可以更精確地告訴服務(wù)器客戶端的具體需求和支持的特性，以便服務(wù)器可以發(fā)送符合客戶端要求的響應(yīng)。

4.2.2.3 響應(yīng)頭部（Response header）

????????是指只在響應(yīng)消息中使用的頭部，比如Server或WWW-Authenticate。

????????HTTP響應(yīng)頭部的一些例子：

????????Accept-Ranges：定義服務(wù)器是否接受范圍請求，以及定義的范圍類型。示例`Accept-Ranges: none`表明服務(wù)器不支持范圍請求。

????????Age：表示自從響應(yīng)產(chǎn)生以來經(jīng)過的時間（以秒為單位）。示例`Age: 3000`表明該響應(yīng)已經(jīng)產(chǎn)生了3000秒。

????????Location：用于重定向到一個新的URI。示例`Location: http://www.cnam.fr`表示客戶端應(yīng)跳轉(zhuǎn)到提供的URI。

????????Etag：響應(yīng)內(nèi)容的唯一標(biāo)識（實體標(biāo)簽）。它可以用來檢查資源是否有變化。示例`ETag: "nom"`提供了一個值，客戶端可以在后續(xù)的請求中使用這個值來檢查資源是否被修改。

????????這些響應(yīng)頭部幫助客戶端理解服務(wù)器的響應(yīng)并適當(dāng)?shù)靥幚硭鼈?，例如判斷?nèi)容是否最新、是否需要重定向到新的地址，或者驗證緩存的內(nèi)容是否仍然是最新的。

4.2.2.4?實體頭部（Entity header）

????????是指那些和消息體的內(nèi)容相關(guān)的頭部，比如`Content-Length`或`Content-Type`。

????????當(dāng)然，這里有一個HTTP請求的頭部示例：

????????假設(shè)您的瀏覽器向`www.example.com`的服務(wù)器發(fā)送一個請求來獲取首頁的HTML文檔，HTTP請求可能包含以下頭部：

????????GET /index.html HTTP/1.1是請求行，指明使用GET方法獲取`/index.html`這個資源，使用的是HTTP 1.1版本。

????????Host: www.example.com?是一個請求頭部，指定請求的服務(wù)器地址。

????????User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.3是一個請求頭部，描述了發(fā)出請求的瀏覽器的類型和版本。

????????Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 是一個請求頭部，告訴服務(wù)器客戶端能夠處理的內(nèi)容類型。

????????Accept-Language: en-US,en;q=0.5是一個請求頭部，說明客戶端優(yōu)先接受的語言。

????????Accept-Encoding: gzip, deflate 是一個請求頭部，說明客戶端可以接受的內(nèi)容編碼類型，比如gzip壓縮。

????????Connection: keep-alive：是一個請求頭部，要求服務(wù)器保持連接打開，以便后續(xù)請求復(fù)用通過這些頭部，HTTP消息可以攜帶關(guān)于請求或響應(yīng)的附加信息，以及關(guān)于實體本身的數(shù)據(jù)。

4.3?空行（CRLF，即Carriage Return Line Feed）

????????標(biāo)記頭部結(jié)束和消息體開始的地方。

4.4?消息體（message-body）

????????可選部分，包含了發(fā)送的數(shù)據(jù)，比如網(wǎng)頁的HTML代碼或API調(diào)用的JSON數(shù)據(jù)。

????????消息體編碼：HTTP消息的主體部分在傳輸時會進(jìn)行編碼，這種編碼方式會在HTTP頭部中指定。消息體可以包含任意的數(shù)據(jù)字節(jié)（在文本中表示為`OCTET`）。

????????實體（entité）：傳輸在消息體中的資源被稱為實體。實體可以是文檔、圖片或其他任何類型的數(shù)據(jù)。

????????簡而言之，HTTP消息體是HTTP消息結(jié)構(gòu)的一個組成部分，它承載了客戶端請求或服務(wù)器響應(yīng)中的實際內(nèi)容。比如，當(dāng)你請求一個網(wǎng)頁時，該網(wǎng)頁的HTML內(nèi)容就會作為響應(yīng)的消息體發(fā)送給你。消息體的具體內(nèi)容和格式由HTTP頭部中的`Content-Type`和`Content-Encoding`等字段指定。

4.5 理解

????????HTTP消息就像是互聯(lián)網(wǎng)上的信封，里面裝著網(wǎng)頁或應(yīng)用程序發(fā)送和接收的信息。這個“信封”有固定的格式，分為幾個部分：

????????起始行：就像信封的標(biāo)題，告訴我們這是什么類型的信息。如果是請求，會包含你想要做的事情（比如查看網(wǎng)頁），如果是響應(yīng)，會告訴你請求結(jié)果如何（比如請求成功或失?。?。

????????頭部：提供額外信息，比如內(nèi)容有多長，需要用什么方式查看等。

????????空行：頭部結(jié)束的標(biāo)志，就像寫信時在正文前空一行一樣。

????????消息體：這是可選的，如果你發(fā)送的是網(wǎng)頁內(nèi)容或者是其他數(shù)據(jù)，就會用到這一部分。

????????總的來說，HTTP消息就是互聯(lián)網(wǎng)上發(fā)送和接收數(shù)據(jù)的方式，它有固定的格式，確保數(shù)據(jù)能夠正確地發(fā)送和接收。

????????通常，一個HTTP消息從起始行開始，然后是多個頭部，一個空行，最后是消息體（如果有的話）。這種結(jié)構(gòu)使得HTTP消息既可以攜帶請求的詳細(xì)信息，也可以攜帶服務(wù)器的響應(yīng)數(shù)據(jù)。

5. HTTP協(xié)議和統(tǒng)一資源標(biāo)識符（URI）的使用

5.1 目標(biāo)資源

????????在HTTP請求中，客戶端指定想要交互的目標(biāo)資源，這個資源通過URI來識別。

5.1.1 絕對形式

????????客戶端在請求行中使用完整的URI來指定資源。例如：

?GET http://www.ietf.org/rfc/rfc2616.txt HTTP/1.1

????????這里GET是請求方法，http://www.ietf.org/rfc/rfc2616.txt是資源的絕對URI，HTTP/1.1是HTTP協(xié)議的版本。

5.1.2 相對形式

????????客戶端可以在請求行中使用相對URI，并在請求頭部使用`Host`字段來指定主機名。例如：

GET /rfc/rfc2616.txt HTTP/1.1

Host: www.ietf.org

????????在這種情況下，請求行只包含資源的相對路徑（`/rfc/rfc2616.txt`），而`Host`頭部指定了完整的主機名（`www.ietf.org`）。

????????絕對形式的URI在請求中提供了資源的完整地址，而相對形式則需要結(jié)合`Host`頭部字段來確定資源的完整位置。這兩種形式都是HTTP/1.1標(biāo)準(zhǔn)中支持的。

5.2 HTTP請求和響應(yīng)的格式

5.2.1 請求

5.2.1.1 格式

????????由請求行（Request-Line）開始，這是HTTP請求的第一行，包含了方法、請求的資源URI和HTTP版本。

????????緊接著是零個或多個頭部字段（header-field），每個字段都以回車換行符（CRLF）結(jié)束。

????????頭部字段和消息體之間有一個空的回車換行符（CRLF）作為分隔。

????????可選的消息體（message-body），用于包含如POST請求的數(shù)據(jù)。

5.2.1.2 示例

GET /path/file.html HTTP/1.0

From: someuser@jmarshall.com

User-Agent: HTTPTool/1.0

[blank line here]

????????請求行：使用GET方法請求/path/file.html這個資源，HTTP版本為1.0。

????????From頭部：發(fā)起請求的用戶的電子郵件地址是someuser@jmarshall.com。

????????User-Agent頭部：發(fā)起請求的客戶端程序是HTTPTool/1.0。

????????請求頭部與消息體之間有一個空白行，表示消息頭部結(jié)束，如果有消息體的話會在這個空白行后面開始

5.2.2 響應(yīng)

5.2.2.1 格式

????????由狀態(tài)行（Status-Line）開始，這是HTTP響應(yīng)的第一行，包含了HTTP版本、狀態(tài)碼和狀態(tài)描述。

????????同樣地，緊接著是零個或多個頭部字段（header-field），每個字段都以回車換行符（CRLF）結(jié)束。

????????頭部字段和消息體之間有一個空的回車換行符（CRLF）作為分隔。

????????可選的消息體（message-body），用于包含如返回的網(wǎng)頁內(nèi)容或API調(diào)用的JSON數(shù)據(jù)。

5.2.2.2?示例

HTTP/1.0 200 OK

Date: Fri, 31 Dec 1999 23:59:59 GMT

Content-Type: text/html

Content-Length: 1354

<html> <body> ...</body> </html>

????????狀態(tài)行：HTTP版本為1.0，狀態(tài)碼為200，表示請求成功。

????????Date頭部：響應(yīng)生成的日期和時間是1999年12月31日23時59分59秒 GMT。

????????Content-Type頭部：響應(yīng)的內(nèi)容類型是text/html，表示是一個HTML文檔。

????????Content-Length頭部：響應(yīng)的內(nèi)容長度是1354字節(jié)。

????????消息體：包含HTML文檔的實際內(nèi)容，從<html>開始，到</html>結(jié)束。

????????這個格式允許HTTP消息在網(wǎng)絡(luò)上清晰地傳輸請求和響應(yīng)信息，確保接收方可以正確解析消息的各個部分。

5.2.2.2.1 HTTP版本（HTTP-Version）

????????指明了響應(yīng)遵循的HTTP協(xié)議版本，例如HTTP/1.1或HTTP/2.0。

5.2.2.2.2 狀態(tài)碼（Status-Code）

????????是一個三位整數(shù)，用于表示請求的處理結(jié)果。例如，200表示請求成功，404表示沒有找到請求的資源。

HTTP響應(yīng)狀態(tài)碼的分類：

????????1xx（信息響應(yīng)）：表示接收到請求并且繼續(xù)處理中。

????????2xx（成功）：表示請求已被成功接收、理解并接受。

????????3xx（重定向）：表示需要進(jìn)一步的操作以完成請求，通常用來進(jìn)行URL的重定向。

????????4xx（客戶端錯誤）：表示請求包含語法錯誤或無法完成請求。

????????5xx（服務(wù)器錯誤）：表示服務(wù)器在嘗試處理請求時發(fā)生了錯誤。

????????每個數(shù)字范圍代表一個響應(yīng)類型，其中首位數(shù)字定義了響應(yīng)的類別，其后兩位數(shù)字無分類作用，但指定了具體的響應(yīng)條件或錯誤。這個系統(tǒng)允許客戶端理解它們的請求是否成功，并在出錯時了解問題所在。

????????100 Continue：繼續(xù)?？蛻舳藨?yīng)繼續(xù)其請求。

????????101 Switching Protocols：切換協(xié)議。服務(wù)器根據(jù)客戶端的請求切換協(xié)議。

????????200 OK：請求成功。一般用于GET與POST請求。

????????201 Created：已創(chuàng)建。成功請求并創(chuàng)建了新的資源。

????????202 Accepted：已接受。已經(jīng)接受請求，但未處理完成。

????????203 Non-Authoritative Information：非權(quán)威信息。請求成功，但返回的信息可能來自第三方。

????????204 No Content：無內(nèi)容。服務(wù)器成功處理，但未返回內(nèi)容。

????????301 Moved Permanently：永久移動。請求的資源已永久移動到新位置。

????????307 Temporary Redirect：臨時重定向。請求的資源臨時從其他地址響應(yīng)。

????????400 Bad Request：錯誤請求。服務(wù)器無法理解請求的格式。

????????500 Internal Server Error：內(nèi)部服務(wù)器錯誤。服務(wù)器遇到錯誤，無法完成請求。

????????這些狀態(tài)碼是客戶端與服務(wù)器通信時，用于表示請求處理情況和結(jié)果的重要信息

????????原因短語（Reason-Phrase）：是一個對狀態(tài)碼的簡短文字描述，例如"OK"表示成功，"Not Found"表示資源未找到。

????????回車換行符（CRLF）：狀態(tài)行的結(jié)束標(biāo)志，確保與后續(xù)頭部的分隔。

????????例如，一個典型的狀態(tài)行可能是：

`????????HTTP/1.1 200 OK，其中`HTTP/1.1`是協(xié)議版本，`200`是狀態(tài)碼，`OK`是原因短語，表示請求已經(jīng)成功處理。

6. HTTP協(xié)議的總結(jié)

????????請求-響應(yīng)簡單協(xié)議：HTTP是一個基于TCP（傳輸控制協(xié)議）的簡單請求-響應(yīng)類型的協(xié)議，它是無狀態(tài)的，意味著服務(wù)器不會保持與客戶端之間的交互狀態(tài)。

????????Cookies：Cookies是一種在客戶端存儲狀態(tài)信息的簡單方式，用于跨越多個請求維持交互狀態(tài)。

????????信息傳輸載體：HTTP可以用來傳輸任何類型的信息。

????????認(rèn)證機制：HTTP支持基本的認(rèn)證方案，如用戶名和密碼登錄，也支持更安全的摘要認(rèn)證和加密，比如使用SSL（安全套接層）。

????????代理作為中間人：在HTTP通信中，代理服務(wù)器（Proxy）充當(dāng)客戶端和服務(wù)器之間的中間人，可以處理和轉(zhuǎn)發(fā)請求和響應(yīng)。

????????規(guī)范參考：HTTP協(xié)議的規(guī)范由W3C（萬維網(wǎng)聯(lián)盟）維護(hù)，參考地址是：[http://www.w3.org/Protocols/Specs.html](http://www.w3.org/Protocols/Specs.html)。

????????這段總結(jié)指出了HTTP協(xié)議的基本特征和一些關(guān)鍵的技術(shù)點，以及它如何適用于Web通信和數(shù)據(jù)傳輸。文章來源地址http://www.zghlxwxcb.cn/news/detail-813268.html

到了這里，關(guān)于計算機網(wǎng)絡(luò)——HTTP協(xié)議的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！