HTTP details (3)-differences between http1.0 and http1.1

I have reviewed the protocol standard RFC2616 of HTTP1.1. Below are some differences between RFC2616 and HTTP1.0.

1. Persistent Connection

In HTTP1.0, each Request/Response uses a new connection.

In HTTP 1.1, Persistent Connection is supported, and persistent connection is used by default. multiple HTTP requests and responses can be sent over the same tcp connection. multiple requests and responses can overlap, and multiple requests and responses can be performed simultaneously. more request headers and Response Headers (for example, HTTP1.0 does not have a host field ).

For HTTP 1.1 persistent connections, you also need to add new request headers for implementation. For example, when the connection request header value is keep-alive, the client notifies the server to keep the connection after returning the result of this request. When 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 identity authentication, status management, and cache caching.

HTTP 1.0 requires that the browser and the server only maintain a short connection. Each request of the browser needs to establish a TCP connection with the server. After the server completes request processing, the TCP connection is closed immediately, the server does not track each customer or record past requests. In addition, because most web pages have low traffic, a TCP connection rarely passes through the slow-start area, which is not conducive to improving bandwidth utilization.

The session method at 1.0:
1. Establish a connection
2. Send request information
3. Return Response Information
4. Disconnect

Summary:The connection between the browser and the Web server is very short. Each connection only processes one request and response. For each page request, the browser and the Web server must establish a separate connection. the connection is closed before the browser is closed. the communication between the browser and the server is completely separate request and response pairs. in this way, the browser cannot be disconnected or the connection status cannot be controlled. Establishing and disabling a connection will occupy the connection time.

In a webpage, the number of close headers in the connection in the HTTP header is equivalent to the number of HTTP connections.

HTTP 1.1 supports persistent connection and pipelining. Multiple HTTP requests and responses can be sent over a TCP connection, reduces the consumption and delay of establishing and disabling connections. For example, multiple requests and responses to a webpage file containing many images can be transmitted in one connection, but the requests and responses of each webpage file still need to be connected.

HTTP 1.1 also allows the client to send the next request without waiting for the result of the previous request. However, the server must send the response in sequence according to the order in which the client request is received, to ensure that the client can differentiate the response content of each request, which significantly reduces the time required for the entire download process.

To establish a persistent connection in HTTP/1.0, You can include the connection: keep-alive header in the request message. If the server is willing to maintain this connection, the response message also contains a connection: keep-alive header. You can also add commands to describe the attributes of the persistent connection, such as Max and timeout.

In fact, the connection header can carry three types of symbols:

1. a list containing several head domain names. The declaration is limited to the header domain information of a hop connection;

2. Any value, non-standard options for this connection, such as keep-alive;

3. close value, indicating that the persistent connection is closed after message transmission is complete;

 

Message transmission between the client and the source server may be forwarded by many intermediate nodes, which is a hop-by-hop (hop-by-hop ). HTTP/1.1 correspondingly introduces the hop-by-hop header domain, which only applies to one hop instead of the entire transfer path. If a message received by an intermediate node (such as a Proxy or Gateway) contains a Connection header domain, a list of header domain names in the Connection header domain will be searched, delete the header fields in the message before forwarding the message to the next node.

Generally, the HTTP/1.0 Proxy does not support the Connection header domain. To prevent them from forwarding the header domain that may mislead the receiver, the Protocol requires that all header domain names that appear in the Connection header domain will be ignored.

2. host domain

HTTP1.0 considers that each server is bound with a unique IP address. Therefore, the URL in the request message does not pass the Host Name (hostname ). However, with the development of virtual host technology, multiple virtual hosts (Multi-homed Web Servers) can exist on a physical server, and they share an IP address.

Both the Request message and Response Message of HTTP1.1 should support the Host Header domain. If the Request message does not have the Host Header domain, an error (400 Bad Request) will be reported ). In addition, the server should accept resource requests marked with absolute paths.

HTTP1.1 has an additional Host field in the Request Message Header, for example:

GET/pub/www/theproject.html HTTP/1.1

HOST: www.w3.org

Http1.0 does not have this domain.

It is possible that the IP address has been specified when a TCP connection is established in http1.0, and there is only one host on this IP address.

Because HTTP 1.0 does not support the host request header field, the Web browser cannot use the Host header name to indicate which web site on the server to access, in this way, you cannot use the Web server to configure multiple virtual web sites on the same IP address and port number. After the host request header field is added to HTTP 1.1, the Web browser can use the Host header to specify which web site on the server to access, this allows you to create multiple virtual web sites by using different host names on the same IP address and port number on a Web server.

 

3. Date/timestamp (date timestamp)

(Receiving direction)

Both http1.0 and http1.1 must be able to parse the following three types of date/time stamp:

Sun, 06 Nov 1994 08: 49: 37gmt; RFC 822, updated by RFC 1123

