Difference and performance between HTTP and HTTPS

Lot of people end up getting confused when they see two different URL’s one as HTTP and other as HTTPS. So what is the difference between these two? In this post I will discuss the evolution of HTTP and the difference between HTTP and HTTPS in simple term so that it makes sense quite easily. 

What is HTTP

It is always necessary to know something about basics before going to the advanced topics. HTTP stands for HyperText Transfer Protocol. It is the system for transmitting and receiving information across server and the client. The Server is the machine where your website code is placed and client is nothing but your browser. HTTP manages the mutual understanding between server and the client to exchange information or data successfully. The first HTTP had only one method called as GET, which would request a page from server and the response was a HTML page. The latest version of HTTP defines nine request methods.

If you visit any website you may see the address gets prefixed with HTTP:// this means your browser is now connected to the server using HTTP. Now the HTTP isn’t the safest way to establish a connection, the problem with http though is that it is vulnerable to people who might want to eavesdrop or see what your activity is all about.

his shouldn’t be any concern when you are just browsing any website or just Bing’ing, the problem comes when you are making a financial transaction over Internet. As we all know, Internet is not exactly a safe place. Apart from searching and browsing websites, we need to engage in money transactions, online purchases and secure file transfers. So how do we secure such financial transactions? The answer is HTTPS.

What is HTTPS

HTTPS or Secure HTTP some may call it is a combination of Hypertext Transfer Protocol (HTTP) with SSL/TLS protocol. Now everything you communicate over HTTPS will be sent and received in encrypted form, which adds the element of safety.

As when a client makes a request to the server, the server responds by offering a list of encryption methods. When the client connects to a website via HTTPS, the website encrypts the session with a digital certificate. Secure Sockets Layer or SSL uses a cryptographic system that encrypts data with two keys that is browser and server send each other unique codes which are used for encryption for rest of the talk.

Https is used in many situations, such as log-in pages for banking, forms, corporate logins, and other applications in which data needs to be secured. It is always advised to never enter credit card details on websites that run on HTTP.

Difference between HTTP and HTTPS

1)            In case of HTTP URL begins with “HTTP://” and for HTTPS connection it is “HTTPS://”

2)            HTTP is unsecured on other hand HTTPS is secured.

3)            HTTP uses port 80 for communication unlike HTTPS which uses port 443

4)            No certificates required for validation in case of HTTP. HTTPS requires SSL Digital Certificate

5)            No encryption in HTTP; Data encrypted before sending and receiving in HTTPS.

Hope this has cleared the difference between HTTP and HTTPS. If you have any questions or observations to make, please do comment.

HTTP vs HTTPS performance

 Profile the performance of your web server to see what the performance penalty is for your particular situation. There are several tools out there to compare the performance of an HTTP vs HTTPS server (JMeter and Visual Studio come to mind) and they are quite easy to use.

No one can give you a meaningful answer without some information about the nature of your web site, hardware, software, and network configuration.

As others have said, there will be some level of overhead due to encryption, but it is highly dependent on:

• Hardware
• Server software
• Ratio of dynamic vs static content
• Client distance to server
• Typical session length
• Etc (my personal favorite)
• Caching behavior of clients

In my experience, servers that are heavy on dynamic content tend to be impacted less by HTTPS because the time spent encrypting (SSL-overhead) is insignificant compared to content generation time.

Servers that are heavy on serving a fairly small set of static pages that can easily be cached in memory suffer from a much higher overhead (in one case, throughput was halved on an "intranet").

One point that has been brought up by several others is that SSL handshaking is the major cost of HTTPS. That is correct, which is why "typical session length" and "caching behavior of clients" are important.

Many, very short sessions means that handshaking time will overwhelm any other performance factors. Longer sessions will mean the handshaking cost will be incurred at the start of the session, but subsequent requests will have relatively low overhead.

Client caching can be done at several steps, anywhere from a large-scale proxy server down to the individual browser cache. Generally HTTPS content will not be cached in a shared cache (though a few proxy servers can exploit a man-in-the-middle type behavior to achieve this). Many browsers cache HTTPS content for the current session and often times across sessions. The impact the not-caching or less caching means clients will retrieve the same content more frequently. This results in more requests and bandwidth to service the same number of users.

HTTPS requires an initial handshake which can be very slow. The actual amount of data transferred as part of the handshake isn't huge (under 5 kB typically), but for very small requests, this can be quite a bit of overhead. However, once the handshake is done, a very fast form of symmetric encryption is used, so the overhead there is minimal. Bottom line: making lots of short requests over HTTPS will be quite a bit slower than HTTP, but if you transfer a lot of data in a single request, the difference will be insignificant.

However, keepalive is the default behaviour in HTTP/1.1, so you will do a single handshake and then lots of requests over the same connection. This makes a significant difference for HTTPS. You should probably profile your site (as others have suggested) to make sure, but I suspect that the performance difference will not be noticeable.