The browser

Page rendering process

  1. Byte stream decoding. The browser takes the byte data, decodes the byte stream according to the byte encoding, and converts it into code.
  2. Input stream preprocessing. Unified formatting of character data.
  3. The token. Extract recognizable substrings and markers from the input stream. Can be understood as HTML parsing, lexical analysis, matching tags to generate token structure.
  4. Build the DOM tree, build the CSSOM tree. DOM tree and CSSOM tree are built simultaneously. If aScript tag is encountered during HTML parsing, parsing will be paused and execution permission will be given to the JavaScript engine. After the JavaScript script is executed, the rendering engine will continue parsing. (Note: If a script calls document.write() that changes the DOM structure, the rendering engine goes back to step 2, adds the code to the character stream, and parses it again.)
  5. Build the render tree. The DOM tree is responsible for the structural content, and the CSSOM tree is responsible for the style rules, which need to be combined into the render tree for rendering.
  6. Layout. The layout phase calculates the size and position of elements according to the nodes in the rendering tree and their CSS definitions and node affiliations, and converts all relative values into absolute pixels on the screen.
  7. To draw. Drawing is the process of converting each node in the rendered tree into an actual pixel on the screen. In the paint phase, the browser traverses the render tree, calling the renderer’s paint method to display its contents on the screen. In fact, the drawing process is done on multiple layers, called renderlayers.
  8. Render layer composition. Multiple rendered layers are merged in the appropriate overlapping order to generate a bitmap that is eventually displayed on the screen via a graphics card.

Data change process: byte → character → token → tree → page

Backflow, redraw

Reflow

After the layout is complete, making changes to the DOM layout (such as size or position) causes the page to recalculate the layout, a process known as “backflow.”

Repaint

Partial rendering of the screen (such as background colors, font colors) caused by changes to the DOM that do not affect the layout is called “repainting.”

summary

Backflow always causes redrawing, and redrawing does not necessarily cause backflow. Since backflow requires recalculation of node layouts, backflow can be more time-consuming to render than redraw.

For backflow redraw, the browser has its own optimization policy. The browser will maintain a queue, put the backflow redraw operations in the queue, wait for a certain amount of time, and then execute the queue operations in sequence.

There are exceptions, however, when we need to get some style information, for example: The offsetTop and offsetLeft, offsetWidth, offsetHeight, scrollTop/Left/Width/Height, clientTop/Left/Width/Height, GetComputedStyle (), or currentStyle of IE.

In this case, the browser needs to redraw the queue immediately in order to provide accurate feedback, which can cause the queue to execute prematurely.

Event Loop

In browser implementations, such as rendering tasks, JavaScript script execution, User Interaction, and network processing all run on the same thread, and executing one type of task means blocking other tasks. The browser implements what we call an Event Loop scheduling process in order to prioritize each task.

Simply put, an Event Loop is a process of executing code, collecting and processing events, and executing queue subtasks.

Macro task

When a macro task is encountered during a new event loop, it is added to the task queue, but not executed until the next event loop.

Common macro tasks: setTimeout, setInterval, requestAnimationFrame

Micro tasks

When the task queue of the current event loop is empty, the tasks in the microtask queue are executed in sequence. During execution, if a microtask is encountered, the microtask is added to the queue of microtasks in the current event loop. In simple terms, microtasks continue as long as they exist, rather than wait until the next event loop.

The microtask queue belongs to a member of the task running environment and is not in a global position. That is, each task has a queue of microtasks.

Common microtasks: promise.then, Promise.catch, MutationObserver

process

  1. Take out a macro task to execute, put it in the task queue if it encounters a macro task, and put it in the microtask queue if it encounters a microtask
  2. Check whether the microtask queue has available microtasks and execute them if so. If a macro task is encountered during the execution of a micro task, it is put into the task queue. If a microtask is encountered, continue to place it in the current microtask queue until all the microtasks are executed.
  3. Update the render stage to determine if it needs to be rendered, i.e. not necessarily every turnEvent LoopAll correspond to a browser render.
  4. For documents that need to be rendered, executerequestAnimationFrameFrame animation callback.
  5. For documents that need to be rendered, rerender the user interface.
  6. Check whether the task queue and microtask queue are empty. If so, performIdleAn idle cycle algorithm that determines whether to executerequestIdleCallbackThe callback function of.

