? ? http協(xié)議有http0.9，http1.0，http1.1和http2三個(gè)版本，但是現(xiàn)在瀏覽器使用的是http1.1的標(biāo)準(zhǔn)，本篇文章著重介紹關(guān)于http1.1的版本，同時(shí)穿插了解一下http2的一些新特性。

一 介紹

? ? 介紹不多說(shuō)，HTTP是Hyper Text Transfer Protocol（超文本協(xié)議），是一個(gè)基于TCP/IP的應(yīng)用層協(xié)議，主要用于從web服務(wù)器傳輸超文本到本地的瀏覽器的一個(gè)傳輸協(xié)議，由請(qǐng)求和響應(yīng)構(gòu)成，是一個(gè)標(biāo)準(zhǔn)的客戶端服務(wù)器模型。

? ? 這里簡(jiǎn)要的介紹下http和https的區(qū)別：https協(xié)議是一個(gè)承載在SSL+TLS上，基于http和ssl構(gòu)建的，其與http最大的區(qū)別就是其的安全性，而且其使用的是不一樣的連接方式，用的端口也不一樣（443，http是80），另外由于其確保安全性，那么https就需要進(jìn)行與服務(wù)器的還密鑰和確認(rèn)加密算法的需要，這樣的話跟服務(wù)器進(jìn)行握手的次數(shù)就增多，影響性能且繁瑣。

二 http的主要特點(diǎn)

1 支持客戶端/服務(wù)器模式

2 簡(jiǎn)單快速：客戶端向服務(wù)器請(qǐng)求服務(wù)的適合，只需要傳輸方法和路徑。請(qǐng)求的常用方法有GET、HEAD、POST。由于每一種http協(xié)議都簡(jiǎn)單，使得http服務(wù)器的程序規(guī)模小，則通信速度很快

3 靈活：http允許傳輸任意類型的數(shù)據(jù)對(duì)象，正在傳輸?shù)念愋陀烧?qǐng)求頭部的Content-Type加以標(biāo)注

4 HTTP 0.9和1.0使用非持續(xù)連接：限制每次連接只處理一個(gè)請(qǐng)求，服務(wù)器處理完客戶的請(qǐng)求，并收到客戶的應(yīng)答后，即斷開(kāi)連接。采用這種方式可以節(jié)省傳輸時(shí)間。HTTP 1.1使用持續(xù)連接：不必為每個(gè)web對(duì)象創(chuàng)建一個(gè)新的連接，一個(gè)連接可以傳送多個(gè)對(duì)象（這個(gè)關(guān)聯(lián)到頭部信息的Connection進(jìn)行控制）

5 http是無(wú)狀態(tài)協(xié)議。無(wú)狀態(tài)指的是對(duì)于事物處理沒(méi)有記憶能力，缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大。

（無(wú)狀態(tài)協(xié)議：協(xié)議的狀態(tài)是指下一次傳輸可以“記住”這次傳輸信息的能力。http不會(huì)為了下一次連接維護(hù)這次連接所傳輸?shù)男畔⒌模瑸榱吮ＷC服務(wù)器的內(nèi)存。

舉例：比如客戶獲得一張網(wǎng)頁(yè)之后關(guān)閉瀏覽器，然后再一次啟動(dòng)瀏覽器，再登陸該網(wǎng)站，但是服務(wù)器并不知道客戶關(guān)閉了一次瀏覽器。由于Web服務(wù)器要面對(duì)很多瀏覽器的并發(fā)訪問(wèn)，為了提高Web服務(wù)器對(duì)并發(fā)訪問(wèn)的處理能力，在設(shè)計(jì)HTTP協(xié)議時(shí)規(guī)定Web服務(wù)器發(fā)送HTTP應(yīng)答報(bào)文和文檔時(shí)，不保存發(fā)出請(qǐng)求的Web瀏覽器進(jìn)程的任何狀態(tài)信息。這有可能出現(xiàn)一個(gè)瀏覽器在短短幾秒之內(nèi)兩次訪問(wèn)同一對(duì)象時(shí)，服務(wù)器進(jìn)程不會(huì)因?yàn)橐呀?jīng)給它發(fā)過(guò)應(yīng)答報(bào)文而不接受第二期服務(wù)請(qǐng)求。由于Web服務(wù)器不保存發(fā)送請(qǐng)求的Web瀏覽器進(jìn)程的任何信息，因此HTTP協(xié)議屬于無(wú)狀態(tài)協(xié)議（Stateless Protocol）

）

HTTP協(xié)議是無(wú)狀態(tài)的和Connection: keep-alive的區(qū)別：

HTTP是一個(gè)無(wú)狀態(tài)的面向連接的協(xié)議，無(wú)狀態(tài)不代表HTTP不能保持TCP連接，更不能代表HTTP使用的是UDP協(xié)議（無(wú)連接）。

從HTTP/1.1起，默認(rèn)都開(kāi)啟了Keep-Alive，保持連接特性，簡(jiǎn)單地說(shuō)，當(dāng)一個(gè)網(wǎng)頁(yè)打開(kāi)完成后，客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的TCP連接不會(huì)關(guān)閉，如果客戶端再次訪問(wèn)這個(gè)服務(wù)器上的網(wǎng)頁(yè)，會(huì)繼續(xù)使用這一條已經(jīng)建立的連接。

Keep-Alive不會(huì)永久保持連接，它有一個(gè)保持時(shí)間，可以在不同的服務(wù)器軟件（如Apache）中設(shè)定這個(gè)時(shí)間。

1.1 版還引入了管道機(jī)制（pipelining），即在同一個(gè)TCP連接里面，客戶端可以同時(shí)發(fā)送多個(gè)請(qǐng)求。這樣就進(jìn)一步改進(jìn)了HTTP協(xié)議的效率。

舉例來(lái)說(shuō)，客戶端需要請(qǐng)求兩個(gè)資源。以前的做法是，在同一個(gè)TCP連接里面，先發(fā)送A請(qǐng)求，然后等待服務(wù)器做出回應(yīng)，收到后再發(fā)出B請(qǐng)求。管道機(jī)制則是允許瀏覽器同時(shí)發(fā)出A請(qǐng)求和B請(qǐng)求，但是服務(wù)器還是按照順序，先回應(yīng)A請(qǐng)求，完成后再回應(yīng)B請(qǐng)求。

三 工作流程

一次http操作稱之為一次事物，工作過(guò)程可分為四步：

1）首先客戶機(jī)與服務(wù)器需要建立連接。只要點(diǎn)擊某個(gè)超鏈接，HTTP工作開(kāi)始（建立連接）

2）之后，客戶機(jī)發(fā)送請(qǐng)求給服務(wù)器，請(qǐng)求方式的格式為：統(tǒng)一資源標(biāo)識(shí)符（URL）、協(xié)議版本號(hào)、后邊是MIME信息包括請(qǐng)求修飾符、客戶機(jī)信息和可能的內(nèi)容。（發(fā)送請(qǐng)求）

