HTTP協(xié)議入門

原文地址
HTTP 協(xié)議是互聯(lián)網(wǎng)的基礎(chǔ)協(xié)議逃贝，也是網(wǎng)頁開發(fā)的必備知識，最新版本 HTTP/2 更是讓它成為技術(shù)熱點。

本文介紹 HTTP 協(xié)議的歷史演變和設(shè)計思路渣锦。


一、HTTP/0.9

HTTP 是基于 TCP/IP 協(xié)議的應用層協(xié)議浓体。它不涉及數(shù)據(jù)包（packet）傳輸泡挺，主要規(guī)定了客戶端和服務器之間的通信格式，默認使用80端口命浴。

最早版本是1991年發(fā)布的0.9版娄猫。該版本極其簡單，只有一個命令GET生闲。

GET /index.html

上面命令表示媳溺，TCP 連接（connection）建立后，客戶端向服務器請求（request）網(wǎng)頁index.html碍讯。

協(xié)議規(guī)定悬蔽，服務器只能回應HTML格式的字符串，不能回應別的格式捉兴。

<html>
  <body>Hello World</body>
</html>

服務器發(fā)送完畢蝎困，就關(guān)閉TCP連接。

二倍啥、HTTP/1.0

2.1 簡介
1996年5月禾乘，HTTP/1.0 版本發(fā)布，內(nèi)容大大增加虽缕。

首先始藕，任何格式的內(nèi)容都可以發(fā)送。這使得互聯(lián)網(wǎng)不僅可以傳輸文字，還能傳輸圖像伍派、視頻江耀、二進制文件。這為互聯(lián)網(wǎng)的大發(fā)展奠定了基礎(chǔ)诉植。

其次祥国，除了GET命令，還引入了POST命令和HEAD命令倍踪，豐富了瀏覽器與服務器的互動手段系宫。

再次，HTTP請求和回應的格式也變了建车。除了數(shù)據(jù)部分扩借，每次通信都必須包括頭信息（HTTP header），用來描述一些元數(shù)據(jù)缤至。

其他的新增功能還包括狀態(tài)碼（status code）潮罪、多字符集支持、多部分發(fā)送（multi-part type）领斥、權(quán)限（authorization）嫉到、緩存（cache）、內(nèi)容編碼（content encoding）等月洛。

2.2 請求格式
下面是一個1.0版的HTTP請求的例子何恶。

GET / HTTP/1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)
Accept: */*

可以看到，這個格式與0.9版有很大變化嚼黔。

第一行是請求命令细层，必須在尾部添加協(xié)議版本（HTTP/1.0）。后面就是多行頭信息唬涧，描述客戶端的情況疫赎。

2.3回應格式
服務器的回應如下。

HTTP/1.0 200 OK 
Content-Type: text/plain
Content-Length: 137582
Expires: Thu, 05 Dec 1997 16:00:00 GMT
Last-Modified: Wed, 5 August 1996 15:55:28 GMT
Server: Apache 0.84

<html>
  <body>Hello World</body>
</html>

回應的格式是"頭信息 + 一個空行（\r\n） + 數(shù)據(jù)"碎节。其中捧搞，第一行是"協(xié)議版本 + 狀態(tài)碼（status code） + 狀態(tài)描述"。

2.4Content-Type 字段
關(guān)于字符的編碼狮荔，1.0版規(guī)定胎撇，頭信息必須是 ASCII 碼，后面的數(shù)據(jù)可以是任何格式殖氏。因此创坞，服務器回應的時候，必須告訴客戶端受葛，數(shù)據(jù)是什么格式，這就是Content-Type字段的作用。

下面是一些常見的Content-Type字段的值总滩。

  • text/plain
  • text/html
  • text/css
  • image/jpeg
  • image/png
  • image/svg+xml
  • audio/mp4
  • video/mp4
  • application/javascript
  • application/pdf
  • application/zip
  • application/atom+xml

這些數(shù)據(jù)類型總稱為MIME type纲堵，每個值包括一級類型和二級類型，之間用斜杠分隔闰渔。
除了預定義的類型席函，廠商也可以自定義類型。

application/vnd.debian.binary-package

上面的類型表明冈涧，發(fā)送的是Debian系統(tǒng)的二進制數(shù)據(jù)包茂附。
MIME type還可以在尾部使用分號，添加參數(shù)督弓。

Content-Type: text/html; charset=utf-8

上面的類型表明营曼，發(fā)送的是網(wǎng)頁，而且編碼是UTF-8愚隧。

客戶端請求的時候蒂阱，可以使用Accept字段聲明自己可以接受哪些數(shù)據(jù)格式。

Accept: */*

