什么是HTTP協(xié)議

這篇文章主要講解了“什么是HTTP協(xié)議”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“什么是HTTP協(xié)議”吧！

目錄

• 一、前言

• 二、HTTP 的誕生

• 三、什么是 HTTP

• 四、駐足不前的 HTTP

• 五、區(qū)分 URL 和 URI

• 六、HTTP 請(qǐng)求和響應(yīng)

• 七、HTTP 連接管理

• 八、無狀態(tài)的 HTTP

• 九、HTTP 斷點(diǎn)續(xù)傳

• 十、HTTP 的缺點(diǎn)

一、前言

你知道當(dāng)我們?cè)诰W(wǎng)頁瀏覽器的地址欄中輸入 URL 時(shí)，Web 頁面是如何呈現(xiàn)的嗎？

Web 界面當(dāng)然不會(huì)憑空出來，根據(jù) Web 瀏覽器地址欄中指定的 URL，Web 使用一種名為 HTTP 的協(xié)議作為規(guī)范，完成從客戶端到服務(wù)端的一些流程。可以說，Web 是建立在 HTTP 協(xié)議上進(jìn)行通信的。

二、HTTP 的誕生

其實(shí)，在 1983 年 3 月之前，互聯(lián)網(wǎng)還只屬于少數(shù)人，全世界的網(wǎng)民之間的信息是無法共享的。在這一互聯(lián)網(wǎng)的黎明時(shí)期，HTTP 應(yīng)運(yùn)而生。

歐洲核子研究組織的 Tim Berners-Lee 博士提出了一種能夠讓遠(yuǎn)隔兩地的網(wǎng)民共享知識(shí)的設(shè)想，最初的理念是：借助多文檔之間相互關(guān)聯(lián)的超文本（HyperTest），連成可相互參閱的 WWW（World Wide Web，萬維網(wǎng)）。

現(xiàn)在已提出了 3 項(xiàng) WWW 構(gòu)建技術(shù)，分別是：

• 把 SGML（標(biāo)準(zhǔn)通用標(biāo)記語言）作為頁面的文本標(biāo)記語言 HTML

• 作為文檔傳遞協(xié)議的 HTTP

• 指定文檔所在地址的 URL

WWW 這一名稱，是 Web 瀏覽器當(dāng)年用來瀏覽超文本的客戶端應(yīng)用程序的名稱，現(xiàn)在用來表示這一系列的集合，也可簡稱為 Web。

三、什么是 HTTP

說了這么多，大家只知道 HTTP 很牛逼，對(duì) HTTP 是什么仍然沒有很直觀的概念。別急，在了解什么是 HTTP 之前，我們有必要知道超文本是什么。

HTTP 傳輸?shù)膬?nèi)容就是超文本：

• 我們先來理解「文本」：在互聯(lián)網(wǎng)早期的時(shí)候只是簡單的字符文字，但隨著技術(shù)的發(fā)展，現(xiàn)在「文本」的涵義已經(jīng)可以擴(kuò)展為圖片、視頻、壓縮包等，在 HTTP 眼里這些都算做「文本」。

• 再來理解「超文本」：它就是超越了普通文本的文本，它是文字、圖片、視頻等的混合體。最關(guān)鍵有超鏈接，能從一個(gè)超文本跳轉(zhuǎn)到另外一個(gè)超文本。

HTML 就是最常見的超文本了，它本身只是純文字文件，但內(nèi)部用很多標(biāo)簽定義了圖片、視頻等的鏈接，在經(jīng)過瀏覽器的解析，呈現(xiàn)給我們的就是一個(gè)文字、有畫面的網(wǎng)頁了。

OK，下面我們正式介紹什么是 HTTP？

HTTP：超文本傳輸協(xié)議（HyperText Transfer Protocol）是當(dāng)今互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議。所有的 WWW（萬維網(wǎng)） 文件都必須遵守這個(gè)標(biāo)準(zhǔn)。HTTP 和 TCP/IP 協(xié)議簇中的眾多協(xié)議一樣，用于客戶端和服務(wù)器端之間的通信。

四、駐足不前的 HTTP

至今被世人廣泛使用的 HTTP 協(xié)議，仍然是 20 多年前的版本。也就是說，作為 Web 文檔傳輸協(xié)議的 HTTP，它的版本幾乎沒有更新，從另一方面來說，前人的智慧真的牛逼 ?