3）服務(wù)器接收到請(qǐng)求之后，給予相應(yīng)的響應(yīng)信息，其格式為一個(gè)狀態(tài)行，包括信息的協(xié)議版本號(hào)、后邊是MIME信息包括請(qǐng)求修飾符、客戶機(jī)信息和可能的內(nèi)容。（響應(yīng)請(qǐng)求）

4）客戶端接收服務(wù)器所返回的信息通過(guò)瀏覽器顯示在用戶的顯示屏上，然后客戶機(jī)與服務(wù)器斷開(kāi)連接（斷開(kāi)連接）

上述過(guò)程有可能是客戶機(jī)經(jīng)過(guò)了代理服務(wù)器才到達(dá)的web服務(wù)器的

由于HTTP是基于傳輸層的TCP/IP協(xié)議的，TCP是一個(gè)端到端的面向連接的協(xié)議。所謂的端到端可以理解為進(jìn)程到進(jìn)程之間的通信，故HTTP在開(kāi)始傳輸之前需建立TCP連接，TCP連接的過(guò)程需要所謂的“三次握手”，如圖。連接之后就可以進(jìn)行傳輸了，HTTP在傳輸完成之間不會(huì)斷開(kāi)TCP連接，在HTTP1.1中（通過(guò)Connection頭設(shè)置）這是默認(rèn)的行為

四 URL詳解

URL：統(tǒng)一資源定位符，是URI（統(tǒng)一資源標(biāo)識(shí)符）的一種，用于描述一個(gè)網(wǎng)絡(luò)上的資源， 基本格式如下：schema://host[:port#]/path/.../[;url-params][?query-string][#anchor]

scheme 指定低層使用的協(xié)議(例如：http, https, ftp)

host HTTP服務(wù)器的IP地址或者域名

“：”后的是端口，默認(rèn)是80

path：是訪問(wèn)資源的路徑

“；”后面的是url-params：URL參數(shù)，可以用作一個(gè)緩存的標(biāo)識(shí)（session id）

query-string：發(fā)送給http服務(wù)器的數(shù)據(jù)，也可以說(shuō)是查詢參數(shù)，用&符號(hào)分隔

“#”后面的是錨

五 請(qǐng)求消息

5.1 請(qǐng)求的消息格式如下：

1）請(qǐng)求行，如GET /images/logo.gif HTTP/1.1，表示從/images目錄下請(qǐng)求logo.gif這個(gè)文件，使用的是get方法，協(xié)議版本是http1.1

2）請(qǐng)求頭，如Accept-Language: en

3）空行

4）可選的消息體

請(qǐng)求行和標(biāo)題必須以回車換行作為結(jié)尾，空行中必定只有回車換行

5.2 請(qǐng)求方法

前面三個(gè)是http0.9和http1.0協(xié)議就已經(jīng)有的，后面五個(gè)是http1.1之后加的

GET：向特定的資源發(fā)送請(qǐng)求

POST：向指定資源提交數(shù)據(jù)進(jìn)行處理請(qǐng)求（例如提交表單或者上傳文件）。數(shù)據(jù)包含在請(qǐng)求中，POST請(qǐng)求可能會(huì)導(dǎo)致新的資源建立和/或者已有資源的修改

HEAD：向服務(wù)器索要與GET請(qǐng)求相一致的響應(yīng)，但是響應(yīng)體不會(huì)被返回。這一方法可以在不必傳輸整個(gè)響應(yīng)內(nèi)容的情況下，就可以獲取包含在響應(yīng)消息頭中的元信息。該方法常用于測(cè)試超鏈接的有效性，是否可以訪問(wèn)，以及最近是否更新（那么主要 用于響應(yīng)頭信息的獲?。?/p>

PUT：向制定資源位置上傳其最新的內(nèi)容

OPTIONS：返回服務(wù)器針對(duì)特定資源所支持的HTTP請(qǐng)求方法。

DELETE：請(qǐng)求服務(wù)器刪除Request-URI所標(biāo)識(shí)的資源

TRACE：回顯服務(wù)器收到的請(qǐng)求，用于測(cè)試或診斷

CONNECT：http1.1協(xié)議種預(yù)留給能夠?qū)⑦B接改為管道方式的代理服務(wù)器

PATCH：用來(lái)將局部修改應(yīng)用于某一資源，添加于規(guī)范RFC5789。

總結(jié)就是：GET方法用于在服務(wù)器中獲取數(shù)據(jù)，POST方法是在服務(wù)器中修改資源數(shù)據(jù)，PUT是用于上傳數(shù)據(jù)，DELETE是在服務(wù)器中刪除資源，HEAD是獲取響應(yīng)頭信息

GET和POST的區(qū)別：

1）提交的數(shù)據(jù)位置不同，GET是在URL之后，而POST是在HTTP包的body中

2）GET提交的數(shù)據(jù)大小有限制，最多有1024字節(jié)，主要是瀏覽器對(duì)URL的長(zhǎng)度有限制，POST提交的數(shù)據(jù)沒(méi)有限制

3）POST較GET安全，因?yàn)镚ET會(huì)將一些信息暴露在URL上，對(duì)于提交的數(shù)據(jù)都會(huì)顯示在URL上，若頁(yè)面可以緩存或者其他人可以訪問(wèn)，則可從歷史記錄獲取這個(gè)用戶賬號(hào)密碼什么的資料

4）GET方式需要使用Request.QueryString來(lái)取得變量的值，而POST方式通過(guò)Request.Form來(lái)獲取變量的值。

六 響應(yīng)消息

客戶端向服務(wù)器發(fā)送一個(gè)請(qǐng)求，服務(wù)器以一個(gè)狀態(tài)行作為響應(yīng)，響應(yīng)的內(nèi)容包括：消息協(xié)議的版本、成功或者錯(cuò)誤編碼、服務(wù)器信息、實(shí)體元信息以及必要的實(shí)體內(nèi)容。根據(jù)響應(yīng)類別的類別，服務(wù)器響應(yīng)里可以含實(shí)體內(nèi)容，但不是所有的響應(yīng)都有實(shí)體內(nèi)容。

格式：

http協(xié)議版本? 空格? 狀態(tài)碼? 空格 Reason-Phrase 回車換行（Reason-Phrase是個(gè)簡(jiǎn)單的文本描述），如

七 http的狀態(tài)響應(yīng)碼

1XX（信息類）： 表示接收到請(qǐng)求并繼續(xù)處理

2XX（響應(yīng)成功）：表示動(dòng)作被成功接收，理解和接收

關(guān)注200：表明該請(qǐng)求被成功地完成，所請(qǐng)求的資源發(fā)送回客戶端

3XX（重定向）：為了完成指定的動(dòng)作，必須接受進(jìn)一步處理

關(guān)注304：自從上次請(qǐng)求后，請(qǐng)求的網(wǎng)頁(yè)未修改過(guò)，服務(wù)器返回此響應(yīng)時(shí)，不會(huì)返回網(wǎng)頁(yè)內(nèi)容，代表上次的文檔已經(jīng)被緩存了，還可以繼續(xù)使用

4XX（客戶端錯(cuò)誤類）：請(qǐng)求包含錯(cuò)誤語(yǔ)法或不能正確執(zhí)行

