Video summary

Session - 4 (17-12-2024)

Main summary

Key takeaways

Educational

Main ideas & concepts covered

1) Recap: Client–Server architectures

  • Client: requests a resource.
  • Server: responds with the requested resource.
  • Devices in a network can act as clients or servers.

Types of client–server architectures (3)

  1. 1-tier

    • Client and server on the same device
    • Not used (as stated in the summary)

  2. 2-tier

    • Separates into client layer + server layer
    • Server layer stack (bottom → top):
      • hardware → OS → application → database
    • Notes:
      • Not recommended to keep application and database on the same machine for production
      • Leads to bad performance
      • Clients get affected
      • Also described as not secure enough for production

  3. 3-tier

    • client layer + application server layer + database server layer
    • Roles:
      • Application server: hosts the application
      • Database server: hosts/stores the database
    • For production, 3-tier is stated as the best architecture

Network addressing concepts

  • IP address: unique identifier for a device in the network
  • Host name: name of a server/application (e.g., google.com)
  • Systems should be in a private network; customers can’t directly connect to it
  • A web server “in between” mediates requests (linked to the idea of a 3-tier approach)

2) Why understanding “back-end” matters

  • When an end user types a URL (e.g., google.com), they expect the page quickly.
  • If it’s slow or fails, users get frustrated.
  • The owner/engineer must understand what’s happening behind the scenes to troubleshoot.
  • This motivates learning the end-to-end request path.

3) DNS: translating hostnames to IP addresses

A browser needs two things:

  • Host name (e.g., google.com)
  • IP address

Because users don’t want to remember IPs, the network uses DNS.

DNS concepts

  • DNS (Domain Name System / Domain Name Server):
    • Tracks hostnames ↔ IP addresses
    • Converts host name → IP (and IP → host name)

Local DNS

  • Located on the client machine via /etc/hosts (as described)
  • If the mapping isn’t found locally, DNS queries continue further.

Root name server (RNS)

  • Checks the top-level domain (TLD) like .com, .org, .net, etc.
  • Forwards the query to the correct TLD authority.

Name server / authoritative server

  • Identifies where the specific domain lives inside the TLD
    • Example: where google.com lives within .com
  • SOA (Start of Authority) is referenced as holding/providing the IP address in the described flow.

Key outcome

  • The browser finally obtains the IP address needed to connect.

4) Protocols, firewall behavior, and port numbers

When a user accesses a site, traffic includes data packets with source/destination details.

HTTP vs HTTPS

  • HTTP: port 80
  • HTTPS: port 443
  • Firewall behavior described as:
    • It allows/denies based on protocol security preference
    • Example policy: deny HTTP, allow HTTPS

Other protocols + common ports (mentioned)

  • SSH → port 22 (used to connect to Linux machines)
  • RDP → port 389 (as stated in the subtitles; commonly 3389, but the subtitle value was 389)

Firewall definition and purpose

  • A firewall stops unauthorized access to the network.
  • It can allow or deny traffic based on rules (including protocol/port expectations).
  • Analogy used: “protocol + port must be shown” for the request to pass.

5) Load balancer: avoiding direct exposure and distributing traffic

Problem described

  • If users had to use backend server IP addresses directly, that’s inconvenient and brittle.
  • Example: if one server goes down, users would need to try multiple IPs.

Solution: load balancer + friendly DNS name

  • A load balancer provides a friendly DNS name (example: raj.com).
  • Instead of connecting to a single fixed server, requests go through the load balancer.

Load balancer behavior

  • Receives requests (indirectly via the friendly domain)
  • Distributes to multiple servers using round-robin
    • Alternates requests across servers in order

Role in the architecture

  • For the topic being taught, the “web server” concept is effectively served by the load balancer.
  • The load balancer sits after the firewall in the request path.

6) End-to-end request flow (from the subtitles)

  1. Browser supplies:
    • Host name (e.g., google.com)
    • IP address (resolved via DNS)
  2. Conceptual request path:
    • Browser → Firewall → Load balancer
  3. Load balancer forwards to:
    • Web server / application server
    • Database server
  4. Response travels back in reverse order until the browser receives the page.

Troubleshooting insight

  • If a customer says “application not working,” knowing where it might be stuck (firewall, load balancer, web/app server, database) makes troubleshooting easier.

7) Using nslookup (practical command mentioned)

  • To find an IP for a domain:
    • nslookup <domain>
  • Example shown conceptually:
    • nslookup facebook.com
  • Result may point to load balancer targets rather than a single backend server.

Methodology / instruction-style content

DNS resolution steps (conceptual methodology)

  • User types a host name in the browser (e.g., google.com)
  • Browser needs the IP address, so it consults DNS:
  1. Query local DNS
    • Check /etc/hosts
  2. If not found locally, query root name server (RNS)
    • Determine the applicable TLD (e.g., .com)
  3. RNS forwards to the correct TLD name server
  4. The authoritative name server (SOA referenced) provides the IP address
  • Browser then has:
    • host name + IP address
  • The browser can contact the server.

Firewall + protocol access decision (conceptual methodology)

  • Browser sends request using protocol (HTTP/HTTPS) and therefore a port:
    • HTTP → 80
    • HTTPS → 443
  • Firewall applies rules:
    • Allowed policy → allow
    • Otherwise → deny
  • Example policy: HTTP denied, HTTPS allowed

Load balancing distribution (round-robin methodology)

  • Load balancer receives requests for a friendly domain (e.g., raj.com)
  • It forwards each request to backend servers using round-robin:
    • Request 1 → server 1
    • Request 2 → server 2
    • Request 3 → server 3
    • Request 4 → server 1
  • Reason given: distribute load and improve reliability (high availability concept mentioned)

Practical DNS lookup using nslookup

  • Open Command Prompt
  • Run:
    • nslookup <website>
  • Observe returned IP address
    • It may correspond to load balancer targets

Speakers / sources featured

  • Trainer / Instructor (main speaker; name mentioned): Rias (also referenced as “trainer rias … email”)
  • Students/participants mentioned in the dialogue:
    • Manikanta
    • Vishwa
    • Harindra
    • Tjas
    • Dali
    • Naven
    • Surup
    • Ramesh
    • Ganesha / Ganesh
    • Pawan
    • Raj / Rajes
    • Kyra
    • Mark
    • Roxy
    • Malata
    • Rajat
    • Others referenced collectively as “everyone/online people”

Original video