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

一 介紹

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

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

二 http的主要特點

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

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

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

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

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

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

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

）

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

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

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

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

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

舉例來說拢切，客戶端需要請求兩個資源。以前的做法是秆吵，在同一個TCP連接里面淮椰，先發(fā)送A請求，然后等待服務(wù)器做出回應(yīng)，收到后再發(fā)出B請求主穗。管道機制則是允許瀏覽器同時發(fā)出A請求和B請求泻拦，但是服務(wù)器還是按照順序，先回應(yīng)A請求忽媒，完成后再回應(yīng)B請求争拐。

三 工作流程

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

1）首先客戶機與服務(wù)器需要建立連接晦雨。只要點擊某個超鏈接架曹，HTTP工作開始（建立連接）

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

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

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

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

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

四 URL詳解

URL：統(tǒng)一資源定位符，是URI（統(tǒng)一資源標(biāo)識符）的一種齐疙，用于描述一個網(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：是訪問資源的路徑

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

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

“#”后面的是錨

五 請求消息

5.1 請求的消息格式如下：

1）請求行特愿，如GET /images/logo.gif HTTP/1.1仲墨，表示從/images目錄下請求logo.gif這個文件，使用的是get方法洽议，協(xié)議版本是http1.1

2）請求頭宗收，如Accept-Language: en

3）空行

4）可選的消息體

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

5.2 請求方法

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

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

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

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

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

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

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

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

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

PATCH：用來將局部修改應(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é)呈宇，主要是瀏覽器對URL的長度有限制好爬，POST提交的數(shù)據(jù)沒有限制

3）POST較GET安全，因為GET會將一些信息暴露在URL上甥啄，對于提交的數(shù)據(jù)都會顯示在URL上存炮，若頁面可以緩存或者其他人可以訪問，則可從歷史記錄獲取這個用戶賬號密碼什么的資料

4）GET方式需要使用Request.QueryString來取得變量的值型豁，而POST方式通過Request.Form來獲取變量的值僵蛛。

六 響應(yīng)消息

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

格式：

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

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

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

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

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

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

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

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

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

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

八 頭部信息

8.1? HTTP常見的請求頭

If-Modified-Since：把瀏覽器端緩存頁面的最后修改時間發(fā)送到服務(wù)器去，服務(wù)器會把這個時間與服務(wù)器上實際文件的最后修改時間進(jìn)行對比舍扰。如果時間一致倦蚪，那么返回304，客戶端就直接使用本地緩存文件妥粟。如果時間不一致审丘，就會返回200和新的文件內(nèi)容」锤客戶端接到之后滩报，會丟棄舊文件，把新文件緩存起來播急，并顯示在瀏覽器中脓钾。（這與對比緩存有關(guān)，后文會講到桩警，相對的是響應(yīng)頭的Last-Modified）

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

Cache-Control：指定請求和響應(yīng)遵循的緩存機制。緩存指令是單向的（響應(yīng)中出現(xiàn)的緩存指令在請求中未必會出現(xiàn)）蒜鸡，且是獨立的（在請求消息或響應(yīng)消息中設(shè)置Cache-Control并不會修改另一個消息處理過程中的緩存處理過程）胯努。請求時的緩存指令包括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独郎。（請求頭和響應(yīng)頭中都有，關(guān)于強制緩存的）

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

Cache-Control:Private 客戶端可緩存

Cache-Control:no-cache 需要使用對比緩存來驗證緩存數(shù)據(jù)

Cache-Control:no-store 所有內(nèi)容都不會緩存枚赡，強制緩存氓癌，對比緩存都不會觸發(fā)

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

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

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

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

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

Accept-Language：瀏覽器申明自己接收的語言幅垮。語言跟字符集的區(qū)別：中文是語言腰池，中文有多種字符集，比如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)一個網(wǎng)頁打開完成后奏属，客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的TCP連接不會關(guān)閉，如果客戶端再次訪問這個服務(wù)器上的網(wǎng)頁甘桑，會繼續(xù)使用這一條已經(jīng)建立的連接拍皮。HTTP 1.1默認(rèn)進(jìn)行持久連接歹叮。利用持久連接的優(yōu)點，當(dāng)頁面包含多個元素時（例如Applet铆帽，圖片）咆耿，顯著地減少下載所需要的時間。要實現(xiàn)這一點爹橱，Servlet需要在應(yīng)答中發(fā)送一個Content-Length頭萨螺，最簡單的實現(xiàn)方法是：先把內(nèi)容寫入ByteArrayOutputStream，然后在正式寫出內(nèi)容之前計算它的大小愧驱。

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

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

