Web 3.0是针对Web 2.0提出的，较有名的首次提及是在2006年初Jeffrey Zeldman的博客中一篇批评Web 2.0的文章中。
2006年5月，蒂姆·伯纳斯-李曾说：
2006年11月的Technet峰会上，Yahoo创办人兼首席运行官杨致远作出阐述：
在这个峰会上，Netflix创始人Reed Hastings阐述了定义Web术语的简单公式：
2007年8月7日，Google首席运行官埃里克·施密特出席首尔数字论坛时被与会者问及Web 3.0的定义，埃里克·施密特首先开玩笑的地说“Web 2.0只是一个营销术语，而你刚才正好发明了Web 3.0这个营销术语。”随后他谈及了自己的具体看法：
静态代理是一种编译期的代理类，它的.class文件在运行前已经生产，使用静态代理类可以在委托类完成指定调用前对消息进行处理与过滤。
简单例子如下：
package search;
public class HelloServiceProxy
{
private HelloService helloService;
public HelloServiceProxy(HelloService helloService)
{
this.helloService=helloService;
}
public String echo(String msg)
{
System.out.println("预处理");
String result=helloService.echo(msg);
System.out.println("事后处理");
return result;
}
}
package search;
public class Server
{
public static void main(String[]args)
{
HelloService service=new HelloServiceImpl();
HelloServiceProxy proxy=new HelloServiceProxy(service);
System.out.println(proxy.echo("hello"));
}
}
通过调用HelloServiceProxy类的echo方法完成对HelloService类调用，并在调用前对消息进行处理。
运行结果如下：
预处理
事后处理
echo hello
动态代理类通过反射机制在运行期动态生成代理类。
实现代理类需要java.lang.reflect包中的Proxy和InvocationHandler
Proxy类提供了创建动态代理类及其实例的静态方法。
public static Class<?> getProxyClass(ClassLoader loader, Class<?>... interfaces)
loader指定代理类的类加载器，interfaces指定代理类需要实现的所有接口
public static Object newProxyInstance(ClassLoader loader,Class<?>[] interfaces,InvocationHandler h)
loader指定代理类的类加载器，interfaces指定代理类需要实现的所有接口，h指定与代理类相关联的InvocationHandler对象。
由Proxy类的静态方法创建的动态代理类具有如下特点：
1.动态代理类是public,final和非抽象的；
2.动态代理类继承了Proxy类；
3.动态代理类的名字以“$proxy”开头；
4.动态代理类实现getProxyClass()和newProxyInstance()方法中参数Interfaces指定的所有接口；
5.Proxy类的isProxyClass()静态方法可以用来判断参数指定的类是否是动态代理类；
6.动态代理类都具有一个public类型的构造方法，该构造方法有一个InvocationHandler类型的参数；
由Proxy类的静态方法创建的动态代理类实例具有如下特点：
1.每个实例和InvocationHandler实例关联。
2.当程序调用动态代理类实例的xx方法时，该方法会调用与它关联的InvocationHandler对象的invoke()方法。
一个简单的动态代理类例子如下：
package search;
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;
public class HelloServiceProxyFactory
{
public static HelloService getHelloServiceProxy(final HelloService helloService)
{
InvocationHandler handler=new InvocationHandler()
{
public Object invoke(Object proxy, Method method, Object[] args)throws Throwable{
System.out.println("预处理");
Object result=method.invoke(helloService, args);
System.out.println("事后处理");
return result;
}
};
Class classType=HelloService.class;
return (HelloService)Proxy.newProxyInstance(classType.getClassLoader(),new Class[]{classType},handler);
}
}
package search;
public class Client
{
public static void main(String[]args)
{
HelloService helloService=new HelloServiceImpl();
HelloService proxy=HelloServiceProxyFactory.getHelloServiceProxy(helloService);
System.out.println(proxy.getClass().getName());
System.out.println(proxy.echo("hello"));
}
}
运行结果如下：
$Proxy0
预处理
事后处理
echo hello
该文档描述Chromium的高层结构
问题创建一个永不崩溃或挂起的渲染引擎几乎不可能。创建一个非常安全的渲染引擎也不可能。
在某些方面，现在浏览器的状态有点像过去的单用户，合作无间的多任务操作系统。在这样的操作系统中，一个行为不当的程序会导致系统关闭，类似的事情也会发生在现代浏览器的一个行为不当的页面中。一个浏览或插件的错误会拖垮整个浏览器和当前正在运行的标签。现代操作系统健壮的原因是它们把应用程序集成到单独的相互隔离的进程中。一个应用程序的崩溃不影响其他的应用程序或操作系统的完整性，并限制用户间互访数据。
结构概述我们为浏览器标签使用单独的进程，以保护整个应用程序不受渲染引擎的错误和故障的影响。而且我们限制渲染引擎间的相互访问，对系统的其他部分也是限制的。这样就使浏览器受益于操作系统的内存保护和访问控制。
我们把运行UI和管理标签及插件进程的主要进程当作“浏览进程“或”浏览器”。同样，特定标签的进程称为“渲染进程”或“渲染器”。渲染器使用webkit开源布局引擎来解释和布局HTML。
渲染进程的管理每个渲染进程都有一个管理和父浏览器进程通信，维护全局状态的RenderProcess的对象。浏览器为每个渲染进程维护一个对应的RenderProcessHost，它管理浏览器状态以及和渲染器进行通信。浏览器和渲染器使用chromium进程间通信系统进行通信。
视图管理每个渲染进程有一个或多个RenderView对象，它们受RenderProcess的管理，对应相应的标签页的内容。相应的RenderProcessHost维护一个RenderViewHost，对应渲染器的每个视图。每个视图赋予一个视图ID用来区分相同的渲染器中的多个视图。视图ID在渲染器中唯一但在浏览器中不唯一因此标识一个视图需要一个RenderProcessHost和一个视图ID。通过这些RenderViewHost对象可以处理浏览器到特定标签内容的通信，它们知道如何通过RenderProcessHost发送消息给RenderProcess并转发给RenderView。
组件和接口在渲染进程中：
- RenderProcess和浏览器中相应的RenderProcessHost处理IPC消息。正好一个渲染进程一个RenderProcess对象。这就是所有的浏览器↔渲染器间的通信如何发生的。
- RenderView对象和浏览器进程中的对应的RenderViewHost通信（通过RenderProcess），还和Webkit嵌入层通信。该对象描述标签页或弹出式窗口的一个web页的内容。
在浏览器进程中：
Browser对象描述一个顶层浏览窗口。
RenderProcessHost对象描述单个Browser↔ renderer IPC连接的浏览端。在浏览器进程为每一个渲染进程对应一个RenderProcessHost。