Course: From Basic Science to Web Hosting

Module 05 — Networking Fundamentals

From DNS to HTTPS: One Complete Web Request

Difficulty: Intermediate
Prerequisites: Lesson 023 — TCP
Estimated time: 45–60 minutes

Now we connect everything learned so far.

We will follow one request:

https://templates.cresignsys.com

from your computer all the way to your Ubuntu server.

---

1. The Big Picture

The complete journey is approximately:

Browser
   ↓
DNS
   ↓
IP address
   ↓
Routing
   ↓
TCP
   ↓
TLS
   ↓
HTTPS
   ↓
Nginx
   ↓
PHP-FPM
   ↓
WordPress
   ↓
MySQL
   ↓
Response
   ↓
Nginx
   ↓
TLS encryption
   ↓
TCP
   ↓
Internet
   ↓
Browser

The important thing is that each layer has a different job.

---

2. You Type the URL

You enter:

https://templates.cresignsys.com

The browser breaks the URL into concepts such as:

Scheme:
https

Hostname:
templates.cresignsys.com

Port:
443

Because HTTPS conventionally uses port:

443

---

3. What Does https:// Mean?

The scheme:

https

means approximately:

HTTP
+
TLS

So:

HTTPS = HTTP carried through TLS protection

For traditional HTTPS:

HTTP
 ↓
TLS
 ↓
TCP
 ↓
IP

---

4. First Problem: Where Is the Server?

Your browser knows:

templates.cresignsys.com

But networking needs an IP address.

Therefore it needs:

DNS

---

5. DNS Translation

Conceptually:

templates.cresignsys.com
             ↓
            DNS
             ↓
        IP address

Suppose, purely as an example, DNS returns:

203.0.113.10

That is an example address, not your actual server IP.

The browser can now attempt to reach:

203.0.113.10:443

---

6. DNS Does Not Create the HTTPS Connection

This distinction is important.

DNS only answers the naming question.

DNS:
"What address belongs to this hostname?"

Then networking takes over:

IP:
"How do I reach that address?"

Then TCP:

"How do I establish a reliable transport connection?"

Then TLS:

"How do I establish a secure cryptographic session?"

Then HTTP:

"What web resource do I want?"

---

7. DNS Caching

The browser or operating system may already know the DNS answer from a cache.

Therefore the browser does not necessarily perform a complete DNS lookup every time you type the URL.

Possible caches include:

Browser cache
 ↓
Operating-system cache
 ↓
Local resolver
 ↓
Recursive DNS resolver
 ↓
Authoritative DNS server

We will study this entire chain in a later lesson.

---

8. Browser Has the IP

Now suppose the browser has:

Server:
203.0.113.10

and:

Port:
443

The next goal is:

Create TCP connection

---

9. TCP Connection

The browser’s operating system creates a TCP connection.

Conceptually:

Client
192.0.2.20:53000

       ↓

Server
203.0.113.10:443

Again, these are illustrative addresses.

---

10. TCP SYN

The client sends:

SYN

Conceptually:

Browser/OS
     │
     │ SYN
     ▼
Server

This is a TCP segment carried inside an IP packet and then a link-layer frame.

---

11. TCP SYN-ACK

The server responds:

SYN-ACK

Client
  │
  │ SYN
  ▼
Server
  │
  │ SYN-ACK
  ▼
Client

---

12. TCP ACK

The client sends:

ACK

Client
  │
  │ ACK
  ▼
Server

Now:

TCP connection
=
ESTABLISHED

---

13. Important Point

At this moment:

TCP = working

But:

HTTPS = not yet established

TLS still needs to happen.

---

14. TLS Starts

The browser now begins the TLS handshake.

For modern HTTPS connections, the exact handshake details depend on the TLS version and negotiated options. TLS 1.3 is common today.

Conceptually:

TCP established
      ↓
TLS handshake
      ↓
Secure session

---

15. What Is TLS Trying to Achieve?

TLS provides important security properties including:

Authentication
Confidentiality
Integrity

In simpler language:

Who am I talking to?
 ↓
Can others read the data?
 ↓
Can someone secretly modify the data?

---

16. Your Let’s Encrypt Certificate Enters Here

You recently installed:

templates.cresignsys.com

with a Let’s Encrypt certificate.

Certbot reported:

Certificate:
 /etc/letsencrypt/live/templates.cresignsys.com/fullchain.pem

Private key:
 /etc/letsencrypt/live/templates.cresignsys.com/privkey.pem

These files are now used by your TLS-enabled Nginx configuration.

---

17. Certificate vs Private Key

This distinction is critical.

You have:

fullchain.pem

and:

privkey.pem

They are not the same thing.

Certificate

Contains the server’s public identity information and public key, together with the CA’s signatures/chain information as applicable.

Private key

Secret cryptographic material that must remain protected on the server.

Conceptually:

Certificate
   ↓
Public information
   ↓
Can be sent to clients

Private key
   ↓
SECRET
   ↓
Must remain on server

---

18. Why Does the Browser Trust Let’s Encrypt?

Your browser/operating system has a set of trusted:

Root Certificate Authorities

Let’s Encrypt operates a certificate authority hierarchy.

Conceptually:

Trusted Root CA
      ↓
Intermediate CA
      ↓
Your server certificate
      ↓
templates.cresignsys.com

The browser checks the certificate chain against its trusted CA store.

The exact current chain can vary by certificate issuance and client environment.

---

19. Certificate Identity

Your certificate contains identity information for the domain, typically through:

Subject Alternative Name

For example:

DNS:
templates.cresignsys.com

The browser checks whether the hostname it requested matches the certificate’s valid names.

So:

Browser requests:

templates.cresignsys.com

and checks:

Certificate valid for:
templates.cresignsys.com

---

20. Certificate Validity Period

Your Certbot output said:

This certificate expires on 2026-11-11.

That means the certificate has a defined validity period.

Certbot also configured automatic renewal.

Conceptually:

Certificate
     ↓
valid
     ↓
renew before expiration
     ↓
new certificate
     ↓
Nginx uses renewed certificate

---

21. Certificate Does Not Encrypt Everything by Itself

This is a very important correction to a common beginner misunderstanding.

The certificate is not simply:

"the encryption"

Instead, TLS uses certificates and cryptographic protocols to authenticate the server and establish cryptographic keys.

Then symmetric encryption is normally used for the bulk data.

Conceptually:

Certificate
      ↓
Authentication / key establishment
      ↓
Session keys
      ↓
Symmetric encryption
      ↓
HTTPS data

---

22. Why Not Encrypt Everything With the Public Key?

Public-key cryptography is computationally more expensive than symmetric cryptography for bulk data.

So TLS uses a combination of cryptographic techniques.

Conceptually:

Asymmetric cryptography
        ↓
Securely establish/authenticate key material

Symmetric cryptography
        ↓
Encrypt large amounts of application data

This is called hybrid cryptography.

---

23. TLS 1.3

Modern TLS commonly uses:

TLS 1.3

It was designed to improve security and reduce unnecessary handshake complexity compared with older TLS versions.

A simplified conceptual handshake:

Client
  │
  │ ClientHello
  ▼
Server
  │
  │ ServerHello + certificate + other handshake data
  ▼
Client
  │
  │ handshake completion
  ▼
Encrypted application data

The exact messages and cryptographic details are more sophisticated than this simplified diagram.

---

24. ClientHello

The browser sends a:

ClientHello

It communicates information needed to negotiate TLS, including supported protocol capabilities and cryptographic parameters.

Conceptually:

Browser
   │
   │ ClientHello
   ▼
Server

---

25. ServerHello

The server responds with a:

ServerHello

The server selects compatible cryptographic parameters.

Conceptually:

Client
   │
   │ ClientHello
   ▼
Server
   │
   │ ServerHello
   ▼
Client

---

26. Server Certificate

The server provides its certificate during the TLS handshake.

Conceptually:

Nginx
 ↓
Certificate
 ↓
Browser

The browser then validates it.

---

27. What Does the Browser Check?

The browser performs several checks.

Conceptually:

Certificate
 ↓
Is it expired?
 ↓
Does hostname match?
 ↓
Is the chain trusted?
 ↓
Is it cryptographically valid?
 ↓
Is the certificate acceptable under current rules?

If something fails, the browser may display a certificate warning/error.

---

28. Certificate Chain

Your:

fullchain.pem

normally contains your server certificate together with the intermediate certificate chain needed by clients.

Conceptually:

Root
 ↓
Intermediate
 ↓
Server certificate

The exact chain presented depends on how the certificate was issued and configured.

---

29. Why fullchain.pem?

Suppose a browser knows/trusts the root but needs the intermediate certificate to build the chain.

The server can provide the necessary chain information.

Conceptually:

Server
 ↓
Server certificate
 ↓
Intermediate certificate
 ↓
Browser
 ↓
Trusted root

This helps the browser build:

Trusted Root
      ↓
Intermediate
      ↓
Server Certificate

---

30. The Private Key

Your:

/etc/letsencrypt/live/templates.cresignsys.com/privkey.pem

contains the private key.

It is used by the TLS implementation for cryptographic operations involved in authentication/key establishment.

It should never be publicly exposed.

Do not paste its contents into chat, websites, or support requests.

---

31. Important Modern TLS Detail

A common beginner explanation says:

“The browser encrypts a session key using the server’s RSA public key.”

That can describe older TLS designs, but it is not the correct general model for modern TLS 1.3.

Modern TLS commonly uses ephemeral Diffie-Hellman key exchange.

Conceptually:

Client ephemeral key
        +
Server ephemeral key
        ↓
Shared secret
        ↓
Session keys

The certificate’s public key authenticates the server’s identity and participates in authentication of the handshake rather than simply encrypting all session keys.

---

32. Diffie-Hellman Idea

The basic mathematical idea is:

Client secret
      +
Server information
      ↓
Shared secret

Server secret
      +
Client information
      ↓
Same shared secret

Neither side needs to send the final shared secret directly across the network.

This is one of the foundational ideas behind modern secure communications.

---

33. Why Is This Powerful?

An observer may see:

Client public information
Server public information

but should not be able to efficiently derive the shared secret without the required private/ephemeral secret information.

This relies on hard mathematical problems and secure cryptographic algorithms.

---

34. Session Keys

Once TLS establishes the required shared secret material, it derives symmetric session keys.

Conceptually:

TLS handshake
      ↓
Shared secret/key material
      ↓
Key derivation
      ↓
Session keys

Then:

HTTP data
 ↓
Symmetric encryption
 ↓
TLS records

---

35. Now HTTP Can Be Sent

The browser can finally send the HTTP request through the encrypted TLS connection.

Conceptually, the browser wants something like:

GET / HTTP/1.1
Host: templates.cresignsys.com

But on the network:

HTTP request
 ↓
TLS encryption
 ↓
Encrypted TLS records
 ↓
TCP
 ↓
IP
 ↓
Network

So an outside observer cannot simply read the HTTP contents from the network traffic.

---

36. Nginx Receives It

The encrypted data reaches:

Your server
 ↓
Network interface
 ↓
Linux kernel
 ↓
TCP
 ↓
TLS
 ↓
Nginx

Nginx’s TLS layer decrypts/authenticates the TLS records.

Then Nginx obtains the HTTP request.

---

37. Nginx Looks at the Hostname

The request contains the hostname:

templates.cresignsys.com

Nginx can use the hostname and its configuration to select the appropriate server block.

This is why one server can host:

site1.example.com
site2.example.com
templates.cresignsys.com

on the same IP address.

This is called:

Name-based virtual hosting

---

38. Nginx Configuration

You have:

/etc/nginx/sites-enabled/templates.cresignsys.com

Nginx reads its enabled configuration.

Conceptually:

Incoming request
       ↓
Port 443
       ↓
TLS
       ↓
Hostname
       ↓
matching server block
       ↓
templates.cresignsys.com configuration

---

39. What Does Nginx Do Next?

It determines how to handle the request.

Possibilities:

Static file

or:

PHP request

or:

Proxy request

For WordPress:

Nginx
 ↓
PHP-FPM

is common.

---

40. Static File Example

Suppose the browser requests:

/favicon.ico

Nginx may simply find:

/storage/websites/templates.cresignsys.com/public/favicon.ico

and return it.

Path:

Browser
 ↓
Nginx
 ↓
Filesystem
 ↓
favicon.ico

PHP isn’t necessary.

---

41. WordPress Request

Suppose the browser requests:

/

Nginx may route the request to WordPress/PHP.

Conceptually:

Browser
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress

---

42. PHP-FPM

PHP-FPM receives the PHP execution request.

Conceptually:

Nginx
 ↓
FastCGI
 ↓
PHP-FPM
 ↓
PHP worker

The worker executes WordPress PHP code.

---

43. WordPress

WordPress loads components such as:

wp-config.php
Core
Theme
Plugins

Then WordPress may need information from the database.

---

44. MySQL

WordPress communicates with MySQL.

Conceptually:

WordPress
   ↓
Database connection
   ↓
MySQL
   ↓
Database

MySQL retrieves required information.

For example:

Posts
Pages
Settings
Users
Plugin data

---

45. The Response Travels Back

The result flows backward:

MySQL
 ↓
WordPress
 ↓
PHP-FPM
 ↓
Nginx

Nginx constructs the HTTP response.

For example:

HTTP/1.1 200 OK
Content-Type: text/html

plus the generated HTML.

---

46. Nginx Does Not Send Plain HTTP Over the Internet

Remember:

HTTP response
 ↓
TLS
 ↓
Encrypted data
 ↓
TCP
 ↓
IP
 ↓
Internet

The browser receives the encrypted TLS records.

---

47. Browser Decrypts

The browser’s TLS implementation processes the received records:

Encrypted TLS records
       ↓
TLS
       ↓
Plain HTTP response
       ↓
HTML
       ↓
Browser rendering

---

48. The Page Appears

Eventually:

HTML
 ↓
CSS
 ↓
JavaScript
 ↓
Images
 ↓
Browser rendering
 ↓
Web page

The user sees:

templates.cresignsys.com

---

49. One Request in One Diagram

Here is the complete conceptual flow:

                    YOUR COMPUTER
                         │
                         ▼
                      Browser
                         │
                         ▼
                        DNS
                         │
                         ▼
                     Server IP
                         │
                         ▼
                       Routing
                         │
                         ▼
                        TCP
                     SYN/ACK
                         │
                         ▼
                        TLS
                  Certificate check
                         │
                         ▼
                    Session keys
                         │
                         ▼
                 Encrypted HTTP
                         │
════════════════════════════════════════════
                     INTERNET
════════════════════════════════════════════
                         │
                         ▼
                  Cloud Network
                         │
                         ▼
                   Ubuntu VPS
                         │
                         ▼
                  Network Interface
                         │
                         ▼
                    Linux Kernel
                         │
                         ▼
                        TCP
                         │
                         ▼
                        TLS
                         │
                         ▼
                       Nginx
                         │
                  ┌──────┴──────┐
                  ▼             ▼
               Static        PHP-FPM
                               │
                               ▼
                            WordPress
                               │
                               ▼
                             MySQL
                               │
                               ▼
                            Response
                               │
                               ▼
                             Nginx
                               │
                               ▼
                         TLS encryption
                               │
                               ▼
                             TCP/IP
                               │
════════════════════════════════════════════
                     INTERNET
════════════════════════════════════════════
                               │
                               ▼
                             Browser
                               │
                               ▼
                         Render webpage

---

50. Where Your SSL Installation Fits

Your recent Certbot output:

Certificate is saved at:
/etc/letsencrypt/live/templates.cresignsys.com/fullchain.pem

Key is saved at:
/etc/letsencrypt/live/templates.cresignsys.com/privkey.pem

fits here:

                  Nginx
                    │
                    ▼
               TLS configuration
                │           │
                ▼           ▼
          fullchain.pem   privkey.pem
                │           │
                └─────┬─────┘
                      ▼
                 TLS handshake
                      │
                      ▼
                Secure session
                      │
                      ▼
              Encrypted HTTPS

So the certificate files are part of the server’s TLS configuration.

They don’t independently “run SSL.”

Nginx + its TLS library + Linux networking + certificate/private key + TLS protocol together provide HTTPS.

---

51. Why Certbot Is Not TLS

Another important distinction:

Let's Encrypt
     ↓
Certificate Authority

and:

Certbot
     ↓
Certificate automation software

and:

Nginx
     ↓
Web server

and:

TLS
     ↓
Security protocol

These are four different things.

---

52. Their Relationship

Conceptually:

Let's Encrypt
      ↓
issues certificate
      ↓
Certbot obtains/renews it
      ↓
certificate installed/configured
      ↓
Nginx uses certificate
      ↓
TLS handshake
      ↓
HTTPS

This distinction will become extremely important when we study Let’s Encrypt in detail.

---

53. The Five Technologies You Just Connected

You now have a clear relationship between:

DNS

Name → IP information

IP

Host/network addressing and routing

TCP

Reliable ordered byte stream

TLS

Authentication + confidentiality + integrity

HTTP

Web application protocol

Together:

DNS
 ↓
IP
 ↓
TCP
 ↓
TLS
 ↓
HTTP

---

54. One Important Exception: HTTP/3

Do not memorize:

HTTPS always means TCP

That is not universally true.

HTTP/3 uses:

HTTP/3
 ↓
QUIC
 ↓
UDP
 ↓
IP

QUIC integrates TLS 1.3 into its connection establishment.

So:

HTTP/1.1 + TLS → commonly TCP
HTTP/2 + TLS   → commonly TCP
HTTP/3         → QUIC over UDP

We will study this later.

For your current foundational model, continue with:

HTTPS
 ↓
TLS
 ↓
TCP

as the traditional HTTPS architecture.

---

55. Troubleshooting Using Layers

This lesson gives you a powerful diagnostic method.

If the website doesn’t work:

Layer 1 — DNS

Does the domain resolve?

Layer 2 — IP

Is the destination reachable?

Layer 3 — Routing

Can packets reach the server?

Layer 4 — TCP

Is port 443 accepting connections?

Layer 5 — TLS

Does the TLS handshake succeed?

Layer 6 — HTTP

Does Nginx return a valid HTTP response?

Layer 7 — Application

Does WordPress/PHP/MySQL work?

This is the foundation of real-world troubleshooting.

---

56. Practical Tests

From your server:

sudo ss -lntp | grep ':443'

This checks whether something is listening on TCP 443.

Check Nginx:

sudo systemctl status nginx

Test Nginx configuration:

sudo nginx -t

Test HTTPS locally:

curl -I https://templates.cresignsys.com

For detailed TLS information:

curl -v https://templates.cresignsys.com

These commands are for inspection/testing; they don’t require you to modify the server.

---

57. What curl -v Helps Reveal

A verbose HTTPS request can expose the sequence at a useful level:

DNS resolution
 ↓
TCP connection
 ↓
TLS handshake
 ↓
Certificate information
 ↓
HTTP request
 ↓
HTTP response

So curl -v is an excellent bridge between theory and your actual hosting server.

---

58. Deep Technology Chain

We can now extend the complete chain:

Physical signals
 ↓
Network interface
 ↓
Ethernet / Wi-Fi
 ↓
IP
 ↓
TCP
 ↓
