What happens when you type https://www.holbertonschool.com in your browser and press Enter?

To understand what happens when you type https://www.holbertonschool.com in your browser we need to cover a range of topics including; Secure Sockets Layer (SSL), Transmission Control Protocol (TCP), Hyper Text Transfer Protocol Secure(HTTPS), Domain Name System (DNS), load balancer, web server, app server and database.
To begin the process a user types in the request to visit the website https://www.holbertonschool.com. Essentially, this is a request to view the html for the webpage hosted on the holbertonschool.com server that corresponds to home page for Holberton school.
To get the HTML for the webpage we are requesting will need the help of both Secure Sockets Layer (SSL), Transmission Control Protocol (TCP) and Hyper Text Transfer Protocol (HTTPS).
Secure Sockets Layer (SSL)
To get information securely from client to web server we need to have all the information between the two entities encrypted. There are a few steps to the SSL process but the first step to accomplishing this is using what is known as Secure Sockets Layer or SSL protocol.

The SSL protocol goes through a series of steps to encrypt data. In the image above, in step 1 the client (web browser) sends a hello message along with a a randomly generated number to the web server (in our case an ISP) and sometimes other information like session id numbers, compression methods and protocols that the client supports. In step 2, the web server then sends back to the client a server hello message along with it’s own randomly generated number along with chosen protocols version (web servers typically pic the most recent version of protocols available between themselves and the clients). The web server also sends it’s SSL certificate purchased from a reputable vender and the public key that goes along with that certification. In step 3, the client web browser generates a new random number and uses the public key from the web server cerificate to encrypt the new random number. This new random number is encrypted using the web server public key is called the Pre-Master Secret (PMS). The client sends the PMS to the web server giving both the client and the web server a copy of the encrypted PMS. In step 4 the web server has received the Pre-Master Secret and uses it to create a symmetric key that can be used for symmetric encrypted communication between client and server. This just means that the back and fourth hello’s, exchanging of public keys and messages will not be necessary for every communication between this client and this web server during this session. Step 4 shows the web server sending a message back the client saying that it is switching to symmetric encryption for further communication. In step 5 secure symmetric communication is established in both directions from the client to the web server.
Transmission Control Protocol (TCP)
TCP is a protocol that establishes a connection between a client and a web server. TCP as a protocol that establishes how to have a conversation by defining how to send information back in fourth in small chunks called packets. The protocol defines the methods of how to send, accept, deliver and receive packets of information. The TCP protocol even defines a way to error check and determine if any packets are missing from the transmission. The receiving server assembles the packets (The packets can take different routes across the network and be reassembled on arrival) in order to put together the message. To initiate a conversation TCP uses what is called the TCP 3 way handshake. Heres how it works.

TCP uses what is known as the TCP 3 way handshake. Shown in number one in the image above, the client sends a message in a specific format that includes among many things a hello message along with a random synchronization number or sequence number. Number two in the image shows the server receives the message and sequence number, acknowledges by sending an acknowledgement message with the sequence number +1 as well as its own hello message and it’s own random sequence number back to the client. Because the server acknowledged the sequence number by adding one to it the client browser knows the message was received. In number 3 the client then sends an acknowledgement message back to web server doing the same, adding +1 to the sequence number and returning it as acknowledgement to the client. Once the 3way handshake is complete conection has been established.
Hyper Text Transfer Protocol (HTTPS)
HTTPS stands for Hypertext Transfer Protocol Secure and is the protocol that allows communication between client and web servers. The S in HTTPS refers the use of HTTP with SSL to encrypt the communication. Information sent back and fourth can be in one of two forms either a request or a response message. The client initiates a request for a webpage (called a get request) to the web server. The web server will obtain the requested information and send it back the client in the form of a request response. The image below gives you an idea of what a HTTP request/response messages actually look like.

If the image above was an example of HTTPS everything would be encrypterd and unreadable because the client and web server would be using SSL to encrypt the TCP packets containing these request/response messages. Request and response messages consist of three sections; startline, header and body. For the start line section, the request message shows the type of request (in our case a “get” request) and it shows the HTTP version that the client is using. The get request is just one of many different methods that HTTP and HTTPS can request. Other methods include post, head, put delete and options that can be in the startline of a HTTP request.
The startline in the response message back to the client shows the HTTP version the server will use and a status code showing the status of the request. In the example below you can see a status of 200 meaning that the request was located and returned with no problems. Any status code in the 200’s indicates succesful completion of the method requested. Error codes in the 300’s signify that the client may need to supply additional information to complete the request. The famous 404 error means that the ‘Page Not Found.’ Any status code in the 400’s signifies that the client has made some type of error in the request. The 500 status codes are reserved for when the server itself fails to execute the request.
The header section of the request/response messages consists of key value pairs seperated by colon that have information like; website:host_name, language:english, user-agent: Mozilla/4.0 as well as other pertinent information.
Sometimes a get request will also have a body section but often time the body section of an HTTP message is usually empty. However, the response message does have something in the body. The body of the response is the HTML that you requested, the HTML for holbertonschool.com!
This gives an example of both request and response messages in HTTP. But there are lot of steps in between the request and obtaining the HTML for the body of the response message. The first thing that needs to happen is that the web server needs to determine the IP address for the domain name www.holbertonschool.com. To find out this information the web server needs use the Domain Name System or DNS.
Domain Name System (DNS)
The HTTP get request is taken in by the web server but in order for the web server to retrieve our webpage and find the HTML we are looking for we first need to determine the IP address that goes along with the URL that we requested. To do this the ISP server will need to enlist the help of the Domain Name System or DNS system.

