TCP/IP From the Absolute Basics

We now go one level deeper into the network.

You already know:

Browser
 ↓
DNS
 ↓
IP
 ↓
Internet
 ↓
VPS
 ↓
Port 443
 ↓
Nginx

But what actually happens when your browser connects to:

learn.cresignsys.com:443

The key technology is:

TCP

1. What Is TCP?

TCP means:

Transmission Control Protocol

TCP provides reliable, ordered communication between applications over an IP network.

Think:

Application
     ↓
    TCP
     ↓
     IP
     ↓
 Network

2. IP vs TCP

These two solve different problems.

IP

Answers:

Where should this packet go?

TCP

Answers:

How can two applications communicate reliably?

So:

IP
=
addressing + routing

TCP
=
reliable transport

3. Simple Example

Suppose:

Your computer
IP = A

VPS
IP = B

You want:

A → B

IP provides the addressing.

TCP provides the connection between applications.

4. Port Numbers

Suppose your VPS has:

IP:
203.0.113.25

and Nginx listens on:

The destination becomes:

203.0.113.25:443

This identifies the destination network endpoint.

5. TCP Connection

TCP is connection-oriented.

Before normal application data is exchanged, TCP establishes a connection.

The classic process is called:

Three-Way Handshake

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

Then application data can flow.

6. SYN

SYN means:

Synchronize

The client essentially says:

I want to establish a TCP connection.

Conceptually:

Client → Server
SYN

7. SYN-ACK

The server responds:

Server → Client
SYN + ACK

Meaning approximately:

I received your connection request, and I also want to establish the connection.

8. ACK

The client responds:

Client → Server
ACK

Now the TCP connection is established.

9. Complete Handshake

Client                         Server
  │                              │
  │ -------- SYN -------------> │
  │                              │
  │ <------ SYN + ACK ---------- │
  │                              │
  │ -------- ACK -------------> │
  │                              │
  │       CONNECTION READY       │
  │                              │

10. Why Three Messages?

TCP needs both sides to establish that communication parameters can be synchronized.

It isn’t simply:

Client → Hello
Server → Okay

TCP establishes state on both endpoints.

11. TCP Is Stateful

TCP maintains connection state.

For example:

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

These states help TCP manage connections correctly.

12. Server Listening

Before your browser connects:

Nginx
 ↓
TCP port 443
 ↓
LISTEN

Nginx has a listening socket.

You can inspect it:

sudo ss -ltnp

13. Client Connects

Browser:

Client
 ↓
destination:
server-ip:443

The operating system sends a TCP SYN.

14. Server Receives SYN

The server’s networking stack receives it.

If:

port 443

is open and a service is listening:

SYN
 ↓
TCP stack
 ↓
Nginx socket

The server can respond.

15. What If Port 443 Is Blocked?

Suppose OCI security rules block:

TCP 443

Then the TCP handshake cannot complete normally.

The request may appear to:

timeout

rather than reaching Nginx.

16. What If Nothing Is Listening?

Suppose:

OCI allows 443
Ubuntu firewall allows 443

but:

Nginx
 ↓
not listening

The behavior may be different from a silent firewall drop; the host can reject the connection with TCP RST.

This distinction is useful during troubleshooting.

17. Timeout vs Refused

A simplified distinction:

Timeout

Often indicates:

packet dropped
firewall
routing problem
network problem

Connection refused

Often indicates:

host reachable
but no service accepting that port

These are clues, not absolute diagnoses.

18. TCP Data

Once connected:

Client
   ↔
Server

data can flow in both directions.

For HTTPS:

Browser
   ↔
Nginx

19. TCP Segmentation

Applications don’t necessarily send one giant network message.

Large data can be divided into smaller TCP segments.

Conceptually:

Application data
 ↓
TCP
 ↓
Segment 1
Segment 2
Segment 3
Segment 4

20. Sequence Numbers

TCP uses:

Sequence Numbers

They help TCP track the ordering of transmitted data.

Imagine:

Segment A
Segment B
Segment C

If they arrive out of order:

C
A
B

TCP can use sequence information to reconstruct the correct byte stream.

21. TCP Provides an Ordered Byte Stream

Applications generally see:

A B C D E F

rather than worrying about individual IP packets.

TCP handles much of the ordering and reliability underneath.

22. Acknowledgements

The receiver acknowledges received data.

Conceptually:

Sender
  │
  │ data
  ▼
Receiver
  │
  │ ACK
  ▼
Sender

The acknowledgement tells the sender what data has been received successfully.

23. Lost Packet

Suppose:

