Because the last interview, did not prepare this question, very embarrassed shallow level answer, make the interview more anxious.

So LET me take this opportunity to look at and understand this problem carefully.

I read a lot of articles, come to some experience, URL input to browser parsing probably experienced the following several processes.

URL parsing

The DNS query

TCP/IP connection

The HTTP request

Respond to the request

Page rendering

TCP Disconnection

URL parsing

First we need to understand the preparatory knowledge

A URL is a uniform resource locator that represents the address of a resource

The composition of the URL

URL is mainly composed of protocol, domain name, port, path, query parameters, anchor point 6 parts!

http://www.example.com:80/path/index.html?key1=value1&key2=value2#SomewhereInTheDocument
Copy the code
  • httpIs the agreement. It indicates which protocol the browser must use, and the most common protocols are HTTP, HTTPS.
  • www.example.comIt can be a domain name or an IP address.
  • : 80Is the port. The same domain may contain multiple websites, which are distinguished by ports. The default HTTP port is port 80. If no data is written, the default HTTP port is port 80. The HTTPS port is 443.
  • /path/index.htmlIs the path to a resource on a web server. The path to a resource on a web server, for example, to a web site/pathSubdirectory below the web page fileindex.html.
  • ? key1=value1&key2=value2Is additional information provided to the web server. If you want to pass parameters to the server, enter them in this section.
  • #SomewhereInTheDocumentIs an anchor point for another part of the resource itself. When the browser loads the page, it scrolls to the location of the anchor point. The anchor name passes through the page elementidAttribute name.

How to parse

After entering the URL in the address bar, the browser will parse UR to extract the domain name field, such as www.baidu.com. The domain name www.baidu.com is resolved.

Then the NEXT step is DNS resolution

The DNS

You can think of domain name resolution this way. To resolve a domain name to an IP address, the browser sends a UDP packet to the DNS server.

DNS query works as follows:

The query mode between the client and browser and the local DNS is recursive query.

The query mode between the local DNS server and the root domain and its subdomains is iterative query.

Let’s take a look at a picture to see the whole parsing process:

Recursive query

Our browsers, operating systems, and routers all cache SOME IP addresses corresponding to urls, collectively known as THE DNS cache. This is to speed up DNS resolution so that you do not have to go to the root DNS server every time.

The steps of recursive query are

The first step: browser cache query, now browse the cache to find whether there is a corresponding domain name IP, if there is the resolution process will end, if there is no static ru next step.

Step 2: System cache query. The operating system checks its local hosts file. If yes, invoke the IP address first to complete domain name resolution. If not, it goes to step 3

Step 3: Query the router cache. The router has its own DNS cache. If no corresponding IP address can be found in the router cache, the router will go to the next step.

Step 4: DNS server query, here is iterative query

Iterative query

The recursive search process is as follows:

The recursive search process is as follows: for example, if we visit: www.baidu.com, we cannot find it in the recursive query

  • The local DNS server queries the root DNS server. This process does not return the mapping, but tells you to go to the subordinate server (the top-level DNS server)

  • A local DNS server query to a top-level domain name server (that is, a COM server) also does not return a mapping, but only directs you to a secondary DNS server

  • The local DNS server queries the secondary domain name server (the Baidu.com server). If the secondary domain name server exists, the mapping relationship is returned.

  • Get the IP and send it to the local DNS, then return it to the computer, but also cache it, so that it can quickly enter next time, and finally establish a connection with the target server.

Note: iteration does not query the IP address itself, but finds the relevant server IP address and returns it to the client. The client will continuously query these servers until the location is found.

After a few queries, you get the IP and start building links:

TCP/IP connection

Preliminary knowledge

SYN Synchronization bit SYN=1 indicates that a link request is made

ACK bit ACK=1 Confirm valid ACK=0 Confirm invalid

Ack Confirmation number Indicates the number +1 sent by the peer party

Seq serial number random

