HTTP簡介

HTTP（HyperText Transfer Protocol）即超文本傳輸協(xié)議，是一種詳細(xì)規(guī)定了瀏覽器和萬維網(wǎng)服務(wù)器之間互相通信的規(guī)則，它是萬維網(wǎng)交換信息的基礎(chǔ)，它允許將HTML（超文本標(biāo)記語言）文檔從Web服務(wù)器傳送到Web瀏覽器。

HTTP協(xié)議目前最新版的版本是1.1，HTTP是一種無狀態(tài)的協(xié)議，無狀態(tài)是指Web瀏覽器與Web服務(wù)器之間不需要建立持久的連接，這意味著當(dāng)一個(gè)客戶端向服務(wù)器端發(fā)出請求，然后Web服務(wù)器返回響應(yīng)（Response），連接就被關(guān)閉了，在服務(wù)器端不保留連接的有關(guān)信息。也就是說，HTTP請求只能由客戶端發(fā)起，而服務(wù)器不能主動向客戶端發(fā)送數(shù)據(jù)。

HTTP是一個(gè)基于TCP/IP通信協(xié)議來傳遞數(shù)據(jù)（HTML 文件, 圖片文件, 查詢結(jié)果等）。

HTTP工作原理：

HTTP協(xié)議工作于客戶端-服務(wù)端架構(gòu)上。瀏覽器作為HTTP客戶端通過URL向HTTP服務(wù)端即WEB服務(wù)器發(fā)送所有請求。

Web服務(wù)器有：Apache服務(wù)器，IIS服務(wù)器（Internet Information Services）等。

Web服務(wù)器根據(jù)接收到的請求后，向客戶端發(fā)送響應(yīng)信息。

HTTP默認(rèn)端口號為80，但是你也可以改為8080或者其他端口。

HTTP三點(diǎn)注意事項(xiàng)：

• HTTP是無連接：無連接的含義是限制每次連接只處理一個(gè)請求。服務(wù)器處理完客戶的請求，并收到客戶的應(yīng)答后，即斷開連接。采用這種方式可以節(jié)省傳輸時(shí)間。

• HTTP是媒體獨(dú)立的：這意味著，只要客戶端和服務(wù)器知道如何處理的數(shù)據(jù)內(nèi)容，任何類型的數(shù)據(jù)都可以通過HTTP發(fā)送。客戶端以及服務(wù)器指定使用適合的MIME-type內(nèi)容類型。

• HTTP是無狀態(tài)：HTTP協(xié)議是無狀態(tài)協(xié)議。無狀態(tài)是指協(xié)議對于事務(wù)處理沒有記憶能力。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大。另一方面，在服務(wù)器不需要先前信息時(shí)它的應(yīng)答就較快。

HTTP請求與響應(yīng)

HTTP遵循請求（Request）/應(yīng)答（Response）模型，Web瀏覽器向Web服務(wù)器發(fā)送請求時(shí)，Web服務(wù)器處理請求并返回適當(dāng)?shù)膽?yīng)答。

HTTP請求：

HTTP請求包括三部分，分別是請求行（請求方法）、請求頭（消息報(bào)頭）和請求正文。

HTTP請求第一行為請求行，由三部分組成，第一部分說明了該請求時(shí)POST請求，第二部分是一個(gè)斜杠（/login.php），用來說明請求是該域名根目錄下的login.php，第三部分說明使用的是HTTP1.1版本。

HTTP請求第二行至空白行為請求頭（也被稱為消息頭）。其中，HOST代表請求主機(jī)地址，User-Agent代表瀏覽器的標(biāo)識，請求頭由客戶端自行設(shè)定。

HTTP請求第三行為請求正文，請求正文是可選的，它最常出現(xiàn)在POST請求方式中。

HTTP請求方法：

根據(jù) HTTP 標(biāo)準(zhǔn)，HTTP 請求可以使用多種請求方法。

HTTP1.0 定義了三種請求方法： GET, POST 和 HEAD方法。

HTTP1.1 新增了五種請求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。

GET、POST、HEAD、PUT請求：

• GET：GET方法用于獲取請求頁面的指定信息。如果請求資源為動態(tài)腳本（非HTML），那么返回文本是Web容器解析后的HTML源代碼。GET請求沒有消息主體，因此在消息頭后的空白行是沒有其他數(shù)據(jù)。