Host：（發(fā)送請求時糟红，該頭域是必需的）主要用于指定被請求資源的Internet主機和端口號艾帐，它通常從HTTP URL中提取出來的（http1.1協(xié)議種必須包含）

例如: 我們在瀏覽器中輸入：http://www.guet.edu.cn/index.html，瀏覽器發(fā)送的請求消息中盆偿，就會包含Host請求頭域：Host：http://www.guet.edu.cn柒爸，此處使用缺省端口號80，若指定了端口號事扭，則變成：Host：指定端口號

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

Content-Length：表示請求消息正文的長度

Authorization：授權(quán)信息

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

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

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

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

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

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

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

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

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

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

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

Content-Length：指明實體正文的長度夹厌，以字節(jié)方式存儲的十進(jìn)制數(shù)字來表示

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

Content-Range：用于指定整個實體中的一部分的插入位置裆悄，他也指示了整個實體的長度

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

Connection：

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

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

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

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

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

九 HTTP緩存機制

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

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

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

9.1 緩存的優(yōu)點

減少相應(yīng)延遲：因為請求從緩存服務(wù)器（離客戶端更近）而不是源服務(wù)器被相應(yīng)虏肾，這個過程耗時更少尼啡，讓web服務(wù)器看上去相應(yīng)更快。

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

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

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

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

2. 請求首部字段

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

4. 實體首部字段

9.3 緩存方式

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

根據(jù)是否需要重新向服務(wù)器發(fā)起請求來分類唧领，可分為兩大類（強制緩存藻雌、對比緩存）

強制類型不需要向服務(wù)器發(fā)起請求，對比緩存需要向服務(wù)器發(fā)起請求

9.3.1 強制緩存

已經(jīng)具有緩存數(shù)據(jù)的時候斩个，并且緩存時間未過期的話胯杭，使用強制緩存

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

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

Cache-Control

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

作為請求頭部的時候省骂，cache-directive的可選值有

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

實際重點關(guān)注五個值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:需要使用對比緩存來驗證緩存數(shù)據(jù)

no-store:所有內(nèi)容都不會緩存，強制緩存逃延，對比緩存都不會觸發(fā)

舉個例子：

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

也就是說揽祥，在365天內(nèi)再次請求這條數(shù)據(jù)讽膏，都會直接獲取緩存數(shù)據(jù)庫中的數(shù)據(jù)，直接使用

9.3.2 對比緩存

對比緩存：即需要進(jìn)行比較判斷是否可以使用緩存拄丰。瀏覽器第一次請求數(shù)據(jù)時府树，服務(wù)器會將緩存標(biāo)識與數(shù)據(jù)一起返回給客戶端，客戶端將二者備份至緩存數(shù)據(jù)庫中料按。再次請求數(shù)據(jù)時奄侠，客戶端將備份的緩存標(biāo)識發(fā)送給服務(wù)器，服務(wù)器根據(jù)緩存標(biāo)識進(jìn)行判斷载矿，判斷成功后垄潮，返回304狀態(tài)碼，通知客戶端比較成功闷盔，可以使用緩存數(shù)據(jù)

