你知道當(dāng)我們在網(wǎng)頁瀏覽器的地址欄中輸入 URL 時，Web 頁面是如何呈現(xiàn)的嗎？
Web 界面當(dāng)然不會憑空出來，根據(jù) Web 瀏覽器地址欄中指定的 URL，Web 使用一種名為 HTTP 的協(xié)議作為規(guī)范，完成從客戶端到服務(wù)端的一些流程?？梢哉f，Web 是建立在 HTTP 協(xié)議上進(jìn)行通信的。
其實(shí)，在 1983 年 3 月之前，互聯(lián)網(wǎng)還只屬于少數(shù)人，全世界的網(wǎng)民之間的信息是無法共享的。在這一互聯(lián)網(wǎng)的黎明時期，HTTP 應(yīng)運(yùn)而生。
歐洲核子研究組織的 Tim Berners-Lee 博士提出了一種能夠讓遠(yuǎn)隔兩地的網(wǎng)民共享知識的設(shè)想，最初的理念是：借助多文檔之間相互關(guān)聯(lián)的超文本（HyperTest），連成可相互參閱的 WWW（World Wide Web，萬維網(wǎng)）。
現(xiàn)在已提出了 3 項(xiàng) WWW 構(gòu)建技術(shù)，分別是：
WWW 這一名稱，是 Web 瀏覽器當(dāng)年用來瀏覽超文本的客戶端應(yīng)用程序的名稱，現(xiàn)在用來表示這一系列的集合，也可簡稱為 Web。
說了這么多，大家只知道 HTTP 很牛逼，對 HTTP 是什么仍然沒有很直觀的概念。別急，在了解什么是 HTTP 之前，我們有必要知道超文本是什么。
HTTP 傳輸?shù)膬?nèi)容就是超文本：
HTML 就是最常見的超文本了，它本身只是純文字文件，但內(nèi)部用很多標(biāo)簽定義了圖片、視頻等的鏈接，在經(jīng)過瀏覽器的解析，呈現(xiàn)給我們的就是一個文字、有畫面的網(wǎng)頁了。
OK，下面我們正式介紹什么是 HTTP？
HTTP：超文本傳輸協(xié)議（HyperText Transfer Protocol）是當(dāng)今互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議。所有的 WWW（萬維網(wǎng)） 文件都必須遵守這個標(biāo)準(zhǔn)。HTTP 和 TCP/IP 協(xié)議簇中的眾多協(xié)議一樣，用于客戶端和服務(wù)器端之間的通信。
至今被世人廣泛使用的 HTTP 協(xié)議，仍然是 20 多年前的版本。也就是說，作為 Web 文檔傳輸協(xié)議的 HTTP，它的版本幾乎沒有更新，從另一方面來說，前人的智慧真的牛逼 👍
HTTP/0.9：HTTP 于 1990 年問世，功能簡陋，僅支持 GET 請求方式，并且僅能訪問 HTML 格式的資源。那時的 HTTP 并沒有作為正式的標(biāo)準(zhǔn)被建立，因此被被稱為 HTTP 0.9。
HTTP/1.0：1996 年 5 月 HTTP 正式作為標(biāo)準(zhǔn)被公布，版本號為 HTTP 1.0。在 0.9 版本上做了進(jìn)步，增加了請求方式 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 這個框架的局限，被運(yùn)用到了各種場景里。當(dāng)然，1.1 版本的最大變化，就是引入了長連接以及流水線機(jī)制（管道機(jī)制）。
這里面出現(xiàn)的各種專有名詞大家留個印象就行，下文會逐漸講解。
與 URI（統(tǒng)一資源標(biāo)識符） 相比，大家應(yīng)該更熟悉 URL（Uniform Resource Location，統(tǒng)一資源定位符），URL 就是我們使用 Web 瀏覽器訪問 Web 頁面時需要輸入的網(wǎng)頁地址。比如 http://baidu.com。
URI 是 Uniform Resource Identifier 的縮寫，RFC 2386 分別對這三個單詞進(jìn)行如下定義：
綜上，URI 就是由某個協(xié)議方法表示的資源的定位標(biāo)識符。比如說，采用 HTTP 協(xié)議時，協(xié)議方案就是 http，除此之外，還有 ftp、telnet 等，標(biāo)準(zhǔn)的 URI 協(xié)議方法有 30 種左右。
URI 有兩種格式，相對 URI 和絕對 URI。
/user/logo.jpg
總結(jié)來說：URI 用字符串標(biāo)識某一處互聯(lián)網(wǎng)資源，而 URL 標(biāo)識資源的地點(diǎn)（互聯(lián)網(wǎng)上所處的位置），可見 URL 是 URI 的子集。
HTTP 協(xié)議規(guī)定，在兩臺計(jì)算機(jī)之間使用 HTTP 協(xié)議進(jìn)行通信時，在一條通信線路上必定有一端是客戶端，另一端則是服務(wù)端。當(dāng)在瀏覽器中輸入網(wǎng)址訪問某個網(wǎng)站時， 你的瀏覽器（客戶端）會將你的請求封裝成一個 HTTP 請求發(fā)送給服務(wù)器站點(diǎn)，服務(wù)器接收到請求后會組織響應(yīng)數(shù)據(jù)封裝成一個 HTTP 響應(yīng)返回給瀏覽器。換句話說，肯定是先從客戶端開始建立通信的，服務(wù)器端在沒有接收到請求之前不會發(fā)送響應(yīng)。
下面我們詳細(xì)分析一下 HTTP 的請求報(bào)文和響應(yīng)報(bào)文
① HTTP 請求報(bào)文
HTTP 請求報(bào)文由 3 大部分組成：
1）請求行（必須在 HTTP 請求報(bào)文的第一行）
2）請求頭（從第二行開始，到第一個空行結(jié)束。請求頭和請求體之間存在一個空行）
3）請求體（通常以鍵值對 {key:value}方式傳遞數(shù)據(jù)）
舉個請求報(bào)文的例子：
請求行開頭的 POST 表示請求訪問服務(wù)器的類型，稱為方法（method）。隨后的字符串 /form/login 指明了請求訪問的資源對象，也叫做請求 URI（request-URI）。最后的 HTTP/1.1 即 HTTP 的版本號，用來提示客戶端使用的 HTTP 協(xié)議功能。
綜上來看，這段請求的意思就是：請求訪問某臺 HTTP 服務(wù)器上的 /form/login 頁面資源，并附帶參數(shù) name = veal、age = 37。
注意，無論是 HTTP 請求報(bào)文還是 HTTP 響應(yīng)報(bào)文，請求頭/響應(yīng)頭和請求體/響應(yīng)體之間都會有一個空行，且請求體/響應(yīng)體并不是必須的。
HTTP 請求方法
請求行中的方法的作用在于可以指定請求的資源按照期望產(chǎn)生某種行為，即使用方法給服務(wù)器下命令。
包括（HTTP 1.1）：GET、POST、PUT、HEAD、DELETE、OPTIONS、CONNECT、TRACE。當(dāng)然，我們在開發(fā)中最常見也最常使用的就只有前面三個。
1）GET 獲取資源
GET 方法用來請求訪問已被 URI 識別的資源。指定的資源經(jīng)服務(wù)器端解析后返回響應(yīng)內(nèi)容
使用 GET 方法請求-響應(yīng)的例子：
2）POST 傳輸實(shí)體主體
POST 主要用來傳輸數(shù)據(jù)，而 GET 主要用來獲取資源。
使用 POST 方法請求-響應(yīng)的例子：
3）PUT 傳輸文件
PUT 方法用來傳輸文件，由于自身不帶驗(yàn)證機(jī)制，任何人都可以上傳文件，因此存在安全性問題，一般不使用該方法。
使用 PUT 方法請求-響應(yīng)的例子：
4）HEAD 獲取報(bào)文首部
和 GET 方法類似，但是不返回報(bào)文實(shí)體主體部分。主要用于確認(rèn) URI 的有效性以及資源更新的日期時間等。
使用 HEAD 方法請求-響應(yīng)的例子：
5）DELETE 刪除文件
與 PUT 功能相反，用來刪除文件，并且同樣不帶驗(yàn)證機(jī)制，按照請求 URI 刪除指定的資源。
使用 DEELTE 方法請求-響應(yīng)的例子：
6）OPTIONS 查詢支持的方法
用于獲取當(dāng)前 URI 所支持的方法。若請求成功，會在 HTTP 響應(yīng)頭中包含一個名為 “Allow” 的字段，值是所支持的方法，如 “GET, POST”。
使用 OPTIONS 方法請求-響應(yīng)的例子：
7）..........
HTTP 請求頭
請求頭用于補(bǔ)充請求的附加信息、客戶端信息、對響應(yīng)內(nèi)容相關(guān)的優(yōu)先級等內(nèi)容。以下列出常見請求頭：
1）Referer：表示這個請求是從哪個 URI 跳過來的。。如果是直接訪問就不會有這個頭。這個字段通常用于防盜鏈。
2）Accept：告訴服務(wù)端，該請求所能支持的響應(yīng)數(shù)據(jù)類型。（對應(yīng)的，HTTP 響應(yīng)報(bào)文中也有這樣一個類似的字段 Content-Type，用于表示服務(wù)端發(fā)送的數(shù)據(jù)類型，如果 Accept 指定的類型和服務(wù)端返回的類型不一致，就會報(bào)錯）
上圖中的 text/plain;q = 0.3 表示對于 text/plain 媒體類型的數(shù)據(jù)優(yōu)先級/權(quán)重為 0.3（q 的范圍 0 ~ 1）。不指定權(quán)重的，默認(rèn)為 1.0。
數(shù)據(jù)格式類型如下圖：
3）Host：告知服務(wù)器請求的資源所處的互聯(lián)網(wǎng)主機(jī)名和端口號。該字段是 HTTP/1.1 規(guī)范中唯一一個必須被 包含在請求頭中的字段。
4）Cookie：客戶端的 Cookie 就是通過這個報(bào)文頭屬性傳給服務(wù)端的！
Cookie: JSESSIONID=15982C27F7507C7FDAF0F97161F634B5
5）Connection：表示客戶端與服務(wù)連接類型；Keep-Alive 表示持久連接，close 已關(guān)閉
6）Content-Length：請求體的長度
7）Accept-Language：瀏覽器通知服務(wù)器，瀏覽器支持的語言
8）Range：對于只需獲取部分資源的范圍請求，包含首部字段 Range 即可告知服務(wù)器資源的指定范圍
9）......
② HTTP響應(yīng)報(bào)文
HTTP的響應(yīng)報(bào)文也由三部分組成：
在響應(yīng)行開頭的 HTTP 1.1 表示服務(wù)器對應(yīng)的 HTTP 版本。緊隨的 200 OK 表示請求的處理結(jié)果的狀態(tài)碼和原因短語。
HTTP 狀態(tài)碼
HTTP 狀態(tài)碼負(fù)責(zé)表示客戶端 HTTP 請求的的返回結(jié)果、標(biāo)記服務(wù)器端處理是否正常、通知出現(xiàn)的錯誤等工作。（重中之重?。。?，和我們?nèi)粘ｉ_發(fā)息息相關(guān)）
狀態(tài)碼由 3 位數(shù)字組成，第一個數(shù)字定義了響應(yīng)的類別：
| 類別 | 原因短語 | |
|---|---|---|
| 1xx | Informational 信息性狀態(tài)碼 | 接收的請求正在處理 |
| 2xx | Success 成功狀態(tài)碼 | 請求正常處理完畢 |
| 3xx | Redirection 重定向狀態(tài)碼 | 需要進(jìn)行附加操作以完成請求 |
| 4xx | Client Error 客戶端錯誤狀態(tài)碼 | 服務(wù)器無法處理請求 |
| 5xx | Server Error 服務(wù)器錯誤狀態(tài)碼 | 服務(wù)器處理請求出錯 |
2xx：請求正常處理完畢
200 OK：客戶端請求成功
204 No Content：無內(nèi)容。服務(wù)器成功處理，但未返回內(nèi)容。一般用在只是客戶端向服務(wù)器發(fā)送信息，而服務(wù)器不用向客戶端返回什么信息的情況。不會刷新頁面。
206 Partial Content：服務(wù)器已經(jīng)完成了部分 GET 請求（客戶端進(jìn)行了范圍請求）。響應(yīng)報(bào)文中包含 Content-Range 指定范圍的實(shí)體內(nèi)容
3xx：需要進(jìn)行附加操作以完成請求（重定向）
301 Moved Permanently：永久重定向，表示請求的資源已經(jīng)永久的搬到了其他位置。302 Found：臨時重定向，表示請求的資源臨時搬到了其他位置303 See Other：臨時重定向，應(yīng)使用GET定向獲取請求資源。303功能與302一樣，區(qū)別只是303明確客戶端應(yīng)該使用GET訪問304 Not Modified：表示客戶端發(fā)送附帶條件的請求（GET方法請求報(bào)文中的IF…）時，條件不滿足。返回304時，不包含任何響應(yīng)主體。雖然304被劃分在3XX，但和重定向一毛錢關(guān)系都沒有307 Temporary Redirect：臨時重定向，和302有著相同含義。POST不會變成GET4xx：客戶端錯誤
400 Bad Request：客戶端請求有語法錯誤，服務(wù)器無法理解。401 Unauthorized：請求未經(jīng)授權(quán)，這個狀態(tài)代碼必須和 WWW-Authenticate 報(bào)頭域一起使用。403 Forbidden：服務(wù)器收到請求，但是拒絕提供服務(wù)404 Not Found：請求資源不存在。比如，輸入了錯誤的 URL415 Unsupported media type：不支持的媒體類型5xx：服務(wù)器端錯誤，服務(wù)器未能實(shí)現(xiàn)合法的請求。
500 Internal Server Error：服務(wù)器發(fā)生不可預(yù)期的錯誤。503 Server Unavailable：服務(wù)器當(dāng)前處于超負(fù)載或正在停機(jī)維護(hù)，暫時不能處理客戶端的請求，一段時間后可能恢復(fù)正常HTTP 響應(yīng)頭
響應(yīng)頭也是用鍵值對 k：v，用于補(bǔ)充響應(yīng)的附加信息、服務(wù)器信息，以及對客戶端的附加要求等。
這里著重說明一下 Location 這個字段，可以將響應(yīng)接收方引導(dǎo)至與某個 URI 位置不同的資源。通常來說，該字段會配合 3xx:Redirection 的響應(yīng)，提供重定向的 URI。
① 短連接（非持久連接）
在 HTTP 協(xié)議的初始版本（HTTP/1.0）中，客戶端和服務(wù)器每進(jìn)行一次 HTTP 會話，就建立一次連接，任務(wù)結(jié)束就中斷連接。當(dāng)客戶端瀏覽器訪問的某個 HTML 或其他類型的 Web 頁中包含有其他的 Web 資源（如JavaScript 文件、圖像文件、CSS文件等），每遇到這樣一個 Web 資源，瀏覽器就會重新建立一個 HTTP 會話。這種方式稱為短連接（也稱非持久連接）。
也就是說每次 HTTP 請求都要重新建立一次連接。由于 HTTP 是基于 TCP/IP 協(xié)議的，所以連接的每一次建立或者斷開都需要 TCP 三次握手或者 TCP 四次揮手的開銷。
顯然，這種方式存在巨大的弊端。比如訪問一個包含多張圖片的 HTML 頁面，每請求一張圖片資源就會造成無謂的 TCP 連接的建立和斷開，大大增加了通信量的開銷
② 長連接（持久連接）
從 HTTP/1.1 起，默認(rèn)使用長連接也稱持久連接 keep-alive。使用長連接的 HTTP 協(xié)議，會在響應(yīng)頭加入這行代碼：Connection:keep-alive
在使用長連接的情況下，當(dāng)一個網(wǎng)頁打開完成后，客戶端和服務(wù)器之間用于傳輸 HTTP 數(shù)據(jù)的 TCP 連接不會關(guān)閉，客戶端再次訪問這個服務(wù)器時，會繼續(xù)使用這一條已經(jīng)建立的連接。Keep-Alive 不會永久保持連接，它有一個保持時間，可以在不同的服務(wù)器軟件（如 Apache）中設(shè)定這個時間。實(shí)現(xiàn)長連接需要客戶端和服務(wù)端都支持長連接。
HTTP 協(xié)議的長連接和短連接，實(shí)質(zhì)上是 TCP 協(xié)議的長連接和短連接。
③ 流水線（管線化）
默認(rèn)情況下，HTTP 請求是按順序發(fā)出的，下一個請求只有在當(dāng)前請求收到響應(yīng)之后才會被發(fā)出。由于受到網(wǎng)絡(luò)延遲和帶寬的限制，在下一個請求被發(fā)送到服務(wù)器之前，可能需要等待很長時間。
持久連接使得多數(shù)請求以流水線（管線化 pipeline）方式發(fā)送成為可能，即在同一條持久連接上連續(xù)發(fā)出請求，而不用等待響應(yīng)返回后再發(fā)送，這樣就可以做到同時并行發(fā)送多個請求，而不需要一個接一個地等待響應(yīng)了。
HTTP 協(xié)議是無狀態(tài)協(xié)議。也就是說他不對之前發(fā)生過的請求和響應(yīng)的狀態(tài)進(jìn)行管理，即無法根據(jù)之前的狀態(tài)進(jìn)行本次的請求處理。
這樣就會帶來一個明顯的問題，如果 HTTP 無法記住用戶登錄的狀態(tài)，那豈不是每次頁面的跳轉(zhuǎn)都會導(dǎo)致用戶需要再次重新登錄？
當(dāng)然，不可否認(rèn)，無狀態(tài)的優(yōu)點(diǎn)也很顯著，由于不必保存狀態(tài)，自然就減少了服務(wù)器的 CPU 及內(nèi)存資源的消耗。另一方面，正式由于 HTTP 簡單，所以才會被如此廣泛應(yīng)用。
這樣，在保留無狀態(tài)協(xié)議這個特征的同時，又要解決無狀態(tài)導(dǎo)致的問題。方案有很多種，其中比較簡單的方式就是使用 Cookie 技術(shù)。
Cookie 通過在請求和響應(yīng)報(bào)文中寫入 Cookie 信息來控制客戶端的狀態(tài)。具體來說，Cookie 會根據(jù)從服務(wù)器端發(fā)送的響應(yīng)報(bào)文中的一個叫作 Set-Cookie 的首部字段信息，通知客戶端保存 Cookie。當(dāng)下次客戶端再往服務(wù)器發(fā)送請求時，客戶端會自動在請求報(bào)文中加入 Cookie 值發(fā)送出去。服務(wù)器端收到客戶端發(fā)來的 Cookie 后，會去檢查究竟是哪一個客戶端發(fā)來的連接請求，然后對比服務(wù)器上的記錄，最后得到之前的狀態(tài)信息。
形象來說，在客戶端第一次請求后，服務(wù)器會下發(fā)一個裝有客戶信息的身份證，后續(xù)客戶端請求服務(wù)器的時候，帶上身份證，服務(wù)器就能認(rèn)得了。
下圖展示了發(fā)生 Cookie 交互的情景：
1）沒有 Cookie 信息狀態(tài)下的請求：
對應(yīng)的 HTTP 請求報(bào)文（沒有 Cookie 信息的狀態(tài)）
GET /reader/ HTTP/1.1
Host: baidu.com
* 首部字段沒有 Cookie 的相關(guān)信息
對應(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 次以后的請求（存有 Cookie 信息狀態(tài)）
對應(yīng)的 HTTP 請求報(bào)文（自動發(fā)送保存著的 Cookie 信息）
GET /image/ HTTP/1.1
Host: baidu.com
Cookie: sid=1342077140226
所謂斷點(diǎn)續(xù)傳指的是下載傳輸文件可以中斷，之后重新下載時可以接著中斷的地方開始下載，而不必從頭開始下載。斷點(diǎn)續(xù)傳需要客戶端和服務(wù)端都支持。
這是一個非常常見的功能，原理很簡單，其實(shí)就是 HTTP 請求頭中的字段 Range 和響應(yīng)頭中的字段 Content-Range 的簡單使用。客戶端一塊一塊的請求數(shù)據(jù)，最后將下載回來的數(shù)據(jù)塊拼接成完整的數(shù)據(jù)。打個比方，瀏覽器請求服務(wù)器上的一個服務(wù)，所發(fā)出的請求如下：
假設(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ù)器收到請求后，按要求尋找請求的文件，提取文件的信息，然后返回給瀏覽器，返回信息如下：
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ù)傳，客戶端瀏覽器請求服務(wù)器的時候要多加一條信息 — 從哪里開始請求數(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ì)看一下就會發(fā)現(xiàn)多了一行 RANGE: bytes=2000070-。這一行的意思就是告訴服務(wù)器 down.zip 這個文件從 2000070 字節(jié)開始傳，前面的字節(jié)不用傳了。
服務(wù)器收到這個請求以后，返回的信息如下：
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ù)器返回的信息比較一下，就會發(fā)現(xiàn)增加了一行： Content-Range=bytes 2000070-106786027/106786028。返回的代碼也改為 206 了，而不再是 200 了。
到現(xiàn)在為止，我們已經(jīng)了解到了 HTTP 具有相當(dāng)優(yōu)秀和方便的一面，然后，事務(wù)皆有兩面性，他也是有不足之處的：
通信使用明文（不加密），內(nèi)容可能被竊聽
不驗(yàn)證通信對方的身份，因此有可能遭遇偽裝
無法證明報(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ù)會單開一篇文章進(jìn)行講解。
以上就是詳細(xì)HTTP協(xié)議的前世今生的詳細(xì)內(nèi)容，更多關(guān)于HTTP協(xié)議的資料請關(guān)注腳本之家其它相關(guān)文章！
標(biāo)簽：襄陽 錫林郭勒盟 鄂爾多斯 莆田 哈爾濱 雙鴨山 遵義 丹東
巨人網(wǎng)絡(luò)通訊聲明：本文標(biāo)題《詳細(xì)HTTP協(xié)議的前世今生》，本文關(guān)鍵詞 詳細(xì),HTTP,協(xié)議,的,前世,；如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題，煩請?zhí)峁┫嚓P(guān)信息告之我們，我們將及時溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò)，涉及言論、版權(quán)與本站無關(guān)。
