Author: cresignsys

CresignSys Learn — Lesson 032
Linux Processes — Deep Basics

We now go one level deeper into the Ubuntu server.

Previously:
```
Hardware
 ↓
Linux Kernel
 ↓
Processes
 ↓
Services
 ↓
Nginx / PHP-FPM / MySQL
```
Now we answer:

What exactly is a process, how does Linux run it, and what happens when many users access your website simultaneously?

1. Program vs Process

These two words are different.

Program

A program is stored code.

Example:
```
/usr/sbin/nginx
```
It exists on storage.

Process

When that program is executed:
```
nginx executable
      ↓
Linux loads it
      ↓
Process
```
The process exists in memory and is actively running.

So:
```
Program
=
stored instructions

Process
=
running instance of those instructions
```
2. Simple Example

When you run:
```
ls
```
Linux finds the ls program and executes it.

Conceptually:
```
ls program
   ↓
process created
   ↓
CPU executes instructions
   ↓
output
   ↓
process exits
```
Nginx is different because it normally remains running.

3. Long-Running Process

Nginx:
```
Start
 ↓
Keep running
 ↓
Wait for requests
 ↓
Process requests
 ↓
Continue running
```
Similarly:
```
MySQL
PHP-FPM
SSH
```
are normally long-running services.

4. PID

Every running process receives a:

Process ID

or:

PID

For example:
```
PID 1
PID 100
PID 245
PID 1842
```
Run:
```
ps aux
```
and you’ll see process IDs.

5. PID 1

On your Ubuntu system, PID 1 is normally:
```
systemd
```
Conceptually:
```
Kernel
  ↓
systemd
  ↓
services
  ↓
processes
```
PID 1 has a particularly important role in the userspace system.

6. Parent Process

Processes can have relationships.

A process can create another process.

Conceptually:
```
Parent
  │
  ├── Child
  ├── Child
  └── Child
```
The operating system maintains parent/child relationships.

7. PPID

A process also has a:

Parent Process ID

or:

PPID

You can inspect this with commands such as:
```
ps -ef
```
You’ll see both:
```
PID
PPID
```
8. Example

Conceptually:
```
systemd
 PID 1
   │
   ▼
nginx
 PID 1000
 PPID 1
```
Then Nginx may create workers:
```
nginx master
 PID 1000
   │
   ├── worker PID 1001
   ├── worker PID 1002
   └── worker PID 1003
```
The exact process model depends on Nginx configuration and startup environment.

9. Nginx Master and Workers

Nginx commonly uses:
```
Master process
      │
      ├── Worker
      ├── Worker
      ├── Worker
      └── Worker
```
The master handles management tasks.

Workers handle connections and requests.

10. Why Multiple Workers?

Suppose your server has multiple CPU cores.

You don’t necessarily want one process handling everything.

Multiple workers can handle connections concurrently.

Conceptually:
```
             Nginx
               │
       ┌───────┼───────┐
       ▼       ▼       ▼
    Worker  Worker  Worker
```
11. Worker Processes

A worker can handle many connections depending on configuration and workload.

This is important:

One worker does not necessarily equal one visitor.

You could have:
```
4 workers
1000 connections
```
The workers can handle many connections using event-driven I/O.

12. Event-Driven Architecture

Nginx is designed around an event-driven model.

Instead of:
```
1 connection
 ↓
1 permanently occupied process
```
Nginx can efficiently manage many connections with a smaller number of worker processes.

Conceptually:
```
Worker
 │
 ├── Connection A
 ├── Connection B
 ├── Connection C
 ├── Connection D
 └── ...
```
This is one reason Nginx is efficient for handling large numbers of connections.

13. PHP-FPM Is Different

PHP-FPM commonly uses a pool of PHP worker processes.

Conceptually:
```
PHP-FPM
   │
   ├── PHP Worker 1
   ├── PHP Worker 2
   ├── PHP Worker 3
   └── PHP Worker 4
```
When Nginx needs PHP:
```
Nginx
 ↓
PHP-FPM
 ↓
available worker
 ↓
PHP execution
```
14. Why PHP Workers Matter

Suppose:
```
10 visitors
```
request dynamic WordPress pages simultaneously.

PHP-FPM needs enough worker capacity to process requests concurrently.

If all workers are busy:
```
Request
 ↓
PHP-FPM
 ↓
No available worker
 ↓
Wait
```
This can increase response time.

15. PHP-FPM Worker Pool

PHP-FPM can be configured with process-management modes such as:
```
static
dynamic
ondemand
```
These control how PHP worker processes are created and managed.

We will study these in detail later.

16. MySQL Process

MySQL is also a long-running service.

Conceptually:
```
systemd
   ↓
mysqld
   ↓
database engine
```
The MySQL server manages:
```
Connections
Queries
Memory
Tables
Indexes
Transactions
Storage
```
17. One WordPress Request

Now look at one request again:
```
Browser
 ↓
Nginx worker
 ↓
PHP-FPM worker
 ↓
WordPress
 ↓
MySQL
```
Several processes may participate in one request.

18. Many Requests

Suppose 20 users visit simultaneously:
```
                  Nginx
                    │
       ┌────────────┼────────────┐
       ▼            ▼            ▼
    Worker 1     Worker 2     Worker 3
       │            │            │
       └────────────┼────────────┘
                    ▼
                 PHP-FPM
             ┌──────┼──────┐
             ▼      ▼      ▼
           PHP 1  PHP 2  PHP 3
                    │
                    ▼
                  MySQL
```
This is a simplified representation, but it shows the relationship.

19. CPU Scheduling

The CPU cannot literally execute an unlimited number of instructions simultaneously on one core.

Linux uses scheduling.

Conceptually:
```
Process A
Process B
Process C
Process D
      ↓
CPU scheduler
      ↓
CPU cores
```
The kernel decides which runnable tasks receive CPU time.

20. Context Switching

Suppose the CPU is executing:
```
Process A
```
and then switches to:
```
Process B
```
Linux saves/restores execution state.

This is called:

Context switching

Conceptually:
```
CPU
 ↓
Process A
 ↓
save state
 ↓
Process B
 ↓
execute
```
Context switching has overhead, so having huge numbers of processes is not automatically better.

21. Threads

A process can contain multiple:

Threads

Conceptually:
```
Process
 ├── Thread 1
 ├── Thread 2
 └── Thread 3
```
Threads share many resources within their process.

The exact relationship between Linux tasks, threads, and processes is more nuanced, but this model is useful initially.

22. Process vs Thread

Simplified:
```
Process
=
independent execution environment

Thread
=
execution path within a process
```
Threads within a process can share memory.

This makes communication efficient but also introduces synchronization challenges.

23. Nginx and Threads

Nginx’s common architecture is heavily based on processes and event-driven workers rather than creating one thread per connection.

This is different from some other server architectures.

24. PHP and Threads

PHP-FPM generally uses separate worker processes rather than requiring a large multithreaded PHP execution model.

Conceptually:
```
PHP-FPM
 ↓
multiple worker processes
```
This gives process isolation between workers.

25. Process States

Linux processes can have different states.

You may encounter:
```
R
S
D
T
Z
```
The exact state meanings can be inspected through tools such as ps.

26. R — Running/Runnable

R represents a process that is running or runnable.

Conceptually:
```
Process
 ↓
ready to execute
```
It may be actively executing or waiting to be scheduled.

27. S — Sleeping

A sleeping process is waiting for an event.

For example:
```
Nginx worker
 ↓
waiting for network activity
```
This is normal.

A sleeping process isn’t necessarily broken.

28. D — Uninterruptible Sleep

D commonly indicates waiting in an uninterruptible kernel wait, often associated with I/O.

For example:
```
Process
 ↓
waiting for storage/network-related kernel operation
```
A large number of persistent D processes can indicate an underlying problem.

29. T — Stopped/Traced

A process can be stopped or traced.

For example, debugging tools can stop processes.

30. Z — Zombie

A zombie process is a process that has finished execution but whose parent has not yet collected its exit status.

Conceptually:
```
Child
 ↓
finishes
 ↓
Zombie
 ↓
Parent collects status
 ↓
removed
```
A small number of transient zombies can be normal.

Persistent large numbers can indicate a parent-process management problem.

31. Zombie Does Not Mean Running

A zombie process is:
```
finished execution
```
It is not actively consuming CPU like a normal running process.

It mainly remains as a process-table entry until its parent handles it.

32. Inspect Process States

You can use:
```
ps -eo pid,ppid,user,stat,comm
```
This gives a useful view of:
```
PID
PPID
USER
STATE
COMMAND
```
33. Process Tree

Try:
```
pstree -p
```
if available.

You may see something conceptually like:
```
systemd(1)
 ├─sshd(...)
 ├─nginx(...)
 │ ├─nginx(...)
 │ └─nginx(...)
 ├─php-fpm(...)
 │ ├─php-fpm(...)
 │ └─php-fpm(...)
 └─mysqld(...)
```
This is very useful when learning server architecture.

34. CPU Usage

Use:
```
top
```
You’ll see processes and CPU usage.

Conceptually:
```
PID
USER
CPU%
MEM%
COMMAND
```
35. Memory Usage

top also helps identify processes consuming significant memory.

For example:
```
php-fpm
mysqld
nginx
```
may have very different memory footprints.

36. Why PHP Can Consume a Lot of RAM

A PHP worker may load:
```
WordPress core
Plugins
Theme
Libraries
Application data
```
into memory.

A complex WordPress request can therefore consume considerably more memory than a simple static file request.

37. Static vs Dynamic Resource Cost

Compare:

Static
```
GET /logo.png
 ↓
Nginx
 ↓
disk/cache
 ↓
response
```
Dynamic
```
GET /article/
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
Plugins
 ↓
MySQL
 ↓
Theme
 ↓
HTML
```
Dynamic requests generally involve more computation.

38. Why Caching Is Powerful

Suppose the result of:
```
GET /article/
```
is cached.

Instead of:
```
Nginx
 ↓
PHP
 ↓
WordPress
 ↓
MySQL
```
the request might become:
```
Nginx
 ↓
Cache
 ↓
Response
```
This can dramatically reduce application work.

39. CPU Bottleneck

If CPU becomes saturated:
```
CPU
 ↓
100%
```
requests may take longer.

Possible symptoms:
```
Slow website
Slow PHP
Slow MySQL
High load
Timeouts
```
But high CPU does not automatically identify the root cause.

40. Memory Bottleneck

If available memory becomes very low:
```
RAM
 ↓
pressure
```
Linux may use swap and/or processes may encounter allocation problems.

Performance can degrade substantially.

41. Swap

Swap is disk-backed space used by the operating system as part of its virtual memory system.

Conceptually:
```
RAM
 ↓
memory pressure
 ↓
some pages may be moved/reclaimed
 ↓
swap/storage
```
Swap is much slower than RAM.

It is not a replacement for sufficient RAM.

42. Why Your Server Needs Monitoring

A hosting server should be watched for:
```
CPU
RAM
Swap
Disk
Disk I/O
Network
Processes
Connections
PHP-FPM workers
MySQL load
Nginx errors
```
This becomes the foundation of server monitoring.

43. Process Limits

Linux can impose limits on resources such as:
```
Open files
Processes
Memory
CPU
```
You can inspect shell limits with:
```
ulimit -a
```
Some limits can affect high-traffic applications.

44. File Descriptors

A process may need file descriptors for:
```
Files
TCP sockets
Unix sockets
Pipes
Other I/O resources
```
A busy Nginx server can have many open sockets.

Therefore:
```
Traffic
 ↓
Connections
 ↓
Sockets
 ↓
File descriptors
```
can become a scaling consideration.

45. Nginx Connection Capacity

If Nginx is configured for a certain number of worker connections, that becomes part of its capacity planning.

The actual effective maximum is influenced by:
```
worker_processes
worker_connections
file descriptor limits
CPU
memory
network
application latency
```
So worker_connections is not simply “the number of users the server supports.”

46. PHP-FPM Capacity

PHP-FPM has another important constraint:
```
Maximum simultaneous PHP workers
```
Suppose you have:
```
10 PHP workers
```
and:
```
50 dynamic requests
```
The first group can be processed while others may wait, depending on queue/backlog behavior.

47. The Bottleneck Principle

A web application can be limited by:
```
DNS
Network
CPU
RAM
Disk I/O
Nginx
PHP-FPM
MySQL
External API
```
The slowest constrained component can become the bottleneck.

48. Example

Suppose:
```
CPU:       20%
RAM:       40%
Disk:      normal
Nginx:     normal
PHP-FPM:   100% workers busy
MySQL:     normal
```
The likely immediate bottleneck is:
```
PHP-FPM capacity
```
Increasing CPU alone may not solve the problem.

49. Another Example

Suppose:
```
CPU:       30%
RAM:       40%
PHP-FPM:   normal
MySQL:     very slow
```
Then the application can still be slow because:
```
WordPress
 ↓
MySQL query
 ↓
slow
```
The server doesn’t need more PHP workers to solve a database bottleneck.

50. Another Example

Suppose:
```
CPU: 100%
PHP-FPM: busy
MySQL: busy
```
The first question becomes:

Which process is consuming CPU?

Run:
```
top
```
Then investigate the process and workload.

51. Signals

Linux can communicate with processes using:

Signals

Examples include:
```
SIGTERM
SIGKILL
SIGHUP
SIGINT
```
These have different semantics.

52. SIGTERM

SIGTERM is generally a request to terminate gracefully.

Conceptually:
```
system/service manager
       ↓
SIGTERM
       ↓
process
       ↓
clean shutdown
```
It gives the application an opportunity to clean up.

53. SIGKILL

SIGKILL forcibly terminates a process.

It cannot be caught or handled by the target process.

This is why it should not be the first choice for normal service management.

Prefer graceful service management whenever possible.

54. SIGHUP

Historically associated with terminal hangups, but many Unix daemons use it for configuration reload behavior.

For example, some services interpret SIGHUP as:
```
Reload configuration
```
The exact behavior is application-specific.

55. Why systemctl Is Better Than Random Signals

Instead of manually killing Nginx processes:
```
systemctl reload nginx
```
or:
```
systemctl restart nginx
```
lets systemd and the service’s unit configuration manage the operation properly.

This is safer and more predictable.

56. Nginx Graceful Reload

Nginx is designed to support configuration reloads with minimal disruption.

Typical workflow:
```
Edit config
 ↓
nginx -t
 ↓
systemctl reload nginx
```
This is an excellent production habit.

57. Process Monitoring

Useful commands:
```
ps aux
```
```
top
```
```
pstree -p
```
```
systemctl status nginx
```
```
systemctl status mysql
```
58. Find Nginx Processes

You can use:
```
ps aux | grep nginx
```
But remember that grep nginx itself can appear in the results.

A cleaner approach is often:
```
pgrep -a nginx
```
59. Find PHP-FPM

Depending on your PHP version:
```
pgrep -a php-fpm
```
or:
```
ps aux | grep php-fpm
```
60. Find MySQL
```
pgrep -a mysqld
```
Again, the exact process name can vary by installation.

61. A Real Request and Processes

Let’s put the entire lesson together.

User requests:
```
GET /
```
Then:
```
Nginx worker
   ↓
PHP-FPM worker
   ↓
WordPress
   ↓
MySQL
```
The kernel manages:
```
CPU
RAM
Sockets
Files
Scheduling
```
while systemd manages the long-running services.

62. Complete Linux Stack
```
                         USER
                           │
                           ▼
                        BROWSER
                           │
                           ▼
                         HTTP
                           │
                           ▼
                         NGINX
                           │
                     ┌─────┴─────┐
                     ▼           ▼
                Static files   PHP-FPM
                                  │
                                  ▼
                              WordPress
                                  │
                           ┌──────┴──────┐
                           ▼             ▼
                      Filesystem       MySQL
                           │             │
                           └──────┬──────┘
                                  ▼
                              RESPONSE
                                  │
                                  ▼
                                NGINX
                                  │
                                  ▼
                                NETWORK
                                  │
                                  ▼
                              LINUX KERNEL
                           ┌──────┼──────┐
                           ▼      ▼      ▼
                          CPU    RAM   Storage
```
63. The Most Important Concepts Today

Remember these distinctions:
```
Program
=
stored code

Process
=
running program

PID
=
process identifier

PPID
=
parent process identifier

Thread
=
execution path inside a process

Socket
=
communication endpoint

File descriptor
=
process handle for I/O resources

Service
=
managed long-running system component

systemd
=
service/process management framework
```
64. How This Helps Your Hosting Platform

When you eventually create a hosting dashboard, you could expose information such as:
```
Server Status
─────────────
CPU        22%
RAM        48%
Disk       37%
Nginx      Running
PHP-FPM    Running
MySQL      Running
SSL        Valid
```
Behind that simple dashboard are Linux commands and service APIs.

For example:
```
Dashboard
   ↓
Monitoring logic
   ↓
Linux/systemd
   ↓
Processes
   ↓
Metrics
```
65. The Next Layer: Virtual Memory

We have discussed:
```
CPU
RAM
Processes
Threads
```
but we haven’t yet explained something fundamental:

How can dozens or hundreds of processes each behave as if they have their own memory?

The answer is:

Virtual Memory

The next lesson will go deep into:
```
Physical RAM
 ↓
Virtual address
 ↓
Process address space
 ↓
Pages
 ↓
Page tables
 ↓
MMU
 ↓
TLB
 ↓
Physical memory
 ↓
Swap
```
Then we will connect it to:
```
Nginx memory
PHP-FPM memory
MySQL memory
WordPress memory
```
and understand why a VPS with 4 GB RAM can run many thousands of processes without each process directly owning a fixed physical section of RAM.
August 13, 2026
CresignSys Learn — Lesson 031
Linux Server Fundamentals

We now go one layer below:
```
DNS
 ↓
TCP/IP
 ↓
TLS
 ↓
HTTP
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress
```
The next question is:

What is the Ubuntu server underneath all these services?

1. A Server Is a Computer

Your VPS is fundamentally a computer.

At the deepest practical level:
```
Computer
├── CPU
├── RAM
├── Storage
├── Network
└── Operating System
```
Your hosting software runs on top of the operating system.

2. The Basic Linux Architecture

Think of Ubuntu like this:
```
Applications
    │
    ├── Nginx
    ├── PHP-FPM
    ├── MySQL
    ├── WordPress
    └── Certbot
          │
          ▼
      System Libraries
          │
          ▼
         Kernel
          │
    ┌─────┼─────┐
    ▼     ▼     ▼
   CPU   RAM   Storage
          │
          ▼
       Hardware
```
The Linux kernel is the central component connecting applications to the underlying resources.

3. What Is the Kernel?

The kernel is the core of the operating system.

It manages resources such as:
```
CPU
Memory
Processes
Filesystems
Networking
Devices
Security
```
Applications normally do not directly control hardware.

Instead:
```
Application
    ↓
System call
    ↓
Linux kernel
    ↓
Hardware/resource
```
4. Example: Reading a File

Suppose Nginx needs:
```
/storage/websites/templates.cresignsys.com/public/index.html
```
Conceptually:
```
Nginx
 ↓
Request file
 ↓
Linux kernel
 ↓
Filesystem
 ↓
Storage
 ↓
Data
 ↓
Kernel
 ↓
Nginx
```
Nginx doesn’t directly operate the physical SSD.

The kernel manages that interaction.

5. Example: Sending Network Data

When Nginx sends an HTTP response:
```
Nginx
 ↓
Socket
 ↓
Linux networking stack
 ↓
Network interface
 ↓
Cloud virtual network
 ↓
Internet
```
Again, the kernel manages the underlying networking.

6. CPU

The CPU executes instructions.

Programs such as:
```
nginx
php-fpm
mysqld
sshd
```
are executable programs loaded into memory and executed by the CPU.

Conceptually:
```
Program
 ↓
Instructions
 ↓
CPU
 ↓
Execution
```
7. CPU Cores

A VPS may be allocated one or more virtual CPU cores.

For example:
```
CPU
├── vCPU 1
├── vCPU 2
├── vCPU 3
└── vCPU 4
```
The exact virtualization model depends on the cloud provider.

Multiple processes can run concurrently across available CPU resources.

8. RAM

RAM is working memory.

When Nginx runs:
```
Nginx program
```
its active code/data resides in memory.

Similarly:
```
PHP-FPM
MySQL
WordPress PHP execution
```
use RAM.

