Http1.1
Cache handling
It introduces more cache control strategies, such as Entity tag, If-Unmodified-Since, If-Match, If-None-Match and other cache headers you can choose from to control caching policy.
Bandwidth optimization and network connection usage
A range header field was introduced into requests, allowing you to request only a certain part of a resource, i.e. returning status code 206 (Partial Content), which makes it convenient for developers to choose freely and make full use of bandwidth and connections.
Error notification management
It adds 24 new error status response codes, such as 409 (Conflict), meaning the requested resource conflicts with the resource’s current state; and 410 (Gone), meaning some resource on the server has been permanently deleted.
Host header handling
Both request and response messages in Http1.1 should support the Host header field, and a request message without a Host header field will report an error (400 Bad Request).
Persistent connections
Http1.1 supports persistent connections (PersistentConnection) and request pipelining (Pipelining): multiple HTTP requests and responses can be carried over a single TCP connection, reducing the cost and latency of establishing and closing connections. In HTTP1.1, Connection: keep-alive is enabled by default, which to some extent makes up for the shortcoming of HTTP1.0 having to create a connection for every request.
Http2.0
- Fully binary format
Multiplexing
Requests are attributed to their respective different server-side requests according to the request id.
Header compression
An encoder is used to reduce the size of the headers that need to be transmitted; both communicating parties each cache a copy of the header fields table, which both avoids transmitting duplicate headers and reduces the size that needs to be transmitted.
Server push
The server push feature.
What is the difference between Http2.0 multiplexing and persistent connection reuse in Http1.X?
- Http/1.* — one request-response, establish a connection, close it when done; every request has to establish a connection;
- Http/1.1’s Pipeling solution serializes several requests into a queue handled by a single thread; a later request waits for the earlier request’s response before it gets a chance to execute. Once some request times out, the subsequent requests can only be blocked, with nothing you can do about it — this is what people call head-of-line blocking;
- Http/2 allows multiple requests to execute in parallel on a single connection. A single request task that takes a long time will not affect the normal execution of the other connections;
What exactly is server push?
Server push can send the resources the client needs to the client together with index.html, saving the client the step of making repeated requests. Precisely because there is no request initiation, connection establishment and so on, static resources can be greatly sped up through server push.
Why is header compression needed?
Suppose a page has 100 resources to load (a fairly conservative number for today’s Web), and every request carries a 1kb message header (also not uncommon, given things like Cookies and referrers), then at least an extra 100kb is consumed just to fetch these message headers. HTTP2.0 can maintain a dictionary and update HTTP headers differentially, greatly reducing the traffic generated by header transmission.
How good is Http2.0 multiplexing
- The key to Http performance optimization is not high bandwidth, but low latency. A TCP connection “tunes” itself over time: at first it limits the connection’s maximum speed, and if data is transmitted successfully it raises the transmission speed over time. This tuning is called TCP slow start. Because of this, HTTP connections, which are inherently bursty and short-lived, become very inefficient.
- Http/2 lets all data streams share the same connection, which makes more effective use of the TCP connection, so that high bandwidth can truly serve HTTP performance improvements.
