狠狠色丁香婷婷综合尤物/久久精品综合一区二区三区/中国有色金属学报/国产日韩欧美在线观看 - 国产一区二区三区四区五区tv

在網站統計中，我們最常用的是用 Cookie標識身份，由于瀏覽器自帶的 Cookie容易被用戶刪除。于是很多人使用 Flash Cookie來跟蹤用戶的信息。但是在目前360等軟件幫助下，刪除Flash Cookie也變得非常的簡單。那么有沒有什么方法讓Cookie無法刪除呢？答案是有的！做開發的基本上都理解災備機制。即一臺服務器如果出現了故障，則可由由另一臺恢復回去。比如Cookie一旦刪除后，這可通過Flash Cookies進行恢復。另外，除了Cookie和Flash Cookie外，到底還有哪些方式可以用來進行“用戶識別”。

1、標準的 Http Cookie

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

1. 當我們用瀏覽器訪問一個網站的時候，就會想服務器發起一個請求。
2. 根據請求的url和cookie本身的屬性，篩選出需要發送給服務器的cookie（當然也有可能沒有cookie）。
3. 如果有多個cookie的話，還會決定發送的順序。
4. 把這些需要發送的cookie包含在HTTP的包頭里發送給服務器。
5. 然后到了應答階段，服務器會發回一個應答包頭，包頭里包含了cookie信息。
6. 瀏覽器解析這個cookie，包括名稱，值，路徑等元素。
7. 最后，把cookie保存在本地。

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

每次的http請求，cookie都會包含在包頭里發送給服務器，這也是被開發者廣為詬病的一個cookie缺點，因為這意味這每個請求都無形中增加了流量，特別是像請求圖片這些資源的時候，附帶的cookie信息是完全沒有必要的。所以現在很多網站圖片等靜態資源都會用獨立的域名運作，這樣就可以單獨對這些域名進行cookie設置。 除此以外，cookie還有以下影響比較大的缺點：

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

關于Cookies的一些限制問題，可以參考下Nicholas的一篇文章： 瀏覽器允許的每個域名下的Cookie數：

• IE7跟IE8限制為50個。
• Firefox限制為50個。
• Opera限制30個
• Safari/WebKit沒有限制，但是如果header的大小超過服務器能處理的情況下，則會出現錯誤。

那如果Cookie數設置超過限制的時候，各瀏覽器又是如何處理呢：

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

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

• Firefox和Safari允許cookie多達4097個字節，其中4096個字節是名字和值，1個字節是=號。
• Opera允許cookie多達4096個字節，這些字節包含名字、值和=號。
• IE允許4095個字節，這些字節包含名字、值和=號。

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

從上面，我們可以看到，Cookie確實存在一些不足，但是它的一些缺點也正是它的優點，例如每個請求都會被放到包頭里發送給服務器，正是這個特性我們才能很方便的傳輸sessionid。Cookie的出現可謂大大推動了網頁的發展，而且在未來很長的一段時間里，Cookie還會繼續發揮它的作用。但是也正是由于Cookie存在種種的不足，才會有新的本地存儲技術出現的需求。

2、Local Shared Objects (Flash Cookies)

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

3、Silverlight Isolated Storage

獨立存儲（Isolated Storage）是Silverlight 2中提供的一個客戶端安全的存儲，它是一個與Cookie機制類似的局部信任機制。獨立存儲機制的APIs 提供了一個虛擬的文件系統和可以訪問這個虛擬文件系統的數據流對象。Silverlight中的獨立存儲是基于 .NET Framework中的獨立存儲來建立的，所以它僅僅是.NET Framework中獨立存儲的一個子集。

Silverlight中的獨立存儲有以下一些特征:

1. 每個基于Silverlight的應用程序都被分配了屬于它自己的一部分存儲空間, 但是應用程序中的程序集卻是在存儲空間中共享的。一個應用程序被服務器賦給了一個唯一的固定的標識值。基于Silverlight的應用程序的虛擬文件系統現在就以一個標識值的方式來訪問了。這個標識值必須是一個常量，這樣每次應用程序運行時才可以找到這個共享的位置。
2. 獨立存儲的APIs 其實和其它的文件操作APIs類似，比如 File 和 Directory 這些用來訪問和維護文件或文件夾的類。 它們都是基于FileStream APIs 來維護文件的內容的。
3. 獨立存儲嚴格的限制了應用程序可以存儲的數據的大小，目前的上限是每個應用程序為1 MB。

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

userData是微軟在第一次瀏覽器大戰中的產物，屬于DHTML中的一種技術。相比起Cookie，userData在每個域名下可存儲達的數據提升了不少，但是具體的大小視domain的安全域而定。userData的數據會一直存在，直到被刪除或者到過期時間。并且基于安全的考慮，一個 userData 存儲區只能用于同一目錄和對同一協議進行存儲。userData在數據的本地儲存來說，比cookie進步了不少，但是它有個致命的缺點：僅支持IE。僅憑這一點，就注定了userData并不會有太大的作為，只能用作配合其他本地存儲技術兼容低版本的IE。

5、利用 HTTP ETags 存儲Cookie

Etag 是URL的Entity Tag，用于標示URL對象是否改變，區分不同語言和Session等等。具體內部含義是使服務器控制的，就像Cookie那樣。

HTTP協議規格說明定義ETag為“被請求變量的實體值” 。另一種說法是，ETag是一個可以與Web資源關聯的記號（token）。典型的Web資源可以一個Web頁，但也可能是JSON或XML文檔。服務器單獨負責判斷記號是什么及其含義，并在HTTP響應頭中將其傳送到客戶端。

