HTTP phase

  • Enter a URL (or click a link)
  • Check the browser cache and, if cached and fresh, load the specified resource. (The following is not cached)
  • Browser parse URL fetch protocol, host, port, path
    • With juejin. Cn/post / 695973… As an example
    • Protocol: HTTPS
    • Host: juejin. Cn
    • Port: Hidden here, the HTTPS default port 443 is actually used
    • Path: post / 6959730845611458596
  • The browser assembles the parsed data into an HTTP (GET) request packet
  • The browser obtains the IP address of the host
    • Browser cache
    • This machine is the cache
    • Hosts file
    • Router cache
    • ISP DNS cache
    • DNS recursive query (different IP addresses may occur due to load balancing)
  • TCP three-way handshake
    • The general process is as follows
    • The client sends a TCP SYN=1, SEq =x packet to the server port
    • The server sends back a response packet with SYN=1, ACK =x+1, seq=Y
    • The client sends ACK =y+1 and SEq =x+1

  • After a TCP connection is established, an HTTP request is sent
  • The server accepts the request, parses it, and forwards it to the server. (The back end starts executing the corresponding code)
  • The server checks whether the HTTP request header contains cache authentication information. If the cache is fresh, the server returns the status code, such as 304

    • Here’s another cache, and if you don’t understand it, you’ve already judged the cache.

    • If the browser cache is not matched, the browser returns the cache mark. When sending a request, the server checks the freshness of the mark and returns the 304 status code. The browser retrieves the cache of the modified request.

    • The illustration is as follows:

  • The handler reads the complete request and prepares the HTTP response (the back-end program finishes processing)
  • The server sends the response back to the browser over the TCP connection
  • The browser receives the HTTP response and then chooses to close the TCP connection or keep it for reuse (request header: keep-alive keeps the request for reuse, which reduces the number of three handshakes and four waves. Http1.1 and http2 are enabled by default.
  • The four-way handshake for closing a TCP connection is as follows:
    • The active party sends a Fin=1, Seq= U packet
    • The passive sends ack= U +1, SEq = V packets
    • The passive sends Fin=1, ACK = U +1, Seq= W packets
    • The active party sends ack= W +1 and SEQ = U +1 packets

  • Does the browser check the response status: 1XX, 3XX, 4XX, 5XX, these cases are handled differently from 2XX
  • If the resource is cacheable, cache it and decode it (such as gzip compression) (go to this step if there was a cached resource in the first step)

Front page section

  • Parsing HTML documents, building document Object Model (DOM). Parse the JS code. These two steps may alternate several times on the page.
  • The DOM tree has the following code:
<! dOCTYPEHTML>
<html>
    <head>
        <title>web app </title>
        <style>#logo{color: red; }<style>
    </head>
    <body>
        <div id="logo"></div>
        <script>
            function fun() ()
            {... }</script>
     </body>
  </html>
Copy the code

Note that browsers have error-correcting mechanisms, such as placing div tags in head instead of body tags.

  • Image, style sheet, JS file encountered during parsing, start download

  • Build the CSSOM tree:

    • Tokenizing: Character stream converted to token stream
    • Node: Creates a Node based on the tag
    • CSSOM: The node creates the CSSOM tree

  • Build the render tree from the DOM tree and the CSSOM tree.

  • Start rendering process: Layout -> Paint -> Composite

  • Layout (Layout)

    • Calculate the exact position and size of each node – “Box model”

  • To draw (Paint)

    • Pixelate each node

  • Composite

    • The browser breaks down the page into different layers.
    • When changing styles, you can change the style of only one layer and draw it separately.
    • Combine the different layers to make the final web page look.

  • JS code execution

  • The browser creates the Document object, parses the HTML, and adds the parsed elements and text nodes to the Document

  • When the HTML parser encounters scripts without async and defer, it adds them to the document and then executes inline or external scripts.

  • When the JS code is executed, the rendering engine stops working, i.e. stops rendering and waits for the JS code to finish executing. That’s why the script tag comes last.

  • When the parser encounters a script with the async property set, the script file can be downloaded and executed at the same time as the rendering.

  • When the document is parsed, document.readState becomes interactive

  • The browser fires the DOMContentLoaded event on the Document object

  • Browser event handling.

    • During page construction, the browser also registers event listeners to make our application interactive.
    • All generated events are added to the same event queue in the order in which they were detected by the browser.
    • Execution process:

      • The browser checks the event queue header.

      • If the browser does not detect the event in the queue, continue checking.

      • If the browser detects an event in the queue header, it fetches the event and executes the appropriate event handler.

      • It is worth noting that the browser can only execute one event at a time and wait for the rest of the events to complete. Therefore, it is not recommended that an event take too long to execute.

The browser has now successfully displayed the correct page and is interactive.