HTTP1.0 contrast HTTP1.1

HTTP.1 has several major improvements

  • Request connection principle

  • Client cache

  • Connection width optimization

  • Request the Host domain

  • Request status code

  • Request method

Request connection principle

In HTTP 1.0, each request from the client required a separate connection, which was automatically released after the request was processed.

In HTTP 1.1, multiple requests can be processed in a single connection, and multiple requests can overlap without waiting for one request to complete before sending the next.

Setting up a TCP connection requires a three-way handshake:

First handshake: The client sends a SYN packet (SYN = J) to the server and enters the SYN_SEND state.

Second handshake: After receiving a SYN packet, the server must acknowledge the client’s SYN (ACK = J +1) and send a SYN packet (ACK = K). In this case, the server enters the SYN_RECV state.

Third handshake: After receiving the SYN+ACK packet from the server, the client sends an ACK packet (ACK = K +1) to the server. After the packet is sent, the client and the server enter the ESTABLISHED state to complete the three-way handshake.

There is no data in the packet that is sent during the handshaking process. After three handshakes, the client and server begin to send data. Ideally, once a TCP connection is established, it is maintained until either of the communicating parties voluntarily closes the connection. During disconnection, both the server and the client can initiate a request to disconnect the TCP connection. The disconnection process requires “four handshakes”.

HTTP1.1 PersistentConnection, which delivers multiple HTTP requests and responses over a TCP Connection, reduces the cost and latency of establishing and closing TCP connections. Keep-alive, to some extent, compensates for HTTP1.0’s disadvantage of creating a connection on every request.

Client cache

In HTTP/1.0, the Expire header field is used to determine whether a resource is fresh or stale, and conditional requests are used to determine whether a resource is still valid. For example, the cache server verifies to the server whether the last-mo______ header field of the resource has been updated via the if-Modified-since header field and the source server may return 304 (Not Modified) indicating that the object is still valid. It is also possible to return 200 (OK) to replace the requested Cache object.

In addition, THERE is Pragma:no-cache header field defined in HTTP/1.0, which is used by clients to state that the requested resource cannot be fetched from the cache, but must be fetched from the source.

HTTP/1.1 added some new features of cache over 1.0. Stale objects are not discarded when their Age expires, but are revalidated with the source server.

In HTTP/1.0, the if-Modified-since header uses absolute timestamps, accurate to the second, but using absolute times can cause clock synchronization problems on different machines. HTTP/1.1 introduced an ETag header field for the reactivation mechanism, whose 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 a cache-Control header field (both request and response messages can be used), which supports an extensible subset of instructions: for example, max-age directives support relative timestamps; The private and no-store directives prohibit objects from being cached; No-transform prevents the Proxy from doing anything to change the response.

Cache uses the keyword index to index objects cached on disk, and in HTTP/1.0 uses the URL of the resource as the keyword. However, there may be cases where different resources are based on the same URL, and distinguishing them requires additional information from the client, such as the 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, which lists which header fields need to be included in the request message for content negotiation.

Connection width optimization

HTTP1.1 supports delivery of a portion of the content. For example, when the client already has a portion of the content, it can only request a portion from the server to save bandwidth.

In HTTP/1.0, there are some wasted bandwidth phenomena, such as the client only needs part of an object, but the server sends the whole object. For example, the client only needs to display part of a document, or it needs to support breakpoint continuation when downloading large files, rather than having to re-download the entire package after a disconnection.

HTTP/1.1 introduced the range header field in request messages, which allows only a portion of a resource to be requested.

          "Content-Type": "application/octet-stream"."Content-Range": \`bytes ${startPosition}-${endPosition}/${file.size}\ `Copy the code

The content-range header in the response message declares the starting position and length of the returned portion of the object. If the server returns the Partial Content of the requested object accordingly, the response code is 206 (Partial Content), which prevents the Cache from mistaking the response for a complete object. My file concurrent upload project has used this request method.

A very effective way to save bandwidth resources is to compress the data to be transmitted. Content-encoding is the end-to-end Encoding of the message, which may be the inherent format (such as jpeg image format) of the resource stored on the server. Add an Accept-Encoding header field to the request message, which tells the server what Encoding the client can decode.

Transfer-encoding is a hop-by-hop Encoding, such as Chunked Encoding. Add TE header fields to the request message to tell the server which transfer-coding mode it can receive,

Request the Host domain

The **Host ** request header specifies the server Host name and port number to which the request will be sent. HTTP1.0 does not include Host,

If no port number is included, the default port of the requested service is automatically used (for example, port 443 for HTTPS urls and port 80 for HTTP urls).

We can’t deploy multiple services to a server if we use HTTP1.0. HTTP1.1 solves this problem.

All HTTP/1.1 request messages must contain a Host header field. For HTTP/1.1 requests that lack a Host header or have more than one Host header, a 400 (Bad Request) status code may be received.

Request status code

HTTP1.1 added two status codes that were not in 1.0,

The use of the 100 (Continue) status code allows a client to test the server with the Request header before sending the request body to see if the server wants to receive the request body, and then decide whether to send the request body.

101 (Switching Protocols) A status code like this occurs when we use websocket in a web page

Request method

HTTP1.0 defines three request methods: GET, POST, and HEAD.

HTTP1.1 adds six new request methods: OPTIONS, PUT, PATCH, DELETE, TRACE, and CONNECT.

HTTP2.0

Http2.0 is a secure and efficient next generation HTTP transport protocol. Secure because HTTP2.0 is based on the HTTPS protocol, efficient because it transmits data through binary framing.

He has the following major improvements to HTTP1.x

  • Binary Format

  • Multiplexing/connection sharing

  • Header Compression

  • Request Priorities

  • Server Push

Enabling HTTP2.0 provides significant performance improvements, but also introduces new performance bottlenecks. Because all the pressure is now concentrated on the bottom TCP connection, TCP is likely to be the next performance bottleneck, such as the problem of blocking at the head of the TCP packet. The loss of a single TCP packet causes the whole connection to be blocked, and all messages will be affected.

I have summarized the differences between HTTP and HTTPS in another article.

Reference

  • TCP and HTTP and sockets
  • HOST(MDN)
  • HTTP request methods
  • HTTP2.0 in depth

One More Thing

Welcome to follow my personal public numberMr. Wang, who likes to do things

PS: Attention has welfare oh ~