Sunday, 06-nov-94 08: 49: 37gmt; RFC 850, obsoleted by RFC 1036

Sun NOV 6 08: 49: 371994; ansi c's asctime () Format

(Sending direction)
Http1.0 requires that the date/time stamp in the third asctime format cannot be generated;

Http1.1 requires that only date/time stamp in RFC 1123 (first type) format be generated.

4. Transfer codings

Http1.1 supports chunked transfer, so there can be a transfer-encoding header domain:

Transfer-encoding: chunked

Http1.0 does not exist.

HTTP messages can contain entities of any length. Generally, they use Content-Length to indicate the end of a message. However, for many dynamically generated responses, you can only buffer the complete message to determine the message size, but this will increase the latency. If you do not use persistent connections, you can determine the end of a message by means of the signal that the connection is closed.

Chunked transfer-coding is introduced in HTTP/1.1 to solve this problem. The sender splits the message into several data blocks of any size, each data block is attached with the length of the block when it is sent, and a zero-length block is used as the sign of message termination. This method allows the sender to buffer only one segment of the message to avoid the overload caused by buffering the entire message.

In HTTP/1.0, there is a Content-MD5's header domain that needs to be computed before the sender can buffer the complete message. In HTTP/1.1, A chunked-based message is transmitted after the end of the last block (zero length). It contains one or more header domains, these header fields are calculated by the sender after passing all the blocks. The sender will include a trailer header in the message to inform the receiver of the existence of the tail.

5. Quality Values

Http1.1 has multiple Qvalue fields:

Qvalue = ("0" ["." 0*3 digit])

| ("1" ["." 0*3 ("0")])

 

6. entity tags

Used for cache.

 

7. Range and content-range (save optimization)

Http1.1 supports sending part of the content. For example, if a client already has a portion of the content, you can request only a portion of the content from the server to save bandwidth.

In HTTP/1.0, bandwidth is wasted. For example, the client only needs a part of an object, but the server sends the entire object. For example, the client only needs to display part of a document. For example, when downloading large files, you must support the resumable upload function, instead of having to download the complete package again after the disconnection.

In HTTP/1.1, the range header field is introduced in the request message, which allows only a part of the resource to be requested. In the response message, the content-range header declares the offset value and length of the returned objects. If the server returns the content of the range requested by the object, the response code is 206 (partial content), which prevents the cache from mistakenly believing that the response is a complete object.

A very effective way to save bandwidth resources is to compress the data to be transferred. Content-encoding is the end-to-end encoding of messages. It may be an inherent format (such as JPEG image format) that resources are stored on servers ); add the accept-encoding header to the request message, which tells the Server Client the encoding method that can be decoded.

Transfer-Encoding is a hop-by-hop Encoding, such as Chunked Encoding. Add the TE header field to the request message to notify the server of the transfer-coding method,

8. 100 (CONTINUE) status (bandwidth saving)

Another waste of bandwidth is that if the request message contains a large amount of entity content, but it is not sure whether the server can receive the request (if it has permissions ), in this case, if a request with entity is sent rashly, the bandwidth will be wasted if the request is rejected.

HTTP/1.1 adds a new status code 100 (Continue ). The client sends a request that only takes the lead domain in advance. If the server rejects the request because of the permission, the server returns the Response Code 401 (Unauthorized). If the server receives this request, the server returns the response code 100, the client can continue sending complete requests with entities. Note that HTTP/1.0 clients do not support 100 Response codes. However, the client can add the same CT header to the request message and set its value to 100-continue.

The 100 (Continue) Status Code allows the client to test the server with the request header before sending the request body. Check whether the server wants to receive the request body and decide whether to send the request body.

The client contains

Secondary CT: 100-continue

If the status code 100 (Continue) is returned after the Server sees it, the client will Continue sending requestbody.

This is only available in HTTP1.1.

9. Request Method

OPTIONS, PUT, DELETE, TRACE, and CONNECT Request methods are added to HTTP1.1.

Method ="Options"; Section 9.2:

| "Get"; section 9.3

| "Head"; section 9.4

| "Post"; Section 9.5

| "Put"; Section 9.6:

| "Delete"; Section 9.7:

| "Trace"; Section 9.8:

| "Connect"; Section 9.9:

| Extension-method

Extension-method = token

10. Status Code

The new status code added by HTTP1.1:

 

(Http1.0 does not define any specific 1xx status code, and http1.1 has 2)

100 Continue

101 Switching Protocols

 

203 Non-Authoritative Information

205 Reset Content

206 Partial Content

 

302 Found (There is a 302 moved temporarily in http1.0)

303 See Other

305 Use Proxy

307 Temporary Redirect

 

405 Method Not Allowed

406 Not Acceptable

407 Proxy Authentication Required

408 Request Timeout

409 Conflict

410 Gone

411 Length Required

412 Precondition Failed

413 Request Entity Too Large

414 Request-URI Too Long

