在網(wǎng)站統(tǒng)計(jì)中，我們最常用的是用 Cookie標(biāo)識(shí)身份，由于瀏覽器自帶的 Cookie容易被用戶(hù)刪除。于是很多人使用 Flash Cookie來(lái)跟蹤用戶(hù)的信息。但是在目前360等軟件幫助下，刪除Flash Cookie也變得非常的簡(jiǎn)單。那么有沒(méi)有什么方法讓Cookie無(wú)法刪除呢？答案是有的！做開(kāi)發(fā)的基本上都理解災(zāi)備機(jī)制。即一臺(tái)服務(wù)器如果出現(xiàn)了故障，則可由由另一臺(tái)恢復(fù)回去。比如Cookie一旦刪除后，這可通過(guò)Flash Cookies進(jìn)行恢復(fù)。另外，除了Cookie和Flash Cookie外，到底還有哪些方式可以用來(lái)進(jìn)行“用戶(hù)識(shí)別”。

1、標(biāo)準(zhǔn)的 Http Cookie

HTTP Cookie是最常的用于“用戶(hù)識(shí)別”的方式，以下為服務(wù)器與Cookie之間的交互流程：

1. 當(dāng)我們用瀏覽器訪問(wèn)一個(gè)網(wǎng)站的時(shí)候，就會(huì)想服務(wù)器發(fā)起一個(gè)請(qǐng)求。
2. 根據(jù)請(qǐng)求的url和cookie本身的屬性，篩選出需要發(fā)送給服務(wù)器的cookie（當(dāng)然也有可能沒(méi)有cookie）。
3. 如果有多個(gè)cookie的話(huà)，還會(huì)決定發(fā)送的順序。
4. 把這些需要發(fā)送的cookie包含在HTTP的包頭里發(fā)送給服務(wù)器。
5. 然后到了應(yīng)答階段，服務(wù)器會(huì)發(fā)回一個(gè)應(yīng)答包頭，包頭里包含了cookie信息。
6. 瀏覽器解析這個(gè)cookie，包括名稱(chēng)，值，路徑等元素。
7. 最后，把cookie保存在本地。

至于哪些cookie會(huì)被發(fā)送到服務(wù)器端，是有一套規(guī)則的，例如域名選擇、路徑選擇和Max-Age選擇，這些都可以在RFC2109里找到。

每次的http請(qǐng)求，cookie都會(huì)包含在包頭里發(fā)送給服務(wù)器，這也是被開(kāi)發(fā)者廣為詬病的一個(gè)cookie缺點(diǎn)，因?yàn)檫@意味這每個(gè)請(qǐng)求都無(wú)形中增加了流量，特別是像請(qǐng)求圖片這些資源的時(shí)候，附帶的cookie信息是完全沒(méi)有必要的。所以現(xiàn)在很多網(wǎng)站圖片等靜態(tài)資源都會(huì)用獨(dú)立的域名運(yùn)作，這樣就可以單獨(dú)對(duì)這些域名進(jìn)行cookie設(shè)置。 除此以外，cookie還有以下影響比較大的缺點(diǎn)：

• 安全性問(wèn)題。cookie在http請(qǐng)求中是明文傳遞的，除非使用SSL通道，不然是不宜在cookie里放置重要信息。
• 大小問(wèn)題。每個(gè)cookie的大小不能超過(guò)4K。每個(gè)Domain下cookie個(gè)數(shù)根據(jù)瀏覽器不同也不同。

關(guān)于Cookies的一些限制問(wèn)題，可以參考下Nicholas的一篇文章： 瀏覽器允許的每個(gè)域名下的Cookie數(shù)：

• IE7跟IE8限制為50個(gè)。
• Firefox限制為50個(gè)。
• Opera限制30個(gè)
• Safari/WebKit沒(méi)有限制，但是如果header的大小超過(guò)服務(wù)器能處理的情況下，則會(huì)出現(xiàn)錯(cuò)誤。

那如果Cookie數(shù)設(shè)置超過(guò)限制的時(shí)候，各瀏覽器又是如何處理呢：

• Safari由于沒(méi)有Cookie數(shù)的限制，所以不作討論。
• 在IE和Opera下，將會(huì)采用LRU（The Least Recently Used）方法，自動(dòng)踢掉最老的cookie以騰出空間給新的cookie。IE和Opera使用這個(gè)方法。
• Firefox就比較獨(dú)特：它貌似會(huì)隨機(jī)決定哪些cookie將會(huì)保留，盡管最后設(shè)置的cookie會(huì)被保留。所以在Firefox里不要超過(guò)cookie數(shù)的限制。