上面代碼中狂塘，客戶端聲明自己可以接受任何格式的數(shù)據(jù)录煤。

MIME type不僅用在HTTP協(xié)議，還可以用在其他地方荞胡，比如HTML網(wǎng)頁妈踊。

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<!-- 等同于 -->
<meta charset="utf-8" />

2.5 Content-Encoding 字段
由于發(fā)送的數(shù)據(jù)可以是任何格式，因此可以把數(shù)據(jù)壓縮后再發(fā)送泪漂。Content-Encoding字段說明數(shù)據(jù)的壓縮方法廊营。

Content-Encoding: gzip
Content-Encoding: compress
Content-Encoding: deflate

客戶端在請求時，用Accept-Encoding字段說明自己可以接受哪些壓縮方法窖梁。

Accept-Encoding: gzip, deflate

2.6缺點
HTTP/1.0 版的主要缺點是赘风，每個TCP連接只能發(fā)送一個請求。發(fā)送數(shù)據(jù)完畢纵刘，連接就關(guān)閉邀窃，如果還要請求其他資源，就必須再新建一個連接假哎。

TCP連接的新建成本很高瞬捕，因為需要客戶端和服務器三次握手，并且開始時發(fā)送速率較慢（slow start）舵抹。所以肪虎，HTTP 1.0版本的性能比較差。隨著網(wǎng)頁加載的外部資源越來越多惧蛹，這個問題就愈發(fā)突出了扇救。

為了解決這個問題刑枝，有些瀏覽器在請求時，用了一個非標準的Connection字段迅腔。

Connection: keep-alive

這個字段要求服務器不要關(guān)閉TCP連接装畅，以便其他請求復用。服務器同樣回應這個字段沧烈。

Connection: keep-alive

一個可以復用的TCP連接就建立了掠兄，直到客戶端或服務器主動關(guān)閉連接。但是锌雀，這不是標準字段蚂夕，不同實現(xiàn)的行為可能不一致，因此不是根本的解決辦法腋逆。

三婿牍、HTTP/1.1

1997年1月，HTTP/1.1 版本發(fā)布，只比 1.0 版本晚了半年。它進一步完善了 HTTP 協(xié)議革砸，一直用到了20年后的今天期奔，直到現(xiàn)在還是最流行的版本。
3.1 持久連接
1.1 版的最大變化，就是引入了持久連接（persistent connection），即TCP連接默認不關(guān)閉，可以被多個請求復用露该，不用聲明Connection: keep-alive。

客戶端和服務器發(fā)現(xiàn)對方一段時間沒有活動第煮，就可以主動關(guān)閉連接解幼。不過，規(guī)范的做法是包警，客戶端在最后一個請求時撵摆，發(fā)送Connection: close，明確要求服務器關(guān)閉TCP連接害晦。

Connection: close

目前特铝，對于同一個域名，大多數(shù)瀏覽器允許同時建立6個持久連接壹瘟。
3.2 管道機制
1.1 版還引入了管道機制（pipelining）鲫剿，即在同一個TCP連接里面，客戶端可以同時發(fā)送多個請求稻轨。這樣就進一步改進了HTTP協(xié)議的效率灵莲。