Segment 1 ✓
Segment 2 ✗
Segment 3 ✓

TCP detects that something is missing through sequence/acknowledgement mechanisms.

It can retransmit the missing data.

24. Retransmission

Conceptually:

Sender
 ↓
Segment 2
 ↓
LOST

Then:

Sender
 ↓
Segment 2 again
 ↓
Receiver

This is one reason TCP is called reliable.

25. TCP Is Not Magic

Retransmission has a cost.

If packets are repeatedly lost:

packet loss
 ↓
retransmission
 ↓
waiting
 ↓
slower transfer

So network quality affects performance.

26. Latency

Latency means delay.

For example:

Client → Server

might take:

20 ms

while another server might take:

200 ms

Latency affects interactive applications.

27. RTT

RTT means:

Round-Trip Time

It measures approximately how long it takes for a signal to travel from one endpoint to the other and back.

Example:

Client
 ↓ 20 ms
Server
 ↓ 20 ms
Client

RTT ≈:

40 ms

Actual measurement depends on conditions and tooling.

28. Why RTT Matters for Websites

Suppose a page requires many sequential network interactions.

Higher RTT can increase total waiting time.

Modern browsers and HTTP protocols reduce this through:

connection reuse
parallelism
multiplexing
caching

but latency still matters.

29. Bandwidth

Bandwidth is different from latency.

Bandwidth is roughly:

How much data can be transferred per unit time.

For example:

100 Mbps
1 Gbps
10 Gbps

30. Latency vs Bandwidth

Think:

Latency
=
How long does it take to get there?

Bandwidth
=
How much can we transfer per second?

A connection can have:

high bandwidth
+
high latency

or:

low bandwidth
+
low latency

They are different characteristics.

31. Packet Loss

Suppose:

100 packets sent

and:

5 packets lost

Packet loss =:

5%

TCP may retransmit lost data.

But high packet loss can significantly hurt performance.

32. Congestion

Imagine many users send traffic through the same network path.

Users
 │
 ├── Traffic
 ├── Traffic
 ├── Traffic
 └── Traffic
        ↓
    Network link

If the link becomes congested:

queues
 ↓
delay
 ↓
packet loss
 ↓
TCP adaptation

33. TCP Congestion Control

TCP has mechanisms that adjust sending behavior based on network conditions.

The broad goal is:

Avoid overwhelming the network.

Modern TCP implementations use sophisticated algorithms.

34. Slow Start

A TCP connection doesn’t normally begin by sending at the maximum possible rate immediately.

It starts cautiously and increases its sending rate as conditions allow.

This is commonly associated with:

Slow Start

35. Why Slow Start?

Imagine a new connection immediately sending enormous amounts of traffic.

If the network path can’t handle it:

congestion
 ↓
packet loss
 ↓
retransmission
 ↓
worse congestion

Slow start helps discover available capacity.

36. Congestion Window

TCP maintains concepts such as:

Congestion Window (`cwnd`)

This influences how much unacknowledged data can be in flight.

Simplified:

small cwnd
 ↓
careful sending
 ↓
network appears healthy
 ↓
increase

37. Receive Window

TCP also has:

Receive Window

This relates to how much data the receiver is currently prepared to accept.

So TCP has to consider both:

network capacity
+
receiver capacity

38. Flow Control

Flow control prevents a fast sender from overwhelming a slower receiver.

Imagine:

Sender
 ↓↓↓↓↓↓↓↓↓
Receiver

If the receiver cannot process data quickly enough, TCP’s flow-control mechanisms help regulate transmission.

39. Congestion Control vs Flow Control

Memorize:

Flow control
=
protect receiver

Congestion control
=
protect network

They are different problems.

40. TCP Ports

A TCP connection is identified by endpoint information.

Conceptually:

Client IP
Client Port
Server IP
Server Port
Protocol

The combination is often described as a:

5-tuple

For example:

TCP
192.0.2.10:53124
203.0.113.25:443

41. Why Client Ports Are Random-Looking

Your browser doesn’t normally use port 443 as its local port.

Instead it may use an ephemeral port such as:

So:

Client
192.0.2.10:53124
        ↓
Server
203.0.113.25:443

42. Server Port

The server uses a well-known/service port:

Nginx listens there.

43. Client Ephemeral Port

The operating system chooses an available temporary port:

This allows many simultaneous connections.

For example:

Client:53124 → Server:443
Client:53125 → Server:443
Client:53126 → Server:443

44. Multiple Users

Thousands of users can connect to the same:

server:443

because their source addresses and/or source ports differ.

Conceptually:

User A :50001 → Server :443
User B :50002 → Server :443
User C :50003 → Server :443

