== Steps from entering the URL from the browser address bar to displaying the page ==

directory

1. An overview of the

2.DNS domain name resolution

3. Three handshakes and four waves

4.DOM, CSSOM, construction, rendering and rendering of rendering tree

1. An overview of the

The browser sends the requested URL to the ==DNS domain name resolution ==, finds the real IP address, and sends a request to the server.

== Three times handshake == establish the connection, the server to the background processing after the completion of the return of data, browser to receive files (HTML, JS, CSS, images, etc.), data transmission after the completion of == four times wave == disconnect;

The browser parses the loaded resources (HTML, JS, CSS, etc.) to create the corresponding internal data structure

(for example, HTML DOM);

Load the parsed resource file, render the page ==, and finish.

Step 1: When you type a web site address into the browser’s address bar and press Enter, the browser constructs a request line. The line structure is simple, consisting of the request method, request URI, and HTTP version protocol. Such as:

GET/HTTP/1.1 // The request method is GET, the path is the root path, and the HTTP version is 1.1

Find strong cache

2. DNS

The browser obtains the host IP address as follows:

DNS domain name resolution is essentially a process of searching for the server IP address in the address bar

Example: www.baidu.com (domain name) – DNS resolution -> 182.61.200.6 (IP address)

2.1 Step 1: Check the cache first

2.1.1 Browser Cache

When a user accesses a domain name through the browser, the browser first searches for the IP address of the domain name in the cache

(chrome: / / version)

= = cache = = (www.cnblogs.com/chengxs/p/1…

Strong caches negotiate caches through == Expires == and ==cache-control== controls. A: Because expires has an issue where the server and browser time can be out of sync, cache-control is a relative time.

Control by == last-modify == and ==ETag==

Last-modify has a precision problem, accurate to seconds;

However, ETag (ensure that every resource is unique, resource changes will lead to changes in ETag, ETag value changes indicate that the resource has been modified), there is no precision problem as long as the file changes the ETag value

== Negotiation cache ==

Negotiation cache negotiation what?

The browser asks the server if my cached file has been updated.

1. The browser can use the cache without updating it, redirecting the status code to 304.

2. The browser cannot use the cache server to send new files to the browser, success status code 200 (OK normal return message)

== Note == :

(Strong cache: The browser fetches data directly from the local cache without interacting with the server;

Negotiated cache: the browser sends a request to the server, and the server determines whether the local cache can be used.

First request

Second request

== Cache mode ==?

(1) From memory cache: Memory cache has two characteristics, namely fast read and timeliness:

1. Fast reading: The memory cache will directly store the compiled and parsed files into the memory of the process, occupying certain memory resources of the process, so as to facilitate the fast reading of the next operation.

2. Timeliness: Once the process is closed, its memory will be emptied.

(2) From disk cache: Disk cache directly writes the cache to disk files. To read the cache, I/O operations are performed on the disk files stored in the cache, and then reparse the cache content. The reading is complex and slower than the memory cache.

2) == System cache == If the browser does not have an IP address corresponding to the domain name in the cache, the browser automatically checks whether the DNS cache of the Hosts file on the user’s computer has an IP address corresponding to the domain name

IP (C: \ Windows \ System32 \ drivers \ etc.)

3) == Router cache == If neither the browser nor the system cache has an IP address corresponding to the domain name, check the IP address in the router cache. The preceding three steps are the DNS cache of the client

4) DNS server cache / ==ISP (Internet service provider) cache == (China Mobile, China Unicom, China Telecom, Pearl River Broadband, Great Wall broadband… Etc.)

2.2 Step 2: DNS server lookup

(www.baidu.com –> www.baidu.com.)

5) == Root domain name resolution == If none of the preceding information is displayed, enter the root server for query. There are only 13 root DNS servers in the world, including 1 primary root DNS server and 12 secondary root DNS servers. After receiving the request, the root domain views the zone file records. If no, the root domain tells the local DNS server the IP address of the top-level domain name (such as.com) in its jurisdiction (using UDP, which has a maximum of 512 bytes).

What domain name resolution uses UDP protocol?

Because UDP is fast! The UDP DNS protocol requires only one request and one reply. Using THE TCP-based DNS protocol requires three handshakes, sending data, as well as answering and waving four times. However, the content transmitted through UDP cannot exceed 512 bytes. However, when a client queries a domain name from the DNS server, the returned value usually does not exceed 512 bytes, which can be transmitted through UDP.

6) == TOP-LEVEL domain name resolution == (e.g. : com, net, gov, cn, us, UK……) After receiving the request, the TOP-LEVEL DNS server checks the zone file record. If no, the TOP-LEVEL DNS server tells the local DNS server the IP address of the primary DNS server within its jurisdiction