關(guān)注404：一個(gè)404錯(cuò)誤表明可連接服務(wù)器，但服務(wù)器無(wú)法取得所請(qǐng)求的網(wǎng)頁(yè)，請(qǐng)求資源不存在。eg：輸入了錯(cuò)誤的URL

5XX（服務(wù)器端錯(cuò)誤類）：服務(wù)器不能正確執(zhí)行一個(gè)正確的請(qǐng)求

八 頭部信息

8.1? HTTP常見(jiàn)的請(qǐng)求頭

If-Modified-Since：把瀏覽器端緩存頁(yè)面的最后修改時(shí)間發(fā)送到服務(wù)器去，服務(wù)器會(huì)把這個(gè)時(shí)間與服務(wù)器上實(shí)際文件的最后修改時(shí)間進(jìn)行對(duì)比。如果時(shí)間一致，那么返回304，客戶端就直接使用本地緩存文件。如果時(shí)間不一致，就會(huì)返回200和新的文件內(nèi)容?？蛻舳私拥街?，會(huì)丟棄舊文件，把新文件緩存起來(lái)，并顯示在瀏覽器中。（這與對(duì)比緩存有關(guān)，后文會(huì)講到，相對(duì)的是響應(yīng)頭的Last-Modified）

If-None-Match：If-None-Match和ETag一起工作，工作原理是在HTTP響應(yīng)頭中添加ETag信息。 當(dāng)用戶再次請(qǐng)求該資源時(shí)，將在HTTP請(qǐng)求頭中加入If-None-Match信息(ETag的值)。如果服務(wù)器驗(yàn)證資源的ETag沒(méi)有改變（該資源沒(méi)有更新），將返回一個(gè)304狀態(tài)告訴客戶端使用本地緩存文件。否則將返回200狀態(tài)和新的資源和Etag（這也與對(duì)比緩存有關(guān)，且優(yōu)先級(jí)高于上面的If-Modified-Since/Last-Modified對(duì)）

Cache-Control：指定請(qǐng)求和響應(yīng)遵循的緩存機(jī)制。緩存指令是單向的（響應(yīng)中出現(xiàn)的緩存指令在請(qǐng)求中未必會(huì)出現(xiàn)），且是獨(dú)立的（在請(qǐng)求消息或響應(yīng)消息中設(shè)置Cache-Control并不會(huì)修改另一個(gè)消息處理過(guò)程中的緩存處理過(guò)程）。請(qǐng)求時(shí)的緩存指令包括no-cache、no-store、max-age、max-stale、min-fresh、only-if-cached，響應(yīng)消息中的指令包括public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age、s-maxage。（請(qǐng)求頭和響應(yīng)頭中都有，關(guān)于強(qiáng)制緩存的）

Cache-Control:Public 客戶端和服務(wù)器都可緩存

Cache-Control:Private 客戶端可緩存

Cache-Control:no-cache 需要使用對(duì)比緩存來(lái)驗(yàn)證緩存數(shù)據(jù)

Cache-Control:no-store 所有內(nèi)容都不會(huì)緩存，強(qiáng)制緩存，對(duì)比緩存都不會(huì)觸發(fā)

Cache-Control:max-age 緩存的內(nèi)容將在 xxx 秒后失效。

Cache-Control:min-fresh 指示客戶機(jī)可以接收響應(yīng)時(shí)間小于當(dāng)前時(shí)間加上指定時(shí)間的響應(yīng)。

Cache-Control:max-stale 指示客戶機(jī)可以接收超出超時(shí)期間的響應(yīng)消息。如果指定max-stale消息的值，那么客戶機(jī)可以接收超出超時(shí)期指定值之內(nèi)的響應(yīng)消息。

Accept：瀏覽器端可以接受的MIME類型。例如：Accept: text/html 代表瀏覽器可以接受服務(wù)器回發(fā)的類型為 text/html 也就是我們常說(shuō)的html文檔

Accept-Encoding：瀏覽器申明自己可接收的編碼方法，通常指定壓縮方法，是否支持壓縮，支持什么壓縮方法（gzip，deflate）

Accept-Language：瀏覽器申明自己接收的語(yǔ)言。語(yǔ)言跟字符集的區(qū)別：中文是語(yǔ)言，中文有多種字符集，比如big5，gb2312，gbk等等

Accept-Charset：瀏覽器可接受的字符集

User-Agent：告訴HTTP服務(wù)器，客戶端使用的操作系統(tǒng)和瀏覽器的名稱和版本

Content-Type：例如：Content-Type: application/x-www-form-urlencoded。

Connection：例如：

Connection: keep-alive 當(dāng)一個(gè)網(wǎng)頁(yè)打開(kāi)完成后，客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的TCP連接不會(huì)關(guān)閉，如果客戶端再次訪問(wèn)這個(gè)服務(wù)器上的網(wǎng)頁(yè)，會(huì)繼續(xù)使用這一條已經(jīng)建立的連接。HTTP 1.1默認(rèn)進(jìn)行持久連接。利用持久連接的優(yōu)點(diǎn)，當(dāng)頁(yè)面包含多個(gè)元素時(shí)（例如Applet，圖片），顯著地減少下載所需要的時(shí)間。要實(shí)現(xiàn)這一點(diǎn)，Servlet需要在應(yīng)答中發(fā)送一個(gè)Content-Length頭，最簡(jiǎn)單的實(shí)現(xiàn)方法是：先把內(nèi)容寫(xiě)入ByteArrayOutputStream，然后在正式寫(xiě)出內(nèi)容之前計(jì)算它的大小。

Connection: close 代表一個(gè)Request完成后，客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的TCP連接會(huì)關(guān)閉，當(dāng)客戶端再次發(fā)送Request，需要重新建立TCP連接。

Referer：包含一個(gè)URL，用戶從該URL代表的頁(yè)面出發(fā)訪問(wèn)當(dāng)前請(qǐng)求的頁(yè)面

Host：（發(fā)送請(qǐng)求時(shí)，該頭域是必需的）主要用于指定被請(qǐng)求資源的Internet主機(jī)和端口號(hào)，它通常從HTTP URL中提取出來(lái)的（http1.1協(xié)議種必須包含）

例如: 我們?cè)跒g覽器中輸入：http://www.guet.edu.cn/index.html，瀏覽器發(fā)送的請(qǐng)求消息中，就會(huì)包含Host請(qǐng)求頭域：Host：http://www.guet.edu.cn，此處使用缺省端口號(hào)80，若指定了端口號(hào)，則變成：Host：指定端口號(hào)

Cookie：最重要的請(qǐng)求頭之一, 將cookie的值發(fā)送給HTTP服務(wù)器

Content-Length：表示請(qǐng)求消息正文的長(zhǎng)度

Authorization：授權(quán)信息

8.2? HTTP常見(jiàn)的響應(yīng)頭

Allow：服務(wù)器支持哪些請(qǐng)求方法（如GET、POST等）

Date：表示消息發(fā)送的時(shí)間，時(shí)間的描述格式由rfc822定義。

Expires：指明應(yīng)該在什么時(shí)候認(rèn)為文檔已經(jīng)過(guò)期，從而不再緩存它，重新從服務(wù)器獲取，會(huì)更新緩存

