Some one may be curious to know what TLS/SSL version is being currently used by Client Browser with Server when a website is displayed in browser?
Very easy to check this..
In Chrome ( Verified on version 43.0.2357.124, hope this works on other version the same way):
View Security TLS version thru this menu option
Right click anywhere on the browser window, with https based website currently open in it. Once you select “view page info” menu option, another window will open. second tab on this window will be ‘connection’. You will see the TLS version being used by website, on this tab..
In IE ( Verified on 11.0.9600.17728)
Right click anywhere on the browser window, with https based website currently open in it. Once you select “properties” menu option, another window will open. You will see the TLS version being used by website, on this new window.
Happy checking TLS version and stay safe.
HTTP/2.0 is next major version of HTTP. Last version in use of HTTP is 1.1. RFC for v 2.0 is 7540. IESG is the group which manages and approves this standards. This new v2.0 was approved by this group in Feb 2015.
Chrome, Opera, Firefox, Internet Explorer 11, Safari, and Amazon Silk browsers are some the browsers which are HTTP/2 ready.
This new version of the HTTP protocol provides much better connection utilization (fewer round-trips between client and server), resulting in lower latency web page loading for users. Web pages (as opposed to services) benefit the most from HTTP/2, since the protocol optimizes for multiple artifacts being requested as part of a single experience.
• Multiplexing and concurrency: Several requests can be sent in rapid succession on the same TCP connection, and responses can be received out of order – eliminating the need for multiple connections between the client and the server
• Stream dependencies: the client can indicate to the server which of the resources are more important than the others
• Header compression: HTTP header size is drastically reduced
• Server push: The server can send resources the client has not yet requested
Header compression, so that the normal request and response headers don’t dominate your bandwidth — even if what you’re requesting is very small, will be a huge win on mobile, where getting big request headers can easily blow out the load time of a page with a lot of resources by several round trips. You can read more about this HTTP/2 by googling “Http/2”.