Linux Networking — From Internet to Your Nginx Process

We now move from the filesystem into networking inside the VPS.

The central question is:

When someone opens https://templates.cresignsys.com, how does the network packet travel from their computer all the way to the Nginx process running inside your Ubuntu server?

1. Start With the Complete Journey

At a high level:

Browser
   ↓
DNS
   ↓
Internet
   ↓
Cloud network
   ↓
Public IP
   ↓
VNIC
   ↓
Subnet
   ↓
Firewall/security rules
   ↓
Ubuntu network stack
   ↓
TCP :443
   ↓
Nginx
   ↓
TLS
   ↓
HTTP

There are many layers hidden inside this simple diagram.

We will open them one by one.

2. What Is a Network?

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

For example:

Computer A
     │
     │
   Network
     │
     │
Computer B

Your VPS is simply another network-connected computer.

3. The Internet

The Internet is not one giant physical cable controlled by one machine.

It is a:

Network of networks

Conceptually:

Your PC
   ↓
Home/Office Network
   ↓
ISP
   ↓
Internet
   ↓
Cloud Provider
   ↓
Your VPS

Different networks communicate using standardized protocols.

4. Network Interface

Your Ubuntu server needs a network interface to communicate with a network.

Run:

ip addr

You may see something similar to:

lo
eth0

or:

lo
ens3

The exact name depends on the operating system and cloud environment.

5. `lo`

The interface:

lo

means:

Loopback

Its typical IPv4 address is:

127.0.0.1

This means:

This computer itself.

6. Loopback Example

Suppose Nginx communicates with another service locally.

Conceptually:

Nginx
 ↓
127.0.0.1
 ↓
local service

The packet does not need to travel out to the Internet.

7. Network Interface and IP Address

An interface can have one or more IP addresses.

For example:

eth0
 ├── IPv4 address
 └── IPv6 address

The actual addresses on your Oracle Cloud VM depend on your VNIC configuration.

8. What Is an IP Address?

An IP address identifies a network endpoint/address.

Example IPv4:

192.168.1.10

Another:

10.0.0.5

A public IPv4 might look like:

203.0.113.50

The last example uses a documentation range.

9. IPv4

IPv4 addresses are:

32 bits

Usually written as four decimal numbers:

192.168.1.10

Each section represents 8 bits:

192 . 168 . 1 . 10
 ↓     ↓    ↓    ↓
 8     8    8    8 bits

Total:

8 × 4 = 32 bits

10. IPv6

IPv6 uses:

128 bits

Example:

2001:db8::1

IPv6 was developed primarily because IPv4 has a limited address space.

11. Public IP vs Private IP

This is fundamental for cloud hosting.

Private IP

Used within private/internal networks.

Common IPv4 private ranges include:

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

Public IP

Routable through the public Internet.

Your Oracle Cloud networking configuration determines how your VM is reached publicly.

12. Your Oracle Cloud VPS

Conceptually, your architecture is something like:

Internet
   ↓
Public IP
   ↓
Oracle Cloud VCN
   ↓
Subnet
   ↓
VNIC
   ↓
Private IP
   ↓
Ubuntu

The exact OCI implementation involves additional virtual networking components.

13. VCN

Oracle Cloud uses:

VCN — Virtual Cloud Network

Think of it as your private virtual network inside Oracle Cloud.

Conceptually:

Oracle Cloud
└── VCN
    ├── Subnet
    │   ├── VM 1
    │   ├── VM 2
    │   └── VM 3
    └── ...

14. Subnet

A subnet divides a network into a smaller network segment.

For example:

VCN
   ↓
Subnet
   ↓
VM

The subnet has an IP address range.

Example:

10.0.0.0/24

This is an example only; your actual OCI subnet may be different.

15. CIDR

You will frequently encounter notation such as:

10.0.0.0/24

This is:

CIDR notation

The /24 indicates that the first 24 bits represent the network prefix.

16. `/24`

IPv4 has:

32 bits

Therefore:

/24

means:

24 network bits
8 remaining host bits

So the range contains:

2^8 = 256

IPv4 addresses in the mathematical range.

Some addresses may have special/reserved purposes depending on the network context.

17. Example Subnet

Imagine:

10.0.1.0/24

Conceptually:

Network:
10.0.1.0

Possible addresses:
10.0.1.x

The exact usable-address rules depend on the networking environment.

18. Why Subnets Matter

The server needs to know:

Is this destination on my local network or somewhere else?