對比緩存解決的問題：緩存時間過期弯洗，但是服務(wù)器卻沒有更新這個資源，此時客戶端再次請求服務(wù)器把這個資源重新發(fā)過來的話逢勾，很浪費帶寬和時間牡整。對比緩存就是讓服務(wù)器知道客戶端現(xiàn)在存有的緩存文件，其實跟自己所有的文件是一致的溺拱，讓客戶端直接使用自己緩存的即可逃贝，提高了緩存的復(fù)用率

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

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

Last-Modified? /? If-Modified-Since

Last-Modified：

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

If-Modified-Since：

再次請求服務(wù)器時秋泳，通過此字段通知服務(wù)器上次請求時，服務(wù)器返回的資源最后修改時間攒菠。

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

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

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

Last-Modified 說好卻也不是特別好奕筐，因為如果在服務(wù)器上舱痘，一個資源被修改了，但其實際內(nèi)容根本沒發(fā)生改變离赫，會因為Last-Modified時間匹配不上而返回了整個實體給客戶端（即使客戶端緩存里有個一模一樣的資源）

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

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

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

Etag：

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

If-None-Match：

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

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

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

相同员萍，說明資源無新修改，則響應(yīng)HTTP 304拣度，告知瀏覽器繼續(xù)使用所保存的cache碎绎。

注意：如果同時存在兩對字段，需要都通過才能使用緩存

總結(jié)

對于強制緩存抗果，服務(wù)器通知瀏覽器一個緩存時間筋帖，在緩存時間內(nèi)，下次請求冤馏，直接用緩存日麸，不在時間內(nèi)，執(zhí)行比較緩存策略。

對于比較緩存代箭，將緩存信息中的Etag和Last-Modified通過請求發(fā)送給服務(wù)器墩划，由服務(wù)器校驗，返回304狀態(tài)碼時嗡综，瀏覽器直接使用緩存乙帮。

瀏覽器第一次請求：

瀏覽器再次請求時：

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

十 解決HTTP無狀態(tài)的問題

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

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

通過Cookies异吻，服務(wù)器就可以清楚的知道請求2和請求1來自同一個客戶端。

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

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

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

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

1、使用Cookie來實現(xiàn)

服務(wù)器給每個Session分配一個唯一的JSESSIONID猖吴，并通過Cookie發(fā)送給客戶端摔刁。

當(dāng)客戶端發(fā)起新的請求的時候，將在Cookie頭中攜帶這個JSESSIONID海蔽。這樣服務(wù)器能夠找到這個客戶端對應(yīng)的Session共屈。

2、使用URL回寫來實現(xiàn)

URL回寫是指服務(wù)器在發(fā)送給瀏覽器頁面的所有鏈接中都攜帶JSESSIONID的參數(shù)党窜，這樣客戶端點擊任何一個鏈接都會把JSESSIONID帶會服務(wù)器拗引。如果直接在瀏覽器輸入服務(wù)端資源的url來請求該資源，那么Session是匹配不到的幌衣。

Tomcat對Session的實現(xiàn)矾削，是一開始同時使用Cookie和URL回寫機制，如果發(fā)現(xiàn)客戶端支持Cookie，就繼續(xù)使用Cookie怔软，停止使用URL回寫垦细。如果發(fā)現(xiàn)Cookie被禁用，就一直使用URL回寫挡逼。jsp開發(fā)處理到Session的時候括改，對頁面中的鏈接記得使用response.encodeURL() 。

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

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

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

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

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

注意：這里說一點自己的見解，保持狀態(tài)我感覺是服務(wù)器對某個狀態(tài)進(jìn)行標(biāo)識装蓬，這樣子其實是很像session機制的著拭，具體看下面

十一 cookies與session

11.1 含義

cookie機制

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

具體來說cookie機制采用的是在客戶端保持狀態(tài)的方案。它是在用戶端的會話狀態(tài)的存貯機制蹂随，他需要用戶打開客戶端的cookie支持十嘿。cookie的作用就是為了解決HTTP協(xié)議無狀態(tài)的缺陷所作的努力。

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

