This chapter is about the network layer, which is basically a black box for front-end developers and can be used as a learning tool. It’s also great for interviews.

A little bit of history

More than 50 years ago, the ARPA network was created. It was an early packet switching network and was the first to implement TCP/IP. The network is connected to the University of California and Stanford University. Twenty years later, Tim Berners-Lee came up with a draft of what became known as the World Wide Web. In more than 50 years, the Internet has come a long way, from two computers exchanging data to more than 75 million servers, 3.8 billion people using the Internet and 1.3 billion websites.

In this section, we’ll look at what technologies modern browsers use to optimize, especially at the network layer. Finally, as usual, I put forward some optimization suggestions

An overview of the

Modern browsers are designed for fast, efficient, and data secure web sites. Hundreds of components run in different tiers, such as process management, GPU pipeline sandbox, audio and video, and so on. Modern browsers now look more like operating systems than applications

The factors that affect the overall performance of the browser are several large components: transformation, layout, style calculation, code execution (JS or WebAssembly), rendering, and the network stack. Developers generally think of the network stack as a performance bottleneck, which is normal because grabbing all the resources from the network will block the rest of the rendering step. For the network layer to be efficient, it needs to be more than just a socket management. It looks like a simple mechanism to capture resources, but it’s actually an integrated platform that optimizes its principles, apis, and services

As developers, we don’t have to worry about individual TCP or UDP packets, request formats, caching, and all the rest of it. The browser takes care of all the hard work, so developers can focus on their own business development. But understanding the underlying mechanisms can help you write faster and safer applications

When the user uses the post-browser, this is what happens:

  • The user entered the URL in the address bar
  • The browser checks the local cache against the URL and then attempts to respond to the request with a local copy.
  • If the cache is unavailable, the browser obtains the domain name from the URL and then obtains the IP address from the DNS service. If the domain name is already cached, do not query DNS.
  • The browser creates an HTTP packet indicating that it is in the remote service of the requested web page.
  • HTTP packets are sent to the TCP layer, which adds its own information to the top of the packet. This information is used to maintain the session.
  • This packet is processed by the IP layer, which specifies how the user sends the packet to the server. This information is also stored at the top of the package.
  • The packet is sent to the remote server
  • Once the server accepts the packet, it responds with similar behavior

The W3C provides a browser API and visual timing and performance data behind each request in the browser. Let’s take a look at these components, as each plays an important role in achieving the best user experience.

The entire network process is very complex, and each layer can be a performance bottleneck. Is this why browsers use various means to improve performance and minimize the impact of the network layer

Socket management

Let’s start with some terminology:

  • Source – Consists of the protocol, domain name, and port
  • Socket pool – a group of sockets under the same source (most browsers limit the pool to a maximum size of 5)

Both JS and WebAssembly do not allow developers to manage every socket lifecycle, which is a very good thing. This not only keeps our hands clean, but also allows the browser to perform many optimization actions, including socket multiplexing, request prioritization and delayed binding, protocol negotiation, enforced connection limits, and other optimization measures.

In fact, modern browsers go further and separate the request management cycle from socket management. Sockets can be organized in pools, which are grouped according to the source of the request, and each pool also enforces its own connection number and security requirements. Queued, prioritized waiting requests, and bound to a single socket in the socket pool. Multiple requests can automatically reuse the same socket if the server does not actively close these connections.

Opening a new TCP connection adds a lot of additional cost, so connection reuse has huge benefits. By default, browsers use the Keepalive mechanism to save the time to open a connection when a request is made. The average time to open a TCP connection is:

  • Local request –23ms
  • Intercontinental access —120ms
  • International request —225ms

This structure brings many opportunities for optimization. Depending on the weight of the request, they can be executed in a different order. Browsers can optimize bandwidth allocation based on all sockets, or open sockets and wait for requests.

The browser does all of this, we don’t have to do anything. However, there are some helpful things we can do with its origin. Choosing the right network connection paradigm, type and transmission frequency, the right protocol type, and the right server stack tunneling/optimization can greatly improve the performance of the entire application. Some browsers go further. Chrome, for example, can optimize itself for your use. With your browser access and browser patterns, it can guess the user’s behavior and then take action before the user executes it. The simplest example is to pre-render the page when the user’s mouse hover over a link.

Cyber security and sandbox

Allowing browsers to manage separate sockets serves a very important purpose: browsers can enforce a consistent set of security and policy constraints against untrusted application resources. For example, browsers do not allow direct access to the original socket, which can allow malicious applications to access arbitrary ports. The browser also enforces connection restrictions, which also protects the server from being depleted by heavy user traffic.

The browser formats all outgoing requests to enforce well-formed and consistent protocol semantics to protect the server. Likewise, the browser automatically decodes the response content to protect the user from a suspected server attack.