45. TCP Connection State

Your server can have many connections:

sudo ss -tan

You may see:

ESTAB
LISTEN
TIME-WAIT
SYN-SENT

46. `ESTABLISHED`

Means a TCP connection is established.

Example:

ESTAB
client:53124
server:443

Data can flow.

47. `LISTEN`

Means a server socket is waiting for incoming connections.

Example:

LISTEN
0.0.0.0:443

Nginx can accept incoming connections there.

48. `SYN-SENT`

A client has sent a SYN and is waiting for the response.

Conceptually:

Client
 ↓
SYN
 ↓
waiting

49. `SYN-RECV`

The server has received a SYN and is in the process of completing the handshake.

50. TCP Connection Closing

TCP also needs to close connections properly.

A simplified closing sequence involves:

FIN
ACK
FIN
ACK

The exact sequence depends on which side initiates closure and the connection state.

51. FIN

FIN means approximately:

I have finished sending data.

Conceptually:

Client → Server
FIN

52. ACK

The other side acknowledges:

Server → Client
ACK

The remaining direction can then close separately.

This is why TCP is full-duplex.

53. Full-Duplex

TCP allows both sides to send data independently.

Client
 ↑     ↓
 │     │
 TCP connection
 │     │
 ↓     ↑
Server

54. TIME_WAIT

After a TCP connection closes, one side may enter:

TIME_WAIT

This is normal TCP behavior.

You may see many:

TIME-WAIT

connections on a busy web server.

55. Why TIME_WAIT Exists

It helps ensure delayed packets from an old connection don’t interfere with a later connection using the same endpoint combination.

It also allows the final connection termination process to complete safely.

56. Don’t Automatically Treat TIME_WAIT as an Error

Seeing:

1000 TIME-WAIT

doesn’t automatically mean the server is broken.

It can simply indicate many short-lived TCP connections.

57. HTTP/1.1

Traditional HTTP/1.1 can reuse TCP connections through:

Keep-Alive

Instead of:

Request
 ↓
TCP connection
 ↓
close

Request
 ↓
new TCP connection

the browser can reuse a connection:

TCP connection
 ↓
Request 1
 ↓
Request 2
 ↓
Request 3
 ↓
...

This reduces connection setup overhead.

58. HTTP/2

HTTP/2 goes further.

It can multiplex multiple streams over a single TCP connection.

Conceptually:

One TCP connection
│
├── Stream 1
├── Stream 2
├── Stream 3
└── Stream 4

This reduces the need for many separate connections.

59. HTTP/3

HTTP/3 changes the transport layer.

Instead of TCP:

HTTP/3
 ↓
QUIC
 ↓
UDP

QUIC provides transport features above UDP.

60. TCP vs UDP

TCP:

Connection-oriented
Reliable
Ordered
Retransmission
Flow control
Congestion control

UDP:

Connectionless datagram transport
No built-in TCP-style reliability
No built-in ordering
Lower protocol overhead

UDP does not mean “unreliable network” in the broader sense; it means the transport protocol itself does not provide TCP’s reliability mechanisms.

61. Why Does HTTP/3 Use UDP?

QUIC implements modern transport features in user space over UDP.

This allows:

HTTP/3
 ↓
QUIC
 ↓
UDP

with features such as:

encryption
multiplexing
connection migration
reliability

62. But Your Current Website May Use TCP

When you see:

HTTPS

it doesn’t automatically tell you whether the connection uses HTTP/1.1, HTTP/2, or HTTP/3.

For HTTP/1.1 and HTTP/2:

HTTP
 ↓
TCP

For HTTP/3:

HTTP
 ↓
QUIC
 ↓
UDP

63. TCP and TLS

For traditional HTTPS:

TCP
 ↓
TLS
 ↓
HTTP

The order is conceptually:

IP
 ↓
TCP
 ↓
TLS
 ↓
HTTP

64. TCP Handshake Before TLS

For a traditional TCP-based HTTPS connection:

TCP handshake
      ↓
TLS handshake
      ↓
HTTP request

So there are multiple negotiation stages.

65. Complete HTTPS Connection

Simplified:

Browser
   │
   │ TCP SYN
   ▼
Server
   │
   │ SYN-ACK
   ▼
Browser
   │
   │ ACK
   ▼
TCP established
   │
   ▼
TLS handshake
   │
   ▼
Encrypted connection
   │
   ▼
HTTP request

66. Why This Matters

When debugging:

HTTPS doesn't work

you need to determine:

TCP failure?
TLS failure?
HTTP failure?
Application failure?

These are different problems.