HTTP/0.9：HTTP 于 1990 年問世，功能簡陋，僅支持 GET 請(qǐng)求方式，并且僅能訪問 HTML 格式的資源。那時(shí)的 HTTP 并沒有作為正式的標(biāo)準(zhǔn)被建立，因此被被稱為 HTTP 0.9。

HTTP/1.0：1996 年 5 月 HTTP 正式作為標(biāo)準(zhǔn)被公布，版本號(hào)為 HTTP 1.0。在 0.9 版本上做了進(jìn)步，增加了請(qǐng)求方式 POST 和 HEAD；不再局限于 0.9 版本的 HTML 格式，根據(jù) Content-Type 可以支持多種數(shù)據(jù)格式...... 需要注意的是：1.0 版本的工作方式是短連接。雖說 HTTP/1.0 是初期標(biāo)準(zhǔn)，但該協(xié)議標(biāo)準(zhǔn)至今仍然在被廣泛使用。

HTTP/1.1：1997 年公布的 HTTP 1.1 是目前主流的 HTTP 協(xié)議版本。當(dāng)年的 HTTP 協(xié)議的出現(xiàn)主要是為了解決文本傳輸?shù)碾y題，現(xiàn)在的 HTTP 早已超出了 Web 這個(gè)框架的局限，被運(yùn)用到了各種場(chǎng)景里。當(dāng)然，1.1 版本的最大變化，就是引入了長連接以及流水線機(jī)制（管道機(jī)制）。

這里面出現(xiàn)的各種專有名詞大家留個(gè)印象就行，下文會(huì)逐漸講解。

五、區(qū)分 URL 和 URI

與 URI（統(tǒng)一資源標(biāo)識(shí)符） 相比，大家應(yīng)該更熟悉 URL（Uniform Resource Location，統(tǒng)一資源定位符），URL 就是我們使用 Web 瀏覽器訪問 Web 頁面時(shí)需要輸入的網(wǎng)頁地址。比如 http://baidu.com。

URI 是 Uniform Resource Identifier 的縮寫，RFC 2386 分別對(duì)這三個(gè)單詞進(jìn)行如下定義：

• Uniform：統(tǒng)一規(guī)定的格式可方便處理多種不同類型的資源

• Resource：資源的定義是可標(biāo)識(shí)的任何東西。不僅可以是單一的，也可以是一個(gè)集合

• Identifier：標(biāo)識(shí)可標(biāo)識(shí)的對(duì)象。也稱為標(biāo)識(shí)符

綜上，URI 就是由某個(gè)協(xié)議方法表示的資源的定位標(biāo)識(shí)符。比如說，采用 HTTP 協(xié)議時(shí)，協(xié)議方案就是 http，除此之外，還有 ftp、telnet 等，標(biāo)準(zhǔn)的 URI 協(xié)議方法有 30 種左右。

URI 有兩種格式，相對(duì) URI 和絕對(duì) URI。

• 相對(duì) URI：指從瀏覽器中基本 URI 處指定的 URL，形如 /user/logo.jpg

• 絕對(duì) URI：使用涵蓋全部必要信息

總結(jié)來說：URI 用字符串標(biāo)識(shí)某一處互聯(lián)網(wǎng)資源，而 URL 標(biāo)識(shí)資源的地點(diǎn)（互聯(lián)網(wǎng)上所處的位置），可見 URL 是 URI 的子集。

六、HTTP 請(qǐng)求和響應(yīng)

HTTP 協(xié)議規(guī)定，在兩臺(tái)計(jì)算機(jī)之間使用 HTTP 協(xié)議進(jìn)行通信時(shí)，在一條通信線路上必定有一端是客戶端，另一端則是服務(wù)端。當(dāng)在瀏覽器中輸入網(wǎng)址訪問某個(gè)網(wǎng)站時(shí)， 你的瀏覽器（客戶端）會(huì)將你的請(qǐng)求封裝成一個(gè) HTTP 請(qǐng)求發(fā)送給服務(wù)器站點(diǎn)，服務(wù)器接收到請(qǐng)求后會(huì)組織響應(yīng)數(shù)據(jù)封裝成一個(gè) HTTP 響應(yīng)返回給瀏覽器。換句話說，肯定是先從客戶端開始建立通信的，服務(wù)器端在沒有接收到請(qǐng)求之前不會(huì)發(fā)送響應(yīng)。

