DEV Community

Cover image for (Transmission Control Protocol)TCP and TCP Header: Networking
Kaustuv Pokharel
Kaustuv Pokharel

Posted on

(Transmission Control Protocol)TCP and TCP Header: Networking

#tcp #networking #network #computerscience

Excellent observation — you're noticing those numbers on top and side of the TCP header diagram.

Let’s break that part down

What Do 0 1 2 3 and 0123456789... Mean in the Header Diagram?

This is a bit-level layout of the TCP header.

Top Row: 0 1 2 3

This row represents 32-bit word boundaries.

  • Each group (0, 1, 2, 3, etc.) stands for 4 bytes (32 bits).
  • It's showing how the entire header is organized as a series of 32-bit blocks, which is how computers store and process them efficiently.

Why 32 bits?
CPUs are optimized to process 32-bit or 64-bit words at once. TCP headers are aligned to 32-bit boundaries to boost speed.

Second Row: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

These are bit positions inside each 32-bit word (horizontal axis, left to right).

  • Each tick = 1 bit.
  • After 15, it wraps around again with 0,1... for the next 16 bits.
  • So from left to right, you’re seeing bit 0 to 31 of that 32-bit chunk.

Left Side: 0 1 2 3

These numbers on the left represent row numbers → how many 32-bit rows down you are in the header.

So:

  • Row 0 = first 32 bits (4 bytes)
  • Row 1 = next 32 bits
  • …
  • Row 3 = last block in the minimal 20-byte TCP header

Reminder from the Image:

“One tick mark represents one bit position.”

So when you see a field that spans 16 tick marks — that means it's 16 bits = 2 bytes wide.

How to Read It

Let’s pick an example: Source Port is in row 0, bit 0 to 15 (16 bits).

  • The + signs mark 32-bit (4-byte) boundaries.
  • Each field is aligned within those 32-bit words.
  • Data Offset is just 4 bits, which is why it sits at bit position 0-3 on row 4.

Real Example (Row by Row)

Row Bit Range Fields
0 0–15 Source Port (16 bits)
16–31 Destination Port (16 bits)
1 0–31 Sequence Number (32 bits)
2 0–31 Acknowledgment Number (32 bits)
3 0–3 Data Offset (4 bits)
4–6 Reserved (3 bits)
7 NS flag
8–15 CWR, ECE, URG, ACK, PSH, RST, SYN, FIN
16–31 Window Size (16 bits)
4 0–15 Checksum
16–31 Urgent Pointer
5+ Options + Padding (if present)
... Payload data

Why This Layout?

  • Compact: Every bit is carefully packed — no wasted space.
  • Efficient: 32-bit words are perfect for CPU alignment.
  • Extendable: Options + reserved bits make TCP forward-compatible.

Perfect, let’s now go field-by-field in the TCP header, but this time from the creator’s perspective,

Background: Why TCP Needs a Header at All

TCP is designed to provide:

  • Reliable delivery over unreliable IP (which can drop, reorder, duplicate packets)
  • Ordered byte stream
  • Error checking
  • Flow & congestion control

Thus, every TCP segment must carry enough metadata to:

  1. Track what’s being sent/received
  2. Allow reordering, retransmission, and confirmation
  3. Handle connection establishment and teardown

1. Source Port (16 bits)

Why it was created:

To identify which application on the sender's side is sending the data.

If not included:

Receiver wouldn’t know where to route the response — especially in systems with multiple open connections.

Analogy:

Think of it like the return address on a letter.

Example:

  • Web browser opens a page (source port = 49500), connects to google.com:443.
  • Server uses 443 as destination, and 49500 as reply source.

2. Destination Port (16 bits)

Why it was created:

To indicate which application/service should receive the data on the destination machine.

If not included:

The OS wouldn’t know whether to pass data to a web server, email server, or FTP daemon.

Analogy:

Like writing “To: Sales Department” on a company envelope.

Example:

Connecting to a web server uses port 80 (HTTP), or 443 (HTTPS).

3. Sequence Number (32 bits)

Why it was created:

To ensure in-order delivery and detect packet loss/duplication.

If not included:

  • You could receive packets out of order.
  • Lost packets would be hard to detect.
  • Duplicated packets would corrupt data.

Analogy:

Page numbers in a book — imagine receiving 2, 3, 1, 4.

Example:

You send 3000 bytes: packet 1 (0–999), packet 2 (1000–1999), packet 3 (2000–2999).
If packet 2 is lost, the receiver knows to ask again.