P3P：用于跨域設(shè)置Cookie, 這樣可以解決iframe跨域訪問(wèn)cookie的問(wèn)題

Set-Cookie：非常重要的header, 用于把cookie發(fā)送到客戶端瀏覽器，每一個(gè)寫(xiě)入cookie都會(huì)生成一個(gè)Set-Cookie。

例如: Set-Cookie: sc=4c31523a; path=/; domain=.acookie.taobao.com

ETag：和If-None-Match 配合使用。

Last-Modified：用于指示資源的最后修改日期和時(shí)間。Last-Modified也可用setDateHeader方法來(lái)設(shè)置。

Content-Type：WEB服務(wù)器告訴瀏覽器自己響應(yīng)的對(duì)象的類型和字符集，

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

Content-Length：指明實(shí)體正文的長(zhǎng)度，以字節(jié)方式存儲(chǔ)的十進(jìn)制數(shù)字來(lái)表示

Content-Encoding：WEB服務(wù)器表明自己使用了什么壓縮方法（gzip，deflate）壓縮響應(yīng)中的對(duì)象

Content-Range：用于指定整個(gè)實(shí)體中的一部分的插入位置，他也指示了整個(gè)實(shí)體的長(zhǎng)度

Content-Language：WEB服務(wù)器告訴瀏覽器自己響應(yīng)的對(duì)象所用的自然語(yǔ)言

Connection：

例如：Connection: keep-alive 當(dāng)一個(gè)網(wǎng)頁(yè)打開(kāi)完成后，客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的TCP連接不會(huì)關(guān)閉，如果客戶端再次訪問(wèn)這個(gè)服務(wù)器上的網(wǎng)頁(yè)，會(huì)繼續(xù)使用這一條已經(jīng)建立的連接。

Connection: close 代表一個(gè)Request完成后，客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的TCP連接會(huì)關(guān)閉，當(dāng)客戶端再次發(fā)送Request，需要重新建立TCP連接。

Location：用于重定向一個(gè)新的位置，包含新的URL地址

Refresh：表示瀏覽器應(yīng)該在多少時(shí)間之后刷新文檔，以秒計(jì)

摘抄于：http://www.cnblogs.com/EricaMIN1987_IT/p/3837436.html

九 HTTP緩存機(jī)制

WEB緩存(cache)位于Web服務(wù)器和客戶端之間。

緩存會(huì)根據(jù)請(qǐng)求保存輸出內(nèi)容的副本，例如html頁(yè)面，圖片，文件，當(dāng)下一個(gè)請(qǐng)求來(lái)到的時(shí)候：如果是相同的URL，緩存直接使用副本響應(yīng)訪問(wèn)請(qǐng)求，而不是向源服務(wù)器再次發(fā)送請(qǐng)求。

HTTP協(xié)議定義了相關(guān)的消息頭來(lái)使WEB緩存盡可能好的工作

9.1 緩存的優(yōu)點(diǎn)

減少相應(yīng)延遲：因?yàn)檎?qǐng)求從緩存服務(wù)器（離客戶端更近）而不是源服務(wù)器被相應(yīng)，這個(gè)過(guò)程耗時(shí)更少，讓web服務(wù)器看上去相應(yīng)更快。

減少網(wǎng)絡(luò)帶寬消耗：當(dāng)副本被重用時(shí)會(huì)減低客戶端的帶寬消耗；客戶可以節(jié)省帶寬費(fèi)用，控制帶寬的需求的增長(zhǎng)并更易于管理。

9.2 http報(bào)文中跟緩存有關(guān)的頭部字段

為了對(duì)以下能用到的一些頭部信息能有個(gè)大致了解，介紹以下與緩存有關(guān)的頭部字段

1. 通用首部字段（就是請(qǐng)求報(bào)文和響應(yīng)報(bào)文都能用上的字段）

2. 請(qǐng)求首部字段

3. 響應(yīng)首部字段

4. 實(shí)體首部字段

9.3 緩存方式

緩存實(shí)際上就是根據(jù)一些策略規(guī)則來(lái)決定是否使用瀏覽器中的一些存儲(chǔ)的信息，這個(gè)緩存信息可以認(rèn)為是瀏覽器中有存在的一個(gè)緩存數(shù)據(jù)庫(kù)（也可以稱為本地緩存）

根據(jù)是否需要重新向服務(wù)器發(fā)起請(qǐng)求來(lái)分類，可分為兩大類（強(qiáng)制緩存、對(duì)比緩存）

強(qiáng)制類型不需要向服務(wù)器發(fā)起請(qǐng)求，對(duì)比緩存需要向服務(wù)器發(fā)起請(qǐng)求

9.3.1 強(qiáng)制緩存

已經(jīng)具有緩存數(shù)據(jù)的時(shí)候，并且緩存時(shí)間未過(guò)期的話，使用強(qiáng)制緩存

http1.0的強(qiáng)制緩存是有兩個(gè)字段來(lái)進(jìn)行，Pragma（表示禁用緩存）和Expires（啟用緩存和定義緩存時(shí)間）。同時(shí)使用的話，Pragma優(yōu)先級(jí)會(huì)較高，但是響應(yīng)報(bào)文中Expires所定義的緩存時(shí)間是相對(duì)服務(wù)器上的時(shí)間而言的，如果客戶端上的時(shí)間跟服務(wù)器上的時(shí)間不一致（特別是用戶修改了自己電腦的系統(tǒng)時(shí)間），那緩存時(shí)間可能就沒(méi)啥意義了，為了解決這個(gè)問(wèn)題，http1.1使用的是新字段：Cache-Control（重點(diǎn)掌握，以此為基準(zhǔn)）

注意：為了做http協(xié)議的向下兼容，你還是可以看到很多網(wǎng)站依舊會(huì)帶上這兩個(gè)字段，實(shí)際上是可拋棄的兩個(gè)字段了

Cache-Control

使用方法： "Cache-Control":"cache-directive"

作為請(qǐng)求頭部的時(shí)候，cache-directive的可選值有

作為響應(yīng)首部時(shí)，cache-directive 的可選值有：

實(shí)際重點(diǎn)關(guān)注五個(gè)值private、public、no-cache、max-age，no-store，默認(rèn)為private

private:客戶端可以緩存

public:客戶端和代理服務(wù)器都可緩存（前端的同學(xué)，可以認(rèn)為public和private是一樣的）

max-age=xxx:緩存的內(nèi)容將在 xxx 秒后失效

no-cache:需要使用對(duì)比緩存來(lái)驗(yàn)證緩存數(shù)據(jù)

no-store:所有內(nèi)容都不會(huì)緩存，強(qiáng)制緩存，對(duì)比緩存都不會(huì)觸發(fā)

舉個(gè)例子：

圖中Cache-Control僅指定了max-age，所以默認(rèn)為private，緩存時(shí)間為31536000秒（365天）

也就是說(shuō)，在365天內(nèi)再次請(qǐng)求這條數(shù)據(jù)，都會(huì)直接獲取緩存數(shù)據(jù)庫(kù)中的數(shù)據(jù)，直接使用