FIN Terminate FIN= 1 Data has been sent and needs to be released.

Simple dialogue, basic understanding of three handshakes

C: I’m going to text you

S: Ok, I’m ready. Go ahead

C: Ok, copy that

After the DNS resolves the IP, it is time to establish a link, which will go through three handshakes

  • First handshake: When establishing a connection, the client sends a SYN packet (SYN = J) to the server and enters the SYN_SENT state, waiting for confirmation from the server. SYN: Indicates the Synchronize Sequence number.
  • Second handshake: After receiving a SYN packet, the server must acknowledge the client’s SYN (ACK = J +1) and send a SYN packet (ACK = K). In this case, the server enters the SYN_RECV state.
  • Third handshake: After receiving the SYN+ACK packet from the server, the client sends an ACK packet (ACK = K +1) to the server. After the packet is sent, the client and the server enter the ESTABLISHED state (TCP connection is successful) and complete the three-way handshake.

The packet transmitted during the handshake does not contain data. After three handshakes, the client and server start data transmission.

After the TCP three-way handshake is complete, HTTP request packets are sent.

The HTTP request

The process of sending an HTTP request is to construct an HTTP request packet and send it to a specified port on the server through TCP. A request packet consists of a request line, a request header, and a request body.

The request line

Contains the request method, URL, and protocol version

  • There are eight request methods: GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS, and TRACE.
  • The URL is the requested address, which is specified by < protocol > : //< host > : < port >/< path >? < parameters > composition
  • Protocol version Indicates the HTTP version number

Request header

The request header notifies the server that there is information about the client request. It contains a lot of useful information about the client environment and the request body. For example, Host indicates the Host name and virtual Host. Connection,HTTP/1.1 added to use keepalive, a Connection can send more than one request; User-agent, request originator, compatibility, and customization requirements.

Request body

It can hold data for multiple request parameters, including carriage returns, newlines, and request data, which may not be present in all requests. The picture above bears three request parameters: name, password and realName.

Respond to the request

The application that handles requests, the Web Server, is installed on each server. Common Web server products include Apache, Nginx, IIS, or Lighttpd. Web server plays the role of control. For the requests sent by different users, it will combine configuration files and entrust different requests to the programs that process the corresponding requests on the server for processing (such as CGI scripts, JSP scripts, Servlets, ASP scripts, server-side JavaScript, Or some other server-side technology, etc.), and returns the result of daemon processing as a response.

The HTTP response message also consists of three parts (response line + response header + response body).

The HTML,CSS, and JS files requested from the server are placed in the response body.

Status code, which tells the client the result of the request in unambiguous language.

1XX: indicates that the request has been received and processing continues.

2xx: success – The request is successfully received, understood, or accepted.

3xx: Redirect – Further action must be taken to complete the request.

4XX: client error – The request has a syntax error or the request cannot be implemented.

5xx: Server side error – The server failed to fulfill a valid request.

Page rendering

At this point we have the data.

The next step is to parse and render the retrieved content, which is where the browser comes in.

There are five steps that browsers take to parse a rendered page:

1. Parse the DOM tree based on HTML

  • According to the content of HTML, tags are parsed into a DOM tree according to the structure. The DOM tree parsing process is a depth-first traversal. That is, all children of the current node are built before the next sibling node is built.
  • If a script tag is encountered during the process of reading an HTML document and building a DOM tree, the building of the DOM tree is suspended until the script is executed.

2. Generate CSS rule tree (CSSOM) based on CSS parsing

  • Js execution is paused while the CSS rule tree is parsed until the CSS rule tree is ready.
  • Browsers do not render until the CSS rule tree is generated.

3. Generate a rendering tree by combining DOM tree and CSS rule tree

  • After the DOM tree and CSS rule tree are all ready, the browser starts building the render tree.
  • Simplifying CSS can also speed up the building of CSS rule trees, resulting in faster pages.

