Quick viewing(Text Mode)

Conceptual Architecture of Google Chrome

Conceptual Architecture of Google Chrome

CISC 322

Conceptual Architecture of 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 6 5.2 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 . Chrome browser is an open source program for accessing the and running Web-based applications. It is based on the open source 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 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 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 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 , 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 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 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, (rendering engine), Data Persistence, Javascript , 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 V8 was the 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 , they have developed a new rendering engine called blink, which was meant to replace webkit. We thought the 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 , 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 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 .

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. An example would be displaying a PDF file using a PDF viewer plug-in. Chrome is using Blink today, different from using Webkit and using . Blink is an open source rendering engine that is based on Webkit, which is the web platform that Google is using now.

Every engine has their own implementation if how to render the page with requested content, however, all of them tend to follow the same flow. Generally the main flow of a rendering engine will start gathering the contents of requested documents and from the networking layer. The rendering engine first parsing the HTML document, reads the HTML code, and constructs a DOM(), which is a object representation of HTML document, is made of DOM nodes, nodes can be image, text blocks, buttons and any other element. Meanwhile, CSS parser will parse the style sheets, both in external CSS files and in style elements. The styling information, the DOM tree and style rules, combine together with some visual instructions to pack an attachment. Eventually it process into another tree - the render tree.

The render tree consists rectangles attached with visual information, such as colour, positions, and dimensions. The rectangles follow the requested order positioned on the screen. In the following, once the rendering tree has been constructed, it then goes through a layout process where it gives each the exact coordinates to position themselves and appear on the screen. The next step will go through the painting stage where the rendering tree will be traversed and each node will be painted using the UI backend layer. The whole process taken place so fast that you are unable to witness every node got rendered on the page. That is the magic process that the whole pages and entire content is visible when the page is finish loading.

Figure Four: Renderer Object ​ 7

The rendering object could be broken down into separate components, and each component has strong connection and interaction within themselves. The rendering object uses blinks layout engine. The components in the rendering object is the RenderProcess, RenderView, Resource Dispatcher, and Webkit.

The rendering engine has a main thread which contains the renderer process. The renderer process is an object that communicates with the browser and communicates with the renderer. The Render Process is connected to the Render Thread. The Render Thread will have at least 1 or more RenderView objects managed by the Render Process. The Render Thread will also have the Resource Dispatcher and their own Webkit library within it. The RenderView objects each communicates with the embedded webkit layer which will render and animate the user’s requested contents. These render view objects are what represents the contents on a in a tab or popup window. The Render Dispatcher creates unique request Ids for sending and receiving requests from the browser.

Each rendering object is separated in their own sandbox environment to increase security. Each rendering object would strive to be dedicated to a single site which would increase security, but it would also increase RAM(Random Access Memory) usage. Therefore often the rendering engine would be hosting more than one web page at a time and be used in multiple tabs.

Network Stack

The network stack is the component that enables the browser to connect to the internet to receive data, mostly in the of web pages. The network stack is the priority of the rendering engine. Once we click links, the rendering engine will handle all URLs requested by the browsers. Then the rendering engine will check which protocol is needed such as HTTP, FTP, SMTP and so on. All of these are integrated in TCP/IP protocol. Once it is validated, the connection that computer to computer or computer to server will be established which allows browser to transfer files. All websites visited will be stored in cookie for the convenience of visiting again.

Data Persistence

Data persistence is the continuation of the data after its cause has been removed, the cause would be the chrome browser. Data persistence is saved in a number of ways; cookies, session and local storage, file systems, and indexedDB. The non-persistent data will be automatically cleared, but all persistent data will have to be manually cleared. Chrome has persistence permission for when a site is bookmarked, has high site engagement, on the home screen, or when push notifications are enabled. All other sites would automatically have data persistence disabled. This helps sort when data

8

should be made persistence and avoid adding unnecessary data while having persistent data in preferrable sites.

There are 3 main types of data persistence. Session persistence is when data is only retained for the current tab or websession and stored in the session storage API. It is deleted when the tab or web session is closed. Device persistence is when data is stored between different sessions while on the same device and stored in the cache API. Global persistence is when data is stored between different sessions and devices, in chrome it would be the google storage.

JavaScript V8

A Javascript engine is a program that converts Javascript to lower level code or machine code for microprocessors to read. JavaScript V8 is an open source Javascript engine provided by google. V8 is written in ++ and implements EMCS script which defines the standards for . V8 is very powerful as it can run standalone or C++ can be used to create additional functions for new features in javascript. Another key performance of V8 is its ability to handle memory allocation for objects, and its accurate garbage collection for objects no longer needed.

9

Sequence Diagram

Figure Five: sequence diagram of saving user’s password

This sequence diagram explains the procedure how chrome save the password for the user. The user interface gets the login information from the user and passes the information to the browser engine. The Browser engine handles the interactions ​ between user interface and rendering engine so it will continue to pass the information to the rendering engine. The Rendering engine will then communicate with the network stack to get the that is needed. After all previous steps are done, the javascript V8 will execute the source code from the rendering engine and generate a bitmap. And then through the browser engine and UI, the user will see that their log-in is confirmed and will be prompt if they want to save the password. If yes, the browser will communicate with data persistence to save the login information for future use. And finally, the user interface will display that the password is saved.

10

Figure Six: sequence diagram of how chrome renders a page has javascript

