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时代中统治市场的关键。