Internet Fundamentals

A simple, visual revision guide based on my Week 1 Computer Systems / Internet learning.

Goal: Understand the ideas behind the Internet instead of memorizing protocol names.

0. The Big Picture

When you open a website, it feels like one simple action:

Type a URL → press Enter → website appears.

But underneath, many different systems work together:

Your Browser
    ↓
DNS → "Where is this website?"
    ↓
IP → "Which machine should I reach?"
    ↓
Routers → "Which path should the packets take?"
    ↓
TCP / UDP → "How should the data be transported?"
    ↓
TLS → "Can this communication be protected?"
    ↓
HTTP → "What does the browser want?"
    ↓
Web Server
    ↓
HTTP Response
    ↓
Your Browser

The important idea is:

The Internet is not one single technology. It is many layers of technologies working together.

1. Before the Internet: Computers Were Alone

ENIAC — A Computer With No Network

One of the early general-purpose electronic computers was ENIAC, completed in the 1940s.

It was huge, powerful for its time, and had no modern keyboard, monitor, operating system, or network connection.

Programming it involved physical switches and cables.

ENIAC

Why does this matter?

Because the first networking problem was not:

"How do we make the Internet?"

It was much simpler:

"How do we make computers communicate with each other?"

One computer could calculate.

But once many computers existed, another problem appeared.

2. The Sneakernet Problem

Imagine two universities have computers hundreds of kilometres apart.

Computer A produces a file that Computer B needs.

There is no network.

So what do you do?

You copy the data to something physical:

Then a person physically carries it.

Computer A
   │
   │ copy data
   ▼
Punch Cards / Magnetic Tape
   │
   │ human carries it
   ▼
Computer B

This is often called Sneakernet.

Real-world example

Imagine you want to send a 2 GB project folder from Kolkata to Mumbai, but the only option is:

Copy it to a hard drive → put the hard drive in a bag → send a person to Mumbai.

It works.

But it is slow, inconvenient, and does not scale.

The better idea was obvious:

Why not connect the computers directly?

That problem pushed computer networking forward.

3. ARPANET — Connecting Computers

In the late 1960s, ARPANET became one of the major early packet-switched computer networks.

The first four nodes were:

In October 1969, the first message sent between UCLA and SRI was intended to be:

LOGIN

But the system crashed after:

LO

Early ARPANET

The important lesson is not just the famous "LO" story.

ARPANET showed that computers could communicate over a network instead of depending on physically carrying data.

4. Circuit Switching vs Packet Switching

This is one of the most important ideas behind computer networking.

Circuit Switching

Traditional telephone systems used the idea of creating a dedicated path.

Person A ================= Person B
          one fixed path

The path is reserved for the communication.

If an important part of that path fails, the communication can fail.

Packet Switching

The Internet uses packet switching.

Instead of treating your entire message as one giant thing, data is divided into smaller pieces called packets.

Large message

        ↓

[Packet 1] [Packet 2] [Packet 3] [Packet 4]

Those packets can travel through a network of routers.

Packet switching

A simplified idea:

              Router B
             /         \
Sender → Router A       Router D → Receiver
             \         /
              Router C

If one path becomes unavailable, routing can potentially use another path.

Real-world example

Think about sending a 100-page book.

Circuit-style idea:

Put the entire book in one truck and send it through one fixed route.

Packet-style idea:

Split the book into numbered envelopes:

Page 1  → Envelope 1
Page 2  → Envelope 2
Page 3  → Envelope 3
...
Page 100 → Envelope 100

Different envelopes may take different routes.

The receiver puts them back together.

Why packets?

Because many users can share the same network infrastructure.

The network does not need to reserve one entire physical path for one conversation.

5. The Next Problem: Different Networks Could Not Easily Talk

ARPANET was not the only network.

Other networks existed too.

They could use different internal technologies.

So another problem appeared:

How do we connect different networks together?

This is where internetworking becomes important.

