Main Parts of a browser

• User Interface (UI) : With the use of ui you interact with the browser. This includes the address bar, back/ forward buttons, tabs .. etc

• Browser Engine: It is the coordinator between the UI and the render engine. It ensures whatever is rendered by the render engine is displayed by the ui

• Render Engine: Converts HTML, CSS and JavaScript into visual and interactive elements in the screen

• Networking: Fetches resources either using HTTP or HTTPS

• JavaScript Engine: Executes JavaScript logics in the page

• Data Storage: Stores cache, keys, token and passwords

Browser Engine vs Render Engine The browser engine acts as a bridge between the UI and the Render Engine whereas the Render Engine is responsive for doing all the calculations on how the website should look, what should happen after you press a button, calculations for the animations and visuals you see in the web-apps. Now a days render engine takes advantage of gpu acceleration to make animation and rendering a lot more efficient and fast.

Real world example of how a browser works

• You write facebook.com on the address bar and press enter

• Browser resolves the domain using DNS

• Fetches the resources from the ip address that the authoritative DNS provider gave

• Parses the HTML into the DOM (Document Object Model)

• Parses CSS into the CSSOM (CSS Object Model)

• Combines DOM and CSSOM into the render tree

• Preform layout calculations and displays the webpage

• Executes JavaScript Using the javascript Engine to handle user interactions

dig Command : dig is a command line tool used to query dns server and see how the dns is resolved.

dig . NS -> shows all the available root servers dig com NS -> shows all Top Level Domain Servers from .com dig google.com NS -> shows the authoritative name server for google.com

When the dig command is used to resolve a domain like google.com. It emulates the full DNS lookup. First dig . Ns queries the root name servers are responsible for the top-level domain (TLDs) such as .com . After that dig com NS asks the .com TLD servers to identify the authoritative name server for google.com. Then dig google.com NS gets the authoritative name server that actually stores the dns of google.com. Finally this authoritative name server provides the DNS records like A (ipv4 address) and AAAA (ipv6 address) of the website. Using dig allows you to trace the full DNS resolution path from root to the TLD to authoritative server and finally till the domains ip address.

Example of using dig command

• Testing Websites: Curl is used to check if the API is running or not. Either for a deployed website or hosted on the local computer

• Debugging: curl can be used to see what exactly the server sends back as a response, giving insights to debugging efforts.

Making First request using curl

You can try using curl by opening the terminal in mac/ linux or the command prompt in windows and running this command

curl https://www.google.com The output may look very messy as it basically provides all the html,css and js for google.com website

You can also use the -I flag to only get the headers here is an example

Every-time you are using cURL you are sending a request to the server and then receiving a response. The request contains the URL, http method (GET, POST, PUT, PATCH, DELETE), headers and the data you want to send. And the server sends back a response. The response includes status codes like (200, 2001, 400, 4001 ... etc) each status code has it own specific meaning. In the above example the google server sent back a http 200 status code, meaning everything is working fine.

Using crul although seems easy, some beginners often miss a minute details and scratch there heads when they don't get the response that they were hoping for. Here are some things to keep in mind when using curl.

• Protocol: http / https

• Method: Use correct method Get/ Post/ Put/ Patch/ Delete

• Data Format: Ensure correct data format JSON/ XML

• Authentication tokens / keys

NS Record NS or Name Server Record is a type of dns record which tells you which dns providers server are authoritative for the dns you are searching for. These dns provider servers store all DNS records for that domain, such as A, AAAA, CNAME, MX, and TXT records. NS record generally point towards big DNS hosting providers such as godaddy,namecheap,cloudfare.

Some important DNS Record Types Explained in short:

• A Record -> Refers to the domain address in ipv4 format

• AA Record -> Refers to the domain address in ipv6 format

• CName -> Maps one domain to another domain Eg: (www.google.com is a cname for google.com)

• MX Server -> Specifies which domain server receives email for the domain

• TXT Record -> TXT record is a record that stores text information associated with the domain. Commonly used for domain ownership verification.

Example Scenario How they all work together When you visit www.abc.com, the dns system first looks at the www in the CNAME pointing towards abc.com. The DNS then looks up abc.com and finds the A Record and the AAAA Record of the server hosting the website. This gives the actual address of where the servers of abc.com are. Now your browser is able to access the website. If you send email to @abc.com then all the traffics are routed to the MX Record of that particular url and the TXT Record is used to verify the ownership of the email through SPF?DKIM checks. All these records are stored in the DNS provider's authoritative servers, which are pointed towards by the NS Record ensuring everything works as intended and the end-user can browse the internet without having to deal with all the complex internal working mechanism.