下面我們?cè)敿?xì)分析一下 HTTP 的請(qǐng)求報(bào)文和響應(yīng)報(bào)文

① HTTP 請(qǐng)求報(bào)文

HTTP 請(qǐng)求報(bào)文由 3 大部分組成：

1）請(qǐng)求行（必須在 HTTP 請(qǐng)求報(bào)文的第一行）

2）請(qǐng)求頭（從第二行開始，到第一個(gè)空行結(jié)束。請(qǐng)求頭和請(qǐng)求體之間存在一個(gè)空行）

3）請(qǐng)求體（通常以鍵值對(duì) {key:value}方式傳遞數(shù)據(jù)）

舉個(gè)請(qǐng)求報(bào)文的例子：

請(qǐng)求行開頭的 POST 表示請(qǐng)求訪問服務(wù)器的類型，稱為方法（method）。隨后的字符串 /form/login 指明了請(qǐng)求訪問的資源對(duì)象，也叫做請(qǐng)求 URI（request-URI）。最后的 HTTP/1.1 即 HTTP 的版本號(hào)，用來提示客戶端使用的 HTTP 協(xié)議功能。

綜上來看，這段請(qǐng)求的意思就是：請(qǐng)求訪問某臺(tái) HTTP 服務(wù)器上的 /form/login 頁面資源，并附帶參數(shù) name = veal、age = 37。

注意，無論是 HTTP 請(qǐng)求報(bào)文還是 HTTP 響應(yīng)報(bào)文，請(qǐng)求頭/響應(yīng)頭和請(qǐng)求體/響應(yīng)體之間都會(huì)有一個(gè)空行，且請(qǐng)求體/響應(yīng)體并不是必須的。

HTTP 請(qǐng)求方法

請(qǐng)求行中的方法的作用在于可以指定請(qǐng)求的資源按照期望產(chǎn)生某種行為，即使用方法給服務(wù)器下命令。

包括（HTTP 1.1）：GET、POST、PUT、HEAD、DELETE、OPTIONS、CONNECT、TRACE。當(dāng)然，我們?cè)陂_發(fā)中最常見也最常使用的就只有前面三個(gè)。

1）GET 獲取資源

GET 方法用來請(qǐng)求訪問已被 URI 識(shí)別的資源。指定的資源經(jīng)服務(wù)器端解析后返回響應(yīng)內(nèi)容

使用 GET 方法請(qǐng)求-響應(yīng)的例子：

2）POST 傳輸實(shí)體主體

POST 主要用來傳輸數(shù)據(jù)，而 GET 主要用來獲取資源。

使用 POST 方法請(qǐng)求-響應(yīng)的例子：

3）PUT 傳輸文件

PUT 方法用來傳輸文件，由于自身不帶驗(yàn)證機(jī)制，任何人都可以上傳文件，因此存在安全性問題，一般不使用該方法。

使用 PUT 方法請(qǐng)求-響應(yīng)的例子：

4）HEAD 獲取報(bào)文首部

和 GET 方法類似，但是不返回報(bào)文實(shí)體主體部分。主要用于確認(rèn) URI 的有效性以及資源更新的日期時(shí)間等。

使用 HEAD 方法請(qǐng)求-響應(yīng)的例子：

5）DELETE 刪除文件

與 PUT 功能相反，用來刪除文件，并且同樣不帶驗(yàn)證機(jī)制，按照請(qǐng)求 URI 刪除指定的資源。

使用 DEELTE 方法請(qǐng)求-響應(yīng)的例子：

6）OPTIONS 查詢支持的方法

用于獲取當(dāng)前 URI 所支持的方法。若請(qǐng)求成功，會(huì)在 HTTP 響應(yīng)頭中包含一個(gè)名為 “Allow” 的字段，值是所支持的方法，如 “GET, POST”。

使用 OPTIONS 方法請(qǐng)求-響應(yīng)的例子：

7）..........

HTTP 請(qǐng)求頭

請(qǐng)求頭用于補(bǔ)充請(qǐng)求的附加信息、客戶端信息、對(duì)響應(yīng)內(nèi)容相關(guān)的優(yōu)先級(jí)等內(nèi)容。以下列出常見請(qǐng)求頭：

