What happens when you type a URL in a browser and hit enter

Betcha didn’t know how much work is involved when you watch cat videos on the internet :)

Topics covered:

• DNS Lookup
• TCP/IP model
• HTTP(S)/SSL/TLS/HSTS
• Server side: Firewall, Load Balancer, Web Server, Application Server, Database

The internet is made up of a network of computers connected to each other. In order to connect and communicate between computers, they must follow a set of rules, Internet Protocol(IP), that govern how data is transmitted over a network. Every machine on the web has a unique identifier to distinguish from one another. It’s similar to having a telephone number or a physical address.

A typical IP address(IPv4) follows the format of 4 sets of numbers between 0–255. xxx.xxx.xxx.xxx.

There are a total of 4,294,967,296 IPv4 addresses available and 340,282,366,920,938,463,463,374,607,431,768,211,456 possible IPV6 addresses. Having to look for the IP address when you want to visit a webpage will take a lifetime. So we just type in the domain name we’re familiar with and let the magical system that is the DNS do its thing and take care of the rest :)

But before we move forward, the browser will first check whether our specified domain(www.holbertonschool.com) is in its HSTS preload list. We will be required to communicate securely through HTTPS if our domain is in that list. We’ll go over about HSTS and HTTPS soon.

Domain Name System(DNS)

The Domain Name System is created to keep track of IP addresses for us so we can enter human-readable addresses in our browser’s URL bar instead.

To resolve a domain name = to translate from domain name to its IP address.

When you type www.holbertonschool.com in your web browser and hit enter, the request will be forwarded to a DNS server. DNS server will then perform a DNS lookup to locate the corresponding IP address.

DNS uses a client/server architecture and the DNS servers are organized in a hierarchical and distributed fashion. It really just means we the users are the clients requesting some kind of information from a computer somewhere that will serve us what we asked for. And the route in which we take will look similar to an upside down tree-like structure. More on these later.

root->.com(TLD)->holbertonschool.com

Steps to resolving a domain name:

TL;DR — DNS servers translate human readable URL to it’s IP address. If local DNS server doesn’t know the IP address, it will ask others DNS servers systematically until it reaches someone who has the IP address or it will get an error if the website doesn’t exist.

1. Web browser and OS will first check whether the domain is in their cache. If you’ve been to the webpage recently, your browser might already know the IP address and the search will end here. Otherwise, we shall continue.
2. The web browser then will send a request to a DNS resolver. A DNS resolver is a local server with a central database of DNS nameservers. For most, DNS resolvers are hosted by a user’s Internet Service Provider (ISP). The resolver will first check its cache. If the IP address for holbertonschool.com isn’t in its cache, it will (3)forward the query recursively up the to the root servers, (4)down to the Top Level Domain (TLD) of holbertonschool.com( .com would be the TLD in this case), and then (5)down to the authoritative name servers responsible for www.holbertonschool.com.
3. So earlier we talked about how the DNS system is organized in an upside down tree-like structure. We will go to the top and search downward. First stop is the root servers. Root servers respond with address to the .com Top-Level Domain(TLD). Top-level domain just refers to the last chunk of a domain name after the dot symbol. Our TLD here is .com, but other examples are .org, .edu, .gov, etc.
4. The resolver then queries .com servers for the authoritative name servers of our domain, holbertonschool.com. The authoritative name servers are the ones with the answer to our search. They hold the actual DNS records and will provide the IP address of our query.
5. So now the resolver will be able to query the authoritative name servers. Holbertonschool.com’s authoritative name servers contain all DNS records within the domain.
6. Authoritative name servers will respond with the corresponding IP address of www.holbertonschool.com, allowing the local DNS servers to pass along to the user. But first, it will save this IP to its cache. Caching every step of the way!
7. The user’s operating system will also cache this IP address for reference in the future.
8. The user’s web browser can now follow HTTP protocol and send a GET request to the server at holbertonschool.com’s corresponding IP address.

Client sends GET request and waits for server to respond when request is completed

Redundancy: There are multiple DNS servers at each level. Having redundancy ensures requests will still be processed if one of the servers fail.

Client — Server:
Machines used to serve other machines are called servers and machines used to request service are called clients.

TCP Model