cookie的總大小在各瀏覽器中也是不同的：

• Firefox和Safari允許cookie多達(dá)4097個(gè)字節(jié)，其中4096個(gè)字節(jié)是名字和值，1個(gè)字節(jié)是=號(hào)。
• Opera允許cookie多達(dá)4096個(gè)字節(jié)，這些字節(jié)包含名字、值和=號(hào)。
• IE允許4095個(gè)字節(jié)，這些字節(jié)包含名字、值和=號(hào)。

注意這里用的字節(jié)，也就是，如果是多字節(jié)字符，自然就會(huì)占用兩個(gè)字節(jié)。在所有瀏覽器里，如果設(shè)置的cookie大小超過(guò)限制，那么它就會(huì)被忽略或者不被設(shè)置。

從上面，我們可以看到，Cookie確實(shí)存在一些不足，但是它的一些缺點(diǎn)也正是它的優(yōu)點(diǎn)，例如每個(gè)請(qǐng)求都會(huì)被放到包頭里發(fā)送給服務(wù)器，正是這個(gè)特性我們才能很方便的傳輸sessionid。Cookie的出現(xiàn)可謂大大推動(dòng)了網(wǎng)頁(yè)的發(fā)展，而且在未來(lái)很長(zhǎng)的一段時(shí)間里，Cookie還會(huì)繼續(xù)發(fā)揮它的作用。但是也正是由于Cookie存在種種的不足，才會(huì)有新的本地存儲(chǔ)技術(shù)出現(xiàn)的需求。

2、Local Shared Objects (Flash Cookies)

Local Shared Objects 即本地共享對(duì)象，長(zhǎng)被稱(chēng)為Flash Cookie。Flash Cookies是由Adobe公司開(kāi)發(fā)的一個(gè)技術(shù)，該技術(shù)允許Flash對(duì)象在每個(gè)域名上存儲(chǔ)100KB的數(shù)據(jù)。LSO解決了Cookie的一些問(wèn)題，例如大小，安全等。跟Cookie不同，LSO被保存為二進(jìn)制文件（不過(guò)變量名具有可讀性）。LSO具有了不少優(yōu)點(diǎn)，但是缺點(diǎn)也是明顯，就是它需要安裝Flash這個(gè)插件。雖然現(xiàn)在Flash的普及率很高，但是這種依賴(lài)插件的技術(shù)始終不能解決問(wèn)題的根源，而且為了使用這個(gè)方案不得不引入額外的swf和js文件。另外IE8開(kāi)始和Chrome在刪除歷史記錄的時(shí)候會(huì)將Flash Cookie刪除掉。

3、Silverlight Isolated Storage

獨(dú)立存儲(chǔ)（Isolated Storage）是Silverlight 2中提供的一個(gè)客戶(hù)端安全的存儲(chǔ)，它是一個(gè)與Cookie機(jī)制類(lèi)似的局部信任機(jī)制。獨(dú)立存儲(chǔ)機(jī)制的APIs 提供了一個(gè)虛擬的文件系統(tǒng)和可以訪問(wèn)這個(gè)虛擬文件系統(tǒng)的數(shù)據(jù)流對(duì)象。Silverlight中的獨(dú)立存儲(chǔ)是基于 .NET Framework中的獨(dú)立存儲(chǔ)來(lái)建立的，所以它僅僅是.NET Framework中獨(dú)立存儲(chǔ)的一個(gè)子集。

Silverlight中的獨(dú)立存儲(chǔ)有以下一些特征:

1. 每個(gè)基于Silverlight的應(yīng)用程序都被分配了屬于它自己的一部分存儲(chǔ)空間, 但是應(yīng)用程序中的程序集卻是在存儲(chǔ)空間中共享的。一個(gè)應(yīng)用程序被服務(wù)器賦給了一個(gè)唯一的固定的標(biāo)識(shí)值?；赟ilverlight的應(yīng)用程序的虛擬文件系統(tǒng)現(xiàn)在就以一個(gè)標(biāo)識(shí)值的方式來(lái)訪問(wèn)了。這個(gè)標(biāo)識(shí)值必須是一個(gè)常量，這樣每次應(yīng)用程序運(yùn)行時(shí)才可以找到這個(gè)共享的位置。
2. 獨(dú)立存儲(chǔ)的APIs 其實(shí)和其它的文件操作APIs類(lèi)似，比如 File 和 Directory 這些用來(lái)訪問(wèn)和維護(hù)文件或文件夾的類(lèi)。 它們都是基于FileStream APIs 來(lái)維護(hù)文件的內(nèi)容的。
3. 獨(dú)立存儲(chǔ)嚴(yán)格的限制了應(yīng)用程序可以存儲(chǔ)的數(shù)據(jù)的大小，目前的上限是每個(gè)應(yīng)用程序?yàn)? MB。

