CISC 322 Conceptual Architecture of Google Chrome Go 6ers! Yinchen Shi(group manager) ​ ​ [email protected] Zhaoyu Yin: [email protected] Jason Liu: [email protected] Laixin Xu: [email protected] Cheng Cao: [email protected] Xuebin Yang:[email protected] ​October 18, 2018 Table of Contents Section Page 1 Table of Contents 1 2 Abstract 2 3 Introduction and overview 2-3 4 Conceptual Architecture 4-5 4.1 final styles 4 4.2 Derivation process 5 4.3 Alternative styles 5 5 Subsystem Functionalities 6-9 5.1 User Interface 6 5.2 Browser Engine 6 5.3 Rendering Engine 7-8 5.4 Network Stack 8 5.5 Data Persistence 8-9 5.6 JavaScript V8 9 6 Sequence diagram 10-11 7 Concurrency 11-12 8 Team issues 12 9 Lessons learned 12 10 Conclusion 12-13 11 Name convention 13 12 References 14 1 ​Abstract This report is about the conceptual architecture of Google Chrome web browser. Chrome browser is an open source program for accessing the World Wide Web and running Web-based applications. It is based on the open source Chromium project. After using a high-level diagram to illustrate the structure of Chrome system, we decided that the overall architecture style is layered. We derived this conclusion from the dependencies of each system and how they provide service to the layer above it and serving as client below. The six main subsystems are User Interface, Browser Engine, Rendering Engine, Network Stack, Data Persistence, and JavaScript V8. Furthermore, We dig in the rendering engine. We will explain how it works by figuring out different properties of its inner subsystems. Also two use cases sequence diagrams will be included to explain how typical web browser functions, such that how Chrome browser saves the password for users, and how it renders the pages that has JavaScript, following the flow of interaction and dependency of the system. Overall, this project will be the foundation for deciding concrete architecture of Google Chrome in the future. Introduction and Overview In 2008, the Web became a principal delivery mechanism for applications. But as such, it was only getting slower, and perhaps the biggest bottleneck is at the receiving end, with the Web browser itself. In order to solve this problem, Chrome was revealed publicity for the first time aiming to speed up the web for Google. One biggest change Chrome has made was developing V8 JavaScript engine to replace JavaScript VM. In a demonstration of a JavaScript app, the application timed itself at an average of 7.5 revolutions per hour on Microsoft Internet Explorer 7 while the same application, running on Chrome with V8, was timed at between 562 and 580 revolutions per hour, which was 76 times faster. Also, instead of building a traditional content viewer, with the bulky toolbars and buttons and all that kind of stuff, Google develops a very streamlined user interface which is more like a window manager for Web pages and apps. It has a sleek, cross-platform design that is stable and conveniently presented to take up the minimum screen space. Furthermore, since Security continues to be one of the biggest problems Web users face, Google does a great effort in it. Sandboxing and Site Isolation are used that Sandboxing prevents malicious web pages from installing malware, while Site Isolation puts pages from websites into different processes, limiting what each process is allowed to do. Chrome Browser also authenticates secure connections with HTTP Strict Transport Security 2 (HSTS), root CA verification, and mixed script blocking, so users’ online activity remains safe. With all these features, plus full Google Account integration, a thriving extension ecosystem, and a reliable suite for mobile apps, Chrome has became the most popular browser across the world over the past ten years. It now accounts for 60 percent of browser usage. While some of Chrome’s old competitors like Internet Explorer have stopped development of new features, Google refreshed the browser on an average tempo of 45 days which is the shortest interval among all the popular browsers. On October 2018, Google released Google 70 to celebrate its 10th birthday with a significant visual redesign and some nice features. This report is aiming to examine the conceptual architecture of Google Chrome. We derived a conceptual architecture diagram with six main subsystem components which are User Interface, Browser Engine, Blink (rendering engine), Data Persistence, Javascript v8, and Network. This report will also address to how we get this diagram, the style we choose for this system, and the alternative styles we’ve considered during the process. How does each subsystem contribute to the overall Chrome system will be talked later as well as the dependencies between the subsystems. In addition, two sequence diagrams based on two use cases will be provided. The first use case is about user log in to a website, succeed, and Chromium save the password. While another One is Chromium renders a page that has JavaScript. After analyzing each part, concurrency will be mentioned and we will imagine what team issue Google would have if they use our conceptual architecture. At last, we will share the problem we meet and what we learned while doing this project. 3 ​Conceptual Architecture Figure One: Conceptual Architecture of Google Chrome ​ Derivation Process At the beginning of the assignment, we weren’t sure about the architecture of chrome so we started with the basic web browser model. In order to get familiar with the chrome architecture, we start researching each block from the basic web browser model in chrome and find the differences between the basic model and chromes model. We began looking into the relationships of chromes subsystem by reading the chrome documentation,blogs and books that are related with chrome. At first we came up with the rough conceptual architecture diagram as shown in the alternative styles section. After viewing the documentation of chrome, we have identified the dependencies of each subsystem and how they provide service to the layer above it and serving as a client to the layer below. We were able to confirm that javascript V8 was the javascript engine used by google, and that it was called by the rendering engine which creates the dependency link. We 4 have also learned that Chrome does not use webkit, they have developed a new rendering engine called blink, which was meant to replace webkit. We thought the xml is the storage where chrome saves the data and that the browser engine calls the network stack. While looking through the documents on the rendering engine, it was said that the rendering engine calls the underlying network stack so we believe that the rendering engine has the dependency of the network stack. When we learned that XML does not act as data storage, we learned about data persistence. We found out that the web browser manages data persistence so we added it as a dependency for the browser engine. These changes rearranged our conceptual architecture diagram, however we still believe that the architecture is using layered style as we view each subsystem and their dependencies, it emulates a layered style. Each subsystem has a dependency on the layer below them which leads to reduced coupling and consistency. We then come up with our finalized conceptual architecture as shown in the diagram above. Alternative Styles: Figure Two: The Alternative Architecture Style 5 User Interface The user interface includes the address bar, tabs, back/forward button, menu, setting, etc. It is the data layer that we use to interact with browser engine to control and get information from the chrome. There are three components: Skia, GDI, and NativeControls which realize calls from the browser to the display libraries. The Skia is used to render the majority of the UI; GDI is the component that is used for text rendering; NativeControls is responsible for a small amount of elements such as buttons and labels. Generally, the goal of the design is to produce a UI which is aesthetic, ​ ​ efficient and user-friendly to operate a machine in the way that produces the desired result. After Google browser’s first launch ten years ago, Chrome is getting a new look today. Its new tabs are designed to be easier to see, which will be useful for those who like having too many tabs open in their browser. Browser Engine Browser engine is widely used in every browser these days. It links a crucial bridge between User Interface(UI) and Rendering Engine. It is not a independent computer element but most central component of Chrome. Browser engine acts as a commander who directs manipulations and querying between the UI and rendering engine as well as external communication with servers, It provides methods and directions to initiate the loading of a URL and other actions, such as reloading and communication. The process plays a role as a magic box so that the browser process is expected to extract the web content in a certain format from the renderer process. The conversion between these two things includes a few sub-components of which layout engine is one. In this case, the browser process deals with tasks like user resources or requests such as access to filesystem, network etc. However the sandboxed Renderer process is responsible for converting the web pages to a format, hence browser-process can put it to display in window tab. Figure Three: Renderer Object 6 Blink(Rendering Engine) The responsibility of the rendering engine is to display the requested contents on the browser screen by creating a bitmap. By default the rendering engine can display HTML and XML documents and images, which can display other types through a plug-in.