Media Content Distribution: HTTP/2 Architecture

A web surfing by the browser is the most valuable way Media Content Distribution provided around the World. Technically, this process is based on HTTP networking protocol. Actually, HTTP is treated as protocol of Internet. The industry is always in motion at line of new features and challenges, so HTTP protocol is waiting for its new second version. For now, HTTP/2 [https://github.com/http2/http2-spec] is approved by its creators and going to be accepted and published as RFC standard. HTTP/2 release will have huge impact on direction of many networking techniques and implementation approaches. It would be first sufficient change in Media Content Distribution since HTTP/1.1 release in 1999.


HTTP/2 is based on Google’s SPDY protocol. As you can see, there is one more Google’s technology appears modern enough to be used as standard of future. HTTP/2 is a binary protocol instead of text HTTP/1.1. There is much better performance produced by changes in architecture: header compression, multiplexing requests, requests priorities, proactive push-responses from servers side. It supports IPv4, IPv6 and NAT. There are modern security approaches. Firefox and Chrome already have HTTP/2 support in special mode. To test new protocol you need to install HTTP/2 server. There are several server side implementations by Akamai, Google, Twitter and open source.


To move your application under HTTP/2, it needs to apply specific changes. Otherwise, there would be a problems with performance.

HTTP/2 is based on a concept of stream, messages and frames. The is a channel to send bidirectional messages. The message is a logical HTTP packet like a request or a response. Messages consists of one or several frames. The frame is the smallest unit of specific data such as header or payload. You can’t telnet to HTTP/2 server to send some HTTP request by hand. It’s binary and you need special tool wget, curl, browser.

HTTP/1.1 has limits for TCP connections the browser may use for the same domain. So, if the page has a lot of resources (JavaScript, CSS, media), the page loading takes a lot of time. HTTP/2 introduces multiplexing to use one connection and load multiple resources via that single connection simultaneously. That means you don’t need to concatenate CSS and JavaScript resources into monolithic bundles and avoid composing several images into single sprite sheet.

There is strong request-response scheme applied in HTTP/1.1. In HTTP/2, the server may send several resources right for the first page request. To use this feature, the application should be able to figure out the set of resources it needs to push to the client side. For further optimization, each request may have a priorities attribute (0 is highest priority). HTTP/2 has the same methods (GET, POST, etc.) and status codes (200, 404, etc.).


As HTTP/2 is based on SPDY, it supports TLS as well, but is not forced to use it by design. On the other hand, it looks like main browser (Chrome and Firefox) may be limiting HTTP/2 support via TLS connections only. That pushes Media Content Distribution to be much more secured, as a whole. HTTP/2 will support headers compression. If there is a security sensitive data, you better avoid compression, because of several attack types in case of HTTP compression are possible for both HTTP/1.1 and HTTP/2.

Read also

Comments are closed.