67. Example: TCP Failure

443 blocked

Result:

TLS never starts

because TCP hasn’t been established.

68. Example: TLS Failure

Suppose:

TCP 443 ✓
TLS ✗

Possible causes:

certificate problem
TLS configuration
protocol incompatibility
SNI/configuration issue

69. Example: HTTP Failure

Suppose:

TCP ✓
TLS ✓
HTTP ✓

but response is:

500 Internal Server Error

Now the network works.

The problem is higher in the application/server stack.

70. Example: WordPress Failure

TCP ✓
TLS ✓
HTTP ✓
Nginx ✓
PHP-FPM ✓
WordPress ✗

You might get:

or a WordPress-specific error page.

71. TCP Testing

A useful test:

nc -vz example.com 443

If successful, you know the TCP port is reachable.

But this doesn’t prove:

TLS works
HTTP works
WordPress works

It only tests the TCP connection at a basic level.

72. `curl -v`

For deeper HTTPS debugging:

curl -v https://example.com/

This can show stages of the connection, including:

DNS resolution
TCP connection
TLS handshake
HTTP request
HTTP response

73. Very Useful Command

Try:

curl -Iv https://example.com/

This combines:

-I

headers only, and:

-v

verbose diagnostics.

74. Local Server Test

On the VPS:

curl -I http://127.0.0.1

This tests the local web server.

If it works:

Nginx is responding locally

but external access fails:

look at networking/firewall/cloud rules

75. Binding Address Matters

Suppose Nginx listens on:

127.0.0.1:443

Then only local connections can normally reach that socket.

If it listens on:

0.0.0.0:443

it can accept IPv4 connections on the configured interfaces.

This is a major troubleshooting clue.

76. Check Nginx Listening Address

Run:

sudo ss -ltnp | grep ':443'

Look at the local address.

For example:

0.0.0.0:443

versus:

127.0.0.1:443

They mean very different things.

77. TCP and Your Hosting Platform

When you create a website automatically, your platform needs to make sure:

DNS
 ↓
public IP
 ↓
TCP 80/443
 ↓
Nginx
 ↓
website

is correctly configured.

78. Hosting Automation

Your future hosting script might perform:

Create website
       ↓
Create directory
       ↓
Create Nginx config
       ↓
Enable config
       ↓
Reload Nginx
       ↓
Install SSL
       ↓
Verify port 443
       ↓
Test HTTPS

A good automation script should verify each stage.

79. Don’t Assume

For example, after:

sudo systemctl reload nginx

don’t assume:

website works

Instead test:

sudo nginx -t
sudo ss -ltnp | grep ':443'
curl -I https://example.com

80. Network Troubleshooting Tree

If website doesn’t load:

DNS?
 │
 ├── NO → fix DNS
 │
 └── YES
       ↓
TCP 443?
 │
 ├── NO → routing/firewall/listener
 │
 └── YES
       ↓
TLS?
 │
 ├── NO → certificate/TLS config
 │
 └── YES
       ↓
HTTP?
 │
 ├── NO → Nginx/application
 │
 └── YES
       ↓
WordPress?
 │
 ├── NO → PHP/database/application
 │
 └── YES → working

81. Deep Mental Model

You should now visualize:

APPLICATION
    │
    ▼
   HTTP
    │
    ▼
   TLS
    │
    ▼
   TCP
    │
    ▼
    IP
    │
    ▼
 Network Interface
    │
    ▼
   Internet

On the receiving side:

Internet
   │
   ▼
Network Interface
   │
   ▼
IP
   │
   ▼
TCP
   │
   ▼
TLS
   │
   ▼
HTTP
   │
   ▼
Nginx

82. One Critical Principle

Each layer has a different job.

DNS
=
name → address

IP
=
routing/addressing

TCP
=
reliable transport

TLS
=
encryption/authentication

HTTP
=
web application protocol

Nginx
=
web server

Do not mix them together.

83. The Full CresignSys Hosting Stack

You now have:

                    DOMAIN
                       │
                       ▼
                      DNS
                       │
                       ▼
                 PUBLIC IP
                       │
                       ▼
                 INTERNET ROUTING
                       │
                       ▼
                  OCI VCN
                       │
                       ▼
                    SUBNET
                       │
                       ▼
                     VNIC
                       │
                       ▼
                    UBUNTU
                       │
              ┌────────┴────────┐
              ▼                 ▼
           FIREWALL          SERVICES
                                │
                                ▼
                              NGINX
                                │
                               TLS
                                │
                               HTTP
                                │
                           PHP-FPM
                                │
                            WORDPRESS
                                │
                             MySQL
                                │
                             InnoDB
                                │
                              DISK

