TCP — Deepest Basics

We now go one layer deeper.

Previously:

Domain
 ↓
DNS
 ↓
IP address
 ↓
TCP

Now we study exactly what TCP does.

1. What Is TCP?

TCP means:

Transmission Control Protocol

TCP is a transport-layer protocol.

Its job is to provide a reliable, ordered stream of bytes between applications.

For example:

Browser
   ↓
TCP connection
   ↓
Nginx

2. TCP Is Not HTTP

This distinction is essential.

HTTP
 ↓
uses TCP

HTTP describes:

What request and response are being exchanged.

TCP describes:

How a reliable byte stream is transported between two endpoints.

Therefore:

HTTPS
 ↓
HTTP
 ↓
TLS
 ↓
TCP
 ↓
IP

3. TCP Has No Idea What a Web Page Is

TCP does not understand:

WordPress
HTML
CSS
PHP
URL

TCP sees a stream of bytes.

Conceptually:

Application
     ↓
bytes
     ↓
TCP
     ↓
network

4. TCP Endpoint

A TCP endpoint can be thought of as:

IP address + TCP port

For example:

203.0.113.50:443

means:

IP   = 203.0.113.50
Port = 443

The IP identifies the network endpoint.

The port identifies the transport endpoint/application service.

5. Client and Server

For your website:

Browser
   ↓
Client

and:

Nginx
   ↓
Server

The client initiates the TCP connection.

The server listens for incoming connections.

6. Listening

Nginx may be listening on:

TCP :443

Check:

sudo ss -lntp

Conceptually:

Nginx
  ↓
LISTEN
  ↓
0.0.0.0:443

7. What Happens When the Browser Connects?

Suppose DNS returned:

203.0.113.50

The browser wants:

203.0.113.50:443

TCP begins the connection process.

8. TCP Three-Way Handshake

TCP traditionally establishes a connection using:

SYN
SYN-ACK
ACK

Diagram:

Client                         Server

  SYN  ───────────────────────►

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

  ACK  ───────────────────────►

This is the famous:

Three-way handshake

9. Why a Handshake?

TCP needs both sides to establish connection state.

It allows the endpoints to synchronize important sequence-number state and confirm that communication is possible.

10. SYN

SYN means the client is initiating a TCP connection.

Conceptually:

Client
  │
  │ SYN
  ▼
Server

The packet contains TCP control information, including an initial sequence number.

11. Sequence Number

TCP numbers bytes in its stream.

Imagine the client sends:

ABCDEFGH

TCP conceptually tracks where those bytes belong in the stream.

This allows TCP to:

Detect missing data
Reorder segments
Acknowledge received data

12. Initial Sequence Number

At connection establishment, each side chooses an initial sequence number.

For example, conceptually:

Client:
ISN = 1000

Server:
ISN = 5000

The actual values are not normally this predictable.

The important idea is:

Each direction has its own sequence-number space.

13. SYN-ACK

The server responds:

SYN + ACK

Conceptually:

Client
  │
  │ SYN, Seq=1000
  ▼
Server
  │
  │ SYN-ACK
  │ Seq=5000
  │ Ack=1001
  ▼
Client

Why Ack=1001?

Because the SYN consumes one sequence-number position.

14. ACK

The client responds:

ACK

Conceptually:

Client
  │
  │ ACK = 5001
  ▼
Server

Now both sides have established the TCP connection.

15. Then TLS Starts

For HTTPS over TCP:

TCP handshake
       ↓
TLS handshake
       ↓
HTTP

So:

SYN
 ↓
SYN-ACK
 ↓
ACK
 ↓
TLS ClientHello

16. TCP Connection Is a State Machine

TCP isn’t simply:

connected

or:

not connected

It has multiple states.

Examples:

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

17. LISTEN

A server waiting for connections is commonly in:

LISTEN

For example:

Nginx
 ↓
TCP :443
 ↓
LISTEN

18. SYN-SENT

The client sends SYN.

It enters a state conceptually associated with:

SYN-SENT

while waiting for the server’s response.

19. SYN-RECEIVED

The server receives SYN and sends SYN-ACK.