7) == permission domain name resolution ==. The master DNS server queries its cache after receiving the request. If it does not, it goes to the next level DNS server for search and repeats this step until the correct record is found

I) Secondary domain name resolution. (Below the top-level domain cn: hk, bj, edu, gov….)

Ii) Tertiary domain name resolution. (Tsinghua, Fudan, Pku……)

Iii) Tertiary domain name resolution. (Tsinghua: lib, JWC, mailreg)

.

DNS server search usually adopts: == recursive query == or == iterative query ==

8) Save the result to the cache.

3. Three grips and four strokes:

In the TCP header == Source port == and == Destination port == In the IP packet == Source IP== And == Destination IP== Uniquely identifies a TCP connection

Seq 32-bit serial number (4 bytes =32 bits) : 37 59 56 75; Identifies the byte stream of data sent from the TCP source to the TCP receiver

Ack confirmation sequence number (4 bytes =32 bits) :

This packet is a SYN packet and the ACK flag is 0. Therefore, the ACK number is not valid. (The ACK number is valid only when the ACK flag is 1.) According to THE TCP protocol, the ACK number is valid only when the ACK value is 1

Once a connection is established, this value is always sent (same as the ACK flag)

Header length: This field contains four bits and indicates the length of the packet header, in 4 bytes. HeadLen = ((packet[12]>>4) &0x0f)*4;

Reserved six bits: The field contains six bits and is temporarily useless.

URG: 1 bit long, indicating that the emergency pointer field is valid.

==ACK== : 1 bit in length, which indicates that the confirmation number field is valid. According to the TCP protocol, == is valid only when ACK=1==, and the ACK value of all packets sent after the connection is established must be 1

PSH: 1 bit long, indicating that the current packet requires a push operation.

RST: 1 bit in length. If this bit is set, the TCP connection is reset.

==SYN== : 1 bit long, used to synchronize the sequence number when the connection is established. When SYN=1 and ACK=0, it indicates that this is a connection request packet. If the peer agrees to establish a connection, SYN=1 and ACK=1 should be set in the response packet. Therefore,==SYN 1 indicates that this is a connection request or connection accept message ==.

==FIN== : A bit long, used to indicate the end of the sender’s bit stream when releasing the TCP connection. The end, the end, is used to release a connection. == If FIN = 1, the sender finishes sending data and requests to release the connection. ==

Window size: 16 bits in length, 2 bytes.

Checksum: contains 16 bits and 2 bytes.

Emergency pointer: 16 bits in length, 2 bytes.

The preceding fields, also known as inherent fields, are required in the TCP packet header. The length is 20 bytes.

3.1 Three-way handshake to establish a connection

Q: == why three handshakes instead of two? = =

A: In the case of two handshakes, the client knows that the server can send and receive packets, but the server only knows that the client can send packets, but does not know whether the client can receive packets.

TCP is a connection-oriented transport layer a safe and reliable transport protocol, three-way handshake mechanism is to ensure that can build a safe, reliable connection, so the first time to shake hands is initiated by the client, the client will send a message to the service side, inside the message: the SYN flag position is 1, said a new connection. After receiving this message, the server knows that the client wants to establish a new connection with me, so the server sends an acknowledgement message to the client. In this message packet, the ack flag position is 1, indicating that the first connection request initiated by the client is confirmed. After the above two handshakes, it is clear to the client that I can successfully send a message to the server and also receive a response from the server. But for the server: two handshakes is not enough, because so far, the server only knows one thing: the client sends me a message and I can receive it, but I respond to the client’s message and I don’t know whether the client can receive it. Therefore, a third handshake is required. The third handshake is an ACKNOWLEDGEMENT message with ack flag 1 sent by the client after receiving the acknowledgement response packet sent by the server. Through the above three connections, both the client and the server know that I can send messages to the other side and receive the response from the other side. Then, the connection is securely established.

Transition step: == Data transfer from server to client ==

Disconnect……. after transmission So how do you disconnect?

3.2 Wave four times

Q: == is it necessary for the client to finally set the 2MSL wait time? = =

A: If there is no 2MSL waiting time, if the client loses its last acknowledgement packet, the server will repeatedly trigger timeout retransmission because it fails to receive the acknowledgement packet from the client, as shown in the figure below:

Q: == Why are the two packets on the server not combined into one packet and sent at a time? = =

A: After the client sends a Fin=1 disconnection request packet, the server may have incomplete data transmission. Therefore, when receiving the disconnection request packet from the client, the server replies with ACK=1 to acknowledge receipt, indicating that: “I received the FIN=1 packet you sent (but this does not mean that data transmission is complete).” After all data transmission is complete, the server returns a FIN=1 release packet.

Transition step: == If the resource is cacheable, cache it; The response is decoded (such as gzip compression), and then depending on the resource type, what to do with ==

4. Browser parsing and rendering

Nuggets – What you don’t know about browser page rendering mechanisms (juejin.cn/post/684490…

After receiving the HTTP request, the server computes (pushes different content to different users) and returns the HTTP request with the following content:

It’s just a bunch of HMTL bytes, because only HTML can be properly parsed by the browser, as required by the W3C standard. Next comes the browser’s rendering process.

4.0 Browser Rendering Process (Overview)

1) Browsers parse three things:

• The first is HTML/SVG/XHTML. The HTML string describes the structure of a page. The browser will parse the HTML structure string into a ==DOM tree == structure.

• The second is CSS. Parsing CSS produces a CSS rule tree, which is similar to the DOM structure.

• The third is Javascript script. After the Javascript script file is loaded, DOM API and CSSOM API are used to operate DOM Tree and CSS Rule Tree.

2) After parsing, the browser engine creates the Rendering Tree using DOM Tree and CSS Rule Tree.

• A Rendering Tree is not the same as a DOM Tree, the Rendering Tree only contains the nodes to be displayed and the style information for those nodes.
• CSS Rule Tree is used to match and attach CSS rules to each Element (i.e. each Frame) on the Rendering Tree.
• Then, the position of each Frame is calculated, which is also called layout and Reflow procedures.

3) Finally draw by calling the API of the operating system Native GUI.

(Next, we will elaborate on the important steps in this process.)

4.1 build the DOM

The browser follows a set of steps to convert the HTML file into a DOM tree. Macroscopically, it can be divided into several steps:

• The browser reads the HTML’s == raw bytes == from disk or the network and converts them to the == string == based on the file’s specified encoding, such as UTF-8.

All the stuff that’s going around the network is zeros and ones. When the browser receives these bytes of data, it converts them into a string, which is the code we wrote.

• Convert string to ==Token==, for example:,And so on.Tokens are identified as “start tag”, “end tag”, or “text”.

At this time you must have a question, how to maintain the relationship between nodes?

In fact, that’s what tokens are supposed to do with tokens like “start tag” and “end tag.” For example, the == node between the start tag and end tag of the title Token must be a child node of the head Token.

The figure above shows the relationship between nodes, for example: The “Hello” Token is located between the “title” start tag and the “title” end tag, indicating that the “Hello” Token is a child node of the “title” Token. Similarly, the title Token is the child node of the Head Token.

• Generate node objects and build ==DOM==

In fact, in the process of == DOM construction, instead of generating node objects after all tokens are converted, the node objects == are generated by consuming tokens while generating tokens. In other words, as soon as each Token is generated, the Token is consumed to create a node object. Note: Tokens with an end tag identifier do not create node objects.

Let’s take an example. Suppose we have some HTML text:

<html>

<body> <div> <h1>Web page parsing</h1> <p>This is an example Web page.</p> </div> </body> </html>

The above HTML will parse like this:

4.2 build CSSOM

The DOM captures the content of the page, but the browser also needs to know how the page is presented, so you need to build CSSOM.

The process of building a CSSOM is very similar to the process of building a DOM. When a browser receives a piece of CSS, the first thing the browser does is recognize the Token, then build the node and generate the CSSOM

During this process, the browser determines what the style of each node is, and this process can be very resource-intensive. Because styles can be set to a node or inherited. In this process, the browser recurses the ==CSSOM tree == and determines what style the specific elements are.

Note: CSS matching HTML elements is a fairly complex and performance problem. Therefore, the DOM tree should be small, CSS should try to use ID and class, do not transition layer on layer.

4.3 Build the rendering tree

Once we have generated the DOM tree and the CSSOM tree, we need to combine the two trees into a == rendering tree ==.

In this process, it is not as simple as merging the two. The render tree contains only the nodes that need to be displayed and their style information. If a node is display: None, it will not be displayed in the render tree.

We may have a question: == browser if the rendering process encountered JS file ==?

During rendering, if encountered, stop rendering and execute JS code. Because browsers have GUI rendering threads and JS engine threads, the two threads are mutually exclusive in order to prevent unexpected results from rendering. The loading, parsing, and execution of JavaScript will block DOM construction, that is, if the HTML parser encounters JavaScript during DOM construction, it will suspend DOM construction and hand over control to the JavaScript engine. When the JavaScript engine is finished running, The browser then picks up the DOM build from where it left off.

