Http1.0 vs. HTTP1.1

A long connection

HTTP 1.0 requires the keep-alive parameter to tell the server to establish a long connection, whereas HTTP1.1 supports long connections by default. HTTP is based on THE TCP/IP protocol. Creating a TCP connection requires a three-way handshake, which costs a certain amount of money. If a connection needs to be re-established each time, performance will be affected. Therefore, it is best to maintain a long connection, which can be used to send multiple requests.

HTTP 1.1 supports sending only header information (without any body information) and returning 100 if the server thinks the client has permission to request the server, or 401 otherwise. The client does not start sending the request body to the server until it receives 100. In addition, HTTP1.1 supports transmission of portions of content, which is the basis for breakpoint continuation.

The HOST domain

Now that Web Servers such as Tomat are available, it is very common to set up virtual sites, that is, multiple virtual sites on a Web Server can share the same IP and port.

HTTP1.0 does not have a host field; HTTP1.1 only supports this parameter.

Http1.1 vs. HTTP2.0

multiplexing

HTTP2.0 uses multiplexing techniques to process multiple requests concurrently for the same connection, and the number of concurrent requests is orders of magnitude larger than HTTP1.1 (HTTP1.1 can create multiple TCP connections concurrently, but maintaining connections consumes resources).

Data compression

HTTP2.0 uses the HPACK algorithm to compress header data to speed up transmission.

HTTP versus HTTPS

  1. For HTTPS, you need to apply for a certificate from the CA.
  2. HTTP is a hypertext transmission protocol, and information is transmitted in plain text. HTTPS is a secure SSL encryption transmission protocol.
  3. HTTP and HTTPS use completely different connections, with the former being 80 and the latter 443.
  4. HTTP connections are simple and stateless; HTTPS is a network protocol that uses SSL and HTTP to encrypt transmission and authenticate identity. It is more secure than HTTP.

HTTPS Transfer Process

  1. The client initiates an HTTPS request
  2. The server sends a certificate to the client (public key)
  3. The client parses and validates the certificate (public key, issuing authority, expiration date, etc.)
  4. The client sends an encrypted private key (encrypts its own string using the public key and sends it to the server)
  5. The server decrypts the encrypted private key (the server uses the certificate private key to parse out the string passed by the client)
  6. Server-side encryption information (the server uses the client’s private key (the client’s own string) to encrypt all data sent to the client)
  7. The client uses the private key to parse the data sent by the server (all sent data is encrypted with this key and then transmitted)

Symmetric encryption: The same key is used for both encryption and decryption

Asymmetric encryption: Asymmetric encryption uses public key encryption, while decryption requires a private key

Reversible encryption: can be decrypted

Irreversible encryption: also called one-way encryption, cannot decrypt the algorithm such as MD5