The idea eventually developed into the TCP/IP protocol suite.

The word Internet itself comes from the idea of connecting/interconnecting networks.

A useful mental model:

Network A
   │
   │
 Gateway / Router
   │
   │
Network B
   │
   │
 Gateway / Router
   │
   │
Network C

Each network can have its own internal technology.

The common Internet protocols provide a way for them to communicate.

6. IP — Giving Data an Address

If you want to send a letter, you need an address.

Networking has a similar idea.

An IP address identifies a destination on an IP network.

Very simplified:

Source IP
   ↓
Router
   ↓
Router
   ↓
Router
   ↓
Destination IP

Routers look at destination information and make forwarding decisions.

Important distinction

IP answers:

"Which host/network should this packet go toward?"

It does not answer:

"Which application on that computer should receive it?"

That is where ports become useful.

7. IP Address vs Port

Imagine a large apartment building.

IP Address  = Building address
Port Number = Specific flat/room

For example:

IP:   192.168.1.50
Port: 443

The IP helps identify the machine.

The port helps identify the network service/process that should receive the traffic.

A computer can have many applications communicating at the same time:

Ports help the operating system deliver incoming traffic to the correct application.

Common web ports

Port Common use
80 HTTP
443 HTTPS
8080 Common alternative HTTP/development port

8. DNS — Humans Like Names, Computers Use Addresses

Imagine you had to remember an IP address for every website you visit.

Instead of:

142.x.x.x

you want to type:

example.com

This is where DNS (Domain Name System) helps.

DNS translates a domain name into information such as an IP address.

DNS

A simplified flow:

You type:

example.com
     ↓
Browser / OS checks cache
     ↓
DNS Resolver
     ↓
DNS hierarchy
     ↓
Authoritative DNS server
     ↓
IP address
     ↓
Browser can contact the destination

DNS is more than "the Internet phonebook"

The phonebook analogy is useful, but DNS is actually a distributed hierarchical system.

Think of it like a tree:

                    Root
                     │
                    .com
                     │
                example.com
                     │
                DNS records

This structure allows the system to scale much better than maintaining one giant list on one computer.

9. How a Domain Lookup Can Work

Suppose you type:

example.com

A simplified lookup can involve:

Step 1 — Root

The resolver asks:

"Who handles .com?"

Step 2 — TLD

The .com system points toward the authoritative nameserver for the domain.

Step 3 — Authoritative DNS

The authoritative server has the actual DNS record.

It can answer:

"This domain currently points to this IP."

Then the resolver returns the result to your device and may cache it.

10. From Your Laptop to a Server: Hops

Your data usually does not travel directly from your laptop to the destination server.

It can pass through multiple networks and routers.

A simplified journey:

Your Laptop
    ↓
Home / Mobile Network
    ↓
ISP
    ↓
Other Networks / Backbone
    ↓
Internet Exchange / Peering
    ↓
Data Center / Cloud Network
    ↓
Server

Each router makes forwarding decisions based on network information.

Try it yourself

On Windows:

tracert example.com

On macOS/Linux:

traceroute example.com

This can show the sequence of network hops observed from your machine toward the destination.

11. Internet vs World Wide Web

These two words are often used as if they mean the same thing.

They are not exactly the same.

Internet

The Internet is the underlying global network infrastructure and protocols that allow networks and devices to communicate.

Web

The World Wide Web is a service built on top of the Internet.

A simple analogy:

Internet = Roads + infrastructure

Web = One type of service using those roads

The Web uses technologies such as:

So:

The Internet is the infrastructure. The Web is one major thing built on that infrastructure.

12. Now the Web Layer: HTTP

Suppose your browser wants:

/index.html

It needs a standard way to tell the server what it wants.

That is where HTTP — Hypertext Transfer Protocol comes in.

HTTP is an application-layer protocol.

It defines things such as:

A simplified HTTP conversation:

Browser → Server

GET /index.html
Host: example.com