This is becoming your complete server mental model.

84. Commands to Practice

Run these on your Ubuntu VPS.

Network interfaces

ip addr

Routing

ip route

Listening ports

sudo ss -ltnp

All TCP connections

sudo ss -tan

DNS

dig +short yourdomain.com

HTTP

curl -I http://yourdomain.com

HTTPS

curl -Iv https://yourdomain.com

Firewall

sudo ufw status

Nginx

sudo nginx -t

85. What You Should Understand Now

You should be able to explain:

What happens when someone opens your website?

DNS
 ↓
IP
 ↓
TCP
 ↓
TLS
 ↓
HTTP
 ↓
Nginx

What happens after Nginx receives a PHP request?

Nginx
 ↓
FastCGI
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL

Where does the network stop?

Internet
 ↓
VNIC
 ↓
Ubuntu

Where does application processing begin?

Nginx
 ↓
PHP-FPM
 ↓
WordPress

Lesson 048 Summary

The essential concepts:

TCP
=
reliable transport protocol

SYN
=
request to establish TCP connection

SYN-ACK
=
server response to SYN

ACK
=
acknowledgement

Sequence number
=
helps maintain byte ordering

Retransmission
=
resends missing data

RTT
=
round-trip time

Latency
=
delay

Bandwidth
=
transfer capacity

Flow control
=
protect receiver

Congestion control
=
manage network congestion

Port
=
service endpoint

Socket
=
communication endpoint

LISTEN
=
waiting for connections

ESTABLISHED
=
active TCP connection

TIME_WAIT
=
normal post-connection TCP state

The most important flow to memorize:

DNS
 ↓
IP
 ↓
TCP
 ↓
TLS
 ↓
HTTP
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL

Next Lesson — 049

TLS/HTTPS From the Absolute Basics

We will go inside the part between TCP and HTTP:

TCP
 ↓
TLS
 ↓
HTTPS

and learn:

What is encryption?
What is a certificate?
What is a private key?
What is a public key?
What is a CA?
What is Let's Encrypt?
What is a certificate chain?
What is TLS handshake?
What is SNI?
Why does Nginx need SSL configuration?
Why does a certificate work for one domain but not another?

Then we will connect it directly to your Let’s Encrypt + Nginx + multiple-domain hosting setup.

CresignSys Learn — Lesson 048

TCP/IP From the Absolute Basics

TCP

1. What Is TCP?

Transmission Control Protocol

2. IP vs TCP

IP

TCP

3. Simple Example

4. Port Numbers

5. TCP Connection

Three-Way Handshake

6. SYN

Synchronize

7. SYN-ACK

8. ACK

9. Complete Handshake

10. Why Three Messages?

11. TCP Is Stateful

12. Server Listening

13. Client Connects

14. Server Receives SYN

15. What If Port 443 Is Blocked?

16. What If Nothing Is Listening?

17. Timeout vs Refused

Timeout

Connection refused

18. TCP Data

19. TCP Segmentation

20. Sequence Numbers

Sequence Numbers

21. TCP Provides an Ordered Byte Stream

22. Acknowledgements

23. Lost Packet

24. Retransmission

25. TCP Is Not Magic

26. Latency

27. RTT

Round-Trip Time

28. Why RTT Matters for Websites

29. Bandwidth

30. Latency vs Bandwidth

31. Packet Loss

32. Congestion

33. TCP Congestion Control

34. Slow Start

Slow Start

35. Why Slow Start?

36. Congestion Window

Congestion Window (cwnd)

37. Receive Window

Receive Window

38. Flow Control

39. Congestion Control vs Flow Control

40. TCP Ports

5-tuple

41. Why Client Ports Are Random-Looking

42. Server Port

43. Client Ephemeral Port

44. Multiple Users

45. TCP Connection State

46. ESTABLISHED

47. LISTEN

48. SYN-SENT

49. SYN-RECV

50. TCP Connection Closing

51. FIN

52. ACK

53. Full-Duplex

54. TIME_WAIT

TIME_WAIT

55. Why TIME_WAIT Exists

56. Don’t Automatically Treat TIME_WAIT as an Error

57. HTTP/1.1

Keep-Alive

58. HTTP/2

59. HTTP/3

60. TCP vs UDP

61. Why Does HTTP/3 Use UDP?

62. But Your Current Website May Use TCP

Congestion Window (`cwnd`)

46. `ESTABLISHED`

47. `LISTEN`

48. `SYN-SENT`

49. `SYN-RECV`

72. `curl -v`