Reliable when needed, fast when it matters, essential always.

Turning raw data into meaningful communication.

First Listen: let your ears lead the way before your mind takes notes.

Then read: let your eyes explore before your mind starts to explain.

TCP/IP: Transport Essentials

Tuesday, November 18, 2025

The TCP/IP model is often shown as four layers: Application, Transport, Internet, and Network Access. Of these, the Transport layer is the quiet professional—the layer that rarely gets the spotlight, but without which nothing above it could communicate reliably or efficiently. If the Application layer is the brain, the Transport layer is the heart, pumping data reliably and rhythmically so the entire system stays alive.

In this lesson, we explore the Transport layer by studying its major functions

• Session Multiplexing
• Identifying the Applications
• Segmentation
• Flow Control
• Connection-Oriented
• Reliability Functions
  • Detecting and retransmitting dropped packets
  • Detecting duplicate or out-of-order data
  • Avoiding congestion in the network

We will also show how these concepts appear in Cisco CLI and conclude with core troubleshooting commands.

Session Multiplexing

Imagine sitting in a noisy cafe. Around you, dozens of people are having completely different conversations. Even though everyone’s voices mix in the air, your brain is capable of separating the sound waves and focusing on your conversation partner. That ability to manage many conversations at once is session multiplexing.

Computers do the same thing.

When your laptop loads a webpage, it may need to talk to

• a web server (TCP port 80 or 443),
• a DNS server (UDP port 53),
• maybe a CDN (Content Delivery Network),
• background applications like Teams or Slack,
• your OS checking for updates.

Your device must handle all these conversations simultaneously without confusion.

The Transport layer achieves this by using ports.

• Source port = like a return address
• Destination port = like the address of the service you want

A single device can maintain thousands of simultaneous sessions because each connection is uniquely identified by the *5-tuple

• Source IP
• Source Port
• Destination IP
• Destination Port
• Transport protocol (TCP/UDP)

This is what prevents your HTTP traffic from being mistaken for your DNS queries—even though they may be sent at the same time through the same NIC.

In Cisco CLI You can view active sessions using

show ip sockets
show control-plane host open-ports
show tcp brief

These commands reveal which ports are in use and which protocols are active on the system.

(*In networking, a 5-tuple is a set of five values that uniquely identify a traffic flow or session between two endpoints. It’s basically the fingerprint of a connection.)

Note for Packet Tracer Users
Packet Tracer is a great learning tool, but remember that it does not support every real IOS command. Some advanced commands—like show ip sockets, show control-plane host open-ports, and show tcp brief —won’t work because Packet Tracer does not fully emulate the internal processes of a real Cisco device.

How Ports Map to Programs

Ports act like department numbers in a large office building. When a letter arrives, the front desk uses the department number to know where to deliver it.

Similarly

• A packet arriving at TCP port 443 is routed to whatever application is listening for SSL/TLS.
• A packet arriving at UDP port 53 goes to the DNS resolver.
• If your device opens a web browser session using source port 50123, responses using that port automatically return to your browser—not to some other application.

IANA maintains the official port number list, but in reality, most admin interactions revolve around:

You must memorize this information.
It’s essential for the CCNA exam, and knowing it by heart will make troubleshooting and configuration much easier during your studies and real-world networking tasks.

• Well-known ports (0–1023) – System services
• Registered ports (1024–49151) – Apps and vendors
• Ephemeral ports (49152–65535) – Temporary client sessions

On Cisco Routers you can see open ports and which services are listening

show ip sockets
show control-plane host open-ports

This is helpful when troubleshooting issues like

• A service not listening on the expected port
• Conflicting applications
• Unexpected open ports that may indicate malware/session hijacking

Segmentation

Think of segmentation like shipping a large desk by mail. You can’t just put the whole thing into an envelope—you dismantle it into small parts, ship each box separately, and reassemble it at the destination.

That’s what TCP does with data.

Many applications produce data streams too large for a single network packet. The Transport layer solves this by

• Breaking the data stream into small pieces: Segments
• Numbering them: Sequence numbers
• Ensuring they’re reassembled correctly at the destination

Segmentation enables

• Efficient handling of large files
• Parallel transmission
• Reliable recovery from partial loss

You can observe in Cisco CLI segmentation behavior using

