How the Internet Works: DNS, IP Addresses, TCP, HTTP, HTTPS and More

When you open a website like editmystuff.in, it feels instant: type the address, press Enter, and the page appears. But behind that simple action, several networking systems work together.

Your browser has to find the server, discover its IP address, establish a network connection, send an HTTP request, receive a response, and render the result.

This guide explains the most important pieces of that process — client-server architecture, DNS, IP addresses, ports, TCP, UDP, HTTP, HTTPS, TLS, and latency — without assuming a networking background.

The big picture: what happens when you open a website?

At a very high level:

Browser
   ↓
DNS
   ↓
IP address
   ↓
TCP / UDP connection
   ↓
HTTP / HTTPS request
   ↓
Server
   ↓
HTTP / HTTPS response
   ↓
Browser renders the page

For a typical HTTPS website, you can think of the stack like this:

HTTPS
  ↓
TLS
  ↓
TCP
  ↓
IP
  ↓
Internet

HTTP/1.1 and HTTP/2 commonly use TCP. HTTP/3 uses QUIC over UDP, which is an important modern exception.

Client-server architecture

The client is the application requesting something. In a web application, the browser is usually the client.

The server is the system that receives the request and returns a response.

Client / Browser
       │
       │ Request
       ▼
     Server
       │
       │ Response
       ▼
Client / Browser

For example, when you open a PDF tool on EditMyStuff, your browser acts as the client. A server-based application could receive a request, process it, and return HTML, JSON, an image, or another resource.

The important idea is simple:

The client asks for something; the server responds.

This model is the foundation of most networked applications. To see how these pieces — clients, gateways, services, caches and databases — fit together in a larger system, you can visualise an architecture with the System Design Generator and step through the request flow interactively.

DNS: turning a domain name into an IP address

Humans prefer names:

editmystuff.in

Computers need network addresses such as:

13.235.10.20

DNS (Domain Name System) connects the two.

editmystuff.in
       ↓
DNS lookup
       ↓
IP address

DNS is often described as the internet's phonebook.

When you type a domain into your browser, the browser and operating system may first check cached DNS information. If the answer is not available locally, a recursive DNS resolver can query the DNS hierarchy.

A simplified lookup looks like:

Browser
   ↓
OS / Local DNS cache
   ↓
Recursive DNS resolver
   ↓
Root DNS server
   ↓
TLD server (.com, .in, etc.)
   ↓
Authoritative DNS
   ↓
IP address

The root server points the resolver toward the correct top-level domain (TLD) servers.

The TLD server knows which authoritative DNS servers are responsible for a domain.

The authoritative DNS server contains the actual DNS records for that domain.

For an AWS-hosted application, Amazon Route 53 can act as the authoritative DNS service.

Common DNS records

A record

Maps a name to an IPv4 address:

example.com → 13.235.10.20

AAAA record

Maps a name to an IPv6 address:

example.com → 2406:da1a:abcd::1

CNAME

Maps one hostname to another hostname:

www.example.com → example.com

MX

Specifies which mail servers handle email for a domain.

NS

Specifies the authoritative name servers for a DNS zone.

DNS can also support routing strategies such as geolocation, latency-based routing, weighted routing, and failover.

What is an IP address?

An IP address identifies a network interface or host on an IP network.

Think of it like a building address.

IP address = Which machine / network endpoint?

For example:

13.235.10.20

There are two major IP versions you will encounter.

IPv4

IPv4 uses 32-bit addresses.

Example:

192.168.1.10

There are about 4.3 billion possible IPv4 addresses, which is why the internet also uses techniques such as private addressing and NAT.

IPv6

IPv6 uses 128-bit addresses.

Example:

2406:da1a:abcd:1234::1

IPv6 provides an enormous address space and is increasingly supported across modern networks.

In practice, applications can support both using dual-stack networking.

What is a port?

An IP address identifies the machine or network endpoint. A port identifies the network service/application endpoint on that machine.

Think:

IP   = Building address
Port = Specific door

For example:

13.235.10.20:443

means:

Server → 13.235.10.20
Service → port 443

