Understand how Web and Your Browser Works!

Isn’t it wonderful how the whole technology is working around us? I mean, whenever we connected to a WiFi we can open up the browser and type all sorts of webpages that do all kinds of stuff. But how is this whole thing work? I think it’s worth spending a few minutes to understand the underlying infrastructure and general working principles. In this post, I will go through all the interesting bits and pieces of the web and show you a few things you can try out in the browser right now! So you can take this as your how websites work tutorial!

What is a Server?

I’m pretty sure you hear the term server all around the place. Let’s understand that first! Server can be any kind of computer. Your laptop or even a raspberry pi, but in the industry, it’s most often a rackmount computer. It’s usually running a Linux operating system and only accessible via some network connection (no monitor/keyboard is needed). But by definition, the server must “serve” something. It can be a website, a game server, chat server or any other thing. These are all just applications you can install and call it a day. So basically, as a bare minimum, you can pick an old pc, host a game server on it, (maybe install Nginx which can serve your website), Propagate your IP address to the internet, never turn off the pc, and you have a server. Based on the setup various clients can connect to you in various protocols.

These clients can discover the server via its IP address. This address can change though! Let’s see a technology that fixes this issue! It’s called DNS.

What’s DNS?

DNS stands for Domain Name System. It acts like a phonebook. You type in your browser a website name, like https://thelearningchamber.com and it will ask around higher and higher if someone knows what’s the IP for this domain. It starts on your pc (localhost), yes Windows and Linux both have their own little DNS. It’s a file in

Windows C:\Windows\System32\drivers\etc\hosts

Mac /private/etc/hosts

Linux /etc/hosts

If these files contain no information about the whereabouts of the domain we are looking for, it proceeds and asks higher. The router may contain such information. If not, there is an external public DNS server set in the router. So it will continually ask for the IP address on 1.1.1.1 (It’s a public DNS server) or 8.8.8.8 (google’s DNS server) or OpenDNS etc… It’s usually the last step. If the domain name does not exist on these DNS servers, your browser will show you the infamous code 404 not-found page!

If you want your server visible under a domain, you must purchase a domain name from a domain authority, and report it to the major DNS servers. It will propagate through and soon your site will be available on the internet!

You can even create your very own DNS server with relative ease! There is a project called PiHole, which allows you to have a private DNS server that blocks most of the advertisement addresses, so you will have fewer ads while browsing. If you are interested in such a project, it’s super easy to set it up in Docker on your raspberry PI. (We have a tutorial on docker here!)

HTTP Protocol

Okay, we know the IP address of the wanted server. Now what? Let’s ask something from the server with the probably most used protocol, HTTP. It stands for Hyper Text Transfer Protocol and it was introduced in 1991 by CERN. Web browsers build around this protocol. All they do is ask a server in HTTP, take the response and try to show it to you.

Inspect an average call closer. The browser calls https://thelearningchamber.com/about/ . This means the following:

The browser makes a GET type HTTP request to the server thelearningchamber.com’s port 443 (default secure https://xy port for calls). This request contains information in many places. There is information in the URL itself, /about/. There is information in parameters called headers. These headers are sent by the browser all the time, with information like whether are you desktop or mobile, what’s your OS, browser etc… There are also cookies in the browser which are visible to the server.

Based on all of this information the server gives you a response with a response code and usually some content. This could be many things, but most likely it will be a piece of HTML code, CSS code, Javascript code and assets like files, images etc. with response code 200 (which means all good). These things are rendered as a full website on the client’s browser.

Let’s inspect a slightly different tricky call. Let’s call http://thelearningchamber.com/about/ this time. Notice that it’s HTTP instead of HTTPS. Now it means calling port 80 instead of 443. Port 80 is usually insecure so the server won’t respond with content (it can be stolen due to the insecure channel) rather it will respond with code 302 or 304 and with a new URL in the response. this commands the browser to navigate to a different URL. So if you navigate to http://site it’s usually built the way to redirect you to the secure version of the same site on https://site.

The interesting part is that you can inspect this kind of communication in the browser itself. If you press F12 it will bring up the developer’s console in any browser and you can take a look at this kind of communication in the network tab.

I already mentioned GET-type requests. It’s worth mentioning that there are a few other types of these requests that exist. There are POST, PUT and DELETE etc. type operations, but they are less frequently used, especially when the server responds with a full webpage.

Building Blocks of a Webpage

I mentioned previously that the browser can understand HTML, CSS and Javascript formats. These are standards and all of the browsers will understand them, and they will know what to show. Let’s discuss them, how they work and what they look like. The good thing is, it is really easy to try this out, probably most of you already learned about it in IT class. If you create a simple text file with the extension of .html and open it with a browser, will make the browser render the HTML file. Don’t be confused with the extension itself, we can put Javascript, CSS and HTML in the same file for the sake of the example (in reality they are separated of course).

Let’s create an index.html file and copy this basic skeleton in it:

<!DOCTYPE html>
<html>
  <head>
    <!-- In the head we can store all kind of information about the page  -->
    
    <!-- CSS Goes here -->
    <style>
    p {
      box-shadow: 0 0 0 3px red;
    }
    </style>
    <!-- Title of the page -->
    <title>My Page</title>
    <!-- Meta infos, like keywords for search engines -->
    <meta name = "keywords" content = "me,webpage,first">
  </head>

  <body>
    <!-- Body: Here goes the page itself -->
    <h1>A big title</h1>
    <p>A paragraph</p>

    <!-- we can write javascript here too -->
    <p id="scriptdemo"></p>
    <script>
      document.getElementById("scriptdemo").innerHTML = "From Javascript: " + (2 + 3);
    </script>
  </body>
</html>

On opening this script in the browser, we should see something like this:

Believe it or not, all of the webpages are built from HTML, CSS and Javascript! You can inspect them in the browser in the developer menu (F12)!

Modern WebApps

I briefly mentioned that the server does not always respond with a “full webpage”. What else could be the case?

So first, All we discussed so far is good and all, but if you think about it, a complex webpage might not give you the best experience. Every time we click on a button on the site, it will result in a new request to the server and will give a completely new view in the response, so the whole site will refresh. To eliminate this, we can create much smarter applications as frontend and run them on the browser. Imagine a javascript-heavy application running in your browser, which just queries the posts or chat messages from the server (backend), not always the whole website. So we load the website with the first request, but the rest of the communication is only data, not HTML. The rendering is done dynamically via the application running in the frontend. Some technologies that are using this approach are Angular, React, VueJs.

Cookies 🍪

There is another problem we should encounter at this point. Between two refreshes, we lose all of the progress on the page. For example, you type in something, or you set a value in a dropdown and on refresh, everything sets back to default. It is a completely new website after all from the browser’s perspective. The technology we can utilize to save states between site visits (User tokens for login as well) are the cookies. A webpage can set a cookie in your browser, and the value of this cookie will remain the same between refreshes. Keep in mind that this cookie will be only accessible to this very domain you run your website under, this is the same origin policy. However! Sites can embed some code from 3d party places into the site (from google for example) and this code can place its own cookies in the browser and they will fall under the 3d party domain. This means every site which has the same code embedded, can have the same cookie jar, and google can detect based on these cookies where you have been. Your cookies basically can store some of your internet histories which can come in handy for advertisement/tracking reasons. If you browsed some baby-related sites, advertisements might show you baby goods. You can also check these cookies are in the browser how they look, and easily block them with extensions if you are privacy conscious!

I hope now you have a basic understanding of how the net/websites work around you! Remember, keep learning