• POST：POST方法也與GET方法相似，但最大的區(qū)別在于，GET方法沒有請求內(nèi)容，而POST是有請求內(nèi)容的。

• HEAD：這個(gè)請求的功能與GET請求相似，不同之處在于服務(wù)器不會再其響應(yīng)中返回消息主體，因此，這種方法可用于檢查某一資源在向其提交GET請求前是否存在。

• PUT：PUT方法用于請求服務(wù)器把請求中的實(shí)體存儲在請求資源下，如果請求資源已經(jīng)在服務(wù)器中存在，那么將會用此請求中的數(shù)據(jù)替換原先的數(shù)據(jù)。向服務(wù)器上傳指定的資源。

HTTP響應(yīng)：

HTTP響應(yīng)的第一行為響應(yīng)行，其中有HTTP版本（HTTP/1.1）、狀態(tài)碼（200）以及消息“OK”。

第二行至末尾的空白行為響應(yīng)頭，由服務(wù)器向客戶端發(fā)送。

消息頭之后是響應(yīng)正文，是服務(wù)器向客戶端發(fā)送的HTML數(shù)據(jù)。

HTTP消息頭：

請求頭：請求頭只出現(xiàn)在HTTP請求中，請求報(bào)頭允許客戶端向服務(wù)端傳遞請求的附加信息和客戶端自身信息。

響應(yīng)頭：響應(yīng)頭是服務(wù)器根據(jù)請求向客戶端發(fā)送的HTTP頭。

HTTP請求頭：

• Host 請求報(bào)頭域主要用于指定被請求資源的Internet主機(jī)和端口。

• User-Agent 請求報(bào)頭域允許客戶端將它的操作系統(tǒng)、瀏覽器和其他屬性告訴服務(wù)器。

• Referer 包含一個(gè)URL，代表當(dāng)前訪問URL的上一個(gè)URL，也就是說，用戶是從什么地方來到本頁面。當(dāng)前請求的原始URL地址。

• Cookie 是非常重要的請求頭，常用來表示請求者的身份等。

• Accept 這個(gè)消息頭用于告訴服務(wù)器客戶端愿意接受那些內(nèi)容，比如圖像類，辦公文檔格式等等。

HTTP響應(yīng)頭信息：

攔截HTTP請求的分析點(diǎn)：

HTTP狀態(tài)與會話

HTTP狀態(tài)碼：

當(dāng)瀏覽者訪問一個(gè)網(wǎng)頁時(shí)，瀏覽者的瀏覽器會向網(wǎng)頁所在服務(wù)器發(fā)出請求。當(dāng)瀏覽器接收并顯示網(wǎng)頁前，此網(wǎng)頁所在的服務(wù)器會返回一個(gè)包含HTTP狀態(tài)碼的信息頭（server header）用以響應(yīng)瀏覽器的請求。

HTTP狀態(tài)碼的英文為HTTP Status Code。

五種狀態(tài)碼：

• 1xx：信息提示，表示請求已被成功接收，繼續(xù)處理。

• 2xx：請求被成功提交。

• 3xx：客戶端被重定向到其他資源。

• 4xx：客戶端錯(cuò)誤狀態(tài)碼，格式錯(cuò)誤或者不存在資源。

• 5xx：描述服務(wù)器內(nèi)部錯(cuò)誤。

常見的狀態(tài)碼描述如下：

• 200：客戶端請求成功，是最常見的狀態(tài)。

• 302：重定向。

• 404：請求資源不存在，是最常見的狀態(tài)。

• 400：客戶端請求有語法錯(cuò)誤，不能被服務(wù)器所理解。

• 401：請求未經(jīng)授權(quán)。

• 403：服務(wù)器收到請求，但是拒絕提供服務(wù)。

• 500：服務(wù)器內(nèi)部錯(cuò)誤，是最常見的狀態(tài)。

• 503：服務(wù)器當(dāng)前不能處理客戶端的請求。

會話與會話狀態(tài)簡介：

WEB應(yīng)用中的會話是指一個(gè)客戶端瀏覽器與WEB服務(wù)器之間連續(xù)發(fā)生的一系列請求和響應(yīng)過程。

