A little background If you’re a web developer (or indeed any developer nowadays) then you really should know HTTP as this is the de facto protocol for client/server communication on the web. HTTP is in essence the TCP/IP protocol for the web using ports 80 and 442 by default (for non-secure and secure communication respectively). HTTP dates back to the late 1980’s and early 1990’s so it’s a mature protocol which was designed long before the modern web app of today. Thus, many conceivable performance enhancements have been proposed over the years that saw things like headers (initially missing from the 0.9 HTTP specification), VERBS (HTTP initially consisted only of GET requests), content types and much more. However, these enhancements were working within the constraints of the original HTTP specification and the HTTP/1.1 was pushed to the maximum. It greatly needed a reboot. And in 2015 HTTP/2.0 was born. HTTP/2.0 is born Through a partnership between Google (and its now deprecated SPDY protocol) and a number of other leading bodies, the HTTP/2.0 specification was drafted which focused on a number of major shortcomings in the HTTP/1.x specification. Primary targets for optimisation included: Prioritise binary content over text Header compression Inherrant security Multiplexing Server-side push Whereas earlier versions of the protocol were purely text based, HTTP/2.0 is a binary protocol consisting of a HEADERS frame and a DATA frame (analogous but not the same as the headers and body in HTTP as you know it today). Frames are grouped into streams. Because of this, only a single TCP connection is required to transmit multiple resources, as various streams can be sent to the client and easily reconstructed using the stream id to decompose frames accurately. Server push With the multiplexing described above, clients can eagerly make several requests for resources knowing the server can send them on the same connection. However, servers utilising a HTTP/2.0 connection can be a little more pro-active and actually push content to the client knowing it will be needed. The server will notify the client that it is performing a server push using a special frame called a PUSH-PROMISE which informs the client that it is sending data that it hasn’t asked for, but thinks it will need. Therefore when the client later realises it needs this resource, it already has it and knows where to get it without contacting the server. Prioritisation With all this lovely asynchronous goodness and pro-activeness on a single stream, it is conceivable that the client could be waiting longer for a resource on a TCP connection as its being intermixed with other content. This has been though of though and clients can tag a request with a priority so that it can later send the server a PRIORTY request frame and switch priority levels of resources being returned, thus allowing it to get the most important content first. Without...Read More »
On my blog…
I'm a gadget loving code-junkie who loves to program, create websites and try out new stuff. Married, with two young daughters I am also a keen marathon runner and fitness enthusiast.
- Cloud Technologies (Azure & AWS)
- Mobile application development
- WordPress / Orchard CMS / Alterian ACM
- C#, Asp.net MVC & WebForms, Python
- IIS & Windows Server