Server → Browser

HTTP/1.1 200 OK

<html>
...
</html>

The browser says:

"Give me this resource."

The server replies:

"Here is the result."

13. HTTP Methods

Some common HTTP methods:

Method Simple meaning
GET Give me a resource
POST Send data / create something
PUT Replace a resource
DELETE Delete a resource

Real-world example

Imagine an online store.

GET /products

"Show me the products."

GET /products/42

"Show me product 42."

POST /orders

"Create an order using this data."

HTTP gives applications a common language for these interactions.

14. HTTP Status Codes

The server also communicates what happened.

Common examples:

200 OK

Everything worked.

404 Not Found

The requested resource was not found.

500 Internal Server Error

Something went wrong on the server.

Think of status codes as short answers from the server:

"Success."

"I couldn't find it."

"Something broke on my side."

15. TCP vs HTTP — They Are Not Competitors

A very common beginner confusion is:

"Should I use TCP or HTTP?"

They solve different problems.

A simple analogy:

HTTP is the message. TCP is part of the delivery system carrying that message.

Think about sending a contract.

HTTP
= What the message means

TCP
= How the bytes are transported reliably

HTTP can say:

GET /products

TCP does not care that this means "give me products."

TCP sees bytes.

Layer view

Application Layer
        HTTP
         ↓
Transport Layer
      TCP / UDP
         ↓
Network Layer
         IP
         ↓
Link / Physical
 Ethernet / Wi-Fi / 5G / Fibre

The source notes describe HTTP as application-layer and TCP as transport-layer, with IP below them. fileciteturn3file1L11-L25

16. Encapsulation — Data Gets Wrapped Layer by Layer

When a browser sends data, it is not simply thrown onto the cable as "HTTP."

The data gets wrapped as it moves down the networking stack.

A simplified view:

HTTP data
   ↓
TCP segment
   ↓
IP packet
   ↓
Link-layer frame
   ↓
Physical transmission

The receiver performs the reverse process:

Physical data
   ↓
Frame
   ↓
IP packet
   ↓
TCP data
   ↓
HTTP message

This wrapping process is called encapsulation.

The uploaded TCP vs HTTP notes describe this as HTTP payload being carried inside TCP, TCP inside IP, and IP inside a link-layer frame. fileciteturn3file1L49-L59

17. TCP — Reliability

Networks are not perfect.

Packets can be:

TCP exists to provide a reliable, ordered byte stream between endpoints.

TCP uses mechanisms such as:

The current TCP specification is documented by the IETF in RFC 9293. citeturn1search1

18. TCP's 3-Way Handshake

Before normal TCP data transfer begins, TCP establishes a connection.

A simplified handshake:

Client                         Server

   SYN  -------------------->

        <-------------------  SYN + ACK

   ACK  -------------------->

          Connection ready

What is the basic idea?

Both sides establish that they can communicate and synchronize connection state.

You do not need to memorize the packet details immediately.

Remember:

TCP performs a handshake before normal data transfer.

19. TCP Reliability in Simple Terms

Imagine sending a numbered set of pages:

1  2  3  4  5

Suppose page 3 is lost.

TCP can detect that something is missing and arrange for the missing data to be retransmitted.

It also keeps data ordered for the application.

So the application can receive:

1 → 2 → 3 → 4 → 5

rather than randomly receiving pieces with no ordering guarantee.

20. UDP — When Speed Matters More

UDP is much simpler than TCP.

It does not provide TCP's connection setup, reliable retransmission, or ordered byte-stream guarantees.

The original UDP specification describes it as a minimal datagram mechanism on top of IP. citeturn1search2

TCP mindset

"If something is missing, I need to recover it."

UDP mindset

"Send the datagram. Keep moving."

This can be useful when low delay matters more than perfect delivery.

21. TCP vs UDP — The Real Tradeoff