WEB應(yīng)用的會話狀態(tài)是指WEB服務(wù)器與瀏覽器在會話過程中產(chǎn)生的狀態(tài)信息，借助會話狀態(tài)，WEB服務(wù)器能夠把屬于同一會話中的一系列的請求和響應(yīng)過程關(guān)聯(lián)起來。

如何實(shí)現(xiàn)有狀態(tài)的會話：

某個(gè)用戶從網(wǎng)站的登錄頁面登入后，在進(jìn)入購物頁面購物時(shí)，負(fù)責(zé)處理購物請求的服務(wù)器程序必須知道處理上一次請求的程序所得到的用戶信息。

HTTP協(xié)議是一種無狀態(tài)的協(xié)議，WEB服務(wù)器本身不能識別出哪些請求是同一個(gè)瀏覽器發(fā)出的 ，瀏覽器的每一次請求都是完全孤立的。

WEB服務(wù)器端程序要能從大量的請求消息中區(qū)分出哪些請求消息屬于同一個(gè)會話，即能識別出來自同一個(gè)瀏覽器的訪問請求，這需要瀏覽器對其發(fā)出的每個(gè)請求消息都進(jìn)行標(biāo)識，屬于同一個(gè)會話中的請求消息都附帶同樣的標(biāo)識號，而屬于不同會話的請求消息總是附帶不同的標(biāo)識號，這個(gè)標(biāo)識號就稱之為會話ID（SessionID）。

會話ID可以通過一種稱之為Cookie的技術(shù)在請求消息中進(jìn)行傳遞，也可以作為請求URL的附加參數(shù)進(jìn)行傳遞。會話ID是WEB服務(wù)器為每客戶端瀏覽器分配的一個(gè)唯一代號，它通常是在WEB服務(wù)器接收到某個(gè)瀏覽器的第一次訪問時(shí)產(chǎn)生，并且隨同響應(yīng)消息一道發(fā)送給瀏覽器。

會話過程由WEB服務(wù)器端的程序開啟，一旦開啟了一個(gè)會話，服務(wù)器端程序就要為這個(gè)會話創(chuàng)建一個(gè)獨(dú)立的存儲結(jié)構(gòu)來保存該會話的狀態(tài)信息，同一個(gè)會話中的訪問請求都可以且只能訪問屬于該會話的存儲結(jié)構(gòu)中的狀態(tài)信息。

Cookie技術(shù)：

Cookie是一種在客戶端保持HTTP狀態(tài)信息的技術(shù)，它好比商場發(fā)放的優(yōu)惠卡。

Cookie是在瀏覽器訪問WEB服務(wù)器的某個(gè)資源時(shí)，由WEB服務(wù)器在HTTP響應(yīng)消息頭中附帶傳送給瀏覽器的一片數(shù)據(jù)，WEB服務(wù)器傳送給各個(gè)客戶端瀏覽器的數(shù)據(jù)是可以各不相同的。

一旦WEB瀏覽器保存了某個(gè)Cookie，那么它在以后每次訪問該WEB服務(wù)器時(shí)，都應(yīng)在HTTP請求頭中將這個(gè)Cookie回傳給WEB服務(wù)器。

Cookie技術(shù)最先被Netscape公司引入到 Navigator瀏 覽器中。

現(xiàn)在，絕大多 數(shù)瀏覽器都支持Cookie，或者至少兼容 Cookie技 術(shù)的使用。

Cookie是一小段文本信息，伴隨著用戶請求和頁 面在Web服務(wù)器和瀏覽器之間傳遞。Cookie包含每次 用戶訪問站點(diǎn)時(shí)Web應(yīng)用程序都可以讀取的信息。

Cookie只是一段文本，所以它只能保存字符串。

WEB服務(wù)器通過在HTTP響應(yīng)消息中增加Set-Cookie響應(yīng)頭字段將Cookie信息發(fā)送給瀏覽器，瀏覽器則通過在HTTP請求消息中增加Cookie請求頭字段將Cookie回傳給WEB服務(wù)器。

一個(gè)Cookie只能標(biāo)識一種信息，它至少含有一個(gè)標(biāo)識該信息的名稱（NAME）和設(shè)置值（VALUE）。

一個(gè)WEB站點(diǎn)可以給一個(gè)WEB瀏覽器發(fā)送多個(gè)Cookie，一個(gè)WEB瀏覽器也可以存儲多個(gè)WEB站點(diǎn)提供的Cookie。