The subnet/routing configuration helps determine that.

19. Routing

Suppose your server wants to communicate with:

8.8.8.8

Linux asks:

Where should I send this packet?

The answer comes from the:

Routing table

Run:

ip route

20. Example Routing Table

You might see something conceptually like:

default via 10.0.0.1 dev eth0
10.0.0.0/24 dev eth0

Meaning approximately:

10.0.0.0/24
 ↓
directly reachable through eth0

everything else
 ↓
default gateway

Your actual output will differ.

21. Default Gateway

The:

Default gateway

is the next-hop router used for destinations that don’t have a more specific route.

Conceptually:

Server
  ↓
Default gateway
  ↓
Other network
  ↓
Internet

22. Local vs Remote Destination

Suppose:

Server:
10.0.1.20

Destination:
10.0.1.50

If the routing configuration considers it directly connected:

Server
 ↓
local network
 ↓
10.0.1.50

But:

Server:
10.0.1.20

Destination:
8.8.8.8

may use:

Server
 ↓
default gateway
 ↓
Internet

23. MAC Address

IP is not the only addressing system.

Network interfaces also have:

MAC addresses

Example:

02:42:ac:11:00:02

A MAC address identifies a network interface at the local link layer.

The exact semantics in cloud virtual networking can be more abstract than physical Ethernet.

24. IP vs MAC

Simplified:

MAC
=
local network/link addressing

IP
=
network-layer addressing

Think:

IP
 ↓
Where is the destination network/device?

MAC
 ↓
Which local network interface should receive this frame?

25. ARP

For IPv4 local-network communication, systems traditionally use:

ARP — Address Resolution Protocol

to determine a link-layer address associated with an IPv4 address.

Conceptually:

IP address
   ↓
ARP
   ↓
MAC address

In cloud networks, the underlying implementation may involve virtualized networking mechanisms.

26. IPv6 Uses Neighbor Discovery

IPv6 doesn’t use ARP.

It uses:

Neighbor Discovery Protocol

which is built using ICMPv6.

Conceptually:

IPv6
 ↓
Neighbor Discovery
 ↓
Link-layer information

27. Packet

Data sent over a network is divided into units.

At the IP layer, we commonly talk about:

Packets

Conceptually:

Large data
 ↓
smaller packets
 ↓
network

Each packet contains addressing/control information and payload.

28. Packet Structure

At a simplified level:

┌───────────────────────────┐
│ IP header                 │
├───────────────────────────┤
│ TCP/UDP header            │
├───────────────────────────┤
│ Application data         │
└───────────────────────────┘

The exact encapsulation is more detailed.

29. Protocol Layers

A very useful mental model:

Application
     ↓
Transport
     ↓
Internet
     ↓
Link

Examples:

Application → HTTP / DNS / TLS
Transport   → TCP / UDP
Internet    → IP
Link        → Ethernet / virtual link

30. TCP

TCP is:

Transmission Control Protocol

It provides reliable, ordered byte-stream communication.

For HTTPS:

Browser
 ↓
TCP
 ↓
Server

TCP establishes a connection before application data is exchanged.

31. UDP

UDP is:

User Datagram Protocol

It provides a connectionless datagram transport with much less built-in reliability than TCP.

Examples of protocols/applications that can use UDP include:

DNS
QUIC
some streaming/real-time applications

32. TCP Port

A TCP port identifies an application/service endpoint on a host.

Examples:

22  → SSH
80  → HTTP
443 → HTTPS
3306 → MySQL commonly

Port numbers are part of TCP/UDP transport addressing.

33. IP + Port

A connection endpoint can conceptually be represented as:

IP address + port

Example:

203.0.113.50:443

This means:

IP:
203.0.113.50

Port:
443

34. Socket

A socket is an operating-system abstraction for network communication.

Conceptually:

Application
 ↓
Socket
 ↓
TCP/UDP
 ↓
IP

Nginx uses sockets to communicate with clients.

35. Nginx Listening on 443

When you have HTTPS working, Nginx is typically listening on:

TCP 443

Check:

sudo ss -lntp

You may see something like:

LISTEN
0.0.0.0:443

36. `0.0.0.0`

When a service listens on:

0.0.0.0:443

it means, conceptually:

Listen on port 443 on all IPv4 local interfaces.

It does not mean that 0.0.0.0 itself is a remote destination.

37. `127.0.0.1`

Compare:

127.0.0.1:443

This means the service is bound only to the local loopback interface.