4、IE瀏覽器 userData 存儲(chǔ)   (從IE9開(kāi)始， 不再支持 userData)

userData是微軟在第一次瀏覽器大戰(zhàn)中的產(chǎn)物，屬于DHTML中的一種技術(shù)。相比起Cookie，userData在每個(gè)域名下可存儲(chǔ)達(dá)的數(shù)據(jù)提升了不少，但是具體的大小視domain的安全域而定。userData的數(shù)據(jù)會(huì)一直存在，直到被刪除或者到過(guò)期時(shí)間。并且基于安全的考慮，一個(gè) userData 存儲(chǔ)區(qū)只能用于同一目錄和對(duì)同一協(xié)議進(jìn)行存儲(chǔ)。userData在數(shù)據(jù)的本地儲(chǔ)存來(lái)說(shuō)，比cookie進(jìn)步了不少，但是它有個(gè)致命的缺點(diǎn)：僅支持IE。僅憑這一點(diǎn)，就注定了userData并不會(huì)有太大的作為，只能用作配合其他本地存儲(chǔ)技術(shù)兼容低版本的IE。

5、利用 HTTP ETags 存儲(chǔ)Cookie

Etag 是URL的Entity Tag，用于標(biāo)示URL對(duì)象是否改變，區(qū)分不同語(yǔ)言和Session等等。具體內(nèi)部含義是使服務(wù)器控制的，就像Cookie那樣。

HTTP協(xié)議規(guī)格說(shuō)明定義ETag為“被請(qǐng)求變量的實(shí)體值” 。另一種說(shuō)法是，ETag是一個(gè)可以與Web資源關(guān)聯(lián)的記號(hào)（token）。典型的Web資源可以一個(gè)Web頁(yè)，但也可能是JSON或XML文檔。服務(wù)器單獨(dú)負(fù)責(zé)判斷記號(hào)是什么及其含義，并在HTTP響應(yīng)頭中將其傳送到客戶(hù)端。

6、在瀏覽器歷史記錄中存儲(chǔ)cookie

大家都知道，用戶(hù)訪問(wèn)過(guò)一次頁(yè)面，就會(huì)存儲(chǔ)在瀏覽器瀏覽歷史里面，這個(gè)方法就是利用瀏覽器的這個(gè)特性。通過(guò)新建一個(gè)iframe去訪問(wèn)這個(gè)頁(yè)面。如默認(rèn)的url是http://www.example.com/test/。

那他發(fā)送的路徑會(huì)是加上了name跟value的。這里的name跟value分別是id跟123456，如

http://www.example.com/test/id/123456

發(fā)送方法為每個(gè)字母遞增發(fā)送,并在最后加個(gè)”-“的結(jié)束符號(hào)

http://www.example.com/test/i

http://www.example.com/test/id

…

http://www.example.com/test/id/123456

http://www.example.com/test/id/123456-

那要相應(yīng)的name value他是這樣獲取的。

默認(rèn)url加上 ”ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/=-“。其中一個(gè)字符，看看是否存在歷史記錄里面。不存在則循環(huán)查找下一個(gè)。如果這里查到i是訪問(wèn)過(guò)的 ，則繼續(xù)循環(huán)，在i的后面循環(huán)檢查。繼而又查到d是訪問(wèn)過(guò)的。一直循環(huán)知道出現(xiàn)’-‘符號(hào)為止。繼而解析獲取到的字符串，那name value自然也就解析出來(lái)。

但這樣做的弊端很大。首先，必須要連續(xù)發(fā)送n個(gè)url，用戶(hù)體驗(yàn)不好。獲取的時(shí)候要遍歷，也影響了瀏覽器的性能。所以不推薦。

7、使用PNG像素圖片保存Cookie

以自動(dòng)生成、強(qiáng)制緩存的PNG像素圖片的RGB值形式保存cookie，使用HTML5 Canvas標(biāo)簽讀取像素圖片（cookie）。

服務(wù)器創(chuàng)建一個(gè)寬100像素高1像素的黑色空白PNG（每個(gè)像素的RGB 顏色可存儲(chǔ)3個(gè)字節(jié)，可存儲(chǔ)600字節(jié)信息），然后將值拆分并按順序每3個(gè)字母生成一個(gè)RGB顏色值并且按順序設(shè)置到圖片的像素點(diǎn)中，然后給這個(gè)圖片設(shè)置一個(gè)expires非常長(zhǎng)的時(shí)間（Expire 頭，用于客戶(hù)端緩存，不同于cookie的expire屬性）讀取的時(shí)候取出并且解析還原出來(lái)。要求瀏覽器必須支持html5才能用上此方法。ie8，ie9，ff，chrome，safari都是 ok的。

8、使用window.name儲(chǔ)存Cookie

window.name 傳輸技術(shù)，原本是 Thomas Frank 用于解決 cookie 的一些劣勢(shì)（每個(gè)域名 4 x 20 Kb 的限制、數(shù)據(jù)只能是字符串、設(shè)置和獲取 cookie 語(yǔ)法的復(fù)雜等等）而發(fā)明的（詳細(xì)見(jiàn)原文：《Session variables without cookies》），后來(lái) Kris Zyp 在此方法的基礎(chǔ)上強(qiáng)化了 window.name 傳輸 ，并引入到了 Dojo （dojox.io.windowName），用來(lái)解決跨域數(shù)據(jù)傳輸問(wèn)題。

window.name 的美妙之處：name 值在不同的頁(yè)面（甚至不同域名）加載后依舊存在，并且可以支持非常長(zhǎng)的 name 值（2MB）。

name 在瀏覽器環(huán)境中是一個(gè)全局/window對(duì)象的屬性，且當(dāng)在 frame 中加載新頁(yè)面時(shí)，name 的屬性值依舊保持不變。通過(guò)在 iframe 中加載一個(gè)資源，該目標(biāo)頁(yè)面將設(shè)置 frame 的 name 屬性。此 name 屬性值可被獲取到，以訪問(wèn) Web 服務(wù)發(fā)送的信息。但 name 屬性?xún)H對(duì)相同域名的 frame 可訪問(wèn)。這意味著為了訪問(wèn) name 屬性，當(dāng)遠(yuǎn)程 Web 服務(wù)頁(yè)面被加載后，必須導(dǎo)航 frame 回到原始域。同源策略依舊防止其他 frame 訪問(wèn) name 屬性。一旦 name 屬性獲得，銷(xiāo)毀 frame 。

在最頂層，name 屬性是不安全的，對(duì)于所有后續(xù)頁(yè)面，設(shè)置在 name 屬性中的任何信息都是可獲得的。然而 windowName 模塊總是在一個(gè) iframe 中加載資源，并且一旦獲取到數(shù)據(jù)，或者當(dāng)你在最頂層瀏覽了一個(gè)新頁(yè)面，這個(gè) iframe 將被銷(xiāo)毀，所以其他頁(yè)面永遠(yuǎn)訪問(wèn)不到 window.name 屬性。

window.name 傳輸技術(shù)相比其他的跨域傳輸?shù)囊恍﹥?yōu)勢(shì)：

1. 它是安全的。也就是說(shuō)，它和其他的基于安全傳輸?shù)?frame 一樣安全，例如 Fragment Identifier messaging （FIM）和 Subspace。(I)Frames 也有他們自己的安全問(wèn)題，由于 frame 可以改變其他 frame 的 location，但是這個(gè)是非常不同的安全溢出，通常不太嚴(yán)重。
2. 它比 FIM 更快，因?yàn)樗挥锰幚硇?shù)據(jù)包大小的 Fragment Identifier ，并且它不會(huì)有更多的 IE 上的“機(jī)關(guān)槍”聲音效果。它也比 Subspace 快，Subspace 需要加載兩個(gè) Iframe 和兩個(gè)本地的 HTML 文件來(lái)處理一個(gè)請(qǐng)求。window.name 僅需要一個(gè) Iframe 和一個(gè)本地文件。
3. 它比 FIM 和 Subspace 更簡(jiǎn)單和安全。FIM 稍微復(fù)雜，而 Subspace 非常復(fù)雜。Subspace 也有一些額外的限制和安裝要求，如預(yù)先聲明所有的目標(biāo)主機(jī)和擁有針對(duì)若干不同特殊主機(jī)的 DNS 入口。window.name 非常簡(jiǎn)單和容易使用。
4. 它不需要任何插件（比如 Flash）或者替代技術(shù)（例如 Java）。

9、使用HTML5客戶(hù)端儲(chǔ)存數(shù)據(jù)方法。

HTML5 提供了四種在客戶(hù)端存儲(chǔ)數(shù)據(jù)的新方法，即

• HTML5 Session Storage
• HTML5 Local Storage
• HTML5 Global Storage
• HTML5 Database Storage via SQLite

