This article analyzes the differences between HTTP1.0 and HTTP1.1 from the perspective of communication performance. And the differences between HTTP1.1 and HTTP2.0. The details of this article are organized as follows

directory

One, HTTP1.0 and HTTP1.1 communication performance differences

  1. Persistent connection
  2. Pipelining technology

Second, HTTP2.0 and HTTP1.1 communication performance differences

  1. multiplexing
  2. HTTP header compression

The body of the

One, HTTP1.0 and HTTP1.1 communication performance differences

  • Persistent connection

    HTTP1.1 supports persistent connections by default. HTTP1.0 to support persistent connections requires the display of the specified Keep-Alived header.

    1. HTTP communication over non-persistent connections

    • For example, visit the URL www.taobao.com. The URL is accessed from the target server to a static resource such as HTML, which is automatically disconnected when the server returns the resource. This is a non-persistent HTTP communication process. This process includes TCP three handshakes and four waves of the hand.
    • Furthermore, static HTML must contain many images, JS, CSS, and other resources, all of which are stored on the server. Access to these resources repeats the HTTP communication process described above, including the TCP three-way handshake and four-way wave. This process of repeatedly establishing and releasing TCP connections wastes a lot of bandwidth resources on the server and slows down the loading speed of Web pages. The following figure shows the communication process of HTTP over a non-persistent connection

    2. HTTP communication over persistent connections

    Persistent connections are easy to understand. After an HTTP connectivity process, the server does not disconnect if it is not notified that the connection is closed, but maintains the connection. As a result, when visiting a page such as www.taobao.com, most of the resources on the page can be transferred over a single TCP link. This greatly reduces the performance loss caused by releasing multiple TCP connections. Communication over persistent connections is shown below

    • Pipelining technology

    Pipelining technology further improves communication performance on the basis of persistent connection. Under persistent connections, requests and responses are sequential. The next request can be sent only after the last request receives a response. Pipelining is the ability to send multiple responses sequentially when no response is received.

Second, the communication performance comparison between HTTP2.0 and HTTP1.1

  1. Multiplexing technology

    Multiplexing is based on persistent connections, allowing all requests to share the same connection and be transmitted in parallel. The values of multiplexing and pipework differ here in:.

    • In pipelining, all requests are sent sequentially. In multiplexing, all requests are sent in parallel.

  2. Header compression

    Header compression is also easy to understand, reducing the overhead of header fields in HTTP packets and improving communication efficiency. There are two main reasons for using header compression:

    (1) For a single HTTP packet, when it carries a small amount of communication data, the size of the packet header is much larger than the valid communication data, resulting in low bandwidth utilization.

    (2) In persistent connection, repeated header fields often exist in transmission between multiple HTTP packets.

    The HTTP2.0 header compression algorithm is optimized for both of the above points:

    • Based on static dictionary compression, a static dictionary is maintained between the HTTP client and server. This static dictionary stores a large number of common HTTP header fields. For example, static dictionaries:

      In static dictionaries, two cases are preserved:

      • Complete packet headers and field values, such as Content-language: zh-cn.
      • Complete header, such as user-agent.

    Based on the static dictionary, the index number in the static dictionary can be used to replace the HTTP header. Generally, one byte is enough to cover all the index numbers in the static dictionary. As shown in the figure below, the HTTP header is replaced by a byte format, with index being the index number in the static dictionary.

    • Based on dynamic dictionary compression

      Static dictionaries cannot cover all combinations of HTTP header key-value pairs, so dynamic dictionary compression is added to static dictionary compression.

      The dynamic dictionary compression process is relatively simple. If you encounter an HTTP header field that does not exist in a static dictionary, you use uncompressed transport here, and then add the header field to the dynamic field. The next time the same header field is passed, it can be compressed based on the contents of the dynamic dictionary.

      1. The longer the communication process, the more content the dynamic dictionary will accumulate, so HTTP header compression is better
      2. The contents of the dynamic dictionary are reset when the connection is newly established.