Skip to main content

HTTP vs HTTP/2

HTTP was first proposed by Tim Berners Lee in 1990 and many websites follow the same till today. As Google's SPDY got introduced in 2009 with few advancements, HTTP/2 seems like a response to SPDY.

Before I dive into the main differences let me recollect the basic concepts like What is HTTP/ HTTP2? or What is protocol?

Protocol:
Protocol defines the rules for data communication mechanisms between clients and servers.
Three basic components that makes a protocol are:

  1. Header -- Provides info on size, type, source and destination addresses.
  2. Payload -- Actual message transmitted using protocol.
  3. Footer -- Similar to header, contains control fields.
Two most often used commands over HTTP
Get - Requests data from a specified resource.
Post - Submits data to be processed to a specified resource.
Other methods include:
  • HEAD - gets HTTP headers
  • PUT - Uploads a representation of the specified URI
  • DELETE - Deletes specified resource
  • OPTIONS - Returns HTTP methods that server supports
  • CONNECT - Converts request connection to a transparent TCP/IP tunnel
Why Improve HTTP?
With all these advantages and features why HTTP is not enough and what pushed to innovate to HTTP/2. Here are few limitations to notice in old version:

- HTTP  processes only one request per TCP connection. Being synchronous HTTP/1.1 is forcing browsers to use multiple TCP connections to process multiple requests. Using multiple requests slows network performance for other users and results in:
  • TCP Congestion
  • Data Duplication
- Couple of techniques used by developers to improve performance are Domain Sharding, Concatenation, Data inlining, Multiple connections, Spriting etc..

- Poor resource prioritization degrades performance as the Web application grow in terms of complexity, functionality and scope and not to mention the other security loopholes.

What's up with HTTP/2?
All of the issues and workarounds are result of one fundamental issue(Synchronous requests) with HTTP/1.1. The new version HTTP/2 fixes this by firing all requests once and dealing with responses as they come in. HTTP/2 is binary rather than text based protocol which supports parallel multiplexed requests and response that do not block each other. Single TCP connection is used. Reduced latency, faster web performance and here's my favorite better SEO rankings :-). Though HTTP/2 server push is a good feature, It doesn't fit in for every website and its really premature at this point of time. Unlike HTTP/1.1 which process text commands to complete request-response cycles, latest version will use binary commands to execute same tasks. HTTP/2 uses HPACK specification to compress redundant headers which helps avoid pushing similar headers in each request as in HTTP/1.1. Here's a good comparison of differences between HTTP/1.x, SPDY(Google's response to address HTTP/1.x issues), HTTP/1.2 by Kinsta

Similarities with HTTP1 and SPDY


With significant improvements in performance, security and availability. HTTP/2 may become the default protocol to transfer data. 

Browser Support:

  • Chrome
  • Firefox
  • Apple Safari
  • IE - IE8 and above
  • and I'm sure there's  more being added to the list.

Thanks to awesome folks @Tune the Web and @Kinsta and of course Google for helping me improve my understanding on HTTP/2.


Comments

Popular posts from this blog

Spring Boot - RestTemplate PATCH request fix

  In Spring Boot, you make a simple http request as below: 1. Define RestTemplate bean @Bean public RestTemplate restTemplate () { return new RestTemplate (); } 2. Autowire RestTemplate wherever you need to make Http calls @Autowire private RestTemplate restTemplate ; 3. Use auto-wired RestTemplate to make the Http call restTemplate . exchange ( "http://localhost:8080/users" , HttpMethod . POST , httpEntity , String . class ); Above setup works fine for all Http calls except PATCH. The following exception occurs if you try to make a PATCH request as above Exception: I / O error on PATCH request for \ "http://localhost:8080/users\" : Invalid HTTP method: PATCH ; nested exception is java . net . ProtocolException : Invalid HTTP method: PATCH Cause: Above exception happens because of the HttpURLConnection used by default in Spring Boot RestTemplate which is provided by the standard JDK HTTP library. More on this at this  bug Fix: This can b...

RADUS#4 - Caching the response in REST API's

  Caching in spring boot app: Caching can be used to provide a performance boost to your application users by avoiding the business logic processing involved again and again, load on your DB, requests to external systems if the users request data that's not changed frequently Different types of caching: We'll be focusing more on in-memory caching in this post i listed other options available to have an idea. In-memory caching You'll have a key-value data stores that stores the response of the request after it is served for the first time There are multiple systems like Redis, Memcached that do this distributed caching very well By default Spring provides concurrent hashmap as default cache, but you can override CacheManager to register external cache providers. Database caching Web server caching Dependencies needed: Maven < dependency > < groupId > org . springframework . boot </ groupId > < artifactId > spring - boot - starter - cache ...

Settings.xml for Maven, JFrog

For development and deployment of applications we always use an artifactory in real-time world to host artifacts needed for your build and also as a target to deploy artifacts generated in the build process. For Maven, to communicate with artifactory we need a settings.xml file which is usually located at "/User/rake/.m2/settings.xml" this file consists of how to authenticate to the artifactory servers and authorizations to read/ write to different locations like release, snapshots e.t.c... Settings.xml can be generated using the artifactory you're using which in my case is JFrog , but here's a sample settings file for your reference incase you're feeling lazy☺ <?xml version="1.0" encoding="UTF-8"?> <settings xsi:schemaLocation= "http://maven.apache.org/SETTINGS/1.1.0 http://maven.apache.org/xsd/settings-1.1.0.xsd" xmlns= "http://maven.apache.org/SETTINGS/1.1.0" xmlns:xsi= "http://www.w3.org/2001/XM...