舉例來說，客戶端需要請求兩個資源殴俱。以前的做法是政冻，在同一個TCP連接里面枚抵，先發(fā)送A請求，然后等待服務器做出回應赠幕，收到后再發(fā)出B請求俄精。管道機制則是允許瀏覽器同時發(fā)出A請求和B請求，但是服務器還是按照順序榕堰，先回應A請求，完成后再回應B請求嫌套。
3.3 Content-Length 字段
一個TCP連接現(xiàn)在可以傳送多個回應逆屡，勢必就要有一種機制，區(qū)分數(shù)據(jù)包是屬于哪一個回應的踱讨。這就是Content-length字段的作用魏蔗，聲明本次回應的數(shù)據(jù)長度。

Content-Length: 3495

上面代碼告訴瀏覽器痹筛，本次回應的長度是3495個字節(jié)莺治，后面的字節(jié)就屬于下一個回應了。
在1.0版中帚稠，Content-Length字段不是必需的谣旁，因為瀏覽器發(fā)現(xiàn)服務器關(guān)閉了TCP連接，就表明收到的數(shù)據(jù)包已經(jīng)全了滋早。
3.4分塊傳輸編碼
使用Content-Length字段的前提條件是榄审，服務器發(fā)送回應之前，必須知道回應的數(shù)據(jù)長度杆麸。

對于一些很耗時的動態(tài)操作來說搁进，這意味著，服務器要等到所有操作完成昔头，才能發(fā)送數(shù)據(jù)饼问，顯然這樣的效率不高。更好的處理方法是揭斧，產(chǎn)生一塊數(shù)據(jù)莱革，就發(fā)送一塊，采用"流模式"（stream）取代"緩存模式"（buffer）未蝌。

因此驮吱，1.1版規(guī)定可以不使用Content-Length字段，而使用"分塊傳輸編碼"（chunked transfer encoding）萧吠。只要請求或回應的頭信息有Transfer-Encoding字段左冬，就表明回應將由數(shù)量未定的數(shù)據(jù)塊組成。

Transfer-Encoding: chunked

每個非空的數(shù)據(jù)塊之前纸型，會有一個16進制的數(shù)值拇砰，表示這個塊的長度梅忌。最后是一個大小為0的塊，就表示本次回應的數(shù)據(jù)發(fā)送完了除破。下面是一個例子牧氮。

HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked

25
This is the data in the first chunk

1C
and this is the second one

3
con

8
sequence

0

3.5 其他功能
1.1版還新增了許多動詞方法：PUT、PATCH瑰枫、HEAD踱葛、 OPTIONS、DELETE光坝。
另外尸诽，客戶端請求的頭信息新增了Host字段，用來指定服務器的域名盯另。

Host: www.example.com

有了Host字段性含，就可以將請求發(fā)往同一臺服務器上的不同網(wǎng)站，為虛擬主機的興起打下了基礎(chǔ)鸳惯。
3.6 缺點
雖然1.1版允許復用TCP連接商蕴，但是同一個TCP連接里面，所有的數(shù)據(jù)通信是按次序進行的芝发。服務器只有處理完一個回應绪商，才會進行下一個回應。要是前面的回應特別慢后德，后面就會有許多請求排隊等著部宿。這稱為"隊頭堵塞"（Head-of-line blocking）。

為了避免這個問題瓢湃，只有兩種方法：一是減少請求數(shù)理张，二是同時多開持久連接。這導致了很多的網(wǎng)頁優(yōu)化技巧绵患，比如合并腳本和樣式表雾叭、將圖片嵌入CSS代碼、域名分片（domain sharding）等等落蝙。如果HTTP協(xié)議設(shè)計得更好一些织狐，這些額外的工作是可以避免的。

四筏勒、SPDY 協(xié)議

2009年移迫，谷歌公開了自行研發(fā)的 SPDY 協(xié)議，主要解決 HTTP/1.1 效率不高的問題管行。
這個協(xié)議在Chrome瀏覽器上證明可行以后厨埋，就被當作 HTTP/2 的基礎(chǔ)，主要特性都在 HTTP/2 之中得到繼承捐顷。

五荡陷、HTTP/2