Some common ports are:

Port	Common use
80	HTTP
443	HTTPS
22	SSH
53	DNS
3306	MySQL
5432	PostgreSQL
6379	Redis

Port numbers are conventions, not permanent requirements. An application can be configured to listen on another port.

TCP: reliable, ordered communication

TCP (Transmission Control Protocol) provides a connection-oriented, reliable byte stream.

It handles things such as:

• Establishing a connection
• Acknowledging received data
• Retransmitting lost data
• Keeping data in order
• Detecting transmission problems
• Controlling the rate of transmission

Imagine packets:

1 → 2 → 3 → 4 → 5

If packet 3 is lost, TCP can retransmit it.

The important consequence is that the application sees an ordered stream. Data that arrives later can be buffered while missing earlier data is recovered.

This reliability makes TCP a good fit for things where losing or reordering data is unacceptable, such as:

• Web traffic using HTTP/1.1 or HTTP/2
• SSH
• Database connections
• Many file transfers

TCP trade-off

TCP's reliability requires additional protocol work. Retransmissions and waiting for missing data can add latency.

For a real-time application, waiting for old data can sometimes be worse than skipping it.

UDP: lightweight datagrams

UDP (User Datagram Protocol) is connectionless and has much less built-in reliability machinery.

A sender can send datagrams without TCP-style connection establishment, acknowledgements, or retransmission guarantees.

Sender
  │
  ├── Packet 1 ──────→
  ├── Packet 2 ──────→
  ├── Packet 3 ──X
  └── Packet 4 ──────→

If packet 3 is lost, UDP itself does not automatically retransmit it.

This can make UDP useful when low overhead and timeliness matter more than perfect delivery, including:

• Real-time voice
• Real-time video
• Online gaming
• Certain streaming and networking protocols

UDP does not mean that an application can never be reliable. A higher-level protocol can implement its own reliability on top of UDP.

A modern example is QUIC, which runs over UDP and provides features such as reliable streams and encryption. HTTP/3 uses QUIC.

TCP vs UDP: which should you use?

A useful question is:

If some data is lost, do I need that exact data to be retransmitted before continuing?

If yes, a reliable transport such as TCP may be appropriate.

Examples:

Database query
SSH command
File transfer
Traditional HTTPS

If timeliness is more important than perfect delivery, UDP or a UDP-based protocol may be appropriate.

Examples:

Real-time voice
Gaming
Real-time media
QUIC / HTTP/3

There is no universal rule that one is always faster or better. The correct choice depends on the application's requirements.

HTTP: how web applications communicate

HTTP (HyperText Transfer Protocol) is an application-layer request-response protocol.

A browser can send:

GET /products HTTP/1.1
Host: example.com

The server might respond:

HTTP/1.1 200 OK

followed by the requested content.

HTTP is also the foundation of many APIs.

Common HTTP methods include:

• GET — retrieve data
• POST — submit/create data
• PUT — replace/update a resource
• PATCH — partially update a resource
• DELETE — remove a resource

Common status codes include:

• 200 OK — successful request
• 201 Created — resource created
• 400 Bad Request — invalid request
• 401 Unauthorized — authentication is required or invalid
• 403 Forbidden — request is not allowed
• 404 Not Found — resource was not found
• 500 Internal Server Error — server-side failure

HTTPS: HTTP with TLS protection

HTTPS is HTTP protected by TLS (Transport Layer Security).

A simplified stack for traditional HTTPS is:

HTTP
 ↓
TLS
 ↓
TCP
 ↓
IP

TLS provides:

• Encryption — helps prevent others from reading traffic
• Authentication — certificates help verify the server's identity
• Integrity — helps detect tampering with data in transit

This is why modern websites should use:

https://example.com

rather than plain:

http://example.com

HTTPS normally uses port 443, while HTTP normally uses port 80.

TLS handshake in simple terms

Before encrypted application data can be exchanged, the client and server establish a secure TLS session.

A simplified view:

