Everyone’s hiding tool and place to go is always to Google, at least in this era of technology. But have you ever wondered, from a higher level perspective, what the hell goes on once you type https://www.google.com in your browser and press Enter. I’ll attempt to walk you through, as below.
Terminologies
- Client: As part of the client-server model of computer networks, a client is a piece of computer hardware or software that accesses a service made available by a server. The client usually connects to the service through a network because the server is frequently on a different computer system. You access the server by mobile phones, desktop etc, and in this article, client will be referring to the web browser.
- Protocol: Alternatively, you might use the term “communication protocol,” which is a general term for a set of guidelines or a technique for sending data between two devices. Numerous protocols make up the Open System Interconnections (OSI) model, which is the conceptual framework used to explain computer communications.
- Server: A computer program or apparatus that offers a service to another computer program and its user, also known as the client, is referred to as a server. The actual computer that a server program runs on in a data center is also frequently referred to as a server. The computer system(s) that host www.google.com will be referred to as “server(s)” in the context of this article.
STEP 0 — URL PARSING
Although it is possible to provide web browsers with precise IP addresses so they can access specific websites, doing so would actually save the browser quite a bit of work. However, since there are so many websites we visit every day, it is difficult for us to remember even the dozens of them. As a result, we encode IP addresses as domain names, giving rise to the.com,.net,.gov, and a huge number of other domains that are familiar to us all.
Although the Domain Name System (DNS) greatly improves the efficiency and convenience of web browsing, domain names are meaningless by themselves to web browsers because they must decode, or resolve, a given domain name into its matching IP address. What do you do when you’re asked to describe something you’ve never seen before and are given it? You presumably evaluate the supplied object based on its more distinct, smaller characteristics, including specifics of how it feels, looks, or functions. The same is true with web browsers. First and foremost, the web browser, which we’ll use as an example in this article and call Firefox, splits up the string https://www.google.com.
The protocol that will be utilized for data transport between the client and server is https. The protocol in this instance is HTTPS (HyperText Transfer Protocol Secure). The domain name www.google.com serves as the server’s hostname and corresponds to its IP address.
The port where our request will be sent (see it as the server’s inbox). 0 in our sample URL, but implied as such by the browser based on the HTTPS protocol, which utilizes port 443. Path-and-file-name identifies the name of the requested file and where it is located on the server. The fact that our example URL is empty further suggests that we are contacting the server at the root /.
In a nutshell, our URL indicates that we want to access the file set up at the server’s root directory, which hosts www.google.com. Additionally, we are instructing the browser to use HTTPS to connect to this server at port 443. The web browser checks the hostname, www.google.com, once it has parsed the URL. In the beginning, it checks for any non-ASCII characters such as a-z, A-Z, 0-9,., or -. Although the URL we are given is clear, Firefox would utilize Punycode to encrypt it if it contained a strange character.
The web browser then checks its caches. Think about how similar we are to web browsers. People often dislike doing things twice, and browsers are no different. Your browser maintains a running database of recently resolved hostnames in its cache. Firefox looks into its own cache first. It directly retrieves the hostname’s IP if it matches a recurrent hostname. After failing there, it will look in the operating system’s cache as a final resort. If it fails once again, as we’ll suppose for the purposes of our example, the browser must go through the DNS resolution procedure.
STEP 1 — DNS LOOKUP
STEP 2 — TCP/IP
Our web browser is now ready to use. After determining the IP address for www.google.com, Firefox starts a connection with the appropriate server. Transmission Control Protocol/Internet Protocol (TCP/IP) is used for the communication between the browser and server. This communication protocol is a standard when it comes to web infrastructure and the OSI model, but it is not required. Any functional protocol is acceptable.
The connection between the client and server is established through TCP, the transport-layer protocol. The reliability of TCP is what makes it unique; even if it takes longer, packet delivery (i.e., request/response data) is always assured. User Datagram Package (UDP), a different transport-layer protocol, is quicker but less dependable because packet delivery is not verified twice. TCP is typically utilized elsewhere, but UDP is typical of streaming services where instant material is prioritized. Internet Protocol has already been discussed, however just to be clear, IP addresses are specific to individual machines and stand for the network addressing and routing that direct TCP’s destination locations. In the example, Firefox will use TCP to connect to the server that hosts www.google.com because reliability is more important than speed for this static page.
STEP 3 — SSL
When you connect to a website using HTTPS, your browser displays a cool green lock as a result of the full security procedure, known as the TLS handshake.
STEP 4 — HTTPS
TCP/IP establishes the communication protocol, while HTTP specifies how computers interact with one another. For instance, Firefox sends an HTTP request message to the server after the TLS handshake is complete. The browser’s kind of request to the server is specified in the first line, called the request line.
There are numerous different request message types. Two of these are POST, which submits data to a server, and DELETE, which removes data from a server. A GET message, which obtains a web resource (web page) for a client from a server, is what our entry of https://www.google.com qualifies as.
The browser can include information about the request in the header part of HTTP request messages, such as whether or not the server should keep cookies or if the connection should end immediately (persisted session information for a given client). The optional request body is generally unnecessary for request messages. It was a lot to take in at once, but HTTP will be discussed again later. For the time being, remember that in our case, Firefox has sent a TLS-encrypted HTTP GET request to http://www.google.com’s resolved IP address to obtain the web page defined at the host server’s root.
It was a lot to take in at once, but HTTP will be discussed again later. For the time being, remember that in our case, Firefox has sent a TLS-encrypted HTTP GET request to www.google.com‘s resolved IP address to obtain the web page defined at the host server’s root.
STEP 5 — LOAD BALANCER
You are entirely correct if you believe that only one machine could successfully handle that volume of traffic. In truth, the majority of well-known websites distribute traffic among numerous servers. Traffic is managed much more effectively by distributing requests among them as each is set up to service requests in exactly the same way. An intermediary in charge of handling this traffic-splitting function is a load balancer. Software known as a load balancer can be set up either on the same server that is serving web content or on a separate server. HAProxy is one such popular and cost-free load balancing program.
A tool like HAProxy divides up HTTP request traffic based on a load balancing algorithm. There are different kinds of load balancing algorithms, and each has benefits and drawbacks of its own. Round-robin load balancing, which sends requests to servers in turn based on a queue, is one example of this. Another is least connections, which issues a fresh request to the server managing the fewest connections at the moment.
Going back to our example, the load balancer server’s IP address was really the resolved IP address of www.google.com. This load balancer server became the TLS termination proxy once Firefox successfully finished the TLS handshake with it. This server, which we’ll pretend is set up with a round-robin mechanism on HAProxy, was the recipient of our HTTP GET request and resembled a post office in certain ways. When a request came in, HAProxy looked up the IP address of the following web server in its queue and forwarded the request that way.
I’ve only discussed a system that uses one load balancer thus far. However, if a website just has one load balancer installed, and that load balancer server goes down, the entire website would become unreachable; this is known as a single point of failure. A robust website should have several load balancers setup as a transparent cluster. Each load balancer in the cluster is always aware of the status of its comrades, and any one of them can manage a larger volume of requests if another fails.
STEP 6 — FIREWALL
Hardware, software, or a combination of the two can be used to build firewalls, which filter all incoming and outgoing server traffic. Data interception during transmission can be avoided with TLS. However, it makes the assumption that the data obtained is from a reliable source. Firewalls don’t make these kinds of assumptions and check each packet for the presence of malware or malicious hardware using a combination of packet filters, application gateways, circuit-level gateways, and proxy servers.
Firewalls are often configured everywhere data is received and are reasonably simple to implement, including on host and load balancer servers. Uncomplicated Firewall is one such brilliantly named and freely downloadable Linux program (UFW). In our hypothetical example of firewalls, our GET request has already gone through one firewall that is installed on the load balancer at this point. Any host server that it is distributed to will then pass another installation.
STEP 7 — Host Server
Finally, we are here!
Our initial URL has been resolving into its IP, transferred over TCP/IP, encrypted by TLS, formatted as HTTP, passed through a firewall, distributed by a load balancer, and passed through another firewall before being received as an HTTP GET request by a server hosting our desired web page.
The host server is a multi-part web stack that is typically configured in accordance with what is known as the LAMP paradigm. Here is how the LAMP model is broken down:
- L stands for Linux, which is the host server’s operating system. Select your preferred distribution. Ubuntu will be used as our example.
- The HTTP web server A, also known as Apache. The static web page is finally delivered by this program, which also handles HTTP request/response communications. Although alternative HTTP web servers, like Nginx, are similarly effective, Apache is the most popular one.
- M — MySQL — the database server. This is the database software, which is often SQL-based and used to store data like user accounts. Although it is free and widely used, any database program will do. A normal website will have several database servers, one of which will be set up as a “primary” database with exclusive write access, whose updates are then replicated to “replicant” databases with only read privileges. This configuration is known as a “primary-replica” model.
- P — PHP/Python. Application server Web servers work well for delivering static, never-changing web pages, but they are unable to display dynamic content, which is essential to current websites. Web servers that can handle dynamic content typically support PHP and Python as well as other high-level languages like JavaScript and Ruby.
This LAMP web stack can be set up individually or all at once on the same server. Unlike in the past, when each layer of the stack would run on a virtual machine, today it is typical to divide each component into a separate container, such as Docker, which is pre-configured with the specific software required to run the particular server. To produce a web page, the stack collaborates on a single codebase. A LAMP stack setup using the aforementioned applications will have a codebase that is made up of a combination of Apache configuration files, Python scripts, and MySQL queries.
The way a web page is delivered is as follows:
- The web server receives a GET request. The file configured at the specified location is retrieved by the web server (in our example, the HTML file configured at the machine’s root (/)).
- The application server is launched if the file contains dynamic content (ie. the corresponding Python scripts are run). These scripts produce a result that is put into the web page.
- When dynamic content uses stored data, Python scripts execute database server queries (probably through Python libraries such as MySQLdb or SQLAlchemy).
- The web page is delivered via the web server.
Keep in mind that a particular website will be configured with numerous servers most reliably. As a result, traffic is handled more effectively, and a new single point of failure is avoided. Multiple load balancers are useless if the web servers are down. A server only receives data after it has passed through its firewall, so keep that in mind as well!
Our flowchart will be set up with three host servers, each running the Ubuntu Linux operating system, and three containers: one for an Apache web server, one for a Python application, and one for a MySQL database server. In other words, all servers will be operational and processing requests simultaneously in an active-active setup (as opposed to an active-passive setup). The first host server’s database container will function as the master, and the rest as replicants.
Aside Monitoring
Before we wrap up, it’s important to note that a monitoring software is used to keep an eye on the web infrastructure architecture we’ve detailed. Websites are sensitive, so maintaining a smooth operation involves ongoing monitoring and fine-tuning in response to information like traffic volume, request response time, and server health. A monitoring software collects these statistics.
8. PAGE RENDERING
Our web browser has finally obtained the webpage we requested after a protracted voyage. The host server then returned the HTML document loaded from the root of http://www.google.com to the web browser as an HTTP response message. A status code indicating the success of the processed request is included in the first status line of this response message.
The host server signals 200 once the web page has been successfully delivered and retrieved. The status codes 301 (page redirection) and 404 are additional frequent ones (page not found).The host server specifies details about the delivered page, including its size and type (in this case, HTML), in the response header.The host server then sends the actual, complete HTML code in the body of the response message.
The browser has been looking for this from the beginning! The code is now parsed, broken down into its Document Object Model, and the page is rendered using its HTML and CSS engines. The file is opened and any JavaScript scripts are executed.A quick rundown of the process just described:The URL https://www.google.com is received by the browser, which decodes it into its protocol (https), hostname (www.google.com), port (implicity, 443), and location (implicity, root /).
The browser checks its own or the OS’s cache to see if the hostname has already been resolved. If so, the matching IP is immediately retrieved.Otherwise, the Domain Name System resolves the hostname.The load balancer provided at the resolved IP successfully completes a TLS handshake with the browser. Over TCP/IP, this communication takes place.The browser sends the load balancer a GET request for the file located at the root of http://www.google.com after establishing an encrypted connection mechanism.
On the load balancer, the GET request is routed through a firewall.According to its preset load balancing mechanism, the load balancer distributes the GET request to the subsequent host server that becomes available.The host server’s firewall allows the GET request to proceed. The application and database servers offer dynamically generated content from the host server’s root directory file, which is retrieved by the host server.After receiving the HTTP response message with the file content, the browser displays the user with an HTML page.
The Postulations of Zach Alex Ria N 
Incredible. Learnt a lot from this piece
LikeLiked by 1 person