这种架构的一个优点是，所有的资源请求都完全在I/O线程上处理，用户接口产生的活动与网络事件之间互不干扰。资源过滤器运行在浏览器进程中的I/O线程中，截获资源请求消息，并将其转发给浏览器进程中的ResourceDispatcherHost【注3】单例。
这个单例接口允许浏览器控制各个呈现器的网络访问权限，它还能实现高效和一致性的资源共享。一些例子包括：
socket池和连接限制：浏览器能够对每个profile、代理和{scheme, host, port}组所对应的已开启socket数量进行限制（分别为256、32和6个）。注意，按照这个规则，同一{host, port}最多可以进行6个HTTP和6个HTTPS连接。
socket重用：持久性的TCP连接会在请求处理之后在socket池中保留一段时间，以供连接重用，这样能够避免发起新的连接额外带来的DNS、TCP和SSL（如有需要）的启动开销。
socket后期绑定：当socket准备好分派应用程序请求时，请求才与基础的TCP连接绑定起来，这样一来可以获得更好的请求次序优化（例如：当socket在连接中时，更高优先级的请求到达），更大的流量（例如：在现有socket可用而新连接正在打开时，重用“刚使用过”的TCP连接）以及TCP预连接的通用机制和其他一些优化。
一致的会话状态：所有呈现进程的身份鉴证、cookies和缓存数据都是共享的。
全局性资源和网络优化：浏览器可以从所有呈现进程和未完成请求的全局做出决策。例如，对前景标签页发起的请求赋予网络优先级。
预测性优化：通过观测所有的网络流量情况，Chrome能够构建和修正预测性模型提升性能。
就呈现进程而言，它只是通过IPC发送资源请求消息，这个请求被打上对应浏览器进程的唯一请求ID，剩下的部分都是由浏览器内核进程处理的。
跨平台资源获取
跨Linux、Windows、OS X、Chrome OS、Android和iOS等不同平台的可移植性是Chrome网络栈实现中的一个重要问题。要解决这个挑战性的问题，网络栈被实现为一个几乎单线程（有单独的缓存和代理线程）的跨平台库，使Chrome可以重用相同的基础设施并提供相同的性能优化水平，更有机会进行跨平台的优化。
当然，所有的代码都是开源的，可以在src/net子目录中找到。我们不打算详细剖析每个部分，但是代码格局本身就带有很大的信息量，告诉我们它的功能和结构。表1.2中是一些例子。
表1.2 Chrome的组件
这些组件的代码都让人忍不住想好好读一读，它们文档完备，每个组件你都能找到很多的单元测试。
移动平台的架构和性能
移动端浏览器的使用正在以指数级增长，即使按照保守预测，它也会在不远的将来完全取代桌面浏览。所以不言而喻，提供优化的移动端访问体验一直是Chrome团队的首要任务之一。在2012年初，Chrome for Android发布，数月后Chrome for iOS发布。
关于Chrome的移动端版本，第一件需要注意的事是，它并不是简单地直接在桌面浏览器基础上做一些调整——那样并不能得到最好的用户体验。从本质讲，移动端环境的资源更加局限，而且有很多根本不同的操作参数：
桌面用户通过鼠标来浏览，可以进行窗口重叠，屏幕更大，几乎没有电量的约束，网络连接通常更稳定，能够访问更大的存储和内存池。
移动端用户使用触摸和手势浏览，屏幕更小，受制于电池和电量的约束，往往使用流量计量的网络，本地存储和内存也较为有限。
此外，并不存在一个“典型移动设备”。不同硬件能力的各种设备五花八门，要提供最佳性能，Chrome必须适应每种设备的操作约束条件。所幸，Chrome有多种执行模型正好可以实现这一点。
在Android设备上，Chrome沿用了桌面版本中相同的多进程架构——即一个浏览器进程多个呈现进程。一个区别是，由于移动设备的内存有限，Chrome可能不能为每个开启的标签页运行专用的呈现器。Chrome是根据可用内存和设备的其他约束条件确定一个最优的呈现进程数量，由多个标签页共享呈现进程。
当只有最少资源可用时，或者Chrome无法运行多进程时，它也可以切换回使用单进程、多线程处理模型。实际上，在iOS设备上，由于基础平台对沙盒的限制，它就是这样实现的——运行多线程的单一进程。
网络性能方面呢？首先，Chrome在Android和iOS上使用和其他版本相同的网络栈。这样保证所有平台都有相同的网络优化，Chrome由此获得显著的性能优势。但是，如推测优化技术、socket超时设定与管理逻辑、缓存大小等这样的变量，是有所不同的并且会根据设备功能和所用网络时时调整。
例如，为了节约电池电量，移动端Chrome可能选择使用闲置socket的懒惰关闭方式——即仅当开启新socket时才关闭旧的，这样来尽可能减少使用广播模组。同样地，因为预呈现（见下文）可能需要大量的网络和处理器资源，所以通常仅当用户使用WiFi时才进行。
优化移动端浏览体验是Chrome开发团队的首要优先任务之一，我们可以期待在未来几个月或几年内看到新的改进。实际上，这是一个值得单独行文介绍的内容——或许在POSA系列的下一版中就会出现。
使用Chrome预测器进行推测优化
Chrome会随着你的使用变得越来越快。这项本领是借助Predictor单例对象实现的，它在浏览器内核进程中被实例化，其唯一职责是观测网络模式，并学习和预测未来可能出现的用户行为。Predictor处理信号的一些例子有：
用户鼠标在一个链接上悬停，很好地预示了接下来可能发生的浏览行为，Chrome可以发起一个推测的目标主机DNS查询，还有可能开始TCP握手，以提升速度。待用户实际点击时，这平均还需要约200毫秒的时间，我们很有可能已经完成了DNS和TCP的步骤，这就为这次浏览减少了数百毫秒的额外延迟时间。
在Omnibox（URL）栏中键入内容将触发高概率建议，也会触发DNS查询、TCP预连接甚至在隐藏的标签页中预呈现该页面。
我们都有一个每天访问的喜爱站点清单。Chrome可以学习这些站点的子资源并推测性地进行预解析，甚至可能预获取这些资源来加速浏览。
Chrome会随着你的使用，逐步学习网络的拓扑结构和你的浏览模式。如果顺利，它可以为每次浏览减少数百毫秒的延迟，让用户更加接近“页面即刻加载”的理想状态。为了实现这一点，Chrome使用了四个核心的优化技术，见表1.3
表1.3 Chrome所使用的网络优化技术
每个触发这些技术的决定都是在大量约束条件下优化判断的。毕竟，每一项优化都是推测性的，这意味着如果运用失当，可能会导致不必要任务和网络流量，更糟的是，还有可能对用户实际浏览行为的加载时间产生负面效果。
Chrome是如何解决这个问题的呢？预测器会尽可能多地吸收信号，包括用户产生的行为、历史浏览数据以及来自呈现器和网络栈本身的信号。
与ResourceDispatcherHost负责协调Chrome中所有网络活动的情况类似，Predictor对象也在Chrome内部创建了对一些用户和网络产生活动的过滤器：
IPC频道过滤器，监测来自呈现进程的信号
为各个请求添加ConnectInterceptor对象，这样它就能观测每个请求的流量模式并记录成功次数。
下面是一个实际操作的例子，呈现进程可以发出一条带有以下任何提示的消息给浏览器进程，这些提示定义在ResolutionMotivation（url_info.h）中：
收到这样的信号后，预测器的目标是评价其成功的可能性，然后在资源可用的情况下触发相应行为。每条提示可能都有一个成功概率、一个优先级和一个过期时间戳，这组数据可用于维护一个推测优化的内部优先级队列。最后，对于每条从此队列发出的请求，预测器还能够跟踪记录其成功率，这又被用于未来决策的优化中。
Chrome网络架构概要
Chrome使用多进程架构，将呈现进程与浏览器进程隔离开。
Chrome保持资源调度器的一个单一实例，它被所有呈现进程所共享，运行在浏览器内核进程中。
网络栈是一个跨平台、几乎单线程的库。
网络栈使用非阻塞操作来管理所有网络操作。
共享的网络栈可实现高效的资源次序优先化、重用并使浏览器可以在所有运行的进程之间进行全局性的优化。
各个呈现进程通过IPC与资源调度器通信。
资源调度器通过自定义的IPC过滤器截获资源请求。
预测器截获资源请求和响应通信来学习和优化未来的网络请求。
预测器根据所学的浏览模式可能推测性地安排DNS、TCP甚至资源请求的计划，当用户实际发生行为时节省数百毫秒的时间。
浏览器会话的生命周期
有了对Chrome网络栈架构的一个概括性认识后，我们接下来仔细研究一下浏览器内部实施的各种面向用户的优化。具体而言，假设我们刚创建了一个新的Chrome profile，准备好开始了。
相关文章
网友评论（共有 0 条评论）
