2.1 HTTP Versions

This is a historical learning note and may contain outdated or incomplete understanding.

1. HTTP/1.0

A TCP connection is established for each HTTP request, and the TCP connection is released after the request is completed, so that resources can be released as soon as possible to serve other clients.
Problem: for static resources such as images, each image requires a request to the server, and the time spent re-establishing the connection is wasteful.
- Solution: Connection: Keep-Alive. That is, do not release the connection after a request; keep it alive.

HTTP is a stateless protocol, meaning that it has no memory for transaction processing. In other words, every request is independent and complete. The previous request and the next request are unrelated and cannot perceive each other.
Benefit: good horizontal scalability.
Problem: we have a requirement to know whether multiple requests were sent by the same user.
- Solution: Cookie and Session.md. However, repeated data has to be carried with every request, so performance decreases.

Multiple HTTP requests reuse one TCP connection. As long as neither the client nor the server explicitly requests that the TCP connection be disconnected, the connection remains open and can carry multiple HTTP requests.
Problem: in the short-connection scenario, closing the connection means request processing has finished. With a persistent connection, how do we determine that request processing has finished?
- Solution: Content-Length: xxx: this field tells the client how many bytes the HTTP Response Body contains. After the client receives that many bytes, it knows that the response has been completely received.
  - Problem: it is difficult to calculate the length for dynamic content.
    - Solution: Chunk (HTTP Streaming).
      - Transfer-Encoding: chunked: tells the client that the response Body is divided into chunks, with delimiters between chunks and a special marker at the end of all chunks. This allows the client to determine the end of the response even without a Content-Length field.
Connection pool: only HTTP persistent connections have a connection pool. http.md

The client can issue multiple HTTP requests at the same time without waiting for each response one by one.
Problem: head-of-line blocking. The client sends requests 1, 2, and 3. The server processes them concurrently and returns the responses. Responses 2 and 3 may have reached the client while response 1 has not. At this point, the client blocks waiting for response 1. Therefore, Pipeline is disabled by default.

It actually uses HTTP message headers and chunked transfer encoding to transfer the entity body in chunks.

In HTTP/1.1, there is already corresponding compression for the message body, especially for images, which are already compressed; however, message headers have not been compressed.