How JavaScript works (JavaScript works) (12) Network layer Quest and how to improve its performance and security

Personal Summary: Reading this article takes 20 minutes, this article mainly explains the modern browser in the network layer transfer of some of the techniques used.

This is the 12th chapter of how JavaScript works.

As mentioned in the previous article on the rendering engine, we believe that the difference between a good and a great JavaScript developer is that the latter not only understands the specifics of the language but also understands its internal structure and operating environment.

Network history

49 years ago, ARPAnet was born. It is an early packet switching network and the first network to implement a TCP/IP protocol suite. The network is connected to the California lobby and the Stanford Institute. 20 years later, Tim Berners-lee distributed a "Mesh" draft of a later-known world Wide Web. In the 49, the network went through a long journey, from just two computers exchanging data messages to at least 75 million servers, 3.8 billion people using the Internet and 1.3 billion websites.

This article will try to analyze what technologies modern browsers use to automatically improve application performance (some you don't even understand), and then focus on the browser network layer. Finally, there are some tips for browsers to improve the performance of Web applications.

Overview

Modern browsers are specifically designed for fast, efficient and secure data transmission for Web applications/websites. With hundreds of components running at various levels, from process management and security sandbox to GPU pipelines, audio and video and more, web browsers are more like an operating system than just one software.

The overall performance of the browser is determined by a number of large components, including: parsing, layout, style calculations, JavaScript and WebAssembly execution, rendering, and of course, the network stack.

In general, engineers think of the network stack as a performance bottleneck. This is often the case because crawling all the resources from the network will clog up the remaining steps. For a more efficient network layer, it needs more than just playing the role of a socket manager. It seems to us that getting a resource is a very simple mechanism, but it actually integrates its own set of optimization criteria, interfaces and services.

Web developers do not need to worry about individual TCP or UDP packets, requests for formatting, caching, and everything else that is happening. The browser handles these complex things so that you can focus on developing your own programs. However, knowing its internal principles can help developers develop more efficient and secure programs.

In essence, when the user starts interacting with the browser, the situation arises as follows:

• The user enters the URL address in the browser address bar.
• Looking for resources on the network for the specified URL, the browser starts checking the local and application caches and tries to use local copies to respond to requests for resources.
• When the cache is unavailable, the browser uses the domain name in the URL and then obtains the server's IP address from DNS based on the domain name. If you have a domain name cache, you will not need to make DNS queries.
• The browser creates an HTTP message indicating that it is requesting a Web page from the remote server.
• The message is transmitted to the TCP layer, which adds its own information to the header of the HTTP message. This information is the necessary information to keep the session created.
• The packet is then processed at the IP layer, where the primary responsibility is to find the path from the user sending the message to the remote server. Adds the path information to the header of the HTTP message.
• Transmit the message to the remote server.
• Once a message is received, the response data is returned in a similar manner.

The Navigation Timing specification provides a browser interface and visual timings and performance data behind each request in the browser. Let's explore these components, because each component plays an important role in getting the best user experience.

The entire network request process is quite complex and has many hierarchies, each of which can be a performance bottleneck. This is why browsers use a variety of technologies to improve their performance to minimize the performance loss of the entire network traffic.

Socket Management

Look at some new technologies:

• Source-consists of three parts of the application protocol, domain name and port number (e.g. HTTPS, www.example.com, 443)
• Socket pool-A set of sockets that belong to the same origin (all major browsers limit the socket pool to 6 sockets only)

JavaScript and WebAssembly prohibit developers from manipulating the life cycle of individual network sockets, which is quite sensible. This will not only give your hair a little bit less and allow the browser to automatically optimize a lot of performance, including socket reuse, request optimization and delay binding, protocol negotiation, forcing connection restrictions and other optimizations.

In fact, modern browsers have stripped the request management cycle from socket management a step further. Use sockets pools to organize sockets, to group sockets in source, and each socket pool to enforce limits on its number of connections and security constraints. Queues up, prioritizes waiting requests, and then binds to a single socket in the socket pool. If the server is not actively shutting down these connections, multiple requests can automatically reuse the same socket.

Because creating a new TCP connection brings additional performance overhead, reusing a connection can bring a significant performance boost. By default, when a request is initiated, the browser uses the so-called "keepalive" mechanism to save the time it takes to create a new connection to the server. The average time to create a new TCP connection is:

• Local request-23 MS
• Transcontinental request-120 ms
• Intercontinental Request-225 ms

Some other optimization methods are derived from this architecture. Requests can be executed in a different order based on the priority level. The browser can optimize bandwidth allocations between all sockets or it can create sockets to wait for the expected request.

As mentioned above, these are controlled by the browser without the intervention of the developer. But that doesn't mean we're doing nothing. Choosing the right network communication mode, type and frequency, the correct protocol type, and proper server stack tunneling/optimization are essential to improve the performance of the entire program.

Some browsers even went further. For example, when you use Chrome, it learns to be self-learning and become faster when used by users. It learns based on visited Web pages and typical browser patterns, so that possible user behavior can be expected and manipulated before the user makes any action. The simplest example is the pre-rendered page when the user hovers over a link. If you want to learn more about Chrome optimization technology, you can check out the https://www.igvita.com/posa/of High-performance Browser Networking book. high-performance-networking-in-google-chrome/Chapter.

Network Security and Sandbox

Allowing the browser to operate a separate socket has another very important purpose: the browser can enforce a consistent set of security and policy constraints on untrusted program resources. For example, the browser prohibits direct access to the original network sockets through the API, because this can cause any suspicious program to connect arbitrarily to any host. The browser also enforces a limit on the number of connections to protect the server from exhaustion of its resources due to client access.

The browser formats all outgoing requests to enforce a properly formatted and consistent protocol semantics to protect the server. Similarly, the browser automatically decodes the response content to protect users from suspicious servers.

TLS negotiation

Transport Layer Security (TLS) is an encryption protocol that provides communication security for computer networks. It is widely used in a large number of applications, one of which is browsing the web. The Web site can use TLS to secure all communications between the server and the Web browser.

The entire TLS handshake process consists of the following steps:

1. The client sends a "client Hello" message to the server, which is accompanied by a client-side random value and a supported cipher combination.
2. The server returns to the client "server Hello" information, with the server random values attached.
3. The server returns the authentication certificate to the client and may require the client to return a similar certificate. The server returns "server Hello done" information.
4. If the server requires the client to send a certificate, the client sends it.
5. The client creates a random pre-master key and then encrypts it with the public key in the server certificate, sending the encrypted Pre-master key to the server.
6. The server receives the Pre-master key. The server and client each generate a master key and session key based on the Pre-master key.
7. The client sends a "change cipher spec" notification to the server, indicating that the client will start using the new session key to hash and encrypt the message. The client also sends a "client finished" message.
8. The server receives a "Change cipher spec" notification and then uses the session key to switch its record layer security state to a symmetric encryption state. The server returns a "server finished" message to the client.
9. The client and server can now exchange program data through established secure channels. The information sent between all clients and servers is encrypted using the session key.

The user receives a warning whenever any validation failure occurs. For example, the server uses a self-signed certificate.

Homologous policy

When the two-page protocol, the port (if specified), and the hostname are the same, it is called homology.

Here are some examples of resources that might include cross-domain:

• <script src=”…”></script>The JavaScript code inside. The error message for syntax errors applies only to homologous scripts.
• <link rel=”stylesheet” href=”…”>The CSS. Because of the loosely grammatical rules of CSS, cross-domain CSS requires the correct Content-type header. The restrictions differ for each browser.
• Image
• <video>and <audio> media files
• <object>, <embed> and <applet> plug-ins
• @font-face Font. Some browsers allow cross-domain fonts, others require homologous fonts.
• And all the content related to <iframe>. Web sites can use the X-frame-options header to prevent this cross-domain interaction.

The list above is not enough; The list is designed to emphasize the "least privilege" principle in work. The browser exposes only the necessary interfaces and resources for application code: The app provides data and URL addresses, and the browser formats requests and processes the entire lifecycle of each connection.

It is important to note that there is no simple "same-origin strategy" concept.

Instead, there is a series of related mechanisms to enforce restrictions on browser DOM access, cookie and session state management, network connectivity, and other components.

Resource and client state caching

The best and fastest request is to not create the request. Before dispatching a request, the browser automatically checks its resource cache, makes the necessary validation checks, and then returns a copy of the local resource when the specified condition is matched. If no local resources are available in the cache, the network request is initiated and the response is automatically placed in the cache for subsequent access (if this is allowed).

• The browser automatically evaluates the cache instruction for each resource.
• The browser automatically recovers expired resources when conditions permit
• Browser automatically handles cache and resource collection size

Managing an efficient and optimized resource cache is very difficult. Thankfully, the browser has handled the whole complex thing for us, and all we need to do is to ensure that the server returns the appropriate cache instructions; You can see the client resource cache article for more information. You add Cache-control,etag, and last-modified response header information to all the resources on the page.

Finally, a frequently overlooked but critical browser feature is its ability to provide authentication, session and cookie management. The browser maintains a separate "cookie jars" for each source by providing the necessary program and server interfaces to read and write new cookies, session and authentication data, and to automatically mount and process the appropriate HTTP headers to automatically process the entire process for us.

Example:

A simple but straightforward example of the convenience of displaying a browser's deferred session state management: Multiple tabs or browser windows can share a single authentication session, and vice versa; a logout operation in one tab invalidates all other open windows sessions.

Application interfaces and protocols

Once you understand the network service, you end up talking about application interfaces and protocols. It is well known that the lower-level structure provides a broad set of important services: socket and connection management, request and response processing, various security policies, caching and many more enforcement measures. Whenever you initialize an HTTP request or XMLHttpRequest, a persistent service push event or WebSocket session or open a WebRTC connection, we are interacting with some or all of these underlying services.

There is no single best protocol or interface. Each complex program mixes different transport protocols based on different requirements: interaction with browser caches, protocol overhead, message latency, reliability, data transmission types, and more. Some protocols have characteristics of low data transfer latency (such as server push events, WebSocket), but may not meet other important occasions, such as the ability to use a browser cache or support binary data transfer in any case.

Extended

Cross-domain issues about font files can be viewed here and here.

How JavaScript works (JavaScript works) (12) Network layer Quest and how to improve its performance and security