9.3.2 對(duì)比緩存

對(duì)比緩存：即需要進(jìn)行比較判斷是否可以使用緩存。瀏覽器第一次請(qǐng)求數(shù)據(jù)時(shí)，服務(wù)器會(huì)將緩存標(biāo)識(shí)與數(shù)據(jù)一起返回給客戶端，客戶端將二者備份至緩存數(shù)據(jù)庫(kù)中。再次請(qǐng)求數(shù)據(jù)時(shí)，客戶端將備份的緩存標(biāo)識(shí)發(fā)送給服務(wù)器，服務(wù)器根據(jù)緩存標(biāo)識(shí)進(jìn)行判斷，判斷成功后，返回304狀態(tài)碼，通知客戶端比較成功，可以使用緩存數(shù)據(jù)

對(duì)比緩存解決的問(wèn)題：緩存時(shí)間過(guò)期，但是服務(wù)器卻沒(méi)有更新這個(gè)資源，此時(shí)客戶端再次請(qǐng)求服務(wù)器把這個(gè)資源重新發(fā)過(guò)來(lái)的話，很浪費(fèi)帶寬和時(shí)間。對(duì)比緩存就是讓服務(wù)器知道客戶端現(xiàn)在存有的緩存文件，其實(shí)跟自己所有的文件是一致的，讓客戶端直接使用自己緩存的即可，提高了緩存的復(fù)用率

對(duì)比緩存是根據(jù)請(qǐng)求頭部和響應(yīng)頭部的緩存標(biāo)識(shí)進(jìn)行判斷的

對(duì)比緩存使用的緩存標(biāo)識(shí)字段

Last-Modified? /? If-Modified-Since

Last-Modified：

服務(wù)器在響應(yīng)請(qǐng)求時(shí)，告訴瀏覽器資源的最后修改時(shí)間。

If-Modified-Since：

再次請(qǐng)求服務(wù)器時(shí)，通過(guò)此字段通知服務(wù)器上次請(qǐng)求時(shí)，服務(wù)器返回的資源最后修改時(shí)間。

服務(wù)器收到請(qǐng)求后發(fā)現(xiàn)有頭If-Modified-Since 則與被請(qǐng)求資源的最后修改時(shí)間進(jìn)行比對(duì)。

若資源的最后修改時(shí)間大于If-Modified-Since，說(shuō)明資源又被改動(dòng)過(guò)，則響應(yīng)整片資源內(nèi)容，返回狀態(tài)碼200；

若資源的最后修改時(shí)間小于或等于If-Modified-Since，說(shuō)明資源無(wú)新修改，則響應(yīng)HTTP 304，告知瀏覽器繼續(xù)使用所保存的cache。

Last-Modified 說(shuō)好卻也不是特別好，因?yàn)槿绻诜?wù)器上，一個(gè)資源被修改了，但其實(shí)際內(nèi)容根本沒(méi)發(fā)生改變，會(huì)因?yàn)長(zhǎng)ast-Modified時(shí)間匹配不上而返回了整個(gè)實(shí)體給客戶端（即使客戶端緩存里有個(gè)一模一樣的資源）

ETag / If-None-Match（優(yōu)先級(jí)高于Last-Modified? /? If-Modified-Since）

為了解決上述Last-Modified可能存在的不準(zhǔn)確的問(wèn)題，Http1.1還推出了 ETag 實(shí)體首部字段。

Etag可以理解成一個(gè)服務(wù)器用加密算法計(jì)算出來(lái)的唯一標(biāo)識(shí)符，用來(lái)標(biāo)識(shí)一個(gè)資源的，在客戶端第一次請(qǐng)求的時(shí)候服務(wù)器會(huì)隨著數(shù)據(jù)一起傳給客戶端，客戶端會(huì)保留該 ETag 字段，并在下一次請(qǐng)求時(shí)將其一并帶過(guò)去給服務(wù)器。服務(wù)器只需要比較客戶端傳來(lái)的ETag跟自己服務(wù)器上該資源的ETag是否一致，就能很好地判斷資源相對(duì)客戶端而言是否被修改過(guò)了

Etag：

服務(wù)器響應(yīng)請(qǐng)求時(shí)，告訴瀏覽器當(dāng)前資源在服務(wù)器的唯一標(biāo)識(shí)（生成規(guī)則由服務(wù)器決定）。

If-None-Match：

再次請(qǐng)求服務(wù)器時(shí)，通過(guò)此字段通知服務(wù)器客戶段緩存數(shù)據(jù)的唯一標(biāo)識(shí)。

服務(wù)器收到請(qǐng)求后發(fā)現(xiàn)有頭If-None-Match 則與被請(qǐng)求資源的唯一標(biāo)識(shí)進(jìn)行比對(duì)，

不同，說(shuō)明資源又被改動(dòng)過(guò)，則響應(yīng)整片資源內(nèi)容，返回狀態(tài)碼200；

相同，說(shuō)明資源無(wú)新修改，則響應(yīng)HTTP 304，告知瀏覽器繼續(xù)使用所保存的cache。

注意：如果同時(shí)存在兩對(duì)字段，需要都通過(guò)才能使用緩存

總結(jié)

對(duì)于強(qiáng)制緩存，服務(wù)器通知瀏覽器一個(gè)緩存時(shí)間，在緩存時(shí)間內(nèi)，下次請(qǐng)求，直接用緩存，不在時(shí)間內(nèi)，執(zhí)行比較緩存策略。

對(duì)于比較緩存，將緩存信息中的Etag和Last-Modified通過(guò)請(qǐng)求發(fā)送給服務(wù)器，由服務(wù)器校驗(yàn)，返回304狀態(tài)碼時(shí)，瀏覽器直接使用緩存。

瀏覽器第一次請(qǐng)求：

瀏覽器再次請(qǐng)求時(shí)：

摘抄于：http://www.cnblogs.com/vajoy/p/5341664.html、http://www.cnblogs.com/chenqf/p/6386163.html

十 解決HTTP無(wú)狀態(tài)的問(wèn)題

10.1 通過(guò)cookies保存狀態(tài)信息

cookies實(shí)際上是一個(gè)保存在客戶端上的，網(wǎng)站為了辨別用戶身份而儲(chǔ)存在用戶本地終端(Client Side)上的數(shù)據(jù)(通常經(jīng)過(guò)加密)，Cookie就是服務(wù)器暫存放在你的電腦里的資料（.txt格式的文本文件），通過(guò)在HTTP傳輸中的狀態(tài)好讓服務(wù)器用來(lái)辨認(rèn)你的計(jì)算機(jī)。當(dāng)你在瀏覽網(wǎng)站的時(shí)候，Web服務(wù)器會(huì)先送一小小資料放在你的計(jì)算機(jī)上，Cookie 會(huì)幫你在網(wǎng)站上所打的文字或是一些選擇都記錄下來(lái)。

通過(guò)Cookies，服務(wù)器就可以清楚的知道請(qǐng)求2和請(qǐng)求1來(lái)自同一個(gè)客戶端。

10.2 通過(guò)session保存狀態(tài)信息