Conceptually:
```
Storage
   ↓
Program files
   ↓
RAM
   ↓
CPU
```
9. Storage

Storage is persistent.

It contains:
```
Ubuntu files
Nginx configuration
WordPress
Plugins
Themes
MySQL data
Logs
SSL certificates
Backups
```
Unlike RAM, storage is intended to retain data across reboots.

10. RAM vs Storage

Memorize:
```
RAM
=
working memory

Storage
=
persistent data
```
For example:
```
WordPress PHP file
     ↓
stored on disk

PHP executes it
     ↓
code/data loaded into memory
```
11. Processes

Linux runs programs as:

Processes

Run:
```
ps aux
```
You may see processes such as:
```
root
www-data
mysql
nginx
systemd
```
and many others.

12. What Is a Process?

A process is a running instance of a program.

For example:
```
Program:
nginx

Running instance:
nginx process
```
Conceptually:
```
Executable file
      ↓
Process
      ↓
CPU + RAM + resources
```
13. Process ID

Every Linux process has a:

PID

Process ID.

For example:
```
PID 1
PID 500
PID 1200
PID 2500
```
You can inspect processes using:
```
ps aux
```
or:
```
ps -ef
```
14. PID 1

One of the most important Linux processes is:
```
PID 1
```
On modern Ubuntu systems, this is typically:
```
systemd
```
It is the first userspace process started by the kernel.

Conceptually:
```
Kernel
 ↓
systemd (PID 1)
 ↓
Services
 ↓
Nginx
PHP-FPM
MySQL
SSH
...
```
15. systemd

systemd manages many system services.

For example:
```
systemctl status nginx
```
asks systemd about Nginx.

Similarly:
```
systemctl status mysql
```
asks about MySQL.

16. Service

A service is a long-running/background system component.

Examples:
```
nginx
mysql
php-fpm
ssh
cron
```
Conceptually:
```
systemd
 ├── nginx.service
 ├── mysql.service
 ├── php-fpm.service
 └── ssh.service
```
17. Start a Service

For example:
```
sudo systemctl start nginx
```
This asks systemd to start Nginx.

18. Stop a Service
```
sudo systemctl stop nginx
```
This stops Nginx.

19. Restart a Service
```
sudo systemctl restart nginx
```
This stops and starts the service.

Use restarts carefully on production servers.

20. Reload vs Restart

This distinction is important.

Reload
```
sudo systemctl reload nginx
```
Typically asks Nginx to reload its configuration while preserving existing worker processes/connections as appropriate.

Restart
```
sudo systemctl restart nginx
```
Stops and starts the service.

For configuration changes, a reload is often preferable when supported.

21. Enable at Boot
```
sudo systemctl enable nginx
```
This configures Nginx to start automatically during boot according to its systemd unit configuration.

22. Check Status
```
sudo systemctl status nginx
```
You might see:
```
Active: active (running)
```
This means systemd considers the service running.

23. systemctl Mental Model

Think:
```
systemctl
   ↓
systemd
   ↓
service
   ↓
process
```
For example:
```
systemctl
   ↓
nginx.service
   ↓
nginx master/worker processes
```
24. Users

Linux is a multi-user operating system.

You can have:
```
root
ubuntu
www-data
mysql
```
and many others.

Different processes can run under different users.

25. Root

root is the superuser.

It has extensive privileges over the system.

Commands such as:
```
sudo systemctl restart nginx
```
temporarily request elevated privileges.

26. sudo

Suppose you’re logged in as:
```
ubuntu
```
but need to perform an administrative operation.

You can use:
```
sudo command
```
For example:
```
sudo nginx -t
```
Conceptually:
```
ubuntu user
   ↓
sudo
   ↓
privileged execution
```
27. Why Not Run Everything as Root?

Because a compromised application running with unrestricted privileges could potentially cause much greater damage.

This leads to:

Principle of Least Privilege

Give each process only the permissions it needs.

28. www-data

On Ubuntu/Debian systems, web services often use:
```
www-data
```
as a service account.

For example, PHP-FPM workers may run as:
```
www-data
```
depending on configuration.

This means WordPress operations can be restricted by Linux permissions.

29. MySQL User

MySQL commonly has its own system account:
```
mysql
```
The database process runs under that account rather than as an ordinary web user.

Conceptually:
```
Nginx
  ↓
www-data
  ↓
PHP-FPM
  ↓
MySQL
  ↓
mysql user
```
The exact permissions and process model depend on configuration.

30. Files and Directories

Linux organizes storage as a hierarchy.

At the top:
```
/
```
called:

Root filesystem

Under it:
```
/etc
/var
/home
/usr
/opt
/tmp
/run
/storage
```
and many others.

31. /etc

This generally contains system and application configuration.

For example:
```
/etc/nginx/
/etc/php/
/etc/mysql/
/etc/ssh/
```
Your Nginx configuration lives under:
```
/etc/nginx/
```
32. /var

Often contains changing application/system data.

Examples:
```
/var/log/
/var/lib/
/var/cache/
```
Logs commonly live under:
```
/var/log/
```
33. /var/log

Examples:
```
/var/log/nginx/
/var/log/mysql/
/var/log/syslog/
```
Logs are essential for troubleshooting.

34. /run

Contains runtime state.

For example, service sockets can exist under:
```
/run/php/
```
A PHP-FPM Unix socket might be:
```
/run/php/php8.3-fpm.sock
```
depending on your PHP version/configuration.

35. /home

Usually contains users’ home directories.

For example:
```
/home/ubuntu
```
36. Your /storage

You have been using paths such as:
```
/storage/websites/
```
This is not one of the standard top-level directories required by Linux.

It is a directory/mount chosen for your server architecture.

Conceptually:
```
/storage
   ↓
websites
   ↓
domain
   ↓
public
```
37. Your Hosting Structure

For example:
```
/storage/websites/
    │
    ├── templates.cresignsys.com/
    │      └── public/
    │
    ├── learn.cresignsys.com/
    │      └── public/
    │
    └── shop.cresignsys.com/
           └── public/
```
This is your hosting filesystem organization.

38. Linux Permissions

Every file/directory has permissions.

Run:
```
ls -l
```
You might see:
```
-rw-r--r-- 1 ubuntu ubuntu 1234 index.php
```
This contains several pieces of information.

39. Permission Structure

Consider:
```
-rw-r--r--
```
Break it down:
```
-
rw-
r--
r--
```
The first character indicates the object type.

Then three permission groups:
```
Owner
Group
Others
```
40. r

Means:

Read

For a file:
```
r
```
means the user can read the file.

41. w

Means:

Write

For a file:
```
w
```
means the user can modify its contents.

42. x

Means:

Execute

For a file:
```
x
```
means it can be executed as a program, subject to other conditions.

For directories, x has a different but very important meaning: it permits traversal/search through the directory.

43. Directory Permissions

This is subtle.

For a directory:
```
r
```
generally allows listing directory entries.
```
x
```
allows traversing/searching the directory.
```
w
```
allows modifying directory entries, subject to the combination of permissions.

This is why directory permissions need to be understood separately from file permissions.

44. WordPress Permissions

Your web server needs appropriate access to:
```
wp-content/
uploads/
plugins/
themes/
```
depending on what WordPress needs to do.

But giving everything:
```
777
```
is generally a bad security practice.

45. 777

You may encounter:
```
chmod -R 777 website/
```
Do not use this as a generic fix.

It grants broad read/write/execute permissions and can create serious security problems.

Correct permissions depend on:
```
Owner
Group
Web server user
Deployment method
Application requirements
```
46. Ownership

Check ownership with:
```
ls -l
```
Example:
```
www-data www-data
```
means:
```
Owner = www-data
Group = www-data
```
Ownership is separate from the permission bits.

47. chown

Changes ownership.

Example:
```
sudo chown user:group file
```
This is a powerful command.

Do not recursively change ownership across your whole server without understanding the consequences.

48. chmod

Changes permission bits.

For example:
```
chmod 644 file
```
means a common file permission pattern:
```
Owner  → read/write
Group  → read
Others → read
```
For directories, commonly used permission patterns differ because directories need traversal.

49. Symbolic Representation

Common permissions:
```
644
```
means:
```
Owner: 6
Group: 4
Others: 4
```
The numbers are based on:
```
r = 4
w = 2
x = 1
```
So:
```
6 = 4 + 2 = rw-
4 = r--
4 = r--
```
50. 755
```
755
```
means:
```
Owner  → rwx
Group  → r-x
Others → r-x
```
This is commonly used for directories and executable scripts where appropriate.

But permissions should be chosen based on actual requirements rather than blindly applying 755 everywhere.

51. Processes and Permissions Connect

Suppose PHP-FPM runs as:
```
www-data
```
and a file belongs to:
```
ubuntu
```
with permissions:
```
-rw-------
```
Then www-data may not be able to read it.

Result:
```
PHP
 ↓
File access
 ↓
Permission denied
```
This can cause application failures.

52. Linux Networking

Now move from filesystem to networking.

Linux exposes network interfaces.

Run:
```
ip addr
```
You may see interfaces such as:
```
lo
eth0
ens3
```
The exact interface name depends on the environment.

53. Loopback

The interface:
```
lo
```
is:

Loopback

Typically:
```
127.0.0.1
```
for IPv4.

It represents the local machine.

54. Why Loopback Matters

Suppose Nginx communicates with PHP-FPM using:
```
127.0.0.1:9000
```
Then:
```
Nginx
 ↓
localhost
 ↓
PHP-FPM
```
The traffic doesn’t leave the machine through the public Internet.

55. Network Interface

A network interface connects the system to a network.

Conceptually:
```
Linux
 │
 ├── lo
 │
 └── eth0
       ↓
    Cloud network
       ↓
    Internet
```
The actual cloud networking architecture is more complex.

56. IP Addresses on Linux

Run:
```
ip addr
```
You may see:
```
127.0.0.1
```
and a private/internal address such as:
```
10.x.x.x
```
or another private range.

Your cloud provider may separately associate a public IP with the VM through its virtual networking system.

57. Routing Table

Linux needs to know:

Where should packets go?

Run:
```
ip route
```
You may see a default route.

Conceptually:
```
Destination
     ↓
Routing table
     ↓
Interface / gateway
```
58. Default Route

A default route means roughly:

If there isn’t a more specific route, send the packet this way.

Conceptually:
```
Unknown destination
       ↓
default route
       ↓
gateway
```
59. Sockets

Now we connect networking to applications.

A socket is an endpoint used by applications for network communication.

Conceptually:
```
Application
    ↓
Socket
    ↓
TCP/UDP
    ↓
IP
```
60. Nginx Listening

When Nginx listens on:
```
0.0.0.0:443
```
it is waiting for incoming TCP connections on port 443 on IPv4 interfaces.

You can inspect this using:
```
sudo ss -lntp
```
61. Understanding ss

Example:
```
LISTEN
```
means a socket is waiting for connections.
```
0.0.0.0:443
```
means IPv4 address wildcard + port 443.
```
[::]:443
```
represents an IPv6 wildcard listener.

62. Process → Socket

Now the relationship becomes:
```
Nginx process
      ↓
Socket
      ↓
TCP 443
      ↓
Network interface
      ↓
Internet
```
This is how a web server becomes reachable.

63. SSH

You also connect to the server through a network service.

Typically:
```
SSH client
 ↓
TCP 22
 ↓
sshd
 ↓
Linux
```
The SSH daemon is commonly:
```
sshd
```
64. SSH and Nginx Are Similar at One Level

Both are programs listening on network sockets.

For example:
```
sshd
 ↓
TCP 22
```
and:
```
nginx
 ↓
TCP 443
```
Different application protocols, same fundamental networking concept.

65. Server Services Map

Your server may look conceptually like:
```
Ubuntu
 │
 ├── sshd
 │     └── TCP 22
 │
 ├── nginx
 │     ├── TCP 80
 │     └── TCP 443
 │
 ├── php-fpm
 │     └── Unix socket / TCP
 │
 └── mysql
       └── database socket / TCP
```
Not every service must be publicly exposed.

That is a major security principle.

66. MySQL Should Usually Not Be Public

If WordPress and MySQL are on the same VPS:
```
WordPress
 ↓
localhost/socket
 ↓
MySQL
```
There is usually no need to expose MySQL publicly.

A safer conceptual architecture is:
```
Internet
   ↓
Nginx :443
   ↓
PHP-FPM
   ↓
MySQL
```
rather than:
```
Internet
   ↓
MySQL :3306
```
67. Service Exposure

Ask for every service:

Does this service actually need to be reachable from the Internet?

For example:
```
Nginx :443
YES

Nginx :80
Usually yes for HTTP/HTTPS redirects and ACME HTTP validation, depending on setup

MySQL :3306
Usually no

PHP-FPM
Usually no

Redis
Usually no
```
This is a fundamental server-security concept.

68. Linux Security Model

Now the architecture becomes:
```
Internet
   ↓
Cloud firewall
   ↓
Ubuntu firewall
   ↓
Network socket
   ↓
Process
   ↓
Linux user
   ↓
Filesystem permissions
```
Security exists at multiple layers.

69. Defense in Depth

You should not rely on only one security mechanism.

For example:
```
Cloud firewall
      +
Ubuntu firewall
      +
Nginx configuration
      +
Linux permissions
      +
Application authentication
      +
TLS
```
This is called:

Defense in depth

70. The Server Is Not One Thing

When you say:

“My server is running.”

that doesn’t necessarily mean the website is working.

The server contains many independent components:
```
Kernel
systemd
Network
Nginx
PHP-FPM
MySQL
WordPress
Storage
DNS
TLS
```
Any one of them can fail independently.

71. A Better Mental Model

Think of your VPS as a small city:
```
Kernel
=
city infrastructure

Processes
=
businesses

Users
=
people/accounts

Ports
=
doors

Sockets
=
doorways/endpoints

Filesystem
=
buildings/storage

Permissions
=
access control

systemd
=
service manager

Nginx
=
front desk

PHP-FPM
=
application workers

MySQL
=
records/archive
```
This analogy is useful for understanding the relationships, but the actual Linux mechanisms are more precise.

72. Essential Commands

Start memorizing these:

CPU/RAM
```
top
```
or:
```
htop
```
if installed.

Processes
```
ps aux
```
Services
```
systemctl status nginx
```
Network
```
ip addr
```
Routes
```
ip route
```
Ports
```
sudo ss -lntp
```
Files
```
ls -la
```
Disk
```
df -h
```
Memory
```
free -h
```
73. df -h

This shows filesystem capacity.

For example:
```
df -h
```
You might see:
```
Filesystem
Size
Used
Avail
Use%
Mounted on
```
This is essential for hosting servers.

If your storage reaches 100%:
```
MySQL
Nginx
PHP
WordPress
```
can all start behaving unexpectedly.

74. free -h

Shows memory usage.
```
free -h
```
Conceptually:
```
Total
Used
Free
Shared
Buffers/cache
Available
Swap
```
Memory pressure can affect PHP-FPM, MySQL and other services.

75. uptime

Try:
```
uptime
```
It gives information including:
```
System uptime
Logged-in users
Load averages
```
76. Load Average

You may see:
```
load average: 0.20, 0.15, 0.10
```
These correspond to different time windows.

Load average is not simply “CPU percentage.”

It represents runnable/uninterruptible work in the system’s scheduling/load model.

This is a deeper Linux performance topic we will study later.

77. Process Tree

Use:
```
pstree
```
if installed.

You may see relationships such as:
```
systemd
 ├── sshd
 ├── nginx
 │    ├── nginx worker
 │    └── nginx worker
 ├── php-fpm
 └── mysqld
```
This helps visualize process hierarchy.

78. Parent and Child Processes

A process can create another process.

Conceptually:
```
Parent
  ↓
Child
```
The operating system tracks these relationships.

This is another reason PID information matters.

79. File Descriptors

This is a deeper Linux concept.

Processes interact with files, sockets and other resources using:

File descriptors

Conceptually:
```
Process
 ├── FD 0 → stdin
 ├── FD 1 → stdout
 ├── FD 2 → stderr
 └── other FDs → files/sockets
```
A network socket can be represented by a file descriptor inside a process.

This is why Linux has such a unified model around files and I/O.

80. Why This Matters for Nginx

Nginx can have many open connections.

Conceptually:
```
Nginx worker
 ├── socket FD
 ├── socket FD
 ├── file FD
 ├── socket FD
 └── ...
```
Operating-system limits on file descriptors therefore matter for high-traffic servers.

We will study this later.

81. The Deep Architecture

You can now visualize your server as:
```
                     INTERNET
                         │
                         ▼
                       DNS
                         │
                         ▼
                     CLOUD NET
                         │
                         ▼
                    LINUX KERNEL
                         │
       ┌─────────────────┼─────────────────┐
       ▼                 ▼                 ▼
     NETWORK            FILES             CPU/RAM
       │                 │                 │
       ▼                 ▼                 ▼
     SOCKETS          FILESYSTEM         PROCESSES
       │                 │                 │
       └─────────────────┼─────────────────┘
                         ▼
                      systemd
                         │
          ┌──────────────┼──────────────┐
          ▼              ▼              ▼
        Nginx          PHP-FPM         MySQL
          │              │              │
          └──────────────┼──────────────┘
                         ▼
                      WordPress
```
82. The Most Important New Concept

The key idea from this lesson is:

Applications don’t directly own the machine. They request resources from the operating system kernel.

For example:
```
Nginx
 ↓
kernel
 ↓
network
```
and:
```
PHP
 ↓
kernel
 ↓
filesystem
```
and:
```
MySQL
 ↓
kernel
 ↓
storage
```
83. From Your Hosting Platform Perspective

Your CresignSys hosting system is ultimately an automation layer above all of this:
```
CresignSys Hosting Platform
            │
            ▼
       Linux commands
            │
            ▼
          systemd
            │
     ┌──────┼──────┐
     ▼      ▼      ▼
   Nginx   PHP    MySQL
     │      │      │
     └──────┼──────┘
            ▼
         Website
```
A hosting panel is therefore not magic.

It is automation and management around these underlying technologies.

Lesson 031 Summary

You now understand the foundation underneath your hosting server:
```
Hardware
 ↓
CPU / RAM / Storage / Network
 ↓
Linux Kernel
 ↓
Processes
 ↓
Users
 ↓
Permissions
 ↓
Filesystems
 ↓
Sockets
 ↓
systemd
 ↓
Services
 ↓
Nginx
 ↓
PHP-FPM
 ↓
MySQL
```
And the critical commands:
```
ps aux
systemctl status nginx
ip addr
ip route
sudo ss -lntp
ls -la
df -h
free -h
uptime
```
Next Lesson — 032

Linux Processes — The Deep Basics

We will go deeper into:
```
Program
 ↓
Process
 ↓
PID
 ↓
Parent process
 ↓
Child process
 ↓
Threads
 ↓
CPU scheduling
 ↓
Memory
 ↓
Virtual memory
 ↓
File descriptors
 ↓
Signals
 ↓
Process states
 ↓
Zombie processes
 ↓
systemd services
```
Then we will connect these concepts directly to:
```
Nginx workers
PHP-FPM workers
MySQL processes
WordPress requests
```
so you can understand what is actually happening inside the VPS when 1, 10, or 1,000 visitors access your websites.
August 13, 2026
CresignSys Learn — Lesson 030
One WordPress Request: Browser → Nginx → PHP-FPM → MySQL

This lesson connects the networking concepts to the actual WordPress server you are operating.

We will follow:
```
https://templates.cresignsys.com/
```
from the browser to the server and back.

1. The Complete Architecture

The request travels through:
```
Browser
   ↓
DNS
   ↓
IP address
   ↓
TCP 443
   ↓
TLS
   ↓
HTTP
   ↓
Nginx
   ↓
FastCGI
   ↓
PHP-FPM
   ↓
PHP
   ↓
WordPress
   ↓
MySQL
   ↓
Filesystem
   ↓
HTML
   ↓
Nginx
   ↓
TLS
   ↓
Browser
```
We will now examine each step.

2. The Browser Requests the Website

You type:
```
https://templates.cresignsys.com/
```
The browser determines:
```
Scheme:
https

Hostname:
templates.cresignsys.com

Port:
443

Path:
/
```
3. DNS

The browser needs the server IP.

Conceptually:
```
templates.cresignsys.com
          ↓
         DNS
          ↓
      Server IP
```
For example:
```
203.0.113.10
```
The address above is only an example.

4. TCP

The browser establishes a TCP connection:
```
Client
   │
   │ SYN
   ▼
Server
   │
   │ SYN-ACK
   ▼
Client
   │
   │ ACK
   ▼
Server
```
Now:
```
TCP connection = established
```
5. TLS

Because the URL uses:
```
https://
```
TLS begins.

The browser and server negotiate a secure connection.

The browser also indicates the requested hostname using SNI:
```
SNI:
templates.cresignsys.com
```
6. Nginx Presents the Certificate

Your Nginx configuration has access to:
```
/etc/letsencrypt/live/templates.cresignsys.com/fullchain.pem
```
and:
```
/etc/letsencrypt/live/templates.cresignsys.com/privkey.pem
```
Nginx uses the TLS configuration to participate in the handshake.

The browser validates the certificate.

7. Secure Channel

After the TLS handshake:
```
Browser
   │
   │ encrypted TLS data
   ▼
Nginx
```
The HTTP request is now protected in transit.

8. HTTP Request

Conceptually, the browser sends:
```
GET / HTTP/1.1
Host: templates.cresignsys.com
```
A real browser sends many additional headers.

The important idea is:
```
GET
 ↓
/
 ↓
Host
 ↓
templates.cresignsys.com
```
9. TLS Decryption

At the server:
```
Encrypted TLS records
          ↓
         TLS
          ↓
       HTTP data
```
Nginx/TLS processing obtains the HTTP request.

Now Nginx can process:
```
GET /
Host: templates.cresignsys.com
```
10. Nginx Has a Problem to Solve

Nginx asks:

Which website configuration should handle this request?

The server may host:
```
templates.cresignsys.com
learn.cresignsys.com
shop.cresignsys.com
manage.cresignsys.com
```
all on the same IP.

11. server_name

Your Nginx configuration may contain:
```
server_name templates.cresignsys.com;
```
Nginx matches the requested hostname.

Conceptually:
```
Host:
templates.cresignsys.com
        ↓
Nginx
        ↓
server_name:
templates.cresignsys.com
```
Now Nginx has selected the correct virtual host.

12. Virtual Host

A virtual host is essentially:

A configuration that tells the web server how to handle a particular website.

Conceptually:
```
Nginx
 │
 ├── templates.cresignsys.com
 │       ↓
 │     Site A
 │
 ├── learn.cresignsys.com
 │       ↓
 │     Site B
 │
 └── shop.cresignsys.com
         ↓
       Site C
```
This is the basis of multi-domain hosting.

13. Document Root

The Nginx configuration may specify:
```
root /storage/websites/templates.cresignsys.com/public;
```
This tells Nginx where website files live.

Conceptually:
```
templates.cresignsys.com
          ↓
Nginx
          ↓
/storage/websites/templates.cresignsys.com/public
```
14. What Does / Mean?

The browser requested:
```
GET /
```
The / means:

Request the root resource of the website.

Nginx needs to determine what file or application should handle it.

15. Static vs Dynamic

Nginx can handle two broad categories.

Static
```
HTML
CSS
JavaScript
Images
Fonts
PDF
```
Dynamic
```
PHP
WordPress
Database-driven pages
APIs
```
16. WordPress Is Dynamic

A WordPress page isn’t normally stored as:
```
/about.html
```
Instead, WordPress generates the response dynamically.

So a request such as:
```
/about/
```
may eventually be processed through:
```
index.php
```
17. try_files

A typical Nginx WordPress configuration often contains logic similar to:
```
try_files $uri $uri/ /index.php?$args;
```
The exact configuration can differ.

The basic idea is:
```
Does requested file exist?
       ↓
YES → serve it
       ↓
NO
       ↓
Send request to WordPress
```
18. Example: CSS File

Browser requests:
```
GET /style.css
```
Nginx checks:
```
/storage/websites/templates.cresignsys.com/public/style.css
```
If it exists:
```
Nginx
 ↓
Read file
 ↓
Return CSS
```
PHP isn’t needed.

19. Example: WordPress Page

Browser requests:
```
GET /about/
```
Nginx checks whether:
```
/about/
```
corresponds to a real file/directory.

If not, it may send the request to:
```
/index.php
```
Now PHP becomes involved.

20. FastCGI

Nginx commonly communicates with PHP-FPM using:

FastCGI

Conceptually:
```
Nginx
  ↓
FastCGI
  ↓
PHP-FPM
```
FastCGI is a protocol/interface for communication between a web server and application processes.

21. Why PHP-FPM?

PHP-FPM means:

PHP FastCGI Process Manager

It manages PHP worker processes.

Conceptually:
```
Nginx
   ↓
PHP-FPM
   │
   ├── PHP worker
   ├── PHP worker
   ├── PHP worker
   └── PHP worker
```
22. Why Workers?

Imagine 100 users request pages simultaneously.

You don’t want to start an entirely new PHP environment from scratch for every request.

PHP-FPM maintains worker processes that can execute PHP requests.

Conceptually:
```
100 requests
     ↓
PHP-FPM
     ↓
Worker pool
```
The exact scheduling behavior depends on PHP-FPM configuration.

23. PHP Socket

Nginx may communicate with PHP-FPM through a Unix socket such as:
```
/run/php/php8.3-fpm.sock
```
The exact version/path depends on your server.

Alternatively, PHP-FPM can listen on a TCP socket.

For example:
```
127.0.0.1:9000
```
24. Unix Socket vs TCP

Two possible architectures:

Unix socket
```
Nginx
 ↓
Unix socket
 ↓
PHP-FPM
```
TCP
```
Nginx
 ↓
TCP
 ↓
PHP-FPM
```
For PHP-FPM on the same server, Unix sockets are commonly used.

25. Nginx Sends the PHP Request

Conceptually:
```
Nginx
 │
 │ "Execute /index.php"
 ▼
PHP-FPM
```
Nginx also passes relevant request/environment information required by the PHP application.

26. PHP-FPM Executes PHP

PHP-FPM starts/uses a PHP worker.

The worker executes:
```
index.php
```
which leads into WordPress.

27. WordPress Bootstrap

WordPress has a large PHP execution flow.

At a simplified level:
```
index.php
   ↓
wp-blog-header.php
   ↓
wp-load.php
   ↓
wp-config.php
   ↓
WordPress core
```
The exact internal execution path depends on the request and WordPress version.

28. wp-config.php

WordPress needs configuration information.

This includes database connection information.

Conceptually:
```
WordPress
   ↓
wp-config.php
   ↓
Database configuration
```
The actual database credentials in your file are sensitive and should never be shared publicly.

29. WordPress Connects to MySQL

Now:
```
WordPress
    ↓
Database connection
    ↓
MySQL
```
WordPress asks the database for information.

For example:
```
Which page is `/about/`?
What is its title?
What is its content?
Which settings apply?
```
30. Database Is Not the Website

Another important distinction:

MySQL does not contain the entire WordPress website.

WordPress is split between:
```
Filesystem
+
Database
```
31. Filesystem Contains

The filesystem contains things such as:
```
WordPress core
Themes
Plugins
Uploaded media
PHP files
CSS
JavaScript
Configuration
```
32. Database Contains

The database commonly contains:
```
Posts
Pages
Users
Settings
Metadata
Comments
Plugin data
Theme-related data
```
The exact data depends on WordPress and installed plugins.

33. WordPress Combines Both

Conceptually:
```
                 WordPress
                    │
          ┌─────────┴─────────┐
          ▼                   ▼
     Filesystem             MySQL
          │                   │
          │                   │
          └─────────┬─────────┘
                    ▼
              Generated page
```
34. Theme

WordPress determines which theme/template should render the page.

Conceptually:
```
WordPress
   ↓
Theme
   ↓
Template
   ↓
HTML
```
The actual template hierarchy is more sophisticated.

35. Plugins

Plugins can modify the request processing.

For example:
```
Request
 ↓
WordPress
 ↓
Plugin
 ↓
Modify query/content
 ↓
Theme
 ↓
Response
```
A badly functioning plugin can therefore cause:
```
500 Internal Server Error
```
or other application problems.

36. WordPress Generates HTML

Eventually PHP generates something like:
```
<!doctype html>
<html>
<head>
<title>Templates</title>
</head>
<body>
<h1>Templates</h1>
</body>
</html>
```
This is generated dynamically.

37. PHP Returns to Nginx

The result flows back:
```
WordPress
   ↓
PHP
   ↓
PHP-FPM
   ↓
Nginx
```
Nginx now has the generated response.

38. Nginx Adds/Handles HTTP Response Details

Nginx may handle:
```
HTTP status
Headers
Compression
Caching
Security headers
Connection handling
```
depending on configuration.

39. HTTP Response

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

<!doctype html>
<html>
...
</html>
```
40. TLS Encrypts the Response

Before the response travels across the Internet:
```
HTTP response
      ↓
TLS
      ↓
Encrypted TLS records
```
Then:
```
TLS
 ↓
TCP
 ↓
IP
 ↓
Internet
```
41. Browser Receives It

The browser:
```
Encrypted data
      ↓
TLS
      ↓
HTTP response
      ↓
HTML
```
Then it parses the HTML.

42. Browser Finds More Resources

Suppose the HTML contains:
```
<link rel="stylesheet" href="/style.css">
<script src="/app.js"></script>
<img src="/logo.png">
```
The browser now makes additional requests:
```
GET /style.css
GET /app.js
GET /logo.png
```
So the original page causes a chain of additional requests.

43. One Page Can Become Hundreds of Requests

A modern WordPress page might request:
```
HTML
CSS
JavaScript
Images
Fonts
AJAX/API requests
Analytics
Ads
Third-party resources
```
Therefore:
```
One URL
 ↓
Many HTTP requests
```
44. Browser Rendering

The browser combines:
```
HTML
+
CSS
+
JavaScript
+
Images
+
Fonts
```
and produces the visible page.

Conceptually:
```
HTML
 ↓
DOM

CSS
 ↓
CSSOM

DOM + CSSOM
 ↓
Rendering
 ↓
Pixels
```
This leads us toward frontend/browser technology.

45. Complete WordPress Request

Now the entire process:
```
Browser
   │
   │ https://templates.cresignsys.com/
   ▼
DNS
   │
   ▼
Server IP
   │
   ▼
TCP 443
   │
   ▼
TLS
   │
   ▼
HTTP GET /
   │
   ▼
Nginx
   │
   ▼
server_name
   │
   ▼
Document root
   │
   ▼
try_files
   │
   ▼
index.php
   │
   ▼
FastCGI
   │
   ▼
PHP-FPM
   │
   ▼
WordPress
   │
   ├──────────────┐
   ▼              ▼
Filesystem       MySQL
   │              │
   └──────┬───────┘
          ▼
      WordPress
          │
          ▼
     Theme/Plugins
          │
          ▼
      Generated HTML
          │
          ▼
       PHP-FPM
          │
          ▼
        Nginx
          │
          ▼
         TLS
          │
          ▼
         TCP
          │
          ▼
       Browser
```
46. Why This Architecture Is Powerful

Each component has a separate responsibility.
```
DNS
→ Find the server

IP
→ Address the server

TCP
→ Transport data

TLS
→ Secure communication

HTTP
→ Web protocol

Nginx
→ Web server / request routing

FastCGI
→ Web server ↔ PHP communication

PHP-FPM
→ Manage PHP execution

PHP
→ Execute application code

WordPress
→ Web application

MySQL
→ Store application data

Filesystem
→ Store application files
```
47. Why Separation Matters

Suppose MySQL is down.

Then:
```
DNS ✓
TCP ✓
TLS ✓
Nginx ✓
PHP-FPM ✓
WordPress ✗
MySQL ✗
```
The website may produce an application/database error.

But DNS and TLS are perfectly healthy.

48. Another Failure

Suppose PHP-FPM is down:
```
DNS ✓
TCP ✓
TLS ✓
Nginx ✓
PHP-FPM ✗
WordPress ✗
```
You might receive:
```
502 Bad Gateway
```
49. Another Failure

Suppose Nginx is down:
```
DNS ✓
TCP ✗
TLS ✗
HTTP ✗
```
The browser may report a connection failure.

50. Another Failure

Suppose DNS is wrong:
```
DNS ✗
```
Everything behind it may appear broken to the user even if:
```
Nginx ✓
PHP ✓
WordPress ✓
MySQL ✓
```
This is why layered troubleshooting is so important.

51. Nginx Is the Gateway to Your Applications

Your architecture can be viewed as:
```
                    INTERNET
                       │
                       ▼
                     NGINX
                       │
          ┌────────────┼────────────┐
          ▼            ▼            ▼
       Website A    Website B    Website C
          │            │            │
          ▼            ▼            ▼
       PHP-FPM       PHP-FPM       Static
          │            │
          ▼            ▼
      WordPress     WordPress
          │            │
          ▼            ▼
        MySQL        MySQL
```
This is a simplified architecture; databases and PHP-FPM pools can also be shared or separated depending on design.

52. Why Hosting Panels Exist

This explains why products such as hosting control panels automate many things.

A hosting panel may automate:
```
Domain creation
DNS integration
Website directory
Nginx configuration
PHP-FPM
Database
SSL
Backups
Users
Logs
```
Instead of manually configuring each layer.

Your own CresignSys Hosting Platform is essentially trying to automate the same classes of operations.

53. Manual Hosting Creation

Without a hosting panel, creating a WordPress site might involve:
```
1. DNS
2. Directory
3. Permissions
4. Nginx configuration
5. PHP-FPM configuration
6. Database
7. WordPress files
8. wp-config.php
9. SSL
10. Renewal
```
Your hosting automation scripts can eventually perform these tasks.

54. A Hosting Automation Pipeline

A future CresignSys hosting script could conceptually do:
```
Create Website
      ↓
Validate domain
      ↓
Create directory
      ↓
Create database
      ↓
Create database user
      ↓
Create Nginx configuration
      ↓
Enable site
      ↓
nginx -t
      ↓
Reload Nginx
      ↓
Install SSL
      ↓
Configure renewal
      ↓
Install WordPress
      ↓
Return credentials/status
```
This is the bridge from networking theory to your actual hosting platform.

55. Security Boundaries

Notice that sensitive information exists at different layers.

TLS private key
```
/etc/letsencrypt/.../privkey.pem
```
WordPress database credentials
```
wp-config.php
```
MySQL credentials

Stored/configured securely.

Linux permissions

Control filesystem access.

Cloud credentials

Control infrastructure.

Each needs separate protection.

56. One Request, Many Processes

A single browser request may involve:
```
Browser process
      ↓
Operating system networking
      ↓
Nginx process
      ↓
PHP-FPM worker
      ↓
PHP execution
      ↓
WordPress
      ↓
MySQL process
      ↓
Filesystem
```
This is why web hosting is an excellent practical example of systems engineering.

57. One Important Optimization

Not every request goes through:
```
Nginx → PHP-FPM → WordPress → MySQL
```
Static resources can stop earlier:
```
Browser
 ↓
Nginx
 ↓
Filesystem
 ↓
Response
```
This is much faster.

58. Caching Changes the Architecture

If a page is cached:
```
Browser
 ↓
Nginx/cache
 ↓
Cached HTML
```
WordPress may not need to execute for every request.

With a CDN:
```
Browser
 ↓
CDN
 ↓
Cache HIT
```
The request may never reach your VPS at all.

This becomes extremely important when we study performance.

59. The Architecture Evolves

Basic hosting:
```
Browser
 ↓
Nginx
 ↓
PHP
 ↓
MySQL
```
More advanced hosting:
```
Browser
 ↓
CDN
 ↓
Load Balancer
 ↓
Nginx
 ↓
Cache
 ↓
PHP-FPM
 ↓
Application
 ↓
Database
 ↓
Database cache
 ↓
Storage
```
Modern large-scale hosting can become much more complex.

60. Your Learning Path

You have now completed:
```
Science
 ↓
Networking
 ↓
DNS
 ↓
IP
 ↓
TCP
 ↓
TLS
 ↓
HTTP
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL
```
The next logical layer is:

Linux Server Architecture

because all of these services are actually running inside your Ubuntu server.

Lesson 030 Summary

The most important chain to remember is:
```
HTTPS Request
      ↓
Nginx
      ↓
server_name
      ↓
location
      ↓
try_files
      ↓
index.php
      ↓
FastCGI
      ↓
PHP-FPM
      ↓
WordPress
      ↓
MySQL + Filesystem
      ↓
HTML
      ↓
Nginx
      ↓
TLS
      ↓
Browser
```
And the central principle:

Nginx is the front door; PHP-FPM executes PHP; WordPress is the application; MySQL stores application data; the filesystem stores application files.

Next Lesson — 031

Linux Server Fundamentals

We will now go underneath Nginx and PHP and learn what is actually running your hosting platform:
```
Hardware
 ↓
CPU
 ↓
RAM
 ↓
Storage
 ↓
Kernel
 ↓
Processes
 ↓
Users
 ↓
Permissions
 ↓
Filesystems
 ↓
Network interfaces
 ↓
Sockets
 ↓
systemd
 ↓
Services
 ↓
Nginx
 ↓
PHP-FPM
 ↓
MySQL
```
This will explain what your Ubuntu VPS actually is, rather than treating the server as a black box.
August 13, 2026
CresignSys Learn — Lesson 029
HTTP — From the Deepest Basics

We have now reached the protocol that actually carries the web request and web response.

The complete foundation is:
```
Domain
 ↓
DNS
 ↓
IP
 ↓
Routing
 ↓
TCP
 ↓
TLS
 ↓
HTTP
```
Now we study HTTP itself.

1. What Is HTTP?

HTTP means:

Hypertext Transfer Protocol

At its most basic level:
```
HTTP
=
Rules for exchanging web messages
```
A browser sends an HTTP request.

A web server sends an HTTP response.
```
Browser
   │
   │ HTTP Request
   ▼
Web Server
   │
   │ HTTP Response
   ▼
Browser
```
2. HTTP Is an Application-Layer Protocol

Remember the networking layers:
```
Application
    ↓
HTTP

Transport
    ↓
TCP

Internet
    ↓
IP

Link
    ↓
Ethernet / Wi-Fi
```
For traditional HTTPS:
```
HTTP
 ↓
TLS
 ↓
TCP
 ↓
IP
 ↓
Ethernet/Wi-Fi
```
3. HTTP Doesn’t Know About Ethernet

HTTP doesn’t directly care whether the connection uses:
```
Ethernet
Wi-Fi
Fiber
4G
5G
Cloud networking
```
HTTP simply operates above the transport/security layers.

That separation is one of the most powerful ideas in networking.

4. A Web Request

Suppose you open:
```
https://templates.cresignsys.com/
```
Conceptually, the browser sends:
```
GET / HTTP/1.1
Host: templates.cresignsys.com
```
There are additional headers in a real browser request.

5. GET

The first word:
```
GET
```
is an HTTP method.

It tells the server:

I want to retrieve a resource.

Other important methods include:
```
GET
POST
PUT
PATCH
DELETE
HEAD
OPTIONS
```
6. URL Path

The next part:
```
/
```
is the path.

For example:
```
https://templates.cresignsys.com/about
```
has:
```
Path:
/about
```
Another example:
```
https://templates.cresignsys.com/blog/hello
```
has:
```
Path:
/blog/hello
```
7. HTTP Version

You may see:
```
HTTP/1.1
```
This identifies the HTTP protocol version used for that request.

Modern websites may also use:
```
HTTP/2
HTTP/3
```
We will study these separately.

8. Host Header

A request can contain:
```
Host: templates.cresignsys.com
```
This tells the HTTP server which hostname the request is intended for.

This is extremely important when one IP hosts multiple websites.

9. One IP, Multiple Websites

Imagine:
```
203.0.113.10
```
hosts:
```
templates.cresignsys.com
learn.cresignsys.com
shop.cresignsys.com
```
The HTTP request can identify:
```
Host: templates.cresignsys.com
```
Nginx can then choose the corresponding virtual host.

Conceptually:
```
Same IP
   │
   ▼
Nginx
   │
   ├── Host: templates → Site A
   ├── Host: learn     → Site B
   └── Host: shop      → Site C
```
10. HTTP Headers

HTTP messages contain headers.

Example:
```
GET / HTTP/1.1
Host: templates.cresignsys.com
User-Agent: ...
Accept: text/html
Accept-Language: en-US
Connection: ...
```
Headers provide metadata about the request.

11. Header = Name + Value

Conceptually:
```
Header-Name: Header-Value
```
For example:
```
Host: templates.cresignsys.com
```
means:
```
Name:
Host

Value:
templates.cresignsys.com
```
12. Why Headers Exist

HTTP needs to communicate more than:
```
"I want this page."
```
It may need to communicate:
```
Which hostname?
What content can I accept?
What language?
What cookies do I have?
What authentication information?
What browser/client am I using?
What content format?
```
Headers provide this metadata.

13. HTTP Request Structure

Conceptually:
```
Request Line
     ↓
Headers
     ↓
Blank Line
     ↓
Optional Body
```
Example:
```
GET /about HTTP/1.1
Host: templates.cresignsys.com
Accept: text/html
```
The blank line separates headers from the optional body.

14. GET Usually Has No Request Body

A basic GET request often looks like:
```
GET / HTTP/1.1
Host: templates.cresignsys.com
```
No body is required.

The server receives the request and generates a response.

15. POST

POST is commonly used when the client sends data to the server.

For example:
```
POST /login HTTP/1.1
Host: templates.cresignsys.com
Content-Type: application/x-www-form-urlencoded
Content-Length: ...

username=abey&password=...
```
The exact request would depend on the application.

Important:

Never put a real password into a tutorial command or share it in chat.

16. Request Body

A request can have a body.

Conceptually:
```
Request
 ├── Method
 ├── Path
 ├── Headers
 └── Body
```
The body may contain:
```
Form data
JSON
XML
Images
Files
Other data
```
depending on the application.

17. JSON API Example

A modern web application might send:
```
POST /api/users HTTP/1.1
Host: example.com
Content-Type: application/json

{"name":"John","age":30}
```
The body is JSON.

This is extremely common in web APIs.

18. HTTP Response

The server responds.

For example:
```
HTTP/1.1 200 OK
Content-Type: text/html

<html>
...
</html>
```
The response contains:
```
Status line
 ↓
Headers
 ↓
Blank line
 ↓
Body
```
19. Status Code

The first important part of the response is:
```
200
```
This is the status code.

It tells the client broadly what happened.

20. HTTP Status Code Groups

HTTP status codes are grouped by their first digit.
```
1xx → Informational
2xx → Success
3xx → Redirection
4xx → Client-related error
5xx → Server-related error
```
Memorize this first.

21. 2xx — Success

Common examples:
```
200 OK
201 Created
204 No Content
```
22. 200 OK

The most familiar response:
```
HTTP/1.1 200 OK
```
means the request was successfully processed.

For a webpage:
```
Browser
 ↓
GET /
 ↓
Nginx/WordPress
 ↓
200 OK
 ↓
HTML
```
23. 201 Created

Often used after successfully creating a resource.

For example:
```
POST /users
```
might produce:
```
201 Created
```
This is common in APIs.

24. 204 No Content

Means the request succeeded but there is no response body to return.

Example:
```
DELETE /resource/123
```
could return:
```
204 No Content
```
25. 3xx — Redirects

Examples:
```
301 Moved Permanently
302 Found
303 See Other
307 Temporary Redirect
308 Permanent Redirect
```
These tell the client to look elsewhere or make another request according to the redirect semantics.

26. HTTP → HTTPS Redirect

A common web hosting configuration is:
```
http://templates.cresignsys.com
```
redirecting to:
```
https://templates.cresignsys.com
```
Conceptually:
```
Browser
 ↓
HTTP :80
 ↓
Nginx
 ↓
301/308
 ↓
HTTPS :443
```
This is an HTTP redirect.

It is not DNS.

27. 4xx — Client-Side Request Problems

Common examples:
```
400 Bad Request
401 Unauthorized
403 Forbidden
404 Not Found
405 Method Not Allowed
429 Too Many Requests
```
These generally indicate that the request cannot be successfully fulfilled as made, though the exact reason varies.

28. 400 Bad Request

The server cannot properly process the request because it is malformed or invalid.

Conceptually:
```
Browser
 ↓
Invalid request
 ↓
Server
 ↓
400
```
29. 401 Unauthorized

This generally indicates that authentication is required or has failed.

For example:
```
GET /private
```
could return:
```
401 Unauthorized
```
HTTP authentication mechanisms can then be involved.

30. 403 Forbidden

The server understood the request but refuses to fulfill it.

For example:
```
Browser
 ↓
GET /private
 ↓
Server
 ↓
403 Forbidden
```
31. 404 Not Found

The requested resource could not be found.

Example:
```
GET /abc123
```
might return:
```
404 Not Found
```
In WordPress, 404 behavior can involve Nginx configuration and WordPress’s routing system.

32. 5xx — Server Errors

Common examples:
```
500 Internal Server Error
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout
```
These are particularly important for web hosting.

33. 500

The server encountered an internal error.

For WordPress this could result from:
```
PHP error
Plugin error
Theme error
Application error
Server configuration
```
34. 502

Often associated with an upstream problem.

For your architecture:
```
Browser
 ↓
Nginx
 ↓
PHP-FPM
```
If Nginx cannot communicate properly with PHP-FPM:
```
Nginx
   X
PHP-FPM
```
you may receive:
```
502 Bad Gateway
```
35. 503

Usually indicates service unavailability.

Possible causes include:
```
Service stopped
Temporary overload
Maintenance
Application unavailable
Upstream unavailable
```
The exact cause depends on the configuration.

36. 504

A gateway or proxy waited too long for an upstream response.

Conceptually:
```
Nginx
 ↓
PHP-FPM / upstream
 ↓
too slow
 ↓
timeout
 ↓
504
```
37. HTTP Request Lifecycle

Let’s follow your website.
```
Browser
   ↓
GET /
   ↓
TLS
   ↓
Nginx
   ↓
Find server block
   ↓
Find resource
   ↓
Maybe PHP-FPM
   ↓
WordPress
   ↓
MySQL
   ↓
Generate response
   ↓
Nginx
   ↓
HTTP response
   ↓
Browser
```
38. HTTP and Nginx

Nginx is an HTTP server/reverse proxy.

It understands things such as:
```
GET
POST
Host
Content-Type
Cookies
HTTP status codes
URLs
Headers
```
This is why Nginx sits directly at the HTTP layer.

39. HTTP and PHP

PHP doesn’t normally receive raw Internet traffic directly.

Your architecture is more like:
```
Internet
 ↓
TLS
 ↓
Nginx
 ↓
FastCGI
 ↓
PHP-FPM
 ↓
PHP
```
Nginx handles the HTTP-facing connection.

PHP-FPM executes PHP code.

40. HTTP and WordPress

WordPress receives application-level information derived from the HTTP request.

For:
```
GET /about
```
WordPress can determine:
```
Requested URL
Query parameters
Cookies
Headers
User state
```
and then decide what content to generate.

41. HTTP Query Parameters

Consider:
```
https://templates.cresignsys.com/search?q=keyboard
```
The path is:
```
/search
```
The query string is:
```
?q=keyboard
```
Conceptually:
```
URL
 ├── Scheme
 ├── Host
 ├── Port
 ├── Path
 └── Query
```
42. Query String

Example:
```
/search?q=keyboard&page=2
```
contains:
```
q = keyboard
page = 2
```
The server/application can use these values.

43. Fragment

Consider:
```
https://example.com/page#section2
```
The:
```
#section2
```
is a URL fragment.

An important distinction:

The fragment is normally processed by the browser and is not sent to the server as part of the HTTP request.

So the HTTP request generally contains:
```
/page
```
not:
```
/page#section2
```
44. URL Structure

Let’s break down:
```
https://templates.cresignsys.com:443/about?x=10#top
```
into:
```
Scheme:
https

Host:
templates.cresignsys.com

Port:
443

Path:
/about

Query:
x=10

Fragment:
top
```
This is important web infrastructure knowledge.

45. HTTP Headers — Important Ones

Learn these:
```
Host
User-Agent
Accept
Content-Type
Content-Length
Authorization
Cookie
Set-Cookie
Cache-Control
Location
Referer
Origin
```
There are many more.

46. Content-Type

This tells the receiver what kind of content is being transmitted.

Examples:
```
text/html
text/css
application/javascript
application/json
image/png
image/jpeg
application/pdf
```
For example:
```
Content-Type: text/html
```
means the response contains HTML content.

47. HTML

A basic response might be:
```
HTTP/1.1 200 OK
Content-Type: text/html

<!doctype html>
<html>
<head>
<title>Hello</title>
</head>
<body>
<h1>Hello</h1>
</body>
</html>
```
The browser interprets the HTML.

48. CSS

The HTML can reference:
```
style.css
```
The browser then makes another HTTP request:
```
GET /style.css
```
The server responds:
```
Content-Type: text/css
```
This is an important realization:

Opening one webpage can generate many HTTP requests.

49. JavaScript

Similarly:
```
GET /app.js
```
might return:
```
Content-Type: application/javascript
```
The browser executes the JavaScript.

50. Images

The page may request:
```
GET /images/logo.png
```
The response may contain:
```
Content-Type: image/png
```
So one page can cause:
```
HTML request
 ↓
CSS requests
 ↓
JavaScript requests
 ↓
Image requests
 ↓
Font requests
 ↓
API requests
```
51. One Page = Many HTTP Requests

Conceptually:
```
Browser
 │
 ├── GET /
 ├── GET /style.css
 ├── GET /app.js
 ├── GET /logo.png
 ├── GET /font.woff2
 └── GET /api/data
```
This is why a webpage is not normally just “one request.”

52. Cookies

HTTP is fundamentally request/response based, while web applications often need to remember users between requests.

Cookies help.

Server response:
```
Set-Cookie: session=...
```
Browser stores the cookie.

Later:
```
Cookie: session=...
```
The browser sends it back to the server.

53. Cookie Flow
```
Server
 ↓
Set-Cookie
 ↓
Browser
 ↓
stores cookie
 ↓
Next request
 ↓
Cookie
 ↓
Server
```
This allows applications to maintain state across multiple requests.

54. WordPress and Cookies

WordPress can use cookies for things such as:
```
Login state
Sessions/authentication-related state
Preferences
Other application behavior
```
Plugins may also set cookies.

55. HTTP Is Stateless

A basic HTTP request doesn’t inherently contain memory of previous requests.

For example:
```
Request 1
Request 2
Request 3
```
are separate HTTP messages.

Applications add state using mechanisms such as:
```
Cookies
Sessions
Tokens
Databases
```
56. Authentication

HTTP applications can authenticate users through mechanisms including:
```
Cookies
Sessions
Authorization headers
Bearer tokens
Basic authentication
OAuth-related flows
```
Modern web applications often combine several technologies.

57. HTTPS Protects HTTP

Without TLS:
```
HTTP
 ↓
TCP
 ↓
IP
```
With HTTPS:
```
HTTP
 ↓
TLS
 ↓
TCP
 ↓
IP
```
TLS protects the HTTP traffic in transit.

So someone monitoring the network should not simply be able to read:
```
GET /private
Cookie: ...
```
from the encrypted connection.

58. HTTP vs HTTPS

HTTP:
```
Application data
 ↓
TCP
```
HTTPS:
```
Application data
 ↓
TLS encryption/authentication
 ↓
TCP
```
The application protocol remains HTTP.

TLS provides the security layer.

59. HTTP/1.0

Historically, HTTP/1.0 used a relatively simple request/response model.

Connections were often closed after a response unless connection reuse mechanisms were used.

HTTP evolved because modern websites became much more complex.

60. HTTP/1.1

HTTP/1.1 introduced important improvements including persistent connections and the standardized Host header behavior that enabled practical name-based virtual hosting.

A connection can carry multiple requests/responses sequentially.

Conceptually:
```
TCP connection
 ├── Request 1
 ├── Response 1
 ├── Request 2
 ├── Response 2
 └── ...
```
61. HTTP/1.1 Limitation

HTTP/1.1 messages on a single connection are fundamentally ordered.

This can contribute to:
```
Head-of-line blocking
```
at the HTTP message level.

Modern protocols address this differently.

62. HTTP/2

HTTP/2 changed the way HTTP messages are transported.

It supports:
```
Binary framing
Multiplexing
Header compression
Stream prioritization mechanisms
```
Conceptually:
```
One connection
      │
 ┌────┼────┬────┬────┐
 ▼    ▼    ▼    ▼    ▼
Req1 Req2 Req3 Req4 ...
```
Multiple streams can share one connection.

63. HTTP/3

HTTP/3 uses:
```
HTTP/3
 ↓
QUIC
 ↓
UDP
 ↓
IP
```
instead of the traditional:
```
HTTP/2
 ↓
TLS
 ↓
TCP
 ↓
IP
```
QUIC integrates TLS 1.3 into its transport design.

64. Important Evolution

Remember:
```
HTTP/1.1
   ↓
TCP

HTTP/2
   ↓
TCP + TLS

HTTP/3
   ↓
QUIC
   ↓
UDP
```
This is a simplified conceptual map; protocol negotiation and deployment details can vary.

65. How to Check HTTP

Run:
```
curl -I https://templates.cresignsys.com
```
This asks for response headers.

You may see something like:
```
HTTP/2 200
content-type: text/html
...
```
If HTTP/2 is negotiated.

66. Force HTTP/1.1

You can test:
```
curl --http1.1 -I https://templates.cresignsys.com
```
This helps you understand protocol negotiation.

67. Test HTTP/2

Try:
```
curl --http2 -I https://templates.cresignsys.com
```
Support depends on how your curl build and server are configured.

68. Test HTTP/3

Support depends on your curl build and server.

A modern curl build may support:
```
curl --http3 -I https://templates.cresignsys.com
```
If unsupported, curl will report that HTTP/3 isn’t available in that build/environment.

Don’t install anything yet just for this lesson.

69. Inspect the Response

Use:
```
curl -v https://templates.cresignsys.com
```
You may observe:
```
* Connected
* TLS handshake
* SSL certificate
> GET /
> Host: templates.cresignsys.com
< HTTP/...
< content-type: ...
```
This is where your previous lessons become visible in one command.

70. The Complete Request

Conceptually:
```
Browser
   │
   │ DNS
   ▼
IP address
   │
   │ TCP
   ▼
Connection
   │
   │ TLS
   ▼
Secure channel
   │
   │ HTTP
   ▼
GET /
Host: templates.cresignsys.com
   │
   ▼
Nginx
```
71. Nginx Receives the Request

Nginx can inspect:
```
Method
Path
Host
Headers
Body
```
Then it decides:
```
Static file?
Proxy?
PHP?
Redirect?
Error?
```
72. Example: Static Request
```
GET /logo.png
```
Nginx:
```
Request
 ↓
Document root
 ↓
logo.png
 ↓
Read file
 ↓
HTTP response
```
PHP is unnecessary.

73. Example: WordPress Request
```
GET /about/
```
Nginx may determine that the request should ultimately be handled by WordPress.

Conceptually:
```
GET /about/
 ↓
Nginx
 ↓
index.php
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL
 ↓
HTML
 ↓
Nginx
 ↓
Browser
```
74. HTTP Rewrite

WordPress commonly uses URL rewriting so URLs such as:
```
/about/
```
can be handled by:
```
index.php
```
rather than requiring a physical file:
```
/about/index.html
```
The exact behavior depends on your Nginx configuration.

75. HTTP Redirect in WordPress

WordPress or Nginx may redirect:
```
http://...
```
to:
```
https://...
```
or:
```
www.example.com
```
to:
```
example.com
```
These are HTTP-level behaviors.

DNS itself isn’t performing the redirect.

76. HTTP Caching

HTTP also contains caching mechanisms.

Important headers include:
```
Cache-Control
Expires
ETag
Last-Modified
```
Caching can occur at:
```
Browser
CDN
Reverse proxy
Web server
```
This is another major web-hosting topic.

77. ETag

An ETag is a representation identifier used for cache validation.

Conceptually:
```
First response:
ETag: "abc123"
```
Later the browser may ask:
```
If-None-Match: "abc123"
```
If the resource hasn’t changed, the server can respond:
```
304 Not Modified
```
This can avoid retransmitting the full resource.

78. 304 Not Modified

A 304 response means the cached representation can be reused under the request’s conditional caching rules.

Conceptually:
```
Browser cache
      │
      │ Is my copy still valid?
      ▼
Server
      │
      │ 304
      ▼
Browser
      │
      ▼
Use cached copy
```
79. HTTP Compression

Servers can compress content.

Common mechanisms include:
```
gzip
Brotli
```
The browser advertises what it supports.

For example:
```
Accept-Encoding: gzip, br
```
The server may respond with:
```
Content-Encoding: br
```
depending on configuration.

80. Why Compression Matters

Suppose HTML is:
```
500 KB
```
Compression may significantly reduce the amount transmitted.

This improves:
```
Bandwidth usage
Page transfer time
Server efficiency
```
Actual gains depend on the content.

81. HTTP Content Negotiation

The browser can tell the server what it can accept.

Examples:
```
Accept:
Accept-Encoding:
Accept-Language:
```
The server can select an appropriate representation.

Conceptually:
```
Browser
 ↓
I support:
HTML
Brotli
English
 ↓
Server
 ↓
Best representation
```
82. The Web Is a Chain of Protocols

We can now see:
```
DNS
 ↓
IP
 ↓
TCP
 ↓
TLS
 ↓
HTTP
 ↓
HTML
 ↓
CSS
 ↓
JavaScript
 ↓
Application
```
Each technology solves a different problem.

83. The Most Important Distinction

Memorize this:
```
DNS
"What IP?"

IP
"Where?"

TCP
"Reliable connection."

TLS
"Secure/authenticated channel."

HTTP
"Web request/response."

HTML
"Page structure."

CSS
"Page presentation."

JavaScript
"Page behavior."

PHP
"Server-side application execution."

MySQL
"Data storage."
```
This is the conceptual backbone of web hosting.

84. Your Actual Hosting Stack

For your Ubuntu VPS:
```
Internet
   ↓
DNS
   ↓
Public IP
   ↓
Cloud networking
   ↓
TCP 443
   ↓
TLS
   ↓
Nginx
   ↓
FastCGI
   ↓
PHP-FPM
   ↓
WordPress
   ↓
MySQL
   ↓
Filesystem
```
Now we can start studying each connection between these components.

85. Practical Exercise

Run:
```
curl -I https://templates.cresignsys.com
```
Then:
```
curl -v https://templates.cresignsys.com
```
Then:
```
curl --http1.1 -I https://templates.cresignsys.com
```
Then, if supported:
```
curl --http2 -I https://templates.cresignsys.com
```
Look for:
```
HTTP version
Status code
Content-Type
Server
Location
Cache-Control
Set-Cookie
```
Do not worry if some headers differ from examples.

86. One Complete Request

Your entire journey now looks like:
```
USER
 │
 ▼
BROWSER
 │
 │ templates.cresignsys.com
 ▼
DNS
 │
 ▼
IP ADDRESS
 │
 ▼
ROUTING
 │
 ▼
TCP 443
 │
 ▼
TLS
 │
 ├── Certificate
 ├── SNI
 └── Session keys
 │
 ▼
HTTP
 │
 ├── GET
 ├── Host
 ├── Headers
 └── Body
 │
 ▼
NGINX
 │
 ├── Static file
 │
 └── PHP-FPM
       │
       ▼
    WORDPRESS
       │
       ▼
     MYSQL
       │
       ▼
    RESPONSE
       │
       ▼
     NGINX
       │
       ▼
      TLS
       │
       ▼
      TCP
       │
       ▼
    INTERNET
       │
       ▼
    BROWSER
```
Lesson 029 Summary

You should now understand:
```
HTTP
Request
Response
Methods
Headers
Body
Status codes
Cookies
Query strings
Redirects
Caching
Content-Type
HTTP/1.1
HTTP/2
HTTP/3
```
And most importantly:
```
DNS
 ↓
IP
 ↓
TCP
 ↓
TLS
 ↓
HTTP
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL
```
Next Lesson — 030

HTTP Request → Nginx → PHP-FPM → WordPress

We will trace one actual WordPress page request byte-by-byte conceptually:
```
GET /
 ↓
TLS decryption
 ↓
Nginx parses request
 ↓
server_name matching
 ↓
location matching
 ↓
try_files
 ↓
index.php
 ↓
FastCGI
 ↓
PHP-FPM
 ↓
WordPress bootstrap
 ↓
wp-config.php
 ↓
MySQL
 ↓
Theme
 ↓
HTML
 ↓
Nginx
 ↓
TLS
 ↓
Browser
```
This is where your understanding changes from “I know web hosting terms” to “I understand how a WordPress hosting server actually processes a request.”
August 13, 2026
CresignSys Learn — Lesson 028
DNS + Network Troubleshooting

We now move from learning how the Internet works to diagnosing why a real website does not work.

The key principle for this entire lesson is:

Troubleshoot from the outside toward the application, one layer at a time.

For your server, the target is:
```
templates.cresignsys.com
```
1. The Troubleshooting Ladder

When a website doesn’t open, don’t immediately restart Nginx or reinstall WordPress.

Follow:
```
1. Domain
   ↓
2. DNS
   ↓
3. IP
   ↓
4. Routing
   ↓
5. Firewall
   ↓
6. TCP port
   ↓
7. Nginx
   ↓
8. TLS
   ↓
9. HTTP
   ↓
10. PHP-FPM
   ↓
11. WordPress
   ↓
12. MySQL
   ↓
13. Filesystem
   ↓
14. Storage
```
Each layer depends on the previous one.

2. First Question

Start with:
```
Does the domain resolve?
```
Run:
```
dig templates.cresignsys.com
```
3. A Record

For IPv4 specifically:
```
dig templates.cresignsys.com A
```
You want to see an answer similar to:
```
templates.cresignsys.com.   300   IN   A   <SERVER-IP>
```
The actual IP should be the public IP that should receive traffic for this website.

4. Simplified Interpretation

If you see:
```
A → correct server IP
```
then:
```
DNS
✓
```
If you see:
```
A → wrong IP
```
then:
```
DNS
✗
```
Do not troubleshoot Nginx yet.

5. +short

For a cleaner result:
```
dig +short templates.cresignsys.com A
```
You may get:
```
203.0.113.10
```
Again, this address is illustrative.

6. Check IPv6

Run:
```
dig +short templates.cresignsys.com AAAA
```
If there is an IPv6 address, the client may potentially use IPv6.

This introduces an important troubleshooting situation.

7. IPv6 Can Cause Confusing Problems

Suppose DNS contains:
```
A
 ↓
Correct IPv4

AAAA
 ↓
Incorrect IPv6
```
Some clients may prefer IPv6.

Then:
```
Client
 ↓
AAAA
 ↓
Wrong/unreachable IPv6
```
while IPv4 works perfectly.

Therefore, always inspect both:
```
A
AAAA
```
when diagnosing a modern website.

8. Check Nameservers

Run:
```
dig +short cresignsys.com NS
```
This tells you the authoritative nameservers.

If you don’t know which DNS provider is controlling your domain, this is one of the first things to inspect.

9. Follow the DNS Hierarchy

Run:
```
dig +trace templates.cresignsys.com
```
Conceptually, you should see the chain:
```
Root
 ↓
.com
 ↓
cresignsys.com
 ↓
Authoritative DNS
 ↓
templates.cresignsys.com
```
This helps distinguish a DNS delegation problem from a simple record problem.

10. Authoritative vs Resolver

Suppose:
```
dig templates.cresignsys.com
```
gives:
```
OLD-IP
```
But your DNS control panel shows:
```
NEW-IP
```
Don’t immediately assume the DNS provider is broken.

There may be:
```
Caching
```
between your machine and the authoritative server.

11. Find the Authoritative Server

Run:
```
dig +short cresignsys.com NS
```
Suppose you get:
```
ns1.example-dns.com
ns2.example-dns.com
```
Now query one directly:
```
dig @ns1.example-dns.com templates.cresignsys.com A
```
This asks:

What does the authoritative DNS server itself say?

12. Compare Results

You can compare:
```
Recursive resolver
       ↓
templates.cresignsys.com
       ↓
IP-A
```
with:
```
Authoritative server
       ↓
templates.cresignsys.com
       ↓
IP-B
```
If:
```
IP-A ≠ IP-B
```
you may be seeing cached old data.

13. DNS Is Working

Suppose:
```
dig +short templates.cresignsys.com A
```
returns the correct server IP.

Now move to the next layer.

IP Connectivity

14. ping

Try:
```
ping templates.cresignsys.com
```
But don’t make this your primary website test.

Why?

Because:
```
ICMP
```
can be blocked while:
```
TCP 443
```
still works perfectly.

Therefore:
```
ping fails
```
does not automatically mean:
```
website is down
```
15. What Does Ping Test?

ping generally uses:
```
ICMP Echo Request
```
and:
```
ICMP Echo Reply
```
Conceptually:
```
Client
 ↓
ICMP
 ↓
Server
 ↓
ICMP response
```
It tests a particular form of network reachability.

16. Website Connectivity Needs TCP

HTTPS normally requires:
```
TCP
 ↓
443
```
So a better question is:

Can I establish TCP connectivity to port 443?

17. Test TCP 443

From a machine with network access to the server:
```
nc -vz templates.cresignsys.com 443
```
Possible successful output might indicate:
```
succeeded
```
If it fails:
```
Connection refused
```
or:
```
timed out
```
those indicate different problems.

18. Connection Refused vs Timeout

This distinction is extremely useful.

Connection refused

Often means:
```
Host reachable
 ↓
TCP connection arrived
 ↓
No service accepting that port
```
For example:
```
Nginx stopped
Port not listening
```
But firewalls and other network devices can alter exactly what you observe.

19. Connection Timeout

A timeout can indicate:
```
Packet filtering
Firewall
Cloud security rule
Routing problem
Network failure
```
The exact cause must be investigated.

20. Cloud Firewall

Your VPS may have multiple security layers.

For example:
```
Internet
 ↓
Cloud security rules
 ↓
Virtual network
 ↓
VM
 ↓
Ubuntu firewall
 ↓
Nginx
```
So even if Nginx is listening:
```
443 LISTEN
```
the Internet may still be unable to reach it if a cloud firewall blocks TCP 443.

21. Server-Side Firewall

Ubuntu may also use firewall tools such as:
```
ufw
nftables
iptables
```
depending on configuration.

For UFW:
```
sudo ufw status
```
This is a read-oriented inspection command.

22. Don’t Confuse Firewalls

You may have:
```
Cloud firewall
```
and:
```
Ubuntu firewall
```
and:
```
Nginx
```
all controlling different layers.

Conceptually:
```
Internet
 ↓
Cloud security
 ↓
Ubuntu networking
 ↓
Local firewall
 ↓
Nginx
```
23. Check Nginx

Once TCP reachability is established, inspect Nginx.
```
sudo systemctl status nginx
```
You want something similar to:
```
Active: active (running)
```
24. Test Nginx Configuration

Always know this command:
```
sudo nginx -t
```
It checks the Nginx configuration syntax and basic configuration validity.

A successful result typically includes:
```
syntax is ok
test is successful
```
25. Why nginx -t Is Important

Suppose you edited:
```
/etc/nginx/sites-enabled/templates.cresignsys.com
```
and introduced a syntax error.

Nginx may fail to reload.

Then:
```
DNS ✓
TCP ✓
Nginx ✗
```
nginx -t helps identify this before attempting a reload.

26. Check Listening Ports

Run:
```
sudo ss -lntp
```
Look for:
```
:80
:443
```
You may see:
```
LISTEN ... 0.0.0.0:443
```
and perhaps:
```
LISTEN ... 0.0.0.0:80
```
27. What Does :443 Tell You?

If you see:
```
0.0.0.0:443
```
a process is listening on TCP port 443 on IPv4 interfaces.

You might also see an IPv6 listener such as:
```
[::]:443
```
depending on configuration.

28. Find the Process

The -p option can show the process associated with the listening socket, subject to permissions.

For example:
```
users:(("nginx",pid=...,fd=...))
```
This connects:
```
TCP port
 ↓
Socket
 ↓
Nginx process
```
29. Now Test HTTPS Locally

On the server:
```
curl -I https://templates.cresignsys.com
```
This is a very useful test.

It asks for HTTP headers.

A successful response might be:
```
HTTP/1.1 200 OK
```
or:
```
HTTP/2 200
```
depending on the configuration/protocol.

30. What If Local Curl Works?

Suppose:
```
curl -I https://templates.cresignsys.com
```
works on the server.

But your home computer cannot open it.

That suggests the application stack itself may be working locally.

Investigate:
```
Cloud firewall
Network security
Public routing
DNS
Client network
```
rather than immediately changing WordPress.

31. What If Local Curl Fails?

Then investigate the server stack.

Possible layers:
```
TLS
Nginx
PHP
WordPress
Database
```
depending on the exact error.

32. curl -v

For deeper inspection:
```
curl -v https://templates.cresignsys.com
```
This can show a useful sequence:
```
DNS resolution
 ↓
TCP connection
 ↓
TLS handshake
 ↓
Certificate
 ↓
HTTP request
 ↓
HTTP response
```
This makes it an excellent learning tool.

33. TLS Inspection

Another powerful command is:
```
openssl s_client -connect templates.cresignsys.com:443 -servername templates.cresignsys.com
```
This is particularly useful for understanding TLS.

34. Why -servername?

The:
```
-servername
```
option sends the hostname using SNI.

This matters when one server hosts multiple HTTPS websites.

Conceptually:
```
Client
 ↓
TLS ClientHello
 ↓
SNI = templates.cresignsys.com
 ↓
Nginx
 ↓
Correct certificate/configuration
```
35. What openssl s_client Can Reveal

It can help inspect:
```
Certificate
Certificate chain
TLS version
Cipher
SNI behavior
Handshake
```
This is one of the best tools for learning what your Let’s Encrypt certificate is actually doing.

36. Check Your Certificate Files

You already have:
```
/etc/letsencrypt/live/templates.cresignsys.com/fullchain.pem
```
and:
```
/etc/letsencrypt/live/templates.cresignsys.com/privkey.pem
```
Never display the private key contents.

You can inspect certificate information safely with:
```
sudo openssl x509 -in /etc/letsencrypt/live/templates.cresignsys.com/fullchain.pem -noout -subject -issuer -dates
```
This can show:
```
Subject
Issuer
Not Before
Not After
```
37. Certificate Expiry

Your previous Certbot output showed:
```
Expires:
2026-11-11
```
You can independently inspect the certificate dates.

Conceptually:
```
Certificate
 ↓
Not Before
 ↓
Not After
```
This is useful for monitoring.

38. Check the Certificate Name

You can inspect SAN information with:
```
sudo openssl x509 -in /etc/letsencrypt/live/templates.cresignsys.com/fullchain.pem -noout -text
```
Look for:
```
Subject Alternative Name
```
You want the requested hostname to be covered.

39. Certificate Chain

Your fullchain.pem contains the server certificate plus intermediate certificates needed for chain presentation.

Conceptually:
```
Server certificate
       ↓
Intermediate CA
       ↓
Trusted root
```
The exact chain depends on the certificate authority and current issuance configuration.

40. Important: privkey.pem

Do not run commands that print:
```
privkey.pem
```
to the terminal for learning purposes.

Never do:
```
cat /etc/letsencrypt/live/templates.cresignsys.com/privkey.pem
```
and then copy it somewhere.

The private key is secret.

41. Check Nginx’s Certificate Configuration

You can inspect your site configuration:
```
sudo sed -n '1,240p' /etc/nginx/sites-enabled/templates.cresignsys.com
```
Look for directives conceptually similar to:
```
server_name templates.cresignsys.com;

ssl_certificate /etc/letsencrypt/live/templates.cresignsys.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/templates.cresignsys.com/privkey.pem;
```
The exact configuration may differ.

42. DNS and Nginx Must Agree

This is a critical rule.

DNS:
```
templates.cresignsys.com
        ↓
      Server IP
```
Nginx:
```
server_name templates.cresignsys.com;
```
They must refer to the same service.

If DNS points to Server A but the Nginx site exists only on Server B:
```
Browser
 ↓
Server A
 ↓
Wrong website / error
```
43. Nginx Root

Your Nginx configuration may contain something like:
```
root /storage/websites/templates.cresignsys.com/public;
```
Conceptually:
```
Hostname
 ↓
Nginx server block
 ↓
Document root
 ↓
Website files
```
44. Test the Filesystem

Check:
```
ls -la /storage/websites/templates.cresignsys.com/public
```
You should see the website files.

For WordPress, you might see:
```
index.php
wp-admin/
wp-content/
wp-includes/
```
45. Check Permissions

If Nginx/PHP cannot access the files:
```
Browser
 ↓
Nginx
 ↓
PHP-FPM
 ↓
Filesystem
 ↓
Permission denied
```
Then you may see:
```
403
500
502
```
depending on where the failure occurs.

46. PHP-FPM

For WordPress, check PHP-FPM.

First determine your installed PHP version:
```
php -v
```
Then list PHP-FPM services:
```
systemctl list-units --type=service | grep php
```
You might see something like:
```
php8.3-fpm.service
```
The actual version depends on your server.

47. Check PHP-FPM

For example:
```
sudo systemctl status php8.3-fpm
```
Use the version actually installed on your server.

The relationship is:
```
Nginx
 ↓
FastCGI
 ↓
PHP-FPM
 ↓
PHP
 ↓
WordPress
```
48. 502 Bad Gateway

One common WordPress/Nginx error is:
```
502 Bad Gateway
```
It can occur when Nginx cannot successfully communicate with the upstream service, such as PHP-FPM.

Conceptually:
```
Browser
 ↓
Nginx
 ↓
PHP-FPM
 X
```
Then:
```
502
```
49. 404 Not Found

A:
```
404
```
means the requested resource wasn’t found according to the application/server handling the request.

Possible causes include:
```
Wrong URL
Wrong root
Wrong rewrite configuration
Missing file
Application routing
```
50. 403 Forbidden

A:
```
403
```
often indicates access is forbidden.

Possible causes include:
```
Filesystem permissions
Directory restrictions
Nginx configuration
Application access rules
```
Don’t assume every 403 is a Linux permission problem.

51. 500 Internal Server Error

A:
```
500
```
generally means the server encountered an internal application/server-side error.

For WordPress, possibilities include:
```
PHP error
Plugin error
Theme error
Application configuration
Server configuration
```
52. 502 vs 503

A:
```
502 Bad Gateway
```
often points toward an upstream communication problem.

A:
```
503 Service Unavailable
```
often indicates that a service is temporarily unavailable or unable to handle the request.

The exact meaning depends on the architecture and configuration.

53. Nginx Logs

One of the most important troubleshooting tools:
```
/var/log/nginx/
```
You may have:
```
access.log
error.log
```
or site-specific logs depending on your configuration.

54. Access Log

An access log records requests.

Conceptually:
```
Client
 ↓
GET /
 ↓
Nginx
 ↓
access.log
```
It can show things such as:
```
IP
Request
Status code
User agent
Timing information
```
depending on the log format.

55. Error Log

The error log is especially useful when something goes wrong.

For example:
```
sudo tail -f /var/log/nginx/error.log
```
Then make a request from your browser.

You can watch errors appear in real time.

56. journalctl

For system services:
```
sudo journalctl -u nginx
```
For recent entries:
```
sudo journalctl -u nginx -n 100
```
For live logs:
```
sudo journalctl -u nginx -f
```
This connects systemd service management with troubleshooting.

57. The Layered Troubleshooting Workflow

Use this sequence:
```
1. dig
   ↓
2. Check IP
   ↓
3. Test TCP 443
   ↓
4. Check cloud firewall
   ↓
5. Check UFW/firewall
   ↓
6. ss
   ↓
7. nginx -t
   ↓
8. systemctl status nginx
   ↓
9. curl
   ↓
10. openssl s_client
   ↓
11. Nginx logs
   ↓
12. PHP-FPM
   ↓
13. WordPress
   ↓
14. MySQL
```
58. Don’t Skip Layers

Suppose:
```
dig
```
already proves:
```
DNS ✓
```
There is no reason to spend an hour investigating DNS.

Move down:
```
TCP
```
If TCP works:
```
TCP ✓
```
move to:
```
TLS
```
This dramatically reduces troubleshooting time.

59. A Real Example

Imagine the browser shows:
```
ERR_CONNECTION_REFUSED
```
Investigate:
```
DNS
 ↓
correct
```
Then:
```
TCP 443
 ↓
connection refused
```
Now inspect:
```
sudo ss -lntp | grep ':443'
```
If nothing is listening:
```
Nginx/TLS listener problem
```
You don’t need to investigate WordPress yet.

60. Another Example

Suppose:
```
TCP 443
✓
```
but browser says:
```
NET::ERR_CERT_COMMON_NAME_INVALID
```
Now:
```
DNS ✓
TCP ✓
TLS certificate identity ✗
```
Inspect:
```
openssl s_client -connect templates.cresignsys.com:443 -servername templates.cresignsys.com
```
and the certificate configuration.

61. Another Example

Suppose:
```
DNS ✓
TCP ✓
TLS ✓
HTTP = 502
```
Now:
```
Nginx ✓
PHP-FPM/upstream ?
```
Investigate PHP-FPM and Nginx error logs.

62. Another Example

Suppose:
```
DNS ✓
TCP ✓
TLS ✓
HTTP = 200
```
but WordPress displays an error.

Now the network stack is largely working.

Move upward into:
```
PHP
 ↓
WordPress
 ↓
Plugins/themes
 ↓
MySQL
```
63. The Most Important Skill

Don’t ask:

“What command fixes my website?”

Ask:

“At which layer does the failure occur?”

That question changes server administration from trial-and-error into engineering.

64. Your Complete Troubleshooting Map
```
                   WEBSITE
                      │
                      ▼
                   DOMAIN
                      │
                      ▼
                     DNS
                      │
                 ┌────┴────┐
                 ▼         ▼
                A         AAAA
                 │         │
                 └────┬────┘
                      ▼
                     IP
                      │
                      ▼
                   ROUTING
                      │
                      ▼
                CLOUD FIREWALL
                      │
                      ▼
                 UBUNTU FIREWALL
                      │
                      ▼
                    TCP
                      │
                    :443
                      │
                      ▼
                    TLS
                      │
                    SNI
                      │
                      ▼
                   NGINX
                      │
                 ┌────┴────┐
                 ▼         ▼
              STATIC     PHP-FPM
                           │
                           ▼
                       WORDPRESS
                           │
                           ▼
                         MYSQL
                           │
                           ▼
                       FILESYSTEM
                           │
                           ▼
                        STORAGE
```
65. Practical Exercise

For templates.cresignsys.com, perform these read-only checks in order:

1. DNS
```
dig +short templates.cresignsys.com A
```
2. IPv6
```
dig +short templates.cresignsys.com AAAA
```
3. Listening port
```
sudo ss -lntp | grep ':443'
```
4. Nginx configuration
```
sudo nginx -t
```
5. Nginx status
```
sudo systemctl status nginx --no-pager
```
6. HTTPS
```
curl -I https://templates.cresignsys.com
```
7. TLS
```
openssl s_client -connect templates.cresignsys.com:443 -servername templates.cresignsys.com
```
8. Certificate dates
```
sudo openssl x509 -in /etc/letsencrypt/live/templates.cresignsys.com/fullchain.pem -noout -subject -issuer -dates
```
9. Nginx errors
```
sudo tail -n 50 /var/log/nginx/error.log
```
Don’t paste the private key anywhere.

66. What We Have Learned

You can now distinguish:
```
DNS problem
≠
Firewall problem
≠
TCP problem
≠
TLS problem
≠
Nginx problem
≠
PHP problem
≠
WordPress problem
≠
MySQL problem
```
This is one of the most important foundations for becoming capable of managing a real hosting server.

Next Lesson — 029

HTTP From the Deepest Basics

Now that we understand:
```
DNS
 ↓
IP
 ↓
TCP
 ↓
TLS
```
we can finally study the protocol that actually carries the web request:

HTTP

We will build it from:
```
Byte
 ↓
Text
 ↓
Request
 ↓
Response
 ↓
Methods
 ↓
Headers
 ↓
Status codes
 ↓
Cookies
 ↓
Sessions
 ↓
HTTP/1.1
 ↓
HTTP/2
 ↓
HTTP/3
 ↓
Browser ↔ Nginx
```
Then we will inspect a real request to templates.cresignsys.com and see exactly what Nginx receives.
August 13, 2026
CresignSys Learn — Lesson 027
DNS Resolution — What Actually Happens Inside DNS?

We now know DNS records.

The next deeper question is:

When you type templates.cresignsys.com, what exactly happens between your computer and the DNS system?

1. The Complete DNS Journey

A simplified journey is:
```
Browser
   ↓
Operating System
   ↓
Stub Resolver
   ↓
Recursive DNS Resolver
   ↓
Root DNS
   ↓
.com TLD DNS
   ↓
cresignsys.com Authoritative DNS
   ↓
A / AAAA Record
   ↓
IP Address
   ↓
Back to Browser
```
But there is an important optimization:
```
CACHE
```
At almost every practical stage, cached information can prevent the entire journey.

2. Start With the Browser

You enter:
```
https://templates.cresignsys.com
```
The browser needs to know:
```
Where is templates.cresignsys.com?
```
It needs an IP address before it can normally establish the connection.

So it initiates hostname resolution.

3. Browser DNS Cache

The browser may have previously resolved the hostname.

Conceptually:
```
Browser
   ↓
DNS cache
   ↓
Found?
```
If yes:
```
Browser
   ↓
Cached IP
```
No external DNS query may be necessary at this point.

4. If Browser Cache Misses

The request proceeds to the operating system’s name-resolution mechanism.

Conceptually:
```
Browser
 ↓
OS resolver
```
The exact implementation varies by operating system.

5. Stub Resolver

A client machine commonly has a:

Stub Resolver

The stub resolver is the client-side component that sends DNS queries to a configured recursive resolver.

Conceptually:
```
Browser
   ↓
Stub resolver
   ↓
Recursive resolver
```
The stub usually does not perform the complete root → TLD → authoritative lookup itself.

6. Recursive Resolver

The recursive resolver performs the larger DNS lookup when necessary.

Examples of resolver services include:
```
ISP DNS
Enterprise DNS
Cloud DNS resolver
Public DNS resolver
```
The client simply asks:
```
What is the address of:
templates.cresignsys.com?
```
The recursive resolver does the difficult work.

7. Resolver Cache

The first thing a recursive resolver may check is its cache.
```
Query
 ↓
Resolver
 ↓
Cache
```
If the resolver already has:
```
templates.cresignsys.com
        ↓
203.0.113.10
```
and the cached information is still valid:
```
Cache HIT
```
The resolver returns the answer immediately.

8. Cache Miss

If it doesn’t have a usable cached answer:
```
Cache MISS
```
the resolver must find the authoritative answer.

Conceptually:
```
Recursive Resolver
       ↓
Root
       ↓
TLD
       ↓
Authoritative DNS
```
9. Root DNS

The DNS hierarchy begins at:
```
.
```
The root.

The recursive resolver knows how to reach the root DNS infrastructure through root-server information/root hints.

It asks essentially:

Where should I look for .com?

10. Root Does Not Usually Give the Website IP

This is extremely important.

The root does not normally answer:
```
templates.cresignsys.com
        ↓
203.0.113.10
```
Instead it provides information about:
```
.com
```
Conceptually:
```
Resolver
   ↓
Root
   ↓
".com is handled by these TLD nameservers."
```
11. Root Delegation

The response directs the resolver toward the .com TLD nameservers.

So:
```
Root
 ↓
.com nameservers
```
The resolver now knows where to ask next.

12. .com TLD

The resolver asks the .com TLD infrastructure:

Where are the authoritative nameservers for cresignsys.com?

Conceptually:
```
Recursive Resolver
       ↓
     .com
       ↓
cresignsys.com nameserver information
```
13. TLD Doesn’t Usually Give the Final IP

Again:
```
Root
 ↓
find .com

.com
 ↓
find cresignsys.com authoritative DNS
```
The TLD’s main role here is delegation.

The authoritative server contains the actual zone data.

14. Authoritative DNS

Now the resolver has discovered the authoritative nameserver for:
```
cresignsys.com
```
It asks:
```
A templates.cresignsys.com?
```
The authoritative DNS server responds with the authoritative record if one exists.

Conceptually:
```
templates.cresignsys.com
        ↓
A
        ↓
SERVER IP
```
15. The Answer Returns

Now the journey reverses:
```
Authoritative DNS
       ↓
Recursive Resolver
       ↓
Stub Resolver
       ↓
Operating System
       ↓
Browser
```
The browser now has the IP address.

16. The Whole Process

Put everything together:
```
                    DNS RESOLUTION

Browser
   │
   ▼
Browser Cache
   │
   │ miss
   ▼
OS Resolver
   │
   ▼
Stub Resolver
   │
   ▼
Recursive Resolver
   │
   │ cache miss
   ▼
Root
   │
   ▼
.com TLD
   │
   ▼
cresignsys.com Authoritative DNS
   │
   ▼
A / AAAA record
   │
   ▼
Recursive Resolver
   │
   ▼
Stub Resolver
   │
   ▼
Browser
```
17. Why This Is Fast

You might think:
```
Browser
 ↓
Root
 ↓
TLD
 ↓
Authoritative
```
must happen every time.

It doesn’t.

Caching is one of the main reasons DNS can operate at global scale.

18. TTL

Suppose the authoritative DNS server returns:
```
A
203.0.113.10
TTL 3600
```
The resolver can cache that information for the appropriate TTL period.

Conceptually:
```
Answer
 ↓
Cache
 ↓
3600 seconds
```
During that period, another client asking the same resolver may receive the cached answer.

19. TTL Is a Countdown

Suppose:
```
TTL = 3600
```
The resolver caches it.

After some time:
```
Remaining TTL = 2500
```
Later:
```
Remaining TTL = 100
```
When the cached information expires, the resolver needs to obtain fresh information.

20. DNS Cache Is Not Permanent

Eventually:
```
TTL expires
 ↓
Cache entry expires
 ↓
New resolution
```
This is why DNS changes don’t necessarily become visible everywhere immediately.

21. Example DNS Change

Suppose you originally have:
```
templates.cresignsys.com
A
OLD-IP
```
You change it to:
```
templates.cresignsys.com
A
NEW-IP
```
But a resolver may already have:
```
OLD-IP
```
cached.

Therefore:
```
DNS authoritative data = NEW-IP

Some resolver cache = OLD-IP
```
temporarily.

22. Different Resolvers Can Have Different Cached Answers

Imagine:
```
Resolver A → OLD-IP
Resolver B → NEW-IP
Resolver C → NEW-IP
```
This can happen during normal DNS caching transitions.

Therefore two users can temporarily receive different answers.

23. “DNS Propagation”

The term:
```
DNS propagation
```
is commonly used for this situation.

But conceptually it is often better to think:
```
Authoritative data changed
        ↓
Cached data expires/revalidates
        ↓
Different resolvers update at different times
```
It isn’t literally a single DNS message traveling around the world.

24. Negative DNS Answers

DNS can also cache the fact that something doesn’t exist.

For example:
```
Does:
abc123.cresignsys.com
exist?
```
The authoritative system may answer negatively.

That negative result can also be cached according to DNS rules.

This is called:

Negative caching

25. Why Negative Caching Matters

Suppose you create:
```
newsite.cresignsys.com
```
A resolver may have previously learned:
```
newsite.cresignsys.com
does not exist
```
It may temporarily continue returning the negative result until the applicable negative-cache lifetime expires.

So a newly created DNS record may not immediately appear through every resolver.

26. NXDOMAIN

A common negative DNS response is:

NXDOMAIN

It means the queried domain name does not exist in the relevant DNS namespace.

Conceptually:
```
Query:
abc.cresignsys.com

Response:
NXDOMAIN
```
This is different from simply having an existing name with no particular record of the requested type.

27. NXDOMAIN vs No A Record

Suppose:
```
templates.cresignsys.com
```
exists but has no A record.

That is not necessarily the same as:
```
templates.cresignsys.com
doesn't exist at all
```
DNS distinguishes between different kinds of negative answers.

This distinction becomes important in troubleshooting.

28. DNS Query Types

When your resolver asks:
```
A?
```
it specifically requests an IPv4 address record.

For example:
```
dig templates.cresignsys.com A
```
For IPv6:
```
dig templates.cresignsys.com AAAA
```
Different questions produce different answers.

29. DNS Response Structure

A DNS response can contain several conceptual sections:
```
QUESTION
ANSWER
AUTHORITY
ADDITIONAL
```
You can see these with:
```
dig templates.cresignsys.com
```
30. QUESTION Section

This represents what was asked.

Conceptually:
```
QUESTION:
templates.cresignsys.com. IN A
```
Meaning:
```
Name:
templates.cresignsys.com

Class:
IN

Type:
A
```
31. ANSWER Section

The answer might contain:
```
templates.cresignsys.com. 3600 IN A 203.0.113.10
```
Conceptually:
```
Name
 ↓
TTL
 ↓
Class
 ↓
Type
 ↓
Value
```
32. IN Means Internet

You will often see:
```
IN
```
in DNS output.

It means:

Internet

It is the DNS class normally used for the public Internet.

So:
```
IN A
```
means:
```
Internet class
+
A record
```
33. Authority Section

The authority section can contain information relevant to the authority for the response.

For example, in some responses you may see:
```
NS
```
records.

This becomes particularly useful when following delegations and negative answers.

34. Additional Section

The additional section can contain supporting information.

For example, DNS may provide address records associated with names referenced by other DNS records.

This can reduce the number of additional lookups required.

35. DNS Iterative Resolution

Now we can understand the difference between:

Recursive

and:

Iterative

The client asks the recursive resolver:
```
"Find the answer for me."
```
The recursive resolver may perform several iterative queries:
```
Resolver → Root
Resolver → TLD
Resolver → Authoritative
```
36. Recursive Request

From the client’s perspective:
```
Client
   │
   │ "Find templates.cresignsys.com"
   ▼
Resolver
   │
   │ does the work
   ▼
Answer
```
That’s recursion from the client’s perspective.

37. Iterative Queries

The resolver may ask:
```
Root:
"Where is .com?"
```
Root answers:
```
"Ask these .com servers."
```
Then:
```
Resolver → .com
```
.com answers:
```
"Ask these cresignsys.com nameservers."
```
Then:
```
Resolver → authoritative DNS
```
Authoritative server answers:
```
"Here is the A record."
```
These are iterative steps.

38. Root Hints

How does a recursive resolver initially know where the root servers are?

It can use:

Root hints

Root hints contain information needed to locate the root DNS server infrastructure.

They are used by recursive DNS software as a starting point for iterative resolution.

39. Root Server Letters

The DNS root system is represented by:
```
a.root-servers.net
b.root-servers.net
...
m.root-servers.net
```
These represent the well-known root server identities.

There are many physical instances distributed globally using anycast.

40. Anycast

This introduces another important networking concept:

Anycast

The same service address can be announced from multiple geographic/network locations.

Conceptually:
```
             Root DNS
           /     |     \
          /      |      \
       Location Location Location
```
Your DNS query can be routed to an appropriate nearby/available instance.

This improves:
```
Performance
Resilience
Availability
```
41. Root DNS Is Distributed

There isn’t simply:
```
one root computer
```
Instead:
```
Root DNS service
      ↓
Many instances
      ↓
Distributed globally
```
This is essential for Internet-scale reliability.

42. TLD Infrastructure Is Also Distributed

Similarly:
```
.com
```
is served through distributed DNS infrastructure.

The Internet’s DNS system is therefore highly distributed.

43. Authoritative DNS Can Also Be Distributed

Your domain’s authoritative DNS provider may have multiple nameservers.

For example:
```
ns1.example.com
ns2.example.com
```
Potentially in different networks/locations.

This gives redundancy.

44. Why Multiple Nameservers?

Suppose there is only:
```
ns1
```
and it fails.

DNS resolution for the domain could become unavailable.

With:
```
ns1
ns2
ns3
```
the system can remain available if one server fails, assuming they are properly configured.

45. DNS Availability

This leads to an important hosting concept:

Your website depends on multiple systems:
```
DNS
Cloud network
Firewall
Server
Nginx
TLS
PHP
Database
Storage
```
Failure in any important layer can affect the website.

46. DNS and Your VPS

Your VPS doesn’t necessarily have to run DNS.

You can have:
```
DNS Provider
      ↓
Your VPS
```
For example:
```
DNS provider
A record
   ↓
VPS public IP
```
Your Ubuntu server then only needs to provide:
```
HTTP/HTTPS
```
It doesn’t have to be an authoritative DNS server.

47. Running Your Own DNS

You could theoretically run DNS software on your VPS:
```
BIND
PowerDNS
Knot DNS
NSD
```
Then your server could participate in authoritative DNS.

But this introduces:
```
DNS security
Redundancy
Zone management
DNSSEC
Nameserver infrastructure
```
For a hosting platform, DNS architecture needs careful planning.

48. DNS Provider vs Registrar

These are often confused.

Registrar

The company through which a domain registration is managed.

DNS provider

The service that hosts/manages DNS zones.

Sometimes one company provides both.

But they are conceptually different.

49. Domain Registration

Suppose you register:
```
cresignsys.com
```
The registrar manages the registration relationship.

The domain is delegated to authoritative nameservers.

Conceptually:
```
Domain registration
       ↓
Nameserver delegation
       ↓
Authoritative DNS
       ↓
DNS records
```
50. Why This Matters for Hosting

When you create:
```
templates.cresignsys.com
```
you generally need:
```
DNS record
```
pointing to your server.

Then on your server:
```
Nginx server block
```
must recognize the same hostname.

So:
```
DNS hostname
=
Nginx hostname
```
must be coordinated.

51. The Hosting Creation Process

When creating a new hosted domain, conceptually:
```
1. Create DNS record
        ↓
2. Point name to VPS
        ↓
3. Create website directory
        ↓
4. Create Nginx server block
        ↓
5. Configure PHP-FPM if needed
        ↓
6. Install SSL
        ↓
7. Deploy application
```
This is the architecture behind a hosting automation script.

52. Example: New Website

Suppose you want:
```
newsite.cresignsys.com
```
First:
```
DNS
 ↓
newsite.cresignsys.com
 ↓
VPS IP
```
Then:
```
VPS
 ↓
/storage/websites/newsite.cresignsys.com/public
```
Then:
```
Nginx
 ↓
server_name newsite.cresignsys.com
```
Then:
```
TLS
 ↓
certificate
```
Then:
```
WordPress
```
53. Why DNS Must Come First

If the domain doesn’t resolve to the server:
```
Browser
 ↓
DNS
 ↓
wrong/no IP
```
the user never reaches:
```
Nginx
```
So your hosting automation needs to understand DNS as a separate layer.

54. DNS and Port Numbers

DNS A/AAAA records generally don’t contain:
```
:443
```
For example:
```
templates.cresignsys.com
A
203.0.113.10
```
The browser determines HTTPS’s default port:
```
443
```
from the URL scheme.

So:
```
DNS → IP
URL scheme → port
```
Conceptually:
```
https://templates.cresignsys.com
         │
         ├── DNS → IP
         │
         └── HTTPS → TCP 443
```
55. DNS Does Not Store Your Nginx Path

DNS does not know:
```
/storage/websites/templates.cresignsys.com/public
```
That information belongs to your server configuration.

So:
```
DNS:
hostname → IP
```
while:
```
Nginx:
hostname → website configuration/path
```
This distinction is fundamental.

56. DNS Does Not Store Your WordPress Database

DNS also does not know:
```
MySQL database
WordPress username
PHP version
Plugins
Themes
```
These belong to the application/server layers.

Therefore:
```
DNS
 ↓
Network location

Nginx
 ↓
Web routing

PHP
 ↓
Application execution

MySQL
 ↓
Application data
```
57. Deep Layer Map

Your web hosting system can now be visualized as:
```
                    USER
                     │
                     ▼
                  BROWSER
                     │
                     ▼
                    DNS
                     │
                     ▼
                 IP ADDRESS
                     │
                     ▼
                  ROUTING
                     │
                     ▼
                CLOUD NETWORK
                     │
                     ▼
                  FIREWALL
                     │
                     ▼
                   TCP 443
                     │
                     ▼
                TLS + SNI
                     │
                     ▼
                   NGINX
                     │
                     ▼
                 PHP-FPM
                     │
                     ▼
                WORDPRESS
                     │
                     ▼
                  MYSQL
                     │
                     ▼
                FILESYSTEM
                     │
                     ▼
                  STORAGE
```
58. One Very Important Principle

When troubleshooting:

Always identify the first layer that fails.

For example:
```
DNS fails
```
Do not start changing:
```
PHP
WordPress
MySQL
```
They haven’t even been reached.

Similarly:
```
DNS works
TCP works
TLS fails
```
Don’t immediately reinstall WordPress.

The problem is higher in the stack.

59. Practical DNS Investigation

Run:
```
dig templates.cresignsys.com A
```
Then:
```
dig +trace templates.cresignsys.com
```
Then:
```
dig templates.cresignsys.com A +stats
```
The +stats output can show timing information.

60. Test the Authoritative Server Directly

First find the authoritative nameservers:
```
dig +short cresignsys.com NS
```
Then query one of them directly.

Conceptually:
```
dig @AUTH_SERVER templates.cresignsys.com A
```
Replace AUTH_SERVER with the actual authoritative nameserver.

This is powerful because you can compare:
```
Authoritative answer
```
against:
```
Recursive resolver answer
```
61. Why Direct Authoritative Queries Are Useful

Suppose:
```
Authoritative DNS:
NEW-IP
```
but:
```
Recursive resolver:
OLD-IP
```
You immediately know:
```
DNS zone is updated
but cache still contains old data
```
This is a practical troubleshooting technique.

62. DNS Learning Milestone

You now understand:
```
Domain
 ↓
DNS hierarchy
 ↓
Root
 ↓
TLD
 ↓
Authoritative DNS
 ↓
Records
 ↓
Recursive resolver
 ↓
Cache
 ↓
TTL
 ↓
Client
```
This is enough foundation to begin studying real DNS troubleshooting.

Next Lesson — 028

DNS Troubleshooting in a Real Web Hosting Server

We will take actual situations such as:
```
Domain not opening
        ↓
Is DNS correct?

DNS correct
        ↓
Is IP correct?

IP correct
        ↓
Is port 443 open?

443 open
        ↓
Is Nginx listening?

Nginx listening
        ↓
Is TLS correct?

TLS correct
        ↓
Is server_name correct?

server_name correct
        ↓
Is website root correct?

Root correct
        ↓
Is PHP-FPM working?

PHP working
        ↓
Is WordPress working?
```
We will also learn:
```
dig
nslookup
host
ping
traceroute
tracepath
ss
curl
openssl s_client
nginx -t
journalctl
```
and how each command tests a different layer of the hosting stack.
August 13, 2026

CresignSys Learn — Lesson 026

DNS Records Deep Dive

We now know:

Domain
 ↓
DNS
 ↓
IP address
 ↓
Network
 ↓
TCP
 ↓
TLS
 ↓
HTTP
 ↓
Nginx

Now we go one level deeper into what DNS actually stores.

1. DNS Is Made of Records

DNS does not simply contain:

domain → IP

It contains different types of records.

Think of a DNS zone as a database table:

NAME                         TYPE       VALUE
────────────────────────────────────────────────────
cresignsys.com               A          IP
templates.cresignsys.com    A          IP
www.cresignsys.com           CNAME      cresignsys.com
cresignsys.com               MX         mail server
cresignsys.com               TXT        verification data
cresignsys.com               NS         nameserver
cresignsys.com               SOA        zone information

Each record has a specific purpose.

2. The Most Important Records

For web hosting, learn these first:

A
AAAA
CNAME
NS
SOA
MX
TXT
CAA

Later:

PTR
SRV
NAPTR
DNSSEC records

3. A Record

The A record maps a name to an IPv4 address.

Example:

templates.cresignsys.com
        ↓
       A
        ↓
203.0.113.10

Again, 203.0.113.10 is only an example.

4. What Happens After an A Record?

Suppose:

templates.cresignsys.com
A
203.0.113.10

The browser can then attempt:

203.0.113.10:443

The path becomes:

Domain
 ↓
A record
 ↓
IPv4
 ↓
TCP 443
 ↓
TLS
 ↓
Nginx

5. AAAA Record

AAAA performs the equivalent function for IPv6.

Example:

templates.cresignsys.com
AAAA
2001:db8::10

Conceptually:

A
 ↓
IPv4

AAAA
 ↓
IPv6

6. Why Both Can Exist

A website can have:

templates.cresignsys.com
 ├── A
 │    └── IPv4 address
 │
 └── AAAA
      └── IPv6 address

A client may use IPv6 when available and appropriate, or IPv4 otherwise.

The actual connection behavior depends on the client and network.

7. CNAME

CNAME means:

Canonical Name

It creates an alias.

Example:

www.cresignsys.com
        ↓
      CNAME
        ↓
cresignsys.com

Then DNS can resolve:

cresignsys.com
 ↓
A / AAAA
 ↓
IP

8. CNAME Does Not Mean Redirect

This is a common misunderstanding.

DNS CNAME:

www.example.com
      ↓
CNAME
      ↓
example.com

is not an HTTP redirect.

It happens at the DNS level.

An HTTP redirect happens later:

Browser
 ↓
HTTP request
 ↓
Web server
 ↓
301/302
 ↓
new URL

These are completely different mechanisms.

9. CNAME Example

Suppose:

www.cresignsys.com
CNAME
cresignsys.com

The browser asks DNS:

What is www.cresignsys.com?

DNS follows the CNAME relationship and ultimately obtains the relevant address information for:

cresignsys.com

10. CNAME and IP Address

Remember:

A:
name → IPv4

while:

CNAME:
name → another name

So:

A
 ↓
192.0.2.10

but:

CNAME
 ↓
another.example.com

11. NS Record

NS means:

Name Server

It tells DNS which authoritative nameservers are responsible for a zone.

Conceptually:

cresignsys.com
      ↓
     NS
      ↓
ns1.example-dns.com
ns2.example-dns.com

These nameservers are responsible for serving authoritative DNS information.

12. Why NS Is Important

Imagine your domain registrar knows:

cresignsys.com

but doesn’t itself necessarily store all your DNS records.

You tell the DNS system:

Use these nameservers for cresignsys.com.

Conceptually:

Registrar / parent zone
        ↓
NS delegation
        ↓
Authoritative DNS
        ↓
A / AAAA / MX / TXT / etc.

13. Delegation

This is one of the deepest DNS concepts.

The parent zone can delegate responsibility for a child domain.

For example:

.com
 ↓
cresignsys.com

The .com infrastructure knows which nameservers are authoritative for:

cresignsys.com

Then those servers manage the records within that domain’s zone.

14. SOA Record

SOA means:

Start of Authority

It contains information about the DNS zone.

Conceptually:

cresignsys.com
      ↓
     SOA
      ↓
Zone information

It includes things such as:

Primary/authoritative server information
Administrative contact information
Serial number
Refresh-related timing
Retry-related timing
Expiration-related timing
Minimum/negative caching-related information

The exact semantics of these fields are defined by DNS standards.

15. DNS Serial Number

The SOA record contains a serial value.

It can be used by secondary DNS systems to determine whether zone data has changed.

Conceptually:

Old zone
Serial = 100

New zone
Serial = 101

The secondary can recognize that the zone has been updated.

Modern DNS providers often manage this automatically.

16. MX Record

MX means:

Mail Exchange

It tells mail systems where email for a domain should be delivered.

Example:

cresignsys.com
MX
mail.example.com

It also has a priority value.

Conceptually:

Priority 10 → mail1
Priority 20 → mail2

Lower numeric preference values generally have higher priority.

17. Website vs Email

Your website might use:

while email uses:

MX

Therefore:

cresignsys.com
 ├── Website → A / AAAA
 │
 └── Email   → MX

The same domain can support completely different services.

18. TXT Record

TXT records contain text data.

They are heavily used for verification and policy mechanisms.

Examples include:

Domain ownership verification
SPF
DKIM
DMARC
ACME DNS challenges
Other service verification

19. SPF

SPF means:

Sender Policy Framework

It is an email authentication mechanism that uses DNS TXT records to publish which servers are authorized to send mail for a domain.

Conceptually:

cresignsys.com
      ↓
     TXT
      ↓
SPF policy
      ↓
Mail receiver checks

SPF is about email, not web hosting.

20. DKIM

DKIM means:

DomainKeys Identified Mail

It uses cryptographic signatures to help verify that an email is associated with a domain and has not been modified in transit in ways detectable by the signature.

The public key is published in DNS.

Conceptually:

Email
 ↓
DKIM signature
 ↓
Receiver
 ↓
DNS
 ↓
Public key
 ↓
Verify signature

21. DMARC

DMARC means:

Domain-based Message Authentication, Reporting, and Conformance

It builds on email authentication mechanisms such as:

SPF
DKIM

and lets a domain publish policy/reporting instructions through DNS.

Conceptually:

SPF
 +
DKIM
 +
DMARC policy

This belongs to email security rather than website HTTPS.

22. CAA Record

CAA is particularly relevant to your SSL learning.

CAA stands for:

Certification Authority Authorization

It allows a domain to publish which certificate authorities are authorized to issue certificates for it.

Conceptually:

cresignsys.com
      ↓
     CAA
      ↓
Authorized certificate authority

23. CAA and Let’s Encrypt

Suppose your DNS policy allows:

Let's Encrypt

to issue certificates.

Conceptually:

Let's Encrypt
      ↓
Check CAA
      ↓
Is this CA authorized?
      ↓
Yes
      ↓
Continue certificate issuance

If the CAA policy prohibits that CA, issuance can fail.

CAA is an additional control; certificate authorities also perform their required domain-control validation.

24. PTR Record

PTR is essentially the reverse of an A-style mapping.

Forward DNS:

name
 ↓
IP

Reverse DNS:

IP
 ↓
name

This is called:

Reverse DNS

25. Reverse DNS

Suppose:

server.example.com
A
203.0.113.10

Reverse DNS could conceptually provide:

203.0.113.10
 ↓
server.example.com

The reverse namespace for IPv4 uses:

in-addr.arpa

IPv6 uses:

ip6.arpa

26. Why Reverse DNS Matters

Reverse DNS can be important for:

Mail servers
Server identification
Logging
Network troubleshooting
Some reputation systems

For a web server, it is not generally what makes HTTPS work.

27. SRV Record

SRV records provide information about services, including:

service
protocol
priority
weight
port
target

Conceptually:

_service._tcp.example.com
        ↓
SRV
        ↓
server + port

They are used by various network services and applications.

28. DNS Record Comparison

Record	Main purpose
A	Name → IPv4
AAAA	Name → IPv6
CNAME	Name → another name
NS	Authoritative nameserver delegation
SOA	Zone authority/metadata
MX	Mail delivery
TXT	Text/policy/verification
CAA	Certificate authority authorization
PTR	Reverse DNS
SRV	Service discovery

29. A Realistic Hosting Zone

Imagine your DNS zone contains:

cresignsys.com

A       → server IP
AAAA    → server IPv6

templates.cresignsys.com
A       → server IP

learn.cresignsys.com
A       → server IP

shop.cresignsys.com
A       → server IP

www
CNAME   → cresignsys.com

MX      → mail server

TXT     → verification/email policies

CAA     → certificate authority policy

This creates the DNS side of your hosting architecture.

30. DNS Does Not Create the Website

This is one of the most important concepts.

Suppose DNS says:

templates.cresignsys.com
A
SERVER-IP

That does not mean the website automatically exists.

You still need:

Server
 ↓
Network access
 ↓
Port 443
 ↓
Nginx
 ↓
Server block
 ↓
Website files

DNS only gets the client to the appropriate network destination.

31. DNS + Nginx

Now connect the two systems.

DNS:

templates.cresignsys.com
       ↓
     A record
       ↓
    Server IP

Nginx:

Server IP:443
       ↓
Hostname
       ↓
templates.cresignsys.com
       ↓
Website configuration
       ↓
/storage/websites/templates.cresignsys.com/public

This is the key relationship between DNS and web hosting.

32. Same IP, Multiple Websites

This is where hosting becomes interesting.

Suppose:

templates.cresignsys.com
learn.cresignsys.com
shop.cresignsys.com

all point to:

same server IP

How can Nginx know which website the visitor wants?

Because the HTTP request contains the hostname, and TLS also uses the hostname during the HTTPS connection setup through SNI.

Conceptually:

                 Same IP
                   │
          ┌────────┼────────┐
          ↓        ↓        ↓
      templates   learn    shop
          │        │        │
          ↓        ↓        ↓
        Nginx    Nginx    Nginx
          │        │        │
          ↓        ↓        ↓
       Site A    Site B   Site C

33. One Server, Many Domains

This is the foundation of shared hosting.

                    VPS
                     │
                Public IP
                     │
                    Nginx
        ┌────────────┼────────────┐
        ↓            ↓            ↓
     Site A        Site B       Site C
        │            │            │
        ↓            ↓            ↓
   WordPress      WordPress      HTML

DNS makes all those names point toward the server.

Nginx separates them.

34. Domain → DNS → Nginx

The complete chain:

templates.cresignsys.com
          ↓
         DNS
          ↓
       Server IP
          ↓
     TCP port 443
          ↓
         TLS
          ↓
        Nginx
          ↓
Hostname matching
          ↓
templates.cresignsys.com
          ↓
Website directory

35. Why the Hostname Is Important

Suppose three domains use one IP:

A → 203.0.113.10
B → 203.0.113.10
C → 203.0.113.10

The IP alone cannot tell Nginx which website is wanted.

The application-level hostname helps.

For HTTPS, TLS also has:

SNI

Server Name Indication.

36. SNI

SNI allows the client to indicate the hostname it wants during the TLS handshake.

Conceptually:

Client
 ↓
TLS ClientHello
 ↓
SNI:
templates.cresignsys.com
 ↓
Server

Nginx can then select the appropriate certificate/configuration for the requested hostname.

This is crucial for modern HTTPS hosting.

37. Certificate + SNI

Suppose one server hosts:

templates.cresignsys.com
learn.cresignsys.com
shop.cresignsys.com

It may have certificates covering these different names.

The TLS connection indicates the requested hostname through SNI.

Conceptually:

Client
 ↓
SNI = templates.cresignsys.com
 ↓
Nginx
 ↓
Select appropriate TLS configuration
 ↓
Certificate for requested hostname

38. DNS Does Not Choose the Certificate

This is subtle.

DNS says:

templates.cresignsys.com
 ↓
IP

SNI says:

TLS connection wants:
templates.cresignsys.com

Nginx then uses its configuration to select an appropriate certificate/server block.

So:

DNS
 ↓
network destination

SNI
 ↓
TLS hostname

Nginx
 ↓
virtual host

39. Practical DNS Inspection

Install/use dig if available:

dig templates.cresignsys.com A

You can inspect the answer.

For CNAME:

dig www.cresignsys.com CNAME

For nameservers:

dig cresignsys.com NS

For mail:

dig cresignsys.com MX

For TXT:

dig cresignsys.com TXT

For certificate authority policy:

dig cresignsys.com CAA

40. Short Form

You can also use:

dig +short templates.cresignsys.com A

This focuses on the answer.

For example:

203.0.113.10

if that were the actual result.

41. Follow CNAMEs

Try:

dig +short www.cresignsys.com

If www is a CNAME, the result can help show the eventual address information after resolution.

42. Check Your Nameservers

Run:

dig +short cresignsys.com NS

This tells you which nameservers are authoritative for the domain.

This is one of the first things to check when debugging DNS.

43. Check the Authoritative Answer

You can use:

dig +trace templates.cresignsys.com

This is particularly useful for understanding:

Root
 ↓
TLD
 ↓
Domain delegation
 ↓
Authoritative server
 ↓
Record

44. The DNS Hierarchy as a Tree

Think of DNS like this:

.
│
├── com
│   │
│   ├── cresignsys
│   │    │
│   │    ├── templates
│   │    ├── learn
│   │    ├── shop
│   │    └── www
│   │
│   └── other domains
│
├── org
│
├── net
│
└── in

Each label is a node in a hierarchical namespace.

45. Subdomains Are Just Labels

For example:

templates.cresignsys.com

has:

templates

as one label beneath:

cresignsys.com

You could have:

learn.cresignsys.com
shop.cresignsys.com
manage.cresignsys.com

Each is another DNS name.

46. DNS Doesn’t Require Separate Servers

These can all point to the same server:

templates.cresignsys.com
learn.cresignsys.com
shop.cresignsys.com

For example:

templates → 203.0.113.10
learn     → 203.0.113.10
shop      → 203.0.113.10

One VPS can serve all three.

47. Different Servers Are Also Possible

You could instead have:

templates → Server A
learn     → Server B
shop      → Server C

DNS makes this possible.

Therefore DNS provides a layer of infrastructure abstraction.

48. DNS and Cloud Hosting

In a cloud environment:

DNS
 ↓
Public IP
 ↓
Cloud networking
 ↓
VNIC / virtual network interface
 ↓
Security rules
 ↓
VM
 ↓
Nginx

So DNS is only the first part of the network path.

49. Security Rules

Even if DNS is correct:

templates.cresignsys.com
 ↓
correct IP

cloud security rules may still block:

TCP 80
TCP 443

Then the website will not be reachable.

So troubleshooting must continue layer by layer.

50. The Three Different Configurations

For a working HTTPS website, you can think in terms of three separate configurations:

DNS

Name
 ↓
IP

Cloud/network firewall

Internet
 ↓
TCP 443
 ↓
Allowed?

Nginx

Port 443
 ↓
Hostname
 ↓
Certificate
 ↓
Website

All three need to cooperate.

51. Example Failure

Suppose:

DNS = correct
Firewall = correct
Nginx = stopped

Result:

DNS
 ↓
works

TCP 443
 ↓
connection refused/failed

52. Another Failure

DNS = wrong
Firewall = correct
Nginx = correct

Result:

Browser
 ↓
DNS
 ↓
wrong server

Your Nginx configuration can be completely correct and the user still won’t reach it.

53. Another Failure

DNS = correct
Firewall = correct
Nginx = correct
Certificate = wrong

Result:

TCP
 ↓
works

TLS
 ↓
certificate error

This layered diagnosis is one of the most valuable skills in web hosting.

54. Your Hosting Platform

You are gradually building a hosting architecture that can be represented as:

                 INTERNET
                     │
                     ▼
                    DNS
                     │
            ┌────────┼────────┐
            ▼        ▼        ▼
        templates   learn    shop
            │        │        │
            └────────┼────────┘
                     ▼
                  Public IP
                     │
                     ▼
                Cloud Network
                     │
                     ▼
                   Ubuntu
                     │
                     ▼
                  Nginx
          ┌──────────┼──────────┐
          ▼          ▼          ▼
       Site A      Site B      Site C
          │          │          │
          ▼          ▼          ▼
      WordPress   WordPress    HTML

That is the basic architecture behind a multi-site hosting server.

55. The Next Level: DNS Resolution in Detail

We can now go deeper into exactly what happens inside a DNS lookup:

Browser
 ↓
OS resolver
 ↓
Recursive resolver
 ↓
Cache
 ↓
Root hints
 ↓
Root nameserver
 ↓
TLD nameserver
 ↓
Authoritative nameserver
 ↓
A record
 ↓
TTL
 ↓
Cache
 ↓
Browser

Then we can connect DNS directly to:

TCP
 ↓
SNI
 ↓
TLS certificate
 ↓
Nginx server block

56. Practical Exercise for Your Server

Run these and record the output:

dig +short templates.cresignsys.com A

dig +short templates.cresignsys.com AAAA

dig +short cresignsys.com NS

dig +short cresignsys.com MX

dig +short cresignsys.com TXT

dig +short cresignsys.com CAA

Then:

dig +trace templates.cresignsys.com

These commands are read-only.

Do not modify DNS yet.

Lesson 026 Summary

The most important concepts are:

A
 ↓
IPv4

AAAA
 ↓
IPv6

CNAME
 ↓
Another DNS name

NS
 ↓
Authoritative nameservers

SOA
 ↓
Zone authority information

MX
 ↓
Email

TXT
 ↓
Policies / verification

CAA
 ↓
Certificate authority authorization

PTR
 ↓
Reverse DNS

SRV
 ↓
Service discovery

And the complete hosting connection is:

DOMAIN
   ↓
DNS RECORD
   ↓
IP ADDRESS
   ↓
CLOUD NETWORK
   ↓
FIREWALL
   ↓
TCP 443
   ↓
TLS + SNI
   ↓
NGINX
   ↓
SERVER BLOCK
   ↓
WEBSITE DIRECTORY

Next Lesson — 027

DNS Resolution — What Happens Inside the Resolver?

We will go even deeper into:

Stub Resolver
 ↓
Recursive Resolver
 ↓
Root Hints
 ↓
Root Server
 ↓
TLD Server
 ↓
Authoritative Server
 ↓
Caching
 ↓
TTL
 ↓
Negative Caching
 ↓
DNS Response

Then we will use dig +trace to understand the actual journey of templates.cresignsys.com from the DNS root to your domain.

August 13, 2026

CresignSys Learn — Lesson 025
Course: From Basic Science to Web Hosting

Module 05 — Networking Fundamentals

DNS — From Domain Name to IP Address

Difficulty: Beginner → Intermediate
Prerequisites: Lesson 024 — DNS → TCP → TLS → HTTPS
Estimated time: 45–60 minutes

We now study the first major step in opening:
```
https://templates.cresignsys.com
```
The question is:

How does a computer turn templates.cresignsys.com into an address that networking can use?

The answer is:

DNS — Domain Name System

1. The Basic Problem

Computers communicate using network addresses.

Humans prefer names.

You remember:
```
templates.cresignsys.com
```
rather than:
```
some IP address
```
DNS connects the two.
```
Domain name
     ↓
    DNS
     ↓
IP address
```
2. DNS Is a Distributed Database

A common beginner explanation is:

DNS is a phone book.

That is useful initially, but incomplete.

DNS is better understood as:

A globally distributed, hierarchical naming system and database.

It is distributed across many servers.

It is hierarchical.

And it contains many types of records.

3. The Domain Name

Consider:
```
templates.cresignsys.com
```
This name contains multiple labels:
```
templates
   .
cresignsys
   .
com
```
Read from right to left:
```
com
 ↓
cresignsys
 ↓
templates
```
4. The Root

At the top of DNS is:
```
.
```
the root.

The complete conceptual name is:
```
templates.cresignsys.com.
```
The final dot is normally hidden from users.

So:
```
templates.cresignsys.com
```
is shorthand for:
```
templates.cresignsys.com.
```
5. DNS Hierarchy

The hierarchy looks like:
```
                         .
                         │
              ┌──────────┼──────────┐
              │          │          │
             com        org        net
              │
         cresignsys
              │
          templates
```
So:
```
.
 ↓
com
 ↓
cresignsys
 ↓
templates
```
6. Root DNS

The root is the top of the DNS hierarchy.

The root system knows where to find information about top-level domains.

For example:
```
.
├── com
├── org
├── net
├── in
└── ...
```
The root doesn’t normally contain the final IP address of your website.

Instead, it helps direct DNS resolution toward the appropriate TLD.

7. TLD

TLD means:

Top-Level Domain

Examples:
```
.com
.org
.net
.in
```
For:
```
templates.cresignsys.com
```
the TLD is:
```
.com
```
8. Second-Level Domain

Inside:
```
.com
```
you have:
```
cresignsys
```
So:
```
cresignsys.com
```
is the domain name under the .com TLD.

9. Subdomain

Then:
```
templates
```
is a subdomain label.

Therefore:
```
templates.cresignsys.com
```
can be viewed as:
```
templates
    ↓
subdomain

cresignsys.com
    ↓
domain

com
    ↓
TLD
```
10. DNS Does Not Care That It Is a Website

DNS does not inherently know:

“This is a WordPress website.”

DNS simply stores information associated with names.

For example, DNS can contain:
```
A
AAAA
CNAME
MX
TXT
NS
CAA
```
and many other record types.

11. A Record

The most important record for basic IPv4 web hosting is:

A

An A record maps a hostname to an IPv4 address.

Conceptually:
```
templates.cresignsys.com
          ↓
        A record
          ↓
      IPv4 address
```
Example:
```
templates.cresignsys.com
A
203.0.113.10
```
The IP above is only an example.

12. AAAA Record

For IPv6, DNS commonly uses:

AAAA

Conceptually:
```
templates.cresignsys.com
          ↓
       AAAA
          ↓
       IPv6 address
```
Example:
```
2001:db8::10
```
Again, this is a documentation/example address.

13. A vs AAAA

Remember:
```
A
 ↓
IPv4

AAAA
 ↓
IPv6
```
A domain can have both.
```
templates.cresignsys.com
 ├── A
 │    └── IPv4
 │
 └── AAAA
      └── IPv6
```
14. CNAME

Another important record is:

CNAME

It creates an alias from one DNS name to another DNS name.

Conceptually:
```
www.example.com
       ↓
     CNAME
       ↓
example.com
```
Then DNS can continue resolving:
```
example.com
 ↓
A / AAAA
 ↓
IP address
```
15. Important CNAME Rule

A CNAME points to a name, not directly to an IP address.

Conceptually:
```
CNAME
 ↓
hostname
```
whereas:
```
A
 ↓
IPv4 address
```
16. NS Record

NS means:

Name Server

An NS record identifies the authoritative DNS servers for a domain/zone.

Conceptually:
```
cresignsys.com
      ↓
NS
      ↓
Authoritative DNS server
```
For example, conceptually:
```
ns1.example-dns.com
ns2.example-dns.com
```
The actual nameservers for your domain depend on your DNS provider.

17. Authoritative DNS Server

An authoritative DNS server contains the actual DNS records for a zone.

For example:
```
templates.cresignsys.com
A
203.0.113.10
```
If that record is authoritative, that server is providing the definitive DNS data for that zone.

18. Recursive DNS Resolver

Your computer often doesn’t directly ask the authoritative server.

Instead it asks a:

Recursive Resolver

Conceptually:
```
Your computer
      ↓
Recursive resolver
      ↓
DNS hierarchy
      ↓
Authoritative server
```
The recursive resolver performs the lookup on behalf of the client and usually caches the result.

19. Why Use a Recursive Resolver?

Imagine every computer had to understand the entire DNS hierarchy.

That would be inefficient.

Instead:
```
Computer
   ↓
Resolver
   ↓
Does DNS work
   ↓
Returns answer
```
Your computer only needs to communicate with the resolver.

20. The Complete DNS Lookup

Suppose your browser wants:
```
templates.cresignsys.com
```
Conceptually:
```
Browser
  ↓
Operating system
  ↓
Recursive resolver
  ↓
Root
  ↓
.com
  ↓
cresignsys.com authoritative DNS
  ↓
templates.cresignsys.com
  ↓
A / AAAA
  ↓
IP address
```
But this is simplified because caching may eliminate many of these steps.

21. First Query: Root

The recursive resolver may ask a root server:

Where can I find information about .com?

The root responds with information directing the resolver toward .com nameservers.

Conceptually:
```
Resolver
   │
   │ Where is .com?
   ▼
Root
   │
   │ .com nameserver information
   ▼
Resolver
```
22. Second Query: TLD

The resolver then asks the .com TLD infrastructure:

Where are the authoritative nameservers for cresignsys.com?

Conceptually:
```
Resolver
   │
   │ Where is cresignsys.com?
   ▼
.com TLD
   │
   │ Authoritative nameserver information
   ▼
Resolver
```
23. Third Query: Authoritative Server

The resolver asks the authoritative server:

What is the A record for templates.cresignsys.com?

Conceptually:
```
Resolver
   │
   │ A templates.cresignsys.com?
   ▼
Authoritative DNS
   │
   │ IP address
   ▼
Resolver
```
24. Resolver Returns Answer

Finally:
```
Authoritative DNS
      ↓
Recursive resolver
      ↓
Your computer
      ↓
Browser
```
The browser now has the IP address.

Then DNS is mostly finished for this particular connection.

25. DNS Is Before TCP

This connects directly to the previous lesson.
```
Domain
 ↓
DNS
 ↓
IP address
 ↓
TCP
 ↓
TLS
 ↓
HTTP
```
Therefore:

If DNS fails, TCP connection establishment may never even begin because the client may not know where to connect.

26. DNS Caching

DNS lookups can be expensive if every request must travel through the whole hierarchy.

So DNS uses:

Caching

Suppose the resolver previously learned:
```
templates.cresignsys.com
 →
203.0.113.10
```
It can temporarily remember that answer.

Then another user asks:
```
templates.cresignsys.com
```
The resolver may already know the answer.
```
Client
 ↓
Resolver
 ↓
Cache HIT
 ↓
IP address
```
No root/TLD/authoritative lookup is necessary at that moment.

27. Cache Hit
```
DNS query
   ↓
Resolver cache
   ↓
Found
   ↓
Return answer
```
Fast.

28. Cache Miss
```
DNS query
   ↓
Resolver cache
   ↓
Not found
   ↓
Perform DNS resolution
   ↓
Cache result
   ↓
Return answer
```
29. TTL

DNS records commonly have a:

TTL

Time To Live.

It tells caching resolvers how long the information can be cached before it should be considered expired and re-queried.

Example:
```
A record
TTL = 3600
```
Conceptually:
```
3600 seconds
=
1 hour
```
The actual caching behavior can involve additional details, but this is the basic idea.

30. Why TTL Matters

Suppose you change:
```
templates.cresignsys.com
```
from:
```
Old IP
```
to:
```
New IP
```
Some resolvers may still have the old answer cached until its TTL expires.

Therefore:
```
DNS change
 ↓
not necessarily instant everywhere
```
31. DNS Propagation

People often say:

“DNS propagation takes 24–48 hours.”

This is an oversimplification.

More precisely:
```
Different resolvers
 ↓
may have cached different answers
 ↓
until TTL-related caching expires
```
Changes can become visible at different times depending on caching, resolver behavior, and configuration.

32. DNS Zone

A:

DNS Zone

is an administratively managed portion of the DNS namespace.

For your domain:
```
cresignsys.com
```
the zone may contain records such as:
```
A
AAAA
CNAME
MX
TXT
NS
CAA
```
The exact records depend on your DNS configuration.

33. Zone vs Domain

These concepts are related but not identical.

A domain is part of the DNS namespace.

A zone is an administratively managed portion of that namespace.

For example:
```
cresignsys.com
```
could be one DNS zone.

A delegated subdomain could potentially be managed as a separate zone.

34. SOA Record

Another important DNS record is:

SOA

Start of Authority.

It contains important information about the DNS zone, including administrative and serial/timing information.

Conceptually:
```
Zone
 ↓
SOA
 ↓
Zone metadata
```
You don’t normally modify this manually when using a managed DNS provider.

35. MX Record

MX means:

Mail Exchange

It specifies mail servers for a domain.

Example conceptually:
```
cresignsys.com
   ↓
MX
   ↓
mail server
```
This is for email routing, not website hosting.

36. TXT Record

TXT records can store text data used by many systems.

Common uses include:
```
Domain verification
SPF-related email policy
DKIM-related information
DMARC-related information
Certificate/CA policy
Service verification
```
TXT records are extremely important in modern Internet infrastructure.

37. CAA Record

CAA means:

Certification Authority Authorization

It can specify which certificate authorities are authorized to issue certificates for a domain.

Conceptually:
```
cresignsys.com
      ↓
CAA
      ↓
Authorized CA(s)
```
This becomes directly relevant to your Let’s Encrypt learning.

38. DNS and Let’s Encrypt

When Let’s Encrypt issues a certificate, domain control must be validated.

One possible validation method is:

DNS-01

The ACME client creates a special TXT record.

Conceptually:
```
Let's Encrypt
      ↓
Challenge
      ↓
DNS TXT record
      ↓
Let's Encrypt checks DNS
      ↓
Domain control verified
```
Another common method is:

HTTP-01

Let’s Encrypt checks a special HTTP resource served by the domain.

Conceptually:
```
Let's Encrypt
      ↓
HTTP request
      ↓
your server
      ↓
challenge response
      ↓
domain control verified
```
We will study ACME and these challenges later.

39. DNS Is Not Certificate Validation

Another important distinction:
```
DNS
 ↓
Name resolution
```
while:
```
TLS certificate validation
 ↓
Server identity/authentication
```
They interact in some scenarios, but they solve different problems.

40. DNS Does Not Encrypt Your Website

DNS can tell you:
```
templates.cresignsys.com
 ↓
IP address
```
It does not automatically make:
```
HTTP
```
secure.

Security comes from mechanisms such as:
```
TLS
```
So:
```
DNS
 ↓
Find server

TLS
 ↓
Secure communication
```
41. DNS Record Example

Imagine your DNS zone contains:
```
templates.cresignsys.com.    A       203.0.113.10
```
Then:
```
templates.cresignsys.com
        ↓
A record
        ↓
203.0.113.10
```
Your browser can then attempt:
```
203.0.113.10:443
```
Again, this IP is only illustrative.

42. What Happens If the A Record Is Wrong?

Suppose DNS points to:
```
Old server
```
while your website is actually on:
```
New server
```
Then:
```
Browser
 ↓
DNS
 ↓
Wrong IP
 ↓
Wrong server
```
Your Nginx configuration can be perfect and the website can still fail.

This is why DNS must be understood separately from Nginx.

43. What Happens If DNS Works but Port 443 Is Closed?

Then:
```
DNS
 ↓
works
 ↓
IP address
 ↓
TCP 443
 ↓
fails
```
The browser cannot reach the HTTPS service.

Again:
```
DNS problem ≠ TCP problem
```
44. What Happens If TCP Works but Certificate Is Wrong?

Then:
```
DNS
 ↓
works

TCP
 ↓
works

TLS
 ↓
fails
```
For example, the certificate may:
```
not match hostname
be expired
have an untrusted chain
be incorrectly configured
```
So the website can have a perfectly working IP and TCP port but still fail HTTPS validation.

45. DNS + TCP + TLS

We can now distinguish three different questions:

DNS
```
Where is the server?
```
TCP
```
Can I establish a transport connection?
```
TLS
```
Can I establish a secure authenticated session?
```
HTTP
```
What web resource do I want?
```
This layered thinking is extremely important.

46. DNS Command: dig

One of the best DNS learning tools is:
```
dig
```
For example:
```
dig templates.cresignsys.com
```
It can show the DNS answer and other information.

47. Ask Specifically for A
```
dig templates.cresignsys.com A
```
This asks for:
```
A record
```
48. Ask for AAAA
```
dig templates.cresignsys.com AAAA
```
This asks for:
```
AAAA record
```
49. Ask for NS
```
dig cresignsys.com NS
```
This asks:
```
Which nameservers are authoritative for the domain?
```
50. Ask for MX
```
dig cresignsys.com MX
```
This asks about mail-exchange records.

51. Ask for TXT
```
dig cresignsys.com TXT
```
This displays TXT records.

This can be useful when learning:
```
SPF
DKIM
DMARC
verification
ACME DNS challenges
```
52. dig +trace

A particularly educational command is:
```
dig +trace templates.cresignsys.com
```
This can show the iterative DNS resolution path from the root toward the authoritative answer.

Conceptually:
```
Root
 ↓
.com
 ↓
cresignsys.com
 ↓
templates.cresignsys.com
```
It is an excellent tool for understanding the DNS hierarchy.

53. resolvectl

On many modern Ubuntu systems:
```
resolvectl status
```
can show resolver configuration.

You may see information about:
```
DNS servers
Interfaces
DNS domains
```
The exact configuration depends on your Ubuntu/cloud setup.

54. /etc/resolv.conf

Linux systems also commonly expose resolver configuration through:
```
/etc/resolv.conf
```
You can inspect it:
```
cat /etc/resolv.conf
```
Depending on the system, this may be a symlink or managed by another service.

55. DNS Resolver Flow

Your computer may work approximately like:
```
Browser
   ↓
OS resolver
   ↓
Configured DNS resolver
   ↓
Recursive DNS server
   ↓
Cache / DNS hierarchy
   ↓
Answer
```
The exact implementation differs across operating systems and network environments.

56. Authoritative vs Recursive

This distinction is extremely important.

Recursive resolver

Finds answers on behalf of clients.
```
Client
 ↓
Recursive resolver
```
Authoritative server

Provides authoritative DNS data for its zone.
```
Recursive resolver
 ↓
Authoritative server
```
They perform different jobs.

57. Root Server vs Authoritative Server

The root system doesn’t normally answer:
```
"What is the IP of templates.cresignsys.com?"
```
Instead it helps answer:
```
"Where should I look for .com?"
```
Then .com helps answer:
```
"Where should I look for cresignsys.com?"
```
Then the authoritative DNS server answers:
```
"What is templates.cresignsys.com?"
```
58. Why DNS Is Hierarchical

Imagine every DNS server on Earth stored every hostname.

That would be inefficient.

Instead:
```
Root
 ↓
TLD
 ↓
Domain
 ↓
Subdomain
```
Each layer delegates responsibility.

This is one of the key ideas that allows DNS to scale globally.

59. Delegation

Suppose:
```
.com
```
delegates:
```
cresignsys.com
```
to certain authoritative nameservers.

Conceptually:
```
.com
 ↓
Delegation
 ↓
cresignsys.com nameservers
```
Those servers then manage the records for the domain/zone.

60. Your Hosting Architecture

Now connect DNS to your hosting system:
```
                 DNS
                  │
                  ▼
templates.cresignsys.com
                  │
                  ▼
              A record
                  │
                  ▼
             Server IP
                  │
                  ▼
             Cloud VM
                  │
                  ▼
              Ubuntu
                  │
                  ▼
                Nginx
                  │
                  ▼
/storage/websites/templates.cresignsys.com/public
```
DNS gets the user to the server.

Nginx gets the request to the website.

61. DNS Is Outside Your Ubuntu Server

This is important for your hosting platform.

Your server contains:
```
Ubuntu
Nginx
PHP
MySQL
WordPress
```
But DNS records are usually managed through a DNS provider or registrar’s DNS service.

Therefore:
```
DNS configuration
```
and:
```
Nginx configuration
```
are separate systems.

62. Why Your SSL Setup Needed DNS

When you ran Certbot for:
```
templates.cresignsys.com
```
Let’s Encrypt needed to establish that the requester controls the domain.

With HTTP-01, the validation path involves:
```
Let's Encrypt
 ↓
DNS
 ↓
templates.cresignsys.com
 ↓
Your public server
 ↓
HTTP challenge
```
After validation:
```
Let's Encrypt
 ↓
certificate
 ↓
Certbot
 ↓
Nginx
```
63. The Three Major DNS Uses in Your Hosting

DNS can be involved in:

1. Website routing
```
domain
 ↓
A/AAAA
 ↓
server
```
2. Email
```
domain
 ↓
MX
 ↓
mail server
```
3. Certificate validation
```
domain
 ↓
DNS or HTTP challenge
 ↓
Let's Encrypt
```
64. DNS Security

DNS itself has security challenges.

Traditional DNS queries/responses can be observed or modified depending on the network path and resolver architecture.

Technologies such as:
```
DNSSEC
DoH
DoT
```
address different parts of the DNS security/privacy problem.

We will study these later.

65. DNSSEC

DNSSEC means:

Domain Name System Security Extensions

DNSSEC adds cryptographic signatures to DNS data so resolvers can validate that DNS responses are authentic and haven’t been tampered with within the DNSSEC validation model.

Conceptually:
```
DNS data
 ↓
Digital signature
 ↓
Resolver validates
```
This is different from TLS.

66. DNSSEC vs TLS

Remember:
```
DNSSEC
 ↓
Authenticates DNS data

TLS
 ↓
Authenticates server identity
 + encrypts application communication
 + protects integrity
```
They solve different problems.

67. DoH

DoH means:

DNS over HTTPS

DNS queries are transported through HTTPS.

Conceptually:
```
DNS query
 ↓
HTTPS
 ↓
DNS resolver
```
This can help protect DNS queries from some forms of network observation or manipulation between the client and resolver.

68. DoT

DoT means:

DNS over TLS

Similar idea:
```
DNS
 ↓
TLS
 ↓
Network
```
Again, this concerns the transport of DNS queries, not the TLS session used by your website itself.

69. Very Important Distinction

Your website:
```
https://templates.cresignsys.com
```
uses TLS to protect:
```
Browser ↔ Website
```
DoH/DoT concern:
```
Client ↔ DNS resolver
```
These are different connections.

70. Complete DNS-to-Web Chain

Now we can make the entire chain:
```
Browser
   │
   │ "Where is templates.cresignsys.com?"
   ▼
DNS Resolver
   │
   ▼
DNS hierarchy
   │
   ▼
Authoritative DNS
   │
   ▼
IP address
   │
   ▼
Internet routing
   │
   ▼
TCP :443
   │
   ▼
TLS
   │
   ▼
HTTPS
   │
   ▼
Nginx
```
71. The Most Important Mental Model

Remember these four questions:
```
DNS
 ↓
WHERE?

IP
 ↓
WHICH HOST/NETWORK?

TCP
 ↓
WHICH TRANSPORT CONNECTION?

PORT
 ↓
WHICH SERVICE?

TLS
 ↓
IS THE COMMUNICATION SECURE AND THE SERVER AUTHENTICATED?

HTTP
 ↓
WHAT WEB RESOURCE?
```
This model will make the rest of web hosting much easier.

72. Practical Exercise

On your Ubuntu server, run:
```
dig templates.cresignsys.com
```
Then:
```
dig templates.cresignsys.com A
```
Then:
```
dig templates.cresignsys.com AAAA
```
Then:
```
dig cresignsys.com NS
```
Then:
```
dig +trace templates.cresignsys.com
```
Then:
```
resolvectl status
```
Do not change anything yet.

The purpose is to observe how DNS works.

73. Next Lesson — 026

DNS Records Deep Dive

We will go one level deeper:
```
A
AAAA
CNAME
NS
SOA
MX
TXT
CAA
PTR
SRV
NAPTR
```
Then we will specifically build the DNS structure for a hosting platform:
```
cresignsys.com
├── www
├── templates
├── learn
├── shop
├── manage
└── other websites
```
and understand:
```
Domain
 ↓
Subdomain
 ↓
DNS record
 ↓
IP
 ↓
Server
 ↓
Nginx server block
 ↓
Website directory
```
This will be the foundation for understanding how one VPS can host dozens or hundreds of domains and subdomains.
August 13, 2026

CresignSys Learn — Lesson 024

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:

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.

August 13, 2026

CresignSys Learn — Lesson 023
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.
August 13, 2026

Author: cresignsys

CresignSys Learn — Lesson 032

Linux Processes — Deep Basics

1. Program vs Process

Program

Process

2. Simple Example

3. Long-Running Process

4. PID

Process ID

PID

5. PID 1

6. Parent Process

7. PPID

Parent Process ID

PPID

8. Example

9. Nginx Master and Workers

10. Why Multiple Workers?

11. Worker Processes

12. Event-Driven Architecture

13. PHP-FPM Is Different

14. Why PHP Workers Matter

15. PHP-FPM Worker Pool

16. MySQL Process

17. One WordPress Request

18. Many Requests

19. CPU Scheduling

20. Context Switching

Context switching

21. Threads

Threads

22. Process vs Thread

23. Nginx and Threads

24. PHP and Threads

25. Process States

26. R — Running/Runnable

27. S — Sleeping

28. D — Uninterruptible Sleep

29. T — Stopped/Traced

30. Z — Zombie

31. Zombie Does Not Mean Running

32. Inspect Process States

33. Process Tree

34. CPU Usage

35. Memory Usage

36. Why PHP Can Consume a Lot of RAM

37. Static vs Dynamic Resource Cost

Static

Dynamic

38. Why Caching Is Powerful

39. CPU Bottleneck

40. Memory Bottleneck

41. Swap

42. Why Your Server Needs Monitoring

43. Process Limits

44. File Descriptors

45. Nginx Connection Capacity

46. PHP-FPM Capacity

47. The Bottleneck Principle

48. Example

49. Another Example

50. Another Example

51. Signals

Signals

52. SIGTERM

53. SIGKILL

54. SIGHUP

55. Why systemctl Is Better Than Random Signals

56. Nginx Graceful Reload

57. Process Monitoring

58. Find Nginx Processes

59. Find PHP-FPM

60. Find MySQL

61. A Real Request and Processes

62. Complete Linux Stack

63. The Most Important Concepts Today

64. How This Helps Your Hosting Platform

65. The Next Layer: Virtual Memory

Virtual Memory

26. `R` — Running/Runnable

27. `S` — Sleeping

28. `D` — Uninterruptible Sleep

29. `T` — Stopped/Traced

30. `Z` — Zombie

55. Why `systemctl` Is Better Than Random Signals

23. `systemctl` Mental Model

26. `sudo`

28. `www-data`

31. `/etc`

32. `/var`

33. `/var/log`

34. `/run`

35. `/home`

36. Your `/storage`

40. `r`

41. `w`

42. `x`

45. `777`

47. `chown`

48. `chmod`