瀏覽器一般只允許存放300個(gè)Cookie，每個(gè)站點(diǎn)最多存放20個(gè)Cookie，每個(gè)Cookie的大小限制為4KB。

Cookie的傳送過程示意圖：

Cookie功能特點(diǎn)：

• 存儲于瀏覽器頭部/傳輸于HTTP頭部

• 寫時(shí)帶屬性，讀時(shí)無屬性

• HTTP頭中Cookie: user=bob; cart=books;

• 屬性 name/value/expire/domain/path/httponly/secure/……

• 由三元組[name,domain,path]唯一確定cookie

Set-Cookie2響應(yīng)字段：

Set-Cookie2頭字段用于指定WEB服務(wù)器向客戶端傳送的Cookie內(nèi)容，但是按照Netscape規(guī)范實(shí)現(xiàn)Cookie功能的WEB服務(wù)器，使用的是Set-Cookie頭字段，兩者的語法和作用類似。

Set-Cookie2頭字段中設(shè)置的cookie內(nèi)容是具有一定格式的字符串，它必須以Cookie的名稱和設(shè)置值開頭，格式為“名稱=值”，后面可以加上0個(gè)或多個(gè)以分號（;）和空格分隔的其它可選屬性，屬性格式一般為“屬性名=值”。

舉例：

Set-Cookie2: user=hello; Version=1; Path=/

除了“名稱=值”對必須位于最前面外，其它的可選屬性的先后順序可以任意。

Cookie的名稱只能由普通的英文ASCII字符組成，瀏覽器不用關(guān)心和理解Cookie的值部分的意義和格式，只要WEB服務(wù)器能理解值部分的意義就行。

大多數(shù)現(xiàn)有的WEB服務(wù)器都是采用某種編碼方式將值部分的內(nèi)容編碼成可打印的ASCII字符，RFC 2965規(guī)范中沒有明確限定編碼方式。

Cookie請求字段：

• Cookie請求頭字段中的每個(gè)Cookie之間用逗號（,）或分號（;）分隔。

• 在Cookie請求頭字段中除了必須有“名稱=值”的設(shè)置外，還可以有Version、Path、Domain、Port等幾個(gè)屬性。

• 在Version、Path、Domain、Port等屬性名之前，都要增加一個(gè)“$”字符作為前綴。

• Version屬性只能出現(xiàn)一次，且要位于Cookie請求頭字段設(shè)置值的最前面，如果需要設(shè)置某個(gè)Cookie信息的 Path、Domain、Port等屬性，它們必須位于該Cookie信息的“名稱=值”設(shè)置之后。?瀏覽器使用Cookie請求頭字段將Cookie信息回送給WEB服務(wù)器。

• 多個(gè)Cookie信息通過一個(gè)Cookie請求頭字段回送給WEB服務(wù)器。

• 瀏覽器根據(jù)下面的幾個(gè)規(guī)則決定是否發(fā)送某個(gè)Cookie信息：

• 請求的主機(jī)名是否與某個(gè)存儲的Cookie的Domain屬性匹配；

• 請求的端口號是否在該Cookie的Port屬性列表中；

• 請求的資源路徑是否在該Cookie的Path屬性指定的目錄及子目錄中；

• 該Cookie的有效期是否已過。

• Path屬性指向子目錄的Cookie排在Path屬性指向父目錄的Cookie之前。

• 舉例：Cookie: $Version=1; Course=Java; $Path=/hello/lesson; Course=vc; $Path=/hello

Cookie的安全屬性：

• secure屬性

  當(dāng)設(shè)置為true時(shí)，表示創(chuàng)建的 Cookie 會被以安全的形式向服務(wù)器傳輸，也就是只能在 HTTPS 連接中被瀏覽器傳遞到服務(wù)器端進(jìn)行會話驗(yàn)證，如果是 HTTP 連接則不會傳遞該信息，所以不會被竊取到Cookie 的具體內(nèi)容。

• HttpOnly屬性

  如果在Cookie中設(shè)置了”HttpOnly”屬性，那么通過程序(JS腳本、Applet等)將無法讀取到Cookie信息，這樣能有效的防止XSS攻擊。

secure屬性是防止信息在傳遞的過程中被監(jiān)聽捕獲后信息泄漏，HttpOnly屬性的目的是防止程序獲取cookie后進(jìn)行攻擊。