4. Acknowledgment Number (32 bits)

Why it was created:

To let sender know what data has been successfully received.

If not included:

The sender would have no clue if data arrived or was lost — no way to retransmit reliably.

Analogy:

A “Received” stamp on a document.

Example:

If the receiver got all data up to byte 5000, it sends ACK = 5001.

5. Data Offset (4 bits)

Why it was created:

To tell where the TCP header ends and the actual data begins.

If not included:

You couldn’t parse the packet — where are the flags? Where’s the data? It’d be ambiguous if options were used.

Analogy:

Table of contents telling where Chapter 1 starts.

Example:

Header = 20 bytes → Offset = 5 (because 5 × 4 = 20).

6. Reserved (3 bits)

Why it was created:

To future-proof TCP for new features.

If not included:

Adding new control fields would require breaking compatibility.

Analogy:

Empty parking spots reserved for future use.

7. Control Flags (9 bits)

Each bit represents a control instruction. Let's break them down:

Flag Full Form Why It Exists What Breaks Without It
URG Urgent Urgent data like keyboard interrupt (legacy) Can’t prioritize emergency info
ACK Acknowledgment Used in almost every packet after the first SYN Can’t confirm delivery
PSH Push Tells receiver to pass data to app immediately Data might be buffered
RST Reset Kill connection immediately Can’t handle bad or spoofed connections
SYN Synchronize Establish connection (step 1 of 3-way handshake) Connection setup is impossible
FIN Finish Gracefully close a connection Can’t signal end of transmission
ECE/CWR/NS ECN bits for congestion Helps manage congestion in modern networks No congestion signaling

Example:

  • SYN: Initiates connection
  • SYN+ACK: Response with agreement
  • FIN: Closes connection
  • RST: Force stop (e.g., invalid packet received)

8. Window Size (16 bits)

Why it was created:

To perform flow control: telling sender how much data can be accepted.

If not included:

The sender might flood the receiver’s buffer, causing overflow or dropped packets.

Analogy:

Your inbox says, “I can only receive 5 emails right now.”

Example:

Window = 65535 → receiver can accept 65535 bytes.
When full, it tells sender to stop.

9. Checksum (16 bits)

Why it was created:

To detect corruption of header or data in transit.

If not included:

Corrupt packets would go unnoticed, causing bad data, crashes, or security flaws.

Analogy:

Seal on a package — if broken, don’t trust it.

Example:

You send “hello” but noise changes it to “h3llo”. Checksum mismatch alerts the receiver.

10. Urgent Pointer (16 bits)

Why it was created:

To point to urgent data when the URG flag is set — legacy for telnet/terminal systems.

If not included:

Legacy apps couldn’t prioritize user interrupts.

Analogy:

“Skip to this part immediately!” note.

Example:

Used to send Ctrl+C from terminal user.

11. Options (Variable)

Why it was created:

To allow extension of TCP capabilities (MSS, window scaling, timestamps, SACK).

If not included:

TCP would be stuck with static features and couldn’t adapt to evolving networks (e.g., gigabit speeds, large windows).

Analogy:

Extra paper in a contract for terms.

Example:

  • MSS Option: “Don’t send more than 1460 bytes”
  • Timestamp Option: Improve RTT measurement

12. Padding

Why it was created:

Ensures TCP header ends on a 32-bit boundary.

If not included:

Misalignment could slow down CPU processing and break parsing.

Analogy:

Adding blank pages to align chapters in a book.

13. Data (Payload)

Why it was created:

The actual message/data being delivered to the application.

If not included:

You’d be sending metadata but no meaningful content.

Analogy:

The gift inside the wrapping.

Stage 1: Connection Establishment (TCP 3-Way Handshake)

Before data is sent, TCP must establish a connection.

Imagine:

You (Client) want to connect to a web server (Server) on port 80.

Step 1: Client sends SYN 

Source Port: 53123         → your random port
Destination Port: 80       → HTTP server
Sequence Number: 1000      → start of byte stream
ACK Number: 0              → not used yet
Flags: SYN=1               → I want to start a connection
Window Size: 65535         → I can accept this much data
Checksum: valid
Options: MSS = 1460
Enter fullscreen mode Exit fullscreen mode

🔧 What’s happening:

  • SYN flag is set to start connection
  • Sequence number says “my byte stream starts at 1000”
  • Options tell the server the Maximum Segment Size (MSS)

