Features of HTTP Versions and HTTPS

HTTP/1.0

• Support GET and POST request methods
• In essence, long connections are supported, but the default is short connections. The keep-alive keyword is added to change from short connections to long connections.
• The request and response format of HTTP has also changed. In addition to the data to be transmitted, each communication contains header information to describe some information.
• Also added status code, multi-character set support, multi-part type, authorization, cache, content encoding, etc.

HTTP/1.1

The biggest change in HTTP 1.1 is the introduction of long links, that is, TCP links are not closed by default and can be reused by multiple requests. If the client or server finds that the other party is inactive for a long time, it will close the link, but the standard practice is that the client asks the server to close the link at the last request. For the same domain name, the current browser supports the establishment of 6-8 long links (chrom, 6, firefox, 8).

insufficient

The main reason is that the connection is slow, and the server can only respond in order. If a request takes a long time, there will be a request queue blocking.

HTTP/2.0

Features

• Binary Framing
• header compression
• flow control
• multiplexing
• request priority
• server push

Binary framing does not change the semantics, methods, and status codes of HTTP1.x. In the case of URL and header fields, HTTP2.0 breaks through the performance limitations of HTTP1.1 by adding a binary framing layer between the application layer (HTTP) and the transport layer (TCP), improves transmission performance, and achieves low latency and high throughput.

• Frame: The smallest unit of HTTP2.0 communication, all frames share an 8-byte header, which contains the length, type, flag, and a reserved bit of the frame, and at least an identifier that identifies the stream to which the current frame belongs , frames carry specific types of data, such as HTTP headers, payloads, etc.
• Message: A communication unit larger than a frame, which refers to logical HTTP messages, such as requests and responses. consists of one or more frames
• Stream: A communication unit larger than a message. It is a virtual channel in a TCP connection that can carry bidirectional messages. Each stream has a unique integer identifier
• header compression
  HTTP1.1 does not support HTTP header compression, for which SPDY and HTTP2.0 appeared. SPDY uses the DEFLATE algorithm, while HTTP2.0 uses the HPACK algorithm specially designed for header compression.

flow control
HTTP 2.0 provides a simple mechanism for data flow and connection traffic:

• Traffic is based on each hop of the HTTP link, not end-to-end control
• Flow control is based on window update frames, that is, the receiver broadcasts how many bytes of a data stream it is ready to receive, and how many bytes it wants to receive for the entire link.
• Flow control is directional, that is, the receiver may set any window size for each stream or even the entire link according to its own situation
• Flow control can be disabled by the receiver, both for individual flows and for the entire link.
• The type of frame determines whether flow control is applied to the frame. Currently, only DATA frames are subject to flow control, and all other types of frames do not consume space in the flow control window. This ensures that important control frames are not blocked by flow control

The server push server returns multiple responses in advance according to the client's request, and pushes additional resources to the client.

insufficient

• http2 is based on the tcp protocol. The tcp protocol was not designed on the basis of the current high-quality and high-bandwidth network infrastructure at the beginning of its design. He fully considered the reliability of the data and seemed cautious. The performance of the transmission rate also It can't keep up with the current network infrastructure. It remains to be seen whether more optimized network layer protocols will be developed in the future, including protocols like QUIC based on the udp protocol. Personally, I think it is better to implement the lower-level protocol by the os kernel. The QUIC protocol is implemented in the application layer rather than the kernel layer of the operating system, which is always a soft underbelly.
• Most http2 implementations and applications (including browsers and web servers) must in fact be based on the TLS (SSL) Secure Sockets Layer. For a basic protocol that carries Internet content, such security considerations are reasonable and necessary. There are pros and cons. The TLS handshake and data encryption process will inevitably bring some burdens to the communication and communication parties. These burdens and extra costs are sometimes not necessary for some internal applications, such as between back-end microservices, and can be simplified.
• Since the real world has been established based on http1, the infrastructure on some communication links, such as http proxy, cannot support http2 for the time being, so this will hinder the spread of http2, and this obstacle may be a long-term process.
• Since http2 is binary and the transmission is multiplexed, compression, priority control, flow control, and server push are considered in the design of different frames, which makes the http2 protocol more complicated. Therefore, the implementation of the protocol and the debugging of the application will obviously increase some difficulties compared with the simple plaintext http1. Simple and intuitive, for humans, with an innate affinity.

Common Status Codes

• 1xx: Indication information - Indicates that the request has been received, continue processing
• 2xx: Success - Indicates that the request has been successfully received
• 3xx: Redirect - Indicates that further action must be taken to complete the request
• 4xx: Client Error - Indicates that the request has a syntax error or the request cannot be fulfilled
• 5xx: Server Error - Indicates that the server failed to fulfill a legitimate request
  

HTTP/3.0

Background Since HTTP 2.0 relies on TCP, what is wrong with TCP will be what is wrong with HTTP2. The most important thing is the head-of-line blocking. The problem at the application layer has been solved, but the head-of-line blocking at the TCP protocol layer has not been solved.
TCP will retransmit when a packet is lost. If there is a packet in front of it that is not received, it can only put the latter packet in the buffer. The application layer cannot fetch data. That is to say, the multiplexing parallelism of HTTP2 is very important for The loss recovery mechanism of TCP does not work, so lost or reordered data will cause the interaction to hang. To solve this problem, Google invented the QUIC protocol.

Features