TLS
 ↓
HTTP
 ↓
Nginx
 ↓
FastCGI
 ↓
PHP
 ↓
WordPress
 ↓
MySQL
 ↓
Filesystem
 ↓
Storage

This is essentially the technology stack you are building your hosting knowledge around.

---

59. The Core Mental Model

Do not memorize hundreds of commands yet.

Understand this:

DOMAIN
  ↓
DNS
  ↓
IP ADDRESS
  ↓
ROUTING
  ↓
PORT
  ↓
TCP
  ↓
TLS
  ↓
HTTP
  ↓
NGINX
  ↓
PHP-FPM
  ↓
WORDPRESS
  ↓
MYSQL
  ↓
FILESYSTEM
  ↓
STORAGE

Once this chain is clear, individual commands become much easier to understand.

---

Next Lesson — 025

DNS From the Deepest Basics

We will now go backward and study the first step in the journey in much greater depth:

Domain name
 ↓
Hostname
 ↓
DNS
 ↓
DNS hierarchy
 ↓
Root servers
 ↓
TLD servers
 ↓
Authoritative nameservers
 ↓
A record
 ↓
AAAA record
 ↓
CNAME
 ↓
NS
 ↓
MX
 ↓
TXT
 ↓
DNS caching
 ↓
TTL
 ↓
Recursive resolver
 ↓
Your domain
 ↓
templates.cresignsys.com

Then we will examine exactly how your templates.cresignsys.com DNS record points toward your server.

Course: From Basic Science to Web Hosting

Module 05 — Networking Fundamentals

TCP From the Deepest Basics

Difficulty: Beginner → Intermediate
Prerequisites: Lesson 022 — Computer Networking
Estimated time: 40–50 minutes

We now know:

Application
   ↓
TLS
   ↓
TCP
   ↓
IP
   ↓
Network

Today we will understand TCP itself, starting from the most basic idea.

---

1. The Problem TCP Solves

Imagine your computer wants to send:

HELLO

to another computer.

At the simplest level:

Computer A
     ↓
   HELLO
     ↓
Computer B

But real networks have problems.

Data can be:

Lost
Delayed
Duplicated
Received out of order

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

---

2. IP Alone Is Not Enough

IP mainly provides packet delivery between hosts/networks.

Imagine sending:

Packet 1
Packet 2
Packet 3

IP does not by itself provide the complete reliable-stream behavior that applications often need.

You could have:

Packet 1 → arrives
Packet 2 → lost
Packet 3 → arrives

TCP adds mechanisms to handle such situations.

---

3. TCP’s Main Responsibilities

TCP provides mechanisms for:

Connection establishment
 ↓
Reliable delivery
 ↓
Ordering
 ↓
Retransmission
 ↓
Flow control
 ↓
Congestion control
 ↓
Connection termination

---

4. TCP Is a Transport Protocol

Remember the networking layers:

Application
     ↓
Transport
     ↓
Internet
     ↓
Link

TCP belongs here:

Transport Layer
       ↓
      TCP

IP belongs here:

Internet Layer
       ↓
       IP

---

5. TCP Does Not Know About Your Website

TCP does not understand:

WordPress
HTML
CSS
JavaScript
TLS certificates
Nginx

TCP only provides transport behavior.

Conceptually:

HTTP/TLS
   ↓
TCP
   ↓
IP

TCP doesn’t need to know what the bytes mean.

---

6. Bytes

TCP provides an ordered stream of bytes.

Suppose an application wants to send:

HELLOWORLD

TCP sees data as bytes:

H E L L O W O R L D

It does not fundamentally understand this as words.

---

7. Byte Stream

This is important.

TCP provides:

Ordered byte stream

not a message-by-message protocol.

For example, an application might write:

HELLO

then:

WORLD

The receiving application sees an ordered stream:

HELLOWORLD

TCP itself does not preserve those application write boundaries.

---

8. TCP Uses Segments

TCP divides the byte stream into units called:

TCP Segments

Conceptually:

Application data
       ↓
TCP
       ↓
┌─────────────┐
│ TCP segment │
└─────────────┘
       ↓
      IP

A TCP segment contains:

TCP header
+
payload

---

9. TCP Header

A simplified TCP segment looks like:

┌──────────────────────────────┐
│ Source Port                  │
│ Destination Port             │
├──────────────────────────────┤
│ Sequence Number              │
├──────────────────────────────┤
│ Acknowledgment Number        │
├──────────────────────────────┤
│ Flags                        │
├──────────────────────────────┤
│ Window                       │
├──────────────────────────────┤
│ Other TCP information        │
├──────────────────────────────┤
│ Application Data             │
└──────────────────────────────┘

We will examine each important field.

---

10. Source Port

The source port identifies the sending application’s transport endpoint.

Example:

Source port:
52341

The client might use an automatically selected temporary port.

These are often called:

Ephemeral ports

---

11. Destination Port

The destination port identifies the service on the destination host.

For HTTPS:

Destination port = 443

So a connection might look conceptually like:

Client
192.0.2.20:52341

        ↓

Server
203.0.113.10:443

The addresses above are examples, not your actual server addresses.

---

12. IP + Port

An endpoint can be thought of conceptually as:

IP address + transport port

For example:

203.0.113.10:443

means:

IP = 203.0.113.10
Port = 443

---

13. What Is a Socket?

A socket is an operating-system networking abstraction used by applications.

A simplified model:

Nginx
  ↓
Socket
  ↓
TCP
  ↓
IP
  ↓
Network

Nginx can ask Linux to:

Create socket
Bind address/port
Listen
Accept connections
Read data
Write data

---

14. Listening

When Nginx is waiting for HTTPS connections, Linux may show something like:

0.0.0.0:443

in a listening state.

Conceptually:

Nginx
 ↓
socket
 ↓
TCP port 443
 ↓
WAITING

You can inspect this with:

sudo ss -lntp

---

15. What Does LISTEN Mean?

A TCP server socket in:

LISTEN

state is waiting for incoming connection attempts.

For example:

LISTEN 0 511 0.0.0.0:443

The exact values vary.

The basic idea is:

Internet
   ↓
TCP connection request
   ↓
Port 443
   ↓
Nginx

---

16. The TCP Connection

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

This uses:

Three-Way Handshake

The three main messages are:

SYN
SYN-ACK
ACK

---

17. SYN

The client sends:

SYN

SYN means the client is requesting TCP connection establishment and synchronizing sequence-number state.

Conceptually:

Client
  │
  │ SYN
  ▼
Server

---

18. SYN-ACK

The server responds:

SYN-ACK

Conceptually:

Client
  │
  │ SYN
  ▼
Server
  │
  │ SYN-ACK
  ▼
Client

The server is acknowledging the client’s SYN while also sending its own synchronization information.

---

19. ACK

The client then sends:

ACK

So:

Client                    Server

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

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

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

      Connection established

---

20. Why Three Messages?

Both sides need to establish that:

Client → Server communication works

Server → Client communication works

Both sides agree on initial sequence-number state

This creates the foundation for reliable TCP data transfer.

---

21. Sequence Numbers

TCP numbers bytes in the stream.

Suppose the initial sequence number is conceptually:

1000

Then data bytes are associated with positions in the sequence space.

Simplified:

Byte 1000
Byte 1001
Byte 1002
Byte 1003
...

The real TCP protocol uses sequence numbers with specific rules and randomization considerations; this is only a conceptual illustration.

---

22. Why Sequence Numbers?

Suppose packets arrive:

Segment 1
Segment 3
Segment 2

TCP can use sequence numbers to determine:

What data arrived?
What is missing?
What order should the bytes have?

So:

Network order
may differ

TCP stream
must be ordered

---

23. Acknowledgment Numbers

TCP also uses acknowledgment numbers.

Conceptually:

Sender
  ↓
Data
  ↓
Receiver
  ↓
ACK

The receiver communicates what sequence position it expects next.

For example, conceptually:

Received bytes through 5000
       ↓
ACK = 5001

Meaning approximately:

I have received everything through byte 5000 and next expect byte 5001.

---

24. Lost Data

Suppose:

Segment 1 → arrives
Segment 2 → lost
Segment 3 → arrives

The receiver’s acknowledgments indicate that some expected data has not arrived.

TCP can eventually retransmit the missing data.

Conceptually:

Sender
  │
  ├── Segment 1 ───────► Receiver
  │
  ├── Segment 2 ──X
  │
  └── Segment 3 ───────► Receiver
             │
             ↓
        Missing data
             │
             ↓
       Retransmission

---

25. Why Retransmission?

Because IP networks can lose packets.

TCP provides reliability by detecting missing data and retransmitting when appropriate.

This is one reason TCP is useful for applications such as:

HTTPS
SSH
Email protocols
Database connections

where losing or reordering application bytes silently would be unacceptable.

---

26. TCP Does Not Make the Physical Network Perfect

This is important.

TCP doesn’t prevent:

Packet loss
Delay
Congestion

Instead, it reacts to these conditions using protocol mechanisms.

Think:

Network problems
      ↓
TCP mechanisms
      ↓
Reliable ordered stream

---

27. Flow Control

Imagine:

Sender = very fast
Receiver = slower

If the sender sends unlimited data:

Sender
 ↓↓↓↓↓↓↓↓↓↓↓
Receiver

the receiver could become overwhelmed.

TCP uses:

Receive Window

to help control how much unacknowledged data the receiver is prepared to accept.

---

28. Receiver Window

Conceptually:

Receiver says:

"I currently have room for approximately X bytes."

The sender should respect that advertised receive window.

So:

Sender
 ↓
Data
 ↓
Receiver
 ↓
Receive capacity

---

29. Congestion Control

Flow control protects the receiver.

But there is another problem:

What if the network itself is overloaded?

This is handled by:

Congestion Control

TCP estimates network conditions and adjusts its sending behavior.

Conceptually:

Too much traffic
      ↓
Congestion
      ↓
TCP reduces/adjusts sending

When conditions improve, it can increase sending appropriately.

---

30. Flow Control vs Congestion Control

Remember this distinction:

Flow control
 ↓
Protect the receiver

Congestion control
 ↓
Protect/manage the network

Both affect how much data can be in flight.

---

31. What Is RTT?

RTT means:

Round-Trip Time

It is approximately the time for a packet/message to travel to the other endpoint and for a response/acknowledgment to return.

Conceptually:

Client
  │
  │──────────►
  │
  │◄──────────
  │
  Server

     RTT

---

32. Why RTT Matters

Suppose:

RTT = 20 ms

versus:

RTT = 200 ms

The second connection has significantly greater network delay.

This can affect interactive applications and TCP performance, especially when data transfer depends on acknowledgments and congestion-control behavior.

---

33. TCP Connection States

A TCP connection moves through states.

Examples include:

LISTEN
SYN-SENT
SYN-RECEIVED
ESTABLISHED
FIN-WAIT
CLOSE-WAIT
TIME-WAIT
CLOSED

You don’t need to memorize all of them yet.

The most important now:

LISTEN
   ↓
SYN
   ↓
SYN-RECEIVED
   ↓
ESTABLISHED

---

34. ESTABLISHED

When a connection is established:

ESTABLISHED

means the TCP connection is active and can carry application data.

For HTTPS:

TCP ESTABLISHED
       ↓
TLS handshake
       ↓
Encrypted HTTPS data

---

35. TCP Is Before TLS

This connects directly to your earlier TLS lessons.

For traditional HTTPS over TCP:

1. DNS
2. IP routing
3. TCP handshake
4. TLS handshake
5. HTTP exchange

This ordering is fundamental.

---

36. Your Website Example

You enter:

https://templates.cresignsys.com

The conceptual sequence is:

Browser
   ↓
DNS lookup
   ↓
Server IP
   ↓
TCP connection to port 443
   ↓
TCP handshake
   ↓
TLS handshake
   ↓
HTTPS request
   ↓
Nginx

---

37. Step 1 — DNS

The browser needs an IP address.

Conceptually:

templates.cresignsys.com
          ↓
         DNS
          ↓
      IP address

We will study the exact DNS process later.

---

38. Step 2 — TCP Destination

The browser now knows the server IP.

It wants:

Server IP
Port 443

So conceptually:

Client
192.0.2.20:ephemeral-port

        ↓ TCP

Server
203.0.113.10:443

---

39. Step 3 — SYN

The browser’s operating system sends a TCP SYN:

Client
   │
   │ SYN
   │
   ▼
Server:443

---

40. Step 4 — SYN-ACK

The server’s TCP stack responds:

Client
   │
   │ SYN
   ▼
Server
   │
   │ SYN-ACK
   ▼
Client

---

41. Step 5 — ACK

The client responds:

Client
   │
   │ ACK
   ▼
Server

Now:

TCP = ESTABLISHED

---

42. But the Browser Still Hasn’t Sent HTTP Yet

This is a very important point.

For HTTPS, TCP establishment is not the end.

Now TLS begins:

TCP established
      ↓
TLS handshake
      ↓
Secure encrypted channel

---

43. TLS Uses TCP

For the traditional HTTPS architecture:

HTTP
 ↓
TLS
 ↓
TCP
 ↓
IP

TLS uses the reliable byte stream provided by TCP.

---

44. TLS Handshake

The browser and server negotiate things such as:

TLS version
Cryptographic algorithms
Server identity
Keys

Your certificate:

templates.cresignsys.com

is involved in authenticating the server during this process.

---

45. Then HTTP

After the TLS handshake establishes the secure session:

Browser
 ↓
Encrypted HTTP request
 ↓
TLS
 ↓
TCP
 ↓
IP
 ↓
Nginx

Nginx receives the request after the lower networking layers process it.

---

46. Nginx Does Not Receive “Raw Internet”

The complete path is:

Network hardware
 ↓
Linux network driver
 ↓
Linux IP stack
 ↓
TCP stack
 ↓
Socket
 ↓
Nginx

Nginx works through the operating system’s networking APIs.

---

47. Nginx’s Listening Socket

Conceptually:

Nginx
 ↓
socket()
 ↓
bind()
 ↓
listen()
 ↓
accept()

These are operating-system networking interfaces/system calls.

The exact implementation involves Linux’s socket APIs and kernel networking stack.

---

48. bind()

Conceptually, Nginx associates a socket with an address/port.

For example:

0.0.0.0:443

means:

HTTPS
 ↓
TCP port 443
 ↓
Nginx

---

49. listen()

Nginx tells Linux:

This socket should accept incoming TCP connections.

Conceptually:

socket
 ↓
bind
 ↓
listen

---

50. accept()

When a client connection is ready, the application can accept it.

Conceptually:

Incoming connection
       ↓
listen socket
       ↓
accept()
       ↓
connected socket
       ↓
Nginx handles request

This is a very important distinction:

Listening socket

and:

Connected socket

are not the same thing.

---

51. One Nginx Server, Many Connections

Imagine:

Client A ───────►
Client B ───────► Nginx
Client C ───────►
Client D ───────►

Each connection has its own transport state.

Conceptually:

Nginx
 ├── TCP connection A
 ├── TCP connection B
 ├── TCP connection C
 └── TCP connection D

This is how one web server can handle many clients.

---

52. TCP Four-Tuple

A TCP connection can be identified by a combination of:

Source IP
Source port
Destination IP
Destination port

For example:

Client:
192.0.2.20:53001

Server:
203.0.113.10:443

Together these values identify a connection endpoint pair.

This is commonly called the TCP four-tuple.

---

53. Why Can Thousands of Clients Use Port 443?

Because clients use different source ports and/or source IPs.

For example:

Client A → 192.0.2.20:50001 → Server:443

Client B → 192.0.2.21:50002 → Server:443

Client C → 192.0.2.22:50003 → Server:443

The server can distinguish the connections.

---

54. TCP Doesn’t Mean “One Request = One Connection”

Modern HTTP behavior can reuse connections.

For example:

TCP connection
      ↓
TLS session
      ↓
HTTP request 1
HTTP response 1
HTTP request 2
HTTP response 2
...

This reduces connection-establishment overhead.

HTTP/2 goes further by multiplexing multiple streams over a single connection.

---

55. TCP Connection Termination

A TCP connection also needs to close cleanly.

A simplified model:

Client                    Server

 FIN -------------------->

      <----------------- ACK

      <----------------- FIN

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

       Connection closed

This is more complicated internally because each direction of a TCP connection can be closed independently.

---

56. FIN

FIN indicates that a side has finished sending data in that direction.

It does not necessarily mean the entire connection instantly disappears.

---

57. RST

TCP also has:

RST — Reset

A reset can abruptly terminate/reset a connection in situations where a normal graceful shutdown isn’t appropriate.

For example:

No listener
Invalid connection state
Application/network reset

The exact reason depends on context.

---

58. TIME-WAIT

You may eventually see connections in:

TIME-WAIT

This is a normal TCP state used after connection termination to help prevent delayed old segments from interfering with later connections and to ensure certain protocol requirements are satisfied.

So:

TIME-WAIT

doesn’t automatically mean something is broken.

---

59. Inspect TCP on Your Server

Run:

sudo ss -tan

You may see:

State
ESTAB
LISTEN
TIME-WAIT

This gives you a practical view of TCP.

---

60. See Listening TCP Ports

Use:

sudo ss -lntp

Meaning approximately:

-l = listening
-n = numeric
-t = TCP
-p = process information

You might find:

:22
:80
:443

depending on your configuration.

---

61. See HTTPS Connections

Use:

sudo ss -tnp '( sport = :443 )'

This can show TCP connections associated with port 443, depending on your ss version/filter syntax.

---

62. Test Port 443

From a machine with network access to the server, a tool such as:

nc -vz templates.cresignsys.com 443

can test whether a TCP connection to port 443 can be established.

This tests network connectivity to the port; it does not prove that TLS or HTTP is working correctly.

---

63. Important Troubleshooting Layers

Suppose:

https://templates.cresignsys.com

doesn’t open.

Do not immediately blame TLS.

Check the layers:

DNS
 ↓
IP
 ↓
Routing
 ↓
Firewall/security rules
 ↓
TCP port 443
 ↓
TLS
 ↓
HTTP
 ↓
Nginx
 ↓
PHP
 ↓
WordPress

This layered approach is fundamental to server troubleshooting.

---

64. Example: Port 443 Closed

Suppose:

DNS works

but:

TCP 443 connection fails

Then TLS cannot even begin.

Because:

TCP
 ↓
must exist first
 ↓
TLS

So troubleshooting TLS at this stage would be premature.

---

65. Example: TCP Works, TLS Fails

Suppose:

TCP 443
   ↓
works

but:

TLS handshake
   ↓
fails

Then investigate:

Certificate
Private key
TLS configuration
Server name
Supported protocols
Cipher configuration
Certificate chain

This is where your recent Let’s Encrypt installation becomes relevant.

---

66. Example: TLS Works, HTTP Fails

Suppose:

TCP
 ↓
works

TLS
 ↓
works

HTTP
 ↓
502

Then the problem is probably above TLS:

Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL

Again:

Find the lowest failing layer.

---

67. The Complete Architecture