4. Calculate the information of each node according to the render tree (layout)

  • Layout: Calculates the position and size of each render object from the render object information in the render tree
  • Backflow: After the layout is complete, it is found that some part of the layout has changed and needs to be rerendered.

5. Draw the page based on the calculated information

  • In the paint phase, the system traverses the render tree and calls the renderer’s “paint” method to display the renderer’s contents on the screen.
  • Redraw: Attributes such as the background color, text color, etc. of an element that do not affect the layout around or inside the element will only cause the browser to redraw.
  • Backflow: If the size of an element changes, the render tree needs to be recalculated and re-rendered.

What you need to know

backflow

When the size, structure, or attributes of some or all of the elements in the Render Tree change, the process by which the browser rerenders some or all of the document is called reflux.

Operations that cause backflow:

  • Page first render
  • The browser window size changed. Procedure
  • The size or position of the element changed
  • Element content changes (number of words or image size, etc.)
  • Element font size changes
  • Add or removevisibletheDOMThe element
  • The activationCSSPseudo classes (e.g.:hover)
  • Query some properties or call some methods

Some common properties and methods that cause backflow:

  • clientWidth,clientHeight,clientTop,clientLeft
  • offsetWidth,offsetHeight,offsetTop,offsetLeft
  • scrollWidth,scrollHeight,scrollTop,scrollLeft
  • scrollIntoView(),scrollIntoViewIfNeeded()
  • getComputedStyle()
  • getBoundingClientRect()
  • scrollTo()

redraw

When a change in the style of an element in a page does not affect its position in the document flow (e.g., color, background-color, visibility, etc.), the browser assigns the new style to the element and redraws it, a process called redraw.

TCP Disconnection

When data transfer is complete, you need to disconnect the TCP connection and initiate the TCP wave four times.

Simple dialogue, basic understanding of the four wave

C: I’ve finished sending my message.

S: Ok, I heard you. Then I won’t receive your messages anymore.

S: I don’t need to text you anymore (full-duplex)

C: Ok, it’s closed

  • 1) The client process sends a connection release packet and stops sending data. Release the header of the data packet, FIN=1, whose sequence number is SEq = U (equal to the sequence number of the last byte of the previously transmitted data plus 1). At this point, the client enters the fin-WaIT-1 state. According to TCP, FIN packets consume a sequence number even if they do not carry data.

  • 2) After receiving the connection release packet, the server sends an acknowledgement packet with ACK=1, ACK= U +1 and its serial number seq= V. Then, the server enters the close-wait state. The TCP server notifies the higher-level application process that the client is released from the direction of the server. This state is half-closed, that is, the client has no data to send, but if the server sends data, the client still accepts it. This state also lasts for a period of time, i.e. the duration of the close-wait state.

  • 3) After receiving the acknowledgement request from the server, the client enters the fin-WaIT-2 state and waits for the server to send the connection release message (before receiving the final data from the server).

  • 4) After sending the final data, the server sends a connection release packet to the client, FIN=1, ACK = U +1. Because the server is in the semi-closed state, it is likely to send some more data. Assume that the serial number is SEQ = W, then the server enters the last-ACK state, waiting for the confirmation of the client.

  • 5) After receiving the connection release packet from the server, the client must send an acknowledgement with ACK=1, ACK= W +1 and its serial number is SEq = U +1. In this case, the client enters the time-wait state. Note that the TCP connection is not released, and the client enters the CLOSED state only after the client revokes the corresponding TCB after 2*MSL (maximum packet segment life).

  • 6) As long as the server receives the confirmation from the client, it will enter the CLOSED state immediately. Similarly, revoking the TCB terminates the TCP connection. As you can see, the server ends the TCP connection earlier than the client.

Refer to the article

What happens when you go from URL input to page presentation? TCP connection three times handshake, four times waved down summary of common problems: TCP three times handshake four times waved down profound summary: Start from the input URL to build front-end knowledge system browser Reflow & Repaint