It can enter:

SYN-RECEIVED

while completing the handshake.

20. ESTABLISHED

After the handshake:

ESTABLISHED

means the TCP connection is established.

This is where most application data transfer occurs.

21. Check Established Connections

On your VPS:

sudo ss -ntp

You may see:

ESTAB

for active connections.

22. TCP Is a Byte Stream

This is a very important concept.

Suppose an application sends:

HELLO

then:

WORLD

TCP doesn’t preserve “HELLO” and “WORLD” as application messages.

It provides:

HELLOWORLD

as an ordered byte stream.

The application protocol determines message boundaries.

23. TCP Segments

TCP breaks the stream into transport segments.

Conceptually:

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

IP then carries these segments in packets.

24. TCP Segment

Simplified:

┌──────────────────────┐
│ TCP Header           │
├──────────────────────┤
│ Application Payload  │
└──────────────────────┘

The TCP header contains information such as:

Source port
Destination port
Sequence number
Acknowledgement number
Flags
Window
Checksum

plus additional fields/options.

25. IP Packet

TCP sits inside IP.

Conceptually:

┌─────────────────────────┐
│ IP Header               │
├─────────────────────────┤
│ TCP Header              │
├─────────────────────────┤
│ Data                    │
└─────────────────────────┘

This is called:

Encapsulation

26. Encapsulation

Each layer adds its own information.

Conceptually:

HTTP data
   ↓
TLS record/data
   ↓
TCP segment
   ↓
IP packet
   ↓
Link-layer frame

At the receiving side, the layers are processed in reverse.

27. Receiving Side

Conceptually:

Network frame
 ↓
IP
 ↓
TCP
 ↓
TLS
 ↓
HTTP
 ↓
Nginx

This is called:

Decapsulation

28. Acknowledgements

TCP uses acknowledgements to let the sender know what data has been received.

Conceptually:

Client
   │
   │ data
   ▼
Server
   │
   │ ACK
   ▼
Client

29. Lost Packet

Suppose:

Segment 1 ✓
Segment 2 ✗
Segment 3 ✓

The receiver can indicate what data it has successfully received.

The sender can then retransmit missing data.

This is one of the reasons TCP is reliable.

30. TCP Retransmission

Conceptually:

Sender
  │
  │ Segment 2
  X
  │
  │  lost
  │
  │ timeout / duplicate ACK mechanisms
  ▼
Retransmit Segment 2
  │
  ▼
Receiver

TCP has sophisticated mechanisms for detecting loss and retransmitting data.

31. Why TCP Is Reliable

TCP provides mechanisms for:

Ordering
Acknowledgement
Retransmission
Duplicate detection
Flow control
Congestion control

This does not mean TCP guarantees successful delivery under every circumstance. A connection can fail.

32. Ordering

Imagine packets arrive:

3
1
2

TCP can reconstruct the byte stream:

1
2
3

before delivering the appropriate ordered stream to the application.

33. Duplicate Data

Sometimes retransmission can cause duplicate segments to arrive.

TCP uses sequence numbers to recognize duplicate data.

Conceptually:

Sequence number
       ↓
"This byte range has already been received."

34. Flow Control

Suppose the server can process data slowly while the client sends very quickly.

The receiver needs a mechanism to tell the sender:

Don’t send more than I can currently handle.

This is:

Flow control

TCP uses a receive window for this purpose.

35. Receive Window

Conceptually:

Receiver
   ↓
"I can currently accept this much data."
   ↓
Sender

The advertised receive window helps prevent overwhelming the receiver’s available receive buffer.

36. Congestion Control

Flow control protects the receiver.

Congestion control protects the network.

These are different.

Flow control

Protect receiver

Congestion control

Avoid overwhelming the network

37. Why Congestion Control Matters

Imagine:

1 sender

sending moderately.

Then:

100,000 senders

all send as fast as possible.

The network could become congested.

TCP therefore adjusts sending behavior based on network conditions.

38. Congestion Window

TCP maintains a concept called:

Congestion window

Often abbreviated:

cwnd

It controls how much unacknowledged data can be in flight based on congestion-control state.