這兩個(gè)屬性并不能解決cookie在本機(jī)出現(xiàn)的信息泄漏的問題(FireFox的插件FireBug能直接看到cookie的相關(guān)信息)。

Session技術(shù)：

什么是Session？

使用Cookie和附加URL參數(shù)都可以將上一次請求的狀態(tài)信息傳遞到下一次請求中，但是如果傳遞的狀態(tài)信息較多，將極大降低網(wǎng)絡(luò)傳輸效率和增大服務(wù)器端程序處理的難度。

Session技術(shù)是一種將會話狀態(tài)保存在服務(wù)器端的技術(shù) ，它可以比喻成是醫(yī)院發(fā)放給病人的病歷卡和醫(yī)院為每個(gè)病人保留的病歷檔案的結(jié)合方式 。

客戶端需要接收、記憶和回送 Session的會話標(biāo)識號，Session可以且通常是借助Cookie來傳遞會話標(biāo)識號。

Session的跟蹤機(jī)制：

Servlet API規(guī)范中定義了一個(gè)HttpSession接口，HttpSession接口定義了各種管理和操作會話狀態(tài)的方法。

HttpSession對象是保持會話狀態(tài)信息的存儲結(jié)構(gòu)，一個(gè)客戶端在WEB服務(wù)器端對應(yīng)一個(gè)各自的HttpSession對象。

WEB服務(wù)器并不會在客戶端開始訪問它時(shí)就創(chuàng)建HttpSession對象，只有客戶端訪問某個(gè)能與客戶端開啟會話的Servlet程序時(shí)，WEB應(yīng)用程序才會創(chuàng)建一個(gè)與該客戶端對應(yīng)的HttpSession對象。

WEB服務(wù)器為HttpSession對象分配一個(gè)獨(dú)一無二的會話標(biāo)識號，然后在響應(yīng)消息中將這個(gè)會話標(biāo)識號傳遞給客戶端?？蛻舳诵枰涀挊?biāo)識號，并在后續(xù)的每次訪問請求中都把這個(gè)會話標(biāo)識號傳送給WEB服務(wù)器，WEB服務(wù)器端程序依據(jù)回傳的會話標(biāo)識號就知道這次請求是哪個(gè)客戶端發(fā)出的，從而選擇與之對應(yīng)的HttpSession對象。

WEB應(yīng)用程序創(chuàng)建了與某個(gè)客戶端對應(yīng)的HttpSession對象后，只要沒有超出一個(gè)限定的空閑時(shí)間段，HttpSession對象就駐留在WEB服務(wù)器內(nèi)存之中，該客戶端此后訪問任意的Servlet程序時(shí)，它們都使用與客戶端對應(yīng)的那個(gè)已存在的HttpSession對象。

HttpSession接口中專門定義了一個(gè)setAttribute方法來將對象存儲到HttpSession對象中，還定義了一個(gè)getAttribute方法來檢索存儲在HttpSession對象中的對象，存儲進(jìn)HttpSession對象中的對象可以被屬于同一個(gè)會話的各個(gè)請求的處理程序共享。

Session是實(shí)現(xiàn)網(wǎng)上商城的購物車的最佳方案，存儲在某個(gè)客戶Session中的一個(gè)集合對象就可充當(dāng)該客戶的一個(gè)購物車。

Session的超時(shí)管理：

WEB服務(wù)器無法判斷當(dāng)前的客戶端瀏覽器是否還會繼續(xù)訪問，也無法檢測客戶端瀏覽器是否關(guān)閉，所以，即使客戶已經(jīng)離開或關(guān)閉了瀏覽器，WEB服務(wù)器還要保留與之對應(yīng)的HttpSession對象。

隨著時(shí)間的推移而不斷增加新的訪問客戶端，WEB服務(wù)器內(nèi)存中將會因此積累起大量的不再被使用的HttpSession對象，并將最終導(dǎo)致服務(wù)器內(nèi)存耗盡。

WEB服務(wù)器采用“超時(shí)限制”的辦法來判斷客戶端是否還在繼續(xù)訪問，如果某個(gè)客戶端在一定的時(shí)間之內(nèi)沒有發(fā)出后續(xù)請求，WEB服務(wù)器則認(rèn)為客戶端已經(jīng)停止了活動，結(jié)束與該客戶端的會話并將與之對應(yīng)的HttpSession對象變成垃圾。