Browser                         Server

   ClientHello  ───────────────→

                ←────────────── ServerHello
                ←────────────── Certificate

   Key establishment / verification
                ↕
   Secure session established

   🔒 Encrypted HTTP data
                ↔

TLS uses asymmetric cryptography during the setup/authentication process and then uses efficient symmetric cryptography for the bulk of the session data.

This combination gives you secure communication without using expensive public-key operations for every byte of application data.

TLS termination at a load balancer

In a production AWS architecture, TLS is often terminated at the Application Load Balancer (ALB) or at a CDN such as CloudFront.

For example:

Browser
   │
   │ HTTPS :443 🔒
   ▼
ALB
   │
   │ HTTP :3000
   ▼
EC2

The ALB holds the TLS certificate, decrypts the incoming HTTPS request, and forwards the request to a healthy backend target.

AWS Certificate Manager (ACM) can be used to manage certificates for supported AWS services.

This reduces the need to make every backend instance handle public TLS directly.

For environments that require encryption between the load balancer and backend servers, the second hop can also use HTTPS:

Browser
   │ HTTPS 🔒
   ▼
ALB
   │ HTTPS 🔒
   ▼
EC2

What is latency?

Latency is the time it takes for data or a request to travel between two points.

Think of it as network delay.

Browser ───────────────→ Server
          ↑
        latency

If a server is geographically far away, network latency can increase.

For example:

User in India → Mumbai server

may have lower network latency than:

User in India → US server

Latency is one reason large applications use:

• CDNs
• Caching
• Multiple regions
• Data replication
• Load balancing
• Latency-based DNS routing

Global traffic and DNS

Suppose an application is deployed in multiple regions:

                 DNS
                  │
       ┌──────────┼──────────┐
       ▼          ▼          ▼
    Mumbai      London      Virginia
       │          │          │
      ALB        ALB        ALB

DNS routing policies can help direct users toward an appropriate region.

Geolocation routing can use configured geographic rules, such as:

India → Mumbai
USA → Virginia

Latency-based routing instead attempts to send users to the region that provides the lowest measured network latency among the configured regions.

Health checks and failover policies can also help move traffic away from an unhealthy endpoint.

How all the concepts connect

Now put everything together.

When a user opens a modern web application:

                    Browser
                       │
                       │ 1. Domain
                       ▼
                     DNS
                       │
                       │ 2. IP
                       ▼
                IP + Port :443
                       │
                       ▼
                    TCP
                       │
                       ▼
                     TLS
                       │
                       ▼
                    HTTPS
                       │
                       ▼
             Load Balancer / CDN
                       │
                       ▼
                  Backend EC2
                       │
                       ▼
                    Database

A more AWS-oriented production flow can look like:

User
  │
  ▼
Route 53
  │
  ▼
CloudFront / ALB
  │
  ├── WAF / security controls
  │
  ▼
Target Group
  │
  ├── EC2-1
  ├── EC2-2
  └── EC2-3
        │
        ▼
     Database

Each component has a different responsibility:

Concept	Simple meaning
Client	The application asking for something
Server	The system responding to the request
DNS	Finds the network destination for a domain
IP	Identifies the network destination
Port	Identifies a service endpoint
TCP	Reliable, ordered transport
UDP	Lightweight datagram transport
HTTP	Web request-response protocol
HTTPS	HTTP protected by TLS
TLS	Encrypts and authenticates communication
Latency	Network delay between two points

The easiest mental model

Imagine sending a package:

Domain
   ↓
"What's the address?"
   ↓
DNS
   ↓
IP address
   ↓
"Which door/service?"
   ↓
Port
   ↓
"How should the package travel?"
   ↓
TCP / UDP
   ↓
"What language does the application speak?"
   ↓
HTTP / HTTPS
   ↓
Server

The important thing is that these aren't competing technologies. They operate at different layers and solve different problems.

That's why understanding the flow is more useful than memorizing definitions:

Domain
  ↓
DNS
  ↓
IP + Port
  ↓
TCP/UDP
  ↓
TLS
  ↓
HTTP
  ↓
Server

For a production web application, this chain is the foundation behind everything from a simple React app to a globally distributed AWS architecture.