TCP UDP
Connection-oriented Connectionless
Reliable delivery mechanisms Best-effort delivery
Ordered byte stream Individual datagrams
Retransmission No built-in retransmission
More protocol overhead Very small header
Useful when completeness matters Useful when low latency matters

The source notes highlight examples such as web traffic and file transfer for TCP, and real-time voice/video and some gaming traffic for UDP. fileciteturn3file2L123-L148

22. Real-World Example: Why UDP Can Make Sense for a Call

Imagine you are on a live voice call.

You say:

"Can you hear me?"

One tiny piece of audio gets lost.

If the system waits too long to recover that old piece, the conversation becomes delayed.

For real-time communication:

Slightly damaged audio now
        can be better than
Perfect audio 2 seconds late

That is why real-time systems may prefer a transport designed around low latency.

Modern WebRTC, for example, commonly uses UDP-based transport mechanisms.

23. Head-of-Line Blocking

TCP's ordered delivery is useful, but it has a consequence.

Imagine:

Packet 1 ✓
Packet 2 ✗ LOST
Packet 3 ✓
Packet 4 ✓
Packet 5 ✓

Because TCP provides an ordered byte stream, later data cannot simply be delivered to the application as if packet 2 did not exist.

It may have to wait for the missing data.

This is one form of Head-of-Line (HoL) blocking.

The source notes use this as an important limitation of TCP's strict ordering. fileciteturn3file2L109-L119

24. HTTP/1.1 → HTTP/2 → HTTP/3

HTTP itself has evolved.

HTTP/1.1

Introduced persistent connections, allowing multiple requests to reuse a TCP connection instead of opening a new connection for every request.

HTTP/2

Introduced binary framing and multiplexing, allowing multiple HTTP streams to share a connection.

HTTP/3

Uses QUIC, which runs over UDP, instead of TCP.

This is an important correction to a common simplified statement:

HTTP is not permanently tied to TCP.

HTTP/3 uses QUIC over UDP, while HTTP/2 commonly runs over TLS and TCP. RFC 9110 describes HTTP's semantics independently of the particular transport and notes the HTTP/3 + QUIC relationship. citeturn1search0

25. HTTP vs HTTPS

Now we have HTTP.

But there is a serious problem.

Normal HTTP traffic does not provide the cryptographic protection that HTTPS provides.

If sensitive information travels over an unsecured HTTP connection, someone able to observe the traffic may be able to read or interfere with it.

HTTPS solves this by using TLS (Transport Layer Security).

HTTPS = HTTP secured with TLS

MDN describes TLS as providing encryption, integrity, and authentication for secure communication across an untrusted network. citeturn1search5

26. HTTP vs HTTPS in One Picture

HTTP

Browser
   │
   │ readable HTTP data
   ↓
Network
   │
   ↓
Server

With HTTPS:

Browser
   │
   │ TLS-protected data
   ↓
Network
   │
   ↓
Server

The network still carries the traffic.

But the HTTP content is protected inside the secure connection.

27. The Three Big Security Goals of HTTPS

TLS provides three important properties:

1. Confidentiality

Others should not be able to simply read the protected data in transit.

Example:

Password: mypassword123

should not travel as readable plaintext across the network.

2. Integrity

The receiver should be able to detect unauthorized modification of protected data.

In simple words:

"Did somebody change this data while it was travelling?"

3. Authentication

Your browser needs a way to verify that it is communicating with the intended website.

This is where digital certificates and the certificate trust system become important.

28. Certificates — How Does the Browser Trust a Website?

When you visit an HTTPS website, the server presents a digital certificate.

A certificate contains information that helps establish the identity of the website and its public key.

Certificates are issued within a chain of trust, involving trusted Certificate Authorities (CAs).

A simplified picture:

Trusted Root CA
      ↓
Intermediate CA
      ↓
Website Certificate
      ↓
example.com

Your operating system and/or browser maintains trusted root certificates.

If the certificate is invalid, expired, incorrectly issued, or does not match the website, the browser can warn you.