That said, if you want the first screen to render as quickly as possible, you should not load JS files on the first screen, which is why it is recommended to place the script tag at the bottom of the body tag. At this point, of course, it’s not necessary to put the Script tag at the bottom, as you can add either defer or async properties to the script tag (the difference between the two is described below).

The JS file doesn’t just block DOM building, it can cause CSSOM to block DOM building as well.

Originally, DOM and CSSOM were constructed independently of each other, but once JavaScript was introduced, CSSOM also started blocking DOM construction, and only after the COMPLETION of CSSOM construction, DOM construction resumed.

What’s going on here?

This is because JavaScript can not only change the DOM, it can also change styles, which means it can change CSSOM. Because incomplete CSSOM cannot be used, JavaScript must get the full CSSOM when executing JavaScript if it wants to access it and change it. As a result, if the browser has not finished downloading and building CSSOM, and we want to run the script at this point, the browser will delay script execution and DOM building until it has finished downloading and building CSSOM. That is, in this case, the browser downloads and builds CSSOM, then executes JavaScript, and then continues to build the DOM. = =

4.4 Layout and Drawing

When the browser generates the render tree, the layout (also known as backflow) is performed based on the render tree. All the browser has to do at this stage is figure out the exact location and size of each node on the page. This behavior is often referred to as “automatic reordering.”

The output of the layout process is a “box model” that accurately captures the exact position and size of each element within the viewport, and all relative measurements are translated into absolute pixels on the screen.

Immediately after the layout is complete, the browser issues “Paint Setup” and “Paint” events that convert the render tree into pixels on the screen.

4.5 Redraw and Rearrange (extended)

The rendering process basically looks like this (the four yellow steps below) : 1. Compute CSS style 2. Build Render Tree 3.Layout – Position coordinates and size 4. Officially open draw

Two concepts are important here, one is Reflow and the other is Repaint

• == redraw == : When we make changes to the DOM that result in a change in the style of == without affecting its geometry (such as changing the color or background color) ==, the browser doesn’t need to recalcate the element’s geometry and simply draw the element in a new style (skipping the backflow shown above).
• == backflow == : When we modify the DOM to cause a change in the GEOMETRY of the DOM (such as changing the width or height of the element, or hiding the element) ==, the browser needs to recalculate the geometry of the element (which also affects the geometry and position of other elements), and then draw the calculated result. This process is called reflux (also known as rearrangement)

We know that when a web page is generated, it will be rendered at least once. It is constantly re-rendered as the user accesses it. Rerender will repeat reflux + redraw or only redraw. == rearrangement (backflow) will occur redraw, redraw does not necessarily cause rearrangement (backflow) ==. Redraw and backflow occur frequently when we set the node style, and can greatly affect performance. The cost of backflow is much higher, and changing the child node in the parent node is likely to result in a series of backflows in the parent node.

1) Properties and methods commonly used to cause rearrangement (reflux)

Any operation that == changes element geometry (element position and size)== triggers backflow,

• Add or remove visible DOM elements
• Element size changes — margins, padding, borders, width, and height
• Content changes, such as the user entering text in an input box
• Browser window size changes – when the resize event occurs
• Calculate the offsetWidth and offsetHeight properties
• Sets the value of the style property

2) Redraw properties and methods are commonly caused

3) How to reduce backflow and redraw

• Use transform instead of top

• Use visibility instead of display: None, because the former will only cause redraw and the latter will cause backflow (changing the layout)

• Do not put node property values in a loop as variables in the loop.

  for(let i = 0; i < 1000; Console. log(document.querySelector(‘.test’).style.offsettop)}

Do not use the table layout, it is possible that a small change will cause the entire table to be rearranged

Select the speed of the animation implementation, the faster the animation, the more backflows, you can also choose to use requestAnimationFrame

CSS selectors match from right to left to avoid too many node hierarchies

Set nodes that are frequently redrawn or reflow as layers to prevent their rendering behavior from affecting other nodes. For the video TAB, for example, the browser automatically turns the node into a layer.

4.6 summarize

From what has been discussed above, we may come to the conclusion that…

• Browser workflow: Build DOM -> Build CSSOM -> Build render tree -> Layout -> Draw.
• CSSOM blocks the rendering and only moves on to the next stage of building the rendering tree once the CSSOM is built.
• Normally DOM and CSSOM are built in parallel, but when the browser encounters aScript tag that doesn’t defer or async, DOM building will stop. If the browser hasn’t finished downloading and building CSSOM at this point, JavaScript can modify CSSOM, So you need to wait until the CSSOM is built before executing JS, and then re-dom is built.

(Note: this article is for personal study and collation, if there is anything wrong in the article, please also point out in the comments section!)