Step 2: Server responds with SYN + ACK 

Source Port: 80            → Server replying from port 80
Destination Port: 53123    → Back to your app
Sequence Number: 8000      → Server’s stream starts here
ACK Number: 1001           → Acknowledging your SYN (seq+1)
Flags: SYN=1, ACK=1
Window Size: 65535
Checksum: valid
Enter fullscreen mode Exit fullscreen mode

Server:

  • Acknowledges your SYN by setting ACK = 1001
  • Sends its own SYN with sequence number 8000

Step 3: Client sends ACK 

Source Port: 53123
Destination Port: 80
Sequence Number: 1001      → Next byte I’ll send
ACK Number: 8001           → I received your SYN
Flags: ACK=1
Enter fullscreen mode Exit fullscreen mode

Now connection is established!

Stage 2: Data Transfer Begins

Let’s say you’re sending this HTTP GET request:

GET /index.html HTTP/1.1\r\nHost: example.com\r\n\r\n
Enter fullscreen mode Exit fullscreen mode

It’s 60 bytes long.

Client sends data packet: 

Source Port: 53123
Destination Port: 80
Sequence Number: 1001
ACK Number: 8001
Flags: ACK=1, PSH=1
Window Size: 65535
Checksum: valid
Data: 60 bytes of GET request
Enter fullscreen mode Exit fullscreen mode

Key insights:

  • Sequence Number = 1001 (your byte stream continues)
  • PSH = 1 (push data to app immediately)
  • Server will now acknowledge this by sending ACK = 1061

Server responds with data

Let’s say the server sends back HTML (e.g., 1000 bytes)

Source Port: 80
Destination Port: 53123
Sequence Number: 8001
ACK Number: 1061
Flags: ACK=1, PSH=1
Data: 1000 bytes of HTML
Enter fullscreen mode Exit fullscreen mode
  • ACK=1061: acknowledges your GET
  • Sequence=8001: server sends its byte stream
  • Your client now acknowledges with ACK=9001

Stage 3: Connection Termination

Once the server is done sending, it will gracefully close the connection using the FIN flag.

Step 1: Server sends FIN 

Source Port: 80
Destination Port: 53123
Sequence Number: 9001
ACK Number: 1061
Flags: FIN=1, ACK=1
Enter fullscreen mode Exit fullscreen mode

Step 2: Client ACKs it 

Flags: ACK=1
ACK Number: 9002
Enter fullscreen mode Exit fullscreen mode

Step 3: Client sends its own FIN 

Flags: FIN=1, ACK=1
Sequence Number: 1061
Enter fullscreen mode Exit fullscreen mode

Step 4: Server ACKs that, and connection is fully closed 

Flags: ACK=1
ACK Number: 1062
Enter fullscreen mode Exit fullscreen mode

Summary of Header Fields Across Phases

Field Handshake Data Transfer Termination
Source/Dest Port YES YES YES
Sequence Number YES YES YES
Acknowledgment YES (after first packet) YES YES
Data Offset Always Always Always
Flags SYN, ACK, FIN ACK, PSH, URG FIN, ACK
Window YES (flow control) YES YES
Checksum Always Always Always
Options SYN packets Sometimes Rarely
Padding Only if options used – –
Data No YES Sometimes (e.g., FIN can carry data)

Flow Visualization (Simplified) 

Client                             Server
  | SYN (seq=x) -----------------> |
  | <-------------- SYN+ACK (seq=y, ack=x+1)
  | ACK (ack=y+1) --------------> |

  | GET Request ----------------> |
  | <-------------- HTML Response
  | ACK ------------------------> |

  | <------------ FIN (I'm done)
  | ACK ------------------------> |
  | FIN ------------------------> |
  | <------------ ACK (closed)
Enter fullscreen mode Exit fullscreen mode

What If We Remove a Field?

Field Removed Consequence
Sequence Number No ordering, retransmission, reliability breaks
ACK Number Sender doesn’t know what was received
Window Size Receiver might be overwhelmed
Checksum Corrupt packets go undetected
Flags Can’t start or stop connection
Offset Can’t know where data begins
Ports Can’t route data to app

This header isn't just a data structure — it's a conversation manager.

It allows two devices to:

  • Start talking
  • Exchange data responsibly
  • Detect losses
  • Avoid overload
  • End the talk gracefully

TCP header is what turns the chaos of the internet into something structured and reliable.

Top comments (0)