2015年雨效，HTTP/2 發(fā)布。它不叫 HTTP/2.0废赞，是因為標準委員會不打算再發(fā)布子版本了徽龟，下一個新版本將是 HTTP/3。

5.1 二進制協(xié)議
HTTP/1.1 版的頭信息肯定是文本（ASCII編碼）唉地，數(shù)據(jù)體可以是文本据悔，也可以是二進制。HTTP/2 則是一個徹底的二進制協(xié)議渣蜗，頭信息和數(shù)據(jù)體都是二進制屠尊，并且統(tǒng)稱為"幀"（frame）：頭信息幀和數(shù)據(jù)幀。

二進制協(xié)議的一個好處是耕拷，可以定義額外的幀。HTTP/2 定義了近十種幀托享，為將來的高級應用打好了基礎(chǔ)骚烧。如果使用文本實現(xiàn)這種功能，解析數(shù)據(jù)將會變得非常麻煩闰围，二進制解析則方便得多赃绊。
5.2 多工
HTTP/2 復用TCP連接，在一個連接里羡榴，客戶端和瀏覽器都可以同時發(fā)送多個請求或回應碧查，而且不用按照順序一一對應，這樣就避免了"隊頭堵塞"校仑。

舉例來說忠售，在一個TCP連接里面，服務器同時收到了A請求和B請求迄沫，于是先回應A請求稻扬，結(jié)果發(fā)現(xiàn)處理過程非常耗時，于是就發(fā)送A請求已經(jīng)處理好的部分羊瘩， 接著回應B請求泰佳，完成后，再發(fā)送A請求剩下的部分尘吗。

這樣雙向的逝她、實時的通信，就叫做多工（Multiplexing）睬捶。

5.3數(shù)據(jù)流
因為 HTTP/2 的數(shù)據(jù)包是不按順序發(fā)送的黔宛，同一個連接里面連續(xù)的數(shù)據(jù)包，可能屬于不同的回應侧戴。因此宁昭，必須要對數(shù)據(jù)包做標記跌宛，指出它屬于哪個回應。

HTTP/2 將每個請求或回應的所有數(shù)據(jù)包积仗，稱為一個數(shù)據(jù)流（stream）疆拘。每個數(shù)據(jù)流都有一個獨一無二的編號。數(shù)據(jù)包發(fā)送的時候寂曹，都必須標記數(shù)據(jù)流ID哎迄，用來區(qū)分它屬于哪個數(shù)據(jù)流。另外還規(guī)定隆圆，客戶端發(fā)出的數(shù)據(jù)流漱挚，ID一律為奇數(shù)，服務器發(fā)出的渺氧，ID為偶數(shù)旨涝。

數(shù)據(jù)流發(fā)送到一半的時候，客戶端和服務器都可以發(fā)送信號（RST_STREAM幀）侣背，取消這個數(shù)據(jù)流白华。1.1版取消數(shù)據(jù)流的唯一方法，就是關(guān)閉TCP連接贩耐。這就是說弧腥，HTTP/2 可以取消某一次請求，同時保證TCP連接還打開著潮太，可以被其他請求使用

客戶端還可以指定數(shù)據(jù)流的優(yōu)先級管搪。優(yōu)先級越高，服務器就會越早回應铡买。

5.4 頭信息壓縮
HTTP 協(xié)議不帶有狀態(tài)更鲁，每次請求都必須附上所有信息。所以寻狂，請求的很多字段都是重復的岁经，比如Cookie和User Agent，一模一樣的內(nèi)容蛇券，每次請求都必須附帶缀壤，這會浪費很多帶寬，也影響速度纠亚。

HTTP/2 對這一點做了優(yōu)化塘慕，引入了頭信息壓縮機制（header compression）。一方面蒂胞，頭信息使用gzip或compress壓縮后再發(fā)送图呢；另一方面，客戶端和服務器同時維護一張頭信息表，所有字段都會存入這個表蛤织，生成一個索引號赴叹，以后就不發(fā)送同樣字段了，只發(fā)送索引號指蚜，這樣就提高速度了乞巧。