You can now understand this:

                         USER
                           │
                           ▼
                        BROWSER
                           │
                           ▼
                         DNS
                           │
                           ▼
                      SERVER IP
                           │
                           ▼
                         ROUTING
                           │
                           ▼
                          IP
                           │
                           ▼
                         TCP
                           │
                     port 443
                           │
                           ▼
                          TLS
                           │
                           ▼
                         HTTPS
                           │
                           ▼
                         NGINX
                           │
                     ┌─────┴─────┐
                     ▼           ▼
                  Static       PHP-FPM
                                │
                                ▼
                             WordPress
                                │
                                ▼
                              MySQL

---

68. The Deepest Chain So Far

Your learning journey now looks like:

Matter
 ↓
Atoms
 ↓
Electrons
 ↓
Electricity
 ↓
Semiconductors
 ↓
Transistors
 ↓
Logic gates
 ↓
Binary
 ↓
CPU
 ↓
Memory
 ↓
Storage
 ↓
Operating system
 ↓
Linux kernel
 ↓
Processes
 ↓
Users
 ↓
Permissions
 ↓
Sockets
 ↓
Networking
 ↓
IP
 ↓
TCP
 ↓
TLS
 ↓
HTTP
 ↓
Nginx
 ↓
PHP
 ↓
WordPress
 ↓
Web hosting

You are now only a few layers away from connecting the complete theory to your actual templates.cresignsys.com server.

---

69. Quick Check

What does TCP provide?

A reliable, ordered byte stream with mechanisms for retransmission, flow control, congestion control, and connection management.

What is a port?

A transport-layer identifier used to identify an application endpoint on a host.

What is a socket?

An OS networking abstraction used by applications to communicate.

What is SYN?

A TCP flag used during connection establishment to synchronize sequence-number state.

What is SYN-ACK?

The server’s response acknowledging the client’s SYN while synchronizing its own sequence-number state.

What is ACK?

An acknowledgment mechanism used by TCP.

What is ESTABLISHED?

A TCP state representing an active connection.

What is LISTEN?

A server socket state waiting for incoming connections.

What comes first: TCP or TLS?

For traditional HTTPS over TCP:

TCP
 ↓
TLS

What comes before TCP?

Usually:

IP

and below IP:

Link layer

---

Next Lesson — 024

TCP → TLS → HTTPS: One Real Connection

We will now combine the last three major subjects:

DNS
 ↓
IP
 ↓
TCP 3-Way Handshake
 ↓
TLS Handshake
 ↓
Certificate
 ↓
Public Key
 ↓
Private Key
 ↓
Session Keys
 ↓
Encrypted HTTP
 ↓
Nginx

We will trace one actual HTTPS request to templates.cresignsys.com packet-by-packet conceptually, including exactly where the Let’s Encrypt certificate you installed enters the process.

Course: From Basic Science to Web Hosting

Module 05 — Networking Fundamentals

What Is a Computer Network?

Difficulty: Beginner → Intermediate
Prerequisites: Lesson 021 — Linux Storage
Estimated time: 40–50 minutes

We now move from:

INSIDE THE SERVER
CPU
 ↓
RAM
 ↓
Storage
 ↓
Processes
 ↓
Linux

to:

OUTSIDE THE SERVER
Network
 ↓
Internet
 ↓
Other computers

This is the beginning of understanding how:

https://templates.cresignsys.com

actually reaches your server.

---

1. The Most Basic Definition

A network is a system that allows devices to exchange data.

For example:

Computer A
    │
    │ data
    ↓
Computer B

A larger network:

Computer
   ↓
Switch
   ↓
Router
   ↓
Internet
   ↓
Server

---

2. Why Do We Need Networking?

Your server may be physically located somewhere else.

Your browser may be on your computer.

You need a communication system connecting them:

Your computer
      ↓
     LAN
      ↓
   Router
      ↓
   Internet
      ↓
Cloud network
      ↓
Your VPS

---

3. Data Is Just Bits

At the deepest level, computers exchange:

0
1

For example:

10110100

But networking doesn’t simply send one enormous stream of random bits.

It organizes data into structured units.

---

4. Network Data Has Layers

A useful simplified model is:

Application
     ↓
Transport
     ↓
Internet
     ↓
Link
     ↓
Physical

For example, when loading a website:

HTTP
 ↓
TCP
 ↓
IP
 ↓
Ethernet/Wi-Fi
 ↓
Electrical/radio signals

For HTTPS:

HTTP
 ↓
TLS
 ↓
TCP
 ↓
IP
 ↓
Ethernet/Wi-Fi

And HTTP/3 uses a different transport architecture:

HTTP/3
 ↓
QUIC
 ↓
UDP
 ↓
IP
 ↓
Link

---

5. Why Layers?

Imagine one giant networking program had to understand:

Browser
TLS
TCP
IP
Ethernet
Wi-Fi
Fiber
Radio

It would become extremely complicated.

Instead, networking uses layers.

Each layer has a particular responsibility.

---

6. Application Layer

At the top are application protocols.

Examples:

HTTP
HTTPS
DNS
SSH
SMTP
IMAP

For your website:

Browser
 ↓
HTTPS

---

7. Transport Layer

The transport layer provides communication between applications/processes.

Important protocols include:

TCP
UDP

Later we’ll study them deeply.

---

8. Internet Layer

The Internet Protocol:

IP

provides addressing and packet delivery between networks.

Common versions:

IPv4
IPv6

---

9. Link Layer

This deals with communication over a particular local network technology.

Examples:

Ethernet
Wi-Fi

It includes concepts such as:

MAC addresses
Frames
Switching

---

10. Physical Layer

At the physical level, data becomes physical signals.

Depending on the technology:

Copper
 ↓
Electrical signals

Fiber
 ↓
Light

Wi-Fi
 ↓
Radio waves

So the complete concept is:

Bits
 ↓
Signals
 ↓
Network hardware
 ↓
Other network hardware
 ↓
Bits

---

11. The Network Interface

Your Ubuntu server needs a network interface.

You can inspect interfaces with:

ip link

You may see something like:

lo
ens3

The exact interface name depends on the system.

---

12. lo — Loopback

You will often see:

lo

This is the:

Loopback Interface

It allows a computer to communicate with itself.

Its common IPv4 address is:

127.0.0.1

---

13. What Is 127.0.0.1?

Suppose Nginx is listening locally.

You could access:

http://127.0.0.1

from the server itself.

The path is essentially:

Application
 ↓
loopback
 ↓
Linux network stack
 ↓
another local application

The traffic does not need to leave the machine through the physical network.

---

14. localhost

The hostname:

localhost

usually refers to the local system.

It commonly resolves to loopback addresses such as:

127.0.0.1

and/or:

::1

depending on configuration.

---

15. Network Interface Example

Your server might have an interface such as:

ens3

This represents a network interface exposed to the operating system.

Conceptually:

Linux
 ↓
ens3
 ↓
Virtual network
 ↓
Cloud network
 ↓
Internet

---

16. MAC Address

Network interfaces commonly have a:

MAC Address

MAC means:

Media Access Control

A MAC address is a link-layer identifier associated with a network interface.

Example format:

02:42:ac:11:00:02

The actual address on your server will be different.

---

17. MAC vs IP

These are different concepts.

MAC

Primarily used at the local link layer.

IP

Used for logical network addressing and routing between networks.

Simplified:

MAC
 ↓
Local network delivery

IP
 ↓
Network-to-network delivery

---

18. IPv4 Address

An IPv4 address looks like:

192.168.1.10

It contains four decimal numbers called octets.

Each ranges from:

0–255

because IPv4 uses:

32 bits

---

19. Binary Representation

For example:

192

in binary is:

11000000

So:

192.168.1.10

is ultimately:

11000000.10101000.00000001.00001010

This connects networking back to binary computing.

---

20. Private IP Addresses

Some IPv4 ranges are designated for private networks.

Common ranges include:

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

For example:

192.168.1.20

is typically a private IPv4 address.

It is not directly routable across the public Internet.

---

21. Public IP Address

A public IP address can be used for Internet routing, subject to network/provider configuration.

A VPS commonly has an Internet-reachable public IP or an external network path involving NAT/load balancing.

Conceptually:

Internet
   ↓
Public IP
   ↓
Cloud networking
   ↓
VPS

---

22. Your Domain Does Not Equal Your IP

This is extremely important.

You have:

templates.cresignsys.com

and your server has an IP address.

These are not the same thing.

DNS connects them.

Conceptually:

Domain name
      ↓
DNS
      ↓
IP address

---

23. What Is DNS?

DNS means:

Domain Name System

Its basic purpose is to translate names into network information.

For example:

templates.cresignsys.com
        ↓
DNS
        ↓
IP address

This allows humans to use names instead of memorizing IP addresses.

---

24. Why Not Just Use the IP?

You could theoretically visit:

https://203.0.113.10

instead of:

https://templates.cresignsys.com

But domain names provide:

Human-readable identity
Flexible infrastructure
Multiple services
Virtual hosting
TLS certificate identity

---

25. DNS Is Not the Internet

DNS is a naming system.

It does not carry your entire website.

Think:

DNS
 ↓
"What IP address belongs to this name?"

Then:

IP
 ↓
"Where should the network packets go?"

Then:

TCP/TLS/HTTP
 ↓
"What communication should happen?"

---

26. Subnet

An IP address normally needs to be interpreted together with a:

Subnet prefix

For example:

192.168.1.10/24

The /24 means the first 24 bits form the network prefix.

---

27. What Does /24 Mean?

IPv4 has:

32 bits

So:

/24

means:

24 bits = network prefix
8 bits  = remaining host portion

Conceptually:

11111111.11111111.11111111.00000000

This corresponds to:

255.255.255.0

for a conventional IPv4 subnet mask representation.

---

28. Why Subnets?

Subnets divide networks into logical groups.

For example:

Network
 ↓
Subnet A
 ├── Computer 1
 ├── Computer 2
 └── Computer 3

Subnet B
 ├── Server 1
 └── Server 2

This helps with:

Routing
Address management
Security
Network organization

---

29. Default Gateway

Suppose your server wants to communicate with a destination outside its local subnet.

It normally sends the traffic toward a:

Default Gateway

Conceptually:

Server
 ↓
Default Gateway
 ↓
Other network
 ↓
Internet

---

30. Local vs Remote Destination

Suppose:

Server:
192.168.1.10/24

and wants:

192.168.1.20

The destination may be on the same local subnet.

But:

8.8.8.8

is outside that subnet.

So traffic goes toward the configured gateway.

---

31. Routing

Routing answers:

Where should this packet go next?

Conceptually:

Source
 ↓
Router
 ↓
Router
 ↓
Router
 ↓
Destination

Each router makes a forwarding decision based on its routing information.

---

32. Linux Has a Routing Table

You can inspect it with:

ip route

You may see something like:

default via 10.0.0.1 dev ens3
10.0.0.0/24 dev ens3 proto kernel scope link src 10.0.0.10

The exact output on your VPS will be different.

---

33. Understanding default

A route such as:

default via 10.0.0.1

means roughly:

For destinations that don’t match a more specific route, send traffic toward this gateway.

---

34. The Network Interface Has an IP

Use:

ip addr

You might see:

inet 10.0.0.10/24

This tells Linux:

IP address = 10.0.0.10
Prefix = /24
Interface = ens3

---

35. The Basic Linux Networking Commands

Start learning these:

ip link

Shows network interfaces.

ip addr

Shows IP addresses.

ip route

Shows routes.

ping

Tests IP reachability using ICMP, where permitted.

ss

Shows sockets and listening connections.

---

36. What Is a Packet?

When data travels across an IP network, it is typically divided into packets.

Conceptually:

Large data
   ↓
Packets
 ├── Packet 1
 ├── Packet 2
 ├── Packet 3
 └── ...

Each packet contains control information and payload.

---

37. IP Packet

An IP packet contains information such as:

Source IP
Destination IP
Protocol
Payload

Conceptually:

┌────────────────────────────┐
│ IP Header                  │
│                            │
│ Source                     │
│ Destination                │
│ Protocol                   │
├────────────────────────────┤
│ Payload                    │
└────────────────────────────┘

---

38. Ethernet Frame

At the local-link level, the packet is carried inside a frame.

Conceptually:

Ethernet Frame
 ├── MAC destination
 ├── MAC source
 ├── payload
 └── error-detection information

So:

Application data
 ↓
Transport segment/datagram
 ↓
IP packet
 ↓
Link-layer frame
 ↓
Physical signals

---

39. This Is Encapsulation

This is a major networking concept.

Suppose your browser sends HTTPS data.

Conceptually:

HTTP data
 ↓
TLS
 ↓
TCP
 ↓
IP
 ↓
Ethernet
 ↓
Electrical/radio/optical signals

Each layer adds its own control information.

This is called:

Encapsulation

---

40. At the Destination

The reverse happens.

Physical signal
 ↓
Ethernet
 ↓
IP
 ↓
TCP
 ↓
TLS
 ↓
HTTP
 ↓
Application

This is often called:

Decapsulation

---

41. Your Website Request

Now let’s connect everything to:

https://templates.cresignsys.com

The browser first needs to discover the server’s IP address.

So:

Browser
 ↓
DNS
 ↓
IP address

Then:

Browser
 ↓
IP network
 ↓
Server

Then:

TCP
 ↓
TLS
 ↓
HTTP

Then:

Nginx

---

42. Full Website Journey

You type:

https://templates.cresignsys.com
              │
              ▼
           Browser
              │
              ▼
             DNS
              │
              ▼
         Server IP
              │
              ▼
          IP routing
              │
              ▼
             TCP
              │
              ▼
             TLS
              │
              ▼
            HTTPS
              │
              ▼
            Nginx
              │
       ┌──────┴──────┐
       ▼             ▼
   Static file     PHP-FPM
                     │
                     ▼
                  WordPress
                     │
                     ▼
                   MySQL

You have now reached the boundary between Linux administration and web hosting.

---

43. Network Interface to Internet

The physical/virtual path can be visualized as:

Application
 ↓
Linux socket
 ↓
TCP
 ↓
IP
 ↓
Network interface
 ↓
Cloud virtual network
 ↓
Internet gateway/router
 ↓
Internet
 ↓
Other routers
 ↓
Destination network
 ↓
Server

---

44. What Is a Socket?

A socket is an operating-system interface through which applications communicate over networks.

Conceptually:

Application
 ↓
Socket
 ↓
TCP/UDP
 ↓
IP

For example, Nginx creates listening sockets.

---

45. Port

An IP address identifies a network endpoint at the host level.

A:

Port

helps identify the application/service endpoint.

For example:

HTTP  → 80
HTTPS → 443
SSH   → 22

These are conventional/default ports.

---

46. IP + Port

You can think of:

IP address + port

as identifying a network endpoint.

For example:

203.0.113.10:443

means:

IP = 203.0.113.10
Port = 443

This is not the actual IP of your server; it is an illustrative example.

---

47. Why Does Nginx Listen on 443?

Your SSL/TLS-enabled Nginx configuration commonly contains a listener conceptually equivalent to:

listen 443 ssl;

That means:

Incoming TCP connection
       ↓
Port 443
       ↓
Nginx
       ↓
TLS

---

48. What About Port 80?

HTTP traditionally uses:

80

HTTPS traditionally uses:

443

A common configuration is:

HTTP :80
   ↓
redirect
   ↓
HTTPS :443

For example:

http://templates.cresignsys.com
              ↓
      HTTPS redirect
              ↓
https://templates.cresignsys.com

---

49. Listening Ports

You can see listening sockets with:

sudo ss -lntup

You may see entries such as:

LISTEN
0.0.0.0:80
0.0.0.0:443
0.0.0.0:22

The exact output depends on your server.

---

50. What Does 0.0.0.0 Mean?

When used as a listening address:

0.0.0.0:443

generally means:

Listen on all available IPv4 interfaces.

It does not mean that 0.0.0.0 is the server’s actual public IP.

---

51. IPv6

Modern networking also uses:

IPv6

IPv6 addresses are 128 bits.

Example:

2001:db8::1

This is an example/documentation address.

IPv6 solves the address-space limitations of IPv4 and introduces additional architectural features.

---

52. IPv4 vs IPv6

IPv4
 ↓
32-bit address

IPv6
 ↓
128-bit address

Examples:

IPv4:
192.168.1.10

IPv6:
2001:db8::10

---

53. The Next Important Layer: TCP

We have now reached the transport layer.

For your traditional HTTPS connection:

HTTP
 ↓
TLS
 ↓
TCP
 ↓
IP

TCP answers a different question from IP.

IP

Which host/network should this packet reach?

TCP

How do two application endpoints establish and maintain a reliable byte stream?

---

54. Why TCP?

TCP provides mechanisms for:

Connection establishment
Reliable delivery
Ordering
Retransmission
Flow control
Congestion control

It does not simply mean “the Internet is reliable.” TCP implements reliability mechanisms between endpoints.

---

55. TCP Connection

A simplified TCP connection begins with a:

Three-Way Handshake

Conceptually:

Client                    Server

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

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

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

        Connection ready

This is one of the most important things we will study next.

---

56. Where TLS Comes In

After TCP establishes the connection for a traditional HTTPS connection:

TCP connection
      ↓
TLS handshake
      ↓
Encrypted application data

So your earlier SSL/TLS lessons now fit into the networking architecture:

DNS
 ↓
IP
 ↓
TCP
 ↓
TLS
 ↓
HTTP

---

57. The Complete Learning Map

You have now covered:

1. Hardware
   ↓
2. CPU
   ↓
3. RAM
   ↓
4. Storage
   ↓
5. Linux
   ↓
6. Filesystem
   ↓
7. Users
   ↓
8. Permissions
   ↓
9. Processes
   ↓
10. Services
   ↓
11. Networking

Next:

12. Ethernet
13. IP
14. Routing
15. TCP
16. UDP
17. Ports
18. Sockets
19. DNS
20. HTTP
21. TLS
22. Nginx
23. PHP-FPM
24. MySQL
25. WordPress
26. Web hosting

---

58. Practical Exercise

On your Ubuntu server, run these read-only commands:

ip link

Then:

ip addr

Then:

ip route

Then:

sudo ss -lntup

Then:

ping -c 4 127.0.0.1

These five commands begin to reveal:

Network interfaces
      ↓
IP addresses
      ↓
Routes
      ↓
Listening services
      ↓
Local network-stack connectivity

Do not change anything yet. The goal is observation.

---

Next Lesson — 023

TCP From the Deepest Basics

We will start from the physical meaning of communication and build upward:

Bits
 ↓
Bytes
 ↓
Frames
 ↓
Packets
 ↓
Ports
 ↓
Sockets
 ↓
TCP
 ↓
SYN
 ↓
SYN-ACK
 ↓
ACK
 ↓
TCP connection
 ↓
Data
 ↓
ACKs
 ↓
Retransmission
 ↓
Connection termination

Then we will trace what happens when your browser connects to:

templates.cresignsys.com:443

from the first network packet all the way to Nginx.

Course: From Basic Science to Web Hosting

Module 04 — Linux Fundamentals

How Linux Uses Storage

Difficulty: Beginner → Intermediate
Prerequisites: Lesson 020 — Linux Memory
Estimated time: 40 minutes

We now understand:

CPU
 ↓
RAM
 ↓
Processes

But your WordPress files must survive a reboot.