summary

In the current task running environment, micro task is always executed before macro task.

The requestAnimationFrame callback is called before the page renders and is suitable for animation;

RequestIdleCallback is called after rendering the screen and can be used to perform less important tasks.

Same Origin Policy

A source is the part of the URL that consists of the protocol, host name (domain name), and port.

The same origin policy is the behavior of the browser. In order to protect local data from being contaminated by data retrieved from JavaScript code, it is the most core and basic security function existing in the browser.

Same-origin means that the protocol, domain name, and port number must be the same. If one of them is different, it is cross-source.

The most common same-origin policy is because the domain name is different, often referred to as “cross domain.” Generally divided into request across domain and page across domain.

Request a cross-domain solution

  1. Cross-domain resource sharing (CORS). Access-control-allow-origin HTTP response header
  2. Proxy forwarding. The same origin policy exists only in the browser. There is no restriction on the same origin policy when configuring proxy forwarding on the server.
  3. The json. The dependency on script tags to reference JS files across domains is not restricted by the browser’s same origin policy.
  4. Websocket. HTML5 specification proposed an application layer full duplex protocol, suitable for real-time communication between browser and server scenarios.

Common methods are CORS and proxy forwarding.

Page cross domain solution

  1. PostMessage. HTML5’s postMessage method can be used to communicate between two pages, regardless of whether they are homologous or not.
  2. The document domain. If the main domain name is the same and the subdomain name is different, you can change the value of document.domain to cross the domain.
  3. Window.location. hash, hash via URL, passes data through a non-cross-domain intermediate page.
  4. Window. name, when a window’s location changes and then is reloaded, its name property can remain the same. The SRC attribute of iframe is used to transfer the cross-domain data from the outfield to the local region. In this case, the window. name of iframe is used to transfer the cross-domain data from the outfield to the local region.

CORS requests

For CORS requests, browsers divide them into two types: simple and non-simple.

A simple request

A simple request meets the following two characteristics:

  1. The request methods are GET, POST, and HEAD.

  2. Request headers can only use the following specified security fields:

    • Accept (the type of response that the browser can Accept)
    • Accept-language (list of natural languages accepted by the browser)
    • Content-type (only text/plain, multipart/form-data, application/ X-www-form-urlenCode)
    • Content-language (the natural Language that browsers want to adopt)
    • Save-Data
    • DPR
    • DownLink
    • Viewport-Width
    • Width

Non-simple request

A request that does not meet any of the requirements is a non-simple request. Custom headers are common, such as setting the token to the request header.

When processing a non-simple request, the browser sends a pre-check request. The pre-check request uses the OPTIONS method to determine whether the server allows the actual request, avoiding unexpected impact of the cross-domain request on the server. If the precheck request returns 200 and is allowed to pass, the real request is sent.

Precheck requests do not need to be sent every time. You can optimize the cache time by using access-Control-max-age to reduce request sending.

HTTP

Differences between HTTP 1.0, HTTP 1.1, and HTTP 2.0

HTTP1.0

Added header Settings, header content in the form of key-value pairs. The request header uses the Accept field to tell the server what Type of file to Accept, and the response header uses the Content-Type field to tell the browser what Type of file to return.

HTTP1.1

Each communication in HTTP1.0 goes through three phases: establishing a connection, transferring data, and disconnecting, which adds a lot of network overhead.

HTTP1.1 adds persistent connections, where TCP connections are not closed immediately after transmission, but can be reused by other requests. This connection remains until the browser or server asks to disconnect.

HTTP2.0

HTTP1.1 reduces the performance cost of connections, but the maximum number of concurrent requests is limited. The number of HTTP connections in the same domain varies by browser, and generally ranges from 6 to 8. A TCP connection can process only one request at a time. Other requests are blocked until the current request is completed.