Our ISP has now taken our get request to view https://www.holbertonschool.com and if the IP address is not stored in the ISP cache it uses the DNS system to find the IP address. The ISP first asks a type of server known as a resolving name server or DNS resolver. This server takes the get request to view the webpage and gets to work locating the IP address that corresponds to the domain name you are looking for. The DNS resolver contacts another server type called a root name server as shown as number 2 in drawing above. The root server may know the IP but if not the root server does know the IP address of a different type of server called a TLD or Top Level Domain server that may have the IP address. As shown in number 4 in the drawing above the DNS resolver then asks the TLD server for the IP address. If the TLD server does not know the IP address for the webpage we are looking for it does have the address of another type of server that will know the answer. The Authoritative name server is the server that has the information we are looking for! In the image above we are requesting and receiving the domain names IP address in steps 6 and 7 in the image above. In reality almost every server along the way keeps a cache of recently visited domain names and IP addresses. This includes the ISP server and our own operating system. If any server along the way has the IP address and domain cache’d the information is immediately returned by the resolver and the DNS lookup process is completed.
You may be wondering how the IP address gets stored in the Authoritative name server. Who decides what IP’s go on what Authoritative name server? It is assigned the Authoritative name server by the registrar who issued the domain name when the domain was purchase!
Once the IP address is retrieved it is sent back the client to be stored in the operating systems cache to prevent the need to go through the DNS process again. Now we can request the IP address for www.holbertonschool.com on.
Getting webpage from the Holberton school server
Once our request for the webpage has arrived at the holbertonschool.com server there are still many steps that need to be executed in order for the client to receive the HTML for the page that was requested. There are server firewalls, load balancing servers, web server, app servers, codebase and the database that all play a roll in processing and returning your request.
The Firewall
The first step in the process is making is having a request make it past the firewall protecting the what are called load balancing servers for the holberto school website. The firewall acts as a monitor for incoming and outgoing traffic and denies access to some devices that are not trusted. A simple firewall does this by examining the packets of information being sent to the server looking at aspects like the packets source, destination and location. Firewalls have a list of permissions that it is allowed to let pass into the system and it checks the packets being sent to ensure that these packets are sent from trusted sources and locations. If the source is not trusted it is not permitted through the firewall.
The Load Balancer
Once passed the firewall check the request hits what is know as the load balancer server. A load balancing servers job is to take incoming requests and distribute the work of fulfilling requests to the servers that all contain the html for the requested webpage. Often times a large website will have many servers for one IP address and requests are spread around the servers in different ways. The load balancer can choose at random or it can have weighted algorithm choosing a more powerful server more often than others or a load balancer can route traffic based on the servers with the least connections etc… The load balancer routes the request to an available server to fulfill our request.
The server
Once the request makes it through the load balancer firewall and the load balancer the request is being routed to a server that is ready to serve the information that we requested, the holbertonschool.com webpage. The server choosen by the load balancer is likely to have it’s own firewall and our arriving packets of information will be checked just as they were at the load balancer. Once past the firewall the request is handed offto a component od the server called the web server
Web server
The web servers job is take in requests for HTML pages, assemble the requested HTML, and send that HTML out to the client who requested it. If the web server is asked to retrieve a webpage that is static (never changing) than the web server goes into the file system of the server called the codebase and retrieves the HTML to serve it back to the client. This is the simplest case. But sometimes there is information missing that is needed to complete the requested HTML. This means that our request is dynamic meaning that the web page may change at some point in the future if we decide to revisit the page again. Maybe a new user added a new element, or maybee the information on the page changes daily. In this case we will need to get some information from the database to complete the HTML for our requested page. To do this the web server passes the request off to another component in the server, the application server or App server.
App server
The App servers job is to assist the web server in putting together dynamic html. If the page requested by the client will be different each time it is viewed the content is dynamic or changing and the database must be consulted to obtain the information needed to complete the requested HTML. The app server have the ability to use additional scripting languages like PhP, python and others as well as SQL to extract data from the database. The app server gets the request and sees that it needs to extract information from the database to complete the request. It uses its ability to understand and utilize these additional scripting languages (PhP, python and others…) to extract the information requested from the database. It sends the requested data back to the web server and the web server takes the data and uses it to complete the HTML you have requested. Once completed it sends the HTML back to the ISP and the ISP then sends the information, the requested HTML for https://www.holbertonschool.com, back to us the client to be viewed.
In reality this is a simplified view of what happens when you type a URL in the browser and press enter. There are many other layers of complexity mixed in the process.