A. 瀏覽器採用http 協議訪問網頁的工作過程
1. 首先嘛，你得在瀏覽器里輸入要網址:
2. 瀏覽器查找域名的IP地址
導航的第一步是通過訪問的域名找出其IP地址。DNS查找過程如下：
瀏覽器緩存 – 瀏覽器會緩存DNS記錄一段時間。 有趣的是，操作系統沒有告訴瀏覽器儲存DNS記錄的時間，這樣不同瀏覽器會儲存個自固定的一個時間（2分鍾到30分鍾不等）。
系統緩存 – 如果在瀏覽器緩存里沒有找到需要的記錄，瀏覽器會做一個系統調用（windows里是gethostbyname）。這樣便可獲得系統緩存中的記錄。
路由器緩存 – 接著，前面的查詢請求發向路由器，它一般會有自己的DNS緩存。
ISP DNS 緩存 – 接下來要check的就是ISP緩存DNS的伺服器。在這一般都能找到相應的緩存記錄。
遞歸搜索 – 你的ISP的DNS伺服器從跟域名伺服器開始進行遞歸搜索，從.com頂級域名伺服器到Facebook的域名伺服器。一般DNS伺服器的緩存中會有.com域名伺服器中的域名，所以到頂級伺服器的匹配過程不是那麼必要了。
DNS遞歸查找如下圖所示：
DNS有一點令人擔憂，這就是像wikipedia.org 或者 facebook.com這樣的整個域名看上去只是對應一個單獨的IP地址。還好，有幾種方法可以消除這個瓶頸：
循環 DNS 是DNS查找時返回多個IP時的解決方案。舉例來說，Facebook.com實際上就對應了四個IP地址。
負載平衡器 是以一個特定IP地址進行偵聽並將網路請求轉發到集群伺服器上的硬體設備。 一些大型的站點一般都會使用這種昂貴的高性能負載平衡器。
地理 DNS 根據用戶所處的地理位置，通過把域名映射到多個不同的IP地址提高可擴展性。這樣不同的伺服器不能夠更新同步狀態，但映射靜態內容的話非常好。
Anycast 是一個IP地址映射多個物理主機的路由技術。 美中不足，Anycast與TCP協議適應的不是很好，所以很少應用在那些方案中。
大多數DNS伺服器使用Anycast來獲得高效低延遲的DNS查找。
3. 瀏覽器給web伺服器發送一個HTTP請求
因為像Facebook主頁這樣的動態頁面，打開後在瀏覽器緩存中很快甚至馬上就會過期，毫無疑問他們不能從中讀取。
所以，瀏覽器將把一下請求發送到Facebook所在的伺服器：
GET http://facebook.com/ HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, [...]
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; [...]
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Host: facebook.com
Cookie: datr=1265876274-[...]; locale=en_US; lsd=WW[...]; c_user=2101[...]
GET 這個請求定義了要讀取的URL： 「http://facebook.com/」。 瀏覽器自身定義 (User-Agent 頭)， 和它希望接受什麼類型的相應 (Accept and Accept-Encoding 頭). Connection頭要求伺服器為了後邊的請求不要關閉TCP連接。
請求中也包含瀏覽器存儲的該域名的cookies。可能你已經知道，在不同頁面請求當中，cookies是與跟蹤一個網站狀態相匹配的鍵值。這樣cookies會存儲登錄用戶名，伺服器分配的密碼和一些用戶設置等。Cookies會以文本文檔形式存儲在客戶機里，每次請求時發送給伺服器。
用來看原始HTTP請求及其相應的工具很多。作者比較喜歡使用fiddler，當然也有像FireBug這樣其他的工具。這些軟體在網站優化時會幫上很大忙。
除了獲取請求，還有一種是發送請求，它常在提交表單用到。發送請求通過URL傳遞其參數(e.g.: http://robozzle.com/puzzle.aspx?id=85)。發送請求在請求正文頭之後發送其參數。
像「http://facebook.com/」中的斜杠是至關重要的。這種情況下，瀏覽器能安全的添加斜杠。而像「http: //example.com/folderOrFile」這樣的地址，因為瀏覽器不清楚folderOrFile到底是文件夾還是文件，所以不能自動添加 斜杠。這時，瀏覽器就不加斜杠直接訪問地址，伺服器會響應一個重定向，結果造成一次不必要的握手。
4. facebook服務的永久重定向響應
圖中所示為Facebook伺服器發回給瀏覽器的響應：
HTTP/1.1 301 Moved Permanently
Cache-Control: private, no-store, no-cache, must-revalidate, post-check=0,
pre-check=0
Expires: Sat, 01 Jan 2000 00:00:00 GMT
Location: http://www.facebook.com/
P3P: CP="DSP LAW"
Pragma: no-cache
Set-Cookie: made_write_conn=deleted; expires=Thu, 12-Feb-2009 05:09:50 GMT;
path=/; domain=.facebook.com; httponly
Content-Type: text/html; charset=utf-8
X-Cnection: close
Date: Fri, 12 Feb 2010 05:09:51 GMT
Content-Length: 0
伺服器給瀏覽器響應一個301永久重定向響應，這樣瀏覽器就會訪問「http://www.facebook.com/」 而非「http://facebook.com/」。
為什麼伺服器一定要重定向而不是直接發會用戶想看的網頁內容呢？這個問題有好多有意思的答案。
其中一個原因跟搜索引擎排名有 關。你看，如果一個頁面有兩個地址，就像http://www.igoro.com/ 和http://igoro.com/，搜索引擎會認為它們是兩個網站，結果造成每一個的搜索鏈接都減少從而降低排名。而搜索引擎知道301永久重定向是 什麼意思，這樣就會把訪問帶www的和不帶www的地址歸到同一個網站排名下。
還有一個是用不同的地址會造成緩存友好性變差。當一個頁面有好幾個名字時，它可能會在緩存里出現好幾次。
5. 瀏覽器跟蹤重定向地址
現在，瀏覽器知道了「http://www.facebook.com/」才是要訪問的正確地址，所以它會發送另一個獲取請求：
GET http://www.facebook.com/ HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, [...]
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; [...]
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Cookie: lsd=XW[...]; c_user=21[...]; x-referer=[...]
Host: www.facebook.com
頭信息以之前請求中的意義相同。
6. 伺服器「處理」請求
伺服器接收到獲取請求，然後處理並返回一個響應。
這表面上看起來是一個順向的任務，但其實這中間發生了很多有意思的東西- 就像作者博客這樣簡單的網站，何況像facebook那樣訪問量大的網站呢！
Web 伺服器軟體
web伺服器軟體（像IIS和阿帕奇）接收到HTTP請求，然後確定執行什麼請求處理來處理它。請求處理就是一個能夠讀懂請求並且能生成HTML來進行響應的程序（像ASP.NET,PHP,RUBY...）。
舉 個最簡單的例子，需求處理可以以映射網站地址結構的文件層次存儲。像http://example.com/folder1/page1.aspx這個地 址會映射/httpdocs/folder1/page1.aspx這個文件。web伺服器軟體可以設置成為地址人工的對應請求處理，這樣 page1.aspx的發布地址就可以是http://example.com/folder1/page1。
請求處理
請求處理閱讀請求及它的參數和cookies。它會讀取也可能更新一些數據，並講數據存儲在伺服器上。然後，需求處理會生成一個HTML響應。
所 有動態網站都面臨一個有意思的難點 -如何存儲數據。小網站一半都會有一個SQL資料庫來存儲數據，存儲大量數據和/或訪問量大的網站不得不找一些辦法把資料庫分配到多台機器上。解決方案 有：sharding （基於主鍵值講數據表分散到多個資料庫中），復制，利用弱語義一致性的簡化資料庫。
委 托工作給批處理是一個廉價保持數據更新的技術。舉例來講，Fackbook得及時更新新聞feed，但數據支持下的「你可能認識的人」功能只需要每晚更新 （作者猜測是這樣的，改功能如何完善不得而知）。批處理作業更新會導致一些不太重要的數據陳舊，但能使數據更新耕作更快更簡潔。
7. 伺服器發回一個HTML響應
圖中為伺服器生成並返回的響應：
HTTP/1.1 200 OK
Cache-Control: private, no-store, no-cache, must-revalidate, post-check=0,
pre-check=0
Expires: Sat, 01 Jan 2000 00:00:00 GMT
P3P: CP="DSP LAW"
Pragma: no-cache
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
X-Cnection: close
Transfer-Encoding: chunked
Date: Fri, 12 Feb 2010 09:05:55 GMT
2b3Tn@[...]
整個響應大小為35kB，其中大部分在整理後以blob類型傳輸。
內容編碼頭告訴瀏覽器整個響應體用gzip演算法進行壓縮。解壓blob塊後，你可以看到如下期望的HTML：
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"
lang="en" id="facebook" class=" no_js">
<head>
<meta http-equiv="Content-type" content="text/html; charset=utf-8" />
<meta http-equiv="Content-language" content="en" />
...
關於壓縮，頭信息說明了是否緩存這個頁面，如果緩存的話如何去做，有什麼cookies要去設置（前面這個響應里沒有這點）和隱私信息等等。
請注意報頭中把Content-type設置為「text/html」。報頭讓瀏覽器將該響應內容以HTML形式呈現，而不是以文件形式下載它。瀏覽器會根據報頭信息決定如何解釋該響應，不過同時也會考慮像URL擴展內容等其他因素。
8. 瀏覽器開始顯示HTML
在瀏覽器沒有完整接受全部HTML文檔時，它就已經開始顯示這個頁面了：
9. 瀏覽器發送獲取嵌入在HTML中的對象
在瀏覽器顯示HTML時，它會注意到需要獲取其他地址內容的標簽。這時，瀏覽器會發送一個獲取請求來重新獲得這些文件。
下面是幾個我們訪問facebook.com時需要重獲取的幾個URL：
圖片
http://static.ak.fbcdn.net/rsrc.php/z12E0/hash/8q2anwu7.gif
http://static.ak.fbcdn.net/rsrc.php/zBS5C/hash/7hwy7at6.gif
…
CSS 式樣表
http://static.ak.fbcdn.net/rsrc.php/z448Z/hash/2plh8s4n.css
http://static.ak.fbcdn.net/rsrc.php/zANE1/hash/cvtutcee.css
…
JavaScript 文件
http://static.ak.fbcdn.net/rsrc.php/zEMOA/hash/c8yzb6ub.js
http://static.ak.fbcdn.net/rsrc.php/z6R9L/hash/cq2lgbs8.js
…
這些地址都要經歷一個和HTML讀取類似的過程。所以瀏覽器會在DNS中查找這些域名，發送請求，重定向等等...
但 不像動態頁面那樣，靜態文件會允許瀏覽器對其進行緩存。有的文件可能會不需要與伺服器通訊，而從緩存中直接讀取。伺服器的響應中包含了靜態文件保存的期限 信息，所以瀏覽器知道要把它們緩存多長時間。還有，每個響應都可能包含像版本號一樣工作的ETag頭（被請求變數的實體值），如果瀏覽器觀察到文件的版本 ETag信息已經存在，就馬上停止這個文件的傳輸。
試著猜猜看「fbcdn.net」在地址中代表什麼？聰明的答案是"Facebook內容分發網路"。Facebook利用內容分發網路（CDN）分發像圖片，CSS表和JavaScript文件這些靜態文件。所以，這些文件會在全球很多CDN的數據中心中留下備份。
靜態內容往往代表站點的帶寬大小，也能通過CDN輕松的復制。通常網站會使用第三方的CDN。例如，Facebook的靜態文件由最大的CDN提供商Akamai來託管。
舉例來講，當你試著ping static.ak.fbcdn.net的時候，可能會從某個akamai.net伺服器上獲得響應。有意思的是，當你同樣再ping一次的時候，響應的伺服器可能就不一樣，這說明幕後的負載平衡開始起作用了。
10. 瀏覽器發送非同步（AJAX）請求
在Web 2.0偉大精神的指引下，頁面顯示完成後客戶端仍與伺服器端保持著聯系。
以 Facebook聊天功能為例，它會持續與伺服器保持聯系來及時更新你那些亮亮灰灰的好友狀態。為了更新這些頭像亮著的好友狀態，在瀏覽器中執行的 JavaScript代碼會給伺服器發送非同步請求。這個非同步請求發送給特定的地址，它是一個按照程式構造的獲取或發送請求。還是在Facebook這個例 子中，客戶端發送給http://www.facebook.com/ajax/chat/buddy_list.php一個發布請求來獲取你好友里哪個 在線的狀態信息。
提起這個模式，就必須要講講"AJAX"-- 「非同步JavaScript 和 XML」，雖然伺服器為什麼用XML格式來進行響應也沒有個一清二白的原因。再舉個例子吧，對於非同步請求，Facebook會返回一些JavaScript的代碼片段。
除了其他，fiddler這個工具能夠讓你看到瀏覽器發送的非同步請求。事實上，你不僅可以被動的做為這些請求的看客，還能主動出擊修改和重新發送它們。AJAX請求這么容易被蒙，可著實讓那些計分的在線游戲開發者們郁悶的了。（當然，可別那樣騙人家~）
Facebook聊天功能提供了關於AJAX一個有意思的問題案例：把數據從伺服器端推送到客戶端。因為HTTP是一個請求-響應協議，所以聊天伺服器不能把新消息發給客戶。取而代之的是客戶端不得不隔幾秒就輪詢下伺服器端看自己有沒有新消息。
這些情況發生時長輪詢是個減輕伺服器負載挺有趣的技術。如果當被輪詢時伺服器沒有新消息，它就不理這個客戶端。而當尚未超時的情況下收到了該客戶的新消息，伺服器就會找到未完成的請求，把新消息做為響應返回給客戶端。
B. 電腦里的AKamai Netsession Interface是什麼意思啊！能不能刪了！！
Akamai NetSession界面通常是這些應用程序所需要的網路組件。提高下載速度，縮短下載時間。後台運行，佔用最小的系統資源。Akamai下載管理器是基於Akamai NetSession界面的應用程序之一。
應該是裝什麼軟體帶的這個程序，這個不是系統必須文件，可以刪除。
C. 0.......
2001年秋天互聯網公司（dot-com)泡沫的破滅標志著互聯網的一個轉折點。許多人斷定互聯網被過分炒作，事實上網路泡沫和相繼而來的股市大衰退看起來像是所有技術革命的共同特徵。股市大衰退通常標志著蒸蒸日上的技術已經開始佔領中央舞台。假冒者被驅逐，而真正成功的故事展示了它們的力量，同時人們開始理解了是什麼將一個故事同另外一個區分開來。
「Web 2.0」的概念開始於一個會議中，展開於O'Reilly公司和MediaLive國際公司之間的頭腦風暴部分。所謂互聯網先驅和O'Reilly公司副總裁的戴爾·多爾蒂(Dale Dougherty)注意到，同所謂的「崩潰」迥然不同，互聯網比其他任何時候都更重要，令人激動的新應用程序和網站正在以令人驚訝的規律性涌現出來。更重要的是，那些倖免於當初網路泡沫的公司，看起來有一些共同之處。那麼會不會是互聯網公司那場泡沫的破滅標志了互聯網的一種轉折，以至於呼籲「Web 2.0」的行動有了意義？我們都認同這種觀點，Web 2.0會議由此誕生。
在那個會議之後的一年半的時間里，「Web 2.0」一詞已經深入人心，從Google上可以搜索到950萬以上的鏈接。但是，至今關於Web 2.0的含義仍存在極大的分歧，一些人將Web 2.0貶低為毫無疑義的一個行銷炒作口號，而其他一些人則將之理解為一種新的傳統理念。
本文就是來嘗試澄清Web 2.0本來意義。
在我們當初的頭腦風暴中，我們已經用一些例子，公式化地表達了我們對Web 2.0的理解：
Web 1.0 Web 2.0
DoubleClick Google AdSense
Ofoto Flickr
Akamai BitTorrent
mp3.com Napster
大英網路全書在線（Britannica Online） 維基網路全書（Wikipedia）
個人網站 博客(blogging)
evite upcoming.org和EVDB
域名投機 搜索引擎優化
頁面瀏覽數 每次點擊成本
屏幕抓取（screen scraping） 網路服務（web services）
發布 參與
內容管理系統 維基
目錄（分類) 標簽（「分眾分類」，folksonomy）
粘性 聚合
這個列表還會不斷繼續下去。但是到底是什麼，使得我們認定一個應用程序或一種方式為作所謂「Web 1.0」，而把另外一個叫做「Web 2.0」呢？（這個問題尤為緊迫，因為Web 2.0的觀念已經傳播的如此廣泛，以至於很多公司正在將這個詞加到他們的行銷炒作中，但卻沒有真正理解其含義。同時這個問題也尤為困難，因為許多嗜好口號的創業公司顯然不是Web 2.0，而一些我們認為是Web 2.0的應用程序，例如Napster和BitTorrent，甚至不是真正適當的網路程序！）我們首先來探討一些原則，這些原則是通過Web 1.0的一些成功案例，以及一些最為有趣的新型應用程序來體現的。
1. 互聯網作為平台
正如許多重要的理念一樣，Web 2.0沒有一個明確的界限，而是一個重力核心。不妨將Web 2.0視作一組原則和實踐，由此來把距離核心或遠或近的網站組成為一個類似太陽系的網路系統，這些網站或多或少地體現著Web 2.0的原則。
圖1為Web 2.0的「模擬圖」，該圖是在名為「O'Reilly的朋友」（Friend Of O』reilly, FOO）的會議的一個研討會上產生的。這個圖基本上仍處於演化階段，但已經描繪出了 從Web 2.0核心理念中衍生出的許多概念。
例如，在2004年10月的第一次Web 2.0的會議上，約翰·巴特利（John Battelle）和我在我們各自的開場白中列舉了一組初步的原則。
這些原則中的第一條就是「互聯網作為平台」。這也曾是Web 1.0的寵兒網景公司（Netscape)的戰鬥口號，而網景在同微軟的大戰中隕落了。此外，我們早先的Web 1.0的楷模中的兩個，DoubleClick和Akamai公司，皆是將網路當作平台的先驅。人們往往不認為這是一種網路服務，但事實上，廣告服務是第一個被廣泛應用的網路服務，同時也是第一個被廣泛應用的混合處理（mashup），如果用另一個近來流行的詞來說的話。每個旗幟廣告（banner ad)都是用來在兩個網站之前無縫合作，向位於另外一台計算機上的讀者傳遞一個整合好的頁面。
Akamai也將網路看作平台，並且在一個更深入的層次上，來搭建一個透明的緩存和內容分發網路，以便降低寬頻的擁塞程度。
雖然如此，這些先驅提供了有益的對比，因為後來者遇到同樣問題的時候，可以將先驅們的解決方案進一步延伸，從而對新平台本質的理解也更為深刻了。DoubleClick和Akamai都是Web 2.0的先驅，同時我們也可以看到，可以通過引入更多Web 2.0的設計模式，來實現更多的應用。
讓我們對這三個案例中的每一個都作一番深究，來探討其間的一些本質性的差別。
Netscape 對 Google
如果Netscape可以稱為Web 1.0的旗手，那麼Google幾乎可以肯定是Web 2.0的旗手，只要看看他們的首次公開上市（IPO)是如何地揭示了各自的時代就清楚了。所以我們就從這兩個公司和其定位的差別入手。
Netscape以傳統的軟體摹本來勾勒其所謂「互聯網作為平台」：他們的旗艦產品是互聯網瀏覽器，一個桌面應用程序。同時，他們的戰略是利用他們在瀏覽器市場的統治地位，來為其昂貴的伺服器產品建立起市場。從理論上講，在瀏覽器中控制顯示內容和程序的標准，賦予了Netscape一種市場支配力，如同微軟公司在個人計算機市場上所享受的一樣。很像當初「自行的馬車」（horseless carriage）將汽車描繪為一種熟知事物的延伸，Netscape曾推銷一種網路桌面（webtop）來替代傳統的桌面（desktop），並且計劃藉助信息更新，以及由購買了Netscape伺服器的信息提供者來推送的各種小程序，來開發推廣這種網路桌面。
最終，瀏覽器和網路伺服器都變成了「日用品」，同時價值鏈條也向上移動到了在互聯網平台上傳遞的服務。
作為對比，Google則以天生的網路應用程序的角色問世，它從不出售或者打包其程序，而是以服務的方式來傳遞。客戶們直接或間接地為其所使用的服務向Google付費。原有軟體工業缺陷盪然無存。沒有了定期的軟體發布，只需要持續的改善。沒有了許可證或銷售，只需要使用。沒有了為了讓用戶在其設備上運行軟體而不得不進行的平台遷移，只需要搭建宏大的、由眾多個人計算機組成的、可伸縮的網路，其上運行開源操作系統，及其及自行研製的應用程序和工具，而公司之外的任何人則永遠無法接觸到這些東西。
在其底層，Google需要一種Netscape從未需要過的能力：資料庫管理。Google遠遠不只是一個軟體工具的集合，它是一個專業化的資料庫。沒有這些數據，那些工具將毫無用武之地；沒有這些軟體，數據也將無可控制。軟體許可證制度和對應用程序介面（API）的控制——上一個時代的法寶——已經毫不相關了，因為Google的軟體只需要執行而從不需要分發，也因為如果不具備收集和管理數據的能力，軟體本身就沒有什麼用處了。事實上，軟體的價值是同它所協助管理的數據的規模和活性成正比的。
Google的服務不是一個簡單的伺服器，雖然其服務是通過大規模的互聯網伺服器集合來傳遞的；其服務也不是一個瀏覽器，雖然這種服務是被用戶在瀏覽器中體驗到的。Google的旗艦產品——搜索服務，甚至不託管它讓用戶來搜尋的內容。很像一個電話通話過程，不僅發生在通話的兩端，而且發生在中間的網路上。作為用戶和其在線體驗的一個中介，Google作用於瀏覽器、搜索引擎和最終的內容伺服器之間的空間中。
雖然Netscape和Google都可以被描述為軟體公司，但顯然Netscape可以歸到Lotus，Microsoft，Oracle，SAP，以及其他發源於上個世紀八十年代軟體革命的那些公司所組成的軟體世界。而Google的同伴們，則是像eBay，Amazon，Napster，及至DoubleClick和Akamai這樣的互聯網公司。
DoubleClick對Overture和AdSense
同Google類似，DoubleClick是一個名副其實的互聯網時代的孩子。它把軟體作為一種服務，在數據管理方面具有核心競爭力，並且正如上文所述，它是一個早在連網路服務的名字還不曾有的時候，就已然開始其服務的先驅。然而，DoubleClick最終還是被其商業模式局限住了。它所貫徹的是九十年代的互聯網觀念。這種觀念圍繞著出版，而不是參與；圍繞著廣告客戶，而不是消費者，來進行操縱；圍繞著規模，認為互聯網會被如MediaMetrix等網路廣告評測公司尺度下的所謂頂級網站所統治。
結果是，DoubleClick得意地在其網站上引用道：「超過2000種的成功應用」。而相對比的是，Yahoo!公司的搜索市場（從前的Overture）和Google的AdSense產品，已經在為幾十萬的廣告客戶服務。
Overture和Google的成功源自於對克里斯·安德森（Chris Anderson）提到的所謂「長尾」的領悟，即眾多小網站集體的力量提供了互聯網的大多數內容。DoubleClick的產品要求一種簽訂正式的銷售合同，並將其市場局限於很少的幾千個大型網站。Overture和Google則領會到如何將廣告放置到幾乎所有網頁上。更進一步地，它們迴避了發行商和廣告代理們所喜愛的廣告形式，例如旗幟廣告和彈出式廣告，而採用了干擾最小的、上下文敏感的、對用戶友好的文字廣告形式。
Web 2.0的經驗是：有效利用消費者的自助服務和演算法上的數據管理，以便能夠將觸角延伸至整個互聯網，延伸至各個邊緣而不僅僅是中心，延伸至長尾而不僅僅是頭部。
毫不奇怪，其他Web 2.0的成功故事也顯示著同樣的軌跡。eBay扮演著一個自動的中間媒介的角色，使個體之間發生的幾個美元的偶然性的交易成為可能。Napster（雖然已經出於法律原因而關閉）將其網路建立在一個集中的歌曲資料庫之上，但是它讓每一個下載者都成為一台伺服器，從而使其網路逐漸擴大。
Akamai 對 BitTorrent
同DoubleClick類似，Akamai的業務重點面向網路的頭部，而不是尾部；面向中心，而不是邊緣。雖然它服務於那些處於網路邊緣的個體的利益，為他們訪問位於互聯網中心的高需求的網站鋪平了道路，但它的收入仍然來自從那些位於中心的網站。
BitTorrent，像P2P風潮中的其他倡導者一樣，採用了一種激進的方式來達到互聯網去中心化（internet decentralization）的目的。每個客戶端同時也是一個伺服器；文件被分割成許多片段，從而可以由網路上的多個地方提供，透明地利用了網路的下載者來為其他下載者提供帶寬和數據。事實上，文件越流行下載得越快，因為有更多的用戶在為這個文件提供帶寬和各個片段。
BitTorrent由此顯示出Web 2.0的一個關鍵原則：用戶越多，服務越好。一邊是Akamai必須增加伺服器來改善服務，另一邊是BitTorrent用戶將各自的資源貢獻給大家。可以說，有一種隱性的「參與體系」內置在合作準則中。在這種參與體系中，服務主要扮演著一個智能代理的作用，將網路上的各個邊緣連接起來，同時充分利用了用戶自身的力量。
2. 利用集體智慧
在誕生於Web 1.0時代並且存活了下來，而且要繼續領導Web 2.0時代的那些巨人的成功故事的背後，有一個核心原則，就是他們藉助了網路的力量來利用集體智慧：
--超級鏈接是互聯網的基礎。當用戶添加新的內容和新的網站的時候，將被限定在一種特定的網路結構中，這種網路結構是由其他用戶發現內容並建立鏈接的。如同大腦中的神經突觸，隨著彼此的聯系通過復制和強化變得越來越強，而作為所有網路用戶的所有活動的直接結果，互聯的網路將有機地成長。
--Yahoo!是第首例偉大的成功故事，誕生於一個分類目錄，或者說是鏈接目錄，一個對數萬甚至數百萬網路用戶的最精彩作品的匯總。雖然後來Yahoo!進入了創建五花八門的內容的業務，但其作為一個門戶來收集網路用戶們集體作品的角色，依然是其價值核心。
--Google在搜索方面的突破在於PageRank技術，該技術令其迅速成為搜索市場上毫無爭議的領導者。PageRank是一種利用了網路的鏈接結構，而不是僅僅是使用文檔的屬性，來實現更好的搜索效果的方法。
--eBay的產品是其全部用戶的集體活動，就向網路自身一樣，eBay隨著用戶的活動而有機地成長，而且該公司的角色是作為一個特定環境的促成者，而用戶的行動就發生在這種環境之中。更重要的是，eBay的競爭優勢幾乎都來自於關鍵性的大量的買家和賣家雙方，而這正是這一點使得後面許多競爭者的產品的吸引力顯著減低。
--Amazon銷售同Barnesandnoble.com等競爭者相同的產品，同時這些公司從賣方獲得的是同樣的產品描述、封面圖片和目錄。所不同的是，Amazon已然締造出了一門關於激發用戶參與的科學。Amazon擁有比其競爭者高出一個數量級以上的用戶評價，以及更多的邀請來讓用戶以五花八門的方式，在近乎所有的頁面上進行參與，而更為重要的是，他們利用用戶的活動來產生更好的搜索結果。Barnesandnoble.com的搜索結果很可能指向該公司自己的產品，或者是贊助商的結果，而Amazon則始終以所謂「最流行的」打頭，這是一種實時計算，不僅基於銷售，而且基於其他一些被Amazon內部人士稱為圍繞著產品「流動」（flow）的因素。由於擁有高出對手一個數量級的用戶參與，Amazon銷售額超出競爭對手也就不足為奇了。
現在，具備了這種洞察力，並且可能會將之延伸開來的那些創新型的公司，正在互聯網上留下他們的印跡。
維基網路全書（Wikipedia）是一種在線網路全書，其實現基於一種看似不可能的觀念。該觀念認為一個條目可以被任何互聯網用戶所添加，同時可以被其他任何人編輯。無疑，這是對信任的一種極端的實驗，將埃里克·雷蒙德（Eric Raymond）的格言（源自開放源碼軟體的背景之下）：「有足夠的眼球，所有的程序缺陷都是膚淺的」（with enough eyeballs, all bugs are shallow）運用到了內容的創建之中。維基網路全書已然高居世界網站百強之列，並且許多人認為它不久就將位列十強。這在內容創建方面是一種深遠的變革。
像del.icio.us（美味書簽）和Flickr這樣的網站，其公司已經在近期獲得了廣泛的關注，並且已經在一種被人們成為「分眾分類」（folksonomy，有別於傳統分類法）的概念上成為先行者。「分眾分類」是一種使用用戶自由選擇的關鍵詞對網站進行協作分類的方式，而這些關鍵詞一般稱為標簽（tags)。標簽化運用了像大腦本身所使用的那種多重的、重疊的關聯，而不是死板的分類。舉一個經典的例子，在Flickr網站上，一幅小狗照片可能被加上「小狗」和「可愛」這樣的標簽，從而允許系統依照用戶行為所產生的自然的方式來進行檢索。
協作式垃圾信息過濾產品，例如Cloudmark，就聚集了電子郵件用戶們對於「一封郵件是或者不是垃圾郵件」的眾多相互獨立的決策，從而勝過了依賴於分析郵件本身的那些系統。
偉大的互聯網成功者並不主動地到處推銷其產品，這幾乎成為公理。他們採用「病毒式營銷」（viral marketing）的方式，也就是說，一些推介會直接從一個用戶傳播到另外一個用戶。如何一個網站或產品依賴廣告來進行宣傳，你幾乎可以斷定它不是Web 2.0。
即便許多互聯網基礎設施本身，包括在大多數網路伺服器中用到的Linux，Apache，MySQL，以及Perl，PHP或Python代碼，也都依靠開放源碼的對等生產（peer-proction）的方式。其中包含了一種集體的、網路賦予的智慧。在SourceForge.net網站上列有至少10萬種開放源碼軟體項目。任何人都可以添加一個項目，任何人都可以下載並使用項目代碼。
同時，由於作為用戶使用的結果，新的項目從邊緣遷移到中心。一個對軟體的有機的接受過程幾乎完全依靠病毒式營銷。同時，作為用戶應用的結果，新的項目從邊緣遷移到中心，這是一種幾乎完全依靠病毒式營銷的，有機的軟體採用過程，。
經驗是：源於用戶貢獻的網路效應，是在Web 2.0時代中統治市場的關鍵。