HTTP / 0.9

HTTP was officially born in 1991 at version 0.9, and as the name suggests, the protocol was used to transfer hypertext content, HTML.

Protocol defines the communication mode in which the client initiates a request and the server responds to the request. The request message contains only one line, including GET and the requested file path. The server receives the request and returns an HTML document encoded in an ASCII character stream.

HTTP / 1.0

With the development of the Internet and the emergence of browsers, simple text content is no longer enough for users. Browsers want to transfer different types of files such as scripts, styles, images, audio and video through HTTP.

So in version 1.0 of the 1996 HTTP update, significant changes were made to address these issues.

One of the most important changes is the addition of header Settings, which are set 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.

This is also a very forward-looking design, because header fields are not only used to solve the problem of different types of file transfer, but also can be used for many other functions, such as caching and authentication information.

HTTP / 1.1

With the rapid development of the Internet, HTTP/1.0 has been unable to meet the needs, the core is the connection problem. To be specific, every HTTP/1.0 communication requires three phases: establishing a connection, transferring data, and disconnecting. When a page references many external files, the process of establishing and disconnecting can add a lot of network overhead.

To address this problem, HTTP/1.1, released in 1999, added a way to create persistent connections. The main implementation is that when a connection is completed, it is not immediately closed, but continues to reuse it for other requests, and the connection remains open until the browser or server asks to disconnect.

How does TCP establish/disconnect connections

Because HTTP is based on TCP, the process of establishing and disconnecting a connection is often referred to as the “three-way handshake” and the “four-way wave”

Three-way handshake

Before establishing a TCP connection, the client and server send data Three times to confirm the receiving and sending capabilities. This is called three-way Handshake.

The details of the three-way handshake are shown below.

First handshake: The client is in the CLOSED state and the server is in the LISTEN state. The client sends a SYN packet to the server with the ISN sequence number specified. The client is in the SYN_SEND state.

Second handshake: After receiving a SYN packet from the client, the server responds with its OWN SYN packet and specifies its initial ISN. At the same time, the ISN + 1 of the client is used as the ACK value, indicating that the server has received a SYN from the client, and the server is in the SYN_REVD state.

Third handshake: After receiving a SYN packet, the client sends an ACK packet. The ISN + 1 of the server is used as the ACK value, indicating that a SYN packet has been received from the server. In this case, the client is in the ESTABLISHED state. After receiving the ACK packet, the server is also in the ESTABLISHED state. In this case, the two parties establish a connection.

Why do you need three handshakes to establish a connection?

Just look at the purpose of each handshake. The first handshake lets the server know that the client has the sending capability. The second handshake lets the client know that the server has the receiving and sending capabilities. However, the server does not know whether the client has received the message. After three communications, both the server and client confirm their receiving and sending capabilities.

Four times to wave

Data is sent four times when the client and server are disconnected, a process known as quad waving.

The four waves are shown below.

First wave: The server and client are in the ESTABLISHED state before the first wave. The client sends a FIN packet to disable data transmission from the client to the server, and the client is in FIN_WAIT_1 state.

Second wave: After receiving the FIN packet, the server sends an ACK packet and adds 1 to the sequence number of the ACK packet to indicate that the packet has been received. In this case, the server is in CLOSE_WAIT state.

Third wave: If the server agrees to close the connection, it sends a FIN packet to the client and specifies a sequence number. In this case, the server is in the LAST_ACK state.

Fourth wave: When the client receives an ACK, it is in FIN_WAIT_2 state. After receiving a FIN packet, the client sends an ACK packet and uses the sequence number of the server plus 1 as the sequence number of its OWN ACK packet. In this case, the client is in TIME_WAIT state. After a period of time, the server enters the CLOSED state. After receiving the ACK packet, the server also enters the CLOSED state. In this case, the connection is CLOSED.

Why did it take only three times to establish a connection and four times to disconnect?

After receiving a FIN packet from a client, the server sends an ACK packet to reply to the FIN packet. This does not mean that the server wants to close the connection immediately.

When the server sends all the packets, it sends a FIN packet to inform the client that the connection can be disconnected. Therefore, the server needs to wave four times before disconnecting.

HTTP/2

Although HTTP/1.1 reduces the performance cost of creating/disconnecting a large number of connections through long connections, there is still a lot of room for improvement in transport performance due to its limited concurrency.

Why is the concurrency of HTTP/1.1 limited? It is mainly manifested in two aspects:

• In order to reduce the pressure on the server, the browser limits the number of HTTP connections in the same domain, namely 6 ~ 8, so it is easy to see the situation of resource files waiting to be loaded under HTTP/1.1. The corresponding optimization method is to use multiple domain names to load image resources.

