1. HTTP 1.1 supports persistent connection (PersistentConnection) and request pipeline (Pipelining) processing
HTTP 1.0 stipulates that the browser and the server only maintain a short-term connection. Each request of the browser needs to establish a TCP connection with the server. After the server completes the request processing, the TCP connection is immediately disconnected. The server does not track each client or record the past ask.
HTTP 1.1 supports persistent connection Persistent Connection, and persistent connection is used by default. Multiple HTTP requests and responses can be transmitted in the same tcp connection. Multiple requests and responses can overlap, and multiple requests and responses can be performed simultaneously. More The request header and response header (for example, HTTP1.0 does not have a host field).
Session mode in 1.0:
1. Establish a connection
2. Send a request message
3. Send back a response message
4. Turn off the connection
The persistent connection of HTTP 1.1 also needs to add new request headers to help realize. For example, when the value of the Connection request header is Keep-Alive, the client informs the server to keep the connection after returning the result of this request; the value of the Connection request header is close , the client notifies the server to close the connection after returning the result of this request. HTTP 1.1 also provides request headers and response headers related to mechanisms such as authentication, state management, and Cache.
Request pipeline (Pipelining) processing, multiple HTTP requests and responses can be sent on a TCP connection, reducing the consumption and delay of establishing and closing connections. For example, multiple requests and responses for a web file containing many images can be transmitted in one connection, but each individual web file request and response still needs to use its own connection. HTTP 1.1 also allows the client to send the next request without waiting for the result of the previous request to be returned, but the server must return the response results in the order in which the client's request was received, so as to ensure that the client can distinguish the response of each request. Response content.
2. HTTP 1.1 adds host field
In HTTP 1.0, each server is considered to be bound to a unique IP address, so the URL in the request message does not pass the hostname (hostname). But with the development of virtual host technology, there can be multiple virtual hosts (Multi-homed Web Servers) on a physical server, and they share an IP address.
The request message and response message of HTTP1.1 should support the Host header field, and if there is no Host header field in the request message, an error (400 Bad Request) will be reported. Additionally, the server SHOULD accept resource requests marked with absolute paths.
3. 100 (Continue) Status (saving bandwidth)
HTTP/1.1 added a new status code 100 (Continue). The client sends a request with only the header field in advance. If the server rejects the request because of permissions, it returns a response code of 401 (Unauthorized); if the server receives the request, it returns a response code of 100, and the client can continue to send a complete request with an entity. . The use of the 100 (Continue) status code allows the client to test the server with the request header before sending the request message body, to see if the server wants to receive the request body, and then decide whether to send the request body.
4. Chunked transfer-coding was introduced in HTTP/1.1 to solve the above problem. The sender divides the message into several data blocks of any size. Each data block will be sent with the length of the block, and finally a zero The length of the block serves as a sign of the end of the message. This approach allows the sender to buffer only a fragment of the message, avoiding the overload of buffering the entire message.
5. HTTP/1.1 adds some new cache features on the basis of 1.0. When the Age of the cached object exceeds Expire, it becomes a stale object. The cache does not need to directly discard the stale object, but revalidates with the origin server (revalidation). .