The algorithms are sophisticated.

39. Slow Start

One well-known TCP behavior is:

Slow Start

Despite the name, it can grow quickly.

Conceptually:

small sending window
        ↓
increase
        ↓
increase
        ↓
increase

until congestion or another limit is encountered.

40. TCP Is Not Always the Same

Different operating systems and TCP implementations can use different congestion-control algorithms.

Examples include:

CUBIC
BBR

Linux supports configurable congestion-control algorithms.

41. Check TCP Congestion Control

On Linux, you can inspect the configured algorithm with:

sysctl net.ipv4.tcp_congestion_control

You may see something such as:

cubic

The exact value depends on your system.

42. TCP Buffering

TCP uses buffers.

Conceptually:

Application
 ↓
send buffer
 ↓
TCP
 ↓
network
 ↓
TCP
 ↓
receive buffer
 ↓
Application

This allows the application and network to operate somewhat independently.

43. TCP Send Buffer

Nginx may write data to a socket.

The kernel manages sending that data through TCP.

Conceptually:

Nginx
 ↓
socket
 ↓
TCP send buffer
 ↓
network

Nginx doesn’t manually construct every Ethernet frame.

44. TCP Receive Buffer

Similarly:

network
 ↓
TCP
 ↓
receive buffer
 ↓
Nginx

The kernel manages much of this process.

45. Socket Is the Application Interface

This is an important bridge:

Nginx
 ↓
socket API
 ↓
Linux kernel
 ↓
TCP
 ↓
IP
 ↓
network interface

Applications don’t normally manipulate TCP internals directly.

46. `connect()`

A client application can request a TCP connection through a system-call interface such as:

connect()

Conceptually:

Browser
 ↓
connect(server:443)
 ↓
kernel
 ↓
TCP handshake

47. `bind()`

A server can associate a socket with an address/port using:

bind()

Conceptually:

Nginx
 ↓
bind()
 ↓
:443

48. `listen()`

The server then makes the socket listen:

listen()

Conceptually:

bind
 ↓
listen
 ↓
wait for connections

49. `accept()`

When a connection arrives:

accept()

can create/access the connected socket for the application.

Conceptually:

Listening socket
       ↓
accept()
       ↓
Connected socket

50. Your Nginx Server

A simplified representation:

Nginx
 │
 ├── listening socket :80
 │
 └── listening socket :443

Incoming client connections then become individual connected sockets.

51. TCP Port 443

Your HTTPS architecture is therefore:

Internet
 ↓
IP address
 ↓
TCP
 ↓
destination port 443
 ↓
Nginx listening socket

Then:

TCP connection
 ↓
TLS
 ↓
HTTP

52. Connection Refused

Now we can understand an important error.

Suppose the network path works, but nothing is listening on port 443.

The connection can be actively rejected.

You may see:

Connection refused

Conceptually:

Client
 ↓
TCP SYN
 ↓
Server
 ↓
no listener
 ↓
connection rejected

53. Connection Timeout

A timeout is different.

Suppose packets cannot reach the server or responses are filtered.

The client may keep waiting.

Eventually:

Connection timed out

Conceptually:

Client
 ↓
SYN
 X

with no usable response.

Possible causes include:

Cloud firewall
Host firewall
Routing
Network outage
Wrong IP
Server unavailable

54. Connection Reset

Another error:

Connection reset

usually means the connection was forcibly terminated rather than simply receiving no response.

Possible causes include:

Application
Firewall
Kernel
Proxy/load balancer
Network equipment

The exact cause requires investigation.

55. Three Different Problems

Memorize:

Connection refused
=
connection reached a point where it was actively rejected

Connection timed out
=
expected communication did not arrive in time

Connection reset
=
existing/attempted connection was forcibly terminated

These clues help identify which layer to investigate.

56. TCP FIN

TCP connections need to close gracefully.

One side can send:

FIN

meaning approximately:

I have finished sending data.

57. TCP Connection Closing

A simplified four-message close can look like:

Client                    Server

FIN       ───────────────►

          ◄────────────── ACK

          ◄────────────── FIN

ACK       ───────────────►