This sequence diagram explains the procedure how chrome renders a page. The user interface gets the URL from the user and passes the URL to the browser engine. The Browser engine handles the interactions between user interface and rendering engine ​ so it will continue to pass URL to the rendering engine. The Rendering engine will then communicate with the network stack to get the source code that is needed. After all previous steps are done, the javascript V8 will execute the source code from the rendering engine and generate a bitmap. And then the browser will communicate with data persistence to save the login information for future use. And finally, the user interface will display the webpage.

Concurrency

Nowadays, the browsers will encounter real challenges for robustness, responsiveness, and security if the browsers put everything in one process. If one of the crashes, it will cause the browser stops working. So it is really important for a browser to have a good architecture implemented to prevent the situation. Google Chrome is designed as a Multi Process Architecture to handle the concurrencies. Multi Process architecture refers to the ability of a system to support more than one processor at the same time. Multi Process architecture breaks applications to smaller routines that run 11

independently. Google Chrome takes these properties of multi process architecture and puts web applications in separate processes from the browser itself. The advantage of using the multi-process architecture is that even if a rendering engine crashes in one web application, the browser will not be affected.

Team Issues

Assuming that the Chrome team uses our conceptual architecture, here are the issues the team may face in different aspects. Since we chose the layered style for the architecture, the performance requirements may force the coupling of high-level functions to their lower-level implementations. Also, not all systems are easily structured in a layered fashion and lack of inbuilt scalability. Although the browser engine is useful for security, it makes the team have to work around the browser engine when passing information from rendering engine to UI. When developing, members may have their own mind like different opinions and views, which may cause the human error.

Lessons learned

We learned valuable lessons through this assignment that will definitely be helpful for future assignments and projects. ● Advantages and disadvantages of different styles and how to choose appropriate styles for different subsystems ● Functions of different subsystems and their interactions ● Features update of Chrome in recent years ● Clearly understands the conceptual architecture of Chrome ● How Chrome differs from other browsers

Conclusions

In conclusion, our group firstly learned from the document and had the general of what the Chrome browser. After the derivation, we settled on the conceptual architecture being layered style based on the research. The layers along with the overall code organization is consistent across all the layered projects. All the objects are kept together, so it is easy for us to quickly find an object if we need to change something in some or all the objects of a particular type. Then we chose six boxes for our architecture which are UI, browser engine, rendering engine(Blink), network stack, JavaScript V8 and Data Persistence. We analyze their different functions and the interaction between each other. Also, we dig in the rendering engine to find the subsystems inside it and the

12

process of how the engine works. We use the password saving and how to render a page that has JavaScript in Chrome as examples, drawing the sequence diagram to show how both work in Chrome using our architecture.

All of the knowledge we learned from this project will help us to progress further into the assignments to follow. After understanding the conceptual architecture and the working procedure, our group will continue investigating the concrete architecture of Chrome.

Name Convention HTTP - HyperText Transfer Protocol: defines how are formatted and ​ ​ transmitted, and what actions Web servers and browsers should take in response to various commands. FTP - The (FTP) is a standard network protocol used for the ​ ​ ​ transfer of computer files between a client and server on a computer network. ​ ​ SMTP - Simple Mail Transfer Protocol (SMTP) is an Internet standard for electronic mail ​ () transmission. URL- Uniform Resource Locator and is defined as the global address of documents and ​ ​ ​ ​ ​ ​ ​ other resources on the World Wide Web. ​ ​ XML - Extensible Markup Language is a markup language that defines a set of rules for ​ ​ encoding documents in a format that is both human-readable and machine-readable. HSTS - HTTP Strict Transport Security: a web security policy mechanism that helps to ​ ​ ​ protect websites against protocol downgrade attacks and cookie hijacking CA - Certification Authority: an entity that issues digital certificates. ​ ​ GDI - Graphic Device interface is responsible for representing graphical objects and ​ ​ transmitting them to output devices such as monitors and printers.

13

References Chrome's Objective: To Speed Up the Web For Google: ://betanews.com/2008/09/02/chrome-s-objective-to-speed-up-the-web-for -google/

Chrome's Turning 10, Here's What's New Ellie Powers - https://www.blog.google/products/chrome/chromes-turning-10-heres-whats-new

Browser Security - Protects Users & Business | Chrome Enterprise | Google Cloud https://cloud.google.com/chrome-enterprise/browser/security/

How Browsers Work – Geekyants Blog GeekyAnts - https://blog.geekyants.com/how-browsers-work-f3ef2ca29afd

How Javascript Works: the Rendering Engine and Tips To Optimize Its Performance Alexander Zlatkov - https://blog.sessionstack.com/how-javascript-works-the-rendering-engine-and-tips-to-op timize-its-performance-7b95553baeda

Network Stack https://www.chromium.org/developers/design-documents/network-stack

Introduction To Xml https://www.w3schools.com/xml/xml_whatis.asp

Developers Corner Nguyen Tuan - https://sgdev-blog.blogspot.com/2014/01/maximum-concurrent-connection-to-same.

Persistent Storage | Web | https://developers.google.com/web/updates/2016/06/persistent-storage

Behind Browser (basics - Part 1) – Venkat.r – Medium Venkat.R - https://medium.com/@ramsunvtech/behind-browser-basics-part-1-b733e9f3c0e6

14

Top View