That requires:

Persistent Storage

---

1. The Basic Storage Chain

A simplified path is:

Website
 ↓
File
 ↓
Filesystem
 ↓
Mount point
 ↓
Storage device
 ↓
SSD / virtual disk

For your server:

WordPress
 ↓
/storage/websites/
 ↓
Filesystem
 ↓
Mounted storage
 ↓
Virtual disk / physical storage

---

2. RAM vs Storage

Remember:

RAM
= temporary working memory

while:

Storage
= persistent data

Example:

WordPress files
       ↓
Storage

Running WordPress
       ↓
RAM

---

3. Why Storage Is Needed

Suppose you install WordPress.

You have files such as:

wp-admin/
wp-content/
wp-includes/
index.php
wp-config.php

If these existed only in RAM:

Power off
 ↓
RAM contents disappear
 ↓
WordPress disappears

Instead:

WordPress files
 ↓
SSD
 ↓
Power off
 ↓
Files remain

---

4. What Is a Storage Device?

At the hardware level, a computer may have:

HDD
SSD
NVMe SSD
Flash storage

A cloud VPS normally exposes a virtual block storage device to the guest operating system, backed by the provider’s physical infrastructure.

So your Ubuntu VM may see something like:

/dev/sda

or:

/dev/vda

or:

/dev/nvme0n1

The exact device name depends on the virtualization/cloud platform.

---

5. What Is /dev?

We learned previously:

/dev

is a special filesystem containing device interfaces.

Storage devices can appear there.

For example:

/dev/sda

could represent an entire disk.

And:

/dev/sda1

could represent a partition on that disk.

---

6. Disk vs Partition

Imagine a disk:

┌──────────────────────────────┐
│          DISK                │
│                              │
│ ┌──────────┐ ┌─────────────┐ │
│ │Partition1│ │ Partition 2 │ │
│ └──────────┘ └─────────────┘ │
└──────────────────────────────┘

A partition is a defined region of a disk.

For example:

/dev/sda

might be the disk.

/dev/sda1

might be its first partition.

---

7. Why Partition?

Partitions allow a disk to be divided into separate logical regions.

For example:

Disk
 ├── EFI partition
 ├── Root partition
 └── Data partition

Modern systems can use different partitioning schemes and layouts.

---

8. GPT

A common modern partitioning scheme is:

GPT

GUID Partition Table.

It is commonly used with UEFI systems and supports large disks and many partitions.

Conceptually:

Disk
 ↓
GPT partition table
 ↓
Partitions

---

9. Filesystem

A partition or block device is not automatically a directory tree.

You normally create a:

Filesystem

on a storage device or partition.

Common Linux filesystems include:

ext4
XFS
Btrfs

Ubuntu commonly uses:

ext4

in many installations, though other filesystems are possible.

---

10. Filesystem’s Job

A filesystem organizes raw storage into structures that Linux can use as:

Files
Directories
Metadata
Permissions
Timestamps

Conceptually:

Raw storage
 ↓
Filesystem
 ↓
Files/directories

---

11. Raw Block Storage

A disk fundamentally provides blocks of storage.

Conceptually:

Block
Block
Block
Block
Block
...

The filesystem turns this low-level storage into a structured hierarchy.

Blocks
 ↓
Filesystem structures
 ↓
Files
 ↓
Directories

---

12. What Is ext4?

ext4 is a Linux filesystem.

It manages things such as:

Files
Directories
Inodes
Blocks
Metadata
Free space
Journaling

We will study these individually.

---

13. What Is a Mount?

This is one of the most important Linux concepts.

Suppose you have:

/dev/sdb1

containing an ext4 filesystem.

Linux can attach it to:

/storage

This is called:

Mounting

Conceptually:

/dev/sdb1
     ↓
  ext4 filesystem
     ↓
   mount
     ↓
/storage

---

14. Why Is Mounting Needed?

Linux uses a single unified filesystem hierarchy.

You don’t normally access storage as:

C:
D:
E:

as in traditional Windows drive-letter notation.

Instead:

/
├── etc
├── var
├── home
└── storage

A separate filesystem can be mounted into this tree.

---

15. Example

Suppose:

/dev/sdb1

is mounted at:

/storage

Then:

/storage/websites/

is actually stored on the filesystem provided by /dev/sdb1.

Conceptually:

/dev/sdb1
     ↓
   mount
     ↓
/storage
     ↓
/storage/websites

---

16. Your /storage Directory

Your hosting architecture uses:

/storage/websites/

There are two possibilities:

Case A

/storage is simply a directory inside your root filesystem.

Case B

/storage is a separate filesystem mounted there.

These are very different at the storage level.

---

17. How Do We Find Out?

Use:

df -h

You might see:

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        80G   30G   46G  40% /

Or you might see a separate entry:

/dev/sdb1       200G   50G  150G  25% /storage

Then you know /storage is a separate mounted filesystem.

---

18. df

df means:

Disk Free

Use:

df -h

It shows filesystem capacity and usage.

Important columns:

Filesystem
Size
Used
Avail
Use%
Mounted on

---

19. df -h /storage

You can directly check the filesystem containing /storage:

df -h /storage

This is useful because the directory itself doesn’t tell you which device backs it.

---

20. lsblk

Another important command:

lsblk

This displays block devices and their relationships.

Example:

sda
├─sda1
└─sda2

A more useful version:

lsblk -f

It can show:

NAME
FSTYPE
LABEL
UUID
MOUNTPOINTS

---

21. Block Device

A block device is a device that provides storage in addressable blocks.

Examples:

SSD
HDD
Virtual disk

Linux exposes these through device nodes such as:

/dev/sda
/dev/nvme0n1

---

22. NVMe

Modern SSDs often use NVMe.

You may see:

/dev/nvme0n1

and partitions:

/dev/nvme0n1p1
/dev/nvme0n1p2

The naming differs from traditional SCSI-style names such as /dev/sda1.

---

23. Cloud VPS Storage

Your server is running as a virtual machine.

Therefore:

Your VM
 ↓
Virtual block device
 ↓
Cloud infrastructure
 ↓
Physical storage

You normally interact with the virtual device, not directly with the provider’s physical SSD.

---

24. Storage Abstraction

This is another important computer-science concept.

You see:

/storage/websites/

but underneath:

Directory
 ↓
Filesystem
 ↓
Block device
 ↓
Virtualization
 ↓
Cloud storage infrastructure
 ↓
Physical hardware

Each layer hides details from the layer above it.

---

25. Inodes

A filesystem needs to keep metadata about files.

One important structure is an:

Inode

An inode can contain information such as:

File type
Permissions
Owner
Group
Timestamps
File size
Pointers/references to file data

The exact internal structure depends on the filesystem.

---

26. Filename vs Inode

A useful conceptual distinction:

Filename
   ↓
Directory entry
   ↓
Inode
   ↓
File data

The filename is not the complete identity of the file’s underlying filesystem metadata.

This explains several Linux filesystem behaviors.

---

27. Hard Links

A hard link allows multiple directory entries to refer to the same inode.

Conceptually:

fileA
   \
    → inode → data
   /
fileB

Therefore:

fileA

and:

fileB

can refer to the same underlying file data.

This is a deeper filesystem concept.

---

28. Symbolic Links

A symbolic link is different.

It contains a path reference to another file/directory.

Example:

link
 ↓
/some/other/path

You can create one with:

ln -s /source /destination

---

29. Why Symlinks Matter for Nginx

Linux server configurations often use symbolic links.

For example, Nginx commonly uses:

/etc/nginx/sites-available/

and:

/etc/nginx/sites-enabled/

A site configuration can be stored in one location and linked into the enabled directory.

Conceptually:

sites-available
       ↓
configuration file
       ↑
       │ symlink
       │
sites-enabled
       ↓
Nginx loads enabled configuration

Your:

/etc/nginx/sites-enabled/templates.cresignsys.com

is part of this style of configuration organization.

---

30. File Size vs Disk Usage

These are not always identical concepts.

A file may have:

Logical size

and:

Actual allocated blocks

Sparse files are one example where these can differ significantly.

For ordinary beginner use, ls -lh shows the logical file size, while du shows disk usage.

---

31. du

Use:

du -sh /storage/websites/

This estimates the amount of disk space consumed by that directory.

Compare:

df -h

with:

du -sh

df

Filesystem-level free/used space.

du

Space consumed by files/directories.

This distinction is extremely important.

---

32. Example

Suppose:

df -h /

shows:

80G total
60G used
20G available

But:

du -sh /storage/websites/

shows:

25G

The other space may be used by:

Operating system
Logs
Databases
Caches
Other files
Filesystem metadata

---

33. Finding Large Directories

You can inspect:

du -h --max-depth=1 /storage

This can show which directories consume space.

For example:

2G   /storage/websites/site1
10G  /storage/websites/site2
5G   /storage/websites/site3

---

34. Why Disk Space Matters for WordPress

A WordPress site may accumulate:

Images
Videos
Plugins
Themes
Backups
Logs
Cache
Database files
Temporary files

Therefore:

Disk usage

can grow over time.

---

35. Database Storage

MySQL also stores persistent data on disk.

Conceptually:

WordPress
 ↓
MySQL
 ↓
Database files
 ↓
Storage

The exact internal storage layout depends on MySQL/InnoDB configuration.

---

36. Disk I/O

Reading/writing storage requires:

I/O

Input/Output.

For example:

Read:
SSD → RAM

Write:
RAM/application → filesystem → SSD

---

37. Why Disk I/O Can Slow a Server

Suppose MySQL performs many disk operations.

Then:

MySQL
 ↓
Storage requests
 ↓
SSD
 ↓
waiting

The CPU may have little work to do while the process waits for I/O.

This can contribute to:

High I/O wait
Slow applications
Slow database queries
Slow websites

---

38. CPU Utilization vs I/O Wait

This distinction is important.

A server can feel slow even if:

CPU usage = 20%

because processes may be waiting for:

Disk I/O
Network I/O
Other resources

So server performance isn’t just:

CPU percentage

---

39. iostat

A useful tool for storage monitoring is:

iostat

It may be provided by the sysstat package.

A more detailed command:

iostat -xz 1

can show storage-device performance statistics.

You may need to install sysstat if it isn’t already installed.

---

40. Storage Performance

Storage has several important characteristics:

Capacity
Latency
IOPS
Throughput

---

41. Capacity

How much data can be stored?

Example:

100 GB
500 GB
1 TB

---

42. Latency

How long does an operation take?

Conceptually:

Request
 ↓
Wait
 ↓
Response

Lower latency generally means faster response for individual operations.

---

43. IOPS

IOPS means:

Input/Output Operations Per Second

It measures how many I/O operations a storage system can handle under specified conditions.

Database workloads can be sensitive to IOPS and latency.

---

44. Throughput

Throughput measures how much data can be transferred per unit time.

For example:

500 MB/s

A large sequential file transfer may care strongly about throughput.

A database performing many small random operations may care more about latency and IOPS.

---

45. Sequential vs Random I/O

Sequential

Block 1
Block 2
Block 3
Block 4

Random

Block 900
Block 12
Block 5000
Block 77

Different workloads produce different performance characteristics.

---

46. Mount Points

Let’s return to the key concept.

Suppose:

/dev/sdb1

contains a filesystem.

You mount it:

/storage

Then:

/storage

becomes the entry point into that filesystem.

Conceptually:

/dev/sdb1
      ↓
   filesystem
      ↓
    mount
      ↓
  /storage

---

47. /etc/fstab

Linux can define persistent mounts in:

/etc/fstab

This file describes filesystems that should be mounted automatically according to system configuration.

A conceptual entry might contain:

UUID=...
/storage
ext4
defaults
0 2

The exact syntax and options depend on the filesystem and desired configuration.

---

48. Why UUID?

Instead of relying only on:

/dev/sdb1

Linux can identify a filesystem using a:

UUID

Universally Unique Identifier.

For example:

UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

This can be more stable across device enumeration changes.

You can inspect filesystem UUIDs with:

lsblk -f

---

49. Check Your Mounts

Useful commands:

findmnt

and:

df -h

and:

lsblk -f

Together they help answer:

What storage devices exist?
 ↓
What filesystems exist?
 ↓
Where are they mounted?
 ↓
How much space is available?

---

50. Your Hosting Storage Architecture

Your system may look conceptually like:

Cloud VM
   ↓
Virtual disk
   ↓
Partition / volume
   ↓
Filesystem
   ↓
Mount point
   ↓
/storage
   ↓
/storage/websites
   ↓
templates.cresignsys.com
   ↓
public
   ↓
WordPress

The exact device/partition structure should be discovered from your server using:

lsblk -f
df -h
findmnt

rather than assumed.

---

51. Website Files vs Storage Device

This is an important distinction.

When you run:

cd /storage/websites/templates.cresignsys.com/public

you are navigating the filesystem namespace.

You are not directly navigating:

SSD sectors

The filesystem and kernel translate your path into storage operations.

Conceptually:

Path
 ↓
Directory entry
 ↓
Inode
 ↓
Filesystem
 ↓
Block device
 ↓
Storage

---

52. The Complete Storage Chain

Now connect everything:

WordPress
 ↓
PHP
 ↓
Filesystem API
 ↓
Linux kernel
 ↓
Virtual filesystem
 ↓
Filesystem driver
 ↓
Block layer
 ↓
Device driver
 ↓
Virtual disk
 ↓
Cloud storage
 ↓
Physical storage

This is the deep connection between:

wp-config.php

and:

physical storage hardware

---

53. Storage + Memory + CPU

A running application continuously moves through these resources:

              CPU
               ↑
               │
               ↓
              RAM
               ↑
               │
               ↓
            Storage

For example:

WordPress file
 ↓
Storage
 ↓
RAM
 ↓
CPU
 ↓
execution

Results may then be:

CPU
 ↓
RAM
 ↓
Network
 ↓
Browser

---

54. Full Web Hosting Resource Model

Your server is now understandable as four major resource areas:

                SERVER
                  │
      ┌───────────┼───────────┐
      ↓           ↓           ↓
     CPU          RAM       Storage
      │            │           │
      └────────────┼───────────┘
                   ↓
                Network

Web hosting performance depends on all of them.

---

55. Practical Commands to Learn

Run these on your Ubuntu server:

lsblk -f

df -h

df -h /storage

findmnt

du -sh /storage/websites/

du -h --max-depth=1 /storage/websites/

These commands let you begin understanding your actual storage architecture rather than just memorizing theory.

---

56. Quick Check

What is persistent storage?

Storage that retains data when power is removed.

What is a filesystem?

A system that organizes persistent storage into files, directories, and metadata.

What is a mount point?

A directory in the filesystem hierarchy where another filesystem is attached.

What does df -h show?

Filesystem capacity and space usage.

What does du -sh show?

Approximate disk space consumed by a file/directory tree.

What does lsblk -f show?

Block devices and filesystem information such as filesystem type, UUID, and mount points.

What is an inode?

A filesystem structure containing metadata about a file and references to its data.

What is I/O?

Input/output operations such as reading and writing storage.

---

Next Lesson — 022

Linux Networking Fundamentals

Now we have completed the major local-server foundations:

CPU
 ↓
RAM
 ↓
Processes
 ↓
Storage
 ↓
Filesystem
 ↓
Users
 ↓
Permissions
 ↓
Services

Now we can finally move outside the computer:

Server
 ↓
Network Interface
 ↓
Ethernet
 ↓
MAC Address
 ↓
IP Address
 ↓
Subnet
 ↓
Gateway
 ↓
Router
 ↓
Internet

Then we will build progressively toward:

IP
 ↓
TCP
 ↓
UDP
 ↓
DNS
 ↓
HTTP
 ↓
TLS
 ↓
HTTPS
 ↓
Nginx
 ↓
Domain
 ↓
Web Hosting

This will connect directly to how templates.cresignsys.com reaches your Ubuntu server.

Course: From Basic Science to Web Hosting

Module 04 — Linux Fundamentals

How Linux Uses Memory

Difficulty: Beginner → Intermediate
Prerequisites: Lesson 019 — Linux Processes
Estimated time: 35–45 minutes

The next fundamental question is:

When Nginx, PHP, MySQL and WordPress are running, where do their instructions and data actually live?

The answer begins with memory.

---

1. The Basic Memory Chain

We previously learned:

Program
 ↓
Process
 ↓
CPU

But the CPU needs somewhere to obtain instructions and data.

So:

Storage
 ↓
RAM
 ↓
CPU

A simplified computer looks like:

             CPU
              ↑↓
             RAM
              ↑↓
           Storage

---

2. Storage vs RAM

Consider your WordPress installation.

The files physically exist on persistent storage:

/storage/websites/templates.cresignsys.com/public/

But when WordPress is running, the CPU does not normally execute PHP directly from the SSD.

The operating system loads needed code/data into memory.

Conceptually:

SSD
 ↓
Filesystem
 ↓
RAM
 ↓
CPU

---

3. Why Not Run Everything Directly From SSD?

Storage is persistent, but RAM is designed for much faster access.

A simplified hierarchy is:

CPU registers
      ↓
CPU cache
      ↓
RAM
      ↓
SSD
      ↓
Long-term storage

Generally:

Higher
 ↑
Speed

Lower
 ↓
Capacity

There are many technical details, but this hierarchy is the important starting point.

---

4. What Is RAM?

RAM means:

Random Access Memory

It is the computer’s main working memory.

When programs are running, they need memory for:

Instructions
Variables
Buffers
Stacks
Heaps
Libraries
Operating-system data

---

5. A Simple Example

Suppose a program contains:

5
+
3

The program’s instructions are stored persistently somewhere.

When executing:

SSD
 ↓
RAM
 ↓
CPU

The CPU fetches instructions/data through the memory system.

---

6. RAM Is Volatile

Normal RAM is generally volatile.

If power disappears:

RAM
 ↓
contents lost

Storage such as SSD is non-volatile:

Power OFF
 ↓
Data remains on SSD

Therefore:

RAM
= working state

SSD
= persistent state

---

7. What Does a Process See?

A process doesn’t normally work directly with raw physical RAM addresses.

Instead, it receives a:

Virtual Address Space

Conceptually:

Process
   ↓
Virtual addresses
   ↓
Memory-management hardware + kernel
   ↓
Physical memory

This is one of the most important concepts in modern operating systems.

---

8. Why Virtual Memory?

Imagine two processes:

Nginx
PHP

Both could theoretically use a virtual address such as:

0x1000

But Linux can map those virtual addresses to different physical memory locations.

Conceptually:

Nginx
0x1000
   ↓
Physical RAM location A


PHP
0x1000
   ↓
Physical RAM location B

So processes can have isolated address spaces.

---

9. Memory Isolation

This helps prevent:

PHP
 ↓
directly modifying
 ↓
Nginx's memory

or:

WordPress
 ↓
directly modifying
 ↓
kernel memory

The CPU’s memory-management mechanisms enforce access restrictions.

---

10. Virtual Address Space

A simplified process memory layout might look like:

High addresses
┌──────────────────┐
│      Stack       │
├──────────────────┤
│                  │
│       ...        │
│                  │
├──────────────────┤
│       Heap       │
├──────────────────┤
│ Data             │
├──────────────────┤
│ Program code     │
└──────────────────┘
Low addresses

