HTTP 1.0篱昔、HTTP1.1主要區(qū)別

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

http是基于TCP/IP協(xié)議創(chuàng)建的tcp連接，需要進行三次握手，每一次通訊都需要重新建立連接，對性能有影響和泌，需要一定的開銷，因此最好維持一個長連接祠肥，可以利用長連接發(fā)送多個請求武氓。

HTTP1.1只支持發(fā)送header信息，服務(wù)器有權(quán)限返回100，否則返回401县恕，返回100东羹，才把請求body發(fā)送到服務(wù)器（401狀態(tài)碼：請求要求身份驗證。 對于需要登錄的網(wǎng)頁弱睦，服務(wù)器可能返回此響應(yīng)）百姓，如果返回401渊额，就不用發(fā)送請求body了况木，解約帶寬。

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

web server 上的多個虛擬站點可以共享同一個ip和端口（例如tomat） http1.0是沒有host域的奔垦，http1.1才支持這個參數(shù)屹耐。

HTTP 1.1、HTTP2.0主要區(qū)別? （減少帶寬椿猎、傳輸快惶岭，請求快）

多路復(fù)用

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

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

? ? ? ? ? ?TCP連接有一個預(yù)熱和保護的過程，先檢查數(shù)據(jù)是否傳送成功量蕊，一旦成功過铺罢，則慢慢加大傳輸速度。因此對應(yīng)瞬時并發(fā)的連接残炮，服務(wù)器的響應(yīng)就會變慢韭赘。所以最好能使用一個建立好的連接，并且這個連接可以支持瞬時并發(fā)的請求势就。

數(shù)據(jù)壓縮

? ? ? ?HTTP1.1不支持header數(shù)據(jù)的壓縮辞居，HTTP2.0使用HPACK算法對header的數(shù)據(jù)進行壓縮，這樣數(shù)據(jù)體積小了蛋勺，在網(wǎng)絡(luò)上傳輸就會更快

服務(wù)器推送

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

? ? ? ?服務(wù)器端推送的這些資源其實存在客戶端的某處地方，客戶端直接從本地加載這些資源就可以了，不用走網(wǎng)絡(luò)碉怔，速度自然是快很多的烘贴。

?服務(wù)端推送過來的資源，會統(tǒng)一放在一個網(wǎng)絡(luò)與http緩存之間的一個地方撮胧，在這里可以理解為“本地”桨踪。當客戶端把index.html解析完以后，會向本地請求這個資源芹啥。由于資源已經(jīng)本地化锻离，所以這個請求的速度非常快墓怀，這也是服務(wù)端推送性能優(yōu)勢的體現(xiàn)之一汽纠。

HTTP狀態(tài)碼?

1XX系列：指定客戶端應(yīng)相應(yīng)的某些動作，代表請求已被接受傀履，需要繼續(xù)處理虱朵。由于 HTTP/1.0 協(xié)議中沒有定義任何 1xx 狀態(tài)碼，所以除非在某些試驗條件下钓账，服務(wù)器禁止向此類客戶端發(fā)送 1xx 響應(yīng)碴犬。

2XX系列：代表請求已成功被服務(wù)器接收、理解梆暮、并接受服协。這系列中最常見的有200、201狀態(tài)碼惕蹄。

200狀態(tài)碼：表示請求已成功蚯涮，請求所希望的響應(yīng)頭或數(shù)據(jù)體將隨此響應(yīng)返回

201狀態(tài)碼：表示請求成功并且服務(wù)器創(chuàng)建了新的資源，且其 URI 已經(jīng)隨Location 頭信息返回卖陵。假如需要的資源無法及時建立的話遭顶，應(yīng)當返回 ‘202 Accepted’

202狀態(tài)碼：服務(wù)器已接受請求，但尚未處理

3XX系列：代表需要客戶端采取進一步的操作才能完成請求泪蔫，這些狀態(tài)碼用來重定向棒旗，后續(xù)的請求地址（重定向目標）在本次響應(yīng)的 Location 域中指明。這系列中最常見的有301撩荣、302狀態(tài)碼铣揉。