Now that we have our IP address, we need to send a request to the server at that location to get our webpage. We can follow the TCP model and organize the next few steps into layers conceptually to make things a little easier to understand.

We start at the application layer — user interface. This is where we enter the URL in browser and where DNS lookup takes place. Once we have the actual address, we(client) can send HTTP request to server at that address and server will respond with the corresponding data. Hypertext Transport Protocol (HTTP) is an application layer protocol used for transmitting files/data across the web through TCP/IP sockets.

TCP(Transmission Control Protocol) resides in the transport layer and is responsible for creating a reliable end-to-end connection between two hosts. It’s similar to a messenger. Allows data transfers of other protocols(like HTTP). TCP will break the data down into smaller packets and reassemble them at the other end. An analogy for this concept would be something like breaking down a rocket to transport and reassemble the parts at the destination. We can look at how these protocols are stacked on top of each other by using the analogy of picking up cookies from grandma’s house. IP would be the road on which we drive. TCP would be the car. And HTTP would be the box of cookies moving from one location to another.

I spent way too much time on this

TCP/IP

HTTP relies on TCP to establish a reliable connection between client and server. Four pieces of information are needed to establish a TCP connection (TCP Connection tuple):
1. Client IP address
2. Client Port number
3. Source IP address
4. Source Port number

An IP address will identify the device, but a port number is also needed to identify the specific application/service. It’s similar to having an address to an apartment and a specific unit number.
IP + port number = socket

A web server will bind its application to a port and listen for connection requests. HTTP protocol uses port 80 as default so web servers typically bind to their port 80. On the other hand, the client’s web browser does not need to bind specifically to a port to send out its HTTP request.

Holbertonschool.com is a secured website so will be using port 443 instead.

TCP Connection

To make a TCP connection, the client will attempt to connect with the server at the specified port. If the server accepts the connection request, the connection with client will occur on a new socket. This allows the server to continuously listen to its port for other requests whilst communicating with a client.

A three-way handshake is used to establish a TCP connection:
Client initiates TCP handshake by sending a segment with SYN(Synchronize Sequence Number) flag set to 1.

Server will either accept or decline the connection.
To accept, server will open ports and respond with a SYN-AWK segment (with SYN and AWK flags set to 1) - acknowledging client’s segment and sending a SYN segment indicating the sequence number with which to start.

Client sends an AWK segment back acknowledging server’s messages and will then start data transfer.

Client ->->->->->-SYN->->->->->-> Server
Client <-<-<-<-<-ACK/SYN<-<-<-<-<-Server
Client->->->->->-ACK->->->->->-> Server

SSL / TLS

Without secured connection, communication between client and server is vulnerable. SSL is a security protocol that establishes a secure connection between a client and server.

SSL secured websites will have a lock icon on the left side of the URL

Notice the protocol stated on the left is HTTPS as opposed to HTTP. HTTPS uses the same HTTP protocol but with an added SSL/TLS encryption. It’s another way to access our website.

In order for this to work, both the browser and the server need SSL Certificates. Since holbertonschool.com is an SSL-secured website, we will need an SSL Certificate and establish the connection through an SSL Handshake.

HSTS(HTTP Strict Transport Security) — We went over how the browser will first check its HSTS preload list prior to performing a DNS lookup. HSTS provides an added layer of security through using a special response header that forces communication to be sent over HTTPS for our specified domain. You can actually add your personal website to the HSTS list if it follows a few (easy) requirements. Our browser doesn’t know if Holberton supports HTTPS so it will try to load the website via HTTP first and then with HTTPS on the second try. This is risky business as it allows an attacker to intercept the HTTP request. HSTS allows browsers to know ahead of time to use HTTPS when a website is in the preloaded list.

Transportation Layer Security(TLS) is an updated, more ecure version of SSL. Though this is still more commonly refered to as SSL.

SSL uses asymmetric encryption (public key for encryption, private key for decryption) first to generate a symmetric key. Communication will then use symmetric encryption (shared key). Due to asymmetric encryption’s heavy computational costs, it is only used to exchange and generate a symmetric key safely.

SSL handshake steps

SSL handshake starts after successful TCP connection:

Client hello: Client (browser) sends a client hello message with information such as a random byte string (will be used to symmetry key session), highest SSL version browser can support, compression methods it supports, cipher suite it supports, etc).
Server hello: based off the client’s hello message, server sends a server hello message containing the chosen cipher suite, compression method, and SSL version as well as a random byte string.

Asymmetric encryption server authentication and key exchange:
Server sends client its digital certificate containing its public key for client to encrypt its data before sending to the server.
Server may request for client’s certificate to establish identity of the client(but optional).

Client verifies server’s certificate and sends a random byte string (session key, premaster secret) encrypted with the server’s public key(server will be able to decrypt with server’s private key). If the server requested client’s certificate, client will send its certificate along.

Symmetric encryption
Server verifies client certificate and decrypts client’s premaster secret(encrypted with server’s public key) with the server’s private key and will then generate a symmetric key(master secret).

Client will generate the same symmetric key and send a change cipher spec message (changing to symmetric encryption) to the server and a client finish message.

Server follows with a change cipher message and server finish message. The server finish message will be encrypted with the shared symmetric key. Connection is now secured. Yay :)

Firewall

TCP network breaks data into chunks (packets). Along with data, a packet will have a header including control information such as source address, destination address, connection state, etc. (The packet receiver must send out a confirmation to the sender upon receiving a packet).
A server’s firewall can use the information provided by packets to filter what permeates through.

Packets rejected by firewall will be dropped into the abyss

Methods:
Packet filtering (stateless): firewall compares packets to predetermine filters. If a packet is flagged by the filters, it will be discarded here. Firewall allows or denies packets based on individual packet headers regardless of connection state. This is often used on small business and home networks.

Stateful inspection: Firewall collects related packets until a connection state is determined. Incoming information is compared to characteristics of trusted/specific characteristics. It keeps records of all connections passing through in order to better assess incoming packets.

Application/Proxy service: Firewall analyzes data with a packet and match against specific predetermined rules to specific services/applications. A proxy is a file server located outside of a firewall. A proxy server has its own IP. It takes a client’s request and sends to the requesting server so the client actually never interacts directly with the requesting server’s IP.

Load Balancer

After a packet makes past the firewall, it is likely to encounter a load balancer. The job of a load balancer is to…. balance loads. When you have a single server handling all client requests, a large volume of traffic may overwork the server and cause delays /connection issues. The lonely server becomes a single point of failure in this case — if the server is down for whatever reason, users will no longer be able to access the website. Having a load balancer means workload can be distributed across servers. If one fails, others will carry on. Load balancers handle HTTP, HTTPS, TCP, and UDP traffic. They manage traffic by load balancing algorithms and server health checks.

How To Create a High Availability Setup — Digital Ocean

High availability is a quality of a system or component that assures a high level of operational performance for a given period of time. High availability functions as a failure response mechanism for infrastructure.

Some common load balancing algorithms are Round Robin, Least Connections, and Source. More on Digital Ocean
Round Robin: sequential selection. Load balancer will choose the first server for the first request, down the line, and repeat.
Least Connections: Select server with least amount of active sessions at time of selection.
Source: Select based on a hash of the source IP of the request. This allows client request to go to the same server it used previously.

Web Server, Application Server, Database

After load balancer selected and forwarded our request to a server, our HTTP request will be processed by its web server.

Server VS Web Server:
A server is a computer designed to process requests and deliver data to other computers over a local network or the internet.
Web servers supply the web content for web browsers; what the browser requests, the web server delivers through Internet network connections.

Static VS dynamic content:
Static content: already processed(HTML pages, images, etc) file and need not further processing. A web server can directly retrieve data from codebase if static content is requested.
Dynamic content: needs to be compiled/process into a HTML file first before web server can process it.

If client requests for a dynamic file, web server will need to forward the request to an application server to process the dynamic content into HTML and retrieve data from the database if needed. Once processed, the application server can communicate and return the processed content to the web server.

Application servers host and execute applications and can be used to communicate and extract data from a database — A database is a data repository that stores information. An Application server accesses a database using SQL (Structured Query Language) though data access drivers.

Once content is processed, web server will reply to the client with the requested content and an HTTP response. The status code within the HTTP response’s header will indicate whether the request was successfully completed.

And finally, you will be greeted with the domain homepage.