29. Why Do Browsers Show "Your Connection Is Not Private"?

You may have seen:

Your connection is not private

This can happen when the browser cannot establish the expected certificate trust.

For example:

The important lesson:

The browser is checking whether the secure connection can be trusted.

30. HTTPS Uses More Than One Kind of Cryptography

A useful high-level idea is that HTTPS/TLS combines different cryptographic techniques.

Asymmetric cryptography

Useful for authentication and establishing shared secrets.

But it is relatively expensive for bulk data encryption.

Symmetric cryptography

Very efficient for encrypting large amounts of data once both sides have established a shared secret.

So, simplified:

Connection setup
       ↓
Authentication + key agreement
       ↓
Shared session keys
       ↓
Fast encrypted communication

This is why you should not think:

"HTTPS just encrypts everything with the website's public key."

The real system is more sophisticated.

31. Port 80 vs Port 443

A useful beginner memory:

HTTP
Port 80

HTTPS
Port 443

These are the default ports associated with the HTTP and HTTPS URI schemes. citeturn1search0

But remember:

A port number does not magically make a protocol secure.

The security comes from the protocol configuration and cryptographic mechanisms being used.

32. Putting Everything Together: What Happens When You Open a Website?

Now imagine you type:

https://example.com

A simplified journey looks like this:

Step 1 — Browser reads the URL

It knows:

Protocol: HTTPS
Domain: example.com
Resource: /

Step 2 — DNS

The system finds the destination IP information for the domain.

example.com
     ↓
DNS
     ↓
IP address

Step 3 — Network routing

Packets travel through your local network, ISP, and other networks toward the destination.

Laptop
  ↓
Router
  ↓
ISP
  ↓
Other routers
  ↓
Server network

Step 4 — Transport connection

Depending on the HTTP version and stack, the communication may use TCP or QUIC/UDP.

For a traditional HTTP/1.1 or HTTP/2 setup:

TCP connection

Step 5 — TLS

For HTTPS, TLS establishes a protected connection.

Browser ↔ Server
      secure channel

Step 6 — HTTP request

The browser can send something like:

GET /

Step 7 — Server responds

The server returns an HTTP response.

200 OK

along with content.

Step 8 — Browser builds the page

The HTML may reference:

The browser fetches the required resources and builds what you see.

33. One Complete Mental Model

Keep this picture in your head:

                YOU
                 │
                 ▼
             BROWSER
                 │
                 │ "Where is example.com?"
                 ▼
                DNS
                 │
                 │ IP address
                 ▼
              ROUTERS
                 │
                 │ packets
                 ▼
        TCP / UDP / QUIC
                 │
                 │ transport
                 ▼
            TLS (HTTPS)
                 │
                 │ secure communication
                 ▼
               HTTP
                 │
                 │ GET / POST / ...
                 ▼
              SERVER

Each layer answers a different question.

Layer / System Main question
DNS Where is this domain?
IP Which destination/network?
Router Where should this packet go next?
TCP How can bytes be delivered reliably and in order?
UDP Can we send datagrams with minimal transport overhead?
TLS How can this communication be protected and authenticated?
HTTP What does the application want?
Browser How do I turn the response into something the user can see?

34. The Most Important Distinctions

Internet vs Web

Internet: The global networking infrastructure.

Web: A service built on top of the Internet.

IP vs TCP

IP: Helps move packets between networked hosts.

TCP: Provides a reliable, ordered byte stream between endpoints.

TCP vs UDP

TCP: Reliability and ordering.

UDP: Minimal transport mechanism and low overhead; applications decide what they need on top.

TCP vs HTTP

TCP: Transport.

HTTP: Application protocol.

They do not compete.

HTTP vs HTTPS

HTTP: Web protocol.

HTTPS: HTTP protected by TLS.

Domain Name vs IP Address

Domain: Human-friendly name.

IP address: Network-level address used for routing.

35. A Simple Real-World Analogy