cookie的內(nèi)容主要包括：名字，值剥险，過期時間聪蘸，路徑和域。路徑與域一起構(gòu)成cookie的作用范圍。若不設(shè)置過期時間健爬，則表示這個cookie的生命期為瀏覽器會話期間控乾，關(guān)閉瀏覽器窗口娜遵，cookie就消失慨仿。這種生命期為瀏覽器會話期的cookie被稱為會話cookie镰吆。會話cookie一般不存儲在硬盤上而是保存在內(nèi)存里万皿，當(dāng)然這種行為并不是規(guī)范規(guī)定的牢硅。若設(shè)置了過期時間，瀏覽器就會把cookie保存到硬盤上佳励，關(guān)閉后再次打開瀏覽器赃承，這些cookie仍然有效直到超過設(shè)定的過期時間。存儲在硬盤上的cookie可以在不同的瀏覽器進(jìn)程間共享抓于，比如兩個IE窗口捉撮。而對于保存在內(nèi)存里的cookie肉康，不同的瀏覽器有不同的處理方式吼和。（故也有內(nèi)存cookie和硬盤cookie之分）

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

session是針對每一個用戶的圃酵，變量的值保存在服務(wù)器上郭赐，用一個sessionID來區(qū)分是哪個用戶session變量,這個值是通過用戶的瀏覽器在訪問的時候返回給服務(wù)器，當(dāng)客戶禁用cookie時罗捎，這個值也可能設(shè)置為由get來返回給服務(wù)器豁状。

就安全性來說：當(dāng)你訪問一個使用session 的站點泻红，同時在自己機子上建立一個cookie，建議在服務(wù)器端的session機制更安全些根悼，因為它不會任意讀取客戶存儲的信息

session機制

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

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

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

經(jīng)常被使用的一種技術(shù)叫做URL重寫，就是把session id直接附加在URL路徑的后面徘禁。還有一種技術(shù)叫做表單隱藏字段诅诱。就是服務(wù)器會自動修改表單，添加一個隱藏字段送朱，以便在表單提交時能夠把session id傳遞回服務(wù)器逢艘。

11.2 作用

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

11.3 區(qū)別

11.3.1 存取方式的不同

cookie只能存儲ASCII字符串

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

11.3.2 隱私策略的不同

Cookie存儲在客戶端閱讀器中，對客戶端是可見的骤菠，客戶端的一些程序可能會窺探商乎、復(fù)制以至修正Cookie中的內(nèi)容遏餐。而Session存儲在服務(wù)器上，對客戶端是透明的碑定，不存在敏感信息泄露的風(fēng)險。

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

11.3.3 有效期上的不同

使用過Google的人都曉得星持，假如登錄過Google揪垄，則Google的登錄信息長期有效饥努。用戶不用每次訪問都重新登錄汉匙，Google會持久地記載該用戶的登錄信息庐橙。要到達(dá)這種效果，運用Cookie會是比較好的選擇恶导。只需要設(shè)置Cookie的過期時間屬性為一個很大很大的數(shù)字浆竭。

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

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

Session是保管在服務(wù)器端的，每個用戶都會產(chǎn)生一個Session包蓝。假如并發(fā)訪問的用戶十分多驶社，會產(chǎn)生十分多的Session，耗費大量的內(nèi)存测萎。因而像Google哺哼、Baidu、Sina這樣并發(fā)訪問量極高的網(wǎng)站峦朗，是不太可能運用Session來追蹤客戶會話的杀怠。

而Cookie保管在客戶端，不占用服務(wù)器資源腕唧。假如并發(fā)閱讀的用戶十分多或辖，Cookie是很好的選擇。關(guān)于Google枣接、Baidu颂暇、Sina來說，Cookie或許是唯一的選擇但惶。