1. Kill TCP directly at the transport layer and replace it with UDP
2. Implemented a new congestion control algorithm to completely solve the problem of TCP squadron head blocking
3. It realizes the functions of flow control and transmission reliability similar to TCP. Although UDP does not provide reliable transmission, QUIC adds a layer on top of UDP to ensure reliable data transmission. It provides packet retransmission, congestion control, and some other features present in TCP
4. A fast handshake function is implemented. Since QUIC is based on UDP, QUIC can use 0-RTT or 1-RTT to establish connections, which means that QUIC can send and receive data at the fastest speed.
5. TLS encryption is integrated. QUIC currently uses TLS1.3

HTTPS

digital certificate

Verify server identity. If there is no verification, it may be hijacked by the middleman. If the request is intercepted by the middleman, the middleman gives his own public key to the client, and the client receives the public key and sends the information to the middleman. After the middleman decrypts and gets the data, Then request the actual server, get the public key of the server, and then send the information to the server. The server and the CA have a pair of keys (public key and private key), and then how to generate a digital certificate?

1. The CA agency generates a digest (hash digest) of the server's public key through the digest algorithm
2. The CA organization encrypts the digest through the CA private key and a specific signature algorithm to generate a signature
3. Pack the signature, server public key and other information into the digital certificate and return it to the server

After the server is configured with the certificate, when the client connects to the server, the certificate is sent to the client for verification and the public key of the server is obtained.

Certificate verification

• Decrypt the signature in the CA using the CA public key and the declared signature algorithm to obtain the digest content of the server public key
• Then use the digest algorithm to generate a digest for the server public key in the certificate, and then compare the digest with the digest obtained in the previous step. If the certificate is consistent, the public key inside is correct, otherwise it is illegal.

Certificate authentication is divided into one-way authentication and two-way authentication

• One-way authentication: the server sends the certificate, the client verifies the certificate
• Two-way authentication: The server and the client provide certificates to each other and verify each other's certificates. However, most https servers are one-way authentication. If the server needs to verify the identity of the client, it is usually through the user name, password, mobile phone verification code, etc. Class credentials to authenticate. Only systems with higher-level requirements, such as large-amount online banking transfers, will provide two-way authentication scenarios to ensure the authentication of customer identities.

encryption process

TLS actually uses a hybrid encryption of the two algorithms. The key of the symmetric encryption algorithm is exchanged through the asymmetric encryption algorithm. After the exchange is completed, the symmetric encryption is used to encrypt and decrypt the transmission data. This ensures the confidentiality of the session. The process is as follows

1. The browser sends a random number client-random and a list of supported encryption methods to the server
2. The server sends another random number server-random, encryption method, and public key to the browser
3. The browser generates another random number pre-random, encrypts it with the public key and sends it to the server
4. The server decrypts it with the private key to get the pre-random
5. Both the browser and the server mix the three random numbers with encryption to generate the final key

In this way, even if it is intercepted, the intermediary cannot obtain the pre-random without the private key, and cannot generate the final key.

A symmetric encryption algorithm uses the same key for encryption and decryption. Such as AES, DES. Encryption and decryption process:

1. The browser sends a random number client-random and a list of supported encryption methods to the server
2. The server returns to the browser another random number server-random and an encryption method supported by both parties
3. Then the two use the encryption method to mix the two random numbers to generate a key, which is the encryption and decryption key of both parties.

advantage

1. The content is encrypted, and the original content cannot be viewed in the middle
2. Authentication to ensure correct user access.
3. Data integrity to prevent content from being impersonated or tampered with by third parties
4. Although it is not absolutely safe, it is the safest solution under the current architecture, which greatly increases the cost of man-in-the-middle attacks.

insufficient

1. Ask for money, the more powerful the certificate, the more expensive
2. The certificate needs to be bound to an IP, and multiple domain names cannot be bound to the same IP
3. HTTPS encryption and decryption on both sides consumes more server resources
4. The https handshake is more time-consuming and reduces the access speed of certain users (optimization is not a disadvantage)

TLS1.2 handshake

1. The browser sends the server a random number client-random, TLS version and a list of supported encryption methods
2. The server generates an elliptic curve parameter server-params, random number server-random, encryption method, certificate, etc. and passes it to the browser
3. The browser also generates elliptic curve parameters client-params, handshake data summary and other information to the server
4. The server then returns the digest to the browser to confirm the response

This version no longer generates the elliptic curve parameters client-params and server-params, but after the server-params and client-params are obtained on both sides of the server and the browser, the ECDHE algorithm is used to directly calculate the pre-random, which has both sides. Three random numbers are generated, and then each of the three random encryptions is mixed to generate the final key

TLS1.3 handshake

The RSA algorithm was abandoned in the TLS1.3 version, because the RSA algorithm may leak the private key and cause all historical packets to be cracked, while the ECDHE algorithm generates a temporary key for each handshake, so even if the private key is cracked, it can only be cracked A message without affecting the previous historical information. At present, the mainstream is to use the ECDHE algorithm for key exchange.

1. The browser generates a list of client-params, and client-random, TLS version and encryption method and sends it to the server
2. The server returns server-params, server-random, encryption method, certificate, digest, etc. to the browser
3. The browser confirms the response, returns the handshake data digest and other information to the server

Simply put, the handshake process is simplified. There are only three steps. The original two RTTs are packaged into one and sent, so the number of transmissions is reduced. This handshake is also called 1-RTT handshake

Continuing handshake optimization can use session reuse