1）Referer：表示這個(gè)請(qǐng)求是從哪個(gè) URI 跳過來的。。如果是直接訪問就不會(huì)有這個(gè)頭。這個(gè)字段通常用于防盜鏈。

2）Accept：告訴服務(wù)端，該請(qǐng)求所能支持的響應(yīng)數(shù)據(jù)類型。（對(duì)應(yīng)的，HTTP 響應(yīng)報(bào)文中也有這樣一個(gè)類似的字段 Content-Type，用于表示服務(wù)端發(fā)送的數(shù)據(jù)類型，如果 Accept 指定的類型和服務(wù)端返回的類型不一致，就會(huì)報(bào)錯(cuò)）

上圖中的 text/plain;q = 0.3 表示對(duì)于 text/plain 媒體類型的數(shù)據(jù)優(yōu)先級(jí)/權(quán)重為 0.3（q 的范圍 0 ~ 1）。不指定權(quán)重的，默認(rèn)為 1.0。

數(shù)據(jù)格式類型如下圖：

3）Host：告知服務(wù)器請(qǐng)求的資源所處的互聯(lián)網(wǎng)主機(jī)名和端口號(hào)。該字段是 HTTP/1.1 規(guī)范中唯一一個(gè)必須被 包含在請(qǐng)求頭中的字段。

4）Cookie：客戶端的 Cookie 就是通過這個(gè)報(bào)文頭屬性傳給服務(wù)端的！

Cookie: JSESSIONID=15982C27F7507C7FDAF0F97161F634B5

5）Connection：表示客戶端與服務(wù)連接類型；Keep-Alive 表示持久連接，close 已關(guān)閉

6）Content-Length：請(qǐng)求體的長度

7）Accept-Language：瀏覽器通知服務(wù)器，瀏覽器支持的語言

8）Range：對(duì)于只需獲取部分資源的范圍請(qǐng)求，包含首部字段 Range 即可告知服務(wù)器資源的指定范圍

9）......

② HTTP響應(yīng)報(bào)文

HTTP的響應(yīng)報(bào)文也由三部分組成：

• 響應(yīng)行（必須在 HTTP 響應(yīng)報(bào)文的第一行）

• 響應(yīng)頭（從第二行開始，到第一個(gè)空行結(jié)束。響應(yīng)頭和響應(yīng)體之間存在一個(gè)空行）

• 響應(yīng)體

在響應(yīng)行開頭的 HTTP 1.1 表示服務(wù)器對(duì)應(yīng)的 HTTP 版本。緊隨的 200 OK 表示請(qǐng)求的處理結(jié)果的狀態(tài)碼和原因短語。

HTTP 狀態(tài)碼

HTTP 狀態(tài)碼負(fù)責(zé)表示客戶端 HTTP 請(qǐng)求的的返回結(jié)果、標(biāo)記服務(wù)器端處理是否正常、通知出現(xiàn)的錯(cuò)誤等工作。（重中之重?。。?，和我們?nèi)粘ｉ_發(fā)息息相關(guān)）

狀態(tài)碼由 3 位數(shù)字組成，第一個(gè)數(shù)字定義了響應(yīng)的類別：

 2xx：請(qǐng)求正常處理完畢

200 OK：客戶端請(qǐng)求成功

204 No Content：無內(nèi)容。服務(wù)器成功處理，但未返回內(nèi)容。一般用在只是客戶端向服務(wù)器發(fā)送信息，而服務(wù)器不用向客戶端返回什么信息的情況。不會(huì)刷新頁面。

206 Partial Content：服務(wù)器已經(jīng)完成了部分 GET 請(qǐng)求（客戶端進(jìn)行了范圍請(qǐng)求）。響應(yīng)報(bào)文中包含 Content-Range 指定范圍的實(shí)體內(nèi)容

3xx：需要進(jìn)行附加操作以完成請(qǐng)求（重定向）

• 301 Moved Permanently：永久重定向，表示請(qǐng)求的資源已經(jīng)永久的搬到了其他位置。

• 302 Found：臨時(shí)重定向，表示請(qǐng)求的資源臨時(shí)搬到了其他位置

• 303 See Other：臨時(shí)重定向，應(yīng)使用GET定向獲取請(qǐng)求資源。303功能與302一樣，區(qū)別只是303明確客戶端應(yīng)該使用GET訪問