The actual behavior can vary depending on which side initiates closure and application state.

58. FIN vs RST

Two important TCP mechanisms:

FIN
=
orderly connection shutdown

RST
=
abrupt/reset connection

59. TIME-WAIT

After a TCP connection closes, one side can enter:

TIME-WAIT

This exists for important protocol reasons, including preventing delayed packets from an old connection from interfering with a later connection using the same tuple.

60. Why TIME-WAIT Exists

Imagine:

Old connection
 ↓
delayed packet

Then a new connection reuses the same connection identifiers.

Without appropriate safeguards, an old delayed packet could potentially be mistaken for part of the new connection.

TIME-WAIT helps prevent this.

61. Check TIME-WAIT

You can inspect:

sudo ss -ant state time-wait

On a busy web server you may see many entries.

That isn’t automatically a problem.

62. CLOSE-WAIT

Another state you may encounter:

CLOSE-WAIT

It means the remote side has closed its sending direction, but the local application has not yet fully closed its socket.

Large numbers of long-lived CLOSE-WAIT connections can sometimes indicate application/socket handling problems.

63. TCP Connection Lifecycle

Simplified:

LISTEN
   ↓
SYN
   ↓
SYN-RECEIVED
   ↓
ESTABLISHED
   ↓
data transfer
   ↓
FIN
   ↓
closing states
   ↓
TIME-WAIT
   ↓
closed

The exact state transitions depend on which endpoint initiates each action.

64. TCP vs UDP

Let’s make the distinction clear.

TCP

Connection-oriented
Reliable
Ordered
Byte stream
Retransmission
Flow control
Congestion control

UDP

Datagram-oriented
No built-in reliable delivery
No built-in ordering
No TCP-style connection establishment

65. Why HTTPS Traditionally Uses TCP

Traditional HTTP/1.1 and HTTP/2 deployments commonly use:

HTTPS
 ↓
TLS
 ↓
TCP

HTTP/3 is different.

It uses:

HTTP/3
 ↓
QUIC
 ↓
UDP

We will study that later.

66. TCP and TLS Relationship

TLS doesn’t replace TCP.

They have different responsibilities.

TLS
 ↓
secure application data

TCP
 ↓
reliable transport

So:

HTTPS
=
HTTP
+
TLS
+
TCP

67. TCP and IP Relationship

IP doesn’t guarantee reliable delivery.

IP primarily provides packet addressing/routing.

TCP adds reliability and connection semantics above IP.

Conceptually:

Application
 ↓
TCP
 ↓
IP
 ↓
Network

68. IP Can Lose Packets

IP itself does not promise:

"Every packet will arrive."

Packets can be:

Dropped
Delayed
Duplicated
Reordered

TCP handles many of these issues for its byte stream.

69. Example: Packet Loss

Suppose your website sends:

100 TCP segments

and one gets lost.

TCP can detect the missing data and retransmit it.

The application generally doesn’t need to know that a particular TCP segment was lost.

70. But TCP Doesn’t Fix Everything

If the network is completely unavailable:

Client
 X
Server

TCP cannot magically repair the network.

Eventually the connection fails.

TCP reliability exists within the limits of an operating network path.

71. TCP Latency

Every network communication has latency.

For example:

Client
 ↓
Internet
 ↓
Server

takes time.

The TCP handshake adds connection-establishment latency.

TLS then adds handshake processing/round trips.

Modern protocols optimize these costs.

72. Round-Trip Time

RTT means:

Round-Trip Time

Conceptually:

Client
  ↓
Server
  ↑
Client

The time for that round trip is RTT.

73. Why RTT Matters

Suppose:

RTT = 10 ms

versus:

RTT = 200 ms

Interactive communication feels very different.

For web hosting, RTT affects connection setup, TLS, and data transfer behavior.

74. TCP Handshake + TLS

For a traditional HTTPS connection, conceptually:

DNS
 ↓
TCP handshake
 ↓
TLS handshake
 ↓
HTTP request

Therefore several network exchanges can occur before the server sends the actual page.

TLS 1.3 reduces handshake overhead compared with older TLS versions.

75. Connection Reuse