This is a conceptual model; actual layouts vary by architecture, operating system, executable format, security features, and process.

---

11. Program Code

The executable instructions occupy memory mappings associated with the program.

Conceptually:

Program file
 ↓
Code mapping
 ↓
CPU executes instructions

For example:

Nginx executable
 ↓
memory mapping
 ↓
CPU

---

12. Data

Programs need storage for data.

For example:

configuration
global variables
program state

Conceptually:

Code
+
Data
 ↓
Running program

---

13. Stack

The stack is used for function-call-related data and automatic/local variables.

Imagine:

main()
 ↓
functionA()
 ↓
functionB()

The stack helps maintain information about these calls.

Conceptually:

Function B
 ↓
Function A
 ↓
main()

When a function returns, its stack frame can be removed.

---

14. Simple Stack Example

Imagine:

function add(a, b)

When called:

add(5, 3)

the execution may need memory for:

a
b
return information
temporary state

Some of this can be associated with stack frames, depending on the compiler and architecture.

---

15. Heap

The heap is used for dynamically allocated memory.

Conceptually:

Program
 ↓
"Give me more memory"
 ↓
Allocator
 ↓
Heap

For example, applications may dynamically allocate memory while processing requests.

Languages and runtimes manage this differently.

PHP has its own memory-management behavior on top of the operating system’s memory facilities.

---

16. Stack vs Heap

A simplified comparison:

Stack	Heap
Function-call data	Dynamic allocations
Automatic lifetime	Flexible lifetime
Usually fast	More complex management
Limited per-thread region	Can grow substantially
Thread-specific	Process-wide in general

Do not treat this table as an exact physical RAM layout; it is a conceptual model of process virtual memory.

---

17. Shared Libraries

Applications often use shared libraries.

For example:

Program
 ↓
Shared library
 ↓
Functions

Instead of every program containing its own copy of common libraries, the operating system can map shared library code into processes.

This can reduce duplication.

---

18. What Is a Page?

Virtual memory is commonly managed in units called:

Pages

Instead of managing every byte independently, memory systems manage chunks.

A common page size is:

4 KB

but other page sizes can exist.

Conceptually:

Virtual memory
 ├── Page
 ├── Page
 ├── Page
 ├── Page
 └── ...

---

19. Page Tables

The CPU’s memory-management hardware uses structures called:

Page tables

They help translate:

Virtual address
      ↓
Physical address

Conceptually:

Process
 ↓
Virtual address
 ↓
Page table
 ↓
Physical RAM

The Linux kernel manages these mappings and the relevant memory structures.

---

20. TLB

Doing a page-table lookup for every memory access would be expensive.

Modern CPUs therefore use a cache called the:

TLB

Translation Lookaside Buffer.

It caches recent virtual-to-physical address translations.

Conceptually:

Virtual address
 ↓
TLB
 ├── hit → fast translation
 └── miss → page-table lookup

This is a deeper CPU/memory concept, but it explains why virtual memory can be efficient.

---

21. What Happens When RAM Is Full?

Suppose your server has:

8 GB RAM

and running processes demand more memory.

Linux has several mechanisms for handling memory pressure.

One is:

Swap

---

22. What Is Swap?

Swap is storage space used as an extension of memory management.

Conceptually:

RAM
 ↓
memory pressure
 ↓
some pages may be moved to swap
 ↓
SSD

This allows the system to keep operating under some memory-pressure situations.

But:

Swap is not equivalent to RAM.

Storage is much slower than RAM.

---

23. Why Heavy Swap Is Bad

Imagine PHP-FPM repeatedly needs a memory page that has been moved to storage.

Then:

CPU
 ↓
needs memory
 ↓
page not in RAM
 ↓
storage access
 ↓
page brought back
 ↓
CPU continues

If this happens excessively, performance can collapse.

This behavior is often associated with:

Thrashing

---

24. Swap Is Not Always Bad

A common misconception is:

“Any swap usage means the server is broken.”

Not necessarily.

Linux may use swap for various reasons, and some inactive pages can be swapped out while plenty of useful RAM remains available.

The important question is:

Is the system experiencing harmful memory pressure?

---

25. OOM

If memory pressure becomes severe and the system cannot satisfy memory demands, Linux has an:

Out-Of-Memory mechanism

commonly called:

OOM

The kernel’s OOM killer may terminate selected processes to recover memory.

Conceptually:

Memory demand
      ↓
Available memory insufficient
      ↓
Severe pressure
      ↓
OOM handling
      ↓
Process may be terminated

---

26. Why This Matters to Web Hosting

Imagine:

Server RAM = 4 GB

and you run:

Nginx
PHP-FPM
MySQL
WordPress
Other services

Now PHP creates many workers.

Conceptually:

PHP-FPM
 ├── Worker 1 → 100 MB
 ├── Worker 2 → 100 MB
 ├── Worker 3 → 100 MB
 ├── Worker 4 → 100 MB
 └── ...

Memory consumption can grow substantially.

---

27. PHP-FPM and Memory

Suppose each worker uses approximately:

100 MB

and there are:

20 workers

A rough upper-bound-style estimate would be:

20 × 100 MB
= 2000 MB
≈ 2 GB

This is only a simplified illustration. Real PHP-FPM memory behavior varies, and shared memory/code can complicate simple multiplication.

But the principle is important:

More concurrent workers can mean more memory consumption.

---

28. MySQL and Memory

MySQL also uses memory for:

Buffers
Caches
Connections
Temporary structures
Internal data

So:

RAM
 ├── Linux
 ├── Nginx
 ├── PHP-FPM
 ├── MySQL
 └── Other services

All compete for available memory.

---

29. Linux Page Cache

Linux also uses otherwise-available RAM for filesystem caching.

Conceptually:

SSD
 ↓
File
 ↓
Linux page cache
 ↓
RAM

If a frequently accessed file is cached in RAM, future reads can be faster.

This means:

RAM shown as “used” is not necessarily a problem.

Some memory is being productively used for cache.

---

30. Free vs Available

When checking Linux memory, don’t look only at:

free

A more useful concept is:

available

because Linux can reclaim some caches when applications need memory.

Use:

free -h

You might see:

               total   used   free   shared   buff/cache   available
Mem:            ...     ...    ...      ...       ...         ...
Swap:           ...     ...    ...      ...       ...         ...

The exact values depend on your server.

---

31. free -h

The -h means human-readable.

Use:

free -h

This is one of the first commands to run when investigating memory problems.

---

32. top

You can also use:

top

Look at:

%Cpu
MiB Mem
MiB Swap

Then inspect which processes are consuming memory.

---

33. ps Memory Usage

You can sort processes by memory usage:

ps aux --sort=-%mem | head

This can help identify processes using the most memory.

For CPU:

ps aux --sort=-%cpu | head

---

34. Memory and WordPress

A WordPress request can involve:

Browser
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
Plugins
 ↓
Theme
 ↓
MySQL

Each layer can consume resources.

Therefore a slow website might be caused by:

CPU
RAM
Database
PHP
Disk I/O
Network
External API
Plugin
Theme

Not necessarily Nginx.

---

35. PHP Memory Limit

PHP itself can impose memory limits.

For example, PHP may have a configuration value:

memory_limit

This limits memory available to a PHP request under PHP’s own memory-management rules.

It is different from:

Server RAM

For example:

Server RAM = 8 GB

PHP memory_limit = 256M

These are completely different concepts.

---

36. Server RAM vs PHP Memory Limit

Think:

Physical/virtual server
       ↓
8 GB RAM

PHP process/request
       ↓
PHP memory_limit

The PHP limit applies within PHP’s execution environment; it doesn’t mean the entire server has only that amount of memory.

---

37. MySQL Memory vs Server RAM

Similarly:

MySQL configuration
       ↓
buffers / caches / connections
       ↓
RAM

If MySQL is configured too aggressively for a small VPS, it can compete heavily with PHP and the operating system.

---

38. The Memory Flow

A simplified request:

Browser
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL

Memory involvement:

RAM
 ├── Nginx process memory
 ├── PHP-FPM worker memory
 ├── WordPress/PHP memory
 ├── MySQL memory
 ├── Linux kernel memory
 └── filesystem cache

---

39. Why More Websites Require More Planning

Suppose you host:

1 website

versus:

50 websites

Each additional site may add:

PHP workload
Database workload
Nginx configuration
Cache
Background jobs
Cron tasks
Traffic

Therefore hosting capacity is not determined by disk space alone.

You must consider:

CPU
RAM
Storage I/O
Network
Database workload
Concurrent requests

---

40. Memory and VPS Hosting

A virtual private server may give you a defined amount of virtual CPU and RAM.

Conceptually:

Physical server
 ├── VM A
 ├── VM B
 ├── VM C
 └── VM D

Your VM sees its allocated resources according to the virtualization/cloud platform.

Inside your VM:

Ubuntu
 ↓
Linux
 ↓
Processes
 ↓
Memory management

---

41. The Deepest Connection

Remember the original chain:

Electron
 ↓
Transistor
 ↓
Logic
 ↓
CPU

Now:

CPU
 ↓
Memory-management hardware
 ↓
RAM
 ↓
Linux kernel
 ↓
Processes
 ↓
Applications

So even a simple command such as:

free -h

ultimately depends on:

Hardware
 ↓
Memory controller
 ↓
CPU
 ↓
Linux kernel
 ↓
/proc and memory-management interfaces
 ↓
free
 ↓
Terminal output

---

42. A Useful Mental Model

Think of RAM as a working area, not as permanent storage.

                 COMPUTER
                     │
          ┌──────────┴──────────┐
          ↓                     ↓
       Storage                 RAM
     "Keep data"           "Work on data"
          │                     │
          └──────────┬──────────┘
                     ↓
                    CPU

---

43. Practical Commands

Start learning these:

Memory summary

free -h

Live system view

top

Memory-heavy processes

ps aux --sort=-%mem | head

CPU-heavy processes

ps aux --sort=-%cpu | head

Kernel memory information

cat /proc/meminfo

System uptime/load

uptime

---

44. What Does uptime Tell You?

For example:

uptime

might show:

up 10 days, 3:15
load average: 0.20, 0.18, 0.15

This introduces another important concept:

Load Average

We will study it properly later.

It is related to how much work is runnable or waiting for certain resources over time.

It is not simply CPU percentage.

---

45. What You Should Remember

The key chain is:

Program
 ↓
Process
 ↓
Virtual memory
 ↓
Pages
 ↓
Physical RAM
 ↓
CPU

And for your server:

Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL
 ↓
RAM

All of these compete for system resources.

---

46. Quick Check

Is a program the same as a process?

No.

Program = stored code
Process = running instance

Is RAM persistent?

Normally no.

Is SSD persistent?

Yes, normally.

What is virtual memory?

An abstraction that gives processes virtual address spaces, with mappings managed by the OS and hardware.

What is a page?

A fixed-size unit used in virtual-memory management.

What is swap?

Storage used as part of the system’s virtual-memory management.

Is swap as fast as RAM?

No.

What can happen under extreme memory pressure?

The system can invoke OOM handling and may terminate processes.

---

Next Lesson — 021

Linux Storage and Disk I/O

Before we move into networking, we need to understand the other major resource your hosting server depends on:

RAM
 ↓
Storage
 ↓
Disk
 ↓
Partitions
 ↓
Filesystems
 ↓
Mount points
 ↓
SSD
 ↓
I/O
 ↓
I/O wait
 ↓
Disk usage
 ↓
Storage performance

Then we will connect it directly to your:

/storage/websites/

architecture and learn how Linux knows which physical/virtual storage device contains your websites.

Course: From Basic Science to Web Hosting

Module 04 — Linux Fundamentals

What Is a Linux Process?

Difficulty: Beginner → Intermediate
Prerequisites: Lesson 018 — Users, Groups & Permissions
Estimated time: 35–40 minutes

The next foundation is understanding what is actually running inside your server.

You have files such as:

/usr/sbin/nginx
/usr/sbin/mysqld

But a file sitting on the SSD is not the same thing as a running program.

The important distinction is:

Program
   ↓
Process
   ↓
CPU + RAM + operating-system resources

---

1. What Is a Program?

A program is stored code.

For example:

/usr/sbin/nginx

is an executable program.

It exists as data on storage.

Conceptually:

SSD
 │
 └── nginx executable

Nothing is necessarily running merely because the file exists.

---

2. What Is a Process?

When the operating system starts a program, it creates a process.

So:

Program
   ↓
OS starts it
   ↓
Process

For example:

nginx program
      ↓
Nginx process

A process is a running instance managed by the operating system.

---

3. Program vs Process

Remember this distinction:

Program	Process
Stored code	Running instance
Exists on storage	Uses RAM
Passive	Active
Executable file	OS-managed execution
Can be started	Is already running

Example:

/usr/sbin/nginx

is a program.

nginx process

is a running instance.

---

4. What Happens When a Program Starts?

Very simplified:

Executable file
      ↓
Linux loads program
      ↓
Creates process
      ↓
Allocates virtual memory
      ↓
Sets process state
      ↓
Schedules it
      ↓
CPU executes instructions

Now the program is running.

---

5. Every Process Has a PID

Linux gives every process an identifier:

PID

Process ID

For example:

PID = 1234

This lets the operating system and administrators identify the process.

---

6. See Running Processes

Use:

ps

You might see:

PID TTY          TIME CMD
1234 pts/0    00:00:00 bash

The important part:

1234

is the PID.

---

7. ps aux

A more comprehensive view:

ps aux

You may see something like:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.1  ...   ... ?        Ss   ...      /sbin/init
www-data  2100  0.0  0.5  ...   ... ?        S    ...      nginx
mysql     2200  0.5  2.0  ...   ... ?        S    ...      mysqld

The exact output will differ on your server.

---

8. Important ps Columns

For example:

USER
PID
%CPU
%MEM
STAT
COMMAND

USER

The user identity running the process.

PID

Process ID.

%CPU

Recent CPU utilization.

%MEM

Memory utilization.

STAT

Process state/status information.

COMMAND

The executable/command associated with the process.

---

9. The First Process

On a typical modern Linux system, the first userspace process is commonly:

systemd

and often has:

PID 1

Conceptually:

Linux kernel
      ↓
PID 1
      ↓
systemd
      ↓
Services

The exact boot architecture can vary, but PID 1 is a crucial concept in Linux.

---

10. Why Is PID 1 Special?

PID 1 has important responsibilities in userspace.

On Ubuntu systems using systemd:

PID 1
 ↓
systemd

It manages system services and participates in process lifecycle management.

For example:

systemd
 ├── nginx
 ├── ssh
 ├── mysql
 └── other services

---

11. Parent and Child Processes

Processes can have relationships.

A process can create another process.

For example:

Parent
  ↓
Child

This creates a process hierarchy.

Conceptually:

systemd
   ↓
service manager
   ↓
nginx

The exact process tree depends on how the service is launched.

---

12. PPID

A process also has a:

Parent Process ID

called:

PPID

Suppose:

PID 2000
PPID 1000

It means process 2000 has process 1000 as its parent.

---

13. Process Tree

Use:

pstree

You might see a structure resembling:

systemd
 ├─ sshd
 │   └─ bash
 ├─ nginx
 │   ├─ nginx
 │   └─ nginx
 └─ mysqld

The exact tree varies.

This is much easier to understand than a flat process list.

---

14. Why Do We Have Multiple Nginx Processes?

Nginx commonly uses a master/worker architecture.

Conceptually:

nginx master
   ├── worker
   ├── worker
   └── worker

The master manages the workers.

The workers handle connections and requests.

The exact architecture and worker count depend on configuration and version.

---

15. Nginx Master and Worker

Conceptually:

             Nginx
               │
        ┌──────┴──────┐
        ↓             ↓
      Master        Workers
                      │
             ┌────────┼────────┐
             ↓        ↓        ↓
           Request  Request  Request

This allows Nginx to handle many connections efficiently.

---

16. PHP-FPM

WordPress usually needs PHP.

PHP-FPM means:

PHP FastCGI Process Manager

Instead of Nginx executing PHP code itself:

Nginx
 ↓
PHP-FPM
 ↓
PHP

PHP-FPM maintains worker processes.

Conceptually:

php-fpm master
      ├── worker
      ├── worker
      └── worker

Again, the exact model depends on configuration.

---

17. MySQL

Your database server also runs as a process or process group managed by the operating system.

Conceptually:

MySQL
  ↓
mysqld
  ↓
CPU + RAM + storage

So your hosting server might contain:

systemd
 ├── nginx
 ├── php-fpm
 ├── mysqld
 └── sshd

---

18. CPU and Processes

The CPU executes instructions from runnable processes/threads.

Imagine:

Nginx → needs CPU
PHP   → needs CPU
MySQL → needs CPU
SSH   → needs CPU

The operating system scheduler decides which runnable threads get CPU time on available cores.

Conceptually:

Processes / threads
       ↓
Scheduler
       ↓
CPU cores

---

19. One CPU Core

With one core, only one instruction stream can execute at a given instant on that core.

The OS rapidly switches among runnable work.

Simplified:

Nginx
 ↓
CPU
 ↓
PHP
 ↓
CPU
 ↓
MySQL
 ↓
CPU

This switching happens extremely quickly.

---

20. Multiple CPU Cores

Modern CPUs have multiple cores.

For example:

CPU
 ├── Core 1
 ├── Core 2
 ├── Core 3
 └── Core 4

Multiple threads can execute simultaneously across different cores.

The operating system schedules work across them.

---

21. What Is a Thread?

A thread is an execution path within a process.

Conceptually:

Process
 ├── Thread 1
 ├── Thread 2
 └── Thread 3

Threads usually share the process’s address space and many resources.

---

22. Process vs Thread

A simplified comparison:

Process
 ↓
Independent execution environment
 ↓
Own virtual address space

Thread
 ↓
Execution path inside a process
 ↓
Shares much of process memory/resources

Threads are generally cheaper to create/switch than separate processes, but the details depend on the operating system and workload.

---

23. Process Memory

A process needs memory.

Conceptually:

Process
 ├── Code
 ├── Data
 ├── Heap
 ├── Stack
 └── Shared libraries

The process sees a virtual address space.

The CPU’s memory-management hardware and Linux map virtual addresses to physical memory as appropriate.

---

24. Virtual Memory

Suppose two processes both use an address such as:

0x1000

That does not mean they necessarily refer to the same physical RAM location.

Conceptually:

Process A
virtual address
     ↓
physical memory A


Process B
virtual address
     ↓
physical memory B

The memory-management unit and kernel establish these mappings.

---

25. Why Virtual Memory Matters

It provides:

Isolation
Protection
Flexible memory management
Shared libraries
Memory mapping

It is one of the foundations of modern operating systems.

---

26. Process States

A process/thread isn’t always executing.

It can be:

Running
Ready/runnable
Sleeping/waiting
Stopped
Zombie

The exact state notation depends on the tool.

---

27. Running

A runnable thread may be executing on a CPU.

Conceptually:

Thread
 ↓
CPU
 ↓
Instructions executing

---

28. Sleeping / Waiting

A process may be waiting for something.

For example:

Nginx
 ↓
Waiting for network connection