show ip traffic
show interfaces | include MTU

If packets exceed the MTU, segmentation (or fragmentation at the IP layer) occurs.

Flow Control

Flow control prevents a sender from overwhelming a slower receiver.

Think of it like walking a dog

• If the dog pulls too fast, you tug the leash (slow down!).
• If the dog drifts too slow, you nudge the leash (speed up!).

In TCP, this leash is the sliding window.

How It Works

• The receiver advertises how much buffer space it has.
• The sender is allowed to send that many bytes before needing acknowledgement.
• As ACKs arrive, the window slides forward, allowing more data to be transmitted.

If the destination begins to struggle, it advertises a smaller window, slowing down the flow of traffic.

Visualized Simply

• Window = 10 – sender can transmit 10 segments
• ACK for 5 segments – window slides – sender can transmit 5 more
  

Cisco CLI Commands
To view TCP window size and flow behaviors

show tcp statistics
show tcp brief all

These help diagnose slow applications or asymmetric performance issues.

The 3-Way Handshake

TCP offers a connection-oriented service, which means both endpoints set up a formal, reliable channel before exchanging data.

The famous three-way handshake works like this

SYN – Client: “I want to start a conversation with you!”
SYN-ACK – Server: “Ok, Let’s talk.”
ACK – Client: “Nice, here we go.”

Only after this handshake does data flow.

Why does this matter?

• It prevents false starts.
• It synchronizes sequence numbers.
• It enables negotiation of features like MSS and window scaling.

You can verify TCP handshake status via

show tcp brief
show ip traffic | include TCP

End-to-End Reliability

TCP implements several reliability mechanisms to ensure correct data delivery.

Detection and Retransmission of Dropped Packets

Using ACKs and sequence numbers, TCP knows exactly which segments arrive and which do not.

If a segment is missing, the receiver will send duplicate ACKs

• ACK for segment 4
• ACK for segment 4 again
• ACK for segment 4 again

At three duplicate ACKs the sender retransmits segment #5.

If no ACKs arrive at all, a timeout triggers retransmission.

This is similar to sending a multi-page letter

• If your friend says “I got page 1 and 2, but not 3” you resend page 3.
• If your friend says nothing, you resend the entire set after waiting.

Detection and Remediation of Duplicate or Out-of-Order Data

The network does not guarantee order. Packets may arrive like this

1, 2, 4, 5, 3

TCP handles this seamlessly

• It buffers out-of-order data
• Reassembles it using sequence numbers
• Discards duplicates

This prevents application errors and ensures that the receiving application gets a smooth, ordered stream.

Avoidance of Congestion in the Network

Congestion happens when too many devices try to transmit through the same bottleneck. Like cars piling up on a one-lane bridge, the network becomes slow, unstable, and chaotic.

TCP fights congestion using algorithms such as

• Slow Start
• Congestion Avoidance
• Fast Retransmit
• Fast Recovery

Slow Start?
TCP begins cautiously, sending just a little data. As ACKs arrive, it doubles the sending rate. If congestion occurs, it slows down again. Imagine entering a dark room:  You don’t sprint—you take small steps, then speed up when you feel confident.

Seeing Reliability in Action: Cisco CLI Verification

These commands show how TCP reliability mechanisms, ports, services, MTU settings, and traffic behavior appear in real Cisco devices—allowing you to validate, troubleshoot, and understand how the theory comes alive in the CLI.

Check TCP Sessions

show tcp brief
show tcp statistics

Check Ports and Listening Services

show ip sockets
show control-plane host open-ports

Check Interface MTU (affects segmentation)

show interfaces

Check Traffic Breakdown

show ip traffic

Troubleshooting

Reliable vs. Best-Effort Transport

TCP vs. UDP

Transport protocols exist to ensure that applications can communicate across networks with the right level of accuracy, speed, and efficiency. In the OSI model, we place these protocols at Layer 4, where the conversation between two devices is managed. Two major transport mechanisms dominate this layer: Reliable (connection-oriented) and Best-Effort (connectionless) delivery. In most CCNA scenarios, these terms map directly to TCP and UDP.

Connection-Oriented

Reliable transport is like having a structured, rule-based conversation where both parties track what was said, confirm understanding, and coordinate pacing. In networking terms, this is TCP’s job.

