The difference between HTTP1.0 and HTTP1.1
1. Long connection
HTTP1.0 uses non-persistent connections, a TCP connection can only send one HTTP request and response, and automatically disconnects after completion
HTTP1.1 supports persistent connection (long connection), a TCP connection lasts for a long time, and can transmit multiple HTTP requests and responses
How to establish a long connection
HTTP1.0 needs to add Connection: Keep-Alive in HTTP to enable long-term connection. HTTP1.1 starts long-term connection by default by giving Keep-Alive
Assignment close can be closed.
Advantages: Reduces the consumption and delay of establishing and closing connections.
2. Cache Control
Cashe-Control
Compared with HTTP1.0 Expires, Cashe-Controlthe defined cache expiration time is more accurate ( Expiresthe defined cache time is relative to the time on the server, if the time on the client is inconsistent with the time on the server, the accuracy will drop). ExpiresIf and both appear in the message Cashe-Control, Cashe-Controlthe priority of is higher. Cashe-ControlAs a general HTTP header field, it can be used in both the request message and the response message. The format is:
"Cache-Control" ":" cache-directive
- no-cache: It does not mean that it will not be cached, but will be cached, but every time the response data is provided to the client, the cache must re-verify the validity of the cache to the original server (freshness verification)
- no-store: the response is not cached
- max-age: Set the maximum period of cache storage, beyond which the cache is considered expired (in seconds). In
Expirescontrast, the time is relative to the time of the request. - max-stale: The client can accept this response object that exceeds the freshness, but the prerequisite is that the expiration time of the response time must be less than
max-stale - min-fresh: Indicates that the client wants to get a response that can keep its latest status within the specified number of seconds (not updated within the specified number of seconds)
- public: Indicates that the response can be cached by any object (including: the client sending the request, the proxy server, etc.)
- private: Indicates that the response can only be cached by a single user and cannot be used as a shared cache (that is, a proxy server cannot cache it)
cache checksum
Cashe-ControlDetermines whether data can be cached and when the cache expires. But if the cache expires, and the server has not actually updated the data, it will be a waste of time and resources to re-request the resource. Cache verification determines whether to resend data by judging whether the cache has been modified.
Solution 1:
Last-Modified: Match according to the last modification time
When the server delivers the resource to the client, it will add the time of the last change of the resource Last-Modified: GMTto the entity header and return it to the client. The client will mark this information for the resource, and when it requests again next time, it will attach this information to the request message and bring it to the server for checking. As for passing the stamped last modification time there are two different approaches:
1. If-Modified-Since: Last-Modified-value
If-Modified-Since: Thu, 31 Mar 2016 07:07:52 GMT
The request header tells the server that if the last modification time sent by the client is the same as that on the server, then just return 304 and the response header directly, otherwise return 200 and new data.
2. If-Unmodified-Since: Last-Modified-value
When the resource has not been modified after the specified time, the server returns 200 and data, and if the requested resource has been modified after the specified time, it returns 412
Solution 2:
ETag: Match by resource identifier (resource fingerprint)
According to Last-Modifiedthe matching, there is a disadvantage. If a resource is modified, but the actual content has not changed, the Last-Modifiedentire entity will be returned to the client or 412 will be returned directly because of the mismatch. In order to solve this problem, Http1.1 introduced resource-based Method for identifier matching.
The server will calculate a unique identifier * (such as md5 flag) * for the resource through a certain algorithm, and when responding to the resource to the client, it will add it to the entity header and return it to the client ETag: 唯一标识符. The client will keep the ETag field and bring it to the server in the next request. The server only needs to compare whether the ETag sent by the client is consistent with the ETag of the resource on its own server, and can judge whether the resource has been modified relative to the client. There are also two different ways to pass identifiers:
1. If-None-Match: ETag-value
If-None-Match: "56fcccc8-1699"
If the resource matches, return 200 and the requested resource, if the resource does not match, if the verification fails, return 304 and the response header or directly return 412
2. If-Match: ETag-value
Resource Match returns 200 and returns the resource or allows uploading the resource. If it does not match, a status code starting with 4 will be returned.
3. Save bandwidth
The range field is introduced in the HTTP header, which can be used to tell the server to return only a certain part of the file. In one Rangeheader , multiple parts can be requested at once, and the server will return them as multipart files. If the server returns a range response, the 206 Partial Contentstatus code needs to be used. If the requested range is invalid, the server will return 416.
Range: bytes=start-end
Another way to save bandwidth is to compress the data to be transmitted. Content-EncodingLists the type of any encoding applied to the current entity message (message payload), and the order of encoding. Add the header field to the request message Accept-Encoding, which can tell the server the encoding method that the client can decode.
4. Host domain
In HTTP1.0, each server is bound to a unique IP address by default, so the url in the request message does not pass the host name, that is, the hostname, but the virtual host technology behind allows multiple virtual hosts to exist on a physical server. They share an ip address.
Both HTTP1.1 request messages and response messages 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 requests for resources marked with absolute paths.
5. Error message
The http1.1 version adds 24 error status response codes.
The difference between HTTP1.x and HTTP2.0
HTTP/2It is the first update of the HTTP protocol since HTTP1.1it was released , and it is mainly based on the SPDY protocol.
HTTP1.xThere are four main differences compared with
1. Use binary format for data transmission
HTTP1.XData transmission is based on text, and the format analysis based on text protocol is not perfect. The binary format is more efficient to parse.
2. Multiplexing
HTTP1.x There is a problem called head-of-line blocking, which means that the efficiency of submitting only one request at a time for a connection is relatively high, and if there are too many, it will slow down . HTTP1.1Solve this problem through long connections, but the effect is not ideal (a large amount of data or a slow response will hinder the requests behind him).
Multiplexing can solve these problems very well, because it can handle the request and response of multiple messages at the same time. Once the TCP connection of the HTTP2 request is established, subsequent requests are sent in the form of stream. The basic unit of each stream is frame (binary frame). Clients and servers can break HTTP messages into independent frames, send them out of order, and finally reassemble them at the other end.
3. HTTP header compression
HTTP1.xThe header contains a lot of information, and it has to be sent repeatedly every time. HTTP2.0Use the encoder to reduce the size of the header that needs to be transmitted. Both parties in the communication cache a table of header fields, which not only avoids the transmission of repeated headers, but also reduces the size of the header that needs to be transmitted. size.
4. Server push
When the user's browser and the server establish a connection, the server actively pushes some resources to the browser and caches them. With caching, when the browser wants to access cached resources, it can directly read from the cache, which can effectively reduce the number of requests.