or:

MySQL
 ↓
Waiting for disk I/O

A waiting process may consume very little CPU.

---

29. Zombie Process

A zombie is a process that has terminated but still has a process-table entry containing its exit status until its parent collects that status.

Conceptually:

Child finishes
     ↓
Zombie entry
     ↓
Parent collects exit status
     ↓
Entry removed

A small number of transient zombies can be normal.

A large accumulation can indicate a parent-process problem.

---

30. top

Use:

top

This provides a live view of system activity.

You can observe:

CPU usage
Memory usage
Load
Processes
PIDs

It is one of the most useful basic server-monitoring tools.

---

31. htop

If installed:

htop

provides a more interactive process viewer.

It can help you see:

CPU cores
Processes
Memory
Process tree

---

32. pgrep

Suppose you want to find Nginx processes:

pgrep nginx

It returns matching PIDs.

For example:

2100
2101
2102

The actual PIDs on your server will be different.

---

33. Find the Process

You can combine:

ps aux | grep nginx

But be aware that grep nginx itself can sometimes appear in the output.

A cleaner approach is often:

pgrep -a nginx

which can show matching process IDs and command lines.

---

34. Inspect a Specific Process

Suppose:

PID = 2100

You can inspect:

ps -p 2100 -f

This can show details such as:

UID
PID
PPID
START
TIME
COMMAND

---

35. /proc/PID

Remember Lesson 017.

If Nginx has:

PID = 2100

Linux exposes process information under:

/proc/2100/

For example:

cat /proc/2100/status

can show information about that process.

This demonstrates the connection:

Process
 ↓
Kernel
 ↓
/proc
 ↓
User-space inspection

---

36. Who Is Running Nginx?

You can use:

ps aux | grep nginx

or:

ps -eo user,pid,ppid,cmd | grep nginx

You may see different users for master and worker processes depending on configuration.

For example, conceptually:

root      nginx master
www-data  nginx worker
www-data  nginx worker

This is a common security architecture.

---

37. Why Would Nginx Have a Root Master?

The master process may need privileged operations such as binding to a low-numbered port, while worker processes can run with reduced privileges.

For example:

root
 ↓
Nginx master
 ↓
www-data
 ↓
Nginx workers

This reduces the privileges of the request-processing workers.

The exact configuration can differ.

---

38. PHP-FPM Workers

Similarly, PHP-FPM may have:

php-fpm master
      ↓
workers
      ↓
www-data

The workers execute PHP application code.

This is especially important for WordPress security.

---

39. MySQL Process

You can inspect the database process:

pgrep -a mysqld

or:

ps aux | grep mysqld

You can then ask:

Who owns the process?
How much RAM is it using?
How much CPU?
What is its PID?

---

40. Process and Service Are Different

This distinction is important.

Service

A managed system function.

Example:

nginx.service

Process

A running execution instance.

Example:

nginx PID 2100

So:

systemd
 ↓
service
 ↓
process

A service may involve multiple processes.

---

41. systemctl status

Run:

sudo systemctl status nginx

You may see information such as:

Active: active (running)
Main PID: ...

This connects:

systemd
 ↓
nginx.service
 ↓
Nginx process
 ↓
PID

---

42. Restart vs Reload

This is important for web hosting.

Restart

sudo systemctl restart nginx

Typically stops and starts the service.

Reload

sudo systemctl reload nginx

asks Nginx to reload its configuration without a full service restart, when supported.

For configuration changes, reload is often preferable because it can avoid unnecessarily interrupting existing connections.

But always test the configuration first:

sudo nginx -t

---

43. nginx -t

Before reloading after changing Nginx configuration:

sudo nginx -t

Nginx checks the configuration syntax and related configuration validity.

Conceptually:

Edit configuration
       ↓
nginx -t
       ↓
Valid?
 ┌─────┴─────┐
No          Yes
 ↓            ↓
Fix         reload

This is an excellent operational habit.

---

44. Process Failure

Suppose PHP-FPM crashes.

Then:

Nginx
 ↓
tries to communicate with PHP-FPM
 ↓
PHP-FPM unavailable
 ↓
request fails

You may see:

502 Bad Gateway

This is why process knowledge is essential for web-hosting troubleshooting.

---

45. CPU High

Suppose:

top

shows:

mysqld
 ↓
95% CPU

You now know the problem may be related to database workload rather than Nginx.

You can investigate:

CPU
 ↓
Process
 ↓
Application
 ↓
Specific workload

---

46. Memory High

Suppose:

php-fpm
 ↓
large memory usage

Then investigate:

PHP workers
 ↓
WordPress
 ↓
Plugin/theme
 ↓
Request workload

This is much better than randomly restarting the server.

---

47. The Troubleshooting Model

When something fails:

Symptom
  ↓
Which process?
  ↓
Which service?
  ↓
Which user?
  ↓
Which resource?
  ↓
CPU?
RAM?
Disk?
Network?
Permissions?
Configuration?

This is the beginning of professional server administration.

---

48. Your Web Hosting Process Architecture

Your server can be visualized as:

                     Linux Kernel
                          │
                       systemd
                          │
        ┌─────────────────┼─────────────────┐
        ↓                 ↓                 ↓
      Nginx            PHP-FPM            MySQL
        │                 │                 │
    Workers           Workers            Threads
        │                 │                 │
        └─────────────────┼─────────────────┘
                          ↓
                       Resources
                    CPU / RAM / Disk

---

49. One Website Request

A request for:

https://templates.cresignsys.com

may produce:

Browser
 ↓
Network
 ↓
Nginx worker
 ↓
PHP-FPM worker
 ↓
WordPress
 ↓
MySQL
 ↓
PHP-FPM
 ↓
Nginx
 ↓
TLS
 ↓
Browser

Multiple processes and threads can be involved.

---

50. The Deep Technology Chain

Your course has now reached:

Atom
 ↓
Electron
 ↓
Electricity
 ↓
Semiconductor
 ↓
Transistor
 ↓
Logic gate
 ↓
Binary
 ↓
CPU
 ↓
Computer
 ↓
Operating System
 ↓
Linux Kernel
 ↓
Filesystem
 ↓
Users
 ↓
Permissions
 ↓
Processes
 ↓
Services
 ↓
Nginx / PHP-FPM / MySQL

The next major layer is:

Network

But before jumping into the Internet, we need one more Linux foundation:

Lesson 020 — Linux Memory

We will go deeply into:

RAM
 ↓
Virtual memory
 ↓
Pages
 ↓
Memory addresses
 ↓
Stack
 ↓
Heap
 ↓
Shared libraries
 ↓
Cache
 ↓
Swap
 ↓
OOM
 ↓
Why a web server becomes slow

Then we will connect memory directly to your Ubuntu VPS, PHP-FPM, MySQL and WordPress.

Course: From Basic Science to Web Hosting

Module 04 — Linux Fundamentals

Linux Users, Groups, Ownership & Permissions

Difficulty: Beginner → Intermediate
Prerequisites: Lesson 017 — Linux Filesystem
Estimated time: 35–40 minutes

---

1. The Big Question

You have seen commands such as:

sudo -u www-data wp core download --allow-root

and you have worked with directories such as:

/storage/websites/templates.cresignsys.com/public/

A fundamental question is:

Who is allowed to read, modify, or execute these files?

Linux answers this using:

Users
Groups
Ownership
Permissions

These four concepts are essential for secure web hosting.

---

2. Why Permissions Exist

Imagine every program could modify every file.

A compromised website could potentially modify:

/etc/

or:

/root/

or another customer’s website.

That would be dangerous.

Linux therefore follows a basic principle:

Program
   ↓
Request access
   ↓
Kernel checks permissions
   ↓
Allow / deny

---

3. Users

A Linux system can have many users.

For example:

root
ubuntu
www-data

Each user has an identity recognized by the operating system.

The identity is represented internally by a:

UID

UID means:

User ID

For example:

root
 ↓
UID 0

The exact UID values of other users depend on the system.

---

4. Root User

root is the traditional privileged Linux user.

Its UID is:

0

Root can perform operations that ordinary users cannot.

For example:

sudo systemctl restart nginx

may execute the service-management operation with elevated privileges.

---

5. Normal User

Your login account might be something such as:

ubuntu

It normally does not have unrestricted access to the entire system.

When it needs administrative privileges, it can use:

sudo

if authorized.

---

6. What Is www-data?

On Ubuntu/Debian systems, web-server software commonly uses a restricted service account such as:

www-data

The exact service user depends on configuration.

For example:

Nginx
 ↓
www-data

or PHP-FPM workers may run as:

www-data

The purpose is security.

If a web application is compromised, restricting it to a low-privilege account can reduce the damage it can cause.

---

7. User vs Process

A user is an identity.

A process is a running program.

For example:

User:
www-data

Process:
php-fpm worker

The process runs with a user identity.

Conceptually:

PHP-FPM process
      ↓
runs as
      ↓
www-data

The Linux kernel uses that identity when checking access to resources.

---

8. Groups

Linux also has groups.

A group is a collection of users.

For example:

developers
webadmins
www-data

A user can belong to one or more groups.

Conceptually:

Users
 │
 ├── ubuntu
 ├── admin
 └── developer

Group
 │
 └── webadmins

Groups make permission management easier.

---

9. Group ID

Like users, groups have numerical identifiers.

This is called:

GID

meaning:

Group ID

The system internally uses UIDs and GIDs rather than relying only on names.

---

10. File Ownership

Every ordinary Linux file has ownership information.

At a basic level:

File
 ├── Owner
 └── Group

For example:

index.php
Owner: www-data
Group: www-data

---

11. View Ownership

Use:

ls -l

Example:

-rw-r--r-- 1 www-data www-data 1234 index.php

The important part is:

www-data www-data

which represents:

Owner = www-data
Group = www-data

---

12. Understanding ls -l

Consider:

-rw-r--r-- 1 www-data www-data 1234 index.php

Break it down:

-rw-r--r--
│
├── file type
│
├── owner permissions
├── group permissions
└── other permissions

The first character:

-

means it is a regular file.

A directory usually begins with:

d

For example:

drwxr-xr-x

---

13. Three Permission Categories

Linux traditionally evaluates three basic permission classes:

Owner
Group
Others

For example:

-rwxr-x---

can be separated into:

Owner  → rwx
Group  → r-x
Others → ---

---

14. Three Basic Permissions

The three basic permissions are:

r
w
x

They mean:

r = read
w = write
x = execute

---

15. Read Permission

For a regular file:

r

generally means the process can read the file’s contents.

For example:

cat index.php

requires appropriate read permission.

---

16. Write Permission

For a regular file:

w

means the process can modify the file contents, subject to other filesystem/security mechanisms.

For example:

nano test.txt

requires write access to save modifications.

---

17. Execute Permission

For a regular file:

x

allows it to be executed as a program/script when the other requirements for execution are satisfied.

For example:

./script.sh

requires execute permission on the script.

But for directories, x has a different meaning.

---

18. Execute Permission on Directories

This is extremely important.

For a directory:

x

generally means:

You can traverse/search the directory.

So directory permissions behave differently from file permissions.

---

19. Directory Read vs Execute

Suppose:

drwxr-x---

For a directory:

r

allows listing directory entries, subject to other permissions.

x

allows traversal/search.

Therefore:

Read directory

and:

Enter/traverse directory

are not exactly the same permission.

---

20. Example

Suppose:

/storage/websites/

has:

drwxr-x---

A user may be able to traverse the directory but not necessarily list its contents, depending on the exact permission combination and ownership/group membership.

This distinction becomes important when securing hosting directories.

---

21. Permission Numbers

Linux permissions can also be represented numerically.

The basic mapping is:

r = 4
w = 2
x = 1

Add them together.

---

22. Examples

Read only:

r--

means:

4

Write only:

-w-

means:

2

Execute only:

--x

means:

1

Read + write:

rw-

means:

4 + 2 = 6

Read + execute:

r-x

means:

4 + 1 = 5

Read + write + execute:

rwx

means:

4 + 2 + 1 = 7

---

23. Three Permission Numbers

Consider:

755

Separate it:

7 5 5

Meaning:

Owner → 7
Group → 5
Others → 5

And:

7 = rwx
5 = r-x
5 = r-x

Therefore:

755
=
rwxr-xr-x

---

24. Another Example: 644

644

means:

Owner → 6 = rw-
Group → 4 = r--
Others → 4 = r--

So:

644
=
rw-r--r--

This is commonly used for ordinary web files, depending on the hosting architecture.

---

25. chmod

The command used to change permissions is:

chmod

For example:

chmod 644 index.php

This sets:

Owner → read/write
Group → read
Others → read

---

26. chmod 755

For a directory:

chmod 755 public

means:

Owner → rwx
Group → r-x
Others → r-x

This is a common directory permission pattern.

But:

Do not blindly apply 755 or 777 everywhere.

Permissions should reflect what the service actually needs.

---

27. chmod 777

You may see:

chmod 777

This gives:

Owner  → rwx
Group  → rwx
Others → rwx

This is often overly permissive.

For a web server, it can create serious security problems.

Avoid using 777 as a generic solution to permission errors.

---

28. Ownership: chown

The command:

chown

means:

change owner

Example:

sudo chown www-data index.php

changes the owner to:

www-data

---

29. Owner + Group

You can specify both:

sudo chown www-data:www-data index.php

Meaning:

Owner = www-data
Group = www-data

---

30. Recursive Ownership

You can apply ownership to a directory and its contents:

sudo chown -R www-data:www-data /storage/websites/example.com/

The -R means:

recursive

But use recursive ownership changes carefully.

A mistake can affect thousands of files.

---

31. chgrp

The command:

chgrp

changes the group ownership.

Example:

sudo chgrp www-data index.php

Now:

Group = www-data

---

32. Why Ownership Matters for WordPress

Suppose WordPress wants to modify:

wp-content/

The PHP-FPM process might be running as:

www-data

Linux checks:

Who is requesting access?
        ↓
www-data
        ↓
Who owns the file?
        ↓
What are the permissions?

Then the kernel decides whether access is allowed.

---

33. The Permission Decision

Conceptually:

PHP-FPM
   ↓
www-data
   ↓
requests write access
   ↓
Linux kernel
   ↓
Check file owner/group/permissions
   ↓
ALLOW or DENY

This is why permissions matter so much in WordPress hosting.

---

34. Why Nginx Can Read a File

Suppose:

index.php

has:

-rw-r--r--

and is owned by:

ubuntu

The owner has:

rw-

Group:

r--

Others:

r--

If Nginx/PHP runs as an account that falls under “others”, it can read the file but cannot modify it.

---

35. Why WordPress May Not Be Able to Write

Suppose:

wp-content/

doesn’t provide write access to the PHP process’s identity.

WordPress might fail to:

Upload media
Install plugin
Update plugin
Create cache
Write generated files

The browser might show an error such as:

Unable to create directory

or:

Could not create temporary file

The correct solution is to understand ownership and required permissions—not automatically use chmod 777.

---

36. A Better Hosting Model

A more controlled architecture might be:

Website files
      ↓
Owner: deployment/admin user
Group: web group
      ↓
Nginx/PHP
      ↓
only required access

The exact model depends on your deployment workflow.

The important principle is:

Give each service only the permissions it actually needs.

---

37. The Principle of Least Privilege

This is a major security principle.

Instead of:

Everyone → Everything

use:

Each process
    ↓
Minimum required permissions

For example:

Nginx
 ↓
Read website files

PHP
 ↓
Read application files
 ↓
Write only where necessary

---

38. Why sudo Is Powerful

Suppose normal user:

ubuntu

runs:

sudo systemctl restart nginx

The system temporarily gives the command elevated privileges according to sudo policy.

Conceptually:

ubuntu
 ↓
sudo
 ↓
authorized elevated operation

Without sudo:

systemctl restart nginx

may fail because managing the service requires privileges the normal user doesn’t have.

---

39. sudo Does Not Mean “Make Everything Root Forever”

This is an important distinction.

When you run:

sudo command

you are asking the system to execute that particular command with elevated privileges according to the sudo configuration.

It does not permanently turn your account into root.

---

40. sudo -u

You have used:

sudo -u www-data ...

The -u option specifies another user identity.

For example:

sudo -u www-data whoami

can produce:

www-data

Conceptually:

ubuntu
 ↓
sudo
 ↓
execute as www-data
 ↓
program

---

41. Why This Is Useful for WordPress

Suppose WordPress should operate as:

www-data

You can execute a command as that user:

sudo -u www-data wp ...

This helps test whether the web-service user actually has access to the files.

---

42. --allow-root

You have also seen:

--allow-root

with WP-CLI.

This is a WP-CLI-specific option, not a Linux permission command.

It tells WP-CLI to permit execution as the root user when the command is otherwise being blocked for safety.

This is different from:

sudo

and different from:

chmod

---

43. Three Different Concepts

Keep these separate:

sudo
 ↓
Who executes a command?

chown
 ↓
Who owns a file?

chmod
 ↓
What permissions does the file have?

This simple distinction will prevent many Linux mistakes.

---

44. Practical Example

Suppose:

ls -ld /storage/websites/templates.cresignsys.com/public

returns something like:

drwxr-xr-x  www-data www-data ...

You can interpret it as:

Directory
Owner = www-data
Group = www-data

Owner:
rwx

Group:
r-x

Others:
r-x

---

45. Inspect a File

Use:

ls -l /storage/websites/templates.cresignsys.com/public/index.php

You might see:

-rw-r--r-- www-data www-data ...

Then:

Owner = www-data
Group = www-data

and:

Owner → rw-
Group → r--
Others → r--

---

46. Inspect the Whole Path

There is a subtle problem.

A file may have correct permissions while one of its parent directories prevents traversal.

For example:

/storage
   ↓
/websites
   ↓
/example.com
   ↓
/public
   ↓
index.php

The process needs appropriate traversal permissions on the directory path.

So troubleshooting permissions means checking:

File
+
Parent directories

not just the final file.

---

47. namei

A useful command is:

namei -l /storage/websites/templates.cresignsys.com/public/index.php

It can show the permissions and ownership of each component of the path.

Conceptually:

/
 ↓
storage
 ↓
websites
 ↓
templates.cresignsys.com
 ↓
public
 ↓
index.php

This is extremely useful for diagnosing “Permission denied.”

---

48. Linux Permission Flow

When a process accesses a file:

Process
  ↓
User identity
  ↓
Path traversal
  ↓
Directory permissions
  ↓
File ownership
  ↓
File permissions
  ↓
Kernel decision
  ↓
Allow / deny

This is the foundation.

---

49. Web Hosting Permission Flow

Now apply it to WordPress:

Browser
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
Filesystem request
 ↓
Linux kernel
 ↓
Ownership + permissions
 ↓
ALLOW / DENY

This explains many real hosting problems.

---

50. The Deeper Technology Chain

We can now extend our original chain:

Matter
 ↓
Electrons
 ↓
Electricity
 ↓
Electronics
 ↓
Transistors
 ↓
Digital logic
 ↓
CPU
 ↓
Computer
 ↓
Linux
 ↓
Kernel
 ↓
Filesystem
 ↓
Users
 ↓
Permissions
 ↓
Processes
 ↓
Services
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
Website

---

