In our last post, we discussed the history of the internet. We think of the internet as a way to browse the web, but it is much more than that. It allows us to share data in a fast and reliable way. It was only in 1990 that the “web” as we know it today was invented. There were other applications that used the internet long before the first commercial browser was invented. Among the most popular internet applications is electronic mail, a.k.a. e-mail.

The email was introduced in 1971 on the ARPANET network, but it can be used on other networks as well. In essence, email is a set of rules created to make sure messages can be sent and received to one or more email addresses and to make sure they can be displayed on computers. The rules defined the syntax and semantics of messages, email addresses, and more. This set of rules is known as a protocol. There are mainly three protocols used for email messages today - SMTP, IMAP, and POP3 and we might explore some of them in a future post.

In the same way that email is built from different protocols, the web uses different protocols as well. In 1989, Tim Berners-Lee and a group of scientists at CERN developed HTTP (Hypertext Transfer Protocol) - the protocol that serves as the basis for the World Wide Web. As mentioned in our previous post, TCP/IP is a protocol that ensures reliable end-to-end communication. HTTP is an application-layer protocol that relies on TCP/IP as its foundation.

In order to understand HTTP, we must first explain what a website is. A website is essentially a collection of HTML-formatted text pages. In order to navigate between these pages, URL addresses can be used to locate other resources such as other pages or images. With the development of other technologies, audio and video can now be embedded within a website, CSS can be used to style the website, and JavaScript can be used to make the website dynamic.

Let’s go back to HTTP. Currently, HTTP/1.1 (version 1.1) and HTTP/2 are the most commonly used HTTP versions. However, HTTP/3 is in draft form. We won’t cover all the details of the protocol in this series, but there are a few things you should know. Let’s begin by defining which parties are involved in the HTTP protocol. The application that serves HTML, CSS, and images is called a “web server”. Web servers are usually installed on dedicated machines. Their task is to receive requests from other nodes and respond to these requests with responses containing all the information they requested. The most common way to send these requests is through your web browser. When we enter a URL, the web browser handles the request syntax, waits for the response, and displays it to us in a meaningful way. We often refer to web servers as “servers” and web browsers as “clients”.

In addition to HTTP, we should also mention HTTPS. HTTPS is an extension of the HTTP protocol that makes communication secure (the “s” stands for “secure”). In HTTPS, the requests and responses between the client and server are encrypted, so people who try to read the traffic cannot read them. Imagine you’re logging into your bank’s website using a login form. Without HTTPS, the username and password will appear in plain text on the request and could be retrieved. It is especially dangerous in cafes and airports where people can connect to the same WiFi network and read your requests. Even though we’re building a landing page, not a login form, you still need to encrypt user data. Why? In the future, you might add a form to subscribe to your newsletter, and your users’ details should be encrypted. Additionally, a website using HTTP might also be considered not secured by Google, which can negatively affect your ranking in search results. The process of setting up HTTPS on our website will be as simple as clicking a button, but if you are running a dedicated server, it might be more complicated.

Modern browsers support HTTPS, and you can tell if a website is secured by looking at the lock next to the URL in the address bar.

Secured:

Not secured:

Encryption and decryption are handled at lower levels, so you don’t need to worry about actually encrypting data. HTTPS encrypts almost everything in a request. However, it’s still possible to get your domain name and the IP address from an HTTP request, so be careful when visiting shady websites. In our next post, we’ll explore how these requests and responses look. We’ll also explore how we can find out what information is sent and received when we browse the web.

Fun fact - the first website is still up and running. It describes the World Wide Web project.