5.5 服務器推送
HTTP/2 允許服務器未經(jīng)請求，主動向客戶端發(fā)送資源摊鸡，這叫做服務器推送（server push）绽媒。

常見場景是客戶端請求一個網(wǎng)頁，這個網(wǎng)頁里面包含很多靜態(tài)資源免猾。正常情況下是辕，客戶端必須收到網(wǎng)頁后，解析HTML源碼猎提，發(fā)現(xiàn)有靜態(tài)資源获三，再發(fā)出靜態(tài)資源請求。其實锨苏，服務器可以預期到客戶端請求網(wǎng)頁后石窑，很可能會再請求靜態(tài)資源，所以就主動把這些靜態(tài)資源隨著網(wǎng)頁一起發(fā)給客戶端了蚓炬。

HTTP1.0 HTTP 1.1主要區(qū)別

長連接
HTTP 1.0需要使用keep-alive參數(shù)來告知服務器端要建立一個長連接，而HTTP1.1默認支持長連接躺屁。

HTTP是基于TCP/IP協(xié)議的肯夏，創(chuàng)建一個TCP連接是需要經(jīng)過三次握手的,有一定的開銷，如果每次通訊都要重新建立連接的話犀暑，對性能有影響驯击。因此最好能維持一個長連接，可以用個長連接來發(fā)多個請求耐亏。

節(jié)約帶寬
HTTP 1.1支持只發(fā)送header信息(不帶任何body信息)徊都，如果服務器認為客戶端有權(quán)限請求服務器，則返回100广辰，否則返回401暇矫。客戶端如果接受到100择吊，才開始把請求body發(fā)送到服務器李根。

這樣當服務器返回401的時候，客戶端就可以不用發(fā)送請求body了几睛，節(jié)約了帶寬房轿。

另外HTTP還支持傳送內(nèi)容的一部分。這樣當客戶端已經(jīng)有一部分的資源后，只需要跟服務器請求另外的部分資源即可囱持。這是支持文件斷點續(xù)傳的基礎(chǔ)夯接。

HOST域
現(xiàn)在的web server例如tomat，設(shè)置虛擬站點是非常常見的纷妆，也即是說盔几，web server上的多個虛擬站點可以共享同一個ip和端口。
HTTP1.0是沒有host域的凭需，HTTP1.1才支持這個參數(shù)问欠。

HTTP1.1 HTTP 2.0主要區(qū)別

多路復用
HTTP2.0使用了多路復用的技術(shù)，做到同一個連接并發(fā)處理多個請求粒蜈，而且并發(fā)請求的數(shù)量比HTTP1.1大了好幾個數(shù)量級顺献。

當然HTTP1.1也可以多建立幾個TCP連接，來支持處理更多并發(fā)的請求枯怖，但是創(chuàng)建TCP連接本身也是有開銷的注整。

TCP連接有一個預熱和保護的過程，先檢查數(shù)據(jù)是否傳送成功度硝，一旦成功過肿轨，則慢慢加大傳輸速度。因此對應瞬時并發(fā)的連接蕊程，服務器的響應就會變慢椒袍。所以最好能使用一個建立好的連接，并且這個連接可以支持瞬時并發(fā)的請求藻茂。
數(shù)據(jù)壓縮
HTTP1.1不支持header數(shù)據(jù)的壓縮驹暑，HTTP2.0使用HPACK算法對header的數(shù)據(jù)進行壓縮，這樣數(shù)據(jù)體積小了辨赐，在網(wǎng)絡上傳輸就會更快优俘。

服務器推送
意思是說，當我們對支持HTTP2.0的web server請求數(shù)據(jù)的時候掀序，服務器會順便把一些客戶端需要的資源一起推送到客戶端帆焕，免得客戶端再次創(chuàng)建連接發(fā)送請求到服務器端獲取。這種方式非常合適加載靜態(tài)資源不恭。

服務器端推送的這些資源其實存在客戶端的某處地方叶雹，客戶端直接從本地加載這些資源就可以了，不用走網(wǎng)絡县袱，速度自然是快很多的浑娜。

