连接延迟和并行性是影响网络应用的网络性能的重要因素。因此，Chromium的工程师花了相当多的时间研究怎样最好的管理我们的连接 -- 应该打开多少，打开多久，等等。这里，我将说说我们的设计和实现基于的各种考量。连接延迟发起一个新的连接的代价是昂贵的。首先，Chromium必须解析主机名，这已经是一个费时的过程。然后，它还得进行各种握手。即TCP握手，可能还有SSL握手。在下面的图中

MemoryCache模块是负责网页加载的一个庞大机制，loader的一部分。这里（https://www.webkit.org/blog/427/webkit-page-cache-i-the-basics/）可以了解更多。本文只谈Memory Cache，以及它内部的一些组件，不涉及到与loader的交互。你可以在MemoryCache.h中找到关于MemoryCache是什么

关于webkit加载的文章网上很多，各种类型、各种角度的都有，有的说的很细。我的体会是，光看那些文章收获不大，可能看看就忘了。想要理解或记住些东西还是得亲自跟踪调试一下才行。可以先通过浏览一些文档来建立一个基本的概念，比一来就跟代码要好。大概的流程是这样的，请求一个资源一般包括如下步骤：1 创建一请求，涉及到的类主要有：ResourceRequest, ResourceRequ

历史2005年之前，Webkit中很多对象都采用引用计数的方式。它们通过继承RefCounted】类模板来实现这种模式。RefCounted主要是实现了ref()和deref()两个函数。在需要引用对象时要调用ref()增加引用计数，在不再需要对象时，要调用deref()函数减少引用计数。ref()和deref()需要成对出现。这和使用new/delete一样，多调用、少调用、没调用的问题

由主文档和子资源组成。主文档描述网页的框架，布局。子资源是组成网页的子元素，包括图片、CSS、JS等。为了显示网页，先要把资源加载到内存。加载就是指把需要的资源加载到内存这一过程。Webkit用到很多缓存机制，加载可能是从网络加载，也可能是从本地缓存加载。Webkit的加载分为两条线，一条是主文档的加载，一条是子资源的加载。首先需要解析主文档才知道用到哪些子资源。但并不一定要等到解析完主文档才

在能够渲染一个网页之前，WebKit需要把该网页和它的子资源从网络上下载下来。从网络上加载资源涉及到很多层次。本文将重点解释WebKit的主要的渲染组件，WebCore，是如何参与加载过程的。WebKit包含两条加载线，主文档加载（加载文档到frames中）和子资源（images and scripts）加载。下图总结了两条加载线所涉及的主要对象。Loading Frame

Page Cache概述你可能更熟悉其它浏览器对Page Cache的叫法。Firefox称之为"Back-Forward Cache" 或 "bfcache"。Opera则叫做"Fast History Navigation"。我们最近开始把WebKit的实现叫做"Page Cache"，以减少同"Back/Forward List"的混淆。注意，Page Cache是一个终

Windows上编译WebKit是件折腾人的事情。看了几篇编译攻略，各种修改，各种配置，完全想放弃的节奏。而且每个人的环境不一样，同样的步骤，不一定能成功。最新的Nightly Builds支持用Visual Studio 2013（vs2013）编译，如果用vs2005, vs2010, vs2008来编译最新的Nightly Builds是会比较麻烦，建议用vs2013编译。一般而言，大部

历史在WebKit中，很多对象采用了引用计数。使用的模式是，通过类成员ref和deref来增加和减少引用计数。每一个ref调用必须有一个相应的deref。当一个对象的引用计数是1时，在其上调用deref将会删除该对象。在WebKit中，很多类是通过继承RefCounted类模板来实现这种模式的。早在2005年，我们发现有太多内存泄露了，尤其是在HTML编辑代码中，这是由于对ref和dere

这里（http://blog.youkuaiyun.com/wy5761/article/details/41869599）有对MemoryCache的整体介绍。本文说一说MemoryCache核心的部分。     MemoryCache是webkit加载网页的庞大机制 -- Loader的一部分。Webkit采用了缓存机制，发起一个请求时，请求顺序经过一系列的Cache，在每层都会查找请求对应的资源是否