HTTP can reuse an established TCP/TLS connection.

Instead of:

Request 1
 ↓
new TCP
 ↓
new TLS

Request 2
 ↓
new TCP
 ↓
new TLS

the browser can often do:

TCP
 ↓
TLS
 ↓
Request 1
Request 2
Request 3
Request 4

This is much more efficient.

76. HTTP Keep-Alive

HTTP connection persistence allows connections to be reused.

This reduces repeated:

TCP handshake
TLS handshake

costs.

77. HTTP/2

HTTP/2 can multiplex multiple HTTP streams over one TCP connection.

Conceptually:

One TCP connection
       │
       ├── Request A
       ├── Request B
       ├── Request C
       └── Request D

This is a major improvement over opening a separate connection for every resource.

78. But TCP Has Head-of-Line Effects

Because TCP provides one ordered byte stream, loss of a TCP segment can delay delivery of later bytes to applications even if those later bytes have already arrived.

HTTP/2 over TCP can therefore experience a form of transport-level head-of-line blocking.

This is one reason QUIC/HTTP/3 was developed.

79. QUIC

QUIC is a modern transport protocol built over UDP.

Conceptually:

HTTP/3
 ↓
QUIC
 ↓
UDP
 ↓
IP

QUIC provides transport features such as:

Reliable streams
Encryption integration
Congestion control
Connection migration

We will study this in a later lesson.

80. Your Website Today

When you access:

https://templates.cresignsys.com

a simplified traditional path is:

DNS
 ↓
IP
 ↓
TCP :443
 ↓
TLS
 ↓
HTTP
 ↓
Nginx

Then:

Nginx
 ↓
static file

or:

Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL

81. Practical TCP Investigation

Run:

sudo ss -lntp

Look for:

:80
:443

Then:

sudo ss -ntp

Look for:

ESTAB

82. Check Nginx

sudo systemctl status nginx

Then:

sudo ss -lntp | grep ':443'

You want to understand:

Nginx
 ↓
listening
 ↓
443

83. Test the TCP Port

From another machine, you can test whether TCP 443 is reachable.

For example:

nc -vz templates.cresignsys.com 443

If nc is installed.

This tests TCP connectivity, not whether the entire HTTPS application is functioning correctly.

84. Test HTTPS

Then:

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

This goes further:

DNS
 ↓
TCP
 ↓
TLS
 ↓
HTTP

So curl -v is a valuable diagnostic tool.

85. The Diagnostic Ladder

When troubleshooting a website:

Layer 1
DNS
 ↓
Layer 2
IP routing
 ↓
Layer 3
TCP 443
 ↓
Layer 4
TLS
 ↓
Layer 5
HTTP
 ↓
Layer 6
Nginx
 ↓
Layer 7
PHP-FPM
 ↓
Layer 8
WordPress
 ↓
Layer 9
MySQL

This layered thinking is much more useful than randomly restarting services.

86. The Deep Mental Model

Think of TCP as a conversation channel.

Browser
   │
   │  "Can we communicate?"
   ▼
Server

Browser
   │
   │  "I sent bytes 1000–1999."
   ▼
Server

Server
   │
   │  "I received them."
   ▼
Browser

TCP keeps track of this communication state.

87. Most Important TCP Concepts

Memorize these:

TCP
=
reliable ordered byte stream

SYN
=
start connection

SYN-ACK
=
server response to connection initiation

ACK
=
acknowledgement

Sequence number
=
tracks byte position

Retransmission
=
recover lost data

Flow control
=
protect receiver

Congestion control
=
protect network

FIN
=
orderly shutdown

RST
=
connection reset

88. TCP Error Vocabulary

TIMEOUT
=
no usable response within expected time

REFUSED
=
connection actively rejected

RESET
=
connection forcibly terminated

CLOSE-WAIT
=
remote closed, local application hasn't fully closed

TIME-WAIT
=
connection remains temporarily in a closing state

These terms become extremely useful when diagnosing VPS problems.

89. Complete Current Knowledge Map

