HTTP1.0 HTTP 1.1 HTTP 2.0 main differences

1. Long connection

HTTP 1.1 Supports long connection (persistentconnection) and requested pipelining (pipelining) processing

HTTP 1.0 Specifies that the browser and the server only maintain a brief connection, each request of the browser needs to establish a TCP connection with the server, the server completes the request processing immediately after disconnecting the TCP connection, the server does not track each customer also does not log past requests.

HTTP 1.1 Supports persistent connection persistent Connection, and persistent Connection is used by default. Multiple HTTP requests and responses can be delivered in the same TCP connection. Multiple requests and responses can overlap, and multiple requests and responses can be made concurrently. More request headers and response headers (such as HTTP1.0 fields without host).

Session Mode at 1.0:
1. Establish a connection
2. Sending Request information
3. Loopback response Information
4. Turn off the connection

HTTP 1.1 Persistent connection, also need to add new request header to help implement, for example, when the value of the connection request header is keep-alive, the client notifies the server to keep the connection after returning the result of the request, and 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 mechanisms such as authentication, state management, and cache caching.

Request Pipeline (pipelining) processing, where multiple HTTP requests and responses can be delivered on a single TCP connection, reducing the consumption and latency of establishing and shutting down the connection.  For example, multiple requests and responses that contain a Web page file with many images can be transferred in one connection, but requests and responses for each individual Web file still need to use their own connection. HTTP 1.1 also allows the client to make the next request without waiting for the last request result to be returned, but the server side must echo the response in the order in which the client requests are received, to ensure that the client can differentiate the response from each request.

2.Host Domain

HTTP 1.1 Add Host Field

In HTTP1.0, each server is considered to be bound to a unique IP address, so the URL in the request message does not have a 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 HTTP1.1 request message and the response message should support the host header domain, and an error will be reported in the request message if there is no Host header field ("Bad Request"). In addition, the server should accept resource requests marked with an absolute path.

3. Save Bandwidth

(Continue) Status (save bandwidth)

(1) http/1.1 added a new status code of (Continue). The client sends a lead-only domain request, and if the server rejects the request because of the permission, the Echo Response code 401 (unauthorized) is sent back, and if the server receives this request, the client can continue to send the full request with the entity with the Echo Response code 100. The use of the 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

(2) http/1.1 introduced the chunked transfer-coding to solve the above problem, the sender divides the message into a number of arbitrary-sized chunks of data, each data block is sent with the length of the block, and finally a 0-length block as the message end of the flag. This method allows the sender to buffer only one fragment of the message, avoiding overloading the entire message.

(3) http/1.1 adds some new features to the cache based on 1.0, when the cached object becomes stale object when age exceeds expire, the cache does not need to discard the stale object directly, but is reactivated with the source server (revalidation).

HTTP1.1 HTTP 2.0 main differences

1. What is HTTP 2.0

HTTP/2 (Hypertext Transfer Protocol version 2nd, originally named HTTP 2.0), is the second major version of the HTTP protocol for use on the World Wide Web. HTTP/2 is the first update of the HTTP protocol since the 1999 HTTP 1.1 release, primarily based on the Spdy protocol (a TCP-based application-layer protocol developed by Google to minimize network latency, improve network speed, and optimize the user's network experience).

2, compared with HTTP 1.1, the main differences include

1. HTTP/2 in binary format rather than text format
2. HTTP/2 are fully multiplexed, rather than ordered and blocked-parallel with just one connection
3. With header compression, HTTP/2 reduces overhead
4. HTTP/2 allows the server to proactively "push" responses to the client cache

3, HTTP/2 why is binary?

Compared to text protocols like http/1.x, binary protocols are more efficient to parse, "online" more compact, and, more importantly, fewer errors.

4. Why does HTTP/2 need multiple transmission?

Http/1.x has a problem called line-end blocking (Head-of-line blocking), which refers to a connection (connection) that submits only one request at a time is more efficient and slows down. http/1.1 tried to use pipelining (pipelining) To solve this problem, but the effect was not ideal (a large amount of data or a slower response would hinder the request that came after him). In addition, because the network medium (intermediary) and the server does not have the very good support pipeline, causes the deployment to be difficult. Multi-channel transmission (multiplexing) can solve these problems very well, because it can handle the request and response of multiple messages simultaneously; You can even mix one message with another during the transfer. So the client only needs a connection to load a page.

5. Why does the message header need to be compressed?

Given that a page has 80 resources to load (a number that is quite conservative for today's web), each request has a 1400-byte header (which is also not uncommon because of the existence of cookies and references), at least 7 to 8 "online" to get these headers. This doesn't include response time-it's just the time it takes to get them from the client. This is all due to TCP's slow-start mechanism, which determines the number of packages to be fetched back and forth based on how many packets are known, which clearly limits the amount of packets that can be sent back and forth in the first few rounds. In contrast, even a slight reduction in the head can be a matter of getting those requests back and forth--sometimes even a package. This overhead can be saved, especially when you're considering mobile client applications, and even under good conditions, you'll typically see a hundreds of-millisecond back-and-forth delay.

6. What are the benefits of server push?

When the browser requests a Web page, the server sends back the HTML, and the server waits for the browser to parse the HTML and send all the embedded resources before the server starts sending JavaScript, pictures, and CSS. The server push service avoids round-tripping delays by "pushing" the content that it believes the client will need to the client's cache.

HTTP1.0 HTTP 1.1 HTTP 2.0 main differences