External clients normally cannot directly reach it through the server’s external interface.

38. `[::]:443`

You may see:

[::]:443

This represents an IPv6 wildcard listener.

Whether it also accepts IPv4 connections depends on the operating system/socket configuration.

39. The Firewall

Now we reach a critical layer.

A packet can arrive at the cloud network, but still be blocked before Nginx sees it.

You may have multiple filtering layers:

Internet
 ↓
OCI network security rules
 ↓
Ubuntu firewall
 ↓
Nginx

40. Cloud Firewall

Oracle Cloud provides network security controls such as:

Security Lists
Network Security Groups

These can control traffic to/from VNICs.

The exact configuration depends on your OCI setup.

41. Ubuntu Firewall

Ubuntu may use:

UFW

as a user-friendly firewall interface.

Check:

sudo ufw status

If enabled, it can control local host traffic.

42. Firewall Rule

A simplified firewall rule might say:

Allow
TCP
443
from Internet

or:

Deny
TCP
3306
from Internet

43. Why MySQL Should Usually Be Protected

Your architecture should generally be:

Internet
   ↓
443
   ↓
Nginx
   ↓
PHP
   ↓
MySQL

rather than:

Internet
   ↓
3306
   ↓
MySQL

unless you have a specific need for remote database access and have secured it appropriately.

44. Port 80

HTTP traditionally uses:

TCP 80

HTTPS traditionally uses:

TCP 443

Your Nginx server may listen on both.

45. Why Keep Port 80?

Common reasons include:

HTTP → HTTPS redirect

and:

Let's Encrypt HTTP-01 validation

depending on your certificate configuration.

46. Port 443

Port 443 carries:

TLS

which protects application traffic such as HTTPS.

So:

TCP 443
 ↓
TLS
 ↓
HTTP

47. TCP Connection Establishment

Before ordinary HTTPS data is exchanged over TCP, TCP normally performs its connection-establishment handshake.

The simplified sequence is:

Client                    Server

SYN       ───────────────►
          ◄──────── SYN-ACK
ACK       ───────────────►

Then the TCP connection is established.

48. SYN

SYN is a TCP control flag used to initiate a connection.

Conceptually:

Client
 ↓
SYN
 ↓
Server

49. SYN-ACK

Server responds:

SYN + ACK

meaning roughly:

I received your request and I’m acknowledging it while synchronizing my sequence state.

50. ACK

Client sends:

ACK

The TCP connection is now established.

Then TLS can proceed for HTTPS.

51. TCP vs TLS

This distinction is extremely important.

TCP provides:

Reliable ordered byte stream

TLS provides:

Encryption
Authentication
Integrity protection

So:

HTTPS
=
HTTP
over TLS
over TCP
over IP

for traditional HTTPS over TCP.

52. HTTPS Request Stack

A simplified stack:

HTTP
 ↓
TLS
 ↓
TCP
 ↓
IP
 ↓
Link/network

This is one of the most important diagrams in web hosting.

53. DNS Comes Before This

When the browser sees:

templates.cresignsys.com

it needs to determine which IP address corresponds to the domain.

So:

Domain
 ↓
DNS
 ↓
IP address

Then networking begins toward that IP.

54. Complete HTTPS Journey

Now combine everything:

User Browser
      │
      ▼
templates.cresignsys.com
      │
      ▼
DNS
      │
      ▼
Public IP
      │
      ▼
Internet routing
      │
      ▼
Oracle Cloud
      │
      ▼
VCN
      │
      ▼
Subnet
      │
      ▼
VNIC
      │
      ▼
Security rules
      │
      ▼
Ubuntu
      │
      ▼
TCP :443
      │
      ▼
Nginx
      │
      ▼
TLS
      │
      ▼
HTTP

55. But There Is More

The packet does not simply travel:

Browser → VPS

There can be many routers between them.

Conceptually:

Browser
 ↓
Router
 ↓
ISP
 ↓
ISP backbone
 ↓
Internet exchange/transit
 ↓
Cloud provider network
 ↓
Oracle network
 ↓
VPS

The exact route changes over time.

56. `traceroute`

You can investigate routing paths with:

traceroute example.com

On some systems you may need to install it.

Another common tool:

tracepath example.com

The result shows network hops as observed from your system.

Not every hop will respond because routers may filter diagnostic traffic.

57. `ping`

Try:

ping example.com

Ping uses ICMP, not TCP.

Therefore:

A failed ping does not necessarily mean the website is down.

A firewall may simply block ICMP.

58. `curl`

For web testing, curl is much more relevant.

For example:

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

This sends an HTTP request and displays response headers.

59. `curl` and TLS

You can also use:

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

This can show details such as:

DNS resolution
TCP connection
TLS handshake
certificate
HTTP request
HTTP response

This is an excellent learning tool.

60. `ss`

On your server:

sudo ss -lntp

helps answer:

Which processes are listening on TCP ports?

You may find:

:22
:80
:443

and perhaps internal services.

61. Listening vs Established

ss can show:

LISTEN

and:

ESTAB

LISTEN

Waiting for incoming connections.

ESTAB

An established connection exists.

62. Example

Conceptually:

LISTEN
0.0.0.0:443
nginx

means:

Nginx
 ↓
waiting for HTTPS connections

An established connection might look conceptually like:

ESTAB
client-ip:random-port
server-ip:443

63. Ephemeral Ports

A client generally doesn’t use port 443 as its source port.

Instead it gets a temporary:

Ephemeral port

For example:

Client:
192.168.1.20:53142

Server:
203.0.113.50:443

The connection is identified by multiple pieces of information.

64. The TCP 4-Tuple

A TCP connection is commonly identified by:

Source IP
Source port
Destination IP
Destination port

For example:

192.168.1.20
53142
203.0.113.50
443

This allows many simultaneous clients to connect to the same server port.

65. How 10,000 Users Can Use Port 443

You might wonder:

If Nginx only listens on port 443, how can thousands of users connect?

Because each connection has different source information.

For example:

Client A: 10.0.0.10:50001 → Server:443
Client B: 10.0.0.11:50002 → Server:443
Client C: 10.0.0.12:50003 → Server:443

The server can distinguish the connections.

66. NAT

NAT means:

Network Address Translation

It allows addresses to be translated between networks.

For example, a home network might use:

192.168.1.x

internally while sharing one public IPv4 address.

Cloud networking can also involve address translation depending on the architecture.

67. Your Browser Doesn’t Know Your VPS’s Private IP

A public website generally exposes a public-facing address.

The cloud networking layer may translate or route traffic to the VM’s private address/interface.

Conceptually:

Public IP
   ↓
Cloud networking
   ↓
Private IP/VNIC
   ↓
VM

The exact OCI public/private IP implementation depends on the resource configuration.

68. VNIC

Your Oracle Cloud VM has a:

Virtual Network Interface Card

or:

VNIC

Conceptually:

VM
 │
 └── VNIC
      ├── Private IP
      ├── MAC address
      └── network connectivity

The VNIC connects the VM to the VCN/subnet.

69. The Cloud Network Is Virtual

There may not be a physical Ethernet cable directly connected to your VPS.

Instead:

Physical infrastructure
       ↓
Virtualization
       ↓
Virtual network
       ↓
VNIC
       ↓
VM

The cloud provider manages the underlying hardware and virtualization.

70. Packet Arrives at the VM

Eventually the packet reaches the VM’s virtual network interface.

Then:

VNIC
 ↓
Linux network driver
 ↓
Linux networking stack
 ↓
TCP
 ↓
socket
 ↓
Nginx

This is the critical internal journey.

71. Linux Network Stack

Inside Ubuntu:

Network interface
       ↓
Network driver
       ↓
Link layer
       ↓
IP layer
       ↓
TCP layer
       ↓
Socket
       ↓
Nginx

This is a simplified representation.

72. Nginx Doesn’t Read Raw Ethernet Directly

Nginx works through operating-system networking abstractions.

Conceptually:

Physical/virtual network
 ↓
Linux kernel
 ↓
TCP socket
 ↓
Nginx

The kernel handles much of the lower-level networking.

73. Socket Binding

When Nginx starts, it binds/listens on an address and port.

Conceptually:

Nginx
 ↓
bind()
 ↓
0.0.0.0:443
 ↓
listen()

Then it waits for connections.

74. Accept

When a client connects:

Nginx
 ↓
accept()
 ↓
connection socket

The listening socket and the individual connection socket are distinct concepts.

75. Two Socket Roles

Conceptually:

Listening socket
        │
        ▼
Incoming connection
        │
        ▼
Connection socket

Nginx can then process the individual client connection.

76. Nginx Worker

The connection is handled by Nginx’s worker/event architecture.

Conceptually:

Listening
   ↓
Connection
   ↓
Worker
   ↓
TLS
   ↓
HTTP

77. TLS Begins After TCP

For traditional HTTPS over TCP:

TCP handshake
       ↓
TLS handshake
       ↓
HTTP request

This ordering is fundamental.

78. TLS Handshake

At a simplified level:

Client
   ↓
ClientHello
   ↓
ServerHello
   ↓
Certificate
   ↓
Key exchange
   ↓
Handshake completion

The actual TLS 1.3 handshake is more precise and efficient than this simplified sequence.

79. Certificate

Your Let’s Encrypt certificate contains information that allows the browser to authenticate the server’s domain identity through the certificate chain and validation process.

For:

templates.cresignsys.com

Nginx uses the certificate and private key configured for that site.

80. Private Key

Your certificate has a corresponding private key.

Conceptually:

Certificate
+
Private key

The private key must remain secret.

This is why it lives under a protected system path such as:

/etc/letsencrypt/

rather than the public website directory.

81. Encryption Keys

TLS ultimately establishes symmetric encryption keys for the session.

Conceptually:

Handshake
 ↓
key agreement
 ↓
session keys
 ↓
encrypted application data

The exact cryptographic details depend on the TLS version and cipher suite.

82. Encrypted HTTP

After TLS is established:

HTTP request
 ↓
TLS encryption
 ↓
TCP
 ↓
IP
 ↓
Internet

An observer on the network generally cannot read the HTTP contents without the appropriate session keys.

83. Nginx Decrypts TLS

On your server:

Encrypted TLS data
       ↓
Nginx TLS implementation
       ↓
Decrypted HTTP request
       ↓
Nginx routing

Nginx then decides whether the request is:

Static

or:

PHP/WordPress

84. Complete Request

For:

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

the conceptual process is:

1. DNS lookup
       ↓
2. TCP connection to :443
       ↓
3. TLS handshake
       ↓
4. HTTP GET /about/
       ↓
5. Nginx receives request
       ↓
6. Nginx checks configuration
       ↓
7. PHP-FPM if necessary
       ↓
8. WordPress
       ↓
9. MySQL
       ↓
10. HTML response
       ↓
11. Nginx
       ↓
12. TLS encryption
       ↓
13. TCP
       ↓
14. Browser

85. The Full Hosting Architecture

You can now combine nearly everything learned so far:

                         INTERNET
                            │
                            ▼
                           DNS
                            │
                            ▼
                       PUBLIC IP
                            │
                            ▼
                     ORACLE CLOUD VCN
                            │
                         SUBNET
                            │
                           VNIC
                            │
                     SECURITY RULES
                            │
                            ▼
                         UBUNTU
                            │
                    ┌───────┴────────┐
                    ▼                ▼
                 Network           Kernel
                    │                │
                    ▼                ▼
                  TCP             Processes
                    │                │
                    ▼        ┌───────┼────────┐
                  Socket      ▼       ▼        ▼
                    │       Nginx   PHP-FPM  MySQL
                    │         │       │        │
                    └─────────┴───────┴────────┘
                                      │
                                   WordPress
                                      │
                           ┌──────────┴─────────┐
                           ▼                    ▼
                      Filesystem             Database
                           │                    │
                           ▼                    ▼
                      /storage              MySQL data

86. Important Commands

Interfaces

ip addr

Routing

ip route

Listening ports

sudo ss -lntp

Connections

sudo ss -ntp

Firewall

sudo ufw status

DNS

dig templates.cresignsys.com

If dig isn’t installed:

sudo apt install dnsutils

HTTPS

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

87. A Very Important Diagnostic Sequence

When a website doesn’t open, don’t randomly change configurations.

Think through the layers:

1. DNS?
   ↓
2. Public IP?
   ↓
3. Cloud security rule?
   ↓
4. Ubuntu firewall?
   ↓
5. Nginx listening?
   ↓
6. TCP connection?
   ↓
7. TLS certificate/configuration?
   ↓
8. Nginx server block?
   ↓
9. PHP-FPM?
   ↓
10. WordPress?
   ↓
11. MySQL?

This layered approach is one of the most valuable server-administration skills.

88. Example: DNS Problem

If:

DNS
 ↓
wrong IP

then:

Browser
 ↓
wrong server

Nginx on your VPS may be completely healthy.

89. Example: Port 443 Blocked

Suppose:

DNS → correct
Nginx → running
TLS → correct

but:

OCI security rule
 ↓
TCP 443 blocked

Then the browser cannot establish the connection.

90. Example: Nginx Not Listening

Suppose:

Cloud firewall → OK
Ubuntu firewall → OK

but:

Nginx
 ↓
not listening on 443

Then the connection can still fail.

Check:

sudo ss -lntp

91. Example: PHP Problem

Suppose HTTPS works:

Browser
 ↓
TLS
 ↓
Nginx

but WordPress produces:

502 Bad Gateway

Then investigate:

Nginx
 ↓
PHP-FPM

rather than immediately blaming DNS or TLS.

92. Example: Database Problem

Suppose:

HTTPS works
Nginx works
PHP works

but WordPress says it cannot connect to the database.

Then investigate:

PHP
 ↓
MySQL

This is why layered troubleshooting is so powerful.

93. The Deepest Concept From This Lesson

A web request is not one operation.

It is a chain:

Name resolution
 ↓
Routing
 ↓
Network delivery
 ↓
Firewall
 ↓
TCP
 ↓
TLS
 ↓
HTTP
 ↓
Web server
 ↓
Application
 ↓
Database
 ↓
Filesystem

Every layer has its own job.

Lesson 035 Summary

The most important chain to memorize is:

Domain
 ↓
DNS
 ↓
Public IP
 ↓
Internet
 ↓
Cloud VCN
 ↓
Subnet
 ↓
VNIC
 ↓
Security rules
 ↓
Ubuntu
 ↓
Network interface
 ↓
IP
 ↓
TCP
 ↓
Port 443
 ↓
Socket
 ↓
Nginx
 ↓
TLS
 ↓
HTTP
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL / Filesystem

Practical commands

ip addr
ip route
sudo ss -lntp
sudo ss -ntp
sudo ufw status
dig templates.cresignsys.com
curl -v https://templates.cresignsys.com

Next Lesson — 036

DNS — From Domain Name to Your VPS

We will go deeper into:

Domain
 ↓
Registrar
 ↓
Nameserver
 ↓
DNS Zone
 ↓
A record
 ↓
AAAA record
 ↓
CNAME
 ↓
MX
 ↓
TXT
 ↓
DNS resolver
 ↓
Recursive lookup
 ↓
Authoritative nameserver
 ↓
TTL
 ↓
Caching
 ↓
Your Oracle Cloud public IP

Then we will trace exactly how templates.cresignsys.com becomes the IP address of your VPS before the HTTPS connection even begins.

CresignSys Learn — Lesson 035

Linux Networking — From Internet to Your Nginx Process

1. Start With the Complete Journey

2. What Is a Network?

3. The Internet

Network of networks

4. Network Interface

5. lo

Loopback

6. Loopback Example

7. Network Interface and IP Address

8. What Is an IP Address?

9. IPv4

10. IPv6

11. Public IP vs Private IP

Private IP

Public IP

12. Your Oracle Cloud VPS

13. VCN

VCN — Virtual Cloud Network

14. Subnet

15. CIDR

CIDR notation

16. /24

17. Example Subnet

18. Why Subnets Matter

19. Routing

Routing table

20. Example Routing Table

21. Default Gateway

Default gateway

22. Local vs Remote Destination

23. MAC Address

MAC addresses

24. IP vs MAC

25. ARP

ARP — Address Resolution Protocol

26. IPv6 Uses Neighbor Discovery

Neighbor Discovery Protocol

27. Packet

Packets

28. Packet Structure

29. Protocol Layers

30. TCP

Transmission Control Protocol

31. UDP

User Datagram Protocol

32. TCP Port

33. IP + Port

34. Socket

35. Nginx Listening on 443

36. 0.0.0.0

37. 127.0.0.1

38. [::]:443

39. The Firewall

40. Cloud Firewall

41. Ubuntu Firewall

UFW

42. Firewall Rule

43. Why MySQL Should Usually Be Protected

44. Port 80

45. Why Keep Port 80?

46. Port 443

47. TCP Connection Establishment

48. SYN

49. SYN-ACK

50. ACK

51. TCP vs TLS

52. HTTPS Request Stack

53. DNS Comes Before This

54. Complete HTTPS Journey

55. But There Is More

56. traceroute

57. ping

58. curl

59. curl and TLS

60. ss

61. Listening vs Established

LISTEN

ESTAB

5. `lo`

16. `/24`

36. `0.0.0.0`

37. `127.0.0.1`

38. `[::]:443`

56. `traceroute`

57. `ping`

58. `curl`

59. `curl` and TLS

60. `ss`