The history of web

1. ~1993, telnet, NCSA mosaic;
2. 1994, mosaic team splits to Netscape and SPRY;
3. 1995, joined microsoft and the IE team;
4. browser wars;
5. 1996, ie3 vs netscape navigator, css;
6. 1997, ie4, trident engine, dhtml("suddenly anything was dynamically programmable"), activedesktop in wins 98;
7. 1999, ajax, ie5;
8. 2001, ie6 and the death of web;
9. 2001-2004, mashups, mozilla(firefox), safari, webkit;
10. 2004-2006, ie7, back from the dead;
11. 2007-,ie continues to underinvest in platform;
12. 2007-2010, the rise of mobile revolution;
13. web 2.0 isn't a set of technologies - it's caring about your user experience;
14. 2015 the pwa era;

Anatomy of the browser 101

1. 4s principles: speed, security, simplicity, stability;

2. chrome 1.0, communication on IPC:

   1. Browser(ui, networking, storage);
   2. Plugin(NPAPI), one for each;
   3. Renderer(Webkit), sandbox, one for each;

   

3. why multi-process? (as multi-process obviously going to be some performance overhead in some cases)

   1. cannot write perfect code;
   2. security: untrusted web content shouldn't use exploits to access file sysytem;
   3. speed: misbehaving（例如，js 性能不佳） tabs should not impact other tabs or the browser;
   4. stability: crashes should only affect the tab and not other tabs or the browser;

4. IPC

   1. inter-process communication;
   2. message passing between processes, with shared memory for large data;
   3. usuallt between processes of different privileges(特权较低的线程不能接管特权较高的线程), so need security review;
   4. 性能考虑，通常是异步通信;

5. sandboxing

   1. untrusted data can be used to exploit bugs and run arbitrary code;
   2. as we moved from simple HTML pages to web apps, more code to exploit（引擎变复杂，有些载体可以使用操作系统）;
   3. run untrusted web content in a locked-down process where it doesn't have access to file system, OS calls
   4. exact mechanism to lock down a process is platform-specific;
   5. multiple levels of sandboxing depending on process type;

6. render process

   1. where data from the web is handled, e.g. parsing, layout, executing js, decoding
   2. completely sandboxed to prevent bugs from gaining access to user data and/or installing malware;

7. plugin process

   1. ran flash, java, reader etc...;
   2. had to be unsandboxed since plugins were written assuming full access (因为插件是第三方代码，它是在假设完全可以访问系统的情况下编写的);

8. browser process

   1. central coordinator;
   2. owns browser state such as profile data, setting etc...;
   3. draws UI;
   4. handles networking;
   5. cannot trust renderer;

9. threads

   1. in child process, for th most part a main thread and an IPC thread;
   2. many threads in the browser process;
   3. main browser threads:
      1. UI(主线程): where most of the browser logic lives;
      2. IO: non-blocking IO, e.g. networking and also IPC;
      3. files

10. chrome today

    1. 更多进程：gpu(partial sanbox, 和 render、plugin 线程直接通信), utility（实用进程）, extension(扩展进程);
    2. plugin is sandboxed (pepper plugin);
    3. render use blink;

    

11. GPU process

    1. machines with powerful GPUs were becoming widespread;
    2. web platform features like WebGL meant that we'd have to make expensive GPU readback to render a page;
    3. large project to offload compositing and scrolling to GPU;
    4. separate process for stability and security(gpu 驱动程序可能有 bug，所以需要部分沙盒隔离);

12. utility process

    1. as the browser gained more features, new class of untrusted data that was not specific to a tab (e.g. installing an extension, processing JSON);
    2. runs code on behalf of browser in a sandbox;
    3. short-lived(杀死自己);

13. extension process

    1. speed & stability: did not want badly written extension code to adversely affect pages;
    2. security: wanted extension to have limited access to browser, page, and system
    3. simplicity: extensions install and uninstalled without restart;

14. pepper plugin

    1. many exploits coming through plugin code we didn't control (Flash & PDF);
    2. multi-year effort to create new plugin API that's sandboxed
    3. ported Flash
    4. wrote new PDF plugin based on PDF code we licensed(PDFium);

15. chrome/content split

    1. separated the product(Chrome) from the platform (sandboxed multi-process browser);
    2. src/chrome split into src/chrome and src/content;
    3. src/chrome for UI and browser features such as bookmarks, password manager, autofill;
    4. src/content for code related to multi-process, sandbox, and web platform;
    5. new products built on top of content, e.g. ChromeCast, Home, Electron;

16. componentization

    1. ios forces apps to use Safari's web engine
    2. need to share browser feature code(e.g. password manager, autofill, sync) with platform that doesn't use Blink;
    3. split feature code from src/chrome into src/components, and move 'content' specific code to isolated subdirs;

17. site isolation

    1. 针对嵌入型的恶意网站，可以根据来源，在不同的进程中运行选卡项中的不同部分;

18. mojo

    1. new IPC mechanism;
    2. IDL based;
    3. allow generation of bindings for different languages or even for same language but different types;
    4. hides detail of which process the caller and callee run in;

19. mojo primitives

    1. message pipes(双向、cheap);
    2. shared buffers;
    3. data pipes（带通知的共享内存）;
    4. process/thread agnostic: avoid different code paths depending on location of sender/receiver;

20. feature chrome-servicification

    1. upgrade architecture;
    2. microservice architecture: well-defined, reusable, decoupled, layered system;

    

21. directory layout

    

Anatomy of the browser 201

1. chrome 是一个浏览器，同时也个提供给其他应用构建浏览器的库，chrome embeds in content;

2. browser 是其他进程的父进程;

3. 多个配置文件：切换用户、匿名模式（创建一个非记录配置文件，没有将任何东西写入磁盘，但也会读取原始配置文件用于保存密码等功能）、访客模式（创建空白的一次性文件，不会写入磁盘、也不会读取之前的如任何设置）;

4. browsercontext（一个 window）：随 bom 销毁，key service;

   

5. webcontent（一个 tab，但也可以独立于选项卡）:观察者模式（观察事件）、委托模式（调用 chrome 实现一些接口功能）;

   

6. 多进程框架;

   

7. //chrome 实例化了 //content/public 中的部分接口;

8. 管理一个页面中不同源的嵌入；

9. 存储分区；