Session - 5 (18-12-2024)

Main ideas & lessons conveyed

Recap of client–server fundamentals

• A client requests a resource (e.g., a browser requesting google.com).
• A server responds with the requested resource.
• Client and server must communicate over the same network, and they can be on different devices.
• Network devices (e.g., router, Wi‑Fi, hub, switch) are also devices that can act as clients or servers.

Client–server architectures (3 tiers)

One-tier architecture (dead / not recommended)

• The same device acts as both client and server.
• Issue: keeping both roles in one machine is not good design.
• Outcome: effectively becomes one layer.

Two-tier architecture

• Client and server are separated into two layers:
  • Client layer
  • Server layer
• Inside the server machine, typical stack layers include:
  • Hardware
  • Operating system (mostly Linux, though Windows is mentioned)
  • Application
  • Database
• Warning: application and database on the same machine causes capacity contention
  • The application and DB compete for RAM
  • The OS may get too little capacity
  • Result: server overload / unreachable / poor performance
• Therefore, this is not recommended for production.

Three-tier architecture (recommended for production)

• Separates into three layers:
  • Client layer
  • Application layer
  • Database layer
• Motivation: avoid “fight” for resources → better performance.
• Adds a web server component in front to improve security and routing:
  • Web server receives requests and redirects them to the application server
• Placement concept (security):
  • The application server should be private, not directly public
  • Public exposure increases risk of attackers reaching code/services directly

Server types

• Application server: hosts the application (example mentioned: Tomcat).
• Database server: hosts the database.

How machines communicate: IP address + host name

• Each network device has a unique identifier:
  • IP address (Internet Protocol)
• Also uses:
  • Host name (human-readable name)
• DNS is described as the system that maps between hostnames and IPs.

DNS workflow (browser → local DNS → root → TLD → name server → SOA)

• Browser needs both:
  • host name
  • IP address
• DNS avoids humans memorizing IPs (compared to a phone book).
• Flow described:
  1. Browser queries Local DNS (talk mentioned /etc/host)
  2. If not found locally → query Root Name Server (RNS)
  3. Root points to the correct top-level domain (e.g., .com)
  4. Then to a Name Server
  5. Name server uses SOA (Start of Authority) to retrieve the IP address
  6. SOA returns the IP so the browser can connect

Firewall concept + protocol security rules

• Firewall: allows/denies traffic to prevent unauthorized access.
• Examples of security-related ports/protocols mentioned:
  • HTTP: port 80
  • HTTPS: port 443
  • SSH: port 22 (for Linux)
  • RDP: port 3389 (for Windows)
• Packet inspection idea:
  • Firewalls permit only the required protocols (example emphasizes allowing HTTPS instead of HTTP).

Load balancer and traffic distribution

• Problem: with multiple web servers, users shouldn’t hit the “wrong” one or overload a random subset.
• Load balancer:
  • Distributes traffic across multiple servers
  • Example method: round-robin
    • Request 1 → server 1
    • Request 2 → server 2
    • Request 3 → server 3
    • Request 4 → server 1 (repeat)

End-to-end request path in a “Google-style” 3-tier flow

Sequence emphasized:

• Browser request
• Firewall (allow/deny filtering)
• Web tier / load balancer
• Web server(s)
• Application server
• Database server
• Response returns back to the browser

Emphasis: the full process must happen quickly (within milliseconds) for good UX.

HTTP vs HTTPS: purpose, ports, and security

• HTTP (Hypertext Transfer Protocol)
  • Transfers data between browser and server
  • Not secure because it is plain text / clear text
• HTTPS
  • Secure version using encryption
  • Uses port 443
• Redirection:
  • Typing http://google.com may auto-redirect to HTTPS
• Status codes mentioned:
  • 200: success / page found
  • 404: page not found
  • 500: internal server error
  • 502: mentioned
  • 503: service unavailable (example: IRCTC/tatkal)
• Certificates:
  • HTTPS relies on SSL/TLS certificates
  • Certificates are described as being managed via AWS later (AWS mentioned conceptually; no specific subtitle service name)

Port number default rule

• Use default ports:
  • HTTP default: 80
  • HTTPS default: 443
• If a non-default port is used incorrectly, the service may fail (browser can’t connect).
• Example:
  • Backend application runs on port 8080
  • Customer accesses default HTTP/80
  • Solution:
    • Use a load balancer to forward/translate traffic so customers use default ports while backend uses 8080

---

Methodologies / instruction-like concepts (detailed bullets)

Choosing an architecture

• One-tier
  • Avoid: client and server on the same machine is “dead” / not recommended.
• Two-tier
  • Use only conceptually/setup-wise; not recommended for production
  • Reason: application + database together → capacity contention and performance failures
• Three-tier
  • Separate into client, application, and database layers
  • Add a web server layer for routing + security
  • Keep sensitive servers private

Firewall rule pattern

• Configure firewall to:
  • Allow only required protocols/ports
    • e.g., allow HTTPS/443 instead of HTTP/80 when security is needed
• Effect:
  • Blocks unauthorized traffic before it reaches internal systems

DNS resolution approach

• Browser relies on DNS hierarchy:
  • Local DNS → Root Name Server → TLD → Name Server → SOA → IP returned to browser

Load balancing approach

• When multiple web servers exist:
  • Place a load balancer in front
  • Use round-robin routing (server1 → server2 → server3 → repeat)

Port handling guidance

• For customers/users:
  • Prefer default ports:
    • HTTP: 80
    • HTTPS: 443
• For backend apps on non-default ports (e.g., 8080):
  • Use load balancer/web server layer to map/translate traffic from defaults to backend ports

---

Speakers / sources featured (as mentioned in subtitles)

• Riya’s Sir / Sir (main instructor)
• Nana (replies/questions referenced during class)
• Sunil (asked to define firewall)
• Revathi (listed as an online new student)
• Mallikarjun (listed as an online new student)
• Sirisha (listed as an online new student)
• Srilatha (listed as an online new student)
• Srilatha (also addressed in mic-testing / responses)
• Praneeth (mentioned as answering/confirming during recap)
• Ritesh (mentioned during recap permission/interaction)
• Riya (mentioned via “Riya’s fan club” greeting; not clearly confirmed as a separate speaker/instructor)
• Vishal (used as an example user/device in explanations)
• Pandu (used as an example customer in HTTP/HTTPS security example)
• Google engineers / Google company (used as conceptual system examples, not actual speakers)