Reliable transport ensures four things

Guaranteed delivery
If a packet gets lost, corrupted, or arrives out of order, the sender retransmits it. TCP checks whether packets reached their destination through acknowledgments (ACKs).

Ordered delivery
TCP numbers every segment so the receiver can reassemble them properly, even if they arrive out of order.

Connection setup and teardown
Before sending data, TCP establishes a session using the famous 3-way handshake:

• SYN
• SYN-ACK
• ACK

At the end, it gracefully closes the connection with a 4-step FIN sequence.

Flow control and congestion control
TCP adjusts speed dynamically based on network conditions.

• If the network is congested, TCP slows down (congestion control).
• If the receiver is overloaded, TCP paces itself (flow control using window size).

TCP Analogy: Collaborative Coding Session
Think of two programmers collaborating on a shared code project over a live coding platform.

They start with a structured handshake.
Before coding, they join the same session and confirm they see each other

Programmer A says “Ready?”
Programmer B says “Ready—can you see my screen?”
Programmer A replies “Yes, confirmed.”

Every update is acknowledged.
When Programmer A types a code change, the system ensures Programmer B receives it and confirms synchronization. If any update fails to sync, the system resends it.

Order matters.
If code lines arrived scrambled, the whole program would break. So the system tracks changes with precise ordering.

Flow control happens naturally.
If one programmer’s connection slows, the platform adapts and sends updates more slowly to keep the session synchronized.

This collaborative-coding metaphor shows all core features of TCP without referencing mail, parcels, or couriers.

Typical Applications Using TCP

• Web browsing (HTTP/HTTPS)
• Email (SMTP, IMAP, POP3)
• File transfer (FTP, SFTP)
• Remote admin (SSH, Telnet)

These applications need correctness, ordering, and reliability.

Connectionless

Now let’s contrast TCP with UDP. Best-effort transport does not guarantee delivery, ordering, or retransmission. UDP simply sends data as fast as possible and assumes the application can deal with imperfections—or doesn’t care about them.

UDP’s design is intentionally lightweight

No connection establishment
There is no handshake. Data is sent immediately.

No reliability mechanisms
UDP does not track:

• Did the packet arrive? My interest just timed out—no retransmission expected.
• Was it corrupted? No worries, no cares, no stress.
• Is it in the correct sequence? I care exactly zero.

Speed over reliability
Because it avoids checks and overhead, UDP can transmit faster than TCP.

Applications handle losses themselves (if needed)
If reliability matters, the application—not the protocol—handles it.

UDP Analogy: Live Stage Performance Feed

Imagine a backstage team broadcasting live real-time camera feeds to giant screens during a concert.

Speed is everything.
If a frame is dropped, no one pauses the concert to resend it.

There is no handshake.
Once the camera is on, the feed immediately starts sending frames to the screen.

Some imperfections are acceptable.
A tiny glitch or missing frame isn’t noticeable when everything is moving fast.

The show continues regardless.
UDP behaves like this: continuous, high-speed data flow prioritizing real-time performance over accuracy.

Applications Using UDP

• Real-time voice/video (VoIP, video conferencing)
• Online gaming
• Streaming media
• DNS queries
• DHCP

These applications prefer speed and low latency, even at the cost of the occasional missing packet.

TCP vs. UDP

Practical Troubleshooting Scenarios

Scenario 1: A web server is unreachable (uses TCP 80/443)

Steps
Ping the server (ICMP)
Check port reachability with Telnet: telnet <server> 80
Verify ACLs: show access-lists
Inspect NAT if applicable:  show ip nat translations

Scenario 2: VoIP call drops or has choppy audio (UDP)

Steps
Check interface drops: show interfaces | include drop
Verify QoS:  show policy-map interface
Check for latency or jitter:  show interfaces <int> | include rate

Scenario 3: DNS queries failing (UDP 53, fallback TCP 53)

Steps
Test DNS: nslookup www.example.com
Ensure outbound UDP 53 is allowed: show access-lists
Check if server is reachable on TCP 53 (some large queries use TCP): telnet <dns-server> 53

Troubleshooting

TCP (view sessions)

show tcp brief
show tcp

Test TCP ports

telnet <IP> <PORT>

Verify ACLs