• 304 Not Modified：表示客戶端發(fā)送附帶條件的請(qǐng)求（GET方法請(qǐng)求報(bào)文中的IF…）時(shí)，條件不滿足。返回304時(shí)，不包含任何響應(yīng)主體。雖然304被劃分在3XX，但和重定向一毛錢關(guān)系都沒有

• 307 Temporary Redirect：臨時(shí)重定向，和302有著相同含義。POST不會(huì)變成GET

4xx：客戶端錯(cuò)誤

• 400 Bad Request：客戶端請(qǐng)求有語法錯(cuò)誤，服務(wù)器無法理解。

• 401 Unauthorized：請(qǐng)求未經(jīng)授權(quán)，這個(gè)狀態(tài)代碼必須和 WWW-Authenticate 報(bào)頭域一起使用。

• 403 Forbidden：服務(wù)器收到請(qǐng)求，但是拒絕提供服務(wù)

• 404 Not Found：請(qǐng)求資源不存在。比如，輸入了錯(cuò)誤的 URL

• 415 Unsupported media type：不支持的媒體類型

5xx：服務(wù)器端錯(cuò)誤，服務(wù)器未能實(shí)現(xiàn)合法的請(qǐng)求。

• 500 Internal Server Error：服務(wù)器發(fā)生不可預(yù)期的錯(cuò)誤。

• 503 Server Unavailable：服務(wù)器當(dāng)前處于超負(fù)載或正在停機(jī)維護(hù)，暫時(shí)不能處理客戶端的請(qǐng)求，一段時(shí)間后可能恢復(fù)正常

HTTP 響應(yīng)頭

響應(yīng)頭也是用鍵值對(duì) k：v，用于補(bǔ)充響應(yīng)的附加信息、服務(wù)器信息，以及對(duì)客戶端的附加要求等。

這里著重說明一下 Location 這個(gè)字段，可以將響應(yīng)接收方引導(dǎo)至與某個(gè) URI 位置不同的資源。通常來說，該字段會(huì)配合 3xx:Redirection 的響應(yīng)，提供重定向的 URI。

七、HTTP 連接管理

① 短連接（非持久連接）

在 HTTP 協(xié)議的初始版本（HTTP/1.0）中，客戶端和服務(wù)器每進(jìn)行一次 HTTP 會(huì)話，就建立一次連接，任務(wù)結(jié)束就中斷連接。當(dāng)客戶端瀏覽器訪問的某個(gè) HTML 或其他類型的 Web 頁中包含有其他的 Web 資源（如JavaScript 文件、圖像文件、CSS文件等），每遇到這樣一個(gè) Web 資源，瀏覽器就會(huì)重新建立一個(gè) HTTP 會(huì)話。這種方式稱為短連接（也稱非持久連接）。

也就是說每次 HTTP 請(qǐng)求都要重新建立一次連接。由于 HTTP 是基于 TCP/IP 協(xié)議的，所以連接的每一次建立或者斷開都需要 TCP 三次握手或者 TCP 四次揮手的開銷。

顯然，這種方式存在巨大的弊端。比如訪問一個(gè)包含多張圖片的 HTML 頁面，每請(qǐng)求一張圖片資源就會(huì)造成無謂的 TCP 連接的建立和斷開，大大增加了通信量的開銷

② 長連接（持久連接）

從 HTTP/1.1 起，默認(rèn)使用長連接也稱持久連接 keep-alive。使用長連接的 HTTP 協(xié)議，會(huì)在響應(yīng)頭加入這行代碼：Connection:keep-alive

在使用長連接的情況下，當(dāng)一個(gè)網(wǎng)頁打開完成后，客戶端和服務(wù)器之間用于傳輸 HTTP 數(shù)據(jù)的 TCP 連接不會(huì)關(guān)閉，客戶端再次訪問這個(gè)服務(wù)器時(shí)，會(huì)繼續(xù)使用這一條已經(jīng)建立的連接。Keep-Alive 不會(huì)永久保持連接，它有一個(gè)保持時(shí)間，可以在不同的服務(wù)器軟件（如 Apache）中設(shè)定這個(gè)時(shí)間。實(shí)現(xiàn)長連接需要客戶端和服務(wù)端都支持長連接。

HTTP 協(xié)議的長連接和短連接，實(shí)質(zhì)上是 TCP 協(xié)議的長連接和短連接。