51. Quick Check

What is a UID?

A numerical identifier for a Linux user.

What is a GID?

A numerical identifier for a Linux group.

What does r mean?

Read.

What does w mean?

Write.

What does x mean?

Execute for files; generally traversal/search for directories.

What does chmod do?

Changes permissions.

What does chown do?

Changes ownership.

What does chgrp do?

Changes group ownership.

What does sudo -u www-data do?

Runs the specified command as www-data, subject to sudo authorization.

Why should you avoid chmod 777 as a generic fix?

Because it gives owner, group, and others read/write/execute permissions and can unnecessarily expose the website to modification.

---

Next Lesson — 019

Linux Processes: What Is Actually Running on Your Server?

We will go deeper into:

Program
 ↓
Process
 ↓
PID
 ↓
Parent process
 ↓
Child process
 ↓
Thread
 ↓
CPU
 ↓
RAM
 ↓
systemd
 ↓
Nginx
 ↓
PHP-FPM
 ↓
MySQL

Then we will use real commands:

ps
top
htop
pgrep
pstree
systemctl

to understand exactly what is running inside your web-hosting server.

Course: From Basic Science to Web Hosting

Module 04 — Linux Fundamentals

What Is the Linux Filesystem?

Difficulty: Beginner → Intermediate
Prerequisites: Lesson 016 — What Really Happens When You Run a Linux Command?
Estimated time: 30–40 minutes

---

1. The Big Question

You have already used paths such as:

/storage/websites/templates.cresignsys.com/public

and commands such as:

cd /storage/websites/
ls

But what exactly is this structure?

Why does Linux have:

/etc
/var
/usr
/home
/dev
/proc
/sys

?

To understand Linux administration properly, we first need to understand its filesystem.

---

2. What Is a Filesystem?

A filesystem is the software-defined structure used to organize and manage persistent data on storage.

At a simple level:

Storage device
      ↓
Filesystem
      ↓
Directories
      ↓
Files

For example:

SSD
 ↓
Filesystem
 ↓
/
 ├── etc
 ├── var
 ├── home
 └── storage

---

3. Linux Has One Main Directory Tree

Linux organizes its filesystem as a tree.

At the top is:

/

This is called:

Root Directory

Do not confuse:

/

with:

root

The first is the filesystem’s top directory.

The second usually refers to the administrative user account.

---

4. The Root of the Filesystem

Everything in the normal Linux filesystem hierarchy starts from:

/

For example:

/etc

means:

/
└── etc

And:

/var/log

means:

/
└── var
    └── log

And:

/storage/websites/

means:

/
└── storage
    └── websites

---

5. Absolute Paths

A path beginning with / is an absolute path.

Example:

cd /storage/websites/

It means:

Start from the filesystem root and go to storage, then websites.

---

6. Relative Paths

A path without / at the beginning is normally interpreted relative to the current directory.

Suppose:

pwd

returns:

/storage/websites/

Then:

cd templates.cresignsys.com

means:

/storage/websites/templates.cresignsys.com

---

7. pwd

The command:

pwd

means:

Print Working Directory

Example:

pwd

Output:

/storage/websites/templates.cresignsys.com/public

This tells you exactly where you currently are in the filesystem tree.

---

8. ls

The command:

ls

lists directory contents.

For example:

ls

might show:

index.php
wp-config.php
wp-content
wp-admin
wp-includes

---

9. cd

The command:

cd

means:

change directory

Example:

cd /storage/websites/

Then:

pwd

might show:

/storage/websites

---

10. The Linux Filesystem Tree

A simplified Linux filesystem might look like:

/
├── bin
├── boot
├── dev
├── etc
├── home
├── lib
├── media
├── mnt
├── opt
├── proc
├── root
├── run
├── sbin
├── srv
├── sys
├── tmp
├── usr
├── var
└── storage

Some modern distributions use merged directories such as /usr/bin being the effective location behind /bin; the exact filesystem layout can vary.

---

11. /bin

Historically:

/bin

contains essential user command binaries.

Examples conceptually include:

ls
cp
mv
cat

On modern Ubuntu systems, /bin is commonly a symbolic link into /usr/bin.

You can inspect it with:

ls -ld /bin

---

12. /sbin

Historically:

/sbin

contains system-administration commands.

Modern Linux distributions may similarly merge this into /usr/sbin.

Examples include tools used for:

System administration
Networking
Disk management
Boot/system maintenance

---

13. /usr

This is one of the most important directories.

It contains a large part of the operating system’s user-space software.

For example:

/usr/bin
/usr/sbin
/usr/lib
/usr/share

Conceptually:

/usr
 ├── bin
 ├── sbin
 ├── lib
 └── share

Many applications and utilities live here.

---

14. /etc

This is extremely important for a server.

/etc

primarily contains system and application configuration.

Examples:

/etc/nginx/
/etc/ssh/
/etc/systemd/
/etc/php/
/etc/mysql/

So when you modify:

/etc/nginx/

you are modifying Nginx configuration.

---

15. Your Nginx Configuration

You have worked with:

/etc/nginx/sites-enabled/

This is part of:

/etc
   ↓
nginx
   ↓
configuration

For example:

/etc/nginx/sites-enabled/templates.cresignsys.com

can contain the Nginx server configuration for that website.

---

16. /var

/var is used for variable/changing system data.

Examples:

/var/log
/var/lib
/var/cache

The word “variable” means the contents can change during normal operation.

---

17. /var/log

This directory contains logs.

For example:

/var/log/nginx/

may contain:

access.log
error.log

You can inspect them with:

sudo tail -f /var/log/nginx/error.log

This is extremely useful when troubleshooting websites.

---

18. /var/lib

This is commonly used for persistent application/system state.

For example, databases and system services may maintain data under /var/lib.

The exact location depends on the software.

---

19. /var/cache

This contains cache data maintained by various applications.

Caches can often be regenerated, although you should never assume every file under a cache directory is safe to delete without understanding the specific application.

---

20. /home

This normally contains users’ home directories.

Example:

/home/ubuntu

Inside:

/home/ubuntu/

you may have:

Documents
Downloads
scripts
projects

---

21. /root

This is normally the home directory of the root user:

/root

Remember the distinction:

/
   = filesystem root

root
   = privileged Linux user

and:

/root
   = root user's home directory

These are three related but different concepts.

---

22. /tmp

This directory is commonly used for temporary files.

/tmp

Applications can use it for temporary data.

Important:

Do not assume anything placed in /tmp will persist permanently.

Temporary-directory cleanup behavior depends on the system configuration.

---

23. /boot

This contains files related to booting the operating system.

For example:

/boot

may contain:

Linux kernel
initramfs
bootloader-related files

The exact arrangement depends on the boot architecture.

---

24. /dev

This is a very interesting directory.

/dev

contains device nodes representing devices and device interfaces.

Examples can include:

/dev/null
/dev/zero
/dev/random

and storage/device nodes.

Linux uses the filesystem interface to expose many devices to user-space programs.

---

25. /dev/null

One famous Linux device is:

/dev/null

Anything written to it is discarded.

For example:

echo "hello" > /dev/null

The text disappears.

Conceptually:

Program
 ↓
/dev/null
 ↓
discard

---

26. /dev/zero

Another special device:

/dev/zero

provides a stream of zero-valued bytes when read.

This illustrates an important Linux idea:

Many devices and kernel interfaces can be exposed through file-like interfaces.

---

27. /proc

Now we reach something very important.

/proc

is not an ordinary disk directory.

It is a virtual filesystem provided by the kernel.

It exposes information about:

Processes
CPU
Memory
Kernel state
System information

For example:

cat /proc/cpuinfo

can display processor information.

---

28. /proc/meminfo

Try:

cat /proc/meminfo

You can see information about memory.

Conceptually:

Linux kernel
      ↓
/proc
      ↓
Information exposed to user space

The data is dynamically generated by the kernel.

---

29. /proc/PID

Every process has a process ID, commonly called:

PID

Suppose a process has:

PID = 1234

Linux can expose information under:

/proc/1234/

Conceptually:

Process
  ↓
PID
  ↓
/proc/PID

This becomes extremely useful when learning process management.

---

30. /sys

Similar to /proc, Linux provides:

/sys

which is a virtual filesystem exposing information about devices, drivers, buses, and kernel device models.

Conceptually:

Hardware
   ↓
Kernel device model
   ↓
/sys
   ↓
User-space tools

---

31. /run

/run

contains runtime state.

It is generally temporary and is usually populated during boot.

Examples can include:

PID information
Sockets
Runtime service state

---

32. /media

This is commonly used as a location for automatically mounted removable media.

For example:

/media/username/USB

---

33. /mnt

Traditionally used as a temporary or manually managed mount point.

For example:

/mnt/data

could be used for a mounted filesystem.

---

34. /opt

/opt

is commonly used for optional/add-on application software.

For example, some third-party software may install under:

/opt/application/

---

35. /srv

/srv

is intended for data served by the system.

For example, a service could theoretically use:

/srv/www/

However, server administrators often choose other directory structures based on their architecture.

Your:

/storage/websites/

is perfectly valid as a custom hosting layout.

---

36. /storage

This is important for your setup.

Unlike directories such as /etc or /var, /storage is not a mandatory standard Linux directory.

You or your hosting architecture created it for your own purpose.

For example:

/storage
   └── websites
       ├── site1
       ├── site2
       └── site3

This is a good example of Linux’s flexibility.

---

37. Your Hosting Structure

Your architecture can be represented as:

/
└── storage
    └── websites
        └── templates.cresignsys.com
            └── public
                ├── index.php
                ├── wp-admin
                ├── wp-content
                ├── wp-includes
                └── wp-config.php

This is the physical filesystem organization of the website files.

---

38. Filesystem vs Website URL

This distinction is extremely important.

Your filesystem path might be:

/storage/websites/templates.cresignsys.com/public/

But the user sees:

https://templates.cresignsys.com/

These are not the same thing.

Nginx creates the connection between them.

Conceptually:

Browser URL
     ↓
Nginx configuration
     ↓
Filesystem path

---

39. Nginx root

A typical Nginx configuration might contain something conceptually like:

server {
    server_name templates.cresignsys.com;

    root /storage/websites/templates.cresignsys.com/public;
}

This tells Nginx:

Use this filesystem directory as the document root for this virtual host.

Therefore:

https://templates.cresignsys.com/

can map to:

/storage/websites/templates.cresignsys.com/public/

---

40. One URL Request

Suppose someone requests:

https://templates.cresignsys.com/about.html

Conceptually:

Browser
 ↓
DNS
 ↓
Server IP
 ↓
TCP 443
 ↓
TLS
 ↓
Nginx
 ↓
server_name
 ↓
root directory
 ↓
about.html

The physical file might be:

/storage/websites/templates.cresignsys.com/public/about.html

---

41. Why /etc and /storage Are Different

This distinction will become extremely useful.

/etc
 ↓
Configuration

while:

/storage
 ↓
Your website data

For example:

/etc/nginx/

contains instructions telling Nginx how to serve the site.

While:

/storage/websites/templates.cresignsys.com/public/

contains the website itself.

---

42. Configuration vs Data

This is a general systems principle:

Configuration
      ↓
How the software should behave

Data
      ↓
What the software works with

For your website:

Nginx configuration
      ↓
How requests are handled

WordPress files/database
      ↓
Website content

---

43. Logs Are Another Layer

Nginx also produces logs:

/var/log/nginx/

So we have:

/etc/nginx/
     ↓
Configuration

/storage/websites/
     ↓
Website data

/var/log/nginx/
     ↓
Operational records

These three locations have completely different purposes.

---

44. A Practical Example

Suppose the website gives:

502 Bad Gateway

Don’t immediately edit WordPress.

First consider:

Nginx
 ↓
PHP-FPM

Check:

sudo systemctl status nginx

Then:

sudo systemctl status php*-fpm

And inspect:

sudo tail -f /var/log/nginx/error.log

Now you are troubleshooting according to the architecture.

---

45. Another Example: 404

Suppose:

https://templates.cresignsys.com/test.html

returns:

404 Not Found

Possible causes include:

Wrong Nginx root
Wrong URL
File does not exist
Nginx location rule
WordPress routing

First understand which layer is responsible.

---

46. Filesystem Hierarchy to Remember

For your web-hosting work, memorize these first:

/
├── etc       → configuration
├── var       → changing data/logs
├── usr       → installed user-space software
├── home      → user home directories
├── root      → root user's home
├── tmp       → temporary data
├── dev       → device interfaces
├── proc      → kernel/process information
├── sys       → kernel/device information
├── run       → runtime state
└── storage   → your custom hosting storage

---

47. The Deeper Architecture

Now connect today’s lesson with everything before it:

HARDWARE
   ↓
CPU / RAM / SSD
   ↓
Linux Kernel
   ↓
Virtual Filesystem Interface
   ↓
Filesystem
   ↓
Directories
   ↓
Configuration / Data / Logs
   ↓
Applications

And for your hosting server:

Linux
 │
 ├── /etc/nginx
 │       ↓
 │   Nginx configuration
 │
 ├── /var/log/nginx
 │       ↓
 │   Nginx logs
 │
 └── /storage/websites
         ↓
     Website files

---

48. Most Important Concept

Don’t memorize directories as a random list.

Understand their purpose:

/etc
  = "How should the system/software behave?"

/var
  = "What changing operational data exists?"

/usr
  = "What software is installed?"

/home
  = "Where are user files?"

/dev
  = "How does user space interact with devices?"

/proc
  = "What does the kernel expose about processes/system?"

/sys
  = "What does the kernel expose about devices/system structure?"

/storage
  = "Where did we choose to keep our hosting data?"

---

49. Quick Check

What is /?

The root of the Linux filesystem hierarchy.

What is /etc?

Primarily system and application configuration.

What is /var/log?

A common location for system/application logs.

What is /usr?

A major hierarchy containing user-space programs, libraries, and shared data.

What is /proc?

A kernel-provided virtual filesystem exposing process and system information.

What is /sys?

A kernel-provided virtual filesystem exposing device/kernel information.

What is /storage?

In your server, a custom directory used for hosting data.

Where are your website files?

For example:

/storage/websites/templates.cresignsys.com/public/

Where is Nginx configuration?

Commonly under:

/etc/nginx/

Where are Nginx logs?

Commonly:

/var/log/nginx/

---

Next Lesson — 018

Linux Users, Groups, Ownership and Permissions

This is the next essential foundation before managing multiple websites.

We will build from the deepest basics:

User
 ↓
Group
 ↓
Process identity
 ↓
File owner
 ↓
Permissions
 ↓
r / w / x
 ↓
chmod
 ↓
chown
 ↓
chgrp
 ↓
sudo
 ↓
www-data
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress

Then we will answer an important real-world question:

Why can Nginx/PHP sometimes read a WordPress file but cannot write to it?

That leads directly into secure multi-domain web hosting.

Course: From Basic Science to Web Hosting

Module 04 — Operating Systems

What Really Happens When You Run a Linux Command?

Difficulty: Beginner → Intermediate
Prerequisites: Lesson 015 — What Is an Operating System?
Estimated time: 30 minutes

We will use a real command you have already encountered:

sudo systemctl restart nginx

The goal is to understand what happens from your keyboard to the CPU, through Linux, to Nginx.

---

1. Start at the Beginning

You see:

$ sudo systemctl restart nginx

It looks like one command.

But underneath, many layers are involved:

Keyboard
   ↓
Terminal
   ↓
Shell
   ↓
Command
   ↓
Program
   ↓
System calls
   ↓
Linux kernel
   ↓
systemd
   ↓
Nginx

And underneath all of that:

CPU
RAM
Storage
Electronic circuits
Transistors

---

2. What Is a Terminal?

A terminal provides an interface through which you can interact with the operating system using text.

For example:

ubuntu@server:~$

You type:

ls

The terminal receives your keyboard input.

Conceptually:

Keyboard
   ↓
Terminal
   ↓
Text input

---

3. What Is a Shell?

The terminal itself isn’t normally responsible for interpreting shell commands.

A shell is a program that interprets commands.

Common shells include:

bash
zsh
sh
fish

Ubuntu commonly uses Bash by default in many environments.

So:

Keyboard
   ↓
Terminal
   ↓
Bash

---

4. Shell Prompt

When you see something like:

ubuntu@server:~$

the shell is effectively saying:

I am ready to receive a command.

You type:

ls

The shell reads it.

---

5. The Shell Parses the Command

Suppose you type:

sudo systemctl restart nginx

The shell separates the command into components roughly like:

sudo
systemctl
restart
nginx

These have different roles.

---

6. First Word: sudo

sudo is a program that allows an authorized user to run a command with elevated privileges.

So:

sudo systemctl restart nginx

is conceptually:

Run systemctl
       ↓
with elevated privileges

The exact authorization process depends on the system’s sudo configuration.

---

7. Second Word: systemctl

systemctl is a command-line program used to communicate with systemd.

So:

systemctl

is not the service manager itself.

It is a client/control program.

Conceptually:

You
 ↓
systemctl
 ↓
systemd

---

8. Third Word: restart

This is an argument telling systemctl what operation you want.

restart

means:

Stop/restart the specified service

---

9. Fourth Word: nginx

This identifies the service unit.

nginx

So the whole request is approximately:

sudo
 ↓
run systemctl with elevated privileges

systemctl
 ↓
talk to systemd

restart
 ↓
requested operation

nginx
 ↓
target service

---

10. What Happens Next?

The sudo program performs its authorization work and then executes the requested command with the appropriate credentials.

Then:

systemctl
   ↓
communicates with
   ↓
systemd

On a system using systemd, this communication is typically performed through system mechanisms such as Unix-domain sockets and the D-Bus/systemd management interfaces.

You don’t need to manually implement any of this.

The OS handles it.

---

11. What Is systemd?

systemd is a system and service manager.

It manages units such as:

Services
Sockets
Mounts
Timers
Targets

For our example:

nginx.service

is a service unit.

---

12. systemd Checks the Service

When you request:

systemctl restart nginx

systemd determines how the Nginx service should be managed based on its unit configuration.

Conceptually:

systemctl
   ↓
systemd
   ↓
nginx.service

---

13. Where Does the Service Configuration Come From?

Systemd unit files can exist in locations such as:

/etc/systemd/system/

and distribution/package-managed locations such as:

/usr/lib/systemd/system/

The exact locations and precedence depend on the system.

A service unit can describe things such as:

Service name
Dependencies
Command to start
Command to stop
Restart behavior
User
Environment

---

14. systemd Starts Nginx

Eventually systemd launches the Nginx process according to the service configuration.

Conceptually:

systemd
   ↓
fork/exec and process management
   ↓
Nginx

The kernel is involved in creating and managing the process.

---

15. What Is exec?

Unix-like systems have system calls that allow a process to replace its current program image with another executable.

A family of functions commonly called exec* is used for this purpose.

Conceptually:

Existing process
      ↓
exec()
      ↓
New program image

This is one of the fundamental mechanisms behind launching programs.

---

16. What Is a System Call?

Applications cannot directly perform arbitrary privileged hardware operations.

Instead, they request services from the kernel through:

System calls

Conceptually:

Application
    ↓
System call
    ↓
