bzdww

Get answers and suggestions for various questions from here

"Tian Long Eight Steps" details what happened after the browser entered the URL.

cms

Summary of this article:
1. DNS domain name resolution;
2. Establish TCP connection;
3. Send HTTP request;
4. Server process request;
5. Return response result;
6. Close TCP connection;
7. Browser parses HTML;
8. Browser Layout rendering

First, DNS domain name resolution

We enter the URL in the browser, in fact, we want to request the content of the page we want from the server. All browsers must first confirm where the server corresponding to the domain name is. The work of resolving the domain name into the corresponding server IP address is done by the DNS server.

After the client receives the domain name address you entered, it first goes to the local hosts file to check whether there is a corresponding domain name and IP correspondence in the file. If there is, send a request to its IP address. If not, then Go to the DNS server. The average user rarely edits and modifies the hosts file.



Browser client sends to the local DNS server contains a domain name cnblogs.com DNS query message. The local DNS server forwards the query message to the root DNS server, and the root DNS server notices its com suffix, and then returns the IP address of the comDNS server to the local DNS server. Local DNS server sends a query request to the server again to comDNS, comDNS server notices that cnblogs.com The suffix is ​​replied to with the IP address of the authoritative DNS server responsible for the domain name. Finally, the local DNS server will contain Cnblogs.com The response message of the IP address is sent to the client.

The client to the local server is a recursive query, and the interaction between the DNS servers is an iterative query.
Normally, the address of the comDNS server is already in the cache of the local DNS server, so the step of requesting the root domain name server is not required.

Second, establish a TCP link

After a long delay, I finally got the server IP. The next step is naturally to link to the server. For the TCP link between the client and the server, it is necessary to say "three-way handshake".



The client sends a data packet with the SYN flag to the server. After receiving the message, the server sends back a data packet with the SYN/ACK flag to convey the confirmation message. Finally, the client sends back an ACK flag. The data packet indicates the end of the handshake and the connection is successful.

The above picture can also be understood as follows:

Client: "Hello, not at home, there is your courier."

Server: "Yes, send it on."

Client: "Well."

Third, send an HTTP request

Once the connection to the server is established, the request can be made to the server. Here we first look at the structure of the request message (as shown below):


View the message header in the browser (take google browser as an example):


The request line includes the request method, URI, and HTTP version. The header field conveys important information, including the request header field, the generic header field, and the entity header field. We can see the specific information of the request sent from the message. The role of each header field is not explained here.

Fourth, the server handles the request

After the server receives the request, the web server (accurately speaking, it should be the http server) processes the request, such as Apache, Ngnix, IIS, and so on. The web server parses the user request, knows which resource files need to be scheduled, processes the user requests and parameters through the corresponding resource files, and calls the database information, and finally returns the result to the browser client through the web server.



Fifth, return the response result

In HTTP, there will be a response if there is a request, even if it is an error message. Here we also look at the composition of the response message:



There will be an HTTP status code in the response, such as 200, 301, 404, 500, etc., which we are familiar with. Through this status code, we can know whether the processing on the server side is normal and can understand the specific error.

The status code consists of a 3-digit number and a reason phrase. According to the first digit, the status codes can be divided into five categories:



Sixth, close the TCP connection

In order to avoid the resource occupation and loss of both the server and the client, when either party does not request or respond to the delivery, either party can initiate a shutdown request. Similar to the 3-way handshake to create a TCP connection, closing the TCP connection requires 4 handshakes.


The above picture can be understood as follows:

Client: "Brother, I have no data to pass here, oh close the connection."

Server: "Received, I have a look at the data on my side."

Server: "Brother, I have no data to pass you here, you can close the connection."

Client: "Well."

Seven, browser parsing HTML

To be precise, browsers need to load and parse more than just HTML, but also CSS, JS. And also load other media resources such as images and videos.

The browser parses the HTML, generates a DOM tree, parses the CSS, generates a CSS rule tree, and then generates a rendering tree through the DOM tree and the CSS rule tree. The rendering tree is different from the DOM tree. There is no node in the rendering tree, such as head and display, which are not necessarily displayed.

It should be noted that the browser parsing process is not serialized. For example, while parsing CSS, you can continue to load parsing HTML. However, when parsing and executing JS scripts, it will stop parsing subsequent HTML, which will cause blocking problems. Regarding the JS blocking related issues, it is not explained here, but will be explained separately later.

Eight, browser layout rendering

According to the rendering tree layout, calculate the CSS style, that is, the geometric information such as the size and position of each node in the page. HTML defaults to streaming layout, CSS and js will break this layout, changing the look and feel of the DOM as well as its size and position. Two important concepts are mentioned at this time: replaint and reflow.

Replaint: A part of the screen is redrawn without affecting the overall layout. For example, the background color of a CSS is changed, but the geometric size and position of the element are unchanged.

Reflow: means that the geometry of the component has changed, we need to re-verify and calculate the render tree. Some or all of the rendering tree has changed. This is Reflow, or Layout.
So we should try to minimize reflow and replaint, I think this is one of the reasons why there is very little useful table layout.

Finally, the browser draws each node and presents the page to the user.

to sum up

This article systematically describes the overall flow from the browser to the input domain name to the final page display. Due to space limitations, each step of this article is not comprehensive, so I will separately explain the domain name resolution, HTTP request/response, browser parsing, rendering, etc., and interested friends can also pay attention to my personal. Blog.

reference:

igoro.com/archive/what-

taligarsiel.com/Project

zhihu.com/question/3487

Image Maker: Axure, PS, Ulead GIF Animator, ProcessOn


Author: GavinHsueh

Link: imooc.com/article/21340

Source: MOOC