③ 流水線（管線化）

默認(rèn)情況下，HTTP 請(qǐng)求是按順序發(fā)出的，下一個(gè)請(qǐng)求只有在當(dāng)前請(qǐng)求收到響應(yīng)之后才會(huì)被發(fā)出。由于受到網(wǎng)絡(luò)延遲和帶寬的限制，在下一個(gè)請(qǐng)求被發(fā)送到服務(wù)器之前，可能需要等待很長時(shí)間。

持久連接使得多數(shù)請(qǐng)求以流水線（管線化 pipeline）方式發(fā)送成為可能，即在同一條持久連接上連續(xù)發(fā)出請(qǐng)求，而不用等待響應(yīng)返回后再發(fā)送，這樣就可以做到同時(shí)并行發(fā)送多個(gè)請(qǐng)求，而不需要一個(gè)接一個(gè)地等待響應(yīng)了。

八、無狀態(tài)的 HTTP

HTTP 協(xié)議是無狀態(tài)協(xié)議。也就是說他不對(duì)之前發(fā)生過的請(qǐng)求和響應(yīng)的狀態(tài)進(jìn)行管理，即無法根據(jù)之前的狀態(tài)進(jìn)行本次的請(qǐng)求處理。

這樣就會(huì)帶來一個(gè)明顯的問題，如果 HTTP 無法記住用戶登錄的狀態(tài)，那豈不是每次頁面的跳轉(zhuǎn)都會(huì)導(dǎo)致用戶需要再次重新登錄？

當(dāng)然，不可否認(rèn)，無狀態(tài)的優(yōu)點(diǎn)也很顯著，由于不必保存狀態(tài)，自然就減少了服務(wù)器的 CPU 及內(nèi)存資源的消耗。另一方面，正式由于 HTTP 簡單，所以才會(huì)被如此廣泛應(yīng)用。

這樣，在保留無狀態(tài)協(xié)議這個(gè)特征的同時(shí)，又要解決無狀態(tài)導(dǎo)致的問題。方案有很多種，其中比較簡單的方式就是使用 Cookie 技術(shù)。

Cookie 通過在請(qǐng)求和響應(yīng)報(bào)文中寫入 Cookie 信息來控制客戶端的狀態(tài)。具體來說，Cookie 會(huì)根據(jù)從服務(wù)器端發(fā)送的響應(yīng)報(bào)文中的一個(gè)叫作 Set-Cookie 的首部字段信息，通知客戶端保存 Cookie。當(dāng)下次客戶端再往服務(wù)器發(fā)送請(qǐng)求時(shí)，客戶端會(huì)自動(dòng)在請(qǐng)求報(bào)文中加入 Cookie 值發(fā)送出去。服務(wù)器端收到客戶端發(fā)來的 Cookie 后，會(huì)去檢查究竟是哪一個(gè)客戶端發(fā)來的連接請(qǐng)求，然后對(duì)比服務(wù)器上的記錄，最后得到之前的狀態(tài)信息。

形象來說，在客戶端第一次請(qǐng)求后，服務(wù)器會(huì)下發(fā)一個(gè)裝有客戶信息的身份證，后續(xù)客戶端請(qǐng)求服務(wù)器的時(shí)候，帶上身份證，服務(wù)器就能認(rèn)得了。

下圖展示了發(fā)生 Cookie 交互的情景：

1）沒有 Cookie 信息狀態(tài)下的請(qǐng)求：

對(duì)應(yīng)的 HTTP 請(qǐng)求報(bào)文（沒有 Cookie 信息的狀態(tài)）

GET /reader/ HTTP/1.1

Host: baidu.com

* 首部字段沒有 Cookie 的相關(guān)信息

對(duì)應(yīng)的 HTTP 響應(yīng)報(bào)文（服務(wù)端生成 Cookie 信息）

HTTP/1.1 200 OK

Date: Thu, 12 Jul 2020 15:12:20 GMT

Server: Apache

<Set-Cookie: sid=1342077140226; path=/; expires=Wed, 10-Oct-12 15:12:20 GMT>

Content-Type: text/plain; charset=UTF-8

2）第 2 次以后的請(qǐng)求（存有 Cookie 信息狀態(tài)）

對(duì)應(yīng)的 HTTP 請(qǐng)求報(bào)文（自動(dòng)發(fā)送保存著的 Cookie 信息）