Imagine sending a package to a friend.

DNS

You know your friend's name, but need their address.

"Where does this person live?"

IP

The address tells the delivery system where the destination is.

Router

Each local delivery centre decides:

"Where should this package go next?"

TCP

You want a reliable delivery process:

"Did you receive everything? If something is missing, send it again."

UDP

You are sending live announcements:

"Send it quickly. Don't stop everything to resend old information."

TLS

You put sensitive information inside a locked container.

HTTP

You specify what you want:

"Please give me the product list."

Server

The destination receives the request and prepares the response.

36. The Timeline to Remember

1940s
ENIAC
│
│ Computers exist, but are isolated
▼
1950s
Multiple computers
│
│ Data carried physically
▼
1960s
Packet switching + ARPANET
│
│ Computers begin communicating
▼
1970s
TCP/IP research
│
│ Different networks can interconnect
▼
1983
TCP/IP becomes the ARPANET standard
│
│ Internet architecture grows
▼
1983
DNS
│
│ Human-friendly names become practical
▼
1980s–1990s
ISPs + larger interconnected networks
│
▼
1990s
World Wide Web
│
│ HTTP + HTML + URLs + browsers
▼
Today
Web applications + APIs + cloud + mobile + streaming + AI systems

The uploaded Internet notes use the same broad "problem → solution" progression: isolated computers → Sneakernet → ARPANET → packet switching → TCP/IP → DNS → ISPs/routing → Web. fileciteturn3file3L301-L318

37. The "Why" Behind the Vocabulary

Instead of memorizing:

IP, DNS, TCP, UDP, HTTP, HTTPS, TLS, ports...

remember the problems.

Problem: Humans cannot remember IP addresses

→ DNS

Problem: Packets need to reach the correct destination

→ IP + routing

Problem: Multiple applications share one machine

→ Ports

Problem: Data may be lost or arrive out of order

→ TCP can provide reliable ordered delivery.

Problem: Some applications care more about low delay than retransmission

→ UDP can provide a minimal datagram transport.

Problem: The web needs a standard language between browser and server

→ HTTP

Problem: HTTP communication needs protection against reading and modification in transit

→ TLS → HTTPS

This is the mental model worth remembering.

38. Quick Revision Sheet

Internet

A global system of interconnected networks.

Packet

A small unit of data sent across a network.

IP

Provides addressing and packet forwarding at the Internet layer.

Port

Identifies a network service/process on a host.

DNS

Maps domain names to DNS information such as IP addresses.

Router

Forwards packets toward their destinations.

TCP

Reliable, ordered byte-stream transport.

UDP

Minimal, connectionless datagram transport.

HTTP

Application protocol used for communication on the Web.

HTTPS

HTTP secured using TLS.

TLS

Provides confidentiality, integrity, and authentication for secure communication.

Web

A service built on top of the Internet using technologies such as HTTP, HTML, URLs, and browsers.

39. Final Mental Picture

If you remember only one thing, remember this:

        HUMAN
          │
          │ "example.com"
          ▼
         DNS
          │
          │ "Here is the destination IP"
          ▼
      IP + ROUTING
          │
          │ "Move these packets"
          ▼
   TCP / UDP / QUIC
          │
          │ "Transport the data"
          ▼
       TLS / HTTPS
          │
          │ "Protect the communication"
          ▼
         HTTP
          │
          │ "GET /products"
          ▼
        SERVER
          │
          │ response
          ▼
       BROWSER
          │
          ▼
       WEB PAGE

The Internet looks simple from the outside.

Underneath, it is a huge collection of carefully designed solutions to different problems.

Learn the problem first. Then the protocol becomes much easier to remember.

Sources & Further Learning

The explanations above are based primarily on the supplied course notes, with protocol/history details checked against standards and educational references.

A small accuracy note

Some classroom notes use simplified phrases such as "TCP guarantees delivery" or "HTTPS is unbreakable." For learning, the better mental model is: