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:

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.

CresignSys Learn — Lesson 023

Course: From Basic Science to Web Hosting

Module 05 — Networking Fundamentals

TCP From the Deepest Basics

1. The Problem TCP Solves

2. IP Alone Is Not Enough

3. TCP’s Main Responsibilities

4. TCP Is a Transport Protocol

5. TCP Does Not Know About Your Website

6. Bytes

7. Byte Stream

Ordered byte stream

8. TCP Uses Segments

TCP Segments

9. TCP Header

10. Source Port

Ephemeral ports

11. Destination Port

12. IP + Port

13. What Is a Socket?

14. Listening

15. What Does LISTEN Mean?

16. The TCP Connection

Three-Way Handshake

17. SYN

18. SYN-ACK

19. ACK

20. Why Three Messages?

21. Sequence Numbers

22. Why Sequence Numbers?

23. Acknowledgment Numbers

24. Lost Data

25. Why Retransmission?

26. TCP Does Not Make the Physical Network Perfect

27. Flow Control

Receive Window

28. Receiver Window

29. Congestion Control

Congestion Control

30. Flow Control vs Congestion Control

31. What Is RTT?

Round-Trip Time

32. Why RTT Matters

33. TCP Connection States

34. ESTABLISHED

35. TCP Is Before TLS

36. Your Website Example

37. Step 1 — DNS

38. Step 2 — TCP Destination

39. Step 3 — SYN

40. Step 4 — SYN-ACK

41. Step 5 — ACK

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

43. TLS Uses TCP

44. TLS Handshake

45. Then HTTP

46. Nginx Does Not Receive “Raw Internet”

47. Nginx’s Listening Socket

48. bind()

49. listen()

50. accept()

51. One Nginx Server, Many Connections

52. TCP Four-Tuple

53. Why Can Thousands of Clients Use Port 443?

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

55. TCP Connection Termination

56. FIN

57. RST

RST — Reset

58. TIME-WAIT

59. Inspect TCP on Your Server

60. See Listening TCP Ports

61. See HTTPS Connections

62. Test Port 443

63. Important Troubleshooting Layers

64. Example: Port 443 Closed

65. Example: TCP Works, TLS Fails

66. Example: TLS Works, HTTP Fails

67. The Complete Architecture

68. The Deepest Chain So Far

15. What Does `LISTEN` Mean?

48. `bind()`

49. `listen()`

50. `accept()`

What is `ESTABLISHED`?

What is `LISTEN`?