You have now reached:

                         WEBSITE
                            │
                            ▼
                       DOMAIN NAME
                            │
                            ▼
                           DNS
                            │
                            ▼
                         IP ADDRESS
                            │
                            ▼
                         ROUTING
                            │
                            ▼
                           TCP
                            │
                            ▼
                           TLS
                            │
                            ▼
                          HTTP
                            │
                            ▼
                          NGINX
                            │
                  ┌─────────┴─────────┐
                  ▼                   ▼
              Static file          PHP-FPM
                                      │
                                      ▼
                                  WordPress
                                      │
                                      ▼
                                    MySQL

And underneath all of this:

                    LINUX KERNEL
                         │
          ┌──────────────┼──────────────┐
          ▼              ▼              ▼
       Network          Memory       Filesystem
          │              │              │
          ▼              ▼              ▼
         TCP           RAM/VM        Storage

Lesson 037 Summary

The central idea:

TCP takes an unreliable packet-delivery system such as IP and provides applications with a reliable, ordered byte stream.

For your HTTPS website:

DNS
 ↓
IP
 ↓
TCP 443
 ↓
3-way handshake
 ↓
TLS handshake
 ↓
HTTP
 ↓
Nginx

The TCP handshake:

Client                     Nginx

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

        ESTABLISHED

Then the actual HTTPS communication begins.

Next Lesson — 038

TLS 1.3 — Deep Cryptographic Basics

We will now return to the SSL/TLS topic and go much deeper:

TCP
 ↓
TLS ClientHello
 ↓
ServerHello
 ↓
Cipher suites
 ↓
Key exchange
 ↓
ECDHE
 ↓
Public/private keys
 ↓
Digital signatures
 ↓
Certificate
 ↓
Certificate chain
 ↓
Certificate Authority
 ↓
Let's Encrypt
 ↓
Session keys
 ↓
AES-GCM / ChaCha20-Poly1305
 ↓
Encrypted HTTP

Then we will trace the exact role of your fullchain.pem and privkey.pem files inside Nginx during the TLS handshake.

CresignSys Learn — Lesson 037

TCP — Deepest Basics

1. What Is TCP?

Transmission Control Protocol

2. TCP Is Not HTTP

3. TCP Has No Idea What a Web Page Is

4. TCP Endpoint

5. Client and Server

6. Listening

7. What Happens When the Browser Connects?

8. TCP Three-Way Handshake

Three-way handshake

9. Why a Handshake?

10. SYN

11. Sequence Number

12. Initial Sequence Number

13. SYN-ACK

14. ACK

15. Then TLS Starts

16. TCP Connection Is a State Machine

17. LISTEN

18. SYN-SENT

19. SYN-RECEIVED

20. ESTABLISHED

21. Check Established Connections

22. TCP Is a Byte Stream

23. TCP Segments

24. TCP Segment

25. IP Packet

Encapsulation

26. Encapsulation

27. Receiving Side

Decapsulation

28. Acknowledgements

29. Lost Packet

30. TCP Retransmission

31. Why TCP Is Reliable

32. Ordering

33. Duplicate Data

34. Flow Control

Flow control

35. Receive Window

36. Congestion Control

Flow control

Congestion control

37. Why Congestion Control Matters

38. Congestion Window

Congestion window

39. Slow Start

Slow Start

40. TCP Is Not Always the Same

41. Check TCP Congestion Control

42. TCP Buffering

43. TCP Send Buffer

44. TCP Receive Buffer

45. Socket Is the Application Interface

46. connect()

47. bind()

48. listen()

49. accept()

50. Your Nginx Server

51. TCP Port 443

52. Connection Refused

53. Connection Timeout

54. Connection Reset

55. Three Different Problems

56. TCP FIN

57. TCP Connection Closing

58. FIN vs RST

59. TIME-WAIT

60. Why TIME-WAIT Exists

61. Check TIME-WAIT

62. CLOSE-WAIT

63. TCP Connection Lifecycle

64. TCP vs UDP

TCP

UDP

65. Why HTTPS Traditionally Uses TCP

66. TCP and TLS Relationship

67. TCP and IP Relationship

46. `connect()`

47. `bind()`

48. `listen()`

49. `accept()`