Session機(jī)制是一種服務(wù)器端的機(jī)制，服務(wù)器使用一種類似于散列表的結(jié)構(gòu)（也可能就是使用散列表）來(lái)保存信息。

當(dāng)程序需要為某個(gè)客戶端的請(qǐng)求創(chuàng)建一個(gè)session的時(shí)候，服務(wù)器首先檢查這個(gè)客戶端的請(qǐng)求里是否已包含了一個(gè)session標(biāo)識(shí) - 稱為 session id，如果已包含一個(gè)session id則說(shuō)明以前已經(jīng)為此客戶端創(chuàng)建過(guò)session，服務(wù)器就按照session id把這個(gè) session檢索出來(lái)使用（如果檢索不到，可能會(huì)新建一個(gè)），如果客戶端請(qǐng)求不包含session id，則為此客戶端創(chuàng)建一個(gè)session并且生成一個(gè)與此session相關(guān)聯(lián)的session id，session id的值應(yīng)該是一個(gè)既不會(huì)重復(fù)，又不容易被找到規(guī)律以仿造的字符串，這個(gè)session id將被在本次響應(yīng)中返回給客戶端保存

Session的實(shí)現(xiàn)方式：

1、使用Cookie來(lái)實(shí)現(xiàn)

服務(wù)器給每個(gè)Session分配一個(gè)唯一的JSESSIONID，并通過(guò)Cookie發(fā)送給客戶端。

當(dāng)客戶端發(fā)起新的請(qǐng)求的時(shí)候，將在Cookie頭中攜帶這個(gè)JSESSIONID。這樣服務(wù)器能夠找到這個(gè)客戶端對(duì)應(yīng)的Session。

2、使用URL回寫(xiě)來(lái)實(shí)現(xiàn)

URL回寫(xiě)是指服務(wù)器在發(fā)送給瀏覽器頁(yè)面的所有鏈接中都攜帶JSESSIONID的參數(shù)，這樣客戶端點(diǎn)擊任何一個(gè)鏈接都會(huì)把JSESSIONID帶會(huì)服務(wù)器。如果直接在瀏覽器輸入服務(wù)端資源的url來(lái)請(qǐng)求該資源，那么Session是匹配不到的。

Tomcat對(duì)Session的實(shí)現(xiàn)，是一開(kāi)始同時(shí)使用Cookie和URL回寫(xiě)機(jī)制，如果發(fā)現(xiàn)客戶端支持Cookie，就繼續(xù)使用Cookie，停止使用URL回寫(xiě)。如果發(fā)現(xiàn)Cookie被禁用，就一直使用URL回寫(xiě)。jsp開(kāi)發(fā)處理到Session的時(shí)候，對(duì)頁(yè)面中的鏈接記得使用response.encodeURL() 。

10.3、通過(guò)表單變量保持狀態(tài)

除了Cookies之外，還可以使用表單變量來(lái)保持狀態(tài)，比如Asp.net就通過(guò)一個(gè)叫ViewState的Input=“hidden”的框來(lái)保持狀態(tài),比如:

這個(gè)原理和Cookies大同小異，只是每次請(qǐng)求和響應(yīng)所附帶的信息變成了表單變量。

10.4、通過(guò)QueryString保持狀態(tài)

QueryString通過(guò)將信息保存在所請(qǐng)求地址的末尾來(lái)向服務(wù)器傳送信息，通常和表單結(jié)合使用，一個(gè)典型的QueryString比如:www.xxx.com/xxx.aspx?var1=value&var2=value2

注意：這里說(shuō)一點(diǎn)自己的見(jiàn)解，保持狀態(tài)我感覺(jué)是服務(wù)器對(duì)某個(gè)狀態(tài)進(jìn)行標(biāo)識(shí)，這樣子其實(shí)是很像session機(jī)制的，具體看下面

十一 cookies與session

11.1 含義

cookie機(jī)制

Cookies是服務(wù)器在本地機(jī)器上存儲(chǔ)的小段文本并隨每一個(gè)請(qǐng)求發(fā)送至同一個(gè)服務(wù)器。IETF RFC 2965 HTTP State Management Mechanism 是通用cookie規(guī)范。網(wǎng)絡(luò)服務(wù)器用HTTP頭向客戶端發(fā)送cookies，在客戶終端，瀏覽器解析這些cookies并將它們保存為一個(gè)本地文件，它會(huì)自動(dòng)將同一服務(wù)器的任何請(qǐng)求縛上這些cookies 。

具體來(lái)說(shuō)cookie機(jī)制采用的是在客戶端保持狀態(tài)的方案。它是在用戶端的會(huì)話狀態(tài)的存貯機(jī)制，他需要用戶打開(kāi)客戶端的cookie支持。cookie的作用就是為了解決HTTP協(xié)議無(wú)狀態(tài)的缺陷所作的努力。

正統(tǒng)的cookie分發(fā)是通過(guò)擴(kuò)展HTTP協(xié)議來(lái)實(shí)現(xiàn)的，服務(wù)器通過(guò)在HTTP的響應(yīng)頭中加上一行特殊的指示以提示瀏覽器按照指示生成相應(yīng)的cookie。然而純粹的客戶端腳本如JavaScript也可以生成cookie。而cookie的使用是由瀏覽器按照一定的原則在后臺(tái)自動(dòng)發(fā)送給服務(wù)器的。瀏覽器檢查所有存儲(chǔ)的cookie，如果某個(gè)cookie所聲明的作用范圍大于等于將要請(qǐng)求的資源所在的位置，則把該cookie附在請(qǐng)求資源的HTTP請(qǐng)求頭上發(fā)送給服務(wù)器。

cookie的內(nèi)容主要包括：名字，值，過(guò)期時(shí)間，路徑和域。路徑與域一起構(gòu)成cookie的作用范圍。若不設(shè)置過(guò)期時(shí)間，則表示這個(gè)cookie的生命期為瀏覽器會(huì)話期間，關(guān)閉瀏覽器窗口，cookie就消失。這種生命期為瀏覽器會(huì)話期的cookie被稱為會(huì)話cookie。會(huì)話cookie一般不存儲(chǔ)在硬盤(pán)上而是保存在內(nèi)存里，當(dāng)然這種行為并不是規(guī)范規(guī)定的。若設(shè)置了過(guò)期時(shí)間，瀏覽器就會(huì)把cookie保存到硬盤(pán)上，關(guān)閉后再次打開(kāi)瀏覽器，這些cookie仍然有效直到超過(guò)設(shè)定的過(guò)期時(shí)間。存儲(chǔ)在硬盤(pán)上的cookie可以在不同的瀏覽器進(jìn)程間共享，比如兩個(gè)IE窗口。而對(duì)于保存在內(nèi)存里的cookie，不同的瀏覽器有不同的處理方式。（故也有內(nèi)存cookie和硬盤(pán)cookie之分）

而session機(jī)制采用的是一種在服務(wù)器端保持狀態(tài)的解決方案。同時(shí)我們也看到，由于采用服務(wù)器端保持狀態(tài)的方案在客戶端也需要保存一個(gè)標(biāo)識(shí)，所以session機(jī)制可能需要借助于cookie機(jī)制來(lái)達(dá)到保存標(biāo)識(shí)的目的。而session提供了方便管理全局變量的方式