show access-lists

Check NAT mappings

show ip nat translations

UDP

Test DNS

Nslookup

Verify DHCP

show ip dhcp binding
show ip dhcp server statistics

Verify NTP

show ntp associations
show ntp status

Identify open ports

show control-plane host open-ports

General Troubleshooting

Interface status

show ip interface brief
show interfaces

Routing

show ip route

TCP Characteristics & TCP Header

Think of TCP as the “polite, reliable, certified mail service” of the internet. When you absolutely must make sure your message arrives, arrives in the correct order, and is acknowledged, TCP is the protocol of choice.

Imagine mailing a box of important documents

• You number the pages
• You require a signature on delivery
• You resend anything that gets lost
• You maintain an entire conversation history

That’s TCP. It’s connection-oriented and reliable.

Characteristics of TCP

Connection-oriented (the handshake): Before sending data, TCP performs a three-way handshake

SYN – “Hello, can we talk?”
SYN-ACK – “Yes, I hear you. Can you hear me?”
ACK – “I hear you. Communication established.”

Like two people agreeing on a communication channel before discussing something important.

Reliable Delivery: TCP uses.

• Sequence numbers  –  Keeps packets in order
• Acknowledgments (ACKs)  –  Confirms receipt
• Retransmissions  –  Resends what was lost
• Timers  –  Detects when something is missing

This reliability ensures applications such as SSH, HTTP, HTTPS, Telnet, and FTP function without corruption.

Flow Control (using Window Size): TCP uses a window size to tell the sender, “Send me this much at a time.”  If the receiver is overwhelmed, it reduces the window.   This prevents packet drops.

Congestion Control: When the network is overloaded, TCP slows down automatically. Think of it like traffic: if everyone brakes due to congestion, you reduce speed to adapt.

Full-Duplex Communication: Data can flow both directions simultaneously.

TCP Header Fields Explained

Here’s a simplified breakdown of the main TCP header fields

• Source Port (16 bits): Port number of the sending application.
• Destination Port (16 bits): Port number of the receiving application (e.g., 80 for HTTP).
• Sequence Number (32 bits): This identifies the order of bytes being sent. Analogy: numbering pages in a book so they can be reassembled properly.
• Acknowledgment Number (32 bits): Indicates the next expected byte from the sender. Analogy: “I have successfully received everything up through page 200—send me page 201 next.”
• Header Length (Data Offset): Size of the TCP header.
• Control Flags (6 bits) [URG] [ACK] [PSH] [RST] [SYN] [FIN]: These flags define the state of communication. Important ones
  

SYN – start connection
ACK – acknowledgment
FIN – close connection
RST – reset connection
PSH – push data to application immediately
URG – urgent data

• Window Size (16 bits): Used for flow control.
• Checksum (16 bits): Ensures data integrity.
• Urgent Pointer (16 bits): Points to urgent data when the URG flag is set.
• Options: Often includes MSS (Maximum Segment Size) and Window Scaling.

Viewing TCP Connections

R1# show tcp brief
R1# show control-plane host open-ports
R1# show ip sockets
R1# show ip traffic | include TCP

To troubleshoot an SSH session

R1# debug ip tcp transactions
R1# debug ip packet detail

UDP Characteristics & UDP Header

If TCP is certified mail, UDP is the “postcard” of networking—fast, minimal overhead, no guarantees. You drop the postcard in a mailbox and trust it will arrive, but you don’t get a confirmation or tracking number.

Key Characteristics of UDP

Connectionless

• No handshake
• No session setup
• Data is launched into the network without a prior agreement.

Unreliable (No Delivery Guarantees) UDP does not

• Acknowledge packets
• Track sequence numbers
• Retransmit lost packets
• Control congestion
  

Applications using UDP must handle these issues themselves if needed.

Low Overhead: Since UDP uses a very small header (only 8 bytes), it’s extremely efficient.

Perfect for

• Voice (VoIP)
• Video
• DNS queries
• Online gaming
• TFTP
• SNMP

Suitable for Real-Time Communications: In real-time applications, speed is more important than accuracy. A missing packet in a voice call is hardly noticeable—but a delay is.

UDP Header Fields Explained

The UDP header is simple—only 4 fields, each 16 bits, totaling 8 bytes

