What is the Difference Between HTTP and HTTPS?
The team here at KeyCDN is always encouraging people to make the move to HTTPS for a number of reasons such as performance benefits, additional security, and even SEO advantages. We are constantly throwing around the HTTP and HTTPS acronyms and sometimes its important to understand the basics of how they work and some history behind them. So today we thought we would explore more in-depth the difference between HTTP and HTTPS, what they mean, and why it might be time for you to make the move to HTTPS.
What is HTTP?
HTTP stands for Hypertext Transfer Protocol. When you enter
http:// in your address bar in front of the domain, it tells the browser to connect over HTTP. HTTP uses TCP (Transmission Control Protocol), generally over port 80, to send and receive data packets over the web. To put it simply it is a protocol that’s used by a client and server which allows you to communicate with other websites. The client sends a request message to an HTTP server (after the TCP handshake) which hosts a website, the server then replies with the response message. The response message contains completion status information, such as “HTTP/1.1 200 OK”.
TCP has had enhancements over the years but for the most part is very much the same as it was when it first defined in 1974, RFC 675. HTTP also uses UDP (User Datagram Protocol), designed by David Reed in 1980, defined in RFC 768. It is less reliable but widely used in video conferencing, video games, and streaming. It allows individual packets to be dropped and received in a different order for better performance.
The term hypertext originally came from Ted Nelson in 1965. The original HTTP was developed and originally proposed by Tim Berners-Lee, the director of the World Wide Web Consortium (W3C). The W3C’s mission is to lead the web to its full potential by developing protocols and guidelines that ensure the long-term growth of the web.
There was a time when people felt the internet was another world, but now people realize it’s a tool that we use in this world. - Tim Berners-Lee
The first documentation of HTTP was published in 1991 as HTTP/0.9 which only consisted of one HTTP request method, GET (requests data from a specified resource). In 1996 HTTP 1.0, RFC 1945, was developed and this consisted of three HTTP request methods, GET, HEAD, and POST (submits data to be processed to a specified resource). Finally in 1997, the HTTP/1.1 protocol, RFC 2068, was developed as a revision of HTTP 1.0 and after 19 years it is still used today for all HTTP requests.
Over the years there are have been some slight revisions to HTTP/1.1. In 1999, RFC 2616 introduced 5 new methods, OPTIONS, PUT, TRACE, CONNECT, and DELETE. And then in March 2010, RFC 5789 introduced the PATCH method. As of today the current version defines 9 different request methods.
In HTTP/0.9 and 1.0 the connection was closed after a single request. In HTTP/1.1 persisted connections (more than one request/response on the same HTTP connection) were introduced, which dramatically reduced latency. Other improvements such as caching, better compression support, and Cross-Origin Resource Sharing (CORS) were also added.
If there is a problem with an HTTP request there is a list of status codes which inform your browser so that you can better troubleshoot what the problem might be. The way the user-agent handles the response depends upon the code and the response header fields. For example, a “404 Not Found” error means the the content either does not exist or has been moved. Or another common example is a “502 Bad Gateway” error which could mean that the domain name is not resolving to the correct IP or it does not resolve to any IP.
What is HTTPS?
HTTPS stands for Hypertext Transfer Protocol Secure (also referred to as HTTP over TLS or HTTP over SSL). When you enter
https:// in your address bar in front of the domain, it tells the browser to connect over HTTPS. Generally sites running over HTTPS will have a redirect in place so even if you type in
http:// it will redirect to deliver over a secured connection. HTTPS also uses TCP (Transmission Control Protocol) to send and receive data packets, but it does so over port 443, within a connection encrypted by Transport Layer Security (TLS).
As of April 2016, 41.7% of the Internet’s 141,160 most popular websites have a secure implementation of HTTPS. - SSL Pulse
Remember Nestcape? Well HTTPS was actually created by Netscape Communications back in 1994 to use in its Netscape Navigator web browser. HTTPS originally used the SSL protocol which eventually evolved into TLS, the current version defined in RFC 2818 in May 2000. That is why you might hear the terms SSl and TLS thrown around quite loosely.
HTTPS transmits its data security using an encrypted connection. Basically it uses a public key which is then decrypted on the recipient side. The public key is deployed on the server, and included in what you know as an SSL certificate. The certificates are cryptographically signed by a Certificate Authority (CA), and each browser has a list of CAs it implicitly trusts. Any certificate signed by a CA in the trusted list is given a green padlock lock in the browser’s address bar, because it’s proven to be “trusted” and belongs to that domain. Companies like Let’s Encrypt have now made the process of issuing SSL certificates free.
We wrote a post a while back on why you should be establishing SSL trust for your business. According to a GlobalSign survey, 84% of shoppers abandon a purchase if data was sent over an unsecured connection and 28.9% look for the green address bar. Never enter your credit card details on websites that run over HTTP. The main purpose of using HTTPS is for security and privacy reasons. When the data is encrypted this means nothing is passing in plain text. A lot of people might question whether they need to bother with HTTPS on smaller sites, like a blog, but remember even your login page should be encrypted.
SPDY (pronounced SPeeDY) is a network protocol that was designed by Google with the aim to make the web faster. It was originally announced back in 2009. SPDY requires the use of SSL/TLS (with TLS extension ALPN) for security but it also supports operation over plain TCP.
The 3 main benefits were:
- Allows client and server to compress request and response headers, which reduces bandwidth usage when the similar headers (e.g. X-Cache) are sent over and over again for multiple requests.
- Allows multiple requests over a single connection and therefore saving on round trips between client and server. Further, preventing low-priority assets from delaying higher-priority requests.
- Enables the server to proactively push assets to the client that it knows the client will require (e.g. CSS and images) without waiting for the client to request them.
Check out the difference between HTTP/1.1 and SPDY 3.1. However, on February 11, 2016, Google announced that Chrome will no longer support SPDY in favor of HTTP/2.
HTTP/2 is the protocol update to HTTP/1.1 and is based on SPDY. It was developed by the IETF’s HTTP Working Group, published in May 2015 and defined in RFC 7540. Because of browser support for HTTP/2, HTTPS is currently required to take advantage of it. Read about the difference between SPDY3.1 and HTTP/2.
As of April 2016 7.3% of the top 10 million websites support HTTP/2. - W3Techs
Here are some of the benefits of HTTP/2:
- HTTP/2 is binary, instead of textual
- It is fully multiplexed, instead of ordered and blocking
- Speed increase reduces additional round trip times (RTT), making your website load faster without any optimization.
- It can use one connection for parallelism
- It uses HPACK compression with Huffman encoding to reduce headers
- It allows servers to “push” responses proactively into client caches instead of waiting for a new request for each resource
- The new ALPN extension allows faster-encrypted connections since the application protocol is determined during the initial connection.
- Domain sharding and asset concatenation is no longer needed with HTTP/2.
- Addresses the head of line blocking problem in HTTP/1.1.
More and more bigger brands and sites are now making the move to HTTP/2, such as Wikipedia this week. You can use KeyCDN’s HTTP/2 test tool to check if your current server or CDN provider support HTTP/2.
KeyCDN has supported HTTP/2 across all of its edge servers for customers since October 2015.
What is the Difference Between HTTP and HTTPS?
Below are some of the main differences between the HTTP and HTTPS protocols, in no particular order.
- HTTP URL in your browser’s address bar is
http://and the HTTPS URL is
- HTTP is unsecured while HTTPS is secured.
- HTTP sends data over port 80 while HTTPS uses port 443.
- HTTP operates at application layer, while HTTPS operates at transport layer.
- No SSL certificates are required for HTTP, with HTTPS it is required that you have an SSL certificate and it is signed by a CA.
- HTTP doesn’t require domain validation, where as HTTPS requires at least domain validation and certain certificates even require legal document validation.
- No encryption in HTTP, with HTTPS the data is encrypted before sending.
We highly encourage you to think about switching over to HTTPS. The TLS negotiation and CPU overhead are now very negligible and in a lot of tests we have seen performance improvements when people make the switch from HTTP to HTTPS, as long as they are running over HTTP/2. Make sure to also check out our HTTP to HTTPS migration guide. And don’t forget, you can deploy KeyCDN assets over HTTPS, even if you haven’t had time to migrate your origin server yet.