GET /image/ HTTP/1.1

Host: baidu.com

Cookie: sid=1342077140226

九、HTTP 斷點(diǎn)續(xù)傳

所謂斷點(diǎn)續(xù)傳指的是下載傳輸文件可以中斷，之后重新下載時(shí)可以接著中斷的地方開始下載，而不必從頭開始下載。斷點(diǎn)續(xù)傳需要客戶端和服務(wù)端都支持。

這是一個(gè)非常常見的功能，原理很簡單，其實(shí)就是 HTTP 請(qǐng)求頭中的字段 Range 和響應(yīng)頭中的字段 Content-Range 的簡單使用?？蛻舳艘粔K一塊的請(qǐng)求數(shù)據(jù)，最后將下載回來的數(shù)據(jù)塊拼接成完整的數(shù)據(jù)。打個(gè)比方，瀏覽器請(qǐng)求服務(wù)器上的一個(gè)服務(wù)，所發(fā)出的請(qǐng)求如下：

假設(shè)服務(wù)器域名為www.baidu.com，文件名為 down.zip。

GET /down.zip HTTP/1.1 

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms- 

excel, application/msword, application/vnd.ms-powerpoint, */* 

Accept-Language: zh-cn 

Accept-Encoding: gzip, deflate 

User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0) 

Connection: Keep-Alive 

服務(wù)器收到請(qǐng)求后，按要求尋找請(qǐng)求的文件，提取文件的信息，然后返回給瀏覽器，返回信息如下：

200 

Content-Length=106786028 

Accept-Ranges=bytes 

Date=Mon, 30 Apr 2001 12:56:11 GMT 

ETag=W/"02ca57e173c11:95b" 

Content-Type=application/octet-stream 

Server=Microsoft-IIS/5.0 

Last-Modified=Mon, 30 Apr 2001 12:56:11 GMT 

OK，那么既然要斷點(diǎn)續(xù)傳，客戶端瀏覽器請(qǐng)求服務(wù)器的時(shí)候要多加一條信息 — 從哪里開始請(qǐng)求數(shù)據(jù)。 比如要求從 2000070 字節(jié)開始：

GET /down.zip HTTP/1.0 

User-Agent: NetFox 

RANGE: bytes=2000070- 

Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2 

仔細(xì)看一下就會(huì)發(fā)現(xiàn)多了一行 RANGE: bytes=2000070-。這一行的意思就是告訴服務(wù)器 down.zip 這個(gè)文件從 2000070 字節(jié)開始傳，前面的字節(jié)不用傳了。

服務(wù)器收到這個(gè)請(qǐng)求以后，返回的信息如下：

206

Content-Length=106786028

Content-Range=bytes 2000070-106786027/106786028

Date=Mon, 30 Apr 2001 12:55:20 GMT

ETag=W/"02ca57e173c11:95b"

Content-Type=application/octet-stream

Server=Microsoft-IIS/5.0

Last-Modified=Mon, 30 Apr 2001 12:55:20 GMT

和前面服務(wù)器返回的信息比較一下，就會(huì)發(fā)現(xiàn)增加了一行： Content-Range=bytes 2000070-106786027/106786028。返回的代碼也改為 206 了，而不再是 200 了。

十、HTTP 的缺點(diǎn)

到現(xiàn)在為止，我們已經(jīng)了解到了 HTTP 具有相當(dāng)優(yōu)秀和方便的一面，然后，事務(wù)皆有兩面性，他也是有不足之處的：

通信使用明文（不加密），內(nèi)容可能被竊聽

不驗(yàn)證通信對(duì)方的身份，因此有可能遭遇偽裝

無法證明報(bào)文的完整性，所以有可能被篡改

這些問題不僅在 HTTP 上出現(xiàn)，其他未加密的協(xié)議中也存在類似問題，為了解決 HTTP 的痛點(diǎn)，HTTPS 應(yīng)用而生，說白了 HTTP + 加密 + 認(rèn)證 + 完整性保護(hù)就是 HTTPS 協(xié)議，關(guān)于 HTTPS 協(xié)議的內(nèi)容也非常之多且重要，后續(xù)會(huì)單開一篇文章進(jìn)行講解。

感謝各位的閱讀，以上就是“什么是HTTP協(xié)議”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對(duì)什么是HTTP協(xié)議這一問題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！