• Source Port (16 bits): Sending application’s port.
• Destination Port (16 bits): Receiving application’s port.
• Length (16 bits): Header + data size.
• Checksum (16 bits): Provides basic integrity, but UDP does not enforce reliability.

Cisco CLI Example: Viewing UDP Traffic

R1# show udp
R1# show ip sockets | include UDP
R1# show ip traffic | include UDP

Tracing DNS behavior

R1# debug ip udp

Common TCP/IP Application Ports
Port numbers identify what service a device wants to reach.

Analogy: An office building with many rooms.

• Port 22: Room for SSH
• Port 80: Room for HTTP
• Port 53: Room for DNS

If you knock on the wrong door, the wrong service answers—or no one answers at all.

Below are the CCNA-critical port numbers you must memorize.

FTP – File Transfer Protocol

• Port 21 (TCP) – Control channel (like the “conversation” about the file)
  Port 20 (TCP) – Data channel (the actual file being sent)

What it does
FTP is used to upload or download files between computers.
Think of it like an old-school file delivery service.
Not very secure, which is why today people prefer SFTP.

SSH – Secure Shell

• Port 22 (TCP)

What it does
SSH gives you secure, encrypted command-line access to routers, switches, and servers.
It’s like Telnet’s smarter, safer big brother.
This is what every network admin uses today.

Telnet

• Port 23 (TCP)

What it does
Unencrypted remote access.
Everything you type is sent in plain text—very unsafe.
It’s used mainly in labs or testing, not in real networks.

HTTP – Hypertext Transfer Protocol

• Port 80 (TCP)

What it does
This is regular, non-encrypted web browsing.
When you visit a website without HTTPS, you’re using HTTP.

HTTPS – Hypertext Transfer Protocol Secure

• Port 443 (TCP)

What it does
Encrypted web browsing using TLS.
This is the version used by almost every modern website.
If you see a lock in the browser—that’s HTTPS.

DNS – Domain Name System

• Port 53 (UDP) – Fast DNS queries (asking for an IP address)
• Port 53 (TCP) – Used when DNS transfers large data (like zone transfers)

What it does
DNS is the internet’s phonebook.
You ask: “What is google.com’s IP address?”
DNS answers.

TFTP – Trivial File Transfer Protocol

• Port 69 (UDP)

What it does
Very simple file transfer—no login, no encryption, tiny protocol.
Used a lot inside LANs to move IOS images to routers/switches.
Think of it as FTP’s lightweight cousin.

SNMP – Simple Network Management Protocol

• Port 161 (UDP) – Devices listen for SNMP requests
• Port 162 (UDP) – Devices send “traps” (alerts) to servers

What it does
SNMP lets network tools monitor devices.
You can get stats like CPU, bandwidth, interface status, and receive alerts when something breaks.
It’s the “network health monitoring system."

Cisco CLI Examples of Applications and Ports

Check what ports are open

R1# show control-plane host open-ports

Check DNS operation

R1(config)# ip name-server 8.8.8.8
R1# ping google.com
R1# debug domain

Check SNMP configuration

R1# show run | include snmp
R1# show snmp

Verify HTTP/HTTPS server on a router

R1# show ip http server status

IANA Port Number Registry

For a complete list of port numbers, visit the authority that manages all global port assignments:

– Before you click the link below, just know this: the ports we talked about earlier are more than enough for the CCNA exam. If you still want to visit the link, go for it — but don’t overload your brain! I’m giving it to you as bonus info, not a stress test.

Service Name and Transport Protocol Port Number Registry
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml

This list is updated constantly and covers all registered, system, and dynamic/private ports.

Troubleshooting CLI Commands

TCP Troubleshooting

show tcp brief
debug ip tcp transactions
show ip sockets
show control-plane host open-ports
show ip traffic | include TCP

UDP Troubleshooting

show udp
debug ip udp
show ip sockets
show ip traffic | include UDP

Application/Port Troubleshooting

show control-plane host open-ports
show ip http server status
show run | include snmp
debug domain

Summary

Grab the Lab and Test Your Skills

Documentation and topology (for this lab) — click here

[Return to CCNA Study Hub] — Next Stop: [Section 2 | HTTP DNS DHCP ] …Currently Buffering… Available Soon!