301狀態(tài)碼：被請求的資源已永久移動到新位置。服務(wù)器返回此響應(yīng)（對 GET 或 HEAD 請求的響應(yīng)）時餐曹，會自動將請求者轉(zhuǎn)到新位置逛拱。301永久永久永久

302狀態(tài)碼：請求的資源臨時從不同的URI響應(yīng)請求，但請求者應(yīng)繼續(xù)使用原有位置來進行以后的請求

304狀態(tài)碼:自從上次請求后台猴，請求的網(wǎng)頁未修改過朽合。服務(wù)器返回此響應(yīng)時俱两，不會返回網(wǎng)頁內(nèi)容。 如果網(wǎng)頁自請求者上次請求后再也沒有更改過曹步，您應(yīng)將服務(wù)器配置為返回此響應(yīng)(稱為 If-Modified-Since HTTP 標頭)宪彩。

4XX系列：表示請求錯誤。代表了客戶端看起來可能發(fā)生了錯誤讲婚，妨礙了服務(wù)器的處理尿孔。常見有：401、404狀態(tài)碼筹麸。

401狀態(tài)碼：請求要求身份驗證活合。 對于需要登錄的網(wǎng)頁，服務(wù)器可能返回此響應(yīng)竹捉。

403狀態(tài)碼：服務(wù)器已經(jīng)理解請求芜辕，但是拒絕執(zhí)行它尚骄。與401響應(yīng)不同的是块差，身份驗證并不能提供任何幫助，而且這個請求也不應(yīng)該被重復(fù)提交倔丈。

404狀態(tài)碼：請求失敗憨闰，請求所希望得到的資源未被在服務(wù)器上發(fā)現(xiàn)。沒有信息能夠告訴用戶這個狀況到底是暫時的還是永久的需五。假如服務(wù)器知道情況的話鹉动，應(yīng)當使用410狀態(tài)碼來告知舊資源因為某些內(nèi)部的配置機制問題，已經(jīng)永久的不可用宏邮，而且沒有任何可以跳轉(zhuǎn)的地址泽示。404這個狀態(tài)碼被廣泛應(yīng)用于當服務(wù)器不想揭示到底為何請求被拒絕或者沒有其他適合的響應(yīng)可用的情況下。

5xx系列：代表了服務(wù)器在處理請求的過程中有錯誤或者異常狀態(tài)發(fā)生蜜氨，也有可能是服務(wù)器意識到以當前的軟硬件資源無法完成對請求的處理械筛。常見有500、503狀態(tài)碼飒炎。

500狀態(tài)碼：服務(wù)器遇到了一個未曾預(yù)料的狀況埋哟，導(dǎo)致了它無法完成對請求的處理。一般來說郎汪，這個問題都會在服務(wù)器的程序碼出錯時出現(xiàn)赤赊。

502和504的區(qū)別

502 bad gateway 顧名思義 網(wǎng)關(guān)錯誤 后端服務(wù)器tomcat沒有起來，應(yīng)用服務(wù)的問題（前提是接入層7層正常的情況下）煞赢。

應(yīng)用服務(wù)問題一種是應(yīng)用本身問題抛计；另一種是因為依賴服務(wù)問題比如依賴服務(wù)RT高，依賴的服務(wù)有大的讀日罩（mysql慢查吹截，http等）录豺，以至于調(diào)用方超過超時read時間；服務(wù)集群壓力大時饭弓，也會出現(xiàn)502超時（502理解為不可響應(yīng)或響應(yīng)不過來双饥，其實還是不可響應(yīng)）。

504 gateway time-out 顧名思義 網(wǎng)關(guān)超時 一般計算機中的超時就是配置錯了弟断，此處一般指nginx做反向代理服務(wù)器時咏花，所連接的服務(wù)器tomcat無響應(yīng)導(dǎo)致的。