HTTP請求分析

HTTP請求報文

HTTP請求由狀態(tài)行（請求行）、請求頭（首部行）式散、請求正文三部分組成：

  • 狀態(tài)行：包括請求方式Method筋遭、資源路徑URL、http協(xié)議版本Version；
  • 請求頭：包括一些訪問的域名漓滔、用戶代理编饺、Cookie等信息；
  • 請求正文：就是HTTP請求的數(shù)據(jù)响驴。

HTTP中的請求方法：
OPTIONS:返回服務器針對特定資源所支持的HTTP請求方法透且，也可以利用向web服務器發(fā)送‘*’的請求來測試服務器的功能性
HEAD:類似于get請求，只不過返回的響應中沒有具體的內(nèi)容豁鲤，用于獲取報頭秽誊；
GET:向特定的資源發(fā)出請求。它本質(zhì)就是發(fā)送一個請求來取得服務器上的某一資源琳骡。資源通過一組HTTP頭和呈現(xiàn)數(shù)據(jù)（如HTML文本锅论，或者圖片或者視頻等）返回給客戶端。GET請求中楣号，永遠不會包含呈現(xiàn)數(shù)據(jù)最易。
POST:向指定資源提交數(shù)據(jù)進行處理請求（例如提交表單或者上傳文件）。數(shù)據(jù)被包含在請求體中炫狱。POST請求可能會導致新的資源的建立和/或已有資源的修改藻懒。
PUT:向指定資源位置上傳其最新內(nèi)容
DELETE:請求服務器刪除Request-URL所標識的資源
TRACE:回顯服務器收到的請求，主要用于測試或診斷
CONNECT:HTTP/1.1協(xié)議中預留給能夠?qū)⑦B接改為管道方式的代理服務器视译。

現(xiàn)在大多數(shù)協(xié)議版本為http/1.1,下圖所示就是GET的請求嬉荆，沒有請求正文。GET方式僅僅為獲取服務器資源酷含，方式較為簡單员寇，因此在請求方式為GET的HTTP請求數(shù)據(jù)中，請求正文部分可以省略第美，直接將想要獲取的資源添加到URL中。


下圖所示為POST請求的格式陆爽，有狀態(tài)行什往、請求頭、請求正文三部分慌闭。

補充：常見請求頭字段

Header 解釋 示例
Accept 指定客戶端能夠接收的內(nèi)容類型 Accept: text/plain, text/html
Accept-Charset 瀏覽器可以接受的字符編碼集别威。 Accept-Charset: iso-8859-5
Accept-Encoding 指定瀏覽器可以支持的web服務器返回內(nèi)容壓縮編碼類型。 Accept-Encoding: compress, gzip
Accept-Language 瀏覽器可接受的語言 Accept-Language: en,zh
Cache-Control 指定請求和響應遵循的緩存機制 Cache-Control: no-cache
Connection 表示是否需要持久連接驴剔。（HTTP 1.1默認進行持久連接） Connection: close
Cookie HTTP請求發(fā)送時省古，會把保存在該請求域名下的所有cookie值一起發(fā)送給web服務器。 Cookie: $Version=1; Skin=new;
Content-Length 請求的內(nèi)容長度 Content-Length: 348
Content-Type 請求的與實體對應的MIME信息 Content-Type: application/x-www-form-urlencoded
Host 指定請求的服務器的域名和端口號 Host: www.zcmhi.com
User-Agent User-Agent的內(nèi)容包含發(fā)出請求的用戶信息 User-Agent: Mozilla/5.0 (Linux; X11)

二丧失、HTTP響應

2.1HTTP響應報文