session是針對(duì)每一個(gè)用戶的，變量的值保存在服務(wù)器上，用一個(gè)sessionID來(lái)區(qū)分是哪個(gè)用戶session變量,這個(gè)值是通過(guò)用戶的瀏覽器在訪問(wèn)的時(shí)候返回給服務(wù)器，當(dāng)客戶禁用cookie時(shí)，這個(gè)值也可能設(shè)置為由get來(lái)返回給服務(wù)器。

就安全性來(lái)說(shuō)：當(dāng)你訪問(wèn)一個(gè)使用session 的站點(diǎn)，同時(shí)在自己機(jī)子上建立一個(gè)cookie，建議在服務(wù)器端的session機(jī)制更安全些，因?yàn)樗粫?huì)任意讀取客戶存儲(chǔ)的信息

session機(jī)制

session機(jī)制是一種服務(wù)器端的機(jī)制，服務(wù)器使用一種類似于散列表的結(jié)構(gòu)（也可能就是使用散列表）來(lái)保存信息。

當(dāng)程序需要為某個(gè)客戶端的請(qǐng)求創(chuàng)建一個(gè)session時(shí)，服務(wù)器首先檢查這個(gè)客戶端的請(qǐng)求里是否已包含了一個(gè)session標(biāo)識(shí)（稱為session id），如果已包含則說(shuō)明以前已經(jīng)為此客戶端創(chuàng)建過(guò)session，服務(wù)器就按照session id把這個(gè)session檢索出來(lái)使用（檢索不到，會(huì)新建一個(gè)），如果客戶端請(qǐng)求不包含session id，則為此客戶端創(chuàng)建一個(gè)session并且生成一個(gè)與此session相關(guān)聯(lián)的session id，session id的值應(yīng)該是一個(gè)既不會(huì)重復(fù)，又不容易被找到規(guī)律以仿造的字符串，這個(gè)session id將被在本次響應(yīng)中返回給客戶端保存。

保存這個(gè)session id的方式可以采用cookie，這樣在交互過(guò)程中瀏覽器可以自動(dòng)的按照規(guī)則把這個(gè)標(biāo)識(shí)發(fā)揮給服務(wù)器。一般這個(gè)cookie的名字都是類似于SEEESIONID。但cookie可以被人為的禁止，則必須有其他機(jī)制以便在cookie被禁止時(shí)仍然能夠把session id傳遞回服務(wù)器。

經(jīng)常被使用的一種技術(shù)叫做URL重寫(xiě)，就是把session id直接附加在URL路徑的后面。還有一種技術(shù)叫做表單隱藏字段。就是服務(wù)器會(huì)自動(dòng)修改表單，添加一個(gè)隱藏字段，以便在表單提交時(shí)能夠把session id傳遞回服務(wù)器。

11.2 作用

都是可以進(jìn)行保持狀態(tài)的一種機(jī)制

11.3 區(qū)別

11.3.1 存取方式的不同

cookie只能存儲(chǔ)ASCII字符串

session可以存儲(chǔ)任意類型的數(shù)據(jù)

11.3.2 隱私策略的不同

Cookie存儲(chǔ)在客戶端閱讀器中，對(duì)客戶端是可見(jiàn)的，客戶端的一些程序可能會(huì)窺探、復(fù)制以至修正Cookie中的內(nèi)容。而Session存儲(chǔ)在服務(wù)器上，對(duì)客戶端是透明的，不存在敏感信息泄露的風(fēng)險(xiǎn)。

假如選用Cookie，比較好的方法是，敏感的信息如賬號(hào)密碼等盡量不要寫(xiě)到Cookie中。最好是像Google、Baidu那樣將Cookie信息加密，提交到服務(wù)器后再進(jìn)行解密，保證Cookie中的信息只要本人能讀得懂。而假如選擇Session就省事多了，反正是放在服務(wù)器上，Session里任何隱私都能夠有效的保護(hù)

11.3.3 有效期上的不同

使用過(guò)Google的人都曉得，假如登錄過(guò)Google，則Google的登錄信息長(zhǎng)期有效。用戶不用每次訪問(wèn)都重新登錄，Google會(huì)持久地記載該用戶的登錄信息。要到達(dá)這種效果，運(yùn)用Cookie會(huì)是比較好的選擇。只需要設(shè)置Cookie的過(guò)期時(shí)間屬性為一個(gè)很大很大的數(shù)字。

由于Session依賴于名為JSESSIONID的Cookie，而Cookie JSESSIONID的過(guò)期時(shí)間默許為–1，只需關(guān)閉了閱讀器該Session就會(huì)失效，因而Session不能完成信息永世有效的效果。運(yùn)用URL地址重寫(xiě)也不能完成。而且假如設(shè)置Session的超時(shí)時(shí)間過(guò)長(zhǎng)，服務(wù)器累計(jì)的Session就會(huì)越多，越容易招致內(nèi)存溢出

11.3.4 服務(wù)器壓力不同

Session是保管在服務(wù)器端的，每個(gè)用戶都會(huì)產(chǎn)生一個(gè)Session。假如并發(fā)訪問(wèn)的用戶十分多，會(huì)產(chǎn)生十分多的Session，耗費(fèi)大量的內(nèi)存。因而像Google、Baidu、Sina這樣并發(fā)訪問(wèn)量極高的網(wǎng)站，是不太可能運(yùn)用Session來(lái)追蹤客戶會(huì)話的。

而Cookie保管在客戶端，不占用服務(wù)器資源。假如并發(fā)閱讀的用戶十分多，Cookie是很好的選擇。關(guān)于Google、Baidu、Sina來(lái)說(shuō)，Cookie或許是唯一的選擇。

11.3.5? 瀏覽器支持的不同

Cookie是需要客戶端瀏覽器支持的。假如客戶端禁用了Cookie，或者不支持Cookie，則會(huì)話跟蹤會(huì)失效。關(guān)于WAP上的應(yīng)用，常規(guī)的Cookie就派不上用場(chǎng)了。

假如客戶端瀏覽器不支持Cookie，需要運(yùn)用Session以及URL地址重寫(xiě)。需要注意的是一切的用到Session程序的URL都要進(jìn)行URL地址重寫(xiě)，否則Session會(huì)話跟蹤還會(huì)失效。關(guān)于WAP應(yīng)用來(lái)說(shuō)，Session+URL地址重寫(xiě)或許是它唯一的選擇。

假如客戶端支持Cookie，則Cookie既能夠設(shè)為本瀏覽器窗口以及子窗口內(nèi)有效（把過(guò)期時(shí)間設(shè)為–1），也能夠設(shè)為一切閱讀器窗口內(nèi)有效（把過(guò)期時(shí)間設(shè)為某個(gè)大于0的整數(shù)）。但Session只能在本閱讀器窗口以及其子窗口內(nèi)有效。假如兩個(gè)瀏覽器窗口互不相干，它們將運(yùn)用兩個(gè)不同的Session。（IE8下不同窗口Session相干）

11.3.6 跨域支持上的不同