6、在瀏覽器歷史記錄中存儲cookie

大家都知道，用戶訪問過一次頁面，就會存儲在瀏覽器瀏覽歷史里面，這個方法就是利用瀏覽器的這個特性。通過新建一個iframe去訪問這個頁面。如默認的url是http://www.example.com/test/。

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

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

發送方法為每個字母遞增發送,并在最后加個”-“的結束符號

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-

那要相應的name value他是這樣獲取的。

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

但這樣做的弊端很大。首先，必須要連續發送n個url，用戶體驗不好。獲取的時候要遍歷，也影響了瀏覽器的性能。所以不推薦。

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

以自動生成、強制緩存的PNG像素圖片的RGB值形式保存cookie，使用HTML5 Canvas標簽讀取像素圖片（cookie）。

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

8、使用window.name儲存Cookie

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

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

name 在瀏覽器環境中是一個全局/window對象的屬性，且當在 frame 中加載新頁面時，name 的屬性值依舊保持不變。通過在 iframe 中加載一個資源，該目標頁面將設置 frame 的 name 屬性。此 name 屬性值可被獲取到，以訪問 Web 服務發送的信息。但 name 屬性僅對相同域名的 frame 可訪問。這意味著為了訪問 name 屬性，當遠程 Web 服務頁面被加載后，必須導航 frame 回到原始域。同源策略依舊防止其他 frame 訪問 name 屬性。一旦 name 屬性獲得，銷毀 frame 。

在最頂層，name 屬性是不安全的，對于所有后續頁面，設置在 name 屬性中的任何信息都是可獲得的。然而 windowName 模塊總是在一個 iframe 中加載資源，并且一旦獲取到數據，或者當你在最頂層瀏覽了一個新頁面，這個 iframe 將被銷毀，所以其他頁面永遠訪問不到 window.name 屬性。

window.name 傳輸技術相比其他的跨域傳輸的一些優勢：

1. 它是安全的。也就是說，它和其他的基于安全傳輸的 frame 一樣安全，例如 Fragment Identifier messaging （FIM）和 Subspace。(I)Frames 也有他們自己的安全問題，由于 frame 可以改變其他 frame 的 location，但是這個是非常不同的安全溢出，通常不太嚴重。
2. 它比 FIM 更快，因為它不用處理小數據包大小的 Fragment Identifier ，并且它不會有更多的 IE 上的“機關槍”聲音效果。它也比 Subspace 快，Subspace 需要加載兩個 Iframe 和兩個本地的 HTML 文件來處理一個請求。window.name 僅需要一個 Iframe 和一個本地文件。
3. 它比 FIM 和 Subspace 更簡單和安全。FIM 稍微復雜，而 Subspace 非常復雜。Subspace 也有一些額外的限制和安裝要求，如預先聲明所有的目標主機和擁有針對若干不同特殊主機的 DNS 入口。window.name 非常簡單和容易使用。
4. 它不需要任何插件（比如 Flash）或者替代技術（例如 Java）。

9、使用HTML5客戶端儲存數據方法。

HTML5 提供了四種在客戶端存儲數據的新方法，即

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

HTML5 Session Storage顧名思義它就如同Session。 針對一個 session 的數據存儲，任何一個頁面存儲的信息在窗口中同一網站的任何頁面都可以訪問它存儲的數據。每個窗口的值都是獨立的，它的數據會因窗口的關閉而丟失，不同窗口間的sessionStorage是不可以共享的。

HTML5 Local Storage 沒有時間限制的數據存儲，第二天、第二周或下一年之后，數據依然可用。也就是說，localStorage是永遠不會過期的，除非主動刪除數據。數據可跨越多個窗口，無視當前會話，被共同訪問、使用。

HTML5 Global Storage 同HTML5 Session Storage一樣，區別在于其在瀏覽器關閉后，可以將存儲的信息仍能夠保留下來。目前只有FireFox支持，且只支持當前域下的存儲。

HTML5 Database Storage via SQLite （目前只谷歌瀏覽器支持）：可以理解成一個Html5環境下可以用Js執行CRUD的Web數據庫。對于簡單的數據，使用sessionStorage和localStorage能夠很好地完成存取，但是對于處理復雜的關系型數據，它就力不從心了。這也是 HTML 5 的“Web SQL Database”API 接口的應用所在。

一些常見的用來標注用戶身份的方法已經介紹過了，接下來要講解的是如何使用。Evercookie是一個JavaScript API，通過它可以在瀏覽器中生成極其持久的cookie。它的目標就是在用戶刪除了傳統cookie、Flash cookie（LSO）和其他緩存數據后，仍然可以識別客戶端。Evercookie是通過利用瀏覽器不同的存儲機制，把cookie數據保存在多個不同的地方實現的。此外，如果發現用戶刪除了其中一些cookie，Evercookie會利用這些機制重新創建它們。

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

Evercookie被認為是一項很邪惡的技術，事實上作者Kamkar的座右銘是“think bad, do good”。Kamkar說，他寫evercookie是為了向用戶展示公司可以跟蹤他們的方法。

“我希望evercookie只是向人們演示跟蹤他們的是何種方法，由他們決定他們是否應該阻止這些方法，我作為一個安全業余愛好者，寫evercookie也才用了不到一天的時間，因此我很容易想像那些受雇的開發者可以做出什么來。”

有證據表明，Hulu、AOL和Spotify等網站已經開始在自己的網站上使用EverCookies。

參考鏈接：

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

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

http://samy.pl/evercookie/

https://github.com/samyk/evercookie