As front-end developers, the tools we are most familiar with are the browser, so have we seen what the browser rendering process looks like? Let’s take a look at the rendering process.

Start with the structure of the browser

From the structure of the browser, the browser mainly consists of eight subsystems:

  1. Interface module
  2. Browser engine
  3. Rendering engine
  4. Network subsystem
  5. JavaScript interpreter
  6. The XML parser
  7. According to the backend
  8. Data persistence subsystem
Multiprocess structure

Take our common Chrome browser for example, Chrome uses a multi-process architecture, mainly divided into four processes:

  1. Browser process
  2. Plug-in process
  3. Rendering process
  4. GPU process
Threads in the Chrome renderer process
  1. GUI rendering thread (responsible for rendering the browser interface)
  2. JavaScript engine threads (responsible for parsing and executing JavaScript scripts)
  3. Browser timer triggers thread (setTimeout, setInterval thread)
  4. Browser event-triggering thread (responsible for handling browser events and putting the code executed after the event is triggered into the JavaScript engine for execution)
Threads in the Chrome process
  1. UI thread (used to draw browser buttons and input fields)
  2. Network threads (used to process network requests and data received from the server)
  3. Storage threads (used to control access to files)

Enter the URL to the entire page to complete the rendering

The DNS

In the DNS domain name resolution process, is involved in the DNS search process, and then is to find the server where the web resources are stored.

The browser establishes a TCP connection with the server (TCP three-way handshake establishes the established connection and four-way handshake disconnects the connection). The TCP three-way handshake includes:

SYN  =>  SYN ACK   => ACK RECEIVED
Copy the code

  1. Build request

  2. Find the cache and fetch the cache if there is one

  3. The IP address and port number are available

  4. Waiting for TCP queue

  5. Establishing a TCP connection (TCP three-way handshake)

This process refers to the establishment of a TCP connection. During this process, the client and server need to send three packets to confirm the connection.

  1. Sending an HTTP request

  2. Close the TCP connection (TCP wave four times)

Quadruple wave: Indicates the disconnection process of TCP connection. During this process, the client and server send four packets to confirm the connection closure.

  1. The HTTP response

Of course, I do not know if there is a small partner will think,TCP three handshakes which can safely carry data? At what stage of the three-way handshake does accept, which also includes TCP, take place?

The Accept process takes place after three handshakes, after which the client and server establish a TCP connection and can interact with each other.

You can then call the Accept function to obtain the connection.

Is the connection considered successful?

After connect returns a successful return, the three-way handshake is complete.

The completed links are placed in a queue. Accept takes the link with the highest priority from the queue and binds it to a new FD. The server can recv and send data with this new FD.

For the third handshake, you can carry it. The first two handshakes cannot carry data.

If the first two handshakes can carry data, the attacker only needs to send a large amount of data in the SYN packet in the first handshake to attack the server. As a result, the server consumes more time and memory space to process the data, increasing the risk of attack.

On the third handshake, the client is in the ESTABLISHED state, and you can confirm that the server is receiving and sending data properly.

Note: The ACK of the last handshake from the client does not have to wait for the HTTP response from the server to arrive before being sent; there is no relationship between the two processes.

During the first handshake, the server computes the cookie and sends it to the client for caching. Subsequent handshake clients carry the cookie for SYN.

If the cookie is invalid, it is discarded. If the cookie is valid, the HTTP response can be sent directly.

TCP queue header block and HTTP header block
  1. The TCP queue header is blocked

Many people believe that TCP does not have packet loss. UDP does not have packet loss. In my opinion, TCP packets are transmitted sequentially. (Stop waiting)

  1. The HTTP header is blocked

HTTP header blocking is not the same thing as TCP header blocking.

Http1. x uses a keep-alive Connection to send multiple HTTP requests over a TCP request.

There are two ways: decanting and pipelining.

Non-pipelining, completely serial execution, request -> response -> request -> response… , the latter request must be sent after the previous response.

Pipelining, requests can be sent in parallel, but responses must be returned sequentially. The latter response must follow the previous one. The reason is that there is no serial number to indicate the order, only serial reception.

The Achilles heel of pipelining requests:

The queue header is blocked. The previous response is not returned in time. The subsequent blocked request must be idempotent and cannot modify the resource. When an unexpected interruption occurs, the client needs to resend the request that has not received a response, which is a non-idempotent request, causing resource destruction. For this reason, most browsers and Web servers are now off pipelined and in unpipelined mode.

Either unchanneled or channeled causes queue head blocking (request blocking).

HTTP header block

  1. Concurrent TCP connections (browser uses 6-8 TCP connections for a domain name and concurrent HTTP requests)

  2. Domain name sharding (Multiple domain names can establish more TCP connections and increase the concurrency of HTTP requests)

  3. HTTP2 way

Http2 uses a single domain name TCP connection to send requests. The request packet is divided into binary frames ** (multiplexing) ** different requests can be interspersed, avoiding HTTP layer queue header blocking. However, header blocking at the TCP level cannot be avoided.