Linux kernel
    ↓
Hardware / kernel-managed resources

Examples include operations related to:

Files
Processes
Memory
Networking
Time
Devices

---

17. User Space and Kernel Space

Linux separates normal application execution from privileged kernel execution.

Conceptually:

┌───────────────────────────┐
│        USER SPACE         │
│                           │
│ Bash                      │
│ sudo                      │
│ systemctl                 │
│ Nginx                     │
│ PHP                       │
│ MySQL                     │
└─────────────┬─────────────┘
              │
        System calls
              │
┌─────────────▼─────────────┐
│       KERNEL SPACE        │
│                           │
│ Process management        │
│ Memory management         │
│ Networking                │
│ Filesystems               │
│ Device drivers            │
└─────────────┬─────────────┘
              │
┌─────────────▼─────────────┐
│         HARDWARE          │
│ CPU / RAM / SSD / NIC     │
└───────────────────────────┘

This separation is fundamental to operating-system design.

---

18. Why Can’t Nginx Just Control the Hardware?

Security and stability.

Imagine every application could directly control:

RAM
SSD
Network hardware
CPU control mechanisms

One buggy program could potentially destroy the system.

Instead:

Application
    ↓
Kernel
    ↓
Controlled access
    ↓
Hardware

The kernel acts as a privileged resource manager.

---

19. What Happens Inside the CPU?

At the hardware level, the CPU executes machine instructions.

Conceptually:

Machine instruction
      ↓
CPU fetch
      ↓
Decode
      ↓
Execute
      ↓
Memory/register operations

And physically:

CPU instructions
      ↓
Transistor switching
      ↓
Electrical signals

So even:

systemctl restart nginx

eventually becomes processor activity.

---

20. What Happens in RAM?

Programs need memory.

For example:

Bash
sudo
systemctl
systemd
Nginx

all require memory while executing.

Conceptually:

SSD
 ↓
Program executable
 ↓
Linux loads program
 ↓
RAM
 ↓
CPU executes instructions

---

21. What Happens on the SSD?

Programs and configuration files are stored persistently.

For example:

/usr/bin/systemctl
/usr/bin/sudo
/usr/sbin/nginx
/etc/nginx/
/etc/systemd/

When required, executable code and data are loaded from storage into memory.

Simplified:

SSD
 ↓
Filesystem
 ↓
Executable/data
 ↓
RAM
 ↓
CPU

---

22. What Happens to Nginx?

After systemd successfully starts or restarts Nginx:

Nginx process
      ↓
Loads configuration
      ↓
Opens required resources
      ↓
Creates/listens on sockets
      ↓
Waits for network requests

For HTTPS, it may listen on:

TCP 443

For HTTP:

TCP 80

---

23. Your Website Request

Now suppose someone opens:

https://templates.cresignsys.com

The path becomes:

Browser
 ↓
DNS
 ↓
IP address
 ↓
Internet
 ↓
Server
 ↓
TCP connection
 ↓
TLS connection
 ↓
Nginx

Nginx then processes the HTTP request.

---

24. Where Does TLS Fit?

Your SSL/TLS certificate belongs here:

Internet
   ↓
TCP
   ↓
TLS
   ↓
HTTP
   ↓
Nginx

More precisely, modern HTTPS normally uses:

HTTP
over
TLS
over
TCP
over
IP

Although HTTP/3 uses QUIC rather than TCP, which changes the transport layer.

For your current Nginx setup, HTTPS is commonly TCP + TLS + HTTP/1.1 or HTTP/2.

---

25. Nginx Reads the Request

Suppose the browser requests:

GET /

Nginx examines:

Hostname
Path
Method
Headers
TLS connection

For example:

Host: templates.cresignsys.com

Nginx uses its configuration to determine what should happen.

---

26. Nginx May Serve a Static File

If the request is for:

style.css

Nginx can directly read the file.

Conceptually:

Browser
 ↓
Nginx
 ↓
Filesystem
 ↓
style.css
 ↓
Nginx
 ↓
Browser

---

27. Nginx May Send the Request to PHP

If WordPress needs PHP processing:

Browser
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress

PHP-FPM executes the PHP application logic.

---

28. WordPress May Query MySQL

For dynamic content:

WordPress
 ↓
Database query
 ↓
MySQL
 ↓
Database result
 ↓
WordPress

Then:

WordPress
 ↓
HTML generation
 ↓
PHP-FPM
 ↓
Nginx
 ↓
TLS
 ↓
Internet
 ↓
Browser

---

29. One Browser Request — Full Journey

Here is the complete path:

USER
 │
 │ enters URL
 ▼
BROWSER
 │
 ▼
DNS
 │
 ▼
IP ADDRESS
 │
 ▼
INTERNET
 │
 ▼
SERVER NIC
 │
 ▼
LINUX NETWORK STACK
 │
 ▼
TCP
 │
 ▼
TLS
 │
 ▼
NGINX
 │
 ├──── static file ────► FILESYSTEM
 │
 └──── dynamic request ─► PHP-FPM
                              │
                              ▼
                          WORDPRESS
                              │
                              ▼
                            MYSQL
                              │
                              ▼
                         HTML RESPONSE
                              │
                              ▼
                           NGINX
                              │
                              ▼
                            TLS
                              │
                              ▼
                           BROWSER

---

30. The Most Important Layering Concept

Don’t think of the server as one program.

Think of it as layers:

Layer 1
Physical hardware

Layer 2
Firmware

Layer 3
Linux kernel

Layer 4
System services

Layer 5
Network stack

Layer 6
TLS

Layer 7
Web server

Layer 8
Application runtime

Layer 9
Application

Layer 10
Database

Each layer depends on lower layers.

---

31. Why This Matters for Troubleshooting

Suppose your website doesn’t open.

Don’t immediately assume:

“WordPress is broken.”

There are many possible layers:

DNS
 ↓
IP
 ↓
Firewall
 ↓
Network
 ↓
TCP
 ↓
TLS
 ↓
Nginx
 ↓
PHP
 ↓
WordPress
 ↓
MySQL

The correct troubleshooting method is:

Find the lowest layer that is failing, then move upward.

---

32. Example

If:

systemctl status nginx

shows Nginx is stopped, don’t troubleshoot WordPress first.

Check:

Hardware
 ↓
Linux
 ↓
systemd
 ↓
Nginx

Only after Nginx works should you move upward.

---

33. Your Current Learning Position

You started from:

Atom

and reached:

Linux command

The complete path is:

Atom
 ↓
Electron
 ↓
Charge
 ↓
Electricity
 ↓
Circuit
 ↓
Semiconductor
 ↓
Transistor
 ↓
Logic
 ↓
Binary
 ↓
CPU
 ↓
Computer
 ↓
Operating System
 ↓
Linux
 ↓
Command

Now we can begin going deeper into Linux itself.

---

34. Next Lesson — 017

What Is the Linux Filesystem?

We will start from the absolute foundation:

/
├── bin
├── boot
├── dev
├── etc
├── home
├── lib
├── media
├── mnt
├── opt
├── proc
├── root
├── run
├── sbin
├── srv
├── sys
├── tmp
├── usr
├── var
└── storage

We will learn what every directory actually means, why /etc contains configuration, why /var contains changing data, what /proc and /sys really are, and how your:

/storage/websites/

fits into the Linux architecture.

After that we can progress systematically through:

Linux filesystem → users → permissions → processes → services → networking → DNS → TCP/IP → TLS → Nginx → PHP-FPM → MySQL → WordPress → web hosting.

Course: From Basic Science to Web Hosting

Module 04 — Operating Systems

What Is an Operating System?

Difficulty: Beginner → Intermediate
Prerequisites: Lesson 014 — What Is a Computer?
Estimated time: 30 minutes

---

1. The Big Question

We now have:

Transistors
 ↓
Digital circuits
 ↓
CPU
 ↓
Memory
 ↓
Storage
 ↓
Computer

But there is a problem.

The hardware itself does not know what you mean when you say:

ls

or:

cd /storage/websites/

or:

sudo systemctl restart nginx

Something must translate software requests into controlled operations on hardware.

That major layer is the:

Operating System

---

2. What Is an Operating System?

An operating system, or OS, is system software that manages computer hardware and provides services and abstractions that applications use.

Examples:

Linux
Windows
macOS
Android

For your web server:

Ubuntu Linux

is the important operating-system environment.

---

3. The Computer Stack

Think of a computer as layers:

┌─────────────────────────────┐
│ Applications                │
│ WordPress, Nginx, PHP, etc. │
├─────────────────────────────┤
│ Libraries / Runtime         │
├─────────────────────────────┤
│ System Calls                │
├─────────────────────────────┤
│ Operating System / Kernel   │
├─────────────────────────────┤
│ Device Drivers              │
├─────────────────────────────┤
│ Hardware                    │
│ CPU / RAM / SSD / NIC       │
└─────────────────────────────┘

Each layer hides some complexity from the layer above it.

---

4. Why Do We Need an Operating System?

Imagine you want to save:

hello.txt

Without an operating system, software would need to understand enormous amounts of hardware detail:

SSD controller
 ↓
PCIe
 ↓
storage commands
 ↓
flash memory
 ↓
error correction
 ↓
physical storage locations

Instead, your application can ask the OS to create/write a file.

Application
    ↓
Operating System
    ↓
Filesystem
    ↓
Storage driver
    ↓
SSD

The OS provides the abstraction.

---

5. Hardware Is Physical

Your server has physical resources such as:

CPU
RAM
SSD
Network interface

The OS manages them.

For example:

CPU
 ↓
Processes

RAM
 ↓
Memory allocation

SSD
 ↓
Files

Network interface
 ↓
Network communication

---

6. The Kernel

The most important component of a traditional operating system is the:

Kernel

The kernel operates with high privileges and manages critical hardware and system resources.

Conceptually:

Applications
     ↓
System calls
     ↓
Kernel
     ↓
Hardware

Linux is fundamentally the name of the kernel.

---

7. Linux vs Ubuntu

This distinction is important.

Linux

Primarily refers to the Linux kernel.

Ubuntu

A Linux distribution.

It combines:

Linux kernel
+
System utilities
+
Package management
+
Libraries
+
Applications
+
Configuration

So:

Ubuntu
   ↓
uses
   ↓
Linux kernel

---

8. What Is a Linux Distribution?

A distribution packages the Linux kernel with many other components.

Examples:

Ubuntu
Debian
Fedora
Rocky Linux
Arch Linux

Your server uses Ubuntu.

Therefore:

Your server
 ↓
Ubuntu
 ↓
Linux kernel

---

9. Booting a Computer

What happens when a computer starts?

Very simplified:

Power ON
   ↓
Firmware
   ↓
Bootloader
   ↓
Linux kernel
   ↓
Initial userspace
   ↓
System services
   ↓
Login / applications

Let’s examine this carefully.

---

10. Firmware

When the machine starts, firmware initializes hardware and prepares the system to boot.

On modern PCs, this is commonly:

UEFI

The exact boot architecture can differ, especially in cloud environments.

---

11. Bootloader

The bootloader helps load the operating system kernel.

A common Linux bootloader is:

GRUB

Conceptually:

Firmware
   ↓
GRUB
   ↓
Linux kernel

Cloud environments may use different boot arrangements, so this is a general model rather than a universal sequence.

---

12. Linux Kernel Starts

The kernel is loaded into memory.

Then it begins initializing the system.

Conceptually:

Linux kernel
    ↓
CPU management
Memory management
Device initialization
Networking
Filesystem support
Process management

---

13. What Is a Process?

A process is a running instance of a program managed by the operating system.

For example:

Program:
nginx

Running instance:
nginx process

Another example:

Program:
php-fpm

Running instance:
php-fpm worker process

---

14. Program vs Process

This distinction is important.

Program

A stored set of instructions.

Example:

/usr/sbin/nginx

Process

That program currently executing.

nginx
   ↓
Process
   ↓
CPU + memory + OS resources

So:

Program = stored instructions

Process = executing instance

---

15. Multiple Processes

A server can run many processes simultaneously.

For example:

Linux
 │
 ├── nginx
 ├── php-fpm
 ├── mysqld
 ├── sshd
 └── system services

The kernel schedules CPU time among runnable processes.

---

16. CPU Scheduling

Suppose your CPU has work from:

Nginx
PHP
MySQL
SSH
System services

The kernel manages access to the CPU.

Simplified:

Process A
   ↓
CPU
   ↓
Process B
   ↓
CPU
   ↓
Process C
   ↓
CPU

Modern systems have multiple CPU cores, so multiple threads can execute simultaneously across cores.

---

17. Threads

A process can contain one or more threads of execution.

Conceptually:

Process
 ├── Thread 1
 ├── Thread 2
 └── Thread 3

Threads share much of the process’s memory and resources.

This becomes important for:

Web servers
Databases
Operating systems
Parallel computing

---

18. RAM and Virtual Memory

A process needs memory.

The operating system provides each process with a virtual address space.

Conceptually:

Process
 ↓
Virtual memory
 ↓
Physical memory
 ↓
RAM

This is a major abstraction.

A program generally doesn’t need to know the exact physical RAM location where every byte resides.

The OS and CPU’s memory-management hardware handle the mapping.

---

19. Memory Protection

One process should not normally be able to freely modify another process’s memory.

For example:

Nginx
   X
PHP memory

and:

PHP
   X
MySQL memory

The hardware and OS cooperate to provide memory isolation.

This is a major part of system security and stability.

---

20. Files

The OS provides a filesystem interface.

For example:

ls

asks the system to list directory contents.

Conceptually:

ls
 ↓
Shell
 ↓
System interface
 ↓
Filesystem
 ↓
Storage

---

21. Directories

Linux organizes files into a hierarchical directory structure.

For example:

/
├── etc
├── home
├── var
├── usr
├── tmp
└── storage

The root directory is:

/

Everything branches from it.

---

22. Your Website Path

You have used paths similar to:

/storage/websites/templates.cresignsys.com/public/

Break it down:

/
└── storage
    └── websites
        └── templates.cresignsys.com
            └── public

This is simply a directory hierarchy managed by the Linux filesystem.

---

23. Permissions

Linux controls who can access files and resources.

A file can have permissions for:

Owner
Group
Others

with permissions such as:

Read
Write
Execute

For example:

rwx

means:

r = read
w = write
x = execute

---

24. Users

Linux supports multiple user identities.

For example:

root
ubuntu
www-data

A process runs under a particular user identity.

For example, web-server processes often run with restricted privileges such as:

www-data

rather than full root privileges.

This reduces the impact of some security problems.

---

25. Root

The Linux root user has extremely powerful privileges.

For example:

sudo systemctl restart nginx

may execute the requested operation with elevated privileges.

Conceptually:

Normal user
    ↓
sudo
    ↓
root privileges
    ↓
Privileged operation

Because root access is powerful, commands should be used carefully.

---

26. What Is a Service?

A service is a program or group of processes managed to provide a continuing system function.

Examples:

nginx
mysql
ssh
php-fpm

On modern Ubuntu systems, systemd commonly manages services.

---

27. systemd

systemd is the primary system and service manager used by Ubuntu.

For example:

systemctl status nginx

asks systemd for the current state of the Nginx service.

Conceptually:

systemctl
   ↓
systemd
   ↓
Service
   ↓
Process

---

28. Starting a Service

For example:

sudo systemctl start nginx

Conceptually:

Command
 ↓
systemctl
 ↓
systemd
 ↓
Nginx
 ↓
Process starts

---

29. Restarting a Service

When you execute:

sudo systemctl restart nginx

the system roughly performs:

Stop/reconfigure service
        ↓
Start service
        ↓
New/reloaded process state

The exact internal sequence depends on the service and its unit configuration.

---

30. Networking

The operating system also manages network interfaces and networking functionality.

Conceptually:

Application
    ↓
Socket
    ↓
TCP/IP stack
    ↓
Network driver
    ↓
Network interface
    ↓
Cable / fiber / radio

This is the beginning of the path from your Linux server to the Internet.

---

31. What Is a Socket?

A socket is an operating-system interface that applications use for network communication.

Conceptually:

Nginx
 ↓
Socket
 ↓
TCP
 ↓
IP
 ↓
Network interface

A server can listen on a network address and port.

For example:

HTTP  → 80
HTTPS → 443

---

32. What Is a Port?

A port identifies a logical endpoint for network communication on a host.

For example:

Server IP
   +
TCP port 443
   ↓
HTTPS service

Therefore:

IP address
   ↓
Which machine/interface?

Port
   ↓
Which network service?

This distinction is fundamental to web hosting.

---

33. Operating System and Web Hosting

Now we can connect everything:

Physical server
      ↓
CPU / RAM / Storage / NIC
      ↓
Firmware
      ↓
Bootloader
      ↓
Linux kernel
      ↓
Ubuntu
      ↓
systemd
      ↓
Nginx
      ↓
PHP-FPM
      ↓
WordPress
      ↓
MySQL

And externally:

Browser
   ↓
Internet
   ↓
Server IP
   ↓
Port 443
   ↓
Nginx
   ↓
TLS
   ↓
HTTP
   ↓
WordPress

---

34. Your SSL Certificate Fits Here

You recently installed:

templates.cresignsys.com

with Let’s Encrypt.

The architecture is:

Browser
   ↓
HTTPS
   ↓
Port 443
   ↓
Nginx
   ↓
TLS certificate
   ↓
Encrypted connection
   ↓
HTTP request
   ↓
WordPress

Notice the important distinction:

TLS is not the operating system.

It operates at the networking/security layer above the basic OS networking facilities.

---

35. The Complete Stack

Your learning path is now:

PHYSICS
 ↓
Electrons
 ↓
Electricity
 ↓
Electronics
 ↓
Semiconductors
 ↓
Transistors
 ↓
Digital logic
 ↓
Binary
 ↓
CPU
 ↓
COMPUTER
 ↓
Operating System
 ↓
Linux
 ↓
Processes
 ↓
Memory
 ↓
Filesystem
 ↓
Networking
 ↓
TCP/IP
 ↓
TLS
 ↓
HTTP
 ↓
Nginx
 ↓
PHP
 ↓
WordPress
 ↓
Web Hosting

---

36. Quick Check

What is an operating system?

Software that manages hardware resources and provides services/abstractions for applications.

What is the kernel?

The privileged core of the operating system that manages fundamental system resources.

What is a process?

A running execution instance managed by the OS.

What is RAM?

Working memory used by running programs.

What is a filesystem?

A system for organizing and managing persistent files and directories.

What is systemd?

A system and service manager commonly used by Linux distributions such as Ubuntu.

What does Nginx do?

It can accept and process HTTP/HTTPS connections and serve or proxy web requests.

---

Next Lesson — 016

What Happens When You Type a Linux Command?

We will take a real command:

sudo systemctl restart nginx

and trace it from your keyboard all the way down to the CPU and back:

Keyboard
 ↓
Terminal
 ↓
Shell
 ↓
Command parsing
 ↓
sudo
 ↓
system call
 ↓
Linux kernel
 ↓
systemd
 ↓
Nginx
 ↓
CPU
 ↓
RAM
 ↓
Filesystem
 ↓
Network

This will be the foundation for understanding every Linux command you use while managing your web-hosting server.