Network based

RTT

Round-trip Time (RTT) is also an important performance index in computer networks. It refers to the total delay experienced from the Time when the sender sends data to the Time when the sender receives confirmation from the receiver (the receiver sends confirmation immediately after receiving data).

RTT= Point in time when the client receives the earliest response from the server – Point in time when the client sends the last response

HTTP1.0

Each request requires a new handshake, and the TCL link is closed when the transmission is complete. Only 4-6 TCP links are sent at a time.

The obvious drawback of 1.0 was that every file had to be re-connected to TCP, which was very time consuming and resource consuming.

HTTP1.1

To optimize the 1.0 problem, the 1.1 protocol allows multiple HTTP requests to be made over a TCP connection to reduce TCP connection consumption.

So there are a variety of optimization methods for HTTP1.1 front-end, such as:

  1. Domain name fragmentation exceeds the link limit. Procedure
  2. Merge files
  3. Inline resources
  4. Picture Sprite

Chrome allows up to six TCP links to be opened for HTTP requests. In Chrome, the browser dynamically allocates requests to avoid HTTP queue header blocking.

HTTP2

The HTTP2 protocol uses the concept of frames. After the server establishes a TCP connection with the browser, all the files are transferred as binary frames. After receiving these frames, the client assembles the data.

As mentioned earlier, HTTP1.1 requests files sequentially, whereas HTTP2 requests data frames. Although performance is improved, this can cause TCP queue header blocking problems because data processing is done on only one TCP connection.

Although it is frame data, the data is still sent in an ordered data queue. The client receives the data in turn. If a serial number TCP packet is lost, the browser will wait for the packet to be sent again. Subsequent data from this package is stored temporarily, so that subsequent data cannot be processed, even if subsequent frames can assemble other files, because of this problem.

Server push

Traditional preloading

<link rel="preload" href="/styles.css" as="style">
Copy the code

Everyone preloads the resources they need later, but this still consumes the requested resources.

HTTP2 server push

The realization of the nginx

server { listen 443 ssl http2; . location / { ... http2_push /style.css; http2_push /example.png; }}Copy the code

Dynamic push

When the background responds to the request, the Link command is generated. Then attach the files you want to push.

Link: </styles.css>; rel=preload; as=style, </example.png>; rel=preload; as=image

Copy the code

Nginx configuration for dynamic push

server { listen 443 ssl http2; #... root /var/www/html; location = / { proxy_pass http://upstream; http2_push_preload on; }}Copy the code

HTTP3

HTTP3 is a new generation protocol that incorporates HTTP2 features and is based on QUIC. It is designed to reduce bandwidth costs, improve user access speed and so on.

Using HTTP3 can save client RTT, save data retransmission, and avoid TCP queue header blocking.

QUIC

QUIC, short for Quick UDP Internet Connections, is an experimental transport layer network transport protocol developed by Google and implemented in 2013. QUIC uses the UDP protocol, which creates connections between two endpoints and supports multiplexing connections. Initially, QUIC wanted to provide SSL/TLS level network security, reduce latency for data transmission and connection creation, and control bandwidth in both directions to avoid network congestion. Google hopes to use this protocol to replace TCP and make web pages faster, and plans to submit QUIC to the Internet Engineering Task Force (IETF) as the next generation of official web specifications.

First, briefly, what are the advantages of using QUIC?

  1. Retransmission and recovery can be performed
  2. Security: Each packet can be independently encrypted or authenticated using IV
  3. 0-RTT handshake: Saves a session key to facilitate network migration

However, the disadvantages of QUIC are also obvious. The current network infrastructure is built on the basis of TCP, so the bandwidth of UDP packets is expected to be insufficient.

To avoid UDP packet loss, QUIC has a Forward Error Correction (FEC) feature, which is designed like Raid. After packet loss, other packets can be used for recovery. However, the number of packets that can be restored is limited. Beyond a certain number, packets cannot be restored and can only be retransmitted.