415 Unsupported Media Type

416 Requested Range Not Satisfiable

417 Expectation Failed

 

504 Gateway Timeout

505 HTTP Version Not Supported

11. Cache)

In HTTP/1.0, use the Expire header domain to determine the resource's fresh or stale, and use the conditional request to determine whether the resource is still valid. For example, If the cache server uses the If-Modified-Since header field to verify to the server whether the Last-Modefied header field of the resource has been updated, the source server may return 304 (Not Modified ), this indicates that the object is still valid. The 200 (OK) Replacement request Cache object may also be returned.

In addition, The Pragma: no-cache header domain is defined in HTTP/1.0. The client uses this header domain to indicate that the requested resource cannot be obtained from the cache, but must be retrieved from the source.

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 discard the stale object directly, instead, it is re-activated with the source server (revalidation ).

In HTTP/1.0, the If-Modified-Since header field uses an absolute timestamp, accurate to seconds, but the use of absolute time will cause clock synchronization problems on different machines. In HTTP/1.1, an ETag header domain is introduced for re-activation. Its value entity tag can be used to uniquely describe a resource. The If-None-Match header field can be used in the request message to Match whether the entitytag of the resource has changed.

To make the caching mechanism more flexible, HTTP/1.1 adds the Cache-Control header domain (both request messages and response messages can be used). It supports an extensible subset of commands: for example, the max-age command supports the relative timestamp; the private and no-store commands prohibit objects from being cached; the no-transform command prevents the Proxy from performing any behavior that changes the response.

The Cache uses keywords to index the cached objects on the disk. In HTTP/1.0, the resource URL is used as the keyword. However, different resources may be based on the same URL. to distinguish them, the client also needs to provide more information, such as Accept-Language and Accept-Charset header fields. To support this content negotiation mechanism, HTTP/1.1 introduces the Vary header field in the Response Message, this header field lists the header fields to be included in the request message for content negotiation.

Rationale:

Rfc2616Hypertext Transfer Protocol -- HTTP-1.1.txt

Rfc1945Hypertext Transfer Protocol -- HTTP 1.0.txt

Determine the header fields in the message for content negotiation.

Benefits of persistent connections in HTTP 1.1

A web site may receive millions of user requests every day. To improve system efficiency, HTTP 1.0 requires that the browser and server only maintain a short connection, each browser request requires a TCP connection with the server. The server disconnects the TCP connection immediately after processing the request. The server does not track or record the previous request. However, this also causes some performance defects. For example, a webpage file containing many images does not contain real image data content, the URL of these images is specified. When a web browser accesses this webpage file, the browser must first send a request for this webpage file, when the browser parses the HTML content in the webpage document returned by the Web server, after the Image Tag is found, the browser sends an image download request to the server again based on the URL specified by the src attribute in the label, as shown in Figure 3.3.

 

Fig 3.3

Obviously, the whole process of accessing a webpage file containing many images involves multiple requests and responses. Each request and response requires a separate connection, each connection transmits only one document and image, and the previous and next requests are completely separated. Even if the image files are small, it is a relatively time-consuming process to establish and close the connection between the client and the server, and seriously affects the performance of the client and the server. When a webpage file contains the applet, Javascript file, CSS file, and other content, the above situation also occurs.

To overcome this defect of HTTP 1.0, http1.1 supports persistent connections. Multiple HTTP requests and responses can be sent over a TCP connection, reducing the consumption and delay of establishing and disabling connections. Multiple requests and responses to a webpage file containing many images can be transmitted in one connection, but each individual webpage file's request and response still need to use their own connection. HTTP 1.1 also allows the client to send the next request without waiting for the result of the previous request. However, the server must send the response in sequence according to the order in which the client request is received, to ensure that the client can differentiate the response content of each request, which significantly reduces the time required for the entire download process. Based on HTTP
1.1 information exchange between the client and the server, as shown in Figure 3.4.

Fig 3.4

It can be seen that HTTP 1.1 inherits the advantages of HTTP 1.0 and also overcomes the performance problems of HTTP 1.0. In addition, HTTP 1.1 also improves and expands http1.0 by adding more request headers and response headers. For example, because HTTP 1.0 does not support the host request header field, the Web browser cannot use the Host header name to indicate which web site on the server to access, in this way, you cannot use the Web server to configure multiple virtual web sites on the same IP address and port number. After the host request header field is added to HTTP 1.1, the Web browser can use the Host header to specify which web site on the server to access, this allows you to create multiple virtual web sites by using different host names on the same IP address and port number on a Web server. HTTP
For the 1.1 persistent connection, a new request header needs to be added for implementation. For example, when the connection request header value is keep-alive, the client notifies the server to return the request result and keep the connection; when the value of the connection request header is close, the client notifies the server to return the result of this request and close the connection. HTTP 1.1 also provides request headers and Response Headers related to identity authentication, status management, and cache caching.