503狀態(tài)碼：由于臨時的服務(wù)器維護或者過載阀趴，服務(wù)器當前無法處理請求昏翰。通常，這個是暫時狀態(tài)刘急，一段時間會恢復(fù)

Header 解釋 示例

Accept 指定客戶端能夠接收的內(nèi)容類型 Accept: text/plain, text/html,application/json

Accept-Charset 瀏覽器可以接受的字符編碼集棚菊。 Accept-Charset: iso-8859-5

Accept-Encoding 指定瀏覽器可以支持的web服務(wù)器返回內(nèi)容壓縮編碼類型。 Accept-Encoding: compress, gzip

Accept-Language 瀏覽器可接受的語言 Accept-Language: en,zh

Accept-Ranges 可以請求網(wǎng)頁實體的一個或者多個子范圍字段 Accept-Ranges: bytes

Authorization HTTP授權(quán)的授權(quán)證書 Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Cache-Control 指定請求和響應(yīng)遵循的緩存機制 Cache-Control: no-cache

Connection 表示是否需要持久連接叔汁。keep-alive（HTTP 1.1默認進行持久連接） Connection: close（1.0）

Cookie HTTP請求發(fā)送時统求，會把保存在該請求域名下的所有cookie值一起發(fā)送給web服務(wù)器。 Cookie: $Version=1; Skin=new;

Content-Length 請求的內(nèi)容長度 Content-Length: 348

Content-Type 請求的與實體對應(yīng)的MIME信息 Content-Type: application/x-www-form-urlencoded

Date 請求發(fā)送的日期和時間 Date: Tue, 15 Nov 2010 08:12:31 GMT

Expect 請求的特定的服務(wù)器行為 Expect: 100-continue

From 發(fā)出請求的用戶的Email From: user@email.com

Host 指定請求的服務(wù)器的域名和端口號 Host: www.zcmhi.com

If-Match 只有請求內(nèi)容與實體相匹配才有效 If-Match: “737060cd8c284d8af7ad3082f209582d”

If-Modified-Since 如果請求的部分在指定時間之后被修改則請求成功据块，未被修改則返回304代碼 If-Modified-Since: Sat, 29 Oct 2010 19:43:31 GMT

If-None-Match 如果內(nèi)容未改變返回304代碼码邻，參數(shù)為服務(wù)器先前發(fā)送的Etag，與服務(wù)器回應(yīng)的Etag比較判斷是否改變 If-None-Match: “737060cd8c284d8af7ad3082f209582d”

If-Range 如果實體未改變另假，服務(wù)器發(fā)送客戶端丟失的部分像屋，否則發(fā)送整個實體。參數(shù)也為Etag If-Range: “737060cd8c284d8af7ad3082f209582d”

If-Unmodified-Since 只在實體在指定時間之后未被修改才請求成功 If-Unmodified-Since: Sat, 29 Oct 2010 19:43:31 GMT

Max-Forwards 限制信息通過代理和網(wǎng)關(guān)傳送的時間 Max-Forwards: 10

Pragma 用來包含實現(xiàn)特定的指令 Pragma: no-cache

Proxy-Authorization 連接到代理的授權(quán)證書 Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Range 只請求實體的一部分边篮，指定范圍 Range: bytes=500-999

Referer 先前網(wǎng)頁的地址己莺，當前請求網(wǎng)頁緊隨其后,即來路 Referer:?http://www.zcmhi.com/archives...

TE 客戶端愿意接受的傳輸編碼，并通知服務(wù)器接受接受尾加頭信息 TE: trailers,deflate;q=0.5

Upgrade 向服務(wù)器指定某種傳輸協(xié)議以便服務(wù)器進行轉(zhuǎn)換（如果支持） Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

User-Agent User-Agent的內(nèi)容包含發(fā)出請求的用戶信息 User-Agent: Mozilla/5.0 (Linux; X11)

Via 通知中間網(wǎng)關(guān)或代理服務(wù)器地址戈轿，通信協(xié)議 Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)

Warning 關(guān)于消息實體的警告信息 Warn: 199 Miscellaneous warning

————————————————