• HTTP/1.1 itself, although HTTP/1.1 use persistent connection, multiple requests can share a TCP connection, but a connection can only handle one request at a time, until the current request is not finished, other requests can only be blocked, this situation is called “queue head blocking”.

Due to this problem, a binary frame splitting mechanism was added to HTTP/2, which was released in 2015, to improve transmission efficiency.

HTTP/2 will no longer use ASCII encoding for transport by default, but binary data. When sending a request, the client wraps the contents of each request into different numbered binary frames, which are then sent to the server simultaneously. When the server receives the data, it merges the frames with the same number into the complete request information. Similarly, the server returns the result and the client receives the result following the process of splitting and combining the frames.

Thanks to binary frame division, for the same domain, the client only needs to establish a connection with the server to complete the communication requirements, and is no longer limited by the browser connection number limit. This way of using a connection to send multiple requests is called “multiplexing”.

HTTP/2 also adds some additional features, such as compression of header information to reduce transport volume, and service push to reduce client requests. Binary framing, by contrast, is a core feature.

HTTPS principle

Although HTTP can meet the communication requirements of the client and server, sending data in plaintext has some security risks, because the communication content can be easily intercepted or even tampered with by a third party in the communication link. Encrypted transmission of communication data can solve this security risk.

Symmetric encryption

Encryption modes are classified into symmetric encryption and asymmetric encryption. The biggest difference is that symmetric encryption uses the same key during encryption and decryption, while asymmetric encryption uses different keys. Symmetric keys are superior in terms of performance, so they can be used.

But you certainly can’t use the same symmetric key in every communication, because if you use the same key, anyone who communicates with the server can get the key and easily decrypt other communication data. So it should be generated randomly for every communication.

Asymmetric encryption

Because it is impossible to ensure that the client and server generate the same random key at the same time, the generated random key must be transmitted. In this case, there is a risk of theft during transmission.

The solution to this problem is to encrypt the key for transmission. In addition to the symmetric encryption mentioned earlier, we only have asymmetric encryption options, such as the client using the public key to encrypt and the server using the private key to decrypt.

Certificate mechanism

The same problem arises: once the key pair is generated, how should it be distributed?

If the key pair is generated on the client and the private key is sent to the server, then the server needs to keep a key for each client, which is obviously not realistic. Therefore, only the server can generate the key pair and distribute the public key to the clients that need to establish a connection.

Sending it directly to the client will still be tampered with and can only be implemented by a third party, such as a certificate mechanism.

Specifically, the public key is added to a certificate, which contains information about the server, such as the issuer, domain name, and validity period. To ensure that the certificate is trusted, a trusted third party must sign the certificate. The third party is usually the Certification Authority (CA).

How do you verify the signature of the certificate?

To answer this question, understand the certificate signing process. Certificate signature is to obtain the unique hash value through MD5 calculation, and then use the private key of the certificate issuer to encrypt and generate the certificate.

In contrast, you need to use the public key of the certificate issuer to decrypt the signature, calculate the MD5 value of the certificate information, and compare the decrypted MD5 value with the calculated MD5 value. If the two values are consistent, the signature is trusted. Therefore, to verify the signature, you need to obtain the public key of the certificate issuer, which is in the certificate of the issuer.

This way of issuing and verifying certificates by signature will form a traceable chain, namely certificate chain. The certificates at the top of the certificate chain are called root certificates. These root certificates are preset in the operating system.

The certificate issuing and encryption mechanism described above is how HTTPS is implemented.

HTTP/3

Of course HTTP/2 is not perfect, consider the case where the entire TCP connection is suspended if the client or server loses a packet during communication, or if the network on either side is interrupted.

Because HTTP/2 uses binary framing multiplexing, only one TCP connection is usually used for transmission, and all subsequent data is blocked in the event of packet loss or network interruption. However, for HTTP/1.1, multiple TCP connections can be enabled. The failure of any TCP does not affect other TCP connections, and the remaining TCP connections can transmit data normally. HTTP/2 does not perform as well as HTTP/1 in this case.

In 2018, HTTP/3 solved this problem once and for all by changing the underlying TCP dependency to UDP. Compared with TCP, UDP transmits multiple data packets at the same time without establishing a connection. Therefore, the transmission efficiency is high. The disadvantage is that there is no confirmation mechanism to ensure that the peer party can receive data.

conclusion

It is important for front-end engineers to understand HTTP, whether it is for performance optimization or Web application development and design. The following table summarizes the core improvements and problems solved in each version of HTTP.

— Public account “Grace front” —

For every aspiring “front-end ER” to lead the way, build dream aspirations.

Just to be an excellent front end Engineer!