dcsimg

Best Practices for HTTP1.1 Becoming Bad Practices for HTTP/2

  • Best Practices for HTTP1.1 Becoming Bad Practices for HTTP/2-

    Domain Sharding

    HTTP 1.1 only allowed a single transaction per TCP connection, meaning that a client could send just one resource request at a time, and needed to wait for the server reply to be completed before he could send the next request. In order to bypass this limitation, "domain sharding" was used to create multiple TCP connections and allow for multiple transactions to take place in parallel and accelerate the delivery of the web page.

    With HTTP/2, this practice is no longer needed, as the new protocol version allows multiple transactions to be multiplexed over a single TCP connection at the same time, also allowing the server to send interleaved replies, in a different order than the order in which the requests were sent. In fact, continuing to use multiple TCP connections with HTTP/2 will take its toll on the setup time it takes to build each connection, as well as in the amount of compute resources it requires from the server and the browsers.

1 | 2 | 3 | 4 | 5 | 6 | 7

Best Practices for HTTP1.1 Becoming Bad Practices for HTTP/2

  • 1 | 2 | 3 | 4 | 5 | 6 | 7
  • Best Practices for HTTP1.1 Becoming Bad Practices for HTTP/2-2

    Domain Sharding

    HTTP 1.1 only allowed a single transaction per TCP connection, meaning that a client could send just one resource request at a time, and needed to wait for the server reply to be completed before he could send the next request. In order to bypass this limitation, "domain sharding" was used to create multiple TCP connections and allow for multiple transactions to take place in parallel and accelerate the delivery of the web page.

    With HTTP/2, this practice is no longer needed, as the new protocol version allows multiple transactions to be multiplexed over a single TCP connection at the same time, also allowing the server to send interleaved replies, in a different order than the order in which the requests were sent. In fact, continuing to use multiple TCP connections with HTTP/2 will take its toll on the setup time it takes to build each connection, as well as in the amount of compute resources it requires from the server and the browsers.

The Internet has evolved significantly since HTTP 1.1 was introduced 17 years ago. During this evolution, we've seen many enhancements to improve a user's online experience, such as the development of rich content. However, delivering these improvements came at one particular cost: performance. These evolving performance challenges were something that HTTP 1.1 was not designed to handle.

In February 2015, the Internet Engineering Task Force (IETF), an international community of network designers, operators, vendors and researchers concerned with the evolution of Internet architecture, released a new HTTP/2 version to address those challenges and adapt to the progression that Internet content has undergone.

As HTTP/2 took a long time to arrive, many interim best practices were developed to bypass the performance bottlenecks of HTTP 1.1. However, we learned that many of those HTTP 1.1 performance-enhancing practices would actually contribute to slowing web application delivery rather than accelerating it when using the new HTTP/2 protocol. In this slideshow, Radware's Yaron Azerual takes a look at a few examples organizations should consider.