如果客戶端瀏覽器超時(shí)后再次發(fā)出訪問請求，WEB服務(wù)器則認(rèn)為這是一個(gè)新的會話的開始，將為之創(chuàng)建新的HttpSession對象和分配新的會話標(biāo)識號。

會話的超時(shí)間隔可以在web.xml文件中設(shè)置，其默認(rèn)值由Servlet容器定義。

利用Cookie實(shí)現(xiàn)Session跟蹤：

如果WEB服務(wù)器處理某個(gè)訪問請求時(shí)創(chuàng)建了新的HttpSession對象，它將把會話標(biāo)識號作為一個(gè)Cookie項(xiàng)加入到響應(yīng)消息中，通常情況下，瀏覽器在隨后發(fā)出的訪問請求中又將會話標(biāo)識號以Cookie的形式回傳給WEB服務(wù)器。

WEB服務(wù)器端程序依據(jù)回傳的會話標(biāo)識號就知道以前已經(jīng)為該客戶端創(chuàng)建了HttpSession對象，不必再為該客戶端創(chuàng)建新的HttpSession對象，而是直接使用與該會話標(biāo)識號匹配的HttpSession對象，通過這種方式就實(shí)現(xiàn)了對同一個(gè)客戶端的會話狀態(tài)的跟蹤。

利用URL重寫實(shí)現(xiàn)Session跟蹤：

Servlet規(guī)范中引入了一種補(bǔ)充的會話管理機(jī)制，它允許不支持Cookie的瀏覽器也可以與WEB服務(wù)器保持連續(xù)的會話。這種補(bǔ)充機(jī)制要求在響應(yīng)消息的實(shí)體內(nèi)容中必須包含下一次請求的超鏈接，并將會話標(biāo)識號作為超鏈接的URL地址的一個(gè)特殊參數(shù)。

將會話標(biāo)識號以參數(shù)形式附加在超鏈接的URL地址后面的技術(shù)稱為URL重寫。如果在瀏覽器不支持Cookie或者關(guān)閉了Cookie功能的情況下，WEB服務(wù)器還要能夠與瀏覽器實(shí)現(xiàn)有狀態(tài)的會話，就必須對所有可能被客戶端訪問的請求路徑（包括超鏈接、form表單的action屬性設(shè)置和重定向的URL）進(jìn)行URL重寫。

HttpServletResponse接口中定義了兩個(gè)用于完成URL重寫方法：

• encodeURL方法

• encodeRedirectURL方法

Cookie和Session的不同：

session和cookies同樣都是針對單獨(dú)用戶的變量（或者說是對象好像更合適點(diǎn)），不同的用戶在訪問網(wǎng)站的時(shí)候 都會擁有各自的session或者cookies，不同用戶之間互不干擾。

他們的不同點(diǎn)是：

1. 存儲位置不同

   session在服務(wù)器端產(chǎn)生，比較安全，但是如果session較多則會影響性能

   cookies在客戶端產(chǎn)生，安全性稍弱

2. 生命周期不同

   session生命周期 在指定的時(shí)間（如20分鐘）到了之后會結(jié)束，不到指定的時(shí)間，也會隨著瀏覽器進(jìn)程的結(jié)束而結(jié)束。

   cookies默認(rèn)情況下也隨著瀏覽器進(jìn)程結(jié)束而結(jié)束，但如果手動指定時(shí)間，則不受瀏覽器進(jìn)程結(jié)束的影響。

cookie 和session 的區(qū)別：

1. cookie數(shù)據(jù)存放在客戶的瀏覽器上，session數(shù)據(jù)放在服務(wù)器上。

2. cookie不是很安全，別人可以分析存放在本地的COOKIE并進(jìn)行COOKIE欺騙
   考慮到安全應(yīng)當(dāng)使用session

3. session會在一定時(shí)間內(nèi)保存在服務(wù)器上。當(dāng)訪問增多，會比較占用你服務(wù)器的性能

   考慮到減輕服務(wù)器性能方面，應(yīng)當(dāng)使用COOKIE

4. 單個(gè)cookie在客戶端的限制是3K，就是說一個(gè)站點(diǎn)在客戶端存放的COOKIE不能3K。