HTML5 Session Storage顧名思義它就如同Session。 針對(duì)一個(gè) session 的數(shù)據(jù)存儲(chǔ)，任何一個(gè)頁(yè)面存儲(chǔ)的信息在窗口中同一網(wǎng)站的任何頁(yè)面都可以訪問(wèn)它存儲(chǔ)的數(shù)據(jù)。每個(gè)窗口的值都是獨(dú)立的，它的數(shù)據(jù)會(huì)因窗口的關(guān)閉而丟失，不同窗口間的sessionStorage是不可以共享的。

HTML5 Local Storage 沒(méi)有時(shí)間限制的數(shù)據(jù)存儲(chǔ)，第二天、第二周或下一年之后，數(shù)據(jù)依然可用。也就是說(shuō)，localStorage是永遠(yuǎn)不會(huì)過(guò)期的，除非主動(dòng)刪除數(shù)據(jù)。數(shù)據(jù)可跨越多個(gè)窗口，無(wú)視當(dāng)前會(huì)話(huà)，被共同訪問(wèn)、使用。

HTML5 Global Storage 同HTML5 Session Storage一樣，區(qū)別在于其在瀏覽器關(guān)閉后，可以將存儲(chǔ)的信息仍能夠保留下來(lái)。目前只有FireFox支持，且只支持當(dāng)前域下的存儲(chǔ)。

HTML5 Database Storage via SQLite （目前只谷歌瀏覽器支持）：可以理解成一個(gè)Html5環(huán)境下可以用Js執(zhí)行CRUD的Web數(shù)據(jù)庫(kù)。對(duì)于簡(jiǎn)單的數(shù)據(jù)，使用sessionStorage和localStorage能夠很好地完成存取，但是對(duì)于處理復(fù)雜的關(guān)系型數(shù)據(jù)，它就力不從心了。這也是 HTML 5 的“Web SQL Database”API 接口的應(yīng)用所在。

一些常見(jiàn)的用來(lái)標(biāo)注用戶(hù)身份的方法已經(jīng)介紹過(guò)了，接下來(lái)要講解的是如何使用。Evercookie是一個(gè)JavaScript API，通過(guò)它可以在瀏覽器中生成極其持久的cookie。它的目標(biāo)就是在用戶(hù)刪除了傳統(tǒng)cookie、Flash cookie（LSO）和其他緩存數(shù)據(jù)后，仍然可以識(shí)別客戶(hù)端。Evercookie是通過(guò)利用瀏覽器不同的存儲(chǔ)機(jī)制，把cookie數(shù)據(jù)保存在多個(gè)不同的地方實(shí)現(xiàn)的。此外，如果發(fā)現(xiàn)用戶(hù)刪除了其中一些cookie，Evercookie會(huì)利用這些機(jī)制重新創(chuàng)建它們。

雖然Evercookie非常的強(qiáng)大，但是個(gè)人覺(jué)得大部分功能都比較花俏。如evercookie_png，evercookie_etag，evercookie_history，實(shí)際上這些操作均會(huì)對(duì)用戶(hù)體驗(yàn)有一定影響。不過(guò)也體現(xiàn)了evercookie的宗旨：為了記錄用戶(hù)信息，無(wú)所不用其極。但針對(duì)于國(guó)內(nèi)用戶(hù)大部分為ie用戶(hù)，而且很多網(wǎng)站是ie only，完全可把evercookie_userdata納入考慮范圍。同時(shí)一般情況下，裝有silverlight插件的瀏覽器，幾乎必然也裝著flash插件。所以首選flash方案。

Evercookie被認(rèn)為是一項(xiàng)很邪惡的技術(shù)，事實(shí)上作者Kamkar的座右銘是“think bad, do good”。Kamkar說(shuō)，他寫(xiě)evercookie是為了向用戶(hù)展示公司可以跟蹤他們的方法。

“我希望evercookie只是向人們演示跟蹤他們的是何種方法，由他們決定他們是否應(yīng)該阻止這些方法，我作為一個(gè)安全業(yè)余愛(ài)好者，寫(xiě)evercookie也才用了不到一天的時(shí)間，因此我很容易想像那些受雇的開(kāi)發(fā)者可以做出什么來(lái)?！?/p>

有證據(jù)表明，Hulu、AOL和Spotify等網(wǎng)站已經(jīng)開(kāi)始在自己的網(wǎng)站上使用EverCookies。

參考鏈接：

http://en.wikipedia.org/wiki/HTTP_cookie

http://en.wikipedia.org/wiki/Zombie_cookie

http://samy.pl/evercookie/

https://github.com/samyk/evercookie