| 類別 | 原因短語 | |
|---|---|---|
| 1xx | Informational 信息性狀態(tài)碼 | 接收的請求正在處理 |
| 2xx | Success 成功狀態(tài)碼 | 請求正常處理完畢 |
| 3xx | Redirection 重定向狀態(tài)碼 | 需要進(jìn)行附加操作以完成請求 |
| 4xx | Client Error 客戶端錯(cuò)誤狀態(tài)碼 | 服務(wù)器無法處理請求 |
| 5xx | Server Error 服務(wù)器錯(cuò)誤狀態(tài)碼 | 服務(wù)器處理請求出錯(cuò) |
2xx：請求正常處理完畢
200 OK：客戶端請求成功
204 No Content：無內(nèi)容。服務(wù)器成功處理，但未返回內(nèi)容。一般用在只是客戶端向服務(wù)器發(fā)送信息，而服務(wù)器不用向客戶端返回什么信息的情況。不會(huì)刷新頁面。
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：臨時(shí)重定向，表示請求的資源臨時(shí)搬到了其他位置303 See Other：臨時(shí)重定向，應(yīng)使用GET定向獲取請求資源。303功能與302一樣，區(qū)別只是303明確客戶端應(yīng)該使用GET訪問304 Not Modified：表示客戶端發(fā)送附帶條件的請求（GET方法請求報(bào)文中的IF…）時(shí)，條件不滿足。返回304時(shí)，不包含任何響應(yīng)主體。雖然304被劃分在3XX，但和重定向一毛錢關(guān)系都沒有307 Temporary Redirect：臨時(shí)重定向，和302有著相同含義。POST不會(huì)變成GET4xx：客戶端錯(cuò)誤
400 Bad Request：客戶端請求有語法錯(cuò)誤，服務(wù)器無法理解。401 Unauthorized：請求未經(jīng)授權(quán)，這個(gè)狀態(tài)代碼必須和 WWW-Authenticate 報(bào)頭域一起使用。403 Forbidden：服務(wù)器收到請求，但是拒絕提供服務(wù)404 Not Found：請求資源不存在。比如，輸入了錯(cuò)誤的 URL415 Unsupported media type：不支持的媒體類型5xx：服務(wù)器端錯(cuò)誤，服務(wù)器未能實(shí)現(xiàn)合法的請求。
500 Internal Server Error：服務(wù)器發(fā)生不可預(yù)期的錯(cuò)誤。503 Server Unavailable：服務(wù)器當(dāng)前處于超負(fù)載或正在停機(jī)維護(hù)，暫時(shí)不能處理客戶端的請求，一段時(shí)間后可能恢復(fù)正常HTTP 響應(yīng)頭
響應(yīng)頭也是用鍵值對 k：v，用于補(bǔ)充響應(yīng)的附加信息、服務(wù)器信息，以及對客戶端的附加要求等。
這里著重說明一下 Location 這個(gè)字段，可以將響應(yīng)接收方引導(dǎo)至與某個(gè) URI 位置不同的資源。通常來說，該字段會(huì)配合 3xx:Redirection 的響應(yīng)，提供重定向的 URI。
① 短連接（非持久連接）
在 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 請求都要重新建立一次連接。由于 HTTP 是基于 TCP/IP 協(xié)議的，所以連接的每一次建立或者斷開都需要 TCP 三次握手或者 TCP 四次揮手的開銷。
顯然，這種方式存在巨大的弊端。比如訪問一個(gè)包含多張圖片的 HTML 頁面，每請求一張圖片資源就會(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 請求是按順序發(fā)出的，下一個(gè)請求只有在當(dāng)前請求收到響應(yīng)之后才會(huì)被發(fā)出。由于受到網(wǎng)絡(luò)延遲和帶寬的限制，在下一個(gè)請求被發(fā)送到服務(wù)器之前，可能需要等待很長時(shí)間。
持久連接使得多數(shù)請求以流水線（管線化 pipeline）方式發(fā)送成為可能，即在同一條持久連接上連續(xù)發(fā)出請求，而不用等待響應(yīng)返回后再發(fā)送，這樣就可以做到同時(shí)并行發(fā)送多個(gè)請求，而不需要一個(gè)接一個(gè)地等待響應(yīng)了。
HTTP 協(xié)議是無狀態(tài)協(xié)議。也就是說他不對之前發(fā)生過的請求和響應(yīng)的狀態(tài)進(jìn)行管理，即無法根據(jù)之前的狀態(tài)進(jìn)行本次的請求處理。
這樣就會(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 通過在請求和響應(yīng)報(bào)文中寫入 Cookie 信息來控制客戶端的狀態(tài)。具體來說，Cookie 會(huì)根據(jù)從服務(wù)器端發(fā)送的響應(yīng)報(bào)文中的一個(gè)叫作 Set-Cookie 的首部字段信息，通知客戶端保存 Cookie。當(dāng)下次客戶端再往服務(wù)器發(fā)送請求時(shí)，客戶端會(huì)自動(dòng)在請求報(bào)文中加入 Cookie 值發(fā)送出去。服務(wù)器端收到客戶端發(fā)來的 Cookie 后，會(huì)去檢查究竟是哪一個(gè)客戶端發(fā)來的連接請求，然后對比服務(wù)器上的記錄，最后得到之前的狀態(tài)信息。
形象來說，在客戶端第一次請求后，服務(wù)器會(huì)下發(fā)一個(gè)裝有客戶信息的身份證，后續(xù)客戶端請求服務(wù)器的時(shí)候，帶上身份證，服務(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)文（自動(dòng)發(fā)送保存著的 Cookie 信息）
GET /image/ HTTP/1.1
Host: baidu.com
Cookie: sid=1342077140226
所謂斷點(diǎn)續(xù)傳指的是下載傳輸文件可以中斷，之后重新下載時(shí)可以接著中斷的地方開始下載，而不必從頭開始下載。斷點(diǎn)續(xù)傳需要客戶端和服務(wù)端都支持。
這是一個(gè)非常常見的功能，原理很簡單，其實(shí)就是 HTTP 請求頭中的字段 Range 和響應(yīng)頭中的字段 Content-Range 的簡單使用。客戶端一塊一塊的請求數(shù)據(jù)，最后將下載回來的數(shù)據(jù)塊拼接成完整的數(shù)據(jù)。打個(gè)比方，瀏覽器請求服務(wù)器上的一個(gè)服務(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í)候要多加一條信息 — 從哪里開始請求數(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è)請求以后，返回的信息如下：
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 了。
到現(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ù)會(huì)單開一篇文章進(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)信息告之我們，我們將及時(shí)溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò)，涉及言論、版權(quán)與本站無關(guān)。