Problems TCP solves

• Lack of standardization

• Un-reliable data transfer over the internet

• Error Detection

• Ordered delivery of package

Three way handshake is a mechanism that TCP uses to ensure that a reliable connection between the server and the client.

In the beginning the client sends a Synchronization Request, the server sends back New Synchronization Request plus an Acknowledgement and finally the client sends an Acknowledgement. The 3-way handshake happens at the start of every connection and a 4-way handshake is used to terminate a connection.

The main selling point of TCP is its reliableness and correctness. TCP ensure this by the following ways:

• Three way handshake

• Each data segment sent by the sender needs to be replied with an Acknowledgement

• Each data packed it sequenced with numbers

• Checksums are used to check for corruptions

Closing of TCP Connection

TCP connection is closed using a 4 way handshake

Starting with a Fin request from the side that want to close the connection lets say its the client. After receiving the Fin request the server sends an ACK along with a FIN Request of its own. The client sends back an Ack at the end leading to the termination of the connection.

Transmission Control Protocol is basically rules that govern the transfer of packages or data over the internet. It is a reliable protocol which ensures that the data packet is transferred to the required destination and even if the data packet failed to transfer, the sender gets to know as it wont receive a acknowledgement. Here data is converted into smaller chunks called segments

UDP

User Datagram Protocol is another type of rules that govern the transfer of packages or data over the internet. It is unreliable compared to TCP but is a lot more lightweight and fast. Data is converted int small chunks called datagrams

Key differences between tcp and udp

You should use tcp where the data is very important and the sequence of the data is also very important. Some Use Case of TCP are:

• Messages/ Emails

• Banking Transactions

• Sending Images

• Software/ Application download

  In other hand you should use UDP when the sequence of data or the data packet it self is less important then fast delivery. Some use case of UDP are:

• Video/Audio Call

• Live Board-casting

• Gaming

HTTP

HTTP stands for Hyper-Text Transfer Protocol. It is a set of rules that govern the transfer of data between the server and the client that may include html, css, images, videos, javascript, browser resources which are used by your web applications to display an interactive webpage. Http uses TCP in the transport layer, making it a reliable protocol. Http works on top of Tcp and tcp ensures that the packages of http is delivered.

So the question may arise in your mind what is a modem and a router ? A modem is basically a device that converts digital signals that is understood by our computers into analog signal that is more efficient for transmission and vice versa. You needed this in the past as the router didn't understand analog signal and the coaxial cable used for transmitting the data back in the day only supported analog transmission. So modem was basically a translating device for the router and the cable infrastructure.

Routers

The miracle box that makes the internet work in your device. It works like a postman but for digital packages. It reads the address on the package (IP address on the header of the data package) and then determines which device is the ultimate destination for the package. And sends the package to the device either wirelessly or if its connected via ethernet cable, then via the wired route. It is able to do

Break-Down of how router knows device to transfer the package to

Now lets dive Into Switches and Hubs Switches and Hubs are two types of device that are used for similar work that is to increase the number of device connected to the network via wires. Generally via ethernet cable and RJ45 jack. Although they have the same task they do have some important differences they are :

Switches

• Sends packages to the individual device according to their mac address

• More efficient compared to hub

• More secured compared to hub Hub

• Sends packages to all the devices in the network

• Less efficient and less secured compared to switch

• More affordable compared to switch

FireWall

Like the name suggests firewall is a barrier between the internet and you home network or computer. Traditionally it used to be an actual hardware that used to scan each and every package for malicious code or a malicious sender. Nowadays a software is used which runs either on the router level or the actual device level. Firewall responsibility is to protect the end user from the malicious actors from the internet.

Load Balancers

Imagine you are deploying your next big project Tinder but for dogs. Its a huge success and you have hundreds of millions of users. You can only process so much request from a single computer as a server. You may thinking of increasing the capacity of the server by adding extra ram, storage or even upgrading the processor (Vertical Scaling) . But at a point in time you will realize this is to expensive and is not feasible. The next solution is to spin up another computer now u have double the capacity of handling request (Horizontal Scaling) . But you will need a mechanism to ensure that the requests are divided into the multiple server instances so you wont have one server running at maximum capacity and the other one hardly getting any traffic.

To solve this issue load Balancers are user. They are responsible for distributing traffic among the available serve instances. And ensuring that each server instance is healthy. Incase of error it redirects traffic to other healthy server instances.

Conclusion