11.3.5? 瀏覽器支持的不同

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

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

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

11.3.6 跨域支持上的不同

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

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

11.4 聯(lián)系

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

以后此客戶端再發(fā)送請求給服務(wù)器的時候性宏，就會在請求request中攜帶cookie,由于cookie中有sessionID,所以服務(wù)器就知道這是剛才那個客戶端群井。

也就是說cookie可以存儲sessionid的一種標(biāo)識状飞。

摘抄來自于：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 則是一個徹底的二進(jìn)制協(xié)議酵使，頭信息和數(shù)據(jù)體都是二進(jìn)制，并且統(tǒng)稱為"幀"（frame）：頭信息幀和數(shù)據(jù)幀焙糟。

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

12.2 多工

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

舉例來說僚焦，在一個TCP連接里面锰提，服務(wù)器同時收到了A請求和B請求，于是先回應(yīng)A請求叠赐，結(jié)果發(fā)現(xiàn)處理過程非常耗時欲账，于是就發(fā)送A請求已經(jīng)處理好的部分， 接著回應(yīng)B請求芭概，完成后赛不，再發(fā)送A請求剩下的部分。

這樣雙向的罢洲、實時的通信踢故，就叫做多工（Multiplexing）

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

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

HTTP/2 將每個請求或回應(yīng)的所有數(shù)據(jù)包院究，稱為一個數(shù)據(jù)流（stream）洽瞬。每個數(shù)據(jù)流都有一個獨一無二的編號。數(shù)據(jù)包發(fā)送的時候业汰，都必須標(biāo)記數(shù)據(jù)流ID伙窃，用來區(qū)分它屬于哪個數(shù)據(jù)流。另外還規(guī)定样漆，客戶端發(fā)出的數(shù)據(jù)流为障，ID一律為奇數(shù)，服務(wù)器發(fā)出的放祟，ID為偶數(shù)鳍怨。

數(shù)據(jù)流發(fā)送到一半的時候，客戶端和服務(wù)器都可以發(fā)送信號（RST_STREAM幀）跪妥，取消這個數(shù)據(jù)流鞋喇。1.1版取消數(shù)據(jù)流的唯一方法，就是關(guān)閉TCP連接骗奖。這就是說确徙，HTTP/2 可以取消某一次請求醒串，同時保證TCP連接還打開著，可以被其他請求使用鄙皇。

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

12.4 頭信息壓縮

HTTP 協(xié)議不帶有狀態(tài)缠沈，每次請求都必須附上所有信息。所以错蝴，請求的很多字段都是重復(fù)的洲愤，比如Cookie和User Agent，一模一樣的內(nèi)容顷锰，每次請求都必須附帶柬赐，這會浪費很多帶寬，也影響速度官紫。

HTTP/2 對這一點做了優(yōu)化肛宋，引入了頭信息壓縮機制（header compression）。一方面束世，頭信息使用gzip或compress壓縮后再發(fā)送酝陈；另一方面，客戶端和服務(wù)器同時維護(hù)一張頭信息表毁涉，所有字段都會存入這個表沉帮，生成一個索引號，以后就不發(fā)送同樣字段了贫堰，只發(fā)送索引號穆壕，這樣就提高速度了。

12.5 服務(wù)器推送

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

常見場景是客戶端請求一個網(wǎng)頁漫玄，這個網(wǎng)頁里面包含很多靜態(tài)資源。正常情況下压彭，客戶端必須收到網(wǎng)頁后睦优，解析HTML源碼，發(fā)現(xiàn)有靜態(tài)資源壮不，再發(fā)出靜態(tài)資源請求汗盘。其實，服務(wù)器可以預(yù)期到客戶端請求網(wǎng)頁后询一，很可能會再請求靜態(tài)資源隐孽，所以就主動把這些靜態(tài)資源隨著網(wǎng)頁一起發(fā)給客戶端了癌椿。

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