2.2響應數(shù)據(jù)格式
服務器收到了客戶端發(fā)來的HTTP請求后豺妓，根據(jù)HTTP請求中的動作要求，服務端做出具體的動作，將結(jié)果回應給客戶端琳拭，稱為HTTP響應训堆。
HTTP響應由三部分組成：狀態(tài)行、響應頭白嘁、響應正文坑鱼；

  • 狀態(tài)行：包括協(xié)議版本Version、狀態(tài)碼Status Code絮缅、回應短語鲁沥；
  • 響應頭：包括搭建服務器的軟件，發(fā)送響應的時間耕魄，回應數(shù)據(jù)的格式等信息画恰；
  • 響應正文：就是響應的具體數(shù)據(jù)。
    備注：我們主要關(guān)心并且能夠在客戶端瀏覽器看得到的是三位數(shù)的狀態(tài)碼屎开，不同的狀態(tài)碼代表不同的含義阐枣，其中

    具體HTTP響應實例如下圖：

    2.2 常見狀態(tài)碼的含義
  • 200---OK/請求已經(jīng)正常處理完畢
  • 204 No Content 該狀態(tài)碼表示服務器接收的請求已成功處理，但在返回的響應報文中不含實體的主體部分奄抽。比如蔼两，當從瀏覽器發(fā)出請求處理后，返回204響應逞度，那么瀏覽器顯示的頁面不發(fā)生更新额划。
  • 301---Moved Permanently/請求永久重定向
  • 302---Found/請求臨時重定向
  • 304---Not Modified/請求被重定向到客戶端本地緩存
  • 400---Bad Request/客戶端請求存在語法錯誤
  • 401---Unauthorized/客戶端請求沒有經(jīng)過授權(quán)
  • 403---Forbidden/客戶端的請求被服務器拒絕，一般為客戶端沒有訪問權(quán)限
  • 404---Not Found/客戶端請求的URL在服務端不存在
  • 500---Internal Server Error/服務端永久錯誤
  • 503---Service Unavailable/服務端發(fā)生臨時錯誤

補充：常見響應頭字段