In real world scenario all these technologies work together to ensure that the internet functions and you can enjoy you cat videos in youtube without a hacker getting your bank details or social security info. When u click on that cat video the request goes from Your device -> switch/ hub -> router -> modem -> global network of optical fiber and satellites -> youtube servers -> load balancers -> actual device that process the request Then the response travels back all the way from the same path back to your modem -> router -> firewall and finally your Device so you can enjoy your cat videos.

Some Key Concepts of git Head -> Latest commit is called head Hash -> Unique id given to each commit

Branching in Git

Branching can be utilized when you are working on a experimental or new feature and only want to update the main version of the project after you have completed the feature.

Exploring git folder structure

• HEAD:

  Stores the data about the branches and what branch is currently being used

• refs/heads:

  Stores the hash of the current branch

• objects:

  All the changes are stored here with their first two hash code as a folder name for better storage. If u explore into this you will see files with commit hash. Each file includes hash of previous commit, author, commit message and hash of the tree is it part of.

Some more complex git commands

Fixing Errors or mistakes in commit

• git revert <hash>

  Creates a new commit that is negative of the commit u want to revert

• git reset --hard <hash>

  Puts head to the commit mentioned resulting in all the commits after that hash being deleted.

• git reset <hash> -> without the --hard

  Puts the head to the commit and all the changes after it is kept in the staging area

Now, although we highlighted the need for learning git. Some more questions may arise in you mind.

How do u actually use git?

How do u tell it what u want to do?

How do u tell git when to save something?

How do u tell git what to track or what amount of code is considered so called "new version"?

The answer to this question comes from the concept of Git Commands

Git Commands

Git commands are basically instructions you write to git that tells it what to do. For you to have be able to write git commands first of all u will need to have git installed in your computer. Lets go through some common and widely used git commands and learn what they actually do.

1. git init

   As the name suggests it initializes git in the directory you run this command at. After git is initialized it is able to keep track of changes u made also you will be able to use other git commands as well. Syntax:

   git init

2. git add

   It allows you to add all the changes you have made to staging area. Staging area is the place from where you can commit the changes.

   Syntax:

   git add -> for adding individual file or directory

   git add . -> for adding all the changes of files into the staging area

3. git commit

   Commit lets u create a version for the project. It generates a unique identifier for each commit. So u can go back to a commit you made in the past or see what changes have been made in between two commits. After the commit is done its like saving the changes into git.

   You can also use -m flag to write a short message about the particular commit. It is considered good practice to write it in present tense and also to use words like (add, refactor, remove, feat )

   Syntax:

   git commit -m "Your short description to describe the commit"

4. git push

   This allows you to push the changes to a remote server most popularly used is github. This allows you to have a backup, as well as make the code changes accessible for other collaborators to use.

   Syntax:

   git push origin main

5. git log

   This displays all the commits that have been made in the past along with their unique identifier, commit message as well as date and time of the commit.

   Syntax:

   git log

   git log --oneline ->For more compact and cleaner output, but removes details like date and author

6. git diff

   This command allows you to see the different changes that occurred between two different commits. It is very useful when u need to know which files were changed and what were the changes between the commits.

   Syntax:

   git diff <commit id1> <commit id2>

7. git status

   Shows the overall current status of git. What files are stages which are modified after the last commit or which new files have been created and are untracked.

   Syntax

   git status

Lets say, A developer decided to make a personal project. He setup the project in his computer and start writing code. In the beginning the code was of few lines. He didn't have any issue keeping track of what changes he made, at times when he faced a bug or an error he could easily debug. Everything was working fine at the beginning. After a month or so, his consistency paid off and the project grew to have thousands of lines of code. Now, a new problem arose if he faced a bug or wanted to add some experimental feature, and things didn't work out, he would have hard time changing back all the thousands of lines of code to the time everything worked fine. Finding solution to this problem led to the development and the existence of version control system.

The Pendrive Analogy in Software Development

Lets imagine you are working on your next big app "Tinder But for Dogs". The project is a huge success and u need to add a payment feature to earn some money for the hard work. You don't know how to build the payment feature and u ask your good friend Tommy for some help. Now, you have to provide the source code to Tommy. You think for a while and get a brilliant idea to use a USB pen-drive, what could go wrong ? right, Well as brilliant as the solution may sound, like the "Tinder but for dogs" idea u had, here are some problems that may occur.

• You will need to physically move the pen drive from your house to your friends every-time u make and update and vice-versa.

• Both you and Tommy wont be able to work on the project in parallel as if u do so there will be two different project with different things implemented and you will have a hard time merging both.

• You wont know what changes were made by each other (collaboration history).

So, these were the problem faced before a proper version control system existed