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做準備。