How often do you look at the URL in your browser's address bar to see if it starts with HTTP or HTTPS? In the future, make sure you enter your personal information or make online payments with your credit card securely if you haven't already. The URL must be HTTPS!
We at AgileCDN always encourage people to move to HTTPS because of the performance advantages, additional security, and even SEO advantages. Sometimes it is important to understand the basics of HTTP and HTTPS acronyms, as well as their history. Today, we will discuss HTTP and HTTPS, their differences, and why it might be time to move to HTTPS.
HTTP: How Does It Work?
Hypertext Transfer Protocol is an acronym for Hypertext Transfer Protocol. Communication between a client and a server is enabled by this protocol. When you enter http:// in your address bar before the domain, your browser will connect over HTTP. Data packets are sent and received via HTTP using TCP (Transmission Control Protocol), generally over port 80. Following a TCP handshake, a client sends a request message to an HTTP server that hosts a website. HTTP/1.1 200 OK is an example of a completion status message included in the response.
There have been enhancements to CP over the years, but for the most part, it remains the same as when it was first defined in 1974, RFC 675. Besides HTTP, RFC 768 defines UDP (User Datagram Protocol), which was designed by David Reed in 1980. Streaming, video games, and video conferencing use this technology. It is less reliable, however. In order to improve performance, it allows individual packets to be dropped and received in a different order.
It was Ted Nelson in 1965 who coined the term hypertext. W3C's director Tim Berners-Lee developed and suggested the original HTTP protocol. In order to ensure the long-term growth of the web, the W3C develops protocols and guidelines that lead the web to its full potential.
GET (requests data from a specified resource) was the first HTTP request method documented in 1991, which was HTTP/0.9. HTTP 1.0, RFC 1945, was released in 1996, providing three HTTP request methods: GET, HEAD, and POST (submits data to a specified resource for processing). A revision of HTTP 1.0, HTTP/1.1, was developed in 1997, and it is still used today for all HTTP requests after 19 years.
HTTP/1.1 has undergone some slight revisions over the years. A new set of five methods was introduced in RFC 2616 in 1999: OPTIONS, PUT, TRACE, CONNECT and DELETE. After that, PATCH was introduced in March 2010 by RFC 5789.
The connection was closed after a single request in HTTP/0.9 and 1.0. As of HTTP/1.1, persisted connections (more than one request and response on the same connection) were introduced, resulting in a drastic reduction in latency. In addition, CORS, caching, and better compression support were added.
There is a list of HTTP status codes that inform your browser if there are problems with an HTTP request. According to the code and the response header fields, the user agent handles the response. For example, a 404 Not Found error means the content either does not exist or has been moved. A 502 Bad Gateway error can also indicate that a domain name is resolving to the wrong IP address or none at all.
HTTPS: What Is It?
HTTPS is short for Hypertext Transfer Protocol Secure (also called HTTP over TLS or HTTP over SSL). If you type https:// in the address bar before a domain, the browser will use HTTPS to connect. The majority of sites using HTTPS will have a redirect in place, so even if you enter http://, you will be redirected over a secure connection. Data packets are also sent and received using TCP over port 443 via a Transport Layer Security (TLS) encrypted connection over HTTPS.
Have you heard of Netscape? Originally designed for Netscape Navigator's web browser, HTTPS was created by Netscape Communications in 1994. SSL was initially used for HTTPS, but evolved into TLS in May 2000 as defined by RFC 2818. A lot of people tend to use the terms SSL and TLS interchangeably.
An encrypted connection ensures the security of HTTPS's data transmission. It works by using a public key which is decrypted by the recipient. SSL certificates include the public key deployed on the server. Every browser implicitly trusts a list of Certificate Authorities (CA) that cryptographically sign certificates. The browser displays a green padlock in the address bar for any certificate signed by a trusted CA because it's proven to be "trusted" and belongs to that domain. There are now companies that offer free SSL certificates, such as Let's Encrypt.
In a previous post, we discussed why your business needs SSL trust. 98% of shoppers look for the green address bar while 84% abandon a purchase if data is sent over an unsecured connection. Credit card information should never be entered on websites that operate over HTTP. In addition to security, HTTPS is used for privacy purposes as well. Encryption prevents plain text transmission of data. On small sites, like a blog, some people might question whether HTTPS is really necessary, but don't forget to encrypt your login page as well.
SPDY
In order to make the web faster, Google designed SPDY (pronounced SPeeDY). As far back as 2009, it was originally announced. To ensure security, SPDY requires SSL/TLS (with TLS extension ALPN), but also supports plain TCP.
Three main benefits were:
1.When similar headers (e.g. X-Cache) are sent for multiple requests, the client and server can compress them, reducing bandwidth usage.
2. Allows multiple requests to be sent over a single connection, reducing the number of round trips between the client and server. Additionally, low priority assets should not delay higher priority requests.
3.Enables the server to proactively push assets to the client (e.g., CSS and images) without waiting for the client to request them.
Compare HTTP/1.1 with SPDY 3.1. As of February 11, 2016, Chrome will no longer support SPDY in favor of HTTP/2.
HTTP/2
A protocol update to HTTP/1.1 is HTTP/2, which is based on SPDY. IETF's HTTP Working Group developed it, and RFC 7540 defines it. Currently, HTTPS is required in order to use HTTP/2 because browsers support it. You can read about the differences between SPDY3.1 and HTTP/2 here.
HTTP/2 offers the following benefits:
- In contrast to HTTP, HTTP/2 uses binary data instead of text.
- The data is fully multiplexed instead of ordered and blocked.
- By increasing speed without optimizing, you can reduce additional round trip times (RTT).
- Parallelism can be accomplished using one connection.
- The headers are compressed using HPACK compression and Huffman encoding.
- Instead of waiting for each resource request, servers "push" responses into client caches proactively.
- As the ALPN extension determines the application protocol during the initial connection, faster-encrypted connections are possible.
- With HTTP/2, domain sharding and asset concatenation are no longer necessary.
- In HTTP/1.1, this fixes the problem of head of line blocking.
Increasingly, brands and websites are switching to HTTP/2. If your current CDN or server does not support HTTP/2, you can use AgileCDN's HTTP/2 test tool.
HTTP/3
The hypertext transfer protocol will undergo its first major update with HTTP/3. In contrast to HTTP/2, HTTP/3 uses a new transport protocol called QUIC.
The QUIC protocol was developed by Google in 2012 for use on mobile devices. During the development of the first Internet protocols, devices were much less mobile, not like today, with everyone carrying a smartphone and switching from one network to another.
In HTTP/3, QUIC replaces Transmission Control Protocol (TCP) with User Datagram Protocol (UDP). You will experience faster connections and a better online experience by switching to UDP when surfing online.
HTTP vs HTTPS: what's the difference?
These are some of the main differences between HTTP and HTTPS, in no particular order.
There is a difference between HTTP and HTTPS URLs in your browser's address bar.
In contrast to HTTPS, HTTP is an unsecured protocol.
Data is sent over port 80 via HTTP, whereas data is sent over port 443 via HTTPS.
HTTP operates at the application layer, while HTTPS operates at the transport layer.
HTTP does not require SSL certificates; HTTPS requires a CA-signed SSL certificate.
HTTP doesn't require domain validation, but HTTPS does, and some certificates even require legal document validation.
The data is not encrypted in HTTP; it is encrypted with HTTPS.
In summary
If you have not switched over to HTTPS yet, we highly encourage you to do so. As long as people are running over HTTP/2, TLS negotiation and CPU overhead are now very minimal, and in many tests, switching from HTTP to HTTPS results in faster performance. We also have a guide on how to migrate from HTTP to HTTPS. In case you haven't had time to migrate your origin server yet, you can deploy AgileCDN assets over HTTPS.