The TLS negotiations

Transport Layer Security (TLS) is an encryption protocol that provides a secure communication mechanism for computer networks. This protocol is already used extensively in many applications, including web browsers. The web site uses TLS to protect all communications between the server and the browser. The TLS handshake includes the following steps:

  1. The Client sends a ‘Client Hello’ to the server with the Client’s random value and supported password combination.
  2. The Server responds with a “Server Hello” with a random value on the Server side.
  3. The server sends its authentication certificate and may request that the client also send a similar certificate. Then the Server sends the “Server Hello done” message.
  4. If the server requests a certificate from the client, the client sends it.
  5. The client creates a random pre-master Secret, encrypts it with the public key in the server certificate, and sends the encrypted pre-master Secret to the server.
  6. The server accepts the pre-master Secret, and the server and client each generate a Master Secret and a session key based on the pre-master
  7. The client sends a “Change Cipher Spec” notification to the server, indicating that the client will use a new hash session key for encrypted communication. The Client sends a Client Finished message.
  8. The server accepts the “Change Cipher Spec” message and uses the session key to switch the security state of the recording layer to symmetric encryption. The Server sends the Server Finished message to the client.
  9. Clients and servers can now exchange application data through the secure channels they have established. All data is encrypted by the session key.

Users are alerted whenever any authentication failure occurs. For example, the server uses a self-signed certificate.

The same-origin policy

Two pages are homologous if they have the same protocol, port (if specified), and host name.

The following scenarios may cause cross-sourcing:

  • < script SRC = "..." ></script>Inside the JavaScript code. The error message for syntax errors applies only to same-origin scripts.
  • < link rel = "stylesheet" href = "..." >The CSS. Because of the loose syntax rules of CSS, cross-domain CSS requires the correct content-type header. Limitations vary from browser to browser.
  • <img>The image in
  •  <video> 和 <audio>Media files in
  •  <object>.<embed> 和 <applet>Built-in plug-in
  • Font in @font-face. Some browsers allow cross-source fonts, but others require homologous fonts
  • <frame> 和 <iframe>Everything in. You can use the X-frame-Options header to prevent this cross-domain interaction

This list is far from enough; it serves only to highlight the “minimum impact” principle at work. The browser simply exposes the apis and resources necessary for the application code: the application provides the data and urls, the browser formats the requests, and handles the full life cycle of each connection

Note that there is no separate concept of the same origin policy. Instead, there are a number of mechanisms that enforce DOM access, cookie and reply state management, and other components in the network and browser

Resource and client state caching

The fastest request is not sent. Before sending a request, the browser automatically takes a look at its resource cache, performs any necessary validation of how certain conditions are met, and returns a copy of the local cache. If a resource is not available in the cache, a network request is sent and the response content is automatically placed in the cache for later access (if this is allowed).

  • The browser automatically evaluates the cache instructions for each resource
  • When conditions permit, the browser automatically restores expired resources
  • The browser automatically manages the size of the cache and resource reclamation

Managing an efficient and optimized resource cache is difficult. Thankfully, the browser takes care of this for us, and all we need to do is make sure our server returns the appropriate cache instructions. For more information, see client Cache. You can add cache-Control, ETag, and last-Modified response headers to all pages

Finally, a common, but very important, browser feature is responsible for authentication, callback, and cookie management. Browsers maintain a separate “cookie jars” for each source, providing the necessary application and server apis to read and write new cookies, sessions, and validation data, and automatically adding and processing appropriate HTTP headers to automate the process

Here’s an example:

A simple but effective example of the convenience of browser-delayed session state management: Multiple Tabs or browser Windows can share an authentication session and vice versa; Logout in a TAB invalidates the session on other open pages.

Application APIS and protocols

Following network services, we now come to the application layer apis and protocols. As we already know, the underlying layer provides a number of key services: socket and connection management, request and response processes, enforcing security policies, caching, and so on. Every time we initialize an HTTP or an XMLHttpRequest, a persistently active server-sent 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 API. Every complex program mixes different transport protocols based on different requirements: interaction with the browser cache, protocol overhead, message latency, reliability, data transfer type, and more. Some protocols have features with low data transfer latency (such as server push events, WebSocket), but may not be suitable for other important situations, such as the ability to leverage browser caching or support binary data transfer in any case.

A few tips for improving security and performance

  • Use the “Connection: keep-alive” header in your requests. Browsers do this by default, and you need to make sure the server has the same mechanism.
  • Save browser download time by using appropriate cache-Control, Etag, and last-Modified headers
  • Spend time optimizing your web service. This is where real miracles happen. Note whether this process is specific to each program and the data being transmitted.
  • Use TLS frequently. Especially if your program contains any type of authentication.
  • Investigate the security policies provided by the browser and enforce them in your program.