Cookie支持跨域名訪問(wèn)，例如將domain屬性設(shè)置為“.biaodianfu.com”，則以“.biaodianfu.com”為后綴的一切域名均能夠訪問(wèn)該Cookie。跨域名Cookie如今被普遍用在網(wǎng)絡(luò)中，例如Google、Baidu、Sina等。而Session則不會(huì)支持跨域名訪問(wèn)。Session僅在他所在的域名內(nèi)有效。

僅運(yùn)用Cookie或者僅運(yùn)用Session可能完成不了理想的效果。這時(shí)應(yīng)該嘗試一下同時(shí)運(yùn)用Cookie與Session。Cookie與Session的搭配運(yùn)用在實(shí)踐項(xiàng)目中會(huì)完成很多意想不到的效果

11.4 聯(lián)系

客戶第一次發(fā)送請(qǐng)求給服務(wù)器，此時(shí)服務(wù)器產(chǎn)生一個(gè)唯一的sessionID，并返回給客戶端(通過(guò)cookie)，保存于客戶端的內(nèi)存中，并與一個(gè)瀏覽器窗口對(duì)應(yīng)著,由于HTTP協(xié)議的特性，這一次連接就斷開(kāi)了。

以后此客戶端再發(fā)送請(qǐng)求給服務(wù)器的時(shí)候，就會(huì)在請(qǐng)求request中攜帶cookie,由于cookie中有sessionID,所以服務(wù)器就知道這是剛才那個(gè)客戶端。

也就是說(shuō)cookie可以存儲(chǔ)sessionid的一種標(biāo)識(shí)。

摘抄來(lái)自于：http://blog.csdn.net/weixin_37196194/article/details/55806366

十二 http2的新特性

? ? ? ? 2015年發(fā)布的http2

12.1 二進(jìn)制協(xié)議

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

二進(jìn)制協(xié)議的一個(gè)好處是，可以定義額外的幀。HTTP/2 定義了近十種幀，為將來(lái)的高級(jí)應(yīng)用打好了基礎(chǔ)。如果使用文本實(shí)現(xiàn)這種功能，解析數(shù)據(jù)將會(huì)變得非常麻煩，二進(jìn)制解析則方便得多

12.2 多工

HTTP/2 復(fù)用TCP連接，在一個(gè)連接里，客戶端和瀏覽器都可以同時(shí)發(fā)送多個(gè)請(qǐng)求或回應(yīng)，而且不用按照順序一一對(duì)應(yīng)，這樣就避免了"隊(duì)頭堵塞"。（隊(duì)頭阻塞意思是客戶端或者服務(wù)器發(fā)送消息的時(shí)候，如果某條數(shù)據(jù)太大，那么需要的時(shí)間就要很長(zhǎng)，后面等待發(fā)送的就會(huì)有很多，造成堵塞）

舉例來(lái)說(shuō)，在一個(gè)TCP連接里面，服務(wù)器同時(shí)收到了A請(qǐng)求和B請(qǐng)求，于是先回應(yīng)A請(qǐng)求，結(jié)果發(fā)現(xiàn)處理過(guò)程非常耗時(shí)，于是就發(fā)送A請(qǐng)求已經(jīng)處理好的部分， 接著回應(yīng)B請(qǐng)求，完成后，再發(fā)送A請(qǐng)求剩下的部分。

這樣雙向的、實(shí)時(shí)的通信，就叫做多工（Multiplexing）

12.3 數(shù)據(jù)包

由于多工的特性存在，http2的數(shù)據(jù)包是不按順序發(fā)送的，同一個(gè)連接里面連續(xù)的數(shù)據(jù)包，可能屬于不同的回應(yīng)。因此，必須要對(duì)數(shù)據(jù)包做標(biāo)記，指出它屬于哪個(gè)回應(yīng)。

HTTP/2 將每個(gè)請(qǐng)求或回應(yīng)的所有數(shù)據(jù)包，稱為一個(gè)數(shù)據(jù)流（stream）。每個(gè)數(shù)據(jù)流都有一個(gè)獨(dú)一無(wú)二的編號(hào)。數(shù)據(jù)包發(fā)送的時(shí)候，都必須標(biāo)記數(shù)據(jù)流ID，用來(lái)區(qū)分它屬于哪個(gè)數(shù)據(jù)流。另外還規(guī)定，客戶端發(fā)出的數(shù)據(jù)流，ID一律為奇數(shù)，服務(wù)器發(fā)出的，ID為偶數(shù)。

數(shù)據(jù)流發(fā)送到一半的時(shí)候，客戶端和服務(wù)器都可以發(fā)送信號(hào)（RST_STREAM幀），取消這個(gè)數(shù)據(jù)流。1.1版取消數(shù)據(jù)流的唯一方法，就是關(guān)閉TCP連接。這就是說(shuō)，HTTP/2 可以取消某一次請(qǐng)求，同時(shí)保證TCP連接還打開(kāi)著，可以被其他請(qǐng)求使用。

客戶端還可以指定數(shù)據(jù)流的優(yōu)先級(jí)。優(yōu)先級(jí)越高，服務(wù)器就會(huì)越早回應(yīng)。

12.4 頭信息壓縮

HTTP 協(xié)議不帶有狀態(tài)，每次請(qǐng)求都必須附上所有信息。所以，請(qǐng)求的很多字段都是重復(fù)的，比如Cookie和User Agent，一模一樣的內(nèi)容，每次請(qǐng)求都必須附帶，這會(huì)浪費(fèi)很多帶寬，也影響速度。

HTTP/2 對(duì)這一點(diǎn)做了優(yōu)化，引入了頭信息壓縮機(jī)制（header compression）。一方面，頭信息使用gzip或compress壓縮后再發(fā)送；另一方面，客戶端和服務(wù)器同時(shí)維護(hù)一張頭信息表，所有字段都會(huì)存入這個(gè)表，生成一個(gè)索引號(hào)，以后就不發(fā)送同樣字段了，只發(fā)送索引號(hào)，這樣就提高速度了。

12.5 服務(wù)器推送

HTTP/2 允許服務(wù)器未經(jīng)請(qǐng)求，主動(dòng)向客戶端發(fā)送資源，這叫做服務(wù)器推送（server push）。

常見(jiàn)場(chǎng)景是客戶端請(qǐng)求一個(gè)網(wǎng)頁(yè)，這個(gè)網(wǎng)頁(yè)里面包含很多靜態(tài)資源。正常情況下，客戶端必須收到網(wǎng)頁(yè)后，解析HTML源碼，發(fā)現(xiàn)有靜態(tài)資源，再發(fā)出靜態(tài)資源請(qǐng)求。其實(shí)，服務(wù)器可以預(yù)期到客戶端請(qǐng)求網(wǎng)頁(yè)后，很可能會(huì)再請(qǐng)求靜態(tài)資源，所以就主動(dòng)把這些靜態(tài)資源隨著網(wǎng)頁(yè)一起發(fā)給客戶端了。

這里可以去搜搜看阮一峰的網(wǎng)絡(luò)日志中關(guān)于http協(xié)議這一篇，寫(xiě)的簡(jiǎn)短又有內(nèi)涵