P2P技術，在分享大文件（你懂的）是現在必不可缺的技術，現在的人，已經很難想象在沒有這玩意的互聯網早期，人們是怎樣的艱難求生。想當年，不要說電影，下一個稍大點的文件，都是很吃力的事情。
后來牛人科恩，發明了P2P技術，見這里【科技英雄傳】BitTorrent技術之父：科恩
P2P技術發明后，其互聯網帶寬占到了7成以上，可見此技術的威力，網絡有多快，分享就有多快，速度不在受到終端或服務器限制，而是受到網絡，也就是道路的限制。真正回歸到網絡的本質。
作為程序員，我們經常為一個問題苦惱，就是性能，怎么讓服務器支撐更多的人，更多的訪問流量？這是一個大問題。
我們看看傳統的解決方案，不斷的提高服務器的並發，使用服務器緩存，使用大數據，使用分布式數據庫，使用CDN，加CPU，加內存，加帶寬，限制用戶數，等等等等。這些手段，都是治標不治本，中心或分中心模式，不管怎么做，最終都有問題，這也不是網絡模式。這就和買票一樣，都跑一個地方買，再快的搶票軟件也一樣沒用。
那么，有沒有可能，象P2P一樣，把網頁也給P2P了呢？從原理來看，其實是可行的。
原理是這樣的，比如我訪問這個頁面，那么數據已經在我瀏覽器里了，但是，我瀏覽器里的內容可以分享啊，通過P2P技術，其它用戶相互間分享同一時間的同一頁面內容，和P2P原理一樣，同一頁面訪問的人越多，那么速度反而越快。
如果有人能搞出頁面P2P技術，那么世界將再次被改變，任何頁面，都可以支撐全球所有的訪問量。從此網站再也不怕大用戶，用戶越多，網站越快，剛好和現在的模式相反，我們再也不需要優化網站了。
但是這種一籃子的解決方案，可不可行呢？有沒有人能搞出來呢？從原理來看是可行的，但實際上很困難。原因是很多頁面不僅僅只是靜態內容，而且頁面很復雜，文本，數據，圖片，甚至視頻。
但是部分的解決方案還是有的，比如雲服務，把圖片，視頻等放在第三方，CDN服務，把一些公用代碼放第三方，還有網頁加速服務，比如什么數字的風行計划，給網站緩存加速。
當然了，上述這些解決方案，都是很費事又費錢的東西，最好就是瀏覽器支持本身支持網頁P2P，但這個技術看上去，這幾年都不用指望了，作為創業者或中小企業網站，有沒有成本更低廉的辦法，解決性能問題？
這就可以使用一些Html5的先進技術了，Html支持本地存儲，和本地緩存，但對於動態加載的頁面可能還需要自已進一步編碼，如果我們把樣式表，代碼，通用數據，圖片，在第一次加載后，再用腳本方式存在本地數據庫，當然這得需要一個版本管理技術。
這樣的話，除了第一次慢點，以后因為有大量內容被緩存到了本地，那么Web應用就有點類似傳統的C/S應用了。服務器端的壓力被大大減輕。
但是，用戶多了服務器還是一樣有性能問題，能不能在A客戶緩存了本地數據以后，B客戶訪問網站時，直接把A客戶，導向B客戶，讓A客戶取得B客戶的緩存數據呢？
答案是可以的，但不是現在，W3C正在開發P2P瀏覽器標准，讓你的瀏覽器和他的瀏覽器實時通信，不需要經過服務器，可見此技術，在將來是可行的，但現在沒有足夠的支撐。
由此可見，現在如果利用Html5技術，解決如下幾個問題：
一是本地存儲的版本問題，這樣服務器更新后，就從服務器上取新數據，如果沒有更新就讀取本地緩存。
二是本地存儲的讀取寫入，以及路徑問題，這需要有一種機制，讓應用不需要管數據的來源是本地還是服務器，把資源路由交給一個統一機制，由它去判斷
版本問題有比較現成的解決思路，比如時間過期，或者是版本號，加個二維碼什么的。資源路由就不太清楚，這需要進一步的摸索。但是，優先考慮Html5的本地存儲及緩存技術，應該是一個低成本解決性能問題的方案。而這種方案，還可以為將來到來的瀏覽器P2P做准備。