Browser page rendering process

The process that a browser goes through from entering a link to rendering the page.

DNS resolution

First, the browser performs a DNS resolution on the entered link, which is the process of converting a domain name to an IP address, obtaining the specific IP address of the server and enabling TCP connection and data transmission.
In the specific DNS resolution process, the browser first checks its own DNS cache for the IP address of the domain name. In Chrome, the caching time for domain name resolution is 60s, and the DNS cache can be cleared by entering chrome://net-internals/#dns in the address bar. If the browser's cache does not have a hit, it then checks the domain-name-to-IP mapping in the operating system's hosts file. If there is no hit in the hosts file, it then requests resolution from the local domain name server, which is generally provided by the internet service provider (ISP) and typically sends UDP datagram requests to the server for DNS resolution through port 53. If the local server resolution does not yield a hit, there are two resolution methods: iterative resolution and recursive resolution. Generally, the host's query to the local domain name server is a recursive query, and the local domain name server's query to the root domain name server is typically an iterative query, querying from the root domain name server, top-level domain name server, primary domain name server, etc., level by level, until it finds the IP address.

TCP three-way handshake

The HTTP protocol uses the TCP protocol as its transport layer protocol. After obtaining the server's IP address, the client browser establishes a TCP connection with the server, a process that involves a three-way handshake.

client server actively open → SYN=1,seq=x → passively open, receive (synchronize sent) (synchronize received) receive ← SYN=1,ACK=1,seq=y,ack=x+1 ← send (connection established) (synchronize received) send → ACK=1,seq=x+1,ack=y+1 → receive (connection established) (connection established)
  1. First handshake: The client actively connects to the server, sends the initial sequence number seq=x and the SYN=1 synchronization request flag, and enters the SYN_SENT state, waiting for confirmation from the server.
  2. Second handshake: After receiving the message, the server sends the acknowledgment flag ACK=1 and the synchronization request flag SYN=1, sends its own sequence number seq=y and the client's acknowledgment number ack=x+1, at this point the server enters the SYN_RECV state.
  3. Third handshake: After receiving the message, the client sends the acknowledgment flag ACK=1, sends its own sequence number seq=x+1 and the server's acknowledgment number ack=y+1, and after sending, the connection is confirmed to be in the ESTABLISHED state, and the server enters the ESTABLISHED state upon receiving the confirmation information.

SSL Encryption Transmission

The establishment of SSL is for the encrypted transmission of HTTPS. HTTPS adds the SSL layer on the basis of HTTP, and the security foundation of HTTPS is SSL, so the details of the encryption require SSL.

  1. First, the TCP three-way handshake establishes the connection, which is the foundation of data transmission, and then SSL starts.
  2. The client first sends Client Hello to start the SSL communication. The message contains the SSL version supported by the client, a random value Random1, encryption algorithm, and key length.
  3. The server sends Server Hello, which, like the client, includes the SSL version, random value Random2, and encryption components. The server then sends the certificate to the client.
  4. At this point, the client needs to verify the certificate sent by the server. By using the built-in CA certificate of the operating system, the client decrypts the digital signature of the server's certificate and compares the public key of the certificate with the same algorithm's HASH and the decrypted content of the digital signature, verifying whether the certificate is valid and legitimate or whether it has been hijacked and replaced.
  5. The client verifies the certificate as valid, then generates a random value Random3, encrypts it with the public key, generates the Pre-Master Key, and sends the Pre-Master Key to the server in a Client Key Exchange message. Then it sends a Change Cipher Spec message to indicate that subsequent data transmission will be encrypted.
  6. The server decrypts the Pre-Master Key with its private key to get Random3, and then sends a Change Cipher Spec message to indicate that subsequent data transmission will be encrypted.
  7. At this point, both the client and the server have three random strings, and Random3 is transmitted in ciphertext, which is in a secure state, and these three strings can then be used for symmetrically encrypted transmission. Asymmetric encryption is slow and cannot be used for every data transmission, so it is used to negotiate the key and then use symmetric encryption for data transmission.
  8. At this point, normal HTTP data transmission can occur, but due to the effect of SSL encryption, the HTTP transmission at this point is secure. This is the process of HTTPS transmission, where steps 2, 3, 5, and 6 are also known as the SSL four-way handshake.

Initiating Requests

The browser constructs an HTTP request message and transmits it to the server's specified port via the TCP protocol. An HTTP request message consists of three parts: the message header, usually containing the request line and various request header fields; a blank line (telling the server that the request header ends here); and the message body, which contains the transmitted data and is not necessarily required.