Header 解釋 示例
Cache-Control 告訴所有的緩存機制是否可以緩存及哪種類型 Cache-Control: no-cache
Content-Encoding web服務器支持的返回內(nèi)容壓縮編碼類型档泽。 Content-Encoding: gzip
Content-Language 響應體的語言 Content-Language: en,zh
Content-Length 響應體的長度 Content-Length: 348
Content-Location 請求資源可替代的備用的另一地址 Content-Location: /index.htm
Content-MD5 返回資源的MD5校驗值 Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==
Content-Range 在整個返回體中本部分的字節(jié)位置 Content-Range: bytes 21010-47021/47022
Date 原始服務器消息發(fā)出的時間 Date: Tue, 15 Nov 2010 08:12:31 GMT
Expires 響應過期的日期和時間 Expires: Thu, 01 Dec 2010 16:00:00 GMT
Last-Modified 請求資源的最后修改時間 Last-Modified: Tue, 15 Nov 2010 12:45:26 GMT
Location 用來重定向接收方到非請求URL的位置來完成請求或標識新的資源 Location: http://www.zcmhi.com/archives/94.html
refresh 應用于重定向或一個新的資源被創(chuàng)造俊戳，在5秒之后重定向（由網(wǎng)景提出，被大部分瀏覽器支持） Refresh: 5; url=http://www.zcmhi.com/archives/94.html
Server web服務器軟件名稱 Server: Apache/1.3.27 (Unix) (Red-Hat/Linux)
Set-Cookie 設(shè)置Http Cookie Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1
Transfer-Encoding 文件傳輸編碼 Transfer-Encoding:chunked
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 人面猴
    序言：七十年代末馆匿，一起剝皮案震驚了整個濱河市抑胎，隨后出現(xiàn)的幾起案子，更是在濱河造成了極大的恐慌渐北，老刑警劉巖阿逃，帶你破解...
    沈念sama閱讀 206,968評論 6贊 482
  • 死咒
    序言：濱河連續(xù)發(fā)生了三起死亡事件，死亡現(xiàn)場離奇詭異赃蛛，居然都是意外死亡恃锉，警方通過查閱死者的電腦和手機，發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 88,601評論 2贊 382
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進店門呕臂，熙熙樓的掌柜王于貴愁眉苦臉地迎上來破托，“玉大人，你說我怎么就攤上這事歧蒋⊥辽埃” “怎么了州既？”我有些...
    開封第一講書人閱讀 153,220評論 0贊 344
  • 道士緝兇錄：失蹤的賣姜人
    文/不壞的土叔 我叫張陵，是天一觀的道長瘟芝。 經(jīng)常有香客問我易桃，道長，這世上最難降的妖魔是什么锌俱？ 我笑而不...
    開封第一講書人閱讀 55,416評論 1贊 279
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任晤郑，我火速辦了婚禮，結(jié)果婚禮上贸宏，老公的妹妹穿的比我還像新娘造寝。我一直安慰自己，他們只是感情好吭练，可當我...
    茶點故事閱讀 64,425評論 5贊 374
  • 惡毒庶女頂嫁案：這布局不是一般人想出來的
    文/花漫 我一把揭開白布诫龙。 她就那樣靜靜地躺著，像睡著了一般鲫咽。 火紅的嫁衣襯著肌膚如雪签赃。 梳的紋絲不亂的頭發(fā)上，一...
    開封第一講書人閱讀 49,144評論 1贊 285
  • 城市分裂傳說
    那天分尸，我揣著相機與錄音锦聊，去河邊找鬼。 笑死箩绍，一個胖子當著我的面吹牛孔庭，可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播材蛛，決...
    沈念sama閱讀 38,432評論 3贊 401
  • 雙鴛鴦連環(huán)套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開眼圆到，長吁一口氣：“原來是場噩夢啊……” “哼！你這毒婦竟也來了卑吭？” 一聲冷哼從身側(cè)響起芽淡，我...
    開封第一講書人閱讀 37,088評論 0贊 261
  • 萬榮殺人案實錄
    序言：老撾萬榮一對情侶失蹤，失蹤者是張志新（化名）和其女友劉穎豆赏，沒想到半個月后吐绵，有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體，經(jīng)...
    沈念sama閱讀 43,586評論 1贊 300
  • ?護林員之死
    正文 獨居荒郊野嶺守林人離奇死亡河绽，尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 36,028評論 2贊 325
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年，在試婚紗的時候發(fā)現(xiàn)自己被綠了唉窃。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片耙饰。...
    茶點故事閱讀 38,137評論 1贊 334
  • 活死人
    序言：一個原本活蹦亂跳的男人離奇死亡，死狀恐怖纹份，靈堂內(nèi)的尸體忽然破棺而出苟跪，到底是詐尸還是另有隱情廷痘，我是刑警寧澤，帶...
    沈念sama閱讀 33,783評論 4贊 324
  • ?日本核電站爆炸內(nèi)幕
    正文 年R本政府宣布件已，位于F島的核電站笋额，受9級特大地震影響，放射性物質(zhì)發(fā)生泄漏篷扩。R本人自食惡果不足惜兄猩，卻給世界環(huán)境...
    茶點故事閱讀 39,343評論 3贊 307
  • 男人毒藥：我在死后第九天來索命
    文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望鉴未。 院中可真熱鬧枢冤，春花似錦、人聲如沸铜秆。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,333評論 0贊 19
  • 一樁弒父案，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽连茧。三九已至核蘸，卻和暖如春，著一層夾襖步出監(jiān)牢的瞬間啸驯，已是汗流浹背客扎。 一陣腳步聲響...
    開封第一講書人閱讀 31,559評論 1贊 262
  • 情欲美人皮
    我被黑心中介騙來泰國打工， 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留坯汤，地道東北人虐唠。 一個月前我還...
    沈念sama閱讀 45,595評論 2贊 355
  • 代替公主和親
    正文 我出身青樓，卻偏偏與公主長得像惰聂，于是被迫代替她去往敵國和親疆偿。 傳聞我的和親對象是個殘疾皇子，可洞房花燭夜當晚...
    茶點故事閱讀 42,901評論 2贊 345

推薦閱讀更多精彩內(nèi)容