HTTP2.0 adds a “multiplexing” mechanism that is no longer limited by the browser’s connection count. Based on binary framing, the data sent by the client is divided into numbered fragments (binary frames), which are then sent to the server at the same time. The server receives the data and merges it into complete data based on the number. The same process is followed when the server returns data.

Three-way handshake

process

First handshake: The client sends a connection request packet with a SYN identifier to the server.

Second handshake: After receiving a packet from the client, the server detects that the packet contains a connection identifier. The server sends a reply packet (with the SYN identifier) to the client to confirm the connection.

Third handshake: The client sends a reply packet to the server to confirm the connection. After receiving the reply packet, the server formally establishes a TCP connection.

Why three handshakes? Is two okay?

In the case of a two-time handshake, the confirmation packet is lost during the second handshake, and the client does not know whether the server is ready. In this case, the client does not send data to the server and ignores the data sent by the server.

In the three-way handshake, if the confirmation packet is lost during the third handshake, the server re-shakes the handshake if it does not receive any reply packet from the client for a period of time. After receiving the repeated packet, the client sends the confirmation packet to the server again.

The three-way handshake is mainly concerned with the problem of packet loss and reconnection.

Four times to wave

process

First wave: The client sends a connection release packet with a connection release identifier (FIN) to the server. In this case, the client cannot send data, but can receive data normally.

Second wave: The server receives a packet from the client and knows that it is a connection release request. The server sends an acknowledgement packet to the client. Note that the reply packet does not contain the FIN identifier. At this point, the server is in the closed waiting state, and this state will last for a period of time, because the server may still have data to send.

Third wave: After sending the final data, the server sends a reply packet (with the FIN identifier) to the client to notify the client that the connection can be released.

Fourth wave: After receiving the acknowledgement packet from the server, the client sends the acknowledgement packet to the server. The server releases the TCP connection as soon as it receives the confirmation packet from the client. Therefore, the server terminates the TCP connection earlier than the client.

Why do you need three handshakes and four waves

To ensure data integrity, the server can only reply to the client with an acknowledgement message to tell the client that it has received the packet and enters the closed waiting state. After the data is sent, the server replies with a FIN packet to inform the client that the data is sent and the client can be disconnected. In this way, another wave process is performed.

HTTPS

HTTPS is more secure than HTTP because it encrypts the transmitted content. HTTPS encryption uses both symmetric and asymmetric encryption.

Symmetric encryption: Both parties share a key and can encrypt and decrypt content in both directions. However, as long as someone communicates with the server, they can obtain the key and decrypt other communication data. Therefore, it is less secure than asymmetric encryption, but it is more efficient than asymmetric encryption.

Asymmetric encryption: Asymmetric encryption generates public and private keys. Generally, the server holds the private key and the public key is disclosed to the public. Asymmetric encryption encrypts and decrypts content in one direction. That is, public key encryption can only be solved by private key encryption, and private key encryption can only be solved by public key encryption. Asymmetric encryption has high security but low encryption and decryption efficiency.

CA certificate: issued by an authority to verify the validity of the server. The CA certificate contains information about the authority, public key, company, and domain name.

Symmetric encryption is not secure mainly because the key is easy to leak, so as long as the key is secure, we can get the best of both sides of the scheme, high encryption and decryption efficiency and good security. Therefore, HTTPS uses symmetric encryption for content and asymmetric encryption for keys during transmission.

process

  1. The client sends an HTTPS request to the server
  2. The server returns the HTTPS certificate
  3. The client verifies whether the certificate is valid. If the certificate is invalid, an alarm is generated
  4. After the certificate is valid, a random number is generated locally
  5. Encrypt random numbers with public keys and send them to the server
  6. The server uses the private key to decrypt random numbers
  7. The server uses random numbers to construct symmetric encryption algorithms to encrypt content and transmit it
  8. After receiving the encrypted content, the client uses the locally stored random number to construct a symmetric encryption algorithm for decryption

HTTP cache

HTTP cache includes strong cache and negotiation cache, and the priority of the strong cache is higher than that of negotiation cache. The advantage of caching is that the server does not need to send some resources repeatedly by using the browser cache, which reduces the pressure on the server and improves the user experience.

Strong cache

When the browser loads a resource, it searches for the result from the cache. If the result does not exist, it sends a request to the server.

Expirss

In HTTP/1.0, you can use the response header field Expires to set the cache time.

When the client requests for the first time, the server will add a Expirss field in the response header. When the browser sends a request next time, it will compare the Expirss time with the Expirss time. If the expiration date is not used, the cache will be sent.

Cache-Control

HTTP/1.1 introduced cache-control response header fields.

The value of max-age is generally set to indicate how long the resource needs to be cached. Cache-control has a max-age priority over Expires.

Negotiate the cache

The update policy of the negotiated cache does not specify the valid time of the cache. Instead, the browser directly sends a request to the server to confirm whether the cache is updated. If the HTTP status returned by the response is 304, the cache is still valid.

The last-modified and If – Modified – Since

Last-modified and if-modified-since compare the Last modification time of the resource to implement caching.

  1. When a browser requests a resource for the first time, the server adds a last-Modified field to the response returned by the browser. The value is the Last modification time of the resource on the server.
  2. The browser requests the resource again and adds if-modified-since to the request header, which is the last modification time returned by the server.
  3. The server receives the request based on the value of if-modified-since. If the resource has not been modified, the 304 status code is returned and no content is returned. The browser uses cache. Otherwise return the contents of the resource and update last-Modified;
The ETag and If – None – Match

ETag and if-none-match compare the resource hash value. The hash value is calculated from the resource content, that is, the cache depends on the resource content.

  1. When the browser requests a resource for the first time, the server adds an ETag field to the response that returns the resource. The value is the hash value of the resource
  2. The browser requests the resource again and adds if-none-match to the request header. The value is the resource hash returned by the server last time.
  3. The server checks the request based on the if-none-match value. If the resource content does not change, the 304 status code is returned and no content is returned. The browser uses cache. Otherwise return the contents of the resource and compute the hash value into the ETag;

Differences between TCP and UDP

TCP

  • connection-oriented
  • One-to-one communication
  • Word oriented stream
  • Reliable transmission, using flow control and congestion control
  • The minimum header is 20 bytes and the maximum is 60 bytes

UDP

  • There is no connection
  • Supports one-to-one, one-to-many, many-to-one and many-to-many communication
  • For a message
  • Unreliable transmission, not using flow control and congestion control
  • The header overhead is small, only 8 bytes

Forward agent

  • Acting customers;
  • Hide the real client, send and receive requests for the client, so that the real client is invisible to the server;
  • All users on a LAN may be forward propped by a server that handles HTTP requests.
  • The forward proxy server communicates with the server.

The reverse proxy

  • Proxy server;
  • Hide the real server, send and receive requests for the server, so that the real server is invisible to the client;
  • Load balancing servers that distribute user requests to idle servers;
  • This means that the user communicates with the load balancing server directly, that is, the user obtains the IP address of the load balancing server when resolving the server domain name.

The front security

Cross-site scripting (XSS)

Cross Site Scripting (XSS) refers to the ability of an attacker to insert malicious code into a page. When other users visit the page, the browser will parse and execute the code, resulting in identity theft, phishing, and spreading malicious code. Generally, XSS can be divided into reflection type, storage type and DOM type.

Reflective XSS

Reflective XSS, also known as “non-persistent XSS”, means that an attacker submits malicious code to a server through a request, and the server returns the content with the XSS code, causing the browser to execute the malicious code.

Reflective XSS attack requires to induce the user to click on the link, and the attacker will disguise the link (such as a short link). When the user clicks on the attacker’s link, the attacker can obtain the user’s cookie identity information.

Case study:

The server directly outputs the parameter content:

<? php
$input = $_GET["param"];
echo "<div>".$input."</div>";
Copy the code

Malicious code links:

http://www.a.com/test.php?param=<srcipt src="xss.js"></script>
Copy the code

Type stored XSS

Storage XSS, also known as “persistent XSS”, stores user input data on the server and has strong stability.

Case study:

For example, when an attacker leaves a message under a blog post, the message contains malicious code, which is submitted to the server and stored in a database. All visitors to the blog will execute the malicious code in their browsers when they load the message.

The DOM model XSS

DOM XSS is a special type of reflective XSS, which is also non-persistent. In contrast to reflective XSS, it does not need to go through the server, but instead changes the page DOM to achieve the attack. Again, this type of attack requires the user to click.

Case study:

Target page:

<html>
    <body>hello</body>
</html>
<script>
  let search = new URLSearchParams(location.search)
  document.write("hello, " + search.get('name') + '! ')
</script>
Copy the code

Malicious code links:

http://www.a.com/test.index?name=<srcipt src="xss.js"></script>
Copy the code

defense

  1. Parameter verification, do not meet the requirements of the data stored in the database
  2. Escape special characters, such as “<“, “>”, “/”, and “&”
  3. Avoid the use ofeval,new FunctionA method for dynamically executing a string
  4. Avoid the use ofinnerHTML,document.writeOutput the string directly to HTML
  5. Put some sensitivecookieSet tohttp onlyTo avoid front-end accesscookie

Cross-site Request Forgery (CSRF)

A CSRF attack is a fake request sent to the target site in the victim’s name without the victim’s knowledge to perform operations protected by permissions without authorization. CSRF does not need to directly obtain user information, but only needs to “borrow” user login information related operations, which is more hidden.

Case study:

Suppose you have a blog site and know that the URL to delete the blog post is:

http://blog.com?m=delete&id=123
Copy the code

The attacker constructs a page with the following contents:

<img src="http://blog.com?m=delete&id=123"></img>
Copy the code

The attacker disguises the site’s links and induces users to click on them, who happen to have visited Blog.com and whose cookie authentication information has not expired. Then enter the attacker’s website, IMG launched a request, the request with cookies, successfully delete the blog. However, there is no perception for the user. When the user returns to the blog, he will find that the blog post is missing, and this request is a legitimate request, because the attacker uses the identity information of the victim to operate.

defense

  1. Set the SameSite for cookies
  2. The server validates the Refer field, which is the source address of the request, and rejects the request for an invalid Refer
  3. addtoken, so that links become unpredictable, attackers can not construct a complete URL to implement CSRF attacks
  4. Adding a verification code forces users to interact with applications, but reduces user experience and can only be used as an auxiliary method

ClickJacking

The attacker creates a webpage to contain the target website by using iframe, and then hides the target website by setting transparency, so that the user cannot detect the existence of the target website and masks it on the webpage. Inducing the user to click on a specific button in a web page, and the location of the button and the target site of a button, when the user clicks on a button on the web page, is actually clicking on the target site of the button.

defense

  1. Frame busting, usually a piece of JavaScript can be written to disable the nesting of iframes.
if(top.location ! = location) { top.location = self.location }Copy the code
  1. Add HTTP header X-frame-options

The resources

  • White Hat on Web Security
  • HTML specification – Parses HTML documents
  • Browser layer composition and page rendering optimization
  • 10 Cross-domain Solutions (with The Ultimate Trick)
  • MDN – HTTP Access Control (CORS)
  • HTML specification – Event loops
  • MDN – In Depth: Microtasks and Javascript runtime environments
  • What you don’t know about EventLoop and browser rendering, frame animation, idle callbacks
  • Tasks, microtasks, queues and schedules
  • Oh, my gosh! Cow skin, the first time to see a big guy TCP three times shake hands four times waved to explain so clear
  • You don’t even know how HTTPS works, and you still talk about man-in-the-middle attacks?
  • Advanced · The basics of the web that you have to understand

Recommended reading

  • Gold nine Silver ten, preliminary intermediate front-end interview review summary “JavaScript chapter”
  • Gold nine silver ten, preliminary intermediate front-end interview review summary “Vue chapter”