<!-- Message header --> GET / HTTP/1.1 <!-- Request line --> accept: text/html accept-encoding: gzip, deflate, br accept-language: zh-CN, zh;q=0.9 ... <!-- Request header --> <!-- Blank line --> <!-- Message body --> u=1&t=1587699008

Response Message

The server responds to the HTTP request by returning a response message, which consists of four parts: the response line, response header, blank line, and response body.

HTTP/1.1 200 OK <!-- Response line --> content-encoding: gzip content-type: text/html; charset=utf-8 date: Fri, 24 Apr 2020 03:34:50 GMT ... <!-- Response header --> <!-- Blank line --> <!-- Response body --> {"status":1, "msg": "success"}

Rendering a Web Page

  1. From top to bottom, the HTML tags are first parsed to generate the DOM Tree.
  2. When parsing encounters a <link> or <style> tag, the CSS is parsed to generate the CSSOM. It's worth noting that at this point, parsing of HTML tags and CSS is executed in parallel.
  3. When a <script> tag is encountered, the browser immediately begins script parsing, halting the document parsing. This is because scripts may modify the DOM and CSS, and continuing parsing would waste resources. Therefore, <script> tags should be placed after the <body></body>.
  4. Once the DOM Tree and CSSOM are generated, they are merged to perform layout, calculating their size, position, and layout information to form an internal representation model that can represent all this information, known as the render tree.
  5. The entire page is drawn based on the calculated information. The system traverses the render tree and invokes the paint method to display the content on the screen.

Terminating a TCP Connection

client server Active close → FIN=1,seq=u → Passive close, receive (LAST-ACK) (CLOSE-WAIT) Receive ← ACK=1,seq=v,ack=u+1 ← Send (TIME-WAIT) (CLOSED) Receive ← FIN=1,ACK=1,seq=w,ack=u+1 ← Send (CLOSED) (CLOSED) Send → ACK=1,seq=u+1,ack=w+1 → Receive (CLOSED) (CLOSED)
  1. First handshake: The client sends a release indication FIN=1, its own sequence number seq=u, and enters the terminated waiting FIN-WAIT-1 state.
  2. Second handshake: After receiving the message, the server sends ACK=1 acknowledgment flag and the client's acknowledgment number ack=u+1, its own sequence number seq=v, and enters the closed waiting CLOSE-WAIT state. The client enters the terminated waiting FIN-WAIT-2 state upon receiving the message.
  3. Third handshake: The server sends the release indication FIN=1 signal, acknowledgment flag ACK=1, acknowledgment number ack=u+1, its own sequence number seq=w, and transitions to the last acknowledgment LAST-ACK state.
  4. Fourth handshake: Upon receiving the reply, the client sends the acknowledgment flag ACK=1, acknowledgment number ack=w+1, its own sequence number seq=u+1, and enters the time waiting TIME-WAIT state. After 2 maximum segment lifetimes, the client CLOSEs. Upon receiving the acknowledgment, the server immediately enters the CLOSE state.

Related

TCP Three-Way Handshake and Four-Wave Goodbye https://github.com/WindrunnerMax/EveryDay/blob/master/Browser/TCP%E4%B8%89%E6%AC%A1%E6%8F%A1%E6%89%8B.md Overview of HTTP Protocol https://github.com/WindrunnerMax/EveryDay/blob/master/Browser/HTTP%E5%8D%8F%E8%AE%AE%E6%A6%82%E8%BF%B0.md Process of HTTPS Encrypted Transmission https://github.com/WindrunnerMax/EveryDay/blob/master/Browser/HTTPS%E5%8A%A0%E5%AF%86%E4%BC%A0%E8%BE%93%E8%BF%87%E7%A8%8B.md Browser Rendering and Kernel https://github.com/WindrunnerMax/EveryDay/blob/master/Browser/%E6%B5%8F%E8%A7%88%E5%99%A8%E6%B8%B2%E6%9F%93%E4%B8%8E%E5%86%85%E6%A0%B8.md Symmetric Encryption and Asymmetric Encryption https://github.com/WindrunnerMax/EveryDay/blob/master/Browser/%E5%AF%B9%E7%A7%B0%E5%8A%A0%E5%AF%86%E4%B8%8E%E9%9D%9E%E5%AF%B9%E7%A7%B0%E5%8A%A0%E5%AF%86.md

Daily Topic

https://github.com/WindrunnerMax/EveryDay

References

https://www.jianshu.com/p/d616d887953a https://www.cnblogs.com/lhh520/p/10232738.html https://blog.csdn.net/bjweimengshu/article/details/78978314 https://blog.csdn.net/wlk2064819994/article/details/79756669 https://blog.csdn.net/weixin_40659167/article/details/86510745
ON THIS PAGE