UDP

How to implement UDP reliable transmission?

The transport layer cannot guarantee the reliable transmission of data, only through the application layer to achieve.

The implementation method can refer to the TCP reliability transmission method, but the implementation is not the transmission layer, the implementation is transferred to the application layer.

The simplest way is to emulate the reliability of TRANSPORT layer TCP transport at the application layer.

The following is a simple design for reliable UDP without regard to congestion handling.

1. Add seQ/ACK to ensure that data is sent to the peer end

2, add send and receive buffer, mainly the user timeout retransmission.

3. Add timeout retransmission mechanism.

– When sending data, generate a random SEq =x, and then allocate SEQ to each piece according to the data size. After the data arrives at the receiver, the receiver puts it into the cache and sends an ACK =x packet to indicate that the receiver has received the data. After receiving the ACK packet, the sender deletes the data in the buffer. When the time is up, a scheduled task checks whether data needs to be retransmitted. Parser: Parses HTML/CSS/JavaScript code.

In fact, in front of performance optimization, the optimization of the network request is often occupied very big one part, including the first screen straight out, the subcontract loading, data fragmentation pull, use the cache, preload, etc., by reducing network reasonably request content, reduce network request of waiting time, optimize the expected effect.

Layout of 3.

Layout: location coordinates and size, whether to wrap, various position/overflow/ Z-index attributes calculation, etc.

Paint: Determines the order in which elements are rendered.

Raster: The conversion of computed information into pixels on the screen.

  1. parsing

The main thread of the renderer process parses the following:

Parsing THE HTML content produces a DOM node tree;

The CSS is parsed to generate a CSS rule tree.

Parsing Javascript scripts, because Javascript scripts can manipulate the DOM node tree and CSS rule tree through the DOM API and the CSSOM API, this process will wait for Javascript to complete before parsing HTML.

After parsing, we get DOM node Tree and CSS rule Tree. The layout process is to construct the Render Tree through DOM node Tree and CSS rule Tree.

  1. layout

After parsing, the renderer process knows the structure and style of each node, but if a page needs to be rendered, the browser also needs to lay it out, which is often referred to as the creation of a render tree.

In this process, elements like header or display: None are stored in the DOM node tree, but are not added to the render tree.

After the layout is complete, the drawing process will be entered.

  1. draw

During the draw step, the renderer main thread traverses the render tree to create the draw record.

Note that if the render tree changes, the renderer triggers Repaint and Reflow.

Redraw: Part of the screen is redrawn, such as a CSS with a different background color but the geometry of the elements remains the same.

Rearrangement (reflux) : The geometry of the element has changed (part or all of the render tree has changed) and the render tree needs to be revalidated and evaluated.

To avoid a complete layout calculation for every small change, the renderer marks the changed element and its children with dirty bits, indicating that the element needs to be rearranged. Global style changes trigger global layout, partial style or element changes trigger incremental layout, which is done asynchronously, and global layout fires synchronously.

Backflow needs to involve changes in all node geometry and locations, at a much higher cost than drawing. It is important to avoid frequent operations such as adding, deleting, modifying DOM nodes, moving DOM positions, Resize Windows, and scrolling, which can lead to performance degradation.

  1. rasterizer

Through the parsing, layout, and drawing process, the browser gets information about the structure of the document, the style of each element, the order in which it is drawn, and so on. This information is converted into pixels on the screen, a process called rasterization.

Rasterization can be accelerated by GPU, and the rasterized bitmap will be stored in GPU memory. According to the rendering process described earlier, when the page layout changes, rearrangement and redrawing are triggered, and rasterization needs to be redone. If there are animations on the page at this point, too many computations in the main thread will likely affect the performance of the animations.

As a result, modern browsers typically use compositing, dividing the parts of the page into several layers, rasterizing them (dividing them into different tiles), and compositing the page through synthesizer threads.

The synthesis process is as follows:

When the main thread creates the composition layer and determines the drawing order, it submits this information to the composition thread.

The synthesizer thread rasterizes each layer and then sends each block to the raster thread;

Raster threads raster each tile and store them in GPU memory;

The synthesizer thread submits to the browser process via IPC, and these synthesizer frames are sent to the GPU process for processing and display on the screen.

The real purpose of composition is to move layers without having to reraster them. Because of the synthesizer thread, the page can scroll smoothly independently of the main thread.

At this point, the page is actually rendered to the screen.

There are also some strange rendering issues that can occur when drawing a page, such as using transform: Scale which can cause rendering to be blurred in some browsers due to the rasterization process.

conclusion

1. The DNS

2. A TCP connection

3. Send an HTTP request

4. The server processes the request and returns the required data

5. The browser parses the rendered page

6. The connection ends

Enter the domain name, the domain name through DNS resolution to find the corresponding server address (IP) of the domain name, through THE TCP request link service, through the WEB server (Apache) to return the data, the browser according to the returned data to build a DOM tree, through the CSS rendering engine and JS parsing engine to render the page, close the TCP connection.

Please correct the deficiencies