HTTP vs HTTPS: The Difference Between HTTP and HTTPS

Do you pay attention to whether the URL of the website you are visiting starts with HTTP or HTTPS in your browser's address bar? If not, you should definitely do so in the future, especially when you enter your personal information or make online payments with your credit card. All that matters then is HTTPS in the URL!

The team here at KeyCDN always encourages people to move to HTTPS for several reasons, such as performance benefits, additional security, and even SEO advantages. We are constantly throwing around the HTTP and HTTPS acronyms, and sometimes it's important to understand the basics of how they work and some history behind them. So today, we thought we would explore the difference between HTTP and HTTPS, what they mean, and why it might be time for you to move to HTTPS.

What is HTTP?

HTTP stands for Hypertext Transfer Protocol. It is a protocol used by a client and server that allows you to communicate with other websites. 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. The client sends a request message to an HTTP server (after the TCP handshake) that 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 was first defined in 1974, RFC 675. HTTP also uses UDP (User Datagram Protocol), designed by David Reed in 1980 and 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 have been some slight revisions to HTTP/1.1. In 1999, RFC 2616 introduced five new methods, OPTIONS, PUT, TRACE, CONNECT and DELETE. And then, in March 2010, RFC 5789 introduced the PATCH method.

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) was also added.

If there is a problem with an HTTP request, there is a list of status codes that inform your browser so that you can better troubleshoot what the problem might be. The user agent handles the response depending on the code and the response header fields. For example, a 404 Not Found error means 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 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 May 2022, 54.5% of the Internet's 135,302 most popular websites have a secure implementation of HTTPS.

- SSL Pulse

Remember Netscape? Well, HTTPS was created by Netscape Communications back in 1994 to use in its Netscape Navigator web browser. HTTPS initially used the SSL protocol, which eventually evolved into TLS, the current version defined in RFC 2818 in May 2000. You might hear the terms SSL and TLS threw 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 98% 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, nothing is passing in plain text. Many 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

SPDY (pronounced SPeeDY) is a network protocol designed by Google to make the web faster. It was originally announced back in 2009. SPDY requires SSL/TLS (with TLS extension ALPN) for security, but it also supports operation over plain TCP.

The three main benefits were:

1. Allows client and server to compress request and response headers, which reduces bandwidth usage when similar headers (e.g. X-Cache) are sent repeatedly for multiple requests.
2. Allows multiple requests over a single connection and therefore save on round trips between client and server. Further, preventing low priority assets from delaying higher priority requests.
3. 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 would no longer support SPDY in favor of HTTP/2.

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 May 2022 46.3% of all the 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 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 are no longer needed with HTTP/2.
• Addresses the head of line blocking problem in HTTP/1.1.

More and more brands and websites have switched to HTTP/2. You can use KeyCDN's HTTP/2 test tool to check if your current server or CDN provider supports HTTP/2.

"As of this morning, https://t.co/Bv0erJiH66 supports HTTP/2. Tested by https://t.co/mykDE06rEv #http2 #webperf"

- Wikipedia (@Wikipedia) May 4, 2016

KeyCDN has supported HTTP/2 across all of its edge servers for customers since October 2015.

HTTP/3

HTTP/3 will be the first major update to the hypertext transfer protocol. HTTP/3 differs from HTTP/2 in that it runs on a new transport protocol called QUIC.

Google developed the QUIC protocol in 2012 for mobile Internet use. This was necessary because when the first Internet protocols were developed, devices were much less mobile and not like today, where everyone carries their smartphone and switches from one network to another.

The use of QUIC means that HTTP/3 relies on the connectionless User Datagram Protocol (UDP) rather than Transmission Control Protocol (TCP). When surfing online, switching to UDP allows for faster connections and a faster user experience.

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.

1. HTTP URL in your browser's address bar is http://, and the HTTPS URL is https://.
2. HTTP is unsecured while HTTPS is secured.
3. HTTP sends data over port 80 while HTTPS uses port 443.
4. HTTP operates at application layer, while HTTPS operates at transport layer.
5. No SSL certificates are required for HTTP; with HTTPS, it is required that you have an SSL certificate and a CA signs it.
6. HTTP doesn't require domain validation, whereas HTTPS requires at least domain validation and certain certificates even require legal document validation.
7. There is no encryption in HTTP; with HTTPS, the data is encrypted before sending.

Summary

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 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.